【Power Automate】HTTP要求トリガーが想定どおり進まない時の入力値と条件分岐の直し方

Power AutomateのHTTP要求トリガーは、外部システムからのWebhookやAPI呼び出しを受けてフローを起動する強力な機能です。しかし、設定したはずの条件分岐が意図しない結果になったり、トリガー自体が発動しなかったりするトラブルは少なくありません。特に、入力値の型やJSON構造が想定と異なる場合、フローが正常に進まない原因になります。この記事では、HTTP要求トリガーが想定どおりに進まない原因を具体的に切り分け、入力値の確認方法と条件分岐の修正手順を解説します。

1. HTTP要求トリガーの基本と失敗しやすいポイント

トリガーの仕組みと設定項目

HTTP要求トリガーは、他のアプリケーションからHTTPリクエストを受け取った瞬間にフローを開始します。トリガーの設定画面では、以下の項目を指定します。

• HTTPメソッド: GET、POST、PUT、DELETEなど、期待するメソッドを選択します。実際に送られてくるメソッドと異なる場合、トリガーは反応しません。
• 要求本文JSONスキーマ: 受け取るJSONの構造を定義します。このスキーマが実際のデータと一致しないと、トリガー後のアクションでプロパティにアクセスできず、エラーになります。
• 認証: 基本的には「なし」で動作しますが、Azure ADやAPIキーが必要な場合は適切に設定する必要があります。

多くのトラブルは、送信元のアプリケーションが期待するフォーマットでデータを送っていない、またはスキーマ定義が厳格すぎるために発生します。

2. 想定通り進まない主な原因と切り分け方法

入力値の型や形式の不一致

最も多い原因は、トリガーで定義したJSONスキーマと実際に受信したJSONペイロードの間に型やプロパティ名のズレがあることです。例えば、スキーマで “age”: “integer” と定義しているのに、送信側が文字列 “25” を送ってくると、アクションの中で age を数値として使おうとするとエラーになります。また、配列なのか単一オブジェクトなのかの違いも混乱を招きます。

条件分岐のロジックの誤り

条件アクション(Condition)でプロパティを比較する際、演算子の選択や値の指定が適切でないケースです。たとえば、「次を含む」演算子を使うべきところを「等しい」にしてしまったり、大文字小文字の区別を意識せずに「東京」と「とうきょう」を比較したりします。また、nullや空文字列の扱いも注意が必要です。

タイミングや順序の問題

HTTP要求トリガーは同期的に動作し、レスポンスをすぐに返すことができますが、フロー内で時間のかかる処理があると、呼び出し元がタイムアウトする可能性があります。また、トリガーが複数回呼ばれる場合、フローの実行が重複しないように制御する必要があります。

3. 具体的な修正手順

以下の手順で、問題を特定し修正します。

1. 手順1: 実際のHTTPリクエスト内容を確認する
   フローが動作しない場合、まず送信元からどんなJSONが送られているか確認します。PostmanやcURLを使って手動でリクエストを送り、フローの「実行履歴」で生のペイロードを取得できます。実行履歴の「入力」タブを見ると、ボディが記録されています。
2. 手順2: スキーマを自動生成し直す
   Power AutomateのHTTPトリガー編集画面で「ペイロードからスキーマを生成」ボタンを使い、実際に受信したJSONのサンプルを貼り付けてスキーマを再作成します。これにより、プロパティ名や型が完全に一致するスキーマになります。
3. 手順3: 条件分岐内で明示的に型変換する
   数値を比較する場合、int() 関数や string() 関数を使って型を揃えます。例えば、@int(triggerBody()?[‘age’]) のように数値に変換してから比較します。
4. 手順4: 条件式をシンプルにしてテストする
   複雑な条件は一時的に単純な「true」や「false」に置き換え、フローが最後まで実行できるかを確認します。その後、条件を一つずつ追加して問題を切り分けます。
5. 手順5: スコープアクションを使ってエラーハンドリングを追加する
   条件分岐の前に「Try-Catch」のようなスコープを設け、例外が発生した場合に代替処理を実行することで、フローが中断されるのを防ぎます。
6. 手順6: 管理者に確認が必要な設定を洗い出す
   会社のポリシーでカスタムコネクタが禁止されていたり、HTTPトリガーのエンドポイントが特定のIPからのみ許可されている場合があります。IT管理者に問い合わせ、制限事項を確認します。

4. 失敗パターンとその対処法

下表に、よくある失敗パターンと修正方法をまとめます。

失敗パターン	原因	修正方法
トリガーが発動しない	HTTPメソッドが不一致、またはエンドポイントURLが間違っている	送信元のメソッドを確認し、トリガーの設定に合わせる。URL末尾の / の有無にも注意
アクションで「未定義の変数」エラー	JSONパスが間違っている、またはスキーマにないプロパティを参照している	triggerBody()?[‘prop’] のように安全なアクセス(? 演算子)を使う。スキーマを再生成
条件が常にFalseになる	比較する値の型が異なる(数値 vs 文字列)	int() または string() で型を合わせる
条件が大文字小文字で誤判定	Power Automateの条件はデフォルトで大文字小文字を区別しないが、一部の比較で区別される場合あり	toLower() 関数で統一してから比較する

5. 管理者に確認すべき設定

会社の環境によっては、以下のような制限がかかっている場合があります。IT管理者に確認をお願いしてください。

• カスタムコネクタの利用制限: HTTP要求トリガーは標準で使えますが、カスタムコネクタが必要な高度な認証や変換は制限されている可能性があります。
• エンドポイントのIP制限: 一部の企業では、外部からのHTTPリクエストを特定のIPアドレスからのみ許可するファイアウォールルールが設定されています。Azureの送信IPリストを確認してください。
• データ損失防止(DLP)ポリシー: HTTPトリガーはコネクタとみなされ、DLPポリシーでブロックされている場合があります。管理者にポリシーの詳細を問い合わせてください。

6. よくある質問

Q1: HTTP要求トリガーのURLは変わることはありますか?

フローを保存するたびに、エンドポイントURLの一部が変わることがあります。特に、フローをコピーして別の環境にインポートすると、新しいURLが生成されます。よって、URLは固定せず、フロー保存後に必ず最新のURLを送信元に設定し直してください。

Q2: 条件分岐でJSONの配列をループ処理したい場合の注意点は?

「Apply to each」アクションを使います。その前に、配列が確かに配列であることを確認してください。もし単一オブジェクトしか期待していないと、Apply to eachがエラーになります。スキーマで配列と定義し、かつ実際のデータが配列になっているかを検証します。

Q3: HTTP要求トリガーは同期?非同期?

HTTP要求トリガーは同期的に動作し、フロー内で「応答」アクションを使えば、呼び出し元にすぐにレスポンスを返すことができます。ただし、フロー全体がタイムアウト(通常2分)する前に応答を返す必要があります。長時間の処理が必要な場合は、最初に「202 Accepted」を返すなど、パターンを工夫してください。

7. まとめ

HTTP要求トリガーが想定通り進まない原因は、多くが入力値の型不一致や条件分岐のロジックミスに集約されます。最初に実際のリクエストペイロードを確認し、スキーマを再生成することが最も効果的な対策です。また、条件分岐では型変換や演算子の選択を慎重に行い、エラーハンドリングを組み込むことで安定したフローを維持できます。管理者の設定により制限がある場合は、事前に確認しておきましょう。これらのポイントを押さえることで、トラブルシューティングの時間を大幅に短縮できるはずです。