モデル間でエージェントを引き継ぐとき、実行済みの作業を捨てない仕組み CFRC

「引き継ぎ」でやり直しが起きる問題

AIエージェントを安く動かす手法として、小さいモデルで処理を始め、難しい部分だけ大きいモデルに渡す「ルーティング」や「カスケード」が使われます。ただし、エージェントがすでにツールを呼び出して外部に影響を与えていた場合、単純に制御を渡すと厄介なことになります。確定した選択、実際に起きてしまった副作用、まだ終わっていない約束事——これらを引き継ぎ先が把握していなければ、同じ操作を二度実行したり、途中から辻褄の合わない行動を取ったりします。

研究者が査読前の論文を公開するサイト「arXiv（アーカイブ）」に投稿された論文は、この状況を「コミットメント制約付きの残余完了」という問題として定式化しました。つまり、すでに確定した部分は動かせない制約として固定し、残りだけを解く問題として扱うということです。

契約を凍結してから残りを解く

提案手法はCommitment-Frontier Residual Completion（CFRC）と名付けられています。受け入れ済みの進捗から「残余契約」を凍結し、引き継ぎ先の続きの処理を証拠と結びついたグラフとして閉じた上で、残りが契約に覆われていることが確認できたときだけ実行を許すという構成です。実行中に得られる受領記録（レシート）が、未完了の義務を消し込んでいきます。

設計原則として三つが置かれています。提案より先に目標を定めること、権限を与える前に提案全体を確定させること、成功と判定する前に実地の証拠を得ること。いずれも、エージェントが勝手に既成事実を作らないための順序の制約だと読めます。

論文は、契約に対する部分正当性を証明し、契約が完全に構成された場合には元の残余要求そのものに対しても成立すると述べています。

コストは2〜3割

評価は五つの環境と、同一プロバイダの二つのモデルの組み合わせで行われました。タスク全体を強力なエージェントに解かせた場合と比べ、マクロ精度は同程度を保ちながら、推論コストは22.0%〜34.6%に収まったと報告されています。さらに、異なるプロバイダのモデル間でも転移が見られたとしています。

マルチエージェント構成の話題は増えていますが、「誰がどのモデルを呼ぶか」よりも「引き継いだ後に何を壊さないか」のほうが実運用では難所になります。この論文が扱っているのは後者で、形式的な保証を与えようとしている点が目を引きます。数値はいずれも論文が示した実験条件でのものなので、そのまま一般化はできません。

たとえば Claude Code から Codex へ渡すとき

ここから先は論文が挙げている例ではなく、この問題が普段の作業でどう現れるか、という話です。

コーディング用のエージェントを複数使い分けている人は多いはずです。片方で作業を進め、行き詰まったところで別のモデルに渡す。そのとき何が失われるかを並べると、論文が分けている三つがそのまま出てきます。

すでに起きてしまったこと

ブランチを切った。依存パッケージを入れた。データベースの移行を適用した。プルリクエストを立てた。渡した先がこれを知らなければ、同じことをもう一度やります。移行の二重適用や重複したプルリクエストは、やり直しでは済まない種類の失敗です。

確定した選択

「この設計でいく」「このライブラリを使う」と決めた判断です。渡した先が選び直すと、すでに書いたコードと噛み合わなくなります。途中から方針が二つ走っている状態は、後から気づくほど直しにくくなります。

まだ果たしていない約束

「テストを通してからマージする」「この関数のエラー処理は後で足す」。宣言しただけで実行していないものは、引き継ぎで最も消えやすい部分です。

いま多くの人が取っている対処は、引き継ぎメモを書かせることでしょう。作業ログを吐かせる、プルリクエストの説明に現状を書く、リポジトリに指示ファイルを置いておく。これは論文が「残余契約」と呼ぶものを、自然言語で手作業でやっていることに相当します。

違いは、その引き継ぎが確認できる形になっているかどうかです。散文のメモは、受け取った側が読み飛ばしても誰も気づきません。CFRCが置いているのは、残りの作業が契約に覆われていることを確かめてから実行を許す、という順序です。人間が気をつけて防いでいるものを、手順のほうで防ぐという発想だといえます。

出典: arXiv:2609.13800v1「Do Not Restart: Residual Completion for Stateful Agent Handoffs」（arXiv cs.AI）