AntigravityとSlackを連携する手順｜MCP経由で通知・操作を自動化する設計ガイド

本記事を読めば、Slack通知の自動送信、特定チャンネルからのデータ取得、Slack上でのエージェント操作を自力で構築でき、問い合わせ一次対応や定例報告の確認工数を月10時間以上削減できます。

AntigravityとSlackをMCP経由でつなぐと、エージェントがSlackを業務の入口として扱えるようになります。AIzen株式会社は、AIエージェントを組み込んだ業務アプリ開発や社内DX基盤の設計を支援してきました。

本記事では、情シス・DX担当者向けに、認証、スコープ、接続方式、実装、トラブル時の確認順序までを整理します。

AntigravityとSlackの連携で必要な4つの準備

AntigravityとSlackの連携は、トークンを貼り付けるだけでは安定運用できません。通知だけを送るのか、チャンネル履歴を読むのか、Slack上からエージェントに依頼するのかで設計は変わります。MCPサーバー、トークン種別、権限スコープ、エラー時の切り分け順序を先に決めます。

MCPサーバーの選定で確認するポイント

Slack公式MCPサーバーは、JSON-RPC 2.0 over Streamable HTTPで動作し、エンドポイントは https://mcp.slack.com/mcp です。利用には登録済みSlack app固定IDが必要で、内部アプリまたはMarketplace公開アプリが対象です。ローカルMCPで試す場合でも、認証方式、ログ取得、再認証時の影響範囲を確認します。

Bot Token・User Token・OAuthの使い分け

Bot Tokenは、アプリとして投稿したり、Botが参加しているチャンネルで操作したりする用途に向きます。User Tokenは、認可したユーザーの権限で検索や履歴参照を行う用途に使います。OAuth構成では client_id と client_secret を使います。chat.postMessage が403になる場合は、Token種別の取り違え、Bot未参加、スコープ不足を優先して確認します。

権限スコープの設計

スコープは「広く付ける」ではなく、業務に必要な範囲だけを付与します。通知送信は chat:write、履歴取得は channels:history や groups:history、DMは im:history、検索は search:read.* 系、ファイル参照は files:read、メンバー情報は users:read が代表例です。扱うデータの機密度が高いほど、対象チャンネルと保存先ログを明確にします。

利用目的	主なスコープ例	確認事項
チャンネルへ通知する	chat:write	Botが投稿先に参加しているか
履歴を取得する	channels:history、groups:history	対象チャンネルを限定できるか
DMやスレッドを扱う	im:history、mpim:history	個人情報の扱いを定義しているか
検索・ファイル参照を行う	search:read.*、files:read	取得データの保存範囲を決めているか

連携が動かないときの切り分け順序

エラー時は、認証、スコープ、チャンネル参加、MCP通信、Slackイベントの順で確認します。401は認証情報の期限切れや設定不一致、403は権限不足やToken種別の誤り、404はエンドポイントやチャンネルIDの指定ミスが主な原因です。Slack APIのレスポンスとMCPサーバーのログを同じ時刻で突き合わせると、原因を短時間で絞れます。

MCPサーバーの選定と接続方式

MCPサーバーは、AntigravityからSlackを操作する中継層です。小さく試す段階ではローカルMCPが有効ですが、複数部署で使う場合は、認証情報の置き場所、監査ログ、障害時の責任範囲を含めて公式MCPや外部サービスを比較します。

ローカルMCPサーバーを使うケース

ローカルMCPサーバーは、PoCや開発者個人の検証に向いています。Slack APIの呼び出し内容を手元で確認でき、トークン差し替えやスコープ追加も素早く試せます。ただし本番では、担当者端末への依存、トークン管理、アクセスログの標準化が課題になります。検証用と位置づけ、本番では管理された接続方式へ移す前提で設計します。

外部サービス（CData等）経由で接続するケース

外部サービス経由は、Slack以外のSaaSやデータベースとまとめて連携したい場合に有効です。たとえば、問い合わせチャンネルの投稿を取得し、kintone、スプレッドシート、社内DBへ記録する運用では扱いやすくなります。ただし、データの経由地点が増えるため、保存範囲、ログ保持期間、管理者権限、IP制限、契約上のデータ処理条件を確認します。

MCP接続の動作確認と通信ログ

接続確認は、検証用チャンネルへの固定文投稿から始めます。chat:write だけで投稿できることを確認し、その後に履歴取得、スレッド取得、検索を追加します。ログでは、AntigravityからMCPサーバーへのツール呼び出し、MCPサーバーからSlack APIへのリクエスト、Slackのレスポンスを分けて見ます。Slack側で成功しているのにAntigravity側で失敗する場合は、JSON-RPCの戻り値やレスポンス整形を確認します。

AntigravityとSlackの認証設定の手順

認証設定では、Slack側でアプリを作成し、Antigravity側へMCPサーバーと認証情報を登録します。情シス部門では、誰の権限で、どのチャンネルに、何ができるかを明確にし、異動や退職でUser Tokenが無効になるリスクも考慮します。

Slack側でのアプリ作成と認証情報の発行

Slack側では、ワークスペースにアプリを作成し、OAuth & Permissionsで必要なスコープを設定します。通知投稿が目的ならBot Token Scopesに chat:write を追加し、投稿先チャンネルにBotを招待します。履歴取得や検索を行う場合は、対象範囲に応じてUser Token Scopesも検討します。公式MCPを使う場合はSlack app固定IDが前提です。

Antigravity側でのMCPサーバー登録と認証情報の連携

Antigravity側では、MCPサーバーのエンドポイント、認証方式、利用するツール名を登録します。Slack公式MCPを使う場合は、https://mcp.slack.com/mcp を接続先として扱い、OAuth設定に必要な情報を紐づけます。

ローカルMCPでは、ローカルホストのURLと環境変数に保存したSlackトークンを参照します。登録後は実運用チャンネルではなく、検証用チャンネルで投稿と履歴取得を確認します。

再認証が必要になる条件と切り替え

再認証が必要になるのは、スコープ変更、Slackアプリの認証情報更新、OAuthトークンの無効化、ワークスペースのセキュリティ設定変更などです。

Webhookやイベント購読を使っている場合、再認証やアプリ再インストールのタイミングで通知先設定が切れることがあります。切り替え時は、チャンネルID、Webhook URL、イベント購読URL、MCPサーバーの環境変数を一覧で確認します。

通知・操作・データ取得の実装手順

実装は、通知、データ取得、Slack上での操作依頼の順に広げると管理しやすくなります。投稿や返信は社内メンバーの目に触れるため、完全自動で実行してよい処理と、人の確認を挟む処理を分けて設計します。

特定チャンネルへの自動通知の設定

自動通知では、社内システムのエラー、日次レポートの完了、承認依頼の発生などをSlackへ送れます。実装時は、通知先チャンネルID、本文テンプレート、メンション有無、失敗時の再送条件を定義します。本文には、タイトル、発生日時、対象システム、確認URL、次のアクションを含めると、担当者が読んだ瞬間に対応を判断できます。

スレッドや返信の取得とエージェント連携

スレッド取得では、本文、返信、投稿者、投稿時刻、添付ファイルの有無を合わせて扱います。問い合わせチャンネルなら、未回答の投稿を抽出し、過去の返信を要約し、担当者に対応案を提示できます。

取得対象は最初から全チャンネルに広げず、「問い合わせ」「障害対応」「申請受付」など業務ごとに限定します。

弊社エンジニアからのコメント：

Slack連携では、Bot Tokenで投稿できる範囲とUser Tokenで読める範囲を同じものとして扱うと、chat.postMessage が403になったり、履歴取得だけ成功して投稿が失敗したりします。

実装前に「投稿」「検索」「履歴取得」を別々の検証項目に分け、各処理で使うトークンとスコープを表にすると、初回設定の確認時間を短縮できます。

Slack上でエージェントに作業を依頼するパターン

Slack上でエージェントに依頼する入口は、メンション、スラッシュコマンド、専用チャンネル投稿の3つが中心です。問い合わせ一次回答ならメンション、定型処理ならスラッシュコマンド、部署横断の依頼受付なら専用チャンネルが向いています。実行結果をSlackに返す際は、数値の根拠、参照元URL、実行した処理を含めると、業務利用での信頼性が上がります。

AntigravityとSlackの連携が動かないときの確認順序

Slack連携の不具合は、認証エラー、スコープ不足、Webhookやイベントの未達に分かれます。障害時は「Antigravity側の問題か」「MCPサーバー側の問題か」「Slack側の問題か」を分けるため、各ログの時刻をそろえます。

認証エラーで止まるケース

認証エラーでは、まずトークンの有効性を確認します。Slackアプリの再インストール、スコープ変更、管理者によるアプリ承認設定の変更があると、以前のトークンが使えなくなる場合があります。

401が返る場合は、トークン期限、認可情報の不一致、MCPサーバー側の環境変数更新漏れを確認します。開発環境と本番環境でSlackアプリを分けている場合は、誤った認証情報が入っていないかも見ます。

スコープ不足で操作が拒否されるケース

スコープ不足では、Slack APIのレスポンスに missing_scope や not_allowed_token_type が返ることがあります。投稿、履歴取得、検索、ファイル参照で必要なスコープは異なるため、成功している処理と失敗している処理を分けます。

履歴取得は成功するのに投稿だけ失敗する場合は、chat:write、Botのチャンネル参加、Token種別を確認します。スコープ追加後は再インストールや再認証も必要です。

Webhookやイベントが届かないケース

Webhookやイベントが届かない場合は、送信元と受信先の両方を確認します。イベント購読URL、MCPサーバーの到達性、署名検証を順番に見ます。

ローカルMCPでは、トンネルURLの期限切れやURL更新漏れも原因になります。再認証後に通知が止まった場合は、Slackアプリ設定、MCPサーバーの環境変数、Antigravity側の登録情報を照合します。

まとめ

AntigravityとSlackをMCP経由で連携すると、Slack通知、チャンネル履歴の取得、Slack上からのエージェント操作を業務フローに組み込めます。

まずはMCPサーバー、Token種別、スコープを整理し、通知・読み取り・操作を分けて設計することが重要です。実装は検証用チャンネルで投稿から始め、履歴取得、検索、Slack上の操作依頼へ段階的に広げます。動かないときは認証、スコープ、Webhook・イベントの順でログを照合すると、原因を短時間で切り分けられます。

AIzen株式会社では、AIエージェントを組み込んだ業務アプリ開発、Slackなどの業務ツール連携を支援しています。AntigravityとSlackの連携を運用したい場合は、権限設計やMCPサーバー選定からご相談いただけます。