Contents
スポンサードリンク
Slack App の作成と Manifest 設定
手順概要
- Slack API ポータル → 「Create New App」 → 「From manifest」 を選択。
- 以下の Manifest を貼り付けて Save、続いて Install App to Workspace で Bot User OAuth Token (
xoxb-…) を取得。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
display_information: name: OpenClawBot features: bot_user: display_name: OpenClaw Bot always_online: true oauth_config: scopes: bot: - chat:write - channels:read - app_mentions:read settings: socket_mode_enabled: true # Socket Mode 必須 interactivity: is_enabled: false # Webhook が不要な場合はオフ |
ポイント
Manifest に必須項目だけを書けば、GUI と設定の乖離が防げます。公式ドキュメントは Slack の App Manifest guide を参照してください。
Socket Mode と最小権限 Scopes の付与
| Scope | 用途 |
|---|---|
chat:write |
メッセージ送信（Bot が回答を返す） |
channels:read |
チャンネル一覧取得（許可対象チャンネル判定に使用） |
app_mentions:read |
Bot へのメンション受信 |
- 最小権限の原則：実際に必要な操作だけを列挙し、過剰なスコープは付与しない。
- スコープ追加後は Reinstall App（または
manifestを更新して再インストール）で有効化します。
参考: Slack の OAuth & Permissions documentation
Bot Token の安全な保管・ローテーション手順
1. シークレット管理ツールへの格納
| ツール | 主な特徴 |
|---|---|
| HashiCorp Vault | 動的シークレット、ACL ベースのアクセス制御 |
| AWS Secrets Manager | 自動ローテーション（Lambda で実装可能） |
| GCP Secret Manager | IAM による細粒度権限管理 |
Docker Compose と連携例（AWS Secrets Manager）
|
1 2 3 4 5 6 |
services: openclaw: image: ghcr.io/openclaw/openclaw:latest environment: - SLACK_BOT_TOKEN=${SLACK_BOT_TOKEN} # .env ではなく、ecs/compose の secret 引数で注入 |
|
1 2 3 4 |
# ローカルテスト用に一度だけ取得（本番はランタイムで注入） aws secretsmanager get-secret-value --secret-id slack/bot-token \ --query SecretString --output text > .env |
2. トークンローテーション手順
- 新規トークン発行
- Slack の OAuth & Permissions ページで Reinstall App → 新しい
xoxb-が生成されます。 - シークレットストア更新
- 例:
aws secretsmanager put-secret-value --secret-id slack/bot-token --secret-string "xoxb‑NEW…" - コンテナ再起動（ロールアウト）
bash
docker compose pull openclaw
docker compose up -d --no-deps --force-recreate openclaw - 旧トークンの無効化（即時反映させる場合）
- Slack の App Management で「Remove token」または API
auth.revokeを実行。
有効期限対策：Slack の Bot Token は自動失効しないため、上記ローテーションを 90日ごと にスケジュール化するとベストプラクティスです。（CI/CD パイプラインで
cronタスクとして実装可）
OpenClaw 側設定（openclaw.json）とチャンネル限定運用
1. 設定ファイル例
|
1 2 3 4 5 6 7 8 9 |
{ "groupPolicy": "closed", "allowChannels": [ "C01ABCD2EFG", // #general "C02HIJK3LMN" // #project‑alpha ], "defaultModel": "gpt-4o" } |
groupPolicy: "closed"→ 許可されたチャンネル以外では Bot が無視します。allowChannelsに Slack のチャンネル ID（C…）を列挙。
2. チャンネル ID の取得手順
- Slack アプリで対象チャンネルを開く。
- 右クリック → 「コピー」 > 「リンクをコピー」。
- コピーされた URL の最後の
Cxxxxxxxx部分がチャンネル ID。
正確な ID が設定されていないと Bot は無反応になるため、必ず確認してください。
Docker Compose によるデプロイ – ベストプラクティス
完全サンプル（2026 年版）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 |
version: "3.9" services: openclaw: image: ghcr.io/openclaw/openclaw:latest restart: unless-stopped environment: - SLACK_BOT_TOKEN=${SLACK_BOT_TOKEN} # ランタイムで注入 - SOCKET_MODE_ENABLED=true - OPENCLAW_CONFIG=/app/config/openclaw.json volumes: - ./openclaw.json:/app/config/openclaw.json:ro ports: [] # Socket Mode の場合は外部ポート不要 # ---- 健康チェック ------------------------------------------------- healthcheck: test: ["CMD", "curl", "-fSs", "http://localhost:8000/health"] interval: 30s timeout: 5s retries: 3 # ------------------------------------------------------------------ logging: driver: "awslogs" options: aws-region: us-east-1 log-group: /openclaw/slack tag: "{{.Name}}" # ---- セキュリティ強化 --------------------------------------------- secrets: - source: slack_bot_token target: SLACK_BOT_TOKEN # ------------------------------------------------------------------ secrets: slack_bot_token: external: true # AWS Secrets Manager / Vault で管理されたシークレットを参照 networks: default: name: openclaw-net |
補足ポイント
| 項目 | 説明 |
|---|---|
| Healthcheck | OpenClaw の組み込み /health エンドポイントはデフォルトで 8000 ポート。コンテナ起動後に 200 が返れば正常です。ポート番号は環境変数 OPENCLAW_HEALTH_PORT で上書き可能です。 |
| 外部ロギング | AWS CloudWatch (awslogs) を例示。他のプロバイダー（GCP Logging、Azure Monitor）でも同様に設定できます。 |
| Secrets | Docker の secrets 機能と外部シークレットストアを組み合わせることで、環境変数ファイルに平文トークンを書かずに済みます。 |
接続確認・トラブルシューティング
1. テストメッセージでの動作検証
|
1 2 3 |
# コンテナログをリアルタイムで監視 docker compose logs -f openclaw |
Slack の許可チャンネルで @OpenClaw test と送信。
期待される応答例：
「テストメッセージを受け取りました 🚀」
ログに次のような行が出力されれば接続成功です。
|
1 2 |
Received event: app_mention {"type":"app_mention","user":"U12345",...} |
2. よくあるエラーと対処法
| エラーメッセージ | 主因 | 解決策 |
|---|---|---|
invalid_auth |
Token が無効、または環境変数未設定 | シークレットストアから最新トークンを取得し、コンテナ再起動 |
missing_scope |
必要な Scope が付与されていない | Manifest に不足スコープを追加 → Reinstall |
socket_mode_error: connection failed |
Socket Mode が無効かネットワーク制限 | Slack App の Socket Mode がオンか、ファイアウォールで wss://*.slack.com が許可されているか確認 |
rate_limited (HTTP 429) |
API 呼び出し頻度超過 | バックオフ実装（指数的遅延）とリクエスト数削減を検討 |
運用上の注意点（レートリミット・監査ログ）
Slack API のレートリミット
| エンドポイント | 1 分間あたりの上限 |
|---|---|
chat.postMessage |
約 20 回/チャンネル |
conversations.list |
約 100 回/ワークスペース |
apps.event.authorizations.list (Socket Mode) |
約 50 回/秒（内部で自動制御） |
- 対策
- 再試行ロジックに Exponential Backoff を実装。
- バッチ送信は可能な限りまとめ、不要な
chat.postMessage呼び出しを削減。 - Slack の公式レートリミットガイド（https://api.slack.com/docs/rate-limits）を常に参照。
監査ログとコンプライアンス
| 項目 | 推奨設定 |
|---|---|
| Slack API 呼び出し | SLACK_APP_LOGGING を有効化し、全リクエスト/レスポンスを CloudWatch / Stackdriver に転送 |
| コンテナ stdout/stderr | 前述の外部ロギングドライバで集約。ログ保持期間は最低 90 日（ISO 27001 準拠） |
| シークレット変更履歴 | Vault の audit デバイス、AWS Secrets Manager の Rotation History を有効化 |
| CI/CD 変更レビュー | Manifest・docker‑compose の差分は必ず Pull Request でコードレビューし、OPA（Open Policy Agent）で「過剰スコープ」チェックを自動実行 |
まとめ
- Manifest だけで最小構成の Slack App を作成 →
socket_modeと必要 Scopes が一元管理。 - 最小権限（chat:write, channels:read, app_mentions:read） を付与し、過剰権限を排除。
- Bot Token は Vault/AWS Secrets Manager 等で暗号化保存 → 90 日ごとのローテーションと自動再デプロイを実装。
- OpenClaw の
groupPolicy:"closed"と正確なチャンネル ID により、Bot が応答する範囲を限定。 - Docker Compose に Healthcheck (
/healthon 8000)、外部ロギング、シークレット注入を組み込み、運用の可観測性と安全性を確保。 - テストメッセージで接続確認 → エラーパターンはトークン・スコープ・Socket Mode の設定ミスが主因。
- レートリミット対策（バックオフ実装）と 監査ログの集中管理 を徹底し、コンプライアンス要件を満たす。
この手順に沿って構築・運用すれば、OpenClaw と Slack の連携は 安全かつスケーラブル に実現できます。ぜひ本ガイドをデプロイパイプラインや社内ドキュメントに組み込んで、継続的なセキュリティ改善に役立ててください。
スポンサードリンク