Azure Logic Apps のワークフローに送信された受信 HTTPS 呼び出しを受信して応答する

2025-07-23

適用対象: Azure Logic Apps (従量課金 + Standard)

このガイドでは、組み込みトリガー要求を使用して、別のサービスからの受信したHTTPS要求を処理できるロジックアプリのワークフローを作成する方法を説明します。ワークフローでこのトリガーを使用する場合、ワークフローは応答組み込みアクションを使用して HTTPS 呼び出しに応答できます。

注

応答アクションは、要求トリガーを使用する場合にのみ機能します。

たとえば、要求トリガーと応答アクションを使用すると、ワークフローで次のタスクを実行できます。

オンプレミスデータベース内のデータに対する HTTPS 要求を受信して応答する。
別のロジックアプリワークフローから送信された HTTPS 要求を受信して応答します。
外部 Webhook イベントが発生したときにワークフローの実行をトリガーする。

代わりに送信要求を送信してワークフローを実行するには、HTTP 組み込みトリガーまたは HTTP 組み込みアクションを使用します。

前提条件

Azure アカウントとサブスクリプション。サブスクリプションがない場合は、無料の Azure アカウントにサインアップできます。

受信 HTTPS 要求を受け取るワークフローを含むロジックアプリリソース。

要求トリガーを使用してワークフローを開始するには、空のワークフローが必要です。応答アクションを使用するには、ワークフローを要求トリガーで開始する必要があります。

ロジックアプリのリソースとワークフローがない場合は、必要なロジックアプリの手順に従って、今すぐ作成します。
- 従量課金ロジックアプリワークフローを作成する
- 標準ロジックアプリワークフローの例を作成する

HTTP 要求を送信してソリューションをテストできるツールをインストールまたは使用します。次に例を示します。
- Visual Studio Code を Visual Studio Marketplace からの拡張機能と一緒に使用する
- PowerShell Invoke-RestMethod
- Microsoft Edge - ネットワークコンソールツール
- ブルーノ
- curl
注意

資格情報、シークレット、アクセストークン、API キーなどの機密データがあるシナリオでは、必要なセキュリティ機能でデータを保護するツールを必ず使用してください。このツールはオフラインまたはローカルで動作する必要があり、オンラインアカウントへのサインインやクラウドへのデータの同期は必要ありません。これらの特性を持つツールを使用すると、機密データを一般に公開するリスクが軽減されます。

Request トリガーの追加

この Request トリガーは、HTTPS 経由の受信要求のみを処理する、手動で呼び出し可能なエンドポイントを作成します。呼び出し元がこのエンドポイントに要求を送信すると、Request トリガーが起動され、ワークフローが実行されます。このトリガーを呼び出す方法については、「 Azure Logic Apps で HTTPS エンドポイントを使用してワークフローを呼び出す、トリガーする、または入れ子にする」を参照してください。

従量課金プラン
標準

Azure portal で、従量課金ロジックアプリリソースを開きます。
サイドバーメニューの [開発ツール] でデザイナーを選択し、空のワークフローを開きます。
トリガーを追加する一般的な手順に従って、ワークフローに HTTP 要求を受信したときにという名前の要求組み込みトリガーを追加します。

トリガー情報ボックスが表示されたら、次の情報を入力します。

プロパティ名	JSON プロパティ名	必須	説明
HTTP URL	{なし}	はい	ワークフローを保存した後に生成され、ワークフローをトリガーする要求の送信に使用されるエンドポイント URL。
要求本文の JSON スキーマ	`schema`	いいえ	受信要求本文内のプロパティと値を記述する JSON スキーマ。デザイナーでは、このスキーマを使用して、要求内のプロパティ用のトークンが生成されます。このようにして、ワークフローは、Request トリガーからの出力を解析し、使用し、ワークフローに渡すことができます。 JSON スキーマがない場合は、[サンプルのペイロードを使用してスキーマを生成する] の機能を使用して、サンプルペイロードからスキーマを生成することができます。

次の例は、サンプル JSON スキーマを示しています。

次の例は、完全なサンプル JSON スキーマを示しています。

{
   "type": "object",
   "properties": {
      "account": {
         "type": "object",
         "properties": {
            "name": {
               "type": "string"
            },
            "ID": {
               "type": "string"
            },
            "address": {
               "type": "object",
               "properties": {
                  "number": {
                     "type": "string"
                  },
                  "street": {
                     "type": "string"
                  },
                  "city": {
                     "type": "string"
                  },
                  "state": {
                     "type": "string"
                  },
                  "country": {
                     "type": "string"
                  },
                  "postalCode": {
                     "type": "string"
                  }
               }
            }
         }
      }
   }
}

JSON スキーマを入力すると、デザイナーに、要求に Content-Type ヘッダーを含め、そのヘッダー値を application/json に設定するようにアラームが表示されることがあります。詳細については、コンテンツタイプの処理に関するページを参照してください。

次の例は、 Content-Type ヘッダーが JSON 形式でどのように表示されるかを示しています。

{
   "Content-Type": "application/json"
}

予想されるペイロード (データ) に基づく JSON スキーマを生成するには、 json-schema.org などのツールを使用するか、次の手順に従います。

[要求] トリガーで、[サンプルのペイロードを使用してスキーマを生成する] を選択します。

サンプルペイロードを入力して、[完了] を選択します。

次の例は、サンプルペイロードを示しています。

{
   "account": {
      "name": "Contoso",
      "ID": "12345",
      "address": {
         "number": "1234",
         "street": "Anywhere Street",
         "city": "AnyTown",
         "state": "AnyState",
         "country": "USA",
         "postalCode": "11111"
      }
   }
}

指定したスキーマに一致する要求本文が受信呼び出しに含まれることを確認するには、次の手順に従います。
1. スキーマで記述されているのとまったく同じフィールドを受信メッセージに強制するには、スキーマに required プロパティを追加し、必須フィールドを指定します。 additionalPropertiesプロパティを追加し、値を false に設定します。
  
  たとえば、次のスキーマでは、受信メッセージには msg フィールドが必要で、他のフィールドは必要ないことが指定されています。
```
{
   "properties": {
     "msg": {
        "type": "string"
     }
   },
   "type": "object",
   "required": ["msg"],
   "additionalProperties": false
}
```
2. デザイナーで「要求トリガー」を選択してください。情報ペインが開いたら、[設定] タブを選択します。
3. [Data Handling] を展開して、[スキーマの検証] を [オン] に設定します。
  
  受信呼び出しの要求本文がスキーマと一致しない場合、トリガーからは HTTP 400 Bad Request エラーが返されます。
[メソッド] ボックスの一覧から、トリガーが受信要求で使用するメソッドを選択します。
トリガーに他のパラメーターが存在する場合は、[ 詳細パラメーター ] ボックスの一覧を開き、目的のパラメーターを選択します。
準備が整ったら、ワークフローを保存します。デザイナーのツールバーで、[保存] を選択します。

この手順により、ワークフローをトリガーする要求を送信するために使用する URL が生成されます。
生成された URL をコピーするには、URL の横にあるコピーアイコンを選択します。

注

Request トリガーを呼び出すとき、ハッシュまたはシャープ記号 (#) を URI に含める場合は、エンコードされたバージョン %25%23 を代わりに使用します。

Azure portal で、Standard ロジックアプリリソースを開きます。
リソースサイドバーメニューの [ ワークフロー] で [ ワークフロー] を選択し、空のワークフローを選択します。
ワークフローサイドバーメニューの [ ツール] で、デザイナーを選択してワークフローを開きます。
トリガーを追加する一般的な手順に従って、ワークフローに HTTP 要求を受信したときにという名前の要求組み込みトリガーを追加します。

トリガー情報ボックスが表示されたら、次の情報を必要に応じて入力します。

プロパティ名	JSON プロパティ名	必須	説明
HTTP URL	{なし}	はい	ワークフローを保存した後に生成され、ワークフローをトリガーする要求の送信に使用されるエンドポイント URL。
要求本文の JSON スキーマ	`schema`	いいえ	受信要求本文内のプロパティと値を記述する JSON スキーマ。デザイナーでは、このスキーマを使用して、要求内のプロパティ用のトークンが生成されます。このようにして、ワークフローは、Request トリガーからの出力を解析し、使用し、ワークフローに渡すことができます。 JSON スキーマがない場合は、[サンプルのペイロードを使用してスキーマを生成する] の機能を使用して、サンプルペイロードからスキーマを生成することができます。

次の例は、サンプル JSON スキーマを示しています。

次の例は、完全なサンプル JSON スキーマを示しています。

{
   "type": "object",
   "properties": {
      "account": {
         "type": "object",
         "properties": {
            "name": {
               "type": "string"
            },
            "ID": {
               "type": "string"
            },
            "address": {
               "type": "object",
               "properties": {
                  "number": {
                     "type": "string"
                  },
                  "street": {
                     "type": "string"
                  },
                  "city": {
                     "type": "string"
                  },
                  "state": {
                     "type": "string"
                  },
                  "country": {
                     "type": "string"
                  },
                  "postalCode": {
                     "type": "string"
                  }
               }
            }
         }
      }
   }
}

次の例は、 Content-Type ヘッダーが JSON 形式でどのように表示されるかを示しています。

{
   "Content-Type": "application/json"
}

予想されるペイロード (データ) に基づく JSON スキーマを生成するには、 json-schema.org などのツールを使用するか、次の手順に従います。

[要求] トリガーで、[サンプルのペイロードを使用してスキーマを生成する] を選択します。

サンプルペイロードを入力して、[完了] を選択します。

次の例は、サンプルペイロードを示しています。

{
   "account": {
      "name": "Contoso",
      "ID": "12345",
      "address": {
         "number": "1234",
         "street": "Anywhere Street",
         "city": "AnyTown",
         "state": "AnyState",
         "country": "USA",
         "postalCode": "11111"
      }
   }
}

指定したスキーマに一致する要求本文が受信呼び出しに含まれることを確認するには、次の手順に従います。
1. スキーマで記述されているのとまったく同じフィールドを受信メッセージに強制するには、スキーマに required プロパティを追加し、必須フィールドを指定します。 additionalPropertiesプロパティを追加し、値を false に設定します。
  
  たとえば、次のスキーマでは、受信メッセージには msg フィールドが必要で、他のフィールドは必要ないことが指定されています。
```
{
   "properties": {
     "msg": {
        "type": "string"
     }
   },
   "type": "object",
   "required": ["msg"],
   "additionalProperties": false
}
```
2. デザイナーで「要求トリガー」を選択します。情報ペインが開いたら、[設定] タブを選択します。
3. [Data Handling] を展開して、[スキーマの検証] を [オン] に設定します。
  
  受信呼び出しの要求本文がスキーマと一致しない場合、トリガーからは HTTP 400 Bad Request エラーが返されます。
[メソッド] ボックスの一覧から、トリガーが受信要求で使用するメソッドを選択します。
トリガーに他のパラメーターが存在する場合は、[ 詳細パラメーター ] ボックスの一覧を開き、目的のパラメーターを選択します。
トリガーに他のパラメーターが存在する場合は、[ 詳細パラメーター ] ボックスの一覧を開き、目的のパラメーターを選択します。
準備が整ったら、ワークフローを保存します。デザイナーのツールバーで、[保存] を選択します。

この手順により、ワークフローをトリガーする要求を送信するために使用する URL が生成されます。
生成された URL をコピーするには、URL の横にあるコピーアイコンを選択します。

注

要求トリガーの呼び出しを行うときに URI にハッシュ記号またはポンド記号 (#) を含める場合は、代わりに次のエンコードされたバージョンを使用します。 %25%23

要求トリガーの URL は、ワークフローのストレージアカウントに関連付けられています。この URL は、ストレージアカウントが変更されると変わります。たとえば、Standard ロジックアプリでは、ストレージアカウントを手動で変更し、ワークフローを新しいストレージアカウントにコピーすると、要求トリガーの URL も変更され、新しいストレージアカウントが反映されます。同じワークフローは異なる URL を持ちます。

ステートレスワークフローのスキーマの検証

ステートレスワークフローのスキーマの検証を有効にするには、ロジックアプリリソースまたはプロジェクトの host.json ファイル内に以下のホスト設定があることを確認します。

"extensions": {
   "workflow": {
      "Settings": {
         "Runtime.StatelessFlowEvaluateTriggerCondition": "true"
      }
   }
}

次に、次の手順として別のアクションを追加して、ワークフローの構築を続けましょう。たとえば、応答アクションを追加することによって、要求に応答することができます。応答アクションは、カスタマイズした応答を返す場合に使用できます。これについては、この記事の後半で説明します。

注

ワークフローは、受信要求を限られた時間だけ開いたままにします。ワークフローに応答アクションが含まれている場合、この時間が経過する前にワークフローから呼び出し元に応答が返されないと、ワークフローから呼び出し元に 504 GATEWAY TIMEOUT 状態が返されます。ワークフローに応答アクションが含まれていない場合、ワークフローから呼び出し元に、直ちに 202 ACCEPTED 状態が返されます。

トランスポート層セキュリティ (TLS)、Microsoft Entra ID を使用した OAuth、Shared Access Signature (SAS)、Azure API Management を使用したロジックアプリリソースの公開、受信呼び出しを開始する IP アドレスの制限など、ワークフローへの受信呼び出しのセキュリティ、認証、暗号化の詳細については、「要求ベースのトリガーへの受信呼び出しのアクセス」を参照してください。

トリガー出力

次の表に、要求トリガーからの出力を示します。

JSON プロパティ名	データ型	説明
`headers`	Object	要求のヘッダーを記述する JSON オブジェクト
`body`	Object	要求の本文のコンテンツを記述する JSON オブジェクト

Response アクションを追加する

要求トリガーを使用して受信要求を受信する場合は、応答をモデル化し、要求トリガーでのみ機能する応答組み込みアクションを使用してペイロードの結果を呼び出し元に返すことができます。要求トリガーと応答アクションとのこの組み合わせにより、要求と応答のパターンが作成されます。 For Each ループ、Until ループ、および並列分岐を除き、Response アクションをワークフロー内の任意の場所に追加できます。

重要

応答アクションに次のヘッダーが含まれている場合、Azure Logic Apps は、警告やエラーを表示せずに、生成された応答メッセージからこれらのヘッダーを自動的に削除します。 Azure Logic Apps にはこれらのヘッダーは含まれませんが、サービスは、これらのヘッダーを含む応答アクションを持つワークフローを保存することを妨げません。
- Allow
- Content-Disposition、Content-Encoding、および Content-Type を除く Content-* ヘッダー (POST と PUT 操作を使用する場合。ただし、GET 操作については含まれない)
- Cookie
- Expires
- Last-Modified
- Set-Cookie
- Transfer-Encoding
分岐を含む複雑なワークフローに 1 つ以上の応答アクションがある場合は、ワークフローで、少なくとも 1 つの応答アクションが実行時に処理されるようにしてください。そうしない場合、すべての Response アクションがスキップされると、ワークフローが正常に終了した場合でも、呼び出し元は 502 無効なゲートウェイ エラーを受け取ります。
Standard ロジックアプリの "ステートレス" ワークフローでは、応答アクションはワークフローの最後に表示される必要があります。アクションがそれ以外の場所に表示されていても、他のすべてのアクションの実行が完了するまでは、Azure Logic Apps はアクションを実行しません。

従量課金プラン
標準

Azure portal で、従量課金ロジックアプリリソースを開きます。
サイドバーメニューの [開発ツール] で、デザイナーを選択してワークフローを開きます。

このワークフロー例では、前のセクションで追加した要求トリガーを使用します。
アクションを追加する一般的な手順に従って、応答組み込みアクションをワークフローに追加します。

アクション情報ボックスに、応答メッセージに必要な値を追加します。

プロパティ名	JSON プロパティ名	必須	説明
状態コード	`statusCode`	はい	応答で返される状態コード
ヘッダー	`headers`	いいえ	応答に含める 1 つまたは複数のヘッダーを記述する JSON オブジェクト
本文	`body`	いいえ	応答本文

テキストフィールド内で選択すると、動的コンテンツリスト (稲妻アイコン) または式エディター (関数アイコン) を開くオプションが表示されます。動的コンテンツリストを選択すると、ワークフローの前の手順で使用できる出力を選択できます。要求トリガーでスキーマを指定した場合、スキーマプロパティは動的コンテンツリストにも表示され、ワークフローで使用できます。

たとえば、[ ヘッダー ] フィールドで、キー名として Content-Type を使用し、この記事で前述したようにキー値を application/json に設定します。 [本文] ボックスでは、動的コンテンツの一覧を開き、トリガー本文の出力を選択できます。

ヘッダーを JSON 形式で表示するには、[Switch to text view]\(テキストビューに切り替え\) を選択します。

アクションに他のパラメーターが存在する場合は、[ 詳細パラメーター ] ボックスの一覧を開き、目的のパラメーターを選択します。
完了したら、ワークフローを保存します。デザイナーのツールバーで、[保存] を選択します。

Azure portal で、Standard ロジックアプリリソースを開きます。
リソースサイドバーメニューの [ ワークフロー] で [ ワークフロー] を選択し、ワークフローを選択します。
ワークフローサイドバーメニューの [ ツール] で、デザイナーを選択してワークフローを開きます。

このワークフロー例では、前のセクションで追加した要求トリガーを使用します。
アクションを追加する一般的な手順に従って、応答組み込みアクションをワークフローに追加します。

アクション情報ボックスに、応答メッセージに必要な値を追加します。

プロパティ名	JSON プロパティ名	必須	説明
状態コード	`statusCode`	はい	応答で返される状態コード
ヘッダー	`headers`	いいえ	応答に含める 1 つまたは複数のヘッダーを記述する JSON オブジェクト
本文	`body`	いいえ	応答本文

ヘッダーを JSON 形式で表示するには、[Switch to text view]\(テキストビューに切り替え\) を選択します。

アクションに他のパラメーターが存在する場合は、[ 詳細パラメーター ] ボックスの一覧を開き、目的のパラメーターを選択します。
完了したら、ワークフローを保存します。デザイナーのツールバーで、[保存] を選択します。

ワークフローをテストする

ワークフローをトリガーするには、HTTP 要求ツールとその指示を使用して、要求トリガーに対して生成された URL に HTTP 要求を送信します。要求トリガーが予期するメソッドも含まれます。

トリガーの基になる JSON 定義と、このトリガーを呼び出す方法の詳細については、次の記事を参照してください。要求トリガーの種類と、 Azure Logic Apps の HTTP エンドポイントを使用したワークフローの呼び出し、トリガー、または入れ子。

セキュリティと認証

要求トリガー (Webhook トリガーではなく) で始まる標準ロジックアプリワークフローでは、Azure Functions プロビジョニングを使用して、マネージド ID を使用してそのトリガーによって作成されたエンドポイントに送信された受信呼び出しを認証できます。このプロビジョニングは 、Easy Auth とも呼ばれます。詳細については、「Easy Auth を使用して標準ロジックアプリのワークフローをトリガーする」を参照してください。

トランスポート層セキュリティ (TLS)、Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth)、Azure API Management を使用したロジックアプリの公開、受信呼び出しの発信 IP アドレスの制限など、ロジックアプリワークフローへの受信呼び出しのセキュリティ、承認、暗号化の詳細については、「要求ベースのトリガーへの着信呼び出しのアクセス」を参照してください。

フィードバック

このページはお役に立ちましたか?