レッスン5: 失敗と調整

学習目標:

• サブエージェントが「完了」と主張しても額面通りに受け取れない理由と、独立した検証方法が必要な理由を説明する
• マルチエージェントコラボレーションにおける2つの一般的な失敗を認識する: 重複作業と矛盾する結果
• 結果統合段階で、重複を排除する方法と矛盾する出力を処理する方法を知る

前提: レッスン4を完了し、3つのコラボレーションパターンとハンドオフを区別できること | 前: レッスン4 << | 次: レッスン6 >>

2つのサブエージェントがそれぞれ同じクラウドプロバイダーのスタータープランを調査します。一方は月額$20から始まると報告し、もう一方は$25と言います。そして両方の出力は自信を持って「検証済み、エラーなし」とマークしています。前のレッスンはすべてマルチエージェントコラボレーションを立ち上げる方法をカバーしました。このレッスンは、それを構築した後でどこが壊れるかをカバーします。サブエージェントの自己報告ステータスは信頼できない、重複作業、矛盾する結果、そしてオーケストレーターがそれぞれについて何をすべきかです。

サブエージェントが「完了」と言っても正しくやったという意味ではない

サブエージェントが結果を返すとき、通常「完了」や「検証済み、エラーなし」のような行を付け加えます。その声明は証拠ではありません。それは単にサブエージェント自身の出力についての自己要約であり、その要約は間違っている可能性があります。エージェントの動作についての公式の観察はまさにこれです。"Claude stops when the work looks done. Without a check it can run, "looks done" is the only signal available, and you become the verification loop: every mistake waits for you to notice it."¹ だから公式のアドバイスは "Have Claude show evidence rather than asserting success."¹ です。

公式ドキュメントはこれを trust-then-verify gap と呼んでいます。"The trust-then-verify gap. Claude produces a plausible-looking implementation that doesn't handle edge cases. Fix: Always provide verification (tests, scripts, screenshots). If you can't verify it, don't ship it."¹ そのアドバイスはコードを書くことについて書かれましたが、同じ論理は任意の委任に適用されます。サブエージェントが返すものはスムーズに読め、正しいフォーマットで、注意深く行われたように見えます。そしてそのすべては単に「もっともらしく見える」だけで、実際に正しいこととは同じではありません。オーケストレーターがサブエージェントの「完了」という言葉を額面通りに受け取り、出力を最終結果に直接つなぎ合わせると、検証を完全にスキップしたことになります。

検証方法: サブエージェントの出力に対してチェック可能な基準を設定する

「額面通りに受け取らない」と言うのは簡単です。難しいのは検証方法です。一度読んで「良さそうだ」と決めることは検証ではありません。それはまだ trust-then-verify gap の前半に留まっています。信頼できるアプローチは、最初に具体的でチェック可能な基準を定義し、次にサブエージェントの出力をそれに対して測定することです。

本番システムで使用されている1つの基準はこのように見えます。"We used an LLM judge that evaluated each output against criteria in a rubric: factual accuracy (do claims match sources?), citation accuracy (do the cited sources match the claims?), completeness (are all requested aspects covered?), source quality (did it use primary sources over lower-quality secondary sources?), and tool efficiency (did it use the right tools a reasonable number of times?)."² これらの5つの基準が共有するのは、それぞれが印象でスコアされるのではなく、具体的にチェックできるということです。事実の正確性は、サブエージェントが引用したソースに対して一行ずつチェックできます。完全性は、タスク記述にリストされたすべての要件に対してチェックし、それらがすべてカバーされたかどうかを確認できます。ツール効率は呼び出しログから直接読み取って、明らかに冗長または重複した呼び出しがあったかどうかを判断できます。

これを自分のコラボレーションセットアップに取り入れる場合、サブエージェントの出力を検証する最初のステップは「これは正しく見えるか」と尋ねることではなく、「このタスクについて、私は何を具体的にチェックできるか」と尋ねることです。それらをリストアップし、各項目に対して出力を測定します。

重複作業: 複数のサブエージェントが同じことをする

レッスン3では、十分に詳細でないタスク記述が、"misinterpreted the task or performed the exact same searches as other agents."² というサブエージェントにつながることをカバーしました。それが根本原因ですが、失敗は通常、結果が集約される瞬間にのみ表面化します。オーケストレーターは複数のサブエージェント出力を受け取り、そのうちの2つが大きく重複し、異なる言葉で同じことをカバーしていることを発見します。

重複作業はそれ自体が壊滅的なエラーではありません。コンテンツは間違っていません。異なる角度をカバーすべきだったトークンと呼び出しを無駄にしただけです。しかし、それはシグナルです。一部のサブエージェントのタスク境界が十分に明確に引かれておらず、この1つのバッチの結果を手動で重複排除して完了と呼ぶのではなく、派遣ステップからのタスク記述を確認するために戻る価値があります。重複作業を見つけたら、重複したコンテンツを削除するだけでなく、なぜ繰り返されたのかを理解する方がより価値があります。2つのタスク記述がスコープで重複していたか、サブエージェントがそれぞれ同じ最も明白な方向に漂ったかです。

矛盾する結果: 2つのサブエージェントが矛盾する結論に達する

重複作業よりも厄介なのは結果の衝突です。このレッスンを開始したシーンのように、2つのサブエージェントがそれぞれ独自の調査を行い、互いに矛盾する結論を返します。一方はスタータープランが月額$20から始まると言い、もう一方は$25と言います。「どちらかを選ぶ」か「差を分割する」ことでこれに対処することはできません。両方のアプローチは、間違った数値を最終結論として提供するリスクがあります。

結果の衝突に遭遇したとき、賢明な順序は、最初に各側が答えの基礎にしたものを見ることです。彼らは異なるソースを参照したか、一方はプロバイダーの現在のライブページを使用し、もう一方は誤ってキャッシュされた古いページを使用したか。基礎を追跡できる場合、通常どちらがより信頼できるかを判断し、信頼できないものを置き換えることができます。基礎そのものが誰が正しいかを解決できない場合、統合中に自分で判断を下さないでください。矛盾をそのまま人間のレビューのためにフラグするか、その1つの不一致点を検証するために特別に新しいサブエージェントを立ち上げます。結果の衝突が露呈する問題は、通常、重複作業よりも心配する価値があります。それは少なくとも1つのサブエージェント出力が間違っていることを意味し、それを処理せずに最終結果にドロップすると、未検証のエラーを「完了」の結論としてパッケージ化したことになります。

結果統合と重複排除: オーケストレーターがまとめるために行うこと

複数のサブエージェント出力を最終結果につなぎ合わせることは、それらを端から端まで連結することではありません。上記の問題のカテゴリーを再度実行することを意味します。マージする必要がある重複コンテンツはありますか、検証またはフラグする必要がある矛盾する結論はありますか、すべての主張が対応する基礎に遡ることができますか。最後のポイントは特に見落としやすいです。レッスン3「委任のためのプロンプトを書く」では、本番システムが専用のエージェントを設定したことに言及しました。"a CitationAgent, which processes the documents and research report to identify specific locations for citations. This ensures all claims are properly attributed to their sources."² と説明されています。同じ論理が統合段階にも当てはまります。複数のサブエージェント出力がプールされると、誤った帰属が起こりやすくなります。サブエージェントAが見つけたデータを、サブエージェントBが担当していた会社についての結論として書き上げることです。統合段階で各主張のソース帰属を検証することは、事実そのものが正確かどうかを検証することと同じくらい重要です。

重複排除、衝突の検証、ソース帰属のチェック。これら3つが一緒に「集約」ステップの本当の作業であり、レッスン2が警告したように、サブエージェントの生の返信を連結して完了と呼ぶことではありません。

まとめ

• サブエージェントが返すときの「完了」または「検証済み、エラーなし」は単なる自己報告で、証拠ではありません。実行できるチェックがなければ、"looks done" が利用可能な唯一のシグナルです¹。公式ドキュメントは、Claude が "produces a plausible-looking implementation that doesn't handle edge cases" であることを明示しており、検証できない場合は出荷しないでください。¹
• 検証は「うまく読める」で止まることはできません。特定のタスクに対してチェック可能な基準を定義します。公式の LLM ジャッジが使用したルーブリックのように、事実の正確性、引用の正確性、完全性、ソースの品質、ツール効率はそれぞれ一行ずつチェックできます。²
• 重複作業は明確に引かれていないタスク境界の一般的な結果であり²、通常、結果が集約されるときにのみ表面化します。重複を見つけることは余分なコンテンツを削除するだけでなく、派遣ステップからのタスク記述を確認するために戻る価値があります。
• 矛盾する結果 — 2つのサブエージェントが矛盾する結論に達する — はランダムに1つを選ぶか差を分割することで処理できません。まず各側の基礎の信頼性を検証し、ランク付けできない場合は、人間のレビューのために衝突をそのままフラグします。
• 統合段階は3つのことを同時に行います。重複排除、衝突の検証、各主張のソース帰属が誤って帰属されていないかのチェック²です。それが「集約」ステップの本当の作業であり、サブエージェントの生の返信を連結するだけではありません。

>> レッスン6: ハンズオン: 2エージェントレビューパイプラインの構築