コーディングエージェントのモデル選びは機会コストで決める — Fable 5 Low・Codex 5.6 Sol Light を速度に振る理由

最近、コーディングエージェントで使うモデルの設定を、意識して軽いほうへ寄せています。Claude Code では Fable 5 を推論レベル Low で、Codex では 5.6 Sol を推論レベル Light・速度レベル Fast で回す。これが今の私のデフォルトです。以前は「せっかく賢いモデルがあるのだから、推論もたっぷり効かせたほうが良い結果になるはずだ」と考えて、重い設定を選びがちでした。その前提を、この数か月でだいぶ疑うようになりました。

きっかけは大げさな検証ではなく、日々エージェントを使い倒すなかでの手触りです。重い設定にして待たされる時間の割に、返ってくる答えの質が思ったほど変わらない。むしろ、軽い設定でさっと返してもらって、自分の目で見て直す往復を速く回したほうが、一日の仕事が前に進む。その実感を言葉にしてみると、トークンコストではなく機会コストでモデルを選ぶ、という一本の筋になりました。

いま、軽い設定をデフォルトにしている

まず現状の設定を具体的に書いておきます。Claude Code では Fable 5 を推論レベル Low で、Codex では 7 月 9 日に一般提供が始まった 5.6 Sol を推論レベル Light、速度レベル Fast で使っています。

ここで押さえておきたいのは、推論レベルと速度レベルが別のつまみだということです。推論レベルはモデルにどれだけ考える手数を使わせるかを決めるもので、Codex なら Light から Ultra まで段階があります。速度レベルはそれとは独立に、応答をどれだけ速く返すかを決めるものです。私はこの二つを、どちらも軽いほう・速いほうに寄せています。Claude Code の Low も同じく推論レベルで、Fable 5 が取れる推論の幅のなかでは軽いほうの設定です。

もう一つ大事なのは、軽い設定にしても使っているモデル自体は高知能な最新世代だ、という点です。推論トークンを絞るというのは、モデルを賢くない下位モデルに落とすこととは違います。同じ賢いモデルに、考える手数を短めに指示しているだけです。だからコード生成でも調査でも、素の理解力や引き出しの広さは十分に高いまま、返答だけが速くなる。この「賢さは据え置きで速度だけ上げる」という感覚が、今の設定選びの前提になっています。

もちろん、常に軽い設定でいいと言いたいわけではありません。後で触れるように、本質的に難しい場面では重い設定に振ります。ただ、一日の大半を占める普通のタスク、つまり実装の叩き台づくり、既存コードの修正、テストの雛形、軽い調査といった作業では、軽い設定を出発点に置くのが今のところ一番割に合っています。

速度と知能のトレードオフ

推論設定を選ぶという行為は、突き詰めると速度と知能のトレードオフをどこで取るかという問題です。推論トークンを多く使わせれば、時間はかかるが、より深く考えた答えが返ってくる余地がある。少なくすれば、速いが、考えが浅くなる余地がある。素朴に考えれば、重要な仕事ほど知能側に振るべきだ、という話になります。

私が以前重い設定を選びがちだったのも、この素朴なトレードオフ観に従っていたからです。せっかく高い推論能力があるのだから、それを使い切らないのはもったいない。時間が多少かかっても、質の高い答えが返るほうが結局は得だ。そう信じていました。

けれど、このトレードオフには暗黙の前提が一つ入り込んでいます。「推論を厚くすれば、そのぶん失敗が本質的に減るか、少なくとも失敗の性質が良くなる」という前提です。ここが実感と食い違い始めました。重い設定にしても、返ってきたコードを結局は自分で読んで確かめる必要がある。そして読んでみると、間違え方そのものは軽い設定のときと大して変わらない。トレードオフの天秤に載せていたはずの「知能側の見返り」が、思ったより軽かったのです。

ミスの傾向は推論トークンで大きくは変わらない

ここがこの記事の核心です。今の高知能モデルは、推論トークンを絞っても、ミスの傾向に大差がありません。

どういうことか。エージェントに任せた仕事が失敗するとき、その失敗にはいくつかの決まったパターンがあります。指示の前提を取り違える、既存コードの流儀を無視して独自のやり方を持ち込む、テストは通るが要件を微妙に外している、境界条件を一つ落とす。こうした失敗の傾向は、軽い設定でも重い設定でも、驚くほど似た顔で現れます。推論を厚くしても、まったく別の次元の安全なコードが出てくるわけではない。頻度が多少下がることはあっても、失敗の種類が入れ替わるわけではないのです。

これが実務上どう効くかというと、レビューの構えが変わらない、ということに尽きます。軽い設定の出力も重い設定の出力も、人間がレビューで捕まえるべき失敗の傾向は同じ。だから、私がコードを読むときにかける注意も、確認する観点も、ほとんど変わりません。言い換えれば、重い設定にしても「人間のレビューを省ける」ようにはならない。レビュー工数という一番高い人的コストは、推論を厚くしても軽くしても、そのまま残ります。

だとすれば、重い設定に払っている待ち時間は、いったい何を買っているのか。失敗の傾向が同じでレビューが省けないなら、追加の推論トークンで買えているのは「頻度がわずかに下がること」くらいです。その見返りは、待たされる時間に対して驚くほど小さい。トレードオフの天秤は、私が思っていたよりずっと速度側に傾いていました。

トークンコストより機会コストで決める

この気づきを、コストの言葉で言い直します。モデル設定を選ぶとき、私たちは二種類のコストを天秤にかけています。

トークンコスト: 推論トークンや API 利用にかかる、金額として見えるコスト。重い設定ほど高い
機会コスト: エージェントの返答を待つあいだ、人間の手が止まっていることで失われる価値。重い設定ほど待ち時間が延び、大きくなる

議論が生成 AI のコストに及ぶと、話はトークンコストに集まりがちです。1 リクエストいくら、月にいくら、と金額で見えるからです。けれど本当に効いているのはもう一方、機会コストのほうだと考えています。ミスの傾向が変わらずレビューが省けない以上、重い設定で買えるものは小さい。にもかかわらず待ち時間だけは確実に延びる。この延びた待ち時間のあいだ、人間の思考と判断が止まっている。そのほうが、トークンの金額よりよほど高くつきます。

だから私は、モデル設定をトークンコストではなく機会コストで決めます。軽い設定を選ぶのは、トークン代を節約したいからではありません。むしろ逆で、機会コストを削るためなら、多少トークンを余分に使う選択だってします。基準はあくまで、人間の手が止まる時間を最小にすること。ここに置いています。

ここまでの筋を、一枚のフローチャートにまとめておきます。

flowchart TD
    A["1 ターンのモデル設定をどう決めるか"] --> B{"軽い設定と重い設定で<br/>ミスの傾向は変わるか"}
    B -->|"大きくは変わらない<br/>どちらも人間のレビューで捕まる"| C["レビュー工数は同じ"]
    C --> D{"では何が変わるか"}
    D -->|"待ち時間 wall-clock"| E["人間の手が止まる時間"]
    E --> F["機会コストが支配的"]
    F --> G["軽い設定をデフォルトにする"]
    B -->|"本質的に難しいタスク<br/>設計・深いデバッグ"| H["傾向が変わり得る"]
    H --> I["重い設定に振る"]

機会コストが見えにくいのは、人間がボトルネックだから

機会コストがトークンコストより大事だと言っても、多くの現場でそう扱われていないのは、機会コストが見えにくいからです。トークンコストは請求書に金額で載る。けれど「エージェントを待つあいだに人間が失った価値」は、どこにも請求書として届きません。見えないから、つい軽視される。ここが厄介なところです。

では、見えない機会コストが本当に大きいと、どうして言い切れるのか。答えは、いまの開発において人間がボトルネックだという事実から自明です。コードを書く速さがエージェントによって制約でなくなった今、一日にどれだけ前に進めるかを決めているのは、人間が何を作るか見極め、生成物を読み、評価し、責任を持って世に出す速度のほうです。処理能力の上限が人間の側にある以上、そのボトルネックが一秒でも止まることは、システム全体のスループットが一秒ぶん止まることを意味します。

この見方に立つと、機会コストの正体がはっきりします。重い設定でエージェントが長考しているあいだ、ボトルネックである人間の手が止まっている。ボトルネックを止めることほど、スループットに直接効く損失はありません。トークンコストは、ボトルネックでない部分（機械の処理）にかかる金額の話にすぎない。ボトルネックである人間の時間を止めてまで節約したり、逆に厚くしたりする価値があるかどうかは、機会コストで測るしかない。人間がボトルネックだという一点から、機会コストが支配的だという結論は自動的に出てくるのです。

だから、軽い設定で速く返してもらい、人間のレビューと判断の往復を高速で回す。これは単なる好みではなく、ボトルネックを止めないための合理的な帰結だと考えています。

それでも重い設定に振る場面

ここまで軽い設定を推してきましたが、いつでも軽くていいという話ではありません。ミスの傾向が「大きくは変わらない」のは、ボトルネックが人間のレビューにあるような、普通のタスクの話です。次のような場面では、私は迷わず重い設定に振ります。

本質的に難しい設計判断: 選択肢が広く、トレードオフの評価そのものが仕事の中心になる場面。ここは推論を厚くすると、傾向そのものが改善することがある
深いデバッグや原因調査: 手がかりが薄く、長い連鎖を辿らないと真因に届かないとき。人間が追うより、じっくり考えさせたほうが速く正解に着くことがある
人間のレビューが効きにくい領域: 出力が正しいかを人間が短時間で判断しづらいとき。レビューで捕まえられない以上、生成側の質に頼る比重が上がる

要は、レビューがボトルネックなら軽く、モデルの思考そのものがボトルネックなら重く、という切り替えです。判断の軸は一貫していて、どちらのコストが支配的かを見て決める。デフォルトを軽い設定に置き、必要なときだけ重い設定に上げる。この非対称なデフォルトが、機会コストを最小にする実務的な落としどころだと思っています。

まとめ

コーディングエージェントのモデル設定をどう選ぶか、いまの私の考えを 3 点にまとめます。

ミスの傾向は推論トークンで大きくは変わらない: 今の高知能モデルは、軽い設定でも重い設定でも似た傾向で失敗する。人間がレビューで捕まえるべき観点は同じで、重くしてもレビューは省けない
だからトークンコストより機会コストで決める: 重い設定で買えるのは頻度のわずかな低下だけで、見返りは待ち時間に対して小さい。効いてくるのは金額に見えるトークンコストより、人間の手が止まる機会コスト
人間がボトルネックだから機会コストが支配的: 処理能力の上限が人間側にある以上、ボトルネックを止めることが最大の損失。見えにくくても機会コストが大きいことは、この一点から自明に導ける

道具がどれだけ賢くなっても、一日のスループットを決めているのは人間の側です。だから私は、賢いモデルをあえて軽い設定で速く走らせ、自分の手が止まらないことを最優先にしています。トークン代をケチるためではなく、見えにくい機会コストを削るために。

以上、ミスの傾向が推論トークンで変わらない以上、モデル選びはトークンコストより機会コストで決めるべきだと整理した、現場からお送りしました。