Baseten Gridが問う、コーディング作業一件を完了する費用はいくらか

コーディングエージェントが、失敗したテストを直すきれいな変更を出します。ところがCIで落ち、開発者はやり直しを頼みます。二度目はリポジトリの広い範囲が変わり、5分で済むはずのパッチにレビュアーが30分を費やします。どのモデルのほうが安かったのでしょうか。

Basetenは11月4日、Gridの公開プレビューを発表しました。承認済みモデルへのゲートウェイ、ルーター、使用量やガードレールの一元管理を組み合わせたサービスです。対応するコーディングツールとモデルの間に置くことで、依頼全体に共通の方針を適用できます。早期アクセスのページでは、希望するチームを待機リストへ案内しています。

分母を実際に受け入れた成果に置く

受け入れたタスク当たりの費用。Telli.sh制作。

トークン単価はモデル使用量の一単位に対する価格です。チームが提供すべきものは、受け入れ基準を満たした成果です。リクエストから回答が返り、実行で差分が出ても、作業は未完了の場合があります。これらを別々に数えてこそ、ルーティングの試験が役立ちます。

二つの経路に、似たタスクをそれぞれ100件渡すとします。安い経路はすべての試行に50ドルを使い、50件を受け入れ可能な状態まで終えます。もう一方は90ドルで90件を終えます。この例では受け入れ可能な成果一件当たりのモデル費用は、どちらも1ドルです。人のレビュー時間、ツール利用料、再試行を待つコストを足すと差が出るかもしれません。どちらに傾くかはタスク次第です。

失敗した試行も分子に入れます。難しい依頼を途中で断念する経路は、打ち切った試行が集計から消えると効率的に見えます。成功の定義も一定に保ちます。文書の修正なら差分の承認だけで十分かもしれません。移行なら既存データに対するテストと、元に戻す手段が必要です。

作業の種類によって難しさは違います。リポジトリ全体のAPI移行には、文脈の把握と調整、多数の小さな変更が必要です。微妙な並行処理のバグが絡むと、一行のパッチのほうが難しい場合もあります。ファイル数やプロンプトの長さは、自分たちの環境で成果を予測できるときに役立つ指標です。

ルーターの実験を費用と合格率の両方で読む

ルーティングの試験。Telli.sh制作。

Basetenの技術報告は、常にOpus 5.5を使う場合と、同モデルとGLM 5.3 Flashの間でタスクを振り分ける場合を比べています。DeepSWE、SWE Atlas QnA、Terminal-Benchを組み合わせた評価で、常にOpusを使う場合より費用が72%低く、合格率の差が0.8パーセントポイント以内となる設定を同社は報告しています。同程度の費用で無作為に割り当てた場合とも比べています。コイン投げで決めても、安いモデルへの割り当てを増やせば平均のモデル費用は下がるためです。

経路選択のしきい値は、期待できる成功にどこまで支払うかを表します。費用を重視すれば、安い経路に割り振る件数が増えます。成果が特に重要な場面では、別の設定で能力の高いモデルを優先できます。Basetenの結果には、同社が選んだモデル、タスク、価格の前提があります。チームごとに作業の分布も、失敗の代償も異なります。

製品発表では、初期のベンチマークで費用を最大70%削減したという、丸めた別の数字を使っています。技術報告の72%と、それに対応する合格率の比較は分けて読みます。技術報告から役立つのは、費用と成果がどう動くかです。重視するものに沿って設定を選び、実際の仕事でも効果が続くかを確認できます。

ゲートウェイで適用する方針を見えるようにする

Gridの発表では、承認済みモデル、チーム単位の制御、使用量の可視化が紹介されています。プラットフォームチームは、組織が評価済みのモデルを開発者に提供しながら、使われ方を把握できます。経路選択を委ねる前でも、どこにお金がかかっているかを調べる助けになります。

実務では複数の判断が必要です。どの事業者に社内コードを見せてよいか、特定のリポジトリで使えるモデルはどれか、再試行の予算をどのチームが持つか、障害後に誰が経路を上書きできるかです。管理者が制御の範囲を理解していれば、ゲートウェイを共通の判断箇所にできます。

モデルのゲートウェイとエージェントの実行環境は別々の制御点です。ゲートウェイはリクエストを受け取るモデルを決められます。認証情報を読めるか、ファイルを書き換えられるか、ネットワークへ接続できるかは、ツールや実行環境が決めます。経路の制限は、実行時の権限と組み合わせて役立ちます。安い経路でも、強い権限のツールには同じ制約が必要です。

証拠として何を残すかも決めます。ルーティングログは費用が変わった理由を説明する一方、追跡記録にコードやパス、顧客の障害に関する詳細が入る可能性があります。何を記録でき、誰が見られ、いつまで保持するかを決めます。開発者が方針を確認できないと、依頼が拒否されたり意外な経路に送られたりした際に、原因を調べにくくなります。

既定の経路を変える前にルーティングを試す

1. よくある作業を二、三種類選びます。定型的なテスト更新のような単純な作業と、後方互換性が必要な移行のような難しい作業を含めます。
2. 先に受け入れに必要な証拠を定義します。コーディング作業なら、回帰テストの合格、整理された差分、レビュアーの承認、想定外のファイル変更がないことなどです。
3. 現在の既定モデルを基準として記録します。失敗、再試行、開発者が手で終えた作業を含めます。本番と同じセキュリティとデータの制約を維持します。
4. 同等のタスクでルーティングを比較します。利用できる場合は、アカウントを接続する前に、公式資料でゲートウェイが対応するツールと権限を確認します。
5. いつ上位モデルに切り替えるかを決めます。初回の失敗をきっかけに二つ目のモデルを使えますが、無制限の再試行は最初から強いモデルを使うより高くつく場合があります。上限を決め、切り替えの理由を残します。
6. 誤った結果の影響が大きいタスクでは、経路を上書きできるようにします。試行後、費用と受け入れ率の集計に加え、例外も確認します。

社内で試すなら、開発者がモデルを選んだ期間とルーティングを使った期間で、似た作業を比べられます。前者はリポジトリを知る開発者の判断を生かせます。後者は方針の一貫性と可視性が利点です。作業の違いを記録すれば、自動化が効くところと、人の判断が役立つところが見えてきます。

条件をそろえた作業ログを読む

完了したプルリクエスト一か月分が出発点になります。依存関係の更新、再現テストがあるバグ、リポジトリをまたぐ変更、デプロイ失敗を調べる自由度の高い依頼など、当初の依頼で作業にタグを付けます。作業ごとにリポジトリのリビジョンと受け入れ条件を保存します。安定した基準とルーターでサンプルを再実行し、ツール、時間の上限、テスト環境をそろえます。

依存関係の更新は曖昧さの少ない例です。指定された依存関係が更新され、互換性の確認に通り、プルリクエストに無関係な変更がなければ成功です。課金の契約に関わる変更は、もっと厳格なレビューが要ります。不完全な要件を人が読み解くこともあります。作業の種類を分けると、どこで平均支出が下がったのかを把握できます。安い経路が依存関係の更新には強く、課金変更では繰り返し試行が必要なら、二種類を別々に振り分けられます。

成果を受け入れるかどうか、人が決める時間も記録します。基準モデルが19ドルで20件のうち19件、ルーターが9ドルで18件を受け入れ可能にしたとします。この例では、成果一件当たりのモデル費用は1.00ドルと0.50ドルです。ルーティングで失敗した一件をレビュアーがさらに20分かけて直すと、費用の比較は変わります。組織が使う指標に手直しを含めつつ、時間と金額は別々の測定値として扱えます。

ルーターが何を学習に使ったかを知る

Basetenの技術記事は、DeepSWE 1.1、SWE Atlas QnA、Terminal-Bench 2.1を挙げています。Claude Opus 5.5とGLM 5.3 Flashを複数のタスクで比べ、学習に使用しなかったデータでルーターを評価しています。どこまで一般化できるかを判断するうえで重要です。リポジトリ内の位置を尋ねる質問と、シェルや外部ツールを使ったり複数のファイルを変更したりする作業では、費用の構造が違います。顧客側の評価には、実際に送る予定のタスクを反映します。

技術記事によると、Cost、Balanced、Intelligenceは、リクエスト時にルーティングのしきい値を動かす設定です。これを利用して、実運用の外で比較できます。許可された同じ作業セットを再実行して設定を比較し、連携先が選択モデルを示すなら記録します。違いが出た例を調べます。高い経路が主にチームにとって機微な作業や難しい作業に選ばれるなら、方針が役立っている可能性があります。日常的で単純な作業に差が集中するなら、分類や方針を調整できます。

遅く高くついたケースまで見る

平均の遅延だけでは、複数のモデルを経由した難しいパッチを利用者が待った時間が見えません。依頼から成果の受け入れまでに実際にかかった時間を記録し、再試行、上位への切り替え、タイムアウト、引き継ぎを記録します。最初のモデルの応答時間しか出さないダッシュボードでは、担当者が再開しなければならなかった作業も成功に見えます。引き継いだ後の支出と時間を含めます。

広く有効にする前に、試行の上限を決めます。タスク全体の予算と、中止または上位モデルへ切り替える条件を決めます。失敗した試行には、次の試行が続きから始められる証拠を残します。別のモデルが選ばれただけで、テストを再実行したり同じファイルを読み直したりするのは避けます。重要なのは作業がどこまで進んだかです。

展開するなら、受け入れ条件を自動化でき、人が例外を調べられる範囲の狭い作業から始めます。次に、人の判断が必要な種類を加えます。受け入れたタスク当たりの費用、上位モデルへ送った割合、レビュー時間を別々に比べます。作業を変えても効果が保てるなら、既定の設定を決める根拠が増えます。

モデルが変わっても使える基準を残す

ある週に集めた結果は、モデルやツール、リポジトリが変われば古くなります。経路の判断と一緒に、モデル識別子、テスト対象のリビジョン、受け入れ条件を保存します。方針を変えたら、代表的なタスクを少数再実行します。費用のかさんだ失敗も何件か残しておきます。こうした費用は平均に埋もれやすいからです。

レビュアーには、どのモデルを選んだかを伏せて、経路ごとに結果が分かれたケースを見てもらいます。どの成果なら受け入れられるか判断できなければ、試行を増やす前に基準を見直します。チームで成功の判定に合意していれば、経路の方針も比べやすくなります。

仕事が変われば方針も見直す

ルーティングは、チームが同じ小さな判断を何度も繰り返す手間を減らします。性能と価格を同じ作業単位で測れるときに特に役立ちます。モデルも価格もリポジトリも変わります。ベンチマークのタスクを保存し、テストセットを更新すれば、ルーティングの方針も追随できます。

計画会議に持っていくべき数字は、チームが受け入れられる成果を届けるために支払った額です。何を引き換えにしたかも明示します。エンジニアリングと予算の責任者は、その数字を共通の根拠にできます。

出典

• Basetenの11月4日のGridプレビュー発表
• Basetenの11月4日のRouter技術報告

---

仕事の背景となる会話や判断を検索できる記録にするには、Telli.shのアカウントを作成してください。