コンテキストウィンドウの説明：AIが忘れる理由（と対処法）

LLMは長期記憶を持たず、最近のトークンのスライディングウィンドウのみを「見て」おり、このウィンドウの外のすべてが忘れられるか圧縮されます。 この記事は、それがプロンプトにとって何を意味するのか、そしてこれらの制限の内側（および外側）でどのように機能するかを説明しています。

コンテキストウィンドウは、LLMが次の出力を生成するときに考慮に入れることができるテキストの最大量（トークンで測定）です。

これをモデルの「見えるテキスト」をいつでも思い描いてください。GPT-4oに128kトークンのコンテキストウィンドウがある場合、モデルは会話の最後の128,000トークン（約96,000語）を「見る」ことができます。それより前のすべてはモデルに見えず、応答に影響しません。

トークンと単語：トークンは単語ではありません。平均して、1トークン≈4文字または約0.75単語です。4,000トークンのコンテキストウィンドウ≈プレーンな英語テキスト3,000語です。密なコードまたは日本語などの言語の場合、比率は異なります。日本語テキストは文字エンコーディングのため、単語あたり約2トークンを必要とします。

**コンテキストウィンドウのサイズはモデル間で大きく異なります：

すべてのモデルで原則は同じです。ウィンドウの外のすべては見えません。

会話内のトークンの合計数（システムプロンプト+チャット履歴+ユーザー入力+ツール+予想出力）がコンテキストウィンドウを超える場合、古い部分は切り詰められ、要約されるか、完全に削除されます。

これは人間の忘却のような記憶喪失ではありません。モデルは「考えてから忘れる」わけではありません。文字通り切り詰められたテキストを見ません。モデルの入力空間に存在しなくなります。

**コンテキスト限界に達した場合の一般的な症状：

ほとんどのチャットインターフェースは次のいずれかの戦略を使用します:

これらすべては「要点」を保持しますが、具体的な詳細は失われます。モデルが元の指示を見なくなったとき、それに従うことはできません。

コンテキスト過負荷はハルシネーションを増加させます。元の情報が見えなくなったとき、モデルはもっともらしい推測でギャップを埋めるためです。

パターンは次のようになります。50メッセージ前に言及した何かをAIに参照するよう求めます。しかしそのメッセージはコンテキストウィンドウから回転しました。モデルは実際の事実にアクセスできないため、現在のコンテキストから推測することに基づいて、もっともらしく聞こえる答えを生成します。結果：捏造。

これが高コンテキストの長いチャットが、集中した短い交換よりも多くのハルシネーションを生成する理由です。モデルは推論能力を失っていません。不完全な情報で機能しています。

相互作用は直接的です： コンテキストが少ない → グラウンディングが不足している → ハルシネーションリスクが増加します。

この効果は、すでに確率性を高める高い温度とtop-pの設定で強化されます。Temperature and Top-P: Control AI Creativityを参照してください。パラメータチューニングがハルシネーションとどのように相互作用するかを理解するために。

プロンプトを戦略的に構造化することにより、固定コンテキスト予算内でより多くを達成できます。

重要な指示を前に配置します。 最も重要な制約、ルール、定義をシステムプロンプトまたはすべての最初のユーザーメッセージに配置します。これらは、20ターン後に埋め込まれた指示よりもコンテキストから削除される可能性が低いです。

繰り返しを避ける。 何かを一度説明したら、もう一度貼り付けないでください。代わりに、それを参照してください。「上記のサマリーで説明したように…」これはトークンを節約します。

明確に要約してください。 モデルに、これまでの主要な決定、制約、または事実を要約するように求めます。その後、分散された以前のコンテキストに依存するのではなく、その要約から次の応答を構築します。

ターンに焦点を当てておきます。 単一の複数トピックのモノローグはコンテキストを効率的に使用しません。分離された、狭いスコープの交換に分割します。

本全体または数百ページのPDFを単一のコンテキストウィンドウに貼り付けることは、Gemini 3.1 Proの2Mトークンウィンドウでも、モデルは複数の異なるセクションに効果的に焦点を当てることができないため、非効率です。

1,000ページの本≈250,000トークン。Gemini 3.1 Proの2Mトークンウィンドウでは技術的に収容できます。実際には、モデルの推論は、大きく異なるセクション全体で質問に答えるよう求められたときに低下します。まるで人が一度に本全体を読んでから、50ページ、200ページ、400ページから特定の詳細を思い出すよう求められるようなものです。想起はかすかになります。

**長いドキュメントの方が良い方法：

コンテキスト制限の近くで作業することは難しいです。各モデルには異なる制限、切り詰め動作、価格設定、および（ローカルLLMの場合）VRAMの要件があります。PromptQuorumはこれらの制限を透明にします：送信前に各モデルのコンテキスト消費量と溢れリスクを確認できます。

LM StudioまたはOllamaでモデルを実行すると、コンテキストウィンドウサイズを構成できます。デフォルトでは、ツールはそれをモデルの最大値に設定することが多い（たとえば、7Bモデルの場合は32k）。しかし、それはあなたが必要とするものはめったにありません。

PromptQuorumはLM Studioと統合されており、タスクごとにコンテキストウィンドウを調整できます。軽くて高速なQ&Aの場合は4kを選択します。深いドキュメント分析の場合は32kを選択します。長い会話の場合は64kを選択します。これにより、トレードオフが構成ファイルに隠されるのではなく、明示的になります。

PromptQuorumは*を送信する前に確認します：システムプロンプト+現在の会話履歴+新しい入力+予想される出力の長さが与えられている場合、それは各モデルに設定されたコンテキストウィンドウに適合しますか？

オーバーフロー可能性がある場合、PromptQuorumはあなたを警告するか、送信する前に会話をトリム/要約するよう求めます。サプライズの切り詰めはもうありません。AIが「忘れた」理由について推測していません。

ローカルモデルでは、コンテキストウィンドウが大きくなるとVRAM消費も増加します。7B (Q4_K_M) モデルは4kコンテキストで~5 GB、32kコンテキストで~8–10 GB、128kコンテキストで~12–14 GB VRAMが必要です。VRAMが不足するとGPUはクラッシュするか、CPU推論に切り替わります（10–100倍遅い）。

PromptQuorumはこの関係を表示します：「このコンテキストウィンドウサイズはハードウェア上で約12–14 GB VRAMを使用します。利用可能な8 GBがあります。」タスクとハードウェアに合わせてコンテキストウィンドウを適切に調整できます。

ローカルデプロイメントで利用可能な最大コンテキストウィンドウを持つモデル（ハードウェア要件含む）については、ロングコンテキストローカルLLMをご覧ください。

GPT-4o（128kウィンドウ）、Claude（200kウィンドウ）、ローカル7Bモデル（選択した32kウィンドウ）にプロンプトをディスパッチすると、PromptQuorumは自動的にプロンプトを3つの境界内に保ちます。1つのプロンプト、複数のモデル、手動の書き換えなし。

レシピ1：1つのプロジェクトについての長いチャット — 以前の決定を失わずに、単一のプロジェクトに関するマルチターン会話を維持します。

レシピ2：長いレポートの分析 — 50～100ページのドキュメントから洞察を抽出します。

レシピ3：コンテキストウィンドウの端でのプロンプト作成 — ほぼ完全なコンテキストウィンドウをオーバーフローなしで使用します。

レシピ4：VRAMが限られたローカルLLM — クラッシュなしでローカルモデルを効果的に実行します。