Deep Researchは検証のワークフローである

Deep Researchが本当に力を発揮するのは、チャットボットのように振る舞うのをやめ、検証システムのように動き始めたときだ。

この違いは大きい。チャットボットは目の前の質問に答える。検証システムは質問そのものを組み立て直し、証拠を整理し、前提を疑い、現状を確かめ、そして磨き上げられた一段落を「証明」として鵜呑みにすることを拒む。

いまだにほとんどのAIリサーチは、前者のバージョンのように感じられる。市場概観、競合調査、技術サマリー、戦略メモをモデルに頼めば、たいていはもっともらしい何かが返ってくる。目立つ情報源は見つけてくれる。きれいに要約してくれる。自信たっぷりに書いてくれる。重要度の低い作業なら、それで十分かもしれない。

しかし重要度の高い作業では、「もっともらしさ」こそが失敗の形だ。

私が使うDeep Researchのワークフローは、まさにその問題を軸に設計されている。その価値は、より長いレポートを生み出すことではない。複雑さのために多くのエージェントを動かすことでもない。効いてくるのは、繰り返し実行できる一連のループだ。文脈を発見し、主張を整理し、証拠を集め、ドラフトに反論し、成果物を修正し、そして「完了」と呼ぶ前にシステム全体を検証する。

重要な発想の転換はここにある。アウトプットを静的なメモとして扱わない。生きた証拠のグラフとして扱うのだ。

普通のリサーチは早く止まりすぎる

シングルエージェントのリサーチは速い。そしてその速さには意味がある。だが、予測できる弱点も抱えている。

システムの文脈を見落とす。新しいチャットは、ソースツリーもメモもデータセットも受け入れ基準も、最終成果物の形も、自動では把握していない。見えているプロンプトから始めるだけで、動作環境の全体像からは始まらない。

古くなった主張をそのまま受け入れる。かつては正しかった情報源も、今は間違っているかもしれない。QAのメモが、すでに修正済みの問題を指しているかもしれない。生成されたデータセットが、表に見える成果物は変わったのに古い表現を残したままかもしれない。

証拠と解釈を混ぜてしまう。モデルは技術的な主張、市場推計、原典を、それらしく聞こえる形で要約しながら、こっそりと主張の範囲を書き換えてしまうことがある。

そして、文章の指摘で止まってしまう。問題を見つけたときでさえ、作業はコメントで終わりがちだ。「この引用は古いようです」「このセクションは見直すべきです」と。役には立つが、それは検証ではない。検証とは、修正後にドキュメント、データ、引用、メモ、検証の状態がすべて一致していることを意味する。

だから浅いリサーチは、仕上がって見えても脆いままなのだ。最終ドキュメントは読み心地がいい。だが、その下にある主張の連鎖は、レビューに耐えることを一度も強いられていない。

Deep Researchは、その脆さへの私なりの答えだ。

ワークフロー

このワークフローには6つのフェーズがある。どれもシンプルだが、順序が肝心だ。

1. 文脈の発見

最初のステップは書くことではない。方向づけだ。

外部を調べる前に、ワークフローはまずローカルのファイル、メモ、ソースのエクスポート、データセット、既存のQA成果物を探す。狙いは「健忘症」を避けることだ。ワークスペースにすでに関連する文脈があるのに、ゼロから始めてしまう問題を防ぐ。

このフェーズでは、こんな問いに答える。

すでにどんな文脈が存在するか?
この成果物にとって、どの主張が中心的か?
どの情報源がすでに紐づいているか?
どの知見が古くなっている可能性があるか?
この成果物にとって「完了」とは何を意味するのか?

最後の問いは飛ばしやすい。だがAIリサーチが崩れるのは、まさにここだ。リサーチメモ、技術ブリーフ、dashboard、付録では、受け入れ基準が同じではない。ワークフローはコンテンツの品質を判断する前に、成果物の形を見極めなければならない。

2. ソースと主張のマッピング

次に、ワークフローは成果物を一つのシステムとしてマッピングする。

通常の執筆パスでは、文章を読む。検証パスでは、主張を証拠までたどる。どの記述がどのソースIDに依存しているか? どのチャートがどのデータセットに依存しているか? どの付録がエグゼクティブサマリーの主張を繰り返しているか? 表に見える引用のうち、どれがソースのエクスポートから生成されたものか?

ここで成果物はドキュメントであることをやめ、グラフになる。

主張
情報源
ソース参照
データファイル
メモ
付録
ソースエントリー
検証スクリプト

グラフが可視化されると、ズレを捕まえやすくなる。本文で主張を一つ直しても、同じ古い主張が付録やJSONデータ、ソースノート、生成されたエクスポートに生き残っていては不十分だ。

3. 並列でのリサーチと検証

文脈と主張のマッピングを終えて初めて、ワークフローは横に広がっていく。

複数のリサーチのレーンが並列で動ける。あるレーンはソースの網羅性を確かめ、別のレーンは技術的な主張を、また別のレーンは数値と前提を、さらに別のレーンはメタデータと引用の整合性を確かめる。狙いは「マルチエージェント」の見せかけを演出することではない。関心の分離だ。

情報源を集めるリサーチャーが、その解釈の唯一の批評家であってはいけない。ソースIDを確かめるエージェントが、ナラティブの流れに気を取られてはいけない。技術的な主張をレビューするレーンには、「文章は明快だが、この主張は強すぎる」と言う自由が与えられるべきだ。

並列性が重要なのは、それぞれの視点を保てるからだ。作業も速くなるが、速さが主たる利点ではない。主たる利点は、各レーンがより狭い基準を持ち、それをより厳格に適用できることにある。

4. 敵対的QA

4つ目のフェーズは、意図的に懐疑的だ。

ワークフローは、古くなった知見、引用のズレ、壊れた証拠ID、重複したアンカー、切れた内部リンク、生成データの不一致、そして過剰な結論を探す。古いQAメモが今の成果物を正しく描写しているかを確かめる。キャッシュバスティングされたアセットが本当に欠けているのか、それともバリデーターがファイル名を字義どおりに読みすぎて欠けて見えるだけなのかを確かめる。ソースのエクスポートが期待どおりのキーを使っているのか、それとも別の安定した識別子を使っているのかを確かめる。

なぜこれが重要かといえば、リサーチ成果物は退屈な形で壊れるからだ。

危険なエラーは、必ずしも派手なハルシネーションではない。多くの場合、それは小さな食い違いだ。

数値の主張が、間違ったソースIDを指している。
ステータスの主張が、隣接するがより弱い情報源を引いている。
技術サマリーが、二次的なディテールを主要な主張に昇格させている。
ソースエントリーのトピックは正しいのに、その裏づけとなる参照が間違っている。
検証ファイルが、すでに置き換えられた知見を残したままだ。
一方だけにパッチが当たったせいで、ドキュメントと付録が食い違っている。

こうした欠陥は、通し読みでは見逃しやすい。そしてまさに、検証ワークフローが捕まえるべきものだ。

5. 直接の修正

問題を見つけることはゴールではない。

ワークフローがエラーを確認したら、成果物を直接修正する。それは、表に見える文章、生成データ、ソースのマッピング、ソースのエクスポート、メモ、あるいは検証サマリーの更新を意味する。修正は、問題に気づいた場所だけでなく、主張が実際に存在する場所に届かなければならない。

これがDeep Researchと普通のAI支援リサーチの最大の違いだ。ワークフローは批評だけでは満足しない。成果物がより「真実」に近づくことを求める。

基準は証拠に導かれた修正であって、当て推量の書き直しではない。主張が未検証なら、ワークフローはそれを狭める。情報源が古いなら、差し替えるか但し書きを付ける。技術的なニュアンスを完全には確認できないなら、推計を事実にすり替えるのではなく、不確実性をそのまま残す。

6. 最終検証

最後のフェーズは、機械的でありながら不可欠だ。

修正のあと、ワークフローはシステムをもう一度検証する。ソース参照が解決するか、JSONがパースできるか、ローカルのアセットが存在するか、内部リンクが機能するか、重複IDがないか、ソースのエクスポートが一致しているか、フォーマットのチェックが通るか。

このフェーズは華やかではない。だが、信頼が勝ち取られるのはここだ。リサーチ成果物は、優れた文章を備えていても、運用面では壊れていることがある。壊れた引用、古い生成ファイル、無効なデータ構造は、見た目の細部ではない。それらは、成果物が実際には一貫した状態に戻されていなかった証拠だ。

Deep Researchが終わるのは、成果物とその証拠のレイヤーが一致したときだけだ。

私が作ったシステム

このシステムは、シンプルな前提のうえに成り立っている。リサーチの品質は、表に見えるテキストだけでなく、成果物全体の整合性に依存する、という前提だ。

成果物はmarkdownのブリーフでも、構造化されたレポートでも、データセットに支えられたページでも、付録付きのメモでも、生成された成果物でもよい。具体的なフォーマットは変わる。だが制御ループは変わらない。

浅いレビューは、トップレベルのドキュメントを読み、いくつか言い回しの提案をして、そこで止まる。

Deep Researchのシステムは、成果物を「つながり合った複数の面」の集合として扱う。

ナラティブのセクション
ソースのマッピング
データファイル
メモ
付録
生成されたエクスポート
検証成果物

それぞれの面が、他の面と突き合わされてチェックされる。ナラティブが一つのことを言い、データが別のことを言っていれば、システムはその不一致にフラグを立てる。引用が間違った情報源を指していれば、システムはそれを見た目の問題ではなく、主張の失敗として扱う。生成されたアウトプットが古い表現を残していれば、システムは段落だけを直すのではなく、主張をソースのレイヤーまでたどり直す。

私が一番大切にしているのはこの部分だ。ワークフローは執筆と検証を切り離さない。執筆を、証拠のレイヤーに対して説明責任を負うものにする。

このシステムには3つの仕事がある。

ソースのグラフを可視化しつづける。
主張を正しい証拠に紐づけつづける。
修正のあとも、最終成果物の内部整合を保ちつづける。

だからこのワークフローは、一つの領域を超えて役に立つ。市場調査、技術分析、プロダクト戦略、競合レビュー、社内の意思決定支援まで扱える。核となる問題が同じだからだ。主張は、システムが引き戻しつづけない限り、証拠から離れていってしまう。

これが「ドキュメントをレビューした」と「成果物が以前より信頼できるものになった」の違いだ。

なぜこれが積み上がるのか

このワークフローは、時間とともに価値を増していく。実行するたびに、より良い文脈を残していくからだ。

普通のチャットは答えを生み出す。検証ワークフローは、答えに加えて、ソースのマッピング、修正された成果物、検証メモ、そして「その成果物のどこが脆かったか」という再利用可能な知識を残す。次の実行は、冷えた状態からではなく、システムの文脈から始まる。

これが私の大切にしている複利の効果だ。リサーチシステムは、構造化リサーチに現れる特定の種類のエラーを、より上手く捕まえるようになる。生成データが表の文章からズレうることを学ぶ。古いQAファイルが陳腐化しうることを学ぶ。ソースのタイトルと同じくらいソースIDが重要だと学ぶ。技術サマリーには主張の範囲を守る規律が要ると学ぶ。

だからといって、無謀な意味でワークフローが自律するわけではない。むしろ、より検査しやすくなる。判断は依然として人間のものだ。ワークフローは、証拠の道筋を監査しやすくするだけだ。

これはオペレーターの役割も変える。最もレバレッジの高い仕事は、「これを調べてくれる?」と尋ねることではない。何を証拠と見なすか、どの面が一致していなければならないか、どのリスクが敵対的レビューに値するか、そして結果を信頼する前にどんな検証を通さなければならないかを定義することだ。

言い換えれば、オペレーターは単にプロンプトを書いているのではない。リサーチの制御システムを設計しているのだ。

何がうまくいかなくなりうるか

Deep Researchは魔法ではない。運用の規律が崩れれば、失敗しうる。

自分の中間メモを信じすぎることがある。QAチェックリストは役に立つが、古くなっているかもしれない。現在の成果物は、直接確かめなければならない。

生成された構造に過剰適合することがある。バリデーターが、ローカルパスからクエリ文字列を取り除けずにアセットが欠けているとフラグを立てるかもしれない。CSVのチェックが、エクスポートは実際には evidence_id を使っているのに、安定したキーは id だと決めつけるかもしれない。

不確実な主張を言い切りすぎることがある。市場規模の推計、技術のスコープ、競合のポジショニング、原典の解釈には、最終的な文章にまで残すべき不確実性が伴うことが多い。

表のレイヤーだけを直してしまうことがある。これが最もよくある失敗だ。ドキュメントは正しく読めるのに、データやメモ、ソースのエクスポートが古い主張を抱えたままなのだ。

対策は退屈で厳格だ。システムをマッピングし、可能な限り一次情報や恒久的な情報源に照らして検証し、依存するすべての面にパッチを当て、編集後に検証する。

再利用できるメンタルモデル

このワークフローを最もシンプルにすると、4つの動詞になる。

マップする。検証する。パッチを当てる。検証しなおす。

主張と、それが現れる面をマップする。

文章の自信ではなく、原典に照らして主張を検証する。

生成データや引用のレイヤーも含め、実際の成果物にパッチを当てる。

最終成果物が内部で一貫していることを検証しなおす。

これがDeep Researchを、AIによる要約と分ける点だ。説得力のある初稿に最適化するのではない。自分自身の証拠との衝突に耐えられる成果物に最適化する。

技術系のオペレーター、創業者、プロダクト戦略家、AIのパワーユーザーにとって、真似する価値があるのはこの部分だ。ただ多く書くだけのリサーチワークフローを作ってはいけない。主張に説明責任を負わせるワークフローを作るのだ。

AIリサーチの未来は、最も長い答えではない。レビューを経てもなお、その証拠のグラフが崩れずに保たれている答えだ。