%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
この記事の結論
MCPとSlack APIをつなぐと、AIが会話を探し、要点をまとめ、業務イベントに沿った通知案を作れます。大切なのは、対象となる情報、AIに任せる処理、人が確認する場面を先に決めることです。
MCPとSlack APIをつなぐと、AIが会話を探し、要点をまとめ、業務イベントに沿った通知案を作れます。大切なのは、対象となる情報、AIに任せる処理、人が確認する場面を先に決めることです。
——「必要な決定事項がどのチャンネルにあるのかわからない」
——「CRMの更新をSlackに転記しているが、通知が多くて見落とされる」
——「長いスレッドを読む時間がなく、途中から参加しづらい」
MCP Slack連携とは、Model Context Protocolを介してAIクライアントからSlack APIを利用し、会話の検索や要約、メッセージ投稿を行う仕組みです。HubSpotなど別のシステムも接続すると、CRM上の情報をSlackで共有する流れも設計できます。
以下の画像は、Slackの会話を探す、要約する、関係者に共有するという本記事のテーマを示しています。
本記事では、MCP Slack連携の基本構造から、検索・要約・通知の使い分け、権限と運用の設計までを整理します。接続前に決める項目と、運用範囲を広げる際の確認事項も順に示します。前提となる考え方はMCP連携ガイドをご覧ください。
この記事でわかること
Slackの情報を探す時間やCRMからの転記を見直したいとき、検索、要約、通知のどこから着手するかを判断するための内容です。必要な権限を決め、取得結果を確認し、投稿へ進むまでの順序を解説します。
- MCPと従来の自動化の違い — AIクライアント、MCPサーバー、Slack APIの役割と、手法を選ぶ基準を整理します。
- 検索・投稿・要約の設計 — 会話の検索結果をどう確かめ、要約や通知にどうつなぐかを紹介します。
- HubSpotとの連携方法 — CRMの情報をSlackに共有するときの条件、記載項目、確認者の決め方を解説します。
- 権限と運用の考え方 — アクセス範囲を絞って試し、結果を見直してから対象を広げる手順を説明します。
MCP Slack連携の基本構造と役割
MCP Slack連携は、AIクライアントがMCPサーバーを介してSlack APIを呼び出す構成です。利用者は自然言語で検索や要約を依頼できます。
ただし、依頼できる操作と取得できる会話は、次のものによって変わります。
- 接続したMCPサーバーの機能
- Slack Appの権限
- 対象チャンネルへのアクセス
MCPサーバーが担うこと
MCPサーバーは、AIクライアントとSlack APIの間をつなぎ、利用可能な操作をAIに示します。AIはその操作を選び、会話の取得や投稿などを実行します。
MCP自体が取得結果の正しさを保証するわけではありません。検索対象が広すぎたり、要約の目的が曖昧だったりすると、判断に必要な文脈が抜けることがあります。
導入時は、次の点を分けて決めます。
- 何を探せるか
- どこに投稿できるか
- 取得した内容を誰が確認するか
最初に特定チャンネルの履歴を読む用途を試し、必要な投稿を参照できるか、要約が元の会話と一致するかを確認します。その結果に問題がなければ、投稿機能を追加するか判断します。
従来手法との使い分け
- Slack Workflow Builder ── 決められた条件と処理を組み合わせる用途に向いています
- カスタムBot ── 細かな制御や継続運用の仕組みを個別に作る場合に適しています
- MCP連携 ── AIに自然言語で検索や要約を依頼する用途で検討できます
| 方法 | 得意なこと | 検討時に見る点 |
|---|---|---|
| Slack Workflow Builder | 定型条件に応じた処理 | 条件や分岐が定型化できるか |
| カスタムBot | 個別要件に合わせた処理 | 開発と保守を担う体制があるか |
| MCP Slack連携 | 会話を探し、指示に沿って整理すること | AIの実行範囲と人の確認手順を定義できるか |
選ぶ順序は、まず処理の条件を文章にし、入力が決まれば出力も決まるかを確認することです。
- 条件を固定できるなら ── 定型処理として設計します
- 会話を読んで論点を整理する必要があるなら ── MCPによる検索や要約を試します
- 個別の制御や保守体制が必要なら ── カスタムBotを含めて比較します
MCPサーバーの選定、権限設定、AIクライアントの管理は、導入後も必要です。試行時には、期待する結果だけでなく、取得できなかった会話や人による修正も記録すると、手法を見直す材料になります。
業務フローのどこに置くか
Slackは会話の共有先であり、顧客や取引の正式な記録先とは役割が異なります。HubSpotを使う場合、コンタクトや会社の情報を管理し、取引やチケットの進捗を更新した後、関係者への連絡をSlackに流す形が考えられます。
通知を設計する前に、その情報を後から確認する人がどこを見るべきかを決めます。
- HubSpotを記録の正本とするなら ── Slackには対応に必要な要点、次に動く担当者、レコードへの導線を載せます
- Slackの会話から新たな決定が生まれた場合 ── 担当者が内容を確認してHubSpotに記録します
これにより、通知を読んだ後の行動と、記録を残す場所が明確になります。
Slack連携のセットアップと権限設計
セットアップでは、次の順に進めます。
- Slack Appの権限
- MCPサーバーの設定
- 接続確認
必要な権限は用途から逆算し、読み取りと投稿を分けて設計します。
会話履歴の取得とメッセージ投稿では確認する権限が異なるため、利用する操作ごとに公式APIの説明を照合します（出典：conversations.history、chat.postMessage）。
用途から必要な権限を決める
Slack Appには、実行する操作に対応したOAuthスコープを付与します。たとえば次のとおりです。
- 投稿 ──
chat:writeが関係します - パブリックチャンネルの履歴取得 ──
channels:historyが関係します - プライベートチャンネル ── 別のスコープとBotの参加条件が関係するため、対象チャンネルを先に決めてから設定します
| 用途 | 確認する権限・条件 | 判断のポイント |
|---|---|---|
| パブリックチャンネルの履歴取得 | channels:history とチャンネルへのアクセス |
閲覧対象を限定できるなら対象を先に絞ります |
| プライベートチャンネルの履歴取得 | groups:history とBotの参加 |
招待するチャンネルを管理者と確認します |
| メッセージ投稿 | chat:write と投稿先へのアクセス |
投稿専用なら読み取り権限を追加しません |
| チャンネル情報の確認 | 利用するMCPサーバーが必要とする読み取り権限 | 実際に呼び出すAPIとスコープを照合します |
- 実行したい操作と対象チャンネルを一覧にする
- MCPサーバーが実際に呼び出すAPIとSlack Appのスコープを照合する
- 必要な権限を特定できない操作は、接続確認へ進める前にサーバーの説明を確認する
用途に含まれない操作の権限は追加せず、対象を広げる際に改めて判断します。
MCPクライアントを設定する
AIクライアントの設定ファイルにMCPサーバーを登録します。以下は設定の考え方を示す例です。実際のコマンドや環境変数名は、採用するサーバーの公式手順に合わせてください。
{
"mcpServers": {
"slack": {
"command": "サーバー起動コマンド",
"args": ["サーバーの引数"],
"env": {
"SLACK_BOT_TOKEN": "環境変数から読み込む値",
"SLACK_TEAM_ID": "対象ワークスペースの識別子"
}
}
}
}トークンを設定ファイルに直接書く構成では、ファイルの共有や保存先にも注意が必要です。
- 管理方法 ── 利用環境で安全に管理できる方法を選び、認証情報をチャットやソース管理へ貼り付けない運用にします
- 設定後 ── 投稿を試す前に、限定した対象で読み取りができるかを確かめます
接続後に読み取りから確認する
接続確認では、次の点を順に見ます。
- 対象チャンネルを参照できるか
- 許可した範囲の履歴を取得できるか
- 取得結果に想定外の会話が含まれないか
取得できない会話があれば、検索の指示を変える前に、対象チャンネル、権限、Botの参加状況を確認します。想定外の会話が含まれる場合も、投稿テストには進まずアクセス範囲を見直します。
読み取り結果が意図した範囲に収まったら、投稿先を限定して通知文を確認します。次のものが揃った場合に投稿を試します。
- 宛先
- 記載内容
- 元情報への導線
- 確認者
誤った投稿に気づいた際に誰が確認し、どの記録を直すかも決めておきます。
チャンネル横断検索で情報を探す
Slack検索では、情報がどのチャンネルやスレッドにあるかを利用者が覚えていない場合があります。AIに検索目的、対象チャンネル、期間を伝えると、取得した会話の整理を支援できます。
検索結果は根拠となる投稿と一緒に確認し、要約だけで業務上の事実を確定しないようにします。
検索条件を具体化する
「価格改定について探して」とだけ依頼すると、対象期間や決定事項の範囲が曖昧になります。対象チャンネル、期間、探したい内容、出力形式を指定すると、結果を確かめやすくなります。
#sales チャンネルで、指定した期間に価格改定について議論した投稿を探してください。
決定事項、未決事項、関連するスレッドを分け、各項目に元投稿への参照を付けてください。「値上げ」「料金体系の見直し」など同じ話題を指す表現も含めるよう依頼できます。
- 結果を受け取ったら ── 決定事項として挙がった項目から元投稿を開き、発言後に結論が変更されていないかを見ます
- 該当する投稿が見つからない場合 ── 対象チャンネルや表現を見直し、見つからなかったことだけを根拠に、議論が存在しなかったとは判断しません
検索結果を業務知識として整理する
チャンネルごとに散らばった情報をまとめるときは、次の項目を分けます。会話中に挙がった意見と、実際に決まったことを混同しないためです。
- 話題
- 決定事項
- 担当
- 次の確認事項
顧客対応に関わる内容は、担当者が元投稿を確認したうえで、HubSpotの会社、コンタクト、取引、チケットのどこに残すかを決めます。
| 検索目的 | 指示に含める条件 | 出力後の確認先 |
|---|---|---|
| 顧客対応の状況確認 | 顧客名、対象チャンネル、期間 | HubSpotの会社やチケット |
| プロジェクトの決定事項 | プロジェクト用チャンネル、議題、期間 | プロジェクト管理の記録 |
| 障害対応の振り返り | エラーの種類、報告先、期間 | 対応記録や関連スレッド |
| 競合情報の収集 | 全チャンネルを横断し、Competitor Xへの言及を対象期間ごとに検索・集約する | 社内に散在する競合インテリジェンスの統合 |
表の「全チャンネル」は検索したい範囲を示す条件です。実際に取得できた範囲とは分けて確認します。
結果を記録へ移す際は、参照した投稿と確認者を残し、未確認の解釈を決定事項として記載しないようにします。
公式APIの取得条件を踏まえる
Slackの conversations.history は、指定した会話のメッセージ履歴を取得するAPIです。
必要なスコープは会話の種類に応じて異なり、取得できる範囲はトークンの権限やアプリの参加状況にも依存します（出典：conversations.history）。
「全チャンネルを横断する」と指示しても、対象のすべてを取得できたとは限りません。
- 網羅性が必要な業務 ── 検索対象の一覧と実際に取得できた範囲を照合します
- 対象外のチャンネルがある場合 ── 理由を確認し、結果の説明にも取得できた範囲を明示します
- 重要な結論 ── 抽出された要約から元投稿へ戻って確かめます
HubSpotの業務イベントをSlack通知につなぐ
HubSpotとSlackを接続する目的は、CRM上で起きた業務上の変化を、次に動く関係者へ伝えることです。
コンタクトの登録、取引ステージの変更、チケットの作成や更新などを起点に通知内容を整理できます。通知を見た後の対応や進捗はHubSpotへ記録し、関係者が確認する場所を揃えます。
通知条件を業務上の判断に合わせる
取引のステージ変更を通知する場合、まず「誰が、変更を受けて何をするか」を決めます。行動が定まっていない変更まで全員に送ると、通知の目的が曖昧になります。
対応が必要なイベントを選び、受け手と投稿先を対応づけます。
| CRM上のイベント | 通知の目的 | 設計する内容 |
|---|---|---|
| コンタクトの登録 | 初回対応の担当を決める | 担当者、会社、問い合わせ内容 |
| 取引ステージの変更 | 次の営業行動を共有する | 取引名、変更後のステージ、担当者 |
| チケットの優先度変更 | 対応が必要な関係者を集める | チケット、優先度、対応担当 |
| 取引のクローズ | 顧客対応を引き継ぐ | 合意事項、顧客の背景、次の対応 |
| CRMイベント | スコアが閾値を超えたとき | 該当する担当チームのチャンネル |
表の各イベントについて、通知を読んだ担当者が次の行動を判断できるかを確かめます。
- 判断材料が足りなければ ── 記載項目を見直します
- 誰にも具体的な行動がなければ ── 即時の通知ではなく定期的な確認に回すか、通知対象から外します
通知文には必要な要点とHubSpotレコードへの導線を示します。顧客情報や商談メモを長文で複製せず、閲覧権限のある担当者が正本を確認できる形にします。
AIに任せる処理と人が決める処理を分ける
AIは複数の投稿から要点を抽出し、決めた形式に整える作業を支援できます。一方で、取引ステージの定義や通知を受けて行う営業判断は、社内の業務ルールに基づいて人が決めます。
| 処理 | AIが支援できること | 人が確認すること |
|---|---|---|
| 投稿の要約 | 決定事項や次の行動の整理 | 元投稿との一致 |
| 取引通知の下書き | 取引情報を指定形式に整形 | 宛先、内容、共有範囲 |
| 問い合わせの分類 | 文面から分類候補を提示 | 担当部門や優先度の最終判断 |
| 取引の更新 | 変更候補や根拠の整理 | CRM上の更新を行うか |
最初はAIが通知文を作り、担当者が対象レコード、宛先、共有範囲を確認してから投稿します。
- 確認時に同じ修正が続くなら ── 指示や通知条件を見直します
- 根拠と責任者が明確になり、担当者が内容を安定して確認できる処理 ── 自動投稿の範囲を検討します
通知を仕組みにして引き継げる状態にする
通知の条件、投稿先、記載項目、確認担当を文書化します。あわせて、次の点を記します。
- 通知を受けた後に誰がHubSpotを更新するか
- 内容に誤りがあった場合はどこを確認するか
担当者が交代しても、通知から次の行動と記録先をたどれる状態が目標です。
運用後は、対応につながらなかった通知と、必要なのに届かなかった連絡を確認します。
- 対応につながらなかった通知 ── 条件や宛先を絞ります
- 必要なのに届かなかった連絡 ── 起点となるイベントや対象者を見直します
通知件数だけで良し悪しを判断せず、必要な行動に結びついたかを確認します。
スレッド要約を意思決定と引き継ぎに使う
スレッド要約は、長い会話から決定事項と未決事項を分け、途中から参加する人に議論の経緯を示す用途に向いています。重要な意思決定では、要約の各項目から根拠となる投稿を確認できる形にします。
要約形式を先に決める
要約の依頼時に出力項目を指定します。次の項目を分けると、読み手が次の行動を選びやすくなります。
- 決定事項
- 未決事項
- 担当
- 期限
- 根拠となる投稿
対象スレッドを要約してください。
決定事項、未決事項、次のアクションに分けてください。
担当者が明記されていない場合は推測せず「未設定」とし、根拠となる投稿を添えてください。担当者や期限が会話に書かれていない場合は、未設定として残します。そのまま進めると対応が止まる項目については、要約の確認者が担当者や期限を決め、決定を記録します。
| 場面 | 整理のしかた |
|---|---|
| 技術ディスカッション | 検討された選択肢、採用された結論、判断の理由を分けます。結論が読み取れなければ未決事項として扱い、担当者に確認します。 |
| 顧客フィードバック | 顧客が述べた評価と改善要望を分けます。社内の解釈を加える場合は元の発言と区別し、担当者が確認してから対応方針に反映します。 |
| チャンネル別のハイライト | チャンネルごとに決定事項と次の行動を整理します。同じ話題が複数の場所で扱われていたら、結論が一致しているかを元投稿で確かめます。 |
顧客フィードバックの要約では、評価を肯定的な内容と否定的な内容に分けて整理します。
Slackの機能とMCPの役割を分ける
- Slack上のスレッドをその場で把握したいなら ── 利用環境で使える画面上の要約方法を確認します
- 複数チャンネルの内容を指定形式で整理したり、CRMの記録と照合したりする必要があるなら ── MCP経由でAIクライアントに依頼する設計を検討します
接続したサーバーが提供する操作、権限、Slack APIの取得条件によって実行範囲は変わります。最初に対象を絞ったスレッドで、次の点を確かめます。
- 必要な投稿を取得できたか
- 決定と意見を分けられたか
- 参照先を示せたか
確認できない項目が残る場合は対象を広げず、取得条件や要約形式を見直します。
要約をCRMへ引き継ぐ
顧客との会話に関する決定や次の対応は、担当者が要約案を確認してから、HubSpotの該当レコードに必要な範囲で記録します。会社、コンタクト、取引、チケットのどこに残すかは、後からその情報を使う業務を基準に選びます。
記録時には、確定した決定と未解決の論点を区別します。
- Slack ── 議論の文脈をたどれるようにします
- HubSpot ── 顧客対応の履歴と進捗を確認できるようにします
要約案と元投稿が食い違う場合は、記録を進める前に担当者が内容を確認します。
通知疲れと運用リスクを抑える
自動化の対象を増やすと、通知を受ける人や共有される情報も増えます。導入時は、次のことに気づく手順まで設計します。
- 情報の取り違え
- 権限の過剰付与
- 要約の誤り
対象を絞って試し、確認できた処理から適用範囲を広げます。
通知条件を絞り、受け手を定める
通知先は、情報を受け取って具体的な行動を取るチームや担当者に合わせます。緊急対応、進捗共有、定期確認では、必要な受け手と投稿内容が異なります。
| 通知の種類 | 投稿先の考え方 | 投稿する内容 |
|---|---|---|
| すぐ対応が必要な連絡 | 対応担当と関係者 | 要対応の理由と次の確認事項 |
| 営業やCSの進捗共有 | 該当するチーム | 変更点とCRMレコードへの導線 |
| 定期的な状況共有 | 定例で確認するチャンネル | 集計対象と確認時点 |
| 参考情報 | 専用チャンネルやまとめ | 要点と元情報への参照 |
| クレーム発生時 | 担当者へのDMと管理者への通知 | クレームの内容と対応状況 |
| 定期 | パイプラインサマリーやKPI達成状況 | 全体チャンネルで共有し、日次または週次に確認 |
通知ごとに、受け手、期待する行動、確認先を定めます。期待する行動を説明できない情報は、投稿対象や頻度を見直します。
運用後は、対応につながらなかった通知と、受け手に届かなかった情報を確認し、条件と宛先を調整します。
AIの出力を人が確認する
AIの要約や通知文には、文脈の抜けや事実の誤認が含まれる可能性があります。取引金額、契約条件、顧客への約束など重要な情報は、CRMの正本や元投稿に照らして確認します。
通知案の確認者は、次の順に見ます。
- 対象レコード
- 変更内容
- 共有先
- 次の行動
根拠が確認できれば投稿し、確認できない情報は通知文から外して担当者に確認します。宛先が判断できない場合も投稿を保留し、業務上の受け手を先に決めます。
レート制限と取得範囲を考慮する
Slack APIにはメソッドごとのレート制限があります。
- 履歴取得 ── 対象チャンネルと期間を絞り、必要な範囲をページネーションで取得する設計を検討します
- 取得結果が途中で止まった場合 ── どこまで確認できたかを判別できるようにします（出典：conversations.history）
投稿が集中する可能性がある場合は、利用するアプリと投稿先の条件を確認します。CRMの更新をそのまま個別に投稿する前に、受け手が各通知で行動する必要があるかを判断します。
- 個別の対応が必要なら ── 投稿順と再試行の扱いを決めます
- まとめて確認できる内容なら ── 要約して共有します（出典：Slack公式 chat.postMessage）
履歴取得側も、利用するアプリの条件に合わせて設計します。対象の取得条件と実際の応答を確認し、取得漏れがあれば検索結果を完全な一覧として扱わず、対象範囲や取得方法を見直します。
制限を示す応答を受けた場合は、その案内に従って再試行を制御します（出典：Slack公式 conversations.history、Slack公式レート制限）。
まず読み取りから始める
導入初期は、対象チャンネルの検索やスレッド要約など、情報を読み取って整理する用途から始めます。人が次の点を確認します。
- 元投稿への参照が付くか
- 決定事項と未決事項を分けられるか
必要な情報を取得できない場合は、投稿機能へ進む前に対象と権限を見直します。
読み取り結果を確認できたら、投稿先を限定して通知案を試します。担当者が宛先と内容を確認し、重複投稿や誤った共有先がないことを確かめます。問題があれば条件を修正し、確認手順を整えてから対象範囲を広げます。
よくある質問
MCP Slack連携にはプログラミングスキルが必要ですか？
利用するAIクライアントとMCPサーバーによって設定方法は異なります。初期設定で構成ファイルや認証設定を扱う場合は、その設定を確認できる担当者が必要です。日常の検索や要約は自然言語で依頼できます。運用を始める前に、権限の変更と接続不良の確認を誰が担うかを決めておきます。
プライベートチャンネルも検索できますか？
Botが対象チャンネルに参加し、必要なスコープが付与されている場合に、APIで取得できる範囲の情報を扱えます。まず検索する必要があるチャンネルを特定し、アクセスさせる範囲を管理者と確認します。接続後は、対象の会話を取得できるかと、対象外の会話が含まれないかを確かめます。
Slackへの投稿を自動化できますか？
Slack APIの投稿機能を使う構成では、MCP経由で投稿操作を行えます。最初はAIが通知案を作り、担当者が宛先、内容、元情報を確認する形で試します。誤りがあった場合の修正手順と責任者を決め、通知条件が明確になった処理から自動投稿の範囲を検討します。
Slack AIの要約機能と併用できますか？
用途に応じて併用を検討できます。Slack上の会話をその場で把握する場合と、複数システムの情報を照合して定めた形式で整理する場合では、必要な操作が異なります。まず必要な出力と確認先を決め、利用環境で使える機能と接続設定を確認してください。詳細はSlack AIのビジネス活用ガイドをご覧ください。
HubSpotとの連携では何を管理しますか？
HubSpotでは顧客や取引、チケットの情報を管理し、Slackでは関係者への共有や会話を行う形が考えられます。通知には次の行動に必要な要点とレコードへの導線を含め、対応結果や進捗はHubSpotへ記録します。どのオブジェクトに残すかは、後から情報を確認する担当者と社内の顧客対応フローを基準に決めます。
まとめ
MCP Slack連携は、AIクライアントからSlackの会話を検索し、要約し、通知を組み立てるための仕組みです。導入時は、検索対象と権限を定め、元投稿と出力を照合し、通知を受けた人の行動と記録先を決めます。
まずは、特定チャンネルのスレッド要約から始めます。
- 対象チャンネル、探す情報、結果を確認する担当者を決めます。
- 読み取り権限で接続し、取得範囲と元投稿への参照、要約内容を確認します。
- 必要な情報を確認できたら、通知条件と宛先を決め、担当者の確認を経て投稿を試します。
- 取得漏れや通知の誤りがあれば条件を見直し、対応手順が明確になった範囲から運用を広げます。
企業様によって最適な形は異なります。CRMを活用した業務効率化やAIとの連携について、検索対象の決め方、HubSpotに残す情報、Slack通知の条件を整理したい場合は、StartLinkまでお気軽にお問い合わせください。
あわせて読みたい
MCPを使う業務の範囲を比較したい場合は、メールと予定、CRMと会計、デザイン作業を扱う以下の記事も参考にしてください。それぞれ、連携対象に応じて何をAIに任せ、どの結果を人が確認するかを考える際の材料になります。
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
