AIエージェントClineを進化させるMemory Bankの「忘れる」というアイデア
はじめに
Clineのcustom instructionsライブラリの中にMemory BankというAIエージェントの「記憶」を管理することを目指したものがある。これは昨今のAIが超えるべき課題を表しているなという風に感じているので思ったことを書いていく。
ざっくりとした前提
Clineとは
先人による説明記事がいっぱいあるのであまり書きませんが、AIエージェントが自律的にコーディング・デバッグ・設計といったタスクをこなしてくれるVSCodeの拡張機能。チャットの中で必要に応じてファイルを更新・コマンドを実行・ブラウザやMCPサーバーにアクセスしアクションを実行/情報を取得といったことを自律的に実行してくれる。
1つ1つのできることは以前から出来たことが多いと感じる。外部リファレンスを見るのはRAGやベクトル検索で出来たし、Cursorを始めとしてコード編集ツールもあった、外部リソースにアクセスするためのFunction Callingもあったしコード実行はなかったがまあそのくらい。
しかし、Clineの便利なところは「自律的に」これらを実行することだと感じる。必要なリファレンスを1つ1つ渡してAIにやってもらうというよりは、そこの取得も含め大きなタスクとしてやりたいことを丸っとお願いできるようになった感覚がある。
custom instructionsとは
Clineの会話において常に指定したプロンプトを渡せるというもの。中身のコードはあんまり見ていないが、システムプロンプトの次くらいに渡しているものと推測。
.clinerulesというファイルでも同様に共通的なルールを渡すことが出来るが、.clinerulesはワークスペース単位の指示でありcustom instructionsは拡張機能の設定として入れるためワークスペースを超えて共通のプロンプトを渡せる。
Clineが抱えている課題
Clineは自律的になんでもやってくれる！と大きなことを言ってしまったが、出来ないことも多い。特に複雑なデバッグタスクや大きいシステムの開発・保守・運用を実現するのはまだ難しいように感じる。もちろんAIなので指示に書いてないことは出来ないとかそういう前提もある。
複雑度の高いタスクが実現できない理由として、Clineは今までの会話を（おそらく）全てプロンプトに含める仕様のため、会話が長くなりすぎるとAI側のコンテキスト長の限界に到達してしまうということが原因となる。これは体感では特にデバッグ時に顕著であり、実行時のログやスタックトレースをコンテキストに持ってしまっているようで複数回コマンドを実行すると限界に到達してしまう。大規模なシステム開発においても必要とする前提情報が多すぎて同様にコンテキストの限界まで到達してしまう場合があるのではないか、と感じる。
このあたりは現在うまくプロンプトを書いて背景情報を渡してあげるとかそういった工夫が求められる世界であると感じている。
Memory Bankとは
Memory Bankは6つのMarkdownファイルを使って記憶を保持しようとする試み。Clineのリポジトリのcline-memory-bank.mdに詳細が記載されている。
AIエージェントClineは単一のタスクの間でしか記憶を保持できないため、ユーザーはワークスペースの目的や構造・システムアーキテクチャ・技術的な詳細・制約・現在進行中のタスクなどを都度説明する必要がある。（もちろん一部の内容は.clinerulesに記載する等によって都度書く必要はないのだが。）
これらの情報をMarkdownのファイルに記述することによってタスク間で保持させようというのだ。
LLMは利用可能なコンテキストサイズの上限の増加によって、より複雑で難易度の高いタスクを実現できるようになった。とはいえMemory Bankのような仕組みが増えることでAIエージェントがさらに複雑な課題を解消できるようになると考えている。例えば「膨大なコンテキストが必要な巨大システム」「難易度の高いデバッグが求められる複雑なタスク」といったもの。
Memory Bankによって難易度の高い大きなタスクをClineの複数の「タスク」に分割し、記憶を引き継がせながらタスクを処理させることで、大きなコンテキストがなくても大きなコンテキストを必要とするタスクを達成させよう、という試みに見える。
Memory Bankのアーキテクチャ。Memory Bankは6つのMarkdownから構成され、これらの管理はCline自身が実行するというのも興味深い点である。このMarkdownファイル群によってタスク間の記憶を保持し、複雑で難易度の高いタスクを実行できるようになることを目指しているのだ。
「忘れる」というアイデア
Memory Bankというものを使うことでClineはタスクをまたぐ際に自分の頭の中にあったことをすべて「忘れ」、Memory Bankを利用して必要なものだけ「取り戻す」ことでコンテキストの中でタスクを実行できるようになる、とも解釈できそうである。これはまさに人間がやっていることそのものと感じる。
人間が巨大なシステムを作る際にはまずは大きな単位で必要な機能や目的を整理し、そこから少しずつ細かい単位に分解しより詳細な設計実装に落とし込んでいく。詳細な機能の実装を作っている際には、別の機能がどう実装されているかを100%記憶している必要はない。小さなメモ書きに必要な情報だけが書き残してあればよい。これはまさにMemory Bankのアイデアそのものではないか。
大きなシステムを空間的に分割する手法（マイクロサービスアーキテクチャやクリーンアーキテクチャ等）や開発プロセスを時間的に分割する手法（ウォーターフォール開発における要件定義/基本設計/詳細設計等）も人間の理解を助けるのに非常に有用である。他マイクロサービスを呼び出す際には全ての実装を頭に入れる必要がなく、インターフェースのみを理解していれば良い。また実装の妥当性は前工程の設計がある程度担保してくれているため考えることを程度減らすことが出来る。
AIが扱えるコンテキストでは巨大なシステムを開発できる日は来ないのではないかと絶望していたが、このアイデアを使うことで開発ステップを「Clineのタスク」単位で区切り、それぞれのタスクの間をゆるやかにMemory Bankで接続することで実現できるのではないか、と希望が持てた。
ポエム：メモリに乗らない情報をさばくということ
「メモリに乗り切らない大きなデータをどう捌くのか」の先行事例で言うとデータベースを思い出す。メモリが高価だった時代に小さなメモリを使って、そのメモリの数十倍や数百倍のデータをいかに処理するのか、というのは昔のデータベースにおける大きな課題であったはずだ。（筆者がエンジニアになる前にその問題は解かれてしまったので、そのころを実際に知っているわけではないが。）
データベースにおける解決策はRedoやUndoといったログおよびDirty Pageなのであると理解している。つまり、 「メモリに乗り切らないデータを一時的にストレージに書き戻すことでメモリを節約しつつ大きなデータを処理する」 という考え方。
Memory Bankが取ろうとしているアプローチも 「コンテキストというメモリに乗り切らないデータをMarkdownという形でストレージに書き戻すことで保持する」 という考え方と解釈するとデータベースの取ったアプローチに比較的近いのではないだろうか。
ただ、データベースのとったアプローチとしては、データベースはインデックスを貼って高速にデータを取り出しやすくした一方で、Memory Bankはコンテキストの要点だけを書き戻すことで必要なデータのみを取捨選択しながら保持するという方向性をとっているように見える。これは先述の通りどちらかというと人間的なアプローチに近いように感じる。正確にデータを保持することが必要なデータベースと記憶をより抽象的に圧縮することが許されるClineの機能的な違いであるように感じており、ここは面白い。
人間の記憶も同じように、全ての情報を保持することはできない。そのため、必要な情報だけを取捨選択しながら保持するように「忘れる」「必要なことでも全てを記憶せず、必要な部分だけぼんやりと記憶する」ことが可能となっている。
タスクの中でも情報を忘れていくという機能はまだClineでは実現できない。Memory Bankもタスクをまたぐことによって記憶をリセットするという思想である。しかし、読み込んだファイルをすべて記憶しておいたりコマンド実行時のログを全て記憶しておくことことは必要ないわけで、実際にはタスクを完了させるためのコンテキストはもっとずっと小さな領域なのではないか。
Memory Bankもタスクの最中で不要な記憶を忘れていくというこの人間的なアプローチを取り込むことで、タスクをまたがなくてもコンテキストを節約しつつ大きなタスクが実現できるようになるのではないか？という未来への期待と共に本記事を締めくくろうと思う。
Discussion