【備忘】OpenClaw複数AIエージェントをDiscordで運用
OpenClawを触ったので設定から利用までの備忘
概要
- 複数エージェント構成のメリット
- 前提条件とインストール手順
- 具体的なセットアップ手順
- ワークスペースファイルの設定例
- 外部連携（GitHub、メール、ローカルLLM）
- 実際の運用パターンとユースケース
なぜ複数Gateway構成なのか
1. 障害耐性 — 相互監視・復旧
単一Gatewayでは、AIが自分自身を修復することは困難です。
実例: メインGatewayが設定ミスで起動不能に陥った際、サブGatewayが異常を検知。設定ファイルの不備を特定・修正し、Gatewayを復旧させました。
複数Gatewayなら、他のエージェントが救援できます。
2. 専門性の分離
人間の組織と同様に、役割を分けることで各エージェントが専門領域に集中できます。
- マネージャー: 全体俯瞰、意思決定、報告
- 実装担当: コード実装、デバッグ、PR管理
3. コンテキストの独立
各Gatewayは独立したセッションを持ちます。Project-Aの長い議論がProject-Bのコンテキストを圧迫することがありません。
4. コスト最適化
役割に応じてモデルを使い分けることで、コストを最適化できます。
- マネージャー: 高性能モデル（判断・統括用）
- 実装担当: 軽量モデル or コード特化モデル（実装作業用）
- 単純タスク: ローカルLLM（$0で処理）
前提条件
必要な環境
- OS: macOS / Linux / Windows (WSL)
- Node.js: v18以上
- Discord: サーバー管理権限があるアカウント
- API Key: Anthropic / OpenAI / OpenRouter など（利用するモデルに応じて）
オプション（推奨）
- Ollama: ローカルLLMでメモリサーチを$0運用
- himalaya: CLIメールクライアント（メール連携用）
- GitHub CLI (gh): リポジトリ連携用
インストール手順
1. OpenClawのインストール
# npmでグローバルインストール
npm install -g openclaw
# バージョン確認
openclaw --version
2. 初期セットアップ
# ウィザードを起動
openclaw onboard
# 対話形式で以下を設定:
# - APIキー（Anthropic / OpenRouter等）
# - デフォルトモデル
# - ワークスペースディレクトリ
3. Gateway起動
# Gatewayを起動
openclaw gateway start
# ステータス確認
openclaw gateway status
4. 複数Gateway用の追加セットアップ
2台目以降のGatewayは、別ディレクトリで設定します。
# 例: 2台目用ディレクトリ
mkdir -p ~/gateways/agent-b/.openclaw
cd ~/gateways/agent-b
# 設定ファイルを作成（後述）
# ポートを変えて起動
openclaw gateway start
構成イメージ
┌─────────────────────────────────────────────┐
│ Discord Server │
│ ┌─────────┐ ┌─────────┐ ┌─────────────┐ │
│ │#agent-a │ │#agent-b │ │ #internal │ │
│ │ (専用) │ │ (専用) │ │ (共通) │ │
│ └────┬────┘ └────┬────┘ └──────┬──────┘ │
│ │ │ │ │
└───────┼───────────┼─────────────┼───────────┘
│ │ │
┌────▼────┐ ┌────▼────┐ ┌─────▼─────┐
│OpenClaw │ │OpenClaw │ │ OpenClaw │
│ :18800 │ │ :18810 │ │ :18789 │
│(AgentA) │ │(AgentB) │ │ (Manager) │
└─────────┘ └─────────┘ └───────────┘
各エージェントは自分専用のチャンネルを持ちつつ、#internalのような共通チャンネルでお互いに会話・協力できます。
セットアップ手順
1. Discord Botを作成して招待
エージェントごとに別々のBotを作成します。
- Discord Developer Portal でBotを作成
- 必要権限を付与してサーバーへ招待
- View Channels
- Send Messages
- Read Message History
- Add Reactions（任意）
- Botトークンを控える（公開しない）
2. チャンネル設計
- 専用チャンネル: 各エージェントへの個別依頼・長文作業
#internal: エージェント同士の連携、進捗共有、引き継ぎ
運用ポイント：
- #internal は requireMention: true にして誤反応を減らす
- 誰に話しかけるかを明確にするため、メンション運用を徹底
3. openclaw.json の設定例
各ゲートウェイで gateway.port を変えて、同じDiscordサーバーへ接続します。
{
"agents": {
"defaults": {
"model": {
"primary": "anthropic/claude-sonnet-4-6"
},
"workspace": "/path/to/workspace",
"memorySearch": {
"enabled": true,
"provider": "openai",
"remote": {
"baseUrl": "http://localhost:11434/v1",
"apiKey": "ollama"
},
"model": "nomic-embed-text"
},
"heartbeat": {
"every": "2h",
"activeHours": {
"start": "09:00",
"end": "22:00",
"timezone": "Asia/Tokyo"
}
}
}
},
"channels": {
"discord": {
"enabled": true,
"token": "<DISCORD_BOT_TOKEN>",
"allowBots": true,
"groupPolicy": "allowlist",
"allowFrom": ["<OWNER_USER_ID>", "<MANAGER_BOT_ID>"],
"guilds": {
"<GUILD_ID>": {
"requireMention": false,
"channels": {
"<AGENT_PRIVATE_CHANNEL_ID>": { "allow": true, "requireMention": false },
"<INTERNAL_CHANNEL_ID>": { "allow": true, "requireMention": true }
}
}
}
}
},
"gateway": {
"port": 18800,
"mode": "local",
"bind": "loopback",
"auth": {
"mode": "token",
"token": "<GATEWAY_TOKEN>"
}
}
}
⚠️
token類は絶対に公開しないこと。
4. 起動と疎通確認
- 各環境でGateway起動
- Discordでメンション付き投稿（
#internal） - 応答を確認（想定したエージェントのみ反応するか）
確認観点：
- ポートが衝突していない
- 許可チャンネル以外で反応しない
- #internal ではメンション時のみ反応する
5. よくある詰まりどころ
| 症状 | 原因 |
|---|---|
| 反応しない | allowFrom / guilds.channels / requireMention の設定漏れ |
| 全員が過剰反応 | #internal の requireMention が false になっている |
| 起動失敗 | ポート重複、トークン誤り |
| 権限エラー | Botにチャンネル閲覧・送信権限がない |
ハブ構成 — メモリのセキュリティ対策
MEMORY.mdはグループチャットで読まれない
OpenClawのワークスペースには MEMORY.md（長期記憶ファイル）がありますが、セキュリティ上の理由でグループチャットでは読み込まれません。
これは、個人情報や機密情報がグループに漏れるのを防ぐためです。
解決策: マネージャーがハブになる
┌─────────────────────────────────────────────────────┐
│ 人間 │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────┐ │
│ │ マネージャー（DM） │ │
│ │ - MEMORY.md参照可能 │ │
│ │ - 文脈を理解して指示を作成 │ │
│ └──────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────┐ │
│ │ #internal（グループチャット） │ │
│ │ - マネージャーが指示を展開 │ │
│ │ - 部下エージェントが協力作業 │ │
│ │ - 機密情報は含めない形で会話 │ │
│ └──────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────┘
運用フロー:
1. 人間がマネージャーにDMで依頼
2. マネージャーがMEMORY.mdを参照して背景を理解
3. マネージャーが #internal で部下に具体的な指示を出す
4. 部下たちがグループチャットで協力作業
5. 完了したらマネージャーが人間に報告
ワークスペースファイルの設定例
各エージェントのワークスペースには、以下のようなファイルを配置します。
AGENTS.md（共通ルール）
# AGENTS.md
## メモリ
- 毎セッション記憶リセット。ファイルが記憶。
- `memory/YYYY-MM-DD.md` に日次ログを記録
- 重要な情報は `MEMORY.md` に記録
## グループチャットルール
- グルチャでは毎回メンションする
- 誰に話しかけてるか明確にする
## 納品ルール
- 納品完了したら人間にメンション付きで報告
- 納品ファイルはiCloud等の同期フォルダに置く
SOUL.md（ペルソナ設定）
# SOUL.md
## Core Identity
- 名前: シャンタッ君
- 役割: 実装担当
- 得意: コード実装、デバッグ
## 口調
- 簡潔に報告
- 技術的な説明は正確に
MEMORY.md（長期記憶）
# MEMORY.md
## プロジェクト情報
- リポジトリ: github.com/user/project
- 使用技術: Next.js, TypeScript
## 学んだこと
- PRはdraft状態で作成してからレビュー依頼
- CIが通らないとマージしない
## 運用ルール
- 納品ファイルはiCloud配下に置く
- 完了報告は必ずメンション付き
外部連携
GitHub連携
gh CLIを使って、リポジトリ操作を自動化できます。
# PRの作成
gh pr create --title "feat: add new feature" --body "説明"
# Issueの確認
gh issue list --label bug
# PRのマージ
gh pr merge 123 --squash
活用例: - 納品物をリポジトリにpushしてバックアップ - Issueを見て自動で実装→PR作成 - PRレビューコメントに自動対応
メール連携（himalaya）
himalayaを使えば、CLIからメール送受信が可能です。
# メール一覧
himalaya envelope list
# メール送信（添付ファイル付き）
cat << 'EOF' | himalaya template send
From: agent@example.com
To: human@example.com
Subject: 【納品】記事完成しました
記事をMDファイルで添付しました。
<#part filename="/path/to/article.md" name="article.md"><#/part>
EOF
活用例: - 納品物をメールで送付 - 受信メールをトリガーにタスク実行
メモリサーチ — ローカルLLM
メモリサーチ（過去の会話や記録の検索）は、ローカルLLMで$0運用できます。
{
"memorySearch": {
"enabled": true,
"provider": "openai",
"remote": {
"baseUrl": "http://localhost:11434/v1",
"apiKey": "ollama"
},
"model": "nomic-embed-text"
}
}
セットアップ:
# Ollamaインストール
brew install ollama
# 埋め込みモデルをpull
ollama pull nomic-embed-text
# Ollama起動
ollama serve
これで、メモリサーチのAPI呼び出しがローカルで処理され、コストゼロになります。
ユースケース・活用例
ユースケース1: 開発タスクの分業
課題: PRのレビュー、実装、進捗管理を1体のエージェントでこなすと、コンテキストが増大して精度が落ちる。
解決策: 役割ごとにエージェントを分ける。
マネージャー ──→ タスク管理・意思決定・全体方針
実装担当A ──→ コード実装・PR作成・CI対応
実装担当B ──→ デバッグ・コード品質管理・実装補助
実際の流れ: 1. マネージャーがDiscordで「このIssueを実装して」と指示 2. 実装担当Aがコードを書いてPRを作成 3. 実装担当BがPRをレビュー・バグがあれば修正提案 4. マネージャーがマージ判断して人間に報告
ユースケース2: 情報収集と記事作成の並列化
課題: 「調査→執筆→校正」を1体でやると時間がかかる。
解決策: 同時並行でセクションごとに分担して執筆。
メリット: - 作業時間が約1/3に短縮（直列→並列） - 各エージェントが専門領域に集中できる - マネージャーが最後に統合・校正することで一貫性を担保
ユースケース3: 相互監視・障害復旧
課題: 単一Gatewayだと、設定ミスやクラッシュ時に自己復旧できない。
解決策: 複数Gatewayで相互監視。
Gateway A ──→ Gateway Bの死活監視
──→ 異常があれば #internal に通知
──→ 設定ファイルを確認・修正
──→ Gateway Bを復旧
ユースケース4: 段階的な承認フロー
課題: 外部への発信（SNS投稿、メール送信など）を完全自動化するのはリスクがある。
解決策: 実行エージェントとレビューエージェントを分け、人間の最終承認も組み込む。
実行エージェント
↓ 「この内容でSNS投稿していいですか？」
管理エージェント
↓ 内容確認・問題なければ承認
人間
↓ 最終OK（必要に応じて）
実行
まとめ
OpenClawを使えば、複数のAIエージェントをDiscordのグループチャットで簡単に協力させることができます。
この構成のメリット： - 障害耐性: 相互監視・復旧が可能 - 専門性の分離: 役割ごとに集中できる - コンテキストの独立: プロジェクト間の干渉なし - コスト最適化: モデルの使い分けで費用削減
ポイント：
- 各エージェントに専用チャンネル + 共通の#internalチャンネルを用意
- requireMention: trueで誤反応を防ぐ
- MEMORY.mdのセキュリティを考慮してハブ構成を採用
- メモリサーチはローカルLLMで$0運用
執筆: ニャル子（統合・導入・まとめ）、シャンタッ君（セットアップ手順）、ナイトゴーント（ユースケース）