Claude Code のトークンを理解する - 日本語と文字数の関係、課金の仕組み、利用料を抑えるコツ

Claude Code を使っていると、料金やレート制限の話で必ず出てくるのが「トークン（token）」です。「日本語だとトークンを食いやすい」とよく言われますが、実際のところ文字数とどう違うのか、なぜ日本語は不利になりやすいのか、そして利用料を抑えるには何をすればいいのか。

この記事では、Anthropic 公式ドキュメントの情報をもとに、トークンの基礎・日本語との関係・課金の基準・節約のコツを整理します。

トークンとは何か

LLM はテキストをそのまま文字単位で読むのではなく、「トークン」という単位に分割して処理します。トークンは単語そのものだったり、単語の一部だったり、記号だったりします。英語では Hello は1トークン、Hello, world! は4トークン（Hello / , / world / !）といった具合です。

英語の目安として、1トークンはおおよそ4文字、または約0.75単語に相当します。つまり文字数とトークン数はだいたい比例しますが、イコールではありません。

Claude の課金・コンテキスト長・レート制限はすべて、この文字数ではなく「トークン数」を基準に計算されます。だからこそ、文字数の感覚ではなくトークンの感覚を持っておくと、料金が読めるようになります。

日本語はどうなるのか

ここが本題です。英語が「1トークン ≒ 4文字」と効率よく分割できるのに対し、日本語をはじめとする非ラテン文字は、1文字あたりに必要なトークン数が多くなりがちです。一般に、非ラテン文字は文字あたり英語の2〜4倍程度のトークンを消費するとされています。

ざっくりした目安が以下です。あくまで概算で、実際の値はテキストの内容やトークナイザのバージョンで変わります。

注意したいのは、「日本語は文字あたりのトークンが多い」ことと「同じ内容を伝えるのに日本語の方が高い」ことはイコールではない点です。日本語は1文字あたりの情報量が多いため、同じ意味を表す英文より文字数自体は少なくなる傾向があります。とはいえ、文字あたりのトークン効率の悪さがそれを上回ることが多く、結果として同じ内容なら日本語の方がトークン数が増えやすい、というのが実務上の体感に近いところです。

正確に測るには公式のトークンカウントAPIを使う

目安は目安でしかありません。料金やコンテキスト消費をきっちり見積もりたいなら、Anthropic のトークンカウントAPI（count_tokens）を使うのが確実です。このエンドポイントは無料で、メッセージ作成時と同じ入力（システムプロンプト・ツール・画像・PDF）を受け取り、入力トークン数を返します。

curl https://api.anthropic.com/v1/messages/count_tokens \
    --header "x-api-key: $ANTHROPIC_API_KEY" \
    --header "content-type: application/json" \
    --header "anthropic-version: 2023-06-01" \
    --data '{
      "model": "claude-opus-4-8",
      "messages": [{
        "role": "user",
        "content": "今日はいい天気ですね"
      }]
    }'

公式ドキュメントの例では、システムプロンプト You are a scientist ＋ ユーザー発話 Hello, Claude で input_tokens は 14 でした。日本語と英語で同じ意味の文を投げて数値を比べてみると、トークン効率の差を体感できます。

[!NOTE] トークンカウントの結果は「見積もり」です。実際の生成時とは多少ずれることがあります。また、Anthropic がシステム最適化のために自動付与するトークンはカウントに含まれることがありますが、その分は課金されません（課金対象は自分のコンテンツのみ）。

Python SDK なら次のように書けます。

import anthropic
 
client = anthropic.Anthropic()
 
resp = client.messages.count_tokens(
    model="claude-opus-4-8",
    messages=[{"role": "user", "content": "今日はいい天気ですね"}],
)
print(resp.json())  # {"input_tokens": ...}

Claude Code の課金の基準

Claude Code は、消費した API トークンに応じて課金されます。トークンには大きく次の種類があります。

• 入力トークン（input）: あなたのプロンプト、CLAUDE.md、ファイルの中身、ツールの実行結果など、Claude に渡したすべて
• 出力トークン（output）: Claude が生成した応答。拡張思考（extended thinking）のトークンも出力トークンとして課金される
• キャッシュ関連トークン: プロンプトキャッシュへの書き込み・読み出し

たとえば Claude Opus 4.8 の標準価格は入力 $5 / 出力 $25（100万トークンあたり）です。料金は「やりとりした文字数」ではなく、この入出力トークンの合計で決まります。

注意したいのは、会話が長くなるほど毎ターンのコストが上がるという点です。Claude Code はセッション中の文脈（過去のやりとり、読んだファイル、ツール出力）を都度モデルに渡すため、コンテキストが膨らむと「1回の発言」あたりの入力トークンが増えていきます。

使用量を可視化する

Claude Code には使用量を見るコマンドがあります。

• /usage: 現在のセッションのトークン使用量・推定コストを表示（API 利用者向けの推定値。サブスクの場合はプラン消費の内訳も表示される）
• /context: 何がコンテキストを消費しているかを確認

公式ドキュメントによると、エンタープライズ全体での平均は1開発者あたり1稼働日約 $13、月 $150〜250 程度で、90% のユーザーは1稼働日 $30 未満に収まっているとされています。プロンプトキャッシュと自動コンパクションによる最適化は標準で効いています。

利用料を抑えるコツ

Claude Code 公式の「コスト管理」ガイドにある実践策を、効果の大きい順に整理します。要は「コンテキストを小さく保つ」のが本質です。

1. コンテキストをこまめに切る

• 無関係な作業に移るときは /clear で文脈をリセットする。古い文脈は以降の毎メッセージでトークンを浪費する
• 長くなってきたら /compact。/compact コードサンプルとAPI使用箇所を中心に のように要約方針を指定できる
• 複雑なタスクはプラン モード（Shift+Tab）で先に方針を固める。誤った方向に進んで作り直す無駄を防げる

2. モデルを使い分ける

• ふだんは Sonnet で十分。深い分析や複雑なリファクタなど、必要なときだけ Opus に切り替える（/model）
• サブエージェントの単純作業は model: haiku を指定する

3. 拡張思考（thinking）を絞る

拡張思考は既定で有効で、思考トークンは出力トークンとして課金されます。単純なタスクでは /effort で effort レベルを下げる、/config で思考をオフにする、MAX_THINKING_TOKENS=8000 のように予算を下げる、といった調整が効きます。

4. ツール出力とMCPを節約する

• ファイル読み込み・シェル実行・MCP 呼び出しの出力は、要約ではなく全文がコンテキストに残る。1万行のログを読むと、その後の毎メッセージで1万行ぶんのトークンを引きずる
• 冗長な処理（テスト実行・ログ処理・ドキュメント取得）はサブエージェントに逃がし、本体には要約だけ返す
• フックで前処理する。たとえばテスト出力を grep ERROR で絞ってから Claude に渡せば、数万トークンを数百トークンに減らせる
• MCP より CLI ツール（gh / aws / gcloud 等）を優先する。MCP のツール定義はコンテキストを食うため、未使用サーバーは /mcp で無効化する

5. プロンプトを具体的に書く

「このコードベースを改善して」のような曖昧な依頼は広範囲のスキャンを誘発します。「auth.ts のログイン関数に入力バリデーションを追加して」のように具体的に書くと、最小限のファイル読み込みで済みます。

6. CLAUDE.md は短く保つ

CLAUDE.md はセッション開始時に読み込まれ、その後ずっとコンテキストに残ります。特定ワークフローの詳細手順は Skills に移し、CLAUDE.md は要点だけ（目安として200行以内）に保つと、ベースのコンテキストが小さくなります。

なお、プロンプトキャッシュ自体は標準で効いていますが、仕組みを理解して活かすとさらに効率が上がります。詳しくは Claude Prompt Caching と Pre-warming の解説記事 を参照してください。

日本語ユーザーならではの注意点

日本語は文字あたりのトークンが重いという特性は、Claude Code の使い方にも効いてきます。

• CLAUDE.md やシステム指示を日本語で長々と書くと、そのぶん毎ターンのトークンが増える。要点を簡潔に書く意識が、英語以上に効く
• 大きな日本語ドキュメントを丸ごと読ませると入力トークンが膨らみやすい。必要箇所だけ渡す、要約を渡す、といった工夫が有効
• コスト最重視のバッチ処理では、指示や定型部分を英語にするとトークンを減らせる場合がある。ただし可読性・チーム運用とのトレードオフなので、無理に英語化する必要はない

結局のところ、日本語か英語かよりも「余計な文脈を渡さない」ことのほうが効果は大きいです。日本語特性は、その意識を一段強める理由くらいに捉えておくとよいでしょう。

まとめ

• トークンは LLM がテキストを処理する単位。英語は1トークン ≒ 約4文字だが、日本語は1文字 ≒ 約1トークン前後と、文字あたりのトークンが重い
• 同じ内容なら日本語の方がトークン数が増えやすい。正確に測るなら無料の count_tokens API を使う
• Claude Code は入力・出力（思考含む）・キャッシュのトークン合計で課金される。会話が長いほど毎ターンのコストが上がる
• /usage と /context で使用量を可視化できる
• 節約の本質は「コンテキストを小さく保つ」こと。/clear・/compact、モデルの使い分け、thinking の調整、ツール出力・MCP の節約、具体的なプロンプト、短い CLAUDE.md が効く
• 日本語はトークンが重いぶん、CLAUDE.md や指示文を簡潔に保つ効果が英語以上に大きい

参考リンク

• Token counting（Claude API 公式ドキュメント）
• Manage costs effectively（Claude Code 公式ドキュメント）
• Claude Opus 4.8 リリースまとめ（当ブログ）
• Claude Prompt Caching と Pre-warming 徹底解説（当ブログ）