エージェントのためのコンテキストエンジニアリング¶
チェック¶
- [ ] 本文を確認した
- [ ] 概要を確認した
- [ ] タグを確認した
- [ ]
inbox/直下へ移行した
概要¶
LangChain の記事は、LLM エージェントにおけるコンテキスト管理を「write」「select」「compress」「isolate」の 4 パターンで整理している。 長時間動くエージェントでは、ツール結果、記憶、指示、検索結果が増え続け、コスト・遅延・精度低下につながる。 そのため、何を保存し、何を取り出し、何を圧縮し、何を分離するかを明示的に設計する必要がある。 LangGraph は状態、メモリ、ノード構成、サブエージェント、サンドボックスを使ってこれらを実装しやすくする、という主張。
解説¶
この記事の中心は、プロンプトをうまく書く話ではなく、エージェント実行中に「モデルへ渡す作業記憶」をどう設計するかにある。 コードエージェントやリサーチエージェントのように、ツール呼び出しを何十回も重ねるワークロードでは、全履歴をコンテキストに入れ続ける設計はすぐに破綻する。
実務では、まずトレースを見て「どの情報が増えすぎているか」「どの情報が意思決定に効いているか」を測る。 そのうえで、会話履歴、ツール結果、ファイル、検索結果、長期記憶を同じものとして扱わず、それぞれ保存先と再投入条件を分けるのが現実的。
特に重要なのは、長期記憶の retrieval は便利だが危険でもある点。 関係の薄いユーザー情報や古い事実が勝手に混ざると、ユーザーが意図しない出力になる。 メモリは「入れる」よりも「いつ出さないか」の設計が難しい。
本文¶
本文は取得できた記事内容をもとに、日本語で再構成したもの。 原文の長い逐語転載ではなく、あとで参照しやすいように論点を整理している。
背景¶
LLM のコンテキストウィンドウは、OS における RAM のような作業領域として説明されている。 エージェントは LLM 呼び出しとツール呼び出しを交互に行い、ツールのフィードバックを使って次の行動を決める。 この過程で、指示、知識、ツール結果、過去の会話、メモリ、検索結果が蓄積する。
コンテキストが増えすぎると、次の問題が起きる。
- コンテキスト長上限を超える
- コストとレイテンシが増える
- 不要な情報にモデルが引きずられる
- 矛盾した情報が混ざる
- ツール選択や判断が不安定になる
4 つの設計カテゴリ¶
Write Context¶
コンテキストウィンドウの外に情報を書き出す設計。 代表例は scratchpad と memory。
scratchpad は、あるタスクの実行中に必要な計画、仮説、途中結果を保存する場所。 ファイル、ランタイム state、専用ツールなどで実装できる。 長期メモリは、セッションをまたいで再利用したいユーザー設定、過去の判断、手順、好みなどを保存する。
Select Context¶
保存された情報から、今のステップに必要なものだけをコンテキストへ戻す設計。 scratchpad を読むのか、state の一部だけを LLM に見せるのか、長期メモリから関連するものだけを検索するのかを決める。
メモリ選択では、手続き的メモリ、エピソード記憶、意味記憶のように用途を分けると整理しやすい。 ツールが多すぎる場合は、ツール説明に対して RAG をかけ、必要なツールだけをモデルへ提示する方法もある。 コードベース検索では、embedding だけでは不十分になりやすく、grep、AST、知識グラフ、reranking の組み合わせが必要になる。
Compress Context¶
必要なトークンだけを残す設計。 代表例は会話履歴やツール結果の要約、古いメッセージのトリミング、検索結果の後処理。
ただし要約は簡単ではない。 エージェントの判断に必要なイベント、失敗、制約、ユーザー指示を落とすと、後続の行動が壊れる。 そのため、単純な短縮ではなく「意思決定に必要な情報を残す」圧縮として設計する必要がある。
Isolate Context¶
コンテキストを分割して、不要な情報を LLM から隔離する設計。 サブエージェント、サンドボックス、state schema が例として挙げられている。
サブエージェントは、それぞれが別のコンテキストウィンドウ、指示、ツールセットを持つため、関心ごとを分離できる。
サンドボックスは、画像、音声、大きな中間データ、コード実行結果などを環境側に保持し、必要な戻り値だけを LLM に渡すのに向く。
LangGraph の state object も、messages だけを LLM に見せ、他のフィールドを内部状態として保持する形で分離に使える。
LangGraph / LangSmith での適用¶
LangSmith はトレースと評価に使う。 まずエージェントの実行履歴とトークン使用量を観測し、どこにコンテキスト問題があるかを把握する。 次に、変更が性能を改善したかを評価で確認する。
LangGraph は、短期メモリ、長期メモリ、state、node、tool call、multi-agent を使って 4 パターンを実装する土台になる。 たとえば、状態に scratchpad を持たせる、メモリ collection から retrieval する、message list を要約・削除する、サブエージェントに別作業を委譲する、といった形。
要点¶
- エージェントの品質は、プロンプトだけでなくコンテキスト投入の設計に強く依存する。
- 保存、選択、圧縮、分離を別々の問題として扱うと設計しやすい。
- 長期メモリは便利だが、無関係な記憶を勝手に取り出すリスクがある。
- ツール結果や検索結果は、そのまま積むより後処理・要約・分離が必要になる。
- LangSmith のような観測と評価がないと、どのコンテキスト設計が効いたか判断しにくい。