AIを使ったチームビルディングでは、すべてのプロジェクトの最初に同じ決断をします。どのモデルを使うのか？
そして、ほとんどの人が同じやり方でそれを決めます。いちばん耳にしたことのあるもの、前回使ったもの、技術リードが好むものを選ぶのです。ベンチマークもしません。コストも見積もりません。ただ選んで出荷します。
その後3か月たつとAWSの請求書が届き、誰かが「$0.038で同じ仕事ができたのに、なぜタスクあたり$600も払ってるの？」と聞いてきます。
私はそれを直すためにCostGuardを作りました。15のモデルに対して163回のベンチマーク実行を行って分かったこと――そして、私を本当に驚かせた数字――を紹介します。
誰も話題にしない問題
多くのチームが、LLM推論に対して大幅に過払いしています。手抜きをしているからではありません。そうではなく、それ以外を判断するためのツールがないからです。
最安のモデルと最も高価なモデルの差は、2倍とか5倍ではありません。200倍です。
Gemini 2.5 Flashは、入力トークン1Kあたり$0.000075です。GPT-5は$0.015。つまり200倍の価格差です。――誰もが実際には体系的に答えていない問い――は次の2つです。200倍のプレミアムはいつその価値があり、いつ純粋な無駄になるのか？
CostGuardはその問いに答えます。
私が作ったもの
CostGuardはオープンソースのベンチマークツールです。CSVまたはParquetファイルをアップロードし、タスクを説明すると、15の主要LLMにあなたのデータを流し込みます――Claude、GPT、Gemini、Llama、そしてGrok。評価用ハーネスは4次元の評価設計であるRealDataAgentBenchを使用します。15秒以内で次が得られます：
各実行の費用を$0.000001の精度まで正確に見積もった、ランキング形式の推奨
すべてのモデルをCorrectness（正確性）、Code Quality（コード品質）、Efficiency（効率性）、Statistical Validity（統計的妥当性）で比較するレーダーチャート
プロジェクトにそのまま貼り付けられる、ワンクリックでコピー可能な設定
アカウント不要。データは保存されません。シミュレーションモードではAPIキーも不要です。
アーキテクチャはシンプルです――FastAPIのバックエンド、Streamlitのダッシュボード、並列のモデル評価、合成スコアリング：
{% embed Upload CSV/Parquet
↓
Data Loader（バリデーション、スキーマ抽出）
↓
Question Generator（スキーマから評価質問を自動生成）
↓
CostGuard Engine（15のモデルすべてで並列評価）
↓
RDAB CompositeScorer（Correctness · Code · Efficiency · StatVal）
↓
Ranker（60% RDABスコア + 40% コストの重み付け）
↓
Recommendation + コピー可能なconfig %}
ただし面白いのはアーキテクチャではありません。ベンチマークデータが実際に明らかにしたことです。
発見1：Claude Haikuは同じタスクでGPT-4.1より20倍多くトークンを消費した
これは私を完全に止めました。
同一のタスクでClaude Haikuは608,000トークンを消費しました。GPT-4.1は同じタスクを30,000トークンで完了しました。
これは小さな違いではありません。トークン効率の差が20倍あるのです――しかも「安くて速いはず」のモデルで。トークン課金の場合、「トークンあたり安い」が「タスクあたり安い」を意味するわけではありません。モデルが非効率にトークンを消費してしまえば、結局タスク全体では高くつくからです。
これは罠です。1トークンあたりの価格を見ると、Claude Haikuが$0.00025/1Kなので「コスト規律は守れてる」と感じます。次に実際のトークン消費量を見て、「本来は予算向けのはず」が、より高価な「はず」のモデルを使っていれば20倍安く済んだはずの請求を引き起こしていたと気づくのです。
教訓：LLMのコストは、トークン単価だけで評価してはいけません。必要なのはタスクあたりのコストであり、そのためには、各モデルがあなたの特定のワークロードを完了するのに実際に何トークン消費するのかを知る必要があります。
発見2：GPT-4.1はデータタスクでコストパフォーマンスの首位――想定していたモデルではない
この調査に入る前は、GPT-4oやClaude Sonnetが圧倒すると思っていました。どちらも違いました。
GPT-4.1は、データ分析タスクにおいて一貫して最良のコストパフォーマンス比を示しました。タスクあたり$0.038で、GPT-5の$0.596（タスクあたり約15倍安い）。そして性能差は多くのワークロードではプレミアムの正当化が難しいほど小さいのです。
163回の実行結果に基づくランキング：
Groq経由のLlama 3.3-70Bもまた驚きでした。統計モデリングのタスクでは、コストが大幅に高いモデルを上回ったのです。オープンソースモデルは、多くの人が思っているよりもずっと早くギャップを埋めてきています。
発見3：すべてのモデルが統計的妥当性で失敗する
これは、LLMを何らかの形のデータ分析に使っている場合に重要です。
163回のすべての実行、15のすべてのモデルにわたって、すべてのモデルの統計的妥当性の次元のスコアはおおむね0.25でした。この次元は、モデルがp値や信頼区間を正しく報告できるか、pハッキングのようなパターンを避けられるか、といった点を測定します。
特定のモデルだけではありません。すべてのモデルです。普遍的に。
LLMにデータ分析をさせて統計的な結論を導きたいのであれば、これを知っておく必要があります。モデルは数値つきで自信ありげな答えを返します。しかしその数値が正しい統計手法に従っているとは限りません。これはGPTの問題でも、Claudeの問題でもありません。この種のタスクにおける、現行世代のモデルの普遍的な制約です。
解決策は、データ分析にLLMを使わないことではありません。弱点がどこにあるかを理解し、その周りにバリデーションを組み込むことです。
発見4：Grok-3はscikit-learnで死角がある
Grok-3は能力のあるモデルです。ただし、他のモデルがしなかった形で、scikit-learn固有のタスクに対して一貫して失敗しました。コードを書くことができないからではありません――できます。ですが、sklearnのAPIパターンに関して学習データに特定の欠落があったためです。
こういうことは、実際のワークロードをモデルにぶつけて初めて分かる類のものです。一般的なベンチマークでは分かりません。「Grok-3はHumanEvalで87%だった」という情報では、sklearn.preprocessing.StandardScalerが、古いAPIバージョン相当のものと違う動作をすることを理解しているかどうかは何も分かりません。
本番用途でのモデル選定は、常にワークロードに固有であるべきです。CostGuardのアプローチ――評価用ハーネスにあなたの実データを流すこと――が、一般ベンチマークでは抽象的すぎて実用に結びつかないため、まさにそれを避ける目的で存在しています。
ビジネスケースを具体化する
数字が実務で何を意味するのかを説明します：
大規模に構造化データの分析を行っていて、現在GPT-4oを使っているなら、同じタスクをGPT-4.1に切り替えることで、精度の大きな低下なしにおよそ20%の節約になります。
大量のバジェット推論――バッチ処理、スケールでの分類――を行っているなら、GPT-4oからGPT-4o-miniへ切り替えるだけで94%節約でき、精度低下は5%未満です。これは単なる丸め誤差ではありません。月10,000ドルの請求と月600ドルの請求の違いです。
デフォルトとしてClaude Sonnetを使っていて、そのタスクがClaude Sonnet固有の強みを必要としていないなら、Gemini 2.5 Flashは97.5%少ないコストで済み、多くのワークロードで競争力のある性能を発揮します。
これらの最適化はデータなしでは自明ではありません。データがあれば15秒で分かります。
次に来るもの
CostGuard v1は、単一モデルの評価と推奨に対応します。今後私が作っていくロードマップは以下です：
エージェント型ワークフローのベンチマーク。シングルターン評価は有用ですが限界があります。ほとんどの本番AIシステムは、ツール呼び出しを伴う多段のエージェント型ワークフロー、RAGの検索、コード実行ループを実行します。次のバージョンでは、個々のモデル呼び出しだけでなく、完全なエージェントパイプラインをベンチマークします。
返却形式: {"translated": "翻訳されたHTML"}リアルタイムのコスト監視。いまCostGuardは、開始する前にどのモデルを選ぶべきかを教えてくれます。
次のステップは、実際の本番コストをリアルタイムで監視し、トークン消費がベンチマークの基準値から逸脱したときに通知することです――いわばClaude Haiku問題を、自動で検知します。
カスタム採点の次元。RDABハーネスは現在、Correctness（正確性）、Code Quality（コード品質）、Efficiency（効率性）、Statistical Validity（統計的妥当性）でスコアリングしています。異なるワークロードには異なる次元が必要です。カスタマーサポートのユースケースではトーンや安全性が重要になりますが、コーディングエージェントではテストの合格率が重要です。カスタム採点プロファイルはロードマップにあります。
マルチプロバイダーのコスト裁定。まったく同じモデルでも、プロバイダーが違えば、レイテンシや料金が意味のある形で変わり得ます。これはどこにも十分に文書化されていません。CostGuardがそれを可視化すべきです。
試してみる
ライブデモはcostguard.up.railway.appです――シミュレーションモードではAPIキーは不要です。任意のCSVをアップロードし、タスクを説明して、あなたの特定のデータでどのモデルが勝つかを確認してください。
コードはオープンソースです。
github.com/patibandlavenkatamanideep/CostGuard. ローカルで実行したい場合：
bashgit clone https://github.com/patibandlavenkatamanideep/CostGuard.git
cd CostGuard
cp .env.example .env
pip install -e .
./scripts/dev.sh
localhost:8501でダッシュボード、localhost:8000/docsでAPIドキュメントです。
モデル選択の問題はなくなりません。むしろ、能力の高いモデルが増えていくほど、判断は難しくなり、間違えたときのコストはより大きくなります。
163回のベンチマーク実行から学んだのは、「明らかな」選択が最適であることはほとんどない、ということでした。適切なモデルはあなたのワークロード次第で完全に決まります。そして今、そのモデルがどれかを教えてくれるツールがあります。
いまどんなモデル選択の判断をしていて、できればデータが欲しいと思っているものは何ですか？コメントに投下してください。ベンチマークスイートを構築する取り組みは継続中で、実際のユースケースが次に何が追加されるかを左右します。
