Standard シングルテナント ロジック アプリと従量課金マルチテナント ロジック アプリの違い

Azure Logic Apps は、アプリ、データ、サービス、およびシステムを統合する自動化された "ロジック アプリ ワークフロー" を作成および実行するためのクラウドベースのプラットフォームです。 このプラットフォームを使用すると、エンタープライズおよび企業間 (B2B) シナリオ向けのスケーラビリティの高い統合ソリューションを迅速に開発できます。 ロジック アプリ リソースを作成する際は、従量課金または Standard のホスティング オプションを選択します。 従量課金ロジック アプリでは、"マルチテナント" Azure Logic Apps 内で実行されるワークフローを 1 つだけ保有できます。 または、"シングルテナント'' Azure Logic Apps あるいは App Service Environment v3 (ASE v3) で実行される Standard ロジック アプリ ワークフローを作成します。

作成するロジック アプリ リソースを選択する前に、次のガイドを参照して、ロジック アプリのワークフローの種類がどのように異なるかを確認します。 その後、シナリオ、ソリューション要件、ワークフローをデプロイおよび実行する宛先に最適なロジック アプリのワークフローと環境について、より適切な選択を行うことができます。

Azure Logic Apps を初めて使用する場合は、「Azure Logic Apps とは」と"ロジック アプリ ワークフロー" の概要に関する記事を参照してください。

ロジック アプリ ワークフローの種類と環境

次の表は、従量課金ロジック アプリ ワークフローと Standard ロジック アプリ ワークフローの違いをまとめたものです。 また、ワークフローのデプロイ、ホスティング、実行に関して、シングルテナント環境とマルチテナント環境の違いについても説明します。

Standard ロジック アプリとワークフロー

Standard ロジック アプリとワークフローには、再設計されたシングルテナント Azure Logic Apps ランタイムが使用されています。 このランタイムには Azure Functions 機能拡張モデルが使用されており、Azure Functions ランタイムの拡張機能としてホストされます。 この設計により、ロジック アプリ ワークフローの移植性、柔軟性、パフォーマンス向上に加え、Azure Functions プラットフォームと Azure App Service エコシステムから継承されたその他の機能と利点が提供されます。 たとえば、Azure App Service Environment v3 では、シングルテナント ベースのロジック アプリとそのワークフローを作成、デプロイ、および実行することができます (Windows プランのみ)。

Azure Functions アプリで複数の関数をホストできるのと同様に、Standard ロジック アプリでは、複数のワークフローをホストできるリソース構造が導入されています。 1 対多のマッピングでは、同じロジック アプリとテナント内のワークフローによってコンピューティングと処理リソースが共有され、その近接性によってパフォーマンスが向上します。 この構造は、ロジック アプリのリソースとワークフローの間に 1 対 1 のマッピングがある従量課金ロジック アプリ リソースとは異なります。

移植性、柔軟性、パフォーマンス向上の詳細については、引き続き次のセクションを参照してください。 シングルテナントの Azure Logic Apps ランタイムと Azure Functions の拡張性の詳細について、次のドキュメントを参照してください。

• あらゆる場所で実行される Azure Logic Apps - ランタイムの詳細
• Azure Functions の概要
• Azure Functions triggers and bindings (Azure Functions のトリガーとバインド)

移植性と柔軟性

Standard ロジック アプリとワークフローを作成すると、Azure App Service Environment v3 (Windows プランのみ) などの他の環境でワークフローをデプロイして実行できます。 Visual Studio Code を Azure Logic Apps (Standard) 拡張機能と共に使用する場合、Azure にデプロイせずに、開発環境で "ローカルに" ワークフローを開発、ビルド、実行できます。 シナリオでコンテナーが必要な場合は、Azure Arc 対応 Logic Apps を使用してシングルテナント ロジック アプリを作成できます。 詳細については、「Azure Arc 対応 Logic Apps とは」を参照してください。

Azure 内で実行されている既存のりソースに対して開発を行う必要があるマルチテナント モデルと比較すると、これらの機能によって大幅な改善と大きなメリットを得ることができます。 従量課金ロジック アプリ リソースのデプロイを自動化するためのマルチテナント モデルは、アプリとインフラストラクチャの両方のリソース プロビジョニングを結合して処理する Azure Resource Manager テンプレート (ARM テンプレート) に基づいています。

Standard ロジック アプリ リソースでは、アプリのデプロイとインフラストラクチャのデプロイを分離できるため、デプロイが容易になります。 シングルテナント Azure Logic Apps ランタイムとワークフローをロジック アプリのリソースまたはプロジェクトの一部としてまとめてパッケージ化できます。 ロジック アプリのリソースをビルド、アセンブル、圧縮して、すぐにデプロイできる状態の成果物を生成する一般的な手順またはタスクを使用できます。 インフラストラクチャをデプロイする場合も、ARM テンプレートを使用して、それらの目的で使用する他のプロセスやパイプラインと共に、それらのリソースを別々にプロビジョニングできます。

アプリをデプロイするには、成果物をホスト環境にコピーしてから、アプリを開始してワークフローを実行します。 または、既に使ったことのあるツールとプロセスを使用して、成果物をデプロイ パイプラインに統合します。 そうすることで、開発に使用するテクノロジ スタックに関係なく、独自に選択したツールを使用してデプロイできます。

標準的なビルドとデプロイのオプションを使用することにより、インフラストラクチャのデプロイから切り離して、アプリの開発に集中できます。 その結果、プロジェクト モデルはより汎用的になり、汎用アプリに使用する多くの類似したまたは同じデプロイ オプションを適用できます。 また、アプリのデプロイ パイプラインを構築するときや、運用環境に発行する前に必要なテストと検証を実行するときに、より一貫性のあるエクスペリエンスを利用できます。

パフォーマンス

Standard ロジック アプリを使用すると、同じシングル ロジック アプリ リソースとテナント内に複数のワークフローを作成して実行できます。 この 1 対多のマッピングにより、これらのワークフローではコンピューティング、処理、ストレージ、ネットワークなどのリソースが共有され、その近接性によってパフォーマンスが向上します。

Standard ロジック アプリリソースとシングルテナント Azure Logic Apps ランタイムでは、より一般的なマネージド コネクタを組み込みのコネクタ操作として使用できるようにすることで、もう 1 つの大幅な改善が得られます。 たとえば、Azure Service Bus、Azure Event Hubs、SQL などに対して組み込みのコネクタ操作を使用できます。 一方、マネージド コネクタのバージョンは現在も利用でき、引き続き機能します。

新しい組み込みのコネクタ操作を使用する場合は、"組み込み接続" または "サービス プロバイダー接続" と呼ばれる接続を作成します。 それに対応するマネージド接続は "API 接続" と呼ばれます。これは、Azure リソースとして別個に作成されて実行され、ARM テンプレートを使用してデプロイする必要があります。 組み込み操作とその接続は、ワークフローを実行するのと同じプロセスでローカルに実行されます。 どちらも、シングルテナント Azure Logic Apps ランタイムでホストされます。 その結果、組み込み操作とその接続では、ワークフローとの近接性によってパフォーマンスが向上します。 サービス プロバイダーの接続が同じビルド成果物にパッケージされるため、この設計はデプロイ パイプラインでも適切に機能します。

データの保存場所

Standard ロジック アプリ リソースはシングルテナントの Azure Logic Apps でホストされます。ここでは、これらのロジック アプリ リソースをデプロイしたリージョン以外へのデータの格納、処理、レプリケートは行われません。つまり、ワークフローのデータは、その親リソースを作成してデプロイしたのと同じリージョン内に留まります。

Azure 仮想ネットワーク内のリソースへの直接アクセス

シングルテナント Azure Logic Apps 内で実行されるワークフローは、Azure 仮想ネットワーク内に存在する仮想マシン (VM)、他のサービス、システムなどのセキュリティで保護されたリソースに直接アクセスできます。

シングルテナント Azure Logic Apps は、Azure Logic Apps サービスの専用インスタンスであり、専用リソースを使用し、マルチテナント Azure Logic Apps とは別に実行されます。 専用インスタンスでワークフローを実行することで、他の Azure テナントがアプリのパフォーマンスに与える可能性がある影響 ("うるさい隣人" エフェクトとも呼ばれます) を低減できます。

シングルテナント Azure Logic Apps には、次の利点もあります。

• 自分専用の静的 IP アドレス。これらの IP アドレスは、マルチテナント Azure Logic Apps のロジック アプリによって共有される静的 IP アドレスとは区別されています。 また、送信先システムとの通信のために、単一の予測可能な静的パブリック アウトバウンド IP アドレスを自分で設定することもできます。 このようにすると、それらの送信先システムで追加のファイアウォールを設定する必要がなくなります。

• 実行継続時間、ストレージのリテンション期間、スループット、HTTP の要求と応答のタイムアウト、メッセージのサイズ、カスタム コネクタの要求の上限が引き上げられました。 詳細については、Azure Logic Apps の制限と構成に関する記事をご覧ください。

作成、ビルド、およびデプロイのオプション

目的の環境に基づいてロジック アプリ リソースを作成するには、複数のオプションがあります。次に例を示します。

シングルテナント環境

マルチテナント環境

従量課金と Standard のどちらのロジック アプリ リソースを作成するかによって開発エクスペリエンスは異なりますが、デプロイされたすべてのロジック アプリは Azure サブスクリプションの下にありアクセスできます。

たとえば、Azure portal では、[ロジック アプリ] ページには従量課金と Standard の両方のロジック アプリ リソースが表示されます。 Visual Studio Code では、デプロイされたロジック アプリは Azure サブスクリプションの下に表示されますが、従量課金ロジック アプリは [Azure] ウィンドウの Azure Logic Apps (従量課金) 拡張機能の下に表示され、Standard ロジック アプリは [リソース] セクションに表示されます。

ステートフルおよびステートレス ワークフロー

Standard ロジック アプリ内では、次のワークフローの種類を作成できます。

• ステートフル

  前のイベントのデータを保持、確認、または参照する必要がある場合は、ステートフル ワークフローを作成します。 これらのワークフローは、すべての操作の入力、出力、および状態を外部ストレージに保存します。 この情報により、各実行が完了した後に、ワークフローの実行の詳細と履歴を確認できます。 ステートフル ワークフローでは、サービス停止が発生した場合に高い回復性を実現できます。 サービスとシステムが復元された後に、中断された実行を保存済みの状態から再構築し、ワークフローを再実行して完了することができます。 ステートフル ワークフローは、ステートレス ワークフローよりもはるかに長い間実行を継続できます。

  既定では、マルチテナントとシングルテナントの両方の Azure Logic Apps のステートフル ワークフローが非同期に実行されます。 HTTP ベースのすべてのアクションは、標準的な非同期操作パターンに従います。 HTTP アクションがエンドポイント、サービス、システム、または API に対して要求を呼び出す、または送信した後、受信側が直ちに "202 ACCEPTED" 応答を返します。 このコードは、受信側が要求を受け入れたが、処理が完了していないことを確認します。 応答には、受信側が処理を停止して "200 OK" 成功応答またはその他の 202 以外の応答が返されるまで、呼び出し元が非同期要求の状態をポーリングまたは確認するために使用できる URI およびリフレッシュ ID を指定する location ヘッダーを含めることができます。 ただし、呼び出し元は要求の処理が完了するまで待機する必要はなく、次のアクションの実行を継続できます。 詳細については、マイクロサービスの非同期統合によるマイクロサービスの自律性の強制に関するページを参照してください。

• ステートレス

  後で確認するために、各実行が完了した後に外部ストレージに前のイベントのデータを保持、確認、参照する必要がない場合は、ステートレス ワークフローを作成します。 これらのワークフローでは、各アクションとその状態の入出力を外部ストレージにではなく、"メモリ内にのみ" 保存します。 その結果、ステートレス ワークフローでは、実行時間が短縮され (通常は 5 分未満)、パフォーマンスが高速化されて応答時間が短くなり、スループットが向上し、実行コストが削減されます。これは、実行の詳細と履歴が外部ストレージに保存されないためです。 しかし、サービス停止が発生した場合、中断された実行は自動的には復元されないため、呼び出し元は中断された実行を手動で再送信する必要があります。

  ステートレス ワークフローは、"合計" サイズが 64 KB を超えないファイルなどのデータやコンテンツを処理する際に、最高のパフォーマンスを発揮します。 サイズの大きな添付ファイルが複数ある場合など、コンテンツのサイズが大きくなると、ワークフローのパフォーマンスが著しく低下し、メモリ不足の例外によってワークフローのクラッシュが引き起こされることもあります。 ワークフローでより大きなサイズのコンテンツを処理する必要がある場合は、代わりにステートフル ワークフローを使用してください。

  Note

  ステートレス ワークフローの場合、ワークフローの実行スケジュールを指定しないプッシュ トリガーのみを使用できます。 これらの Webhook ベースのトリガーは、イベントが発生するか、データが使用可能になるまで待機します。 たとえば、繰り返しトリガーはステートフル ワークフローでのみ使用できます。 ワークフローを開始するには、プッシュ トリガー (要求、Event Hubs、Service Bus などのトリガー) を選択します。 制限付き、使用できない、またはサポートされていないトリガー、アクション、コネクタの詳細については、「変更された、制限付き、使用できない、またはサポートされていない機能」を参照してください。

  ステートレス ワークフローは同期的にのみ実行されるため、ステートフル ワークフローで使用される標準の非同期操作パターンは使用されません。 代わりに、"202 ACCEPTED" 応答を返す HTTP ベースのすべてのアクションは、ワークフロー実行の次のステップに進みます。 応答に location ヘッダーが含まれる場合、ステートレス ワークフローでは、指定された URI をポーリングして状態を確認することはありません。 標準の非同期操作パターンに従うには、代わりにステートフル ワークフローを使用します。

  デバッグをより容易にするために、ステートレス ワークフローの実行履歴を有効にし (この場合、パフォーマンスに何らかの影響があります)、その後、完了時に実行履歴を無効にすることができます。 詳細については、Visual Studio Code でのシングルテナント ベースのワークフローの作成または Azure portal でのシングルテナント ベースのワークフローの作成に関するページを参照してください。

ステートフル ワークフローとステートレス ワークフローの違いのまとめ

ステートフルおよびステートレス ワークフローの入れ子になった動作の違い

Request トリガー、HTTP Webhook トリガー、または ApiConnectionWebhook 型であり HTTPS 要求を受信できるマネージド コネクタ トリガーを使用することによって、同じ Standard ロジック アプリに存在する他のワークフローからワークフローを呼び出せるようにすることができます。

次の一覧では、親ワークフローで子ワークフローが呼び出された後、入れ子になったワークフローで従うことができる動作パターンを示します。

• 非同期ポーリング パターン

  親ワークフローは、最初の呼び出しに対する子ワークフローからの応答を待ちません。 ただし、子が実行を完了するまで、親は継続的に子の実行履歴を確認します。 既定では、ステートフルなワークフローはこのパターンに従います。これは、要求タイムアウト制限を超える可能性がある、長時間実行される子ワークフローに適しています。

• 同期パターン ("ファイア アンド フォーゲット")

  子ワークフローは、すぐに 202 ACCEPTED 応答を返すことで、親ワークフローの呼び出しに対して受信確認します。 ただし、親は子から結果が返されるのを待ちません。 代わりに、親はワークフロー内の次のアクションに進み、子が実行を完了したときに結果を受け取ります。 応答アクションを含まない子ステートフル ワークフローは、常に同期パターンに従い、確認用に実行履歴を提供します。

  この動作を有効にするには、ワークフローの JSON 定義で、operationOptions プロパティを DisableAsyncPattern に設定します。 詳細については、トリガーとアクションの種類 (操作オプション) に関するページを参照してください。

• トリガーと待機

  ステートレス ワークフローはメモリ内で実行されます。 そのため、親ワークフローが子ステートレス ワークフローを呼び出すと、親は子からの結果を返す応答を待機します。 このパターンは、組み込みの HTTP トリガーまたはアクションを使用して子ワークフローを呼び出す場合と同様に機能します。 応答アクションを含まないステートレスな子ワークフローは直ちに 202 ACCEPTED 応答を返しますが、親は次のアクションに進む前に子が終了するまで待機します。 これらの動作は、ステートレスな子ワークフローにのみ適用されます。

次の表では、親と子がステートフル、ステートレス、または混合のどのワークフロー型であるかに基づいて、子ワークフローの動作を示します。 表の後の一覧

その他のシングルテナント モデルの機能

シングルテナント モデルと Standard ロジック アプリには、次のような現行と新規の機能が多数含まれています。

• サービスとしてのソフトウェア (SaaS) およびサービスとしてのプラットフォーム (PaaS) のアプリとサービス用の何百ものマネージド コネクタや、オンプレミス システム用のコネクタから、ロジック アプリとそのワークフローを作成します。

  • さらに多くのマネージド コネクタが、Standard ワークフローの組み込みコネクタとして使用できるようになりました。 組み込みバージョンは、シングルテナント Azure Logic Apps ランタイムでネイティブに実行されます。 一部の組み込みコネクタは "サービス プロバイダー" コネクタとも呼ばれています。 一覧については、従量課金と Standard の組み込みコネクタに関する記事を参照してください。

  • シングルテナント Azure Logic Apps 機能拡張フレームワークを使用して、必要なサービス用の独自のカスタム組み込みコネクタを作成できます。 Azure Service Bus や SQL Server などの組み込みコネクタと同様に、これらのカスタムの組み込みコネクタは、より高いスループット、短い待機時間、ローカル接続を実現しますが、これはシングルテナントのランタイムと同じプロセスでネイティブに実行されるためです。 ただし、カスタムの組み込みコネクタは、現在サポートされていない カスタム マネージド コネクタと似ています。 詳細については、「カスタム コネクタの概要」および「シングルテナントの Azure Logic Apps で Standard ロジック アプリ用のカスタム組み込みコネクタを作成する」を確認してください。

  • 統合アカウントを使わずに、Liquid 操作と XML 操作に以下のアクションを使用できます。 実行できる操作には次のアクションが含まれます。

    • XML: XML の変換と XML の検証

    • Liquid: JSON から JSON への変換、JSON からテキストへの変換、XML から JSON への変換、XML からテキストへの変換

    注意

    Standard ワークフローでこれらのアクションを使用するには、Liquid マップ、XML マップ、または XML スキーマが必要です。 これらの成果物は Azure portal で、ロジック アプリのリソース メニューの [成果物] ( [スキーマ] セクションと [マップ] セクションが含まれます) からアップロードできます。 または、Visual Studio Code プロジェクトの [成果物] フォルダーで [マップ] フォルダーと [スキーマ] フォルダーをそれぞれ使用して、これらの成果物を追加することもできます。 その後、"同じ" ロジック アプリ内の複数のワークフローでこれらの成果物を使用できます。

  • Azure Logic Apps によって、ロジック アプリでクラウド接続ランタイム エンドポイントに要求を送信するために使用できる Shared Access Signature (SAS) 接続文字列が生成されるため、Standard ロジック アプリ ワークフローはどこでも実行できます。 Azure Logic Apps によって、これらの接続文字列が他のアプリケーション設定とともに保存されるため、Azure にデプロイするときにこれらの値を Azure Key Vault に簡単に格納できます。

  • Standard ロジック アプリ ワークフローでは、システム割り当てマネージド ID "および" 複数のユーザー割り当てマネージド ID の両方を同時に有効にすることができますが、一度に使用する ID は 1 つしか選択できません。 組み込みのサービス プロバイダー ベースのコネクタではシステム割り当て ID の使用がサポートされていますが、現在のところ、SQL Server と HTTP コネクタを除き、認証用のユーザー割り当てマネージド ID の選択はサポートされていません。

    注意

    既定では、実行時に接続を認証するために、システム割り当て ID は既に有効になっています。 この ID は、接続の作成時に使用する認証資格情報または接続文字列とは異なります。 この ID を無効にした場合、接続は実行時に機能しません。 この設定を表示するには、ロジック アプリのメニューの [設定] で、 [ID] を選択します。

• Visual Studio Code 開発環境でローカルにロジック アプリとそのワークフローを実行、テスト、デバッグできます。

  ロジック アプリを実行してテストする前に、ワークフローの workflow.json ファイル内にブレークポイントを追加して使用することで、デバッグをより簡単に行うことができます。 しかし、ブレークポイントは、現時点ではトリガーではなく、アクションに対してのみサポートされます。 詳細については、Visual Studio Code でのシングルテナント ベースのワークフローの作成に関するページを参照してください。

• ロジック アプリとそのワークフローを Visual Studio Code から、Azure や Azure Arc 対応 Logic Apps などのさまざまなホスティング環境に直接発行またはデプロイします。

• Azure サブスクリプションとロジック アプリの設定でサポートされている場合は、Application Insights を使用してロジック アプリに対して診断ログとトレース機能を有効にします。

• Azure Functions Premium プランを使用して、ロジック アプリを作成してデプロイする場合の Azure Functions と同様に、Azure 仮想ネットワークとのプライベートな接続や統合などのネットワーク機能にアクセスします。 詳細については、次のドキュメントを確認してください。

  • Azure Functions のネットワーク オプション

  • あらゆる場所で実行される Azure Logic Apps - Azure Logic Apps を使用したネットワークの可能性

• Standard ロジック アプリの個々のワークフローで使用されるマネージド接続のアクセス キーを再生成します。 このタスクでは、ロジック アプリのリソース レベルではなく、個々のワークフロー レベルで従量課金ロジック アプリに対して同じ手順を実行します。

Standard 用の組み込みコネクタ

Standard ワークフローでは、従量課金ワークフローと同じ組み込みコネクタの多くを使用できます。 その逆に、Standard ワークフローには、従量課金ワークフローでは使用できない多数の組み込みコネクタがあります。

たとえば、Standard ワークフローには、Azure BLOB、Azure Cosmos DB、Azure Event Hubs、Azure Service Bus、DB2、FTP、MQ、SFTP、SQL Server などのためのマネージド コネクタと組み込みコネクタの両方が用意されています。 従量課金ワークフローには、これらの同じ組み込みコネクタ バージョンはありませんが、Azure API Management、Azure App Services、などの他の組み込みコネクタがあります。

シングルテナント Azure Logic Apps では、特定の属性を持つ組み込みコネクタは、非公式に "サービス プロバイダー" と呼ばれます。 組み込みコネクタによっては、基盤となるサービスへの接続を認証する単一の方法のみがサポートされています。 その他の組み込みコネクタでは、接続文字列、Microsoft Entra ID、マネージド ID の使用など、選択肢を提供できます。 すべての組み込みコネクタは、再設計された Azure Logic Apps ランタイムと同じプロセスで実行されます。 詳細については、Standard ロジック アプリ ワークフローの組み込みコネクタの一覧を確認してください。

変更された、制限付き、使用できない、またはサポートされていない機能

Standard ロジック アプリ ワークフローでは、これらの機能は変更されているか、現在制限されているか、使用できないか、またはサポートされていません。

• トリガーとアクション: 組み込みのトリガーとアクションは Azure Logic Apps でネイティブに実行されますが、マネージド コネクタは Azure 内の共有リソースを使用してホストおよび実行されます。 Standard ワークフローでは、スライディング ウィンドウ、Azure App Service、Azure API Management などの一部の組み込みトリガーとアクションは現在使用できません。 ステートフルまたはステートレス　ワークフローを開始するには、組み込みトリガー (Recurrence、Request、Event Hubs、Service Bus などのトリガー) を使用します。 Recurrence トリガーはステートフル ワークフローでは使用できますが、ステートレス ワークフローでは使用できません。 デザイナーでは、組み込みのトリガーとアクションは [アプリ内] ラベルを使用して表示されますが、マネージド コネクタのトリガーとアクション は [共有] ラベルを使用して表示されます。

  ステートレス ワークフローの場合、ワークフローの実行スケジュールを指定しない "プッシュ" トリガーのみを使用できます。 これらの Webhook ベースのトリガーは、イベントが発生するか、データが使用可能になるまで待機します。 たとえば、繰り返しトリガーはステートフル ワークフローでのみ使用できます。 ワークフローを開始するには、プッシュ トリガー (要求、Event Hubs、Service Bus などのトリガー) を選択します。 ステートレス ワークフローに対してマネージド コネクタを有効にすることはできますが、コネクタ ギャラリーには、追加できるマネージド コネクタの "ポーリング" トリガーは表示されません。

  Note

  Visual Studio Code でローカルに実行するには、Webhook ベースのトリガーとアクションに追加の設定が必要です。 詳細については、Visual Studio Code でのシングルテナント ベースのワークフローの作成に関するページを参照してください。

  • 以下のトリガーとアクションは、変更されたか、現在制限されているか、サポートされていないか、使用できません。

    • 組み込みアクションである [Azure Functions] - [Azure 関数を選択する] は、[Azure Functions Operations - Call an Azure function]\([Azure 関数の操作] - [Azure 関数を呼び出す]\) になりました。 このアクションは、現在、HTTP トリガー テンプレートから作成された関数に対してのみ機能します。

      Azure portal では、ユーザー エクスペリエンスを通じて接続を作成することによってアクセスできる HTTP トリガー関数を選択できます。 Visual Studio Code を使用してコード ビューまたは workflow.json ファイルで関数アクションの JSON 定義を調べる場合、アクションでは connectionName 参照を使用して関数が参照されます。 このバージョンでは関数の情報は接続として抽象化されます。これは、Visual Studio Code で接続を作成した後に使用できるようになる、ロジック アプリ プロジェクトの connections.json ファイルで確認できます。

      注意

      シングルテナント モデルの場合、関数アクションではクエリ文字列認証のみがサポートされます。 Azure Logic Apps では、接続を行っているときに関数から既定のキーが取得されます。そのキーはアプリの設定に格納され、関数を呼び出す際の認証に使用されます。

      マルチテナント モードと同様に、(たとえば、ポータルの Azure Functions エクスペリエンスを通じて) このキーを更新すると、無効なキーが原因で関数アクションは機能しなくなります。 この問題を解決するには、呼び出す関数への接続を再作成するか、新しいキーを使用してアプリの設定を更新する必要があります。

    • 組み込みアクションのインライン コードは、インライン コード操作に名前が変更され、統合アカウントは不要になり、制限が更新されました。

    • 組み込みアクションである [Azure Logic Apps - Choose a Logic App workflow]([Azure Logic Apps] - [ロジック アプリ ワークフローを選択する]) は、 [Workflow Operations - Invoke a workflow in this workflow app]([ワークフロー操作] - [このワークフロー アプリでワークフローを呼び出す]) になりました。

    • Gmail コネクタは現在サポートされていません。

    • 現在、カスタムのマネージド コネクタはサポートされていません。 ただし、Visual Studio Code を使用する場合は、"カスタムの組み込み操作" を作成できます。 詳細については、Visual Studio Code を使用したシングルテナント ベースのワークフローの作成に関するページを参照してください。

    • Standard ロジック アプリ ワークフローには、トリガーは一つのみ含めることができ、複数のトリガーはサポートされていません。

• 認証: 現在、次の認証の種類は、Standard ワークフローでは使用できません。

  • 要求トリガーや HTTP Webhook トリガーなど、要求ベースのトリガーへの受信呼び出しに対する Microsoft Entra ID Open Authorization (Microsoft Entra ID OAuth)。

  • マネージド ID 認証: システム割り当てマネージド ID とユーザー割り当てマネージド ID の両方のサポートを利用できます。 既定では、システム割り当てマネージド ID が自動的に有効になります。 ただし、ほとんどのサービス プロバイダー ベースの組み込みコネクタで、認証用ユーザー割り当てマネージド ID の選択が現在サポートされていません。

• XML 変換: 現在サポートされているのは XSLT 1.0 のみです。

• Visual Studio Code でのデバッグのブレークポイント: ワークフローの workflow.json ファイル内にブレークポイントを追加して使用することはできますが、ブレークポイントは現時点ではトリガーではなく、アクションに対してのみサポートされます。 詳細については、Visual Studio Code でのシングルテナント ベースのワークフローの作成に関するページを参照してください。

• トリガー履歴と実行履歴: Standard ロジック アプリの場合、Azure portal のトリガー履歴と実行履歴は、ロジック アプリ リソース レベルではなくワークフロー レベルで表示されます。 詳細については、Azure portal を使用したシングルテナント ベースのワークフローの作成に関するページを参照してください。

• ワークフロー実行履歴のバックアップと復元: 標準ロジック アプリでは、現在、ワークフロー実行履歴のバックアップと復元はサポートされていません。

• Terraform テンプレート: 完全なインフラストラクチャのデプロイのための Standard ロジック アプリ リソースでは、これらのテンプレートを使用できません。 詳しくは、Azure での Terraform の概要に関する記事をご覧ください。

• Azure API Management: 現在、Standard ロジック アプリ リソースを Azure API Management にインポートすることはできません。 ただし、従量課金ロジック アプリ リソースをインポートすることはできます。

厳格なネットワークとファイアウォール トラフィックのアクセス許可

お使いの環境に、トラフィックを制限する厳しいネットワーク要件またはファイアウォールがある場合、お使いのワークフローですべてのトリガーまたはアクション接続にアクセスを許可する必要があります。 必要に応じて、サービス タグからのトラフィックを許可し、Azure App Service と同じレベルの制限またはポリシーを使用できます。 また、接続用の完全修飾ドメイン名 (FQDN) を見つけて使用する必要もあります。 詳しくは、次のドキュメントの対応するセクションをご確認ください。

• シングルテナント ロジック アプリのファイヤーウォールのアクセス許可 - Azure portal
• シングルテナント ロジック アプリのファイヤーウォールのアクセス許可 - Visual Studio Code

次の手順

• Azure portal でシングルテナント ベースのワークフローを作成する
• Visual Studio Code でシングルテナント ベースのワークフローを作成する

また、シングルテナント Azure Logic Apps でのエクスペリエンスについてご意見をお聞かせください。

• バグまたは問題については、GitHub で問題を作成してください。
• 質問、要望、コメント、その他のフィードバックについては、このフィードバック フォームを使用してください。