OpenClaw を使い始めると、かなりの確率で同じところで詰まります。workspace は何を置く場所なのか、~/.openclaw/ とは何が違うのか、sandbox を有効にしたらどこで作業しているのか、そして何をバックアップすべきなのか。この境界が曖昧なまま使うと、memory が飛んだように見えたり、秘密情報を間違った場所に置いたり、sandbox 内で「さっきのファイルが見えない」と混乱しやすいです。
この記事は、その混乱をほどくためのものです。OpenClaw の全体像から入りたいなら OpenClaw で何ができるのか、安全運用の前提を先に固めたいなら OpenClaw のセキュリティ設定入門、Claude 側とどう住み分けるかを見たいなら OpenClaw vs Claude Code 徹底比較 を先に読むとつながります。組織で AI エージェント運用まで広げるなら、AIコーディングツールの社内ガイドライン も補助線になります。
結論を先に書きます。OpenClaw の workspace は「設定置き場」ではなく「エージェントの記憶置き場」です。 一方で ~/.openclaw/ は config、credentials、sessions のような state 置き場です。この2つを分けて考えるだけで、運用はかなり安定します。
まず押さえるべき前提: workspace は memory、~/.openclaw/ は state
公式 docs では、agent workspace は「agent の home」であり、file tools と workspace context が使う唯一の working directory だと説明されています。デフォルトは ~/.openclaw/workspace です。ただし、ここは hard sandbox ではありません。sandbox を有効にしていない限り、relative path は workspace 基準でも、absolute path なら host 上の別の場所にも届きます。
ここを雑に理解すると、workspace に config や token を混ぜ込みがちです。しかし実際には役割が違います。
~/.openclaw/workspace- AGENTS.md や memory のような、エージェントに継続して読ませたい文脈
- 長期メモ、日次メモ、作業手順、判断基準
- private git で戻せるようにしておきたい「頭の中」
~/.openclaw/openclaw.json- auth profiles や credentials
- session transcripts と metadata
- managed skills などの state
この分離が大事なのは、バックアップ単位と漏えいリスクが違うからです。workspace は「残したい文脈」ですが、~/.openclaw/ は「漏らしたくない状態」を含みます。両方を同じ repo に突っ込む設計は雑です。
workspace に置くもの、置かないもの
OpenClaw の FAQ と workspace docs を合わせて読むと、memory は plain Markdown files です。日次メモは memory/YYYY-MM-DD.md、長期メモは MEMORY.md に置かれます。要するに workspace は、モデルの長期記憶をファイルで管理する場所です。
私なら workspace に置くものは次に絞ります。
- AGENTS.md などの恒久指示
MEMORY.mdと日次 memory- 再利用する手順書
- プロジェクト単位の判断メモ
逆に、置かない方がいいものは次です。
- API key や OAuth token
openclaw.json- session transcript 一式
- 共有 repo に出したくない個人情報
公式 docs も、~/.openclaw/openclaw.json、credentials/、agents/<agentId>/sessions/ などは workspace repo に commit すべきではないと明示しています。workspace を memory repo として扱うなら、秘密情報は workspace ではなく state 側か OS の秘密管理に寄せるのが基本です。
sandbox を有効にすると「今どこで作業しているか」が変わる
OpenClaw で workspace 設計がややこしくなる最大の理由はこれです。sandboxing を有効にして workspaceAccess が "rw" でない場合、tools は host の workspace ではなく ~/.openclaw/sandboxes 配下の sandbox workspace で動きます。
つまり、次の誤解が起きやすいです。
- host の
~/.openclaw/workspaceにあるはずのファイルが見えない - memory を書いたのに別セッションでは反映されないように見える
- bind mount したフォルダに対して、想定より広い権限が通ってしまう
設計としては、こう割り切るのが安全です。
- 常用する durable memory は host workspace に置く
- untrusted input や public channel は sandbox 前提で分ける
- bind が必要なら
:roを基本にする - sandbox 内の作業ディレクトリは「host workspace の写し」だと理解する
FAQ でも、bind mounts は sandbox filesystem walls を迂回するので、敏感なものは :ro にしろと書かれています。便利さのために bind を広く開けると、sandbox を入れた意味がかなり薄れます。
backup は workspace と state を分けて考える
公式 docs が強く勧めているのは、workspace を private git repo にして戻せるようにしておくことです。これは筋がいいです。workspace は memory なので、差分で追える方が扱いやすいからです。
最小限なら次で足ります。
cd ~/.openclaw/workspace
git init
git add AGENTS.md SOUL.md TOOLS.md IDENTITY.md USER.md HEARTBEAT.md memory/
git commit -m "Add agent workspace"ただし、これで OpenClaw 全体の復旧が終わるわけではありません。openclaw backup create は通常 ~/.openclaw の state directory、active config、外出しの credentials directory、workspace directories をまとめてバックアップ対象にします。つまり実務では、次の二層で考えるべきです。
- workspace backup
- 目的: 記憶と恒久指示の復元
- 手段: private git
- state backup
- 目的: config や認証状態も含めた復旧
- 手段:
openclaw backup create
もし config が壊れていて workspace discovery が失敗する状況なら、docs は openclaw backup create --no-include-workspace を案内しています。ここでも、workspace と state を別物として扱っていることが分かります。
私ならこう設計する
個人運用なら、まずは次の初期値で十分です。
- host workspace は 1つに絞る
- workspace には memory と指示だけ置く
- secrets は
~/.openclaw/側か環境変数へ寄せる - sandbox は public input や untrusted task にだけ使う
- bind は必要最小限、原則
:ro - workspace は private git、state は別バックアップ
この設計にしておくと、どこで何が壊れたか切り分けやすいです。memory が飛んだなら workspace 側、認証が飛んだなら state 側、sandbox で見え方が変わるなら workspaceAccess と bind 側を疑えばよい。
よくある失敗
1. workspace を「なんでも置いてよいホームディレクトリ」だと思う
それは違います。workspace は convenience のための置き場ではなく、エージェントの durable memory を育てる場所です。雑多な secrets や一時ファイルを積むと、検索も復旧も悪化します。
2. sandbox を有効にしたのに host workspace を前提に話してしまう
sandbox 実行時は、agent が実際に見ている workspace が別物になりえます。ここを分からないまま不具合調査すると、かなり遠回りします。
3. workspace の git backup だけで十分だと思う
不十分です。workspace backup は「記憶の復元」であって、config と認証状態の完全復旧ではありません。state backup は別に要ります。
まとめ
OpenClaw の workspace 設計で本当に大事なのは、機能を増やすことではなく境界を明確にすることです。
- workspace は memory
~/.openclaw/は state- sandbox 時は実作業場所が変わる
- backup も workspace と state を分ける
この4点を先に決めておけば、OpenClaw はかなり扱いやすくなります。逆にここを曖昧にすると、「なぜか覚えない」「なぜか見えない」「なぜか戻せない」がまとめて起きます。OpenClaw を便利なまま安全に使いたいなら、最初に触るべきはモデル設定より workspace 設計です。