LLMのContextは、モデルが一回の推論で参照できるTokenの集合です。
画面に会話履歴が残っていても、その履歴を次のRequestへ渡していなければ、モデルは参照できません。
System Instruction、利用者の入力、会話履歴、具体例、検索結果、Tool定義、Tool結果、生成途中の情報が同じContext Windowへ入ります。
モデルが学習済みの知識や、アプリケーションのDatabase全体を指す言葉ではありません。その推論で実際にモデルへ渡したものがContextです。
Context Windowは作業領域の上限
Context Windowは、一回の推論で入力と出力に使えるToken量の上限です。上限の数え方や、入力・出力の配分はModel APIによって異なります。
System Instruction、履歴、取得データ、Tool情報、例示はすべて有限のContext Windowへ集約されます。LLMはその時点で渡されたContextだけを使って推論し、Output tokensを生成します。
- System Instruction、Message history、Retrieved data、Tool情報、Examplesを選びます。
- 選んだ情報をContext Windowへ収めます。
- LLMがContextを使って推論し、Output tokensを返します。
Claude Messages APIのように、会話履歴をRequestごとに明示して送るStateless APIがあります。UIに会話が残っていても、必要な履歴をRequestへ含めなければモデルは参照できません。
逆に、アプリケーションが保持しているデータをすべて渡す必要もありません。Contextへ入れた情報だけがモデルの作業領域に載り、Token、費用、レイテンシ、注意配分を使います。
Prompt、Context、Memory、RAGは同じではない
| 用語 | 主な役割 |
|---|---|
| Prompt | モデルへ渡す入力を指す広い呼び方 |
| Instruction | モデルに求める行動や条件 |
| Context | 一回の推論でモデルが参照するToken全体 |
| Context Window | Contextとして扱えるToken量の上限 |
| Memory | セッションや実行をまたいで保持する外部状態 |
| RAG | 外部情報を検索し、必要な部分をContextへ加える構成 |
Memoryへ保存しただけでは、モデルは使えません。次の推論で必要な情報を選び、Contextへ戻す処理が必要です。
RAGも検索結果を渡せば完了ではありません。検索した文書の関連性、鮮度、権限、長さを確認し、どの部分をContextへ入れるか決めます。
入る量と使える量は別
Lost in the Middleは、長い入力の中で重要情報の位置により性能が変わり、中央付近の情報を使いにくくなる傾向を報告しました。モデルやタスクによって結果は異なりますが、上限内に収まることだけを成功条件にはできません。
AnthropicのContext Engineering解説も、Contextを有限の資源として扱い、望む結果に必要な高SignalのTokenを選ぶ考え方を示しています。
古い履歴、重複したTool結果、関係のない文書、巨大なSchemaを入れると、費用だけでなく、モデルがどの情報を優先するかにも影響します。
WebシステムではContextの出所を追う
Contextへ入る情報は、同じ信頼度ではありません。
- 開発者が管理するInstruction
- 認証済み利用者の入力
- 権限を確認して取得した社内データ
- 外部Webから取得した未信頼の文書
- Tool実行結果
- 過去のモデル出力
外部文書や過去のモデル出力に命令が含まれていても、System Instructionへ昇格させません。出所、取得時刻、対象利用者、参照権限を追えるようにします。
個人情報や秘密情報は、Contextへ入れた時点でModel APIへ送信される可能性があります。保存期間、利用規約、Data residency、ログへの記録範囲も確認します。
長い処理ではContextを更新する
Context Engineeringでは、処理の進行に合わせてContextを選び直します。
- 不要になったTool結果を外す
- 長い履歴を要約・圧縮する
- 決定事項を構造化した外部状態へ保存する
- File pathやIDだけを保持し、必要時にToolで取得する
- 新しいAgentへ引き継ぐ情報を明示する
要約すると情報が失われる可能性があります。元の参照先を残し、重要な制約や未解決事項が落ちていないか評価します。
よくある誤解
Context Windowが大きいほど常に性能が上がる
大きなWindowは選択肢を増やしますが、無関係な情報を増やしてよい理由にはなりません。必要な情報を取り出せるかは別に評価します。
会話履歴はモデルが自動的に覚えている
Stateless APIでは、アプリケーションが履歴を保持し、次のRequestへ含めます。製品側にMemory機能がある場合も、保持範囲と削除条件を確認します。
RAGで取得した文書は信頼できる
検索結果には古い情報、権限外データ、攻撃的な命令が含まれる可能性があります。取得元と権限を検証し、データとして扱います。
Contextを圧縮しても意味は変わらない
要約は情報を選別する処理です。細かな条件、例外、数値が落ちる可能性を前提に、元データへ戻れるようにします。
EastBraver Labsの判断基準
EastBraver Labsでは、Contextを大きくする前に、各情報が次の判断へ必要かを確認します。
固定Instruction、動的な業務データ、未信頼の外部文書、過去のモデル出力を分け、出所と権限を記録します。
長時間処理では、会話全文を唯一の状態管理にしません。
Contextへ入るから全部入れる、は避けたい構成です。必要な情報を必要な時点で取り出せる方が、費用・調査・安全性の面で扱いやすくなります。