# Context Engineeringとは — Agentへ渡す情報を選び続ける設計

> Context Engineeringを、System Prompt・Tool・履歴・外部データ・Memoryを限られたContext Windowへ選択し続ける工程として整理します。

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

Context Engineeringは、[LLM](/guides/llm)が推論するたびに、限られた[Context](/guides/context)へ何を入れ、何を外し、何を外部状態へ残すかを設計する工程です。

Agentを長く動かすと、会話履歴とTool結果は増え続けます。全部を次の推論へ渡していると、Goalより過去の試行の方が大きくなります。

[Prompt Engineering](/guides/prompt-engineering)がInstructionや例の改善を中心にするのに対し、Context Engineeringは会話履歴、Tool定義、Tool結果、取得文書、Memory、進捗状態まで扱います。

## Contextは一度作って終わりではない

[AnthropicのContext Engineering解説](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)は、Context Engineeringを、推論時に利用できるTokenを選び、維持するStrategyとして説明しています。

[AI Agent](/guides/ai-agent)は、実行するたびに新しい情報を生みます。

1. 利用者の依頼を受け取る
2. ModelがToolを選ぶ
3. Tool結果が返る
4. Modelが次の判断を行う
5. 途中結果とErrorが増える

すべてを履歴へ足し続けると、古い情報、重複、失敗した試行がContextを占有します。各Stepで次の判断に必要な情報を選び直します。

## Contextを構成する層を分ける

| 層 | 例 | 管理方法 |
| --- | --- | --- |
| Stable instruction | 目的、Policy、出力契約 | Version管理 |
| Task state | 現在のGoal、完了条件、未解決事項 | 構造化状態 |
| Working context | 直近のMessage、Tool結果 | Window内で更新 |
| Retrieved context | 文書、DB、Web検索 | 必要時に取得 |
| [Long-term memory](/guides/memory) | Preference、過去の決定 | 外部Storageと取得Policy |
| Artifact | File、Plan、Patch、Report | URIやPathで参照 |

固定Instructionと動的状態を一つの長文へ混ぜると、更新箇所と信頼境界が分かりにくくなります。

## PreloadとJust-in-time Retrievalを使い分ける

すべての情報を最初に渡すPreloadは、単純でRequest回数も少なくできます。ただし、不要な情報までContextを使います。

File path、Resource ID、検索Toolだけを先に渡し、必要になった時点で取得するJust-in-time Retrievalは、Contextを絞れます。一方で、Agentが適切な情報を見つけられるToolと説明が必要です。

### 必要なContextだけを取得するAgent loop

AgentはGoalとStable instructionを起点に、追加Contextが必要かを都度判断します。必要な場合だけSearchまたはResource Toolから情報を選び直し、不要ならそのままActionまたはAnswerへ進みます。

- GoalとStable instructionをAgentへ渡します。
- Agentが追加Contextの必要性を判定します。
- 必要ならToolで検索してSelected contextをAgentへ戻します。
- Contextが十分ならActionまたはAnswerへ進みます。

*Context不足の判定と選択的な追加取得を組み込んだloop*

業務ルールや必須の安全条件は先に渡し、大きな文書や詳細データは必要時に取得するHybrid構成が現実的です。

## Compaction、Memory、Artifactを分ける

長時間処理では、一つのContext Windowに収まり続けません。

### Compaction

会話や実行履歴を要約し、重要な決定、未解決事項、次のStepを残します。情報を失う処理なので、元のTraceやArtifactへ戻れるようにします。

### Structured Memory

利用者設定、確定した事実、過去の決定をFieldへ分けて保存します。モデルが生成した推測を、確認済み事実と同じ場所へ保存しません。

### Artifact

Code、文書、Plan、Test結果をFileやObjectとして外部へ置き、ContextにはPath、要約、必要な抜粋だけを載せます。

[Anthropicの長時間Agent向けHarness](https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents)は、複数Sessionにまたがる作業で、進捗FileやCommitなどのArtifactを引き継ぐ方法を示しています。

## Context品質を評価する

Context Engineeringの失敗は、単にToken上限を超えることだけではありません。

- 必要な情報が入っていない
- 古い情報が残っている
- 相反するInstructionがある
- 未信頼データをInstructionとして扱った
- 要約で例外条件が消えた
- Tool結果が大きすぎてGoalが埋もれた
- 同じ資料を繰り返し取得している

Traceから、各StepでどのContextを渡し、その情報が次の判断に使われたかを確認します。Token削減だけでなく、Task成功率と誤操作を一緒に見ます。

## よくある誤解

### Context Engineeringは長いSystem Promptを書くこと

System Promptは一部です。履歴、Tool、検索結果、Memory、Artifactを含む推論時の情報全体を扱います。

### Context Windowが広がれば不要になる

上限が広がっても、情報の鮮度、信頼度、矛盾、取得費用は残ります。[Lost in the Middle](https://arxiv.org/abs/2307.03172)が示すように、長い入力内の情報利用も別に評価が必要です。

### Compactionすれば情報を失わない

要約は選別です。数値、条件、例外、未解決事項が落ちる可能性をTestします。

### Agentに検索Toolを渡せば必要情報を必ず見つける

Toolの説明、検索範囲、Index、権限、停止条件が不十分なら、見落としや無駄な探索が起きます。

## EastBraver Labsの判断基準

EastBraver Labsでは、Contextを会話全文ではなく、**目的に必要な作業状態**として扱います。

確定事実、モデルの推測、利用者入力、外部文書を分け、出所を追える状態にします。長時間処理では、進捗と完了条件を構造化Artifactへ残します。

一番大きなContextを使うのではなく、次の判断に必要な情報を戻せる構成を選びます。

情報を減らすこと自体が目的ではありません。Agentが迷わず検証できる状態を作るためです。

## 関連記事

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

## 検証範囲

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

## 変更履歴

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