LLMのコンテキストとは？仕組みや重要性、限界を突破するアプローチ2選

社内文書をLLMに読み込ませても、回答が不完全だったり、もっともらしい誤った情報（＝ハルシネーション）が混じったりすることはないでしょうか。

その大きな要因は「LLMコンテキスト（Context）」の制御にあります。コンテキストとは、モデルが一度に処理できる情報の枠のことを指します。LLMは入力されたテキストを「トークン」という最小単位の情報（単語や文字の断片）に分解して処理しますが、一度に扱える情報量(≒トークンの総量)には物理的な限界があります。

本記事では、この「枠」の仕組みを解き明かすとともに、トークン制限という情報量の限界をどう乗り越えるか、RAG（検索拡張生成）を用いた具体的な突破策を解説します。

LLMにおけるコンテキストの定義と仕組み
コンテキストはなぜ重要？LLMの性能を左右する3つの要因
注意点：LLMのコンテキストには限界がある
LLMのコンテキスト限界を突破する2つのアプローチ
1. 解決策1：RAG（検索拡張生成）
2. 解決策2：コンテキスト拡張技術
まとめ｜LLMにおけるコンテキストの重要性を理解し、必要に応じたアプローチを取り入れよう

LLMにおけるコンテキストの定義と仕組み

情報の枠であるコンテキストの中身の質は入力する情報の内容、トークン量、構造によって決まります。

入力する情報のボリュームを誤ると、必要なデータが足りずに根拠不足に陥ったり、逆に不要な情報まで詰め込みすぎてコストが跳ね上がったりします。まずは、コンテキストの定義と、その内部でデータが処理される仕組みを整理しましょう。

コンテキストとは、LLMが作業の実行時に参照する情報のこと

コンテキストは「作業メモ帳」に近い概念です。
質問、指示、履歴、参考資料が1つの束になり、モデルの推論と生成の材料になります。

LLMのコンテキストはトークンという単位で計測され、その上限がコンテキストウィンドウ（一度に記憶できる文字量の上限）です。

コンテキストに含まれる情報は次の3種類です。

システムプロンプト（指示・成約）：役割や制約を固定する設定。これがブレると同じ入力でも出力が揺れる。（例「あなたは営業支援AI」「出力はJSON」）
ユーザー入力（プロンプト）：質問と追加条件を指し、idやvalueなどのパラメータ指定も含む。指示が曖昧だとモデルが学習データから補完するが、推測で補完する場合もあるため精度が不安定になりがち。
会話履歴/参考資料：過去のやり取りやRAG（検索拡張生成）で取得したナレッジ。文脈（コンテキスト）が共有されているほど、判断の精度と安定性が向上する。（例：社内Wikiや契約条項）

実務上の注意点：ウィンドウの「空き」が重要

「入力する全情報」と「モデルがこれから生成する回答」の合計が、ウィンドウという限られたメモリ枠を分け合います。

つまり、入力情報で枠を使い切ってしまうと、「AIが回答を書き込むためのスペース」がなくなります。その結果、回答が途中で途切れたり、古い指示を忘れて無視したりといった不具合が発生します。

そのため、大規模な文書を扱う実務ほど、「容量オーバーにならないよう、必要な箇所だけを抜き出して入れる」という設計が不可欠になります。

コンテキストはどのように処理されるのか？

LLMの内部処理は

入力
関連付け
出力

の流れで進みます。

まず、入力テキストはトークンに分割され、順序情報が付与されます。次にSelf-Attention（文章内の情報同士の関係を同時に計算し、情報を選択する仕組み）により、関連の強いトークンに重みが与えられます。この「重み」は、AIが文脈を理解するための「注目度」のような数値です。

最後に重み付けの表現を統合し、次のトークンを予測して文章を生成します。

この仕組みを中核に持つのが、現在のLLMで使われている基本構造であるTransformerです。文脈全体を俯瞰できる点が強みですが、トレードオフとして計算量が増えます。

Self-Attentionは、入力されるトークン数が増えるほど、内部で行う比較計算が急激に増加します。そのため、文書が長くなるほど遅延とコストが増え、コンテキストウィンドウの上限にも早く到達します。

コンテキストはなぜ重要？LLMの性能を左右する3つの要因

LLMのコンテキストは「根拠」と「状態」を保持する領域です。薄すぎると推測が増え、厚すぎると関連づけが分散します。

性能にどう影響するか、3つに分けて整理します。

要因1：応答品質の向上

回答精度は、必要な情報がコンテキストに含まれているかで決まります。不足するとモデルは学習データから補完し、誤情報の生成（ハルシネーション）が起きやすくなります。

例えば、製品仕様書を与えずに保証条件を聞くと、旧版や別製品の条件が混ざることがあるかもしれません。業務FAQや契約回答では、致命的な判断ミスにつながります。

このような誤りは、参照情報が不足している場合だけでなく、判断の仕方が不安定な場合にも起こります。その対策の1つが「Few-shot」です。

Few-shot（モデルにいくつかの実例を見せて振る舞いを調整する手法）は、タスク例をコンテキストに含めて出力形式をそろえ、分類や抽出の揺れを抑えます。これはICL（In-Context Learning：追加学習なしに振る舞いを寄せる方法）とも呼ばれます。

学習ではなく与える情報の設計で結果が変わるため、プロンプトは指示、コンテキストは根拠と考えると設計しやすいです。

要因2：複雑なタスクの実行

複雑なタスクは、「途中状態」を保持できるかが成否を左右します。コンテキストは短期メモリとして機能し、推論と実行を支える基盤です。

特にエージェント型の実装では、ツール呼び出しの結果を履歴に残し、次の判断に再利用します。例えば「顧客データ分析→課題抽出→施策提案」のタスクでは、分析結果を文脈として保持しないと提案が飛びます。

このような処理を安定させる考え方の一つがCoT（Chain-of-Thought：推論を段階的に分解して扱う手法）です。CoTでは、結論だけでなく途中の考えや判断結果を一つずつ整理して保持することで、推論の飛びや抜けを防ぎます。これらの中間結果は、外部に出さず内部で保持しても、段階的な分解が進みやすくなります。

さらにナレッジグラフ（Knowledge Graph：情報同士の関係をグラフ形式で表したもの）を統合すると、判断の根拠をより明確にできます。曖昧な自然文だけの指示を与えるより、項目と関係が定義された構造のほうが整合性を取りやすいです。