単一ホストで OpenClaw Gateway は動いているものの、同一マシンに複数の業務リポジトリを載せる必要があるとき、ディレクトリの踏み合い、トークンの混線、広すぎる MCP サーフェス、アップグレード後に静かにずれる cron が気になります。本稿ではプラットフォームエンジニアリングおよび自動化の責任者向けに、サインオフできる本番ベースラインを示します。まず七つのチェックでマルチプロジェクト運用の実リスクを洗い出し、次に対照表で「単一 Gateway・複数 Workspace」と「複数インスタンス」を整理し、最後に六ステップの Runbook を提示します。サイト内の 本番向け認証トリアージ、cron の健全性、MCP ホワイトリスト とあわせて読むことで、モデルの品質問題と設定問題を取り違えないようにします。
OpenClaw の強みは、モデル・ツール・チャネルを観測可能な Gateway に収束させることです。複数の事業線を一つのプロセス境界に詰め込むと、典型的な失敗は「モデルが劣化した」ではなく権限、cron、MCP の組み合わせ爆発になります。以下はロールアウト前のセルフチェックです。該当が多いほど、ディレクトリ・実行ユーザー・ツールホワイトリストを文書と契約に落とし、エンジニアの善意だけに頼らないようにしてください。
Workspace を「フォルダ名を変えるだけ」と見なす：サービスアカウント、ログ出力先、バックアップパスを揃えないままだと、アップグレードやロールバック後に一部プロジェクトだけ古い設定を読む幽霊障害が出ます。
MCP のツール一式を既定で全開にする：ツールが増えるほど下流のハングやタイムアウト確率が上がります。一度詰まると共有 Gateway のイベントループ全体が重く見え、全チャネルの遅延が上がります。
cron を systemd と LaunchAgent の両方に登録する：アップグレード後に二重実行や静かな欠落が起き、「OpenClaw が不安定」と誤認されがちですが、実際はサービス境界が緩いだけです。
Gateway トークンとプロバイダキーを台帳の同じ列に混ぜる：調査で値が上書きされ、Unauthorized と「No API key」が交互に現れます。監査軸は分割し、詳しくは認証の記事を参照してください。
アップグレード後の固定検収順がない：UI だけ見て openclaw doctor を走らせないと、スキーマ変更後も半互換設定が数週間残ります。
CI とポートやテンポラリを奪い合う：リモート Mac や共有ビルダーでは、Gateway の既定リスナとビルドキャッシュを隔離しないとポート競合や I/O 飢餓が散発します。
「誰がホワイトリストを広げられるか」を変更フローに書かない：監査なしでツールが増えると、最小露出は一度で崩れます。
共通の根本原因は、Gateway をステートレスなリバースプロキシだと見なすことです。長期間資格情報・子プロセス・スケジュールを抱えるため、半永続状態にはすべて名前空間が必要です。Workspace は名前空間を口頭約束から監査可能なパスと設定スライスへ引き上げます。プラットフォーム標準が既にある組織では、OpenClaw を変更チケット、ロールバック窓、オンコール Runbook と同じ枠に置き、AI チームだけのブラックボックスにしないことが重要です。
MCP ホワイトリスト記事 と整合させる際は、ツールと業務ドメインの対応を決め、同一ツールがプロジェクトごとに異なるパラメータ空間を許容するか判断してください。不可なら Workspace かインスタンスを分割します。「stdio MCP の方が軽い」という誤解にも注意してください。並列が上がると子プロセスの寿命管理と RSS 曲線が敏感になり、運用記事のとおり監視と並列上限が要ります。
マルチプロジェクト Gateway を24/7 のリモート Macや Linux 本番に置く場合、同じ箱で重いコンパイルやディスク負荷を背負っていないかも問う必要があります。そうなら Gateway のディスク余裕、cron の窓、CI ピークを一枚のラフな時系列にまとめない限り、「CPU は低いのに P99 が悪い」という定番のパターンが残ります。次の表でアーキテクチャ議論をレビュー資料に収束させます。
銀の弾丸はありません。小規模チームは単一 Gateway と厳格なホワイトリストで素早く回し、成長段階では強い隔離が要るワークロードをインスタンス分割し、弱い隔離の多リポジトリは Workspace に載せるのが一般的です。レビューでは次の三つを明文化してください。変更の追跡可能性、障害の爆発半径、アップグレード窓の長さです。
| 観点 | 単一 Gateway＋複数 Workspace | 複数 Gateway インスタンス（ポート／ユニット分割） | 物理的にマシン分割 |
|---|---|---|---|
| 隔離の強さ | 設定とディレクトリ境界。プロセスとアップグレードサイクルは共有 | プロセス隔離。独立ロールバック可 | 最強。コストと運用負荷も最大 |
| 運用コスト | 低〜中。厳しいホワイトリストと変更規律が前提 | 中。監視とバックアップが重複 | 高。厳格なコンプライアンスやマルチテナント向き |
| 典型的な故障 | 広すぎるツール面が共有ループを停滞させる | ポート、トークン、systemd ユニットの取り違え | 機械の碎片化と設定ドリフト |
| 監査への優しさ | 中。ログフィールドでプロジェクトを識別する前提 | 高。サービス単位の台帳が自然 | 高。会計科目も切りやすい |
| CI 同居 | ピークをずらしディレクトリを隔離必須 | Gateway を静かなコアに固定可能 | 専用ホストなら最もシンプル |
「Workspace はフォルダのマーケ用語ではなく、リスク面を監査可能な境界に書き下すものです。ホワイトリスト、cron、ログ出力先が同じ名前空間を指します。」
エンタープライズビルドプールを導入している場合は、Gateway の並列と署名ジョブのピークをずらしてください。Workspace は設定境界の話であり、キーチェーン争奪は解決しません。認証記事 と連動させ、複数 Workspace があっても「Gateway トークンのローテーションウィンドウ」を統一し、プロジェクトごとの独自キー運用を増やさないことです。
単一 Gateway＋複数 Workspace に寄せた結論なら、バックアップとリストアも更新してください。設定ディレクトリと鍵資料を定期的にスナップショットし、アップグレード前に「設定だけ戻しモデルは再インストールしない」演習をします。初めてちゃんとリストアするのがインシデント直後、というチームは後遺症コストが高くなりがちです。
複数インスタンスなら、ヘルスプローブとログインデックスのフィールドを揃えないとオンコールがホスト間を跳び回りトリアージ時間が跳ね上がります。最後に cron 記事 と整合させ、インスタンスごとにジョブ名を一意にし、systemd テンプレートのコピーで WorkingDirectory を書き換え忘れないようにしてください。
順序は「境界→ツール→スケジュール」です。本番デプロイメントガイド の Node ベースラインと揃え、Workspace が第二の未記録ランタイムにならないようにします。
Workspace ごとにルートディレクトリと実行ユーザーを固定：絶対パスを文書化し、シェルのカレントディレクトリ依存を禁止します。
最小 MCP ホワイトリストのファミリを定義：読み多め書き少なめ、書き多め、読み取り専用オブザーバビリティの三段に分け、まず最も厳しいセットで出してチケットで順に広げます。
cron を登録し検収コマンドを記載：アップグレード後は必ず openclaw cron status と list を実行し、件数と最終実行時刻を確認します。
トリアージ順を固定：gateway status → channels status --probe → openclaw doctor。最初にモデルルートをいじって設定問題を隠さないようにします。
ログフィールドをプロジェクト次元に揃える：workspaceId、jobId、ツール名、レイテンシを最低限含め、同居ホストでのコスト帰属ができるようにします。
CI ピークと時間をずらす：重い cron は夜間へ、日中は軽いプローブだけにして xcodebuild とディスクを奪い合わせないようにします。
#!/usr/bin/env bash set -euo pipefail openclaw gateway status || true openclaw channels status --probe || true openclaw cron status || true openclaw doctor
ヒント：同じホストで セルフホステッド Runner を動かす場合は、Gateway の作業ディレクトリと Runner のルートをパーティションごとに分け、クリーンアップがセッションファイルを消さないようにします。
GitHub Actions や GitLab CI で設定ドリフト検知を走らせるなら、このスクリプトを日次カナリアに載せ、失敗したらチケットを切ります。リモート Mac ではスリープや省電力ポリシーを Gateway 常駐ポリシーと同じページに書かないと、「昼は安定、夜は不安定」という見かけの相関に振り回されます。
複数チーム共有プールでは「誰が MCP を追加できるか」「追加前のセキュリティレビュー閾値」を内部ドキュメントに明記してください。さもなくば Workspace を増やしても万能鍵一枚で貫通します。設計は買えますが、組織の約束は先に必要です。
権限トラブルの典型は「sudo を一度かけると緑になる」ことです。実行ユーザーとディレクトリ所有者が一致していません。サービスアカウントと人手でのブレイクグラスアカウントを分離し、一時昇格の承認とロールバックを Runbook に書いてください。Workspace が増えるほどプロジェクトごとに異なる uid を許すと、バックアップとログ収集が維持不能になります。
cron は cron 記事 と同じ順で見ます。アップグレード直後は新機能より旧ジョブが残っているか・二重登録されていないかが先です。cron の「静かな失敗」はクラッシュより厄介なので、終了コードとレイテンシのヒストグラムをログに明示します。
注意：本番のプロバイダキーを複数 Workspace が読める world-readable パスに平文で置かないでください。最小権限はファイルシステム ACL とシークレットマネージャに載せ、口頭約束に頼らないようにします。
MCP は ホワイトリスト記事 と同様に、ツール単位でタイムアウトと並列上限を設定し、「下流が固まった」を一次インシデントとして扱います。stdio と HTTP MCP の運用曲線は異なり、短命の子プロセス群か接続プール付きマイクロサービスかで見え方が変わります。
SSH 主軸 CI の記事どおり、Gateway の調査も SSH ログを主とし、VNC はブレイクグラスに限定します。リモート Mac で UI 自動化と Gateway を同居させる場合は、GPU とメモリのスパイクが両方の P99 に積み上がる点にも注意してください。
最後に「最小権限＋最小ツール面」をオンコール手順に書きます。いつ臨時でツールを足せるか、誰が承認するか、どれだけの窓か、証跡をどう残すか。無いチームは「急いている人が勝つ」になり、監査も安定性も破綻します。
社内調整向けです。閾値はツール数とチャネルトラフィックに合わせてください。
ノート PC はスリープ、アップデート、デスクトップ作業で常駐 Gateway を中断しやすく、スクリプト専用機だけでは Apple ツールチェーンの視覚的トリアージがしにくいです。複数 Workspace の OpenClaw を専用・常時オンライン・SSH 可能なリモート Mac に載せれば、権限、cron、MCP の境界を契約として書けます。不安定な共有環境や同僚マシンの借用に頼ると、設定ドリフト、鍵の混線、リソース競合で止血コストが続きます。調査ウィンドウが伸び、自動化キューが支配し、コストは説明しにくい工数と機時間として現れます。固定 SSH、はっきりしたディスクティア、再現可能なノード像が必要なチームには、NodeMini のクラウド Mac Mini レンタルがプラットフォームエンジニアリングに載せやすいことが多いです。仕様と料金は Mac Mini レンタル料金 で比較し、オンボーディングはヘルプセンターと合わせて進めてください。
運用では本 Runbook を社内の「自動化レベル」と結びつけると説明が楽です。L1 は単一 Workspace、L2 は複数 Workspace で共通ホワイトリスト基線、L3 で業務別ホワイトリスト、L4 で複数インスタンス。レベルアップごとに監視ゲートを添え、口頭要件だけで広げないようにします。そうして初めてレンタルコストとキュー体験を財務と開発が同じ物差しで読めます。
Workspace は同一の信頼ドメイン内で設定とディレクトリを分ける用途に適しています。複数インスタンスは強い隔離や独立したアップグレードサイクル向けです。複数リポジトリでもチームが共有しているだけなら、まず Workspace と最小 MCP ホワイトリストを優先してください。
まずサイト内の cron 記事を読み、openclaw cron status と list で突き合わせます。続けて openclaw doctor でスキーマ変更を確認します。プラットフォーム支援が必要なら ヘルプセンター を参照してください。
Mac Mini レンタル料金 で専用ティアと外向き帯域を比較し、並列度、cron、MCP ツール数を受け入れチェックリストに書き込みます。本文の Runbook とあわせてオンコールへ渡せば引き継ぎが済みます。