Teamsのアダプティブカードで回答を受け取る

準備：商用のMicrosoft 365環境で、Teamsを使える自分の職場アカウントとメールアドレスを確認します。TeamsのWorkflowsアプリが使えること、Power AutomateからTeamsへの接続が有効なことを確認。本番と分けたインスタントクラウドフローを作り、「手動でフローをトリガーする」を選びます。テストは1回ずつ行い、実行中の練習フローを重ねません。

Microsoft Teamsの「アダプティブ カードをポストして応答を待つ」（Post adaptive card and wait for a response／操作ID：PostCardAndWaitForResponse）を追加し、名前を CardReply に変更します。非推奨の旧アクションや、応答を待たない投稿アクションを選ばないようにします。［投稿者］＝フローボット（Flow bot）、［投稿先］＝フローボットとのチャット（Chat with Flow bot）、［受信者］＝準備した自分のメールアドレスにします。

CardReplyの［メッセージ］欄へ、下のJSON全体を通常の入力として貼り付けます。式として入力したり、全体をさらに引用符で囲んだりしません。2つのAction.Submitは表示するtitleと、送るdata.answerを分けてあります。［更新メッセージ］に「回答を受け取りました。練習を終了します。」を指定します。更新する設定が別に表示される場合は有効にします。

{
  "type": "AdaptiveCard",
  "version": "1.4",
  "body": [
    {
      "type": "TextBlock",
      "text": "【練習】内容を確認しましたか？",
      "wrap": true
    }
  ],
  "actions": [
    {
      "type": "Action.Submit",
      "title": "確認しました",
      "data": {
        "answer": "confirmed"
      }
    },
    {
      "type": "Action.Submit",
      "title": "修正が必要",
      "data": {
        "answer": "review_requested"
      }
    }
  ]
}

直後に組み込みのデータ操作「作成」を1つ置き、名前を AnswerOut に変更します。［入力］の［式］欄へ body('CardReply')?['data']?['answer'] を入れて確定します。先頭の @ や @{ } は付けません。CardReplyに成功した後だけ実行する既定の設定を保ちます。回答者・ボタンの表示名・submitActionIdではなく、JSONで定義したanswerを読み取ります。

確認A：保存して手動実行し、Teamsで今回届いたカードの「確認しました」を1回押します。フローの実行履歴でCardReplyが成功したこと、出力本文のdata内にanswer＝confirmedがあること、AnswerOutの出力もconfirmedであることを確認します。この練習では外部の表や承認状態は更新しません。

確認B：新しく手動実行し、新しいカードの「修正が必要」を1回押します。AnswerOutの出力がreview_requestedになることを確認します。同じカードを押し直して回答を変更する練習ではありません。各カードで処理されるのは最初の回答だけです。

確認C：もう一度実行し、今回はボタンを押さずに実行履歴を見ます。CardReplyは回答待ち、AnswerOutは未実行で、confirmedもreview_requestedも得られません。確認後は、その練習実行を実行履歴からキャンセルして待機を終えます。キャンセル後の古いカードは使わず、再テストには新しい実行とカードを使います。

届かない・押しても再開しない：実行履歴のCardReplyを開き、受信者、Teams接続、Workflowsの利用可否、JSONの半角ダブルクォートを確認します。古いカードや、応答を待たないアクションになっていないかも確認します。権限エラーは組織の管理者に確認し、管理ポリシーを無効にして回避しません。

AnswerOutが空（null）になる：成功したCardReplyの実行履歴で出力本文を開き、dataの中にanswerがあるか確認します。JSONのキーの大文字・小文字、式内のCardReplyというアクション名、押したカードが今回のものかを照合します。空や想定外の値を「修正が必要」と自動判定せず、ここで原因を調べます。本番で条件分岐を足す場合は、confirmedとreview_requestedをそれぞれ明示して判定し、その他は別扱いにします。