コーディングエージェントの動的モデル切り替え：GMI Routerを2つのハーネスで検証

過去数週間にわたり、価格帯の両端に位置するDeepSeek V4 FlashとClaude Fable 5を使い、89件のTerminal-Bench 2.1タスクをTerminus 2とClaude Codeで実行しました。GMI Routerの対象をリクエスト単位のモデル選択からエージェント型ワークロードへ広げるにあたり、コーディングエージェントが低コストのモデルで作業を始め、実行中に必要になった場合だけ高性能なモデルを使えるかを調べました。その結果、ハーネスに関して予想外の発見もありました。

そこで、次の問いを立てました。

GMI Routerは開始時のモデル選択に加え、実行中に必要な場合だけ、より高性能なモデルへ動的に切り替えられるか。

主な目的は、実行中のモデル切り替えが機能するか、また品質とコストのバランスにどう影響するかを調べることでした。その過程で、ハーネス自体がモデルの性能と、切り替えが必要に見えるタスクを変えることも分かりました。後半で詳しく説明します。

実験設定

ベンチマークには、検証プログラムで採点するTerminal-Bench 2.1の89タスクを使用しました。V4 Flashは各タスクをハーネスごとに5つのシードで実行しました。Fable 5には、各タスク5回の公式実行記録を使用しました。

固定モデルでの結果

両ハーネスとも、成功率はFable 5が上回りました。Terminus 2ではFlashの69.2%に対して80.7%、Claude Codeでは70.3%に対して84.3%です。しかし、コストには大きな差があります。Flashの1回あたりのコストはTerminus 2で$0.04、Claude Codeで$0.07でした。Fableはそれぞれ$1.15、$1.97です。同じタスク群で26～28倍の差があり、これこそルーターが必要な理由です。すべてをFableで実行すれば、Flashでも解けるタスクに高い料金を払うことになります。すべてをFlashで実行すれば、解けないタスクが残ります。この二つの固定的な方法の間から、より良い運用点を見つけることがルーターの役割です。

図：各条件の成功率（棒はPass@1、目盛りは5回の実行に基づくPass@5）と、1回あたりのコスト。右側のコスト差が、ルーターによって削減できる余地を示します。

2階層のルーティング

ルーティングを二つの段階で検証しました。

第1段階：開始時のモデル選択

最初のステップより前に、目的に基づいてモデルを選びます。品質重視ならFable 5、費用重視ならV4 Flashです。これは現在のGMI Routerと同じリクエスト単位の判断です。

第2段階：実行中の切り替え

第2段階は実行中に働きます。切り替えのルールが、一連の実行に現れる失敗の兆候を監視します。より高い能力が必要と判断すると、V4 FlashからFable 5へ切り替えます。再び低コストのモデルで進められる状態になれば、Flashへ戻します。切り替え後も会話履歴と作業中のファイル状態は引き継がれるため、次のモデルは前のモデルが行った作業を踏まえて続行できます。モデル間の頻繁な行き来を防ぐため、各モデルを使う最短時間、切り替え回数、経過時間に制限を設けました。

この仕組みの仮説は単純です。タスクを始めるのに適したモデルと、終えるのに適したモデルは異なるかもしれません。

図：第1段階ではタスクごとに一度モデルを選択。第2段階ではステップごとに切り替え可能。失敗確率P(fail)、処理のループ、想定を超える実行などを切り替えの兆候とし、安全な状態が2ステップ続くとFlashへ戻します。最短使用時間、切り替え回数、経過時間による制限も設けています。

大半のタスクは低コストのモデルで対応できた

実行中の切り替えを検証する前に、各モデルの複数回の実行結果に基づいてタスクを四つに分類しました。LOWERはV4 Flashで十分に解けるタスク、MIXEDはどちらか一方が明確に優位とはいえないタスクで、通常は5回中2～3回成功します。UPPERはFableが必要なタスク、INTRACTABLEは両モデルとも安定して失敗するタスクです。

両ハーネスともLOWERが最大で、Terminus 2では57タスク、Claude Codeでは58タスクでした。常にFableを使う方法では、これらすべてに高いコストを払います。一方、MIXEDとUPPERの合計はTerminus 2で21タスク、Claude Codeで25タスクです。常にFlashを使う方法では、こうしたタスクを解決しきれません。二つのグループを見分けられれば、ルーターには大きな改善の余地があります。

図：ハーネスごとのタスク分類。青はFlashだけで十分なタスクを示します。

実行中の切り替えで難しいタスクを解決できるか

品質面を検証するため、両ハーネスを通じた過去10回の実行でV4 Flashが一度も成功しなかった9タスクを選び、それぞれ1回ずつ実行中の切り替えを試しました。9タスク中3タスクが成功しました。

chess-best-moveでは8ステップ目に切り替え、Fableがタスクを完了しました。make-mips-interpreterではFlashが28ステップ進めてから引き継ぎました。path-tracingは複雑で、27ステップ目にFableへ切り替え、30ステップ目にFlashへ戻し、33ステップ目に再びFableへ切り替えました。それでも検証プログラムによるスコアは1.0でした。いずれもFlashが初期作業を行い、失敗の兆候をルーターが検出した後、Fableが続きから仕上げています。

9回の試行は少数です。3件の成功は仕組みが機能する実例ですが、一般的な救済率を示すには全タスクでの検証が必要です。現段階で確認できたのは、開始時のモデルには難しすぎるタスクでも、会話履歴を保ったまま高性能なモデルへ引き継ぎ、途中の状態から続行できるということです。

失敗した6タスクも重要です。切り替えは高性能なモデルによる再挑戦の機会を与えますが、利用できるモデルにも解決能力がなければ、その先の切り替え先はありません。

図：切り替えによって成功した3件の実行。上向きの三角はFableへの切り替え、下向きの三角はFlashへの復帰を示します。下段は難しい9タスクの結果で、成功3件、失敗6件です。

解けるタスクでは切り替えを控えられるか

必要以上の切り替えも問題です。少しつまずくたびに高性能なモデルへ切り替えては、コスト面の利点が失われます。そこで、V4 Flashだけで解ける6タスクに同じルールを適用しました。6タスクすべてが成功しました。

4タスクは最後までFlashを使い、1回あたり$0.01～$0.09で完了しました。残る2タスクでは、誤った兆候によって切り替えが起きました。fix-ocaml-gcは27ステップ目にFableへ切り替え、30ステップ目にFlashへ戻って$0.93で完了しました。それでもFableだけで実行した場合の$1.08を下回っています。mailmanは26ステップ目にFableへ切り替え、そのまま$1.51で完了しました。Flashなら数セントで解けるタスクです。この2件は、切り替え判断の精度を改善すべき箇所を最もよく示しています。

有効な切り替えの仕組みには、低コストのモデルに任せてよい場面を見極める能力も必要です。その判断は、難しいタスクを救済することと同じくらい重要です。

図：Flashだけで解ける対照群の6タスク。オレンジ色の区間は、Fableへの不要な切り替えを示します。遅い段階で切り替えた2件が、対照群のコストの大部分を占めます。

もう一つの発見：ハーネスがモデルの性能を変える

同じタスクとモデルの組み合わせをTerminus 2とClaude Codeの両方で実行したため、実行環境がモデルの動作に与える影響を比較できました。その差は予想以上に大きいものでした。

切り替えが役立つ可能性の高いMIXEDとUPPERのタスクを調べると、Terminus 2だけに該当するものが9件、Claude Codeだけに該当するものが13件、両方に該当するものが12件でした。二つの切り替え候補集合のジャッカード類似度は0.35です。一方のハーネスではFableが必要なタスクでも、もう一方ではFlashで解けることが少なくありません。

つまり、タスクの難しさにはハーネスも関わります。ハーネスは、エージェントが文脈をどう構築し、どの順番で作業し、実行を管理し、失敗から立て直すかを左右します。その一つひとつがモデルの結果を変えます。ルーティングにおいては、タスクに最適なモデルが、使用するハーネスによっても変わり得ます。

ここで対象範囲を明確にしておきます。現在の本番環境のGMI Routerはプロンプトに基づいてルーティングします。今回の実験は、ハーネスの影響を外部から測定したものです。この結果は、ハーネスの情報がモデル選択に役立つことを示しています。次回のGMI Routerリリースでは、ハーネスの情報をルーティングへの明示的な入力にする予定です。

図：左はハーネス間で共通する切り替え候補タスク（ジャッカード類似度0.35）。右は89タスク中、いずれかの条件で解けた81タスクと、解けなかった8タスク。

固定的なルーティングから実行状況に応じたルーティングへ

今回の結果は、混同されがちな二つの問題を分けて考える必要があることを示します。

リクエスト単位のルーティングは、「このタスクをどのモデルで始めるか」を決めます。従来の問題であり、現在の多くのルーターが扱うものです。

実行状況に応じたルーティングは、「これまでの経過を踏まえ、現在のモデルで続けるべきか」を判断します。有用な情報の多くは、実行を始めて初めて現れます。失敗の繰り返し、進捗の停滞、ループ、プロンプトから想定したより難しいタスク、途中の難所からの立て直しなどです。これらは実行状況を表す兆候です。コーディングエージェントのルーティングは、開始時の分類を判断材料の一つとしながら、実行中に必要なモデルの能力を継続的に割り当てる問題へと変わります。

経済的な指標：解決済みタスク1件あたりのコスト

成功率だけでは、本番環境における判断材料として十分ではありません。高性能なモデルは多くのタスクを解けますが、1回あたりのコストは26倍以上です。低コストのモデルは数セントで実行できますが、失敗が増えます。両方を捉える指標が、解決済みタスク1件あたりのコストです。安価なモデルでも4回の再試行が必要なら、コストは膨らみます。逆に、Flashで解ける大半の簡単なタスクを高性能なモデルで1件$1.50かけて解くのも高くつきます。

動的な切り替えが目指すのは、その中間です。実行の流れを「Flash、Flash、Flash、Fable、Fable」と考えてみてください。すべてのステップをFableで処理する場合や、失敗するまでFlashだけで処理する場合と比較できます。問うべきことは、どのモデルが最も強いかではなく、解決に向けて進むために各段階でどの程度の能力が必要かです。

現時点で分かったこと

両ハーネスを通じて、四つの傾向が確認できました。まず、コーディングエージェントのタスクの大半は低コストのモデルで対応できます。LOWERに分類されたのは、Terminus 2で89件中57件、Claude Codeで58件であり、コスト削減の余地があります。次に、より高い能力が必要なタスクもあります。MIXEDとUPPERの結果は、低コストのモデルだけに固定すると解けないタスクが残る理由を示しています。また、高性能なモデルを実行途中から導入できます。Flashが固定モデルでの実行では一度も解けなかった3タスクが、実行中の切り替えによって成功しました。最後に、ハーネスの選択はモデルの動作に大きく影響します。切り替え候補の集合の類似度が0.35だったことから、ルーティングでは実行環境も考慮する必要があります。ハーネスを考慮したルーティングを次の検証項目にした理由です。

制約

これは初期段階の実験であり、次の制約があります。

·       V4 Flashの結果は当社による実行、Fable 5の結果は公式実行記録に基づきます。

·       対象は2モデルと2種類のハーネスです。

·       実行中の切り替えを試したのは、難しい9タスクと対照群6タスクで、それぞれ1回ずつです。

·       高性能モデルへの切り替えと低コストモデルへの復帰の判断ルールは実験段階にあり、不要な切り替えも発生しています。

·       固定モデルと動的ルーティングの各方法について、解決済みタスク1件あたりのコストを集計した結果は、今後公開する予定です。

今回の結果は、実行中のモデル切り替えの仕組みと、その潜在的な価値を示すものです。本番利用を判断するためのベンチマークは、全タスクでの実行後に得られます。

今後の検証

次回は、両ハーネスで89タスクすべてに実行中の切り替えを適用します。それによって、今回の記事では示せなかった数値が得られます。実行の一部でのみFableの料金を払いながら、Fableの成功率にどれだけ近づけるかです。

ハーネス間の違いから、もう一つの検証課題も生まれました。ハーネスの種類と、ハーネス固有の動作を明示的な入力にすると、ルーティングはどれほど改善するのか。次回リリースで予定している、ハーネスを考慮したルーティングは、この問いに答えるためのものです。

まとめ

出発点は、「コーディングエージェントが必要性を示すまで、高価なモデルの使用を先送りできるか」という問いでした。初期の答えは、いくつかの留保付きで「できる」です。Terminal-Benchのタスクの大半は、低コストのモデルですでに解けました。一部のタスクには、初めから高性能なモデルが必要でした。そして、難しいタスクの中には、実行を始めて初めて高い能力の必要性が見えるものもありました。固定的なルーターでは捉えにくいケースです。

同じタスクを2種類のハーネスで実行した結果、重要な要素がもう一つ加わりました。エージェントの実行環境は、タスクと同じようにモデルへの要求を左右し、成功率と切り替えの動作を変えます。これまでの問いは、「このリクエストに最適なモデルはどれか」でした。

これから取り組むのは、次の問いです。

GMI Routerを使ってみる

この記事で紹介した第1段階のルーティングは、すでにGMI Routerで利用できます。console.gmicloud.aiにログインし、GMI Routerを開いて、ご自身のプロンプトで試してみてください。詳細はドキュメントをご覧ください。エンドポイントはOpenAI APIと互換性があるため、連携時にはベースURLを変更できます。

from openai import OpenAI
 client = OpenAI(
     base_url="https://console.gmicloud.ai/api/v1/ie/recommendation",
     api_key="YOUR_GMI_API_KEY",
 )
 resp = client.chat.completions.create(
     model="auto",
     messages=[{"role": "user", "content": "Fix the failing test in src/parser.py"}],
     extra_body={"mode": "cost"},   # cost | balanced | quality
 )
 print(resp.choices[0].message.content)

実行途中のモデル切り替えと、ハーネスを考慮したルーティングは次回のリリースで提供予定です。その際、89タスクすべてを再実行し、各方法の解決済みタスク1件あたりのコストを公開します。