Azure Logic Apps の コネクタとは

Azure Logic Apps を使用してワークフローを構築するとき、"コネクタ" を使用すると、他のアプリ、サービス、システム、プラットフォームのデータ、イベント、リソースを、コードを書くことなく作業できます。 コネクタに用意されている 1 つ以上の事前構築済み操作が、ワークフローのステップとして使用されます。

コネクタでは、それぞれの操作はトリガー条件 (ワークフローを開始する) と後続のアクション(特定のタスクを実行する) のいずれかであり、それに構成が可能なプロパティが伴います。 多くのコネクタにはトリガーとアクションの両方がありますが、コネクタの中にはトリガーしかないものがあれば、アクションしかないものもあります。

Azure Logic Apps では、コネクタは組み込みバージョン、マネージド バージョン、あるいは両バージョンのいずれかがあります。 多くのコネクタが通常は、まず基礎となるサービスやシステムへの接続を作成し、構成することを必要とします。たいていは、それによりユーザー アカウントへのアクセスを認証できるようにするためです。 アクセスしたいと思うサービスやシステムに利用できるコネクタがない場合は、一般的な HTTP 操作を使用してリクエストを送信するか、カスタム コネクタを作成することができます。

この概要では、コネクタの概要と、一般的な動作について説明します。 コネクタについて詳しくは、次のドキュメントをご覧ください。

組み込みコネクタとマネージド コネクタの比較

Azure Logic Apps では、コネクタは"組み込み"と"マネージド"のいずれかです。 両方のバージョンを持つコネクタもあります。 使用できるバージョンは、マルチテナントの Azure Logic Apps で実行される従量課金ロジック アプリ ワークフローを作成するか、シングル テナントの Azure Logic Apps で実行する Standard ロジック アプリ ワークフローを作成するかによって異なります。 ロジック アプリ リソースの種類の詳細については、リソースの種類とホスト環境の違いに関するセクションをご覧ください。

  • 組み込みコネクタは、直接 Azure Logic Apps 内でネイティブで動作するよう作られています。

  • マネージド コネクタは、Microsoft によって Azure でデプロイ、ホスト、管理されます。 マネージド コネクタはほとんどが、基になるサービスまたはシステムが Azure Logic Apps と通信するために使用する API のプロキシまたはラッパーを提供します。

    • 従量課金ワークフローでは、マネージド コネクタは価格レベルに基づいて、デザイナーで Standard または Enterprise ラベルが付いています。

    • Standard ワークフローでは、すべてのマネージド コネクタがデザイナーの Azure ラベルの下に表示されます。

詳しくは、次のドキュメントをご覧ください。

トリガー

トリガーはワークフローを開始するために満たすべき条件を指定しており、あらゆるワークフローにおいて常に最初のステップです。 各トリガーはまた、トリガーがイベントを監視したり、それに応答したりする方法を制御する特定の起動パターンに従います。 通常、トリガーは "ポーリング" パターンまたは "プッシュ" パターンに従います。 ときには、両方のトリガー バージョンがあります。

  • "ポーリング トリガー" を使って、指定されたスケジュールで特定のサービスまたはシステムを定期的にチェックして、新しいデータまたは特定のイベントをチェックします。 新しいデータが利用可能な場合、または特定のイベントが発生した場合、ワークフローの新しいインスタンスが、このトリガーによって作成および実行されます。 この新しいインスタンスから、入力として渡されたデータを使用できます。

  • "Push" トリガーや "webhook" トリガーを使って、新しいデータまたはイベントの発生をリッスンし、ポーリングは行いません。 新しいデータが使用可能になった場合、またはイベントが発生した場合、これらのトリガーではワークフローの新しいインスタンスを作成して実行します。 この新しいインスタンスから、入力として渡されたデータを使用できます。

たとえば、ファイルが FTP サーバーにアップロードされたときに動作するワークフローを構築したいとします。 ワークフローの最初のステップとして、ポーリング パターンに従う、「ファイルの追加または変更時」という名前の FTP トリガーを追加できます。 その後、アップロード イベントを定期的にチェックするスケジュールを指定します。

トリガーは起動すると、通常は参照して使用するための後続アクションのイベント出力を渡します。 FTP の例では、トリガーは自動的にファイル名やパスなどの情報を出力します。 ファイル内容を含むようトリガーを設定することもできます。 そのため、このデータを処理するには、アクションをワークフローに追加する必要があります。

アクション

アクションは実行するタスクを指定し、常にワークフローでは後続のステップ として存在します。 ワークフローでは、複数のアクションを使用できます。 たとえば、SQL データベース内の新しい顧客データを検出する SQL Server トリガーを使用してワークフローを開始してもよいでしょう。 このトリガーに従って、ワークフローに、その顧客データを取得する SQL Server アクションを含めることができます。 この SQL Server アクションに続けて、ワークフローに、そのデータを処理する別のアクション、たとえば CSV テーブルを作成する Data Operations アクションを使用することができます。

接続のアクセス許可

従量課金ロジック アプリ ワークフローでは、ロジック アプリのリソース、ワークフローおよびその接続を作成または管理する前に、特定のアクセス許可が必要です。 これらのアクセス許可の詳細については、セキュリティで保護された操作 - Azure Logic Apps でのアクセスとデータのセキュリティ保護に関するページを参照してください。

接続の作成、構成、認証

ワークフローでコネクタの操作を使用するには、多くのコネクタの場合、まずターゲット サービスまたはシステムへの"接続"を作成しておく必要があります。 ワークフロー デザイナー内からの接続を作成するには、アカウントの資格情報、および場合によっては他の接続情報を使用してご自分の ID を認証する必要があります。

たとえば、ワークフローで Office 365 Outlook 電子メール アカウントにアクセスしてそれを操作するには、そのアカウントへの接続を認可しておく必要があります。 一部の組み込みコネクタとマネージド コネクタの場合は、認証情報を提供する代わりに、マネージド ID を設定して認証に使用することができます。

ワークフロー内から接続を作成しますが、実際にはそれらの接続は独自のリソース定義を持つ個別の Azure リソースです。 これらの接続リソース定義を確認するには、従量課金ワークフローと Standard ワークフローのどちらを使用しているかに基づいて、次の手順に従います。

接続のセキュリティと暗号化

サーバー アドレス、ユーザー名、パスワード、資格情報、シークレットなどの接続構成の詳細は暗号化され、セキュリティで保護された Azure 環境に格納されます。 この情報は、ロジック アプリ リソースでのみ使用することができ、リンクされたアクセス確認を使用して適用される接続リソースに対するアクセス許可を持つクライアントによってのみ使用できます。 Office 365、Salesforce、GitHub など、Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth) を使用する接続では、サインインが必要ですが、Azure Logic Apps ではアクセス トークンと更新トークンだけがシークレットとして格納され、サインイン資格情報は格納されません。

サービスまたはシステムが許可する限り、確立された接続から、対象のサービスまたはシステムにアクセスできます。 Office 365 や Dynamics など、Microsoft Entra ID OAuth 接続を使用するサービスについては、アクセス トークンは Azure Logic Apps によって無制限に更新されます。 その他のサービスでは、Logic Apps が更新なしでトークンを使用できる期間が制限されることがあります。 一部のアクション (パスワードの変更など) では、すべてのアクセス トークンが無効になります。

Note

組織が Azure Logic Apps のコネクタを介して特定のリソースにアクセスすることを許可していない場合は、Azure Policy を使用して、そのような接続を作成する機能をブロックすることができます。

ロジック アプリのワークフローと接続をセキュリティで保護する方法の詳細については、「Azure Logic Apps におけるアクセスとデータのセキュリティ保護」をご覧ください。

接続のためのファイアウォール アクセス

トラフィックを制限するファイアウォールを使用しており、かつロジック アプリ ワークフローがそのファイアウォール経由で通信する必要がある場合は、そのロジック アプリ ワークフローが存在する Azure リージョン内の Azure Logic Apps プラットフォームまたはランタイムによって使用される受信 IP アドレスと送信 IP アドレスの両方のアクセスを許可するようにファイアウォールを設定する必要があります。

また、ワークフローでマネージド コネクタ (Office 365 Outlook コネクタや SQL コネクタなど) を使用する場合や、カスタム コネクタを使用する場合は、ファイアウォールで、ロジック アプリ リソースの Azure リージョン内の "すべての" マネージド コネクタ送信 IP アドレスのアクセスも許可する必要があります。 詳細については、ファイアウォールの構成に関するページを参照してください。

カスタム コネクタと API

マルチテナント Azure Logic Apps 用の従量課金ワークフローで、既定のコネクタとして使用できない Swagger ベースまたは SOAP ベースの API を呼び出すことができます。 カスタム API アプリを作成してカスタム コードを実行することもできます。 詳しくは、次のドキュメントをご覧ください。

シングルテナント Azure Logic Apps 用の Standard ワークフローでは、任意の Standard ロジック アプリ ワークフローで使用できるネイティブ実行のサービス プロバイダー ベースのカスタム組み込みコネクタを作成できます。 詳しくは、次のドキュメントをご覧ください。

ISE とコネクタ

Azure 仮想ネットワーク内のリソースに直接アクセスする必要があるワークフローの場合は、専用のリソースでワークフローをビルド、デプロイ、および実行できる、専用の統合サービス環境 (ISE) を作成できます。 ISE の作成について詳しくは、Azure Logic Apps から Azure Virtual Network への接続に関するページをご覧ください。

ISE 内で作成されたカスタム コネクタは、オンプレミス データ ゲートウェイでは動作しません。 ただし、これらのコネクタでは、ISE がホストされている Azure 仮想ネットワークに接続されているオンプレミス データ ソースに直接アクセスできます。 そのため、ISE 内のロジック アプリ ワークフローでは、ほとんどの場合、それらのリソースと通信するときにデータ ゲートウェイは不要です。 ISE の外部で作成したカスタム コネクタがあり、オンプレミス データ ゲートウェイを必要とする場合、ISE 内のワークフローから、それらのコネクタを使用できます。

ワークフロー デザイナーでは、組み込みコネクタまたは ISE でワークフローに使用するマネージド コネクタを参照すると、組み込みコネクタでは CORE ラベルが表示されるに対して、ISE で動作するように設計されたマネージド コネクタでは ISE ラベルが表示されます。

Example CORE connector

CORE

このラベルが付いた組み込みコネクタは、ワークフローと同じ ISE 内で動作します。

Example ISE connector

ISE

このラベルが付いたマネージド コネクタは、ワークフローと同じ ISE 内で動作します。

Azure 仮想ネットワークに接続されているオンプレミス システムがある場合は、ISE により、ワークフローはオンプレミス データ ゲートウェイを使用しなくても、そのシステムに直接アクセスできます。 代わりに、そのシステムの ISE コネクタ (使用可能な場合)、HTTP アクション、またはカスタム コネクタを使用できます。

ISE コネクタのないオンプレミス システムの場合は、オンプレミス データ ゲートウェイを使用します。 使用できる ISE コネクタを見つけるには、ISE コネクタを確認してください。

Example non-ISE connector

ラベルなし

ラベルのないその他のすべてのコネクタ (これも引き続き使用できます) の場合は、グローバルなマルチテナント Logic Apps サービスで実行します。

既知の問題

次の表には、Azure Logic Apps のコネクタに関する既知の問題が含まれています。

エラー メッセージ 説明 解像度
Error: BadGateway. Client request id: '{GUID}' このエラーは、 1 つ以上の接続で SFTP や SQL などの Microsoft Entra ID OAuth 認証がサポートされていないロジック アプリ リソースでタグを更新した場合に発生し、それらの接続が切断されます。 この動作を回避するには、それらのタグを更新しないようにします。

次のステップ