結論からお伝えします。一つのOpenClawゲートウェイで、異なるモデルを使う複数のエージェントを同時運用するのは、設定数行で終わる話ではありませんでした。私たちはこの過程を2本の記事に分けて扱いましたが、今回統合改訂のために見直したところ、内容の重複が多く、ゲートウェイのポート番号のように記事間で食い違う情報もありました。この記事はその2本を1本にまとめ、間違っていた部分を修正し、5か月前に立てた次の目標が実際どうなったのかまで確認した総合ガイドです。

🔍 概要 ― なぜエージェントを複数運用するのか

AIを秘書のように使うには、24時間稼働し続けてチャットで話しかければ即座に応答するシステムが必要です。それも一人だけでなく、異なるモデルを使う複数のエージェントが、それぞれのチャンネルで独立して動く形です。この記事はOpenClawゲートウェイ一つでシウォル（Gemini基盤）とレッド（Grok基盤）の2エージェントを同時運用しながら経験した設定プロセスをまとめています。設定の試行錯誤、ルーティングの原理、重複応答のトラブルシューティングまで全て含みます。

🏗️ 全体構造 ― 一つのゲートウェイ、二つの頭脳

核心原則はシンプルです。シウォルはGeminiのみ、レッドはGrokのみ使用します。モデルが絶対に混ざらないよう、フォールバックまで同一プロバイダーに制限しました。各エージェントは別々のDiscordボットアカウントを使用し、チャンネルへのアクセスは物理的に分離されています。

⚙️ openclaw.json 主要設定の解剖

OpenClawマルチエージェント設定の核心は、~/.openclaw/openclaw.jsonの3つのセクションです。

1. agents ― エージェント定義

各エージェントのID、名前、モデル、ワークスペースを宣言します。

"agents": {
  "list": [
    {
      "id": "main",
      "name": "시월이",
      "workspace": "~/.openclaw/workspace",
      "model": {
        "primary": "vertex-ai/gemini-3-flash-preview",
        "fallbacks": ["vertex-ai/gemini-3-pro-preview"]
      }
    },
    {
      "id": "red",
      "name": "레드",
      "workspace": "~/.openclaw/workspace-red",
      "model": {
        "primary": "xai/grok-4-1-fast-reasoning",
        "fallbacks": ["xai/grok-4-0709"]
      }
    }
  ]
}

2. bindings ― ルーティングルール

どのDiscordボットアカウントがメッセージを受信したら、どのエージェントが応答するかを決定します。マルチエージェントの核心メカニズムです。

"bindings": [
  { "agentId": "main", "match": { "channel": "discord", "accountId": "siwol" } },
  { "agentId": "red", "match": { "channel": "discord", "accountId": "red" } }
]

3. channels.discord ― チャンネルアクセスの分離

各ボットアカウントがアクセスできるチャンネルを物理的に分離します。guildsを共通設定ではなく各account内に配置するのがポイントです。

"accounts": {
  "siwol": {
    "guilds": { "サーバーID": { "channels": { "シウォルチャンネルID": { "allow": true } } } }
  },
  "red": {
    "guilds": { "サーバーID": { "channels": { "レッドチャンネルID": { "allow": true } } } }
  }
}

こうするとルーティングの流れは次のようになります。

Discordメッセージ受信
  ↓
どのボットアカウントが受信したか？
  ├── siwolボット → bindingsでaccountId="siwol"にマッチ
  │   → agentId="main"（シウォル、Gemini）
  └── redボット → bindingsでaccountId="red"にマッチ
      → agentId="red"（レッド、Grok）

accountIdベースのマッチングなので、きれいに分離されます。DMもボットアカウントごとに自動的に分離されるため、シウォルにDMを送ればシウォルが、レッドに送ればレッドが応答します。

🧠 ワークスペース ― エージェントの魂

各エージェントの性格、記憶、行動ルールはワークスペースファイル群によって定義されます。OpenClawは毎セッション開始時にこれらのファイルを読み込み、エージェントのコンテキストを構成します。

~/.openclaw/workspace/        (シウォル)
├── SOUL.md       ← 素直で温かい性格、丁寧語
├── IDENTITY.md   ← 名前、絵文字(🌸)
├── USER.md       ← ユーザー情報
└── AGENTS.md     ← 行動ルール

~/.openclaw/workspace-red/    (レッド)
├── SOUL.md       ← 大胆でスパイシーな性格、タメ口
├── IDENTITY.md   ← 名前、絵文字(🔥)
├── USER.md       ← ユーザー情報 + 境界線設定
├── AGENTS.md     ← 行動ルール
└── memory/       ← 日付別の記憶記録

SOUL.mdがエージェントの根本的な性格を決定します。同じプロンプトを投げても全く異なるトーンで応答するのはこのファイルのおかげです。こうしてワークスペースを分離すると、シウォルに話した内容がレッドに漏れることはありません。

🔧 トラブルシューティング ― 実戦で起きたこと

1. 重複応答の問題。 セットアップ直後、シウォルが同じ応答を3~4回繰り返し送信する現象が発生しました。原因は2つありました。

原因A ― debounce未設定。 OpenClawには連続受信メッセージを一つにまとめるデバウンス機能がありますが、デフォルト設定にはこの値が抜けていました。

"messages": {
  "inbound": {
    "debounceMs": 2000
  }
}

原因B ― queue.mode未設定。 キューモードをcollectに設定し、連続メッセージを収集してから一度に処理するようにしました。

"queue": {
  "mode": "collect"
}

2. 設定エラー4つ。 上記の重複応答以外にも、設定過程で実際に遭遇したエラーメッセージ基準で整理します。

3. ゲートウェイのポート競合 & 無限再起動。 WSL起動時にsystemdがOpenClawサービスを自動起動しますが、ポートが既に占有された状態で再起動を試みると無限ループに陥りました。サービス依存関係の設定とポート解放確認ロジックの追加で解決しました。

4. ポートフォワーディング（NATモード）。 WSL2はNATモードで動作するため、外部から直接アクセスできません。PowerShellスクリプトでWindowsホストからWSLポートへの自動フォワーディングを設定しました。

🔌 MCPツール連携 ― AIに手と足を

エージェントが本当に役立つには、話すだけのAIではなくツールを使える必要があります。OpenClawのmcporterを通じてMCPサーバーを接続すると、シウォルとレッドが直接外部サービスを利用できます。

特にKnowledge RAGは、ConfluenceとJiraの全ドキュメントをチャンキング→埋め込み→ベクトルDB化したシステムのため、「あの時のポート競合、どう解決したっけ？」といった自然言語の質問で過去の記録を即座に見つけられます。

📊 運用状況 ― 2週間動かした結果（2026年2月時点）

WSL上でのリソース負担はほぼありませんでした。API基盤のため、2エージェント合計でRAM 100~200MB、CPUは待機時ほぼ0%でした。

🔄 では、今はどうなのか？

上記の内容は2026年2月時点の記録です。5か月半が経った今、実際のGitHub・公式ドキュメントと一つずつ照合してみました。

次の目標 ― 実際どうなったか。 当時の記事は「シウォルがコード実行が必要だと判断したら自動的にレッドに引き渡す」エージェント間自動ハンドオフを次の目標として掲げていました。確認の結果、この構想は構想通りには実現しませんでした。 公式ドキュメント（docs.openclaw.ai/concepts/delegate-architecture）によれば、委任は今も事前定義された静的bindingsベースであり、タスク内容を見て動的に判断して引き渡す方式ではありません。エージェント間の直接メッセージング自体は存在しますが（docs.openclaw.ai/concepts/multi-agent）、デフォルトはオフになっており、明示的な有効化+許可リスト登録が必要です。sessions_spawn/sessions_sendのような、上位エージェントがプログラム的に他のエージェントへ委任するツールは存在しますが、これも運用者が自分で設計しなければならない手動構成です。まとめると、自動分類・自動委任というビジョン自体はまだturnkey機能としては実現しておらず、代わりに手動で構成すべき隣接ツールが登場した、という状況です。

レッドは今どうなっているか。 この部分はGitHubで確認できる事実ではなく、私たちのチーム内部記録の問題でした。再検証の過程で、レッドが現在のチーム構成に含まれているか確認する必要がありましたが、私たち側の記憶照会では確認できず、この質問自体をTerryに別途伝えてあります。この記事ではシウォル・レッドという構成を2026年初頭時点の実験記録として扱い、レッドの現在の状態については断定しません。確認され次第、この節を更新します。

設定項目別には次の通りです。

• bindingsの最上位配置 ― 今もそのまま有効です。スキーマ自体は安定しています。
• debounceMs / queue.mode ― 今も有効な設定キーです。ただしdebounceMsは現在2000msのデフォルト値が付いて出てくるようになり、queue.modeは当時のcollect一つだけだったオプションがsteer/followup/collect/interruptの4つに増えました。デフォルト値ができた分、当時の記事が強調していた「必ず手動設定」の必要性は、以前ほど切実ではないかもしれません。
• ワークスペースファイル構造 ― SOUL.md/IDENTITY.md/USER.md/AGENTS.mdは今もコアです。ただし現在の公式ドキュメントは、TOOLS.md、MEMORY.md、HEARTBEAT.mdまで含めた、より広いブートストラップファイルリストを案内しています。この3ファイルは当時の記事にはなかった項目です。
• mcporter ― 変更なく、今も標準のMCP連携ツールです。

🧭 まとめ

今回の統合改訂で最も重要なのは3点です。第一に、ゲートウェイのポート番号（19876 → 18789）のように、既存2記事の間で食い違っていた部分を正しました。第二に、次の目標として掲げていたエージェント間自動ハンドオフは構想通りには実現しませんでしたが、手動で構成可能な隣接機能が登場しました。第三に、ワークスペースのブートストラップファイルが4種類から最低7種類に増えたように、設定の対象範囲自体が広がっています。今マルチエージェントを新しく設定される場合は、上記「openclaw.json 主要設定の解剖」の節と「では、今はどうなのか？」の節を併せてご覧いただくことをおすすめします。

📚 参考資料

• OpenClaw GitHub
• OpenClaw公式ドキュメント ― Agent Bindings & Routing
• OpenClaw公式ドキュメント ― Gateway CLI（デフォルトポート確認）
• OpenClaw公式ドキュメント ― Delegate Architecture
• OpenClaw公式ドキュメント ― Multi-Agent Messaging
• OpenClaw公式ドキュメント ― Agent Workspace
• OpenClaw公式ドキュメント ― mcporter