AIが安くなったというニュースを読んだのに、自社の請求は増えている。そんなときは、単価の改定と使った量を分けて確かめる必要があります。単価が半分になっても、同じ条件の処理を4倍行えば、従量部分の総額は2倍になります。
この関係は、値下げが悪いことを意味しません。利用を広げた結果なのか、同じ仕事に余分な処理が増えたのかによって、判断が変わるということです。経営者や予算担当者が持っておきたいのは、単価・処理量・回数を分けた見通しです。
本稿では、過去の価格低下を読む際の注意と、将来の料金を決め打ちしない予算の考え方を整理します。後半のドル金額は、計算練習用に作った架空の料金です。現行モデルの料金表や導入効果の実測ではありません。
過去の値下がりは、比較の条件まで読む
Stanford HAIの2025年AI Indexは、MMLUという評価でGPT-3.5相当の成績に達するモデルを使う価格が、2022年11月の100万トークンあたり20ドルから、2024年10月には0.07ドルへ下がったと紹介しています。280分の1未満になったという、過去の特定条件での比較です。Stanford HAIの解説
これを「自社の同じ仕事が280分の1で済む」「今後も同じ速さで下がる」と置き換えることはできません。評価で一定の成績を満たすことと、社内の資料や手順で必要な品質を出すことは別だからです。比較期間も2024年までで、2026年の将来予測を示した数字ではありません。
また、利用者に提示される価格と、提供企業の内部の原価を分けて読みます。公開料金の変化だけでは、各社が原価を割って提供しているのか、将来の値上げを狙っているのかは確定できません。自社の予算を組むときは、そうした推測を前提にせず、確認できる契約条件と利用量から始めます。
請求額が動く場所を3つに分ける
従量課金を大づかみに考えるなら、「単価」「1回あたりの処理量」「回数」を分けると原因を追いやすくなります。Claude APIでは、公式料金表に入力・出力やキャッシュなど別の課金区分があり、機能による料金も示されています。入力と出力をまとめて一つの単価で掛ける計算は避けます。ClaudeのAPI料金仕様
さらに、同じ文章でもモデルが変わるとトークン数が変わる場合があります。単価だけを差し替えても、移行後の請求を正確に予測できるとは限りません。モデル変更時には実際の利用量も確認します。
| 変化する項目 | 総額が増える例 | 確かめる材料 |
|---|---|---|
| 単価・課金区分 | モデルや使用機能が変わった | 利用時点の公式料金と契約条件 |
| 1回の処理量 | 渡す資料や求める出力が長くなった | 利用記録の入力・出力などの内訳 |
| 処理する回数 | 対象部署や案件が増えた | 業務件数と実際の呼び出し回数 |
この表は、すべてのサービスの請求書をそのまま表すものではありません。座席数に応じた契約や追加利用料がある場合は、その部分を別に扱います。Claudeの有料サブスクリプションとAPI・Consoleは別の製品で、サブスクリプションにAPI利用が含まれるわけではありません。Claude公式ヘルプ
本稿の仕様確認日は2026年10月6日です。実際に試算するときは、利用する提供元、モデル、機能、通貨、確認日も一緒に残してください。取引条件が違う料金表を混ぜると、計算が合っていても実際の請求とはずれます。
演習:単価半減、利用回数4倍ならどうなるか
ここからは、編集部が設定した架空のAPI利用を計算します。実在するモデルの料金ではなく、APIの実行も支払いも行っていません。各回のトークン数は同じと仮定し、キャッシュ、追加機能、税、為替、固定費は計算の対象外にします。
1回の入力:4,000トークン
1回の出力:1,000トークン
旧単価:入力$2、出力$8(各100万トークン)
新単価:入力$1、出力$4(各100万トークン)
旧利用:月2,000回
比較A:新単価で月2,000回
比較B:新単価で月8,000回
旧単価での1回分は、入力が4,000÷1,000,000×2で0.008ドル、出力が1,000÷1,000,000×8で0.008ドル。合計0.016ドルです。新単価では0.008ドルになります。
| 条件 | 1回分 | 月の計算結果 |
|---|---|---|
| 旧単価・2,000回 | $0.016 | $32 |
| 新単価・2,000回 | $0.008 | $16 |
| 新単価・8,000回 | $0.008 | $64 |
比較Aでは総額も半分ですが、比較Bでは旧利用の2倍です。どちらも単価半減という条件は同じです。したがって、「単価が下がったので来月の予算も半分にできる」という結論には、処理量と回数が変わらないという前提が必要です。
Claudeに表を整理させる場合も、前提を省かずに渡します。
上の架空条件から、旧利用・比較A・比較Bを計算してください。
入力と出力を分け、100万トークン単位で計算します。
1回分と月額を別々に示し、旧利用との比も出してください。
計算対象外の費用を勝手に補ってはいけません。
この結果を現行モデルの見積もりと呼ばず、
利益や人件費の削減額も推定しないでください。
期待する結果は32、16、64ドルで、旧利用との比は1、0.5、2です。入力と出力を合計して入力単価だけで計算していたら修正が必要です。また、利用記録を集める段階では、業務の「案件数」とAPIの「呼び出し回数」を区別してください。一つの案件で複数回処理する設計なら、両者は一致しません。

図解を大きく見る ↗
料金の予測を一つに決めず、条件を動かしてみる
来月の予算は、まず現在の契約条件で計算します。そのうえで、利用部署が増える場合、資料が長くなる場合、単価が変わる場合を別々に試します。一度にすべてを変えるより、どの条件が総額を動かしたかが分かります。
予算表には、基本の見込みに加えて、利用が多い場合の見込みも置きます。何倍にするかは自社の予定や記録から決めます。どの会社にも共通する「安全な倍率」を置くより、新しい対象業務、繁忙期、再作成の回数を説明できるほうが、見直しに使えます。
無料枠や期間限定条件を使う場合も、期間や対象を記録します。条件が変わったら何を続け、どの業務を止めて再検討するかを、担当者と決めておきます。予算額を表に書いただけでは、サービスの課金上限にはなりません。通知や停止を使うなら、利用先での設定と実際の動作を別に確認します。
値下げがいつ起きるかを当てる必要はありません。前提が変わったときに、影響を計算し直せる状態にしておくことが大切です。
高いモデルを使うかは、成果物でも比べる
高いモデルなら重要な判断を任せても安心、という関係は成り立ちません。安いモデルなら定型業務には必ず十分、という決め方も避けたいところです。元資料との一致、必要事項の欠落、出力を修正する時間など、仕事に応じた同じ基準で比較します。
たとえば、説明文の生成料金が下がっても、確認にかかる時間が増えれば、作業全体では負担が増える場合があります。反対に、従量料金が上がっても、必要な資料を作れるようになり、確認まで含めた作業が改善するなら、その変化を検討する余地があります。
請求の増加だけで成功とも失敗とも決めません。 処理した案件数、採用できた成果物の数、確認や修正の負担も並べます。単価を比較する表と、仕事の結果を比較する表をつなぐと、削るべき処理と続けたい利用を区別しやすくなります。
将来の料金が一方向に下がり続けるか、必ず二極化するかは、本稿の資料だけでは断定できません。自社の用途と契約を確認し、数量の見通しを更新し、品質と総額の変化を一緒に見る。そのための材料を、今月の利用から残していきましょう。






