包括的リサーチエージェントのベストプラクティス
このスキルは、多段階のリサーチタスクで共通する障害（ツールエラーの未処理、検証不足、不透明な推論、早すぎる結論）に対処します。ソース検証、エラーリカバリ、思考の透明性のための構造化プロトコルを提供し、リサーチの品質と信頼性を大幅に向上させます。
いつ有効にするか
- タスクに search、read_url、fetch 操作を用いたウェブリサーチが含まれる場合
- タスクが複数のソースから情報を収集する必要がある場合
- タスクが完全性や検証について明示的な要件を持つ場合
- タスクに検証が必要なファイル操作（save、write、read）が含まれる場合
- 3回以上のツール対話があるリサーチまたは情報収集ワークフロー全般
コアコンセプト
- 検証チェックポイント: フェーズの移行時に、ツールの出力、ソースの関連性、情報の完全性を確認する明示的な検証ステップ
- エラーリカバリプロトコル: ツールの失敗を黙って続行するのではなく、必須の認識と、フォールバック戦略を用いた処理
- ソーストレーサビリティ: 実際に取得したソースと、事前知識から参照したソースを明確に区別し、幻覚を防止する
- 実質的な思考ブロック: 各ステップでの洞察、関連性、ギャップ、決定理由を文書化した詳細な推論トレース
- クロスソース検証: 複数のソースに対して主要な主張を検証し、コンセンサス、矛盾、情報ギャップを明示的に記録する
避けるべきパターン
- サイレントなツール失敗: ツール呼び出しがエラー（404、タイムアウト、無効なURL）を返したにもかかわらず、エージェントがそれを認識せずに続行し、重要な情報を見逃す可能性がある。常に失敗を記録し、回復を試みるか、ギャップを文書化すること。
- 曖昧な完了主張: エージェントが「十分な情報を得た」や「リサーチは包括的」と宣言するが、何を学んだか、どのソースが主張を裏付けるか、どのようなギャップが残っているかを明示しない。具体的なカバレッジの要約に置き換えること。
- 未検証のソース選択: 検索結果からURLを読む前に、関連性、信頼性、鮮度を評価しない。これは低品質のソースにツール呼び出しを浪費する。深読みの前に常にソースをランク付けし優先順位をつけること。
- 汎用的な思考ブロック: 思考に「今からXを検索する」といった次のアクションの説明だけが含まれ、学んだこと、目標との関連性、残る疑問の分析がない。思考は実質的で内省的であるべき。
- 検証方法の誤り: list_directory を使用してファイル作成を検証すると、キャッシュの問題により偽陰性が発生する可能性がある。実際のコンテンツ検証には常に read_file を使用すること。
- 未取得ソースの引用: 最終報告書で、実際に取得・読み込みに成功していないソース（URL、論文タイトル）を引用する。ソースを明示的に追跡し、未取得コンテンツの引用を禁止すること。
- 重複したツール呼び出し: 既に取得したものを追跡せずに、重複した検索やソースの読み込みを行う。重複を避けるために「見つかったリソース」トラッカーを維持すること。
推奨プラクティス
- 読み込み前のソース評価の実装: URLを読む前に、検索結果を関連性、信頼性、鮮度、権威によってランク付けする。選択の根拠を思考ブロックに文書化する。
- 構造化思考ブロックの使用: 各思考ブロックには以下を含めること。(a) ソース/アクションから学んだこと、(b) リサーチ目標との関連性、(c) 特定された矛盾/ギャップ、(d) 下した戦略的決定。汎用的な次のアクション記述は避ける。
- 必須エラー認識の追加: ツールが失敗した場合、次の思考ブロックで明示的に扱うこと：失敗の種類を記録し、回復戦略（再試行、代替ソース、または文書化されたギャップ）を提案し、選択したアプローチを説明する。
- 完了前検証チェックリストの作成: リサーチ完了を宣言する前に、以下を確認する：必要なセクションすべてに具体的な証拠があること、すべてのソースが正常に取得されたこと、主要な主張がクロス検証されていること、ギャップが文書化されていること。
- クロスソース検証の実装: 複数のソースから情報を収集した後、結果を明示的に比較する。ソース間で一致する点、矛盾する点、未検証の点を記録する。これを使用して全体的な確信度を評価する。
- ソース追跡テーブルの維持: 思考内に、どのURLが取得されたか、どのURLが失敗したか、どのURLが特定の主張に使用されたかを示す簡単なテーブルを作成する。未取得のソースを決して引用しない。
- 検証にRead_Fileを使用: ファイル書き込みを確認するときは、list_directory ではなく read_file を使用して実際のコンテンツを検証する。list_directory はキャッシュの問題により偽陰性を引き起こす可能性がある。
- 明示的な検証フェーズの追加: ソースを読んだ後、簡単な統合を書き、有用性を確認し、リサーチ目標との関連性を指摘し、次のフェーズに進む前に残っているギャップを特定する。
ガイドライン
- 各ツール呼び出しの後、レスポンスのエラーを明示的にチェックし、次の思考ブロックで回復戦略とともに失敗を認識すること
- URLを読む前に、ソースを関連性/信頼性でランク付けし、選択の根拠を文書化すること。評価なしに結果を読まないこと
- 思考ブロックは最低3〜5文以上とし、以下を含めること：学んだこと、目標との関連性、ギャップ/矛盾、次のステップ
- 完了前チェックリストを作成し、以下を確認すること：すべての要件がカバーされているか、ソースが取得されたか、主張が検証されたか、ギャップが文書化されたか
- ソース追跡を維持すること：正常に取得されたURLのみを引用し、未取得のソースの引用を禁止すること
- 最終報告書を作成する際は、「制限とギャップ」セクションを含め、試みたが失敗したこと、または未検証のまま残っていることを文書化すること
- ファイル保存操作後は、list_directory ではなく read_file を使用してファイル内容を検証すること
- 可能な場合は、少なくとも2つのソース間で主要な主張をクロス検証し、コンセンサスまたは矛盾を明示的に記録すること
- 収集した情報を追跡して重複検索を避けること。多段階リサーチのために「見つかったリソース」トラッカーを実装すること
- 曖昧な「包括的」という記述を、具体的な要約に置き換えること：「YトピックについてX個のソースをカバー。Zの側面が不足」
例
- *改善前（アンチパターン）: 「コンテキストエンジニアリングについて検索し、いくつかの結果が見つかりました。次にいくつかのURLを読んで、レポートを書きます。先に進むのに十分な情報があります。」
改善後（パターン）: 「検索でコンテキストエンジニアリングに関する15件の結果が返されました。関連性を評価：Liu et al. (2024) は「中間の喪失」現象について最も権威があると思われる；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%）