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サーバーの作り方で解説しています。Slackの場合は接続の向きが2つあり、どちらの話かによって設定がまったく異なります。

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

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

2つ目は、SlackbotがMCPクライアントとして外部のMCPサーバーを呼ぶ向きです。LinearやCanva、Figmaなどを会話の中からSlackbotに操作させる機能で、Slackのモデルコンテキストプロトコルのガイドには、MCPクライアント側のパートナーが15社並んでいます。Slack内で@Claudeに仕事を頼むClaude Tagの仕組みと旧appからの移行もSlack側からAIを呼ぶ向きで、本記事の手順とは別物です。Slack上でAIに答えさせるBotを自作する構成はSlack BotにAIで回答させる作り方で扱っています。

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

Slack MCP server overviewによると、ツールは検索、メッセージ、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日の変更履歴で発表されました。同じ日に、従来のData Access APIがリアルタイム検索API（RTS API）へ改称されています。

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

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

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

開発者ドキュメントが「Available clients」に挙げているのはClaude.ai、Claude Code、Perplexity、Cursorの4つです。ヘルプセンターの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でプラグインを公開しています。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のハーネス接続ガイドのCLI例はclient IDを含んでいません。しかしDCRが使えない以上、client IDを渡さない構成では登録の段階で止まるので、Claude CodeのMCPドキュメントにある --client-id と --callback-port を付けてください。--scopeの選び方や.mcp.jsonをチームで共有する手順は、Slack以外のMCPサーバーにも共通するためClaude CodeのMCP設定とスコープ・.mcp.jsonの解説にまとめています。

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のログイン方法と認証エラーの直し方を参照してください。

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

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

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

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

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

Slackのハーネス接続ガイドには、Codex向けとして codex mcp add と ~/.codex/config.toml の2通りが載っています。一方、同じSlackのプラグインのページには「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（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から、事前登録したクライアントのIDを渡せるようになっています。0.163.0には --oauth-client-id と --oauth-client-secret があり、設定リファレンスでは 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ガイドに書かれているので、権限を縮めるときは旧トークンを失効させてから認証し直します。
• redirect_uriの末尾にIDが付く：mcp_oauth_callback_url に http://localhost:3118/callback を指定しても、送られるのは /callback/lukW65nqn7xj でした。Slackの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」をオンにしておく必要があります。開発者向けガイドに書かれている手順で、オフのままだと「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の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ドキュメントによると、自社アプリで接続するときに登録するリダイレクトURLは、デスクトップアプリなら http://localhost:8787/callback です。

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

Piは拡張の pi-mcp-adapter を入れてからMCPサーバーを追加します。ハーネス接続ガイドの手順は次のとおりです。

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版の変更点で整理しています。

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種類が並んでいました。承認申請では、用途ごとに束ねて示すと話が通りやすくなります。

情報漏えいの観点で最も重いのは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エージェントへの接続手順で扱っています。

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

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

自社のclientIdに差し替えるとredirect_uriが一致しない不具合

公式リポジトリのIssue #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接続ドキュメントどおり、次の形で自社アプリの資格情報を渡せます。

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ガイドによると、PKCEを有効にしたアプリでは localhost へのリダイレクトがデスクトップ向けとして扱われます。localhostを登録する手がかりはここにありますが、代償も大きい設定です。

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

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

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

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

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

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

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

MCPの公式リポジトリにあった参照実装のSlackサーバーは、servers-archivedへ移されました。リポジトリ自体がアーカイブ扱いで、説明文は「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で、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版のstealth modeは使いません。規程上の問題に加え、退職者のブラウザトークンが誰かのPCに残り続ける経路を作るためです。Codexで公式版がつながらないことは、OSS版を選ぶ理由になりません。OSS版を使ってよいのは、個人のワークスペースや開発者サンドボックスで挙動を試す場面に限られます。

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

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

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

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

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

監査ログのmcp_slack_*_tool_calledでAIの操作を追跡する方法

Audit Logs APIのアクション一覧には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サーバーへのアクセスを管理する」によると、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エージェント開発の範囲でご相談いただけます。

よくある質問

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のアプリ管理画面で対象アプリを開き、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とは？コードチャンネルの仕組みと組み込み手順・権限設計
• ChatGPT workspace agentsとは？API起動・Slack連携・権限設計【2026年10月】
• MCPとRAGの違いとは？役割の違いと使い分け・併用アーキテクチャ
• AWS MCP Serverとは？GA版の接続手順と全ツール・権限設計