Teams連携の設計で最初に確認したのは、「その通知方法はいつまで使えるか」でした。Microsoft Teamsの旧来のIncoming Webhook(Office 365コネクタ)は、すでに公式に廃止スケジュールが進んでおり、設計時点で何を選ぶかが運用の寿命を直接左右します。
アーキテクチャの判断は一つの問いから始まります。「通知は一方向で十分か、それとも承認・タスク起票まで双方向で動かす必要があるか」。この問いに答えないまま「とりあえずWebhookで通知だけ」と進めた連携は、あとから承認フローを足す段階で必ず作り直しになります。
SlackとTeamsでは、連携の選択肢も認証モデルも、廃止スケジュールも異なります。設計前に確認すべき技術的チェックポイントを、実装視点で整理します。
SlackやTeamsとAIエージェントを連携すると、社内業務はどう変わりますか?
SlackやTeamsとAIエージェントを連携すると、社内業務の通知だけでなく承認やタスク起票まで自動化でき、チャットツールがAIの「指揮センター」として機能します。担当者が複数のシステムを開いて確認する作業が、チャット画面上の操作1つに集約されます。
多くの企業で、社内の情報伝達はすでにSlackやMicrosoft Teamsに集まっています。一方で、在庫アラート・承認依頼・問い合わせ通知などはそれぞれ別システムに残り、担当者は「チャットを見て、別システムを開いて、再び戻る」という往復を毎日繰り返しています。この往復こそが、対応漏れと遅延の温床です。
AIエージェントをSlack・Teamsに連携させると、この構造が変わります。AIがシステム側のイベントを検知してチャットに通知し、さらにチャット上のボタン操作を受け取って、承認・差し戻し・タスク登録を実行します。通知が「読むだけ」から「その場で処理する」へ変わるのが本質です。
WindyFloを使った構成では、AIエージェントがSlackやTeamsを入出力の窓口にして、ERPや業務システムの処理をチャット上から起動・完了させます。導入企業の参考値では、承認1件あたりの所要時間が画面遷移を含めて平均で半分以下に短縮されたケースが確認されています(参考用推定値)。
“ChatGPTは答えます。WindyFloは働きます。” — チャットに表示される通知は答えではなく、その場で承認・起票まで完了する実働の起点になります。
SlackとTeamsの連携方式にはどんな種類があり、どう違いますか?
SlackとTeamsの連携方式は、大きく「一方向の通知」「双方向の操作」「リアルタイムのイベント受信」の3層に分かれます。Slackは1つのプラットフォーム内で全層が揃う一方、Teamsは通知・操作・イベント受信で使うべきAPIが分かれる点が最大の違いです。
まず全体像を把握するために、両者の主要な連携方式を整理します。
SlackとTeamsの主要連携方式の比較
| 目的 | Slack | Microsoft Teams |
|---|---|---|
| 一方向の通知 | Incoming Webhook | Workflows(Power Automate)※旧コネクタは廃止移行中 |
| メッセージ投稿(双方向の基盤) | Bot Token + chat.postMessage | Bot Framework(Azure Bot)/ Microsoft Graph |
| リアルタイムのイベント受信 | Events API | Bot Framework + Graph 変更通知 |
| ユーザー操作の受付 | Block Kit(Interactive Components) | Adaptive Cards(Action実行はBotが必要) |
| ユーザー起動のコマンド | Slash Command(/コマンド) | Bot コマンド / メッセージ拡張 |
(出典: Slack Developer Docs, 2026 / Microsoft Graph Docs, 2026)
この表から読み取れる設計上の要点は2つあります。
1つ目は、Slackは「Webhookで通知 → Bot Tokenで投稿 → Block Kitで操作受付」が同じアプリ設定の延長で繋がるため、通知から双方向操作への拡張がスムーズである点です。
2つ目は、Teamsは目的ごとに使うAPIが分かれるため、最初に「将来どこまで自動化するか」を決めてからAPIを選ぶ必要がある点です。通知だけならWorkflows、双方向の操作まで含めるならBot Frameworkを前提に設計します。ここを混同すると、後述するIncoming Webhookの廃止問題に直撃します。
Slack連携の技術構成(Bot Token・Events API・Block Kit)はどう設計しますか?
Slack連携は、「Incoming Webhookで通知を始め、Bot Tokenで投稿・操作に拡張し、Events APIでリアルタイム受信、Block Kitで操作UIを作る」という積み上げ式で設計するのが定石です。最初から双方向を見込むなら、Webhookではなくはじめからアプリ(Bot Token)を作る方が手戻りがありません。
それぞれの役割を、実装の順序で整理します。
1. Incoming Webhook(最小構成・一方向通知)
特定のチャンネルにメッセージを送るだけなら、Incoming WebhookのURLにJSONをPOSTする方式が最も簡単です。在庫アラートやエラー通知など「送るだけ」の用途に向いています。ただしユーザーの操作を受け取れないため、承認やタスク起票には拡張できません。
2. Bot Token + chat.postMessage(双方向の基盤)
Slackアプリを作成し、OAuthスコープ(例: chat:write)を付与してBot Tokenを取得します。chat.postMessage APIでメッセージを投稿でき、ここに後述のBlock Kit要素を載せることで操作可能な通知になります。なお、Slackは2025年3月31日にレガシーのカスタムボットのサポートを終了しており、現在は正式なアプリ(Bot Token)としての構成が前提です(出典: Slack Developer Docs, 2025)。
3. Events API(リアルタイムのイベント受信)
Events APIは、メッセージ受信やチャンネル参加など、Slack内で何かが起きたときにアプリへリアルタイム通知を送る仕組みです(出典: Slack Developer Docs, 2026)。「特定キーワードを含む投稿があったらAIが要約する」といった、ユーザー発話を起点とした自動化に使います。
4. Block Kit(操作UIの構築)
Block KitはSlackのUIフレームワークで、ボタン・選択メニューなどのインタラクティブ要素をメッセージに組み込めます。各要素はactionidとblockidで一意に識別され、ユーザーが操作するとその識別子をもとに処理が正しいハンドラへ振り分けられます(出典: Slack Developer Docs, 2026)。承認/差し戻しの2ボタンを置く典型的なパターンも、このActionsブロックで実現します。
5. Slash Command(ユーザー起動)
/コマンド形式でユーザーがAIエージェントを呼び出す入口がSlash Commandです。「/在庫確認 商品コード」のように、チャットから能動的にシステムを操作する用途に向いています。
開発フレームワークとしてはBoltが用意されており、ボタン操作の受信(app.action())、確認(ack)、モーダル表示(views.open())までを一貫して扱えます(出典: Slack Developer Docs, 2026)。
Microsoft Teams連携でIncoming Webhookは今も使えますか?
Microsoft Teamsの旧来のIncoming Webhook(Office 365コネクタ)は廃止が進行中で、新規の本番連携には推奨されません。Microsoftは2026年4月30日を一区切りとしてOffice 365コネクタを段階的に廃止しており、代替として「Workflows(Power Automate)」への移行を公式に推奨しています(出典: Microsoft 365 Developer Blog, 2026)。
ここはTeams連携で最も間違えやすい論点です。「Teams 通知 Webhook」で検索すると古い手順が大量に出てきますが、その多くは廃止対象の方式を案内しています。設計時点で正しい選択肢を知っているかどうかが、運用の寿命を決めます。
① 一方向の通知 → Workflows(Power Automate)
TeamsのWorkflowsアプリは、Webhook URLでHTTPリクエストを受け取り、チャンネルやチャットにメッセージやAdaptive Cardを投稿できます。Power Automateが基盤のため、投稿前にペイロードを加工できる柔軟性があります(出典: Microsoft Learn, 2026)。
ただし投稿はFlow botの表示名で表示され、Adaptive Cardペイロードではカスタムアイコン・表示名は使えない点に注意が必要です(出典: Microsoft Learn, 2026)。
② メッセージ投稿(双方向の基盤) → Microsoft Graph または Bot Framework
Microsoft Graphのチャンネル/チャットへのメッセージ送信(chatMessage)は、現在のところ委任(delegated)権限のみをサポートし、ユーザーコンテキストを必要とします。通常のチャンネル/チャットメッセージ送信ではアプリケーション権限はサポートされていません(出典: Microsoft Graph Docs, 2026)。
つまり、ユーザーの代理ではなく「Botとして」自律的に投稿したい場合は、Bot Framework(Azure Bot)を使うのが正解です。実運用のアプリやTeams Toolkitのサンプルも、メッセージ配信にはBot Frameworkを使う構成がほとんどです(出典: Microsoft Graph Docs, 2026)。
③ 操作の受付 → Adaptive Cards(Action実行はBotが前提)
Teamsの操作UIはAdaptive Cardsで作ります。ただしGraph経由で投稿したカードがサポートするのはOpenUrlアクションのみで、それ以外のインタラクティブなアクション(ShowCardなど)を動かすにはBotが必要です(出典: Microsoft Graph Docs, 2026)。承認ボタンの結果を受け取って処理する双方向フローは、Bot Framework前提で設計します。
要点はシンプルです。Teamsで「通知だけ」ならWorkflows、「承認・タスク起票まで」ならBot Framework。この分岐を最初に決めれば、廃止された方式に依存する事故は起きません。
AIからの「通知」を超えて「承認・タスク起票」まで自動化するには?
通知から承認・タスク起票へ進むには、「ボタン操作を受け取る経路」と「その操作を業務システムへ反映する経路」の2本を用意します。SlackはBlock Kitのインタラクティブ要素、TeamsはAdaptive Cards + Bot Frameworkがその受け口になり、AIエージェントが受け取った操作をトリガーに後続処理を実行します。
「通知の自動化」と「業務の自動化」はよく混同されますが、技術的には別物です。通知は一方向に送れば終わりですが、承認・起票は「ユーザーが押した → その結果を検証する → システムに書き込む → 結果を返信する」という往復が発生します。この往復を設計できるかどうかが分かれ目です。
具体的な自動化シナリオを、現場でよく使う順に挙げます。
承認フロー: AIが申請内容を要約し、Slackなら承認/差し戻しボタン(Block Kit Actions)、TeamsならAdaptive Cardのボタンを添えて担当者に送ります。担当者がボタンを押すと、その操作がAIエージェントに渡り、基幹システムのステータスを更新したうえで結果をスレッドに返信します。
タスク起票: 「問い合わせ通知」を読んだ担当者が、チャット上のボタンやSlash Commandから直接タスクを登録します。AIが内容を分類し、担当部署・優先度を付けてタスク管理ツールへ起票するため、転記の手間と入力ミスがなくなります。
例外時のエスカレーション: AIが自動処理できない例外を検知したら、該当スレッドに関係者をメンションして人の判断を仰ぎます。判断結果は再びAIが受け取り、後続処理を続行します。
設計上の注意点は、承認結果を必ずサーバー側で検証することです。ボタンのペイロードを信用してそのまま書き込むと、なりすましのリスクがあります。Slackは署名シークレットによるリクエスト検証、TeamsはBot Frameworkの認証で、操作の正当性を担保します。
このあたりの双方向設計の考え方は、AIエージェントとERPを連携する方法で扱った「読み取り専用から書き込み許可へ段階的に広げる」原則と共通します。チャット連携でも、まず通知(読み取り)から始め、効果を確認してから承認・起票(書き込み)へ拡張するのが安全です。
通知の洪水を防ぐ設計(フィルタリング・優先度・スレッド)はどうすべきですか?
通知の洪水を防ぐには、「送る前にAIで絞り込む」「優先度でチャンネルを分ける」「関連通知はスレッドにまとめる」の3つを設計に組み込みます。連携で最も多い失敗は、全イベントをそのまま流して通知が埋もれ、結局誰も見なくなることです。技術的には繋がっても、運用では失敗します。
自動通知を入れた直後によく起きるのが「通知が多すぎて重要なものを見落とす」問題です。これは連携の技術ではなく、通知設計の問題として扱う必要があります。設計時に組み込むべき制御を整理します。
1. 送信前のフィルタリング: 全イベントを通知せず、閾値や条件をAIで判定してから送ります。「在庫が安全在庫を下回ったときだけ」「金額が一定以上の申請だけ」といった条件を、送信側で絞り込みます。Power Automate(Workflows)を使えば、Teamsへ投稿する前にこの加工を挟めます。
2. 優先度によるチャンネル分離: 緊急アラートと参考情報を同じチャンネルに混ぜないことが重要です。「即対応が必要な通知」「日次サマリでまとめて十分な通知」を別チャンネルに分け、緊急度の高いものだけメンションを付けます。
3. スレッドへの集約: 同じ案件に関する通知は、最初の投稿のスレッドにぶら下げます。チャンネルのタイムラインを汚さず、案件単位で経緯を追えるようにします。Slackのスレッド、Teamsの返信機能がこれにあたります。
4. サマリ化: 個別通知が多くなる業務は、AIに1日分をまとめさせて「日次サマリ」として1通に集約します。件数が多い問い合わせ通知などは、リアルタイムよりサマリの方が現場の負荷が下がります。
通知設計を軽視すると、せっかくの連携が「無視される通知ボット」に終わります。実装前に「何を、どの優先度で、どこに、どの粒度で送るか」を決めておくのが、現場に定着させる前提条件です。
WindyFloでSlack・Teams連携を構成する手順はどうなりますか?
WindyFloでのSlack・Teams連携は、「コネクタ設定 → 通知フロー設計 → 操作(承認・起票)の追加 → テスト → 本番稼働」の手順で構成します。プログラミングなしでビジュアルエディタ上で完結し、SlackのBot Token方式・TeamsのWorkflows/Bot方式のどちらにも対応します(参考用推定値)。
ステップ1: コネクタの追加と認証
WindyFloの「コネクタ管理」からSlackまたはMicrosoft Teamsを選択します。SlackはOAuthでアプリを認可してBot Tokenを取得し、Teamsは用途に応じてWorkflows(通知)またはBot(双方向)の接続を設定します。500以上のコネクタが用意されており、ERPや業務システムとも同じ画面で接続できます。
ステップ2: 通知フローの設計
「どのイベントを、どの条件で、どのチャンネルに送るか」をビジュアルエディタで設計します。例えば「ERPの在庫が安全在庫を下回ったら、購買チャンネルにSlack通知」というフローをドラッグ&ドロップで構築できます。前述のフィルタリング・優先度設計も、このフロー上で条件分岐として組み込みます。
ステップ3: 操作(承認・タスク起票)の追加
通知に承認ボタンやタスク起票ボタンを追加します。SlackはBlock Kit、TeamsはAdaptive Cardsの要素として配置し、押された結果をAIエージェントが受け取って後続処理を実行するように設定します。読み取り(通知)で効果を確認してから、この書き込み(操作)を段階的に足すのが安全です。
ステップ4: AIエージェントの設定
フローの中にAIエージェントを配置し、要約・分類・判定の役割を設定します。WindyFloは複数のLLMに対応しており、用途に合わせてモデルを選択できます。機密性が高い処理にはオンプレミス構成も選べます。
ステップ5: テストと本番稼働
テストモードで実際のチャンネルに通知・操作を流し、ボタンの動作と書き込み結果を確認します。問題がなければ本番稼働へ移行します。WindyFloでは小規模な構成から始め、対象業務を段階的に広げられるため、最初から作り込みすぎる必要がありません(参考用推定値)。
ノーコードでの自動化の全体像は、ノーコードAIパイプラインとは? WindyFlo使い方入門で基礎から解説しています。
Slack・Teams連携のセキュリティと権限設計で注意すべき点は何ですか?
Slack・Teams連携のセキュリティでは、「トークン・スコープの最小化」「リクエストの正当性検証」「権限モデルの理解」「監査ログの保存」の4点が必須です。チャット連携はERPデータ連携と違い、認証情報(トークン)とユーザー操作の検証が主な攻撃面になります。
製造業・流通業のERP連携ではデータの外部流出が最大の論点でしたが、チャット連携で守るべきものは少し異なります。ボタン操作のなりすましと、トークンの漏洩・過剰権限が中心的なリスクです。
1. トークンとスコープの最小化
SlackのBot Tokenには必要なOAuthスコープ(chat:writeなど)だけを付与し、不要な権限は与えません。スコープを広げすぎると、トークンが漏れた際の被害が拡大します。トークンは環境変数やシークレット管理で保管し、コードに直書きしないことが前提です。
2. リクエストの正当性検証
ユーザーがボタンを押したペイロードを、そのまま信用してはいけません。Slackは署名シークレットでリクエストの送信元を検証し、TeamsはBot Frameworkの認証トークンで正当性を確認します。この検証を省くと、偽のペイロードで承認や書き込みを実行されるリスクがあります。
3. Teamsの権限モデルの理解
前述のとおり、Microsoft Graphでの通常のメッセージ送信は委任権限のみで、アプリ単独(アプリケーション権限)では送れません(出典: Microsoft Graph Docs, 2026)。「Botとして自律投稿」したいのにGraphのアプリ権限で実装しようとすると行き詰まるため、Bot Frameworkを選ぶ判断を最初に下す必要があります。
4. 監査ログの保存
誰が・いつ・どのボタンで・何を承認/起票したかを、すべて監査ログに記録します。チャット上の操作が業務システムへの書き込みに直結する以上、追跡可能性は必須です。
WindyFloのセキュリティ対応(チャット連携)
| セキュリティ項目 | 対応内容 |
|---|---|
| トークン管理 | OAuthトークン・Bot Tokenをシークレットとして暗号化保管 |
| 操作の検証 | 署名検証・Bot認証で操作の正当性を担保 |
| 権限設計 | 必要最小スコープの付与、役割別アクセス制御(RBAC) |
| 監査ログ | 通知・操作・書き込みの全ログを保存し追跡可能 |
| デプロイオプション | オンプレミス・プライベートクラウド・パブリッククラウド |
権限設計やデプロイ方式の比較は、WindyFlo vs Dify — 日本企業に最適なAIエージェント基盤でも詳しく扱っています。社内セキュリティポリシーに応じた構成を選べます。
よくある質問 (FAQ)
Q1. SlackとTeams、どちらがAIエージェント連携に向いていますか?
社内の主要コミュニケーションツールに合わせるのが基本ですが、双方向の自動化を重視するならSlackの方が構成はシンプルです。
Slackは通知(Incoming Webhook)から双方向操作(Bot Token + Block Kit)への拡張が同じアプリ設定の延長で繋がります。Teamsは通知(Workflows)と双方向(Bot Framework)で使うAPIが分かれるため、設計の初期判断がより重要になります。Microsoft 365を全社利用している企業はTeams、開発主導で柔軟性を求める企業はSlackを選ぶ傾向があります。どちらもWindyFloで対応可能です。
Q2. Teamsの古いIncoming Webhookは、いつまで使えますか?
Office 365コネクタ(旧Incoming Webhook)は廃止が進行中で、新規の本番連携には使うべきではありません。
Microsoftは2026年4月30日を一区切りとしてOffice 365コネクタを段階的に廃止しており、Workflows(Power Automate)への移行を推奨しています(出典: Microsoft 365 Developer Blog, 2026)。既存のコネクタ利用も移行が必要なため、これから構築する場合は最初からWorkflowsまたはBot Frameworkで設計してください。古い手順書を参照すると廃止対象の方式を実装してしまうので注意が必要です。
Q3. プログラミングなしでSlack・Teams連携を構築できますか?
WindyFloを使う場合、プログラミングは不要です。ビジュアルエディタ上で通知フローと操作(承認・起票)を設計できます。
Slackのアプリ認可(OAuth)やTeamsの接続設定は画面の指示に従って進められ、フロー設計もドラッグ&ドロップで完結します。ただしOAuthスコープや権限の意味を理解しておくと、セキュリティ設計がスムーズになります。初回設定はHAMADA LABS Japanのサポートチームが支援します(参考用推定値)。
Q4. 通知が多すぎて見落とすのを防ぐ方法はありますか?
送信前のフィルタリング、優先度によるチャンネル分離、スレッドへの集約、サマリ化の4つを設計に組み込みます。
全イベントをそのまま流すと通知が埋もれます。AIで送信条件を判定して必要なものだけ送り、緊急度の高い通知だけメンションを付け、同一案件はスレッドにまとめます。件数の多い業務はAIに1日分を集約させ、日次サマリとして1通にする方法が有効です。技術的に繋ぐだけでなく、この通知設計が現場定着の鍵になります。
Q5. AIがチャットから業務システムを誤って操作する心配はありませんか?
読み取り専用(通知)から始め、効果を確認してから書き込み(承認・起票)を段階的に追加する設計が可能です。
初期段階はAIが通知・提案を行うだけに留め、人がボタンで承認したものだけをシステムへ反映します。すべての操作はサーバー側で正当性を検証し、監査ログに記録されるため、問題発生時の追跡ができます。Slackは署名シークレット、TeamsはBot Frameworkの認証で操作の正当性を担保します。
Q6. 既存のERPや業務システムとも同時に連携できますか?
はい、可能です。WindyFloはSlack・Teamsと、ERPや業務システムを1つのAIエージェントで統合管理できます。
例えば「ERPの在庫イベントを検知 → Slackに通知 → 承認ボタンで発注を確定 → 結果をスレッドに返信」という、複数システムをまたぐフローを構成できます。チャットを入出力の窓口にして、後続の処理を業務システム側で実行する形です。ERP連携の詳細はSAP・OracleとAIエージェントを連携する技術ガイドを参照してください。
Q7. 承認やタスク起票のボタンは、SlackとTeamsでどう違いますか?
SlackはBlock Kitのインタラクティブ要素、TeamsはAdaptive Cardsでボタンを実装します。仕組みは似ていますが、操作受付の前提が異なります。
SlackはBlock KitのActionsブロックにボタンを置き、action_idで操作を識別して処理へ振り分けます。TeamsはAdaptive Cardにボタンを置きますが、Graph経由で投稿したカードがサポートするアクションは限定的で、本格的なインタラクティブ操作にはBot Frameworkが必要です(出典: Microsoft Graph Docs, 2026)。承認結果を受け取って処理する双方向フローは、両者ともサーバー側での検証を前提に設計します。
Q8. 導入から稼働まで、どのくらいの期間がかかりますか?
通知のみの構成であれば最短1週間程度、承認・タスク起票を含む双方向構成では2〜4週間が目安です(参考用推定値)。
WindyFloの場合、コネクタ設定・フロー設計・テストがすべてノーコードで完結するため、従来のカスタム開発と比べて短期間で稼働できます。まず通知フローから始めて効果を確認し、その後で承認・起票を追加する段階的な進め方をお勧めします。HAMADA LABS Japanの初期設定サポートを利用すれば、さらに短期間での稼働が可能です。
連携を確認する: Slack・TeamsとAIエージェントの連携を、実際の動作でご覧ください。お客様の利用環境(Slack / Microsoft Teams)に合わせたカスタムデモを無料でご提供しています。
デモ申し込みはこちら → https://www.hamadalabs.jp/demo
技術選定の基準を明確にすれば、Slack・Teams連携の判断は自然と決まります。通知だけで終えるのか、承認・タスク起票まで動かすのか——この一点と、Teamsなら廃止予定の方式を避けること。この2つを確認すれば、自社に合う構成は即座に決まります。
このコンテンツはAIツールを活用して作成され、中川 拓也の専門家による検証を経ています。(韓国AI基本法第33条に基づくAI生成物表記)
