費用対効果が最適なモデルはどれ？
Legalscape の中山です。もしあなたが私と同じことを考えているのなら、以下の疑問を解決したいと思っているはずです。
- ある問題の難しさを決定できるとき、その問題を解くために必要最低限の性能を持つモデルのうち最も安いものはどれか？
さてどれでしょうか？最近は GLM-5.2 や Kimi K2.7 Code、Minimax M3 といったオープンウェイトのモデルが登場し、GPT-5.5 に費用対効果で肉薄しているというのが巷間での噂です。
少し丁寧に数字を見てみましょう。
これは Artificial Analysis Intelligence Index のスコアです。この指標はモデルの性能を広範な領域で比較するために様々なベンチマークスコアを加重平均しており、スコアが高いほど総合的な性能が高いことを示します。
これを見ると、オープンウェイトモデルでは GLM-5.2 は max effort で 51 ポイントであり、GPT-5.5 (medium) を 1 ポイント上回っています。 Minimax-M3 と DeepSeek V4 Pro (max) が 44 ポイント、Kimi K2.7 Code (max) が 42 ポイントです。
費用対効果はどうでしょうか。
これはタスク1件あたりの加重平均コストです。プロットの左上に行くほど理想的です。あるインデックススコアを達成するために必要なコストが最安のモデルを結ぶとパレートフロントになります。パレートフロントはスコア昇順で以下のモデルが形成しています。
| スコア | タスクあたり | 入力 | 出力 | |
|---|---|---|---|---|
| DeepSeek V4 Flash (max) | 40 | $0.020 | $0.14 | $0.28 |
| MiMo-V2.5-Pro | 42 | $0.031 | $0.435 | $0.87 |
| DeepSeek V4 Pro (max) | 44 | $0.045 | $0.435 | $0.87 |
| Gemini 3.1 Pro Preview | 46 | $0.291 | $2 | $12 |
| GPT-5.5 (medium) | 50 | $0.344 | $5 | $30 |
| GLM-5.2 (max) | 51 | $0.523 | $1.40 | $4.40 |
| GPT-5.5 (high) | 53 | $0.610 | $5 | $30 |
| GPT-5.5 (xhigh) | 55 | $0.863 | $5 | $30 |
| Claude Opus 4.8 (max) | 56 | $1.797 | $5 | $25 |
| Claude Fable 5 (with fallback) | 60 | $2.750 | $10 | $50 |
入力、出力は1Mトークンあたり料金です。
ただし、パレートフロント上のモデルは必ずしも交換可能ではないことに注意が必要です。性能が足りなければいくらトークンを費やしても問題を解けないことがあります。そのためモデルの性能は調整可能な軸ではなく、選択肢をフィルターする閾値として捉えるほうがより正確です。
表を見ると、 MiniMax M3 や Kimi K2.7 Code が入っていませんね。この2つは単価は安いですしスコアは悪くないのですが、同じかそれ以上のスコアをより安い費用で達成できるモデルがあるため、パレートフロントには入っていません。（厳密には MiniMax M3 のスコアは DeepSeek V4 Pro (max) よりもわずかに高いようです。）
また GLM-5.2 のコストが意外と高いと思われるかもしれません。トークン単価はプロプライエタリなモデルよりも安いのですが、 GLM-5.2 はタスクを完了するために消費するトークン数が多い傾向があるようです。
コーディングエージェントに限るとどうでしょうか。 AA は Coding Agent Index という指標も公開しています。これは DeepSWE, Terminal-Bench v2, SWE-Atlas-QnA という焦点の異なる3つのベンチマークそれぞれを実行し pass@1 スコアを単純平均しています。
エージェントの性質上ハーネスも組み合わせに入っています。また現時点ではインデックスに載っている組み合わせが少ないです。
それもあってか、このインデックスではパレートフロントにはほぼ定番のメンツしか入っていません。 Composer 2.5, Opus 4.7, GPT-5.5, Fable 5 といったところです。
注目の GLM-5.2 は今ひとつ振るっていません。 Kimi K2.7 Code や MiniMax-M3 は載っていません。
Coding Agent Index だけをみると少々情報不足の感があるため、いくつかのモデルについて、 Coding Agent Index を構成する3つのベンチマークそれぞれを詳しく見てみましょう。
DeepSWE では、 GLM-5.2, K2.7 ともにあまり芳しくありません。GPT-5.5 や Opus 4.8 はそれらと同じかもっと安いコストでより高いスコアを達成しています。MiniMax-M3 は載っていません。
Terminal-Bench v2.1 では Kimi K2.7 Code がパレートフロントに入っています。費用と性能は GPT-5.5 (low) とほぼ同じです。ただ、スコアは MiniMax-M3 や DeepSeek V4 Pro/Flash, Xiaomi の MiMo-V2.5-Pro などと数ポイント程度の差しかなく、費用の上昇に対して性能のゲインは小さく留まっています。 GLM-5.2 は GPT-5.5 (high) の近傍にいるものの、惜しくもパレートフロントには入っていません。
SWE-Atlas-QnA では、 Composer 2.5 が 72 というスコアかつ 1.7M トークンで圧倒的なコストパフォーマンスを発揮しています。input/output を 99/1 とした場合、$0.50/M input, $2.50/M output なのでおよそ $0.9 にしかなりません。 Qwen3.7 Plus がそれに続いています。 GLM-5.2 (in $1.4, out $4.4) はもう少しスコアは高いですが、トークン消費量と単価の高さにより費用対効果は低く、Cursor & GPT-5.5 (medium) のペアとほぼ同じコストでスコアは負けています。 Kimi K2.7 Code と MiniMax-M3 は載っていません。GPT-5.5 xhigh や Opus 4.7/4.8 のスコアは当然高いものの、費用は文字通り桁違いです。
なお、 Cursor の Composer 2.5 がこれらのインデックスで評価対象に入っているのは嬉しいのですが、 CursorBench で主張されているほど高い性能は出ていないようです。これは Composer 2.5 はあくまでコード生成を射程としているという制約から来るものかもしれません。しかし Cursor は今また新たなモデルをスクラッチでトレーニング中で、新モデルはより long-horizon でも戦えそうです。数週間以内にリリースするそうなので、安くてそれなりに性能が出る選択肢が増える（かもしれない）のは楽しみですね。
オープンなモデルは低・中価格帯でがんばっている
これらを総合すると、以下のような傾向があると言ってよいかと思います。
低価格帯: まず冒頭の Intelligence Index におけるタスクあたりコストが $0.1 前後もしくはそれ未満の低価格帯においてはオープンウェイトモデルの独擅場となっており、この価格帯で出せる性能で十分なタスクにおいては DeepSeek や Kimi のモデルを湯水の如く使ってもまさに水道代程度しかかからないという状況です。
中価格帯: もう少し高い $0.1〜$1 あたりに相当する中価格帯においては、 Gemini 3.1 Pro Preview や GPT-5.5 (medium) といったクローズドなモデルも費用対効果では意外と健闘しています。業務利用では利用規約やデータの取り扱いに注意する必要があるため、このあたりの価格帯で費用対性能比のよいプロプライエタリなモデルがファーストチョイスになることは多いでしょう。他方で GLM-5.2 (max) などのオープンウェイトモデルも確かにパレートフロントに追いついてきており、条件次第ではそちらを選ぶこともあり得ます。
高価格帯: $1 を超える高価格帯は GPT-5.5 xhigh や Opus 4.8 max, そして Fable 5 といったハイエンドモデルしかなく、どれだけの費用でどれだけ性能の上限を求めるかという話になります。特に困難な問題を解くときにはこのあたりのモデルが必要になることもあります。
すなわち、特に困難なタスクを除けば最新のオープンウェイトモデルが費用対効果の面で十分選択肢に入ってきていると言えます。
これは optionality という意味でも歓迎すべきことです。プロプライエタリなモデルに比肩する性能を持つオープンウェイトモデルがあれば、 OpenAI や Anthropic がいつ値上げをしたり輸出規制されたりしても、他のプロバイダーで代替できます。いざとなればクラウドや物理クラスターでセルフホストもできます。*1
普通のタスクは既にコモディティ化したモデルで十分であり、今後出るモデルを採用するとしたら、より困難でこれまで解けなかった問題を解けるようになった場合か、既に解ける問題をより安く速く解けるようになった場合に限られるでしょう。プロバイダーもそのようなスイートスポットを狙ってモデルを出してくるはずです。*2
で、なんでこんな話を書こうと思ったのか？
6月18日に Ramp から出た記事に書きたかったことが書いてあったのでそちらを読んでいただいてもいいのですが、要はAIのオーケストレーションをする上でなるべく費用を抑えたいですよねという話です。
以下に色々書きましたが、ともすれば1ヶ月後にはオーケストレーション自体不要なモデルやハーネスを OpenAI か Anthropic が出してもおかしくはありません。（と思っていたら Claude Tag という機能がリリースされてしまいました。）Linear や Devin、そしてもちろん GitHub もオーケストレーターになろうとしているので、自作するのとどちらが TCO が安いかは悩ましいところです。
しかし最終的な評価は社内の実際のタスクで測った方が精度がいいでしょうし、コーディング以外まで視野に入れたオーケストレーターは半年くらいは評価が定まらないのではないかと思います。統合すべきものが多い上、ツールを繋いだから ok とはならず、社内の業務の調整から入る必要があります。そしてそのようなオーケストレーションこそが必要なものだと思います。オーケストレーターの入手ではなく、オーケストレーションを実現することが切に求められていると考えています。水道はもう流れるようになったので、あとはそれを使って業務を回し、自己改善していく仕組みが必要です。
Ramp やメルカリ、そして Nadella 氏など多くの人がそのようなナラティブを共有しているように思います。オーケストレーターがあれば解決ではなく、トップの意思決定が必要です。
先日、 OpenClaw の開発者である Steinberger 氏が「もはやプロンプトではなくループを設計すべきだ」と述べたことが話題になりました。Claude にもループ的にタスクを回すための /loop コマンドが3月には登場し、 OpenAI の Symphony も3月にはリポジトリが存在しています（blog記事が出たのは4月末）。 Claude Code を作っている Boris Cherny 氏も「もうプロンプトは書いていない」そうです。LayerX も「アンビエントなAI」を目指していると述べています。
これらに共通しているのは、AIを人間が直接面倒見るのではなく、バックグラウンドで継続的に動かそうとしている点です。仕事が発生した時点でAIが自律的に処理を始め、人間が見るべき状態まで進めておくというものです。
個人的にもAIに対して人間が毎回わざわざ指示を出さずともいつのまにか仕事を進めておいてくれるのが理想だと思っています。AIには「あなたはこういうことをやりたいんじゃないですか。もうやっておきましたよ」というように、バックグラウンドでいつの間にか処理が終わっている状況を作って欲しいと思っています。
そのようにAIを運用することをオーケストレーションと呼ぶのであれば、オーケストレーションはハーネスエンジニアリングをさらに進めたものだと言えます。以前このブログでも takt というオーケストレーターを紹介しましたが、今回は OpenAI が spec とリファレンス実装を公開している Symphony について軽く触れておきます。
Symphony は、たとえば Linear のチケットに特定のラベルが付いたことを検知し、対象チケットに対してAIエージェントを動かすことができます。一定間隔でポーリングし、処理すべきチケットかどうかを判定します。
ポーリングしているだけの間は、言語モデルが呼び出されません。決定論的なプログラムが「このチケットは今AIが処理すべき状態か」を見ているだけなので、ここではコストがかかりません。
そして、処理すべきチケットだと判定されたタイミングで、AIにワークフローを記述した Markdown ファイルを渡し、その手順に沿って作業させます。最終的にプルリクエストを作成できたときや、人間の介入がないと先に進めない状態になったときに、チケットを自動的に「人間のレビュー待ち」という状態へ移動します。
人間がチケットを見て、AIに依頼するのではありません。チケットの状態遷移そのものがAI実行のトリガーになります。そしてAIは、人間のレビューや判断が必要になるまで作業を進めます。
自分でも Symphony に似た仕組みとして、レビューリクエストが来たときに、概要や既存のコメントを整理し、「自分が何を見るべきか」をまとめたレポートを生成する仕組みを作ってみました。また、社内の問い合わせに自動で一次応答を返す仕組みも作ってみました。
こうした仕組みを作ったり使ったりしてみると、AIオーケストレーションの可能性はまったくコーディングに留まるものではなく、より広く業務全体に影響を与えるものであるということが実感できました。
経済性は無視できない
一方で、オーケストレーションによってバックグラウンドでAIを使う場合、個人レベル以上のコストは避けて通れません。
会社員として開発をしている以上、与えられた予算や利用枠の中で運用する必要があります。Codex や Claude Code といったコーディングエージェントであれば、1日あたり、1週間あたりのクォータがあります。
では、AIオーケストレーターを一晩中起動させっぱなしにできるかと考えたとき、クォータが消費し尽くされるのではないかという不安がなかなか大きくなってきます。
Symphony を試した感触では、軽いタスクでも一定のクォータを消費します。大きめのタスク、たとえば数百行から1000行程度の変更になると、消費量はさらに大きくなります。
コーディングエージェントの特徴として、最終的な変更量が小さくてもワークフローやリポジトリのコンテキストを渡すだけで入力トークンが増えることが挙げられます。リポジトリが大きい場合や、ワークフロー自体が複雑な場合、小さなタスクでも相応のコストがかかってしまうわけです。
これが常時または定期的に動くとなれば、個人レベルの支出管理では済まなくなってきます。そもそもオーケストレーターは個人ごとに動かすより、チームで共通のものを運用するほうが全体最適であり、コストもチームや組織の単位で考えるべきものになります。
すべてのタスクに最上位モデルは必要ない
どうすればAIオーケストレーションの費用を抑えることができるでしょうか。
まず、すべてのタスクに最上位のフロンティアモデルが必要なわけではありませんね。
たとえば、レビュー前のレポート作成では、人間がどのプルリクエストに対してどれくらいの注意力を払えばよいのか整理できれば十分であり、ベストではなくともそれなりの性能のモデルでもこなせます。同様に、問い合わせの分類、チケットの重複判定、ログの一次整理、軽微なコード修正の候補提示なども、必ずしも最上位モデルである必要はありません。
またバックグラウンドで動くAIでは、多少レイテンシーがあっても許容できます。人間が画面の前で待っているわけではないからです。そのため、たとえば GPT シリーズであれば、 flex ティアや batch API といった手段によって API 費用を半分に抑えられます。
しかるに、ある程度の推論能力があり、安く、安定して呼び出せるモデルには価値があります。
ここで、 Symphony のようなオーケストレーターを使うとしてもその裏側で使うモデルはもっと安くできないのかという問いが立ちます。冒頭のモデルごとの費用対性能の検討は、まさにそのような疑問のごく一部に答えるためのものです。
もちろん、安いモデルを使えば常に得をするわけではありません。安価なモデルを使った結果、AIや人間が何度も修正しなければならないなら、全体のコストはむしろ高くなります。
コストパフォーマンスにおいて見るべきなのは、単純なトークン単価だけではありません。タスクが完了するまでに必要なターン数、人間の介入回数、手戻りの量、レビュー負荷、マージまでの時間を含めて考える必要があります。
特に、一定以上の複雑なタスクを不十分な性能のモデルで解くのは困難であり、トークン単価の安さに見合わない結果が得られるのはおかしくありません。
最も確実にコストパフォーマンスを推定するには、実際に社内のタスクを解かせてみることです。
弊チームでは symphony を動かしはじめており、そのためのモデルを選定しました。
まずは簡易に測定するべく、リファレンス実装に手を加えたもので素直に GPT ファミリーを使っています。モデルファミリー内であれば以下のようにモデルとエフォートの組み合わせをおおよそ比較できます。
現時点では、一旦 5.5 medium, 5.4 medium, 5.4-mini medium の3つのモデルとエフォートの組み合わせを使い分けることで、コストと性能のバランスを取っています。なるべく費用を抑えたいのでデフォルトは 5.4 とし、難しそうなタスクは 5.5, 非常に簡単なタスクは 5.4-mini を使うようにしています。実証段階であり、コストパフォーマンスのデータが蓄積していくにつれ調整していく予定です。
コードが速くなれば会社は速くなるのか
コードを書く速度は上がりました。しかし、それだけでは必ずしもチームや組織全体が速くならないという問題があります。
これは Legalscape のコアとなるモノレポの、1人あたりのスループットの推移です。マージ数が生産性そのものを示すわけではありませんが、量的にはこれまでにないスピードでコードが書かれ、マージされていると見ています。
この指標にはコードの生成速度だけでなく、レビュー速度も表れています。生成だけを速くしても、レビューが追いつかないとマージされず全体のスループットは上がりません。むしろ、未レビューのプルリクエストが増え、仕掛かり品在庫として積み上がってしまいます。
まずは人間がレビューするコストを下げることが重要です。自明なレビューはすべて機械的な処理で終わらせ、非自明なレビューだけを人間がやります。現状では Devin Review や Linear のレビューガイド、自前のレビューツールで負荷を下げています。
そして最も重要なのはその先、チームや会社の成果そのものへの貢献とその測定です。レビューを速くするだけでは、ボトルネックが生成からマージへ、さらにその先へと移動するだけです。またAIで開発が速くなりますというだけでは費用は正当化されず、投資対効果を測定して企業価値増加に貢献することを示さなければなりません。理想は、ディスカバリ、実装、検証、展開というバリューストリーム全体をエージェントがこなせるようにすることです。
ディスカバリでは BI やテレメトリ、ナレッジベースと接続することで、何が売りやすく何が売りにくいのかを把握し、ユーザーストーリー上の離脱ポイントを特定する。商品仕様や既存実装と突き合わせ、打ち手の制約を洗い出す。改善や新機能をアルファ版として実装し、テックタッチなリサーチの結果をもとに商品仕様を検証する。誰のどんなペインにどう訴えるかという訴求軸やチャネルを設計し、対象ユーザーへ展開し、反応を計測して成功した施策を拡大する。人間は責任が発生するポイントにだけ関わる。大風呂敷ではありますが、そこまでやって初めてボトルネックは解消するのではないでしょうか。
これも巷で言われていることではあり、例えば Warp の CEO である Lloyd 氏は工場の概念を引き合いに出し、ソフトウェアビジネスの最終形は工場事業であり、全体論的な見方をすべきだと述べています。
また、 Nadella 氏は、企業は自己改善するエージェンティックシステムや模倣が困難な学習ループを囲い込むべきだと述べています。これは、モデルがコモディティ化する一方、企業内部の固有知識を蓄積・再利用する費用も下がるため、企業は学習資産の内部化によって良質なトレーニングシグナルという持続的優位を得、規模と価値を拡大できるという解釈ができるのではないでしょうか。
そうしたトレーニングのループを社内で育てるには、バリューストリーム全体をエージェントオーケストレーションでつなぐ全社的な取り組みが必要であり、トップダウンの意思決定と取り組みが欠かせません。とはいえ、足元ではボトムアップで何ができるでしょうか。
たとえば、お客様からの問い合わせや社内からの問い合わせが届いたらすぐ、AIが分類、要約、重要度判定を行うことが考えられます。それが障害報告なのか、仕様確認なのか、機能要望なのかを軽量なモデルで判定する。一定以上クリティカルなものについては、より高性能なモデルに渡し、対応方針の案を作らせる。分析は安価なモデルが得意とするところであり、レポートの形でアウトプットすれば十分であることからバックグラウンド処理に向いています。
難しいのは、その先の実行です。実務との接続が必要になってきます。実際にチケットを作る、コードを変更する、顧客に返答する、設定を変えるといった操作には、権限、責任、監査、エラーハンドリングが必要になります。
そのためには業務システムとの接続、権限管理、承認フロー、ログ、ロールバック手段などを含めた業務フローとハーネスの作り込みが必要です。
ということで、 Legalscape の採用情報はこちらです。会社全体を動かすオーケストレーションを作りたい方はぜひ。
*1:もっとも、昨今の状況下ではホスティングが費用面で有利とは言いにくく、粗利率が高いと言われる API 料金もそれと比べればそんなに法外でもないのではないかと個人的には思っています。
*2:上記の議論ではモデルのスピードについては触れていません。本文後半で述べるとおり人間があまり介入しないオーケストレーションを想定しているため、今回の議論には含めませんでした。また正解が出せないときに出せないと言えるかどうか、すなわち abstention も実務上は重要です。これを評価するベンチもあり、fixedbench, bouncerbench などがあるものの、データはまだ一部のモデルに留まっています。ちなみに OpenRouter の Auto Router や Pareto Router はこういった煩わしさを軽減してくれるかもしれません。一方最近出た Sakana Fugu はむしろ逆の方向で、可能な限り良い結果を得る代わりに少し高いお金を払う仕組みと理解しています。
