Power AppsからPower Automateを呼ぶ｜連携の実装と「権限を借りる」設計
Power AppsとPower Automateは、組み合わせて使うのが実務の基本形です。ただし「どちらを使うか」の話は多くても、実際にどう繋ぐかを扱った情報は多くありません。
この記事では、アプリからフローを呼び出す具体的な方法と、組み合わせることで初めて可能になる「権限の設計」を解説します。これは単なる機能の足し算ではなく、アプリ単体では実現できないことを可能にする使い方です。
なぜ組み合わせるのか｜3つの理由
| 理由 | アプリ単体では | フローを使うと |
|---|---|---|
| 処理を任せられる | 画面が固まる、時間のかかる処理が苦手 | 裏で実行し、アプリは待たない |
| できることが増える | メール送信や承認は組み込みにくい | 承認フロー、通知、外部連携が使える |
| 権限を分離できる | 使う人の権限がそのまま必要 | フロー側の権限で実行できる |
3つ目が最も重要で、しかも知られていません。後半で詳しく説明します。
繋ぎ方｜3ステップ
ステップ1｜フロー側でトリガーを選ぶ
Power Automateで新しいフローを作り、トリガーに「Power Apps（V2）」を選びます。
V2トリガーでは受け取る値（パラメータ）を事前に定義できます。名前と型（テキスト・数値・日付など）、必須か任意かを指定します。
これがV1との大きな違いです。V1では順番だけで値を受け渡していたため、後から変更すると崩れやすい構造でした。V2なら名前と型が明示されるため、扱いやすくなっています。
ステップ2｜アプリからフローを呼び出す
Power Apps側でフローを追加し、ボタンのOnSelectなどから実行します。定義したパラメータに、アプリ側の値を渡します。
ここで1つ制約があります。アプリに追加できるのは自分が所有者、または共有されているフローです。他人が作ったフローを勝手に呼び出すことはできません。
ステップ3｜必要なら結果を受け取る
フローの処理結果をアプリに返したい場合、フローの最後に「Power Appsに応答する」アクションを追加します。返す値の名前と中身を定義すると、アプリ側で受け取れます。
返す必要がなければ、このアクションは不要です。「メールを送るだけ」のような処理なら、投げっぱなしで構いません。むしろ結果を待たないほうがアプリの操作感は良くなります。
核心｜「権限を借りる」という設計
ここが組み合わせの最大の価値です。Power Apps V2トリガーでは、フローをどの権限で実行するかを選べます。
| 埋め込み接続 | 呼び出し元接続 | |
|---|---|---|
| 誰の権限で動くか | フローに設定された接続の権限 | アプリを使っている人の権限 |
| 使う人に権限は必要か | 不要 | 必要 |
| 向いている場面 | 直接の権限を渡したくない場合 | 各自の権限で操作させたい場合 |
これが解決する実務の悩み
次のような状況を考えてください。
- SharePointリストに申請データを書き込むアプリを作りたい
- しかし一般社員にリストの編集権限を与えたくない——直接開いて他人のデータを書き換えられては困る
アプリから直接SharePointに書き込む構成では、使う人全員にリストの編集権限が必要です。これでは元の懸念が消えません。
フロー経由にすれば、この問題が解けます。アプリはフローを呼ぶだけ。実際の書き込みは、フローに設定された接続の権限で行われます。使う人はリストへの権限を持っていなくても、アプリからは登録できます。
これはアクセス制限の記事で述べた「アプリ内で隠してもデータは守れない」という問題への、正面からの解決策になります。そもそも権限を渡さないという設計です。
ただし責任も移る
権限を借りるということは、チェックの責任がアプリ側に移るということです。
フローは「呼ばれたら実行する」だけで、誰が何のために呼んだかを判断しません。不正な値が渡されても、そのまま書き込みます。
したがって次の対策が必要になります。
- アプリ側で入力値を検証する
- フロー側でも条件を確認する——想定外の値なら処理を中断する
- 誰が実行したかを記録する——操作者の情報をフローに渡し、ログとして残す
「権限がないから安全」ではなくなる点は理解しておく必要があります。
実務でよくある組み合わせ
| やりたいこと | アプリ側 | フロー側 |
|---|---|---|
| 申請と承認 | 入力画面、申請ボタン | 承認依頼、承認後の処理 |
| 登録後の通知 | データ登録 | Teams通知、メール送信 |
| 権限のない場所への書き込み | 入力と検証 | 埋め込み接続で書き込み |
| 時間のかかる処理 | 実行ボタンのみ | 一括処理、外部連携 |
| 定期実行 | （不要） | スケジュール実行 |
分担の原則はシンプルです。人が触る部分はアプリ、裏で動く処理はフロー。迷ったら「画面が必要か」で判断できます（詳細はどちらを使うかの判断）。
注意点
①結果を待つとアプリが止まる
「Power Appsに応答する」で結果を受け取る構成にすると、アプリはフローの完了を待ちます。処理が長ければ、その間ユーザーは待たされます。
結果が不要なら、応答アクションを入れないほうが快適です。「受け付けました」とだけ表示して、実際の処理は裏で進める——この設計が有効な場面は多くあります。
②フローが失敗してもアプリは気づかない
投げっぱなしにした場合、フローが失敗してもアプリ側は成功したように見えます。しかもエラー通知は当てにならない（一般的なエラーではメールが来ず、28日間のクールダウンもある）という問題があります。
重要な処理なら、フロー内に失敗時の通知を組み込んでおくべきです。
③ライセンスの扱いを確認する
Power Appsのライセンスに、そのアプリ内で動くフローの実行権が含まれる場合があります。ただしプレミアムコネクタを使う場合は別途ライセンスが必要です。組み合わせる前に、使うコネクタを確認してください。
④トリガーの変更は影響が出る
公式に既知の問題として記載されています。V1トリガーをV2に更新すると、フローが接続エラーで中断する場合があります。回避策は、更新後にアプリ側でフローを削除して追加し直し、保存することです。
接続の種類を変更した場合も同様の対応が必要になります。「フロー側だけ直せば済む」とは限らない点に注意してください。
よくある質問
Q. フローを呼ぶとアプリが遅くなりませんか？
結果を待つかどうかで変わります。「Power Appsに応答する」を使うと完了まで待ちますが、使わなければ待ちません。時間のかかる処理こそフローに任せ、結果を待たない設計にすると快適になります。
Q. 他人が作ったフローをアプリで使えますか？
自分が所有者か、共有されているフローに限られます。フロー内で使う接続の権限も関わるため、フローを作った人が追加するのが確実です。
Q. 権限のないデータに書き込めるのは危険ではないですか？
正しく設計すれば、むしろ安全になります。直接権限を渡すより、アプリという限定された入口だけを開けるほうが制御しやすいからです。ただしアプリとフローの両方で入力値を検証する必要があります。
Q. V1とV2のトリガーはどちらを使うべきですか？
新規ならV2です。パラメータの名前と型を定義でき、後から変更しても壊れにくくなっています。既存のV1から変更する場合は、アプリ側でフローを追加し直す必要があります。
Q. フローの実行結果をアプリに表示できますか？
できます。「Power Appsに応答する」で値を返し、アプリ側で受け取ります。ただし戻り値を使うと完了を待つため、本当に必要かを検討してください。
まとめ
- 繋ぎ方は①V2トリガーでパラメータを定義 ②アプリから呼び出す ③必要なら応答アクションで返す
- 最大の価値は権限の分離——埋め込み接続なら、使う人に権限がなくても処理できる
- 「編集権限は渡したくないが、アプリからは登録させたい」という実務の矛盾を解決する
- ただしチェックの責任はアプリ側に移る。入力値の検証と実行者の記録が必要
- 結果を待たない設計のほうが操作感は良い。ただし失敗に気づけないため通知の作り込みが要る
- アプリに追加できるのは自分が所有者か共有されたフローのみ
参考・出典
- Power Apps V2 トリガーに関する既知の問題（Microsoft Learn）――埋め込み接続と呼び出し元接続、V1からV2への更新時の注意
- キャンバス アプリでのフローの使用（Microsoft Learn）
