Claude CodeとCodex、どのモデルを使う？ 実行時間・成功率・Quotaを記録して選ぶようにした
Claude CodeやCodexを使っていると、Low / Medium / Highのどれを選ぶかを毎回感覚で決めがちです。難しそうなら強いモデル、簡単そうなら軽いモデル、と考えるものの、作業が終わったあとに「本当にその選択でよかったのか」を振り返る材料は残っていませんでした。
そこで最近は、AI coding agentの実行結果をexecution observationとして記録し、次のmodelやeffortを選ぶときの材料にする方法を試しています。まだ十分な統計的検証を終えたわけではありませんが、自分の作業を少しずつ測れるようにする取り組みです。
なぜ「常にHigh」ではないのか
すべての作業に最高性能のmodelやHigh effortが必要とは限りません。軽い調査、小さな修正、テストの追加、複雑な設計判断、数週間から数か月の方向を決める判断では、必要な文脈理解や検証の深さが違います。
私の現在の考え方は、modelの強さを目的にしないことです。1〜3時間程度のcheap testで間違いを潰せる作業なら、まずMedium以下で十分かを見ます。一方、後戻りのコストが大きい設計や運用方針の判断では、StrongなmodelやHigh effortを候補にします。これは固定ルールではなく、実行結果を見ながら見直すための仮説です。
記録している項目
現在のAgent Model Advisorでは、実行後に次のような項目をローカルのJSONLへ記録しています。
- task
- agent
- model
- effort
- elapsed time
- PASS / PARTIAL / FAILなどのresult
- quotaのbefore / after
- recommendationとの関係
- notes
Recommendation IDを取得していない実行も、unpaired observationとして保存できます。事前の推薦に従ったかどうかと、実際の実行結果を分けて残せる点が重要でした。後から都合よく「このmodelが良かった」と解釈しないためです。
Quotaで少し苦労した点
Quotaの画面表示は、providerや画面によってUSEDとREMAININGが混在します。そのため、beforeとafterの数字だけを引き算するのではなく、表示の向きを一緒に保存し、内部ではremainingへ正規化してから差分を計算しています。
例えばremaining表示で87から81になった場合は、観測された消費は6 percentage pointsです。used表示で56から73になった場合は、同じく17 percentage pointsです。表示が80から80のように同じだった場合は、消費ゼロと断定せず、画面の表示粒度では分からなかったものとして扱います。
Quotaの値は実行効率や料金そのものではありません。Claude CodeとCodexのquotaを合算することもできません。現在の残量を判断するためのlive snapshotと、過去の実行でどれくらい変化したかというobservationは、別の情報として扱う必要があります。
実際に見えてきたこと
2026年9月13日時点で、保存済みのexecution observationは98件です。結果の内訳はPASS 90件、PARTIAL 5件、BLOCKED 3件でした。これは私の作業記録であって、model間の公平なベンチマークではありません。taskの難しさや入力の違いがあるため、数字だけで優劣を決めることはできません。
それでも、同じmodelの異なるeffortを見比べると、考える材料は増えます。例えばGPT-5.6 Lunaでは、Mediumが17件で17件ともPASS、Highが7件で6件PASS・1件PARTIAL、Lowが2件で2件ともPARTIALでした。Mediumの方が常に優秀という意味ではありませんが、少なくとも「難しそうだから毎回High」という選び方を検証するきっかけにはなります。
同じように、Claude Sonnet 5のLowは25件中23件PASS・2件BLOCKED、Mediumは21件中20件PASS・1件PARTIALでした。ここでもtask条件が揃っていないため、単純な勝敗にはできません。実行時間もmodelだけで決まらず、入力の量や確認作業の有無に左右されます。
このように、elapsed timeだけを見ても不十分です。result、effort、taskの種類、必要だった検証、quotaの観測状態を一緒に残して、同じまたは近いtask familyで比較する方が現実的です。
Agent Run Regression Ledgerへの発展
execution observationが溜まると、「今回の実行は以前より良かったのか」も比較したくなります。そこで、Agent Run Regression Ledgerという小さなprototypeも試しています。
2つのrunについてelapsed delta、resultの変化、quota burnの変化、model / effortの違いを並べ、PASSからPARTIALならregression候補、PARTIALからPASSならimprovement候補として表示します。同じ結果でも時間が大きく増えた場合はefficiency regression candidate、同じ結果でquota burnが減った場合はefficiency improvement candidateとします。いずれも断定ではなく、次に確認するための候補です。
この比較は、Agent Model Advisorの推薦機能とは役割が違います。Advisorは「このtaskにどのagent/model/effortを使うか」を考える道具で、Ledgerは「実際に実行したrunを比較して、何が変わったかを理解する」道具です。
読者が簡単に始める方法
専用ツールを作らなくても、最初はCSVやスプレッドシートに次の列を作るだけで始められます。
date | task | agent | model | effort | elapsed_seconds | result | quota_before | quota_after | notes
大切なのは、実行直後に記録することです。taskの概要、使ったmodelとeffort、経過時間、結果、次に同じ作業をするときの注意点を残します。QuotaはUSEDかREMAININGかも書きます。同じ数字だった場合は、0消費ではなく「表示解像度以下」と記録します。
数件だけでは傾向は分かりません。まずは同じrepoのテスト修正、似た種類の調査、繰り返し行うレビューなど、比較しやすい作業を少しずつ蓄積するのがよさそうです。異なるtaskを無理に比べて、modelやeffortの一般的なランキングを作らないことも大切です。
まとめ
目指しているのは、最強のmodelをいつも選ぶことではありません。自分のtaskに必要十分なmodelとeffortを、実行結果から少しずつ学習することです。
現時点では98件の観測があるものの、まだ自分の運用に限った初期データです。今後もtaskの種類、結果、時間、quotaの観測状態を記録し、同じ条件に近い実行を比較しながら、強いmodelを使うべき判断と、軽いmodelで十分な作業を分けられるか試していきます。