複雑なリサーチをAIに丸ごと任せようとするとき、まず決めなければならないことがある。計画をどこまで先に立てておくか、だ。
ここでいうディープリサーチとは、数十から数百の情報源を行き来しながら証拠を集め、複雑な問いを解くAIのタスクを指す。最近公開されたディープリサーチエージェントDAGentの答えは意外なものだった。先にすべてを立てない。全体の計画を最初に確定する代わりに、たった今終わったタスクがどれだけ確かなのか、何がまだ不確かなのかを確かめてから、はじめて次にやることを継ぎ足す。この方式に著者らはEvaluate-then-Grow、つまり「評価してから育てる」という名前を付けた。
結論から言おう。同じモデルと同じツールで条件をそろえ、従来方式と突き合わせたとき、DAGentは精度が高いうえに、課題を一つ解くのに使ったトークンとツール呼び出し、ステップ数はむしろ少なかった。普通、この二つはトレードオフになる。精度を上げるには計算をもっと注ぎ込む必要があり、節約すれば精度を手放すことになる。DAGentは両方を同時に手にした。
ディープリサーチはありふれた検索とは違う。一つの問いをめぐって数百の情報源を漁らなければならない。こうした仕事には、作業を細かく分けたうえで「これが終わってからあれをやる」という前後関係で結んでいくやり方がよく合う。こうして組み上げた作業の地図をDAGと呼ぶ。矢印が一方向にだけ流れ、後戻りしないグラフという意味だ。互いに依存しない枝は同時に回せるし、各ワーカーは全体の履歴ではなく、自分が足場にしているタスクだけを見ればよい。ここまではすでに定着した設計だ。
分かれ目は「計画をいつ決めるか」にある。従来のDAGエージェントはたいてい、仕事を始める前に課題全体を覆う計画を一度に立てる。そして実行の途中で失敗や証拠不足が見えてきたら、そのときになってグラフを直す。論文はこのパターンをPlan-then-Patch、「まず計画し、あとで継ぎ当てる」と呼ぶ。
ここに構造的な落とし穴がある。システムは問題をもっとも分かっていないとき、手元の証拠がもっとも乏しいその瞬間に、もっとも大きな計画を確定してしまうのだ。
山にたとえると分かりやすい。頂上までの道のり全体を出発前に地図へ描いておき、登るうちに道が塞がるたびに消しては描き直す——これがPlan-then-Patchだ。視界がもっとも利かない山の麓で、もっとも多くの線を引くことになる。Evaluate-then-Growは順序を逆にする。一区間を登って視界が開けたところで、はじめて次の区間だけを決める。
こうしてDAGentは「始める時点ですべてを確定しなければならない」という従来の前提を崩した。完了したサブタスクの結果と根拠、信頼度の要約に、一つひとつの計画判断を結びつけた初めてのディープリサーチエージェントだ、というのが著者らの説明だ。
何に勝ったのかを先にはっきりさせておこう。DAGentは一つの強者を倒したわけではない。三つのベンチマークは性格がそれぞれ異なっていて、1位を守っていた方式もベンチマークごとに違った。DAGentは、その異なる1位を三つすべてで上回った。学習をまったく付けず、もっとも大きなバックボーンモデルを載せた設定でだ。ここでいうバックボーンモデルとは、エージェントの頭脳の役割を担うLLM(大規模言語モデル)のことで、バックボーンとも呼ぶ。スコアはPass@1、一度実行して正解を当てられるかを見る「初回合格率」の平均だ。
| ベンチマーク | そのベンチマークの従来1位 | DAGent | 差 |
|---|---|---|---|
| BrowseComp-Plus | 56.0 (履歴要約方式) | 61.3 | +5.3 |
| GAIA | 57.3 (コンテキストウィンドウ109K ReAct) | 63.1 | +5.8 |
| xbench-DeepSearch | 70.0 (Flash-Searcher) | 72.0 | +2.0 |
(学習なし · バックボーン Qwen3-235B-A22B · すべてPass@1平均)
括弧内は各ベンチマークで1位だった従来方式の名前なので、見慣れなくてもそのまま読み飛ばして構わない。ちなみに「コンテキストウィンドウ」とは、AIが一度に頭の中に抱えておいて見られる文章の量を指す。
一つのモデルでたまたま出た結果でもない。Qwen3-8Bから235Bまで規模をまたいで、四つのベンダーのオープンソース・バックボーンでも同じパターンが繰り返された。さらにGPT-5をコンテキスト327Kまで広げた設定で比べたときも、最新のエージェントシステムと渡り合えた。
学習を付けると差はさらに開く。Qwen3-8BにDAGRPOという強化学習を適用したところ、同じ計算予算を使った「結果だけを見る」従来の強化学習より、平均Pass@1が3.0ポイント上がった。ただし、この利得が設定値と無関係なわけではない。核心となる設定値の一つ(論文ではα)を変えながら回した感度分析——設定を揺らしたときに性能がどう変わるかを見る検査——を見ると、αを0.25・0.75に置いたとき平均性能は最適設定よりそれぞれ1.2ポイント・1.4ポイント低く、αを0に置くと「結果だけを見る」従来の強化学習のベースラインよりも低くなった。利得をきちんと享受するには、この設定値を適切に合わせる必要があるということだ。(表3)(DAGRPOが何かは後でまとめて見る。)
コストの話は、もっともきれいな比較ではっきりと浮かび上がる。ほかの条件はすべてそのままにして、計画方式だけをEvaluate-then-GrowとPlan-then-Patchで入れ替えて突き合わせる実験だ。モデルもツールも構造も同じなのだから、差が出るとすればそれは計画方式のせいだ。結果は明快だった。証拠を見て広げる側が、課題あたりのトークンとツール呼び出し、ステップをより少なく使いながら精度が高かった。その幅は付録表10に数字で刻まれている。BrowseComp-PlusではPlan-then-Patch比でDAGentは、トークンを168万から120万へ、ツール呼び出しを87.9回から67.6回へ、ステップを54.8から42.7へ減らした。変数をたった一つに絞ったこの比較は、「より正確でありながらより安い」という主張のもっとも強力な証拠だ。
実験そのものは丁寧だ。Qwen3三種に別ベンダー三つ、そしてGPT-5まで七種のバックボーンと三つのベンチマークを行き来し、すべての手法が同じ検索バックエンド——実際に資料を探してくる検索エンジンやツール——を共有するよう条件を固定した。細かな設計は原文にある。
では「証拠を見て育てる」を、機械はどうやって成し遂げるのか。動作の原理は役割分担ひとつに要約される。「オーケストレーター」と「ワーカー」を分け、両者のあいだに明確な信号を流したのだ。
オーケストレーター(Orchestrator)は、ここまでに終わったタスクを見て、グラフに次のタスクの束、つまり一つのバッチを継ぎ足す。ワーカー(ReAct Executor)は「考えて、ツールを使い、結果を見る」を繰り返す実行エージェントだ。新しく足されたタスクは、互いに依存しないかぎり並んで回る。
肝心なのは、ワーカーがオーケストレーターに何を渡すかにある。タスクが一つ終わると、二組の記録が残る。一つは実行の過程を丸ごと収めた詳細な記録で、もう一つはそれを一枚に圧縮した要約カード、名付けてQueryDocだ。
このカードには五つが収められる。サブタスクの答え、その答えについての短い説明、核心となる実行ステップの要約——ここまでが「何を突き止めたか」だ。そして実行者が自分で付けた確信度、まだ確かめるべき不確実性のリスト——この二つが「それがどれだけ信頼でき、何がさらに気になるか」だ。ワーカーは答えだけをぽんと放り投げたりしない。自分が出した結果に自分で点数を付けて一緒に上げる。だからオーケストレーターが覗き込むのは、長々とした実行過程の全体ではなく、答えとその信頼度までを一枚に収めたこの要約カードなのだ。
まさにこのカードが次の一手を決める。オーケストレーターは、たった今終わったバッチのタスクごとに状態を付ける。確かな証拠をつかんだらSuccess、さらに検証が必要ならUncertain、問題なく回ったものの使える証拠がなければNot Found。UncertainやNot Foundが付いたタスクは、別の検索戦略で同じ仕事をやり直すrefineタスクを生む。ただし、一つの筋につき三回までだ。最初の一回に補強を二回、そこで打ち切って無限の再試行を防ぐ。そうやって広げていき、オーケストレーターが散らばった証拠を集めて最終的な答えを組み上げるanswerタスクを立てたら終わりだ。このタスクは必ず自分のバッチに一つだけで存在しなければならない。そうしてこそ、上から降りてきた証拠すべてに届いて答えを組み立てられる。
長いリサーチでは、実行記録は果てしなく長くなる。ところが下流のタスクが必要とするのは、たいてい上流の「結論」だけだ。だから基本的には要約カードだけを次のタスクへ渡す。各タスクは、自分が直接足場にしているタスクの要約だけを受け取る。論文はこれを選別的な伝播と呼ぶ。おかげで一つのタスクが背負うコンテキストの大きさは、「グラフ全体」ではなく「自分に直接入ってくる前後関係の数」だけに抑えられる。要約では足りないとき——原文の正確な表現が必要な場合のように——だけ、ワーカーが詳細な記録から必要な断片を取り出してくる。あくまで例外だ。
これらすべてを支える性質が一つある。append-only、一度足したタスクは消しも繋ぎ直しもせず、積み上げるだけだ、というルールだ。だから「あるタスクが実行されたとき実際に見ていたコンテキスト」が「完成したグラフでそのタスクより上に置かれたタスク」とぴったり一致する。ささいに見えるこの性質が、まさに次の話の鍵になる。
DAGentをもう一段引き上げる仕掛けがDAGRPOだ。出発点は、ごく常識的な不満ひとつだ。一つのグラフの中でも、ある実行は最終的な答えへとつながった核心の経路の上にあり、ある実行は結局使われなかった行き止まりの探索だ。ところが従来の強化学習はこの二つを区別しない。ここでいう従来方式とはGRPOのことで、同じ問題を何度も実行してみたうえで、平均よりうまくやった側に力を入れる方法だ。この方式は最終的な成否だけを見る。
問題は、学習の信号がぼやけてしまう点にある。正解にたどり着いた実行であろうと、さんざん迷った末に捨てられた実行であろうと、同じ点数を受け取れば、モデルは「どの選択が実際に答えに役立ったのか」を最後まで見分けられない。
DAGRPOがやるのは、この点を正すことだ。最終的な答えと、そこまで実際につながったすべての上流タスクを束ねて「答えに貢献した集合」とみなす。この集合の中で働いたワーカーは報酬をまるごと受け取り、集合の外で空回りしたワーカーは報酬が削られる。もし答えへつながる鎖がそもそも作られなかったなら、削らずに元の方式に戻す。無理に罰しはしない。
この貢献度の追跡ができるのは、ひとえに先に述べたappend-onlyのおかげだ。「答えに貢献した集合」は、もう一度実行してみるまでもなく、積み上がるだけのグラフ構造を遡って読むだけでそのまま出てくる。計画を立てては消し、また繋ぎ直すPlan-then-Patchでは、最終的な構造と実際に参照した内容が食い違いうるため、こうした信号をそもそも定義することすらできない。いわば計画方式の選択が、学習方式の革新をタダで連れてきたわけだ。
この方法が万能薬なわけではない。著者らが自ら引いた限界線のほうが、かえって率直だ。
まず「答えに貢献した集合」は、因果ではなく構造で代わりに測る指標だ。「最終的な答えへつながった鎖の上にあった」という事実が、「そのタスクが正解を生み出した」と同じ意味なわけではない。方法全体がappend-onlyという前提に縛られている点も指摘しておく価値がある。グラフを消して繋ぎ直す設計に移った瞬間、DAGRPOの成果配分の信号はそのままでは使えない。
もっと重たいのは別にある。もっとも難しい問題は、依然として大半が解けない。BrowseComp-Plusの難問グループでDAGentのスコアは、Qwen3-8B基準で6.0、もっとも大きな235Bでも22.0にとどまった。三つのベンチマークをまたいだ優位とは別に、ディープリサーチの本当の難題はまだ大きな宿題として残っている、という信号だ。
読むときつねに念頭に置くべき条件もある。成績はPass@1とLLMによる判定に頼っている。一度回して当てたかだけを見て、正解の判定も人ではなく別のLLMが付ける。審判が間違えばスコアも間違う。DAGRPOの学習の利得はQwen3-8B規模で確認されたにすぎず、より大きなモデルでも保たれるかはこの論文の範囲外だ。ベンチマークごとに検索バックエンドが固定されているので、別のツールスタックや別の分野に移したときの一般化もさらに見る必要がある。
最先端のAIエージェントが計算を節約しようとして見つけ出したこの規律は、じつは私たちの働き方にもそのまま通じている。ONTLEでAI PMを設計しながら、私たちがぶつかった地点でもある。
一つの場面を見よう。顧客が「競合と比べた自社の価格とレビューの競争力を分析してほしい」と依頼してきた。先にすべてを立ててしまうPMなら、受付当日、まだ何も覗き込む前に調査計画の全体を打ち込む。競合リストの確定、価格の収集、レビューの分析、総合まで。ところがいざ価格を集めようとすると、競合の二社が価格を非公開にしている。その下にぶら下げておいた「価格比較」の枝が丸ごと空計画になり、消しては描き直す。顧客が依頼をもっとも曖昧に投げてきたまさにその瞬間に、計画をもっとも多く確定しておいたせいだ。
ONTLEでプロジェクトをサブタスクへ細かく分けて枝を張る方式は、まさに先に見た作業グラフと同じだ。今も作業はこうした枝の形で管理されている。ここにEvaluate-then-Growの順序を重ねるのが、私たちが描く次の絵だ。AI PMが最初のバッチで「競合の特定」と「価格が公開されているかの確認」だけを回してみて、各タスクが残した確信度・不確実性を確かめてから、はじめて次のバッチを組む、という具合だ。「五社のうち三社は価格公開、確信は高い。残り二社は追加ソースが必要、不確実」。この信号を受け取ってはじめて次の一手を決め、「不確実」と刻まれたところが長く解けないなら、ONTLE顧客画面の「決定を待っています」の状態へ上げて、人の判断を呼ぶ。
報告の仕方も同じ枠から出てくる。「結論と根拠、確信度、まだ不確かなこと」に圧縮した要約カードは、そのままAI PMが顧客へ上げる中間報告の形であり、詳細な実行記録は「その数字の出所は正確に何なのか」という問いが来たときにだけ取り出す。最先端の研究がコストを節約しようとしてたどり着いた原理が、よいPMがつねに守ってきた常識と同じところで出会う、というわけだ。
まれだ。RecallToolは要約カードでは足りないときにだけ詳細な記録を取り出す例外経路だ。Qwen3-32Bの実行を基準に、BrowseComp-Plus・GAIA・xbench-DeepSearchでそれぞれ全課題の22.0 / 13.6 / 11.0%でだけ使われた。
二つを分けて見る必要がある。本文の表にある「三つすべてで上回った」成績は、そもそも学習を一切付けていない設定だ。一方でDAGRPOで学習したバージョンを見るときは、BrowseComp-Plus一つだけで学習したチェックポイントを、残り二つのベンチマークにそのまま持ってきて評価した。このように「その課題で別途学習しないまま評価すること」をゼロショットと呼ぶ。つまりベンチマークごとに新たに学習させたわけではない。
著者らは、「答えに貢献した集合」はもう一度実行する必要なく記録されたグラフから読み取れる構造的な代理指標であり、学習中に依存関係を膨らませるやり方では悪用されない、と付録で説明している。
コードはGitHub(github.com/hanwenliu6825/DAGent)に公開されている、と論文に書かれている。評価に使った三つのベンチマークはBrowseComp-Plus・GAIA・xbench-DeepSearchだ。