LLM 開発の基礎:トークン・コンテキスト・料金

AI Navigate Original / 2026/5/16

共有:

要点

  • LLM開発前にトークン・コンテキスト・料金を押さえる。日本語は英語の1.5〜2倍トークン
  • コンテキストは入出力合計、2026は~100万級だが変動大で公式確認。長文は中盤が抜けるのでRAG/分割
  • 料金は変動が激しいので金額表は載せない。傾向のみ:出力が高い/軽量は桁違いに安い/キャッシュ・Batchで割引
  • 本番はRate Limit・Latency・Streaming・Tool Use/構造化出力も押さえる

LLM の API を初めて触る前に、トークン・コンテキスト・料金の 3 つだけは押さえておくと、コードもコスト試算も一気に見通しが良くなります。この 3 つは互いにつながっていて、「テキストはトークンに分解される → 一度に渡せるトークン数(コンテキスト)に上限がある → 使ったトークン数で課金される」という一本の流れになっています。本記事ではその流れを、2026 年時点の実際のモデルや仕組みを例にしながら、図とともに整理します。

入力テキスト トークン列 コンテキスト 入力+出力の枠 ¥ トークンで課金 料金

FIG.1 テキスト → トークン分解 → コンテキスト枠に収める → 使った量で課金、という一本の流れ

01トークン ── LLM が読む最小単位

LLM はテキストを「単語」ではなくトークンという小さな断片に分けて処理します。トークンは単語そのもののこともあれば、単語の一部・記号・空白のこともあります。たとえば tokenization のような語は tokenization のように複数トークンに割れますし、スペースや改行も 1 トークンとして数えられます。料金もコンテキストの上限も、このトークン数を基準に決まるため、まず「文字数ではなくトークン数で考える」癖をつけるのが出発点です。

  • 英語:おおむね 1 単語 ≈ 1.3 トークン、1 トークン ≈ 4 文字が目安。
  • 日本語:BPE 系のトークナイザではほぼ 1 文字 ≈ 1 トークンになりやすく、同じ意味の文でも英語の 3〜4 倍のトークンを食うことがある。漢字・かなで増減する。
  • コード:インデントの空白・記号・括弧もすべてトークンとして数えられる。
  • 画像・音声・動画:マルチモーダル入力もトークン換算で課金される(換算ルールは API ごとに異なるので公式を確認)。

トークン数を確認する方法

「このプロンプトは何トークンか」を事前に知りたい場面は多いです。提供元によって手段が異なります。

OpenAI(公開トークナイザ)Anthropic / Google(非公開)
tiktoken ライブラリや Web の Tokenizer ツールで、手元で正確に数えられるトークナイザが公開されていないため、専用 API(Anthropic の count tokens など)か経験的な概算で見積もる
事前に厳密なトークン数が分かる「英語 4 文字 ≈ 1 トークン/日本語はほぼ 1 文字 1 トークン」の目安で当たりを付ける

トークン量の感覚値

細かい正確さより、まず桁感をつかむのが実用的です。下表は英語テキストでのおおよその目安です(日本語は前述のとおり数倍に膨らみます)。

テキスト量概算トークン(英語目安)
短いあいさつ一文3〜10
1 段落(英語 約 350 語)約 500
ブログ記事 1 本2,000〜5,000
書籍 1 冊80,000〜150,000

料金もコンテキストの上限も、すべて トークン数を物差しにしている。

02コンテキストウィンドウ ── 一度に渡せる量

コンテキストウィンドウは、1 回の API 呼び出しで扱える最大トークン数です。重要なのは、これが入力(プロンプト+これまでの会話+渡した資料)と出力(生成される回答)の合計に効く上限だという点。長い資料を入れすぎると、その分だけ回答に使える枠が減ります。

2026 年時点では、上限はモデルによって大きく幅があります。たとえば Google の Gemini は 100 万トークン級(実験的にはさらに大きい構成)、OpenAI の GPT-5 系も 40 万〜100 万トークン級、Anthropic の Claude は標準 20 万トークンで、上位モデルでは 100 万トークンのベータ提供もあります。一方で軽量モデルは 12.8 万トークン程度のことも多い。数値は提供形態で異なり頻繁に変わるので、採用前に必ず公式ドキュメントで確認してください。

拾われる精度 先頭 中盤 末尾 中盤は見落とされやすい(lost in the middle)

FIG.2 窓が大きくても、文脈の中盤に置いた情報は拾われにくくなる U 字の傾向がある

ここで知っておきたい落とし穴が、「lost in the middle」と呼ばれる傾向です。コンテキストが長くなると、モデルは先頭と末尾の情報はよく拾う一方、中盤に置いた情報を見落としやすくなります。研究では、同じ情報でも位置を中盤にずらすだけで精度が大きく落ちる例が報告されています。つまり「窓が大きい=なんでも全部入れれば良い」ではありません。実用では、要点を絞る・分割する・RAG(検索拡張生成)で必要な部分だけ渡すほうが、安定して良い回答になります。重要な指示や資料は、できるだけ先頭か末尾に置くのもコツです。

上限を超えたときの挙動

  • 明示的にエラーになる:OpenAI / Anthropic などの API は、上限超過をエラーで返す。コード側でトークン数を見積もって事前に防ぐのが基本。
  • 古い会話が切り捨てられる:一部のチャット UI は、上限に近づくと古いやり取りを黙って落とす。長い会話で「前に言ったことを忘れた」ように見えるのはこれが原因のことがある。
  • 対処:会話履歴を要約して圧縮する、タスクを分割する、別セッションに分ける。

03料金体系 ── 出力が効く

多くの API は「入力トークン数 × 入力単価 + 出力トークン数 × 出力単価」で課金します。覚えておくべき最重要ポイントは、出力単価は入力単価より高いこと(モデルにもよりますが数倍が一般的)。長い回答を作らせるほど、コストはそちら側で伸びていきます。具体的な金額・モデル名は頻繁に変わるため、ここでは金額表は出さず、判断に効く「傾向」だけを押さえます。

  • 出力は入力より高い:「短く答えさせる」「履歴を要約してから渡す」だけでもコストに効く。
  • 軽量モデルは桁違いに安い:分類・要約・抽出などの簡単なタスクは、各社の小型モデル(mini / Haiku / Flash 級)で十分なことが多い。難しいタスクだけ大型モデルに回す「振り分け」が定石。
  • プロンプトキャッシュ:共通の長いシステムプロンプトや資料を繰り返し使う場合、キャッシュ機構で入力コストを大幅に下げられる。2026 年時点では OpenAI・Anthropic・Google が提供しており、キャッシュ済み入力は通常入力の 1〜2 割程度まで割引される(仕組み・割引率は各社で異なる)。
  • Batch API:即時性が不要な大量処理は、非同期のバッチ実行で割引される(各社おおむね半額前後)。夜間のまとめ処理などに向く。
  • 最新単価は各社公式の価格ページで確認する。全体としては値下がり傾向だが変動は大きい。
入力 出力(数倍) キャッシュ済み入力 (通常入力の1〜2割) 単価

FIG.3 出力は入力より割高、キャッシュ済み入力は大きく割安、という単価の相対関係(金額は各社・時期で変動)

1 回のコストを見積もる考え方

金額を暗記する必要はありません。「どの要素が効くか」を式で押さえておけば、単価を最新値に差し替えるだけで試算できます。

例:チャット 1 応答(入力 500 トークン / 出力 300 トークン)

  コスト ≈ 500 × (入力単価 / 100万トークン)
        + 300 × (出力単価 / 100万トークン)

→ 単価は公式の最新値を当てはめる。
  出力側が効くので、「短く答えさせる」「履歴を要約する」
  といった工夫だけでも合計コストを下げられる。

04まず無料・低コストで試す

いきなり課金しなくても、手を動かして感触をつかむ方法はいくつかあります。最新の上限や条件は変わるので、必ず公式で確認してください。

無料枠を使う

Google AI Studio(Gemini API)などには無料の利用枠がある。まずここで「トークンが減る」「上限に当たる」を体感するのがおすすめ。

初回クレジット

各社で新規登録時に初回クレジットが付くことがある。小さなプロトタイプならこれで足りる場合も多い。

ローカル LLM

Ollama や vLLM でモデルを自分の PC・サーバーで動かせば、API 料金はゼロ。性能は大型 API に劣るが、トークンやコンテキストの挙動を学ぶには十分(後の記事で詳説)。

05本番で必要になる追加の概念

3 概念に慣れたら、実サービスに載せる前に次の 4 つも押さえておくと、つまずきが減ります。

01

Rate Limit(レート制限)

単位時間あたりの呼び出し回数・トークン数に上限がある。超えると一時的にエラーになるので、指数バックオフ(待ち時間を倍々にして再試行)で受け止める。

02

Latency(応答時間)

回答が返るまでの時間。モデルの大きさや渡したコンテキストの長さで変わる。長文を入れるほど遅くなりがち。

03

Streaming(逐次出力)

回答を一文字ずつ流して表示する方式。総時間は変わらなくても、ユーザーの体感速度が大きく改善する。

04

Tool Use / 構造化出力

関数呼び出しや JSON など、後工程のプログラムが扱いやすい形で受け取る仕組み。自由文をパースするより堅牢。

Cost & Reliability

コストと安定性は「設計」で決まる

トークン・コンテキスト・料金は別々の知識に見えて、実は一つの最適化問題です。渡すトークンを絞れば、コンテキストの中盤埋もれも減り、料金も下がり、応答も速くなる ── 効果が連鎖します。逆に「とりあえず全部入れる」設計は、コスト増・精度低下・遅延のすべてを同時に招きます。

実務でまず効く打ち手は、① 出力を短く保つ(出力単価が高いため)、② 簡単なタスクは軽量モデルに振り分ける、③ 共通の長いプロンプトはキャッシュする、④ 必要な情報だけを RAG で渡すの 4 つ。どれもトークンを減らす方向に働き、コストと品質を同時に押し上げます。

06次のステップ

トークン・コンテキスト・料金の関係がつかめたら、次は実際に手を動かす番です。次の記事「API アカウント作成と料金」で、API キーの取得から最初の呼び出しまでを進めます。本記事で見た「トークンで課金される」感覚を持っておくと、最初のリクエストでメーターが動くのが具体的に理解できるはずです。