---
title: "Slack MCPサーバーの接続手順と権限設計｜Claude Code・Codex・Cursorの設定と公式版・OSS版の選び分け"
url: "https://www.issoh.co.jp/tech/details/17875/"
published: 2026-09-27
updated: 2026-11-07
categories: ["AIエージェント・MCP"]
publisher: "株式会社一創"
---

# Slack MCPサーバーの接続手順と権限設計｜Claude Code・Codex・Cursorの設定と公式版・OSS版の選び分け

Slack MCPサーバーは、Slackが `https://mcp.slack.com/mcp` で提供しているリモート型のMCPサーバーです。Claude CodeやCursorから、Slackのメッセージ検索、投稿、canvasやリストの作成まで実行できます。この記事では、クライアントごとの接続設定（Claude Code・Codex・Cursor・Pi）と、Codexで認証が止まる理由を2026年10月24日の実測で確かめます。あわせて、curlで取得したOAuthメタデータから読める認可の前提、承認するスコープの絞り方、OSS版との選び分け、監査ログを使った運用も扱います。

## まとめ：Slack MCPで最初に決める接続先・クライアント・承認範囲

会社のワークスペースで使うなら、接続先はSlack公式のリモートサーバーにしてください。公式版はユーザー本人のOAuthで動き、読めるのは本人が見えるチャンネルまでです。ワークスペース管理者がアプリを承認しない限り認証が通らないので、情報システム部門の統制下に置けます。

クライアント選びでは、いちばん手間が少ないのはClaude CodeとCursorです。どちらも公式プラグインを入れればOAuthまで済みます。Codexは公式ガイドに手順が載っていますが、2026年10月24日時点のCodex 0.163.0では、その手順どおりに打つと認証の手前で止まります。SlackがDynamic Client Registration（DCR）に対応していないためで、自社のSlackアプリを登録してclient IDを渡す必要があります。

承認申請では、スコープを読み取り系と書き込み系に分けて出します。DMの中身をAIに渡したくなければ、1対1のDM用の `search:read.im`・`im:history` と、グループDM用の `search:read.mpim`・`mpim:history` の4つを外します。AIが読んだチャンネルを監査ログで追えるのはEnterpriseプランだけです。ブラウザのセッショントークンで動き、管理者承認を経ないOSS版は個人の検証用にとどめてください。

## Slack MCPの2つの向きと公式サーバーmcp.slack.comが担う範囲

MCPそのものの仕組みは[MCPの仕組みとMCPサーバーの作り方](/tech/details/5736/)で解説しています。Slackの場合は接続の向きが2つあり、どちらの話かによって設定がまったく異なります。

### 外部AIからSlackを読むサーバー側とSlackbotが外部を呼ぶクライアント側

1つ目は、外部のAIクライアントがSlackのデータを読む向きです。SlackがMCPサーバーになり、Claude Codeなどがそこへ接続します。この記事で扱うのはこちらです。

2つ目は、Slackbotが[MCPクライアントとして外部のMCPサーバーを呼ぶ向き](https://slack.com/blog/news/slackbots-mcp-client)です。LinearやCanva、Figmaなどを会話の中からSlackbotに操作させる機能で、Slackの[モデルコンテキストプロトコルのガイド](https://slack.com/intl/ja-jp/help/articles/48855576908307)には、MCPクライアント側のパートナーが15社並んでいます。Slack内で@Claudeに仕事を頼む[Claude Tagの仕組みと旧appからの移行](/tech/details/12721/)もSlack側からAIを呼ぶ向きで、本記事の手順とは別物です。Slack上でAIに答えさせるBotを自作する構成は[Slack BotにAIで回答させる作り方](https://www.issoh.co.jp/tech/details/19483/)で扱っています。

### 公式サーバーの検索・メッセージ・canvas・リストのツール構成

[Slack MCP server overview](https://docs.slack.dev/ai/slack-mcp-server/)によると、ツールは検索、メッセージ、canvas、ユーザー、ファイル、リストの6系統です。2026年10月24日時点で載っている主な機能は次のとおりです。

- 検索：メッセージとファイル、ユーザー、チャンネル、参加中のチャンネル一覧、カスタム絵文字
- メッセージ：送信、予約送信、下書き、チャンネルとスレッドの読み取り、チャンネルやDMの作成、リアクションの追加と取得
- canvas：作成・更新と、Markdownでの読み出し
- ユーザーとファイル：プロフィール取得、チャンネルのメンバー一覧、2段階のファイルアップロード（`slack_get_file_upload_url` で署名付きURLを得てPOSTし、`slack_complete_file_upload` で確定）
- リスト：列の型を指定したリストの作成・読み取りと、行の追加・更新

公開時（2026年2月）は検索・送信・canvas・ユーザーが中心でしたが、予約送信やリアクション、リスト操作まで増えています。実務でまず使うのは検索と読み取りです。検索で拾えるのは条件に合う個々のメッセージなので、議論の経緯まで読ませるには、見つけたメッセージのスレッドを読み取りツールで取り直させます。

### 2026年2月の公開と同時にRTS APIへ改称されたData Access API

公式サーバーは[2026年2月17日の変更履歴](https://docs.slack.dev/changelog/2026/02/17/slack-mcp/)で発表されました。同じ日に、従来のData Access APIがリアルタイム検索API（RTS API）へ改称されています。

MCPサーバーはLLMが読む前提で、ツールの説明と自然文の応答を返します。一方の[RTS API](https://docs.slack.dev/apis/web-api/real-time-search-api/)はAIへ直接はつながず、自社アプリから `assistant.search.context` を呼ぶ経路です。検索結果を加工してからLLMへ渡すならRTS API、市販のAIクライアントから使うならMCPサーバーを選びます。Web APIやEvents APIを含めたSlack APIの全体像は[Slack APIのWeb API・Events API・Boltの違い](/tech/details/18717/)にまとめています。

## クライアント別の接続方式とclient IDの持ち方

公式サーバーはDCRに対応していません。[概要ページ](https://docs.slack.dev/ai/slack-mcp-server/)は「We do not support SSE-based connections or Dynamic Client Registration at this time.」と明記しています。そのため、どのクライアントもSlackに事前登録されたアプリのclient IDを使います。違いは、そのclient IDをSlackかクライアントの開発元が用意しているか、自分で登録するかです。

| クライアント                   | 導入経路               | client ID            | 2026年10月24日の状態 |
| ------------------------ | ------------------ | -------------------- | -------------- |
| Claude Code              | 公式プラグイン            | Slack用意（プラグイン同梱）     | そのまま接続できる      |
| Cursor                   | Cursor Marketplace | Slack用意（Cursor用の別ID） | そのまま接続できる      |
| Claude.ai・Claude Desktop | コネクター              | パートナーアプリ             | 管理画面から追加       |
| Codex CLI                | `codex mcp add`    | 自分で登録                | 公式手順のままでは失敗    |
| Pi                       | pi-mcp-adapter     | 記載なし                 | 公式ガイドに手順あり     |

[開発者ドキュメント](https://docs.slack.dev/ai/slack-mcp-server/)が「Available clients」に挙げているのはClaude.ai、Claude Code、Perplexity、Cursorの4つです。[ヘルプセンター](https://slack.com/intl/ja-jp/help/articles/48855576908307)のMCPサーバーのパートナー一覧には、ChatGPT、Devin、Notion、Dropboxなど14項目が載っています（ChatGPTとOpen AIは別項目）。表にない開発ツールから使うなら、自社のSlackアプリを登録する前提で計画してください。

## Claude CodeからSlack公式MCPへ接続する手順と.mcp.jsonの中身

Claude Codeでつなぐ経路は、公式プラグインを入れる方法、CLIで追加する方法、設定ファイルを直接書く方法の3つです。

### 公式プラグインを/plugin installで入れるいちばん短い経路

Slackは[slackapi/slack-skills-plugin](https://github.com/slackapi/slack-skills-plugin)でプラグインを公開しています。2026年10月24日時点の最新版は1.5.0（10月19日公開）です。Claude Codeの中で次を実行します。

```
/plugin install slack@claude-plugins-official
```

最初にSlackのツールを呼んだときにブラウザでOAuthの同意画面が開き、許可すれば接続は完了です。`/slack:summarize-channel` や `/slack:standup` など5種類のスラッシュコマンドも同梱されています。

### .mcp.jsonに固定clientIdと3118番を書く設定

プラグインが使っている設定は、リポジトリ直下の `.mcp.json` に書かれています。プロジェクト単位でチームに共有するなら、同じ内容をリポジトリに置けば動きます。

```
{
  "mcpServers": {
    "slack": {
      "type": "http",
      "url": "https://mcp.slack.com/mcp",
      "oauth": {
        "clientId": "1601185624273.8899143856786",
        "callbackPort": 3118
      }
    }
  }
}
```

`1601185624273.8899143856786` は、SlackがClaude向けに登録したアプリのclient IDです。リダイレクトURIは `http://localhost:3118/callback` で登録されているため、ポート番号を変えると認証が通りません。

CLIで追加する場合も同じ2つの値を渡します。[Slackのハーネス接続ガイド](https://docs.slack.dev/ai/slack-mcp-server/connect-to-harnesses/)のCLI例はclient IDを含んでいません。しかしDCRが使えない以上、client IDを渡さない構成では登録の段階で止まるので、[Claude CodeのMCPドキュメント](https://code.claude.com/docs/en/mcp)にある `--client-id` と `--callback-port` を付けてください。`--scope`の選び方や`.mcp.json`をチームで共有する手順は、Slack以外のMCPサーバーにも共通するため[Claude CodeのMCP設定とスコープ・.mcp.jsonの解説](https://www.issoh.co.jp/tech/details/19413/)にまとめています。

```
claude mcp add --transport http --scope local \
  --client-id 1601185624273.8899143856786 --callback-port 3118 \
  slack https://mcp.slack.com/mcp
```

追加したら、Claude Codeのセッションで `/mcp` を開いて認証を済ませます。サブスクリプションやAPIキーなど、Claude Code自体のログインで詰まる場合は[Claude Codeのログイン方法と認証エラーの直し方](/tech/details/18748/)を参照してください。

### 管理者承認が済んでいないときに止まる箇所と社内申請の順序

公式ガイドが前提条件に挙げるのは、ワークスペース管理者がMCP連携を承認していることです。承認前に試すと、同意画面の段階で先へ進めません。社内展開は次の順にすると手戻りが減ります。

1. 使うAIクライアントと、そのクライアント用のSlackアプリ名を確認する
2. 必要なスコープを読み取り系と書き込み系に分けて一覧にする
3. 情報システム部門へ承認を申請し、許可するスコープの範囲を合意する
4. 承認後に `/mcp` から認証し、自分の見えるチャンネルだけが返るか確かめる

組織契約のclaude.aiから使う場合は、AIクライアント側でも管理者がコネクターを許可しているかを確認してください。

## CodexからSlack公式MCPへ接続する手順と認証で止まる理由

Slackの[ハーネス接続ガイド](https://docs.slack.dev/ai/slack-mcp-server/connect-to-harnesses/)には、Codex向けとして `codex mcp add` と `~/.codex/config.toml` の2通りが載っています。一方、同じSlackの[プラグインのページ](https://docs.slack.dev/ai/slack-skills-plugin/)には「As the Slack MCP Server is not available on Codex yet」とあり、Codex版プラグインが入れるのはスキルだけです。つまりCodexでは、プラグインではなくCLIか設定ファイルで手動接続することになります。その手動接続の手順を、実際のCodexで確かめました。

### 公式ガイドのコマンドがCodex 0.163.0で通らない2つの段階

2026年10月24日、macOSのcodex-cli 0.163.0で、設定を汚さないよう一時ディレクトリを `CODEX_HOME` に指定して実行しました。ガイドのコマンドは、引数の段階でエラーになります。

```
$ codex mcp add --transport http slack https://mcp.slack.com/mcp
error: unexpected argument '--transport' found
```

Codexの `mcp add` は `--url` でHTTPサーバーを指定する形で、`--transport` というオプションを持っていません。そこで `--url` に直すと追加はできます。ただ、そのまま始まるOAuthが次のエラーで止まります。

```
$ codex mcp add slack --url https://mcp.slack.com/mcp
Added global MCP server 'slack'.
Detected OAuth support. Starting OAuth flow…
Error: Registration failed: Dynamic registration failed: Registration failed: Dynamic client registration not supported
```

Codexはclient IDが設定されていないとDCRでクライアント登録を試みますが、SlackはDCRに対応していません。同じ現象はopenai/codexの[Issue #13200](https://github.com/openai/codex/issues/13200)（2026年3月起票）で報告されており、10月24日時点でもopenのままです。`codex mcp login slack` を打ち直しても同じエラーが返り、`codex mcp list` の表示は「Not logged in」のままでした。

### –oauth-client-idを付けたときの認可URLとredirect\_uri

Codexは、2026年5月にマージされた[PR #22575](https://github.com/openai/codex/pull/22575)から、事前登録したクライアントのIDを渡せるようになっています。0.163.0には `--oauth-client-id` と `--oauth-client-secret` があり、[設定リファレンス](https://developers.openai.com/codex/config-reference)では `mcp_servers.<id>.oauth.client_id` にあたります。ダミーのIDを入れて `codex mcp login slack --no-browser` を実行すると、DCRを飛ばして次の認可URLが表示されました（読みやすいよう改行しています）。

```
https://slack.com/oauth/v2_user/authorize?response_type=code
  &client_id=0000000000.0000000000
  &code_challenge_method=S256
  &redirect_uri=http%3A%2F%2Flocalhost%3A3118%2Fcallback%2FlukW65nqn7xj
  &scope=canvases%3Aread+canvases%3Awrite+...+users%3Aread.email
  &resource=https%3A%2F%2Fmcp.slack.com
```

この認可URLから、3つの注意点が読み取れます。

- **スコープは30種類すべてを要求する**：Codexはサーバーが公開する `scopes_supported` をそのまま並べます。DMを外すなら `mcp_servers.slack.scopes` に必要なものだけを書きます。ただし、すでに発行済みのトークンからスコープを外す方法は無いと[SlackのOAuthガイド](https://docs.slack.dev/authentication/installing-with-oauth/)に書かれているので、権限を縮めるときは旧トークンを失効させてから認証し直します。
- **redirect\_uriの末尾にIDが付く**：`mcp_oauth_callback_url` に `http://localhost:3118/callback` を指定しても、送られるのは `/callback/lukW65nqn7xj` でした。Slackの[OAuthガイド](https://docs.slack.dev/authentication/installing-with-oauth/)は、リダイレクトURLが登録値と同じかその下位パスなら受け付けると書いているので、登録するのは `/callback` までで足ります。
- **client secretが要る**：Slackのトークンエンドポイントは `client_secret_post` しか受け付けません。リファレンスによると、`--oauth-client-secret` の値は `config.toml` に書き込まれます。

自社アプリでこの経路を通した利用者からは、ブラウザの認可までは進んだが、トークン交換で「missing field \`access\_token\`」になったという報告も出ています（Issue #13200、2026年9月24日のコメント）。Codexから公式サーバーへOAuthで確実につながる手順は、まだ確立していません。

### ユーザートークンをbearer\_token\_env\_varで渡す回避策と代償

同じIssueでは、OAuthを使わず、自社アプリで発行したユーザートークン（`xoxp`）を環境変数で渡す回避策が共有されています。Codex側では `bearer_token_env_var` を使います。

```
[mcp_servers.slack]
url = "https://mcp.slack.com/mcp"
bearer_token_env_var = "SLACK_MCP_TOKEN"
```

この方法では、Slackアプリの設定で「Agents」から「Slack Model Context Protocol (MCP) Server」をオンにしておく必要があります。[開発者向けガイド](https://docs.slack.dev/ai/slack-mcp-server/developing/)に書かれている手順で、オフのままだと「App is not enabled for Slack MCP server access.」が返るという報告があります。

ただし、長期間有効なユーザートークンを開発者のPCに置く運用になります。退職や異動のときに回収漏れが出やすく、OAuthと違ってCodexはこのトークンを更新しません。会社のワークスペースでCodexを使うなら、この回避策を全社に広げる前に、Claude CodeかCursorで足りないかを先に検討してください。

## CursorとPiからSlack公式MCPへつなぐ設定

Codex以外で公式ガイドに手順があるのは、CursorとPiです。

### Cursor Marketplaceのプラグインと別のclient ID

Cursorでは、[Cursor Marketplace](https://cursor.com/marketplace/slack)のSlackプラグインを入れると、スキルとMCPサーバーが一緒に設定されます。最初に使ったときにOAuthの同意画面が出ます。プラグインの `.cursor-mcp.json` は、Claude Codeとは別のclient IDを使っています。

```
{
  "mcpServers": {
    "slack": {
      "url": "https://mcp.slack.com/mcp",
      "auth": {
        "CLIENT_ID": "3660753192626.8903469228982"
      }
    }
  }
}
```

Slackの管理画面では、Claude用とCursor用が別のアプリとして承認の対象になります。両方を許可するなら、申請も2件に分けてください。[CursorのMCPドキュメント](https://cursor.com/docs/context/mcp)によると、自社アプリで接続するときに登録するリダイレクトURLは、デスクトップアプリなら `http://localhost:8787/callback` です。

### Piのpi-mcp-adapterで追加する手順

Piは拡張の `pi-mcp-adapter` を入れてからMCPサーバーを追加します。[ハーネス接続ガイド](https://docs.slack.dev/ai/slack-mcp-server/connect-to-harnesses/)の手順は次のとおりです。

```
pi install npm:pi-mcp-adapter
```

Piを再起動したら、`~/.pi/agent/mcp.json` に次を追記します。

```
{
  "mcpServers": {
    "slack": {
      "url": "https://mcp.slack.com/mcp",
      "auth": "oauth"
    }
  }
}
```

Piの中で `/mcp` を開き、SlackのConnectを押すとOAuthに進みます。ただし、このガイドは前提条件に「Your Slack app’s client ID」を挙げている一方、Piの設定例にはclient IDを書く項目がありません。SlackはDCRに対応していないので、この設定のまま認証が完了するかは公式ガイドからは判断できず、未解決の点として残ります。

## curlによるOAuthメタデータの取得と認可方式・30スコープの確認

公式サーバーの要求は、トークンを持たないままでも調べられます。MCPの仕様どおり、認可に必要な情報を公開エンドポイントで返しているためです。接続に失敗したとき、クライアントの不具合かサーバー側の要求かを切り分ける材料になります。MCP仕様の改訂で認可まわりがどう変わったかは[MCP仕様2026-07-28版の変更点](/tech/details/18245/)で整理しています。

### 401応答のWWW-Authenticateから保護リソースメタデータへたどる手順

まずトークンを付けずにPOSTします。

```
curl -i -X POST https://mcp.slack.com/mcp \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'
```

2026年10月24日の実行でも `401` が返り、ヘッダに次の1行が入っていました。

```
www-authenticate: Bearer resource_metadata="https://mcp.slack.com/.well-known/oauth-protected-resource"
```

このURLと認可サーバーのメタデータを続けて取得します。

```
curl -s https://mcp.slack.com/.well-known/oauth-protected-resource
curl -s https://mcp.slack.com/.well-known/oauth-authorization-server
```

### client\_secret\_post・S256・ID-JAGが示す認可の前提

認可サーバーのメタデータから、設計に効く値を抜き出します（2026年10月24日の実測）。

- `authorization_endpoint` は `oauth/v2_user/authorize`：ボットではなくユーザートークンを発行する
- `token_endpoint_auth_methods_supported` は `client_secret_post` のみ：トークン交換にclient secretが要る
- `code_challenge_methods_supported` は `S256`：PKCEを併用できる
- `registration_endpoint` が無い：DCRに対応していないことがメタデータでも分かる
- `grant_types_supported` に `refresh_token` と `urn:ietf:params:oauth:grant-type:jwt-bearer`：更新トークンと、IdPが発行したJWTでの交換を受け付ける

9月27日に取得した時点との差分は、`jwt-bearer` と `authorization_grant_profiles_supported` の `urn:ietf:params:oauth:grant-profile:id-jag` が加わったことです。後述するOkta経由のアクセス管理（Enterprise-Managed Authorization）に使われる値です。

公式ドキュメントも「Slack supports confidential OAuth for MCP clients」と書いています。自社でクライアントを作るなら `client_id` と `client_secret` の両方が前提です。secretを安全に持てないデスクトップアプリでは、後述するPKCEを検討します。

### ツールごとに要るユーザートークンのスコープと承認時に外す候補

保護リソースメタデータの `scopes_supported` には、10月24日時点でも30種類が並んでいました。承認申請では、用途ごとに束ねて示すと話が通りやすくなります。

| 用途          | 代表スコープ               | 区分   |
| ----------- | -------------------- | ---- |
| メッセージ検索     | `search:read.public` | 読み取り |
| DMの検索       | `search:read.im`     | 読み取り |
| チャンネル履歴     | `channels:history`   | 読み取り |
| DMの履歴       | `im:history`         | 読み取り |
| 投稿・予約送信     | `chat:write`         | 書き込み |
| リアクション追加    | `reactions:write`    | 書き込み |
| canvas作成・更新 | `canvases:write`     | 書き込み |
| リストの作成・更新   | `lists:write`        | 書き込み |

情報漏えいの観点で最も重いのはDM系のスコープで、DMの中身までAIの文脈に流れます。1対1のDMは `search:read.im` と `im:history`、グループDMは `search:read.mpim` と `mpim:history` が担います。社内規程でDMを対象外にしたい組織は、この4つを外して承認するよう依頼してください。申請で合意した内容と、クライアントが実際に要求するスコープが一致しているかも確かめます。

`chat:write` にも注意が要ります。公式版はユーザートークンで動くため、AIが送ったメッセージは認証した本人の名前で表示されます。ボットとして投稿させたい場合、公式ドキュメントはボットトークンを別に発行する手順を案内しており、MCPの設定だけでは切り替わりません。MCPサーバー側でツールと権限を設計する考え方は、[MCPサーバーの作り方とAIエージェントへの接続手順](/tech/details/15365/)で扱っています。

## 自社アプリで公式MCPへつなぐ場合に詰まるリダイレクトURIとPKCE

承認済みアプリを増やしたくない、監査ログで自社アプリとして識別したい、といった理由で、自社登録のSlackアプリを使う場面があります。Codexから使う場合もこの経路です。前章の「Agents」の設定に加え、公式サーバーを使えるのはSlack Marketplaceに掲載したアプリか社内アプリだけで、未掲載の配布アプリは使えない点に注意してください。

### 自社のclientIdに差し替えるとredirect\_uriが一致しない不具合

公式リポジトリの[Issue #21](https://github.com/slackapi/slack-skills-plugin/issues/21)（2026年3月起票・10月24日時点でopen）では、client IDを自社アプリのものに差し替えると「redirect\_uri did not match any configured URIs」で失敗すると報告されています。自社アプリに `http://localhost:3118/callback` を登録しようとしても、設定画面がhttpsで始まらないURLを受け付けないためです。

Claude Code側は、[Claude CodeのMCP接続ドキュメント](https://code.claude.com/docs/en/mcp)どおり、次の形で自社アプリの資格情報を渡せます。

```
claude mcp add --transport http \
  --client-id your-client-id --client-secret --callback-port 8080 \
  slack https://mcp.slack.com/mcp
```

`--client-secret` は実行時にマスク入力で求められ、secretは設定ファイルではなくOSのキーチェーンか資格情報ファイルに保存されます。とはいえ、Slack側がlocalhostのリダイレクトを受け付けない限り、このコマンドだけでは解決しません。

### PKCEの有効化で公開クライアント扱いになり解除にサポート連絡が要る制約

[SlackのPKCEガイド](https://docs.slack.dev/authentication/using-pkce/)によると、PKCEを有効にしたアプリでは `localhost` へのリダイレクトがデスクトップ向けとして扱われます。localhostを登録する手がかりはここにありますが、代償も大きい設定です。

- アプリが公開クライアント扱いになり、Slackサポートに連絡しない限り戻せない
- リフレッシュトークンの有効期限が、無期限から30日に変わる
- デスクトップ向けリダイレクトでは、ボットのスコープを要求できない

既存の社内ボットのアプリで有効にすると、ボット側の運用まで巻き込みます。試すなら、MCP接続専用のアプリを新しく作ってください。

### 並行セッションで3118番が衝突してOAuthが完了しない事象

公式設定はコールバックを3118番に固定しているため、同じマシンで複数のClaude Codeセッションが同時に認証すると、2つ目以降が失敗します。[Issue #46](https://github.com/slackapi/slack-skills-plugin/issues/46)（2026年6月起票・10月24日時点でopen）で報告されている事象です。同じマシンで認証情報の保存先を共有するセッションなら、1つずつ認証を済ませれば、以降は保存されたトークンで再認証なしに動きます。一方、同じIssueでは、devcontainerごとに3118番をバインドする構成だと、2つ目のコンテナがポートの競合で起動しないことも報告されています。こちらは順番に認証しても解消しません。

## 公式リモート版とOSSのSlack MCPサーバーを選び分ける判断基準

公式版が出る前から、Slack向けのMCPサーバーはOSSで複数公開されていました。検索上位の記事にもOSS版の設定例が混ざっているので、どちらの手順なのかを見分ける必要があります。

### 参照実装のSlackサーバーが保守終了のアーカイブへ移された経緯

MCPの公式リポジトリにあった参照実装のSlackサーバーは、[servers-archived](https://github.com/modelcontextprotocol/servers-archived/tree/main/src/slack)へ移されました。リポジトリ自体がアーカイブ扱いで、説明文は「Reference MCP servers that are no longer maintained」です。`slack_list_channels` や `slack_post_message` といったツール名、`SLACK_BOT_TOKEN` と `SLACK_TEAM_ID` を環境変数で渡す設定例は、この参照実装か派生版の手順です。保守が止まった実装を、新しく社内へ入れる理由はありません。

### ボットトークン型とブラウザトークン型のOSS版に潜む統制の穴

現役のOSS版で利用者が多いのは[korotovsky/slack-mcp-server](https://github.com/korotovsky/slack-mcp-server)で、10月24日時点の最新版は2026年5月14日のv1.3.0です。stdio・SSE・HTTPの3方式で動きます。

問題はトークンの種類です。READMEは「stealth mode」として、ブラウザのセッショントークン（`xoxc` ／ `xoxd`）なら追加の権限もボットのインストールも要らないと説明しています。管理者承認を経ずに、本人が見える全チャンネルをAIへ流せる状態です。アプリの承認一覧には現れないため、情報システム部門はアクセスログのIPやユーザーエージェントから推測するしかありません。ボットトークン（`xoxb`）なら招待されたチャンネルしか読めず範囲は狭まりますが、READMEのとおり `search.messages` が使えず、横断検索ができなくなります。

### 会社のワークスペースで公式版を採用しOSS版を見送る判断の条件

| 観点         | 公式リモート版       | OSS版（korotovsky）   |
| ---------- | ------------- | ------------------ |
| トークン       | ユーザーOAuth     | xoxc・xoxp・xoxbから選択 |
| 管理者承認      | 必須            | stealth modeでは不要   |
| 監査ログ       | MCP専用アクションで記録 | MCP専用アクションには残らない   |
| 実行場所       | Slackのサーバー    | 自分のPCかサーバー         |
| Codexからの接続 | 自社アプリが必要      | stdioでそのまま可        |

会社が契約するワークスペースでは公式版を採用し、OSS版のstealth modeは使いません。規程上の問題に加え、退職者のブラウザトークンが誰かのPCに残り続ける経路を作るためです。Codexで公式版がつながらないことは、OSS版を選ぶ理由になりません。OSS版を使ってよいのは、個人のワークスペースや開発者サンドボックスで挙動を試す場面に限られます。

## 社内導入で情報持ち出しを抑えるレート制限と監査ログの運用設計

接続できたあとに問題になるのは、AIがどれだけの量をどの頻度で読むかです。公式版はWeb APIと同じ枠で制限と記録がかかるので、その前提で運用を組みます。

### Tier 2の毎分20回を前提にしたチャンネル一覧取得の組み立て方

公式ドキュメントは、MCP経由でもWeb APIを直接呼んでも、ツールごとに同じ[レート制限](https://docs.slack.dev/apis/web-api/rate-limits/)がかかると明記しています。チャンネル検索・参加チャンネル一覧・canvas作成・チャンネル作成はTier 2（毎分20回以上）、チャンネルとスレッドの読み取り・予約送信・リアクションはTier 3（毎分50回以上）、プロフィールやメンバー一覧はTier 4（毎分100回以上）です。メッセージ検索と送信には、メソッドごとの特別な制限が適用されます。

「全チャンネルを要約して」と頼むと、AIは一覧を取ってから1つずつ履歴を読みにいきます。一覧取得がTier 2なので、ページ送りを重ねると上限に届きます。チャンネル名と期間を指定して依頼する運用ルールにすれば、制限にも持ち出し量にも効きます。定型の通知を流すだけなら[Slack Webhookで通知を送る実装](/tech/details/17652/)のほうが単純で、AIに読み取り権限を渡さずに済みます。課題管理のBacklogを同じようにAIへつなぐ場合の権限の絞り方は、[Backlog MCPサーバーの導入手順と削除系ツールの封じ方](/tech/details/17881/)で整理しています。

### 監査ログのmcp\_slack\_\*\_tool\_calledでAIの操作を追跡する方法

[Audit Logs APIのアクション一覧](https://docs.slack.dev/reference/audit-logs-api/methods-actions-reference/)にはSlack MCPサーバー専用の節があり、`mcp_slack_read_channel_tool_called` や `mcp_slack_send_message_tool_called` など11種類が定義されています。取得は次の形で、`oldest` はUNIX時刻です。

```
curl -s "https://api.slack.com/audit/v1/logs?oldest=1788000000&action=mcp_slack_read_channel_tool_called,mcp_slack_search_public_and_private_tool_called" \
  -H "Authorization: Bearer $SLACK_AUDIT_TOKEN"
```

10月24日時点の11種類は、検索・チャンネルとスレッドの読み取り・送信・canvas・プロフィールに対応するものです。予約送信、リアクション、リスト、ファイルアップロード、チャンネル作成のツールには、専用のアクション名がまだ載っていません。書き込み系を承認するときは、この差を前提に範囲を決めてください。

このAPIはEnterpriseプラン限定です。トークンもオーガナイゼーションのオーナーに紐づき、`auditlogs:read` を持つ `xoxp` に限られます。それ以外のプランではAIの読み取りを事後に追えないため、承認するスコープを絞る判断がより重くなります。

### OktaのEnterprise-Managed Authorizationによる仕事用アカウントへの接続制限

Slackのヘルプ記事「[IDプロバイダを介してSlack MCPサーバーへのアクセスを管理する](https://slack.com/help/articles/54548358406419)」によると、Slack Enterprise+プランとClaude TeamまたはEnterpriseプランの組み合わせなら、Claude内のSlack MCPサーバーへのアクセスをOktaから管理できます。これがEnterprise-Managed Authorization（EMA）で、メタデータに加わったID-JAGはこの仕組みに使われます。

設定は、OrGへのClaudeアプリのインストール、Slackの「SSOの設定」でEMAを有効化してID-JAG発行者URL（例：`https://acmeinc.okta.com`）を確認、Okta側とClaude側でのEMA有効化の4段階です。作業には、SlackのOrGオーナー、Oktaのスーパー管理者、ClaudeのOwnerの3つの権限が要ります。ヘルプ記事の時点で対応IdPはOktaだけです。メンバーが私用のアカウントでつなぐ経路を塞げるので、Enterprise+を契約している組織ではユーザーごとのOAuthより先に検討する価値があります。

### 他のMCPサーバーと同時接続するときの経路分離とIP許可リスト

公式ドキュメントのセキュリティの節は、他のMCPサーバーとの同時利用に注意を促しています。Slackで読んだ社内の議論が、同じ会話の中で別のMCPサーバーのツール引数として外部へ送られる経路があるからです。社外のWeb検索や外部SaaSへの書き込みツールを同じセッションに並べないことが、運用上の最低線になります。

自社アプリでつなぐ場合、Slackアプリに設定したIP許可リストはMCPサーバーへのリクエストにも適用されます。社内プロキシの出口IPだけを許可すれば、プロキシを通らない経路からの接続は拒否されます。ただしIPでは端末の所有者までは判定できないため、私物PCを締め出すには、プロキシやVPNの利用自体を会社管理の端末に限る設定と組み合わせる必要があります。Slackと基幹システムをまたいで動くAIエージェントを、権限と経路の設計から作りたい場合は[AIエージェント開発](/service/ai/agent/)の範囲でご相談いただけます。

## よくある質問

Slack MCPの導入検討でよく出る疑問に、公式ドキュメントとGitHubの記載をもとに回答します。

### Slack公式MCPサーバーのURLは何ですか？

`https://mcp.slack.com/mcp` です。通信はStreamable HTTP上のJSON-RPC 2.0だけで、SSEには対応していません。クライアントの設定でtypeを選ぶ欄があれば `http` を指定します。

### CodexからSlack公式のMCPを使えますか？

2026年10月24日時点のCodex 0.163.0では、Slack公式ガイドの手順のままでは認証できません。DCRで止まるため、自社のSlackアプリのclient IDとsecretを渡すか、ユーザートークンを `bearer_token_env_var` で渡す必要があります。Gemini CLIなどへ `npx skills` で入れられるSlackのスキルも、MCPサーバーへの接続は含みません。

### Slack MCPのclient IDはどこで確認しますか？

Claude CodeとCursorでは、Slackがクライアント向けに登録したアプリのIDがプラグインに入っているので、自分で用意する必要はありません（Claude Codeは `1601185624273.8899143856786`）。自社アプリでつなぐ場合は、[Slackのアプリ管理画面](https://api.slack.com/apps)で対象アプリを開き、Basic InformationのApp Credentialsに表示されるClient IDとClient Secretを使います。

### Slack MCPは無料プランのワークスペースでも使えますか？

開発者ドキュメント（2026年10月24日時点）には、プランによる利用条件の記載がありません。書かれている条件は、管理者によるアプリの承認と、Marketplace掲載アプリか社内アプリであることの2点です。監査ログとOkta連携はEnterprise系のプランに限られます。プラン側で絞られている機能はツール経由でも同じ扱いになると考え、自社のプランで検索・投稿・canvas作成が通るかを1つずつ確かめてから展開してください。

### AIがどのチャンネルを読んだか後から確認できますか？

EnterpriseプランならAudit Logs APIで確認できます。`mcp_slack_read_channel_tool_called` などMCP専用のアクションが記録され、どのユーザーの代理で読んだかが残ります。ただし、予約送信やリストなど新しく増えたツールには、専用のアクションがまだありません。Enterprise以外のプランでは、読ませるチャンネルを依頼時に指定する運用ルールと、DM系スコープを承認しない設定で、範囲を先に絞っておきます。

## 関連記事

- [Slack Codeとは？コードチャンネルの仕組みと組み込み手順・権限設計](/tech/details/16890/)
- [ChatGPT workspace agentsとは？API起動・Slack連携・権限設計【2026年10月】](/tech/details/18217/)
- [MCPとRAGの違いとは？役割の違いと使い分け・併用アーキテクチャ](/tech/details/15347/)
- [AWS MCP Serverとは？GA版の接続手順と全ツール・権限設計](/tech/details/17726/)

---

出典: [Slack MCPサーバーの接続手順と権限設計｜Claude Code・Codex・Cursorの設定と公式版・OSS版の選び分け](<https://www.issoh.co.jp/tech/details/17875/>)（株式会社一創）