引っ越し：共有サーバーから独立PCへの環境分離
システムが複雑になるにつれ、「すべてを一台のマシンで動かす」ことは利便性からリスクへと変わります。この記事では、OpenClawを共有ワークサーバーT440から独立PCに移行した過程を記録します——一見シンプルだが、実はアーキテクチャ思考の転換を伴う「引っ越し」でした。
なぜ引っ越すのか
T440（192.168.x.x）はずっとワークサーバーとして、ファイル共有、開発環境、プロジェクトコードなど様々なサービスを動かしていました。後にOpenClawもデプロイしましたが、Agent数の増加とモデル呼び出しの頻度が上がるにつれ、問題が露呈しました：
1. リソース競合：OpenClawのgatewayプロセスがピーク時に大量のメモリを消費し、T440上の他サービスの安定性に影響
2. セキュリティ境界の曖昧さ：OpenClawのagentにはシェル実行能力があり、業務データと同一マシン上で動作。一つの誤操作でプロジェクトファイルに波及する可能性
3. 運用の結合：OpenClawを再起動したくても他サービスを考慮し、システムをアップグレードしたくてもOpenClawの互換性を考慮——互いに制約
これら3つの問題の本質は同じです：分離の欠如。
新しいアーキテクチャ
引っ越し後、3台のマシンがそれぞれの役割を担います：
- PC-A（192.168.x.x）：OpenClawメインホスト、ユーザーopenclaw01、8GB RAM、gateway とmain agentの専用マシン
- PC-B（192.168.x.x）：スタンバイ機、ユーザーopenclaw02、待機状態、フェイルオーバーを担当
- T440（192.168.x.x）：純粋なワークサーバーに復帰。ワークagent、Dashboard、ファイルサービスを実行
8GB RAMは少なく見えますが、OpenClawのgateway自体はNode.jsプロセスで、実際の消費量は大きくありません。リソースを本当に消費するのはモデル呼び出しですが、それはクラウドAPIの話です。
SSH公開鍵認証
3台のマシン間で頻繁な通信が必要です。パスワード手動入力は非現実的なので、SSH公開鍵認証を設定。
ssh-keygen -t ed25519
ssh-copy-id linou@192.168.x.x
ssh-copy-id openclaw02@192.168.x.x
小さな落とし穴：新規ユーザーのホームディレクトリで.sshのパーミッションは700、authorized_keysは600でなければなりません。そうでないとSSHが黙って公開鍵認証を拒否し、明確なエラーも出ません。半日のデバッグでようやくパーミッションの問題だと判明しました。
分離後のメリット
引っ越し完了後、メリットは即座に現れました：
リソースの独立：PC-Aの再起動はT440のサービスに影響せず、T440のメンテナンスはOpenClawの動作に影響しません。
セキュリティ境界の明確化：openclaw01ユーザーはPC-A上でのみ権限を持ち、T440へのSSHアクセスは制限付きアカウントを使用。
運用の自由：OpenClawのアップグレードはPC-Aで直接操作し、他サービスへの影響を心配する必要なし。
考察
多くの人は「内部ネットワークだし、一緒に動かせば便利」と考えます。確かに便利ですが、その代償は結合です。システム規模が小さいうちは結合は問題になりませんが、システムは必ず成長します。
環境分離は高度な技術ではなく、異なる責任のサービスを異なるマシンに配置するだけです。しかしこの判断自体が一つのアーキテクチャ意識を反映しています：問題が事故に発展する前に、能動的に境界を確立する。
時に一歩退くことは、二歩進むためです。引っ越しも、アーキテクチャも同じです。