前編では、Claude Codeに「不要部分を削除してほしい」と頼んだのに、過去の検討過程や棄却した案が残った経験から、AIが対話のコンテキストをどう扱うのかを考えた。
そこでたどり着いたのは、何を残し、何を捨て、何を正本とするかは、AIの記憶力ではなく作業設計の問題だ、という考えだった。
では、分析、構成、執筆、編集を別々のサブエージェントに任せればよいのだろうか。
私は、いきなりエージェントを増やす必要はないと考えている。先に分けたいのは、各工程で使う情報と成果物だ。そのうえで、大量のログを読む仕事や、本文から距離を置いて検査する仕事だけを、別のコンテキストへ移す。
これは、すでに比較して効果を確認した方法ではない。次の長文レポートで確かめるための運用仮説である。
まず、「コンテキスト汚染」という言葉を整理する
この記事では「コンテキスト汚染」という言葉を使っているが、まず何を指しているのかを整理しておきたい。
必要な指示や確定した情報が、大量のログや古い案、競合する記述に埋もれてしまうことがある。Codexの公式文書でも、探索メモやテストログ、スタックトレースなどによってメインスレッドが埋まる状態を context pollution、関連性の低い情報が蓄積して性能が低下する現象を context rot と説明している。
この記事では、こうした「途中の情報が増えた結果、現在使うべき情報が分かりにくくなっている状態」を、便宜的に「コンテキスト汚染」と呼ぶ。
ただし、「コンテキスト汚染」という言葉だけで、失敗の原因まで説明できるわけではない。
前編で経験した削除の失敗も、古い案がコンテキストに残っていたことが原因かもしれない。一方で、削除基準そのものが曖昧だった可能性もある。必要なファイルが読み直されなかったのかもしれないし、長い入力の中で重要な情報をうまく使えなかった可能性もある。
再現実験をしていない以上、どれが原因だったのかは確定できない。
そのため、この記事では「コンテキスト汚染が起きたから失敗した」とは考えない。まず、どの情報を残し、どの情報を次の工程から外すべきだったのか、という作業設計の問題として考える。
なお、ここで扱う「コンテキスト汚染」は、悪意ある指示の混入やプロンプトインジェクションとは別の問題である。古い情報、途中の案、大量のログなどによって、現在使うべき情報の優先順位が分かりにくくなる状態を対象としている。
エージェントを増やす前に、ファイルを分ける
私が最初に変えるべきなのは、サブエージェントの構成ではなく、分析履歴と完成版を一つのファイルへ置いていたことだと思う。
次回は、作業を次のように分ける。
原資料
↓
分析ログ
↓
承認した事実・推論
↓
確定骨子
↓
本文
↓
編集チェック
分析ログには、採用しなかった仮説や途中の迷いも残す。後から判断を検証するには必要だからだ。ただし、確定骨子へ渡すのは、採用した主張、根拠、留保だけにする。本文を書くときも、分析の全履歴ではなく、確定骨子と必要な証拠を使う。
この分け方は、一つのAIとの対話でも実行できる。工程が変わるたびに使うファイルを切り替え、どれが現在の正本かを明示すればよい。最終編集だけ新しいセッションにし、現行原稿と削除基準だけを渡す方法もある。
ただし、ファイルを分けるだけでは足りない。どのファイルが現行版で、どれを参照対象から外すかも明示する必要がある。
たとえば、本文の作成中に確定骨子にない重要な事実が見つかった場合、そのまま本文へ追加しない。いったん分析や承認の工程へ戻し、承認済みの判断と確定骨子を更新してから、本文へ反映する。
こうしておかないと、工程を分けても後工程から上流の判断が勝手に書き換わり、どれが正本なのか再び分からなくなる。
これで改善するかは、まだ分からない。ただ、サブエージェントを設定しなくても試せるので、最初の変更としては小さい。
サブエージェントへ渡す仕事、渡さない仕事
ファイルを分けても、検索結果、実行ログ、参考資料などでメインの対話が長くなることはある。そこでサブエージェントが使える。
Claude Codeでは、通常のサブエージェントは親とは別の会話コンテキストで始まる。親の会話履歴や、親がすでに読んだファイルの内容をそのまま引き継ぐのではなく、委譲された依頼を基に作業し、結果を親へ返す。大量の資料を読ませても、メインの対話へ戻す情報を整理した結果に絞れる。
ただし、会話コンテキストが分かれていることと、作業環境まで完全に隔離されていることは別である。通常は同じ作業ディレクトリを使うため、複数のエージェントが同じファイルを編集すれば変更が衝突する可能性がある。
また、サブエージェントは完全な白紙から始まるわけでもない。
Claude Codeの組み込みサブエージェントのうち、ExploreとPlanは CLAUDE.md や親セッションのGit状態を読み込まない。一方、それ以外の組み込みサブエージェントとカスタムサブエージェントには、CLAUDE.md などのプロジェクト情報が読み込まれる。
カスタムサブエージェントには、設定した場合に限り、専用の永続メモリを持たせることもできる。
さらに、親の会話を複製して始めるフォーク方式では、通常の独立したサブエージェントと異なり、親の対話履歴を引き継ぐ。
つまり、「サブエージェントを使えばコンテキストが分離される」と一括りにはできない。何が渡るかは、使うサブエージェントや起動方式によって異なる。
Codexも、要件、判断、最終成果物をメインスレッドへ残し、探索、テスト、ログ分析のように境界を切りやすい仕事をサブエージェントへ移す使い方を案内している。各サブエージェントの途中経過ではなく、整理した結果をメインへ戻す考え方だ。
長文レポートなら、私は次のように分ける。
| 仕事 | 渡すもの | 返してもらうもの | 確認すること |
|---|---|---|---|
| 資料の分析 | 原資料と問い | 事実、推論、不明点、出典 | 各事実を出典までたどれるか |
| 骨子の作成 | 承認済みの分析 | 中心主張と各章の役割 | 同じ役割の章が重なっていないか |
| 本文の執筆 | 確定骨子と証拠 | 本文 | 骨子にない事実を足していないか |
| 編集チェック | 現行原稿と判定基準 | 問題箇所、修正案、理由 | 主張、事実、確信度を変えていないか |
分析から骨子まで何度も往復し、そのたびに細かな判断理由を参照する仕事は、同じセッションに残した方が効率的な場合が多い。短い修正も、別のエージェントへ説明し直す方が手間になる。
反対に、大量の資料を読む、ログから特定の失敗だけを探す、完成稿を決められた基準で検査するといった仕事は切り出しやすい。
サブエージェントを使うかどうかは、役割名ではなく、仕事の境界を引けるかで決める。
分けると、必要な情報まで落ちる
新しいコンテキストには、途中のノイズがない。その代わり、親がたどった判断の細部もない。
たとえば、分析結果を「A案を採用」とだけ要約して渡した場合、A案が特定の条件でしか成り立たないことや、例外として残していた事実が落ちるかもしれない。骨子はすっきりしても、原資料には忠実でなくなる。
委譲の内容が曖昧なら、各エージェントが同じ資料を読み直し、同じ調査を繰り返す。詳しい結果をすべて返させれば、今度はその報告がメインのコンテキストを埋める。複数のエージェントに同じファイルを同時編集させれば、変更も衝突する。
トークンの使用量も増える。Codexの公式文書では、各サブエージェントが個別にモデルとツールを使うため、同程度の仕事を一つのエージェントで行う場合より多くのトークンを使うと説明されている。Claude Codeも、頻繁な往復が必要な仕事や、多くの文脈を共有する仕事にはメインの対話を使うよう案内している。
分ければよいわけではない。切り離す情報と、落としてはいけない情報を決める必要がある。
受け渡す情報を決めてから、役割を決める
次回は、各工程の依頼に四つの項目を書く。
- 今回の問い
- 正本として使うファイル
- 返してほしい形式
- 合否を決める基準
ただし、分析結果や承認済みの判断を次の工程へ渡す場合は、単なる要約ではなく、必要に応じて次の情報も残す。
主張
根拠
出典
確信度
成立条件
例外
棄却した代替案と棄却理由
たとえば、次のように記録できる。
## 主張
サブエージェントは大量の探索ログをメインの対話から分離できる。
## 種別
製品仕様
## 根拠
Claude Code公式文書
## 成立条件
通常の独立した会話コンテキストで動くサブエージェントを使う場合
## 例外
親の会話を引き継ぐフォーク方式は除く
## 確信度
高
毎回すべての項目を書く必要はない。しかし、後の工程で必要になりそうな条件や例外まで削ってしまうと、情報を整理したこと自体が新しい失敗原因になる。
編集チェックでも、「不要部分を削除して」ではなく、次のように依頼する。
現行原稿と確定骨子を比較してください。
次に当てはまる箇所を挙げ、修正案と理由を返してください。
- 中心疑問へ答えていない
- 同じ根拠を繰り返している
- 確定骨子にない事実を追加している
- 事実、推論、提案の区別が曖昧である
原稿は変更せず、問題箇所、修正案、理由の順で報告してください。
これなら、書き手とは別のコンテキストで点検しながら、変更前に人間が内容を確認できる。
「編集者」という役割名を付けることより、何を見て、何を返し、どこで合否を決めるかを書く方が、作業を検証しやすい。
現時点での結論
ここまで書いた方法は、まだ実際の長文レポートで比較検証したものではない。
そのため、「ファイルを分ければ改善する」「サブエージェントを使えば品質が上がる」とまでは言えない。現時点では、前編で経験した失敗をもとに整理した運用仮説である。
ただし、少なくとも一つ分かったことがある。
問題が起きたときに、すぐ「サブエージェントを増やそう」と考える必要はない。
まず確認すべきなのは、分析ログ、承認した判断、確定骨子、本文といった成果物が分かれているか。そして、次の工程へ渡す情報と、渡さない情報が決まっているかである。
そのうえで、大量の資料を読む、ログから特定の情報を探す、完成稿を一定の基準で検査するといった、境界を切りやすい仕事だけを別のコンテキストへ移す。
サブエージェントは、増やすこと自体に意味があるのではない。
重要なのは、どの工程で、どの情報を使い、何を成果物として次へ渡すのかを決めることである。
増やすべきなのは、エージェントの数ではない。
次の工程へ何を渡し、何を渡さないかを決める境界である。
参考資料
