Azure Logic Apps

Azure Logic Appsは、ドラッグ アンド ドロップ デザイナーを使って自動化されたワークフローを視覚的に構築できる、ローコード／ノーコードの統合プラットフォームです。各ワークフローは、ワークフローを開始するイベントであるトリガーと、順番に実行される 1 つ以上のアクションで構成されます。Logic Apps には、事前構築済みのコネクタを通じて、Office 365、Salesforce、ServiceNow、Azure SQL、Blob Storage など数百のサービスを接続できます。統合コードを最初から記述する必要はありません。

Logic Apps と Azure Functions はどちらもイベント駆動型のサーバーレス自動化を実現しますが、対象とするユーザーは異なります。Logic Appsは、エンタープライズコネクタを利用した視覚的なノーコードワークフローを好む統合スペシャリストやビジネスアナリスト向けに設計されています。Azure Functionsは、プログラミング言語を完全に制御し、カスタムビジネスロジックや低レイテンシを必要とする開発者向けに設計されています。複雑な条件分岐やパフォーマンスが重要な処理には Azure Functions が適しており、SaaS 統合やビジネスプロセスの自動化には Logic Apps が適しています。

Logic Apps には 2 つのホスティングプランがあります。Consumption（クラシック）は共有マルチテナントインフラストラクチャ上でワークフローを実行し、アクションの実行ごとに課金されます。実行頻度の低い自動化に適しています。Standardは専用のシングルテナント App Service インフラストラクチャ上で実行され、VNet 統合、マネージド API を使用したカスタムコネクタ、Logic App あたりの複数ワークフローをサポートします。Standard は App Service と同様に、プランの時間単位で課金されます。コンプライアンス上の分離や VNet 接続が必要なエンタープライズワークフローには Standard を選択してください。

Logic Apps のワークフローは、特定のイベントが発生したときに起動するトリガーから始まります。ポーリングトリガーは、一定の間隔でサービスを確認します（たとえば Outlook の「新しいメールを受信したとき」は 1 分ごとに確認します）。プッシュトリガーは Webhook を使用し、イベントが発生するとすぐに起動します（たとえば「HTTP 要求を受信したとき」）。繰り返しトリガーはスケジュールに従って起動します。トリガーの出力データ（メール本文や HTTP ペイロード）は、ワークフロー内の後続するすべてのアクションで使用できます。

アクションは、トリガーの後に実行されるステップです。各アクションでは、特定のサービスまたはプロトコル用に事前構築された統合アダプターであるコネクタを使用します。Logic Apps には、Office 365 Outlook、SharePoint、Azure SQL Database、Salesforce、Slack、Twitter/X、SAPのほか、汎用的な HTTP、SFTP、FTP コネクタなど、400 種類を超える組み込みコネクタとマネージドコネクタがあります。マネージドコネクタでは、認証と接続管理が自動的に処理されます。

Logic Apps は標準的な制御フロー構造をサポートしています。Condition アクションは、式に基づいてワークフローを分岐させます（例：orderTotal > 1000）。Switch アクションは、値に基づいて異なる分岐へ振り分けます。For Each ループは配列を反復処理します（例：メールの各添付ファイルを処理する）。Until ループは、条件が true になるまでアクションを繰り返します。これらの構造はすべて、デザイナー上で視覚的に設定することも、ワークフロー定義内の JSON として設定することもできます。

Logic Apps では、アクション間でデータを変換したり参照したりするために式言語を使用します。式は @{...} で囲み、文字列（concat、toLower）、配列（length、first、filter）、日付（utcNow、addDays）、JSON 操作、ワークフロー参照（triggerBody()、outputs('ActionName')）用の組み込み関数をサポートします。これらの関数は、ステップの実行時に実行時評価されます。

Logic Apps の各アクションには、実行タイミングを制御するRun After 設定があります。前のステップが成功した後、失敗した後、タイムアウトした後、またはスキップされた後のいずれかを指定できます。これにより、堅牢なエラー処理が可能になります。たとえば、前のステップが失敗した場合にのみ補償処理やアラート処理を実行するアクションを追加できます。各アクションには、下流サービスからの一時的な障害を自動的に処理するための再試行ポリシー（固定間隔、指数バックオフ）も設定できます。

Logic Apps は、主要な Azure サービスとトリガーおよびアクションの両方として直接統合できます。ストレージコンテナーに Blob が追加されたときにワークフローを起動し、結果をAzure SQL Databaseに書き込み、Azure Service Busにメッセージを送信し、カスタムロジックのためにAzure Functionを呼び出し、結果をLog Analytics ワークスペースに記録できます。このため Logic Apps は、カスタムコードなしで特殊な Azure サービスをつなぎ合わせる効果的なオーケストレーション層として機能します。

Logic Apps のすべてのワークフロー実行は実行履歴に記録され、Azure portal からアクセスできます。各実行について、個々のアクションレベルで入力、出力、実行時間、エラーメッセージを確認できるため、デバッグが容易です。診断ログを有効にすると、実行履歴とトリガーログを Log Analytics ワークスペースに送信して、長期的な分析やアラートに利用できます。RunsFailed メトリックに対する Azure Monitor アラートを設定し、ワークフローの障害を検出してください。

次の用途にはLogic Appsを選択します。SaaS とエンタープライズ アプリケーションの統合（Salesforce、SAP、ServiceNow）、承認ワークフローを含む業務プロセスの自動化、ファイルのアップロードをトリガーとする ETL パイプライン、通知およびアラートのワークフロー、また、開発者ではない利用者（ビジネス アナリスト）がコードを書かずにワークフローの手順を変更する必要があるシナリオです。高頻度かつ低レイテンシーが求められるシナリオ（代わりに Azure Functions を使用します）や、式言語では利用できない複雑なプログラミング構造が必要な場合は、Logic Apps の使用を避けてください。

このレッスンでは、Azure Logic Appsが 400 以上の事前構築済みコネクタによるローコードのワークフロー自動化を提供すること、Run After の設定によってアクションごとにきめ細かなエラー処理を実現できること、そして開発者ではない利用者がワークフローを変更する必要があるSaaS 統合および業務プロセスの自動化に Logic Apps が適していることを学びました。次は Event Grid とイベント駆動アーキテクチャについて説明します。