Arize AI、コーディングエージェントのモデルとハルネスルーティングによるコスト削減法を公開

著者による注記：モデルは日々進化しており、この記事を読んでいる頃には、おそらく次のバージョン（Astra や Fable 5.1 など）の実験を始めていることでしょう。しかし、ここで紹介する教訓は、どのモデルを選んでも通用するものです。

私は Arize の実験チームに所属するソフトウェアエンジニアのインターンとして、Claude Code、Codex、Cursor、OpenCode、Pi など、さまざまなコーディングエージェント用ハルネス（環境）のテストに多くの時間を費やしています。この取り組みを始めたのは、実用的な疑問からでした。「同じ AI バジェットで、どれだけの有用なエンジニアリング作業を実現できるか？」

私たちの頻繁に行っていたワークフローの一つは、毎日 Slack ボットが重大なバグを検索し、プルリクエストを作成する仕組みです。Opus 5 を最初から最後まで実行すると、1 回あたり約 100 ドルのコストがかかっていました。その後、メインループを Kimi K3 Max に移行し、補助的な作業は低コストのモデルに任せるようにした上で、Opus 5 はアドバイザーとして残すことにしました。その結果、同じワークフローの実行コストは 1 回あたり約 15〜20 ドルまで削減できました。前回の手法との比較で発見の質を厳密に測定するのは難しいものの、私たちは引き続きこの方法からのプルリクエストのマージを進めています。

この実験を通じて、コーディングエージェントのコスト構造についてさらに興味を持つようになりました。1 つの実行には複数の種類の作業が含まれており、それぞれがモデルに対して異なる要求を課します。見知らぬ変更の計画には最上位レベルの判断力が求められる一方、関連ファイルの特定やテスト出力の要約、単純な編集などは、それほど高度な能力は必要ありません。

私の現在のルールは、最先端のトークンを「判断」に費やし、その上で全体ワークフローが許容できる結果を生み出しているかを測定することです。

コーディングエージェントのコストは、実行全体に依存します

基本となる計算式はシンプルです。

総モデルコスト = トークン単価 × トークン使用量

価格表が示すのは請求書の一部分に過ぎません。入力トークン、キャッシュされた入力トークン、出力トークンはそれぞれ異なるレートで課金されます。長いコンテキストになると、さらに高い価格帯に移行することもあります。また、ハルネス（実行環境）がファイルの読み込み、ツールの呼び出し、作業の委任、失敗時の再試行、結果の確認などを行う間に、単一のリクエストで複数のモデル呼び出しが発生することも珍しくありません。

image請求額を左右する要因：モデルの選択と実行環境（ハルネス）によって分けられる、トークン単価と使用量の積。

ハルネスが重要なのは、そこがモデルの使用方法を制御しているからです。どの程度のリポジトリコンテキストを送信するか、ツールの出力は要約すべきか、サブエージェントをいくつ並列実行できるか、いつ再試行を行うか、そしてタスクが完了したとみなすのか——こうした判断すべてをハルネスが行います。

Composio は、30 のエージェントタスクに対して同一のモデルを 4 つ異なるハルネスで評価しました。その結果、成功件数は 14 から 17 の範囲にありましたが、成功したタスクあたりのコストは最大 2.7 倍も変動しました。これは絶対的なランキングを示すものではなく方向性を示すデータですが、モデル価格だけで比較するのは不十分であることを如実に物語っています。

私が重視する指標は、「承認されたタスクあたりのコスト」です。

1 つのタスクが承認された際の費用は、

試行・再試行・レビュー・人間の検証にかかった総コスト

÷

承認基準を満たしたタスク数

で計算されます。

コーディングエージェントの場合、承認とは「テストに合格する」「仕様に合致する変更を行う」「レビュアーがプルリクエストをマージする」ことを意味します。セキュリティワークフローでは、「人間が検出結果を確認すること」が承認の条件となります。

imageインテリジェンスインデックスタスクにおける出力トークン数（回答用と推論用の比較）。出典：Artificial Analysis。

imageDeepSeek V4 Flash を 30 のエージェントタスクで 4 つのハレスに適用した結果。出典：Composio エージェント評価。

私にとって効果的だったモデルルーティングのパターンは 2 つあります。

一般的なコーディングエージェントの実行には、計画策定、リポジトリの探索、実装、検証、レビューといった工程が含まれます。これらの工程それぞれに異なる推論要件がある場合、ルーティングが有効に機能します。

image2 つのルーティングアーキテクチャ：低コストなサブエージェントを統括する最前線のオーケストレーター、および最前線のアドバイザーを持つ低コストのオーケストレーター。

パターン 1: 低コストなサブエージェントを統括する最前線のオーケストレーター

このパターンでは、最先端モデルが計画を主導し、実行全体を調整します。一方、低コストのサブエージェントは、ファイルの検索やコードの確認、既存の動作の要約、一般的な変更といったトークン消費量の多い作業を担当します。

このアーキテクチャの一つの実装例では、オーケストレーターに GPT-5.6 Sol を、実行担当に Terra サブエージェントを採用しました。簡略化した指示内容は以下の通りです。

親エージェントで計画とアーキテクチャの決定を保持する。

委任するタスク:

• リポジトリの探索
• ファイルの発見
• 既存動作の要約
• シンプルな実装

最終パッチを作成する前に、サブエージェントからの出力を確認する。

これは概念例であり、実際の運用で使われるプロンプトそのものではありません。委任の構文やサブエージェントの振る舞いは、使用するハーンによって異なります。

私は、初期の計画が弱いために下流の作業全体のコストが高騰してしまう場合に、このアプローチを採用します。オーケストレーターはタスクを受け取り、どのように分割するかを決定し、返された成果物を評価します。

パターン 2：低コストのオーケストレーターに最先端モデルをアドバイザーとして配置

2 つ目のパターンでは、能力のある低コストモデルがメインループを駆動します。最先端モデルは計画のレビューや不確実性の解消、あるいは定義されたチェックポイントでの提案変更の確認を担当します。

ある実装例では、ドライバーに Kimi K3 Max を採用しました（このタスクには GPT-5.6 Sol も有力な候補です）。サポート業務には GLM 5.2 Max、Composer 2.5、5.6 Terra を使い、アドバイザーには Opus 5 を配置しました。

この手法が最も効果を発揮するのは、ワークフローに明確な構造があり、初期計画の直後や反復的なテスト失敗の後、あるいは高リスクなアーキテクチャ変更やプルリクエスト作成前にアドバイザーを呼び出せる場合です。

フロンティアモデルに対してレビューという狭いタスクを与えることで、必要なコンテキスト量も削減できます。計画やパッチのレビューは、コードベースを独立して探索して変更全体を実装するよりもコストが低く済みます。

実際のワークフロー 2 つで何が起きたか

• ワークフロー：ルーティング構成 / 結果 / 制限
• 毎日の重要バグ発見 Slack ボット：Kimi K3 Max が実行を主導し、低コストモデルがサポート業務を担当、Opus 5 がアドバイス / 1 回あたりのコストは約 100 ドルから 15〜20 ドルに低下。チームは生成されたプルリクエストの一部をマージし続けた / 再現性のある同等の試行（一致する recall、precision、または重大度）は実施していない
• コードベース全体のセキュリティスキャン：低コストのオーケストレーター、約 50〜60 のサブエージェント、フロンティアモデルによるアドバイザー / スキャン費用は約 100 ドルで、20 件以上の候補となる高重大度発見を特定。Fable 5 で完全に実行した場合のコストは 1,000〜2,000 ドルと推定

高い見積もりはあくまで推計であり、すべての発見には人間の検証が必要

最初の結果から、このルーティングパターンが運用面で有用であるという確信を得ました。ただし、安価なシステムがあらゆる品質の次元においてフロンティアモデル単独のシステムと同等であると主張するには、まだ十分な証拠がありませんでした。

セキュリティスキャンにも同様の限界があります。モデルが生成した「高重大度」のラベルだけで、実際に脆弱性が存在するとは限りません。このワークフローでは、「確認された発見ごとのコスト」「誤検知率」「重複率」「人間レビューとの重大度合致度」、そして各問題を検証するのに要する時間を追跡すべきです。

承認された成果物あたりのコストを測定する

私の初期実験では、品質よりもコストの方が正確に計測できました。トークン数は明示的に数えられる一方、エンジニアリングの品質は定義が難しいからです。

より適切な比較を行うには、エージェント実行前の段階から始めます。

固定されたタセットを構築します。実際のワークフローから、日常的なタスク、曖昧なケース、既知の失敗モードを含めてください。

受容基準を明確に定めます。出力を確認する前に「何が成功とみなされるか」を決めておきます。具体的には、必須テストのパス、文書化された仕様の合致、レビュー承認の取得、または確認済みのセキュリティ発見の生成などが該当します。

各設定を複数回実行してください。コーディングエージェントは非確定的な性質を持つため、1 回の試行だけではコストと品質の両方を誤って代表してしまいます。

ハッチ全体を追跡します。各ステップで使用されたモデル、入力・出力トークン数、キャッシュ利用状況、ツール呼び出し、リトライ回数、サブエージェントの数、レイテンシ、そして最終的な成果物を記録してください。

承認された成果物を比較します。失敗した試行、アドバイザーへの問い合わせ、人間によるレビューも、最終的なコスト計算に含めてください。

バグ発見ボットの場合、「オープンされたプルリクエストごとのコスト」よりも「マージされたプルリクエストごとのコスト」の方が有用です。後者の指標は、エンジニアリングチームが価値を見出した成果物と支出を直接結びつけるからです。

マルチエージェントシステムでは、トップレベルの要求が実際の作業内容を隠蔽してしまうため、トレーシング（追跡）が特に重要です。単一の実行でも、重複するリポジトリ検索や枝分かれ、請求書上では見えない高コストな再試行などが含まれている可能性があります。

より強力なモデルを使用する前に、コンテキストを削減しましょう

私の実験ではルーティングが最大の節約効果をもたらしましたが、不要なコンテキストも請求額に大きな影響を与えます。

テストランナー、Git コマンド、リンター、Docker、ビルドシステムなどは数千行の出力を生み出します。エージェントが必要とするのは、失敗したアサーション、関連するスタックトレース、変更されたファイル、そしてコマンドの状態だけです。進行状況の表示や繰り返される成功メッセージは、次の判断にはほとんど役立ちません。

この課題を解決するための 2 つのツールがあります。

RTK は、エージェントのコンテキストに到達する前にコマンド出力をフィルタリングして圧縮します。プロジェクト側の報告では、コマンドやワークフローの内容にもよりますが、シェルの出力が約 60% から 90% 削減されるとのことです。

Caveman は Claude Code や他のコーディングエージェント向けのレスポンス整形スキルで、モデルに対して簡潔な要約形式での回答を促しつつ、コード、コマンド、エラー文字列、記号などはそのまま残すよう指示します。10 の例題プロンプトにおける平均的な出力トークンの削減率は 65% と報告されています。

これらはプロジェクト側の報告数値ですので、ご自身のチームにとって重要なタスクで実際に検証することをお勧めします。

この原則は、ハネス（実行環境）でも直接適用できます。対象となるファイル範囲を指定してリクエストし、テストの成功出力を要約し、完全な失敗詳細を保持し、重複するスタックトレースを統合し、検索結果に上限を設定し、キャッシュが利用可能な場所では安定したプロンプトプレフィックスを再利用し、完了した作業を繰り返すブランチは停止させるのです。

コンテキストを削減することは、コスト削減だけでなく推論能力の向上にも寄与します。関連する証拠がモデルにとって見つけやすくなるためです。

モデルルーティングの実用的な導入方法

私は、ルーティングを1段階ずつ導入することをお勧めします。

まず、明確な成果物を持つ高価で反復可能なワークフローを選びます。

次に、現在のコスト、トークン使用量、リトライ回数、レイテンシ、受容率、人間のレビュー時間を記録します。

計画、探索、実装、検証、レビューの各工程を分離します。

既存のプランナーとレビュアーは維持したまま、高頻度でリスクが低い工程をより安価なモデルへ移行します。

繰り返し失敗する場合や矛盾する証拠がある場合、セキュリティに関わる判断が必要な場合、あるいは高リスクシステムへの変更が発生した場合のためのエスカレーションルールを追加します。

さらに作業をルーティングする前に、同じタセットで両方の構成を比較検証してください。

安価なモデルであっても、トークン消費量が多かったり頻繁にリトライしたり、広範な修復を必要としたりすれば、結果的に高コストの実行になる可能性があります。また、ベンチマークスコアが高くても、特定のレポジトリでのパフォーマンスが保証されるわけではありません。

セキュリティやデータ取り扱いのポリシーは、最初からモデル選定の基準として機能させるべきです。また、アドバイザー型のアプローチにも限界があります。レビュー担当者が評価できるのは、自身が受け取ったコンテキストのみだからです。証拠が不足していたり、サブエージェントからの要約が弱かったりする場合は、依然として誤った判断を下す可能性があります。

判断が必要な箇所に最先端モデルのトークンを投入する

最も大きな改善は、コーディングエージェントをルーティングシステムとして扱うことから生まれました。

現在、私は最先端モデルを計画立案、曖昧な意思決定、エスカレーション、そして最終レビューに限定しています。一方、コストの低いモデルには、リポジトリの探索、要約作成、および日常的な実装作業を任せています。決定的なツールは、可能な限り検証を行います。

具体的なモデル名はすぐに変わっていくでしょう。つまり、ワークフロー設計において問うべき本質的な問いは、より耐久性のあるものでなければなりません。「このタスクのどの部分が高価な判断力を必要とし、どの部分が主にトークン消費で済むのか」という問いです。

ルーティングポリシーが真に改善として機能するのは、完了したタスクが以前と同じ重要なチェック項目をすべてパスする場合に限られます。

（本記事は Arize AI の「How I cut coding agent costs with model and harness routing」に初出しました。）