6月26日、platform.unoが「Maintaining working memory in AI agents」と題した記事を公開した。AIエージェントのワーキングメモリを6層のマークダウンスタックで管理し、信頼性を維持する実装アプローチについて詳しく紹介されている。
「100万トークン」は信頼できるメモリ量ではない
AIエージェントが最初のタスクをうまくこなしていたのに、しばらくするとステップを繰り返したり、最初に設定した制約を無視したりし始める。モデル自体は変わっていない。変わったのはワーキングメモリの状態だ。
言語モデルはリクエスト間で状態を保持しない。ある瞬間にモデルが「知っている」ことは、そのリクエストに渡されたテキストのみ——システムプロンプト、会話履歴、読み込んだファイル、ツールの出力——これらすべてがコンテキストウィンドウであり、そのリクエストにおけるモデルのワーキングメモリの全てである。
現在のモデルの多くは100万トークンのコンテキストウィンドウを提供しており、「何も削らずにすべてを渡せばいい」という発想は自然に見える。しかし、慎重に検証した研究チームが示した結果は厳しい。短い入力ではほぼ完璧な精度を示すモデルが、ウィンドウの深い部分に答えが埋まると、精度がコイントスに近い水準まで低下する。これは特に、答えを「探す」のではなく「推論して導き出す」必要があるタスクで顕著だ。
つまり、100万トークンはエージェントが「受け入れる」メモリ量であって、「集中して保持できる」量ではない。信頼性はこの2つ目の数字に依存する。
元記事の図によれば、信頼できる深さはおよそ2万8,000トークンと概算されており、リテラルな検索タスクから実際の推論タスクに移るにつれて、この「使えるゾーン」は急激に狭まると示されている。
大きなコンテキストウィンドウには依然として存在意義がある——長い履歴を吸収し、多段階タスクが途中で打ち切られるのを防ぎ、ツールの出力を収める余地を作る。ただし、それは同時に「歯止めの喪失」でもある。30万トークン分の文脈を抱えたエージェントは、静かに答えの質が劣化していく。
コンテキストウィンドウを構成する6つの層
エージェントのワーキングメモリを「清潔に保つ」には、まずそれが何で構成されているかを把握する必要がある。記事では、コンテキストウィンドウを6つの層に分けて整理するマークダウンスタック構造を提案している。各層はそれぞれ異なる更新頻度・重要度・保持戦略を持つ。
Layer 1: System Identity（システム同一性）
エージェントの役割・制約・動作原則を定義する最上位の不変層。原則としてセッション中は書き換えない。ここに記述された内容が後続のすべての層の解釈基盤となる。更新頻度は最も低く、変更するとしてもエージェントの根本的な再設計時のみだ。
Layer 2: Task Context（タスクコンテキスト）
現在のタスクの目標・スコープ・成功条件を記述する層。タスクが切り替わるたびに書き換えられる。「何を達成しようとしているか」をモデルが常に参照できる状態に保つことで、長い作業途中での目的喪失を防ぐ。
Layer 3: Working State（作業状態）
現在のステップ・進捗・中間成果物を記録する最も頻繁に更新される層。エージェントが「今どこにいるか」を追跡するための層であり、ループや繰り返しの原因になりやすい部分でもある。更新のたびに古い状態を上書きし、肥大化を防ぐ設計が推奨されている。
Layer 4: Reference Material（参照資料）
タスク遂行に必要な外部ドキュメント・コード・データを格納する層。RAG（Retrieval-Augmented Generation）で動的に取得したコンテンツもここに入る。この層は「必要なものだけを絞り込む」ことが肝心で、関連性の低い資料を漫然と積み上げると、推論精度を直接圧迫する。
Layer 5: Conversation History（会話履歴）
ユーザーとのやり取りの記録。全履歴を保持するのではなく、サマリー圧縮や重要ターンの選択的保持が求められる層だ。古い詳細な発言を要約に置き換えることで、文脈の連続性を保ちつつトークン消費を抑制できる。
Layer 6: Tool Outputs（ツール出力）
API呼び出し・コード実行・検索結果などのツール出力を収める層。この層はタスクの種類によっては急速に膨張する。元記事では、ツール出力の結果だけを残して生の出力を削る、あるいは複数の出力を統合サマリーに置き換えるといった戦略が紹介されている。
マークダウンスタックとしての実装
記事が提案する実装の要点は、これら6層を単一のマークダウン文書として構造化し、システムプロンプトに埋め込むことだ。各層を見出しで区切ることで、エージェント自身がどの層を読んでいるかを意識しやすくなるとともに、外部ロジックからの層単位の更新・削除が容易になる。
更新の基本方針は「全体を再生成するのではなく、変化した層だけを差し替える」こと。これにより、更新コストを抑えながらコンテキストの鮮度を保つことができる。各層のサイズ上限をトークン数で管理し、超過したら圧縮・要約を実行するというルールベースの制御も、記事内で具体的に示されている。
なぜ今このテーマか
AIエージェントの実用化が進む中で、「長期タスクの安定性」は実装上の最重要課題のひとつになっている。RAGやツール呼び出しを組み合わせた複雑なエージェントでは、コンテキストの肥大化は避けがたく、放置すれば静かに品質が劣化する。「なぜ急に動きがおかしくなったのか」が診断しにくいのも、この問題の厄介な点だ。
単に「大きなコンテキストを渡せば解決する」という直感に反する知見を、実測データと具体的な実装構造で示している点が、本記事の実践的な価値である。
詳細はMaintaining working memory in AI agentsを参照していただきたい。
