AIエージェントを高性能モデルへ替えても手遅れになる。Handoff Taxが示した履歴の罠

小型のAIモデルから大型のAIモデルへ、絡まった会話履歴と整理された作業状態が別々に渡される概念図
モデル切り替えでは、会話の軌跡と検証済みの作業状態を分けて扱う。AICompanyが論文の考え方を再構成したオリジナル図

AIエージェントを高性能モデルへ替えても手遅れになる。Handoff Taxが示した履歴の罠

安いモデルで始めて、難しくなったら高性能モデルへ切り替える。AIエージェントの費用を抑えるなら、いかにも筋のよい作戦です。

ところが、途中までの会話やツール実行を丸ごと引き継がせると、高性能モデルへ替えたのに期待したほど直りません。

ドライブレコーダーもAIにお任せ

AWS Agentic AIの研究チームが公開した論文「The Handoff Tax: Continuing Non-Native Trajectories in LLM Agents」では、低価格モデルから高性能モデルへ生の履歴を渡したとき、高性能モデル単独が持つ品質差の回収はClaude系で47%、GPT系で36%にとどまりました。

モデルを替えるだけでは、能力を替えたことにならない。受け渡し方まで設計して、ようやく切り替えが機能する。これが今回のいちばん大事な話です。

問題はコンテキスト不足ではなく、他人の途中式を継ぐこと

長時間のコーディングエージェントは、何十回もモデルを呼び、ファイルを読み、コマンドを実行し、コードを直します。途中で行き詰まったとき、上位モデルへ切り替えれば、それまでの探索を生かしながら難所だけを突破できそうに見えます。

従来は、この切り替えを主にモデル選択の問題として考えてきました。いつ安いモデルを使い、いつ高いモデルを使うか、というルーティングです。

今回の論文は、そこにもう一つの問題があると指摘します。切り替え後のモデルは、自分では作っていない探索経路を読んで仕事を続けます。論文はこれを「非ネイティブな軌跡の継続」と捉えました。

弱いモデルの履歴には、役に立つ観察だけでなく、誤った仮説、見落とした条件、遠回りした検索、失敗した修正も混ざります。高性能モデルは、その続きを考える前に、どこまで信用してよいかを再評価しなければなりません。

長い履歴は、いつも親切な引き継ぎ書ではありません。ときには、迷子が残した長編旅行記です。

履歴と作業状態を分けた実験

研究チームは、SWE-bench Verifiedの500課題を使い、二つのモデル族で切り替えを調べました。

  • Claude Haiku 4.5とClaude Opus 4.7
  • GPT-5.6 LunaとGPT-5.6 Sol

各モデル族で58構成を評価しています。単一モデルの基準が2構成、切り替えは7時点、4方式、2方向で56構成です。合計は58,000回のエージェント実行、200万回のLLM API呼び出し、360億処理トークンに達しました。

重要なのは、切り替え後も同じDocker環境と作業ツリーを保ったことです。つまり、途中までに変更したファイルは残ります。そのうえで、受け手へ渡す会話軌跡だけを変えました。

比較した主な方式は次の三つです。

  1. Raw:会話、推論、ツール呼び出し、観察をすべて渡す。
  2. Compact:途中経過を要約して渡す。
  3. Traj-drop:会話軌跡は渡さず、作業ツリーと元の課題を渡す。

ここで効いてくるのが、「履歴」と「状態」の違いです。

履歴は、どう考えて現在地へ来たかです。状態は、いま何が変更され、どのテストが落ち、どのファイルが残っているかです。Traj-dropは前者を捨てますが、後者は捨てません。

低価格モデルの会話履歴をフィルターで除き、コード、テスト、リポジトリ状態を高性能モデルへ渡す図
昇格時は、迷走した会話を減らし、コード変更とテスト状態を残す。論文のTraj-dropを実務向けに図解

高性能モデルへ替えても、Rawでは半分も取り戻せない

論文は、高性能モデル単独と低価格モデル単独の品質差を100として、切り替えでどこまで取り戻せたかをQuality Recoveryで示しました。

低価格モデルから高性能モデルへ切り替える昇格では、Rawの回収率はClaude系47%、GPT系36%でした。高性能モデルに替えたのに、能力差の半分も回収できていません。

費用も単純ではありません。

| 昇格条件 | Claude系のパス率 | Claude系の平均費用 | GPT系のパス率 | GPT系の平均費用 | |—|—:|—:|—:|—:| | 低価格モデル単独 | 60.7% | 0.40ドル | 58.7% | 0.06ドル | | 高性能モデル単独 | 79.2% | 0.72ドル | 83.7% | 0.47ドル | | Raw | 69.2% | 1.61ドル | 67.5% | 0.36ドル | | Traj-drop | 72.4% | 0.81ドル | 79.7% | 0.50ドル |

Claude系では、Rawは高性能モデル単独より正解率が低いのに、費用は0.72ドルから1.61ドルへ増えました。論文の条件では、最初から高性能モデルでやり直すほうが、安くてよく解けています。

GPT系ではRawが高性能モデル単独より安いものの、パス率は83.7%から67.5%へ大きく落ちます。価格だけを見れば節約ですが、難所を救うという目的には弱い結果です。

会話を捨て、作業ツリーを残すと回復する

もっとも興味深いのがTraj-dropです。

低価格モデルが作った会話軌跡を渡さず、変更済みの作業ツリーと元の課題だけを高性能モデルへ渡すと、品質差の回収はClaude系で64%、GPT系で84%へ上がりました。Rawの47%と36%から、とくにGPT系で大きく改善しています。

これは「全部やり直せ」という結果ではありません。低価格モデルが残したコード変更は保持されています。捨てたのは、その変更へ至った長い会話です。

ただし、Traj-dropが万能という意味でもありません。費用節約の保持率はClaude系でマイナス30%、GPT系でマイナス8%でした。どちらも高性能モデル単独より少し高くついています。

品質を救うなら有効でも、費用まで必ず救えるわけではない。この二つを分けて読む必要があります。

逆方向では、よい履歴を残したほうが強い

高性能モデルから低価格モデルへ切り替える降格では、話が逆になります。

RawはClaude系で品質差の50%を回収しながら、低価格モデルの費用優位を80%保持しました。GPT系では品質差の79%を回収し、費用優位を14%保持しています。

一方、履歴を落としたTraj-dropでは、品質差の回収がClaude系28%、GPT系53%まで下がりました。

高性能モデルが難しい探索と判断を済ませたあとなら、その履歴は価値ある設計図になります。弱いモデルの迷走を上位モデルへ渡す場合と、上位モデルの整理された判断を下位モデルへ渡す場合は、同じ引き継ぎではありません。

この方向差が、Handoff Taxの核心です。

低価格モデルから高性能モデルへの昇格と、高性能モデルから低価格モデルへの降格で異なる引き継ぎを示す二段の図
昇格では弱い軌跡を減らし、降格では強いモデルの整理された判断を残す。方向によって履歴の価値が変わる

実務では「何を考えたか」より「何が確かか」を渡す

ここからは論文結果をもとにしたAICompanyの実務提案です。論文がCodexやOpenCodeの全製品構成で直接検証したルールではありません。

昇格時の引き継ぎは、長い会話の要約より、次のような検証可能な状態を中心にすると扱いやすくなります。

  • 元の依頼と受け入れ条件
  • 現在の変更ファイルと差分
  • 成功したテストと失敗したテスト
  • 再現コマンドと実際のエラー
  • 確認済みの事実
  • 未解決の仮説
  • 触ってはいけない範囲

反対に、「たぶんこのモジュールが原因」「この方針で行けそう」といった推測は、事実と分けます。受け手がその仮説を引き継ぐか、捨てて探索し直すかを選べるからです。

要約するなら、物語ではなくチェックポイントを作る。これが実装しやすい考え方です。

20件でできる小さな再現テスト

大規模なSWE-bench実験を再現しなくても、自分たちの運用がHandoff Taxを払っているかは小さく調べられます。

過去の難しいエージェント作業を20件ほど選び、上位モデルへ切り替える条件を三つに分けます。

  1. 全履歴をそのまま渡す。
  2. 失敗テスト、変更ファイル、残課題だけを短く渡す。
  3. 会話履歴を渡さず、作業ツリーと元の依頼だけを渡す。

比較するのは解決率だけではありません。追加トークン、追加時間、差し戻し回数、同じファイルを読み直した回数も記録します。

もし2番や3番で解決率が上がり、読み直しが減るなら、問題は上位モデルの能力不足ではなく、引き継ぎ形式にある可能性が高いと言えます。

まだ証明されていないこと

この論文は大規模ですが、結論の範囲には注意が必要です。

第一に、評価したモデルの組はClaude系とGPT系の二つです。能力差や料金差が違う組み合わせで、同じ費用対効果になるとは限りません。

第二に、主実験はSWE-bench Verifiedだけです。記事制作、調査、データ分析、ブラウザ操作でも同じ方向差が出るかは未検証です。

第三に、500課題を各構成で1回ずつ実行しており、同じ課題を繰り返したときのばらつきは測っていません。難しい課題の切り替え共通部分は、1セル平均約24件から27件と小さいため、難易度別の傾向は探索的です。

第四に、切り替え時点は事前に固定されています。実際の製品で行うような、失敗兆候を見て動的に切り替える方法や、一つの作業で何度もモデルを替える方法は、これからの課題です。

また、実験固有の全資産が公開されていることは確認できませんでした。58,000実行という規模は強い証拠ですが、第三者が同じ条件をそのまま再現できる状態とは言い切れません。

結論

AIエージェントのモデル切り替えは、モデル名を差し替えるだけでは完成しません。

弱いモデルから強いモデルへ替えるときは、長い履歴が助けになるとは限らない。むしろ、作業ツリー、テスト結果、確定した条件を残し、迷走した会話を切るほうが、強いモデルの能力を引き出せる場合があります。

一方、強いモデルから安いモデルへ渡すときは、よい探索履歴を残す価値が高い。切り替える方向によって、渡すべき情報が変わります。

高性能モデルを呼ぶ前に、引き継ぎ書を直す。少し地味ですが、費用と品質の両方に効くのは、こういう部分なのかもしれません。

参考資料

ドライブレコーダーもAIにお任せ

投稿者 AICompany

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

CAPTCHA