みなさんこんにちは。日本マイクロソフトの佐々木です。
本日はMicrosoft Teams 内の Office 365 コネクタの廃止とその対応についてのご案内です。
下記のブログ記事を翻訳し、個人的な見解を含めまとめた内容となります。
Teamsは私自身の担当製品ではございませんが、Power Platformの管理者の方に影響があると思われますので、この場でまとめておきます。
概要と背景
概要
-
2024 年 8 月 15 日【8/14Update:変更後】2024年12月31日以降 、Teams の Office 365 コネクタ機能(Incoming WebhookやRSSなど)を廃止し、すべての新しいコネクタの作成はすべてのクラウド内でブロックされます。 -
ユーザーは、スケーラブルで柔軟性があり、安全な方法で情報を連携するために、Power Automate、Teams の Power Automate ワークフローアプリなど別のソリューションに移行する必要があります。
背景
Power Automate コネクタのセキュリティは、Office 365 コネクタのセキュリティよりもはるかに強力であり、情報のセキュリティを最大限に提供できるアーキテクチャに基づいて統合が構築されるようにします。これらの変更は、Microsoft Secure Future Initiative と、サイバー脅威からお客様を保護するという全社的な優先事項に沿ったものです。
ユーザーへの影響
-
2024 年 8 月 15 日【8/14Update:変更後】2024年12月31日以降 、すべての新しいコネクタの作成がすべてのクラウドでブロックされます。 - すべてのクラウド内の既存のすべてのコネクタは 2025 年 12 月まで引き続き機能しますが、2024 年 12 月 31 日以降にコネクタを使用するには、追加のアクションが必要となります。
- ユーザーは、Teams で Power Automate ワークフロー アプリに移行することをお勧めします。Workflows アプリと一般的なテンプレートの使用方法に関する一般的な手順については、こちらのブログ記事 を参照してください。
タイムライン
現状予定しているタイムラインをまとめると下記のようになります。
Microsoft Teams Office コネクタとは
廃止予定となっているMicrosoft Teams の Office コネクタは、コンテンツとサービスの更新をサード パーティのサービスから直接 Teams チャネルに配信します。Office コネクタを使用すると、ユーザーは Azure DevOps Services、Trello、Wunderlist、GitHub などの一般的なサービスから更新プログラムを受け取ることができます。Office コネクタは、これらの更新プログラムをチャット ストリームに直接投稿します。この機能により、すべてのチームメンバーが簡単に同期を取り、関連情報を把握できます。
特にIncomming Webhookを利用しているケースが多いと思われます。
Microsoft Teams のワークフロー アプリとは
推奨の移行先として案内されているのが、Microsoft Teams のワークフロー アプリです。Workflows アプリを使用すると、Microsoft Teams のアクティビティを自動化したり、Microsoft Teams を他のアプリやサービスに接続したりできます。実態はPower Automateフローです。
NOTE:
Microsoft Teams の Workflows アプリは、組織の既定の環境からのフローのみを表示します。 Workflows アプリから作成するフローはすべて、既定の環境にあります。
推奨される移行ソリューションについて
ブログで案内されているとおり、推奨の移行先はMicrosoft Teams のワークフロー アプリとなっています。
一方で、作成されたフローが既定環境に作成されるなど、管理者目線では嬉しくない仕様がございます。特にPower Platformを推進されている企業にとっては、環境戦略など整備されていると思うので、場合によってはPower Automateそのもので代替することも案として出てくると思います。(また、Teams のワークフロー アプリそのものをポリシーで制御しているケースもあると思います。)
Microsoft Teams のワークフロー アプリへの作成方法・移行アプローチ(ユーザー向け)
推奨されているMicrosoft Teams のワークフロー アプリへの作成方法・移行手順についてご案内します。ブログをみるに移行方法(作成方法)は大きく分けて2つあるようですが、そこまで変わりはありません。
下記が参考になるかと思います。
Microsoft Teams でフローを作成する - Power Automate | Microsoft Learn
Microsoft Teams でワークフローを参照して追加する - Microsoft サポート
Office 365 コネクタのWebhookの移行について(ユーザー向け)
さて、前置きが少し長くなりましたが、一番インパクトがあると思われるが、Incoming Webhookの廃止・移行です。アプローチそのものはいままで述べさせていただいたもので問題ないかと思います。
Office 365 コネクタのWebhook(Incoming Webhook)の移行先として、Teams Webhook 要求を受信したとき コネクタを利用した、Workflows アプリの【Webhook 要求を受信するとチャネルに投稿する】テンプレートが用意されております。このテンプレートはPower Automateからも利用することができます。
どちらにおいても作成方法は共通しております。
Teams Webhook 要求を受信したとき コネクタでは、フローをトリガーできるユーザーなどを指定できます。従来のIncoming Webhookと同様の利用方法では[だれでも]を選択してください。
webhook 要求がMicrosoft Teamsで受信されたときにワークフローを投稿する - Microsoft サポート
Teams Webhook 要求を受信したとき コネクタそのものの説明は下記のdocsを参考してください。
Microsoft Teams - Connectors | Microsoft Learn
テストしてみる
簡単にPostmanを利用してテストしてみます。
Teams Webhook 要求を受信したとき コネクタを利用すると、要求先のURLが発行されますので、こちらを利用します。
こちらのテンプレートはアダプティブカード形式でメッセージを送信するため、Bodyを下記のような形式とします。
{
"type":"message",
"attachments":[
{
"contentType":"application/vnd.microsoft.card.adaptive",
"contentUrl":null,
"content": {
"$schema":"http://adaptivecards.io/schemas/adaptive-card.json",
"type":"AdaptiveCard",
"version":"1.4",
"body":[
{
"type": "TextBlock",
"text": "テスト送信"
}
]
}
}
]
}
結果としては、下記のようにフローのなかで指定したチームに送信されることが分かります。
Power Platform管理者の対応
これまで、ユーザーの対応について簡単に書かせていただきましたが、
Teams Webhook 要求を受信したときコネクタを利用するために、Teams Webhook 要求を受信したとき(When a Teams webhook request is received)のコネクタを許可する必要があります。
そのため、Power Platform管理者の方は、管理センター上のDLPポリシーを安全に構成する必要があります。
例えば、移行先のソリューションとしてPower Automateを利用し、特定の環境でのみ本コネクタを有効にするなどのアプローチがあると思いますが、その際は、ビジネス・非ビジネスなどのグループを検討することが重要となります。
O365 コネクタとワークフローを利用した Webhook 間の既知のギャップ
O365 コネクタのIncomming Webhookとワークフローを利用したIncomming Webhookのギャップについてです。
-
ワークフローボットは後続処理、通知先等カスタマイズ可能
-
認証されたユーザーのみがこのワークフローをトリガーできるように設定可能
-
ワークフロー ボットはプライベート チャネルに投稿できません(対応中)
-
ワークフローは、O365コネクターのペイロード/フォーマットを使用してメッセージをポストできません(messageCardとadaptive cardの違い)
-
ワークフローは個人で管理する必要(個人が所有者)がありますが、O365 コネクタはチャネル メンバーが管理できます
-
ワークフローに一部のコネクタ (Jenkins、DataDog など) がありません
-
Workflows Webhook からのメッセージにカスタムのアイコン/名前を付けることはできません
-
ワークフローの待機時間は O365 コネクタとは異なります (e.g. RSS フィードは 5 分ごとにチェックされます)
-
要求制限 (例えば、Microsoft 365 E3 に付帯する Power Automate ライセンスだと、1 日あたり 6,000 回)
よくある質問
簡単ですが、よくある質問(ありそうな質問)についてまとめております。
・このO365コネクタの廃止には "受信 Webhook" コネクタも含まれますか?
はい、これには "受信 Webhook" コネクタの廃止が含まれます。現在、「Incoming Webhook」のコネクタは、認証されていない匿名のサービスであるため、セキュリティ上のリスクがあります。お客様には、認証されたより安全なソリューションを提供するWorkflows Webhookテンプレートを使用するように指示しています。
・ワークフローに費用はかかりますか?
いいえ - すべての M365 ユーザーは、標準の Power Automate コネクタを無料で使用できるシード済みの Power Platform ライセンスを取得します。Teams への受信 Webhook ワークフローは標準/無料です。
・これは、 Teams 内で設定する送信 Webhook に影響しますか?
いいえ、この廃止は送信 Webhook には影響しません。送信 Webhook は、Office 365 コネクタとは関係のない独立したサービスです。
・どの Office コネクタが影響を受けますか?
Office コネクタ サービス全体が廃止されるため、すべてのコネクタ 1P、2P、および が影響を受け、動作を停止します。
・アダプティブ カード通知は廃止されますか?
いいえ、アダプティブ カード通知は Teams 内で廃止されません。
・現在利用しているコネクタの確認方法は?
Teams 管理センターのレポートにて、確認することが可能です。
まとめ
- TeamsのOffice365コネクタが新規作成&利用できなくなります
- この変更に伴い、Incoming Webhookも利用できなくなります
- 移行先はPower AutomateかTeams Workflowで代替します(いずれにせよフローを作成)
- Incoming Webhookの場合コネクタは[Teams Webhook 要求を受信したとき(When a Teams webhook request is received)]
- フローの特性上、トリガー以降のアクションを自由に構成できる
- Power Platformの管理者は環境のDLPポリシーを許可・再考する必要がある
個人的な見解(Teams Webhookについて)
Teams Workflowで代替するのは、ユーザーエクスペリエンス的には直感的な反面、Power Platformの管理者目線では必ずしも正解ではないかもしれません。(既定環境の環境戦略上)
そのため、Power Automateで作成する方針とし、[Teams Webhook 要求を受信したとき(When a Teams webhook request is received)]を許可するDLPポリシーを作成し、指定した環境のみで当該フローを作成(Incoming Webhookを利用したフローを作成)できるようし、DLPポリシーの構成を再考する(トリガーとアクションの組み合わせを限定しリスクを最小限にする)がある意味でヘルシーなのかもしれませんが、ここはバランスが求められそうです。
おわりに
こちらの記事ではMicrosoft Teams 内の Office 365 コネクタの廃止(Incoming Webhookの移行)について、お知らせいたしました。
公式で案内している内容とそうでない内容がありますので、組織で検討のうえ最適なアプローチを選択いただけますと幸いです。