LangChainのコンテキストエンジニアリング、より大きなコンテキストウィンドウを超えてエージェントの信頼性を高める
業界がますます大きなコンテキストウィンドウに注目するなか、LangChainのコンテキストエンジニアリングは、長時間稼働するエージェントにとって4つの仕組みを不可欠なものとして扱うようになっている。このアプローチは、コンテキスト予算、オフロード、圧縮、構造化されたtodo-state、そして永続メモリを組み合わせる。これらの制御により、責任は言語モデルからエージェントハーネスへと移る。
この違いは重要だ。公表されるコンテキスト上限は、あくまで容量の数値にすぎない。数百回に及ぶツール呼び出しの後でも、エージェントが適切な指示に気づくことを保証するものではない。また、古いメッセージが消えた際に、未完了の作業を保持することもできない。
したがって、浮上しつつある競争はLangChainと単一の競合フレームワークの対決ではない。ハーネスが管理する状態と、モデルが拡大し続けるトランスクリプトから確実に目標を回復できるという前提との対立である。OpenAIとAnthropicも同様のアーキテクチャ上の動きを見せており、この問題がモデルやプラットフォームをまたいで存在することを示唆している。
LangChainのコンテキストエンジニアリング、コンテキストを管理対象のリソースに変える
重要な変化は、コンテキストが無制限のトランスクリプトではなく、設計された実行時リソースになりつつあることだ。
9月12日の報道は、エージェントハーネス内の4つの仕組み、すなわち予算管理、圧縮、todo-stateの反復、セッション横断メモリに注目した。基盤となるcontext engineeringのドキュメントは、これらの考え方に具体的な実行時の振る舞いを与えている。
LangChainのDeep Agentsフレームワークは、コンテキストを複数のカテゴリに分けている。入力コンテキストには、プロンプト、メモリファイル、スキル、ツール指示が含まれる。ランタイムコンテキストは、ユーザー識別子や認証情報といった設定を実行中に伝達する。圧縮はあふれた会話を管理し、永続ストレージはスレッド間で存続すべき情報を支える。
この分類は、開発者がエージェントの失敗を診断する方法を変える。モデルが要件を忘れたからといって、直ちにモデルの知性が不足しているとは限らない。ハーネスが要件を誤った保存層に置いた、ノイズの下に埋めた、あるいは圧縮時に取り除いた可能性がある。
フレームワークのデフォルト設定は、こうした判断がどれほど具体的になっているかを示している。大きなツール結果はファイルシステムストレージへ移し、参照に置き換えられる。ドキュメントによれば、20,000トークンを超える結果は自動オフロードの対象となる。
要約は、アクティブなコンテキストがモデルの利用可能な入力ウィンドウの85％など、設定されたしきい値に達した時点で始まる。フレームワークはその後、直近の一部を保持しながら、古い履歴を構造化された要約へ変換する。
これらの数値は実装上のデフォルトであり、普遍的な法則ではない。長文書を処理するリサーチエージェントでは、より早い段階でのオフロードが必要になるかもしれない。限定的な障害をデバッグするコーディングエージェントなら、直近のターミナル出力をより長く保持することで恩恵を受ける可能性がある。
より持続的な原則は明確だ。かつて有用だったという理由だけで、生の履歴をモデルプロンプト内に残し続けるべきではない。
Deep Agentsは、要約が発生しても完全な会話をアクティブプロンプトの外部に保持する。要約は作業用の表現となり、元の記録は後の取得に利用できる状態で残る。
この設計は、チャットインターフェースがしばしば一体化して扱う2つの要件を分離する。エージェントには次の判断のためのコンパクトな作業セットが必要だ。システムには、復旧、検査、監査のための正規記録が必要となる。
この違いは、9月の報道が単なるプロンプト作成の話以上である理由も説明する。その本質的なテーマは状態アーキテクチャだ。プロンプトの表現は依然として重要だが、指示が長いタスクを通じて残るかどうかは、配置、保持、復旧によって決まるようになっている。
開発者は、リポジトリ移行中にこのパターンを観察できる。エージェントはまず、仕様、依存関係ファイル、テスト、ビルドログを読み込む。複数の出力が、数分のうちに元の要求のサイズを超えることもある。
すべてのバイトをアクティブプロンプトに保持すると、次の判断はより高コストになり、焦点もぼやける。すべてを取り除けば、最新のテストが失敗した理由を説明するエラーまで失うおそれがある。ハーネスは、何をアクティブに残し、何を参照にし、何を永続状態へ入れるかを継続的に選ばなければならない。
その選択が中心的な緊張を生む。圧縮はオーバーフローによる連続性の喪失を防ぐが、圧縮そのものが正しく継続するために必要な詳細を捨てる可能性がある。
より大きなウィンドウは安定した目標を保証しない
長いコンテキストは、注意、関連性、タスク制御よりも、保存容量の問題を解決しやすい。
エージェント型のワークロードは、1つの長い文書を読むこととは異なる。トランスクリプトは、繰り返される判断、ツール呼び出し、失敗、修正、環境変化を通じて増大する。あるステップでは重要でなさそうに見えた情報が、数ステップ後には決定的になる場合がある。
コンテキストウィンドウ内のすべてのトークンが、実用上同等の注意を受けるという考え方には、研究によって繰り返し疑問が投げかけられてきた。positional attention problemに関する先行研究では、長い入力の中央に置かれた関連情報をモデルが十分に活用できない可能性が示された。
この研究は、その効果をU字型の注意バイアスにも結びつけた。関連性にかかわらず、冒頭と末尾に近いトークンほど多くの注意を受けた。提案された較正は、評価対象の検索タスク全体で最大15ポイントの結果改善につながった。
新しいモデルは、単純な検索テストで改善を見せている。Googleの研究では、Gemini 2.5 Flashが、同じ位置依存の低下を見せることなく、コンテキスト上限に近い特定の事実探索タスクを処理した。しかし、1つの事実を取得することと、変化し続けるエージェントループを制御することは同じではない。
長時間稼働するエージェントは、新しい証拠に反応しながら、元の受け入れ基準を覚えておかなければならない。完了した作業と、試みただけの作業を区別する必要もある。さらに、新たな失敗が以前の計画を無効にした場合、それに気づかなければならない。
LOCA-benchは、制御可能なコンテキスト増大の下でエージェントを評価することで、この違いに取り組む。同ベンチマークのlong-context benchmarkは、環境履歴を増やしながら、基盤となるタスクの意味論を安定させる。
研究者らは、環境状態がより複雑になるにつれて、エージェントの性能は概して悪化すると報告している。また、高度なコンテキスト管理戦略が全体的な成功率を改善しうることも見いだしている。この結果は、モデルの能力から、モデルとハーネスを組み合わせたシステムへと注目を移す。
実務上の負荷は、コーディングエージェント、リサーチエージェント、コンピュータ利用製品を構築するチームにかかる。大きなコンテキストウィンドウを完全な信頼性戦略として説明することは、もはやできない。
ツールを追加するたびに、トランスクリプトは拡大しうる。ブラウザ出力にはナビゲーションテキストや繰り返し表示されるページ要素が含まれる。シェルツールはログ、コンパイラトレース、テスト出力を返す。文書ツールは、関連性が不明なファイルから数千行を注入することがある。
そのため、入力を増やすほどシグナル密度が下がる場合がある。モデルが技術的にはトークンを受け入れられても、エージェントはどの観測結果が次の行動を左右するかを特定しなければならない。
予算設定は、上限に達する前にこの問題へ対処する。コンテキスト予算は、運用上の価値に応じて貴重なプロンプト空間を割り当てる。現在の目標や安全ルールは、過去に成功したツール出力よりも強く保持されるべきだ。
予算には、次のモデル応答のための空間も確保しなければならない。入力ウィンドウを公表上限まで埋めると、推論、ツール引数、復旧指示に割ける余地が少なすぎる場合がある。
ここでエージェントのコンテキスト圧縮は、緊急機能ではなく運用ポリシーになる。チームには、しきい値、保護対象のフィールド、直近履歴の許容量、取得経路が必要だ。また、現実的なトレースをまたいでポリシーを検証する評価も必要となる。
有用な評価では、タスクの後半で修正を導入すべきだ。必要な詳細を初期のツール出力の中に隠すべきでもある。圧縮後にエージェントを再開させ、各要件がアクティブなままかを確認しなければならない。
テストでは、誤った連続性も測定すべきだ。エージェントは目標を失った後でも流暢な文章を生成できる。表面的な一貫性は、内部のタスク状態が正しいままであることを証明しない。
オフロードと圧縮はオーバーフローの異なる部分を解決する
オフロードはかさばる証拠をプロンプトから取り除き、圧縮はエージェントの運用履歴を書き換える。
この2つの仕組みは関連しているが、互換可能なものとして扱うと避けられるはずの失敗を招く。オフロードは元の資料を別の場所に保持する。圧縮は、すべての詳細を保持できない小さな表現を作る。
数千件の一致を返すコード検索を考えてみよう。完全な結果は、ファイル、データベース、オブジェクトストアに置くことができる。アクティブプロンプトに必要なのは、パス、短いプレビュー、そして後で関連行を取得するために十分なメタデータだけだ。
これは、元のコンテンツを利用可能なまま残すため、忠実性を保てる。エージェントはすべての一致を覚える必要はない。結果がどこにあり、なぜ収集されたのかを覚えておけばよい。
圧縮はより重大な意味を持つ。メッセージの連なりを、より小さな状態表現へ変換するからだ。その表現は、判断、要件、未解決の失敗、現在の計画を保持しなければならない。
Anthropicはコンパクションを、会話が上限に近づいた際に要約し、その要約を用いて新しいコンテキストを開始する手法として説明している。同社のagent context guidanceは、アーキテクチャ上の決定、未解決のバグ、実装の詳細を保持することを推奨している。
Anthropicはまた、過度に積極的なコンパクションでは、その重要性が後になって明らかになる微妙な情報が失われる可能性があると警告している。これが根本的なトレードオフだ。システムは将来のステップについてすべてを知る前に、資料を捨てなければならない。
OpenAIも同様のアーキテクチャ上の結論に至っている。同社のResponses APIには、長時間かつツールを多用するワークフロー向けのネイティブなresponse compactionが含まれている。
OpenAIによれば、圧縮された表現は、主要な過去の状態をトークン効率の高い形で保持する。次のコンテキストには、そのコンパクション項目に加えて、先行ウィンドウから選ばれた価値の高い情報が含まれる。
実装は異なるものの、方向性は一致している。どちらも連続性のロジックをハーネスとAPIの層に置く。開発者が無限に拡大する生のトランスクリプトを再送し続けるべきだとは、どちらも想定していない。
最初に扱うべき対象として最も安全なのは、通常、冗長なツール出力だ。完了したファイル書き込みでは、書き込まれたファイル全体を会話履歴に埋め込んだままにする必要はない。依存関係のインストールが成功した場合も、通常は数百行の過去ログを必要としない。
失敗した操作には、より慎重な対応が必要だ。正確なエラー、そのエラーを生んだコマンド、関連する環境の詳細は、次の試行を左右する可能性がある。「ビルドに失敗した」という一般的な要約では、有用な状態が失われる。
したがって、優れたエージェントのコンテキスト圧縮は因果関係を保持すべきだ。どの行動がどの観測結果を生み、どの結論が続き、その結論が暫定的なものかどうかを記録する必要がある。
また、ソース資料とエージェントの推論を区別すべきでもある。要約が両者を混ぜると、再開したエージェントが以前の推測を検証済みの証拠として扱うおそれがある。
実践的な設計の一つは、3層構造を採用する。ホット層には目標、制約、todo-state、直近のメッセージ、即時の証拠を置く。ウォーム層には要約とインデックス化された成果物を置く。コールド層には正規のトランスクリプト、ファイル、過去の結果を保存する。
すると、検索は保存と同じくらい重要になる。ファイルへの参照は、エージェントがいつそれを確認すべきかを把握して初めて役に立つ。メタデータには、成果物のトピック、出所、タイムスタンプ、現在の目標との関係を記述すべきだ。
リサーチエージェントは分かりやすい例を示している。論文全文を外部化しつつ、引用記録と主張の要約をアクティブな状態で保持できる。公開前には元の箇所へ戻り、各要約が正確であることを確認できる。
コーディングエージェントも同じパターンを利用できる。現在失敗しているテストと予定している修正を、アクティブなコンテキスト内に保持できる。古いビルドログは検索可能な状態に保ち、アーキテクチャ上の決定は永続的なプロジェクトノートに記録する。
この階層的なアプローチは、情報損失をなくすものではない。損失を明示的にし、回復可能かつ検証可能にする。
Todo-Stateは作業を軌道に乗せ続ける小さな制御プレーン
構造化されたtodo-stateは、未完了の作業を繰り返しエージェントに伝えることで、タスクの方向性を守る。
todoリストは、圧縮やメモリより単純に見える。その単純さゆえに、重要性を過小評価しやすい。長期にわたるタスクでは、todo-stateははるかに大きな証拠群を管理するためのコンパクトな制御プレーンとして機能する。
LangChainのDeep Agentsには、作業を個別のステップに分解するwrite_todos機能が含まれている。関連するtodoパターンでは、保留中、進行中、完了という状態で項目を管理する。
こうしたラベルは、物語形式の進捗段落よりも信頼性の高い表現を生む。段落では複数の行動に触れても、完了と意図を明確に区別できない場合がある。構造化された状態は、各項目に明示的なステータスを求める。
todo-stateは、散在するコミットメントよりも要約をまたいで残しやすい。コンパクターは、トランスクリプト内のすべての約束を探し出さなくても、一つの構造化オブジェクトを保護できる。
これは、エージェントが魅力的な横道の作業に遭遇した際に重要になる。コーディングエージェントは、機能実装中に無関係なlintエラーを見つけるかもしれない。安定したタスクリストがなければ、残りのコンテキストをスコープ外の問題修正に費やしてしまう可能性がある。
todo-stateは、受け入れ基準を再び視野に戻す。要求された機能がまだ未完成であること、新たなlint問題は保留にすること、回帰テストは依然として実行が必要であることを示せる。
有用な項目には、短いラベル以上の情報が必要だ。ステータス、完了条件、阻害要因となる依存関係を持たせる必要がある。高リスクのタスクでは、完了前に必要となる証拠も求められる場合がある。
たとえば、「認証を更新する」では曖昧すぎる。より良い項目では、トークン更新の挙動を変更する必要があること、既存のログインテストが通過しなければならないこと、新しい有効期限切れケースの検証が必要であることを明記する。
反復はこの仕組みの一部である。ハーネスは、モデルが次の判断を下す箇所の近くに現在のtodo-stateを注入し、作業目標をプロンプトの末尾近くに維持できる。
この配置は、トランスクリプトのみで制御する構造的な弱点を補う。元の依頼は冒頭付近に残る一方、直近のツール出力が末尾を支配する。タスクリストは、モデルが現在行動している位置で、実行すべき目標を再提示する。
ただし、todo-stateにも固有の失敗モードがある。エージェントはテストを実行する前に、ファイルを編集しただけで項目を完了にするかもしれない。進捗を明確にしないまま注意を消費する、細かすぎる項目を大量に作る可能性もある。
したがって、ステータス更新には証拠のルールが必要だ。パッチが適用されたというだけで、コード変更が検証済みになるわけではない。検索結果が言及したというだけで、リサーチ上の主張が検証されるわけでもない。
ハーネスは、項目を完了に変更する際に検証への参照を要求できる。その参照は、通過したテスト、レビュー済みの成果物、または引用した一次情報源を示すものになり得る。
人間によるレビューも容易になる。数百件のメッセージからタスクを再構築しなくても、完了済みと保留中の作業を明示的なリストで確認できる。
todo-stateは長期メモリになるべきではない。すべての好みや過去の判断ではなく、現在のタスクを記述するものだ。これらの機能を混ぜると、別の過負荷な状態オブジェクトが生まれる。
また、詳細な証拠の代わりにもならない。リストは成果物へ注意を向けさせるが、関連するすべての事実を保持することはできない。todo項目は、テストログ全体を埋め込まずにそのログへリンクできる。
ナレッジワーカーにとって、このパターンは規律あるAI workflow設計に似ている。目標、証拠、判断、次のアクションを、一つの会話ストリームに混在させず区別して維持する。
本当の価値は、その分離にある。トランスクリプトは活動を記録する。todo-stateは義務を記録する。
AIエージェントのメモリはセッションを超えて継続性を拡張する
永続的なメモリはセッション間の継続性を解決するが、ハーネスが書き込みと取得を制御して初めて有効に機能する。
圧縮は、長い実行の中でコンテキスト境界をまたいでエージェントを導く。メモリが扱うのは別の境界、すなわち一つのスレッドの終了と次のスレッドの開始だ。
LangChainの設計では、会話をまたいで保持すべき情報にファイルシステムを基盤とするメモリルートを使う。複合バックエンドは、memoriesディレクトリなどの指定パスを永続ストアへ送れる。
ドキュメントでは、常時ロードするメモリを最小限に保つことが推奨されている。プロジェクトの慣例や安定したユーザー設定はそこに置く。詳細なワークフローは、必要なときだけロードされるスキルに残してよい。
これは組織運用のルールに見せかけた、予算に関する判断である。永続情報も、取得時にはアクティブコンテキストを消費する。すべてを保存しても、コンテキスト汚染をトランスクリプトからメモリストアへ移すだけになる。
したがって、有効なAIエージェントメモリには選別が必要だ。安定した事実は永続化に値する。一時的な観察、期限切れの計画、未検証の推測は通常、そうではない。
エージェントが生成したメモリは誤りを増幅し得るため、書き込みポリシーが重要になる。エージェントが誤った結論を永続的なルールとして保存すると、将来のセッションは元の証拠を再確認せずにそれを繰り返す可能性がある。
各メモリには、来歴、適用範囲、更新条件を持たせるべきだ。来歴は情報の出所を示す。適用範囲は、どのプロジェクトやユーザーに適用されるかを定める。更新条件は、いつそのエントリを置き換えるべきかを説明する。
競合には明示的な処理が必要だ。新しいプロジェクト指示は、そのプロジェクト内では古い慣例を上書きすべきである。しかし、他の場所に適用されるグローバルな設定を、黙って書き換えるべきではない。
メモリの取得にも関連性の制御が必要だ。保存したすべてのノートを起動時にロードすると、過大なコンテキストという問題が再発する。ハーネスは小さく安定した中核だけを注入し、現在のタスクが一致する場合にのみ他の記録を取得すべきだ。
これにより、有用な役割分担が生まれる。システムプロンプトには譲れない行動を置く。todo-stateには現在の義務を置く。ワーキングコンテキストには即時の証拠を置く。永続メモリには、過去のセッションから選別した知識を置く。
正規の成果物は、この4つのいずれにも含めない。ソースファイル、トランスクリプト、テスト結果、ドキュメントは、元の形式で取得可能な状態に保つべきだ。
Anthropicは、構造化されたノートテイキングを、エージェントが単一のコンテキストウィンドウを超えて進捗を維持する方法として説明している。その例には、タスクノート、探索済みの場所、達成事項、リセット後に再利用される戦略が含まれる。
利点は完璧な想起ではない。再構築である。リセット後、エージェントは目標を回復し、証拠を見つけ、明示的な状態から作業を続行できる。
その再構築にはセキュリティ境界が必要だ。個人メモリはユーザー間で共有されるべきではない。プロジェクトの秘密情報をグローバル共有ストアに入れるべきでもない。取得したテキストもまた、信頼できる指示ではなくデータとして扱わなければならない。
こうしたリスクにより、可観測性は不可欠になる。開発者は、どのメモリがプロンプトに入ったか、なぜ選ばれたか、行動に影響したかを確認できるべきだ。
削除も重要である。永続メモリシステムには、古くなった設定、誤った結論、機密情報を取り除く手段が必要だ。ライフサイクル制御のない永続化は負債になる。
最も信頼できるシステムは、メモリを人間のような想起ではなく、管理対象のデータとして扱うだろう。記録、来歴、権限、保持、取得の挙動を可視化するだろう。
この捉え方は、誇張された主張も避けられる。AIエージェントメモリは、モデルに継続的な個人的経験を与えるものではない。ステートレスまたは部分的にステートフルなプロセスに、過去の作業から選択された記録へのアクセスを与えるものだ。
次に問うべきは最大トークン容量ではなく回復品質
エージェントプラットフォームは現在、ハーネスが繰り返される状態変換の後にも目標と証拠を保持できることを証明する必要がある。
今後数か月で注目すべきシグナルは3つある。第一は、複数回のコンパクションサイクル後における回復精度だ。ベンダーは、エージェントが繰り返しリセットされても、制約、未完了項目、情報源の帰属を保持できるかをテストすべきである。
有用なベンチマークでは、異なる段階で導入された要件を含める。そして、外部化、圧縮、中断、再開の後にも、エージェントがそれらの要件に従うかを測定する。
構造化状態が生の長いトランスクリプトを一貫して上回るなら、このシグナルはハーネス管理型アプローチを強化する。コンパクションによって判断が繰り返し変化したり、保護された制約が失われたりするなら、その根拠は弱まる。
第二のシグナルはメモリの可観測性だ。開発者には、エージェントが何を保存し、何を取得し、なぜ各項目がアクティブコンテキストに入ったのかを示す記録が必要である。
明確な検査ツールは、エンタープライズ用途におけるAIエージェントメモリの安全性を高める。不透明または再現不能な取得では、エージェントが古い判断を繰り返した理由をチームが説明できなくなる。
第三のシグナルは、検証と結び付いたtodo-stateだ。フレームワークは、モデルが検証なしに成功を宣言できるようにするのではなく、完了ステータスを具体的な証拠と結び付けるべきである。
コーディング作業では、その証拠にテストとビルド結果を含められる。リサーチでは、一次情報源の確認を含められる。コンピュータ利用タスクでは、アプリケーション状態で確認された変更を含められる。
このシグナルで成功すれば、todo-stateが単なる進捗表示以上のものを提供することが示される。タスクリストを強制力のある制御面として確立することになる。
懐疑的な見方にも相当な根拠がある。すべての圧縮アルゴリズムは、不確実性の下で保持に関する選択を行う。すべてのメモリシステムは誤った記録を取得し得る。すべてのタスクリストは、印象的な一貫性をもって誤った計画を維持し得る。
ハーネスは、洗練された継続性の陰にモデルの限界を隠すこともある。エージェントは、要約の途中で消えた要件を誤解したまま、滑らかに再開するかもしれない。ユーザーに必要なのは、流暢な継続性のデモではなく、成果に基づく評価だ。
コストも別のトレードオフをもたらす。頻繁な要約には追加のモデル呼び出しが必要になる。取得はレイテンシーを加える。永続ストレージはガバナンス上の義務を生む。豊富な状態追跡はエンジニアリングの複雑さを増す。
しかし、代替案も無料ではない。繰り返しの作業はトークンと時間を消費する。目標の喪失は、不正確な変更、不完全なリサーチ、危険なツール利用を引き起こし得る。より大きなウィンドウは、こうした失敗を遅らせるだけで、その原因を取り除くものではない。
LangChainのコンテキストエンジニアリングが重要なのは、これらのトレードオフを可視化するからだ。OpenAIのコンパクションに関する取り組みとAnthropicの構造化メモリに関するガイダンスも、同じ方向を指している。長期的な信頼性は、システムの問題になりつつある。
したがって、エージェントを評価するチームは運用上の問いを投げかけるべきだ。どの情報がアクティブな状態に保たれるのか。何が要約されるのか。どの記録が正規のものとして残るのか。中断後、エージェントは未完了の作業をどのように回復するのか。
敵対的なタイミングもテストすべきです。圧縮の直前にエージェントを修正する。複数のステップを完了した後で受け入れ基準を変更する。新しいセッションでタスクを再開し、何が残っているかを確認する。
最も堅牢な設計は、単一の仕組みに依存しません。予算は回避可能な過負荷を防ぎます。オフロードは大容量の証拠を保持します。圧縮は実行可能なナラティブを維持します。Todo-state は直近の義務を保護し、メモリは後から選択した知識を復元します。
この組み合わせこそが、LangChain のコンテキストエンジニアリングにおける中心的な教訓です。次世代のエージェントは、すべてを記憶することで勝つのではありません。適切な状態を保持し、原典の証拠を取得し、完了した作業が依然として目標に合致していることを証明することで勝つのです。
ビルダーは今、何をすべきでしょうか。代表的な長期タスクを1つ計測し、複数回のコンパクションイベントを意図的に発生させ、最終結果を当初の受け入れ基準と比較してください。失われた制約、根拠のない完了、不必要な取得をすべて記録します。そのうえで、エージェントの自律性を拡大する前に、予算、保護対象の todo-state、メモリポリシーを調整してください。
