Skip to Content
Docs10. LLM 基礎注意機構とコンテキストウィンドウの仕組み
中級llm-foundationscontext-engineeringprompt-caching更新: 2026-09-10この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

注意機構とコンテキストウィンドウの仕組み

この記事の目的

「なぜ長いコンテキストは遅く・高く・品質が落ちるのか」「なぜプロンプトキャッシュプロンプトの固定部分(前方一致)の処理結果を再利用し、入力コストと応答開始までの時間を削減する仕組み。固定部分を先頭に置くプロンプト構造が前提。は前方一致なのか」を、注意機構(attention)と KV キャッシュ(KV cache)の仕組みから説明できるようになります。コンテキストエンジニアリングが示す実務原則(厳選する・固定部分を先頭に置く)の「なぜ」を埋める記事です。

対象読者

  • コンテキスト設計・プロンプトキャッシュ・レイテンシ最適化を、根拠を持って行いたいエンジニア
  • 「コンテキストに入れれば読んでくれる」という直感が実際と合わない理由を知りたい人

前提知識

本文

概要: 「全部が全部を見る」仕組みとその請求書

本記事は、自己回帰 Transformer の**密な因果的注意(causal attention)**を基本例にします。各トークンは自分以前の参照可能なトークンとの関連度を計算し、情報を重み付けして表現を作ります。未来のトークンは参照しません。文脈が長いほど参照対象と計算・メモリAgent が「覚えている」ように見えるデータの総称。短期記憶(コンテキスト)・作業状態・長期記憶(外部ストレージ)の 3 層に分けて設計する。の負担は増えますが、入力上限・料金・品質は、学習や提供側の実装にも依存します。局所注意など参照を限定する構成は 注意機構の変種 で扱います。

注意機構の直感

文中の「それ」が何を指すかを理解するには、離れた位置の名詞を参照する必要があります。注意機構は、参照可能な位置との関連を重み付けし、その重みに応じて情報を混ぜ合わせます。層を重ねることで文脈に応じた表現を更新します。各層が必ず語・句・文という固定の順序に対応するわけではありません。

実務者が持ち帰るべき直感は 2 つです。

  1. 参照は「機会」であって「保証」ではない: すべてのトークンを見られることと、その情報を正しく使うことは別です。重み付けは学習された傾向であり、長い文脈では重要な情報への重みが薄まりえます
  2. 密な注意の計算量は文脈長に対して急速に増える: 入力を一括処理する注意演算では、素朴にはトークン数の 2 乗に比例するペア計算が発生します。これはモデル全体の実測時間が必ず 2 乗になるという意味ではなく、キャッシュを使う 1 トークンずつの生成とも区別します

コンテキスト長のコスト構造

自己回帰生成(LLM はどうやってテキストを生成するか)と組み合わせると、レイテンシの構造が見えてきます。

段階何が起きるか効く指標
プリフィルアシスタント応答の書き出しを開発者側で与えてから続きを生成させる技法。生成が与えた書き出しの続きとして条件付けられるため、前置きの除去や形式の強制に指示より強く効く(対応可否はモデルによる)。(prefill)入力全体を一括処理し、各トークンの中間表現を計算する最初のトークンが出るまでの時間(TTFT最初のトークンが出るまでの時間。ストリーミング表示の体感と全体レイテンシを左右する主要指標の一つ。)。入力長に依存
デコード(decode)1 トークンずつ生成する。各ステップで過去全トークンの中間表現を参照トークン毎秒。文脈が長いほど 1 トークンが重い

「入力を短くすると応答開始が速くなる」「長い会話ほど生成がもたつく」という体感は、この 2 段階の構造そのものです(レイテンシ最適化)。また、長コンテキストは計算だけでなくメモリ(後述の KV キャッシュ)も比例して消費するため、プロバイダーが長文入力に割増価格を設定する背景にもなっています。

KV キャッシュとプロンプトキャッシュ

デコードの各ステップで過去トークンの中間表現を毎回計算し直す処理を減らすため、一度計算した Key と Value を保存して再利用します。これが KV キャッシュです。リクエスト間で共通の接頭辞を再利用するプロンプトキャッシュにも使われます。保存期間・一致条件・料金上の扱いは提供サービスの仕様です。

長文での品質劣化

コンテキストに「入る」ことと「使われる」ことは別です。以下は評価すべき失敗の観点です。Lost in the Middle  は、対象モデルと質問応答・検索タスクで位置による性能差を報告しています。すべてのモデルで同じ程度の劣化が起こるという保証ではありません。

  • 位置による想起の偏り: 文脈の先頭と末尾に比べ、中間に置かれた情報の想起が弱くなる傾向(いわゆる lost in the middle)が知られています。重要な指示・情報を大量の資料の真ん中に埋めない、という配置原則の根拠です
  • 無関係な情報や類似情報の影響: 必要な文書だけの場合と、妨害文書を加えた場合を比較します。品質差を注意の重みの希釈だけで説明せず、採用モデルの実際の回答で確かめます
  • 「入る」と「解ける」のギャップ: 一節を探す評価と、複数箇所を統合する評価を分けます。単純な検索の好成績だけでは、統合推論にも対応できるとは判断できません

これらが、コンテキストエンジニアリングの中心原則 — 入れられるだけ入れるのではなく、必要な情報を選んで渡す — の理論的な裏付けです。長期記憶を「全部コンテキストに置く」のではなく「検索して都度取り出す」設計(長期記憶の実装)も同じ根拠に立っています。

この理解が効く場面

  • コンテキスト予算の判断: 「この資料を丸ごと入れるか、要約・検索に変えるか」を、コスト(プリフィル・キャッシュ)と品質(希釈・中間の弱さ)の両面から判断できます
  • キャッシュ設計: プロンプト構造を前方一致最大化の観点でレビューできます(固定部を先頭に・可変要素を混ぜない)
  • レイテンシの切り分け: 「応答開始が遅い(プリフィル・入力側)」と「生成が遅い(デコード・出力側)」を区別して対策できます(レイテンシ最適化)

実務での注意点

アンチパターン

  • 「コンテキストに入れたのだから読んでいるはず」と考える → 中間位置の希釈・干渉で重要情報が使われないことがある → 重要情報は先頭か末尾に置き、量を厳選する
  • タイムスタンプ・セッション ID などの可変値をプロンプト先頭部に埋め込む → 前方一致が毎回壊れ、キャッシュが一切効かなくなる → 可変値は可変部分(後方)へ移す
  • 長文ベンチマークの好成績を「長文処理は解決済み」と読む → 単純検索と統合推論では劣化の仕方が違う → 自社タスクの長さ・構造で実測する
  • レイテンシ対策を出力側だけで行う → 応答開始の遅さは入力長(プリフィル)由来のことが多い → TTFT と生成速度を分けて計測・対策する

チェックリスト

  • プロンプトが「固定部分が先頭・可変部分が後方」の構造になっている
  • キャッシュの効き(ヒット率・課金上の割引)を計測している
  • 重要な指示・情報を長い資料の中間に埋めていない
  • コンテキストに入れる情報の取捨選択基準がある(「全部入れる」をやめた)
  • TTFT(入力側)とトークン毎秒(出力側)を分けて監視している

関連トピック

参考資料

TODO・未確認事項

なし

トークナイザとトークン経済LLM の学習パイプライン(事前学習から選好調整まで)