comprehensive-research-agent

包括的な調査エージェントのベストプラクティス

このスキルでは、複数の手順を伴う調査タスクでよく発生する問題、つまりツールエラーへの対処不足、検証の欠落、不透明な推論、早まった結論に対応します。ソースの検証、エラーからの復旧、思考の透明性を実現するための構造化された手順を示し、調査の質と信頼性を大幅に向上させます。

有効にするタイミング

• タスクに、検索、read_url、fetch の操作を使ったウェブ調査が含まれる
• タスクで複数のソースから情報を収集する必要がある
• タスクに完全性や検証に関する明示的な要件がある
• タスクに検証が必要なファイル操作（保存、書き込み、読み取り）が含まれる
• 3 回以上のツール操作を伴う調査や情報収集のワークフロー全般

中核となる概念

• 検証チェックポイント：ツールの出力、ソースの関連性、情報の完全性を確認してから次に進むため、フェーズの切り替わり時に行う明示的な検証手順
• エラー復旧プロトコル：ツールの失敗を必ず認識して対処し、何事もなかったかのように続けるのではなく、代替策を講じる
• ソースの追跡可能性：実際に取得したソースと、以前の知識に基づいて参照したソースを明確に追跡し、ハルシネーションを防ぐ
• 実質的な思考ブロック：各ステップで得られた知見、関連性、欠落情報、判断の根拠を記録する詳細な推論の記録
• 複数ソースによる検証：重要な主張を複数のソースと照合し、見解の一致や矛盾、情報の欠落を明示する

避けるべきパターン

• ツールの失敗を黙って無視する：ツール呼び出しでエラー（404、タイムアウト、無効な URL）が返されたのに、それを認識せずに処理を続け、重要な情報を見落とす可能性があります。必ず失敗を記録し、復旧を試みるか、情報の欠落を明記してください。
• 曖昧な完了報告：「十分な情報が得られた」や「調査は包括的です」と宣言する一方で、何が判明したのか、どのソースが主張を裏付けているのか、どのような情報が不足しているのかを示しません。対象範囲を具体的に要約してください。
• ソース選定の未検証：検索結果に含まれる URL について、関連性、信頼性、鮮度を評価せずに読み込みます。質の低いソースにツール呼び出しを浪費します。詳細な読み込みに進む前に、必ずソースを評価して優先順位を付けてください。
• 一般的すぎる思考ブロック：思考内容が「次は X を検索します」のような次の行動の説明にとどまり、何が判明したのか、目標にどう関係するのか、どのような疑問が残っているのかを分析していません。思考では、実質的な内容を掘り下げて振り返る必要があります。
• 検証方法の誤り：ファイルの作成確認に list_directory を使用すると、キャッシュが原因で誤った否定結果になることがあります。実際の内容を検証するには、必ず read_file を使用してください。
• 取得していないソースの引用：最終報告で、取得や読み込みに成功していないソース（URL、論文のタイトル）を引用します。ソースを明示的に追跡し、未取得の内容を引用しないでください。
• 冗長なツール呼び出し：すでに得られた情報を追跡せず、重複する検索を行ったり、ソースを読み込んだりします。重複を避けるため、「取得済みリソース」のトラッカーを維持してください。

推奨される実践方法

• ソースの事前評価を実施する：URLを読む前に、検索結果を関連性、信頼性、新しさ、権威性に基づいて順位付けします。選定理由を思考ブロックに記録します。
• 構造化された思考ブロックを使用する：各思考ブロックには、（a）ソースまたはアクションから得られた知見、（b）それが調査目標とどう結び付くか、（c）特定された矛盾や不足、（d）下した戦略的判断を含める必要があります。一般的な次のアクションの記述は避けます。
• エラーの明示的な認識を必須にする：ツールが失敗した場合、次の思考ブロックで必ずその失敗に言及します。失敗の種類を記し、復旧策（再試行、代替ソース、または文書化された不足）を提案し、選択した方法を説明します。
• 完了前の検証チェックリストを作成する：調査の完了を宣言する前に、必須のすべてのセクションに具体的な根拠があること、すべてのソースを正常に取得したこと、主要な主張を複数のソースと照合したこと、不足事項を記録したことを確認します。
• 複数ソースによる検証を実施する：複数のソースから情報を集めた後、調査結果を明示的に比較します。ソース間で一致する点、矛盾する点、未検証の点を記録します。これをもとに全体の確信度を評価します。
• ソース追跡表を維持する：思考内に、取得したURL、取得に失敗したURL、特定の主張に使用したURLを示す簡単な表を作成します。取得していないソースを引用してはいけません。
• 検証に Read_File を使用する：ファイルへの書き込みを確認するときは、キャッシュの問題で誤った結果になる可能性がある list_directory ではなく、read_file を使用して実際の内容を検証します。
• 明示的な検証フェーズを追加する：ソースを読んだ後、簡潔な統合結果を記述します。次のフェーズに進む前に、ソースが有用であることを確認し、調査目標との関連性を述べ、残る不足事項を特定します。

ガイドライン

1. 各ツール呼び出しの後、応答にエラーがないか明示的に確認し、失敗があった場合は次の思考ブロックで復旧策とともにその失敗を認識します
2. URLを読む前に、関連性と信頼性に基づいてソースを順位付けし、選定理由を記録します。評価せずに検索結果を読んではいけません
3. 思考ブロックは最低3～5文とし、得られた知見、目標との関連性、不足や矛盾、次のステップを含めます
4. すべての要件が網羅されていること、ソースが取得されていること、主張が検証されていること、不足事項が記録されていることを確認する、完了前のチェックリストを作成します
5. ソース追跡を維持し、正常に取得したURLのみを引用します。取得していないURLの引用は禁止です
6. 最終レポートには、試みたものの失敗した事項や未検証の事項を記録する「制限事項と不足」セクションを含めます
7. 保存後のファイル内容の検証には、list_directory ではなく read_file を使用します
8. 可能であれば、重要な主張を少なくとも2つのソースと照合し、一致点や矛盾点を明示します
9. 複数フェーズにわたる調査では、収集した情報を追跡して検索の重複を防ぎ、「発見済みリソース」のトラッカーを実装します
10. 曖昧な「包括的」という表現を、具体的な要約に置き換えます。「Y のトピックについて X 個のソースを調査し、Z の側面は未調査」のように記述します

例

• *前（アンチパターン）：「コンテキストエンジニアリングを検索したところ、いくつかの結果が見つかりました。これからいくつかの URL を読んで、レポートを書きます。必要な情報は十分に集まりました。」

後（パターン）：「コンテキストエンジニアリングについて、検索結果が 15 件ありました。関連性を評価します。Liu ら（2024）は『lost in the middle』現象に関する最も信頼性の高い情報源と思われます。Anthropic のドキュメントには最新のコンテキストウィンドウ仕様が載っている可能性が高く、Patel（2023）は RAG のベストプラクティスを扱っています。この 3 件を最優先にします。まずは最上位の結果を読みます。主要な情報源が利用できない場合（URL エラー）、正しいドキュメント URL を探すために予備検索を行い、最終レポートで情報の欠落を明記します。」

• *前（アンチパターン）：Anthropic のコンテキストウィンドウの URL に対して、ツールが 404 エラーを返します。エージェントはその事実に触れずに処理を続けます。その後、出典を示さずに「Claude のコンテキストウィンドウは 200K」と引用します。最終レポートでは、取得していない Google Research の論文を引用します。

後（パターン）：ツールが Anthropic の URL に対して 404 を返しました。思考：「主要な情報源を取得できませんでした。代替策として、Anthropic の別のドキュメント URL を検索するか、アーカイブ版を探します。見つからない場合は、コンテキストウィンドウのデータが二次情報源のみに基づくことを記し、検証状況に関する免責事項を加えます。」続いて：「Claude のコンテキストウィンドウを相互検証しました。Anthropic のブログ（正常に閲覧）と 2 件の開発者向けドキュメントの記述は、いずれも 200K で一致しています。この主張には確信があります。」情報源の追跡表には、Anthropic の URL（取得失敗、代替情報源を使用）、ブログ（成功）、開発者向けドキュメント（成功）と示されています。

---

スコアの目安

複数のツール（6 件以上）を使い、複数段階の推論を要する複雑な調査タスクでは、通常 65～75 のスコアになります。これはプロンプトの制限ではなく、次の要因を反映したものです。

• ツールの出力に本質的なばらつきがあり、推論の経路に影響すること
• 複数の有効なアプローチによって、中間スコアが異なること
• 長期にわたるエージェント実行に確率的な性質があること

絶対的なスコアではなく、相対的な改善とパターンの排除に注目してください。 最適化による 5～10％の改善は、複雑なタスクにおいて大きな成果です。

---

スキルのメタデータ

生成日：2026-01-11 情報源：Reasoning Trace Optimizer 最適化の反復回数：10 最高スコア：72/100（4 回目） 最終スコア：70.0/100 スコアの改善：67.6 → 70.0（+3.6%）