OpenClaw マルチエージェントルーティング完全ガイド：仕事・生活・実験をきれいに分離する

月曜の朝 9 時、クライアント向けの決済 API コードを書くために AI アシスタントを開きました。すると突然、こう言われました。「昨夜調べていた『エルデンリング』のボス攻略に基づき、ここでも『ヒット＆アウェイ』戦略をおすすめします……」

その場で固まりました。

さらに気まずかったのは、画面共有中のオンライン会議だったことです。ビデオ越しの沈黙がどれほど痛いか、想像できるでしょう。

その瞬間、気づきました。AI アシスタントは賢くなっているのに、仕事・娯楽・実験を全部ひとまとめにしている。仕切りのない引き出しのようで、探すたびにごちゃごちゃし、よく間違ったものを取り出します。

同じ悩みがあるなら、この記事が役立ちます。週末を使って OpenClaw のマルチエージェントルーティングを調べた結果、AI アシスタントを複数の専属アシスタントに「分身」させる方法がわかりました。仕事は仕事、生活は生活、実験はサンドボックスへ。

なぜ必要か、設定方法、私が実際に使っている 5 シナリオを共有します。

低コストで「エビ」を飼う：ArkClaw が AI エージェントを身近に

話題の OpenClaw（ロブスター）は便利だが設定がハードル高め？ ByteDance Volcano Engine の ArkClaw はその壁をかなり下げました。サーバーや Token 設定をいじらず、ワンクリックで 24 時間オンライン、ブラウザ操作・スクリプト実行・カレンダー管理ができる AI アシスタントが手に入ります。

料金も安い：月額 9.9 元。招待コード ZLKUK54M（こちらから登録）なら 8.9 元。エンジニアなら Coding Plan Pro で実質無料で試せます。

AI アシスタントはなぜ「混線」するのか？

単一アシスタントの 3 つの気まずい瞬間

以前は 1 つの AI アシスタントですべてを処理していました。次のような場面に直面するまで。

シーン 1：コンテキスト汚染
会社の DB クエリ最適化を頼んだら、AI が突然「先週の Python スクレイピングと同様に非同期処理を……」と言い出しました。あのスクレイピングは副業用で、会社には知られたくない内容でした。

シーン 2：プライバシー漏洩
チームデモで対話履歴を開いたら、「上司への昇給交渉」「副業の確定申告」など私的な質問が並んでいました。あの「終わった」感、わかりますよね。

シーン 3：実験が本番を壊す
ファイル一括リネームの自動化をテストしたとき、AI が以前の仕事用ディレクトリを覚えていて、顧客プロジェクトのソースファイル名を全部書き換えました。Git がなければ夜逃げするところでした。

なぜこうなるのか？

AI 自体に悪気はありません。発言を覚え、文脈をつなごうとするからです。しかし：

仕事には厳格さとプライバシーが必要
生活にはリラックスとパーソナライズが必要
実験には自由が必要だが、本番への影響は NG

この 3 つは本来、混ぜるべきではありません。

マルチエージェントルーティングの考え方

OpenClaw のマルチエージェントルーティングは、各シナリオに独立した「小部屋」を与えます：

独立ワークスペース：work-agent は /work のみ、personal-agent は /personal のみ。ファイルシステムレベルで物理隔離
独立対話履歴：work で話したことは personal は知らない。逆も同様
独立権限：実験サンドボックスはオフライン・読み取り専用、仕事環境は社内 Git、生活環境は個人クラウド、など

Docker 用語では「コンテナ級隔離」。分かりやすく言えば、お互いに影響を与えない複数の「脳」を持たせるイメージです。

2026 年の AI セキュリティ基準では、エンタープライズはテナント級のデータ隔離が必須です。OpenClaw の Docker サンドボックス方式は、「会話グループを分けるだけ」のツールより安全です。

OpenClaw の 3 層隔離アーキテクチャ

最初は Gateway、Brain、Skills の用語に戸惑いました。自分で組んでみると、構造はシンプルです。

宅配のような 3 層

Gateway 層（集配）：Telegram、Discord、Slack などのメッセージを受け取り、設定に従いどのエージェントへ転送するか決める
Brain 層（管制）：意図（コード？調査？コマンド？）を判断し、タスクフローを組み立てる
Skills 層（実行）：実際の作業。各エージェントは独立 Docker コンテナでコード実行やファイル操作を行う

選べる 3 つの隔離レベル

セッション級隔離（一時タスク）
対話のたびに新コンテナを作り、終われば破棄。「この CSV を分析して」のような一度きり向き。クリーンだが、毎回環境構築が必要。

エージェント級隔離（長期シナリオ）
エージェントごとに常駐コンテナ。私の work/personal はこの方式。環境を一度組めばいつでも呼べる。最もよく使う。

OS ユーザー級隔離（セキュリティ最重視）
エージェントごとに別 OS ユーザー。金融・医療など超機密向き。私は未使用ですが、必要なら検討価値あり。

テストでは、エージェント級隔離下で agent-A のファイルを agent-B が触ることは（共有設定しない限り）不可能でした。安心感は大きいです。

私が使う 5 つの実践シナリオ

ここから実践編。実際の構成をそのまま参考にしてください。

シナリオ 1：仕事 vs 個人

課題：会社プロジェクトと個人ブログのコードが混ざる。コミット時に会社コードを個人 GitHub に上げそうになった。

解決策：

work-agent：D:\work、社内 GitLab の SSH 鍵、仕事用 API キーのみ
personal-agent：D:\personal、個人 GitHub、自由に実験

ポイント：
別々の .env で WORKSPACE_PATH を分ける。Telegram では @my_work_bot と @my_personal_bot を作り、今どちらと話しているか一目でわかるようにしています。

シナリオ 2：複数クライアントの隔離

課題：フリーランスで 3 案件並行。クライアント A への提案にクライアント B の命名規則が混ざった。事故はなかったがヒヤッとした。

解決策：
client-nike-agent、client-adidas-agent、client-puma-agent（仮名）

ポイント：

各エージェントに独立ディレクトリと Git
.env の PROJECT_NAME でログ追跡
各社の API キー・DB 設定は完全分離、絶対に交差させない

シナリオ 3：安全な実験サンドボックス

課題：一括ファイル処理スクリプトを試したいが、誤って重要ファイルを消すのが怖い。

解決策：
sandbox-agent で厳格サンドボックス。

ポイント：

ENABLE_NETWORK=false  # オフライン
HOST_FILESYSTEM_MODE=readonly  # ホストは読み取り専用
TEMP_STORAGE=true  # 変更は一時領域のみ。再起動で消える

コンテナを作り直せばホストは無傷。「怪しい操作」はまずここで試します。

シナリオ 4：チーム空間と個人空間

課題：チーム共有 AI に個人メモや ToDo が混ざり、プライバシーがない。

解決策：

team-agent：チーム共有。全員アクセス可
private-agent：自分専用。下書きや個人 ToDo

ポイント：
team-agent は NAS の共有パス、private-agent はローカル暗号化パーティション。Telegram では team はグループ、private は自分との DM のみ。

シナリオ 5：マルチモデル比較

課題：Claude、GPT-4、ローカル Llama を比較したいが、設定切り替えが面倒。

解決策：
claude-agent、gpt-agent、llama-agent を並列。

ポイント：
各 .env で LLM_PROVIDER と API_KEY を変え、同じ質問を 3 つに投げて品質・速度・コストを比較。

所感：コードは Claude が安定、雑談は GPT-4 が自然、機密は（遅いが）ローカル Llama が安心。

追加のコツ：

命名：シナリオ-用途-日付（例：client-nike-backend-20260201）
切り替え：スマホに複数 Telegram アカウント、スワイプで高速
リソース：使わないエージェントは docker stop

ハンズオン：最初のエージェントペア

Docker と OpenClaw の基本環境がある前提です（未導入なら公式クイックスタートへ）。

目標：work と personal の 2 エージェント

ステップ 1：設定ファイル

cd openclaw
cp .env .env.work
cp .env .env.personal

ステップ 2：work-agent
.env.work を編集：

AGENT_NAME=work-agent
WORKSPACE_PATH=/path/to/your/work/directory
TELEGRAM_BOT_TOKEN=work_bot の token
ALLOWED_USERS=あなたの Telegram ユーザー ID

ステップ 3：personal-agent
.env.personal を編集：

AGENT_NAME=personal-agent
WORKSPACE_PATH=/path/to/your/personal/directory
TELEGRAM_BOT_TOKEN=personal_bot の token
CONTAINER_PORT=8001  # ポート競合回避

ステップ 4：起動

docker-compose --env-file .env.work up -d
docker-compose --env-file .env.personal up -d

数秒後 Status: Running なら成功。

隔離を検証する 3 テスト

テスト 1：ファイル隔離

work：「test.txt を作り ‘work data’ と書いて」
personal：「カレントのファイル一覧を」
結果：personal から test.txt は見えない

テスト 2：対話隔離

work：「プロジェクト代号は ProjectX と覚えて」
personal：「プロジェクト代号は？」
結果：「知りません」

テスト 3：機能隔離

.env.work で ENABLE_CODE_EXECUTION=true
.env.personal で ENABLE_CODE_EXECUTION=false
結果：work のみコード実行可

3 つ通れば隔離は有効です。

よくある問題：

ポート使用中：CONTAINER_PORT をずらす
Bot 無反応：token と ALLOWED_USERS を確認
権限エラー：WORKSPACE_PATH のパーミッションを Docker が読み書きできるように

上級テクニックと落とし穴

数ヶ月の運用で得た知見です。

パフォーマンス：リソース食いつぶしを防ぐ

最初は 5 エージェント常時起動でメモリ 8GB、ファンが唸りました。

上限設定
docker-compose.yml に：

deploy:
  resources:
    limits:
      cpus: '0.5'
      memory: 512M

オンデマンド

# start-sandbox.sh
docker start sandbox-agent-container
# 終了後
docker stop sandbox-agent-container

ベースイメージ共有
全エージェントで同じ OpenClaw イメージを使い、設定だけ変える。ディスクは差分 1〜2GB 程度で済みます。

セキュリティ

最小権限
personal が /work を見る必要はないなら、マウントしない。

機密情報
API キーは環境変数。.env を Git に入れない（.gitignore 必須）。

定期監査

docker logs work-agent-container --since 7d | grep ERROR

トラブルシュート

起動しない

docker logs <コンテナ名>
多くはポート競合か権限

ルーティング失敗

Bot token、ALLOWED_USERS、curl で疎通確認

ファイル権限

ホストとコンテナの UID 不一致 → user: "${UID}:${GID}" を docker-compose に

これらの穴は私も踏みました。9 割はログで原因がわかります。

まとめと次のステップ

要点は 3 つ：

なぜ必要か：単一 AI は仕事・生活・実験の文脈を混ぜ、プライバシーと効率を損なう。物理隔離が解。

どう設定するか：別 .env、別作業ディレクトリ、別メッセージ入口。5 分で work/personal のペアが作れる。

運用：最小権限、オンデマンド起動、定期監査。安全と便利は両立できる。

毎日使っていますが、仕事に集中できる（副業の話が混ざらない）、実験が安心、デモでヒヤッとしない——メリットは大きいです。

次のアクション：

今日、上の手順で最初の work/personal ペアを作る
疑問は OpenClaw の GitHub Issues や Discord へ
同じ悩みの友人にシェア

AI ツールは生活を楽にするためのもの。マルチエージェントルーティングは AI アシスタントの「整理収納」です。役割を分ければ、ワークフローは驚くほどすっきりします。

試してみてください。きっと後悔しません。

OpenClaw デュアルエージェントワークフローの設定

work と personal の 2 つの独立エージェントをゼロから構成し、仕事と個人を物理的に分離する

Estimated time: PT10M

1

Step 1: 設定ファイルの準備

デフォルト環境ファイルを複製し、2 エージェント用の独立設定を作る：
2

Step 2: work-agent の設定

.env.work を編集し、次を必ず変更：
3

Step 3: personal-agent の設定

.env.personal は work との衝突を避ける：
4

Step 4: 起動と隔離の検証

2 エージェントを起動し、隔離を確認：
5

Step 5: 日常運用とメンテナンス

運用のコツ：
6

Step 6: • docker logs

grep ERROR で監査

FAQ

なぜセッション隔離ではなくエージェント隔離を推奨するのですか？

エージェント級隔離は長期利用に向いています。

• セッション級隔離：対話のたびに新しいコンテナを作り、終わったら破棄。一度きりのタスク向きだが、毎回環境を組み直す必要がある
• エージェント級隔離：コンテナが常駐し、環境設定が永続化され、いつでも使える。私の work/personal エージェントはこの方式

実感：起動後はずっと稼働し、応答が速い（コンテナ作成待ちなし）。環境変数や依存パッケージも残るので、日常ワークフローに最適。欠点はある程度のリソース消費だが、docker stop で使わないエージェントは止められる。

複数エージェントでメモリやディスクを食いすぎませんか？

適切に設定すればコントロールできます。

メモリ最適化：
• 1 エージェントあたり 512MB 上限（docker-compose.yml の resources.limits）
• 5 エージェントで約 2.5GB。ノート PC でも十分
• 使わないエージェントは docker stop で解放

ディスク最適化：
• 全エージェントが同じ OpenClaw ベースイメージ（約 500MB）を共有
• 追加は差分データのみ（通常 100MB 未満）
• 5 エージェント合計でも 1〜2GB 程度（500MB×5 ではない）

私の構成：常時 3 エージェント（work/personal/sandbox）、あと 2 つはオンデマンド。16GB メモリの PC で問題なし。

Telegram の bot token を取り違えないには？

命名規則と切り替えの工夫が有効です。

Bot 命名：
• 仕事：@my_work_bot、@company_project_bot
• 個人：@my_personal_bot、@my_hobby_bot
• 実験：@my_sandbox_bot

切り替え：
• スマホに複数 Telegram アカウントを入れ、各アカウントで別 bot に紐付け（スワイプで超高速）
• 同一アカウント内でも @work と @personal で区別
• アイコン色を変える（仕事=青、個人=緑、サンドボックス=黄）

管理：
• 全 token を 1Password/Bitwarden に集約
• .env に用途コメントを付ける
• .gitignore で token がコミットされないか定期確認

personal-agent から work-agent のファイルにアクセスできますか？

デフォルトでは完全に不可。これが物理隔離の肝です。

隔離の仕組み：
• 各エージェントの WORKSPACE_PATH が別ディレクトリ（/work と /personal）
• Docker はそれぞれの WORKSPACE_PATH のみマウントし、OS レベルで分離
• agent-A が作ったファイルは、agent-B からは一切アクセス不可

共有が必要な場合：
• 共有ディレクトリを volume で追加可能（例：/shared:/shared:ro は読み取り専用が安全）
• ただし隔離性が弱まるので非推奨。必要なファイルは手動コピーの方がよい

私の運用：仕事と個人は完全分離。共有は Git やクラウド経由で、エージェントの純度を保つ。

sandbox-agent をオフラインにすると AI モデルは使えますか？

オフラインではクラウドモデルは使えませんが、ローカルモデルは使えます。

制限：
• ENABLE_NETWORK=false では OpenAI/Claude などのクラウド API に届かない
• ファイル操作やスクリプト実行など、AI 推論不要なテスト向き

対策：
• ローカルモデル（Llama/Mistral）：サンドボックス内に Ollama などを配置
• またはネットは許可しつつアクセス範囲を制限：ファイアウォールで特定 API ドメインのみ許可
• 私の設定：サンドボックスはネット ON、HOST_FILESYSTEM_MODE=readonly。AI は呼べるがホストファイルは変更不可

用途：
• 純ファイル操作テスト：オフライン + 読み取り専用 FS
• AI 補助が必要な実験：ネット ON + ファイル権限を厳格化
• リスクに応じて隔離レベルを選ぶ

チーム利用時の ALLOWED_USERS はどう設定しますか？

複数ユーザーをカンマ区切りで指定できます。

例：
• 単一：ALLOWED_USERS=123456789
• 複数：ALLOWED_USERS=123456789,987654321,555666777
• チーム：team-agent に全員 ID、private-agent は自分だけ

ID の取得：
1. 各メンバーが @userinfobot に送って Telegram ID を取得
2. 管理者が集めて .env.work に記載
3. 反映後 docker-compose restart

セキュリティ：
• ALLOWED_USERS を定期監査し、退職者を削除
• 機密プロジェクトは専用エージェント + メンバー限定
• 操作ログにユーザー ID が残るので追跡しやすい

私の運用：team-agent は 5 人チーム、private-agent は自分のみ。境界が明確。

設定ミスでエージェントが起動しないときは？

体系的に切り分ければ早く直せます。

まずコンテナログを確認：
• docker logs <container_name>
• 9 割はログに原因（ポート競合、権限不足、設定ミス）

よくあるエラー：
• 「ポート使用中」：.env の CONTAINER_PORT を 8001/8002 など未使用に変更
• 「WORKSPACE_PATH がない」：パス確認または mkdir
• 「Telegram bot token 無効」：@BotFather で再確認。コピー時の前後空白に注意
• 「Permission denied」：WORKSPACE_PATH に chmod 755

デバッグ：
• 正常なエージェントの .env と差分比較
• 最小構成でテスト：AGENT_NAME / WORKSPACE_PATH / TELEGRAM_BOT_TOKEN のみ
• オプションを 1 つずつ追加して原因特定

最終手段：docker-compose down && docker-compose up で作り直し。Docker なら何度でも試せる。

5分で読めます · 公開日: 2026年2月5日 · 更新日: 2026年6月15日

Easton

AI・インテリジェンス

シリーズの読書導線第 15 / 36 記事

OpenClaw 導入と実践

検索からこのページに来た場合は、前後の記事もあわせて読むと同じテーマの理解がかなり早く深まります。

シリーズ全体を見る

OpenClaw ローカル記憶システム解説：Markdown で AI 記憶を保存する

OpenClaw が Markdown ファイルで AI の永続記憶を実現する仕組みを深掘り。2 層アーキテクチャ、ハイブリッド検索、ローカルプライバシー保護まで解説。

第 14 / 36 記事

OpenClawアーキテクチャ徹底解説：3層設計の技術原理と拡張実践

OpenClaw の Gateway（セッション管理）、Channel（メッセージルーティング）、LLM（モデルインターフェース）の 3 層アーキテクチャを徹底解説。二次開発と拡張の実践ガイド付きで、OpenClaw の中核メカニズムを押さえられます。

第 16 / 36 記事

2026年2月4日 AI・インテリジェンス

OpenClaw クラウド vs ローカル：最適なデプロイの選び方

GitHubアカウントでログインしてコメントできます

AI アシスタントはなぜ「混線」するのか？

単一アシスタントの 3 つの気まずい瞬間

なぜこうなるのか？

マルチエージェントルーティングの考え方

OpenClaw の 3 層隔離アーキテクチャ

宅配のような 3 層

選べる 3 つの隔離レベル

私が使う 5 つの実践シナリオ

シナリオ 1：仕事 vs 個人

シナリオ 2：複数クライアントの隔離

シナリオ 3：安全な実験サンドボックス

シナリオ 4：チーム空間と個人空間

シナリオ 5：マルチモデル比較

ハンズオン：最初のエージェントペア

目標：work と personal の 2 エージェント

隔離を検証する 3 テスト

上級テクニックと落とし穴

パフォーマンス：リソース食いつぶしを防ぐ

セキュリティ

トラブルシュート

まとめと次のステップ

OpenClaw デュアルエージェントワークフローの設定

Step 1: 設定ファイルの準備

Step 2: work-agent の設定

Step 3: personal-agent の設定

Step 4: 起動と隔離の検証

Step 5: 日常運用とメンテナンス

Step 6: • docker logs

FAQ

OpenClaw 導入と実践

OpenClaw ローカル記憶システム解説：Markdown で AI 記憶を保存する

OpenClawアーキテクチャ徹底解説：3層設計の技術原理と拡張実践

関連記事

OpenClaw 改名の全貌：Clawdbot から Moltbot、そして OpenClaw への変遷

OpenClaw 改名の全貌：Clawdbot から Moltbot、そして OpenClaw への変遷

OpenClaw 完全インストールガイド：環境準備から初回実行まで

OpenClaw 完全インストールガイド：環境準備から初回実行まで

OpenClaw クラウド vs ローカル：最適なデプロイの選び方

OpenClaw クラウド vs ローカル：最適なデプロイの選び方

コメント