LLMのトークンとは？料金計算・コンテキスト長・コスト最適化の基本

LLMのAPIを使い始めて最初にぶつかる壁が「料金がいくらかかるのか見当がつかない」という問題です。LLMの料金は「トークン」という単位の利用量に比例しており、この仕組みを正しく理解すれば月額コストは十分にコントロール可能です。本記事では、トークンの定義から料金計算の実例、コンテキスト長のトレードオフ、そして明日から使える7つの最適化手法までを、具体的なコードと試算例を交えて解説します。

トークンとは何か――LLMの「言葉の単位」

トークンとは、LLMがテキストを処理する際の最小単位です。人間にとっての「文字」や「単語」に相当しますが、LLM内部ではもう少し細かく、あるいは粗く分割される点が特徴です。英語であれば1単語がおおむね1〜2トークンに収まりますが、日本語は1文字あたり1〜3トークンへと膨らむ傾向があり、同じ意味を伝えるのに英語の約1.5〜3倍のトークンを消費します。料金はこのトークン数に直結するため、言語の違いが月額費用を大きく左右するのです。

実際にどのように分割されるのか、OpenAIのtiktokenライブラリを使って確認してみましょう。

import tiktoken

encoding = tiktoken.encoding_for_model("gpt-4o")

english_text = "The quick brown fox jumps over the lazy dog."
japanese_text = "生成AIは企業のデータ活用を変革します。"

print(f"英語 : {len(encoding.encode(english_text))} tokens")
print(f"日本語: {len(encoding.encode(japanese_text))} tokens")
# 英語 : 10 tokens
# 日本語: 21 tokens

トークンと料金の関係――API課金の仕組み

LLM APIの料金はほぼ例外なく「入力トークン」と「出力トークン」の二階建てで設定されています。興味深いのは、多くのモデルで出力料金が入力料金の3〜5倍に設定されている点です。これは生成処理が読み取り処理より計算量を必要とするためで、長い応答を出力させるほどコストが跳ね上がるという構造になっています。さらに最近は「プロンプトキャッシュ」という仕組みが広く普及し、同一のプレフィックスを繰り返し送信する場合は大幅な割引が適用されるようになりました。

モデル	入力 / 1Mトークン	出力 / 1Mトークン	最大コンテキスト長	キャッシュ割引
GPT-4o	約 2.50 USD	約 10.00 USD	128K	最大50%
GPT-4o mini	約 0.15 USD	約 0.60 USD	128K	最大50%
Claude 3.5 Sonnet	約 3.00 USD	約 15.00 USD	200K	最大90%
Claude 3.5 Haiku	約 0.80 USD	約 4.00 USD	200K	最大90%
Gemini 1.5 Pro	約 1.25 USD	約 5.00 USD	1M	最大75%
Gemini 1.5 Flash	約 0.075 USD	約 0.30 USD	1M	最大75%

※料金は2026年4月時点の公開情報を元にした概算。最新の正確な料金は各プロバイダの公式ドキュメントをご確認ください。

APIレスポンスにはusageフィールドが含まれ、実際に消費したトークン数を確認できます。運用段階ではこの情報をログに残し、ユーザーやエンドポイント単位で集計することでコスト異常の早期検知につながります。

from openai import OpenAI
client = OpenAI()

response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": "LLMのトークンとは何ですか？"}],
)

usage = response.usage
print(f"入力: {usage.prompt_tokens} / 出力: {usage.completion_tokens}")

コンテキスト長(コンテキストウィンドウ)の理解

コンテキスト長とは、LLMが一度の推論で扱える入力と出力を合算した最大トークン数のことです。「入力が128Kなら出力も128Kいけるのだろう」と誤解される方が後を絶ちませんが、あくまで合計の上限である点に注意が必要です。長文の契約書分析やRAG構成での大量ドキュメント参照など、長いコンテキストが必要なユースケースでは、コンテキスト長の大きなモデルを選択することが前提となります。ただし、入力が長くなればそのまま入力トークン料金に跳ね返るため、「長いコンテキストが使えること」と「それを使うべきか」は別問題として考えるべきです。

【コンテキストウィンドウの構造】

[システムプロンプト]  約500トークン
        +
[会話履歴]            約2000トークン
        +
[ユーザー入力]        約1000トークン
        +
[アシスタント出力]    最大4000トークン
        =
合計 約7500トークン  ----> モデル上限128K以内に収める

※入力と出力は同じ予算を共有する。長い履歴を渡すほど
  出力に使える残りトークンは減っていく。

トークンコスト最適化の7つの手法

ここからが本題です。実務で効果の高い7つの最適化手法を、難易度順に整理してご紹介します。いずれも「できるものから手をつける」スタンスで十分で、複数を組み合わせることで削減効果は掛け算で効いてきます。

プロンプトの簡潔化――冗長な前置き、不要な例示、重複する注意書きを削ぎ落とします。最も基本でありながら、最初の30%削減はここで達成できることが多いです。
プロンプトキャッシュの活用――システムプロンプトやRAGコンテキストなど変化しない部分をキャッシュ対象として固定化し、課金対象を大幅に圧縮します。
適切なモデルサイズの選択――分類・要約・抽出といった定型タスクは軽量モデルで十分です。GPT-4oからGPT-4o miniへの切り替えだけでコストは1/15以下になります。
バッチ処理によるスループット最適化――リアルタイム性を要さない処理はバッチAPIに回し、通常料金の半額で処理できます。
出力トークン数の制限――max_tokensを適切に設定することで、想定外の長文応答による請求額の跳ね上がりを防ぎます。
ストリーミングの活用――直接のコスト削減ではありませんが、UX改善とタイムアウト防止、ユーザーの中断による無駄トークンの抑制につながります。
レスポンスキャッシュ――FAQのような繰り返し問われるクエリは結果を保存し、完全一致の場合はLLMを呼ばずに返却します。

手法	コスト削減率目安	実装難易度	適用条件
プロンプト簡潔化	10〜30%	低	既存プロンプトに冗長性がある
プロンプトキャッシュ	30〜70%	低	固定プレフィックスが大きい
軽量モデル選択	50〜95%	低	定型タスク、精度許容度あり
バッチ処理	約50%	中	非同期処理が許容される
max_tokens制限	5〜20%	低	出力長のブレが大きい
ストリーミング	5〜10%	中	対話UI・長文出力
レスポンスキャッシュ	20〜60%	中	FAQ系、同一クエリ多発

コスト試算の実践――月額費用をシミュレーションする

具体的なシナリオで試算してみましょう。シナリオ1は社内チャットボットで、1日100件の問い合わせを想定し、平均入力500トークン、平均出力300トークンとします。シナリオ2は文書分析バッチで、月1,000件の契約書レビューを想定し、平均入力10,000トークン、平均出力1,500トークンとします。

def monthly_cost(requests_per_month, in_tokens, out_tokens,
                 in_price_per_1m, out_price_per_1m, usd_jpy=150):
    input_cost = requests_per_month * in_tokens * in_price_per_1m / 1_000_000
    output_cost = requests_per_month * out_tokens * out_price_per_1m / 1_000_000
    total_usd = input_cost + output_cost
    return total_usd, total_usd * usd_jpy

# シナリオ1: 社内チャットボット (GPT-4o mini)
usd, jpy = monthly_cost(100 * 30, 500, 300, 0.15, 0.60)
print(f"チャットボット: {usd:.2f} USD / 約{jpy:.0f} 円")

# シナリオ2: 契約書分析バッチ (GPT-4o)
usd, jpy = monthly_cost(1000, 10000, 1500, 2.50, 10.00)
print(f"契約書分析    : {usd:.2f} USD / 約{jpy:.0f} 円")

実行すると、チャットボットは月額数百円、契約書分析バッチは月額6,000円前後に収まる試算となります。このレベルであれば「ざっくり見積もりを外して怒られる」リスクは極めて低くなります。重要なのは、本格展開前に必ず小規模パイロットで実測値を取り、この計算式に代入して現実的な数字を手に入れることです。

まとめ――トークンを理解してコストを制御する

トークンはLLMの処理単位であり、日本語は英語の1.5〜3倍を消費する
料金は入力・出力で異なり、出力側が数倍高いことを前提に設計する
コンテキスト長は入力と出力の合計上限であり、長ければ良いわけではない
最適化は「軽量モデル＋キャッシュ＋簡潔化」の組み合わせが最強

DE-STKでは、LLM導入前のコストシミュレーションから運用フェーズでの最適化まで、トークン経済学に基づいた実装支援を行っております。API料金が想定を超えて膨らんでいる方も、これから導入を検討している方も、お気軽にご相談ください。

よくある質問

Q. LLMのトークンとは何ですか?

トークンはLLMがテキストを処理する最小単位です。英語では1単語が1〜2トークン程度、日本語では1文字が1〜3トークン程度に分割されます。APIの料金はこのトークン数に基づいて計算されるため、運用コストを見積もる際の基礎単位となります。

Q. LLMのAPI料金を安くする方法はありますか?

プロンプトの簡潔化、プロンプトキャッシュの活用、タスクに応じた軽量モデルの選択が効果的です。特にGPT-4o miniやClaude Haikuなどの軽量モデルは、分類や要約などの定型タスクで十分な性能を発揮しつつ、コストを1/10以下に抑えられます。複数手法の組み合わせで半減以上の削減も現実的です。

Q. コンテキスト長とは何ですか?

LLMが一度に処理できるトークンの最大数です。入力（プロンプト）と出力（応答）の合計がこの上限を超えることはできません。2026年時点では100K〜200Kトークン、あるいは1Mトークン級のモデルも登場していますが、長いコンテキストほどコストとレイテンシが増加するため、必要な分だけを渡す設計が重要です。