Claude Codeに「毎回説明」をやめさせる、複数クライアント管理の情報設計

2026年4月11日

AIエージェントに毎朝同じ説明をしていないだろうか。

「このクライアントはこういう業態で、こういうトーンで、こっちのドメインは東京用であっちは大阪用で……」。昨日説明したはずなのに、新しいセッションを開いた途端にゼロに戻る。便利なはずのAIが、一番面倒な「新人研修係」を自分に押し付けてくる。

この記事では、Claude Code を使って複数クライアントの支援業務を回している個人事業の視点で、「AIに毎回説明しないで済む」 ための情報アーキテクチャを紹介する。実際に設計を組み直したプロセスと、そこで見つけた落とし穴までまとめた。

対象は、Claude Code やそれに類するエージェント型AIツールで複数プロジェクトを扱っていて、かつ「受託と自社の境界線」を意識している人。ひとりマーケターや小規模エージェンシーを想定している。

「毎回説明」はなぜ起きるのか

AIエージェントには2種類の記憶がある。

短期記憶: 今のセッション内で保持される会話履歴
長期記憶: セッションをまたいで保持される設定・ファイル・ルール

ほとんどの人は短期記憶だけで運用している。プロンプトに「このクライアントは〜」と毎回書き、セッションが切れたら全部消える。これは、新人に毎朝自己紹介をやり直してもらっているのと同じことだ。

問題の本質は「AIが覚えない」ことではなく、「覚えさせる仕組みを作っていない」 ことにある。Claude Code には最初から長期記憶の仕組みが揃っている。ただ、それをどう整理するかの設計が欠けていると、ファイルが増えるほど逆にカオスになる。

記憶を3階層に分ける

Claude Code の長期記憶を整理するとき、私は3つのレイヤーに分けて考えている。

レイヤー	役割	読み込みタイミング	例
メモリ	出来事・事実・設定・フィードバック	毎セッション自動	「X月Y日にクライアントAのLP改修をした」
ナレッジ	再利用可能な知見・ノウハウ	必要になったときだけ	「GA4のクロスドメイン設定手順と注意点」
スキル	特定の文脈で自動発動する実行ルール	トリガーワード検出時	「このドメインが出てきたらこのトンマナを使う」

それぞれが別の目的を持っているので、混ぜると破綻する。

メモリは軽く、毎回読む

メモリには 「いつ・何があったか」 だけを書く。コードから読めば分かることは書かない。Git のログから分かることも書かない。書くのは、コードにも履歴にも残らない判断の背景や、ユーザーの好みだ。

たとえば「この案件では A よりも B を選んだ。理由はクライアントのコンプライアンス要件」といった、後から読み返して判断材料になる情報。毎セッション自動で読み込まれるので、ここに長文を置くとコストが爆発する。1行ずつ、短く。

ナレッジは重く、必要なときだけ読む

ナレッジには 「どうやって・何に気をつけて」 を書く。調べ直したくない手順、2回ハマった落とし穴、設定値のリファレンスなどだ。

重要なのは、毎回読み込まないこと。ナレッジは「引ける場所」として整備し、セッション開始時は目次だけ読む。本体は会話の文脈で必要になってから取りに行く。

これを守らないと、ナレッジ量が増えるほどコンテキストウィンドウを食い潰し、肝心のタスクに集中できなくなる。

スキルは文脈で自動発動する

スキルが一番重要なレイヤーだ。これは 「特定の文脈を検知したら、自動で関連情報を読み込んで、特定のふるまいをする」 仕組みになっている。

Claude Code のスキルは、YAML フロントマターの description フィールドに書いたトリガーワードで起動する。たとえば「あるエンタメ系クライアントのLP」と会話に出たら、該当クライアントのブランドボイス・USP・禁止表現・ペルソナを一括で読み込む、といった挙動を作れる。

ポイントは 遅延ロード（lazy-loading） にすること。スキル自体は短く軽く、本体のプロファイルは別ファイルに置いて参照させる。

---
name: client-example-a
description: >
  クライアントAのLP・広告・コンテンツを作成するときに発火。
  「クライアントA」「example-a.com」「エンタメ系クライアント」といった
  キーワードで起動し、profile.md から全情報を読み込む。
---

# Client A コンテキストパック

## 起動時の手順
1. `~/.agent/clients/client-a/profile.md` を全文読み込む
2. ブランドボイスと禁止表現を把握
3. 以降の作業はすべてこのコンテキストに従う

実体のプロファイルは別ファイルで管理するので、更新したい情報は1箇所だけ触ればいい。Single Source of Truth（単一の真実の源）をスキルの外に置く設計だ。

スキル化するかは4つの条件で判断する

「便利そうだから全部スキルにしよう」は危険だ。スキルを作るたびにトリガーの衝突リスクが上がり、メンテナンスコストが膨らむ。

私はスキル化するかどうかを、4つの条件すべてを満たしたときだけ GO する基準にしている。

1. 繰り返し発生しているか

同じ説明を2回以上している、あるいは明らかに今後も繰り返すと分かる文脈か。1回きりの作業はメモかナレッジで十分。

2. トリガーが明確か

「この単語が出てきたら発動」と、自然言語で明確に定義できるか。定義が曖昧だと誤発動・非発動が頻発してストレスになる。

3. 既存のスキルに統合できないか

似た機能のスキルがすでにあるなら、そちらに追記する方が整合性を保てる。新規作成は、既存のどれにも綺麗に収まらないときの選択肢。

実例として、この記事を書いている最中に「見出しに『：』や『｜』を使わない」というルールが必要だと気づいた。最初は独立スキルにしようかと思ったが、既に「AIっぽくない文章を書く」ためのスキルがあったので、そこに1行追加するだけで済ませた。新規スキル1個と既存スキル1行追記では、context 消費量が文字通り桁違いになる。「既存のどれにも収まらないか？」を最後に問うだけで、この判断はまるごとひっくり返る。

4. 痛みが大きいか

スキル化しないことで発生する手戻り・認知コスト・ミスのリスクが、スキル化の手間を上回るか。

この4つが揃わないときは、メモリかナレッジに留める。早すぎる抽象化はコードだけでなく、AIエージェントの設定でも負債になる。

受託と自社を物理的に分ける

複数クライアントを管理し始めてすぐに直面するのが、「自分の事業」と「受託クライアント」をどう分けるか だ。

私の場合、同じ AI エージェント設定で次の両方を扱う:

自社の事業（個人事業・ブログ・自社サービス）
受託クライアントの支援業務（広告運用・LP制作・SEO施策）

最初はこれを全部 clients/ に並べていた。自分の屋号もクライアントっぽく1フォルダに入れて、「エンティティ管理として一貫してるし、これで良いだろう」と思っていた。これは間違いだった。

何が壊れるか

自分の事業を clients/ に置くと、ブログ公開時の匿名化ルールが自分自身に適用されてしまう。

私は自社ブログで案件の知見を発信しているが、受託クライアントの情報を公開しないために「匿名化スキル」を動かしている。クライアント名を伏せる、実ドメインを example.com に置き換える、実拠点名を一般名詞にする、といったチェックが自動で走る。

ところが自分のブランド名まで clients/ 配下にあると、このスキルが「これも匿名化対象」と判断して自分のブランド名を隠してしまう。自社ブログの自己紹介で「あるクライアント」と書かれたら意味不明だ。

さらに深刻なのが逆のケース。受託クライアントの情報が自社ブログに漏れる事故は、実際に過去起きている。実ドメインが記事に残ったまま公開されてしまった、という類の話だ。物理的に別ディレクトリに置いておけば、ルール1本で「ここから先は公開禁止」と線引きできる。

正しい分離の形

結論として、私は次の構造に整理した。

~/.agent/
├── departments/
│   └── operations/
│       └── clients/          # 受託クライアントのみ
│           ├── _template/    # 新規クライアント用の雛形
│           ├── client-a/
│           └── client-b/
│
└── personal/                 # 自分の事業・個人プロジェクト
    ├── _template/
    ├── my-business/
    └── side-project/

受託クライアントは clients/ に、自社事業と個人プロジェクトは personal/ に置く。スキルはどちらのディレクトリも参照できるが、「匿名化対象はどこか」 という問いに対して明確に答えられるようになった。

境界がファイルパスで表現されていれば、ルールはファイルパスで書ける。 これが一番安全な設計だ。

テンプレート駆動のスケール設計

クライアントが増えるたびに「前の案件のフォルダをコピーして名前を変えて……」をやっていると、不要な情報が混ざり込む。私は代わりに _template/ フォルダを両方のディレクトリに置いている。

cp -r ~/.agent/.../clients/_template ~/.agent/.../clients/new-client-name

テンプレートには次のファイルを用意している:

profile.md — 基本情報・サイト・広告アカウント・KPI
brand-voice.md — トーン・言い回し・禁止表現
services.md — サービス・USP・料金
proven-copy.md — 検証済みの実績コピー
personas.md — ターゲット・検索意図
compliance.md — 法規制・広告ガイドライン

新規案件を追加するときは、テンプレートをコピーして空欄を埋めるだけ。「何を書けばいいか」が構造で示されている ので、初稿の粒度がブレない。

また、対応する「client-{略称}」という名前のスキルも同じパターンで作る。スキル側はトリガーワードとプロファイルへのパスだけで、本文は数十行に収まる。これで10クライアント抱えても、10個の似たスキルが並ぶだけで、見通しが崩れない。

抽象化しすぎない

ここで注意したいのが、「共通部分を親テンプレートに切り出そう」という誘惑だ。DRY の原則は正しいが、クライアントごとの profile は DRY にしない方がいい。

クライアントごとの特殊事情は必ずある。親テンプレートに共通項を逃がすと、子ファイルだけ読んでも全体像がつかめなくなり、AI エージェントのパフォーマンスがむしろ落ちる。1クライアント = 1完結ファイル の方が運用が楽で、AI にも優しい。

三つ並んだ似たコードは、抽象化ではなく、並んだままの方が良いことも多い。

スキル化は自動ではなく提案させる

ここまでの話は「人間が設計する」前提だった。でも実際には、「これスキル化した方がいいかも」と気づくタイミングは作業の最中にしかない。後からまとめて設計しようとしても忘れている。

そこで、「同じパターンを繰り返していることを AI 側に検知させて、スキル化を提案させる」 ルールを導入した。

ルールはシンプルで、次のどれかが起きたら AI が「これ、スキルにします？」と聞いてくる仕組みだ。

同じ訂正を2回以上受けた
複数セッションで同じ質問を繰り返している
同じ調査を複数回やり直している
データ正確性のルール違反が繰り返されている

検知しても 勝手にスキル化はしない。必ず「提案→承認→実行」の3ステップを挟む。自動化しすぎると、一度の誤検知でおかしなスキルが増殖して掃除が面倒になる。

実際の提案はこんな形で飛んでくる。

## 昇格提案

見出しで「：」「｜」を繰り返し使っている

再発回数: 8回（今セッション内）
痛み: MEDIUM（AIっぽさが残る）

推奨: 既存スキルへの統合。理由: 文章ルールは既存の執筆スキルに綺麗に収まる。

A) 新規スキル化 — 自動発動、context +500 tokens
B) 既存スキルに統合 — 追記1行、context +10 tokens  ← 推奨
C) ナレッジ化 — 手動参照、検索で引く
D) 昇格しない

A〜D から選ぶだけで済む。自分で「これスキル化すべきか？」と考える認知コストが、AI側に移動している。これが決定的に楽だ。

3段階のエスカレーション

検知したパターンを何に落とし込むかも、ルール化している。

段階	落とし込み先	条件
Lv1	メモリ（1行）	単発の事実・好み・フィードバック
Lv2	ナレッジ（ドキュメント）	再利用可能な知見、手順、リファレンス
Lv3	スキル（自動発動）	4条件すべてを満たすパターン

一気に Lv3 まで飛ばすのではなく、まずは Lv1 で様子を見る。これが3回以上繰り返されたら Lv2 に昇格。Lv2 でも頻度が高く、トリガーが明確になってきたら Lv3 へ。

「抽象化は後から上げる、下げるのは難しい」 という原則に従っている。

導入時の落とし穴

実装してみて、ハマったポイントをいくつか共有しておく。

1. Single Source of Truth の崩壊

スキル本文に情報を直接書いてしまうと、同じ情報がプロファイルとスキルの2箇所に存在してしまう。片方を更新してもう片方を忘れる、というズレが必ず発生する。

対策は単純で、スキルは極力「プロファイルを読め」しか書かない。ふるまいのルールはスキルに、データはプロファイルに。レイヤーを混ぜない。

2. 既存参照の破壊

パス構造を変えるとき、既存の参照を壊さないよう注意が必要だ。スキル・メモリ・ナレッジ・他のルールファイルなど、同じパスを参照している場所は意外と多い。

移動前に grep でパスの参照箇所を全部洗い出し、一括で置換する。1つでも残ると、該当スキルが沈黙して起動しなくなる。

3. トリガーワードの衝突

スキルが増えると、トリガーワードの衝突が起き始める。たとえば「LP」というワードだけで起動するスキルを2つ作ると、両方発動してコンテキストが肥大化する。

トリガーはできるだけ 固有名詞やドメイン名 を使う。「LP を作って」では発動させず、「クライアントA の LP を作って」で発動させる。一般語は補助扱いにとどめる。

4. 早すぎるスキル化

繰り返しになるが、これが一番危ない。「便利そう」でスキルを作ると、数週間後には使っていないスキルが増えて、トリガー衝突と読み込みコストだけが残る。

1週間後に自分で見返して、その役割を説明できないスキルは、まだ作る時期じゃない。

5. セパレータ記号の罠

この記事の初稿には、見出しに「：」と「｜」が大量にあった。「3階層の記憶設計：メモリ・ナレッジ・スキル」「Claude Codeで毎回説明をやめる｜複数クライアント管理の情報設計」のように。

書いてる最中は気づかない。「タイトル｜サブタイトル」は SEO 記事の定型パターンとして手癖で入ってしまう。でもこれは読者側から見ると「AI が書いたっぽいタイトル」の典型例だ。対策は、文章生成スキルの禁止ワードリストに「：」「｜」を入れて、執筆後に自動検出させること。一度ルール化すれば二度と踏まない。この記事自体も、書き上げてから見出しを全部書き直している。

こういう細かいルールこそ、前章の自己学習ルートで拾うと効率がいい。独立スキルにする価値はないが、気づかずに積み上がると全部 AI 臭の原因になる。