コンテキストを失わずにClaudeのメモリをOpenClawに移行する方法（2026年）

Claudeからメモリを取り出す。 Anthropicはこれについて直接ドキュメント化しています。Settings（設定） → Capabilities（機能）に移動し、"View and edit your memory"（メモリの表示と編集）を開くと、Claudeが見ている通りのメモリを確認できます。すべてのエントリがカテゴリ別にリストされ、それぞれ編集や削除が可能です。このビューが移行のソース素材となります。

また、チャットでClaudeに「私のメモリを、メモリに記録されている通りに一言一句違わずに書き出してください」と依頼することもできます。出力されたテキストをローカルマシンのファイルにコピーします。構造化されたエクスポートファイルをダウンロードする機能はないため、コピー＆ペーストのステップが必要になります。

ドキュメントに記載されている制限事項の1つが、そこに表示される内容を左右します。Claudeのメモリは仕事関連のトピックに焦点を当てるように設計されています。これは今回の移行において有益です（エントリは雑学ではなく、あなたの仕事の進め方に関するものである傾向があるため）。しかし、それはメモリがこれまでの会話すべての書き起こしではなく、要約された観察結果の集合であることを意味します。

ここでAnthropicのツールの方向性に注目してください。Claudeのメモリインポート（Settings → Memory → "Start import"）は、他のプロバイダーからClaudeにコンテキストを取り込むためのものであり、明示的に実験的機能とされています。Anthropicは、Claudeが「インポートされたメモリを常に正常に取り込めるとは限らない」と指摘しています。逆方向（外部への書き出し）の機能は存在しないため、外部への移行は手動で行う必要があります。

OpenClawが受け取るもの。 OpenClawのモデルは非常に明示的であり、実践者はこれをルールとして挙げています。「ファイルに書き込まれていなければ、それは存在しない」というものです。これはツールに対する不満ではなく、そういう設計なのです。その周囲で定着している慣例は以下の通りです。

• 好ましいアプローチや学んだ落とし穴の真のナレッジベースへと成長する、MEMORY.md形式のファイル。
• 決定事項や重要なやり取りを記録した日報（デイリーノート）。エージェントは新しいセッションの開始時に、長期メモリファイルとともにこれを読み込みます。
• セッション内で /context list を実行し、なぜ特定の情報が定着していないのかを診断する。
• コンパクション（圧縮）の前にサイレントなエージェントターンをトリガーし、重要な内容をディスクに書き込むようモデルに促す、組み込みのプレコンパクションメモリフラッシュ。2026年2月後半にいくつかのコンパクションのバグが修正されたため、最新のビルドを使用することが重要です。

ファイル以外のものについては、OpenClawはMCPを介して接続します。サーバーは ~/.openclaw/openclaw.json の "mcp": { "servers": { … } } の下に配置され、それらを管理するための完全なCLI（openclaw mcp add、set、configure、show、list、unset、さらにOAuthフロー用の openclaw mcp login <name> や、動作確認用の openclaw mcp doctor <name> --probe）が用意されています。Stdio、SSE、およびストリーミング可能なHTTPトランスポートがすべてサポートされており、HTTPサーバー用の静的ヘッダーも利用可能です。

移行されないもの。 Claudeのメモリのエントリはあなたについて記述しています（あなたの慣習、好み、気づいたパターンなど）。一方、OpenClawは実際のシステムに対して無人で実行されるため、必要なのは「運用上の情報」です（どの環境が存在するか、何に決して触れてはならないか、デプロイが実際に何を行うか、すでに2回診断した障害は何かなど）。その一部はClaudeのメモリにあるかもしれません。しかし、その多くはClaudeが要約して消し去った会話の中にあり、記録されたエントリ自体には含まれていません。

ステップ 1: Claudeからメモリを取り出し、徹底的に編集する

Settings（設定） → Capabilities（機能） → View and edit your memory（メモリの表示と編集）を開き、全体に目を通します。ほとんどの人は2度驚くことになります。1つはそこにどれほど多くの情報があるか、もう1つはコマンドを実行するエージェントにとってその多くがいかに無関係であるかです。

• そのビューから、またはClaudeに一言一句違わずに書き出すよう依頼して、エントリをファイルにコピーします。
• 運用上の意味を持たない、会話スタイルに関する記述はすべて削除します。インフラをプロビジョニングするエージェントは、あなたが箇条書きを好むことを知る必要はありません。
• 行動を制限するものはすべて残し、拡張します（環境、命名規則、禁止事項、レビュー要件、触れるシステムなど）。
• 1回しか言わなかったためにClaudeが保存しなかった情報を追加します。あなたの頭の中にある「本番環境に対してそれを実行するな」というすべての注意事項は、今すぐ書き留める価値があります。
• これらの中に資格情報を貼り付けないでください。ファイル内はもちろん、特に ~/.openclaw/openclaw.json 内にインラインで記述しないでください。このファイルは移行時にバックアップおよびコピーされます。環境変数を使用し、${VARIABLE_NAME} として参照してください。

ステップ 2: OpenClawに保存先と保存方法を提供する

次に、残した情報を用途別に分割します。

• 恒久的なルールは、エージェントが実行ごとに読み込む長期メモリファイルに格納します。常にロードされるため、簡潔に保ってください。
• 作業メモはデイリーノートのパターンに格納します。これにより、今週の決定事項を、恒久的なファイルを肥大化させることなく来週も利用できるようになります。
• 参照資料（アーキテクチャドキュメント、ランブック、契約書、図など）は、Markdownファイルに直接貼り付けるべきではありません。MCPを介してOpenClawにその場所を指示し、すべてを持ち運ぶのではなく、関連する情報のみを取得できるようにします。
• 信頼する前に検証する。 セッションを実行し、/context list を行って、エージェントが実際に何をロードしたかを確認します。ファイルは存在するが読み込まれていないというのが、移行が失敗したと感じる最も一般的な原因です。

次に、配管（接続）を確認します。openclaw mcp list で登録されているものを確認し、依存しているものに対して openclaw mcp doctor <name> --probe を実行します。設定されているものの応答しないサーバーは、スケジュール実行中にサイレントに失敗します。これは、問題が発覚する場所としては最悪です。

この移行が実際に何で構成されていたかに注目してください。ある製品のプライベートなストレージから知識を読み出し、別の製品のファイル規則に合わせて手動で書き直す作業です。スタックが変更されるたびにこれを繰り返すことになり、そのたびに前のツールがすでに圧縮して失ってしまった情報を失うことになります。

OpenClawのファイルモデルは本当に機能します。明示的で、バージョン管理が可能で、grep検索もできます。これは多くのツールが提供している以上のものです。その制限は欠陥というよりも構造的なものです。ファイルはマシン上に存在し、手動でメンテナンスされ、各エージェントが独自のセットを持ち、Claudeはそれらを読み取ることができません。そのため、同じ真実の2つのバージョンを保持することになり、それらはやがて乖離していきます。

代替案は、どちらのツールにも所有されないレイヤーに知識を保持することです。MemoryLake はそのレベルに位置します。メモリを独自のレイヤーとし、MCPまたはAPIを介してアクセスできるようにすることで、ClaudeとOpenClawは2つのコピーからではなく、同じ場所から読み込むようになります。

ステップ 1: APIキーを作成する

キーを生成し、約30秒で最初のリクエストを送信します。

ステップ 2: 最初のメモリをアップロードする

上記のステップ1で整理した素材に加えて、本来なら貼り付けるはずだった参照ドキュメント（アーキテクチャメモ、ランブック、API契約、決定ログ、人々が説明し続けているダッシュボードのスクリーンショットなど）をロードします。ドキュメント、画像、その他のファイルはすべて同じ場所に保存されます。

ステップ 3: AIとエージェントを接続する

OpenClaw、Claude、Codex、およびその他のエージェントにMCP経由でアクセスを許可します。OpenClawの場合、これは ~/.openclaw/openclaw.json 内の1つのサーバーエントリ、または単一の openclaw mcp add コマンドで完了します。長期メモリファイルはルールを保持する役割に戻り、毎週増えていく知識を2つの場所で手動メンテナンスする必要はなくなります。

即座に現れる効果は、メモリファイルの肥大化が止まることです。これらのファイルが肥大化する原因の多くは、「恒久的なルール」と「蓄積された知識」という2つの役割を担っているためであり、毎回の実行でロードすべきなのはそのうちの1つだけです。これらを分割することで、エージェントが実行ごとに読み込む量を削減しつつ、必要なときに検索できる情報を増やすことができます。

2つ目の効果は、OpenClawの本領が発揮される無人実行時に現れます。メモリレイヤーにクエリを実行できるスケジュールされたエージェントは、午前3時に必要なランブックを見つけ出すことができます。一方、ファイルに収まる範囲の知識しか持たないスケジュールされたエージェントは即興で対応しようとします。そして、本番環境に対する即興の対応こそが、インシデントの始まりとなります。

3つ目は、ClaudeとOpenClawの不一致がなくなることです。現在、Claudeの会話で下した決定はClaudeのメモリにのみ存在し、他の場所には存在しないため、実際に作業を行うエージェントがそれを学習することはありません。共有された1つのメモリがそのループを閉じます。これが、MCPを介したクロスAIメモリの設定が、どちらか一方のツールを単独で最適化するよりも早く成果を上げる傾向がある理由と同じです。

メモリファイルはアーカイブではなくルールとして扱う

エージェントが常に尊重しなければならない制約である場合は、ファイルに記述します。インシデント、決定事項、システムの詳細など、増え続ける知識である場合は、エージェントがクエリを実行するレイヤーに配置します。実行ごとにロードされるファイルは、誤った情報が混入したときにすぐに気づける程度に短く保つべきです。

すべての決定事項を運用可能な形で記述する

Claude'sのメモリには、あなたが特定のデプロイ手法を好むことが記録されているかもしれません。しかし、OpenClawが必要とするのは、コマンド、環境、ガードレール、および理由が含まれたバージョンです。決定事項を運用言語で書き直すことは、この移行において最も価値のある1時間となります。

資格情報を設定やメモリから排除する

~/.openclaw/openclaw.json は移動します（マシンの移行時にバックアップおよびコピーされます）。そのため、トークンをインラインで記述するのではなく、環境変数を参照してください。また、OpenClawはstdioサーバーに対して NODE_OPTIONS、PYTHONSTARTUP、DYLD_*、LD_* などの危険な起動変数をフィルタリングします。これは、エージェントが読み取れるものはすべて、エージェントが文字起こし（トランスクリプト）に漏洩させる可能性もあるという良い教訓になります。

ClaudeからOpenClawへの移行は、クリック1つで済むものではなく、本物の移行作業です。Settings（設定） → Capabilities（機能）からメモリを読み出し、行動を制限するものだけに絞り込み、運用上の言葉で書き直し、OpenClawが実際に読み取る場所に配置します。そして、思い込みに頼らず、/context list で検証してください。

変更する価値があるのは、手順ではなくパターンです。ClaudeはメモリをClaude内に保持し、OpenClawは知識を1台のマシン上のファイルに保持するため、ツールを変更するたびに手動でプライベートストレージ間で知識を移動させることになります。両方の外部に存在するメモリレイヤーを導入すれば、コンテキストは移行するものではなくなります。そして、無人のエージェントが、たまたまMarkdownファイルに収まった情報だけで動作することもなくなります。ソースが別のシスタントである場合も、ChatGPTのメモリをOpenClawに移行する場合や、ClaudeのメモリをIDEエージェントに移行する場合と同様のルートが適用されます。