AI を使うとき、必ず裏で数えられている単位があります。それがトークンです。文章は「単語」ではなく、もっと細かいトークンへ分解されてからモデルに渡されます。このトークンこそが、料金の単位であり、一度に扱える量の上限（コンテキスト窓）でもあります。ここを押さえると、「なぜ長文を貼ると高くつくのか」「なぜ途中から会話を忘れるのか」が一本の理屈でつながります。
FIG.1 文章はトークンに割られ、その個数で課金と容量が決まる
01トークンとは何か
トークンは、モデルがテキストを処理するときの最小単位です。単語そのものではなく、もっと細かい「文字のかたまり」だと考えるとつかみやすいです。よく出てくる語は 1 個のトークンにまとまり、珍しい語や記号は複数に割れます。
英語の例で見ると分かりやすいです。
hello→ 1 トークン（頻出語はまるごと 1 個）electricity→ 1 トークンprestidigitation（珍しい語）→ 4 トークン程度（pre/stid/ig/itationのように分割）AI→ 1 トークン
日本語は事情が違います。英語ほど「単語まるごと 1 トークン」になりにくく、おおむね 1 文字あたり 1 トークン前後に割れます。つまり同じ意味でも、日本語は英語より多くのトークンを消費します。実測の研究では平均しておよそ 2 倍（文によっては数倍）に達するとされます。料金やコンテキスト容量を見積もるとき、ここを軽く見ると後で数字がずれます。
| テキストの種類 | 1 トークンあたりの目安 |
|---|---|
| 英語 | 約 4 文字（≒ 0.75 単語） |
| 日本語 | 約 1 文字前後（英語の約 2 倍のトークン数） |
| 中国語・韓国語 | 約 1 文字前後（日本語と同様に重い） |
| プログラムコード | 記号や改行も数えるため文字数の割に多め |
目安はトークナイザ（モデルごとの分割方式）によって変わります。正確に知りたいときは、各社が公開するトークナイザやトークン数カウンタで実際に数えるのが確実です。
トークンは、AI にとっての「文字数の代わりのものさし」。料金も上限も、すべてこの個数で測られる。
02コンテキスト窓：一度に見渡せる量
コンテキスト窓（context window）とは、1 回のやり取りでモデルが同時に見渡せるトークンの最大数です。会話履歴・指示文・貼り付けた資料・モデルが書く返答――これら全部を合わせた合計が、この窓に収まっていなければなりません。窓を超えた分は、古いものから押し出されて「見えなくなる」と考えてください。長い会話の途中で前半の話を忘れたように見えるのは、これが原因です。
FIG.2 窓に収まれば全部見える。超えた分は外にこぼれて参照されない
2026 年時点では、コンテキスト窓はモデルによって大きく差があります。下表は主要モデルの代表的な値です（仕様は更新が早いので、最新は各社の公式ドキュメントで確認してください）。
| モデル | コンテキスト窓（目安） |
|---|---|
| GPT-4o / GPT-4.1（一世代前の主力） | 128K トークン |
| GPT-5.4 / GPT-5 系 | 400K トークン |
| GPT-5.5（OpenAI 最新フラッグシップ） | 512K トークン（既定） |
| Claude Opus 4.6 / Sonnet 4.6 | 最大 1M トークン |
| Gemini 3.1 Pro | 最大 2M トークン |
| Gemini（実験的提供）/ 一部 Llama 4 系 | 最大 10M トークン級 |
128K でも日本語で 8 万字前後、一般的な業務文書なら十分に収まる規模です。実際、多くの実運用は 128K〜200K の範囲で間に合います。一方、コードベース全体や長大なマニュアルを丸ごと渡したい用途では、100 万〜数百万トークン級の窓が役に立ちます。
03窓が大きい＝賢い、ではない
窓が広いほど性能が上がる、と思いがちですが、そう単純ではありません。長い入力では、中央あたりに置いた情報が見落とされやすい傾向が繰り返し観測されています（しばしば「Lost in the Middle（中央が埋もれる）」と呼ばれます）。先頭と末尾は強く効くのに、真ん中は拾われにくい、という偏りです。
ベンチマークでも、入力を長くするほど正答率が落ちるモデルが多く、その下がり方には差があります。つまり「窓に入る＝ちゃんと読まれる」ではありません。実務では次の工夫が効きます。
- 重要な情報は先頭か末尾に置く（中央に埋めない）
- 長文は「要約＋必要な詳細」の階層にして渡す
- 全部入れようとせず、RAG（検索）で必要な部分だけ切り出して渡す
大きな窓は「とりあえず全部貼れる」ための保険であって、「全部読ませれば賢くなる」ためのものではない、と捉えておくと判断を誤りません。
04課金の仕組み：入力と出力で別単価
多くの API は、トークン数に応じた従量課金です。基本の式はとてもシンプルです。
料金 ＝ 入力トークン × 入力単価 ＋ 出力トークン × 出力単価
ここで重要なのは、出力（モデルが書く側）の単価は、入力（こちらが渡す側）より高く設定されているのが一般的だという点です。たとえば 2026 年 6 月時点の OpenAI 主要モデルでは、おおむね次のような水準です（金額は変動が速いため、必ず公式の最新価格を確認してください）。
| モデル | 100万トークンあたり（入力 / 出力・目安） |
|---|---|
| GPT-5.5（フラッグシップ） | 約 $5 / $30 |
| GPT-5.4 | 約 $2.50 / $15 |
| GPT-5 | 約 $1.25 / $10 |
具体的に 1 リクエストのコストを計算してみます。GPT-5.4（仮に入力 $2.50・出力 $15 / 100万トークン）で、入力 5,000 トークン・出力 500 トークンを処理した場合は次のようになります。
入力ぶん
5,000 × $2.50 ÷ 1,000,000 ＝ $0.0125
出力ぶん
500 × $15 ÷ 1,000,000 ＝ $0.0075
合計
$0.0125 ＋ $0.0075 ＝ 約 $0.02（数円程度）。出力は少量でも単価が高い点に注意。
1 回あたりは小さく見えますが、後で見るとおりこれが積み上がります。なお、入力単価が安いからといって長文を無制限に貼ると入力トークンが膨らみ、結局コストも遅延も増えます。「短く渡す」ことは料金と速度の両方に効きます。
05プロンプトキャッシュ：繰り返しを安くする
同じシステムプロンプトや長い前置きを毎回送るような使い方では、プロンプトキャッシュが効きます。一度処理した前半部分を再利用することで、その部分の入力料金を大きく下げる仕組みです。エージェントのように同じ指示を何度も送る運用では、コスト削減の主力になります。
ただし割引率や課金方式は提供元によって異なります。「どこでも一律 90% オフ」ではない点に注意してください。2026 年時点の代表的な傾向は次の通りです（条件は変わるため公式確認を）。
| 提供元 | キャッシュの考え方（目安） |
|---|---|
| Anthropic（Claude） | キャッシュ読み出しは通常入力の約 1/10（およそ 9 割引）。書き込みに割増あり |
| OpenAI | キャッシュ済み入力をモデル依存で割引（おおむね 25〜50% 程度）。一定長以上で自動適用 |
| Google（Gemini） | トークン単価の割引ではなく、保存時間に応じた料金体系 |
共通して言えるのは、「変わらない前半（指示・規約・参照文書）を固定し、変わる後半（ユーザー入力）だけを毎回差し替える」設計にすると、キャッシュが効きやすくなることです。
06トークンを減らす実践テクニック
料金も速度もトークン数で決まる以上、削減策はそのまま効きます。やりすぎて必要な情報まで削らない範囲で、次を検討します。
指示を簡潔に
システムプロンプトの冗長な言い回しを削る。意味が同じなら短い方が安い。
必要分だけ渡す
資料を丸ごとではなく、RAG で関連箇所だけ抽出して投入する。
形式を見直す
冗長な JSON より、Markdown や箇条書きの方が軽くなる場合がある。
- 例示は最小限に：大量のサンプルを貼るより、簡潔な指示で足りるケースは多い。
- キャッシュを活かす：固定部分を前半にまとめ、毎回同一にする（前章）。
- 窓に入っても全部入れない：拾いすぎは料金・遅延・精度（中央埋もれ）すべてに悪い。
Cost at Scale
1 回は数円。でも積むと桁が変わる
単発では小さなコストも、規模が掛け算で効くと一気に膨らみます。たとえば「1 ユーザーが 1 日 50 リクエスト、1 回あたり約 $0.02、利用者 1 万人、365 日」という仮定で年間コストを概算すると――
FIG.3 1 回 $0.02 × 50 × 1 万 × 365 ≒ 年 $3.6M。単価より「掛かる回数」が効く
桁としては年間で数百万ドル規模に届きます。だからこそ、1 リクエストあたりのトークンを削る・キャッシュで再利用する・軽いモデルで足りる処理は軽いモデルに回すといった工夫が、規模が大きいほど大きな差になって返ってきます。
07よくある勘違い
- 「1 トークン＝1 単語」ではない。珍しい語は分割され、日本語は 1 文字前後に割れる。文字数からの素朴な見積もりはずれやすい。
- 「窓が大きければ全部読んでくれる」わけではない。中央の情報は埋もれやすい。重要点は端に置く。
- 「入力が安いから貼り放題」ではない。入力トークンが膨らめば料金も遅延も増え、精度も落ちうる。
- 「キャッシュはどこでも 9 割引」ではない。割引率と方式は提供元ごとに異なる。公式で確認する。
- 「料金表は固定」ではない。単価・無料枠・割引は頻繁に変わる。試算は最新の公式価格で。
08まとめ
トークンは、LLM にとっての計算単位であり、課金単位であり、容量の単位です。この一つの単位が、料金（入力＋出力）と上限（コンテキスト窓）の両方を支配しています。実務で効く要点は次の 4 つに集約できます。
- 日本語は英語の約 2 倍のトークンを消費する前提で見積もる。
- 窓は「収まるか」だけでなく「ちゃんと読まれるか」で考える（重要点は端へ）。
- 渡すトークンを減らす（簡潔な指示・RAG で必要分のみ）と、料金・速度・精度がそろって改善する。
- キャッシュとモデル選択で、規模が大きいほど効くコスト最適化を仕込む。
料金体系・窓サイズ・キャッシュ条件はどれも更新が速い領域です。具体的な数字で意思決定するときは、必ず各社の公式ドキュメントで最新値を確認してください。
