ONTLEに「競合の価格を調べて要約レポートにまとめてほしい」というプロジェクトが入ったとしよう。仕事は三つに分かれる。資料収集、データ分析、レポート作成。こうして複数のAIが役割を分け合い、一つの仕事を一緒に片づけていく作業の流れを、マルチエージェントワークフロー(複数のAIエージェントが分業する作業パイプライン)と呼ぶ。
このやり方の弱点は、ある一工程がずれた瞬間に姿を現す。データ分析が見当違いの結果を出すと、たいていは最初からやり直す。すでにうまく終わっていた資料収集にまで、二度分の対価を払うことになる。蛇口が一つ漏れているからといって、家をまるごと建て直すようなものだ。
InFlowOpという論文は、家を建て直さない。漏れているところだけを直す。しかも実行が終わるのを待たずに途中で、そして「正解表」(何が正しい答えかをあらかじめ書いておいた基準)なしで。この記事では、上のレポート一件を最初から最後まで追いかけながら、三つのことを見ていく。分析工程を誰に任せるかをどう選ぶのか、何を見て「ずれた」と判定するのか、そしてどこまで巻き戻すのか。
先に一つだけ耳打ちしておく。この論文でいちばん興味深いところは「どう直すか」ではない。その修正技術の裏には、もっと大事な問いが一つ隠れていて、その答えは記事の最後の数字が自分で語ってくれる。
InFlowOpの心臓には、一つの天秤がある。仕事をどう割り、誰に任せるかを、成功の見込み(信頼度)とかかる時間(遅延)を一つにまとめたスコアに換算して量る天秤だ。そしてスコアがいちばん低い道が勝つ。
すぐに腑に落ちるよう、場面を一つ上げてみよう。分析工程を任せる候補が二つある。一つは正確だが遅い大きなモデル、もう一つは速くて安いがよく間違える小さなモデル。大きなモデルは信頼度が高い代わりに遅延が大きく、小さなモデルはその逆だ。天秤は二つを同じ目盛りの上に乗せ、全体のスコアをより下げるほうを選ぶ。「この仕事が求めるものをどれだけ満たすか」を「回すのにいくらかかるか」と向き合わせるわけだ。
ここでいう「コスト」は請求書に刻まれるお金ではなく、設計を選ぶためのスコアだという点だけ覚えておこう。この区別は、あとで数字を読むときにもう一度効いてくる。
では、天秤に乗せる候補はどう決めるのか。そのためには、まず仕事を切り分けなければならない。InFlowOpは断片の数をあらかじめ決めておかない。細かく分けるほど一つ一つの断片は狭く信頼できるものになるが、回すべきAIが増えて遅くなり、ずれる分かれ目も多くなる。だから、いったんこれ以上割れない最小単位まで細かく分解したうえで、もう一度まとめるのはスコアを下げるときだけにする。どれだけ細かく分けるかさえ、好みではなくスコアが決めるのだ。
断片が決まると、断片ごとに候補のAIを天秤に乗せる。このときの判断基準が肝心なのだが、それは正解と合っているかではない。成果物に必ず入っていなければならない項目をあらかじめ書き出しておき、各候補がその項目をどれだけ満たせそうかをスコアにして付ける。候補が自ら申告した能力と、これまで積み上げてきた実行記録を、その断片が求めるものと突き合わせるという具合だ。
ここがこの論文の賢いところだ。「正解と合うか」ではなく「求めた項目を備えているか」だけを見るので、正解を知らない状態でも評価が回る。
どの候補も基準線を越えられなければ、その断片は「任せる人がいない席」として浮かび上がる。このときだけ罰点を課して、新しいAIを作って候補に加える。大事なのは、無理に押しつける選択と新しく作る選択が、同じ天秤の上で競わされるという点だ。だから新しく作る仕事は、本当に誰にも任せられないときにだけ起きる。
どれだけうまく組んでも、設計は結局のところ予測だ。本当の弱点は、回してみて初めて姿を現す。
レポートに戻ろう。回してみると、データ分析工程が使えない表を出してきた。ところがレポート作成工程は、すでにその表を前提にして文章を書いている。何を見て「ずれた」と判定するのか。
InFlowOpはここでも正解と突き合わせない。代わりに、各工程に始まる前から「約束」を掛けておく。この工程が受け取るべき入力の条件、そして出すべき出力の条件だ。
価格レポートの分析工程に具体化してみよう。入力の条件は、たとえば「資料収集が渡してきた表に、競合ごとの価格が空欄なく埋まっていること、通貨単位が一つに統一されていること」だ。出力の条件は「分析結果に競合の数だけ比較行があり、各行に価格と順位が数字で入っていること」といったところだ。正解(本当の市場一位が誰か)はプロジェクトがすべて終わらないと分からないが、こうした条件は工程が始まる前にでも書いておける。だから全体を終えなくても、実行の途中でずれた地点をすぐに突き止められる。
判定はそこからもう一歩進む。約束のどちら側が破れたかが、責任の所在を分ける。出力の条件を満たせなかったなら — たとえば比較行はすべてあるのに順位の欄が空いていたなら — 仕事はちゃんと置かれていたのに、任されたAIがやりきれなかったということだ。逆に入力の条件から食い違っていたなら — 渡された表の価格の欄がそもそも空いていたなら — 必要な材料を受け取れてすらいなかったわけだ。後者は担当を替えても直らない。仕事を割った切り方そのものを、もう一度いじらなければならない。
判定が終わると、実行はずれたその工程だけで止まる。すでに積み上がった進捗には手をつけない。直す手は、安いものから取り出す。
いちばん安い手は、担当だけを替えることだ。工程も依存の構造もそのままにして、任されたAIだけを入れ替える。たった今失敗した候補は外し、次善を乗せる。出力が未達のときに使う手だ。
これで駄目なら、もう一段上がる。その工程を、さらに細かく割った小さなワークフローに作り替えるのだ。さきほど見た分解・割り当てを、その場だけでもう一度回す分のコストがかかる。入力から脆かったときに使う手だ。
すべての手には予算が掛かっている。使い切ったら元の値に巻き戻す。変わった結果は検証を通ったときにだけ反映され、そうでなければ捨てる。おかげで修正は、ワークフローをよくすることはあっても、組んでおいたものより悪くなるに任せることはない。
直したあとは、どこまで回し直すのか。回し直す必要があるのは、その工程の結果に寄りかかっていた後ろの作業だけだ。レポートの例なら、分析に依存していたレポート作成だけが回り直す。その外側ですでに終わっていた資料収集は、そのまま再利用する。一度直すコストが、全体ではなく影響を受けた範囲の分だけに収まること — これが、家を建て直さずに漏れているところだけを直すという言葉の、実際の姿だ。
いよいよ数字だ。著者たちは、まず測定の道具から手を入れた。複数のAIが分業するワークフローをまともに測るには、それに合わせて組まれた課題が要る。そこで公開データセットに手を加え、新しいベンチマーク(性能測定用の標準問題集)Braidを別途こしらえた。課題ごとに資料が複数ついてくるのだが、資料どうしの中身が重ならないこと、正解があらかじめ漏れていないこと、質問に本当に合う資料が入っていることという品質基準を掛けて、ふるい落とした。
核心の比較は一つだ。ベースとなるモデルと試行回数をそろえたまま、構成・修正のやり方だけを変えたとき、正確度がどう変わるか。論文が前面に出した代表値は、単一エージェント(AI一つで解くやり方)比で最大11.97%ポイント、ワークフローの基準線比で最大9.64%ポイントだ。ここでいう「最大」は、複数のバックボーン(土台となるAIモデル)と系統を通じていちばん高かった値であって、ある一つのモデルの代表成績ではない。そしてこの9.64%ポイントは「ワークフローをどう組むか」全体が生んだ最大の向上幅であって、「実行中の修正」という一つの仕掛けだけを切り出した独立の効果ではない点に注意しよう — その取り分は、すぐ下の表で別に姿を現す。
もっと多くを語ってくれるのは、モジュールを一つずつ積み上げながら測った表だ。ベースとなるモデルはQwen3.5-9B、5つのドメイン(分野)の平均である。
| 構成の仕方 | 正確度(%) | 単一エージェント比(%ポイント) |
|---|---|---|
| Single agent | 17.38 | — |
| greedy-search | 15.49 | -1.89 |
| Coalesce(コスト基準の分割) | 22.21 | +4.83 |
| Coalesce + フロー中の修正 | 23.80 | +6.42 |
| InFlowOp(全体) | 25.13 | +7.75 |
読む順番が大事だ。一人でやるとき(17.38)が出発点だ。スコアをもとに割ったCoalesceは、そこから+4.83%ポイント跳ね上がる — 表のなかでいちばん大きな一マスだ。なぜかは、そのすぐ上の行が語ってくれる。同じように割っても、目先で良さそうに見えるほうばかりをつまんで割るgreedy-search(貪欲な分割)は、一人でやるときよりかえって1.89%ポイント低かったのだから。だから、割ること自体が得を保証するわけではない。得は「どう」割るかから来る。
その次が、この論文の本当のどんでん返しだ。うまく組んでおいた設計の上に修正を加えたとき、積み増した取り分はそれより小さかった。実行の流れのなかの修正が約+1.6%ポイント(表の23.80 − 22.21)、各AIが実行経験を積んで自ら能力記録を更新する仕掛けがさらに約+1.3%ポイント。二つを合わせても、最初にうまく割った一手(+4.83%ポイント)に及ばない。ずれたものをうまく直す腕前よりも、そもそもうまく割る設計のほうがずっと得だということだ。前で耳打ちした「もっと大事な問い」の答えが、まさにこれだ。
規模を飛び越える場面もある。小さなQwen3.5-4BにInFlowOpを着せると、5つのドメイン平均20.81に届く。より大きなQwen3.5-9B(17.38)やGPT-5-mini(16.33)、GPT-5.4-mini(17.49)をそのまま一人で回したときを、すべて上回る値だ。小さなモデルも良い設計を着れば、大きなモデルの拙い使い方を超えるという話だ。いちばん強いベースモデルでも流れは同じ。一人で回した41.99から49.37へと上がる。
ここで一つ、誤解を先に防いでおこう。この表の数字はすべて「正確度」だ。お金や時間が減ったという証明ではない。このスコアをそのまま「コスト削減」と読むと、三重の落とし穴にはまる。まず、このスコアは相対比較用に作ったBraidの上でだけ測った値なので、特定のサービスの実際の支出を絶対値で語ってはくれない。また、修正が正確度を+1.6%ポイント上げたからといって、その修正にかかった実際のコストがそれだけ安かったという意味でもない。表が測っているのは、あくまで正確度の上昇分だ。最後に、遅延をスコアに入れたからといって、その値が壁掛け時計で測った秒だという保証もない(測定の仕方の細部は原文の付録にある)。要するにこの表は「いくら節約したか」ではなく「どの設計がより賢いか」に答える表なのだ。
限界もはっきりしている。得はチャート・数学・金融で大きく、物理でいちばん小さい。物理は、どのモデル、どの方法を使っても低いところにとどまる。協調設計をもってしても越えられない、ベースモデルの推論力そのものが壁になる領域があるという信号だ。全体が正解表なしのスコアの上に立っているという事実も諸刃だ。約束をいいかげんに書いておくと、間違った工程を通してしまったり、問題のない工程を止めてしまったりする。スコアの計算もAIが自ら申告した能力に頼る分、その宣言が誇張されれば、天秤全体が楽観のほうへ傾く。
ONTLEは顧客プロジェクトごとにAI PM(プロジェクトマネージャー)を付け、受付から完了まで引っ張っていく。だから「greedyが一人でやるときより低かった」というあの一行が、他人事ではない。PMがリクエストを細かく割ること自体を美徳としてしまえば、調整のコストが増えるだけだ。割る基準は、いつでも「適合度に対する実行コスト」でなければならない。
InFlowOpの枠組みをONTLEに重ねるなら、変わるのは修正手続きのいくつかではなく、PMの仕事そのものだ。これまで、価格レポートの分析表がずれたとき、ONTLEのPMが取れる道は二つしかなかった。最初からやり直すか(進捗の破棄)、人が割って入って全体を直すか。どちらの道も、結局は人がワークフローを組み直すという意味だ。
この枠組みが入ってくると、「ワークフローをどう組み直すか」という判断をシステムが引き受ける。すると、PMの重心が移る。個々のタスク一つ一つの品質を守る監視役から、プロジェクト全体の目標がきちんと達成されるかを見る企画者へと。顧客に約束できることも変わる — 「間違ったら人が付いて直します」ではなく、「ずれた断片だけをシステムが自動で巻き戻してやり直します」になる。巻き戻している間も、顧客の画面には相変わらず「進行中」と「完了」だけが見えていて、先に終わった資料収集のような工程はそのまま生きている。入力が脆くて工程を割り直さなければならないときは、作業地図の上でノード(地図の上の点一つ、つまり一工程)が複数の下位ノードへと枝分かれしていく、という具合だ。
ただしこれは、いまONTLEに組み込まれている機能ではなく、この論文が指し示す方向だ。ONTLEが次にどこへ向かうかを照らす一行、というわけだ。
著者たちもそのやり方を併せて実験したが、求める項目を基準表に置いて「計算する」ほうが、AIに適合度を「判断」させるほうより良かった。人でもモデルでも「どれだけうまく合いそうか」を目分量で付けると揺れる。満たすべき項目を釘で打ち込んでおき、満たしたかどうかを数えるほうが安定していたということだ。
いや。別途の学習も、追加の正解データも要らない2段階の枠組みだ。前提は一つだけ — 各工程に入力・出力の条件を約束として宣言しておくことだ。
公開データセット10個に手を加えて14個に再構成し、8つのドメインにわたって19の評価系統で組まれている。各課題は二つの複雑度と二つの構成の仕方で組み立てられ、四つの品質基準を掛けて、一つでも通らなければ課題として使わなかった。四つの品質基準は、資料どうしの中身が重ならないように、正解があらかじめ漏れないように、質問に合う資料がきちんと入るようにするための仕掛けだ。