プライベートチャネルに Power Automate 方式の Teams Incoming Webhook でメッセージを投稿する方法
Teams Incoming Webhook 含め Teams の Office 365 コネクタ全てが廃止になる
Microsoft 社より Teams の Office 365 コネクタ廃止が案内され、Incoming Webhook が含まれていることから、多くのユーザーが対応を迫られているかと思います。
まあ、なんで Incoming Webhook がこんなに騒がれているかというと、廃止の期日が 2024/9/30 まで、と、あと 2 ヶ月も無いということが挙げられるんだと思います。(EOSL の期限をだいぶ先にしてくれる Microsoft にしては珍しい対応)
Teams 内の Office 365 コネクタの新規利用が 2024/08/15 に停止し、機能自体の廃止が 2024/10/1 とあるので、時間がないという感じですね。（まあ、これはアメリカ時間とかあると思うので、日本時間的には1日遅れる可能性もあると思いますが）
(2024/07/24 追記)
Microsoft より、コネクタ廃止日の期限が延長されました。(新規作成停止はそのまま)
常に情報が更新される可能性があるため、最新の情報は、上記のブログを参照ください。
| 日時 | 影響 |
|---|---|
| 2024/08/15 | コネクタの新規作成は廃止 |
| 2024/12/31 | Incoming Webhook の既存の URL は利用不可になる (URL を更新すれば 2025/12 まで利用可能、更新方法については 90 日前までに通知予定) |
| 2025/12 | すべての Office 365 コネクタを廃止 |
一応、ユニファイドサポート経由で Microsoft 社のサポートに問い合わせたところ、
弊社公開情報および過去事例をお調べいたしましたが、ご参照いただいたブログや、メッセージセンターにてアナウンスされている "MC808160" に記載されている以上の情報の確認には至りませんでした。
しかしながら、Microsoft Teams 上で利用する全てのコネクタが対象となる認識でございますため、以下の手順にてお客様の環境で利用可能なコネクタをご確認いただける認識でございます。
という回答が返ってきているので、Incoming Webhook も対応しないといけないわけです。
Power Automate 版 Teams Incoming Webhook への移行方法
まあ、この辺りは上記の公式ブログにちゃんと載っているので、英語が辛い方はブラウザ翻訳とか使って見ればいいと思います。基本は
- Power Automate クラウドフローのテンプレートである
Webhook 要求を受信するとチャネルに投稿するを選んで設定する - 新しく追加された
Microsoft Teams WenhookコネクタのTeams Webhook 要求を受信したときトリガーを選択してフローを構築する
のどちらかを行なって、新しい Webhook URL を取得して切り替えれば良いです。この辺りはすでに、有象無象の公式ブログ内容をコピったものたちがたくさんあると思うので、検索して調べてみてください。私の記事ではこの部分の解説は割愛します。
自テナントでどれだけ Incoming Webhook が利用されているかを確認する方法
Teams 管理センターのレポートにて、確認することが可能です。(要 Teams 管理者ロール)
Teams 管理センター にログインし、[分析 & レポート] -> [使用状況レポート] にて、アプリの使用状況 レポートを出力することで、利用状況を把握することができます。
なお、使用状況レポートは選択した期間でアプリが利用されたもののみを集計対象とするため、その期間に利用されていない Incoming Webhook については、コネクタとして構成済みだったとしても集計数には含まれません。(まあ、過去 180 日とかでレポート出力して集計されていなければ、それは使用されていないと判断すべきとは思いますが...)
公式の手順だと、プライベートチャネルに投稿しようとするとエラーになる
標準チャネルだと、公式の手順でそのまま移行すれば問題はないのですが、問題はそれ以外のチャネルです。特にプライベートチャネルは、そのままだとうまくいきません。
これは先述の公式ブログの中のユーザーコメント内でも議論になっていました。
通常であれば、プライベートチャネルを右クリックしても ワークフロー のメニューは出てくるため、「あ、いけるやん」と思うかもですが、これには落とし穴があって、そのままテンプレでクラウドフローを作成してもちゃんと動きません。
まあ、実際にこの Webhook URL に POST してみた結果を Power Automate 上で見れば一目瞭然なんですが、このフローは失敗します。
試しに Postman で POST のリクエストを送ります。すると、Webhook を送信した側のレスポンスは HTTP 202 Accepted で返ってきますが、
POST を受け取った側の Power Automate クラウドフロー側は処理が失敗になります。
エラー内容を見ると、「お前、プライベートチャネルにいねえじゃん、権限ないから投稿させるわけないでしょ」って怒られているわけですね。
(余談ですが、Copilot for Power Automate はこのエラーの回答を正しく表示していますね、全 Power Automate 利用ユーザーは Copilot があれば大丈夫)
プライベートチャネルは Incoming Webhook だろうとチャネル権限を持つ垢が必要なだけ
そう、上記のエラーを見れば一目瞭然ですが、アダプティブカードを投稿している箇所がエラーで、その理由が投稿者権限なので、それを直せばいいだけですね。
要は、プライベートチャネルに参加権限のある所有者 or メンバーで認証した Teams コネクタで、ユーザーとして投稿すれば良いです。
投稿者をプライベートチャネルにアクセス権のあるユーザーに変更しておけば、Power Automate 方式の Teams Incoming Webhook も正常に動作します。(当たり前)
(余談1) 共有チャネルの場合は Power Automate の画面からクラウドフローを作成する必要あり
標準チャネルやプライベートチャネルは、ワークフローから Incoming Webhook 用の Power Automate クラウドフローを作れましたが、共有チャネルはそれが出来ません。(右クリックのメニューに出てこない)
そのため、共有チャネルで Incoming Webhook をしたい場合は、Power Automate の画面からテンプレートを使ってクラウドフローを作成する必要があります。
Teams のアダプティブカード投稿のチャネル一覧には、共有チャネルもちゃんと出てくるので大丈夫です。
Webhook 用の URL は、クラウドフローを 1 度保存すれば作成されるので、保存してから確認しましょう。(保存ボタン押すだけで URL が確認できるようになります)
共有チャネルもプライベートチャネル同様、フローボットだとフローが失敗するので注意です。
今のところ Request の Body は必須要件だけ満たせば残りは適当でもなんとかなる模様
上記などで紹介しているテンプレは、アダプティブカードでの投稿のため、Request Body の JSON は正しい構造で送る必要があります。
従来の Teams Incoming Webhook では、この辺りが適当でも (要は、title と message だけの JSON でも) Teams が勝手にアダプティブカードに補完して投稿をしてくれていました。
これは今後はできなくなる可能性があるので、今のうちに、Adaptive Cards Designer とかを使って JSON 構造を勉強しておくのが better です。
ちなみに公式の解説ページは以下です。
よう分からんって人は、下の JSON みたいに type と attachments の contentType と content 要素を作って、content 要素の中に好きな JSON 要素を入れるようにして、あとはPower Automate クラウドフローの中で、Webhook トリガーの後ろに JSON 解析などのコネクタアクションを追加し、Request Body の JSON を解析して上手い具合に Teams 投稿のコネクタアクションに繋げればいいと思います。
なぜ、上記の JSON 構造が必須になっているかというのは多分、このトリガーアクションの戻り値となる変数が「content 以下の JSON」っていう定義になっているからだと思います。(現に content って動的変数が以降、フロー内で参照できるようになるため)
{
"type": "message",
"attachments": [
{
"contentType": "application/vnd.microsoft.card.adaptive",
"content": {
"title": "test",
"message": "test message"
}
}
]
}
ちなみに、この Teams Webhook トリガーの JSON 構造の仕様は以下のようです。なので、この構造を満たしていれば、なんでも受け取れる模様です。
{
"type": "object",
"properties": {
"type": {
"type": "string"
},
"attachments": {
"type": "array",
"items": {
"type": "object",
"properties": {
"contentType": {
"contentType": {
"type": "string"
}
},
"content": {
"content": {
"type": "object",
"properties": {
"$schema": {
"type": "string"
},
"type": {
"type": "string"
},
"version": {
"type": "string"
},
"body": {
"type": "array",
"items": {
"type": "object",
"properties": {
"type": {
"type": "string"
}
},
"required": [
"type"
]
}
}
}
}
}
},
"required": [
"contentType",
"content"
]
}
}
}
}
今のところは、トリガーで受け取った Request Body (content 以下) の扱いについては、特に制約などは公式発表にもないようですし、トリガーとコネクタアクションが分かれている手前、正直、今後においてもどうとでもなる気がしなくもないです。(あくまで個人的感想、なんならこれが Power Automate の公式 Webhook POST トリガーとしてリリースしてくれ、既存のアレは使いにくい)
プライベートチャネルに Workflows アプリを入れてもエラーは変わらない
プライベートチャネル (と共有チャネル) に投稿できないのは権限問題と言いましたが、じゃあチャネルに Workflows (Power Automate) アプリを入れればいいやん、と思いますよね。
ただ、チャネルのタブとかにアプリを入れても、全くの無駄です、変化はありません。現状はユーザー権限でやるしかないです。
ただ、ここは従来の Teams Incoming Webhook なら、Webhook URL を発行するだけでプライベートチャネルも (共有チャネルも) メッセージ (アダプティブカード) を投稿できていたわけですから、ここはなんとかして欲しいものです。
特に、ユーザー人格で投稿してしまったら、人が直接入力して投稿した内容なのか、bot 的に投稿されたのか分かりにくくなる、という性質もあると思うので、正直ここは将来的な改善に期待です。
(余談2) Incoming Webhook によってアクショントリガー制限に引っかかる可能性 (リスク) は高くなるか否か
Power Automate クラウドフローって、ライセンス種別ごとに、24 時間あたりに実行できるフローのコネクタアクション数には制約が設けられています。(例えば、Microsoft 365 E3 に付帯する Power Automate ライセンスだと、1 日あたり 6,000 回)
まあ、回数足りなかったら有償のユーザーライセンス or フロー (プロセス) のライセンスを購入すれば良い、ってことかもしれませんが、従来の Teams Incoming Webhook だったら関係なかったじゃん、っていう部分があるので、これはこれでエンタープライズ企業などでは特に波乱を呼びそうな気がします。
あと、そもそも、この Teams Webhook トリガー自体にもいくつか制約があるので、何でもかんでも 1 個の Webhook URL に集約して後続のフローアクションで分岐する、みたいなことは基本やらない方がいいと思います。(ちゃんと Throttling Limits がある)
さいごに (本件に関する個人の所感)
Teams の Office 365 コネクタ廃止の意図は正直私にはわかりませんので、ここはいつか Microsoft に聞いてみたいです。
ですが、Teams 機能の中でも、市民開発者ではない通常の開発者の方が多用している (と思われる) Incoming Webhook 機能のみについては、これを他の Office 365 コネクタの移行と同様に Power Automate クラウドフローに寄せる方針は本当に正しいのか、正直な話、個人としては疑念を抱いてしまいます。
(確かに、URL さえ知っていればどこにでもメッセージを投稿できてしまう仕様については検討の余地はあるので、その点で Power Automate を間に挟むという点を理解できなくも無い部分はありますが...だったら Incoming Webhook にだけは認証トークンとか実装すればよいのでは、とも思ってしまう今日この頃)
Office 365 コネクタを廃止するのに際し、Incoming Webhook だけは独立した機能として新規実装したものに移行、とかにしてくれれば、おそらく多くの Teams 利用者は嬉しいはずです。Power Automate 利用を強制するというのは、普段、Microsoft に肩入れしがちな私でも疑問を抱かざるを得ませんし、今後、なんとかしてもらえると嬉しいな、といったところです。
ただ、SaaS である手前、Microsoft の現状の方針ですし、Power Automate 自体はそれはそれで普段から自動化などでお世話になっているから嫌いであるわけでもないので、切り替えは頑張ります。
企業で Teams を管理している方や Incoming Webhook を使っていた方、一緒に移行を頑張りましょう。
Discussion