このエントリは2026/04/04現在の情報に基づいています。将来の機能追加や変更に伴い、記載事項からの乖離が発生する可能性があります。
問い合わせ
お初の方から以下のような問い合わせが届いた。
Microsoft Teams (以下Teams) にシステムの処理結果を投稿するAPIを作成しようとしているが、よい方法はないか？確かWebhookはリタイアすると聞いているので、それ以外の方法が知りたい。
ちょっと漠然としていたので、本当は何を知りたいのか、何ができたらいいのか、もうちょっと聞いてみた。
- メッセージを投稿するためのAPIにはどういうものがあるのか
- アプリとして投稿できるのか、それとも接続ユーザーとして投稿するのか
ということのよう。なお、リタイアするWebhookとは、Incoming webhookのことで、以下のドキュメントの注意書きに記載がある。
受信 Webhook を作成する / Create Incoming Webhooks
https://learn.microsoft.com/microsoftteams/platform/webhooks-and-connectors/how-to/add-incoming-webhook
方策
様々な方式があるが、以下のように大別できる。
| 1 | Teams workflow webhook | Teams incoming webhookの後継。実態はTeamsに組み込まれたPower Automate。 | 受信 Webhook を作成する / Create Incoming Webhooks https://learn.microsoft.com/microsoftteams/platform/webhooks-and-connectors/how-to/add-incoming-webhook |
| 2 | Microsoft Graph Channel Message API | Teamsだけでなく、Microsoft 365アプリを操作するためのREST API | Microsoft Graph API を使用して Microsoft Teams で作業する / Use the Microsoft Graph API to work with Microsoft Teams https://learn.microsoft.com/graph/api/resources/teams-api-overview |
| 3 | Logic Apps/Power AutomateのTeamsコネクター | Low codeソリューションのための接続のしくみ | Microsoft Teams https://learn.microsoft.com/connectors/teams/ |
| 4 | Teams Bot / proactive messaging | 自社アプリ / ボット名義で通知したい、将来 interactive 化したい場合。 アプリのインストールと bot 実装が必要。 Workflows より重いが、アプリとして投稿したいならこちら。 | プロアクティブ メッセージ / Proactive messages https://learn.microsoft.com/microsoftteams/platform/bots/how-to/conversations/send-proactive-messages プロアクティブ インストール メッセージを送信する / Send proactive installation messages https://learn.microsoft.com/microsoftteams/platform/graph-api/proactive-bots-and-messages/graph-proactive-bots-and-messages |
投稿者とAPI認証時のPrincipalは異なる
1の方法を採用する場合に一番注意が必要な点がこれ。WebhookでAPIの呼び出しを制御する場合、以下の3種類から選択できる。
AnyoneAny user in my tenantSpecific users in my tenant
前述の通り、実体はPower Automateなので、Power AutomateのOAuth認証ドキュメントには allowed users に service principal user の object ID （Managed Identityを含む）を指定できるが、投稿者はTeams connectorの投稿アクションで構成したユーザーの権限で決まる。つまり、Flow bot と Teams connector にサインインしているユーザー のいずれか。換言すると、Workflow webhook をそのまま「自分の app registration / service principal として Teams に投稿する仕組み」ではない。
認証
Teams Workflow Webhook側の認証をAny user in my tenantまたはSpecific users in my tenantにした場合、Power Automate のOAuth認証のドキュメントにてservice principal userのobject IDをallowed usersに入れられると明記している。
そのため、Specific users in my tenant を使うなら、対応する managed identity の service principal object ID を allowed users に入れることができる。
Power Automate を使用して Teams でメッセージを送信する / Send a message in Teams using Power Automate
https://learn.microsoft.com/power-automate/teams/send-a-message-in-teams
Azure Logic Apps でマネージド ID を使用して、保護された Azure リソースへのワークフロー接続を認証する / Authenticate workflow connections to protected Azure resources by using managed identities in Azure Logic Apps
https://learn.microsoft.com/azure/logic-apps/authenticate-with-managed-identity
User-assigned Managed Identity in Logic Apps Standard
https://techcommunity.microsoft.com/blog/integrationsonazureblog/user-assigned-managed-identity-in-logic-apps-standard/3119697
ただし、これはあくまで webhook caller auth の話で、Teams 上の投稿者のidentityは受け側workflowのTeamsコネクター・アクションが決めるため、例えばLogic Apps Standardのmanaged identityを使ってAPIの認証を構成したとしても、Teams上での投稿者になるわけではない。つまり、managed identityを使えても、それは 「Workflow webhook を誰として呼ぶか」の話であって、「Teamsに誰として表示されるか」の話ではない点は注意が必要。これはLogic AppsでTeamsコネクターを使った場合でも同じで、Logic AppsのHTTPトリガーで認証を構成したとしても、そのユーザーコンテキストをTeamsコネクターに渡すわけではない。
Microsoft Dataverse でソリューション内で接続参照を使用する / Use a connection reference in a solution with Microsoft Dataverse
https://learn.microsoft.com/power-apps/maker/data-platform/create-connection-reference
使い分け
1～3とも、アプリではなくユーザーとして接続するため、接続に用いるユーザーアカウントのロールの権限でTeams Chat/Channelへのアクセス可否が決まる（Flow botとして投稿することもできるが、接続ユーザーも表示される）。2には確かにApplication permissionもあるのだが、これはmigration用途に限定されており、アプリとして投稿することの一般ソリューションではない。
Graph APIを選ぶのは、Webhook URL 管理よりも Entra ID / Graph ガバナンスを優先し、 delegated user contextでの直接投稿を実施したい場合。公式 API は POST /teams/{team-id}/channels/{channel-id}/messages で、通常の投稿は delegated の ChannelMessage.Send が最小権限。Group.ReadWrite.Allは後方互換用で、application permission のTeamwork.Migrate.Allはmigrationのみサポートなので、実際には使えない。
app identity が必要なら Teams bot / proactive messaging、つまり4の方法を採用せざるを得ない。この方法は手間がかかるので、本当にアプリとして投稿する必要性があるのかを吟味してからでも遅くない。
チャネルで chatMessage を送信する / Send chatMessage in a channel
https://learn.microsoft.com/graph/api/channel-post-messages?view=graph-rest-1.0&tabs=http
今回は
上記のような説明をしたところ、
- 今回のユースケースでは、特に投稿ユーザーが見えても問題ない
- 投稿件数も1日数回なので、Teams Botを構成するまでもない
- 投稿メッセージはレイアウトを考慮する必要があるが、投稿にあたりそこまで学習曲線の勾配が厳しくないものを選択したい
- VNET内から直接呼び出し、投稿するアプリはパブリックからのアクセスをブロックしたい
ということだったので、この問い合わせ主はLogic Apps StandardとTeamsコネクターで実装することにした模様。
Logico Inside 