Contents
はじめに：目的と想定環境（バージョン／前提条件）
OpenClawを使って同一スキルをSlackとDiscordで比較するPoCの設計と再現手順を示します。
この記事はOnboard CLIによるローカルブートストラップ、設定ファイルの具体例、再現可能なコマンドと期待出力を中心に扱います。
想定バージョン（この手順で想定する例）
- OpenClaw: v0.9.x（公式リポジトリのmainブランチを参照してください）
- Onboard CLI: v0.3.x（CLIの --version で確認）
- LLMプロバイダ: OpenAI API (v1)/GPT系列、もしくはローカルLlama系モデル
- Slack API: OAuth 2.0 / Socket Mode（Slack APIドキュメントに依存）
- Discord API: Gateway v10 相当（Intents と Interactions を利用）
注記: 実運用では上記バージョンを自環境で必ず確認してください。公式ドキュメントやリポジトリのタグ／リリースノートを参照のこと（参照例は参考リンク欄に記載、確認日: 2026-05-14）。
OpenClawの概観とOnboard CLIの役割
OpenClawは複数チャネルを横断してスキルを実行するためのOSS基盤で、Onboard CLIはローカルでのPoC立ち上げを簡素化します。
ここでは構成要素とOnboard CLIが担う実務上の役割を簡潔にまとめます。
基本構成要素（gateway / workspace / channel / skill）
各要素の役割を短く整理します。設定はYAMLで管理されることが多く、環境差に応じて置換します。
- gateway: プラットフォーム固有の受信入口（例: slack/socket_mode、discord/gateway）。
- workspace: LLM設定やポリシーを隔離する論理テナント。
- channel: プラットフォーム内のチャネル振る舞い（DM/チャンネル/スレッド）。
- skill: 会話ロジックとLLM呼び出しの定義（トリガー、ハンドラ、テンプレート）。
Onboard CLIの役割とメリット
Onboard CLIはPoCのテンプレート生成とローカル起動を自動化します。これにより同一skillを複数gatewayに短時間で接続できます。
重複設定の管理、環境変数経由のシークレット注入、ローカル検証用のSocket Mode/ngrok連携などをサポートします。
対応チャネルと公式サポート状況（OpenClaw）
OpenClawのコネクタは多くのチャネルをカバーしますが、各コネクタの保守状況は個別に確認が必要です。
以下は公式ソースの確認方法と実務で見るべき点です。
公式コネクタ一覧とソース確認方法
公式リポジトリにコネクタ群が格納されている場合が多いです。リポジトリ構造を直接確認して、最近のコミットやPRの状況を見てください。再現手順の一例を示します。
- GitHubでクローンしてコネクタディレクトリを確認する例（想定リポジトリ: https://github.com/openclawai/openclaw ）:
|
1 2 3 4 5 6 7 8 |
git clone https://github.com/openclawai/openclaw.git cd openclaw # コネクタ一覧を見る ls -1 connectors # 特定コネクタの更新履歴を最新20件見る git log --pretty=format:"%h %ad %s" --date=short -- connectors/discord -n 20 |
期待される情報: README、CHANGELOG、対応APIバージョン、既知のIssueリンク。
公式サイトやリポジトリのパスが異なる場合は、"openclaw connectors"で検索してください。必ず公式リポジトリのREADMEや connectors/ 配下を参照し、変更履歴を確認してください。
保守性と仕様変更の確認ポイント
実運用前に確認すべき点を列挙します。各項目は必ず一次ソースで裏取りしてください。
- コネクタの最終コミット日時と頻度。
- 依存するプラットフォームAPIのバージョン（例: Discord Gateway v10、Slack Events APIの変更）。
- 重大な仕様変更（privileged intent、OAuthスコープの追加など）があれば影響範囲を洗い出す。
- ローカル検証にSocket ModeやInteractions向けの署名検証が整っているか。
参考: GitHubのプルリクエストやIssue、各コネクタのCHANGELOGで確認してください（参考リンクに公式リポジトリを記載）。
Slack と Discord の比較（OpenClaw連携で差が出る点）
同一skillを動かす際に差が出やすい領域を中心に、実装と運用の観点で比較します。導入判断に必要な差分情報を具体的に示します。
メッセージ表現・UI・ファイル制限の差分
Block KitとDiscordのEmbedsでは表現可能なUIが異なります。ファイルサイズや添付の扱いもプラットフォーム差があります。
| 項目 | Slack | Discord |
|---|---|---|
| ファイル添付上限（目安） | 1 GB（プランや管理者設定に依存）[Slack公式]（確認日:2026-05-14） | デフォルト 8 MB、Nitroで50–100 MBに増加（プラン依存）[Discord公式]（確認日:2026-05-14） |
| メッセージフォーマット | Block Kit（複雑なレイアウト） + markdown類似 | Markdown + Embeds（フィールド制約あり） |
| モーダル / ボタン | Block Kitのモーダルが豊富 | InteractionsのModals/Buttonsあり。差分は表現の自由度 |
| エフェメラル | chat.postEphemeral でユーザー限定表示が容易 | Interaction replies に ephemeral フラグあり（対話ベース） |
| 非同期応答 | response_url による遅延応答が一般的 | Interactionは3秒以内にACKが必要、deferred replyで遅延対応 |
注: 上限値や挙動はプラットフォームのプランや時期により変わります。必ず公式ドキュメントで最新値を確認してください（参考リンク欄参照）。
認証・スコープ・Intent の違い（最低限の例）
実装で必要なスコープ／権限を最小化することが安全です。以下はPoCでの最小例です。
- Slack（最小スコープ例）
- chat:write — ボットがメッセージ送信するために必須
- commands — スラッシュコマンドを使う場合
- channels:read / groups:read / im:history — チャンネル一覧や履歴読取が必要な場合
- users:read — ユーザー情報を照合する場合
-
参考: https://api.slack.com/scopes
-
Discord（最小権限例）
- OAuth scopes: bot, applications.commands
- Bot 権限（インストール時）: Send Messages, Read Message History, Use Slash Commands（必要に応じて）
- Privileged Intent: MESSAGE_CONTENT を使う場合は Developer Portal で有効化（影響については下記参照）
- 参考: https://discord.com/developers/docs/topics/gateway#gateway-intents
OAuthの許可画面やBot招待URLは、それぞれの開発者コンソールで生成してください。スコープやIntentの要件は頻繁に変わるため、必ず公式ページの日付を確認してください（参考リンク参照）。
レート制限とスケーリングの違い
両者ともレート制限があり、実装上はリトライやキューを整備する必要があります。Discordは多数Guildでシャーディングが必要です。
- Slack: APIごとにレート制限が異なる。Socket Modeは接続数とMessage量に注意。詳細はSlackのRate Limitsを参照。
- Discord: GatewayとHTTP APIで異なるレート制限。Botが多数Guildに参加する場合はシャーディングが必要。MESSAGE_CONTENT intentを有効にするとレビュー対象となることがある。
実装例: 429を受けたら指数バックオフ＋Jitterで再試行し、キューによる吸収を行います（擬似コードはトラブルシューティング節で提示）。
PoC設計とOnboard CLIハンズオン（再現手順）
Onboard CLIを用いたローカルPoCの再現手順を具体的に示します。設定ファイルスニペットとコマンド、期待出力を含めます。
PoCの目的と合格基準（KPIの閾値例）
PoCは機能面と運用面の両方を評価します。合格基準は運用要件に応じて調整してください。例としての閾値を示します。
- 応答遅延（エンドツーエンド、ユーザ送信→返信送信）
- p50 ≤ 800 ms、p95 ≤ 3 s を理想ラインとする。
- p95 ≤ 5 s を許容ラインとする。これを超える場合はモデル変更やキャッシュを検討。
- エラー率: 5xx 系の API エラー率 < 0.5%（安定運用目標）
- コスト: 1メッセージ当たりのLLMコスト目標 ≤ $0.05（ビジネス要件に応じて調整）
- スケーリング: 1ワーカー当たりの同時セッション数を基に水平スケール設計。
これらは目安です。LLM種別や要求品質により閾値は変える必要があります。
事前準備（アカウント・シークレット管理）
準備事項とシークレット注入の具体例を示します。シークレットはVaultやKubernetes Secretで管理してください。
- 必要アカウント: Slack開発チームアカウント、Discord Developer アカウント、LLMプロバイダのAPIキー
- シークレット管理（HashiCorp Vault 例）:
|
1 2 3 4 |
# Vaultに格納（例） vault kv put secret/openclaw/slack SLACK_BOT_TOKEN="xoxb-..." SLACK_APP_TOKEN="xapp-..." vault kv put secret/openclaw/discord DISCORD_BOT_TOKEN="Bot abc..." DISCORD_PUBLIC_KEY="..." |
- KubernetesでのInject例（短縮）:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
apiVersion: v1 kind: Secret metadata: name: openclaw-secrets type: Opaque stringData: SLACK_BOT_TOKEN: "xoxb-..." DISCORD_BOT_TOKEN: "Bot abc..." --- apiVersion: apps/v1 kind: Deployment spec: template: spec: containers: - name: openclaw image: openclaw/poc:latest envFrom: - secretRef: name: openclaw-secrets |
- GitHub Actionsでの利用例（機密はGitHub Secretsに保管）:
|
1 2 3 4 5 |
- name: Start PoC run: | export SLACK_BOT_TOKEN=${{ secrets.SLACK_BOT_TOKEN }} onboard start --config ./onboard/poc |
シークレット回転の方針: トークンは定期（例: 90日ごと）にローテーションし、漏洩時は即時失効と再配布を行ってください。
Onboard CLIでの具体的手順と設定例
以下はOnboard CLIを用いた再現手順の例です。コマンドと設定ファイルスニペット、期待出力を示します。
1) Onboard CLI のバージョン確認とテンプレ生成
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
# バージョン確認（期待例） onboard --version # 0.3.2 # テンプレート生成（想定コマンド） onboard init --name poc --channels slack,discord # 生成された構成の表示（期待例） tree onboard/poc # onboard/poc # ├─ gateways/ # │ ├─ gateway-slack.yaml # │ └─ gateway-discord.yaml # ├─ workspaces/ # │ └─ workspace-poc.yaml # ├─ channels/ # └─ skills/ # └─ skill-echo.yaml |
2) gateway/workspace/channel/skill の具体例（YAMLスニペット）
- gateways/gateway-slack.yaml
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
id: slack-gateway type: slack/socket_mode client_id: "${SLACK_CLIENT_ID}" client_secret: "${SLACK_CLIENT_SECRET}" app_token: "${SLACK_APP_TOKEN}" # xapp-... bot_token: "${SLACK_BOT_TOKEN}" # xoxb-... signing_secret: "${SLACK_SIGNING_SECRET}" scopes: - chat:write - commands - channels:read events: - message.im - message.channels |
- gateways/gateway-discord.yaml
|
1 2 3 4 5 6 7 8 9 10 11 12 |
id: discord-gateway type: discord/gateway application_id: "${DISCORD_APP_ID}" bot_token: "${DISCORD_BOT_TOKEN}" public_key: "${DISCORD_PUBLIC_KEY}" # interactions signature verification intents: - GUILDS - GUILD_MESSAGES - DIRECT_MESSAGES - MESSAGE_CONTENT # privilege intent: enable in Developer Portal if used shards: 1 |
- workspaces/workspace-poc.yaml
|
1 2 3 4 5 6 7 |
id: workspace-poc llm: provider: openai api_key: "${OPENAI_API_KEY}" model: gpt-4o-mini temperature: 0.2 |
- skills/skill-echo.yaml（簡易スキル例）
|
1 2 3 4 5 6 7 8 9 10 11 12 |
id: echo-skill triggers: - direct_message - mention handler: type: llm prompt_template: | ユーザー入力: {{text}} 要求: シンプルに応答してください。 output_mapping: text: "{{response}}" |
3) ローカル起動と期待ログ
|
1 2 3 4 5 6 7 8 9 10 |
# ローカル起動 onboard start --config ./onboard/poc # 期待ログ（抜粋） # INFO Starting gateway slack-gateway (socket_mode) # INFO Connected to Slack via Socket Mode (app_token: xapp-...) # INFO Starting gateway discord-gateway (gateway) # INFO Listening HTTP /interactions on http://localhost:3000 # INFO Registered skill echo-skill for triggers: [direct_message, mention] |
4) 動作確認（Slack: auth.test, Discord: users/@me）
|
1 2 3 4 5 6 7 8 |
# Slack 認証チェック curl -s -X POST "https://slack.com/api/auth.test" \ -H "Authorization: Bearer ${SLACK_BOT_TOKEN}" | jq # Discord 認証チェック curl -s -H "Authorization: Bot ${DISCORD_BOT_TOKEN}" \ "https://discord.com/api/v10/users/@me" | jq |
期待: それぞれ有効な認証情報なら、status OK なJSONレスポンスが返ります（200系＋OKフィールド等）。
テスト実行とメトリクス収集
同一skillに対してSlack/Discordから同一メッセージ群を投げ、応答時間・LLM呼び出し時間・エラー率を計測します。収集方法の例:
- 1000件のシナリオを synthetic sender で実行し、各メッセージに unique id を付与。
- OpenTelemetry を経由して span を切り、span 名: receive_event / skill_run / llm_call を出力。
- p50/p95 を算出し、コストは実際のトークン消費を計測して1メッセージ当たりコストを算出。
サンプルスクリプト例（擬似）:
|
1 2 3 4 5 6 |
# 簡易負荷スクリプト（擬似） for i in $(seq 1 1000); do curl -s -X POST "http://localhost:3000/test/slack" \ -d '{"text":"テストmessage '$i'","id":"msg-'$i'"}' & done |
トラブルシューティングと運用設計
運用でよく起きる問題を認証・イベント・レート制限など分野別にまとめ、診断コマンドや対応策を提示します。
認証／権限の問題
認証エラーは最も多い障害の一つです。確認手順を示します。
- Slack: auth.test API による確認（上記コマンド参照）。401/403はスコープ不足か期限切れ。アプリのOAuth画面で再承認。
- Discord: GET /users/@me で Bot トークンの検証。401 はトークン不正、403 は権限不足。Botを再生成し、OAuthで再招待。
- トークンの有効期限や回転設定を運用ドキュメントに残してください。
イベント受信と署名検証
イベント受信の失敗は署名検証ミスやURL検証不備が原因です。代表的な確認手順を示します。
- Slack: signing_secret を用いた X-Slack-Signature の検証を行う。検証に失敗すると 401 を返す。
- Discord: Interactions の署名検証（Ed25519）を行う。public_key を用いてX-Signature-Ed25519 と X-Signature-Timestamp を検証する。
- 開発時は ngrok 等で公開URLを作り、プラットフォームのURL検証を通してから本番へ移行してください。
署名検証のサンプル（Node.js, pseudocode）は公式ドキュメントを参照のこと。
レート制限／429対応
429 を受けたら retry-after を読み取り、指数バックオフ＋Jitter を適用します。極端な一斉送信はバッチ化して送信速度を制御してください。
擬似コード:
|
1 2 3 4 5 6 |
retry_delay = base * 2^attempt + random_jitter if response has Retry-After header: sleep(retry_after) else: sleep(retry_delay) |
また、LLM プロバイダ側のレート制限も観測してメトリクスで閾値をアラート化してください。
Privileged Intent（Discord）の影響と手順
MESSAGE_CONTENT intent の有効化手順と影響を示します。
- Developer Portal にアクセス → Applications → 対象アプリ → Bot → Privileged Gateway Intents を有効化（MESSAGE CONTENT）。
- 設定後はBotを再起動し、必要に応じて再招待。多数Guildに展開している場合、Discord側の追加レビューやボット検証が必要になることがあります（閾値は時期により変動するため公式を確認してください）。
- MESSAGE_CONTENTを有効にするとプライバシー上の配慮が増すため、不要なら無効化して別の設計（コマンドベース）を検討してください。
セキュリティとコンプライアンス（具体手順）
トークン管理、最小権限、ログの取り扱い、法令対応について具体的手順を示します。
トークン・シークレット管理の具体例
- Vault を用いる場合はポリシーで読み取り権限を限定し、CI/CD には短期トークンを発行する。
vault kv get -field=SLACK_BOT_TOKEN secret/openclaw/slackのように起動時に注入する。 - Kubernetes は RBAC と NetworkPolicy を組み合わせて Secret へのアクセスを制限する。Secret は必要に応じて CSI ドライバでボリュームマウントする。
- ログには決してシークレットを平文で残さない。PII はマスクして保存する。
最小権限スコープの具体例（再掲と補足）
Slack の例（PoC 最小）:
- chat:write, commands, channels:read, users:read
Discord の例（PoC 最小）:
- OAuth scope: bot, applications.commands
- Bot 権限: Send Messages, Read Message History
権限範囲を最小化した上で、必要になったら段階的に拡張してください。変更は必ず差分として記録し、レビュープロセスを設けます。
GDPR 等の法令対応とプラットフォーム規約
GDPR 等のデータ保護法に従うための具体的措置を示します。
- データフローの可視化: 会話データがどのサービス／ログに保存されるかを書面化する。
- DPA（Data Processing Addendum）の締結: LLMプロバイダやSlack/DiscordとDPAを締結し、処理範囲と責任分界を明確にする。
- 利用者向け同意: 公開ボットでは会話が処理される旨を明示し、必要な同意を取得する。
- 右削除対応: "Right to be forgotten" に対応するため、ユーザーごとの削除APIと自動化スクリプトを用意する。
- 保持期間の設定例: デバッグ用ログは最大 30 日、会話履歴は必要最小限で 30–90 日を目安に。法的要求があれば延長や別途管理を行う。
プラットフォームの利用規約（Slack/Discord）の自動化・データ利用に関する制約は随時更新されます。必ず公式規約を参照してください。
コスト見積りと移行判断の数値基準
コストの算出方法と意思決定に使える数値基準を示します。PoCで実測した値を使って判断してください。
- コスト算出式（1メッセージ当たり）:
- 1メッセージコスト = 平均トークン数 × (API単価／1000) + インフラ分配費（秒単位の処理時間×単価）
- 例: 平均トークン数 800、API単価 $0.03/1k tokens の場合:
- LLMコスト = 800 × (0.03/1000) = $0.024
- インフラ分配費を $0.006 とすると合計 $0.03/メッセージ
- 判断閾値例:
- 1メッセージコスト > $0.1 かつ p95 > 5s なら、ローカルLLMの検討やキャッシュ導入を推奨。
- エラー率 > 1% や p95 が許容より大きければモデル/アーキテクチャの見直し。
具体的な金額は利用するモデルやトラフィックに依存します。PoCで必ず実測してから年度予算へ反映してください。
結論と推奨アクション
短期的に再現性のあるデータを取ることが意思決定を支えます。以下の手順を推奨します。
- Onboard CLI で同一 skill を Slack と Discord に接続する PoC を作成し、応答品質・遅延・コストを実測する。
- KPI（p50/p95、エラー率、1メッセージコスト）を上に示した閾値で評価し、合否を判断する。
- セキュリティは最小権限とシークレット管理（Vault/K8s/CI secrets）で運用し、トークンは定期ローテーションする。
- Discord の PRIVILEGED INTENT や Slack の Enterprise 制約は事前に管理者と合意して運用設計に落とし込む。
上記の手順と設定例を使えば、同一スキルでのプラットフォーム差異を定量的に比較できます。
参考リソース（一次資料へのリンクと確認日）
以下は主要な一次資料と参照先です。実装前に最新の情報を必ず確認してください（確認日: 2026-05-14）。
- OpenClaw 公式サイト: https://openclaw.ai/
- OpenClaw GitHub（想定位置、コネクタ一覧は connectors/ 配下を参照）: https://github.com/openclawai/openclaw
- Slack API（OAuth, Scopes, Socket Mode, Events, Rate limits）: https://api.slack.com/
- OAuth / Scopes: https://api.slack.com/authentication/oauth-v2
- Socket Mode: https://api.slack.com/apis/connections/socket
- Rate Limits: https://api.slack.com/docs/rate-limits
- Discord Developer Docs（Gateway Intents, Interactions, Rate limits）: https://discord.com/developers/docs/
- Gateway Intents: https://discord.com/developers/docs/topics/gateway#gateway-intents
- Interactions (署名検証など): https://discord.com/developers/docs/interactions/receiving-and-responding
- Rate Limits: https://discord.com/developers/docs/topics/rate-limits
- GDPR 入門（EU 一般データ保護規則）: https://gdpr.eu/
- HashiCorp Vault ドキュメント（シークレット管理）: https://www.vaultproject.io/docs
注記: 上記リンク先の仕様や数値は頻繁に更新されます。実装時は必ず公式ページで最新版を確認してください。