Claude API 費用｜モデル別料金と削減技でコスト最適化

Claude API の費用構造 — トークン課金とサブスクの違いを最初に整理

Claude API の請求は Anthropic Console で発行した API キーの使用量 に対して、入力トークンと出力トークンを別々の単価で従量課金する仕組みです。Claude.ai のチャット UI を月額固定で使う Pro($20/月)・Max・Team とは 請求体系が完全に別 で、API を叩いた分だけクレジットカードまたは前払い残高から差し引かれます。サブスクを契約していても API は別建てで請求され、逆に API だけ使う場合は Pro 等のサブスクは不要です。

トークンとは英単語や記号、日本語の文字を AI モデル内部で扱う最小単位で、概ね「英語 4 文字 ≒ 1 トークン」「日本語 1 文字 ≒ 1〜2 トークン」が目安になります。1 リクエストで投入したプロンプト全体(system + user + 会話履歴)が入力トークンとして加算され、モデルが返した文章が出力トークンとして別単価で加算されます。多くのエンジニアが見落とすのは、長いセッションでは過去のやり取りが毎回入力トークンに乗る 点で、これは Claude Code のコスト爆増を防ぐ実践ガイド でも触れた構造です。

出典: Anthropic API Pricing(参照: 2026-05-28)

モデル別トークン単価 — Opus / Sonnet / Haiku の 3 階層

2026 年 5 月時点で API 経由で叩ける主要モデルは Claude Opus 4.7・Sonnet 4.6・Haiku 4.5 の 3 系統で、入力・出力のトークン単価が以下の早見表のとおり階段状に並んでいます。Opus と Haiku の差は 入力で 5 倍、出力で 5 倍 あり、どのモデルを既定に置くかで月額が一桁変わります。

MTok = 100 万トークン。金額はすべて税別・USD で、為替変動と消費税は別途加算されます。

出典: Anthropic API Pricing(参照: 2026-05-28)

実務での選定指針は単純で、「Opus でなければ解けない難題」と判別できた瞬間だけ Opus を呼び出し、それ以外は Sonnet を既定にする のが正解です。さらに分類・抽出・要約のような決定的タスクは Haiku で十分に捌けるため、3 階層を 1 つのアプリで使い分けるルーティング層を最初に作っておくと、後から月額を 1/3 に落とすチューニング余地が生まれます。

月額コストの計算式と試算実例 — チャットボット・要約・コード生成

費用の概算は次の 1 行で出ます。

月額 USD ≒ (月間入力トークン × 入力単価) + (月間出力トークン × 出力単価)

実務で頻出する 3 つのワークロードに当てはめると、規模感を一気に掴めます。

シナリオ A: 社内チャットボット(Sonnet 4.6、月 10 万リクエスト)

1 リクエストあたり入力 2,000 トークン(system + 直近履歴)・出力 500 トークンで月 10 万回叩く想定。

• 入力: 2,000 × 100,000 = 2 億トークン = 200 MTok → 200 × $3 = $600
• 出力: 500 × 100,000 = 5 千万トークン = 50 MTok → 50 × $15 = $750
• 月額: $1,350(税別・USD)

シナリオ B: ドキュメント要約バッチ(Haiku 4.5、月 1 万件 × 平均 8,000 字)

8,000 字 ≒ 12,000 トークンの本文を投入し、500 トークンの要約を返す想定。

• 入力: 12,000 × 10,000 = 1.2 億トークン = 120 MTok → 120 × $1 = $120
• 出力: 500 × 10,000 = 500 万トークン = 5 MTok → 5 × $5 = $25
• 月額: $145(税別・USD) ※後述のバッチ API で更に 50% 引き

シナリオ C: コード生成エージェント(Opus 4.7、月 1,000 セッション)

1 セッションあたり累積で入力 50,000 トークン・出力 8,000 トークンを使う重ためのエージェント想定。

• 入力: 50,000 × 1,000 = 5 千万トークン = 50 MTok → 50 × $5 = $250
• 出力: 8,000 × 1,000 = 800 万トークン = 8 MTok → 8 × $25 = $200
• 月額: $450(税別・USD)

シナリオ A の Sonnet ワークロードを仮に Opus に切り替えると、$600 → $1,000(入力)、$750 → $1,250(出力)で月額 $1,350 → $2,250 に跳ねます。逆に Haiku に落とせる軽い分類タスクが半分を占めるなら、$1,350 → $700 まで下がる計算です。モデル選定こそが最大のコスト最適化レバー であることが、この比較から読み取れます。

プロンプトキャッシュで最大 90% 削減 — system プロンプトを使い回す

繰り返し同じ system プロンプトや長いコンテキストを送るワークロードでは、プロンプトキャッシュ を有効化するだけで該当部分のコストが大きく落ちます。仕組みは、最初のリクエストでキャッシュに書き込み(基本料金の 1.25 倍)、以降の参照(キャッシュヒット)を 1/10(0.1 倍)で課金 するというもので、TTL は 5 分の標準キャッシュと 1 時間の長期キャッシュが選べます。

Python SDK での最小実装は次のとおりで、cache_control を付けたブロックがキャッシュ対象になります。

client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": "<長い system プロンプト、社内ガイドライン等>",
            "cache_control": {"type": "ephemeral"},
        }
    ],
    messages=[{"role": "user", "content": "本日の質問内容"}],
)

シナリオ A(月 $1,350)で system プロンプト 1,500 トークン分を全リクエストでキャッシュヒットさせた場合、その部分のコストは概ね 10 分の 1 になり、入力側の半分以上を圧縮できます。同じテンプレートを高頻度で叩くプロダクトほど効果が大きい ため、まずキャッシュ可能なブロックを定義してから本実装に進むのが定石です。

出典: Prompt caching — Anthropic Docs(参照: 2026-05-28)

Batch API で追加 50% 割引 — 非同期で良い処理を切り出す

リアルタイム応答を捨てて良いバッチ処理なら、Message Batches API に切り替えるだけで全モデルの単価が 入力・出力ともに 50% オフ になります。24 時間以内の完了が SLA で、1 バッチあたり最大 10 万件・256MB まで投入可能。プロンプトキャッシュとも併用でき、二段の割引が重なります。

呼び出しは通常の messages.create ではなく messages.batches.create を使い、各リクエストに custom_id を付けて結果を後から突合します。シナリオ B のドキュメント要約バッチに適用すると $145 → $72.5 まで落ち、要約・分類・タグ付け・翻訳のように 遅延を許容できる処理 はバッチ化するのが鉄則です。

逆に、ユーザー対面のチャットや IDE 補完のように 1 秒以下の応答が要る箇所で無理にバッチ化すると UX が壊れるため、非同期で済むワークロードを意識的に切り出す設計 が前提条件になります。

出典: Message Batches — Anthropic Docs(参照: 2026-05-28)

トークン使用量の可視化 — Console と usage レスポンスの二段ログ

費用が見えない最大の理由は、リクエストごとのトークン量を可視化していないからです。Anthropic Console の Usage タブ で日次・モデル別の消費量と請求額が確認できるため、まず本番運用前に管理者がブックマークしておきます。次に、アプリ側でも各レスポンスに含まれる usage ブロックを永続ログに残し、機能別・ユーザー別の消費を切り分けられるようにします。

Python SDK の最小実装は次のとおりです。

res = client.messages.create(...)
log = {
    "feature": "support_chat",
    "user_id": user.id,
    "model": "claude-sonnet-4-6",
    "input_tokens": res.usage.input_tokens,
    "output_tokens": res.usage.output_tokens,
    "cache_read": res.usage.cache_read_input_tokens or 0,
    "cache_create": res.usage.cache_creation_input_tokens or 0,
}

このログを日次集計するだけで、(1) どのユーザーが偏って消費しているか、(2) どの機能が想定の何倍を使っているか、(3) キャッシュヒット率が想定どおりかが、ダッシュボード 1 枚で見えるようになります。「気づいたら $5,000 請求が来ていた」 という事故は、ほぼ全てこの可視化を怠ったケースで発生します。

レート制限と Tier 構造 — RPM / ITPM / OTPM の 3 軸

Claude API には Requests Per Minute (RPM)・Input Tokens Per Minute (ITPM)・Output Tokens Per Minute (OTPM) の 3 軸で制限が掛かり、アカウントの累計利用額と経過日数に応じて Tier 1 → 2 → 3 → 4 へ自動昇格する設計です。Tier 1 は新規発行直後の控えめな上限で、本番投入には Tier 2 以上が必要になるケースが多く、月次の与信枠と最低利用額の達成が昇格条件として案内されています。

制限に当たると HTTP 429 が返り、レスポンスヘッダ retry-after に再試行までの秒数が入ります。SDK は自動で 指数バックオフ + ジッタ によるリトライを内蔵していますが、それでも上振れが避けられない場合は Token Bucket の挙動を理解した上で、自前のキュー(SQS 等)で投入レートを整える方法が現実解です。Tier ごとの具体上限と昇格条件は更新が早いため、本番設計前に必ず公式ドキュメントを直接確認してください。

出典: Rate limits — Anthropic Docs(参照: 2026-05-28)

月額予算管理ベストプラクティス — 上限・アラート・モデル切替

費用の事故を未然に防ぐ仕掛けは、予防・検知・縮退 の 3 段階で組みます。

1. 予防(Spend Limits): Anthropic Console の Billing 設定で月次の Soft Limit と Hard Limit を必ず両方入れ、Hard Limit に達したら API が自動停止する状態にしておく
2. 検知(Usage アラート): Soft Limit 到達時にメール通知が飛ぶようにし、社内の Slack / ChatWork 等に転送する webhook も併設する
3. 縮退(モデルフォールバック): アプリ側で「Opus 不可なら Sonnet、Sonnet 不可なら Haiku」と段階的に落とすフォールバック分岐を実装し、コスト急騰時に手動で env を 1 つ書き換えるだけで自動降格できる構成にしておく

加えて、新機能の試作段階では Haiku で動く形 を必ず先に作り、後から品質要件に応じて Sonnet / Opus へ昇格させる順序を守ると、開発中の浪費が抑えられます。「最初から Opus でプロトタイピング」 は本番化までに数十ドル〜数百ドル単位の余分なコストが必ず積み上がるため、避けるのが鉄則です。

サブスク Pro / Max との使い分け — 個人 IDE 利用は両建てが現実解

最後に整理しておきたいのが、Claude.ai のサブスクと API のすみ分け です。サブスク(Pro $20/月・Max $100〜/月・Team $20〜/席/月)は claude.ai と Claude Code CLI で固定額 で叩き放題に近い体験を提供し、API は 自社プロダクトに組み込むための従量課金 という棲み分けになっています。

個人開発で Claude Code を IDE 補完として使いつつ、自社サービスにも Claude を組み込んでいる場合、Pro / Max サブスクと API キーは別請求で同時に契約可能 です。実務では「自分の手元作業は Max サブスクで定額」「プロダクトの本番呼び出しは API 従量」と二本立てにするのが最も合理的で、本記事の API 費用最適化と Claude 料金完全比較 のサブスク選定を組み合わせると、個人と組織の両面でコストを最小化できます。

API の実装手順そのものは Claude API 入門｜Python 10 行で動かす最短手順 に最短経路をまとめてあるので、料金感を掴んだあとはそちらから接続コードに進んでください。