OpenClawワークスペース（SOUL.md、MEMORY.md）クラウドMac 2026：チーム向け安全設定
レンタルしたApple Silicon Mac上でOpenClawを動かすプラットフォームチームはすぐに気づきます。モデル選定とゲートウェイの稼働率は物語の半分に過ぎず、エージェントの振る舞いはワークスペース内のMarkdownで方向づけられる、と。SOUL系の指示は口調と安全柵を定義し、メモリファイルはセッションをまたいで覚えておくべき事実を保持し、付随ファイルは利用可能なツールとサブエージェントを説明します。2026年の実務では、そのディレクトリをインフラのコードのように扱います。安全な部分だけをバージョン管理し、秘密は除外し、どのmacOSユーザーがLaunchAgentでそれを読むかを明文化する、という流れです。本稿では各コアファイルの役割、七段階の初期セットアップ、複数エンジニア向けサンドボックス、Git運用、典型的な失敗症状と対処の対応表をまとめ、問題がMarkdownではなくゲートウェイやTLS側にあるときはlaunchdトラブルシュートやTLS終端とリバースプロキシの記事へ誘導します。
よく整えられたワークスペース文章はトークンコストも下げます。SOULを簡潔に保てば毎チャットで方針を繰り返す必要が減り、MEMORYを刈り込めば毎タスクで古い段落を再取り込むコストを抑えられます。運用では「プロンプト負債」を月次でレビューし、cronの棚卸しと同じ温度感で実験段落を削除し、廃止されたAPIやブランドトーンに合わない指示をアーカイブします。
チームが増えるほど、ワークスペースの「所有権」が曖昧になるのが典型的事故パターンです。誰が本番用のSOULを承認し、誰がMEMORYの古い箇条書きを消す権限を持つかを、小さなRACI表にしておくだけで週末オンコールが楽になります。また、エージェントに与えるツールの一覧は、セキュリティレビューの対象にすべきです。便利そうだからと追加したシェルワンライナーが、後から組織全体のリスクになるケースは珍しくありません。
クラウドMacはヘッドレス運用が多いため、GUIで一度だけ許可が必要なmacOSのダイアログと、エージェントの自動実行の境界を文書に書いておく価値があります。VNCで操作する人と、SSHだけの人で手順が分岐するなら、その分岐条件をSOULに短く書いておくと、モデルが「推測でクリック」しにくくなります。
ヘッドレスクラウドMacでワークスペースMarkdownが重要な理由
チャット専用アシスタントと違い、MacLoginノード上のOpenClawエージェントはシェルコマンドの実行、フォルダ監視、Webhook応答が可能です。SOULの制約がなければ、親切なモデルがファイルを消したり、誤ったSlackチャンネルに投稿したり、顧客向け返信に内部ホスト名を漏らしたりします。MEMORYを誤用すると、チケットシステムより新しいデータを上書きする古いプロジェクト噂のダンプ場になります。ファイルを正しく保てば、コンテキストウィンドウを伸ばすよりインシデント件数を減らせる場面が多いです。
文章を編集する前に、ゲートウェイプロセスが安定しているかlaunchdの手順で確認してください。Nodeが再起動を繰り返しているのにMarkdownだけを疑っても時間の無駄になります。
さらに、外向きWebhookを使う構成では、SOULに「外向きHTTPの前に人間承認」などの一文を入れておくと、運用のブレを吸収しやすくなります。インフラ側でレート制限やIP許可をかけつつ、エージェント側でも二重にガードするのが2026年の無難な線です。
コアワークスペースファイル：早見表
ディストリビューションは進化しますが、多くの構成ではサービスユーザーの下にワークスペースフォルダ（しばしば隠しの.openclawツリー）があります。ファイル名はビルドドキュメントに従って調整しつつ、次の表をチームとの契約のたたき台にしてください。
| ファイル | 目的 | 保存してはいけないもの |
|---|---|---|
| SOUL.md（または同等） | 人格、拒否パターン、エスカレーション条件 | APIキー、顧客PII、未検証の第三者指示 |
| MEMORY.md | 長期事実、命名規則、リポジトリ地図 | パスワード、生トークン、時間依存シークレット |
| AGENTS.md / TOOLS.md | 宣言されたサブエージェントと呼び出し可能ツール | ClawHub系リスクで未レビューの実験プラグイン |
ワークスペース初期化・七段階
- 所有ユーザーを決める：LaunchAgentを動かすmacOSアカウントと一致させる。混在すると静かに読み取り失敗します。
- ディレクトリをスナップショット：
ls -laで権限を記録。Markdownは意図したスタッフのグループだけが読めるべきです。 - SOUL.mdの初稿：「ワークスペースルート外で
rm -rfを走らせない」や、外向きWebhookは確認必須、を含める。 - MEMORY.mdのシード：リポジトリURL、既定ブランチ、オンコール名を入れ、スプリントレビューで90日超の項目を退役させる。
- ツールマニフェストの整合：ホストが公開してはいけないツールを外す。特にTLS終端済みHTTPSで内向き接続があるマシンでは重要です。
- gitignoreの配線：ローカル作業パスを除外。Markdown横に置いた
.envをコミットしない。 - 再起動とドライラン：ゲートウェイを再起動し、MEMORYを参照する無害プロンプトを送り、ログに期待するハッシュやロード印が出るか確認する。
七段階のうち「所有ユーザー」と「権限」は初日に済ませ、残りは翌営業日に回すチームも多いです。いきなり長大なSOULを書くより、拒否ルールとエスカレーションだけを先に固め、MEMORYは最小構成から始める方が、後からの差分レビューが楽になります。
一台のMac mini上のチームサンドボックス
予算がシンガポールの単一Mac mini M4に収まり、エンジニアがソウルとサンフランシスコにいるようなときは、一つの可変MEMORYを共有するよりコンテキストを分割してください。デプロイ時だけ有効ワークスペースへシンボリックリンクするプロジェクト別サブフォルダや、CIでレビュー済みMarkdownだけをマージするGitブランチ運用が選択肢です。週末オンコール向けに内部Wikiへ「今どのブランチが本番か」を明記してください。
サンドボックスを分けたら、切り替え手順をRunbookに1ページ。誤って本番SOULを実験ブランチで上書きする事故は、権限ミスよりも手順の抜けが原因になりがちです。
Git、バックアップ、シークレット衛生
「社内」Gitでも請負がcloneすれば漏えいし得ます。MEMORYはアプリ設定と同じ扱いで、不要な顧客名は伏せ、会話全文ではなくチケットIDを参照し、秘密鍵はpre-commitでブロックします。バックアップはオフラインコピーを暗号化してください。Markdownは攻撃者にとっても架構のヒントになりやすいです。
運用目標：検索やRAGを入れない限り、SOUL＋MEMORYの合計をおおよそ8,000トークン相当に抑える。四半期ごとに、退役マイクロサービスに紐づく自動化記述を削除する。
複数人がSSH越しに同じMarkdownを編集するときは、非公式でもファイルロックやPR形式のレビューを導入してください。ラストライト勝ちの競合で、半分古い安全ルールと半分新しいマーケトーンが同居し、エージェントが矛盾した指示を同時に拾うことがあります。
さらに、バックアップからリストアしたあとに権限が変わるケースがあるため、リストア手順に「ls -laで再確認」を必ず入れておくと安心です。
トラブルシュート表
| 症状 | 有力な原因 | 対処 |
|---|---|---|
| 新しいSOULルールを無視 | ゲートウェイ未再起動またはユーザーパス違い | LaunchAgentのplist ProgramArgumentsを確認しreload |
| 時間によって矛盾した回答 | 古いMEMORYと生APIデータの競合 | MEMORYの箇条書きに日付。揮発状態はツール呼び出し優先 |
| ツール未検出エラー | TOOLS.mdと実インストールの不整合 | マニフェストをopenclaw doctor出力と突合 |
| 顧客チャットに機微文面 | 伏字ルールなしのMEMORY過共有 | 外部チャネル前にスクラブするSOUL条項を追加 |
よくある質問
SOULにブランドボイスを書くべきか？ はい。推奨の挨拶例と禁止フレーズを入れるとレビュー工数が減ります。
MEMORYをNotionから自動同期できるか？ 信頼できるツール経由でのみ。チャンク化なしでWiki全文を貼らないでください。
ワークスペース実験のリセットタイミングは？ majorなmacOSアップグレード後、またはMacLoginリージョン間の移行（HK、JP、KR、SG、US）のあと。パスと権限が変わることがあります。
MacLoginのMac mini M4がリッチなワークスペースに合う理由
大きなSOULとMEMORYは、無関係なXcodeインデックスとディスク・ユニファイドメモリを争奪していないとき読み込みが速いです。Apple Silicon Mac mini M4はMarkdown解析やツール子プロセス起動に単発性能の予測可能性があります。香港・日本・韓国・シンガポール・米国にホストを置けば、チャット運用者とWebhook送信元の両方にとって遅延を抑えられます。
本番エージェントとR&Dサンドボックスは別ホストを借り、実験SOULが誤って本番に載らないようにしてください。ツール追加に合わせメモリとCPUを料金ページで段階し、Markdownでは代替できない一度きりのGUI承認にはVNCを用意しておくとよいです。
最後に、ワークスペース変更は小さな差分で頻繁に出す文化にすると、巨大な一括更新よりレビューが回りやすくなります。OpenClawの価値は「賢い単発プロンプト」より「再現可能な運用境界」にあり、2026年はその境界をMarkdownでコード化する年だと捉えてください。
