DifyとTeamsを連携する方法｜Power Automate・APIで社内AIを構築

SkillStack Lab（スキスタ）運営者のスタックです。

Difyで作った社内AIやRAGを、社員が普段使っているMicrosoft Teamsから直接利用できるようにしたい、と考えていませんか。

Teamsを日常的に使っている会社なら、わざわざ別のAI画面を開かなくても、いつものチャットから質問できる仕組みは非常に魅力的です。

ただし、2026年現在のDifyとTeamsの連携は、「Webhookを1本つなげれば完成」というほど単純ではありません。

Power Automateを使う方法、TeamsのOutgoing Webhookを使う方法、本格的なTeams Agentを作る方法などがあり、必要な応答速度や会話形式によって適した構成が変わります。

さらにMicrosoft 365の旧Connector方式はすでに廃止段階を終えているため、古い技術記事のIncoming Webhookをそのまま参考にするのも避けた方が安全です。

この記事では元情シスの視点から、2026年8月時点のMicrosoft・Dify公式情報をもとに、DifyとTeamsを連携する現在の方法、Power Automateで作る基本構成、APIキーの管理、タイムアウト、属人化を防ぐ運用設計まで整理して解説します。

※本記事には広告・アフィリエイトリンクが含まれています。Microsoft 365、Power Automate、Difyの仕様やライセンスは変更される場合があります。

DifyとTeamsを連携する方法は4つ

最初に結論から整理します。

DifyをTeamsから利用する方法は1つではありません。

DifyをTeamsから使うメリット

社員が使い慣れた画面からAIを使える

Difyには作成したAIアプリをWebアプリとして公開する機能があります。

しかし、会社ですでにTeamsをコミュニケーション基盤として利用している場合、別のWebアプリを毎回開くより、Teamsから利用できる方が操作の切り替えを減らせます。

例えば、総務・人事のFAQなら、社員が専用チャネルへ「結婚した場合の慶弔見舞金はいくらですか？」と投稿し、裏側のDifyが社内ナレッジを検索して回答する仕組みを作れます。

Difyで社内文書をRAG化する方法については、Difyナレッジの使い方とRAG構築手順で詳しく解説しています。

AIへの問い合わせ窓口をTeamsに集約できる

管理部門では「申請方法はどこに書いてありますか」「この場合はどの書類が必要ですか」といった定型的な問い合わせが発生します。

文書に明確な答えがある質問をDifyで一次回答できれば、担当者は例外処理や判断が必要な問い合わせへ時間を使いやすくなります。

AIに判断を丸投げするのではなく、「探して答える一次対応」をAIへ移すという使い方から始めると、管理部門でも導入しやすいです。

Power AutomateでDifyとTeamsを連携する仕組み

まず、比較的取り組みやすいPower Automate方式を見てみましょう。

基本的なデータの流れは次の4段階です。

1. Teamsで質問を投稿する
2. Power Automateがメッセージを取得する
3. HTTPでDifyのApp APIへ質問を送る
4. Difyの回答をTeamsへ返信する

Step1：Teamsメッセージをトリガーにする

Power AutomateのMicrosoft Teamsコネクタには、「When a new channel message is added（新しいチャネルメッセージが追加されたとき）」などのトリガーがあります。

ただし、ここには重要な制限があります。

そのため、専用FAQチャネルで「新規投稿＝AIへの質問」というシンプルな運用には使えますが、人間とのチャットのような即時応答を期待するとギャップが生まれる可能性があります。

また、AIからの返信を再びフローが拾って無限ループしないよう、対象チャネル、投稿者、メッセージ種別などで処理対象を絞る設計も必要です。

Step2：DifyのApp APIを呼び出す

Difyでは、公開したアプリをREST APIとして呼び出せます。

現在のDifyでは、アプリの種類によって利用するAPIエンドポイントが異なります。

APIキーは各DifyアプリのAPI画面から取得できます。詳しい仕様はDify公式「Get Started with the Dify API」で確認してください。

Chatbot系アプリなら、Dify Cloudの場合は概ね次のような形でリクエストします。

セルフホスト版の場合は、自社Dify環境のAPIベースURLへ変更します。

Step3：Difyの回答をTeamsへ返信する

Difyから回答を受け取ったら、Microsoft Teamsコネクタの「Reply with a message in a channel」や「Post message in a chat or channel」などを使ってTeamsへ返します。

現在のTeams Connectorでは、Flow botまたは接続しているユーザーとしてメッセージを投稿できます。

専用FAQチャネルであれば、元の質問投稿へ返信する形にした方が、質問と回答の対応関係を追いやすくなります。

APIとWebhookは別物として理解する

DifyとTeamsの連携記事で混同されやすいのが、APIとWebhookです。

APIは「こちらから呼び出す窓口」

今回のPower Automate構成では、Power Automate側からDifyへ「この質問に回答してください」とHTTPリクエストを送ります。

これがDify APIです。

Webhookは「イベントが起きたら知らせる仕組み」

Webhookは、あるシステムでイベントが発生した際に、事前に登録されたURLへHTTPリクエストを送る仕組みです。

ただし、Power AutomateのTeams Connectorでチャネル投稿を取得する場合、必ず自分でWebhook URLを作るわけではありません。

Teams Connectorが用意しているトリガーを利用するため、「Teamsの投稿＝Webhook」という説明に単純化しない方が正確です。

旧Incoming Webhookは現在どうなった？

過去のTeams連携記事では、「Incoming Webhookを作成してURLへJSONをPOSTする」という方法をよく見かけます。

しかし、MicrosoftはOffice 365 Connectorsの廃止を進め、2026年5月18日から22日にかけて最終ロールアウトを実施しました。

そのため、旧Connector方式を前提とした新規システムをこれから構築するのは避けた方がよいです。

最新状況はMicrosoft 365 Developer Blog「Retirement of Office 365 connectors within Microsoft Teams」で確認できます。

WorkflowsのIncoming Webhookとは別物

ここで注意したいのが、現在Microsoftが案内しているWorkflowsアプリのWebhookです。

Workflowsでは「When a Teams webhook request is received」を使い、外部サービスからHTTP POSTを受け取ってTeamsへメッセージやAdaptive Cardを投稿できます。

これは、Difyで処理が完了したらTeamsへ通知するような一方向通知には適しています。

一方、「Teamsユーザーが質問→Difyが回答」という会話型の入口とは役割が異なります。

Power Automate方式の3つの制限

1．チャットボットとしては応答が遅れることがある

前述したとおり、「When a new channel message is added」は約3分のポーリング方式です。

そのため、ChatGPTのように投稿直後からリアルタイムで回答が始まる体験にはなりません。

「数分以内にFAQ回答が返れば問題ない」という社内用途なら十分なケースもありますが、リアルタイム対話が必須なら別方式を検討してください。

2．長いDify処理はタイムアウトに注意

Dify APIには、完了後にまとめてJSONを返す「blocking」と、生成途中からSSEで返す「streaming」があります。

Dify公式は、長時間処理ではstreamingを推奨しており、Dify Cloudのblocking処理ではCloudflare側の100秒タイムアウトについても案内しています。

詳しくはDify公式「Consume Streaming Responses」を確認してください。

Power AutomateからDifyを単純なHTTPリクエストで呼び出して1つの回答を受け取る構成なら、まず短時間で完了するWorkflowから始める方が扱いやすいです。

何十秒～数分かかるAgent処理、Human Inputを挟むWorkflow、ストリーミング表示が必要なチャットでは、中継APIやTeams Agentなど別のアーキテクチャを検討してください。

3．HTTPアクションはライセンス確認が必要

Difyのような外部REST APIをPower Automateから呼び出す場合、HTTPやカスタムコネクタなどPremium機能を利用する構成になることがあります。

Power Automate PremiumではPremium Connectorを利用できますが、利用者単位・Process単位など複数のライセンス体系があるため、「Microsoft 365を契約済みだから追加費用なし」とは限りません。

本番構築前に、現在のMicrosoft公式Power Automateライセンス情報を確認してください。

本格的なTeamsチャットボットならAgentも検討

Power Automateは便利ですが、すべてのTeamsチャットボットをPower Automateで作る必要はありません。

次のような要件がある場合は、本格的なTeams Agentを検討する価値があります。

• ユーザーと1対1で自然に会話したい
• チャネルだけでなくチャットでも利用したい
• 即時応答が重要
• Adaptive CardsなどTeams固有UIを使いたい
• ユーザー認証や権限を細かく制御したい
• 大人数へ正式な社内アプリとして展開したい

Microsoftは現在、Teams向けのAgent開発にTeams SDKやMicrosoft 365 Agents SDKを提供しています。

この場合、Teams Agentがユーザーとの会話を受け持ち、そのバックエンドからDify App APIを呼び出す構成にできます。

Dify APIキーを安全に管理する

Teams連携で特に注意したいのがDifyのAPIキーです。

App APIキーは「Dify全体の万能鍵」ではない

Dify公式の現在の仕様では、アプリ用APIキーはそのアプリ単位で作成されます。

そのため、通常のTeamsチャットボットでDifyアプリを呼び出すなら、そのアプリのAPIキーを使用します。

一方、Knowledge API用のキーは、そのキーを作ったアカウントから見える複数のナレッジベースへアクセスできるため、より慎重な管理が必要です。

TeamsからDifyアプリを呼ぶだけなのに、必要以上に強いKnowledge APIキーを使わないことも最小権限の考え方の一つです。

APIキーをPower Automateへ直接ベタ書きしない

Power Automateでは、フローの実行履歴から各アクションの入力・出力を確認できます。

そのため、APIキーをHTTPアクションへ平文で直接書いたままにすると、フローを閲覧できる人から見える可能性があります。

Microsoftは、パスワードやAPIキーなどをフローへ直接埋め込まず、Azure Key Vaultや環境変数を利用し、Secure Inputs / Secure Outputsで実行履歴への表示を抑える方法を案内しています。

詳しくはMicrosoft公式「Secure data used in cloud flows」を確認してください。

TeamsだからMicrosoft内だけで完結するわけではない

ここも重要なポイントです。

Power AutomateとTeamsを使っているからといって、処理されるデータがすべてMicrosoft 365の中だけに留まるとは限りません。

Power AutomateからDify CloudのAPIを呼び出せば、質問データはDifyへ送られます。

さらにDifyからOpenAI、Anthropic、Googleなど外部モデルを利用している場合は、設定したモデルプロバイダーへ必要なデータが送信されます。

Difyを企業で本番利用するときのライセンスやセルフホスト、セキュリティについては、Difyの商用利用と安全な環境構築で詳しく解説しています。

社内ナレッジのアクセス権にも注意

DifyのRAGに社内規定だけを登録する場合と、人事評価・給与・役員会議資料まで登録する場合では、必要なセキュリティ設計がまったく違います。

Teamsへログインできる社員だからといって、Difyへ登録されたすべての情報を閲覧してよいとは限りません。

また、SharePoint側で設定したファイル単位の閲覧権限が、Difyへ取り込んだ後も同じように自動適用されると決めつけないでください。

人事用、全社員用、管理職用など、利用対象によってDifyアプリやKnowledgeを分離する方法も含めて設計する必要があります。

SharePointをDifyのRAGへ接続する場合は、Dify×SharePoint連携と権限設計もあわせて確認してください。

属人化を防ぐPower Automate運用

元情シスとして、技術そのものと同じくらい重要だと考えているのが運用体制です。

一人の担当者が自分のアカウントでPower Automateフローを作り、その人しか構造を知らない状態で本番運用すると、異動や退職時に大きなリスクになります。

Workflowsは所有者依存にも注意

Microsoft自身も、TeamsのWorkflowsは特定ユーザーに紐づいており、所有者がいなくなると「orphan flow（孤立したフロー）」になる可能性があると案内しています。

業務で使うフローなら、複数の共同所有者を設定し、接続情報と運用責任をチームで管理してください。

Solution・Connection Referenceを使う

本番運用を前提とするなら、Power Automateのフローを単体で作って終わりにせず、Solution内で管理する方法も検討してください。

Solution-aware flowではConnection Referenceや環境変数を利用でき、開発・検証・本番環境の違いをフロー本体から分離しやすくなります。

また、フローのバージョン管理も利用できるため、「誰かが設定を変更して動かなくなった」という場面で以前の状態を追いやすくなります。

Dify×Teams連携でよくあるエラーの切り分け

私自身、システム運用では「エラーを出さないこと」より、「エラーが出たときにどの層で止まったかを切り分けられること」の方が重要だと考えています。

Teams、Power Automate、Dify、LLMを一度に疑うのではなく、入力→API→Dify→出力の順に確認するだけでも、トラブル対応はかなり整理しやすくなります。

APIやPower Automateをどこまで学ぶべき？

DifyとTeamsをPower Automateでつなぐだけなら、最初から本格的なプログラマーになる必要はありません。

ただし、次の言葉は最低限理解しておくと、エラー時の切り分けがかなり楽になります。

• HTTPのリクエストとレスポンス
• GET・POST
• HTTPステータスコード
• HeaderとBearer認証
• JSON
• Power Automateの変数・条件分岐
• Secure Inputs / Secure Outputs
• DifyのApp APIとKnowledge APIの違い

ここまで理解できれば、エラーが出ても「認証なのか」「JSONなのか」「Dify処理なのか」「Teamsへの返信なのか」という仮説を立てられるようになります。

動画で横断的に学ぶ方法もある

API、Power Automate、JSON、生成AIなどをまとめて学びたい場合は、動画教材を利用する方法もあります。

Udemyの個人向け定額プランを利用できる場合、対象コレクション内の複数講座を契約期間中に横断して学べます。

ただし、UdemyにあるすべてのDify・Power Automate・API講座が定額対象というわけではありません。受講したい内容が含まれているかを申込前に確認してください。

Udemyの定額対象講座の確認方法は、Udemyサブスク対象講座の見分け方で解説しています。

DifyとTeamsを安全に連携するチェックリスト

• PoCならPower Automate、本格チャットならTeams Agentも比較した
• 旧Office 365 Connector前提の手順を使っていない
• Teamsトリガーのポーリングと返信非対応を理解した
• Difyアプリの種類に合うAPIを選んだ
• APIキーをフローへ平文で埋め込んでいない
• Secure Inputs / Outputsを確認した
• AIの返信を再度トリガーにしない条件を設定した
• Dify処理が長時間化した場合の対策を考えた
• 外部LLMまで含めたデータフローを確認した
• 人事・機密情報の参照範囲を分離した
• Power Automateの共同所有者を設定した
• 構成図・障害対応手順・秘密情報更新手順を残した

安全なDifyとTeams連携に向けて

DifyとTeamsを連携すれば、社員が普段使っている画面から社内AIやRAGへアクセスできる仕組みを作れます。

一方、2026年現在は「Incoming Webhookを作れば完成」という過去の単純な構成から、Teams WorkflowsやAgents SDKなど複数の選択肢へ変わっています。

まず小さく試すならPower Automateで十分な場合があります。

ただし、Teams Connectorのトリガーには遅延や会話上の制限があるため、全社向けの本格的なチャットボットへ成長させる段階ではTeams Agentへの移行も検討してください。

「動く連携」を作ることより、「誰が使っても安全で、担当者が変わっても直せる連携」を作ることの方が本番では重要です。

DifyのAPIキー、Power Automateの接続、Teamsの権限、ナレッジの参照範囲まで含めて設計し、まずは機密性の低い専用チャネルから段階的に検証してみてください。