各エージェントに見る「記憶の置き方」
それではプレーンファイル戦略とはどのようなものなのでしょうか。この戦略を採用する代表的なコーディングエージェントであるCline、Claude Code、Kiroの実装例を具体的に見ていきましょう。
Cline
Clineでは「長期記憶」を保持するため、「Memory Bank」という仕組みが推奨されています。Memory Bankは、ローカルディレクトリ./memory-bank/に配置されるMarkdownファイル群と、それらの扱い方を定義する./clinerules/配下のルールファイル群から構成されます。
./memory-bank/配下の基本的な構成例は以下の通りです。
your-project/ └─ memory-bank/ ├─ projectbrief.md # 1. 概要・全体像・ゴール ├─ productContext.md # 2. ビジネス価値・UX ├─ systemPatterns.md # 3. アーキテクチャと意思決定 ├─ techContext.md # 4. 技術スタックと制約 ├─ activeContext.md # 5. いま取り組んでいる作業 └─ progress.md # 6. 進捗・既知の課題
これらのファイルに対し、Clineが自動で編集や更新を試みます。実行タイミングは、プロンプト内で「新たなパターンの発見」「大きな変更の実施後」「文脈を明確にする必要がある場合」と定義されていますが、ユーザーが明示的に指示すれば任意のタイミングでの更新も可能です。
また、Memory Bankは単なるプレーンファイルで構成されているため、ユーザーが直接編集することもできます。そのため、何を覚えさせるか、何を忘れさせるかをユーザーが完全にコントロールできる点も特徴です。
ここまで見てきた通り、Memory Bank戦略はいわゆるプロンプトエンジニアリングであり、構成を柔軟に調整できます。例えば、現在の作業内容を扱う「activeContext.md」と、進捗や課題を扱う「progress.md」を一本化してシンプルなファイル管理を選ぶこともできます。逆に、より詳細に構造化するアプローチもあり、Cline Recursive Chain-of-Thought System (CRCT)と呼ばれる大規模向けの戦略が、GitHubで公開されています。
Claude Code
Claude Codeの戦略はシンプルで、単一の「CLAUDE.md」に進捗や方針を記録します。Claude Codeはこのファイルを自動で検出し、対話時に参照することで、どのセッションでも常に一貫した生成結果を得られます。
この戦略の特徴は、「CLAUDE.md」を配置する階層によってスコープが異なることです。
最も一般的なのは、リポジトリ直下に./CLAUDE.mdを配置してプロジェクトごとのメモリとして使う方法です。プロジェクト固有のアーキテクチャやコーディング標準、共通の開発ワークフローなどが、バージョン管理システムを通じて同期され、チーム全員が同じ基準で開発できます。
プロジェクトとは別に、個人設定を適用させたい場合は、別途ホームディレクトリ（~/.claude/CLAUDE.md）に置くことで、個人用の設定を反映させられます。
さらに、組織全体に共通する規約やポリシーを適用したい場合は、WindowsならC:\ProgramData\ClaudeCode\CLAUDE.mdなどのシステム領域に配置します。この「企業ポリシー」メモリをIT部門などが管理し、組織内の全ユーザーに適用させるといった運用もできます。
Kiro
Kiroは「Steering」と「Specs」という二層構造のプレーンファイル戦略で長期記憶を扱います。あらかじめプロジェクト内に恒常的な知識ファイルとして「Steering」とセッション単位の仕様ファイル「Spec」を置くことで、対話履歴に依存せず一貫したコード生成を実現します。
前者のSteeringディレクトリにはどのような役割があるのでしょうか。これはプロジェクト単位のナレッジを記録するためのMarkdownファイル群で、以下の構造をもちます。
your-project/
└─ .kiro/
└─ steering/
├─ product.md # 製品の目的・主要機能・ビジネス目標
├─ tech.md # 技術スタック・技術的制約
├─ structure.md # ファイル構成・命名規則・アーキテクチャ
Steeringディレクトリ配下のファイルは対話や生成時に常時読み込まれ、コード提案の一貫性を保ちます。Clineでいう.clinerules/、Claude CodeのCLAUDE.mdと同様の役割ですが、役割ごとにドキュメントが分かれているのが特徴です。
一方、Specsはセッション単位で新たに作成される仕様ドキュメント群です。プロンプトを具体的な要件・設計・実装計画へと落とし込み、体系的にドキュメント化する仕様駆動開発（Spec Driven Development）の考え方に基づいており、KiroではこれをSpecモードとして実現します。
具体的にどんな構造をしているか、見てみましょう。会話セッションごとに作成されたドキュメントは、以下のように格納され、長期記憶として管理されます。
your-project/
└─ .kiro/
└─ specs/
├─ session01/
│ ├─ requirements.md # ユーザーストーリー・受け入れ基準
│ ├─ design.md # 技術アーキテクチャ、シーケンス図、実装上の考慮事項
│ └─ tasks.md # 詳細な実装計画・タスクリスト
├─ session02/
│ ├─ requirements.md
……
