コンテキストウィンドウとは？生成AIにおける文脈の限界とMCP設計｜MCP入門 1.3

1.3 コンテキストウィンドウとその制約

AIに「記憶力」はあるのか？という問いをよく耳にします。 実際のところ、ChatGPTなどの大規模言語モデル（LLM）は、まるで記憶しているかのように会話を続けたり、数ページ前の情報を使って適切に応答したりします。 しかし、これには明確な限界があります。

その制約を決定づけているのが、コンテキストウィンドウ（context window）と呼ばれる技術的な境界です。 このセクションでは、コンテキストウィンドウとは何か、なぜ重要なのか、そしてそれをどう設計に活かすべきかを詳しく解説します。

コンテキストウィンドウとは何か？

コンテキストウィンドウとは、モデルが一度の入力処理で“認識可能な最大トークン数”を指します。 トークンとは、文章を分割して扱う最小単位で、英単語であれば単語単位、日本語では1〜3文字程度で1トークンになることが多いです。

例えば、以下のようなモデルごとのコンテキストウィンドウ制限があります：

• GPT-3.5（turbo）: 約4,096トークン
• GPT-4（standard）: 約8,192トークン
• GPT-4-turbo: 最大128,000トークン（約30万文字相当）
• Claude 2: 最大100,000トークン前後

つまり、1チャットにおいてモデルが保持・参照できるのは、上限トークン数までであり、 それを超えた情報はモデルの“視界”から外れてしまうのです。

なぜウィンドウ制限が重要なのか？

モデルが応答を生成するとき、「今までの履歴」や「渡されたデータ」を内部的に読みながら処理を行います。 しかし、そのすべてを丸ごと覚えているわけではありません。 コンテキストウィンドウの範囲内にある情報だけが、生成プロセスに影響を与えるのです。

もし前半で重要な情報を渡しても、それがウィンドウの外に押し出されてしまえば、モデルはそれを“忘れる”ことになります。 これは特に、長文の文書要約、複雑なチャットセッション、複数ドキュメントを扱うRAGシステムなどで顕著な課題となります。

ウィンドウを使い切ると何が起こるか

実際のシステムで、ウィンドウを超える情報を投入し続けると、以下のような現象が起こります：

• モデルが急に文脈を取り違える
• 「前にも言いましたが...」という指示が通らなくなる
• ユーザーの属性や話題が急にリセットされたような応答が出る
• 重要な制約条件（例：「5文字以内で答えて」）が無視される

これは、単に「モデルの調子が悪い」のではなく、文脈が物理的に失われていることが原因です。

MCP設計におけるコンテキスト制御のポイント

Model Context Protocol（MCP）では、この制約を前提とした設計が求められます。 具体的には、以下のような戦略が重要です：

• 情報の要約：履歴をそのまま詰め込まず、要点だけを抽出する
• 優先順位の明示：「何が重要で、何が補足か」をプロンプト設計で示す
• 外部メモリとの併用：RAG（検索補助）などを使って、必要なときだけ情報を呼び出す
• 情報の分割：1つのプロンプトに全部渡さず、段階的に渡す（チャンク処理）
• 会話履歴の圧縮：過去の応答を自動で要約し、少ないトークンで文脈を保つ

これらは、LLMアプリケーションの品質を安定させるための基本であり、 「ウィンドウ制限という現実」と向き合うことが、MCP設計の出発点でもあります。

トークン単位での設計視点を持つ

もう一歩踏み込んで、1プロンプト＝何トークンになるのかを把握して設計することも重要です。 たとえば、次のような構造を持つプロンプトを考えます：

「以下はユーザーからの問い合わせ内容です。要点を抽出し、簡潔な返信文を生成してください。」

（問い合わせ本文：約500トークン）

「返信文は、100文字以内で書いてください。」

このとき、プロンプトの指示が約80〜100トークン、本文が500トークンで合計600前後と試算されます。 もし他に履歴などがあると、ウィンドウ上限に近づき、応答が不安定になります。 したがって、MCPの運用では「1プロンプトあたり何トークンかかるか」を定量的に見積もり、 設計段階でトークン予算を決めることが推奨されます。

コンテキストウィンドウには限界がある。それでは、モデルに継続的な「記憶」は持たせられないのか？ 実は、多くの生成AIアプリが「記憶しているように見せる」ための様々な工夫を行っています。 次のセクションでは、モデルの「擬似的な記憶」設計と、MCPにおけるメモリ管理の基礎を探っていきましょう。 → 1.4 モデルにとっての「記憶」とは何か へ進む