Power PagesのServer Logicからフローを呼び出す――「呼び出し成功」と「業務完了」を分ける設計

外部向けポータルで申請を受け付け、その後に社内承認や別システムへの登録を進める。このような業務では、画面に「成功」と表示するタイミングが意外に難しくなります。

申請データを受け取れたら成功なのか。承認依頼を送れたら成功なのか。それとも、連携先への登録まで終わって初めて成功なのか。

Microsoftは2026年9月18日、Power PagesのServer LogicからPower Automateのクラウドフローを呼び出す機能拡張を発表しました。サイト側の処理から既存の自動化につなげられる点が特徴です。公式発表

この更新を導入設計につなげるうえで、最も重要なのは「呼び出せるか」だけではありません。呼び出した後に何が起き、どの時点を業務完了とするかを決めることです。

1. 新しくなったのは、フローを呼び出す場所

今回の拡張では、Server Logicから Server.Connector.CloudFlow.TriggerAsync を使ってクラウドフローを呼び出します。

Microsoft Learnによれば、これはWebページから呼ぶ既存のCloud Flow APIに対応するサーバー側の呼び出し方法です。基盤となるパイプライン、設定、認可、ペイロードの扱いは共通で、変わるのは呼び出し元の実行コンテキストです。Server objects：CloudFlow

つまり、「Power Pagesからフローを呼べること」そのものが今回初めて登場したわけではありません。サイトのサーバー側処理にフロー呼び出しを組み込める点が、今回の変更です。

なお、9月18日の公式発表には、この拡張についてGA／Previewを明示する記述がありません。本稿では「機能拡張が発表され、利用方法が文書化されている」と整理し、正式提供済みと断定しません。採用時には対象環境での利用可否とサポート条件を別途確認する必要があります。

2. サーバー側から呼んでも、権限設定は省略できない

呼び出し元をサーバー側に移せば、既存のフローを無条件に実行できるわけではありません。

公式ドキュメントでは、次の前提が示されています。

• フローを作成し、Power Pagesの対象サイトに追加する。
• 許可するWebロールを設定する。
• サインインしたユーザーが、その許可されたロールのいずれかを持つ。
• 別環境へサイトを移す場合は、移行先でもフローを登録する。

また、呼び出しは非同期メソッドであり、呼び出し元の関数を async にし、await を使います。設定・認可・呼び出し方法

ここから先は、これらの仕様を踏まえた設計上の提案です。

移送テストでは、管理者が呼び出せたことだけで完了にしないほうがよいでしょう。業務で利用するWebロールを持つテストユーザーで、許可された操作が成功し、許可されない操作が拒否されることまで確認します。

また、サイトからフローを起動できる権限と、フローが接続先で実行する操作の権限は、別の確認項目として扱います。「誰が開始できるか」と「開始後に何を実行させるか」を分けてレビューするためです。

3. 202 Acceptedを「処理完了」と表示しない

今回のドキュメントで、特に見落としたくない仕様があります。

フローに応答アクションがない場合、呼び出し結果は 202 Accepted、本文は空となり、Server Logic側では IsSuccessStatusCode: true として扱われます。 応答の仕様

したがって、この成功フラグだけを見て、画面に「承認完了」「外部システムへの登録完了」と表示する設計は適切ではありません。呼び出しが受け付けられたことと、その後の業務処理が完了したことは別だからです。

また、await を付ければ、後続の業務全体が完了するまで必ず待ってくれる、という理解も避けるべきです。ここで待つのは呼び出しの応答であり、その応答が業務上どの段階を表すかは、フローとアプリケーション側の設計によります。

例えば、以下のように状態と画面表示を対応させます。これは製品が自動提供する状態モデルではなく、アプリケーションの設計例です。

HTTPステータスをそのまま業務状態へ置き換えるのではなく、業務のどの証拠をもって状態を進めるかを決めます。

4. 再実行を設計しないと、復旧操作が重複処理になる

次に考えたいのは、利用者が結果を確認できなかった場合です。

例えば、申請後に画面がタイムアウトし、利用者がもう一度ボタンを押したとします。最初の処理が既に進んでいた場合、二度目の操作で同じ申請や通知を重複作成する可能性があります。

これは特定の新機能に不具合があるという話ではなく、外部連携を含む処理で設計しておきたい失敗ケースです。

対策として、次の方針を提案します。

• 同じ申請を識別する受付番号やリクエストIDを設ける。
• 再送時に既存の受付結果を確認し、重複して処理しないルールを決める。
• どこまで完了したかを記録し、失敗した段階から再開できるか検討する。
• 再実行の担当者と、再実行してよい条件を決める。

単にIDを付けるだけでは重複防止になりません。同時に同じ要求が来た場合も含め、そのIDを使って重複を検出・制御する実装が必要です。

受付後の失敗をすべて「もう一度最初から実行してください」で済ませず、処理状況を確認してから復旧できるようにしておくことが重要です。

5. 小さな検証でも、正常系以外を先に決める

この機能を試すなら、まず一つの申請と一つのフローに絞るのがよいと考えます。ただし、評価項目まで正常系だけに絞る必要はありません。

最低限、次を確認したいところです。

1. 許可されたユーザーがフローを呼び出せるか。
2. 許可されていないユーザーの操作が拒否されるか。
3. 応答アクションがない場合に「受付」と「完了」を取り違えないか。
4. 連続クリックや再送で、業務データが重複しないか。
5. 後続処理が失敗したとき、受付番号から調査できるか。
6. 別環境でも、サイトへのフロー登録と権限設定を含めて再現できるか。

特に3番は、技術検証と業務確認をつなぐ項目です。画面の文言、通知のタイミング、問い合わせ時の案内まで合わせて確認すると、「APIは成功したが、利用者には処理状況が分からない」という状態を防ぎやすくなります。

まとめ：連携の入口より、完了条件を設計する

Server Logicからクラウドフローを呼び出す機能は、Power Pagesのサーバー側処理とPower Automateの自動化をつなぐ選択肢を広げます。

ただし、連携が容易になるほど、呼び出しの成功だけで設計を完了したくなります。

実装前に決めたいのは、何を受け付け、どこまで処理できたら完了とし、失敗したら誰がどう復旧するかです。

「フローを呼べた」から一歩進めて、「利用者にも運用担当者にも処理状況が分かる」連携を作る。 今回の更新は、その設計を考えるよいきっかけになるはずです。

参考情報・日付の確認

情報確認日：2026年9月26日。以下は、送審日から遡る1年間（2025年9月26日～2026年9月26日）に公開、または引用箇所に関係する更新を確認した一次資料です。

1. Extend Server Logic with Power Automate Cloud Flows in Power Pages
2. 発行：Microsoft Power Platform Blog／Nagesh Bhat。
3. 公開日：2026年9月18日。記事の日付表示、公開日時メタデータ、公式RSSで確認。
4. 参照内容：Server Logicからのクラウドフロー呼び出しの発表、既存自動化の再利用。

5. 機能状態：当該発表にGA／Previewの明記なし。本稿ではGAと断定していません。

6. Server objects — CloudFlow

7. 発行：Microsoft Learn。
8. ページ表示の最終更新日：2026年9月16日。文書の日付メタデータは2026年9月15日。
9. 引用に関係する更新：CloudFlow節にTriggerAsync、Webロール、移行先での登録、202応答の仕様を掲載。9月18日の公式発表がこの文書へ直接リンクし、今回の拡張に対応する利用方法として案内していることを確認。
10. 参照内容：呼び出しコンテキスト、前提条件、非同期呼び出し、応答仕様。
11. 初版公開日は未確認のため、上記を初版公開日とは扱っていません。