Azure Logic Apps の コネクタとは
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 内でネイティブで動作するよう作られています。
マネージド コネクタは、Microsoft によって Azure でデプロイ、ホスト、管理されます。 マネージド コネクタはほとんどが、基になるサービスまたはシステムが Azure Logic Apps と通信するために使用する API のプロキシまたはラッパーを提供します。
従量課金ワークフローでは、マネージド コネクタは価格レベルに基づいて、デザイナーで Standard または Enterprise ラベルが付いています。
Standard ワークフローでは、すべてのマネージド コネクタがデザイナーの Azure ラベルの下に表示されます。
詳しくは、次のドキュメントをご覧ください。
トリガー
トリガーはワークフローを開始するために満たすべき条件を指定しており、あらゆるワークフローにおいて常に最初のステップです。 各トリガーはまた、トリガーがイベントを監視したり、それに応答したりする方法を制御する特定の起動パターンに従います。 通常、トリガーは "ポーリング" パターンまたは "プッシュ" パターンに従います。 ときには、両方のトリガー バージョンがあります。
"ポーリング トリガー" を使って、指定されたスケジュールで特定のサービスまたはシステムを定期的にチェックして、新しいデータまたは特定のイベントをチェックします。 新しいデータが利用可能な場合、または特定のイベントが発生した場合、ワークフローの新しいインスタンスが、このトリガーによって作成および実行されます。 この新しいインスタンスから、入力として渡されたデータを使用できます。
Note
Azure で Microsoft が管理、ホスト、および実行するコネクタの場合、ポーリング トリガーは、[間隔] と [頻度] の値のみを使用して、次の繰り返しを計算します。 [At these hours] (設定時刻 (時間))、[At these days] (設定時刻 (日)) などの高度なスケジュール設定オプションは使用しません。 これらのオプションは、[繰り返し]、[Sliding Window] (スライディング ウィンドウ)、[HTTP] トリガーなどの、Azure Logic Apps ランタイムで直接実行される組み込みのポーリング トリガーでのみ機能します。
"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 portal でこれらの接続を表示および管理するには、「Azure portal の従量課金ワークフローの接続の表示」をご覧ください。
Visual Studio でこれらの接続を表示および管理するには、Visual Studio を使用した従量課金ワークフローの管理に関するページを参照し、Azure からロジック アプリ リソースを Visual Studio にダウンロードします。
従量課金ワークフローの接続リソース定義の詳細については、接続リソース定義に関するページを参照してください。
Standard
Azure portal でこれらの接続を表示および管理するには、Azure portal の Standard ワークフローの接続の表示に関するページをご覧ください。
Visual Studio Code でこれらの接続を表示および管理するには、Visual Studio Code でロジック アプリ ワークフローを表示するに関するページをご覧ください。 connections.json ファイルには、コネクタによって作成された接続に必要な構成が含まれています。
接続のセキュリティと暗号化
サーバー アドレス、ユーザー名、パスワード、資格情報、シークレットなどの接続構成の詳細は暗号化され、セキュリティで保護された 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 アプリを作成してカスタム コードを実行することもできます。 詳しくは、次のドキュメントをご覧ください。
Swagger ベースまたは SOAP ベースのカスタム コネクタを作成します。これにより、Azure サブスクリプション内の任意の従量課金ロジック アプリ ワークフローでこれらの API を使用できるようになります。
Azure 内でカスタム コネクタを公開し、誰でも使用できるようにするには、Microsoft の認定を受けるためにコネクタを提出してください。
シングルテナント Azure Logic Apps 用の Standard ワークフローでは、任意の Standard ロジック アプリ ワークフローで使用できるネイティブ実行のサービス プロバイダー ベースのカスタム組み込みコネクタを作成できます。 詳しくは、次のドキュメントをご覧ください。
既知の問題
次の表には、Azure Logic Apps のコネクタに関する既知の問題が含まれています。
| エラー メッセージ | 説明 | 解像度 |
|---|---|---|
Error: BadGateway. Client request id: '{GUID}' |
このエラーは、 1 つ以上の接続で SFTP や SQL などの Microsoft Entra ID OAuth 認証がサポートされていないロジック アプリ リソースでタグを更新した場合に発生し、それらの接続が切断されます。 | この動作を回避するには、それらのタグを更新しないようにします。 |