概要 Claude Codeのサブエージェント機能に調査や検証を任せると、返ってくるのは要約だけである。サブエージェントが実際に何のツールをいくつ呼んだかは、本流の会話に自動的には現れない。この構造ゆえに、ツールを一度も呼ばずに、具体的なファイル内容や行番号まで挙げた「最もらしい報告」が返ってくることがある。
防ぎ方は単純である。報告の文章の説得力を判断材料にせず、結果に付随するツール呼び出し回数を機械的に確認する。
サブエージェントは「要約」しか返さない Claude Codeの公式ドキュメントは、サブエージェントの結果の返り方を次のように説明している。
the subagent does that work in its own context and returns only the summary
サブエージェントは独立したコンテキストウィンドウで動作し、ファイルを読んだか、コマンドを実行したかといった過程そのものは本流の会話に残らない。戻ってくるのは最終的なテキストだけである。
この設計自体は妥当である。調査の過程をメインの会話から隔離してコンテキストを節約するのがサブエージェントの目的であり、Anthropicが自社のマルチエージェント調査システムについて書いた記事でも、この分離が複雑な調査タスクの精度を大きく引き上げたと報告されている。
問題は、この隔離が「過程を検証する手段」も同時に覆い隠してしまう点にある。要約の文章がどれだけ具体的でも、それが実際のツール実行の結果なのか、それらしく組み立てられた文章なのかを、本文だけから見分けることはできない。
見た目は最もらしい ツールを一度も呼んでいないサブエージェントが、次のような報告を返してくることがある。いずれも、実際に起きた事例を一般化した再構成である。
（サブエージェントからの報告。実際の tool_uses は 0） 対象ファイルを確認しました。12行目でnullチェックが 欠落しており、該当箇所のハッシュ値は a3f9d1... です。 このまま投入すると参照エラーが発生します。 行番号やハッシュ値のような具体的な情報が伴うと、読み手は「実際に確認した結果」だと錯覚しやすい。ほかにも次のような症状が観測されている。
「対象のworktreeが壊れていた／空だった」のように、環境側の障害を発見したかのような報告をする。最もらしく見えるが、実行ログを伴わない自己言及にすぎない 委任プロンプトの中ですでに「実装済み」と明記した内容を、「未確認の懸念事項」として指摘し返してくる。プロンプトの内容を実際には処理していないことの裏返しである やっかいなのは、同じ設定のサブエージェントに再委任しても、同じ症状が再現するとは限らないことである。ある観測例では、1回目は環境障害の作り話、2回目はツール呼び出しの意図だけが生テキストとして出力されて未実行、3回目は一見詳細だが実際にはツール未使用、というように、試行のたびに症状の見た目が変わった。「さっきと違う言い方をしているから今度は本物だろう」という判断は当てにならない。
ツール呼び出し回数を機械的に見る 文章の具体性や説得力を判断材料にしない。サブエージェントの結果には、実行メタデータとしてツール呼び出し回数が付随する。
<usage><subagent_tokens>174728</subagent_tokens><tool_uses>8</tool_uses><duration_ms>183518</duration_ms></usage> これは、サブエージェントへの調査委任で実際に返ってきたメタデータの例である。（subagent_tokensやtool_usesといったフィールド名は、公開ドキュメントに仕様として明記されたものではなく、手元で観測された表示例であり、バージョンによって変わり得る）。ここでのtool_usesが0であれば、本文が「〇〇ファイルの12行目を確認したところ」と具体的に書かれていても、その場では信頼しない。検証や調査を依頼したのに実行回数が0というのは、それ自体が矛盾している。
数値という構造化されたシグナルは、自由記述の本文のように後から都合よく組み立てにくい。疑わしさの判定は、まずここを起点にする。
疑わしい報告への対処 実行するよう明示して再委任する 最初の一手としては、ツールを実際に使って報告するよう明示して再委任するのが自然である。
先ほどの報告には根拠となるツール呼び出しが見当たらない。 実際にファイルを Read してから、確認した内容を報告して。 ただし、これで改善するとは限らない。1回の再委任で直らなければ、同じ指示を繰り返さない。粘っても症状が形を変えて再発するだけで、信頼できる報告には収束しないことが多い。
最小タスクで切り分ける 本番の検証を投げる前に、同じagent構成に対して壊れようのない最小タスクを投げてみる。
このファイルをReadして、1行目をそのまま引用して。 それ以外の作業は不要。 この程度の指示でもtool_usesが0になるなら、agent typeとツール実行環境の組み合わせに問題を抱えている可能性が高い。本番の依頼を重ねる前に、ここで切り分ける。
なお、バックグラウンドで実行したサブエージェントが完了した直後であれば、Claude Codeの/tasksコマンドから対象のトランスクリプトを直接開いて確認する経路もある。完了から数十秒で参照できなくなるため、疑わしいと感じた時点ですぐに開く必要がある。
closed-book形式に切り替える ツールを呼ぶ余地そのものをなくす方法もある。判断に必要な引用や差分をすべてプロンプトへそのまま埋め込み、ツール呼び出しは不要だと明示して委任する。
以下は対象ファイルの全文である。ツール呼び出しは不要、 このテキストだけを根拠に判断せよ。 <file path="src/example.ts"> ...(ファイル内容をそのまま貼り付け)... </file> 上記のコードにnullチェック漏れがないか指摘して。 ツールを呼んだかどうかを気にする必要がなくなる分、判定はシンプルになる。長い調査タスクには向かないが、判断材料が手元にそろっている検証タスクでは有効である。
自分で一次資料を確認する 最終的には、委任結果が語る内容を新しい判断や実装の根拠として使う前に、対象のファイルやログを自分で直接読む。サブエージェントへの委任は調査の下請けであって、検証の代行ではない。
0でなければ安心、ではない tool_usesが1以上であることは、内容が正しいことを保証しない。ツールを何か呼んだという事実を示すだけである。1回だけ無関係なファイルを読んで、それらしい結論を書くこともできる。
この確認はあくまで最初のふるいにすぎない。「0なら本文の具体性に関わらず疑う」がここでの主眼であり、「0でなければ信頼してよい」という意味ではない。重要な判断では、この後も一次情報との突き合わせを省略しない。
まとめ サブエージェントが返すのは要約であり、その過程は隔離されている。この構造では、ツールを一度も呼ばずに具体的な報告文を組み立てることが技術的に可能である。
自由記述の説得力ではなく、ツール呼び出し回数という構造化されたシグナルを先に見る。0であれば本文の具体性に関わらず疑い、実行を明示した再委任、最小タスクでの切り分け、closed-book形式への切り替え、自分での一次資料確認という順で対処する。ツール呼び出しが記録されていること自体は正しさの証明ではない点も、合わせて覚えておく。
参考 