Memory Bankで実現する効率的なAI協働の開発ガイド

AI 協働開発で直面した文脈維持の課題

Vibe Coding を始めて気づいた最大の問題点が、AI はタスクごとに記憶がリセットされるという厳しい制約だった。これは人間との協働において大きな障壁となる。

一般的なシステム開発では、エンジニアは長期間にわたって同じプロジェクトに取り組み、文脈や過去の決定事項を記憶している。しかし AI は違う。私はすぐに、AI が「今日配属されて今日お別れする優秀な新人」のようなものだと認識した。AI とのタスクは通常短時間で完了することが多く、その度に記憶がリセットされるため、短期間で出会いと別れを繰り返すような関係性になる。私の経験では、多くの場合 1 つのタスクは数十分程度で完了するため、ほぼ常に新しい協働者と仕事を始めるような感覚だった。

この問題に対処するため、最初に試みたのは非常に原始的な方法だった。AI が実装している間、私の手が空いているので、手動で議事録を取り続けるというアプローチだ。AI の横で 1 日中、議事録を記録し続けた。

これでタスクを跨いでも認識の齟齬が減ったが、皮肉なことに「AI に仕事を任せているのか、AI に仕事を任されているのか」わからなくなる状況に陥った。本来 AI に任せるはずの作業時間に、人間である私が議事録作成という単調な作業に縛られる本末転倒な状態だった。

先人のブログで見つけたのが、この問題を解決する Memory Bank という概念だった。

Memory Bank の基本概念：公式ガイドライン

Memory Bank とは、Cline（や Roo Code など）の公式カスタムインストラクションとして提供されている概念で、AI とのコンテキスト共有を効率化するアプローチである。特別なプラグインやツールではなく、構造化されたドキュメント管理の方法論だ。

公式が提供する Memory Bank の基本構造

Cline 公式のドキュメントによれば、Memory Bank はプロジェクトのルートディレクトリにmemory-bank/フォルダを作成し、その中に複数の Markdown ファイルを配置する構造となっている。

project-root/
└── memory-bank/
    ├── projectbrief.md      # プロジェクト概要と要件
    ├── productContext.md    # 製品の目的と問題解決
    ├── activeContext.md     # 現在の作業焦点と最近の変更
    ├── systemPatterns.md    # システムアーキテクチャとパターン
    ├── techContext.md       # 使用技術と制約
    └── progress.md          # 進捗状況と未解決の課題

各ファイルには明確な役割が定義されている

1. projectbrief.md：プロジェクトの基本情報を記録する基礎文書。要件、ゴール、制約などを定義する。

2. productContext.md：このプロジェクトが存在する理由、解決すべき問題、どのように機能すべきかを記述する。

3. activeContext.md：現在の作業焦点、最近の変更、次のステップ、アクティブな決定事項を記録する。

4. systemPatterns.md：システムアーキテクチャ、主要な技術的決定、採用しているデザインパターン、コンポーネント間の関係を記述する。

5. techContext.md：使用している技術、開発環境のセットアップ、技術的制約、依存関係などを記録する。

6. progress.md：何が完了し、何が残っているか、現在の状態、既知の問題点を記録する。

基本的な AI 協働フロー

私は Memory Bank を活用した開発フローを以下のよう設定している。特に Plan (Architect) と Act (Code) のタイミングで分割しているのが注目してほしい点である。

このフローにおいて最も重要なのは、各タスクの開始時に AI が Memory Bank を必ず読み込むという点だ。これにより、タスクごとにリセットされる AI の記憶を補完し、プロジェクトの文脈を維持できる。

Memory Bank の更新は主に 2 つのタイミングで行われる：

1. 計画段階（タスク開始後）：現在の状況と計画を記録
2. 実装後（タスク完了時）：実施内容、結果、学びを記録

これらの更新を通じて、Memory Bank はプロジェクトの知識リポジトリとして成長していく。

私の経験：手動議事録から Memory Bank への進化

公式の Memory Bank 概念を理解した後、私は約 1 ヶ月間で 3 つのプロジェクトを通じてこの概念を実践し、カスタマイズした。その進化の過程を紹介する。

最初のプロジェクト：議事録との格闘

最初に取り組んだのは、投資判断を支援する AI システムの開発だった。このプロジェクトでは、ベイズ更新を応用した不確実性のモデリングなど複雑なアルゴリズムを実装していた。

Memory Bank の概念を知る前だったため、完全に手動での議事録管理を行っていた。その際に直面した主な問題は

1. 説明の繰り返しによる時間の浪費：ベイズ更新のアルゴリズムなど、同じ説明を何度も繰り返す必要があった
2. 途中経過の消失：ひとつのタスクに複数のセッションを要する場合、中間状態が失われがちだった
3. 議事録作成という新たな負担：AI の作業中、私は議事録作成という本来不要なはずの作業に時間を費やしていた

「AI を使って効率化する」という当初の目的に対して、AI に働かせているつもりが、逆に AI に働かされているというジレンマを感じていた。

2 つ目のプロジェクト：Memory Bank の導入

2 つ目のプロジェクトでは、AI による評価システムを開発していた。ここで初めて公式の Memory Bank 構造を導入し、基本的な枠組みに沿って運用を開始した。

主な改善点

1. 初期設定の自動化：プロジェクトの基本情報を一度記録すれば、毎回説明し直す必要がなくなった
2. 作業文脈の継続性：あるタスクの途中経過が次のセッションに自然に引き継がれるようになった
3. AI 側の理解度向上：体系的に情報が整理されることで、AI の理解も深まった

しかし、基本的な枠組みだけでは対応しきれない課題も見えてきた

1. 情報量の増大：プロジェクトが進むにつれ、Memory Bank が肥大化していった
2. 抽象化の不足：個別の事実は記録されるが、プロジェクト全体の原則や教訓が抽出されにくい
3. 更新の煩雑さ：小さな更新でも全体を再書き込みする必要があり非効率だった

3 つ目のプロジェクト：カスタマイズと拡張

3 つ目のプロジェクト（本ブログサイト）で、私は公式の Memory Bank 構造をベースにしつつも、前の 2 つのプロジェクトでの経験を踏まえた重要な拡張を行った。ここが私の Memory Bank カスタマイズの核心部分である。

私の Memory Bank カスタマイズと革新

これからの部分が、公式の Memory Bank と私が実践の中でカスタマイズした部分の違いである。公式の枠組みは素晴らしい基盤を提供してくれるが、実際の運用では様々な課題に直面する。それらを解決するために以下の拡張を行った。

拡張ファイルの追加：知識の構造化と抽象化のために

私は公式の 6 つのコアファイルに加えて、以下の 3 つの拡張ファイルを追加した

1. userFeedback.md：ユーザーの好み、インタラクションパターン、マイクロフィードバックの履歴を記録する。これにより、ユーザー中心の開発が強化される。

2. metaLearning.md：自己反省、推論プロセス、失敗からの学びを記録する。これはプロジェクトを超えた学習を促進するために特に重要だ。

3. principleHierarchy.md：特定の指示から抽出された抽象的な原則を記録する。これにより、AI の判断基準がより一貫したものになる。

これらの拡張ファイルの追加により、Memory Bank は単なるプロジェクト情報の記録場所から、学習と知識の構造化プラットフォームへと進化した。特に重要なのは、metaLearning.md による反省と学びの蓄積である。

階層的情報構造：情報間の関係性を明示

私は公式構造をベースにしつつ、以下のような階層的な情報構造を導入した

この階層構造により、情報の流れと抽象化のプロセスが明確になる

1. 基盤層：projectbrief.md が最も基本的な情報を提供
2. 文脈層：productContext.md, systemPatterns.md, techContext.md が具体的な背景情報を提供
3. 活動層：activeContext.md, progress.md が現在の状態と進行を記録
4. 学習層：userFeedback.md, metaLearning.md, principleHierarchy.md が経験からの学びを抽象化

この階層構造により、AI はプロジェクトの文脈をより体系的に理解できるようになった。

差分ベース更新機能の導入：効率的な情報管理

公式の Memory Bank 運用では各ファイルの全体を更新する方法を基本としているが、プロジェクトが大きくなるとこれは非効率になる。私は Custom Instruction に以下のような差分ベース更新の指示を含めた。

- **update memory bank** - Add new information to the Memory Bank
  - I MUST use diff-based updates (apply_diff) instead of rewriting entire files
  - I MUST ONLY append new information to the relevant sections with date headers
  - I MUST ALWAYS keep all existing content unchanged
  - I MUST add clearly marked dated entries to appropriate sections
  - Example: Adding a new "2025/03/17 - Feature Implementation" entry under "## Recent Changes"

この指示により、AI は既存の情報を保持したまま、新しい情報だけを追加するようになった。これはトークン消費の大幅な削減にもつながり、より効率的な運用を可能にした。

自動圧縮プロセスの追加：情報の肥大化を防ぐ

Memory Bank の運用を続けていくと、情報が肥大化し、AI が一度に処理できる限界を超えてしまう問題に直面した。これに対処するため、定期的な圧縮プロセスを導入した

- **compress memory bank** - Reorganize and condense Memory Bank information
  - I will review all files and consolidate redundant information
  - I will summarize older entries while keeping recent details
  - I will restructure content to be more concise while preserving key information

この圧縮プロセスにより、特に activeContext.md や progress.md といった更新頻度の高いファイルの肥大化を防ぎ、本質的な情報を維持しながらトークン消費を抑えることができた。

Memory Bank の効果的な運用テクニック

私の 3 つのプロジェクトを通じた実践から得られた、Memory Bank を効果的に運用するための具体的なテクニックを紹介する。

日付ベースの情報構造化：時間軸での整理

Memory Bank の情報は、日付を基準に整理することで時間的な文脈が明確になる

## 実装の進捗
 
### 2025/03/15 - ユーザー認証機能
 
認証機能の基本実装を完了。JWT 認証方式を採用。
 
### 2025/03/16 - プロフィール編集機能
 
ユーザーが自分のプロフィールを編集できる機能を実装。

この日付ベースの構造により、プロジェクトの進展が時系列で把握しやすくなる。特に最新の情報が一目で分かるため、AI がコンテキストを素早く理解できる。

決定事項と未解決事項の明確な区別：状態の透明化

プロジェクトの状態を明確に把握するためには、決定済みの事項と未解決の課題を区別することが重要だ

## 決定済み事項
 
- データベース：PostgreSQL
- 認証方式：JWT
- デプロイ：Vercel
 
## 未解決の課題
 
- 画像処理のパフォーマンス最適化
- 多言語対応の方針
- 検索機能の実装アプローチ

この区分けにより、AI はプロジェクトの現在の状態を正確に把握し、未解決の問題に焦点を当てた提案をしやすくなる。

英語による記述：AI との相性を最適化

意外かもしれないが、日本語でコミュニケーションしていても、Memory Bank は英語で記述することを強く推奨する。これには複数の理由がある

1. AI モデルとの相性：多くの AI モデルは英語での処理が最適化されている
2. 技術用語の一貫性：多くの技術用語は英語であり、翻訳による不一致を避けられる
3. トークン効率：日本語は英語と比較してトークン消費が多い傾向にある

実際に私は Memory Bank を英語で記述し、AI とのコミュニケーションは日本語で行うというハイブリッドアプローチを採用した。その際、重要な日本語表現は括弧内に保存するという方法で情報の損失を防いでいる。

Memory Bank から学んだ広範な洞察：知識管理への示唆

Memory Bank の概念と実践から得られた洞察は、AI 協働開発に限定されない広い応用可能性を持っている。

日報・議事録の肥大化問題との対比

多くの組織では、日報や議事録が時間とともに肥大化し、誰も読まない文書の山を生み出してしまう問題がある。これらの文書は情報を蓄積するものの、その価値は時間とともに低下していく。

対照的に、Memory Bank は

1. 情報の抽象化と構造化に焦点を当てる
2. 古い情報を要約・圧縮し、本質的な洞察を保持する
3. 情報を階層的に整理し、必要なときに必要な情報にアクセスできるようにする

これらの特性により、Memory Bank は単なる記録媒体ではなく、知識の蒸留装置として機能する。日々の些細な出来事から本質的な洞察を抽出し、それを将来の判断や行動の指針として活用できるのだ。

チーム協働とナレッジマネジメントへの応用

Memory Bank の概念は、AI 協働だけでなく、人間同士の協働にも応用できる

1. チームの知識構造化：

   • 個々のメンバーの経験や洞察を構造化された形で蓄積
   • 暗黙知の明示知化を促進

2. オンボーディングの効率化：

   • 新メンバーがチームの文脈を効率的に理解するための基盤
   • 「なぜこの決定がなされたか」の理解を促進

3. ナレッジの継承：

   • メンバーの離任時に知識が失われるリスクを低減
   • チームの集合知を構造化された形で保存

これらの応用により、Memory Bank はチームの知的資産を保護し、発展させるための強力なツールとなる。

より広い文脈での情報管理への示唆

Memory Bank の概念は、さらに広い文脈での情報管理にも示唆を与える

1. 情報の重層的構造化：

   • 事実の記録だけでなく、その意味と関連性を捉える
   • 多層的な抽象化による本質の抽出

2. 知識の効率的な継承：

   • 経験から得られた暗黙知を構造化された形で継承
   • 「何を学んだか」だけでなく「なぜそう判断したか」を伝える

3. スケーラブルな知識管理：

   • 情報量の増大に対応する圧縮と抽象化のメカニズム
   • 重要度に応じた情報の差別化

これらの原則は、個人の知識管理から組織のナレッジマネジメントまで、様々なレベルで応用可能だ。

課題と今後の展望

Memory Bank 技術はまだ発展途上であり、解決すべき課題と今後の発展可能性がある。

現在の課題と制約

1. トークン消費の最適化：

   • Memory Bank が大きくなるとトークン消費が増大
   • 情報の優先順位付けと選択的な読み込みが必要

2. 情報検索の効率化：

   • 大量の情報からの関連情報抽出が難しい
   • セマンティック検索機能の統合が望ましい

3. 更新の自動化と品質確保：

   • 自動更新と人間によるレビューのバランス
   • 情報の正確性と関連性の維持

AI モデルの進化に合わせた発展

AI モデルは急速に進化しており、それに合わせて Memory Bank の設計も変化していくだろう

1. 長期記憶能力の向上：

   • AI の内部記憶能力が向上すれば、Memory Bank の役割も変化
   • より高レベルの抽象化と原則の記録へとシフト

2. マルチモーダル情報の統合：

   • テキストだけでなく、画像や図表などの複合的な情報管理
   • 視覚的なデザイン情報の効率的な伝達

3. 自己管理能力の向上：

   • AI による Memory Bank の自律的な管理
   • 情報の重要度判断と自動圧縮・構造化

AI の能力が向上するにつれて、Memory Bank の焦点は「情報の保存」から「情報の意味づけと構造化」にシフトしていくだろう。

マルチエージェント環境への発展

将来的には、単一の AI ではなく、複数の AI エージェントが協働する環境も増えていくだろう

1. 共有 Memory Bank：

   • 複数の AI エージェント間で共有される統一的な文脈
   • 各エージェントの視点と貢献の統合

2. 役割別アクセス制御：

   • エージェントの役割に応じた情報アクセスの最適化
   • 専門性に基づく情報フィルタリング

3. 協調学習と知識融合：

   • 各エージェントの学びを統合する仕組み
   • 集合知としての Memory Bank

まとめ：Memory Bank から得た本質的な教訓

Memory Bank の本質は、人間と AI の間の知識と文脈の共有基盤であると同時に、知識の構造化と抽象化のプラットフォームである。私の 3 つのプロジェクトを通じた実践から得られた主な教訓は以下の通りだ

1. タスクごとに記憶がリセットされる AI との協働には、効率的なオンボーディングが不可欠

   • 単なる情報共有ではなく、知識の構造化と優先順位付けが重要
   • AI とのコミュニケーションは「何を伝えるか」だけでなく「どう構造化するか」が鍵

2. 情報の蓄積だけでなく、抽象化と圧縮が価値を生む

   • 量よりも質と構造化が重要
   • ナレッジは単に保存するだけでなく、定期的に再構成することで価値が高まる

3. コンテキスト共有は人間チームにも応用可能な普遍的な課題

   • AI との協働から得た洞察は、人間同士のコミュニケーションにも活かせる
   • 「記録のための記録」ではなく「活用するための記録」という視点の転換

4. 静的な文書ではなく、生きたシステムとしての設計が重要

   • 一度作って終わりではなく、継続的に進化させる仕組み
   • 自己組織化と自己最適化の原則

Memory Bank はツールであると同時に、AI との協働における哲学でもある。それは単なる情報の保存場所ではなく、人間と AI の知的協働の基盤を構築するためのアプローチだ。

私が約 1 ヶ月間で 3 つのプロジェクトを通じて発見し、カスタマイズしてきたこの技術が、今後の AI 駆動開発において標準的なアプローチになることを期待している。そして、その恩恵はソフトウェア開発の領域を超えて、あらゆる知的協働の場面に広がっていくだろう。

実際に手を動かし、自分のプロジェクトに Memory Bank を導入してみることで、AI 協働の新たな可能性を体験できるはずだ。