Azure Logic Apps を使用してワークフローを構築するとき、"コネクタ" を使用すると、他のアプリ、サービス、システム、プラットフォームのデータ、イベント、リソースを、コードを書くことなく作業できます。 コネクタに用意されている 1 つ以上の事前構築済み操作が、ワークフローのステップとして使用されます。
コネクタでは、それぞれの操作はトリガー条件 (ワークフローを開始する) と後続のアクション(特定のタスクを実行する) のいずれかであり、それに構成が可能なプロパティが伴います。 多くのコネクタにはトリガーとアクションの両方がありますが、コネクタの中にはトリガーしかないものがあれば、アクションしかないものもあります。
Azure Logic Apps では、コネクタは組み込みバージョン、マネージド バージョン、あるいは両バージョンのいずれかがあります。 多くのコネクタが通常は、まず基礎となるサービスやシステムへの接続を作成し、構成することを必要とします。たいていは、それによりユーザー アカウントへのアクセスを認証できるようにするためです。 アクセスしたいと思うサービスやシステムに利用できるコネクタがない場合は、一般的な HTTP 操作を使用してリクエストを送信するか、カスタム コネクタを作成することができます。
この概要では、コネクタの概要と、一般的な動作について説明します。 コネクタについて詳しくは、次のドキュメントをご覧ください。
- Power Automate や Power Apps のようなサービスのコネクタの概要
- Azure Logic Apps の組み込みコネクタの概要
- Azure Logic Apps のマネージド コネクタの概要
- Azure Logic Apps のマネージド コネクタのリファレンス
組み込みコネクタとマネージド コネクタの比較
Azure Logic Apps では、コネクタは"組み込み"と"マネージド"のいずれかです。 両方のバージョンを持つコネクタもあります。 使用できるバージョンは、マルチテナントの Azure Logic Apps で実行される従量課金ロジック アプリ ワークフローを作成するか、シングルテナントの Azure Logic Apps で実行する Standard ロジック アプリ ワークフローを作成するかによって異なります。 ロジック アプリ リソースの種類の詳細については、リソースの種類とホスト環境の違いに関するセクションをご覧ください。
組み込みコネクタは、直接 Azure Logic Apps 内でネイティブで動作するよう作られています。
デザイナーでは、すべての組み込みコネクタが In アプリ グループ内のコネクタ ギャラリーに表示されます。
マネージド コネクタは、Microsoft によって Azure でデプロイ、ホスト、管理されます。 マネージド コネクタはほとんどが、基になるサービスまたはシステムが Azure Logic Apps と通信するために使用する API のプロキシまたはラッパーを提供します。
デザイナーでは、すべてのマネージド コネクタが 共有 グループ内のコネクタ ギャラリーに表示されます。 これらは Standard レベルまたはEnterprise レベルで課金されます。
詳しくは、次のドキュメントをご覧ください。
トリガー
トリガーはワークフローを開始するために満たすべき条件を指定しており、あらゆるワークフローにおいて常に最初のステップです。 各トリガーはまた、トリガーがイベントを監視したり、それに応答したりする方法を制御する特定の起動パターンに従います。 通常、トリガーは "ポーリング" パターンまたは "プッシュ" パターンに従います。 ときには、両方のトリガー バージョンがあります。
"ポーリング トリガー" を使って、指定されたスケジュールで特定のサービスまたはシステムを定期的にチェックして、新しいデータまたは特定のイベントをチェックします。 新しいデータが利用可能な場合、または特定のイベントが発生した場合、ワークフローの新しいインスタンスが、このトリガーによって作成および実行されます。 この新しいインスタンスから、入力として渡されたデータを使用できます。
注意
Azure で Microsoft が管理、ホスト、および実行するコネクタの場合、ポーリング トリガーは、[間隔] と [頻度] の値のみを使用して、次の繰り返しを計算します。 [At these hours] (設定時刻 (時間))、[At these days] (設定時刻 (日)) などの高度なスケジュール設定オプションは使用しません。 これらのオプションは、[繰り返し]、[Sliding Window] (スライディング ウィンドウ)、[HTTP] トリガーなどの、Azure Logic Apps ランタイムで直接実行される組み込みのポーリング トリガーでのみ機能します。
プッシュ トリガーまたは Webhook トリガーは、新しいデータまたはイベントの発生をリッスンし、ポーリングは行いません。 新しいデータが使用可能になった場合、またはイベントが発生した場合、これらのトリガーではワークフローの新しいインスタンスを作成して実行します。 この新しいインスタンスから、入力として渡されたデータを使用できます。
たとえば、ファイルが FTP サーバーにアップロードされたときに動作するワークフローを構築したいとします。 ワークフローの最初のステップとして、ポーリング パターンに従う、「ファイルの追加または変更時」という名前の FTP トリガーを追加できます。 その後、アップロード イベントを定期的にチェックするスケジュールを指定します。
トリガーは起動すると、通常は参照して使用するための後続アクションのイベント出力を渡します。 FTP の例では、トリガーは自動的にファイル名やパスなどの情報を出力します。 ファイル内容を含むようトリガーを設定することもできます。 そのため、このデータを処理するには、アクションをワークフローに追加する必要があります。
アクション
アクションは実行するタスクを指定し、常にワークフローでは後続のステップ として存在します。 ワークフローでは、複数のアクションを使用できます。 たとえば、SQL データベース内の新しい顧客データをチェックする SQL Server トリガー を使用してワークフローを開始できます。 このトリガーに従って、ワークフローに、その顧客データを取得する SQL Server アクションを含めることができます。 この SQL Server アクションに続けて、ワークフローに、そのデータを処理する別のアクション、たとえば CSV テーブルを作成する Data Operations アクションを使用することができます。
接続権限
Consumption Logicアプリのワークフローでは、Logic Appのリソース、ワークフロー、接続を作成したり管理したりする前に、特定の権限が必要です。 これらのアクセス許可の詳細については、セキュリティで保護された操作 - Azure Logic Apps でのアクセスとデータのセキュリティ保護に関するページを参照してください。
接続の作成、構成、認証
ワークフローでコネクタの操作を使用するには、多くのコネクタの場合、まずターゲット サービスまたはシステムへの"接続"を作成しておく必要があります。 ワークフロー デザイナー内からの接続を作成するには、アカウントの資格情報、および場合によっては他の接続情報を使用してご自分の ID を認証する必要があります。
たとえば、ワークフローで Office 365 Outlook 電子メール アカウントにアクセスしてそれを操作するには、そのアカウントへの接続を認可しておく必要があります。 一部の組み込みコネクタとマネージド コネクタの場合は、認証情報を提供する代わりに、マネージド ID を設定して認証に使用することができます。
マネージドコネクタの場合、接続はそれぞれ独自のリソース定義を持つ別々のAzureリソースです。 標準ワークフローの組み込みコネクタでは、接続設定はロジックアプリの設定とともに保存され、 connections.json ファイルや参照されたアプリ設定も含まれます。 接続情報を確認するには、消費型か標準型のワークフローかに基づいて以下の手順に従ってください:
従量課金
Azure portal でこれらの接続を表示および管理するには、「Azure portal の従量課金ワークフローの接続の表示」をご覧ください。
Visual Studio Code 内でこれらの接続を表示および管理するには、Visual Studio Code で従量課金ロジック アプリを表示するを参照してください。
従量課金ワークフローの接続リソース定義の詳細については、接続リソース定義に関するページを参照してください。
Standard
Azure portal でこれらの接続を表示および管理するには、Azure portal の Standard ワークフローの接続の表示に関するページをご覧ください。
Visual Studio Code 内でこれらの接続を表示および管理するには、Visual Studio Code で Standard ワークフローを表示するを参照してください。 connections.json ファイルには、コネクタによって作成された接続に必要な構成が含まれています。
接続のセキュリティと暗号化
接続設定の詳細や秘密を保存するAzureサービスは、それらを静止時に暗号化します。 ストレージおよびアクセス制御は、Standardワークフローにおける管理されたAPI接続と組み込み接続で異なります。 Office 365、Salesforce、GitHubなど、Microsoft Entra ID Open Authentication(Microsoft Entra ID OAuth)を使用する接続はサインインが必要ですが、Azure Logic Appsはユーザーのサインインパスワードではなくアクセストークンやリフレッシュトークンを保存します。
Azure Logic Appsは、リフレッシュトークンが有効でターゲットサービスがアクセスを許可している間にOAuthアクセストークンを更新できます。 リフレッシュトークンは期限切れや取り消しになることがあり、再認証が必要になる場合があります。 認証情報の変更は、アイデンティティプロバイダー、クライアントタイプ、認証フローによってはトークンを無効化する可能性もあります。
注意
組織が Azure Logic Apps のコネクタを介して特定のリソースにアクセスすることを許可していない場合は、Azure Policy を使用して、そのような接続を作成する機能をブロックすることができます。
ロジック アプリのワークフローと接続をセキュリティで保護する方法の詳細については、「Azure Logic Apps におけるアクセスとデータのセキュリティ保護」をご覧ください。
接続のためのファイアウォール アクセス
環境がファイアウォールを使用している場合は、ワークフローやコネクタ操作に必要なトラフィックのみを許可してください:
組み込み操作を使用するコンシューマリーワークフローでは、ワークフローが外部呼び出しを受けるときにインバウンドAzure Logic Appsトラフィックを、ワークフローが外部エンドポイントに呼び出した場合にアウトバウンドトラフィックを許可します。 サポートされている場合は LogicAppsManagement と LogicApps のサービスタグを使用してください。
マネージドまたはカスタムコネクタ操作の場合は、サポートされている場合は AzureConnectors サービスタグを使用してください。 それ以外の場合は、該当するAzureリージョンで必要なマネージドコネクタのアウトバウンドIPアドレスを許可してください。
標準ワークフローでは、Azure App Serviceのネットワーク要件に従い、コネクタ接続で必要とされる完全限定ドメイン名を許可してください。 詳細については、 標準ワークフローのファイアウォール権限を参照してください。
詳細については、ファイアウォールの構成に関するページを参照してください。
カスタム コネクタと API
マルチテナント Azure Logic Apps 用の従量課金ワークフローで、既定のコネクタとして使用できない Swagger ベースまたは SOAP ベースの API を呼び出すことができます。 カスタム API アプリを作成してカスタム コードを実行することもできます。 詳しくは、次のドキュメントをご覧ください。
Swagger ベースまたは SOAP ベースのカスタム コネクタを作成します。これにより、Azure サブスクリプション内の任意の従量課金ロジック アプリ ワークフローでこれらの API を使用できるようになります。
Azure 内でカスタム コネクタを公開し、誰でも使用できるようにするには、Microsoft の認定を受けるためにコネクタを提出してください。
シングルテナント Azure Logic Apps 用の Standard ワークフローでは、任意の Standard ロジック アプリ ワークフローで使用できるネイティブ実行のサービス プロバイダー ベースのカスタム組み込みコネクタを作成できます。 詳しくは、次のドキュメントをご覧ください。