AI駆動開発 2026年7月3日

AIエージェントのコスト削減、「モデルを落とす」前に考えるべきこと — Critic役が教えてくれた設計の盲点

「モデルを使い分ければ安くなる」は半分だけ正しい

Xのタイムラインにこんな投稿が流れてきた。「Fable 5をオーケストレーターに据えて、OpusとSonnetをサブエージェントに使えばFableの消費を抑えられる」という趣旨のもので、具体的にはFable 5を最高推論のオーケストレーター、Opusを深い推論のサブエージェント、Sonnetを機械的な作業担当、Codexを異なる視点のピアレビュアーとして組み合わせる構成だ。

Claude Codeにも /model opus で計画フェーズだけOpusを使うオプションが最初から入っているくらいで、「頭を使う場所には上位モデル、手を動かすだけなら安いモデル」というのはすでに業界の定石になりつつある。まとめ記事によっては「これで4〜9割安くなる」という数字まで出回っている。

この記事を書いたhayua氏は、まさにこの定石を自分のマルチエージェント基盤で毎日回してきた人だ。そして「実際に運用してみると、定石だけでは足りない場面にぶつかった」という実体験を丁寧に記録している。その中身が、コスト削減を検討している人間にとって、かなり参考になる。

実際に何が起きたか——Criticを落としたらバグを見逃した

まず料金の前提を整理する。2026年7月時点での価格（入力/出力、100万トークンあたり）はこうだ。

Sonnet（Claude Sonnet 5）: $3 / $15
Opus（Claude Opus 4.8）: $5 / $25
Fable（Claude Fable 5）: $10 / $50

Fableの出力単価はOpusの2倍。思考が常時オンで、レビューやデバッグ、計画には頼りになるが、何も考えずすべての役をFableで回すと「30分で$100のサブスク上限に達した」というのが著者の実体験だ。

そこで著者はモデルを役割ごとに割り当てた。Orchestratorは人が選ぶ、PlannerはFable、WorkerはSonnet（複雑なものだけOpus）、CriticはFable。Workerを安いモデルにするだけでもコストはかなり落ちる。ここまでは定石通りで、大きな問題はない。

問題はCriticだった。「いちばん呼ばれる役だし、ここを安くできれば効きそう」という判断でOpusに落とした。結果、OpusのCriticが素通りさせたバグを、まったく同じコードをFableにレビューさせたら見つけた。

著者は「n=1の話なので鵜呑みにはできない」と留保を置いている。ただ、理屈としては腑に落ちると述べている。深いレビューの核心は「チェック項目を順番に確認する」作業ではなく、「コードを読みながら何かが引っかかる瞬間」にある。既存コードとの噛み合わせや、暗黙に守られていた前提が崩れているといった「言われないと気づかない」類の問題は、モデルの地力がそのまま出る。Criticを安くすると、いちばん拾ってほしいバグから先に取りこぼす。

2つの「きれいに見えたが外れた」案

CriticはFableのままにする、でもトークンが爆発する。この行き詰まりから、著者は2つの案を試した。どちらも最終的には外れた。

「git diffだけ渡す」案: 全ファイルを読む代わりに差分だけ渡せばコンテキストが減る、という発想。既存の大きいファイルを数行いじるだけなら確かに有効だ。ただし著者の仕事は新規開発が中心で、新規ファイルはgit diffに全行が + で出る。つまり差分イコール全文になってしまい、何も減らない。

「書き手の一段上のモデルでレビュー」案: Sonnetが書いたらOpusがレビュー、OpusならFable、という割り当て。整然として見える。が、「Opusは同じコードをFableより見逃した」という事実は、誰が書いたかとは関係なくレビュアー単体の実力差だった。書き手の難しさを軸にレビュアーを決めるのは軸がずれている。しかも書き手はほとんどSonnetなので、この案だとOpusレビューが多数派になる——見逃す実績のあるモデルを主戦力にしてしまう。

ここで著者は一度立ち止まって「そもそも何が爆発しているのか」を考え直した。コードではなく、ビルドエラー時のコンパイラの連鎖エラーやスタックトレースが、コードの何倍もの量になって流れ込んでいたのではないか、という仮説だ（著者は「設計相談で聞いた見積もりで実測ではない」と正直に書いている。この留保は大事だ）。

結局たどり着いた設計——モデルじゃなく入力を分ける

考え直しの結果、著者がたどり着いたのは「モデルを落とすのではなく、渡す入力を減らす」という方向転換だった。検証ゲートを3段に分けた構造がこれだ。

Stage1 Worker（sonnet / 複雑なやつだけ opus）
 実装する

Stage2 収集役（sonnet・判断はしない） ← 節約の肝
 テスト・tsc・ビルドを走らせて、
 生ログを「exit code ＋ 失敗箇所の抜粋」に畳む

Stage3 Critic（fable）
 コードは自分で読む（ここは減らせない）
 テストは再実行せず Stage2 の結果を使う
 合否を出す

要するに「判断のいらない重い入力（生ログ）は安いモデルに畳ませて、判断のいるコードだけをFableに読ませる」。ログを要約するのは判断ゼロの単純作業だからSonnetで十分だし、コードを読む工程だけはFableに残さないと最初の「見逃す」問題が戻ってくる。

ひとつ細かいが重要な実装上の工夫として、exit codeは生の値のまま通すことにしている。Sonnetが「だいたい成功」のように丸める事故を防ぐためだ。数値は要約でごまかせない。

さらに粒度の上限も設けた。1タスクの新規・変更行が600行を超えたら、Fableを呼ぶ前に「大きすぎるから分割して」と計画側に突き返す。どう工夫してもコードそのものの量は読まなければいけない以上、タスクの粒度を小さくするのが最後の砦になる。

なお著者は「この3段化はまだ設計を通しただけで、どれだけ削れたかは測っていない。数字が出たら追記する」と書いている。これは正直な記述で、記事全体の信頼性を高めている。

構造として読むと何が見えるか

ここからは私見だが、この記事が指摘していることには業界全体に通じる構造的な示唆がある。

「モデルの階層化でコストを下げる」という話は、現時点では「上位モデルは高い、下位モデルは安い、だから賢い割り振りをしよう」という価格差の話として語られることが多い。しかし著者がたどり着いた「何をどれだけ渡すか」という設計レイヤーは、それとは別の問いだ。

モデルの賢さを変えるのではなく、モデルが処理しなければならない情報量・情報の質を変える。これはある意味、人間のチームマネジメントにも似た発想で、「優秀な人間に雑多な情報を全部読ませるな、要約してから渡せ」という話でもある。ただし人間と違って、AIはその要約プロセス自体を別のモデルに任せることができる。そこに設計の自由度がある。

Fableが「Opusが集めた証拠にはOpusが見逃したバグの痕跡がそもそも写っていない」と指摘したエピソードは鋭い。これは「下位モデルにフィルタリングさせた証拠を上位モデルが判定する」構造の根本的な問題を突いている。収集と判定を分けるなら、収集段階での情報損失を設計として意識しなければいけない。exit codeを生で通すという細かい工夫は、まさにその意識の産物だ。

実務で使える判断軸

「AIエージェントのコストを削減したい」という文脈でこの記事を読んだとき、持ち帰れる判断軸は大きく2つある。

1. 役割ごとに「落とすと何を失うか」を確かめてから落とす

Workerを安いモデルにするのはほぼ安全だが、Criticを落とすと品質の保証が揺らぐ。「いちばん呼ばれる役だから節約効果が大きい」という論理は、「いちばん呼ばれる役だから見逃しの影響も大きい」という裏面を持っている。コスト削減の提案を見るとき、「その役を下げると何の品質保証が落ちるか」を最初に確認する習慣が要る。

2. モデルの割り当てより先に「入力の設計」を見る

高いモデルに大量のログを垂れ流すのは、頭の良い人間に雑務を全部やらせているのと似ている。「どのモデルを当てるか」の一段下に「何をどれだけ渡すか」がある。この観点で自分のパイプラインを見直すと、意外なところに削れる部分が見つかる可能性がある。

加えて、著者がFableに設計をレビューさせて「初案があっさり却下された」という話は、AI活用の実務的な使い方として参考になる。高いモデルを「使い所を絞った上で敵対的に使う」というのは、コスト削減と品質担保を両立させる一つの現実解だ。「Fableに訊けば正解が出るわけではない」という著者の留保も含めて、そのまま使える知見だと思う。