AWS Lambda から Power Automate の Teams Incoming Webhook コネクタの挙動をテストする

はじめに

Microsoft (以下MS) が、Teams内のOffice 365コネクタを廃止することを発表しました。
これにはIncoming Webhookも含まれ、記事執筆時点では、以下のスケジュールが設定されています。

• 2024年8月15日: 新規コネクタの作成が停止し、これ以降、新規にIncoming Webhookを利用する場合、Power Automateのワークフローでコネクタを介して受信する方式に対応する必要あり
• 2024年12月31日: 既存のWebhook URLが無効化される予定 (ただし、URLを更新すれば2025年12月まで利用可能)

最新の情報は、以下のMS公式サイトをご参考ください。

AWSユーザーも、AWS Health Awareを利用しているなどのケースで、監視などのアラートの受信をTeamsのIncoming Webhookで実装している場合には、本件に適切に対応していく必要があるでしょう。
AWS Health Awareに関する記事は、こちらをご覧ください。

2024/11: 旧コネクタから新コネクタに移行する際、メッセージカード形式のJSONをアダプティブカード形式に変換する必要があり、現状、この変換処理を利用者側で実装する必要があります。しかしながら、直近、マイクロソフトの公式サイトに、この開発が不要になるアップデートが予定されていると受け止められる文章が掲載されております。今後の情報にご注意ください。
https://devblogs.microsoft.com/microsoft365dev/retirement-of-office-365-connectors-within-microsoft-teams/

• ワークフローアプリのパリティ機能に関する注意
  • 現在、次のシナリオをサポートするために、Workflow アプリで Webhook を使用する方法を開発しており、2025 年 3 月 30 日までに詳細を共有する予定です
    • メッセージカード形式のメッセージ ペイロードを投稿します (ペイロードをアダプティブ カードに再フォーマットする必要はありません)
    • プライベートチャンネルに投稿する

移行方法と注意点の概略

Incoming Webhookの廃止に伴い、MSはPower Automateを利用した新しいワークフローへの移行を推奨しています。
具体的な手順は、以下のブログに詳しく掲載されています。

大まかには以下の通りです。

Power Automateでのワークフロー作成

Power Automateを開き、「Webhook要求を受信するとチャネルに投稿する」テンプレートを使用して新しいワークフローを作成します。
このテンプレートにTeamsのチャネルにメッセージを投稿するための設定が含まれていますので、カスタマイズするのが簡単でしょう。

Webhook URLの更新

既存のIncoming Webhookを使用しているアプリケーションやサービスで、Power Automateで生成された新しいWebhook URLに差し替えます。

ユーザー設定の確認

新しいワークフローの動作は、作成したユーザーのアクセス権限に依存するため、ワークフローを実行するユーザーがTeamsのチームメンバーであることを確認します。
メンバーであれば、ワークフローが正常に動作するようになります。

注意点

新しいIncoming Webhookでは、従来のように投稿者の表示名やアイコンを自由に設定できなくなります。
また、投稿はフロー所有者の名前で表示され、アイコンも固定されます。

移行先のワークフローを作成する

非常に簡単です。
Power Automateのフロー作成画面で、以下のように作ります。

一番上のコネクタ「Teams Webhook 要求を受信したとき」の設定です。
認証方式は、環境に応じて任意に選びますが、Active Directoryでドメイン認証できない環境からリクエストを送る場合には「誰でも」を選びます。
この「誰でも」を選んで発行されるURLを利用しますと、URLを知っていれば誰でも投稿できてしまいますので、管理上の注意が必要です。
AWSの場合は、URLの末尾に付加されているsigをAWS Secrets Managerで管理することで、不正利用のリスクを低減できるでしょう。

「JSONの解析」コネクタでは、外部から受信するJSONデータのスキーマを定義します。
ここでスキーマを定義することで、後続のコネクタでパースして各キーの値を扱うことが容易になります。

ここまで出来ていれば、最後の「チャットまたはチャネルでメッセージを投稿する」コネクタで「動的なコンテンツ」を参照すると、パースしたキーと値が見えるようになっていますので、以下のように書くだけです。

AWS LambdaからWebhookの挙動をテストする

AWS LambdaからIncoming Webhookにリクエストを送るにはurllib.requestを利用します。
テスト用なので、最小限の労力でコードを仕上げます。

from urllib import request
import json

endpoint="https://prod-xx.japaneast.logic.azure.com:443/workflows/(以下略)"

def lambda_handler(event, context):
    try:
        data = {
            "title": "【詳細】南海トラフ地震臨時情報「巨大地震注意」対象地域は",
            "url": "https://www3.nhk.or.jp/news/html/20240808/k10014542271000.html",
            "description": "8日、宮崎県で震度6弱の揺れを観測するマグニチュード7.1の大きな地震があり、九州で、最大で50センチの津波を観測しました。この地震で気象庁は南海トラフ地震の想定震源域では大規模地震が発生する可能性がふだんと比べて高まっているとして臨時情報を出して巨大地震への注意を呼びかけています。"
        }
        headers = {'Content-Type': 'application/json'}
        req = request.Request(url=endpoint, method="POST",headers=headers,data=json.dumps(data).encode())

        with request.urlopen(req) as res:
            body = res.read()

    except Exception as e:
        print(e)

引用: 【詳細】南海トラフ地震臨時情報「巨大地震注意」対象地域は | NHK

結果

Lambda関数を実行すると、以下のように投稿され、Incoming Webhookのワークフローが機能していることが確認できました。

終わりに

これまでのTeamsのIncoming Webhookは、シンプルで使いやすいものでしたが、敢えて後ろ向きに捉えれば、投稿するだけで終わりでした。
例えば、Incoming Webhookで投稿された後、何か後続の処理を実行するためには、結局、投稿されたことをトリガーにして実行するPower Automateを組む必要がありました。

今回のPower Automateのワークフローへの移行は確かに体力のかかる作業ですが、移行後はワークフローで様々なコネクタと組み合わせて処理ができるようになりますので、自由度が高まります。

AWSの利用者の場合は、Amazon CloudWatch または EventBridge などを契機としてイベント駆動型で外部に通知を発行したいケースで、Eメールを代替する目的でIncoming Webhookが良く使用されていると思います。
無視すればIncoming Webhookを活用している監視や運用に影響が出ますので、MSからのアナウンスを見逃さず、メリットを理解して前向きに対応していきましょう。

関連記事