複雑な仕事をまるごと一つのAIに丸投げすると、手に余ることが多い。だから役割を分ける。依頼を読み解くAI、手順を設計するAI、コードを書くAI、検査するAIを鎖のようにつなぐ。こうして組み上げた作業の流れを、マルチエージェントのワークフローと呼ぶ。
問題は、このチームを「学習でもっと上手に」しようとするときに起きる。優秀な社員を何人も採用したのに成果が出ない会社を思い浮かべてほしい。たいていは人手が足りないからではない。誰が何に責任を負うのか、うまくやった人にどう報酬が返るのか、それがないからだ。AIのワークフローもまったく同じである。
ところが業界の学習手法は、一方向に偏っていた。仕事の順序と役割を組み立てる「設計者」(論文の用語で生成器、Generator)だけを教え、その設計どおりに実際に手を動かす残りの役割は、最初の実力のまま放置していた。料理の成否が総料理長ひとりの責任ではないのに、ずっとそうしてきたのだ。
FloWrightはこの非対称を壊す。一度の実行で残ったそのログを採点するだけで、設計者だろうと実務者だろうと区別なく、役割ごとの責任を同じ信号として分け合う。責任を見極めるために追加のモデルも、人が手で付けた正解表も、ワークフローを別途また走らせることもなしに。こうしてタダで得た信号で、すべての役割をまとめて学習させる — 学習そのものは、課題ごとに何度も実行(ロールアウト)して方策を繰り返し更新する強化学習だ。その結果、小さな4Bモデルで学習前と比べて平均+5.03%ポイントの向上が得られた(複数の役割を同時に鍛えたとき)。
いちばん面白いのは数字ではなく、やり方だ。実行ログに現れた失敗を、タダで役割ごとに切り分ける方法である。
マルチエージェントのワークフローを厨房にたとえてみよう。食材の下ごしらえ、火加減、盛り付けをそれぞれ受け持ち、客は仕上がった一皿だけで評価する。料理がまずく出てきた。ここで本当に難しい問いが出てくる。誰が味付けを誤ったのか? 完成品だけを舐めていては、永遠にわからない。
ワークフローはノードとエッジでつながれたグラフだ。ノードは仕事をする地点(エージェント・ツール・スキル)、エッジはその間を流れるデータと制御である。FloWrightはこのグラフを、厨房の採点装置として使う。論文ではこれを測定装置(harness)と呼ぶが、ワークフローを最後まで走らせて答えを出させ、その答えを採点する審査システムだと思えばいい。ここから出た一つのスコアが、評価指標にもなり、学習信号にもなり、後で説明するテスト時点の最適化の目標にもなる。この三つを一つの装置からくみ上げるのだ。
肝は、失敗をさかのぼるやり方にある。測定装置は、料理がどの工程をどの順序で通ったかを、調理過程の映像のようにログとして残す。このログが実行トレース(execution trace)、文字どおり「誰が何をしたか」の足跡だ。そして各役割には、自分が「著作した」ノードがある。設計者は自分が描き配線したすべてのノード、実行役割は自分が直接動かしたエージェントノードである。
具体的な一場面で追ってみよう。ある課題で一つのノードが実行中にエラーを出して止まり、その後ろにぶら下がったノードたちも入力を受け取れず、次々と崩れていった。最終的な答えが間違っていた。このとき測定装置は、トレースに残った失敗ノードとその依存関係をたどり、後ろで巻き添えに崩れた連鎖的な失敗は責任から外し、最初に踏み外したノードだけに責任を負わせる。そのノードを設計者が配線したなら設計者に、実行役割が動かしたノードなら実行役割に行く。片方にすべてを押しつけず、それぞれが著作したノードの範囲の中だけで分けて問う。これが「構造を知る報酬(structure-aware credit)」だ。
ただし、この規則が指し示せるのは、あくまで実行ログに「失敗ノード」として現れた誤りだけである。ノードがエラーなく動いたのに結果が間違っていたり、要件を一行取りこぼしたように、失敗として現れなかった誤りは、この装置では見分けられず、後で説明する階層型報酬の大域的な信号(答えがどれだけ正しいか)に委ねる。一つの役割が著作したノードが他の役割と重なる区間でも、責任はきれいには切り分けられない。だから「間違ったところをすべて自動で突き止める」ではなく、「現れた失敗を役割ごとに分ける」が正確だ。
ここで決定的な節約が生まれる。その調理過程の映像は、測定装置が採点する過程ですでに残したものだ。責任を見極めるために別の審判モデルや報酬モデルを付けたり、人が注釈を付けたり、ワークフローを何度も走らせ直したりする必要がない。既存の研究は責任の所在を見極めるためにまさにそうした追加コストを注ぎ込み、それでいてとんちんかんな場所に責任を回すことがあった。FloWrightは、すでにある足跡を読むだけである。
二つ目の装置は、「どこまで上がれたか」を測る階層型報酬(hierarchical reward)だ。結果を合格/不合格につぶしてしまわず、はしごのように段を積む。出力が形式に沿って読めるか、その寄与が有効か、ワークフローが最後まで走って答えを出すか、その答えがどれだけ正しいか。ここに先ほどの構造ベースの責任が五段目として加わる。おかげで料理が途中でひっくり返っても、「三段目までは上がれた」という信号が残る。0点の沈黙の代わりに、方向を指し示すフィードバックだ。各段の重みは役割ごとに違えて置く。
この二つの装置が敷かれると、同じ測定装置一つから、どの役割であれ自分の取り分の報酬を取り出して使える。だから学習の範囲を広げられる。役割一つだけを自ら発展させることも、エージェントとスキルをともに、設計する上流と実行する下流をともに、あるいは複数のエージェントを同時に鍛えることもできる。
複数をともに鍛えると、面白いことが起きる。一つの役割が良くなると、別の役割が向き合う状況そのものが変わる。下ごしらえ担当の腕が上がれば、火加減担当は前より揃った食材を受け取り、新しい水準で練習することになる。互いが互いの練習問題集になるのだ。論文はこれを互いのカリキュラム(mutual curriculum)と呼ぶ。
学習は二つの時点に分かれる。訓練時点には、強化学習でモデルの重みそのものを変える。テスト時点には、重みに手を付けず、再利用できる事前知識を蒸留(distillation)する。蒸留とは、うまく解けた経験を短い参考資料に要約しておくことだ。成功した料理のレシピをカードに残し、次のチームが参考にできるようにするようなものである。自分の経験から取ることもあれば、より強い教師モデルから取ることも、両方を使うこともある。
まともに評価するには、まともな問題集が必要だった。マルチエージェントのワークフローは、これまで単一の質問の数学や、関数一つきりのコーディングのように、エージェント一つでも解ける データで評価されてきた。そんな易しい問題では、測り直してみても大勢が取りかかった利点がほとんど現れない。ワークフローが一人より何を多くこなすのかが見えないのだ。
そこでDataWrightが登場する。既存のデータセットをより難しく手直しし、複数の下位質問を束ねる形で「ワークフローが必ず必要な」課題に変える。採点の方式はそのままに、難易度だけを引き上げる。
訓練はQwen3.5系の4B・9Bモデルで、四つのデータセットで回した。評価ははるかに広く張った。二つのオープンソースモデルに加えてクローズドなモデルまで、すべて学習に使っていないテストセット(held-out)で測った。一つの役割が他の役割と異なるサイズのモデルを使ってもよいので、小さな上流に大きな下流、その逆の組み合わせまで見た。
評価紙は三つの区域だ。訓練に使った条件(in-distribution)、同じデータセットだが訓練が見ていない戦略・難易度(out-of-distribution)、そもそも訓練に使っていないデータセット(out-of-domain)。この設計が測ろうとするものははっきりしている。「学んだ条件で上手にやれるか」ではなく、「見たことのない戦略・難易度・ドメインへどれだけ広がるか」だ。逆に、この表が測れないものもはっきりしている。実際のサービストラフィック、リアルタイムのコストと遅延、人間ユーザーとのやり取りは、ここにはない。
まず目を引くのは、学習を始める前である。小さな4Bモデルでも、FloWrightの構造でワークフローを組んで回すだけで、ツールを握った単一エージェントを大きく引き離した(32.09 対 20.70)。一人で頭をひねるより、仕事をうまく組織するほうが良いということだ。小さなモデルほど、なおさらそうである。
| 設定 (Qwen3.5-4B) | 全体精度(%) |
|---|---|
| 単一エージェント(ツール・スキルなし) | 7.42 |
| 単一エージェント(ツール・スキルあり) | 20.70 |
| FloWright(学習前) | 32.09 |
| + 単一役割の自己進化 | 34.92 |
| + 上流-下流の共進化 | 35.15 |
| + エージェント-スキルの共進化 | 36.15 |
| + 複数エージェントの共進化 | 37.12 |
さらに重要なのは方向だ。ともに鍛える役割が多いほど、向上が大きくなった。役割一つだけを学習させると+2.83%ポイント、上流と下流をともに鍛えると+3.06%ポイント、エージェントとスキルをともに鍛えると+4.06%ポイント。その果て、複数のエージェントを同時に鍛えた場合がもっとも大きかった(表の最下段)。そしてこの複数共進化は、三つの区域すべてで、あらゆるデータセット・戦略・難易度でプラスを守った。たまたま一つの条件だけで上がったのではない、ということだ。
ここで要旨の「最大+7.41%ポイント」を正しい位置に置こう。この数字は全体平均ではない。特定の条件一つのマス(39.32 対 31.91)でもっとも大きく上がった値なので、平均の向上とは区別して見なければならない。
小さなモデルで仕上げた役割が、大きなモデルと混ざってもその利得が生き残る効果も現れた。4Bで最適化した役割は4Bのままにして残りだけを9Bで回す混合の組み合わせに差し込むと、その利得がついてきて、すべて9Bで回した基準線より精度がさらに上がることもあった。小さなモデルの学習内容を大きなモデルに移し植えるのではなく、安く仕上げた小さな役割をそのままにして、他の役割に大きなモデルを付ける道が開けたわけだ。9B単独でも方向は同じで、学習前の47.50%が単一役割の自己進化で51.39%(+3.89%ポイント)になった。
重みに手を付けないテスト時点の最適化も効果を出した。ただし目を留めるべき点がある。成功事例を例として要約する方式は、事例を五つ与えたときにもっとも大きな利得を出した一方、一つだけ与えたときはむしろ学習前より低かった。事例一つでは一般化する根拠が足りず、証拠がある程度積み上がってはじめて参考資料が役立つ、という話である。
最後に目盛りを一つ。絶対精度が7〜50%台と低い。易しいベンチマークではなく、DataWrightでわざと難しくした課題だからだ。この数字たちは「上手に解くAI」ではなく、「ワークフローが一人より何を足すのか」を測る物差しである。
一場面に絞ってみよう。顧客が「在庫管理ダッシュボードを作ってほしい」と依頼する。ONTLEのAI PMはこれを受付→分析→設計→開発→QAに切り分け、各段階に専門の役割を割り当てる。依頼を切り分けるPMがFloWrightの上流なら、分析・設計・開発・QAを実際にこなす役割たちが下流だ。
このパイプラインを改善するとき、手を付けやすいのはPMの分解ロジック、つまり上流である。FloWrightが言うのは、そこで止まるなということだ。依頼をうまく切り分けるPMだけを仕上げて実行役割を固定しておくと、全体が良くなる余地が構造的にふさがれる。上の事例で、分析担当が「在庫しきい値アラート」という要件を一行取りこぼし、プロジェクトが開発段階で座り込んだとしよう。これはPMが仕事を切り分け損ねたからではなく、分析役割が踏み外したのだ。PMだけ手を入れても、同じ失敗が繰り返される。
ここで構造ベースの責任が入ってくる。ONTLEはすでに作業の流れをgitグラフの形(レール・ノード・parent_id)で残し、実行トレースを保管している。だが記録があるという事実だけで、役割ごとの責任が自ずと切り分けられるわけではない。もう二つが必要だ。「各ノードをどの役割が著作したか」を知ること、そして実行ログの失敗ノードとその依存関係をたどり、連鎖的な失敗は取り除いて最初に踏み外したノードを指す規則である。この二つがあってはじめて、完了スコア一つを分析・設計・開発・QAの役割ごとのフィードバックに切り分けられる。
ただし、原論文が引く線はONTLEにもそのまま引き写さなければならない。こうして役割ごとに切り分けられるのは、実行ログに「失敗」として現れたノードだけだ。上の事例の「在庫しきい値アラート」の欠落のように、ノードがきちんと動いたのに要件を一行取りこぼした誤りは、失敗ノードとしては捕まらず、この規則だけでは分析役割に自動では刺さらない。そうした取り分は、プロジェクト全体の結果で付ける大域的な報酬が引き受け、ノードの著作が役割間で重なる区間でも、責任はきれいには切り分けられない。
はしご型の報酬もそのまま引き写して使える。プロジェクトが完了に至らなくても、「要件のパースはでき、設計まで有効だったが開発の実行で止まった」というように、どこまで行けたかを段として残せば、次の分解と割り当てがその地点を避けて通るように手を入れられる。ただしはっきりさせておこう。これはONTLEに移植できる設計上の示唆であって、いま実装されているという意味ではない。
著者ら自身が明かす前提がある。in-distribution区域は、訓練に使った難易度を評価にも使いつつ特定の水準だけを抜き出した構造なので、その成績は「訓練分布の中の成績」だ。
私が見るに、残る問いはこうだ。訓練のバックボーンがQwen3.5系に偏っており、評価は広いが訓練は四つのデータセットという比較的狭い地点から出発している。共進化が良いという結論は明らかだが、役割の数を増やすときの学習コストや収束の難しさといった運用観点のトレードオフは、この表だけで判断するのは早い。ベンチマーク精度という一つの軸しか見ていない点も覚えておくべきだ。実際のサービスで劣らず重要なコスト・遅延・安定性は、別の物差しで測らなければならない。
より良いワークフローを生み出すには、ワークフロー全体が必要だという意味です。設計者一人を取り替えるのではなく、組み立てて実行する役割たちが、互いを練習問題のように押し上げながらともに進化しなければならない、というこの研究の主張をタイトルに込めたものです。
違います。FloWrightはすべての役割をともに学習させる手法のほうで、DataWrightはその手法をきちんと評価できるように、易しいデータセットを「ワークフローが必要な」難しい課題に変える問題集生成のほうです。手法と評価環境、という二つの軸で分けて見ればよいでしょう。
学習はモデルが小さいほど回すのが安く速いです。一つの役割を小さな4Bモデルで仕上げたあと、その役割は4Bのまま実行し、残りの役割だけを大きな9Bモデルで回す混合構成が可能です。小さなモデルの学習内容を大きなモデルに移し植えるのではなく、安く学習させた小さな役割をそのまま使いながら、他の役割に大きなモデルを付けるということです。この研究で、そう組んだ混合の組み合わせが、すべて大きなモデルだけで組んだ基準線を追い抜いた事例が出たことが、その可能性を示しています。
論文はarXivに、要約と議論はHuggingFaceに上がっており、著者らが運営するプロジェクトページが要旨に明記されています。下の参考資料のリンクから始めればよいでしょう。