9-1 Claude Code API 料金の仕組み｜トークン課金を解剖

このレッスンで身につくこと

このレッスンは「Claude Code を月いくらで使えるのか、その金額はどうやって決まっているのか」を、ごまかし無しで分解します。前章までは「だいたい月 $20」「Sonnet が安い」と雑に説明してきましたが、ここから先は 請求書の 1 行ごとを自分で説明できる レベルに引き上げます。

所要時間 — 約 60 分（電卓を叩きながら読むと、より体に入ります） 難易度 — ★★★☆☆（数字に強くなくても OK。掛け算と割り算ができれば足ります）

トークンとは何か — 値段が決まる最小単位

Claude Code の請求書を読み解く出発点は、トークン（token）という言葉です。1-1 や 1-3 でも触れましたが、ここで一度きちんと定義します。

トークンとは、LLM がテキストを処理するために分割した最小の塊 です。文字でも単語でもなく、その中間にある「サブワード」と呼ばれる単位で、Anthropic のモデルは内部的にこのトークン列に変換してから処理します。

イメージを掴むには、実際の例を見るのが早いです。

入力テキスト                    トークン分割（概念）          トークン数
─────────────────────────────────────────────────────────────────────
"Hello, Claude."             ["Hello", ",", " Claude", "."]       4
"こんにちは、Claude。"         ["こん","にち","は","、","Claude","。"] 6〜8
"const x = 42;"              ["const"," x"," ="," 42",";"]         5
"const handleSubmit = ..."   ["const"," handle","Submit"," ="]    多め

ここで体感を作るための 3 つの目安 は次のとおりです。

• 英語: 1 単語 ≒ 1 トークン（短い前置詞や記号は 0.5 トークン換算くらい）
• 日本語: 1 文字 ≒ 1〜2 トークン（漢字 1 文字でも複数トークンに割れることがある）
• コード: 1 行 ≒ 5〜20 トークン（インデント・記号も全部カウント）

なぜ「サブワード」なのか — 1 分だけ仕組みを覗く

「単語単位や文字単位でなく、なぜわざわざサブワードに割るのか」を 1 分だけ覗いておきます。後で「キャッシュが効く範囲」を理解するとき、地味に効いてきます。

LLM の語彙（vocabulary）は数万〜十数万種類しかありません。世界中の単語をそのまま入れたら無限に膨らむので、頻出する塊だけを 辞書化 して、それ以外は組み合わせで表現します。たとえば英語の "Submit" は 1 トークン、"handleSubmit" は ["handle", "Submit"] の 2 トークンに、日本語の「こんにちは」は ["こん","にち","は"] の 3 トークン、というように、頻出ピースの組み合わせで表現されます。

高頻度な塊            1 トークン
珍しい人名や記号列    複数トークンに割れる
日本語の漢字          1〜2 トークン
絵文字 / 顔文字       2〜4 トークン

これが分かっていると「日本語のほうがトークン効率が悪い」という有名な話に、初めて腹落ちします。同じ意味のことを日本語と英語で書き比べると、トークン数は 1.5 倍〜2 倍違う のが普通です。

入力トークン / 出力トークン / キャッシュトークン — 3 種類の値段

ここから本題です。Claude Code の請求書には、トークンが 3 つの種類 に分かれて並びます。

入力トークン / 出力トークン / キャッシュトークン

この 3 種類が、それぞれ 別の単価 で課金されています。「同じトークンなのに別単価」というのが最初は気持ち悪いですが、なぜそうなっているかを掴むと、節約の打ち手がはっきり見えてきます。

① 入力トークン（Input） — Claude が「読む」分

入力トークンとは、あなたが Claude に渡したすべてのテキスト です。具体的には次のものを足し合わせた量です。

• あなたがプロンプトで打った文章
• Read ツールで読み込んだファイルの内容
• Bash ツールが実行したコマンドの出力
• Grep / Glob の検索結果
• 過去の会話履歴 — これが地味に効きます
• CLAUDE.md などプロジェクト共通ファイル
• システムプロンプト（Claude Code が裏で付けている内部指示）

「自分が打った文字だけ」ではない、というのが最初のつまずきポイントです。Claude Code は 前の会話を全部覚えながら 動くので、5 ターン目のプロンプトを送るときは「1〜4 ターン目の全部 + 5 ターン目」を入力として送り直しています。

② 出力トークン（Output） — Claude が「書く」分

出力トークンとは、Claude が生成して返してきたすべてのテキスト です。

• ターミナルに表示される応答メッセージ
• Claude が Write / Edit で書こうとしたファイルの内容
• ツール呼び出しの引数（内部的に文字列として出力される）
• Extended Thinking の「思考プロセス」部分（Opus 4 で有効化した場合）

出力は入力の 5 倍前後の単価 です。これには技術的な理由があります。LLM は 1 トークンずつ 自己回帰的に 次のトークンを予測しているため、出力 1000 トークンは「1000 回モデルを走らせる」のと等価です。一方、入力はまとめて 1 回でエンコードできます。

③ キャッシュトークン（Cache） — 同じ入力を 使い回す 分

3 つ目のキャッシュトークンが、Claude Code の請求書を初見の人がいちばん戸惑う項目です。

Anthropic は プロンプトキャッシュ という仕組みを提供しています。これは、毎回似たような長いプロンプトを送る用途（ Claude Code はまさにそれ ）のために用意された割引機構です。

仕組みはシンプルです。

1 回目のリクエスト
  ┌─────────────────────────────┐
  │ システムプロンプト           │
  │ CLAUDE.md                   │ → これを「キャッシュ書き込み」として保存
  │ 過去の会話 1〜4 ターン目     │
  ├─────────────────────────────┤
  │ 5 ターン目の新しい質問       │ → これだけ通常の入力トークン
  └─────────────────────────────┘

2 回目のリクエスト（数分以内）
  ┌─────────────────────────────┐
  │ システムプロンプト           │
  │ CLAUDE.md                   │ → ==キャッシュ読み取り（10% 価格）==
  │ 過去の会話 1〜5 ターン目     │
  ├─────────────────────────────┤
  │ 6 ターン目の新しい質問       │ → これだけ通常の入力トークン
  └─────────────────────────────┘

つまり、前のターンと同じ「前半部分」は安く再利用される という仕組みです。Claude Code は内部的に自動でキャッシュ書き込み・読み取りを行うので、ユーザーが意識する必要はありません。ただし、料金構造を理解すると「なぜ /compact が効くのか」「なぜ毎回 /clear するとむしろ割高になるのか」が腹に落ちます。

モデル別単価表 — 2026 年時点の公式料金

ここで、現時点の Anthropic 公式料金を整理しておきます。価格は時々アップデートされるので、最終的には console.anthropic.com/pricing を必ず確認してください。

表 1 — 通常の入出力単価（USD / 100 万トークン）

3 モデル共通で 出力は入力の 5 倍 という関係が一定です。これは LLM の構造上の特徴で、しばらく変わらないと思っておいて OK です。

表 2 — プロンプトキャッシュ単価（USD / 100 万トークン）

キャッシュ読み取りは通常入力の 10% に値引き される一方で、キャッシュ書き込みは 1.25 倍 です。つまり「2 回以上同じ前半部分を使い回す」ときに初めて元が取れます。Claude Code のような長セッション用途では、3〜10 ターンの会話で確実に元を取れます。

表 3 — モデルごとの「向き不向き」

1 セッション当たりの実コスト — 電卓を叩いてみる

抽象的な単価表を眺めても体感は得られません。1 セッションの請求がいくらになるかを、具体例で組み立ててみます。

シナリオ A — 5 ファイル編集の小さなタスク（Sonnet）

「React コンポーネント 3 つを修正し、テスト 2 つを追加してくれ」というよくあるタスクを想定します。

内訳（推定）
────────────────────────────────────────────────
入力（通常）         12,000 トークン   $3 / 1M × 0.012M = $0.036
入力（キャッシュ書込）8,000 トークン   $3.75 × 0.008    = $0.030
入力（キャッシュ読取）40,000 トークン  $0.30 × 0.040    = $0.012
出力                 6,000 トークン   $15 × 0.006     = $0.090
────────────────────────────────────────────────
合計                                                    $0.168
日本円換算（@150 円）                                   約 25 円

「ファイル 5 つを編集して 30 円かからない」というのが実感です。1 日に 5〜10 セッションこなしても 150〜300 円、月 20 営業日で 3000〜6000 円。単発の作業で見ると、ランチ 1 回より安い ことが分かります。

シナリオ B — 1 万行を読み込む大規模リファクタ（Sonnet）

巨大プロジェクトの一括リファクタを 1 セッションでやり切る、というケースです。

内訳（推定）
────────────────────────────────────────────────
入力（通常）         50,000 トークン   $0.150
入力（キャッシュ書込）80,000 トークン   $0.300
入力（キャッシュ読取）300,000 トークン  $0.090
出力                 40,000 トークン  $0.600
────────────────────────────────────────────────
合計                                  $1.14
日本円換算                            約 170 円

「1 万行のリファクタが 170 円」というのは、人間の時給と比較するとほぼ無料に近いです。これを 30 分でやっているなら、時給換算 340 円のコストで、エンジニアの 1 日分の仕事を済ませている計算になります。

シナリオ C — 同じ作業を Opus でやった場合

同じシナリオ B を Opus 4.7 でやると、単価が 5 倍になるので素直に 5 倍になります。

Opus 換算         $1.14 × 5 = $5.70
日本円           約 850 円

月 100 セッションを Opus でこなすと $570、Sonnet なら $114。この差は、年間に直すと 5 万円以上になります。Opus はピンポイントで使うのが鉄則です。

コンテキストウィンドウとコスト — 大きい文脈の累積コスト

ここまでで「==1 セッション = 大した金額じゃない」という感覚は掴めたと思います。次は 長く続けるとどうなるか== の話です。

Claude Code には コンテキストウィンドウ というハード制限があります。執筆時点で、Claude Sonnet/Opus は 200,000 トークン、ベータの拡張モードでは 1M トークン（Sonnet のみ）まで扱えます。

これが何を意味するかと言うと、1 セッション内では会話履歴がどんどん積み上がっていく ということです。

ターン 1: 入力  5,000  → 出力 2,000   累積入力  5,000
ターン 2: 入力  9,000  → 出力 3,000   累積入力 14,000
ターン 3: 入力 18,000  → 出力 4,000   累積入力 32,000  ← 重い
ターン 4: 入力 40,000  → 出力 5,000   累積入力 72,000  ← もっと重い
ターン 5: 入力 80,000  → 出力 6,000   累積入力 152,000 ← 危険水域

毎ターン、入力には それまでの会話履歴全部 + 新しい質問 が含まれます。キャッシュが効くので一律ではないですが、それでもターンが進むほど 1 ターンの単価は上がっていく というのが基本構造です。

これを避けるための打ち手は ==/compact と /clear== の使い分けです。

• ==/compact== — 過去の会話を要約して短くする。文脈は保たれるが、ニュアンスが落ちる
• ==/clear== — 会話を完全に消す。新しいタスクに切り替えるときに使う

「話題が変わったタイミング」で /clear、「同じタスクで長くなったとき」に /compact、というのが基本ルールです。第 9 章の続くレッスンで詳しい使い分けに踏み込みます。

/cost コマンド — セッション内コストを その場で 確認

ここで実機の話に戻ります。==/cost== は Claude Code に組み込まれている標準コマンドで、現在のセッションのトークン消費とコストを即座に表示します。

> /cost

Total cost:            $0.4612
Total duration (API):  3m 18.2s
Total duration (wall): 17m 42.0s
Token usage by model:
  claude-sonnet-4-6:
    Input:  82,341 tokens
    Cache read: 412,089 tokens
    Cache write: 22,108 tokens
    Output: 14,930 tokens

ここで読み取るべきポイントは 3 つ あります。

1. ==Total duration (API) と wall の差== — wall は実時間、API は実際に API を叩いていた時間。差が大きいほど「人間が考えてる時間」が長い（＝コスパ良い）
2. ==Cache read の割合== — Cache read がデカいほどキャッシュが効いている。理想は入力全体の 70% 以上
3. ==Output トークン== — これが膨らんでいるなら、Claude が長く書きすぎている可能性。出力こそ単価が高いので、ここを見て「もっと差分だけ返して」と指示するきっかけにする

# こまめに確認するルーティン
> /cost    # 作業開始時のベースラインを把握
> （作業）
> /cost    # 作業終了時に確認、想定とブレてないか見る

Anthropic Console — Usage 画面と Hard Limit

/cost はセッション内のリアルタイム表示でしたが、月全体の使用量と請求書 は Anthropic Console（console.anthropic.com）で見ます。

Usage 画面で見るべき 3 つの数字

1. Daily spend — 日別の支出グラフ。突発的に高い日を見つけてその日の作業を思い出す
2. Model breakdown — Opus / Sonnet / Haiku 別の支出。「Opus が予想より多い」と気づくきっかけ
3. Cache hit rate — キャッシュヒット率。これが 50% 未満なら、何かおかしい（たとえば /clear を多用しすぎている）

Hard Limit を必ず設定する

これがいちばん大事です。月額の Hard Limit を設定しておけば、たとえ何かのバグで暴走しても、ある金額で API が 自動的に停止 します。

Anthropic Console
  ├─ Settings
  │   └─ Billing
  │       └─ Spending limits   ← ここ
  │           ├─ Monthly budget: $50 ← 月額上限
  │           └─ Email alert:    $30 ← 60% で警告メール

最初のうちは 月 $20〜30 の上限 にしておくのが安全です。実際に月末で使い切らなければ、徐々に上げていきます。アラートは上限の 50〜70% に設定 するのが現実的です。

失敗パターン — 知らないと請求書が爆発する 5 つの落とし穴

ここまでで「理論上のコスト」は分かりました。最後に、実際にやらかしがちな 失敗パターン を 5 つ挙げます。

失敗 ① — コンテキスト溜め込み

最も多い失敗です。1 つのセッションで何時間も作業を続けると、コンテキストが膨らんで 1 ターンが 1〜2 ドルに達することがあります。

失敗 ② — 不要な大ファイルの読み込み

「とりあえずプロジェクト全体を見てもらおう」と全ファイルを読み込ませると、入力トークンが 30 万を超えることがあります。

失敗 ③ — リトライ祭り

曖昧な指示で何度もやり直させると、出力トークンが累積で膨らみます。出力は単価が 5 倍なので、ここが効きます。

> いい感じにして
> もっと良くして
> 違う、もっと別の感じで
> やっぱり最初のに戻して

> Tailwind の slate-50 背景、primary に #0AA5D4、
>   見出しは 24px の bold、サイドバーは左固定 240px、
>   この 4 つだけ反映してくれ。

失敗 ④ — Opus を なんとなく 選ぶ

「高性能なほうがいい気がする」で Opus を常用すると、Sonnet 比で 5 倍のコスト。月 $20 が月 $100 になります。

対処

1. デフォルトは Sonnet
2. Sonnet で 2 回失敗したら Opus に切り替え
3. 終わったら Sonnet に戻す（切り替えっぱなしを防ぐ）

失敗 ⑤ — Hard Limit を設定し忘れる

たいてい、これで初月に「思ったより高い」をやります。今すぐ Console を開いて設定してください。

計算演習 — 月 1000 セッションの試算

ここで実際に手を動かして、自分の利用イメージで月額を出してみます。

演習 1 — 個人開発者（中規模）

前提として、次のように仮定します。

• 月 1000 セッション（1 日あたり 33 セッション、結構ヘビー）
• 平均 5 万トークン / セッション（入力 4 万、出力 1 万、cache hit 60%）
• 利用モデルは Sonnet 4.6

1 セッション当たりの内訳
────────────────────────────────
入力（通常）    16,000 × $3.00/1M  = $0.048
入力（cache 読）24,000 × $0.30/1M  = $0.0072
出力          10,000 × $15.00/1M = $0.150
────────────────────────────────
1 セッション合計                     $0.2052

月額                                $0.2052 × 1000 = $205.20
日本円換算（@150 円）                約 30,800 円

月 30,000 円。これだと「Max 20x プラン（月 $200）」に切り替えたほうが安いラインです。Max プランへの乗り換え判断は、こうやって 自分の電卓で出す のが正解です。

演習 2 — ライトユーザー

• 月 100 セッション
• 平均 1.5 万トークン / セッション
• Sonnet 4.6

1 セッション           約 $0.07
月額                  $0.07 × 100 = $7.00
日本円換算            約 1,050 円

月 1,000 円 程度。これなら従量制が圧倒的にお得です。

演習 3 — Opus 混合（高性能タスク中心）

• 月 500 セッション、うち 100 セッションは Opus
• 平均 5 万トークン / セッション

Sonnet 400 セッション × $0.20  = $80
Opus   100 セッション × $1.00  = $100
────────────────────────────────
月額                            $180
日本円換算                      約 27,000 円

月 $180。これも Max プラン（$200）の手前。「あと月 100 セッション増えたら Max」というギリギリラインです。

補足 — 「Plan / Edit / Bash」など内部ツール呼び出しのコスト

ここまでの話に出てこなかったポイントを 1 つ補足します。Claude Code が裏で動かす ツール呼び出し（tool_use） も、すべて入出力トークンとしてカウントされます。

あなた: "src/foo.ts のバグを直して"
   ↓
Claude: tool_use → Read("src/foo.ts")     ← この呼び出し自体が出力
Read   : tool_result → ファイル内容       ← この内容が入力に追加
Claude: tool_use → Edit("src/foo.ts", ...) ← また出力
Edit   : tool_result → 編集成功           ← また入力
Claude: "直しました"                       ← 最後の出力

つまり ==ツール 1 回 = 入出力 1 セット がそれぞれ発生しています。Bash で長いログを出すと、その全文が入力トークンとして加算される== ので、grep | head などで絞り込ませる指示を入れると、地味に効きます。

まとめ — 請求書を読める人になろう

長丁場のレッスンでした。最後に、ここで押さえたポイントを 自分の言葉で説明できる レベルに引き上げてください。

1. トークン は「文字でも単語でもない、サブワード単位」。日本語は英語の 1.5〜2 倍トークンを消費する
2. 課金は 入力 / 出力 / キャッシュ の 3 種類。出力は入力の 5 倍。キャッシュ読み取りは入力の 10%
3. プロンプトキャッシュは Claude Code が裏で自動でやってくれる。長セッションのほうがキャッシュが効いて安くなる
4. モデルは Opus / Sonnet / Haiku。Sonnet が 9 割のタスクで最適
5. ==/cost で常時確認、Console で Hard Limit 設定==。これだけで請求書ショックは起きない
6. 月 1000 セッションを超えるなら Max プランへの切り替え を電卓で検討

<Checklist items={["Anthropic Console で Hard Limit を $30 に設定した","Anthropic Console で Email Alert を $20 に設定した","1 回 /cost を叩いて、cache read / write / output の比率を見た","自分の利用パターンで「月いくらか」を電卓で出してみた","Opus を常用していないか、設定を確認した"]} />

<Quiz question="Claude のプロンプトキャッシュで、キャッシュ「読み取り」の単価は通常の入力単価の何倍ですか？" options={["10%（つまり 1/10）","同じ","1.25 倍","5 倍"]} answer={0} />

<Quiz question="Sonnet 4.6 の出力単価（USD / 100 万トークン）はいくらですか？" options={["$15","$3","$75","$5"]} answer={0} />

<Quiz question="次のうち、コスト最適化として 最も効果が薄い のはどれですか？" options={["毎ターン /clear して会話を真っ新にする","話題が変わったら /clear、長くなったら /compact","Sonnet をデフォルトにして、必要時だけ Opus に切り替える","CLAUDE.md にプロジェクト情報を書いておく"]} answer={0} />

次のレッスン 9-2: トークン最適化 では、ここで掴んだコスト構造をもとに、実際に月額を 30〜50% 下げる具体的なテクニック を 5 つに整理します。/compact の使い所、CLAUDE.md の書き方、モデル切り替えのコツまで、明日からの請求書に効く話です。