トークンとコンテキストウィンドウ入門 — 長い会話で精度が落ちる理由と、コストを下げる5つの実践策

まずトークンから — LLMは文字ではなく「かたまり」で読む

LLM(大規模言語モデル)は、入力した文章を文字単位でそのまま読んでいるわけではありません。最初にトークナイザという仕組みが、文章をトークンと呼ばれる細かいかたまりに切り分けます。モデルが実際に処理しているのは、一つひとつのトークンに割り当てられた番号の列です。

英語であれば、頻出する単語はまるごと1トークン、珍しい単語は複数に割れる、というのがおおまかな挙動です。たとえば tokenization は token + ization のように分割されることがあります。空白・記号・改行も独立したトークンとして数えられます。

日本語は「かさばる」と知っておく

ここが実務で効いてきます。多くのトークナイザは英語テキストを中心に最適化されており、日本語は同じ内容でも英語よりトークン数が多くなりやすい傾向があります。ひらがなや漢字が1〜数文字ずつ細かく割れるためです。「日本語で書いたら思ったより高くついた」「長さ上限に早く引っかかった」という体感は、たいていこの性質が原因です。正確な数は各提供元のトークン計測ツールやAPIで確認できます。

コンテキストウィンドウはモデルの「作業机」の広さ

コンテキストウィンドウとは、モデルが1回の推論で同時に見られるトークンの上限です。机の広さに例えると分かりやすく、机に載らない資料はモデルの視界に入りません。

重要なのは、この机に載るのが「いま打った質問」だけではないという点です。

つまり上限は入力と出力の合計に対してかかります。上限ぎりぎりまで資料を詰め込むと、回答を書く余白が残らず、返答が途中で切れることになります。

上限に近づくと何が起きるか

1. 静かに切り落とされる、あるいはエラーになる

APIを直接呼ぶ場合、上限超過は明示的なエラーで返ることが多く、これはまだ気づけます。厄介なのはチャットアプリや自作エージェントで、多くは「古い履歴から自動的に捨てる」実装になっており、エラーは出ません。会話の序盤で伝えた前提条件をモデルが突然忘れたように見えるのは、たいていこれが起きています。

2. 中盤の見落とし(lost in the middle)

さらに厄介なのがこちらです。長い入力を与えたとき、モデルの参照精度は入力全体で均一ではなく、冒頭と末尾に置かれた情報は拾われやすく、中盤に埋もれた情報は見落とされやすいという傾向が複数の研究で報告されています。イメージとしては、机は広いのに、手前と奥の書類しかきちんと読んでいないような状態です。「長いPDFを丸ごと渡したのに、真ん中に書いてある肝心の条件を無視した回答が返ってきた」というのは典型的な症状です。

注意すべきは、コンテキストウィンドウが大きいモデルでもこの傾向は消えないことです。上限は「入る量」であって「確実に使いこなせる量」ではないと考えるのが安全です。

API料金がトークン単位で決まる仕組み

主要なLLM APIは、ほぼ共通して入力トークン数 × 入力単価 + 出力トークン数 × 出力単価という課金です。執筆時点では、多くの提供元で出力単価のほうが入力単価より高く設定されています。実際の単価はモデルごとに大きく異なり改定も頻繁なので、必ず公式の料金ページで最新の値を確認してください。

会話がじわじわ高くなる理由

ここは誤解されやすいポイントです。APIはステートレス、つまり前回のやり取りを覚えていません。会話を続けるには毎ターン、過去の全履歴を入力として送り直す必要があります。

1ターン目の入力: システム + 質問1
2ターン目の入力: システム + 質問1 + 回答1 + 質問2
3ターン目の入力: システム + 質問1 + 回答1 + 質問2 + 回答2 + 質問3

1ターンあたりの入力量が階段状に増えるため、会話全体の累積入力トークンはターン数に対しておおよそ二乗で効いてきます。20ターン続く相談は、単発の質問20回よりもずっと高くつきます。

コストと精度を同時に改善する5つの実践策

ここまでを踏まえると、渡すトークンを減らすことがコスト削減と精度向上の両方に効くと分かります。ノイズを捨てれば安くなり、同時に中盤の見落としも減るからです。

1. 要約を挟み込む(コンテキスト圧縮)

会話が一定の長さを超えたら、古い履歴をモデル自身に要約させ、原文と差し替えます。たとえば直近5ターンはそのまま残し、それ以前は「決定事項・前提条件・未解決の課題」の3項目にまとめた1メッセージに置き換える、という運用です。要約を頼むときは 以降の作業に必要な事実だけを箇条書きで残し、雑談や言い換えは捨てる のように、残すべき情報を明示するのがコツです。

2. 不要な履歴・データを最初から入れない

• 雑談や、失敗して捨てた試行錯誤のターンは履歴から削除する
• ログやCSVは全文ではなく、該当箇所を grep などで絞ってから貼る
• 大きな文書は検索(RAG)で関連する数段落だけを取り出して渡す
• そのタスクで使わないツール定義は外す

「とりあえず全部渡してモデルに探させる」は、高くつくうえに中盤の見落としを誘発する、二重に損な選択です。

3. プロンプトキャッシュを活用する

同じ長いプレフィックス(システムプロンプト、社内マニュアル、コードベースなど)を繰り返し送るなら、プロンプトキャッシュが効きます。執筆時点で主要な提供元が対応しており、一度処理した先頭部分の計算結果を再利用することで、2回目以降の入力コストと応答待ち時間を下げられます。

効かせるための鉄則は「変わらないものを前に、変わるものを後ろに」です。キャッシュは先頭からの一致で判定されるため、冒頭に日付やユーザー名を差し込むと、それ以降すべてがキャッシュミスになります。

×  [今日は2026-09-02] + [長いマニュアル] + [質問]
○  [長いマニュアル] + [今日は2026-09-02] + [質問]

キャッシュの有効期間、対象となる最小トークン数、書き込み時に追加料金がかかるかどうかは提供元ごとに異なります。採用前に公式ドキュメントで条件を確認してください。

4. 重要な指示は末尾に置く

中盤の見落とし対策として、長い資料を渡すときは 資料 → 指示 の順にし、「何をしてほしいか」を末尾に置きます。絶対に外せない制約は、冒頭と末尾の両方に書いて挟み込むのも有効です。

5. 出力の長さを制御する

出力単価のほうが高いのが一般的なので、ここは素直に効きます。「箇条書きで5点以内」「前置きと結論の繰り返しは不要」のように長さを指示する、max_tokens 相当のパラメータで上限を設ける、JSONなどの構造化出力を使って冗長な説明文を省く、といった方法があります。

まとめ

• モデルは文字ではなくトークン単位で読む。日本語は英語よりトークン数が増えやすい。
• コンテキストウィンドウは入力と出力の合計にかかる上限で、システムプロンプトやツール定義も消費する。
• 上限が大きくても中盤の情報は見落とされやすい。入る量と使える量は別物。
• APIは毎ターン全履歴を再送するため、長い会話のコストはターン数の二乗で効いてくる。
• 要約の挟み込み、履歴の刈り込み、プロンプトキャッシュ、指示の配置、出力長の制御。この5つはコストと精度に同時に効く。

モデル名・価格・コンテキスト長は陳腐化が非常に速い分野です。本記事の考え方は当面変わりませんが、具体的な数値は必ず各提供元の公式ドキュメントで最新版を確認してください。