ここでは、企業のIT部門で働いていた私自身の体験談を交えながら、TeamsのWebhook廃止に伴うPower Automateへの移行について解説していきます。以前、社内チャットツールを刷新した際、Webhookの廃止タイミングにあわてて対応したことがありました。当時はまさにMessageCardからAdaptive Cardへの移行を求められ、思わぬ落とし穴と向き合ったのを懐かしく思います。そのときに苦労した点や気づきをシェアすることで、同じような場面に直面している方の参考になればうれしいです。扱う情報は移行時のポイントや変換のアイデア、Atlassian製品との連携、さらにはPower Automateでありがちなフォーラム投稿トラブルへの対処法まで幅広く取り上げます。
Teams WebhookからPower Automateへの移行が必要な背景
Teamsでは今まで利用できていたWebhookが近い将来廃止されるため、既存で活用しているMessageCard形式の通知を継続するには、Power Automateなど別の仕組みを使って対応せざるを得なくなりました。私が勤めていた会社でもWebhook連携を使ってJiraなどからチケット更新情報をリアルタイムに送っていたため、早い段階で移行方針を決めなければなりませんでした。
よくある困りごと
実際に移行の話を進めてみると、MessageCardで送られてきたペイロードをPower Automateのフロー内で扱おうとしたときにエラーが多発するケースがありました。これはPower Automateが標準で期待しているのがAdaptive Card形式だったことに起因します。特に以下のようなエラーが代表例として報告されています。
Action 'Send_each_adaptive_card' failed: The execution of template action 'Send_each_adaptive_card' failed: the result of the evaluation of 'foreach' expression '@triggerOutputs()?['body']?['attachments']' is of type 'Null'. The result must be a valid array.このエラーはMessageCardのフォーマットにはattachmentsの配列がなく、Power Automateが扱おうとしても空（Null）と判断されるために発生します。
導入企業が増えているPower Automateの活用
近年は複数のSaaSや社内システムをつなぐ業務フロー自動化として、Power Automate（旧Microsoft Flow）を選ぶ企業が急激に増えています。私が関わったプロジェクトでも、独自サーバーで動かしていたジョブを順次Power AutomateやAzure Functionsへ移管し、運用コストを削減できました。そんな状況下で、Webhook通知の廃止が重なったりすると、フロー側でデータ形式の差異を埋める対応が必要になってくるのです。
MessageCard形式をPower Automateで受け取る基本手順
ペイロード変換がカギ
MessageCard形式をそのままPower Automateへ流し込んでも、先ほどのエラーのように処理が停止してしまいます。そこでよく採られるアプローチとしては、「Webhookを受信するトリガーの直後にペイロード変換のステップを挟む」ことです。たとえばCompose（作成）アクションを配置し、受信したMessageCardのJSONを必要な形に整形してあげます。
私が取り入れた変換例
会社で運用していたフローでは、MessageCardのbodyやtitleを取り出して、Adaptive Cardのattachmentsとして定義し直すようにしました。具体的なイメージとしては以下のようになります。
{
"attachments": [
{
"contentType": "application/vnd.microsoft.card.adaptive",
"content": {
"type": "AdaptiveCard",
"body": [
{
"type": "TextBlock",
"text": "@{triggerBody()?['title']}"
},
{
"type": "TextBlock",
"text": "@{triggerBody()?['text']}"
}
],
"actions": []
}
}
]
}このようにMessageCardの要素を取り出してAdaptive Cardに落とし込む形をComposeで作成し、後のステップで利用できるようにするわけです。
手作業でのマッピングに注意
実際にやってみると、フィールド名が細かく異なっていたり、入れ子構造が違っていたりして、根気よくマッピングを行う必要がありました。慣れるまではこまめにテスト実行をして正しくデータが取得できているかを確認しましょう。下手に一度で完璧なマッピングを目指すよりは、段階的に作成・検証しながらフローを仕上げるほうがミスが減ります。
Atlassian製品(Jiraなど)とTeams連携の最新状況
私が昔携わったチケット管理システムの導入先ではJiraを使っており、WebhookによるTeams通知も盛んに活用していました。ところがMicrosoftからのWebhook廃止の通達があり、既存のJira連携がうまく動かなくなる懸念が出てきたんです。そんな中、2024年8月24日にAtlassian社がWebhook廃止に対応する新しい連携機能をリリースしており、それを利用することでスムーズに移行できる、という情報が公式コミュニティで提供されました。
実際にやってみた感想
私も試しに試用環境のJiraとTeamsをつないでみました。すると、確かに以前のようにMessageCardを無理やりPower Automateで受け取らずに済み、Adaptive Card形式で受信できる新フローがあらかじめ用意されていたので、移行の手間が減りました。
注意点: Teams Premiumのライセンス
ただし機能をフル活用するにはTeams Premiumのサブスクリプションが必要になる場面があるため、導入コストや会社のポリシーに合わせて要検討です。すでにPremiumを含むプランを契約している場合は問題ありませんが、新たに契約するとなると予算確保が課題になるかもしれません。
Power Automateコミュニティフォーラムを活用しよう
複雑なJSONパースの手順やカスタムコネクタの作り方など、深掘りしたノウハウはPower Automateコミュニティフォーラムが非常に役立ちます。私も「こういう構造のJSONをパースしたいが、うまく条件分岐が動かない」と困ったときは、フォーラムで実際のコードやスクリーンショットを添えて質問し、丁寧にサポートしてもらえました。開発者同士が出し惜しみせず知識を交換しているため、行き詰まったらまずはのぞいてみるのがおすすめです。
投稿ボタンが灰色になるときの回避策
フォーラムで新規トピックを書こうとしているのに、なぜか投稿ボタンがグレーアウトして押せないという現象に遭遇することがあります。コミュニティサイトのUIが変わった直後などに発生しがちです。私自身も何度かありましたが、検索バーに質問文を入力してから投稿に進むルートを使うとうまくいきました。こうした些細なハマりどころもコミュニティ内で情報共有されているので、ぜひ活用しましょう。
投稿がうまくいかず困っていたとき、コミュニティ内で同じ体験をした方が丁寧にスクリーンショット付きで解説してくれており、とても助かりました。
| 項目 | MessageCard | Adaptive Card |
|---|---|---|
| 利用推奨度 | 過去の形式(非推奨) | Microsoft推奨の最新形式 |
| 特徴 | 簡易通知に特化 JSON構造がシンプル | インタラクティブ要素対応 柔軟なレイアウト構成が可能 |
| 対応状況 | Webhook廃止とともに利用不可へ | Power Automateや最新Teams連携で標準サポート |
| 学習コスト | 低め(しかし今後は推奨されない) | やや高め(多機能ゆえ) |
上記のようにMessageCardは廃止方向のため、どうしても既存の仕組みで使い続けたい場合は、Power Automateでのラップ処理や別のコネクタを介するなどの対策が必須です。
移行してみた感想
以前のプロジェクトでMessageCardからAdaptive Cardに移行したとき、はじめは「少し書式をいじれば済むだろう」と気軽に考えていました。でも蓋を開けてみると、タイトルや本文の取り扱い方が微妙に異なり、インタラクションや画像の埋め込みまでやろうとすると一筋縄ではいきませんでした。そのぶん慣れてくると、ActionボタンやリッチなUI表現が使えるAdaptive Cardのメリットを実感できて、最終的にはチーム全体で「こっちのほうが便利だね」という声が多く聞こえました。
Power Automateでの柔軟なJSONパース方法
典型的なフローの構成
Power AutomateにおけるJSONの取り扱いは、実はかなり自由度が高いです。Webhook受信のトリガーを入口とし、続く手順でParse JSONを挟みながら条件分岐やループを行い、最終的にTeamsや他のサービスへ通知を飛ばす流れが基本形と言えます。私がやっていたケースは次のように組むことが多かったです。
例: MessageCardを変換してAdaptive Cardにするフロー
1. HTTPリクエストを受信
2. Compose(作成)でMessageCardデータを受け取る
3. Parse JSONで特定のキーを抽出し変数に格納
4. Compose(作成)でAdaptive Card用のJSONを組み立て
5. Teamsコネクタを呼び出してAdaptive Card形式で投稿
とはいえ箇条書きにしても頭でイメージしづらいので、なるべく小分けにステップをテストして動くことを確認しつつ組むのがコツです。
{
"title": "@{triggerBody()?['title']}",
"text": "@{triggerBody()?['summary']}"
}上記のようにCompose内で動的コンテンツを参照する式を使うと、フロー実行時にWebhookペイロードが反映されます。失敗した場合はどのステップが原因なのかをデバッグログから丁寧に追うようにしましょう。
大規模なチケット管理システムのケース
より大規模な環境では、ひとつのWebhook通知で複数の情報をまとめて送ってくることもあります。そのため、Power Automate内で複数回のJSONパースを行い、個々の項目を別々のタスクに連動させる工夫が求められます。たとえば下記のようにチケットID、担当者、期日などをキーに分けて取得し、Teamsのカード上に整形表示する手段を取りました。
私のチームでは10種類以上のペイロードを一括で受けていましたが、Power AutomateでJSON構造をしっかり定義すれば意外に管理しやすかったです。
| 機能 | 概要 |
|---|---|
| 拡張セキュリティ | 機微情報を含むチャットを保護しやすくなる |
| 高度な分析 | 会議の参加状況や利用傾向を可視化する |
| カスタム機能連携 | よりリッチなカードやアクションを利用可能 |
ライセンスの契約形態によっては追加費用がかかりますので、ビジネスとして採算が合うか、ユーザ数や運用規模を考慮しながら検討するとよいでしょう。
トラブルを乗り越えるためのポイント
段階的に移行を進める
私が当時経験して学んだ教訓は、「すべてを一気に移行しようとしない」ことでした。MessageCard対応のWebhookを一斉に止めてしまうと混乱が起きるため、一部の通知だけ先行してAdaptive Cardで流してみて問題がないことを確認してから、順次切り替えていく方法が安全です。特にJiraやServiceNowなど、大量に発行されるチケット通知は事前に新方式の動作を確かめておくと安心です。
関連チームとの連携も大切
Webhookの管理部門（たとえばサーバ担当のチーム）とPower Automateを扱う部門（たとえば社内ITやDX推進チーム）が違うと、どこまで誰が責任を持つのか曖昧になりがちです。設定変更権限や運用方針を事前にすり合わせておくと、移行作業がスムーズに進みます。
まとめと今後の展望
Webhookの廃止を機にPower Automateへ移行するのは、面倒にも感じる反面、Adaptive Cardの柔軟さやTeams連携の進化を体感するチャンスでもあります。移行時にはペイロード変換やライセンス要件など気をつける点が多いですが、一度仕組みが整えば運用が楽になるメリットも大きいです。さらに今後はAtlassianなど主要なサードパーティ製品が新たなTeams連携機能を続々提供していくことが予想されるため、MessageCardからAdaptive Cardへスムーズに移行できれば、将来的なメリットも大きいでしょう。
私の場合、移行当初は手間が増えるばかりと思っていたのですが、最終的にはカードのレイアウトが強化されてチーム内での情報共有が楽になりました。やってみる価値は十分あると感じています。
コメント