エージェントはなぜ会話が長くなるほど揺らぐのか：コンテキストと記憶の課題
先日、AMCPに関する記事を公開しました。
その記事を投稿してみて、実はその前に説明しておくべき話が一つありました。 それは、エージェントが実際にどのようにコンテキストを扱い、なぜ会話が長くなるほど揺らぎ始めるのかという点です。
最近、多くの方が「コンテキストウィンドウが100万トークンもあれば、事実上すべて記憶できるのでは？」と考えています。 しかし、実際にコーディングエージェントを長時間使ってみると、必ずしもそうではありません。
むしろセッションが長くなるほど、
- 突然重要な文脈を見失ったり
- さっきまで知っていた設定を再度聞いてきたり
- 直前までうまくできていた作業フローを失ったり
- 結局新しいセッションを開くことになったり
という経験を頻繁にすることになります。
なぜこのようなことが起きるのでしょうか？
1. 会話が長くなるほど送信する情報量が増え続ける
私たちが普段チャットのように質問をやり取りしているとしても、 モデルに実際に渡される情報量は想像以上に大きくなります。
例えば：
- 質問1をすると → 質問1が送信されます
- 質問2をすると → 質問1＋回答1＋質問2が送信されます
- 質問3をすると → 質問1＋回答1＋質問2＋回答2＋質問3が送信されます
このように会話が続くほど、 現在の質問だけでなくこれまでの会話全体が再び一緒に送信されます。
そのため、コンテキストウィンドウがどれだけ大きく見えても、途中で200行のエラーログが一つ入るだけで、実際に使える余裕は思ったより早く減っていきます。
重要なのは、コンテキストウィンドウが大きいということと、常に安定して必要な情報を保持できるということは同じ意味ではない、という点です。
2. コーディングエージェントのコンテキストは通常3層で構成される
実際、コーディングエージェントのコンテキストは大きく3つのレイヤーで考えることができます。
レイヤー1. モデル提供者が設定したシステムプロンプト
例えばClaude、OpenAI、Googleなどのモデル提供者が基本動作のために設定したシステムレベルの指示です。
ユーザーがこのレイヤーを直接制御することは困難です。
レイヤー2. ユーザーが重要だと考えて追加した持続的コンテキスト
例えば：
CLAUDE.mdAGENTS.md.cursorrules- チーム規則
- プロジェクト構造の説明
- 作業方式
このレイヤーは「この作業をどのように進めるべきか」を伝える重要な文脈です。
レイヤー3. 現在のセッションで蓄積された質問と回答
このレイヤーが最も急速に大きくなります。
- 質問
- 回答
- エラーログ
- 修正依頼
- 再質問
- ツール実行結果
こうした情報が絶えず蓄積されていきます。
3. 実際に制御できるのは2番と3番のレイヤー
問題はここから始まります。
ユーザーが実質的にコントロールできるのは：
- レイヤー2：持続的コンテキスト
- レイヤー3：セッション中の会話内容
しかし、モデルは長い入力を完全に均等に扱うわけではありません。 一般的に冒頭と末尾の影響が相対的に大きく、中間に挟まれた情報は弱くなりがちです。
そのため、次のような現象が起こります。
- 直前の質問にはうまく反応します
- しかし中間に含まれる
CLAUDE.md、AGENTS.md、.cursorrulesのような重要な指示は無視されやすくなります - さらに「さっきの環境変数名は何だったっけ？」のような単純な質問にも、その質問だけでなく上記3レイヤーが再びまとめて送信されます
つまり、些細な質問一つでも全体のコンテキストコストがかかることになります。
これが積み重なると最終的に：
- コンテキストが急速に埋まる
- 古い情報は切り捨てられたり強く圧縮されたりする
- 一部の情報は失われたまま再構成される
- モデルが徐々に意味不明な応答をし始める
- 結局新しいセッションを開くことになる
4. しかし新しいセッションを開くと記憶は途切れる
新しいセッションを開くと、通常一つの問題は解決します。
それはセッションが軽くなるという点です。
しかし同時に、より大きな問題が発生します。
前のセッションの重要な文脈が失われてしまうのです。
例えば：
- どの方向で実装することにしたのか
- どんな制約を設けたのか
- ユーザーが嫌がるやり方は何か
- 既に一度失敗したアプローチは何か
- このプロジェクトで重要なルールは何か
こうした情報は本来、次のセッションでも引き継がれるべきです。 しかし現状の多くのシステムでは、この情報がセッション終了とともに消えるか、特定製品の内部メモリに閉じ込められています。
5. だから必要なのは「会話」ではなく「記憶」
ここで区別すべきことがあります。
エージェントに必要なのは単なる長い会話記録ではありません。 本当に必要なのは、その会話から重要なものだけを抽出して残す記憶階層です。
例えば：
- ユーザーの好み
- プロジェクトのルール
- 重要な決定事項
- 失敗した試みと解決方法
- 次のセッションでも生きているべき作業文脈
こうしたものは全体の会話ログとは異なります。 むしろ全体ログから抽出された持続的価値のある情報に近いものです。
つまり、
- すべての会話を永遠に再送するのではなく
- 重要なものだけを構造化して保存し
- 次のセッションや他のエージェントが必要なときに再利用できる構造
が必要です。
6. Nexusはその記憶階層を作るために開発しました
私たちが開発したNexusは、まさにこの課題を解決するためのメモリインフラです。
ポイントは次の通りです。
- 重要な会話内容を構造化して保存し
- セッションが変わっても再利用でき
- さらにClaude CodeからCodexへ、または他のクライアントに移っても
- 必要な記憶を引き継げるようにする
つまりNexusは「今のチャット画面の中だけに閉じ込められているコンテキスト」を セッション外に取り出し、管理可能な記憶として扱う階層です。
7. そしてその保存と移動のための標準が必要だった
ここで自然に次の疑問が生まれます。
「ではこのメモリ保存方式も特定製品の中だけに閉じ込められたら、結局同じ問題では？」
その通りです。 だからこそ、メモリの保存と移動にも公開された標準が必要だと考えました。
その結果提案したのがAMCP（Agent Memory Continuity Protocol）です。
AMCPはエージェントメモリに関する最小限の共通契約を提示します。
- どのような形で保存するか
- どのようにリコールするか
- どのようなスコープを持つか
- 保持や削除をどう扱うか
- 他システムへのエクスポート／インポートをどうするか
この標準があれば、 記憶が特定のモデル会社や特定製品の中だけに閉じ込められず、 他の実装やランタイムにも移動できる可能性が生まれます。
8. まとめ
エージェントが揺らぐ理由は、単にモデルが賢くないからではありません。
問題は：
- 会話が長くなるほど毎回送る情報量が増え
- 重要な指示は長いコンテキストの中で埋もれやすく
- 新しいセッションを開くと過去の文脈が切れてしまうことです
だから必要なのは、より長いチャット画面ではなく、 重要なものを分離して保存し再利用できる記憶階層です。
そしてその記憶階層を特定製品依存ではなく公開された方式で扱うために、 NexusとAMCPを開発しています。
ご興味があれば、以下から続きもご覧いただけます。