株式会社renue
AI導入・DXの悩みをプロに相談してみませんか？
AIやDXに関する悩みがありましたら、お気軽にrenueの無料相談をご利用ください。 renueのAI支援実績、コンサルティングの方針や進め方をご紹介します。
AIエージェントをSlackから呼び出す——「@メンション一発」で開発タスクを実行させる設計
「Slackで@メンションしたら、AIエージェントが自律的にコードを書いて、PRを作成して、結果をSlackに返してくれる」——2026年、この夢は現実になっています。
しかし、Slackとのintegrationは単にAPIを繋ぐだけではありません。認証の設計、イベントの重複排除、VM上のエージェント制御、セキュリティ——企業環境で安全に運用するには、体系的な設計が必要です。
本記事では、AIコーディングエージェントをSlack経由で起動・制御するための設計パターンを、実装レベルで解説します。
アーキテクチャ概要
ユーザー（Slack） │ @メンション ↓ Slack Events API（Socket Mode） │ app_mention イベント ↓ バックエンド │ ①チャットユーザー識別子取得 │ ②社内ユーザーとの照合 │ ③実行セッション作成＋一時セッション識別子発番 ↓ 隔離された実行環境上のAIエージェント │ 一時セッション識別子 + API Key で認証 │ MCPツール経由でバックエンドAPI呼び出し ↓ 結果をSlackスレッドに返信
Socket Mode vs HTTP Webhook
| 方式 | メリット | デメリット | 推奨用途 |
|---|---|---|---|
| Socket Mode | 公開URLが不要、ファイアウォール内で動作 | 常時接続が必要 | 閉域環境・開発環境 |
| HTTP Webhook | スケーラブル、ステートレス | 公開エンドポイントが必要 | 本番の高トラフィック環境 |
閉域環境やIP制限がある場合はSocket Modeが最適です。公開HTTPエンドポイントを設ける必要がないため、ネットワークセキュリティの要件を満たせます。
認証フロー：チャットユーザーと社内ユーザーの対応付け
なぜ認証が重要か
「Slackでメンションされたら誰でもAIを使える」状態はセキュリティリスクです。誰がAIに指示したかを特定し、その人の権限に基づいてAIの操作範囲を制限する必要があります。
認証フローの設計
- チャットユーザー識別子取得：app_mentionイベントからチャットユーザー識別子を抽出
- email取得：Slack API（users.info）でチャットユーザー識別子からemailを取得
- 社内ユーザーの特定：社内ユーザーディレクトリ側でメールアドレスを照合
- 一時セッション識別子発番：
安全なランダム値でセキュアな一時セッション識別子を生成 - セッション保存：セッション識別子と利用者識別子を紐づけて保存
VM上のAIエージェントからの認証
隔離された実行環境上のAIエージェントは、共通API Key + 一時セッション識別子 の2つのヘッダーでバックエンドAPIを呼び出します。
共通のサービス認証キー（ヘッダー） セッション固有の識別子（ヘッダー）
バックエンドは一時セッション識別子からowner_user_idを引き、そのemployeeのroleに基づいて認可を行います。これにより、AIが実行する操作は全て「誰の指示か」が追跡可能になります。
Webhook統一エンドポイント設計
Slack Appは1つのエンドポイントしかInteractivity URLを持てません。複数の処理（議事録のプロジェクト変更、承認フロー等）を1つのエンドポイントで振り分ける設計が必要です。
統一Webhookエンドポイント（POST） ↓ 1. 署名検証（Slack Signing Secret） ↓ 2. ペイロード解析（form-data → JSON） ↓ 3. action_id抽出 ↓ 4. ルーティング ├ 議事録変更用アクション → 議事録プロジェクト変更 ├ 承認用アクション → 承認処理 └ その他 → 「未対応のアクション」
action_idでバックエンドのルーティングを制御する設計により、処理を追加するたびにボットを作成する必要がなくなります。
イベント重複排除
Slackのイベントは再送される場合があります。同じメンションで実行セッションが二重に作成されないよう、重複排除が必要です。
対策
app_mentionイベントのみに絞る（message_changedなどは無視）- イベントIDの重複チェック（処理済みイベントをキャッシュ）
- 実行セッション作成の冪等性を確保（同一メッセージに対して1 Runのみ）
セキュリティ設計
チャンネルアクセス制御
- チャンネル許可リスト：特定チャンネルからのメンションのみ受け付ける
- DM制御：DMからの起動を許可するか、チャンネルのみに限定するか
- レート制限：1ユーザーあたりの同時実行数を制限
操作権限のマッピング
認証で特定したemployeeのroleに基づいて、AIが実行できる操作を制限します。
| role | 許可される操作 |
|---|---|
| manager | 全エンドポイント |
| internal_user | プロジェクト配属済みのエンドポイント |
| external | 許可パスのみ |
プラットフォーム非依存のエージェント設計
コアのエージェントロジックはプラットフォーム非依存にすべきです。推論、意思決定、アクション実行のレイヤーは、リクエストがSlackから来たのかWebから来たのかを知る必要はありません。
┌─ Slack Adapter ─┐
│ 入力パース │
│ 出力フォーマット │
└──────┬──────────┘
↓
┌─ Core Agent ────┐
│ 推論・判断 │ ← プラットフォーム非依存
│ ツール実行 │
│ 結果生成 │
└──────┬──────────┘
↓
┌─ Slack Adapter ─┐
│ スレッド返信 │
│ リアクション追加 │
└─────────────────┘
この設計により、将来TeamsやDiscordにも同じエージェントロジックを展開できます。
実装のチェックリスト
| 領域 | チェック項目 |
|---|---|
| Slack App設定 | Bot Token Scopesが必要最小限に設定されているか |
| Socket Mode | App-Level Tokenが設定され、WebSocket接続が安定しているか |
| 認証 | Slack user → email → employee の変換が正しく動作するか |
| 認可 | employee.roleに基づく操作制限が全エンドポイントで機能するか |
| 重複排除 | 同一メンションで実行セッションが1回だけ作成されるか |
| Webhook | action_idルーティングが正しく振り分けられるか |
| 署名検証 | Slack Signing Secretで署名検証を実施しているか |
| セキュリティ | チャンネル許可リスト・レート制限が設定されているか |
| プラットフォーム分離 | コアロジックがSlack固有コードに依存していないか |
| end-to-end | Slack返信まで完了したことをログで確認できるか |
AIエージェントのSlack連携は、単なるボット開発ではありません。認証・認可・重複排除・セキュリティ・プラットフォーム分離——これらを設計段階で組み込むことで、企業環境で安全に運用できるAI Slack Botが完成します。
あわせて読みたい
- 5Sとは｜整理・整頓・清掃・清潔・しつけの意味・目的・進め方を解説
- AIリードスコアリング実装ガイド【2026年版】— 4要素スコアリング×テリトリー管理×ステータス倍率の本番アーキテクチャ
- AIカスタマーサポート完全ガイド【2026年版】— RAG・チャットボット・有人連携の実装パターンとツール比較
関連記事
AI開発のご相談はrenueまで。
サービス・採用に関する公開情報は、renue公式サイトをご確認ください。
