請求書のCSVを読み込む処理で、空欄の金額があると集計が止まる。AIに修正を頼むと、一度目は空欄を処理できても、今度は正しい金額までゼロにしてしまった。こんなとき、同じモデルにもう一度テスト結果を渡すか、別のモデルに引き継ぐか。コーディングエージェントを使う人が手で決めていた判断です。
OpenRouterが2026年11月5日に公開した「Auto Code」は、この判断をコード修正の進み具合に合わせて行うルーターです。一つのモデルIDを指定すると、その先で回答を担当するモデルを選びます。以下のCSV修正は使い方を考えるための架空例です。公式モデルカード
テストがまた落ちたら、何が変わるのか
Auto Codeが手掛かりにするのは、エージェントとのやり取りに現れた編集内容、テスト結果、繰り返すエラーです。公式説明によると、作業が進んでいる間は同じモデルを維持し、つまずきが続くと、まず推論にかける労力を増やし、それでも必要ならモデルを切り替えます。切り替えるまでの失敗回数は公表されていません。日本語の公式説明
従来の汎用Auto Routerにも、セッションの進行を見てモデルを調整する仕組みがあります。Auto Codeの違いは、最初から各リクエストをエージェントの作業の一部として扱い、標準で高性能寄りのモデルから始め、コード変更の失敗を重く見ること。選択に使う指標として、開発元はコーディング課題の合格率、完了時間、解決1件あたりの費用を挙げています。汎用ルーターとの比較
| CSV修正で起きること | 担当する仕組み |
|---|---|
| 空欄を含む入力と期待する合計を決める | 開発者がテストを用意する |
| コードを編集し、テストを実行して結果を返す | 手元やサンドボックスのエージェントが担当する |
| テスト失敗を含む履歴を受け取り、次の応答を担当するモデルを選ぶ | OpenRouter側でAuto Codeが判断する |
テスト結果が端末に表示されただけでは、その内容はルーターに伝わりません。エージェントが失敗したテスト名や期待値・実際の値を次のやり取りに含められるかを確認します。入力例には架空の請求書を使えば、修正に必要な情報だけを渡せます。
APIキーを使わずに、まずモデルIDを確認する
公開カタログを取得して、正確なIDと料金欄を読み出せます。macOSやLinuxなどでcurlとjqが使える場合は次の2行を実行してください。作業ディレクトリにモデル一覧を保存します。これは一覧を読む操作で、モデルを呼び出す処理は含みません。公開モデル一覧
curl -fsSL https://openrouter.ai/api/v1/models -o openrouter-models.json && jq -e --arg id openrouter/auto-code '.data[] | select(.id == $id) | {id, created, pricing}' openrouter-models.json編集部が11月6日朝に取得した一覧では、IDは openrouter/auto-code、登録時刻を示すcreatedは1793884321（日本時間11月5日22時12分01秒）でした。公式が示すリリース日は11月5日で、発表時刻は不明です。料金欄は入力・出力とも文字列「-1」。料金の確認先はモデルカードで、実際に回答したモデルの単価でリクエストごとに請求されます。無料やマイナス料金として予算表に転記すると、見積もりを誤ります。
実際の推論にはOpenRouterのAPIキーと、接続先・モデルIDを指定できるクライアントが必要です。既存のエージェントでOpenRouter接続を選び、モデル欄に上記IDを指定します。公式料金表で自動ルーティングに対応するのはStandard、Business、Enterpriseで、Freeでは利用できません。EU域内で処理を完結させるルーティングにも現時点で対応していません。会社が設定したモデル・提供事業者の制限はAuto Codeにも適用されます。日本語で依頼した際の精度や特定のエディターとの互換性は今回の確認範囲外です。APIの導入手順・プランと料金
固定モデルと比べるなら、失敗した修正の費用も足す
「1回の応答が安かった」だけでは、任せたい仕事の費用は分かりません。たとえば異なる4件の不具合を一度ずつ依頼し、各件の上限内で何回でも修正できるとします。下表は比較方法を示す架空の数字です。集計するのは、モデルが応答したあとにテストが落ちた修正も含め、各課題で実際に発生した推論費です。クレジットの購入手数料はこの表の外に分けます。
| 設定（架空） | 4件分の推論費 | 合格した課題 | 解決1件あたり |
|---|---|---|---|
| 設定A | 0.24ドル | 2件 | 0.12ドル |
| 設定B | 0.36ドル | 3件 | 0.12ドル |
設定Bは合格数が1件多く、総額も高い一方、解決1件あたりの費用は同じです。合格ゼロなら分母がゼロになるので「算出不能」と記録します。失敗した仕事の総額と件数は残します。この指標には人間のレビュー時間を含めていないため、業務で選ぶなら、完了までの時間とレビューで差し戻した理由も横に並べます。
- 1比較用に同じ初期コードと受け入れテストを保存する。たとえば「空欄は除外・0は有効・数値以外はエラー」の3条件を先に決める。
- 2Auto Codeと普段の固定モデルで、同じ指示、同じツール権限、同じ時間・予算の上限を使う。設定ごとに初期状態から開始し、片方の修正例をもう片方に見せない。
- 3課題ごとにテストの合否、やり取り全体の推論費、経過時間を記録する。途中で予算に達したケースも残し、合格数と総額を集計する。
- 4同じ課題を複数回試すなら、各回を独立した試行にそろえ、分母を「合格した試行数」と明記する。少数の結果から他の仕事での優劣まで広げない。
金額列の空欄を含むと合計が出ない不具合を直してください。空欄は集計から除外し、0は有効な金額として扱い、数値以外の文字列は既存仕様どおりエラーにしてください。用意した受け入れテストは変更せず、実行したテスト名と結果を報告してください。修正が終わらなかった場合は、最後に失敗した入力と期待値を記録してください。本記事で確認したのは公開カタログの応答と、その内容を取り出すコマンドです。推論費・切り替え回数・修正成功率は実測していません。現場で試すなら、まず正解の分かる小さな修正を選ぶと、自分たちの仕事にとっての費用と合格率を同じ表で判断できます。