# LLMのContextとは — Token・履歴・外部データを分けて考える

> LLMが推論時に参照するContextの定義、Context Window・Prompt・Memory・RAGとの違いと、Web実装で管理する情報の範囲を整理します。

Canonical URL: https://labs.eastbraver.com/guides/context
Published: 2026-07-01
Updated: 2026-07-24
Category: field-guide
Tags: llm-inference, software-engineering, ai-agent

[LLM](/guides/llm)のContextは、モデルが一回の推論で参照できるTokenの集合です。

画面に会話履歴が残っていても、その履歴を次のRequestへ渡していなければ、モデルは参照できません。

System Instruction、利用者の入力、会話履歴、具体例、検索結果、Tool定義、Tool結果、生成途中の情報が同じContext Windowへ入ります。

モデルが学習済みの知識や、アプリケーションのDatabase全体を指す言葉ではありません。**その推論で実際にモデルへ渡したもの**がContextです。

## Context Windowは作業領域の上限

Context Windowは、一回の推論で入力と出力に使えるToken量の上限です。上限の数え方や、入力・出力の配分はModel APIによって異なります。

### LLM推論へ渡るContext

System Instruction、履歴、取得データ、Tool情報、例示はすべて有限のContext Windowへ集約されます。LLMはその時点で渡されたContextだけを使って推論し、Output tokensを生成します。

- System Instruction、Message history、Retrieved data、Tool情報、Examplesを選びます。
- 選んだ情報をContext Windowへ収めます。
- LLMがContextを使って推論し、Output tokensを返します。

*複数の入力をContext Windowへ集約して出力する流れ*

[Claude Messages API](https://platform.claude.com/docs/en/api/messages/create)のように、会話履歴をRequestごとに明示して送るStateless APIがあります。UIに会話が残っていても、必要な履歴をRequestへ含めなければモデルは参照できません。

逆に、アプリケーションが保持しているデータをすべて渡す必要もありません。Contextへ入れた情報だけがモデルの作業領域に載り、Token、費用、レイテンシ、注意配分を使います。

## Prompt、Context、Memory、RAGは同じではない

| 用語 | 主な役割 |
| --- | --- |
| Prompt | モデルへ渡す入力を指す広い呼び方 |
| Instruction | モデルに求める行動や条件 |
| Context | 一回の推論でモデルが参照するToken全体 |
| Context Window | Contextとして扱えるToken量の上限 |
| [Memory](/guides/memory) | セッションや実行をまたいで保持する外部状態 |
| [RAG](/guides/rag) | 外部情報を検索し、必要な部分をContextへ加える構成 |

Memoryへ保存しただけでは、モデルは使えません。次の推論で必要な情報を選び、Contextへ戻す処理が必要です。

RAGも検索結果を渡せば完了ではありません。検索した文書の関連性、鮮度、権限、長さを確認し、どの部分をContextへ入れるか決めます。

## 入る量と使える量は別

[Lost in the Middle](https://arxiv.org/abs/2307.03172)は、長い入力の中で重要情報の位置により性能が変わり、中央付近の情報を使いにくくなる傾向を報告しました。モデルやタスクによって結果は異なりますが、上限内に収まることだけを成功条件にはできません。

[AnthropicのContext Engineering解説](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)も、Contextを有限の資源として扱い、望む結果に必要な高SignalのTokenを選ぶ考え方を示しています。

古い履歴、重複したTool結果、関係のない文書、巨大なSchemaを入れると、費用だけでなく、モデルがどの情報を優先するかにも影響します。

## WebシステムではContextの出所を追う

Contextへ入る情報は、同じ信頼度ではありません。

- 開発者が管理するInstruction
- 認証済み利用者の入力
- 権限を確認して取得した社内データ
- 外部Webから取得した未信頼の文書
- Tool実行結果
- 過去のモデル出力

外部文書や過去のモデル出力に命令が含まれていても、System Instructionへ昇格させません。出所、取得時刻、対象利用者、参照権限を追えるようにします。

個人情報や秘密情報は、Contextへ入れた時点でModel APIへ送信される可能性があります。保存期間、利用規約、Data residency、ログへの記録範囲も確認します。

## 長い処理ではContextを更新する

[Context Engineering](/guides/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へ入るから全部入れる**、は避けたい構成です。必要な情報を必要な時点で取り出せる方が、費用・調査・安全性の面で扱いやすくなります。

## 関連記事

- [AI Agent 時代に、エンジニアは何を設計する人になるのか](/blog/ai-development-20260706)
- [エージェント基盤は非同期運用へ](/digest/ai-digest-20260708)
- [GPT-5.6とAI実行基盤の境界](/digest/ai-digest-20260710)

## 検証範囲

- 一次情報: 公式ドキュメント / 研究論文 / 設計面からの分析
- ローカル検証: 概念を整理するGuideなので、コードは動かしていません
- 実運用: 本番運用の実績については、このGuideでは触れていません

## 変更履歴

- 2026-07-24: Mermaid図にテキスト等価物を追加
- 2026-07-15: 検証範囲と根拠区分を明示
- 2026-07-01: 初版公開