Power AutomateのTeams連携とは？カード通知・メンション・承認の実装と権限設計を解説

Teamsへ通知を飛ばすだけなら、Power Automateの最初の一本は十分ほどで動きます。詰まるのはその先です。メンションが名前の文字列にしかならない、カードのボタンがモバイルで表示されない、承認したはずの記録が残らない、件数が増えた途端に投稿が落ちる。どれもコネクタ側の仕様で説明がつき、着手前に知っていれば設計で避けられます。この記事では、投稿アクションの選び方、メンションの上限、カードの表示と応答、承認の受け口としての適否、調整制限と接続主体を、Microsoft Learnの記載に沿って整理しました。製品そのものの概要はPower Automateとは？基本・できること・料金・導入判断まで解説をご覧ください。

まとめ：投稿の主体とカードの方式と接続の権限で決まる

先に結論を置きます。投稿の名義は、返信や更新を後から掛けるならフローボット、政府機関向けクラウドや監査上の都合があるならユーザーで固定する。応答を受け取りたいカードは、名前に「応答を待機」が入ったアクション以外で作らない。承認の記録を残す必要があるなら、アダプティブカードで代替せず承認コネクタを使う。この三点を着手前に決めておけば、作り直しはほぼ発生しません。

規模の天井も先に引いておきます。フローボットとしてのアダプティブカード投稿は接続ごと25回300秒という枠に入り、他のGet以外の要求300回300秒とは別枠です。メンションは一通あたり20ユーザーと20タグまで、本文は約28KBまで。プライベートチャネルへの投稿は現在サポートされません。数値はMicrosoft Learnの記載で、2026年8月時点の値です。

Teamsコネクタの投稿アクションが四系統に分かれている理由

Teamsコネクタの投稿系アクションは、送るものがテキストかカードか、送り先が新規メッセージか既存スレッドかで分かれています。名前が似ているため、まず対応関係を押さえます。

テキストとカードと返信と通知では選ぶ投稿アクションがそれぞれ異なる

Microsoft Learnの「Microsoft Teams コネクタ」リファレンス（2026年8月時点で確認）に載る投稿系のアクションは、次のように整理できます。

操作IDは上から順に PostMessageToConversation、PostCardToConversation、PostCardAndWaitForResponse、UpdateCardInConversation、ReplyWithCardToConversation、PostFeedNotification です。テンプレートの定義はこちらで突き合わせます。

見落としやすいのが最後のフィード通知です。これはチャネルやチャットに本文を残さず、相手のアクティビティフィードにだけ通知を積みます。督促のように何度も飛ばす用途では、チャネルを流さずに済むぶん運用が荒れません。

フローボットとユーザーのどちらの名義で投稿するかを制約から判断する

投稿系のアクションには、投稿者としてフローボットを選ぶか、接続したユーザー自身を選ぶかという分岐があります。前者はTeamsにワークフローアプリが入っていること、そしてTeams管理センター側でそのアプリが許可されていることが前提です。導入前のテナントでは、フローの実行時にアプリ未インストールのエラーで止まります。

名義の選び方には制約が絡みます。フローボットは政府機関向けクラウド（GCC・GCCH・DoD）のテナントではサポートされず、商用テナント専用です。政府機関向け環境ではユーザー名義の投稿へ倒すしかありません。逆に、送信済みカードを後から書き換える運用を組むならフローボットが扱いやすく、退職や異動で名義が消える心配も小さくなります。どちらの名義でも、投稿はその接続を作った人の権限で走る点は変わりません。

プライベートチャネルへ投稿できない制約を標準チャネルかチャットで回避する

コネクタの一般的な制限事項として、プライベートチャネルへのメッセージ投稿とアダプティブカード投稿は現在サポートされていません。機密案件をプライベートチャネルに閉じている組織ほど、この一行で設計が崩れます。

回避の方向は二つあります。ひとつは通知先を標準チャネルに移し、閲覧制限はチーム自体の参加者で担保する方法。もうひとつは、対象者を限定したチャットへ投稿する方法です。ただしチャットを作るアクションには最大20人という上限があり、ゲストユーザーも対象外です。人数が読めない配布先をチャットで賄う設計は避けてください。

メンション付き投稿はトークン取得と本文への差し込みで組み立てる

Teamsのメンションは、本文に記号と名前を書いても通知になりません。専用アクションでトークンを取り、その出力を本文へ差し込む手順を踏みます。

ユーザー宛とチームタグ宛ではトークン取得アクションがそれぞれ異なる

個人宛には「ユーザーの@メンショントークンを取得する」（AtMentionUser）、チームタグ宛には「チームタグの@メンショントークンを取得する」（AtMentionTag）を使います。前段でトークンを作り、後続の投稿アクションの本文へ動的コンテンツとして貼る流れです。アダプティブカードの中でメンションを効かせる場合も考え方は同じで、カードのJSONにトークンの出力を埋め込みます。

宛先が固定でない運用では、タグ側のほうが扱いやすい設計です。タグの作成やメンバー追加のアクション（CreateTag、AddMemberToTag）も揃っているため、当番制の通知先をフロー側から差し替えられます。個人のメールアドレスを直接書き込む設計だと、異動のたびに全フローを触る羽目になります。

一通あたり二十ユーザー二十タグと本文約28KBまでという上限を守る

メンションには明確な上限があります。同リファレンスは、一つのメッセージでメンションできるのは最大20ユーザーと20タグまでと記載しています。全社通知を個人メンションの列挙で作ろうとすると、この線を越えた時点で意図した通知になりません。

本文側の上限も併せて押さえます。メッセージのサイズは約28KBが上限で、テキスト、画像、リンク、テーブル、メンションといったHTML要素をすべて含めた合計です。超えると「要求エンティティが大きすぎます」というエラーが返ります。一覧表をそのまま貼る通知は、件数が伸びた運用の途中でこの壁に当たります。件数が可変の通知は、上位数件だけ本文に出し、全件はリンク先で見せる形に寄せてください。

メンションを届けたい相手が受け取れない条件を実装前に確認して潰す

受け手側の条件も設計に影響します。ゲストや外部ユーザーが絡む経路には個別の非対応が点在し、たとえば「選択したメッセージの場合」と「誰かがアダプティブカードに応答したとき」の二つのトリガーは、チームのゲストユーザーと外部ユーザーに対して動作せず、しかも既定の環境でしか機能しません。

社外メンバーを含む通知は、Teams側で完結させずメールなど別経路を併走させる判断になります。承認まで社外へ回すなら、次章で扱う承認コネクタ側の制約も併せて確認しておきましょう。

アダプティブカードは応答を待つかどうかで実装方式と設計が分かれる

最も相談が集まるのがカードまわりです。作ってから直せない仕様があるため、方式の選択を先に固めます。

投稿して終える通知カードと応答を待機するカードの用途と違いを見極める

ボタンの入力をフローで受け取りたい場合は、名前に「応答を待機」が入ったアクションを選ぶ必要があります。Microsoft Learnのトラブルシューティングでも、カード送信後のエラーの典型として、応答の待機を含まない名前のアクションを使ったケースが挙げられています。単に知らせるだけならPostCardToConversation、入力を受けて後続処理へ渡すならPostCardAndWaitForResponse、という切り分けです。

応答を待機するアクションは、応答が返るまでフローの実行が続きます。長時間の滞留を前提にするなら、実行数や実行時間の上限にも目が向きます。権利の区分ごとの上限はPower Automateの料金・ライセンスとは？Premium/Process/従量課金の区分と見積もり手順を解説【2026年版】に整理しました。どの種別のフローで組むかの判断はPower Automateのクラウドフローとデスクトップフローの違いとは？トリガー種別・実行基盤・ライセンス差で選び分けるが参考になります。

スキーマはv1.5以前でモバイルは1.2までという表示の天井

カードのJSONを書くときに効いてくるのがスキーマバージョンです。Teamsプラットフォームは、ボットが送信したカードについてアダプティブカードv1.5以前の機能をサポートすると明記しています。さらにモバイルアプリはバージョン1.2までのサポートで、1.2より後のスキーマを使ったカードはモバイルで正しく描画されないか、機能が制限される可能性があると注意書きが付きます。

現場での当て方は単純です。閲覧がPCに限られる社内フローなら1.5まで、スマートフォンからの承認や報告を含むなら1.2の範囲で組む。この一行を決めておくと、後から「自分の画面では出るのに現場では出ない」という報告に振り回されずに済みます。

表示面には他にも制約が並びます。肯定的あるいは破壊的なアクションのスタイル設定はTeams上のカードでは効きません。Action.SubmitのisEnabledプロパティも非対応です。カード内でのファイルや画像のアップロードもサポートされず、画像は公開されたHTTPSのURLで参照する形になります。最終的な画像の前にリダイレクトが挟まるURLは表示されないため、配信元は固定URLで用意してください。

一度しか送信できない仕様を踏まえて作り直しが効かない場面に備える

見落とすと運用が壊れるのが、各アダプティブカードは一度だけ送信でき、それ以降の送信はすべて無視されるという仕様です。押し間違えた担当者が「もう一度押しておきました」と言っても、二回目はフローへ届いていません。

備え方は二つです。応答の待機アクションの下部にある更新メッセージ欄を設定し、送信後にカードを別の内容へ置き換えて受け付けた旨を見た目で示すこと。もうひとつは、押し間違いが致命的になる操作を一枚で完結させず、確定処理の前に別経路の確認を挟むことです。取り消しの余地がない処理をワンクリックに載せない、という判断になります。

承認は承認コネクタとカード応答待機のどちらで組むかを要件で決める

Teams上の承認は、承認コネクタで作る道とアダプティブカードの応答待機で代替する道があります。見た目はどちらもカードなので混同されがちですが、残るものが違います。

記録と多段階が要る場合は承認コネクタを選ぶ必要がある理由を押さえる

承認コネクタの「開始して承認を待機」で作った承認は、Dataverseに保存されます。承認の種類も、全員の承認が必須、最初に応答した一人で確定、カスタム応答の全員待ち、カスタム応答の一人待ち、順次承認の五つが用意されています。承認者はOutlookのメール、Teamsのアダプティブカード、Power Automateの画面のいずれからも応答でき、経路をこちらで揃える必要がありません。

つまり、誰がいつ何と答えたかを後から追える形で残す必要があるなら、承認コネクタで組むのが前提になります。承認の種類の選び分けや多段階の組み方、タイムアウトへの対処はPower Automateの承認ワークフローの作り方｜承認の種類・多段階・30日タイムアウトへの対処に切り分けてあります。

アダプティブカードの応答待機で代替してよい条件と判断の境界を定める

それでもカードの応答待機で足りる場面はあります。判断の線はこう引きます。応答が記録として要求されず、対象が単一チームの中で完結し、応答者が誰であっても業務上は同じ、という三条件がすべて揃うときだけ代替してよい。会議室の在庫確認や当番の受諾確認がこれに当たります。

逆に、条件がひとつでも崩れるなら承認コネクタへ倒してください。カードの応答待機には承認のような承認者リストの概念がなく、そのチャネルを見られる人なら誰でもボタンを押せます。誰が押したかの記録もフロー実行履歴の中に散在するだけで、後から一覧で追う手段が用意されていません。監査や社内規程が絡む承認をカードで代用した結果、証跡の再構築に工数を掛ける例が出ています。

ゲストと既定環境の制約が承認の設計を縛る条件と該当場面を確認する

承認コネクタ側の前提条件にも注意が必要です。承認はDataverseに保存されるため、既定以外の環境で初めて承認コネクタを使うときは、最初に実行するユーザーがその環境の管理者ロールを持っている必要があります。既定の環境ならデータベースは自動で用意されます。

社外を含む承認には別の壁が立ちます。B2Bテナントの招待を受け入れていないゲストユーザーは承認者リストから外され、承認に参加しません。またMicrosoft EntraのAllowAdHocSubscriptionsが無効なテナント、セキュリティグループでDataverse環境へのアクセスを制御しているテナント、米国政府機関プランでは、環境にいないユーザーへ承認を割り当てられません。社外承認を含む要件は、実装より先にテナント設定の確認から入るのが順序です。

調整制限とトリガーの間隔が本番運用で処理できる件数の天井を決める

検証環境で通ったフローが本番で落ちる原因の大半は、件数と頻度です。調整制限は接続ごとに定義されています。

接続ごと25回300秒という制限に最初に当たるカード配信の条件を知る

同リファレンスの調整制限の表では、Get以外の要求が二段階に分かれています。チャットの一覧、フィード通知の投稿、フローボットとしてのアダプティブカード投稿、その他フローボットの操作は300秒あたり25回。それ以外のGet以外の操作は300秒あたり300回です。加えてAPI呼び出しが60秒あたり100回、トリガーのポーリング頻度が600秒あたり1回と定められています。

この差が意味するのは、カード通知の一斉配信が早い段階で頭打ちになるということです。百人へ個別カードを配る夜間バッチは、単純に組むと制限に触れます。対象を分割して時間をずらすか、チャネルへの一通とメンションに寄せるか、接続を分けるかの三択です。設計時点で配信対象の最大件数を数えておいてください。

チャネル監視のポーリング3分と返信を拾えないトリガー仕様を理解する

Teams側の投稿をきっかけにフローを回す場合は、トリガーの粒度が制約になります。「新しいチャネルメッセージが追加されたとき」と「チャネルメッセージに記載されている場合」のポーリング間隔は3分です。即時反応を期待する用途には向きません。

さらに前者は、チャネルに追加されたルートメッセージに対してのみ発生し、既存メッセージへの返信では起動しません。スレッドの中でのやり取りを拾う設計は成立しないと考えてください。キーワードで拾うトリガーも、指定できるのは一単語の語句だけです。チャットを見るトリガーはフローごとに一ユーザーのみという制約も付きます。会話を起点にした自動化は、この四つの制約の内側でしか組めません。

接続を誰の名義で作るかによって運用の寿命が変わる理由を押さえる

Teamsコネクタの接続も、他のコネクタと同じく作成した人の権限で動きます。個人アカウントで作った接続を本番に残すと、その人の退職や権限変更でフロー群が一斉に止まります。専用のアカウントで接続を作り、ライセンスと所属チームを固定しておくのが定石です。

接続主体をどう設計するかという一般論と、SharePointを台帳にした場合の権限の考え方はPower AutomateのSharePoint連携とは？トリガー選定・無限ループ回避・権限設計を実装目線で解説に整理してあります。Teams通知の多くはSharePointやFormsを入口にするため、両方の接続を同じ方針で揃えておくと管理が楽になります。

内製で組み切れる範囲と実装支援へ切り出す判断条件の分かれ目を整理する

ここまでの制約を踏まえると、どこまで自前で組むかの線は比較的はっきり引けます。

内製で回せるのは単一チームかつ通知中心という要件の範囲に限られる

通知先が単一チームの標準チャネルに収まり、宛先が20ユーザー以内で、応答を記録として残す要件がない。この範囲なら情報システム部門やパワーユーザーの内製で十分に回ります。テンプレートから起こして、接続を専用アカウントに差し替え、対象件数を数えておけば運用に載ります。

線を越えるのは、承認の証跡が監査対象になる場合、配信対象が数百人規模になる場合、社外メンバーを含む場合、基幹システムのデータを条件に含む場合です。ここからは制約の組み合わせで設計が決まるため、作りながら考えると手戻りが積み上がります。部門別の自動化パターンと外注の線引きはPower Automateの導入事例｜経理・人事・営業の自動化パターンと外注の線引きにまとめました。要件が固まらない段階からの相談はPower Automate導入支援・RPA移行で受けています。

Teams以外へも通知が要る場合は基盤側で受けて送信先を分岐する設計に寄せる

通知先がTeamsだけで終わらない組織も珍しくありません。取引先とLINE WORKSでやり取りしている、現場だけ別のチャットを使っている、といった状況です。ここでTeamsコネクタの制約に合わせて全体を設計すると、他方に無理が出ます。

通知の内容を組み立てる処理を一箇所にまとめ、宛先ごとの送信だけを分岐させてください。他のチャット基盤へ送る側の仕様感はLINE WORKS Incoming Webhookの設定手順とJSON送信仕様｜5URL・120req/minの上限が参考になります。宛先ごとに上限も表現力も違うため、共通で使える最小の情報量に本文を揃えるのが現実的な落としどころです。

よくある質問

プライベートチャネルへ通知を送る方法はありませんか？

コネクタの制限事項として、プライベートチャネルへのメッセージ投稿とアダプティブカード投稿はサポートされていません。通知先を標準チャネルへ移すか、対象者を絞ったチャットへ送る構成に変えます。チャットを作るアクションは最大20人でゲストは対象外のため、人数が可変の配布先には向きません。

メンションが通知にならず文字列のまま表示されるのはなぜですか？

本文に記号と名前を直接書いた場合はメンションとして扱われません。「ユーザーの@メンショントークンを取得する」または「チームタグの@メンショントークンを取得する」を前段に置き、その出力を投稿アクションの本文へ差し込んでください。上限は一通あたり20ユーザーと20タグです。

カードのボタンがスマートフォンで表示されないのはなぜですか？

Teamsモバイルアプリがサポートするアダプティブカードはバージョン1.2までで、それより後のスキーマを使ったカードは描画が崩れたり機能が制限されたりする可能性があるとMicrosoft Learnに記載されています。モバイルからの操作を含むフローは、1.2の範囲でカードを組むのが安全です。

同じカードで二回目の送信ができないのは仕様ですか？

仕様です。各アダプティブカードは一度だけ送信でき、以降の送信は無視されます。応答の待機アクションの更新メッセージ欄を設定し、送信後にカードを置き換えて受付済みと分かる表示に切り替えてください。押し直しが必要になる設計自体を避けるほうが確実です。

承認をアダプティブカードで代用しても問題ありませんか？

記録が不要で、単一チーム内で完結し、応答者が誰でも業務上同じ場合に限れば代用できます。監査や規程が絡むなら承認コネクタを使ってください。承認はDataverseに保存され、承認の種類も五つ用意されています。カードの応答待機には承認者を限定する仕組みがなく、チャネルを見られる人なら誰でも押せます。

関連記事

• Power Automateとは？基本・できること・料金・導入判断まで解説：製品の概要と導入判断の全体像。
• Power Automateの承認ワークフローの作り方｜承認の種類・多段階・30日タイムアウトへの対処：承認そのものの組み方。
• Power AutomateのSharePoint連携とは？トリガー選定・無限ループ回避・権限設計を実装目線で解説：入口側の実装と接続の権限設計。
• Power Automateのクラウドフローとデスクトップフローの違いとは？トリガー種別・実行基盤・ライセンス差で選び分ける：どの種別で組むかの判断。
• Power Automateの料金・ライセンスとは？Premium/Process/従量課金の区分と見積もり手順を解説【2026年版】：権利の区分と見積もり手順。