方法論

確度の等級

すべての利用枠に等級が付きます。数値の大きさではなく、根拠の強さを表します。

official

ベンダーの価格ページまたは文書に明記。出典 URL とベンダーの原文が必須です。

measured

当方またはコミュニティによる実測。参照可能な出典と測定方法の記述が必須です。

estimated

既知の値からの推定。推論の根拠を書き残すことが必須です。

派生値は入力のうち最も弱い等級を取ります。この比較ページには official と measured のみを表示し、estimated は前提を確認・変更できるプランナーにのみ現れます。

ベンダーがどこまで公開しているか

確度とは別の軸であり、しばしば混同されます。Anthropic の「Pro の 5 倍の利用量」はベンダー自身の言葉として official 級の根拠ですが、その枠は依然として数値ではありません。

published

絶対値、または明示的な「無制限」。

relative

他プランとの比率のみ。その基準プラン自体の枠が未公開のこともあります。

undisclosed

数値が一切ない。

能力の区分

階層は、ベンダーが比較可能なスコアを公開したモデルに付く見出しです。モデルのチップにだけ現れます。階層は粗いふるいであって点数でも階層内の順位でもなく、このサイトのどこも階層で絞り込んだり順位を付けたりしていません。

ベンダーが公開した Terminal-bench 2.1 のスコアがあればそれで区分します。80 以上が frontier、70〜79.9 が strong、70 未満が efficient。スコアはないが自社モデルについて明確な順序をベンダーが述べている場合は、その記述で区分し原文のまま記録します。どちらもない場合は未分類のままにします。

未分類は弱いという意味ではなく、比較可能な数値を誰も公開していないという意味です。かつては能力の下限を通過できない代償がありました。その下限は廃止しました——弾かれていたのは力の足りないモデルではなく、ベンチマークを公開しないベンダーがほとんどだったからです。いまは価値の数値が、どのモデルで換算したかを示します。

意図的に使わないものが二つあります。ベンチマークの版が異なるスコア——版の違いだけでモデルが丸ごと一区分動きます。そして販売側の課金区分——価格と密着しているため、それで区分してから価格あたりの価値で順位を付けると循環論法になります。

現在の網羅状況：ベースモデル 19 件中 9 件に区分あり。

前提

利用枠を金額に換算するには、コーディングのセッションがトークンをどう消費するかのモデルが要ります。これは実測ではなく編集上の前提であり、プランナーで調整できます。

価値の数値はどう作られるか

プランの API 換算価値は、ひとつの枠を、ひとつのモデルで換算して得られます。どの枠とどのモデルかは三段階で決まります。

1. 1同じモデルに対して、そのモデルを縛る行は制約です。プラン全体の枠と、そのモデルを名指しする行は二者択一ではなく、後者が前者を狭めます。したがってそのモデルの上限は厳しいほうです。
2. 2モデルをまたぐと、同じ行が選択肢になります。ひとつの 5 時間ウィンドウを共有するモデルは、選んだモデルにその枠を使うので、このグループは最良の選択の価値を持ちます。勝ったモデルが、その数値の換算に使われたモデルです。
3. 3グループをまたぐと、すべての行が同時に効きます。5 時間ウィンドウと週上限は両方に当たるので、プランの価値は最も厳しいものになります。

価値倍率 = その数値 ÷ 月額。1.00 を超えていれば、公開 API 価格で見てその枠は月額以上の買い物になります。

次の四つでは、甘い数値を出す代わりに数値を出しません。要問い合わせのプラン。経路のどこかに、公開されているがドルに換算できない枠があるプラン。割る価格がない無料プラン。そして、公開された枠がこちらの掲載モデルのどれにも対応しないプラン。

どのモデルをどの作業に

コスト試算では作業カテゴリごとにモデルを割り当てます。サイト内で最も根拠の弱い層であり、下の網羅状況を先に読んでください。

網羅状況

ベンチマークがあるカテゴリでは、同一カテゴリ内の公開最高スコアに対する相対位置で帯を決めます。92% 以上を preferred、70% 以上を capable、それ未満を unfit とします。絶対値でなく相対値なのは、これらのベンチマークの難易度が揃っていないからです。最高点が約 85% のものもあれば 65% のものもあり、固定のしきい値では試験の難しさだけで同じモデルが別の帯に入ってしまいます。

ベンチマークのないカテゴリでは、モデルは能力帯から capable を継承し、解決率は持ちません。割り当ての候補にはなりますが、測定されたことのないコスト比較で勝つことはなく、その行は「能力帯で判断」と明示されます。

根拠は強い順に三種類。ベンダーが自社の比較表で公開するベンチマーク。第三者ランキングが示す集計された行動。ただし再配布ライセンスを個別に確認する必要があるため、まだ使用していません。そして本サイト読者からのフィードバック。これは審査待ちの変更案を生むだけで、それ自体がデータを書き換えることはありません。

アーキテクチャ設計には成熟した公開ベンチマークがなく、今後も期待できないため、探すべき能力帯だけを示し、モデル名は挙げません。

トークン単価から1タスクあたりのコストへ

強いモデルはトークン単価が高く、試行回数は少なくて済みます。だから「トークンあたりは高い」と「タスクあたりは安い」は同じモデルで同時に成り立ちます。試算が比べるのは1タスクを終えるまでの期待コストです。カテゴリの基準トークン数をモデルに合わせて調整し、その解決率で割ります。

1タスクあたりの基準トークン数

結果はすべて幅で示します。トークン消費を ±30%、解決率を ±10 ポイント動かして伝播させたものです。編集部が置いた基準値にベンチマークの解決率を掛けて一つの数値にすれば、サイト内で最も確からしく見え、最も擁護しがたい数字になります。

フィードバックのしきい値

あるカテゴリにどのモデルが向くかへの異議は、同じ趣旨が 5 件たまり、その（モデル, カテゴリ）への投票の 70% 以上を占めたときに変更案となります。案は人が公開ベンチマークと照合して判断します。フィードバックがそれ自体でデータを書き換えることはありません。

上限に達したという報告は、プラン・期間・利用強度ごとに集計し、強度をまたいで合算することはありません。重い使い方をする人は大きいプランに集まるため、合算すると「高いプランほど早く尽きる」という、購入者層に由来する見かけの結論が出てしまいます。比率を表示するのは1グループに 20 件以上たまってからで、それ未満はその旨を表示します。

数値をどう最新に保つか

監視が 3 日ごとに各ベンダーのページを読み直し、保持している内容と突き合わせます。見つかった変更は、人が出典と照合して確認するまで公開されません。ベンダーのページが読めなくなった場合、それは静かに吸収されるのではなくプラン上に表示されます。

最終確認: 2026-07-29