Skip to Content
Docs13. ドメイン応用ディープリサーチ型エージェントの設計
上級deep-researchragloop-engineeringcitation更新: 2026-09-10この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

ディープリサーチ型エージェントの設計

この記事の目的

多段の調査(計画 → 検索 → 読解 → 統合 → レポート)を自律実行するディープリサーチ(deep research)型エージェントを、出典の信頼性を保ったまま設計できるようになります。調査タスクの分解・多段検索の打ち切り判断・全主張への出典紐付け・相反する情報源の扱い・レポート形式・評価の設計を、実装の勘所とともに持ち帰れる状態を目指します。

対象読者

前提知識

本文

概要: 「速い RAG」ではなく「調べ切る」設計

ディープリサーチ型エージェントは、調査計画・反復検索・統合をまとめた設計です。RAG 自体も多段検索を含みうるため、検索回数だけで RAG と Agent を区別するものではありません。曖昧な問いを受け取り、自分で調査計画を立て、検索と読解を何度も繰り返し、複数の情報源を突き合わせて、出典付きのレポートを生成します。人間のリサーチャーの仕事を模す、と言えます。

この形式が向くのは、検証可能性が中〜高く、失敗コストが高い調査タスクです(ユースケース発見の軸)。競合調査・技術選定の下調べ・規制の一次情報発信源そのものの情報(論文の原典・公式ドキュメント・公式ブログ・規格本文・法令)。解説・まとめ(二次情報)と区別し、根拠は一次情報に置くのが情報リテラシーの基本。二次情報は「存在を知る」までに使い、一次まで遡って確かめる。の洗い出しなどが典型です。逆に、即答が要る問いや、単一ドキュメントで完結する問いにはオーバースペックで、単発 RAG やそのまま検索を返すほうが速くて安全です。

設計の全体像は次のパイプラインです。各段は独立した設計判断を持ちます。

ディープリサーチ型エージェントの設計: 概要: 「速い RAG」ではなく「調べ切る」設計の図ディープリサーチ型エージェントの設計: 概要: 「速い RAG」ではなく「調べ切る」設計の図
ディープリサーチ型エージェントの設計: 概要: 「速い RAG」ではなく「調べ切る」設計の図
図を元の大きさで表示

図の中をスクロールして読めます。キーボードでは図の領域へ Tab で移動し、矢印キーを使います。読み終わったら、この見出しをもう一度選ぶと閉じます。

ディープリサーチ型エージェントの設計: 概要: 「速い RAG」ではなく「調べ切る」設計の図ディープリサーチ型エージェントの設計: 概要: 「速い RAG」ではなく「調べ切る」設計の図

このライブラリ自身の research/ ディレクトリ(執筆前の公式情報調査メモ)は、この型の記録形式を検討する参考です。「事実 / 出典 URL / 確認日 / 確度」を対応づける形式は、そのままエージェントの出力設計の参考になります。

調査タスクの分解(調査計画の生成)

最初のステップは、曖昧な問いを調査可能なサブクエスチョンに割ることです。ここを飛ばして「いきなり検索」すると、検索クエリが問い全体をなぞるだけになり、浅い結果しか返りません。

  • 調査計画を明示的に生成する: 「この問いに答えるには何を確かめる必要があるか」をエージェントにまず列挙させます。計画をテキスト(または構造化出力)として残すと、後段の進捗判定・打ち切り判断・レポート構成の骨格に再利用できます
  • サブクエスチョンは検証可能な粒度まで割る: 「A は B より優れているか」ではなく「A の公式が示す X の値」「B の公式が示す X の値」まで割ると、各サブクエスチョンに出典を 1 対 1 で紐付けられます。抽象的な問いのまま検索すると、意見記事を根拠にしてしまいがちです
  • 計画は固定しない: 調査の途中で「そもそも問いの前提が違った」と分かることがあります。計画をリードオンリーの契約にせず、中間結果に応じてサブクエスチョンを追加・削除できる設計にします(次節のループと接続)

多段検索の制御(広げる・深める・打ち切る)

ディープリサーチの中核は、検索をいつ広げ・いつ深め・いつ打ち切るかの判断です。ここが甘いと、無限に検索し続けてコストが膨らむか、逆に 1〜2 回で満足して浅いレポートを出すかの両極に振れます。ループエンジニアリングの停止条件設計を、調査ドメインに具体化したものと考えてください。

  • 広げる(breadth): サブクエスチョンを網羅できていないとき。まだ触れていない観点・情報源の種類(公式・学術・報道)を増やします
  • 深める(depth): ある主張の根拠が弱い・一次情報に届いていないとき。二次情報から一次情報へ、要約から原文へ辿ります
  • 打ち切る(stop): 判断が最も難しい部分です。次の複数の停止条件を併用します
    • 飽和: 新しい検索が既知の事実しか返さなくなった(新規情報の増分がしきい値を下回る)
    • 計画の充足: すべてのサブクエスチョンに一定確度以上の出典が付いた
    • 予算: 検索回数・トークン・時間の上限(長時間実行エージェントの予算管理)。上限に達したら「未確認事項」として明示して打ち切る

無限ループと過少調査は同じ根から生じます。 「進捗しているか」を測れないと、停止できない(進捗ゼロでも回り続ける)か、早すぎる打ち切り(進捗しているのに止める)のどちらかになります。各ステップで「計画のどのサブクエスチョンが埋まったか」を更新し、進捗を可観測にすることが、両方の解決策です。中間状態のトレースは 可観測性とトレーシング を参照してください。

出典管理: 全主張に出典を紐付ける

ディープリサーチ型で最も価値を分けるのが、出典管理の厳密さです。レポートの体裁は同じでも、「全主張に検証済みの出典が付く」ものと「もっともらしい文章に後付けで URL を貼った」ものは、実務での信頼性が根本的に違います。

  • 主張と出典を生成時に紐付ける: レポートを書き終えてから出典を探させると、文章に合う出典を探すという逆向きの動きになり、出典の捏造や牽強付会が起きます。読解・抽出の段階で「事実 → その出典」をペアで蓄積し、レポートはそのペアからのみ構成します
  • 出典なし主張を排除する: 蓄積した出典ペアに紐付かない主張は、レポートに出さないか、明確に「一般論・推測」と区別します。エージェントが背景知識(訓練データ)から埋めた文は、出典がないため後で検証できません
  • 引用を検証する: 「その URL に、その主張が実際に書いてあるか」を別ステップで確かめます(ループのフィードバックと検証)。生成モデルは実在する URL に対して書かれていない内容を要約として付けることがあります。可能なら引用箇所(該当文)まで保持し、レポートから原文へ辿れるようにします
  • 一次情報を優先する: 同じ事実でも、公式ドキュメント・原論文・一次統計を、まとめ記事より上位に置きます。出典の発行主体をメタデータとして持つと、後述の確度付けと相反解消に使えます

相反する情報源の扱い(確度の表現)

深く調べるほど、情報源どうしが食い違う場面に必ず出会います。ここでエージェントが「片方を勝手に採用して断定する」と、もっともらしいが偏ったレポートになります。

  • 食い違いを潰さず、明示する: 「A は X と述べ、B は Y と述べる」と両論を残すのが既定です。無理に一つの結論へ丸めません
  • 確度を表現する: 一次性、資料の独立性、対象・時点の一致、反証の有無を記録し、根拠の強さのラベルを主張ごとに付けます。転載された複数記事は独立した裏付けになりません。このラベルは編集上の判断であり、正答確率として較正された信頼度ではありません
  • 発行主体と日付で重み付けする: 相反したとき、発行主体(公式かどうか)と情報の鮮度(いつの時点か)で優先順位の手がかりを示します。ただし最終判断は読者に委ねる書き方にし、エージェントが独断で「Y は誤り」と断じないようにします

社内資料と Web の統合

実務のディープリサーチは、社内資料と Webを統合します。所在だけでは内容の正確さや命令としての権限を判断できません。検索時の権限と外部送信経路を分けて管理します。

  • 経路と権限を分ける: 社内資料は権限を反映した検索経路で引き、Web は別経路で引きます。社内の機密が Web 検索クエリに漏れる・外部の内容が社内資料と区別なく混ざる、といった経路の取り違えを防ぎます
  • 主張ごとに根拠を評価する: 社内制度は承認済み社内規程、外部製品の仕様は提供元の公式資料、というように主張への適合性・発行者・日付を確認します。社内資料にも古い情報や攻撃者由来の指示が混ざりえます。検索文書は所在を問わず、命令ではなく資料として扱います
  • 秘匿の扱い: 社内資料を根拠にレポートを書くとき、そのレポートの配布先が資料の閲覧権限を満たすかを設計に含めます(データ持ち出し対策)

レポート形式の設計

出力レポートは、読者が検証・再調査できる形式にします。結論だけの美しいレポートより、根拠へ辿れる無骨なレポートのほうが実務価値が高い、というのがこのドメインの原則です。

  • 構成を計画から導く: 調査計画のサブクエスチョンをそのまま節構成の骨格にすると、網羅性が担保され、抜けが見えます
  • 確度と出典を本文に埋める: 各主張に確度ラベルと出典リンクを添えます。末尾一括の参考文献より、主張の隣に出典があるほうが検証しやすいです
  • 未確認事項を明示する: 打ち切り時に埋まらなかったサブクエスチョンを「未確認事項」として残します。「調べたが分からなかった」と「調べていない」を区別するのが、信頼できるレポートの条件です
  • 構造化出力LLM の出力を JSON Schema などの機械可読なスキーマに従わせる技術。後続の処理がコードである出力(分類・抽出・スコア)に使う。を併用する: レポートの骨格(主張・出典・確度のリスト)を構造化出力で持つと、後述の自動評価や、他システムへの引き渡しが容易になります

評価の設計

ディープリサーチ型の評価は、単発 RAG より難しくなります。「正解の 1 文」ではなく「レポート全体の質」を測るためです。次の 3 軸に分けて設計します(評価データセット・LLM-as-a-Judge)。

  • 網羅性: 用意した問いに対し、押さえるべき論点を落としていないか。基準となる論点リスト(ゴールドの観点)を人手で作り、レポートがそれを何割カバーしたかで測ります
  • 出典正確性: 各主張の出典が実在し、かつ主張を実際に支持しているか。ここは自動チェック(URL 到達性 + 引用箇所の含意判定)と人手抜き取りを併用します。捏造出典ゼロを最優先の合格条件にします
  • 再現性: 同じ問いで、結論の骨格が安定するか。多段の自律実行はばらつきが大きいため、複数回実行して結論の分散を見ます。分散が大きいレポートは、確度の表現を厚くする設計判断につながります

実務での注意点

アンチパターン

  • 調査計画を立てず、いきなり検索する → 検索が問いをなぞるだけで浅い結果しか出ない → まずサブクエスチョンへ分解し、計画をレポート構成に再利用する
  • レポートを書いてから出典を後付けする → 文章に合う出典を探す逆向きの動きで、捏造・牽強付会が起きる → 読解段階で「事実 → 出典」をペアで蓄積し、そのペアからのみ書く
  • 引用先を検証しない → 実在 URL に書かれていない内容を要約として付けてしまう → 引用箇所の含意を別ステップで確認する
  • 相反する情報源を片方に丸める → もっともらしいが偏ったレポートになる → 両論を残し、確度と発行主体で手がかりを示し、判断は読者に委ねる
  • 停止条件が飽和判定だけ、または予算だけ → 過少調査か暴走のどちらかに振れる → 飽和・計画充足・予算を併用し、進捗を可観測にする
  • 「調べたが不明」と「未調査」を区別しない → 読者が抜けに気づけない → 未確認事項を明示的に残す

チェックリスト

  • 曖昧な問いを、出典を 1 対 1 で紐付けられる粒度のサブクエスチョンへ分解しているか
  • 停止条件を複数(飽和・計画充足・予算)併用し、進捗を可観測にしているか
  • すべての主張が、検証済みの出典ペアに紐付いているか(出典なし主張を排除しているか)
  • 引用先に主張が実際に書かれているかを検証するステップがあるか
  • 相反する情報源を両論併記し、確度を主張ごとに表現しているか
  • 社内資料と Web の検索経路・権限を管理し、根拠の強さは主張への適合性で評価しているか
  • レポートに未確認事項を明示し、「不明」と「未調査」を区別しているか
  • 網羅性・出典正確性・再現性の 3 軸で評価し、捏造出典ゼロを合格条件にしているか

関連トピック

参考資料

TODO・未確認事項

なし

セクション概要データ分析エージェント