なぜMemory Bankは時代遅れになってしまうのか
それはドキュメントであり、ドキュメントは風化する
Memory Bankを動かすカスタム指示ブロックは一人称で書かれており、文字通りに読む価値があります。「私はCline、セッション間でメモリが完全にリセットされるというユニークな特徴を持つ、専門のソフトウェアエンジニアです。これは制限ではありません。完璧なドキュメントを維持するための原動力です。リセットのたびに、私はプロジェクトを理解し、効果的に作業を継続するために、完全にMemory Bankに依存します。」
すべてはこの一文から始まります。Clineは「記憶」しているのではなく、「読んでいる」のです。もしファイルにプロジェクトがRESTを使用していると書かれており、あなたが3週間前にGraphQLに移行していたとしても、Clineは混乱しているわけではありません。間違っているファイルに対して、Clineは「正しく」従っているだけなのです。
6つのファイルのうち1つは、他よりもはるかに速く変化する
コア構造は、意図的な階層を持つ6つのファイルです。すべてのファイルの土台となる「基礎ドキュメント」としての projectbrief.md、その上に構築される productContext.md、systemPatterns.md、techContext.md、そしてそれらから情報を受け取る activeContext.md と progress.md です。
これら6つのファイルは、同じペースで古くなるわけではありません。projectbrief.md は1年間正しいままかもしれません。しかし、activeContext.md は「現在のフォーカス、最近の変更、次のステップ」をカバーしており、ドキュメントによると「最も頻繁に更新される」ファイルです。
この非対称性こそが、メンテナンスにおける最大の問題です。最も古くなりやすいファイルが、タスク開始時にClineが最も頼りにするファイルでもあるのです。なぜなら、それはあなたが昨日何をしていたかを記述しているファイルだからです。
更新は、誰かが実行することを覚えておかなければならないコマンドである
Clineは3つのコマンドを提供しています。構造を作成する「initialize memory bank」、 「ドキュメント全体のレビューと更新」をトリガーする「update memory bank」、そしてClineにバンクを読み込ませて中断したところから再開させる「follow your custom instructions」です。
ドキュメントでは、更新をトリガーすべき4つの条件を挙げています。「新しいプロジェクトパターンの発見」、「重要な変更の実装後」、「ユーザーが update memory bank を要求したとき（すべてのファイルをレビューしなければならない）」、そして「コンテキストの明確化が必要なとき」です。
これら4つのうち3つは、人間が気づくかどうかに依存しています。これは設計に対する批判ではありません（ドキュメント化の手法とはそういうものです）。しかし、どこに労力を注ぐべきかを教えてくれています。
人々が試みること（そして失敗すること）
一度初期化して、二度と触らない。 最も一般的なパターンであり、およそ2週間は機能します。その後、バンクはもはや存在しないバージョンのプロジェクトを記述するようになり、Clineはそれを自信満々に読み込むため、間違ったコンテキストはコンテキストがないことよりも悪影響を及ぼします。
何かが壊れたときにだけ「update memory bank」を実行する。 その頃には、更新は段階的なものではなく完全な書き直しになっており、完全な書き直しは先延ばしにされがちです。
すべてを activeContext.md に詰め込む。 最も頻繁に開かれるファイルであるため、アーキテクチャのメモ、技術スタックの決定、未解決の疑問などが蓄積され、最終的に現在のフォーカスの要約ではなくなってしまいます。階層構造は、まさにこれを防ぐために存在しています。
Memory Bankを自動圧縮（auto-compaction）の代わりに使う。 これらは異なるツールです。ドキュメントでも明確に区別が推奨されています。「日常的なコンテキスト管理はAuto Compactに任せ、手動の『update memory bank』は重要なチェックポイントのために予約しておくこともできます。」
適切なフォルダに .md ファイルがあれば十分だと仮定する。 Memory Bankを有効にするには、指示ブロックが必要です。.clinerules/memory-bank.md などの Cline Rules ファイル、またはグローバルなカスタム指示にコピーしてください。そうしないと、それらのファイルはただのファイルに過ぎず、エージェントが指示ファイルを無視する理由の典型例になってしまいます。
1台のマシンでセットアップし、チーム全員がそれを持っていると仮定する。 指示ブロックがリポジトリではなくグローバルなカスタム指示にある場合、同僚はMemory Bankをまったく持っていません。彼らにとっては、誰のエージェントも読み込むように指示されていないMarkdownファイルのフォルダがあるだけです。この症状は混乱を招きます。あなたがメンテナンスしているためバンクは維持されているように見えますが、他の誰にとっても機能していないように見えるからです。
次の人のためではなく、モデルのためにバンクを書く。 ファイルはリポジトリ内のプレーンなMarkdownであるため、コードレビューやオンボーディングの際に人間が読みます。簡潔なキーワードリストとして書かれたエントリーは、作成コストは低いですが、1ヶ月後にどちらの読者にとっても検証するのがはるかに難しくなります。
解決策：適切にセットアップし、風化しない「永続的な半分」の置き場所を作る
セットアップは3つのステップで構成されており、3番目のステップはほとんどのガイドが省略している部分です。
ステップ 1: 指示をインストールし、初期化する
ClineのドキュメントからMemory Bankのカスタム指示ブロックをコピーし、Cline Rulesファイル（ドキュメントの例では .clinerules/memory-bank.md）に貼り付け、Clineに「initialize memory bank」と依頼します。
場所は慎重に選んでください。ClineのFAQでは、これをトレードオフとして説明しています。「カスタム指示はすべてのプロジェクトにグローバルに適用されます。Cline Rulesファイルはプロジェクト固有でリポジトリに保存されるため、共同作業者と簡単に共有できます。」複数人で作業するプロジェクトでは、リポジトリ版が圧倒的に有利です。あなただけが持つグローバルな指示は、あなただけがメンテナンスするMemory Bankを生み出すことになるからです。
知っておく価値のある3つ目の選択肢もあります。条件付きルールを使用して「memory-bank/ ファイルを操作しているときのみMemory Bankの指示を有効にする」ことができます。常にオンになっているバージョンがコンテキストを圧迫している場合に便利です。
6つのファイルを手書きするのではなく、Clineに初期構造を作成させましょう。ドキュメントでは、基本的なプロジェクト概要（project brief）から始めて構造を進化させることが推奨されており、Clineは人間がテンプレートを埋めるよりも一貫して階層を構築してくれます。
ステップ 2: 6つのファイルを変化の速さで分け、そのリズムで更新する
誰が何をいつ更新するかを、一度書き留めておきましょう。機能するパターンの例：
projectbrief.mdとproductContext.md— セッションごとではなく、マイルストーンごとにレビューします。systemPatterns.mdとtechContext.md— アーキテクチャや依存関係の決定が実際に変更されたときに、その変更と同じコミットで更新します。activeContext.md— 各作業セッションの終わりに更新します。ドキュメントには明記されています。「最も頻繁に変更されます。各セッションの後に更新してください。」progress.md— 「マイルストーンを追跡する」ため、作業を再開するときにレビューします。
次に、ドキュメントに記載されているコンテキストウィンドウのワークフローを使用します。これはメンテナンスの儀式も兼ねています。コンテキストウィンドウがいっぱいになったら、Clineに「update memory bank」を依頼して現在の状態をドキュメント化し、新しい会話を開始して、Clineに「follow your custom instructions」と依頼します。この3つのアクションだけで、クリーンなウィンドウと最新のバンクが得られます。これはカレンダーのリマインダーよりもはるかに信頼性が高い方法です。
完全な更新に関する注意点として、「update memory bank」はClineが「すべてのファイルをレビューしなければならない（MUST review ALL files）」ことを意味します。これは徹底的ですが、無料ではありません。大きなバンクでは、かなりのトークンを消費します。これはチェックポイントのために予約しておき、日常的なトリミングはFAQの提案通りAuto Compactに任せましょう。
ステップ 3: リポジトリよりも長生きする事実は別の場所に保管する
ここにこの設計の限界があります。Memory Bankはプロジェクトディレクトリにスコープされ、コードベースを中心に形成されています。これは systemPatterns.md には適していますが、エージェントが必要とする他の多くのカテゴリの情報には適していません。
クライアントやドメインの仕様。触るすべてのリポジトリで共通する、作業の進め方に関する好み。結果よりもその理由が重要となる決定事項。異なるツールを使用しているチームメンバーと共有されるあらゆる情報。
これらはどれも、1つのリポジトリ内にある6つのMarkdownファイルに属すべきではありません。そこに無理に押し込むことが、Memory Bankを肥大化させ、同時に陳腐化させる原因になります。リポジトリ外のメモリレイヤーがプロジェクト横断的な半分を保持し、Memory Bankは本来得意なことに集中し続けます。MemoryLake は3つのステップでセットアップできます。
ステップ 1: APIキーを作成する
サインインし、ダッシュボードからAPIキーを生成します。これはリポジトリではなくあなたに紐づくため、新しいMemory Bankごとに再構築することなく、同じ知識をプロジェクト間で引き継ぐことができます。
ステップ 2: 最初のメモリをアップロードする
現在のフォーカスとは無関係なのに activeContext.md に貼り付けたくなっていたものから始めましょう。恒常的な好み、ドメイン用語集、クライアントの詳細、決定事項とその背後にある理由などです。次に、別のリポジトリですでに何度も説明し直した内容を追加します。
ステップ 3: AIとエージェントを接続する
Clineをストアに向けます。リポジトリ固有の半分はMemory Bankに残り、チームはプルリクエストでそれをレビューできます。永続的な半分は、新しいプロジェクトごとに再入力する必要がなくなります。
実践においてこれがもたらす変化
最初の変化は、activeContext.md が小さくなり、その結果として正確さが維持されることです。現在のフォーカスのみを保持するファイルであれば、セッションの終わりに30秒で正直に更新できます。一般的な知識のゴミ捨て場になってしまったファイルは、更新を避けるようになるでしょう。
2つ目は、新しいリポジトリの開始が白紙状態ではなくなることです。現在、新しいプロジェクトは中身が空の新しいMemory Bankを意味し、Clineがすでに2回学習した好みを再構築するために最初の1週間を費やすことになります。永続的な半分が外部に保存されていれば、新規に作成するのはプロジェクト固有のファイルだけになります。
3つ目は、別のツールを使っているチームメンバーが取り残されなくなることです。Memory BankはClineの慣習です。別のエージェントを使っている同僚は、それをメモリとして読み込むことはできず、単なるドキュメントとしてしか読めません。もしチームの半分が移行した場合（例えば、CursorからClineへの移行の後など）、共有レイヤーがあることで、双方が同じ事実に基づいて作業を継続できます。
Memory Bankを最新に保つためのベストプラクティス
- 複数人で作業するプロジェクトでは、指示ブロックをグローバル設定ではなくリポジトリに配置する。
- すべてのセッションの終わりに
activeContext.mdを更新する。 これはセッションごとのペースで更新される唯一のファイルであり、Clineが最も熱心に読み込むファイルです。 - アーキテクチャの更新は、アーキテクチャを変更するコミットと紐づける。
systemPatterns.mdの更新を、独立した雑用にしてはいけません。 - ウィンドウがいっぱいになったときの儀式を更新のトリガーにする。 更新、新しい会話、「follow your custom instructions」。すでにやっている作業に付随する、実質無料のメンテナンスです。
- 完全な「update memory bank」の実行はチェックポイントのために予約しておく。 すべてのファイルをレビューするため、日常的なコンテキスト管理はAuto Compactに任せましょう。
- トピックがそれに値する場合は、
memory-bank/の下にファイルを追加する。 ドキュメントでも、複雑な機能、統合仕様、テスト戦略などのためにファイルを追加することが認められています。1つのファイルを無限に肥大化させるのは避けましょう。 - プロジェクト横断的な知識は含めない。 次のリポジトリでも同様に真実である事実は、Memory Bankに置くべきではありません。
- 月に一度は自分自身でバンクを読む。 リポジトリ内のプレーンなMarkdownであることは最大の利点であり、人間が見れば古くなっていることが一目でわかります。AIが記憶している内容の監査は、隠されたストアと同様に、ここでも当てはまります。
結論
Memory Bankは、この分野において極めて誠実な設計の1つです。モデルが何かを覚えているとは主張せず、メモリはリセットされ、ドキュメントこそが生き残るものであるとしています。その誠実さこそが機能する理由であり、同時に風化する理由でもあります。ドキュメントの上に構築されたシステムは、ドキュメントの失敗パターンをそのまま引き継ぐのです。
リポジトリにセットアップし、6つのファイルを変化の速さで分け、すでにやっている作業に更新を紐づけ、そしてこのリポジトリよりも長生きする知識は、同じく長生きする別の場所に保管しましょう。