OpenClaw ローカル記憶システム解説：Markdown で AI 記憶を保存する

先週 AI に分析してもらったアーキテクチャ案を、チャット履歴を遡って確認しようとしたら、もう流れて消えていました。AI アシスタントは問題を解決してくれますが、記憶は短命。会話が終われば、さっき話したことはほぼ忘れ去られます。さらに重要なのは——その対話データはどこへ行くのか。クラウドサーバーに保存されているのか。誰が見られるのか。

OpenClaw は AI のすべての記憶を Markdown ファイルに保存し、データはローカルディスク上に置きます。この方式は 2 つの課題を同時に解決します。AI に長期記憶を持たせつつ、データをクラウドにアップロードしないことです。

本記事では OpenClaw の記憶システムを分解します。2 層アーキテクチャ（一時ログ＋永続知識）、ハイブリッド検索（BM25 キーワード＋ベクトル意味検索）、ローカルプライバシー保護の仕組みまで。データは完全に自分で管理でき、VSCode でいつでも開いて編集可能。Git によるバージョン管理にも対応しています。

低コスト「エビ飼育」ガイド：ArkClaw で AI Agent を本当に身近に

話題の OpenClaw（ロブスタ）は便利ですが、設定のハードルが高い——そんな声に応えて、ByteDance Volcano Engine の ArkClaw は敷居を大きく下げました。サーバーや Token 設定をいじらず、ワンクリックで 24 時間オンライン、ブラウザ操作・スクリプト実行・カレンダー管理ができる AI アシスタントを手に入れられます。

月額 9.9 元と本当に安いのがポイント。招待コード ZLKUK54M（こちらから登録）を使えば 8.9 元。プログラマーなら Coding Plan Pro に入ると無料枠もあります。

なぜ Markdown なのか：ファイルファーストの設計哲学

正直、OpenClaw が Markdown で AI 記憶を保存していると知ったとき、少し戸惑いました。Markdown はドキュメントを書くためのもので、データベース代わりにはならない——そう思っていました。

しかしよく考えると、非常に賢い設計です。

AI の全記憶が PostgreSQL に入っていたらどうでしょう。何を覚えているか確認するには、DB クライアントを開いて SQL を書く必要があります。考えるだけで面倒です。Markdown なら？ VSCode で開けば一目瞭然。修正したければエディタで保存するだけ。バックアップ？ フォルダをコピー。先週の状態に戻したい？ Git コマンド一発です。

OpenClaw の作者はこの理念を「ファイルファースト（File-first）」と呼んでいます。本質的には Markdown ファイルを「唯一の信頼できる情報源（Single Source of Truth）」とし、データベースはインデックスと検索加速のためだけに使います。

これは Anthropic が推奨する NOTES.md パターンとも通じています。Claude 公式も、開発中の重要な決定やコンテキストを NOTES.md に記録し、AI に毎回読ませることを推奨しています。OpenClaw はこの発想を極限まで推し進め、記憶システム全体を Markdown ベースにしました。

従来のソリューションと比較すると：

• Redis / インメモリ DB：高速だが再起動で消失、永続化が別途必要
• PostgreSQL / MySQL：強力だが重い。運用コストがかかり、データが直感的でない
• ベクトル DB（Pinecone 等）：AI 向けだが多くはクラウド。データがローカルを離れる

Markdown 方式のメリットは明白です：

1. 人間可読：AI が何を覚えているか、いつでもファイルで確認できる
2. 完全な制御：データは自分の HDD 上。バックアップ・削除・暗号化も自由自在
3. Git フレンドリー：記憶の変化をバージョン管理でき、チーム協業も可能
4. ゼロ依存：DB サービスも Docker もクラウドも必須ではない

もちろん欠点もあります。最大の課題は検索効率——大量のテキストファイルから、どう関連情報を素早く見つけるか。これについては後述します。

Railway - モダンなデプロイプラットフォーム、煩わしい運用から解放、数分で公開

今すぐ始める →広告

2 層記憶アーキテクチャ：一時と永続のバランス

OpenClaw の記憶システムは人間の脳に似ています。短期記憶と長期記憶があるように、OpenClaw も「一時ログ（Daily Logs）」と「永続知識（Curated Knowledge）」の 2 層に分かれます。

一時ログは短期記憶のようなものです。「今日何をしたか」「さっき何を話したか」が memory/YYYY-MM-DD.md 形式の日次ファイルに記録されます。例えば 2026 年 2 月 5 日なら memory/2026-02-05.md が自動生成され、すべての活動が追記（Append-only）されていきます。

賢いのは、OpenClaw が当日と前日のログだけを自動ロードする点です。なぜ 2 日分か——直近の文脈を保つためです。昨日 AI に頼んだタスクを、今日続きから頼める。それ以前のログは自動ロードされません。そうしないとコンテキストウィンドウが溢れてしまうからです。

永続知識は整理された長期記憶で、MEMORY ディレクトリに保存されます。手動または自動で抽出された重要情報——プロジェクトアーキテクチャ、重要な決定、頻用コードスニペットなどです。

ディレクトリ構成のイメージ：

memory/
├── 2026-02-01.md          # 過去ログ（自動ロードされない）
├── 2026-02-04.md          # 昨日のログ（自動ロードされる）
├── 2026-02-05.md          # 今日のログ（自動ロードされる）
└── MEMORY/
    ├── project-architecture.md   # 永続知識（検索で呼び出される）
    ├── deployment-notes.md
    └── troubleshooting-guide.md

AI 起動時、直近 2 日分のログを読み込んでコンテキストを構築します。昨日の続きからシームレスに対話できます。1 か月前に記録した情報が必要な場合は、検索システム経由で MEMORY を探します。

2 層構造には実用的な機能もあります：自動アーカイブ。ログが溜まりすぎると flush 機構が働き、古いログを圧縮・アーカイブしてディスク圧迫を防ぎます。重要情報は永続ストレージへ移されます。

正直、この設計は人間の忘却曲線を彷彿とさせます。すべての記憶を永久保存する必要はない。大部分の一時情報は自然に忘れていい。本当に重要なものだけが長期記憶として沈殿していきます。

高効率検索：SQLite ベクトル検索のハイブリッド

さて問題です。数百の Markdown ファイルがあるとして、関連情報をどう素早く見つけるか。

単純な grep や全文検索では不十分です。「コンテナ化アプリのデプロイ方法」を探したいのに、ファイルには「Docker イメージのビルドと K8s 展開手順」と書いてあった——キーワードが一致せずヒットしません。プレーンテキスト検索の限界です。字面だけ一致し、意味は理解しない。

OpenClaw の解決策はハイブリッド検索。キーワード検索（BM25）と意味検索（ベクトル類似度）を組み合わせます。

仕組みはこうです：

1. インデックス層：Markdown 書き込み時、内容をチャンクに分割し：

   • SQLite FTS5（Full-Text Search）で全文インデックスを構築し、キーワード高速マッチ
   • Embedding API でテキストをベクトル化し SQLite に保存

2. 検索時：「コンテナ化アプリのデプロイ方法」と聞くと：

   • BM25 で「デプロイ」「コンテナ」を含むチャンクを探索
   • ベクトル検索で意味的に近いチャンクを探索
   • 両結果を混合スコアリングし、Top-K を返す

キーワード一致の速さと、意味理解の正確さ。正確なクエリも曖昧な概念質問も捌けます。

ベクトル検索には Embedding モデルが必要です。OpenClaw は 3 種類をサポート：

• ローカルモデル：完全オフライン。データは外に出ないが、精度は API に劣る場合あり
• OpenAI Embedding API：高精度だがクラウド呼び出し。API キーが必要
• Gemini Embedding API：Google 版。無料枠が大きい

設定で自動選択されます。プライバシー重視ならローカル、精度重視なら OpenAI や Gemini を選べば OK です。

Vultr - 高性能NVMeクラウドサーバー、世界32拠点、Dockerワンクリック展開対応

価格を見る →広告

実際に使うと、単純な grep より遥かに優秀です。以前「Nginx リバースプロキシ設定」のメモを書いたのに、後から「ロードバランサの設定どうやるっけ」と聞いたら、そのメモを見つけてくれました。「ロードバランサ」という語は書いていなかったのに。これがセマンティック検索の威力です。

プライバシーとセキュリティ：ローカルファーストの保護

データ保存といえば、プライバシーは避けて通れません。

AI を使うとき、無意識に機密情報——社内アーキテクチャ、顧客データ、個人情報——を避けていませんか。対話がクラウドに送られ、学習に使われたり第三者に見られたりするかわからないからです。

OpenClaw の「ローカルファースト」アーキテクチャはこの問題を根本から解決します。すべての記憶ファイルはローカルディスクにあり、自動アップロードはされません。クラウドバックアップしたければ自分で Dropbox や Git を使えばいい。暗号化したければ VeraCrypt や FileVault を使えばいい。すべて自分で制御できます。

これは「Local-first Software」の思想と一致します——データ主権はユーザーにあり、ソフトウェアは道具に過ぎない、という考え方です。

ただし、ローカル保存＝絶対安全ではありません。OpenClaw には依然としてセキュリティ課題があります：

1. API キー漏洩：記憶ファイルに API キーをメモし、うっかり GitHub 公開リポジトリへ push したら……
2. ファイルシステム権限：OpenClaw は memory ディレクトリの読み書きが必要。権限設定を誤ると悪意あるプログラムに読まれる可能性
3. 悪意あるスキル / プラグイン：拡張スキルがローカルデータを窃取する可能性
4. インスタンスの露出：認証なしで公網に晒された OpenClaw インスタンスが数百件ある、という調査報告

特に 4 番目は手に汗。Cisco や Vectra AI も警告しています。認証なしで公開すると、誰でも記憶ファイルを読み、任意コマンドを実行され、バックドアを仕込まれる恐れがあります。

対策としてのベストプラクティス：

• Docker サンドボックス：コンテナで OpenClaw を隔離し、アクセス範囲を制限
• 最小権限原則：root で実行せず、必要最小限のファイル権限のみ付与
• 機密データの暗号化：記憶ファイルに機密情報がある場合はファイルシステムレベルで暗号化
• アクセス制御：公網公開するなら Nginx リバースプロキシ＋ Basic Auth または OAuth が必須
• 定期監査：memory ディレクトリの異常ファイル、スキルリストの不審プラグインをチェック

DigitalOcean には詳細なセキュリティ強化デプロイガイドがあります。一読をおすすめします。

結局のところ、ローカル保存はプライバシー保護の可能性を与えるだけです。本当に安全かどうかは、設定と運用次第。鍵を渡されても、かけ忘れたら意味がありません。

実践ガイド：記憶データの管理と最適化

原理はわかりました。では実際どう管理すればいいのでしょう。

ファイル構造

OpenClaw のデフォルト構成：

memory/
├── 2026-02-05.md          # デイリーログ
├── MEMORY/                # 永続知識ベース
│   ├── projects/          # テーマ別
│   │   ├── project-a.md
│   │   └── project-b.md
│   ├── reference/         # 参考資料
│   └── troubleshooting/   # トラブルシューティング
└── .memory_index.db       # SQLite インデックス

必要に応じて調整できます。私はプロジェクトとトピックごとに整理しています：

MEMORY/
├── work/
│   ├── backend-api-design.md
│   └── database-migration-notes.md
├── learning/
│   ├── rust-ownership-model.md
│   └── kubernetes-networking.md
└── personal/
    └── recipe-collection.md

データメンテナンス戦略

1. 定期クリーンアップ：月 1 回、古いログを確認。不要なものを削除し、重要なものを MEMORY へ移行
2. 手動編集：Markdown なのでいつでも編集可。AI の記憶違いを直接修正できる
3. バージョン管理：memory を Git 管理下に。コミット履歴が記憶の進化史になる
4. バックアップ：HDD 故障に備え、クラウドや外付け HDD へ定期バックアップ

パフォーマンス最適化

記憶ファイルが増えると性能問題が出る場合があります。いくつかの提案：

🔥 需要のない製品に3ヶ月も無駄にするな！少額の予算で Adsterra を使い、SaaS の訴求を今すぐ検証 ➡️

今すぐ検証 →広告

• 単一ファイルサイズ：1 ファイル 1MB 以内を目安。大きければ分割
• コンテキストウィンドウ：デフォルトは直近 2 日分のログ。応答が遅ければ当日分のみに変更
• インデックス再構築：.memory_index.db が肥大化したら削除して再起動（自動再構築）
• 圧縮しきい値：ログが 30 日分を超えたら自動圧縮・アーカイブ

小技：MEMORY に INDEX.md を手動作成し、重要ファイルの概要とリンクを一覧化しておくと、検索システムが不調でも人間が素早く探せます。

記憶管理はノート整理に似ています。少しの規律が必要ですが、慣れればクラウド依存より遥かに快適。データが手元にある安心感は何物にも代えがたいです。

まとめ

最初の問いに戻りましょう。AI アシスタントの記憶は、どこにあるべきか。

OpenClaw の答えは「ローカルの Markdown ファイル」です。レトロに見えて、クラウドストレージの 2 つの核心課題——データプライバシーとユーザー主権——を解決しています。

2 層記憶アーキテクチャ（一時ログ＋永続知識）は人間の記憶モデルを模倣し、直近文脈の連続性を保ちつつコンテキスト爆発を防ぎます。ハイブリッド検索（BM25＋ベクトル）により、プレーンテキスト保存でもインテリジェントな検索が可能。「ファイルファースト」の設計哲学により、エディタ・Git・ファイルマネージャーといった使い慣れたツールで AI の記憶を管理できます。

もちろん銀の弾丸ではありません。多デバイス同期、チーム協業、完全メンテナンスフリーが必要なら、クラウドサービスの方が向いている場合もあります。

しかし私にとって、OpenClaw の記憶システムは重要な示唆を与えてくれました。AI の記憶はブラックボックスである必要はなく、透明で、可変で、自分のものにできるということです。

AI Agent アプリを開発しているなら、Markdown 記憶方式を試してみては。シンプルな NOTES.md 一つから始められます。重要なのは技術の高度さではなく、データを誰が握っているかです。

OpenClaw の実装詳細は、公式ドキュメントとソースコードを参照してください。コミュニティも活発で、問題は大抵解決策が見つかります。

そして最後に——セキュリティ設定を忘れずに。あなたの記憶が、他人のデータセットにならないように。