Claude Code × Slack MCP連携の実践ガイド

Claude Codeを業務で使い込んでいくと、「この作業結果をSlackに通知できたら」「チームの議論ログをコンテキストに渡せたら」と感じる場面が増えてきます。そのニーズに応えるのが、Slack MCPサーバーです。

MCP（Model Context Protocol）は、AIエージェントが外部サービスと安全に連携するためのオープン標準プロトコルです。2026年2月にSlack公式がMCPサーバーをGA（一般提供）リリースしたことで、Claude CodeからSlackへの読み書きが正式にサポートされました。

私はMicroCMS MCP、Supabase MCP、Google Search Console MCPを日常的に実務で使っています。Slack MCPは現時点では構想段階ですが、複数のMCPを運用してきた経験から、設定の勘所やセキュリティの落とし穴は共通しています。この記事では、その実運用経験をベースにSlack MCP連携の設定方法から活用シーン、セキュリティ判断基準までを解説します。

Slack MCPサーバーとは何か

Slack MCPサーバーは、Claude CodeなどのMCPクライアントからSlackワークスペースを操作するための中継サーバーです。チャンネルの検索、メッセージの送受信、スレッドへの返信、リアクションの追加など、Slackの主要操作をAIエージェントから実行できます。

公式パッケージは@modelcontextprotocol/server-slackとしてnpmに公開されています。提供されるツールは以下の8種類です。

• slack_list_channels — チャンネル一覧の取得
• slack_post_message — メッセージの投稿
• slack_reply_to_thread — スレッドへの返信
• slack_add_reaction — リアクションの追加
• slack_get_channel_history — チャンネル履歴の取得
• slack_get_thread_replies — スレッド返信の取得
• slack_list_users — ユーザー一覧の取得
• slack_get_user_profile — ユーザープロフィールの取得

MCPエコシステムの成長は著しく、MCP対応のサーバーは5,800以上、クライアントは300以上が公開されています。Forresterは2026年中にエンタープライズ向けアプリベンダーの30%が自社MCPサーバーをリリースすると予測しています（Zuplo「The State of MCP」）。

設定方法：4ステップで接続する

Step 1：Slack Appを作成する

Slack APIのダッシュボードから新しいAppを作成します。「From scratch」を選び、任意の名前（例：Claude Code Bot）を付けて対象ワークスペースを選択します。

Step 2：Bot Tokenを取得する

左メニューの「OAuth & Permissions」からBot User OAuth Tokenを取得します。xoxb-で始まるトークンが発行されます。このトークンは環境変数として管理し、リポジトリには絶対に含めません。

Step 3：OAuthスコープを設定する

同じ「OAuth & Permissions」画面の「Scopes」セクションで、Bot Token Scopesを追加します。最小権限の原則に従い、必要なスコープだけを付与するのが鉄則です。

Slack公式ドキュメントでも「Most apps need only perform a handful of actions with a token, so ensure you are requesting the most limited token authorization scopes possible」と明記されています（Slack Security Best Practices）。

典型的な構成例は以下の通りです。

• channels:read — チャンネル一覧の取得
• channels:history — チャンネル履歴の取得
• chat:write — メッセージの投稿
• reactions:write — リアクションの追加
• users:read — ユーザー情報の取得

通知の送信だけならchat:writeのみで足ります。読み取りも必要ならchannels:readとchannels:historyを追加する、という判断になります。

Step 4：MCP設定ファイルに記述する

Claude Codeのプロジェクトルートにある.claude/settings.jsonにMCPサーバーの設定を追加します。

{"mcpServers":{"slack":{"command":"npx","args":["-y","@modelcontextprotocol/server-slack"],"env":{"SLACK_BOT_TOKEN":"xoxb-your-token","SLACK_TEAM_ID":"T0XXXXXXX"}}}}

特定のチャンネルだけに制限したい場合は、SLACK_CHANNEL_IDSにカンマ区切りでチャンネルIDを指定します。

"env":{"SLACK_BOT_TOKEN":"xoxb-your-token","SLACK_TEAM_ID":"T0XXXXXXX","SLACK_CHANNEL_IDS":"C01XXXXX,C02YYYYY"}

設定後、Claude Codeを再起動すれば接続完了です。/mcpコマンドで接続状態を確認できます。

実務での活用シーン4選

1. デプロイ完了通知

ビルドやデプロイが完了したタイミングで、結果をSlackチャンネルに自動投稿します。成功・失敗のステータス、変更内容の要約、デプロイURLまで含めれば、チームメンバーが管理画面を開かなくても状況を把握できます。

私のケースでは1人経営のため、自分専用の通知チャンネルに送る形になります。それでも、複数案件を並行で回していると「どの案件のデプロイが終わったか」を一元管理できるメリットは大きいです。

2. 日報・作業ログの自動投稿

Claude Codeのセッション終了時に、その日の作業内容を要約してSlackに投稿する使い方です。何を実装したか、どのファイルを変更したか、残タスクは何かを自動でまとめてくれます。

チーム開発では、メンバー全員がClaude Codeを使っていれば、各自の作業ログが自動的にSlackに集約されます。朝会の事前情報として機能します。

3. 過去の議論ログを検索してコンテキストに活用

「この機能の仕様、以前Slackで議論したはず」というシーンで、チャンネル履歴を検索してコンテキストとして渡せます。設計判断の背景や、過去の意思決定の理由を掘り起こすのに有効です。

私はMicroCMS MCPで記事データを取得したり、Supabase MCPでDB構造を確認したりと、「外部データをコンテキストに渡す」運用を日常的にやっています。Slackの会話ログも同じ発想で活用できます。

4. エラーアラートの即時共有

テスト失敗やビルドエラーを検知したら、エラー内容をSlackに即座に投稿します。特にCI/CDパイプラインと組み合わせると、障害の初動対応が大幅に短縮されます。

MCPとスキルの使い分け

Claude Codeには、MCPの他に「スキル」という仕組みもあります。両者の使い分けは明確です。

• MCP — リアルタイムの外部データ取得・更新。Slack、DB、APIなど「生きたデータ」とのやり取り
• スキル — 定型作業のテンプレート化。記事生成、画像生成、レポート作成など「手順が決まった作業」の効率化

たとえば「Slackにメッセージを送る」はMCPの仕事ですが、「毎朝9時にSlackに日報を投稿するワークフロー全体」はスキルで設計し、その中でSlack MCPを呼び出す構成になります。

「本当に必要か」を問うMCP選定基準

MCPは便利ですが、接続すればするほどよいわけではありません。私が実運用で学んだ選定基準を共有します。

使っていないMCPは外す。これが最も重要な原則です。接続しているMCPが多いと、Claude Codeのコンテキストウィンドウを圧迫し、レスポンスの精度が下がります。

実際、以前はデザイン系MCP（UIコンポーネントの生成ツール等）も接続していました。しかし運用してみると、プロンプトやスキルでデザインガイドラインを制定し、コード上でデザインを整える方がトータルコストが下がると判断して外しました。

MCP導入の判断フローはシンプルです。

• そのデータはリアルタイムに取得する必要があるか？（NoならファイルやDBから読めばいい）
• その操作は週に何回使うか？（月1回以下なら手動で十分）
• その接続はセキュリティリスクに見合うか？（後述）

現在、私が常時接続しているMCPはMicroCMS・Supabase・Google Search Consoleの3つだけです。それぞれ毎日使います。Slackは導入すれば4つ目になりますが、チーム体制の拡大に合わせて判断する予定です。

セキュリティ：実体験から学んだ教訓

OAuthスコープは最小権限で

前述の通り、Slack APIのスコープは必要最小限にします。admin系のスコープは原則として付与しません。Slackの公式ドキュメントでも、トークンの権限は最小限にすべきと繰り返し強調されています。

案件ごとにpermissionsを分離する

私はクライアントワークの案件ごとに、Claude Codeのpermissions設定（allow/deny）を変えています。案件Aで使うMCPツールが案件Bのデータにアクセスできる状態は、セキュリティ事故の温床になります。

.claude/settings.jsonのpermissions設定で、MCPツールごとにallow/denyを明示できます。Slack MCPなら「特定チャンネルへの書き込みだけ許可」「履歴の読み取りは不許可」といった粒度で制御が可能です。

自動デプロイの連鎖に注意する

これは私の実体験から得た最大の教訓です。Claude Codeにgit pushまで任せた際、Vercelへの自動デプロイが走り、robots.txtをindex許可に変更した状態でデプロイされました。結果、クライアントのWebサイトが完成前の状態で検索エンジンにインデックスされかけました。

MCP権限を設計するときは「最悪のケースで何が起きるか」を必ず想定すべきです。Slack MCPも同様で、誤ったチャンネルへの投稿、機密情報を含むメッセージの送信など、「AIが間違えたときのダメージ」を事前に見積もっておきます。

Bot Tokenの管理

xoxb-で始まるBot Tokenは、環境変数で管理し、.envファイルに格納します。.gitignoreに.envを追加するのは当然として、CI/CD環境でもシークレット管理機能を使います。Slack公式も「Store tokens with care and never place them in a public code repository」と明記しています。

導入を検討する際のチェックポイント

最後に、Slack MCP導入を判断するためのチェックポイントをまとめます。

• チーム規模 — 1人なら通知用途が中心。3人以上ならログ共有・検索の価値が大きくなる
• 既存のSlack活用度 — 普段からSlackに情報が集約されているチームほど効果が高い
• セキュリティ要件 — 機密性の高い案件では、チャンネル制限とpermissions分離が必須
• 他MCPとの優先順位 — DB、CMS、分析ツールなど、より業務直結のMCPを先に整備すべき

MCPのPython・TypeScript SDKのダウンロード数は2025年12月時点で月間9,700万回に達しており（Zuplo調査）、エコシステムの成熟は加速しています。Slack MCPもその流れの中で、チーム開発の標準インフラになっていく可能性が高いです。

ただし、「流行っているから入れる」ではなく「自分の業務で本当に必要か」を問い続けることが、MCP運用の本質だと私は考えています。

関連記事

Claude Code × Search Consoleで記事戦略を自動化した方法
Claude Code × Notion MCP連携の実践ガイド
Claude Codeチーム開発の導入と運用ガイド