はじめに
ChatGPTによって注目を集めたLLM（大規模言語モデル）は、2025年現在ではAIエージェントとしての活用が本格的に議論されるようになってきました。
なかでも、コーディングやソフトウェア開発のタスクを任せられるコーディングエージェントは、ITエンジニアの間で特に関心が高まっています。
AIエージェントをどのように扱うかの議論も盛んです。LLMに指示を与える技術としては、「プロンプトエンジニアリング」が知られています。これは指示書にあたるプロンプトを過不足なく記述し、最良の応答を引き出すテクニックです。しかし、コーディングエージェントのように複数ターンや複数タスクにまたがってLLMを動作させる場合には、単なるプロンプト設計だけでは不十分です。外部のコンテキストをLLMに渡し、出力を制御する設計が求められます。
外部のコンテキストとは、例えば外部ドキュメント検索を行うRAG（Retrieval-Augmented Generation）、過去の知識や決定事項を保持する長期記憶、セッション内状態や会話履歴である短期記憶、さらに応答フォーマットの制御などです。こうした外部コンテキスト全体を設計する手法は「コンテキストエンジニアリング」と呼ばれています。
そこで今回はコンテキストエンジニアリングの中の「長期記憶」にフォーカスし、コーディングエージェントがどのように長期記憶を扱っているかを紹介していきます。
対話を重ねるにつれて推論精度が低下する？──LLMが保持できる“記憶”の範囲
LLMでは、一度に処理できる情報量はコンテキストウィンドウ（Context Window）と呼ばれる入出力トークン数によって決まっています。モデルはこの範囲内にある情報を基に推論しますが、会話が長くなったりコードが大きくなると、古い情報から順に範囲外へ押し出されて、やがて忘れてしまいます。
ここで、コンテキストウィンドウが大きければ古い情報が押し出されないようにも思えます。しかし、どれほど大きくしても実際には情報の中抜けが発生してしまいます。この現象はLost in the Middleと呼ばれ、セッション内でLLMと対話を重ねるにつれて推論精度が徐々に低下し、あたかも記憶を失っていくかのような挙動を示します。
この理由について、LLMの動きをCPUに例えて考えてみましょう。コンテキストウィンドウは一時的な作業領域であるRAM（主記憶）に相当します。RAM上のデータが電源を切ると消えるように、コンテキストウィンドウの外に出た情報も忘れられてしまいます。
コンピューターでは永続的な記憶領域であるストレージにデータを保存して必要なときに取り出します。エージェントでも同じように、過去の知識や進捗を保持して、任意で取り出すことのできる長期記憶（Long-Term Memory／LTM）が必要になります。
つまり、コーディングエージェントにタスクを継続させるには、「人間なら覚えているだろう」と暗黙の了解に期待せず、「前回どこまで進めたか」「今どんな方針で動いているか」を毎回明示的に与える必要があります。この役割を担う「ストレージ」にあたるものが、まさに長期記憶です。
2種類のメモリー管理──Cursorの「インデックス化」、Claude Codeの「プレーンファイル」
この長期記憶を扱う戦略について、現在のコーディングエージェントでは大きく「インデックス化」「プレーンファイル」の2派に分かれます。この2択は、いわばエージェントの性格付けともいえます。
前者の「インデックス化」戦略を取るのがCursorやWindsurfです。コードベースやドキュメントをベクトルDBに埋め込み、意味的に近い断片を検索して呼び出す方式です。インデックス更新の手間がかかる反面、大規模なコードベースでも効率的に扱えるのが特徴です。
一方、Claude CodeやClineは「プレーンファイル」戦略を取っています。必要なときにローカルファイルをその都度読み込み、必要に応じてコーディングエージェント固有のルールファイルやメモリファイルに書き込み、再利用する仕組みです。
2つを比べると大規模なコードベースに対応する「インデックス化」がより良い戦略に見えますが、実際は必ずしもそうは言えない場合もあります。例えば戦略的に「プレーンファイル」戦略を取るClineの開発チームが書いたブログ「Why Cline Doesn't Index Your Codebase (And Why That's a Good Thing)」では、コードベースをインデックス化すべきでない理由を3つ挙げています。興味深い知見であるため紹介します。
まず1つ目は、インデックス化や埋め込みのためにコードをチャンク（分割）する際に生じる問題です。自然言語のテキストであれば、段落や文といった明確な区切りがあり、意味のまとまりごとに分割するのは比較的容易です。しかしソースコードの場合、チャンク化によってロジックが文字通り分断され、コード全体の意図や構造を理解しづらくなる可能性があります。
2つ目は、インデックスを常に最新の状態に保つことへの懸念です。ソフトウェア開発では、コードの一部を変更するだけでも、依存関係を含めて全体に影響が及びます。インデックスが古いままだと、既に存在しない関数やクラスなど最新の改善を反映していない情報に基づいて、エージェントが自信満々に誤った提案をしてしまう恐れがあります。そのため、ソフトウェア開発のコードベースでは常に最新のインデックスを維持する必要があり、維持するための核となるインデックス更新のパイプラインロジックは常に堅牢でなければなりません。
最後に、セキュリティ上の懸念です。インデックス化したコードベースと元のコードベースを二重で管理することは、攻撃対象が2つに増えるという意味でもあります。安全に利用するためにはエンタープライズレベルの高度なセキュリティを備えたパブリッククラウドや、厳重に管理されたセルフホスティング環境が求められますが、そもそも二重管理を行わなければ生じなかったリスクとも言えます。
