OpenClawローカル記憶システム全解剖：Markdownで実現するAIの長期記憶

午前2時。Claude Codeのチャット画面を見つめながら、ふと気づきました。「先週AIに分析させたあのアーキテクチャ案、あいつ覚えてるのか？」チャット履歴を遡ってみても、もう流れてしまっています。あの議論も、細かいディテールも、どこかへ消えてしまいました。

あなたも経験があるでしょう。AIアシスタントは問題を解決してくれますが、その記憶は金魚のように短いのです。会話が終わるたびに、全てがリセットされます。さらに不安なことがあります。それらの会話データはどこに行くのでしょう？クラウドサーバー？誰かに見られている？

OpenClawは非常に興味深い答えを出しました。「AIの記憶をすべてMarkdownファイルとしてローカルディスクに保存する」というものです。泥臭く聞こえるかもしれませんが、よく考えると、このアプローチは「AIの長期記憶」と「データのプライバシー」という2つの大きな問題を一挙に解決しています。

Alibaba Cloud - 開発者向けクラウドの第一候補、ライトサーバー15%OFF、プロジェクトの迅速な立ち上げを支援

15%割引を入手 →広告

この記事では、OpenClawの記憶システムを解剖し、単純なテキストファイルでどうやって永続的な記憶を実現しているのか、そしてプライバシーを守りながらどうやって効率的な検索を実現しているのかを解説します。

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

正直、OpenClawがMarkdownで記憶を保存していると知った時、少し戸惑いました。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もクラウドも不要（必須ではない）

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

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日間のログを読み込んでコンテキストを構築します。これで昨日の続きからシームレスに対話できます。しかし「先月記録したあの情報」が必要な場合は、検索システムを通じて MEMORY ディレクトリを探しに行きます。

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

価格を見る →広告

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

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

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

さて問題です。数百のMarkdownファイルがあるとして、どうやって関連情報を瞬時に見つけるのか？

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

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

仕組みはこうです：

1. インデックス作成時：Markdownファイル書き込み時、内容を小さなチャンク（塊）に分割し、SQLiteに保存します。

   • SQLiteのFTS5（全文検索エンジン）でインデックス化し、キーワード検索に対応
   • Embedding APIを叩いてテキストをベクトル化し、SQLiteに保存

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

   • BM25で「デプロイ」「コンテナ」を含むチャンクを探す
   • ベクトル検索で意味的に近いチャンクを探す
   • 両者の結果をブレンドしてスコアリングし、トップKを返す

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

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

• ローカルモデル：完全オフライン。データは外に出ないが、精度はAPIに劣る場合がある
• OpenAI Embedding API：高精度だが有料、APIキーが必要
• Gemini Embedding API：Googleのソリューション、無料枠が大きい

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

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

プライバシーとセキュリティ：Local-firstな保護

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

AIを使う時、無意識に機密情報（社内アーキテクチャ、顧客データ、個人情報）を避けていませんか？入力データがクラウドに送られ、学習に使われたり第三者に見られたりするリスクがあるからです。

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

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

今すぐ始める →広告

これは昨今流行りの「Local-first Software」思想と一致します——ユーザがデータ主権を持ち、ソフトウェアはあくまでの道具である、という考え方です。

しかし、ローカル保存だから絶対安全というわけではありません：

1. APIキー漏洩：記憶ファイルにAPIキーをメモしてしまい、うっかり公開リポジトリにpushしたら…悲劇です。
2. ファイル権限：OpenClawはmemoryディレクトリの読み書き権限が必要です。権限設定を誤ると悪意あるプログラムに読まれる可能性があります。
3. 悪意あるスキル：拡張スキルがローカルデータを盗む可能性があります。
4. インスタンスの露出：多くのOpenClawインスタンスが認証なしで公网に晒されているという報告があります。これは危険です。

特に4番目はCiscoやVectra AIも警告しています。認証なしで公開すると、誰でもあなたの記憶ファイルを読み、コマンドを実行できてしまいます。

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

• Dockerサンドボックス：コンテキストを隔離し、アクセス範囲を制限する
• 最小権限原則：rootで実行せず、必要最小限の権限を与える
• 暗号化：機密情報を含む場合はファイルシステムレベルで暗号化する
• アクセス制御：公网公開するならNginxリバプロ＋Basic認証/OAuthが必須
• 定期監査：memoryディレクトリやスキルリストを定期チェック

DigitalOceanに詳細なセキュリティ強化ガイドがあるので、一読をお勧めします。

結局のところ、ローカル保存はプライバシー保護の可能性を提供するだけで、実際に安全かどうかは運用次第です。鍵を渡されても、かけ忘れたら泥棒に入られます。

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

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

ディレクトリ構造

デフォルト構成：

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. 定期クリーンアップ：月一回、古いログを見て不要なものを削除、重要なものをMEMORYへ移動。
2. 手動編集：Markdownなのでいつでも編集可。AIの記憶違いを直接修正できます。
3. バージョン管理：memoryディレクトリをGit管理下に。コミットログが記憶の歴史になります。
4. バックアップ：HDD故障に備えてクラウドや外付けHDDへ。

パフォーマンス最適化

ファイルが増えすぎると重くなる場合があります。

Alibaba Cloud - 開発者向けクラウドの第一候補、ライトサーバー15%OFF、プロジェクトの迅速な立ち上げを支援

15%割引を入手 →広告

• ファイルサイズ：1ファイル1MB以内に抑えるのが無難。
• コンテキストウィンドウ：デフォルト2日分ですが、重ければ当日分のみに変更。
• インデックス再構築：.memory_index.db が肥大化したら削除して再起動（自動再構築されます）。
• 圧縮しきい値：30日以上前のログを自動アーカイブする設定。

小技として、MEMORYディレクトリに INDEX.md を手動で作るのをお勧めします。重要ファイルの概要とリンクをリスト化しておくと、万が一検索システムが不調でも人間が探せます。

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

まとめ

最初の問いに戻りましょう。AIの記憶はどこにあるべきか？

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

2層アーキテクチャ（一時ログ＋永続知識）は人間の記憶モデルを模倣し、ハイブリッド検索（BM25＋ベクトル）によりテキストファイルの弱点を克服しました。「ファイルファースト」哲学により、VSCodeやGitといった使い慣れたツールでAIの記憶を管理できます。

もちろん万能ではありません。多デバイス同期やチームコラボレーション、完全メンテナンスフリーを求めるならクラウドの方がいいでしょう。

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

あなたもAI Agent開発をしているなら、Markdown記憶方式を試してみては？ NOTES.md 一つから始められます。重要なのは技術ではなく、誰がデータを持っているかです。

より詳しい実装は公式ドキュメントやソースコードをチェックしてください。コミュニティも活発です。

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

6 min read · 公開日: 2026年2月5日 · 更新日: 2026年2月5日

Easton

AI・インテリジェンス