TeamsのAdaptive Cards実装手順｜承認カードの作り方

Teams上で「承認」ボタンを押すだけで申請が完結する仕組みを見たことがある方は多いはずです。あの承認カードの正体は、Microsoftが提供するUIフレームワーク「Adaptive Cards」です。SharePointリストやForms、Power Automateと組み合わせることで、休暇届や経費精算、購買稟議といった申請業務をTeams上に一本化できます。本記事は、実際に手を動かして承認カードを作る側に向けた実装手順の記事です。トリガーの設定からカードのJSON、投稿、応答の受け取り、結果の書き戻しまでを順に追い、実装で詰まりやすい箇所と運用上の制約を具体的に扱います。

なお、標準の承認アプリで足りるのか、内製するのか、専用ツールを入れるのか——どの方式を選ぶかの比較はMicrosoft 365の承認ワークフロー｜Teams標準の限界にまとめています。選定から読みたい場合はそちらを先にご覧ください。

この記事の要点

• Adaptive CardsはJSONでUIを定義する仕様で、Power Automateの「Teamsに投稿してフロー応答を待機する」アクションから呼び出して承認カードにする。
• 実装は「トリガー設定→カード生成→投稿→応答取得→結果反映」の5ステップが基本。
• Power Automateでの自作は初期コストが低い反面、運用フェーズで技術的負債が蓄積しやすい構造的課題を抱える。
• 承認者が1〜2名で申請フォーマットもほぼ固定なら、自作でコストをかけずに運用できる。

実装の前提：Adaptive Cardsは何を担う部品か

Adaptive Cardsは承認ワークフローそのものではなく、承認者が見るUIを定義する部品です。実装では、このカードをPower Automateから投稿し、押されたボタンの結果を受け取って元データに書き戻す、という組み立てになります。

Teams標準の承認アプリも内部的にはAdaptive Cardsを使っていますが、こちらはGUIで完結する代わりにカードの構造をいじれません。自分でJSONを書くのは、標準アプリのカードでは足りないと分かってからで十分です。どの方式を採るかの比較はMicrosoft 365の承認ワークフロー｜Teams標準の限界を参照してください。

Adaptive Cards（アダプティブカード）とは何か｜Teamsでの役割

Adaptive Cardsは、JSON形式で記述したUI定義をTeamsのチャットやチャネル投稿内にカードとして描画するためのオープンな仕様です。ボタンや入力フィールド、テキストブロックをJSONで組み立てることで、承認・却下ボタン付きの通知カードをチャット上に直接表示できます。Power Automateの「Teamsに投稿してフロー応答を待機する」アクションなどから呼び出す形で利用するのが一般的です。

Power Automateで自作する方法の概要

Power AutomateはSharePointリストやForms、Excel Onlineなどをトリガーにして、Adaptive Cardsを自動生成・投稿するフローを組めます。トリガーとなるデータソースの更新を検知し、承認者宛にカードを送信、承認者がボタンを押すとその結果をSharePointリストや承認テーブルに書き戻す、という流れが基本形です。ライセンスはMicrosoft 365の標準プランに含まれるPower Automateの範囲で構築できるため、追加コストなしで始められる点が最大のメリットです。

JSONを自分で書くかどうかの分かれ目

標準の承認アプリはJSON編集が不要な代わりに、カードのレイアウトと承認ロジックを変えられません。申請項目をカード上に並べたい、金額に応じて表示を変えたい、承認と同時に追加入力を取りたい——こうした要件が出てきた時点で、Power AutomateからAdaptive Cardsを直接組む実装に移ることになります。

判断の目安は、カードに載せたい項目が標準アプリの枠に収まるかです。収まるならJSONを書く必要はありません。以降は、収まらなかった場合の実装手順を扱います。

Power AutomateとAdaptive Cardsでどう構築する？

承認フロー構築の基本は「トリガー設定→カード生成→投稿→応答取得→結果反映」という5ステップです。この流れを押さえれば、休暇申請や経費精算など多くの承認業務をテンプレート化できます。

フロー設計の基本ステップ（トリガー→カード作成→投稿→応答取得）

まずSharePointリストの「項目が作成されたとき」やFormsの「新しい応答が送信されたとき」をトリガーに設定します。次にAdaptive Card DesignerでJSONテンプレートを作成し、動的コンテンツ（申請者名、金額、日付など）を差し込みます。「Teamsに投稿してフロー応答を待機する」アクションで承認者にカードを送信し、応答結果をSharePointリストや承認履歴用のテーブルに書き戻して完了です。

承認・却下ボタンと動的コンテンツの設定方法

Adaptive CardsのActions.Submit要素に承認・却下それぞれのdataプロパティを設定し、Power Automate側で応答値を条件分岐（Switch）で振り分けます。申請金額や部署名といった動的コンテンツはFactSet要素にバインドし、SharePointの列名と一致させることで、テンプレートを使い回しながら複数の申請フォームに対応できます。

多段階承認・条件分岐（金額別・部署別ルート）の組み方

金額が一定額未満なら課長承認のみ、一定額以上なら課長→部長の2段階、といった条件分岐はCondition（Switch）アクションと承認者テーブル（SharePointリストで部署別・金額別の承認者を管理）を組み合わせて実現します。承認者が複数階層にわたる場合、Apply to eachで承認ステップをループさせる設計が一般的ですが、分岐が増えるほどフロー自体が肥大化しやすい点に注意が必要です。

自作すると何が課題になるのか？

Power Automateでの自作は初期コストが低い反面、運用フェーズで技術的負債が蓄積しやすいという構造的な課題を抱えています。理由は、JSON編集の属人化、Power Automate自体の仕様上の制限、内部統制機能の不足という3点に集約されます。

JSON編集・デザイン調整にかかる工数と属人化リスク

承認カードのレイアウト変更や項目追加のたびにJSONを直接編集する必要があり、担当者が異動・退職すると誰も触れなくなるケースが頻発します。申請フォームが部署ごとに増えるほど、個別にメンテナンスされたフローが乱立し、全体像を把握できる担当者がいなくなる属人化リスクが高まります。

承認フローのメッセージ更新期限・ゲスト承認者エラーなど既知の問題

Power Automateで「フロー応答を待機する」アクションを使う承認フローには、Adaptive Cardsを含むメッセージを更新できる期間に上限がある点に注意が必要です。承認者が長期不在で放置すると、期限切れでカードが無効化され、再送信が必要になります。また社外のゲストユーザーを承認者に設定する場合、招待状況によってカードが正しく表示されない、通知が届かないといった不具合が起こることもあります。

内部統制（監査ログ・承認履歴・権限管理）の観点での不足点

Power Automateの標準機能だけでは、誰がいつ何を承認したかという履歴を体系的に保存・検索する仕組みが用意されていません。SharePointリストに書き戻す設計にしても、改ざん防止や権限分離、監査証跡としての体裁を整えるには追加の設計と運用ルールが不可欠で、内部統制上の要件を満たすには相応の工数がかかります。

内製と専用アプリ、どちらを選ぶべきか？

複雑な稟議フローや内部統制要件がある企業には、Power Automate自作より専用アプリの導入が適しています。理由は、承認履歴の自動保存や多段階承認のノーコード設定など、自作では別途構築が必要な機能が標準搭載されているためです。

Power Automate自作と1Approval for Teamsの機能比較

Power Automate自作はライセンス費用こそかからないものの、JSON編集・メッセージ更新期限への対応・履歴管理をすべて自前で設計する必要があります。これに対し、1Approval for Teamsは、kintoneやMicrosoft 365にすでに構築されている承認基盤の上に、AIによる申請内容の自動判別・入力補完を重ね、Teamsのチャット画面上でワンクリック承認できるようにする拡張レイヤーです。kintoneやMicrosoft 365自体の承認ワークフロー機能を置き換えるものではなく、既存の仕組みを保ったままTeams上での承認体験とAI補完を追加できる点が、ゼロから作り込むPower Automate自作との大きな違いといえます。

さらに経費精算の申請フローと連携させれば、従業員が個人のカードや現金でいったん立て替えて後日精算する、という運用そのものをなくし、法人決済に一本化できる点も見逃せません。立替精算がなくなれば、承認者が「本当にこの支出は妥当か」を判断する承認フロー本来の役割に集中しやすくなります。

ノーコードでテンプレート化できる申請フォーム（稟議・経費・休暇届）

稟議書・経費精算・休暇届といった申請フォームは、GUI上でフィールドを追加・並べ替えするだけでテンプレート化でき、JSON編集は不要です。部署ごとに異なるフォーマットが必要な場合も、既存テンプレートを複製して項目を調整するだけで展開できます。

実際の画面や設定項目を具体的に確認したい場合は、1Approval for Teamsの詳細を見ると、自社のkintone・Microsoft 365環境にどう重ねられるかがイメージしやすくなります。

情シスの保守負担を減らしながら現場主導で運用できる仕組み

承認ルートの変更や新しい申請フォームの追加を総務・経理部門側で完結できるため、情シス担当者がフロー保守に張り付く必要がなくなります。情シスはアクセス権限やセキュリティ設定など基盤側の管理に専念できる体制を構築できます。加えて、複数サービス・複数取引先にまたがる利用料を月1回の法人一括請求にまとめられる仕組みと組み合わせれば、経理部門も個々の立替経費や請求書を突き合わせる作業から解放され、申請〜承認〜精算という一連の流れ全体の負担を減らせます。

よくある質問（FAQ）

Teamsの承認アプリとPower Automateのアダプティブカードは何が違いますか？

Teams標準の承認アプリはGUI操作で完結する反面、カードのレイアウトや承認ロジックのカスタマイズ性が限定的です。一方、Power Automateで直接Adaptive Cardsを組む方法はJSON編集による自由度の高さが特徴ですが、その分保守の手間がかかります。

Adaptive Cardsで作った承認フローはなぜ止まってしまう（失敗する）のですか？

主な原因は、メッセージを更新できる期間に上限があることです。承認者が長期間対応しないまま期限を過ぎると、カードが無効化されフローがエラー終了します。承認者不在時のリマインド設計や、期限切れ時の再送処理を組み込むことで一定程度は回避できます。

Teamsで多段階の承認フロー（部長→役員など）は無料の範囲で作れますか？

はい、Power Automateの標準ライセンス内でCondition分岐とApply to eachを組み合わせれば多段階承認は構築可能です。ただし分岐やループが増えるほどフローの複雑さと保守負担が増すため、承認段階が3段階以上になる場合は専用アプリの利用も検討する価値があります。

プログラミング知識がなくてもTeamsの承認ワークフローは構築できますか？

はい、Teams標準の承認アプリや1Approval for Teamsのような専用アプリを使えば、JSON編集なしでGUI操作のみで承認フローを構築できます。Power Automateで自作する場合はJSON知識がある程度必要になるため、非エンジニアが主導する場合は専用アプリの方が導入しやすいでしょう。

自社の運用イメージを具体的に固めたい方は、1Approval for Teamsの詳細を見ることで、既存のkintone・Microsoft 365環境にどこまでAI補完やワンクリック承認を重ねられるかを確認できます。

まとめ：自社に合ったTeams承認ワークフローの選び方

小規模・単純な承認フローならPower Automate自作で十分なケース

承認者が1〜2名で申請フォーマットもほぼ固定されているなら、Power Automateでの自作でコストをかけずに運用できます。まずは小さく試して自社の要件を把握するのが現実的です。

複雑な稟議・内部統制が必要なら専用アプリ（1Approval for Teams）が有効なケース

多段階承認や部署横断の稟議、監査対応が必要な場合は、履歴管理や権限設定が標準装備された専用アプリの方が結果的に運用コストを抑えられます。

まずは小さく試して自社業務にフィットするか検証する方法

いきなり全社導入するのではなく、まず一部署・一業務（例えば経費精算）に限定して試験導入し、現場の使い勝手と情シスの保守負担の両面から効果を検証することをおすすめします。導入条件や試験導入の進め方については、1Approval for Teamsの詳細を見るから個別に相談できます。