現代のAI開発において最も重要なテーマの一つが、エージェント型AIにおけるコンテキストエンジニアリングとメモリ管理である。本動画では、Google、Anthropic、Manusが発表した3つの重要な論文を基に、長時間実行可能なAIエージェントの構築方法を徹底解説する。多くの開発者が誤解しているメモリシステムの本質、コンテキストウィンドウの限界、そして実用的なエージェント設計の9つの原則と9つの落とし穴を具体的に示す。メモリをランタイム環境として第一級に扱い、多層構造で管理し、動的にコンパイルすることで、数時間にわたる複雑なタスクを処理できる真の自律型エージェントが実現可能となる。この技術的アプローチは、エンタープライズレベルでの実用的なAIシステム構築に不可欠な知見である。
エージェント型コンテキストエンジニアリングの重要性
今日、世界で最も重要なトピックは、エージェント型コンテキストエンジニアリング、つまりAIエージェントにおけるメモリの扱い方です。この分野について深く掘り下げる時期が来ています。そこで今回は、エージェント型コンテキストエンジニアリングに関して最近発表された3つの重要な論文について解説していきます。その仕組み、人々がエージェントのメモリシステムを誤って構築したり誤解したりする一般的な方法、そしてエージェント型コンテキストエンジニアリングによってのみ実現できるユースケースについてお話しします。では、始めましょう。
まず、人々はメモリを誤解しています。コンテキストと言うと、人々はしばしば巨大なプロンプトウィンドウを思い浮かべます。そしてメモリと言うと、RAGやデータベース内のベクトル化された埋め込みでなければならないと考えがちです。しかし実際には、エージェントにとってメモリこそがシステムそのものなのです。プロンプトがエージェントではありません。LLM単体がエージェントでもありません。
状態、つまりエージェントのアクションがどのように保存され、変換され、フィルタリングされ、再利用され、進化していくか。それこそが、おもちゃのデモと実際の作業を処理できるものとの決定的な違いなのです。そして私たちはそれを誤解しています。過去2年間で、より長いコンテキストウィンドウと、はるかに賢いモデルが登場しました。しかし、それらはメモリ問題を解決しませんでした。
実際には、問題を深刻化させたのです。素朴な考え方としては、コンテキストが大きくなればエージェントの能力も高まるというものです。しかし実際に起きたことは、アテンションが希少になり、ログが膨れ上がり、無関係な履歴が重要なシグナルをしばしば溺れさせてしまうということです。エージェントのメモリについて語るとき、私たちがメモリを正しく扱っていないため、タスクが長くなるにつれてパフォーマンスが実際に低下することが多いのです。
そしてこれはLLMの欠陥ではなく、私たちのメモリ構築の欠陥なのです。ですから、これは私たちが変えていくべきことです。すべてをコンテキストウィンドウに詰め込もうとするのをやめ、すべてがRAGだと思い込むのをやめて、メモリを第一級のランタイム環境としてエンジニアリングし始める必要があります。GoogleのADKは、ここでアーキテクチャ的な解決策を示しました。
これは私が取り上げる論文の一つです。それは多層メモリシステムで、作業用コンテキスト、セッション、メモリ、そしてアーティファクトを持っています。プロンプトは各ステップで動的にコンパイルされます。盲目的に蓄積されるだけではありません。これは、コンテキストが単に追加されるのではなく、真に計算されるという初めての主流の明確な表現です。
ACCEの論文は、適応的な修正の側面を示しました。プロンプト、指示、メモリが実行フィードバックを通じてどのように進化しなければならないかということです。ちなみにACCEは、Anthropicがまとめたエージェント型コンテキストエンジニアリングの論文です。静的なプロンプトやワンショットのファインチューニングは、長期的なタスクでは生き残れません。多くの人が「このあれやこれやのためにエージェントをファインチューニングする必要があるのか」と尋ねますが、その必要はありません。
エージェントには、曖昧さに陥ることなく戦略を更新するシステムが必要なのです。そして重要なのはシステムなのです。プロンプト、指示、メモリの組み合わせです。一方、Manusは非常に実用的な解決策を示す論文を発表しました。長時間実行されるエージェントは、コンテキストを積極的に削減し、重い状態をファイルシステムや仮想マシンにオフロードし、サブエージェントのスコープを非常にクリーンに分離した場合にのみ機能します。
これがなければ、長いタスクはログの肥大化、ツールのノイズ、指示のドリフトによって崩壊してしまいます。そしてそれがエージェントのパフォーマンスを低下させる要因の一部なのです。これら3つ、Anthropicのもの、Googleのもの、Manusのものをすべて組み合わせると、2025年後半におけるエージェント型コンテキストエンジニアリングの最初の一貫した青写真が得られます。
エージェント型コンテキストエンジニアリングの原則
まとめると、そしてこれらについて一つずつ話していきますが、メモリファーストの設計について話す必要があります。コンテキストを効果的にコンパイラの出力として扱うこと、ピン留めよりも検索を優先すること(これについては後で詳しく説明します)、スキーマ駆動の要約、重い状態のオフロードとその仕組み、エージェントのスコープを効果的に分離する方法、そして時間とともに洗練されていく進化するプレイブックについてです。
では、飛び込んでいきましょう。最初にお話ししたいスケーリングの原則は、コンテキストをトランスクリプトではなくコンパイルされたビューとして扱うべきだということです。すべてのLLM呼び出しは、永続的な状態に対する新たに計算された投影であるべきです。つまり、今何が関連しているのか、今どの指示が適用されるのか、今どのアーティファクトが重要なのか、そして今どのメモリを表面化すべきなのか、これらをランタイムで計算しているのです。
常に同じ永続的な状態を想定しているわけではありません。これによりシグナルの希釈を防ぎます。つまり、エージェントのメモリにコンテキストウィンドウや会話の過去500ターンをすべて引きずり込むのではなく、タスクの連続性を保ちながらも最小限の非常に関連性の高いスライスを再構築するのです。そうすることで、LLMのアテンションを溢れさせることがありません。
これは、数時間にわたるエージェントループを機能させる唯一の方法です。多くの場合、人々はこれなしで済ませられると思い込んでいますが、それはできません。原則その2は、ストレージとプレゼンテーションを分離する多層メモリモデルを構築する必要があるということです。作業用コンテキストは、呼び出しごとの最小限のビューです。これが先ほどお話ししたことです。
セッションは、アクションの全軌跡に対する構造化されたイベントログのようなものです。メモリは、複数の実行にわたって抽出された永続的で検索可能な洞察です。一方、アーティファクトは、ハンドルやタグによって参照される大きなオブジェクトです。単に貼り付けられるのではありません。作業用コンテキスト、セッション、メモリ、アーティファクトという4つを正しく定義し、真の多層メモリモデルを持つことで、コンテキストウィンドウを小さく保ちながら、状態つまり全体的なメモリシステムを任意に大きく成長させることができます。
非常に豊かに成長させることができ、これは正直に言って従来のコンピュータアーキテクチャを反映しています。キャッシュ、RAM、ディスクドライブという概念があるのは、同じボトルネックがLLMエージェントにも再び現れるからです。ですから、なぜ車輪を再発明する必要があるのでしょうか。このコンテキストで正しく適用すればいいのです。原則その3は、デフォルトでスコープを設定することです。
エージェントは必要なときにメモリを引き出すべきであり、すべてを継承すべきではありません。デフォルトのコンテキストにはほとんど何も含まれていないべきです。ほとんど誰も言わないので、もう一度言います。デフォルトのコンテキストにはほとんど何も含まれていないべきです。そして検索が能動的な決定となるのです。エージェントは、過去のステップを思い出すタイミングを選択します。アーティファクトを取得するタイミングを選択します。
追加の詳細をロードするタイミングを選択します。これによりアテンションが集中し、コンテキストの腐敗を避け、長期的なタスクを非常に実行可能にします。なぜなら、古い情報が受動的に引き継がれることがないからです。原則その4は、検索がピン留めに勝るということです。長期的なメモリは、ピン留めされて永続的であるのではなく、検索可能である必要があります。すべてをコンテキストに保持しようとする試みは、アテンションの制約が効いてくるため、失敗する傾向があります。
100万トークンのような非常に大きなコンテキストウィンドウがあり、さらに大きなものも登場するでしょうが、それをコンテキストウィンドウに押し込みたくなります。しかし、検索の精度は低下する傾向があります。メモリを、エージェントが明確な関連性でランク付けされた構造化された情報を使ってオンデマンドでクエリするものとして扱ってください。つまり、コンテキストウィンドウは常に検索の結果であり、受動的な履歴の蓄積ではないのです。
これにより、エージェントは5日前の重要な制約と5分前のノイズを区別できるようになります。そうでなければ、エージェントは非常にリーセンシーバイアス(最近のものに偏る傾向)があり、コンテキストウィンドウで混乱してしまいます。長期的なメモリを圧縮すれば押し込めるという考えを超えるために、エージェントに検索の明確な指示を与え、検索を可能にする必要があります。
原則その5は、要約はスキーマ駆動で、構造化され、理想的には可逆的である必要があるということです。人々はその部分について語りません。素朴な要約は、複数ステップの推論を非常に曖昧で包括的な光沢のあるスープに変えてしまいます。決定構造を取り除いてしまうのです。すべてを圧縮してしまうだけです。
しかし、意図的にコンパクト化する場合、スキーマを使い、テンプレートを使い、イベントタイプを非常に意図的に使ってコンパクト化することで、何についてのメモリであっても本質的なセマンティクスを保持するなら、表面的な詳細を落としつつも、メモリの関連部分が保持されることがスキーマによって保証されているという事実を知ることができます。
それこそが長期実行コンテキストを維持可能にするものです。デバッグ可能にするものです。なぜなら、何が要約されたかだけでなく、どのように要約されたかを検査できるからです。ほとんど誰もこれについて語っていません。ちなみに、これは実用的なエージェント型の会話では見られない本当に重要なポイントです。原則その6は、お願いですから、お願いですから、重い状態をツール、ファイルシステム、サンドボックスにオフロードしてください。
特に大規模な場合、モデルに生のツール結果を与えないでください。それらをディスクに書き込んで、ポインタを渡してください。20個の重複するツールがあるとして、それらを公開しないでください。シェルやブラウザ、ファイル操作のような小さな直交するツールセットを公開し、エージェント自身にワークフローを構成させてください。これによりコンテキストが本当にスリムに保たれ、モデルの認知的負担が軽減され、はるかに複雑な行動の連鎖が解き放たれます。
20個の重複するツールがなければ複雑な行動の連鎖に到達できないと思うかもしれませんが、実際には逆なのです。非常に明確に直交するツールセットがある場合、エージェントはボックスの中に何があるかをより自由に理解でき、それらのクールなワークフローにより多くの計算リソースを割り当てることができます。
原則その7は、人間の組織図を模倣するためではなく、状態とスコープを分離するためにサブエージェントを使用することです。サブエージェントは、異なるアクターにそれぞれの作業用コンテキストと責任を与えることで、コンテキストの爆発を止めるべきです。プランナー、エグゼキューター、ベリファイアはすべて古典的なエージェントタイプであり、彼らは狭くスコープされたビューを持ち、やり取りする膨大なトランスクリプトではなく、構造化されたアーティファクトを通じてコミュニケーションを取る必要があります。
これにより、多くの素朴なマルチエージェント設計を悩ませるクロストーク、推論のドリフト、幻覚的なチームワークの多くが排除されるはずです。プランナー、エグゼキューター、ベリファイアは人間の職種ではないことに注目してください。人間の職種名でエージェントを作成しないでください。意味がありません。エージェント型のタスクとして考え、人間の前提をそこに投影しないでください。
原則その8は、キャッシングとプレフィックスの安定性を中心にプロンプトレイアウトを設計することです。説明しましょう。エージェントのアイデンティティ、指示、静的戦略のような安定したプレフィックスはほとんど変更されないべきなので、キャッシュをターン間で再利用できます。可変のサフィックス、つまり現在のユーザー入力、新しいツール出力のみが変更されるべきです。
これにより、複数ステップのエージェントループが、キャッシングとプレフィックスの不安定性のために1ステップあたり200ミリ秒という非常に長い時間から、サフィックス、つまり現在のユーザー入力のために素早く読み取れる非常に安定した薄いプレフィックスへと変換されます。スキーマはクリーンです。非常に狭く、非常にクリーンで、モデルが理解できる方法で出力のみが変化しています。
これによりレイテンシを10倍削減できます。200ミリ秒から20ミリ秒程度になります。そしてコストを劇的に削減できますが、より信頼性の高い出力も可能にします。原則その9は、エージェント自身の戦略を進化させることです。
静的なプロンプトは、プロンプトを進化させるまでエージェントをフリーズさせます。バージョン1でフリーズさせてしまうのです。一方、Anthropicのアプローチは、戦略、メモリ、指示が実行フィードバックを通じて更新されるべきことを示しています。能力を上書きするのではなく、洗練させる小さな構造化された増分です。
そしてそれにより、人間のいじくり回しからではなく、実行から学習する実際のエージェントが可能になります。基本的に、エージェントが戦略を更新することを許可され、学習に応じてメモリを更新することを許可され、指示を更新することを許可されれば、仕事をより上手にこなすことを学習するエージェントの可能性が解き放たれます。
よくある落とし穴
人々がこれらを適用しない場合に壊れる一般的な落とし穴は何でしょうか。本当に一般的なものです。私はいくらか調査してきました。エージェントを構築してきました。これはよく起こります。その1、すべてをプロンプトにダンプすることです。これはシグナルの希釈につながります。コストが上昇し、推論が劣化します。エージェントは文字通り、これを行うと精度が低下します。その2、ドメインの洞察を消去する盲目的な要約です。
ただ要約しろと言って、スキーマもなく、構造もなければ、制約を失い、エッジケースを失い、因果関係を失います。有能なエージェントが仕事をするために必要なものです。そしてこれによりコンテキストの崩壊が生じ、エージェントは特定の有用な作業をするのではなく、ますます一般的になってしまいます。
落とし穴その3は、長いコンテキストウィンドウを無制限のRAMであるかのように扱うことです。より大きなウィンドウは、関連性フィルタリングと組み合わせない限り、実際にはノイズと混乱を増加させます。より多くのトークンは必ずしもより多くの明確さを得られることを意味せず、しばしばより多くの注意散漫を意味します。
人々はコンテキストウィンドウを車のトランクのように扱い、そこにものを投げ込めばいいと考えます。それはやめてください。落とし穴4は、プロンプトを可観測性シンクとして使用することです。人々はデバッグログを貼り付け、エラーログメッセージを同期し、巨大なツール出力をプロンプトに入れます。それはアテンションを汚染するだけです。
人間には可観測性が必要ですが、エージェントはそれらに溺れてしまいます。ですから、安定したエージェントパフォーマンスのためにシステムを構築してください。可観測性への他の方法を見つけます。実際、よく構築されたメモリシステムは非常に観測可能です。落とし穴その5は、ツールの肥大化です。
モデルに多くの微妙に異なるツールオプションと巨大なツールスキーマを与えると、非常に洗練されていると思うかもしれませんが、実際にはエラー率を上げてシステムを遅くしているだけです。落とし穴その6は、エージェントを擬人化することです。複数のエージェントが同じトランスクリプトを持ち、みんなが話そうとし、人間の役割を担おうとする場合、なぜなら人間の仕事を与えたからです、推論のドリフトが生じます。
重複した努力が生じます。幻覚の複合が生じます。システムをより頑健にしたいのです。そして、おそらくここには私たち人間にとっての教訓もあると思います。私たちは、エージェントが仕事をするために必要なコンテキストだけを持つシステムを設計しています。職場での私たちの役割がどのように進化しているかについても、何かヒントがあるかもしれません。
ただの考えです。7番目の落とし穴は、決して変わらない静的なプロンプト構成です。人々は知識の蓄積やヒューリスティックスの洗練を全く入れません。進化するようにシステムを設計しません。本質的に毎回エージェントをゼロから再構築していますが、意図的な方法で成長するにつれてプロンプティングや思考を調整する余地をエージェントに与えていません。
これはやや洗練された実装ですが、優れたマルチエージェント実装では、システムに意図的に学習する余地を与えます。決して変わらない静的な構成を持つだけではありません。そしてその学習を文書化している限り、それを制御し、観察し、変更し、安全に管理する余地があります。その8は、ハーネスを過度に構造化すると、モデルは窮屈に感じるということです。
フロンティアモデルを入れ替えても改善が見られない場合、通常はアーキテクチャがボトルネックになっています。基本的に、硬直したハーネスは新興能力を殺してしまう可能性があり、直交するツールを持つ有用なハーネスと、必要に応じて設定できる非常に明確に注入可能なコンテキストプロンプト、進化するスキーマとの間には微妙な境界線があり、それがモデルにその能力を示す余地を与えます。
ハーネスがあまりにもロックダウンされている場合、モデル間での違いはあまり見られないでしょう。そして素朴にモデルを非難するかもしれません。しかし実際には、構造があまりにも狭く制約されています。モデルができることは一つだけです。落とし穴その9は、キャッシングとプレフィックス規律を無視することです。
キャッシングとプレフィックス規律が必要だと言ったことを覚えていますか。それをしない場合、プロンプティングスキーマでクリーンなプレフィックス規律がない場合、モデルが何が起こっているかを理解するためにそのプロンプトを数回再処理しなければならないため、非常に予測不可能なレイテンシが発生します。タスクが長くなるにつれてスケールするのが非常に難しくなります。
メモリ設計で解放されるユースケース
さて、落とし穴を乗り越えました。良いコンテキストエンジニアリング、良いメモリを持つエージェント型コンテキストシステムを設計するための原則のいくつかを乗り越えました。何が解放されるのでしょうか。これらのシステムを適切に設計できるようになると、何ができるようになるのでしょうか。その1、これは本当に長期的な自律性を解放します。数時間にわたる研究、ウェブブラウジング、時間をかけた実行のシミュレーション、例えばリポジトリ監査、エージェントが一貫性を保つマルチステージコード生成といったビジネスをしたい場合は、一度にすべてのコンテキストを投げつけるのではなく、関連する状態のスライスを与えるビジネスをしなければなりません。
そしてこれが長期的な自律性を可能にします。ユースケースその2、これは真の自己改善型エージェントを可能にします。時間とともに改善するエージェントは、メモリシステムを適切に構築すれば、戦略、ヒューリスティックス、ドメイン知識をログに記録し更新できるようになります。
そして適切にスコープを設定すれば、エージェントをオーバースコープする方法でそれらを更新することはありません。エージェント型のスコープを依然として制約できますが、エージェントが各実行から学習するにつれて、そのスコープ内でますます高い知能で実行できるようにすることができます。これは重みによるトレーニングではありません。モデルの重みを変更しているわけではありません。これは、エージェントが何をしたかを記録し学習するよう明確に指示されていれば、完全にメモリと指示レイヤーで起こり得ます。
ユースケースその3、これは実際にスケールするクロスセッションのパーソナライゼーションを可能にします。ユーザーの好み、制約、エージェントにおける過去の結果や行動パターンを記憶する永続的なプロファイルが必要な場合、呼び出しごとのコンテキストを膨張させる必要はありません。
メモリ状態を正しく構築していれば、重要な特定のスライスを注入するだけでそれを実現できます。その4、これはクロストークやドリフトなしでの真のマルチエージェントオーケストレーションを可能にします。プランナー、リサーチャー、エグゼキューター、バリデーター、テスターがすべて構造化されたアーティファクトを通じて協力することができ、コンテキストの汚染につながる混沌とした雑談にはなりません。
ユースケースその5、非常に大きな作業体系にわたる深い推論を可能にします。エージェントは、リポジトリ全体、データセット、PDF、ログを、すべてをトークン化するのではなく、アーティファクトとして扱うことで分析できます。構造化されたサンプリング、構造化された検索、推論をリポジトリの生のサイズから切り離すクリーンな要約を構造化できるからです。
その6、監査可能で、コンプライアンスに準拠した、エンタープライズ対応のエージェント型システムを可能にします。これはおそらく結果ですが、メモリがこれらのシステムの妨げになっているため、指摘する価値があると思います。モデルが何を見て、なぜ行動したかの完全な再構築可能性を得られます。セッションログ、圧縮イベント、メモリ更新がすべて追跡可能になります。
そしてそれはすべてメモリレイヤーで起こっています。メモリレイヤーを正しく構築しなければ、金融、法律、医療、あるいは実際のプロダクションシステムにとって重要な方法で追跡することが難しくなります。ユースケースその7は、コスト安定的なエージェント運用が必要です。コストの増加が線形であってはなりません。
実際には、サブ線形であるべきです。キャッシュを再利用し、ビューをインテリジェントに圧縮し、作業用コンテキストを小さく保てば、それを実現できます。基本的に、メモリを適切に構築すれば、すべてのトークンが重要になります。そしてそれにより、コストをスケールさせるだけでなく、常時稼働のエージェントサービスのようなものにたどり着けます。エンタープライズ全体でエージェントを本当にスケールさせようとしている場合、それは重要です。
その8、ドメイン固有のエージェントOS環境にたどり着けます。金融エージェントは、メモリが正しく構築されていなければ長期的なリスクを持ちます。コーディングエージェントは、メモリシステムが正しく構築されていれば、完全なワークスペース履歴を持つことができます。医療エージェントは、メモリシステムが正しく構築されていれば、永続的な患者状態を持つことができます。
永続的なワークスペースがある場所であればどこでも、エージェントのための長期的な意図を得ることができます。そしてそれは本当にLLMが賢くなるのを待つことの関数ではありません。メモリアーキテクチャがそこにあるため、LLMはプロジェクトの長期的な履歴や、金融について言及したような長期的なリスク要因、または長期的な機会要因を理解できます。
まとめ
これらすべてをまとめると、私が指摘したいのは、これを主要なモデル作成者たち、実際にエージェントを構築している私、プロダクションシステムでエージェントを構築している他の人々が集合的にまとめた実践知識、学んだ教訓として考えてほしいということです。これは、メモリを構築することについて私たちが知っている最良のものを表しています。そしてメモリを正しく構築することは極めて重要です。
プロダクションで大規模に機能するエージェントが必要な場合、だからこそ私はエージェントのコンテキストエンジニアリングについて本当に深く掘り下げたかったのです。ここに代替手段はないと思います。魔法の弾丸はありません。掘り下げて、メモリとコンテキストエンジニアリングが実際にどのように機能するかを理解する必要があります。
Substackでこれについてはるかに長い記事を書きました。ぜひ飛び込んでみることをお勧めします。エージェントを本当に機能させたいなら、これはスキップできないものです。幸運を祈ります。
コメント