エージェントは「外側で動かす」だけでなく「重みに焼き込む」時代へ

外部オーケストレーション偏重への問い直し

2026年5月22日のarXiv更新枠に、実務寄りのエージェント設計にとって示唆的な論文が登場した。タイトルは「Compiling Agentic Workflows into LLM Weights」。主張を一言で表すなら、LangGraphやCrewAIのような外部オーケストレーターで毎回ワークフローを制御するのではなく、手順そのものを小型LLMの重みにファインチューニングで“コンパイル”すれば、近い品質をより低コストで実現できるのではないか、というものだ。投稿時刻は2026年5月21日UTCだが、cs.AIのrecent一覧では5月22日枠に掲載されている。

背景にあるのは、現在のエージェント実装が「モデル＋外部ハーネス」に寄りすぎているという問題意識だ。外部ハーネスはどのノードを実行するか、どの条件分岐に進むか、どの情報を次ターンへ注入するかを、毎回プロンプトやルーティングで管理する。開発はしやすいが、会話ごとに長い手順をコンテキストへ載せるためトークンコストが膨らみ、レイテンシも伸びる。さらに業務上の手順や判断ロジックをAPI提供者側へ露出しやすい。論文は、主要なエージェント・オーケストレーション系フレームワークが広く使われている現状を前提に、この「外側から毎回制御する」設計を問い直している。

“Subterranean Agent”という発想

著者らが提案するのは、“subterranean agent”と呼ばれる発想だ。表層のプロンプトやワークフローグラフではなく、業務手順を学習データに変換し、小型モデルのパラメータ内部に埋め込む。実行時には複雑なオーケストレーターを置かず、モデル自身が手順を内在化した状態で対話を進める。直感的には、「毎回マニュアルを読ませる」のではなく、「マニュアルを読んで訓練された担当者」を作るという違いに近い。

実験の対象ドメイン

実験対象は、旅行予約、Zoomサポート、保険請求という三つの手続き型ドメインだ。arXiv要旨によれば、旅行予約とZoomサポートはいずれも14ノード、保険請求は55ノード・6つの意思決定ハブを含む。ここは重要で、論文が狙うのは自由な創造的推論ではなく、分岐条件と確認事項が明確な「業務プロセス」だ。つまり、あらゆるエージェントを重みに焼き込めるという話ではなく、反復され、形式化でき、評価可能な手順に対する最適化として読むべきものだ。

モデル構成と評価

公開されている論文サマリーによれば、旅行予約ではQwen 2.5 3B、Zoomサポートと保険請求ではQwen3-8Bを使い、フローチャートから合成会話データを生成してフルパラメータ・ファインチューニングを行う。評価軸はタスク成功、情報正確性、一貫性、自然さなどで、Claude Sonnet 4.5によるジャッジとGPT-4.1によるロバストネス確認が使われたとされる。LLM-as-a-judgeに依存しているため、絶対的な業務品質の証明ではなく、比較実験として受け取るのが妥当だ。

結果が示す揺さぶり

注目すべきは、「小型モデルでもそこそこ動く」という点だけではない。サマリーによれば、コンパイル済みモデルはフロンティアモデルへ手順をコンテキスト投入する方式に対して、会話あたり128〜462倍安いとされ、保険請求の例ではレイテンシも改善している。失敗率にも明確な差が出ている。

ドメイン	コンパイル済みモデル	LangGraphオーケストレーター
旅行予約（3B）	5.5%	24.0%
保険請求（8B）	9%	17%

もちろん、これらは著者設定のドメイン・評価系に依存する数字だ。それでも「外部制御は常に高品質」という直感には十分揺さぶりをかけてくる。

「コンパイル」概念の重み空間への拡張

技術的に興味深いのは、エージェントの「コンパイル」という見方を重み空間に拡張している点だ。従来のコンパイル的発想は、自然言語の曖昧な指示をJSON、コード、ワークフロー、ツール呼び出しへ落とし込む方向だった。今回の論文は逆に、明示的なワークフローを教師データ化し、モデル内部の行動分布へ移す。外部グラフを消すことで可観測性は下がるものの、推論時のトークン注入、分岐プロンプト、ルーティング呼び出しを削れる。「エージェントを賢くする」というより、「繰り返し使う手順を実行時コストから学習時コストへ移す」研究と捉えると理解しやすい。

限界と運用上の前提

ただし限界もはっきりしている。

• 手順変更への追従コスト：頻繁に手順が変わる業務では再コンパイルが必要になる。サマリーでは更新サイクルは30〜50分程度とされるが、これはCI/CDに近い運用設計が前提だ。
• 世界知識への弱さ：手順外の広い世界知識が必要な場面では、フロンティアモデルへコンテキストを与える方式の方が有利になりうる。
• 適応手法の制約：フルパラメータ・ファインチューニングが用いられており、LoRAのような軽量適応では同等に届かなかったと整理されている。

つまり、誰でも即座に低コスト化できる魔法ではない。

実務への含意：三層の配置設計

実務への含意は大きい。エージェント開発では、何でも汎用LLMに毎回考えさせるのではなく、次の三層に分ける設計が重要になる。

1. 変わらない手順：コード化・ルール化する
   
2. 反復されるが自然言語対話が必要な手順：小型モデルへコンパイルする
   
3. 毎回未知性が高い判断：フロンティアモデルや外部検索を使う
   

この論文は、2番目の層を具体的に示した点で価値がある。

まとめ

エージェント競争は、モデル単体の能力だけでなく、「どの知識をプロンプトに置き、どの知識をコードに置き、どの知識を重みに置くか」という配置設計の競争になりつつある。外側のワークフローをすべて捨てる必要はない。ただ、毎回同じ手順を長いプロンプトで読ませ続ける設計は、これから少しずつ贅沢品になっていくのかもしれない。