🐕

ClaudeDesktopメモリ運用(インデックス活用術)

に公開
AI
Claude
tech

TL;DR

Claudeのメモリ機能を「詳細を全部記憶させる場所」ではなく「目次・インデックス」として使う運用方法を実装・検証した結果、以下の成果が得られた：

  • デフォルトメモリ（memory_user_edits）: いつ・何を参照するかの索引（最大30項目、1項目200文字）
  • メモリ機能（MCP）Knowledge Graph: 実際のルールや詳細情報を構造化保存（制限なし）
  • 検証結果: 索引機能・曖昧トリガー補完の両方が正常動作することを確認

注意: この記事で紹介する方法は、公式推奨の使用方法ではなく、筆者の独自の工夫です。

はじめに：メモリ機能の使い方の課題

Claudeには複数のメモリ機能があるが、それぞれに制約がある。

デフォルトメモリ（memory_user_edits）

Claude標準のメモリ管理機能。Claude DesktopとClaude.ai（Webインターフェース）の両方で利用可能。

制約:

  • 最大30項目
  • 1項目あたり200文字まで

特徴:

  • 会話開始時に毎回自動参照される
  • 明示的に指示しなくても適用される

メモリ機能（MCP）Knowledge Graph

Model Context Protocol (MCP) の公式メモリサーバーとして提供されるKnowledge Graph機能。

特徴:

  • Entity（エンティティ）、Relation（関係）、Observation（観察事実）の3要素で構成
  • 情報量の制限なし
  • 必要な時に検索・参照される

直面した課題

課題1: 200文字制限

詳細なルールを記載しようとすると、すぐに文字数制限に到達する。

❌ 200文字超過の例:
ファイル操作はfilesystemツール優先、PowerShellは複雑な処理のみ、bash_toolは禁止、
エラー時はファイル不存在なら作成提案、権限エラーなら対処提示、パス不正なら正しい形式を例示...

課題2: 30項目の壁

プロジェクトが増えるにつれ、記憶させたい項目も増える。新しいルールを追加するには、古いものを削除する必要がある。

課題3: 暗黙的なトリガー表現への対応

一般的な表現（「このファイルを編集して」「この内容をまとめて」など）に対して、特定のルールやスキルを適用させたい場合、明示的な指示が必要になる。

解決策：二層構造のメモリ設計

これらの課題に対し、デフォルトメモリを「インデックス」として使用し、メモリ機能（MCP）に詳細を格納する方法を実装した。

アーキテクチャ

┌───────────────────────────────────────────┐
│  デフォルトメモリ（索引層）               │
│  memory_user_edits                        │
│  「ファイル操作→Knowledge Graph参照」    │
│  （毎回自動参照される）                   │
└──────────┬────────────────────────────────┘
           │ 参照指示
           ↓
┌───────────────────────────────────────────┐
│  メモリ機能（MCP）Knowledge Graph（情報層）│
│  Entity「ファイル操作ルール」             │
│  - observation 1...                       │
│  - observation 2...                       │
│  （必要な時だけ参照）                     │
└───────────────────────────────────────────┘

Knowledge Graphの構造

Knowledge Graph MCPは以下の3要素で構成される：

Entity（エンティティ）

情報のノード。各エンティティは以下の属性を持つ：

  • name: エンティティの一意な名前
  • entityType: エンティティの種類（Person、Company、rule、guidelineなど）
  • observations: そのエンティティに関する事実の配列

Relation（関係）

エンティティ間の有向グラフの辺：

  • from: 関係の起点となるエンティティ名
  • to: 関係の終点となるエンティティ名
  • relationType: 関係の種類（"works at"、"refers to"など）
  • 重要: 常に能動態で記述する

Observation（観察/事実）

エンティティに紐づく個別の情報単位：

  • エンティティごとに複数保持可能
  • 時間と共に追加・削除可能
  • 1つのobservationには1つの情報単位を記載

公式推奨の使用方法との違い

公式推奨:
Knowledge Graphは主に以下のカテゴリの情報を保存することが推奨されている：

  1. Basic Identity（基本情報）: 年齢、性別、場所、職種、教育レベル
  2. Behaviors（行動）: 興味、習慣
  3. Preferences（好み）: コミュニケーションスタイル、言語
  4. Goals（目標）: 目的、願望
  5. Relationships（関係）: 個人的・職業的関係

本記事の方法:
上記に加えて、作業ルール、ガイドライン、スキル定義などのメタ情報もKnowledge Graphに格納し、デフォルトメモリから参照する構造を採用。これは公式推奨の使用方法を拡張した独自の工夫である。

実装例

デフォルトメモリの記載例

ファイル操作時はKnowledge Graph「ファイル操作ルール」参照
「まとめて」を含む依頼はKnowledge Graph「スキルトリガールール」参照
技術情報検索時はKnowledge Graph「技術情報検索マニュアル」参照

各項目は25〜60文字程度。200文字制限に余裕を持たせられる。

メモリ機能（MCP）の記載例

Entity: ファイル操作ルール
entityType: file-operation-rule

observations:
  - 基本原則: ファイル操作はfilesystemツール優先、複雑な処理はPowerShell使用
  - filesystemツール使い分け: 単一ファイル読み込みはread_text_file、複数はread_multiple_files
  - PowerShell専用コマンド: Show-TextFile（行番号付き表示）、Add-LinesToFile（行挿入）
  - bash_tool使用: ファイル操作では禁止、システムコマンドのみ許可
  - エラー処理_ファイル不存在: エラーメッセージ表示しファイル作成を提案
  - エラー処理_権限エラー: 内容明示し対処方法提示

文字数制限なし。詳細をすべて記載可能。

検証：機能が実際に動作するか確認

理論上は有効な設計だが、実際に動作するかを3段階で検証した。

検証1: デフォルトメモリによる索引機能

検証目的: デフォルトメモリに記載した索引が、Knowledge Graphへの参照として正しく機能するか

セットアップ

  1. Knowledge Graphに「検証用_テストルール」エンティティを作成
  2. デフォルトメモリに「検証テスト実施時はKnowledge Graph『検証用_テストルール』参照」を追加
  3. ユーザーが「検証テストを実施してください」と依頼

検証結果：✅ 成功

動作フロー:

  1. ユーザー：「検証テストを実施してください」
  2. Claudeがデフォルトメモリを自動参照
  3. 「検証テスト実施時は〜」という索引を発見
  4. Knowledge Graphから「検証用_テストルール」を検索・取得
  5. エンティティ内の推奨動作「検証用ルールが正しく参照されました」を実行

結論: デフォルトメモリを「目次」として、Knowledge Graphを「本文」として使い分ける設計が実際に機能することを確認。

検証2: 曖昧トリガーからスキル実行

検証目的: 曖昧な表現（「まとめて」）から、Knowledge Graphを経由して適切なスキルが実行されるか

セットアップ

  1. Knowledge Graphに「検証用_スキルトリガールール」エンティティを作成
    • 「『この内容をまとめて』→ knowledge-creationスキル使用すべき」を記載
  2. デフォルトメモリに「『まとめて』を含む依頼はKnowledge Graph『検証用_スキルトリガールール』参照」を追加
  3. ユーザーが「この検証結果をまとめて」と依頼

検証結果：✅ 成功

動作フロー:

  1. ユーザー：「この検証結果をまとめて」（曖昧な表現）
  2. Claudeがデフォルトメモリを自動参照
  3. 「『まとめて』を含む依頼は〜」という索引を発見
  4. Knowledge Graphから「検証用_スキルトリガールール」を取得
  5. 「『まとめて』→ knowledge-creationスキル」というマッピングを確認
  6. knowledge-creationスキルファイルを読み込み
  7. スキルのワークフローに従ってナレッジ作成を完了

結論: 明示的なトリガーフレーズがなくても、Knowledge Graphの情報を元に適切なスキルが実行されることを確認。

注意: knowledge-creationは筆者の独自スキルであり、Claude標準機能ではない。

検証3: トリガー記載方法の重要性

検証2の過程で、デフォルトメモリのトリガー記載方法が重要であることが判明した。

失敗パターン

❌ 曖昧な記載: 「ナレッジ作成・ドキュメント化時はKnowledge Graph参照」

この記載では動作しなかった。「〜時」という表現が、いつトリガーされるべきか不明確だったため。

成功パターン

✅ 具体的な記載: 「『まとめて』を含む依頼はKnowledge Graph参照」

具体的なキーワードを指定することで、正常に動作した。

推奨フォーマット

以下のいずれかの形式を推奨：

  1. キーワードベース: 「『X』を含む依頼はKnowledge Graph『Y』参照」
  2. 動作ベース: 「Z実施時はKnowledge Graph『Y』参照」
  3. 作業種別ベース: 「W作業時はKnowledge Graph『Y』参照」

いずれも判定条件が明確で、誤動作が少ない。

実装の工夫

工夫1: デフォルトメモリの「毎回参照」特性の活用

デフォルトメモリは会話開始時に毎回自動的に参照される。この特性を活用し、一般的な作業指示に対しても適切なKnowledge Graphへ誘導できる。

動作フロー

ユーザー: 「このファイルを編集して」
  ↓
Claude: デフォルトメモリを自動参照
  → 「ファイル操作時はKnowledge Graph『ファイル操作ルール』参照」を発見
  ↓
Claude: Knowledge Graphから詳細ルールを取得
  → filesystemツールを優先使用
  → エラー時の対処方法を確認
  ↓
Claude: ルールに従って作業を実行

明示的に「ファイル操作ルールを参照して」と指示しなくても、自動的にルールが適用される。

工夫2: 独自スキルとの連携

筆者の環境では、独自に作成したAgentSkills（knowledge-creation、technical-search-guideなど）を使用している。

これらのスキルには明示的なトリガーフレーズが定義されているが、実際の会話では様々な表現が使われる。

knowledge-creationスキルのトリガー例:

明示的: 「〜のナレッジを作成して」
暗黙的: 「この技術についてまとめておいて」「ドキュメント化して」

デフォルトメモリで広義のトリガーを定義

「まとめて」を含む依頼はKnowledge Graph「スキルトリガールール」参照

これにより、暗黙的な表現でも適切なスキルを実行できる。

注意: knowledge-creation、technical-search-guideは筆者の独自スキルであり、Claude標準機能やAnthropicが提供するものではない。

工夫3: 情報ソースの優先順位管理

技術情報を調べる際、ソースの優先順位を定義：

技術情報検索時はKnowledge Graph「技術情報検索マニュアル」参照

Knowledge Graphの内容：

Entity: 技術情報検索マニュアル
entityType: technical-search-guide

observations:
  - 検索優先順位_第1: Microsoft/Azure関連はmicrosoft-learn MCP使用
  - 検索優先順位_第2: AWS関連はaws-documentation MCP使用
  - 検索優先順位_第3: その他はweb_search使用
  - フォールバック: MCP失敗時はweb_searchにフォールバック

注意: technical-search-guideは筆者の独自スキルである。

運用結果

成果

1. 項目数制約からの解放

デフォルトメモリは現在12項目のみ使用。残り18項目の余裕がある。
メモリ機能（MCP）には100以上のobservationを保存しているが、問題なく動作。

2. メンテナンス性の向上

ルール変更時、Knowledge Graphの該当observationを更新するだけで反映される。

変更例:

変更前: 基本原則: ファイル操作はfilesystemツール優先
変更後: 基本原則: ファイル操作はPowerShell優先、シンプルな操作のみfilesystem

デフォルトメモリは変更不要。

3. 統一されたルール適用

検証により、一般的な表現でも適切なルールが自動適用されることを確認。スキルのトリガーフレーズを厳密に覚える必要が減る。

課題

課題1: アクセスコスト

Knowledge Graphへのアクセスは追加のツール呼び出しを伴うため、若干のレイテンシが発生する。

対応案: 頻繁に使う簡潔なルールは、デフォルトメモリに直接記載する判断もあり。

課題2: Knowledge Graphの肥大化

情報が増えすぎると管理が困難になる。

対応案: Entity間にRelationsを定義して構造化。定期的に不要なobservationを削除。

課題3: 参照整合性の維持

デフォルトメモリで参照しているEntityが削除されると、参照エラーになる。

対応案: Entity削除前に必ずデフォルトメモリの参照を確認。

実装のベストプラクティス

1. デフォルトメモリには「索引」のみ

✅ 良い例: 「ファイル操作時はKnowledge Graph『ファイル操作ルール』参照」
❌ 悪い例: 「ファイル操作はfilesystemツール優先、複雑な処理は...」

2. 統一されたフォーマット

すべての項目で同じ記載形式を使用：

[トリガー条件]はKnowledge Graph「[Entity名]」参照

3. 具体的なトリガー条件

✅ 良い例: 「『まとめて』を含む依頼は〜」
❌ 悪い例: 「ナレッジ作成時は〜」（いつトリガーされるか不明確）

4. 具体的なentityType

✅ 良い例: file-operation-rule
❌ 悪い例: rule（汎用的すぎる）

5. 1 observation = 1情報単位

✅ 良い例:
エラー処理_ファイル不存在: エラーメッセージ表示しファイル作成を提案
エラー処理_権限エラー: 内容明示し対処方法提示

❌ 悪い例:
エラー処理: ファイル不存在はエラーメッセージ表示し作成提案、権限エラーは対処提示...

まとめ

Claudeのメモリ機能を「インデックス」として使う方法により、以下を実現できた：

  1. ✅ 制約の回避: 30項目・200文字の制限から解放
  2. ✅ メンテナンス性向上: ルール変更が容易
  3. ✅ 自動適用: デフォルトメモリの「毎回参照」特性を活用
  4. ✅ 曖昧トリガー対応: 検証により動作を確認

重要なポイントは、「メモリに詳細を詰め込まない」こと。

  • デフォルトメモリ（memory_user_edits） = 「目次」
  • メモリ機能（MCP）Knowledge Graph = 「本文」

この役割分担により、柔軟で管理しやすいメモリ運用を実現できた。

検証により、この設計が実際に機能することを確認できたため、実用的な運用方法として推奨できる。

注意事項:

  • 本記事の方法は公式推奨ではなく、筆者の独自の工夫
  • knowledge-creation、technical-search-guideは筆者の独自スキル
  • トリガー条件は具体的に記載する必要がある

参考リンク

Discussion