サブエージェントにメインの記憶を渡すのは事故だった：7ファイルのうち4つは遮断すべき
サブエージェントを初めて使ったとき、私は良かれと思ってメインの記憶を全部渡しました。CLAUDE.md、ユーザーの好み、過去のメモリ、人格設定。「文脈を共有したほうが賢く動くだろう」という、いま思えば完全に逆の発想です。
結果として何が起きたか。echo success を返すだけの、世界一どうでもいいサブエージェントが、起動しただけで数万トークンを食いました。派遣で来てもらった人に、まず会社の全社員名簿と私の家族構成と過去3年の日記を読ませてから「コピー取ってください」と頼んでいたようなものです。親切ではありません。事故です。
この「サブエージェントには何を渡し、何を渡さないか」という設計、ちゃんと言語化したものを最近読みました。OpenClawという実在のAIエージェントの記憶アーキテクチャです。これがきれいに整理されていたので、自分の運用に当てはめ直した話をします。
7つのファイルで人格を組み立てる
OpenClawは起動時に7つのファイルを順番に読み込んで「記憶」と「人格」を構成します。役割で並べるとこうです。
| ファイル | 中身 |
|---|---|
| AGENTS.md | 全員共通の作業ルール |
| TOOLS.md | ツール一覧とローカル設定 |
| SOUL.md | 人格・性格・関係性 |
| IDENTITY.md | 対外的なプロフィール |
| USER.md | ユーザーの情報 |
| HEARTBEAT.md | 定期チェック項目 |
| MEMORY.md | 過去の記憶(日次+長期) |
人間でいえば、AGENTSが就業規則、TOOLSが持ち物、SOULが性格、USERが「上司の好み」、MEMORYが業務日誌です。メインエージェントはこれを全部読みます。フルスペックの自分として動くからです。
問題はサブエージェントのほうです。
サブに渡すのは2つ、遮断するのは4つ
OpenClawの設計では、サブエージェントに渡すのは AGENTS.md と TOOLS.md の2つだけ です。残りは渡しません。
なぜか。サブエージェントは「派遣社員」だからです。特定のタスクを片付けにきた人に、会社の人格(SOUL)も、対外的な看板(IDENTITY)も、過去の業務日誌(MEMORY)も要りません。むしろ渡してはいけません。遮断すべきは次の4つです。
- SOUL.md(人格): サブは作業者であって、私の代わりに振る舞う必要がない
- IDENTITY.md(対外プロフィール): 外に出る顔はメインだけが持てばいい
- USER.md(ユーザー情報): これはセキュリティの問題。サブに私の個人情報を持たせる理由がない
- MEMORY.md(過去の記憶): トークンの浪費に直結し、しかも過去ログの中身が漏れる
HEARTBEATはメイン専用の機能なので、そもそもサブには関係ありません。だから「サブに渡さない7マイナス2=5」のうち、意図して遮断する情報は4つ という整理になります。人格・看板・ユーザー情報・過去記憶。この4つを渡すと、トークンが溶けて、情報が漏れます。両方同時に悪化するのが厄介なところです。
「親切のつもり」がいちばん高くつく
ここで一番大事な事実を一つ。OpenClawはこの遮断を設計として持っていますが、いま私たちが日常的に使っているClaude Codeのサブエージェントは、デフォルトでは逆の挙動をします。
公式ドキュメントの “What loads at startup” を読むと、Claude Codeのサブエージェントは起動時に、メイン会話が読むメモリ階層をそのまま継承します。~/.claude/CLAUDE.md、プロジェクトのルール、CLAUDE.local.md、管理ポリシーファイル。全部です。例外はビルトインのExploreとPlanだけ。つまり、自分でカスタムのサブエージェントを作ると、何も指定しなければ親の記憶を丸ごと持っていきます。OpenClawが「渡すな」と言っているものを、Claude Codeは標準で「渡します」。
その代償が数字で出ています。GitHubのIssue #6825に、ほぼ自明なサブエージェント(echo success を返すだけ)が、継承したメモリのせいで 約60kトークン を消費した、という報告があります。メモリ無しの環境で同じことをやると 約3k で済みます。20倍です。コピー一枚取るために名簿と日記を読ませた、あの話そのものが計測されています。
このIssueでは、tools フィールドと同じ要領で includes: System, User, Project, Subagent のような「何を継承させるか」を選べるフィールドが要望されています。私が確認した時点ではまだ実装されていません(メンテナの解決方針も未確認です)。だから現状は、設計者である私たちが意識して絞る しかありません。サブエージェントのプロンプトを、必要最小限の作業指示とツール情報だけにする。それがいまできる遮断です。
トークンだけの話ではない
トークンが20倍になるのは財布の問題ですが、もう一つ、財布より怖い問題があります。漏洩です。
サブエージェントは、悪意あるコンテンツやプロンプトインジェクションの影響を受けることがあります。2026年には、単一のプロンプトインジェクションで複数のAIコーディングエージェントがシークレットを漏らした事例が報告されています。攻撃が「モデルを一回だます」から「計画を乗っ取り、特権ツールを呼び、メモリを汚染し、横に広がる」というチェーンに進化しているわけです。
このとき、サブエージェントにUSER.md(あなたの個人情報)やMEMORY.md(過去のやり取り全部)を渡していたら、漏れる範囲がそのまま広がります。逆に、作業ルールとツール情報しか持っていないサブエージェントは、たとえ乗っ取られても漏らせるものが少ない。OWASPのAIエージェント・セキュリティのチートシートが言う 最小権限 とは、まさにこれです。「各エージェントは定義されたタスクに必要な最小限の権限で動かせ、そうすれば侵害された時の影響範囲が構造的に制限される」。学術側でも、共有メモリ経由のクロスコンテキスト推論やIP漏洩を評価するMAGPIEのようなベンチマークが出てきています。
派遣の人に日記を渡さないのは、その人を信用していないからではありません。万が一その人のカバンが盗まれたとき、日記まで一緒に盗まれたら困るからです。
私の運用ルール
整理すると、私がいま守っているのはこれだけです。
- サブエージェントには 作業指示とツール情報 だけ渡す。プロンプトに余計な背景を盛らない
- 人格・対外プロフィール・ユーザー情報・過去記憶 はメイン専用。サブには出さない
- 自明なサブほど警戒する。「どうせ小さいタスクだから」という油断が、60kトークンと漏洩経路を同時に連れてくる
サブエージェントを設計するとき、つい「賢くするために文脈を足そう」と考えてしまいます。でも記憶の設計に限っては、足し算ではなく引き算です。何を渡すかではなく、何を渡さないか。派遣社員には日記を渡さない。それだけで、トークンも安全も守れます。
記憶の設計を含むコンテキストエンジニアリングの全体像(5段階の戦略からRAG、MCP、CLAUDE.md、Agentic RAGまで)は書籍にまとめています。
この記事は役に立ちましたか？