LLMエージェントはなぜ遅いのか。大きな理由の一つは、次に取る行動を毎回、文字を一つずつ生成して決めているからだ。ここでいうトークンとは、モデルが文章を扱うときの最小単位を指す。エージェントが「上に一マス」と決める瞬間にも、そのわずか数文字を一から生成している。「下に一マス」も、「左に一マス」も同じだ。JevSpawnは、まさにこの行動を生成するコストに狙いを定める。
よく考えると奇妙な無駄だ。エージェントが天秤にかける候補の行動は、たいてい形は同じで値がいくつか違うだけである。方向が一つ、数字が一つ。それなのに毎回、文全体を一から書き直している。だとすれば、共有される枠は固定しておき、変わるマスだけを決まった候補の中から選べばいいのではないか。文章を生成するのではなく、選択肢の中から確率で選ぶ方へ切り替えるわけだ。
この発想自体は新しくない。「Jev系モデル」が先にやっている。論文が比較対象に据えたTypeSafe Jevは、質問に文章で答えるのではなく、決められた選択肢それぞれに確率を割り当ててすぐに返す。有限の選択肢の上で選ぶから速い。問題は、その選択肢リストをアプリケーション側があらかじめ用意して渡さなければならない点だ。自律エージェントにとってこれは致命的である。何ができるのかは自然言語の指示からその都度読み取らねばならず、新しい観測が入るたびに変わってしまうからだ。
そこで、本当に難しい問題はこう絞られる。有限選択の速さを保ちながら、その行動リストがやり取りの途中で変えられるようにすること。 JevSpawnが解いたのはこの一点だ。
解法を一文に縮めると、行動の空欄(フィールド)を方策の一部に取り込んだ、ということだ。方策とは、エージェントが次の行動を選ぶ規則のことを指す。あらかじめ受け取って使うのではなく、モデルがタスクの説明を見てその空欄を自ら宣言し、フィードバックを受けて直していく。
厨房にたとえると違いがはっきりする。TypeSafe Jevは「辛口/甘口のどちらか選んでください」という注文票を客があらかじめ作って渡さないと働けないシェフだ。速いが、注文票がなければ何もできない。JevSpawnは「冷蔵庫を開けて、作れる選択肢は自分で組み立てろ」と任されたシェフだ。タスクの指示とやり取りの規則を読み、空欄の名前と意味、そして直前の選択に応じて許される有限の値を自ら宣言する。空欄をすべて埋めれば、それがそのまま実行可能な行動一つになる。
このシェフを支える仕掛けが四つある。
一つ目、並列スポーニング。 一つの状態から複数の行動候補を一度に展開する。どの組み合わせから見るかは結合確率、つまり複数の選択が同時に起こる可能性が導く。論文の設定では、親を一つ選んで異なる行動を最大四つまで展開する。
二つ目、フィードバックに基づく分岐選択。 各候補を親環境の独立したコピー上で一度実行してみる。そこで得た観測を見て分岐のスコアを付け直す。やってみてから考えを変えられる、ということだ。
三つ目、表現の修正。 積み上がったフィードバックを見て宣言そのものを書き直す。可能な行動のリストがやり取りの最中に変わる——あらかじめ固定された空欄に縛られる従来のJev系モデルと分かれる、まさにその地点だ。
四つ目、保存した分岐からの復旧。 行き止まりに追い込まれても最初から歩き直さない。先ほどの分かれ道で選ばず畳んでおいた別の道に戻り、その地点から再び進む。先に辿った経路を生成し直すコストを節約する。
ここで一つ、はっきりさせておこう。追加の学習はない。事前学習済みのパラメータはそのまま使う。宣言を新しく組んだり直したり、最終的な答えを出すときだけテキストを生成し、反復的な探索は有限の方策で回る。
速さの秘訣は二つの「共有」にある。
一つは行動構造の共有だ。完全な記述を毎回書き直さず、欠けたマスだけを埋める。前の段落で見たとおりである。
もう一つは接頭辞(プレフィックス)の共有だ。接頭辞とは、複数の候補が共に使う前半の文脈のこと。いくつもの童話がすべて「むかしむかし」で始まるなら、その導入部を一度だけ読んでおき、後に続く部分だけを変えて読むのと同じだ。候補ごとに共通の前半を計算し直さないので、処理する入力トークンが「毎回接頭辞を含める」コストから「接頭辞を一度だけ処理する」コストへと下がる。
比較は統制された条件で行われた。方策モデルはQwen3.8-27B一つに固定した。JevSpawnも、競合した七つのベースラインも、すべて同じモデルを使った。温度0、シード42で乱数性を取り除き、全体の予算は300秒に縛った。だからこれは「どの手法が絶対的に速いか」ではなく、同じ条件下での相対比較である。
競合相手のアプローチは大きく三つに分かれる。モデルをいつどこで呼ぶかを減らす側(呼び出しの組織化)、ステップ間でやり取りする情報量を減らす側(情報の削減)、出力生成の速度そのものを上げる側(デコード高速化)。JevSpawnはこの三つとは別の軸——行動生成そのもの——を狙う。ただし「行動を生成せずに選ぶ」という発想が初めてなわけではない。先に見たTypeSafe Jevの有限選択や、決定的な生成経路を飛ばすSGLangのような先行技術も論文は土台として挙げている。JevSpawnの貢献は、このアイデアを適応的な行動空間と分岐探索に結びつけ、そのリストがやり取りの途中で変わるようにした点にある。
結果を読むときは一つだけ注意すればいい。タスクごとに測る単位が違う。経路探索系は成功率(0〜1)を使い、パズルや数値ゲームはベンチマークの報酬やスコアを使う。0.96と305.12を並べて比べてはいけない。
もっとも興味深い結果がここにある。普通はスコアを上げれば時間が増える。ところがナビゲーションの二つのタスクでは、どちらも良くなった。
| タスク(成功率) | JevSpawn | 最良ベースライン | 遅延: JevSpawn / 最速ベースライン |
|---|---|---|---|
| Maze | 0.96 | FoldAgent 0.52 | 40.91秒 / 47.91秒 |
| Grid | 0.95 | FoldAgent 0.73 | 40.58秒 / 61.44秒 |
遅延はリクエストから最終応答までにかかった全体時間(E2E)だ。Mazeは0.52から0.96へほぼ二倍、Gridは0.73から0.95へ約1.3倍上がった。スコアが大きく跳ね上がるのに時間はむしろ短い。品質と速度はたいてい引き換えにしなければならない二つの指標だ——一方をもっと得るには他方を諦めねばならない関係で、その最善の縁をパレート境界と呼ぶ。ところがこの二つのタスクでは、JevSpawnがそのトレードオフを破って両方を同時に手に入れた。品質と速度の両方でより優れた手法が事実上存在しない、という意味だ。
反対側の結果もある。LightsOutの報酬は0.61でAgentPruneの0.34を上回り、Nullifyは0.21でHiAgent・FoldAgentの0.09を、2048は305.12点でLLMCompilerの5.00を大きく引き離す。ただし2048の遅延は169.94秒で、最速の33.51秒よりかなり長い。スコアを得る代償に時間を払った領域だ。
そして、すべてのタスクで勝ったわけではない。AgentPruneはPPNL・RushHour・Sokobanで依然として最も強い。SokobanでのJevSpawnのパレート境界への帰属は不安定で、これはLLMCompilerより1.50秒速い(122.49秒対123.99秒)ものの、スコアは低い(0.150対0.350)という状況、つまり速度と品質が相反する立場を反映した結果だと論文が自ら明かしている。
構造はそのままに、有限採点の部分だけを外部のTypeSafe Jev APIに差し替えた変種も回してみた。結果はまちまちだ。外部API変種は一部のタスクでQwenの自前採点を上回るが、別のタスクでは下回る。しかもAPI通信まで含めると自前採点の1.4〜2.1倍の時間がかかる。外部インターフェースが品質で常に有利なわけでもなく、速度ではむしろ損だ、という話である。
スループット(prefillを除いた純粋な生成速度)では、PPNL 544.35、LightsOut 580.05で表中の最高値を記録する。prefillとは、モデルが答えを出す前に入力文脈を一度に読み込む準備段階のことだ。面白いのは、MazeとGridのテキストスループットがN/Aと記されている点だ。遅いからではない。この二つのタスクは最初から最後まで有限評価だけで回り、テキストをほとんど生成しない。数字より「どこでテキスト生成を丸ごと取り除いたか」が肝心だ。経路探索で速度が爆発した理由もここにある。
このあたりで正直な絵が必要だ。JevSpawnには、オンオフするだけで済む普遍的なスイッチはない。良い設定値がタスクごとに正反対に裏返る。使える技術かどうかは、この「裏返り」を自分のタスクに合わせて調律できるかにかかっている。
探索幅は諸刃の剣だ。 幅とは一度に何本の枝を展開するかを指す。幅を1に狭めるとMazeの成功率は0.16、Gridは0.58まで落ち込む。だからもっと広げたくなる。ところが幅を10に増やすと、Mazeはすべて解ける代わりに、Nullifyの報酬が半分に削られ、RushHourの遅延が二倍になる。広い探索がタスクによっては毒になる。
同じ予算でも、どう分けるかで結果が裏返る。 以下は行動四つ分の予算を「親の数 × 親あたりの行動数」で違えて分けてみたものだ。
| 配分 | Maze | Grid |
|---|---|---|
| 1 × 4 | 0.88 | 0.94 |
| 2 × 2 | 1.00 | 1.00 |
| 4 × 1 | 0.12 | 0.75 |
Mazeは2×2で完璧に解け、4×1で崩れる。ところがまさにその4×1という極端な配分が、2048のスコアはむしろ上げる。公式がタスクごとに違うことを、これ以上うまく示すのは難しい。
宣言を固定するか書き直すか、観測を分岐の中に閉じ込めるか分岐同士で共有するかも、すべてタスク次第だ。ただしその混乱のなかに一つ、一貫した信号がある。観測を分岐同士で共有すると、スコアはタスクごとに分かれても、八つのタスク全てで遅延が下がった。付けておく価値のあるデフォルトが一つ、ここにあるわけだ。
時間予算とラウンド数は正面からぶつかる。 探索ラウンドを36から108に増やすと、2048のスコアは315.16から1102.24へ跳ね上がる。長く考えるほどうまく解く。ところが300秒の締め切りをかけると、108ラウンドでは2048タスクの85パーセントがタイムアウトする。より深い思考が現実の遅延予算と衝突する。
最後に、この手法の根底に敷かれた前提。「行動が形を共有し、値が有限である」ということだ。論文のタスクは格子移動・パズル・数値ゲームなので、この前提がよく当てはまる。行動が開かれた自然言語(自由記述、コード作成)だったり、引数空間が事実上無限のタスクでも同じ利得が出るかは、この実験だけでは断定しにくい。すべての結果がQwen3.8-27Bという一つのモデルから出ている点も、一般化の宿題として残る。
こうした条件を丹念に吟味するのは、この技術を自分たちのサービスに現実的にどう当てるかを見極めるためだ。具体的な場面を一つ、最後まで追ってみよう。
顧客が進行中のプロジェクトで納期を前倒ししてほしいと要請した。AI PMは次の一手を決めねばならない。変わった日程に合わせて収集作業をやり直すか、影響を受ける成果物のリストを先に洗い出すか、顧客に縮小する範囲を問い返すか、社内の担当に再配置を知らせるか。いまの構造では、この判断を長い推論テキストで一度長々と生成して下す。遅いし、一度選んだ道を押し通して食い違うと、戻すコストが大きい。
この場面にJevSpawnの枠を当ててみると、変わる地点がはっきりする。PMの「次の一手」は実のところ、形が繰り返される有限の行動だ。対象(どの作業・どの成果物)、動作(再収集・リスト化・問い合わせ・通知)、受信者のように、いくつかのマスに分解される。毎回自然言語で長々と書く代わりに、これらのマスの候補を宣言して有限の確率で選べば、同じ決定をより軽く下す余地が生まれる。ONTLEがすでに使っている狭いアクションツール——言葉と行動が一致し、サーバーが決定論的に実行する設計——が、「形を共有し、値が有限である行動」の定義にそのまま当てはまる。
とはいえ論文をそのまま持ち込むことはできない。引っかかるのは二つ目の仕掛け、分岐シミュレーションだ。「候補を独立したコピー上で実行してみて選ぶ」という前提は、その実行に副作用がなく、巻き戻せるときにだけ成り立つ。格子移動はコピー上で何度でもタダで回せる。だがPMの実際の行動の多く——外部連携の呼び出し、顧客に出す問い合わせ——は副作用があって、軽く試すわけにいかない。コピー上で顧客にメールを四回送ってみる、などできるはずもない。だからこの構造は、収集結果のプレビューや内部の状態遷移のような巻き戻せる行動にまず当て、副作用のある行動は依然として承認ゲートを通す、というのが筋だ。
ここで一歩引いてみると、この論文が指し示す方向は業界の大きな流れと通じている。初期には推論から行動まですべてをLLMの自由生成に委ねていた。JevSpawnはその潮流から一歩引き、巻き戻せる決定論的な行動は有限選択で、開かれた生成が必要な部分はテキスト生成で分離する。ONTLE流の適用も同じハイブリッドだ。次の一手を選ぶ決定は有限の方策で、顧客に送る文章はテキスト生成で。
ただし一つだけ線を引いておくべきだ。「有限の方策のほうが安い」というのは格子・パズルのタスクから出た結論であって、自分たちのタスクで保証された事実ではない。だから適用の第一段階は拡張ではなく測定であるべきだ。提案はこうだ。
この小さな比較で時間と成功率が実際に良くなったときに初めて、先の実験の数字が自分たちの実務の判断へと移ってくる。それまで「より安い」という言葉は仮説であって結論ではない。
そのまま保証されるわけではない。論文の数字は乱数性を取り除いて手法そのものだけを比較するために統制した値だ。運用では温度・モデル・入力が毎回異なるので、サービスに載せる前に自分の環境で測り直すのが筋だ。
もっともな指摘だ。並列に枝を展開するのは、より多くの計算を壁時計時間の中へ畳み込む方式だ。論文がH100 4枚固定の条件で全体の遅延として測った点を覚えておかねばならない。使えるハードウェアが逼迫していれば、幅を広げたときの遅延の利得が減りうる。
アブストラクトにGitHubのアドレス(https://github.com/Hoyant-Su/JevSpawn)が公開されている。詳細な実装と再現は、当該リポジトリと論文の付録を参照すればよい。