エージェントを動かしていて体感的に一番もったいないのが、ツールの結果が返ってくるのを待つ時間だ。LLMが考え、検索なりコード実行なりのツールを呼び、結果が戻るまでGPUはただ待機する。推論・行動・観測(Thought-Action-Observation)を1手ずつ順番に回すこのループは素直で分かりやすいが、待ちの間、手元の計算資源はきれいに遊んでいる。バッチを詰めていない対話的なエージェントほど、この空転が効いてくる。

SPORK(Self-Speculative Forking)は、その空転を「推論そのものを止めずに」埋めにいく手法だ。追加学習も補助モデルもなく、標準のcompletion APIの上に薄いコントローラを載せるだけで動く。7月3日にarXivへ出た論文とコードがあり、Qwen3系での実測が載っている。

そもそもどれだけ待っているのか

論文がまず測るのは、この待ち時間の実測値だ。著者らのワークロードでは、ツール結果の待機がウォールタイム全体の16〜37%を占める(内訳はエンタープライズDB系16%、実Web検索19%、検索+ページ閲覧37%)。この「ツール待ちが無視できない比率を占める」という観察は著者らの独自発見ではなく、同時期の別チームも裏付けている。PASTE(arXiv:2603.18897)は同じ問題設定で、ツール実行がリクエスト全体の35〜61%を占めると報告しており、SPORKが引くのもこの数字だ。数字の幅が広いのはベンチとタスク種別の違いによるもので、少なくとも「最悪ケースではGPUの半分以上が結果待ちで止まりうる」という桁感は複数の一次ソースで一致している。

トークンを速く吐く工夫(いわゆる投機的デコード)はこの数年でかなり成熟したが、そちらが削るのは「1トークンあたりの生成コスト」であって、ツールの往復待ちには手が届かない。この往復待ちを狙う研究は2026年に入って一気に増えており、非同期I/Oで重ねるSpeculative Interaction Agents(arXiv:2605.13360)や、ツールスキーマを使ってドラフトを組むToolSpec(arXiv:2604.13519)などアプローチは分かれる。SPORKが狙うのは生成とツール実行のあいだにある構造的な直列性で、トークン級の投機的デコードとはレイヤーが違うため競合せず併用できる。

鍵になる観察は「モデルは自分が次に何を呼ぶか、早い段階で知っている」

面白いのはここだ。生成のごく序盤でモデルの状態をフォーク(複製)し、ツール呼び出しの書き出しだけを強制的に続けさせると、実際に呼ぶツール名をかなりの精度で当てられる。Qwen3-32Bで測った、生成開始時点(fork-at-start)でのツール名予測精度がこれだ。

ベンチマーク	ツール名の予測精度(生成開始時点)
HotpotQA	99.6%
BFCL	99.2%
GAIA	98.3%
BrowseComp	83.7%
tau2-bench	74.6%

ただし引数(arguments)は話が別で、こちらは考え切るまで待つ必要がある。思考(CoT)を0%しか進めない段階では引数の正解率は7.6%だが、100%まで進めると97.5%まで上がる。名前は早く決まるが中身は推論の産物、というわけだ。SPORKはこの非対称性を使い、「名前が高信頼で確定した瞬間」にツールを先回りで叩き、残りの推論と実行をオーバーラップさせる。当てが正しければ、本流が同じツール呼び出しに辿り着いたときには結果がもう手元にある。

先読みを「割に合う」ようにする仕掛け

素朴にフォークして予測すると、フォーク自体のコストで元が取れない。SPORKはコストモデルを立てて損益分岐(先読みで浮く時間 ≥ フォークの追加コスト)を明示し、式の各項を削りにいく。整理すると手立ては三つで、いずれもこの不等式の左辺を増やすか右辺を減らすかに対応する。

まず右辺、つまりフォークのコストそのものは、prefix-cache forkで抑える。本流が使っているKVキャッシュのプレフィックスを再利用し、プレフィルの再計算を避けることで、プローブ1回のコストが約1.6秒(プレフィル1.3秒+デコード0.3秒)から約0.35秒(キャッシュヒットのプレフィル0.05秒+デコード0.3秒)に落ちる。次に、外れる予測を実行してしまう無駄はconfidence gateが刈り取る。予測したツール名のスパンについてトークンごとのtop-1確率の最小値を信頼度とみなし、閾値で足切りする仕組みで、θ=0.90のとき適合率88%・再現率100%(F1=0.937)。当てにいく前に外れそうなものを捨てるので、無駄なツール実行を防げる。最後に、予測が厳密一致で棄却されたときも、そのフォーク出力を捨てずに投機的デコードのドラフトへ回す(partial-token accept)。棄却されたプローブでも最終的なツール呼び出しと中央値で18トークンを共有しており、その分の生成を前借りできる。

損益分岐が構造的なので、上限も正直に出ている。稼げる速度はツール待ち時間がウォールタイムに占める割合で頭打ちになり、たとえばBrowseComp(ツールが36.6%)では理論上1.58倍が天井だ。ツールが一瞬で返るタスクでは、そもそも埋める空きがないので効かない。

どこで効いて、どこで効かないか

実測はモデルとベンチで素直に分かれる。ツール待ちが長いほど利く。

モデル	ベンチ	P95遅延(改善前 → 改善後)
Qwen3-32B(dense)	GAIA(実Web検索)	131.9s → 108.1s(18%減)
Qwen3.5-35B-A3B(MoE)	GAIA	222.4s → 187.3s(16%減)
Qwen3.5-35B-A3B(MoE)	HotpotQA	18.9s → 15.2s(20%減)
Qwen3.5-35B-A3B(MoE)	tau2-bench	59.4s → 49.8s(16%減)

タスク精度はいずれの構成でもベースラインから±1ポイント以内に収まっている。速くするために答えの質を落としていない、というのがこの手の高速化では一番大事な点で、そこは押さえている。一方、小さいQwen3-4Bだと実ツール系のベンチでは効果が中立まで薄まる。tau2-benchのようにツール遅延を人工的に伸ばした条件では、遅延に比例して速度向上(1.09〜1.18倍)が伸びていく。

制約もはっきり書かれている。読み取り専用ツールが前提で、書き込みや冪等でない操作はサンドボックスや状態チェックポイントなしには使えない(先回りで叩いて外したら副作用が残るからだ)。オープンウェイトのモデルが必須で、フォークできないOpenAIのようなクローズドAPIには使えない。思考モードを切ると重ねる隙間自体が消えて効果は中立〜わずかにマイナス。さらに、モデル本来のツール出力形式が強制プローブの形式とずれると効かず、論文はQwen3.5-35B-A3Bのネイティブなツール形式(XML)では受理率αが4.5%まで崩れる例を挙げている。上の表でMoEが伸びているのは形式を揃えた条件での話であって、素の形式のままなら破綻しうる、と読むべきだろう。派手な数字の裏で、フォーマット整合という地味な前提が効いているのは実装者として頭に入れておきたい。

試すなら

コードはMITで公開されている。vLLMのOpenAI互換エンドポイントを立て、評価スクリプトに構成を渡す形だ。

pip install -r requirements.txt

PYTHONPATH=. python3 spork_unified_eval.py \
    --model-url http://localhost:8000/v1 \
    --model-name qwen3-32b \
    --benchmark tau2 \
    --configs baseline,d1_d2 \
    --n 40 \
    --enable-thinking

--configs baseline,d1_d2 のように、素の直列実行と各部品を並べて比べられる。tau2-bench・Wikipedia(HotpotQA)のツールバックエンドが同梱で、GAIA用は自前で用意する。

SPORKの発想自体は目新しくない。投機はCPUの分岐予測から続く古典だし、「モデルに自分の次の一手を予測させる」筋も自己投機デコードと地続きだ。前述のPASTEやToolSpecと並べても、ツール往復の直列性という同じボトルネックを別の角度から攻めた一群と見るのが正確だろう。それでも、追加学習ゼロで既存APIに被せられる形に落とし、当たり外れの線引きをコストモデルとして明示した点は実務的に筋がいい。ローカルのオープンウェイトでエージェントを回していて、検索やブラウジングのような重いツールで待たされているなら、質を落とさずに2割前後を削れる余地がある。逆にツールが速い・書き込みが多い・クローズドAPI依存のワークロードでは素直に効かない。入れる前に自分のワークロードで効くかを見積もれるのが、この論文の一番使える部分だと思う。

なお本稿の数値・モデル名(Qwen3.5-35B-A3B)・arXiv ID・受理率αは、いずれも上記の一次ソース(arXiv:2607.03333本文および同リポジトリ)で確認したものだが、arXiv版は改稿されうるため、実装前には最新版で表記と数値の整合を再確認してほしい。

※本記事は一次情報の調査をAIが行い、事実確認のうえ執筆・公開しています。