Zenn
📝

roo-logger: Cline Memory Bankとは違うAIの記憶システムを（MCPで）作った理由

に公開
20
AI
Model Context Protocol
Cline
Roo Code
tech

roo-loggerというMCPサーバーを作ったので紹介します。これはCline Memory Bankとは違ったアプローチでAIの記憶を管理するツールです。

最近、AIとの協業どころかvibe codingで全て書かせてしまおうなんて話もある中で、「AIが何をしたか覚えていない問題」が顕在化してきました。特にRoo Codeのような自律型エージェントが大量のファイル操作やコマンド実行をする場合、同じセッションを使い続けることはコンテキスト長的に不可能です。

そして、Memory Bankはプロジェクトの知識を構造化するのに素晴らしいシステムですが、長引くにつれコンテキスト長を制御しづらくなるのと、「AIがどうして何をしたのか」の詳細な記録には向いていないと課題を感じていました。また、プロンプトで作り込むには仕組みが重たすぎるという気持ちも少なからずありました。

かといって備えなしにいきなりコードを書かせるのもまた問題があります。セッションが違えばAIが一貫した方向性で編集してくれるかは運試しになりやすく（特にRoo-Codeのboomerang task機能を使う時など）、大抵の場合（vibe codingの元来の意図には反して）AIの行動に細かくフィードバックを与えたりする（それを覚えて・思い出していてほしい）ので、行動単位の記録が必要だなと考えました。

そこでMemory Bankとは異なるアプローチを考え、AIの行動履歴に特化したroo-loggerを開発しました。

Memory Bankの限界とroo-loggerの誕生

Memory Bankをしばらく使ってみて気づいた課題をまとめてみます：

課題 詳細
行動の細かい履歴には向いていない 「ファイル X の Y 行目を編集した」みたいな操作履歴を残すのは難しい
更新が手動または明示的 AI の活動はリアルタイムに記録されない
階層的な関係性を表現しにくい 「タスク A のサブタスク B」という親子関係を表現する仕組みがない
Markdown は人間向けの形式 人間が読みやすいけど、AI が検索するには構造化が足りない

これらの課題を解決するために、AIの行動履歴に特化したロガーを作ることにしました。JSON形式で構造化し、AIから直接呼び出せるMCPサーバーとして実装することで、AIが自分の活動履歴を自動的に記録し、後から検索できるようにしています。

roo-logger の基本設計

roo-loggerの基本設計は、「何をしたか」「なぜそうしたのか」「どう関連しているのか」を構造化して記録することです。ログはこんな感じのJSON形式で保存されます：

{
  "id": "75add15d-8d5b-4e60-b327-fde785050c86",
  "timestamp": "2025-04-10T01:58:02.905Z",
  "type": "file_operation",
  "level": "info",
  "summary": "README.mdにmermaid図を挿入完了",
  "details": {
    "file": "README.md",
    "operation": "insert_content",
    "insertedLines": "mermaidコードブロック",
    "position": "概要セクション直後"
  },
  "intention": "アクティビティの保存と呼び出しの流れを視覚的に説明するため",
  "context": "Roo Activity Loggerの利用者理解促進のためのドキュメント改善作業",
  "parentId": "98280366-1de1-48e0-9914-b3a3409599b4"
}

特に重要なフィールドは以下の通りです：

  • type: 活動の種類（command_execution, code_generation, file_operation等）
  • intention: なぜその活動を行ったのか
  • context: どのような状況でその活動を行ったのか
  • parentId: 親タスクのID（階層関係を表現）

これらの情報があれば、AIは「自分が何をしたのか、なぜそうしたのか」を後から正確に思い出せるわけです。意図（intention）と文脈（context）を必須にしているのがミソです。

なぜ MCP というアプローチを選んだのか

「なぜプロンプトではなくMCPサーバーとして実装したのか？」という疑問があるかもしれません。これには明確な理由があります。

  1. 構造化した出力を強制したかった
    • Structured Outputsのように、JSONスキーマに従った応答を確実に得たかった
    • AIが自由に書くと、ログの形式が不統一になり検索性が落ちる
  2. AIから直接呼び出せる必要があった
    • Memory Bankはファイルとして存在し、AIがそれを「読む」
    • 対照的に、roo-loggerはAIから「呼び出される」関数として存在する
    • この違いにより、AIは自分で記録・検索のタイミングを制御できる
  3. 標準化されたインターフェースが欲しかった
    • MCPはAIモデルと外部ツールをつなぐ標準プロトコル
    • 一度MCPとして実装すれば、Roo Code以外のAIツールでも利用可能になる

MCPを選んだことで、AIによる記録が一貫した形式で行われ、検索性の高いログデータが自動的に蓄積されていく。「AIに構造化された日記をつけさせる」ようなイメージでしょうか。

Memory Bank と Roo Logger の比較

両者の違いを明確にするために、特徴を表にまとめてみました。

（Memory Bankはプロンプトの調整次第な部分もありますが、参考程度に）

特徴 roo-logger Memory Bank
記録対象 AI の「行動履歴」 プロジェクトの「知識」
記録形式 JSON (機械可読) Markdown (人間可読)
更新タイミング 活動ごとリアルタイム セッション終了時/手動
主な目的 AI の行動を追跡 プロジェクト知識を構造化
ファイル構造 日付ベースの自動生成 決められた 6 つの主要ファイル
呼び出し方法 MCP ツールとして直接 ファイル読み込みとして間接的
人間の関与 最小限（AI が自動記録） 大きい（人間も編集する）
適した保存内容 「〜をした」行動記録 「〜である」知識記録

私は両者を「実験ノート」と「教科書」の関係だと思っています。両方あれば、AIはプロジェクトについての知識と、自分がこれまでに行った実験（操作）の両方を思い出せます。

セットアップ方法

roo-loggerのセットアップは非常に簡単です。Roo Codeの設定ファイルに以下を追加するだけです：

{
  "mcpServers": {
    "roo-activity-logger": {
      "command": "npx",
      "args": ["-y", "github:annenpolka/roo-logger"],
      "env": {},
      "disabled": false
    }
  }
}

Roo Codeでは、.roo/mcp.jsonファイルに上記の設定を追加します。

AI への指示方法（プロンプト例）

（いずれの例もコーディングに使うツールやモデルによって効き具合は変わってくるので、ご留意ください）

roo-logger 単体で使う場合のプロンプト例

roo-loggerを単体で使う場合は、以下のようなプロンプトがおすすめです。

## 活動記録に関する重要なルール

あなたは全ての重要な活動を記録するためにroo-activity-loggerのlog_activityを使用して`logs/`に記録してください。

### ログ記録のポイント

1. 以下の活動は必ず記録してください：
   - コマンド実行（command_execution）
   - コード生成（code_generation）
   - ファイル操作（file_operation）
   - エラー遭遇（error_encountered）
   - 重要な判断（decision_made）
   - 重要な会話（conversation）

2. 各活動記録には必ず以下の情報を含めてください：
   - 概要（何を行ったか）
   - 意図（なぜそれを行ったか）
   - 文脈（どのような状況でそれを行ったか）

3. タスクの階層構造を表現するために：
   - 大きなタスクを開始する際は、新しいログエントリを作成
   - サブタスクを実行する際は、親タスクのIDをparentIdとして設定

### セッション開始時

新しいセッションを開始する際は必ず以下を実行してください：

1. search_logsを使用して最近の活動履歴を取得
2. 前回のセッションでの作業内容を確認
3. 未完了のタスクがあれば、その続きから作業を開始

Memory Bank との併用パターン

両方のシステムを併用する場合は、以下のようなプロンプトをお試しください。（あまり試せていませんが…）

あなたはプロジェクト作業を進める際に、以下の 2 つの記憶システムを活用してください：

1. Memory Bank (知識の管理)

   - memory-bank/フォルダ内の Markdown ファイルを読んでプロジェクト知識を理解する
   - 重要な決定や知識を獲得したら、適切なファイルを更新する
   - 特に作業開始時は必ず Memory Bank の内容を確認する

2. roo-logger (行動履歴の記録)
   - すべての重要な操作（コード生成、ファイル操作、コマンド実行など）を log_activity で記録する
   - 必ず「intention」と「context」を含める
   - タスクが複数の小タスクに分かれる場合は、親子関係を parentId で表現する
   - 作業再開時には、search_logs で過去のログを検索して前回の状態を思い出す

これらの記憶システムは相補的な関係にあります。Memory Bank でプロジェクトの「大きな地図」を理解し、roo-logger で「具体的な作業履歴」を管理してください。

MCP ツールの詳細

roo-loggerは主に3つのMCPツールを提供しています。それぞれの使い方と用途を解説します。

1. log_activity - 記憶を保存

AIが活動を記録するためのツール。以下のパラメータを受け取ります：

パラメータ 必須 説明
type ✅ 活動の種類（command_execution, code_generation, file_operation, error_encountered, decision_made, conversation）
summary ✅ 活動の概要
intention ✅ なぜその活動を行ったか
context ✅ どのような状況でその活動を行ったか
logsDir ✅ ログの保存先（絶対パス）
level ❌ ログレベル（debug, info, warn, error）。デフォルト: info
details ❌ 活動の詳細（任意の JSON オブジェクト）
parentId ❌ 親タスク ID（階層関係用）
sequence ❌ シーケンス番号（順序関係用）
relatedIds ❌ 関連タスク ID 配列（関連性表現用）

2. search_logs - 記憶を検索

AIが過去の活動を検索するためのツール。以下のパラメータで検索が可能です：

パラメータ 説明
logsDir 必須: ログディレクトリ（絶対パス）
type 活動タイプでフィルタリング
level ログレベルでフィルタリング
startDate / endDate 日付範囲でフィルタリング（YYYY-MM-DD 形式）
searchText テキスト検索
parentId 親タスク ID で関連するサブタスクを検索
relatedId / relatedIds 関連タスクで検索
limit 取得する最大ログ数（デフォルト: 50）
offset スキップするログ数（デフォルト: 0）

3. get_log_files - ログファイル一覧取得

ログディレクトリ内のファイル一覧を取得するためのシンプルなツール。

実践パターン

roo-loggerの実践的な使い方として、特に効果的なパターンを紹介します。

階層的なタスク管理

Roo Codeは複雑なタスクを複数のサブタスクに分解するのが得意です。roo-loggerを使うと、こうした階層構造も記録できます。

Roo Codeの「Boomerang Task」機能（タスクを複数のサブタスクに分解して処理する機能）と組み合わせると、各サブタスクがどのように親タスクに関連しているかを明確に記録でき、後から辿りやすくなります。

例えば、「ユーザー認証機能の実装」というタスクを以下のようなサブタスクに分解した場合：

  1. ログインフォームのコンポーネント作成
  2. 認証APIとの連携実装
  3. 状態管理の実装
  4. テストコードの作成

これらの関係性を階層的に記録しておくことで、後から「なぜこのコードが生成されたのか」「どのタスクの一部だったのか」を追跡できます。

セッション間の継続性確保

AIは通常、セッションが終わると文脈がリセットされます。しかし、roo-loggerのログは永続的なので、次のセッションでもAIが前回の作業を思い出せます。

セッション開始時にAIへ前回の作業を思い出させるには、以下のようなパターンが効果的です：

  1. search_logsで最近の活動ログを取得
  2. 未完了のタスクがあれば、その続きから作業を再開
  3. 完了したタスクがあれば、次のタスクに進む

これにより、セッションをまたいでも一貫した作業が可能になります。

roo-logger を作って気づいたこと

このツールを作って実際に使ってみて、いくつか面白い発見がありました：

1. AIの記憶には二重構造が効果的かも

roo-logger単体で利用してもタスクの再開などスムーズになりますが、「知識」と「行動履歴」という2つの異なる記憶システムがあると、AIの作業能力が大きく向上するかもしれません。Memory Bankのような知識ベースと、roo-loggerのような行動履歴を組み合わせることで、AIはより人間らしい記憶機能を獲得する…かも。

これは人間の「宣言的記憶」（事実や概念の知識）と「エピソード記憶」（経験や出来事の記憶）に似ていると思いました。

2. 行動履歴の構造化が重要

単に「何をしたか」だけでなく「なぜそうしたのか」「どう関連しているのか」という情報が特に重要だとわかりました。意図や文脈、関連性の情報があることで、AIは過去の行動を単なるイベントリストではなく、意味のある「物語」として記憶できます。

3. AIの透明性向上

AIの判断や行動の理由が記録されることで、後からの検証や理解が容易になりました。これはAIの「説明可能性」を高める効果があります。特にチームで開発を行う場合、「AIがなぜその判断をしたのか」を追跡できることは重要になるはずです。

まとめ

roo-loggerは、Memory Bankを補完するためのAI記憶システムです。Memory Bankが「知識」を管理するのに対して、roo-loggerは「行動履歴」を記録します。

重要ポイント

  • AIが自分の行動と意図を構造化して記録できる
  • JSON形式で検索性が高い
  • 階層関係を表現できる
  • MCPプロトコルでAIから直接呼び出せる

両方のシステムを組み合わせることで、AIは「このプロジェクトは何か」と「今まで何をしてきたか」の両方を記憶でき、長期的なプロジェクトでも一貫した作業が可能になります。

AIとの協業が進む中で、こうした記憶システムの重要性はますます高まるでしょう。特に複数の人間とAIが関わる大きなプロジェクトでは、AIの行動履歴を追跡することが不可欠になってくると思います。

Memory Bankのファイル構造はこれでいいとして、行動履歴の部分はroo-loggerで補完する。そんなアプローチから試してみてほしいです。

https://github.com/annenpolka/roo-logger

GitHubで編集を提案
20

Discussion