OpenClaw メモリの説明: アーキテクチャ、セットアップ、メモリが忘れられる理由

完全な OpenClaw メモリ アーキテクチャ (3 層の説明)

OpenClaw メモリは、それぞれ異なる永続特性と障害モードを持つ 3 つの異なる層にわたって動作します。

メモリの完全なライフサイクル:

Write → Embed/Index → Search → Compact → Recover
  ↓          ↓           ↓         ↓         ↓
.md file   sqlite-vec  semantic  summary   MEMORY.md
created    indexes it  query     replaces  re-read at
           on save     returns   context   session start
                       chunks    window

このチェーンの各段階は独立して失敗する可能性があります。ほとんどの物忘れの問題は、まさに 1 つの壊れた段階にまで遡ります。

Layer 1 — アクティブ コンテキスト ウィンドウ

これはモデルの作業メモリです。アクティブな会話のコンテキスト ウィンドウに現在読み込まれているすべてのものです。これには、システム プロンプト、会話履歴、検索ツールによって取得されたメモリ チャンクが含まれます。

それを埋めるもの:

• システムプロンプト (多くの場合、大きい)
• 取り出した記憶の抜粋
• ツール呼び出し履歴
• 会話のターン

実際の制限: システム プロンプトとメモリ オーバーヘッドを除いた後、実際の会話に使用できるモデルのアドバタイズされたコンテキスト ウィンドウの約 60 ～ 70% があると仮定します。

Layer 2 — 毎日のメモ (ローリング 2 日ウィンドウ)

毎日のメモは、memory/ ディレクトリ内に保存される、YYYY-MM-DD 形式で名前が付けられた追加専用の Markdown ファイルです。 OpenClaw の読み込み 今日と昨日の 各セッションの開始時にファイルが自動的に作成されます。

• 今日の仕事、下された決定、およびアクティブなタスクに関する事実がここに追加されます
• これらは編集することを意図したものではありません。ログとして扱ってください。
• 2 日後、それらは自動読み込みウィンドウの範囲外となり、セマンティック検索経由でのみ検索可能になります。

レイヤ 3 — 耐久性のあるメモリ (MEMORY.md およびmemory-wiki)

複数のセッションにわたって存続する必要がある長期的な事実 (名前、プロジェクトのコンテキスト、コーディング設定、アーキテクチャ上の決定事項) は、MEMORY.md または構造化された memory-wiki プラグイン ボールトに属します。

圧縮の問題 — タスクの途中で指示が消える理由

圧縮は、OpenClaw で最も文書化されていない障害モードです。ほとんどの記事ではセッション後の物忘れについて取り上げています。住所がほとんどない 長時間実行される自律型ワークフローにおけるタスクの途中での圧縮 — エージェントが複数ステップのタスクを実行している場合、圧縮はステップ 7/12 でサイレントに起動され、ステップ 1 からの動作指示は失われます。

圧縮の内容:

1. コンテキスト ウィンドウが容量に近づいていることを検出します
2. 現在の会話を凝縮されたブロックに要約します。
3. 元のコンテキストを概要に置き換えます
4. 実行を継続します

それがトリガーされると、次のようになります。 デフォルトの memory-core プラグインには構成可能なしきい値はありません。タスクの段階ではなく、トークン数に基づいて起動されます。 2 時間の自律実行では、3 ～ 5 回の圧縮サイクルが期待できます。

圧縮耐性のあるファイル アーキテクチャを構築する方法

動作指示は会話ではなく MEMORY.md に固定します。 複数の圧縮サイクルを経ても存続する必要があるものは、圧縮のたびに再読み取りされる耐久性のあるファイルに保存する必要があります。

推奨されるピン留めパターン:

## Agent Behavioral Rules (always active)
- Never overwrite files without showing a diff first
- Write tests before implementation (TDD mode: on)
- Use TypeScript strict mode in all new files

## Project Context
- Stack: Node.js 22, Fastify, PostgreSQL 16
- Repo root: /home/user/project
- Active sprint goal: migrate auth to Clerk

圧縮しても存続する命名規則:

• クリティカルセクションの先頭に ## [PINNED] を付けます — サマライザは大文字のヘッダーを高優先度として扱います
• 固定された各事実は可能な限り 1 行にまとめます。密集した段落は要約され、単一行の事実はそのまま残る傾向があります。
• MEMORY.md と今日の毎日のメモの両方で 3 ～ 5 つの最も重要な行動ルールを繰り返します。冗長性は圧縮の回避策です。

10 分でゼロからメモリまでセットアップ (完全なファイル スキャフォールド)

これは他には存在しないセットアップガイドです。この構造をコピーし、コンテキストを入力すれば実行できます。

ディレクトリツリー:

memory/
├── MEMORY.md
├── 2026-04-27.md          ← today's daily note (create manually)
└── wiki/                  ← only if using memory-wiki plugin
    ├── index.md
    ├── project-context.md
    └── decisions.md

スターター MEMORY.md:

# Persistent Memory

## Identity & Preferences
- Name: [your name]
- Role: [your role]
- Preferred response style: concise, no preamble

## Project: [Project Name]
- Stack: [your stack]
- Key constraints: [e.g., no external APIs, TypeScript only]
- Current focus: [active task or sprint goal]

## Behavioral Rules
- [Rule 1]
- [Rule 2]

## Decisions Made
- [YYYY-MM-DD] Decided to use X because Y

スターターデイリーノート (2026-04-27.md):

# 2026-04-27

## Session Goals
- [ ] Task 1
- [ ] Task 2

## Notes

プラグインスロット構成 (2026 構文):

{
  "plugins": {
    "slots": {
      "memory": "memory-core"
    }
  }
}

メモリを完全に無効にするには:

{
  "plugins": {
    "slots": {
      "memory": false
    }
  }
}

検証手順:

1. セッションを実行し、エージェントに前のセッションで話した内容を思い出すように依頼します。
2. memory/YYYY-MM-DD.md が書き込まれたことを確認します (新しい内容が含まれているはずです)
3. エージェントに直接尋ねてください:「私のことについて何を知っていますか?」 — MEMORY.md から取得する必要があります

本番ナレッジベース用のメモリ Wiki の構成

プラグイン スロットを交換して有効にします。

{
  "plugins": {
    "slots": {
      "memory": "memory-wiki"
    }
  }
}

Memory-wiki は、memory/wiki/ の下に構造化ボールトを生成します。各トピックには独自のページが与えられます。このプラグインは、エージェントがセッション開始時にロードできるように、信頼性の高い矛盾のない事実を集約する digest.md をコンパイルします。

実稼働エージェントの実際的なボールト構造:

memory/wiki/
├── index.md              ← vault table of contents
├── digest.md             ← auto-generated; agent reads this
├── project-context.md    ← stack, goals, constraints
├── decisions.md          ← architectural decisions log
├── team.md               ← stakeholders, contacts
└── domain-knowledge.md   ← business rules, glossary

セマンティック検索と埋め込み — SQLite、sqlite-vec、および JS フォールバック

OpenClaw は、次を使用してメモリ ファイルにインデックスを付けます。 SQLite with the sqlite-vec extension ベクトル類似性検索用。あなたまたはエージェントがメモリ検索を発行すると、クエリが埋め込まれ、意味的に最も関連性の高いチャンクが取得されます。

ベクター ストアが正常であることを確認します。

# Check that the memory index exists
ls memory/.index/

# Reset a corrupted index (safe to run — it rebuilds from .md files)
rm -rf memory/.index/ && openclaw reindex

sqlite-vec が利用できない場合 (ARM Linux および一部の Windows 構成で一般的)、OpenClaw は純粋な JS ベクトル拡張機能にフォールバックします。明示的にフォールバックを強制します。

{
  "memory": {
    "vectorBackend": "js"
  }
}

セグメント固有のメモリ戦略

Solo Developer — 最小限のオーバーヘッド、最大限のリコール

推奨設定: memory-core プラグイン、MEMORY.md + 毎日のメモのみ、wiki 保管庫なし。

• MEMORY.md を 200 行未満に保ちます。ファイルが長いとセッションの開始が遅くなります。
• 毎日のメモに積極的に追加します。きれいに保とうとしないでください
• MEMORY.md を毎週確認して削除します - 古い事実は検索品質を低下させます

マルチエージェント パイプライン - エージェント間の共有メモリ

複数のエージェントが同じ memory/ ディレクトリに対して読み取りおよび書き込みを行う場合は、明示的な所有権ルールが必要です。

• One agent owns writes to each file — 同じ .md ファイルへの同時書き込みにより競合が発生します
• エージェントごとにサブディレクトリを使用します: memory/agent-a/、memory/agent-b/、共有 memory/shared/MEMORY.md
• 共有ボールトには Memory-Wiki を使用します。そのダイジェスト コンパイルは、生のファイルよりも複数のライターにわたる鮮度を適切に処理します。

長時間実行される自律タスク - 実行時間の存続

時間単位で測定されるタスクを実行するエージェントの場合:

• Force memory writes at checkpoints — 主要なタスクの各段階の後に、現在の状態を今日の日次メモに追加するようにエージェントに指示します。
• Pre-load compaction-resistant context — 最初のメッセージだけでなく、実行を開始する前に完全なタスク仕様を MEMORY.md に入力します。
• Set explicit continuation markers 毎日のメモ: <!-- RESUME POINT: completed steps 1-4, next: step 5 --> 圧縮サイクル後にエージェントが自己方向を設定できるようにする

OpenClaw メモリのトラブルシューティング - メモリ忘れの問題を 2 分で診断

次の手順を順番に実行してください。

よくある質問

最終評決 — 実際に定着するメモリ設定

ほとんどのユーザーの Recommended baseline: memory-core プラグイン、最初のセッションの前に作成された memory/ ディレクトリ、明確にラベル付けされた固定セクションの行動ルールを含む MEMORY.md、各セッションを通じて毎日のメモが追加されます。

あなたの行動チェックリスト:

• プロジェクトのルートに memory/ ディレクトリを作成します
• 上記のスターター MEMORY.md テンプレートをコピーし、コンテキストを入力します。
• plugins.slots.memory が "memory-core" (または選択したプラグイン) に設定されていることを確認します。
• MEMORY.md の ## [PINNED] の下に 3 ～ 5 つの最も重要な行動ルールを追加します。
• 最初のセッションの後、日付の付いた毎日のメモが書かれていることを確認してください
• セマンティック検索に違和感がある場合は、openclaw reindex を実行してベクトル インデックスを再構築してください

一度理解すれば、アーキテクチャは健全なものになります。ほとんどの物忘れの問題は、このチェックリストに従えば 10 分以内に解決します。