Claude Code × Slack連携は3種類ある — Claude Code in Slack・Slack MCP・Hooks通知の使い分け【2026年版】
Claude CodeとSlackの連携は「Claude Code in Slack」「Slack MCPプラグイン」「Hooksによる通知」の3つに分かれ、向きも対象プランも別物だ。公式ドキュメントと2026年7月のSlack MCPプラグイン刷新を基に、混同されがちな違いと選び方を整理する。
エンジニアのゆとです。
「Claude Code Slack連携」で検索すると、SlackからClaude Codeにバグ修正を頼む話、Claude CodeがSlackのメッセージを検索する話、SlackにClaude Codeの完了通知を送るだけの話が同じ検索結果に並ぶ。実はこの3つ、向きも対象プランもまったく別物だ。この記事では公式ドキュメントとSlack側の変更履歴を突き合わせて、混同されがちな連携方法を整理する。
結論 — まず全体像を1枚の表で
先に結論から。「誰が誰を呼ぶか」という向きで分けると迷わない。
| 方法 | 向き | 対象プラン | 主な用途 |
|---|---|---|---|
| Claude Code in Slack | Slack → Claude Code | Pro/Max（個人アカウント単位） | Slackでのバグ報告からPR作成までを1人で回す |
| Claude Tag | Slack → Claude Code | Team/Enterprise（組織共有ID） | 同じことをチームの共有窓口として運用する |
| Slack MCPプラグイン | Claude Code ⇄ Slack（読み書き両方） | 全プラン共通 | Claude Codeのセッションから過去のSlackメッセージを検索・要約・投稿する |
| Hooksによる通知 | Claude Code → Slack（一方向・通知のみ） | 全プラン共通（自前で組む） | タスク完了やエラーをSlackに投げるだけ |
上2つは「Slackから話しかけてClaude Codeを動かす」機能で、下2つは「Claude Codeのセッションの中でSlackを使う」機能になる。同じ「Slack連携」という言葉で語られていても、実装も設定場所もまったく違う。
Slackが「Claude Codeを呼ぶ」方向: Claude Code in Slack
Slackのチャンネルで@Claudeをメンションしてコーディングタスクを頼むと、Claude Codeがその内容を解析し、Claude Code on the web上に自動でセッションを立ち上げる。これが「Claude Code in Slack」だ。既存の「Claude for Slack」アプリの上に、コーディング系のリクエストだけを自動振り分けする仕組みが乗っている。
セットアップの流れ
公式ドキュメントによると、必要な手順は次の5つ。
- ワークスペース管理者がSlack App MarketplaceからClaudeアプリをインストールする
- 各ユーザーがApp Homeの「Connect」からSlackアカウントとClaudeアカウントを紐付ける
claude.ai/code（Claude Code on the web）にサインインし、GitHubリポジトリを最低1つ接続する- App Homeの「Routing Mode」で「Code only」（コーディング専用）か「Code + Chat」（自動振り分け）を選ぶ
- 使いたいチャンネルで
/invite @Claudeを実行する。インストールしただけでは自動的にどのチャンネルにも追加されない
前提条件として、Claude Code on the webへのアクセスが有効なプラン（Pro/Max/Team/Enterprise）、GitHubアカウントの連携、Slackアカウントのリンクが必要になる。DMでは動作せず、パブリック・プライベート問わずチャンネル内の@メンションにしか反応しない点も押さえておきたい。
できること・できないこと
セッションの流れは「メンション→コーディング意図の検出→Claude Code on the webでセッション作成→進捗をスレッドに投稿→完了時に@メンションでサマリー」という順序になる。完了時にはスレッド内に「View Session」「Create PR」のボタンが表示され、そこから直接PRを作れる。ただし現時点の制約として、リポジトリはGitHubのみ対応、1セッションにつきPRは1つまで、という上限がある。
つまづきやすいポイント
公式ドキュメントのトラブルシューティング項目には、実際に起きやすいエラーがいくつか具体的に書かれている。
| 症状 | 原因 | 対処 |
|---|---|---|
| 「Claude Code is not enabled for your account」 | 管理者権限の問題ではなく、そのユーザーがまだクラウド環境を作っていない | claude.ai/codeに一度サインインする。初回訪問でデフォルトのクラウド環境が作られ、次のメンションからエラーが消える |
| セッションが始まらない | Slackアカウントの接続、Claude Code on the webのアクセス権限、GitHubリポジトリの接続、いずれかが未完了 | App Homeで接続状態を1つずつ確認する |
| 意図しないリポジトリが選ばれる | Slackの会話の文脈からリポジトリを自動推定しているため、複数リポジトリが該当すると誤爆する | 「Change Repo」ボタンで選び直すか、依頼文にリポジトリ名を明記する |
セッションの開始時にはチャンネルやスレッドの会話履歴が文脈として渡される。公式ドキュメントも「信頼できるSlackの会話でのみ使うこと」と注意書きしており、他人の発言に含まれる指示にClaudeが従ってしまうリスクを明示している。案件のチャンネルに得体の知れないBotや外部ユーザーが出入りしている状態で気軽に招待するのは避けたほうがいい。
Claude Tagとの関係
Team/Enterpriseプランでは、この「Claude Code in Slack」は段階的に「Claude Tag」へ移行される。Claude Tagは@Claudeを個人アカウントではなく組織の共有アカウントとして動かす仕組みで、既存のSlackアプリや@Claudeのハンドルはそのまま使える。切り替えのタイミングは契約先のAnthropicアカウントチームから案内が来る形になっており、Pro/Maxの個人契約では今のところClaude Tagの対象外で、このページの手順がそのまま使える。
Team/Enterpriseで移行後によく起きるのが「Claude Tagのチャンネルでセッションが即座に失敗する」問題だ。これはチャンネルのクラウド環境が個人アカウントに紐づいたまま作られている場合に起きる。管理者がAdmin settingsから組織共有のクラウド環境を作り直し、組織のデフォルトかチャンネル個別の設定として割り当てる必要がある。
Claude Codeが「Slackを読み書きする」方向: Slack MCPプラグイン
こちらは逆方向で、Claude CodeのセッションからSlackのメッセージを検索・要約・投稿する機能だ。2026年7月31日、Slack公式が「Slack MCP and Skills Plugin」という新しいプラグインを発表し、それまでコミュニティ製サーバーに頼るしかなかったこの連携が公式にサポートされるようになった。
インストール方法
Claude Code内で以下のコマンドを実行するだけでいい。
/plugin install slack@claude-plugins-officialインストール時にOAuth認証のフローが始まり、対象のSlackワークスペースへのログインを求められる。管理者権限で組織のIntegrationsからSlackコネクターを有効化しておく方式もあり、その場合はプラグインをインストールした瞬間に自動で同期される。
できること
プラグインは「スキル」と「MCPサーバー接続」の2要素で構成されている。スキル側はBlock Kitの書き方やSlack CLIの使い方といった開発者向けの参照情報を必要なときだけ読み込む仕組みで、MCPサーバー側が実際にワークスペースとやり取りする部分だ。主な機能は次の4カテゴリに分かれる。
- Search — メッセージ・ファイル・ユーザー・チャンネル（パブリック/プライベート問わず）を横断検索する
- Messaging — メッセージの送信・スケジュール送信、チャンネル履歴の取得、スレッドの追跡、リアクションの追加
- Canvas — Canvasドキュメントの作成・読み取り・更新
- User Management — カスタムフィールドやステータスを含むユーザープロフィールの取得
対応クライアントはClaude CodeとCursorの2つで、Cursorの場合はMarketplace経由でも同じプラグインを導入できる。
ハマりどころ①: 過去に起きていた認証エラー
このプラグインが登場する以前、コミュニティ製のSlack MCPサーバーをClaude Codeに繋ごうとすると、2025年12月ごろから「Incompatible auth server: does not support dynamic client registration」という認証エラーが報告されていた。SlackのOAuthがDynamic Client Registration（動的クライアント登録）に対応しておらず、Claude Code側のプラグインシステムがこの仕組みを前提にしていたことが原因だった。この問題は2026年2月18日に修正されている。現在は公式プラグイン経由であれば、この種の認証エラーに遭遇する可能性はかなり低い。ただし社内で自前運用しているSlack MCPサーバーを使っている場合は、まだ古いOAuth実装のままになっていないか確認しておいたほうがいい。
ハマりどころ②: メッセージ取得時のフォーマットの癖
Slack公式MCPには、検索結果のレスポンス形式を「concise」（簡潔）と「detailed」（詳細）で切り替えるオプションがある。運用上、次のような癖が報告されている。
- conciseフォーマットでは、日時が
56121767-06-30のような明らかに不正な値へ変換されてしまうことがある - 特定の箇条書き構造を含むメッセージをconciseで取得すると、レンダリングに失敗して
MCP error -32602が返ることがある - 日付フィルタの
after:は指定日を含むのに対してbefore:は指定日を含まない。期間の終了日まで含めたい場合は、終了日の翌日をbefore:に指定する必要がある - detailedフォーマットは前後の文脈まで含めてレスポンスを返すため、件数が多いと一気に肥大化する。
limit=5程度に絞って運用するのが無難
日付が不正な値に化けるバグは、Claude Codeに「先週の議論をまとめて」のような曖昧な期間指定をさせたときに気づきにくい形で表面化する。要約結果に不自然な年号が混じっていたら、まずこのフォーマットの癖を疑うといい。
Claude Codeが「Slackに投げるだけ」の方向: Hooksによる通知
MCPほど大掛かりな仕組みがいらない場合は、Hooksを使ってタスク完了やエラーをSlackに通知するだけの構成でも十分なケースが多い。StopイベントのHookからIncoming Webhook URLにcurlでPOSTするだけで組める、実装コストの低い方法だ。
# .claude/hooks/notify-slack.sh の骨格
curl -s -X POST "$SLACK_WEBHOOK_URL" \
-H 'Content-Type: application/json' \
-d "{\"text\": \"Claude Codeのタスクが完了しました\"}"読み取り・検索は不要で「終わったら知らせてほしいだけ」という用途なら、OAuth接続もツール定義のコンテキスト消費も発生しないこちらのほうが軽い。具体的な設定例・非同期実行の注意点・トークンの安全な扱い方は以前の記事にまとめてあるので、そちらを参照してほしい。
結局どれを使えばいいか
用途別に整理すると、次のように選ぶのが妥当だ。
| こういう用途なら | 選ぶべき方法 |
|---|---|
| Slackでバグ報告を受けたら、その場でClaude Codeに調査・修正・PR作成まで任せたい | Claude Code in Slack（個人）／Claude Tag（組織） |
| Claude Codeの作業中に、過去のSlackの議論やユーザー報告を参照させたい | Slack MCPプラグイン |
| 長時間かかるタスクの完了やエラーだけスマホで受け取りたい | Hooksによる通知（Slack/Telegram） |
チームの標準の@Claude窓口として全員で共有したい | Claude Tag（Team/Enterpriseのみ） |
複数のニーズを同時に満たしたいなら、組み合わせて使うのが実際的だ。たとえばSlack MCPプラグインで過去の議論を参照しながら作業しつつ、完了時はHooksで通知する、という構成は互いに競合しない。逆にClaude Code in SlackとSlack MCPプラグインは「呼ぶ側」と「呼ばれる側」が逆なので、片方を入れればもう片方が不要になるという関係でもない。
フリーランスエンジニア視点: クライアント案件での権限の絞り方
複数クライアントを掛け持ちしていると、Slack連携でも「案件間で情報が混ざらないか」が一番の懸念になる。自分が気をつけているのは次の点だ。
Claude Code in Slackを使う場合、セッションはメンションしたユーザー自身のClaude アカウントで動き、そのユーザーが個人的に接続したGitHubリポジトリだけにアクセスする。案件Aのチャンネルで案件Bのリポジトリが誤って選ばれる心配は構造上少ないが、「信頼できる会話でのみ使う」という公式の注意書き通り、クライアントのワークスペースに外部ゲストが多いチャンネルでは招待自体を慎重に判断したほうがいい。
Slack MCPプラグインを使う場合は逆に注意が必要だ。OAuth接続すると、ワークスペース全体のうち自分がアクセス権を持つチャンネル・DMが検索対象になる。案件Aの作業中に案件Bのワークスペースへの接続も残っていると、Claude Codeが「関連しそうな情報」として意図せず別案件のメッセージを参照しようとする可能性がある。案件ごとにプラグインの有効・無効を切り替えるか、CLAUDE.mdの冒頭に「このセッションで参照していいのは案件Aのワークスペースのみ」と明記しておくと、誤参照のリスクを減らせる。この設計の考え方はNotion MCPの記事でも触れた通りだ。
Hooksによる通知は、Webhook URLさえ漏らさなければ最も事故リスクが低い。ただしSLACK_WEBHOOK_URLのようなシークレットを.claude/settings.jsonに直書きしてコミットしてしまう事故は、Notionのトークンと同じ理由でよく起きる。個人設定用のsettings.local.jsonに分けるか、環境変数から読み込む構成にしておくべきなのは他のシークレット管理と変わらない。
よくある質問
Slack MCPプラグインはプライベートチャンネルにもアクセスできる？
自分がSlack上でアクセス権を持っているプライベートチャンネルであれば検索・取得の対象になる。逆に言えば、そもそもSlack上で見えないチャンネルはClaude Code側からも見えない。OAuth接続時の権限は「自分が見れる範囲」がベースになる。
無料プランのSlackワークスペースでもMCP連携は使える？
Slack MCPプラグイン自体はSlackの有料/無料プランを問わずインストールできる。ただしSlack側のAPI呼び出し回数やアプリ数に関する制限は、Slackの契約プランに準じる点は変わらない。
Claude Code in SlackとSlack MCPプラグイン、両方入れても問題ない?
問題ない。前者は「Slackからのメンションでセッションを起動する」機能、後者は「Claude Codeのセッションの中でSlackのAPIを呼ぶ」機能で、内部的に競合する部分がない。実際、公式ドキュメントの想定活用例としても、Slackでの会話をきっかけにセッションを立ち上げつつ、セッション内でSlack MCPを使って過去の関連メッセージを検索する、という組み合わせが想定されている。
DMでもClaude Codeを呼び出せる?
Claude Code in Slackはチャンネル内の@メンションにのみ反応し、DMでは動作しない仕様になっている。個人的にDMベースで気軽に相談したい場合は、通常のClaude for Slackアプリ（コーディング以外の一般的なチャット用途）の方を使うことになる。
まとめ
Claude CodeとSlackの連携は「Slackから呼ぶ」（Claude Code in Slack／Claude Tag）と「Claude Codeが使う」（Slack MCPプラグイン／Hooks通知）の2方向、4つの手段に分かれる。検索結果でこれらが同じ「Slack連携」として並んでいるせいで混同しやすいが、向きが分かれば選ぶべきものは自然と決まる。
個人でバグ報告からPR作成まで任せたいならClaude Code in Slack、チームの共有窓口にしたいならClaude Tag、作業中に過去のSlackの議論を参照させたいならSlack MCPプラグイン、完了通知だけ欲しいならHooks。複数のニーズがあるなら、これらは排他的ではないので組み合わせて使えばいい。フリーランスとして複数案件を掛け持ちしているなら、Slack MCPプラグインの接続範囲とCLAUDE.mdの記述だけは、案件を切り替えるたびに見直す習慣をつけておいたほうがいい。
関連記事
