Power Automate Flowで処理を簡易的にHTTP API化する
X-tech推進本部 黒澤業務の自動化でPower Automate Flowを利用していると、社内ツールなどからクラウドフローを実行したい場面があります。
そのような場合、クラウドフローを簡易的にHTTP API化すると、簡単に呼び出せます。なお、この記事ではHTTP APIを次のような意味で利用しています。
- HTTPリクエストで処理を起動
- リクエストボディのJSONやURLのパスパラメーターを入力として扱う
- 処理結果をHTTPレスポンスとして返す
簡易HTTP API化方法
結論から述べると、クラウドフローを次のように構成することで、簡易なHTTP APIにできます。
- トリガーに「HTTP 要求の受信時(When an HTTP request is received)」を設定
- 自動化したい処理の組み立て(通常通り)
- 処理結果を「応答(Respond)」アクションに設定
「HTTP 要求の受信時」トリガー
「要求」コネクタの「HTTP 要求の受信時」トリガーは、HTTPリクエストを受け取るURLの生成と、入力値の簡単な検証を行います。

HTTPリクエストを受け取るURL(「HTTP URL」設定)はクラウドフロー保存時に自動生成されます。クラウドフローの制作側ではURLを変更できないため、URLが知られてしまうと、第三者からもリクエストされる可能性があります。トリガーの「フローをトリガーできるユーザー」設定で「誰でも」を選択している場合は、クラウドフローの後続処理で、リクエストが意図したものであるかどうか、確認する処理を追加することが望ましいです。後述する入力以外にもHTTPヘッダーやURLクエリパラメーターから値を取り出して、期待した内容であるか検証できます。
入力はレスポンスボディのJSONやURLのパスパラメーターなどから取り出すことができます。
JSONから取り出す場合、トリガー設定の「要求本文の JSON スキーマ」にJSONスキーマを設定することで、簡単な入力値チェックができます。リクエストボディのJSONがスキーマに一致しない場合、クラウドフローがHTTPの400ステータスを返し、後続の処理は実行されません。
なお、JSONスキーマで指定したプロパティ名やタイトル(title)や説明(description)はクラウドフローの編集画面でも確認できます。

パスパラメーターから取り出す場合、トリガー設定の「相対パス」に/path1/{value1}/path2/{value2}のような形式を入力します。すると、トリガー設定に表示されているリクエストURLのパス末尾に/path1/{value1}/path2/{value2}が追加されます。

{value1}や{value2}を具体的な値で置き換えたURLをリクエストすると、クラウドフローの後続の処理で「ヘッダー value1」や「ヘッダー value2」として値を取り出せます。

「応答」アクション
処理結果が得られたら(あるいは得られなかったら)、「要求」コネクタの「応答(Respond)」アクションでHTTPレスポンスを返します。
アクションの設定でHTTPステータスを指定できますので、処理成功時と失敗時で異なるレスポンスを返すことができます。例えば、アクションが「成功」した場合はHTTPの200ステータスを返す「応答」アクション、「失敗」した場合は500ステータスを返す「応答」アクションが実行されるように処理を分岐させることができます。

レスポンスボディにはJSONを指定することがほとんだと思いますが、JSON以外も可能です。アクションの設定でHTTPヘッダーを指定できるため、Content-Typeにtext/markdownを指定して、Markdownを返すこともできます。

メリット・デメリット
クラウドフローの簡易HTTP API化にはメリット・デメリットがあります。
メリットは、クラウドフローで作成済の処理や作成しやすい処理を、そのままHTTPで呼び出せることです。クラウドフローはMicrosoft 365関連の簡単な処理はすぐに自動化できます。実現方法が明確であれば、数十分で動くHTTP APIをデプロイできます。
デメリットは簡易な仕組みのため、複雑な要件や運用には向いていないことです。
リクエストURLはクラウドフローが自動的に生成した非常に長いものが使われます。URLを255文字以下に抑えたり、人にとって分かりやすいものにしたりするようなカスタマイズは困難です。一方で、Microsoftは、猶予期間は設けたうえでリクエストURLを変更したことがあります。今後もリクエストURLが変更される可能性はあると私は考えています。大量のHTTP APIを作って、手を入れることなく長く運用したいのであれば、クラウドフロー以外を利用したほうが良いでしょう。
また、処理時間(HTTPレスポンスが返ってくるまでの時間)のばらつきも大きいと感じています。クラウドフロー自体の制限や呼び出すサービスの制限などによって、同じ処理でも処理時間が異なることがあります。私はHTTP APIを呼び出す側でタイムアウトを長めに設定して対処することが多いです。応答時間やそのばらつきが気になる場合もクラウドフロー以外を利用したほうが良いと考えています。
まとめ
クラウドフローの簡易HTTP化は、本格的なAPIを作るほどではない、簡易な処理をHTTPで呼び出すのに向いています。