Azure Logic Apps

解決する課題

複数のシステムや SaaS をまたぐ手作業の連携を、コードを書かずに自動化できます。

• メール受信・ファイル到着・スケジュールなどをきっかけに後続処理を自動起動したい
• Salesforce・SharePoint・Outlook・Azure サービスなどをコードレスでつなぎたい
• 承認待ちや外部応答待ちを含む長時間にわたるフローを、状態を保ったまま進めたい
• 一時的な失敗を自動リトライし、失敗時のハンドリングまで含めて運用したい
• B2B（EDI/AS2 など）の企業間取引メッセージを変換・送受信したい

主要概念と用語

• ワークフロー: トリガーと一連のアクションからなる処理の流れ。デザイナー上で視覚的に組み立てる
• トリガー: ワークフローを起動するきっかけ。定期実行（Recurrence）、受信 HTTP 要求、コネクタのイベント（メール受信など）の3系統がある
• アクション: トリガー後に実行する各ステップ。条件分岐・ループ・並列・スコープなどの制御フローを含む
• コネクタ: 外部サービスや Azure サービスへの接続部品。組み込み（ビルトイン）コネクタはランタイムに統合され高速、マネージドコネクタは別基盤で動作する
• Consumption（従量課金）プラン: マルチテナント環境で実行され、アクション実行数で課金される従来型のプラン
• Standard プラン: シングルテナントの専用ランタイムで動作し、1 つのリソースに複数ワークフローを収容できる新しいプラン
• コネクタの分類: トリガー/アクションのほか、Enterprise（B2B/EDI 向け）など用途別の区分がある
• Integration Account: B2B シナリオで取引相手・契約・スキーマ・マップを管理する受け皿

仕様・制限・クォータ

• 2 つのプラン: マルチテナントの Consumption と、シングルテナント専用ランタイムの Standard で、制限値やコネクタの動き方が異なる
• コネクタの種類: 組み込みコネクタはランタイムに同居して低レイテンシ、マネージドコネクタは共有基盤で動作し**スロットリング（呼び出しレート上限）**の対象になりやすい
• 実行時間とサイズ: 1 回の実行時間、メッセージ/ペイロードのサイズ、ループ反復回数などに上限があり、プランによって値が異なる
• 長時間フロー: 承認待ちなどの待機を含む長時間実行に対応するが、保持できる最大期間には上限がある
• スループット: マネージドコネクタの呼び出しはレート制限を受けるため、大量実行では組み込みコネクタやバッチ化を検討する
• 具体的な上限値はプランやコネクタ、リージョンで変動するため、設計時に公式ドキュメントで確認する

内部の仕組み

ワークフローはトリガーが発火すると 1 つの実行（run）を生成し、定義された順にアクションを進めます。各アクションの入力・出力は実行履歴として記録され、どのステップで何が起きたかを後から追跡できます。

Logic Apps はステートフルに動作するのが基本で、各ステップの状態を永続化しながら進みます。これにより、外部からの応答待ちや承認待ちといった長時間の中断を挟んでも実行を継続できます。Standard では、状態を保持しないステートレスワークフローも選べ、短時間・高頻度の処理を低オーバーヘッドで実行できます。

コネクタには2系統あります。組み込みコネクタはワークフローのランタイムに統合されて動くため低レイテンシで、レート制限の影響を受けにくいです。マネージドコネクタは共有のコネクタ基盤を経由して外部サービスへアクセスし、認証情報は接続（connection）として管理されます。マネージドコネクタは便利な反面、呼び出しレートのスロットリング対象になりやすい点に注意します。

アクションが一時的に失敗した場合、Logic Apps はリトライポリシーに従って自動再試行します。さらに、各アクションの実行条件（直前が成功/失敗したときに動かす、など）を設定でき、失敗経路だけ別アクションへ分岐させるといったエラーハンドリングを組み込めます。

設計パターン / ベストプラクティス

• 疎結合な連携の中核: イベント通知は Event Grid、確実なメッセージ引き渡しは Service Bus と組み合わせ、Logic Apps は**オーケストレーション（フローの組み立て）**に専念させる
• 重い処理は外に出す: 計算量の多い処理やカスタムロジックは Azure Functions に切り出し、Logic Apps からは呼び出すだけにすると見通しが良い
• リトライとタイムアウトを明示: 各アクションにリトライポリシーとタイムアウトを設定し、失敗経路（実行条件で「失敗時」）を用意して取りこぼさない
• 冪等に設計: トリガーやリトライで重複起動し得るため、重複実行されても結果が壊れないようにする
• 承認・人手介在のフロー: 承認コネクタやメール応答を使い、人の判断を挟む長時間フローを状態保持のまま実装する
• シークレットは外出し: 接続情報やキーは Key Vault やマネージド ID 経由で扱い、定義に直書きしない

運用・監視

• **実行履歴（run history）**で各実行のステップ単位の入出力・成否を確認でき、失敗箇所を素早く特定できる
• **再実行（resubmit）**で失敗した実行を同じ入力で流し直せる
• Azure Monitor / Log Analytics に診断ログとメトリクスを送り、失敗率や実行回数、スロットリングを可視化・アラート化する
• Application Insights（特に Standard）と連携して、より詳細なテレメトリやトレースを取得できる
• マネージドコネクタのスロットリング発生を監視し、頻発する場合は組み込みコネクタ化やバッチ化を検討する

コスト

Logic Apps のコストはプランで大きく考え方が変わります。Consumption は実行したアクション数に応じた従量課金で、待機中は基本的に課金されません。Standard は専用ランタイムを動かすホスティングのプラン費用が中心になります。

セキュリティ

• マネージド ID: ワークフローにマネージド ID を付与し、Key Vault や Storage などへ資格情報レスでアクセスする
• 接続情報の保護: コネクタの接続やシークレットは Key Vault 連携で扱い、定義への直書きを避ける
• HTTP トリガーの保護: 受信 HTTP 要求トリガーは共有アクセス署名（SAS）や Entra ID 認可、IP 制限などで保護する
• RBAC: ワークフローの参照・編集・実行権限を Azure RBAC で最小権限に絞る
• ネットワーク制御: Standard では VNet 統合やプライベートエンドポイントで閉域化でき、社内システムとの接続を安全にする

Well-Architected の観点

• 運用上の優秀性: ノーコードでフローを可視化でき、実行履歴と再実行で運用しやすい。Infrastructure as Code（ARM/Bicep）で定義を管理し、変更を追跡可能にする
• 信頼性: リトライポリシー・失敗経路・冪等設計で一時障害に耐える。確実な引き渡しが要る箇所は Service Bus を挟んで取りこぼしを防ぐ
• パフォーマンス: 組み込みコネクタの活用や並列実行でスループットを確保し、マネージドコネクタのスロットリングを避ける
• セキュリティ: マネージド ID と Key Vault で資格情報を排除し、トリガーとネットワークを保護する
• コスト最適化: ワークロード特性に合わせて Consumption と Standard を選び、ポーリング頻度や集約でコストを抑える

試験で問われるポイント

関連サービス・比較

Logic Apps は AWS の Step Functions に相当するワークフローオーケストレーションです。ノーコード志向で豊富なコネクタを備える点が特徴で、コードベースで状態機械を定義する Step Functions とは設計思想が少し異なります。

ハンズオン / CLI例

# リソースグループを作成
az group create --name demo-rg --location japaneast

# Consumption プランの Logic App（ワークフロー）を作成
# definition.json にはトリガーとアクションのワークフロー定義を記述する
az logic workflow create \
  --resource-group demo-rg \
  --name demo-workflow \
  --location japaneast \
  --definition @definition.json

# ワークフローの概要を確認
az logic workflow show \
  --resource-group demo-rg \
  --name demo-workflow \
  --query "{name:name, state:state, location:location}" \
  -o table

# 一覧を表示
az logic workflow list \
  --resource-group demo-rg \
  -o table