AIエージェントに50ステップの複雑なDeFi戦略を実行させます。ステップ30になると、エージェントはステップ5で下した決定を突然「忘れ」、同じデータを再照会したり、さらに悪いことにステップ5の決定と矛盾し始めます。
これはバグではなく、LLMが劣化したわけでもありません。これはContext Window管理の問題です——Agentの作業メモリがいっぱいになると、何かを「忘れ」始めなければなりません。「何を忘れ、何を残すか」の戦略をどのように設計するかは、Agentシステムエンジニアリングで最も核心的な技術問題の一つです。
Context Windowは、LLMが1回の推論で「見る」ことができるすべてのテキストの上限で、トークンで測定されます。Claude Opusは200,000トークン、GPT-4oは128,000トークンです。大きく聞こえますが、長時間稼働するAgentにとって、この上限は予想より早く到達します。
なぜAgentのContextが急速に膨張するのでしょうか？稼働中のAgentのContextは通常以下を含むからです：System Prompt（戦略説明・ツール定義・セキュリティルール、通常2,000〜10,000トークン）；会話履歴（すべての過去ラウンドの入力と出力）；ツール呼び出し記録（各ツール呼び出しの入力パラメータ+完全なAPI返却）；現在のタスクの作業状態。
1時間ごとに推論を実行するDeFi戦略Agentで、各推論がContext約2,000トークンを追加すると仮定します。200時間後（9日未満）、累積Contextは400,000トークンに達し、ほとんどのモデルの上限を超えます。実際には問題はより早く現れます：Contextが60〜70%を超えると「針穴の中の針」問題が始まります——LLMはContextの中間の重要な情報を無視し始め、先頭と末尾にのみ注目します。
Contextの消費パターンを理解することで、問題を予測し事前に解決策を設計できます。Contextの主な消費源は4つあります：
ツール返却データの蓄積（最大のContext消費要因）：各ツール呼び出しの完全な返却がContextに入ります。DeFiプロトコルのAPIは通常大量の生データを返します——単一のAaveの全市場レート照会は15,000トークンのJSONを返す可能性があります。ツール関数のバックエンドコードで、データがContextに入る前にフィルタリングします。
会話履歴の線形増加：AgentのThought-Action-ObservationサイクルごとにレコードがContextに残ります。管理なしではContextは線形に増加します。
System Promptの隠れたコスト：System Promptはすべての推論でContextに完全に含まれます。10個のツールを説明するSystem Promptは8,000トークンを占める可能性があります。
エラーとリトライの記録：ツール呼び出しが失敗してリトライすると、失敗した呼び出しの記録もContextに残ります。
1つの戦略がすべてのシナリオを完全に解決するわけではありません——Agentのタスクタイプに応じて適切な組み合わせを選択してください：
戦略1：スライディングウィンドウ——最もシンプル、短いタスクAgentに適している
「直近N回の会話履歴を保持する」固定ルールを設定します。LangChainでは1行の設定（`memory = ConversationBufferWindowMemory(k=20)`）で実装できます。各タスクが比較的独立しているAgentに適しています。限界：Agentがステップ21でステップ1の決定を参照する必要がある場合、その重要な情報を「忘れます」。
戦略2：サマリー圧縮——最も柔軟、長いタスクAgentに適している
Contextが閾値（例：60%容量）に達したとき、別のLLM（より安価な小型モデルも可）に履歴レコードを要約・圧縮させます。数千トークンの詳細記録を数百トークンの要約に置き換えます。実装の複雑さ：中程度。
戦略3：外部メモリ（RAG）——長期メモリが必要なAgentに最適
すべての過去の操作記録をベクトルデータベース（Chroma・Pinecone・pgvector）に保存します。各推論前に、意味検索で「現在の決定に最も関連する過去の記録」を見つけ、完全な履歴ではなくこれらの関連記録だけをContextに入れます。外部メモリはAgentに「選択的な長期メモリ」を与えます。
戦略4：構造化状態管理——最も精確、複雑なマルチステップタスクに適している
Agentの作業状態を自由テキストの会話履歴に入れるのではなく、構造化されたJSONオブジェクトで現在の状態を維持し、毎回の推論にはこの状態オブジェクト（完全な履歴ではなく）だけを入れます。このアプローチではContextサイズがほぼ一定を保ちます。LangGraphの設計哲学はこれを中心に置いています。
ツール返却フィルタリング（最高優先度、即効性あり）：各ツール関数の返却値に「フィルター層」を追加し、LLM Contextに入る前にデータを削減します。これはAgentフレームワークを変更せずに実装でき、Context使用量を50〜80%削減できる最もコスト効率の良い最適化です。
Context監視とトリガー式圧縮：各推論前に現在のContextのトークン数を計算します（ほとんどのLLM SDKは`count_tokens()`関数を提供）。トークン数がモデル上限の60%を超えたとき、自動的に圧縮をトリガーします。
階層型Context設計：Contextを「永続層」（System Prompt）・「作業層」（固定サイズの構造化JSON）・「履歴層」（定期的に圧縮または削除）に分けます。異なる層に異なる圧縮ポリシーを適用します。
Context Window管理問題はAgentの開発初期にはほとんど現れません——テスト時はタスクが短くContextは上限に程遠いです。しかし本番環境にデプロイして24時間連続稼働させると問題が突然現れます：Agentが過去の決定と矛盾した判断を下し始め・System Promptで設定したルールを無視し始め・LLM APIが「Contextオーバー」エラーを返し始めます。
最も実用的なアドバイス：開発段階でContext監視を追加し（各推論のトークン数を記録）、問題が現れる前にContextの成長トレンドを確認できるようにします。最優先のContext最適化はツール返却フィルタリングです——最も低コストで最も顕著な効果があり、Context使用量を50〜80%削減できます。