オンプレ環境で複数システムの連携を自動化するとき、多くのインフラエンジニアはPythonスクリプトやシェルバッチを書いてきたはずです。Azureへ移行したとき、同じ役割を果たすサービスとして真っ先に候補に上がるのが Azure Logic Apps です。GUIでワークフローを組み立て、400以上のコネクターで外部サービスと接続できるiPaaS（Integration Platform as a Service）ですが、「AWS Step Functionsと何が違うのか」「ConsumptionとStandard、どちらを選べばいいのか」という疑問を持つAWS経験者も少なくありません。
この記事では、Azure Logic Appsの基本構造・2つのホスティングモデルの料金と選び方・コネクター設計の注意点・AWS Step Functionsとの使い分けを、オンプレ経験のあるインフラエンジニア向けに整理します。
オンプレのバッチ・スクリプト連携との違い
オンプレでよく見る「夜間バッチがDBから読み出してFTPでファイル転送→翌朝メール通知」という処理は、シェルスクリプトやJavaバッチで実装されてきました。このアプローチには２つの弱点があります。一つは、連携先が増えるたびにスクリプトを改修しなければならない点。もう一つは、失敗時の再実行ロジックやアラート通知を自前で用意しなければならない点です。
Azure Logic Appsはこの「システム間連携・自動化ワークフロー」をGUIで組み上げられるクラウドネイティブなサービスです。実行基盤はAzureが管理するため、サーバーの調達・維持が不要で、エラーの再試行や実行ログの保管も標準で提供されます。
Azure Logic Appsの基本構造
1. 3つの構成要素
Logic Appsのワークフローは次の3要素で成り立ちます。
・トリガー: ワークフローの起動条件。「Blob Storageにファイルが追加されたとき」「HTTP POSTリクエストを受け取ったとき」「cronスケジュールで定時実行」など多数対応しています。
・アクション: トリガー発火後に実行する処理の単位。「Azure SQL Databaseにレコードを挿入する」「Teamsにメッセージを送る」「変数を使って条件分岐する」など、複数のアクションを順番・並列に組み合わせます。
・コネクター: 外部サービスとの接続定義。AzureサービスだけでなくSalesforce・SAP・Slack・Office 365・GitHubなど400以上がサポートされています。
2. ワークフロー定義とIaC
ビジュアルデザイナーで作成したワークフローの実態はJSON形式のワークフロー定義です。このJSONをGitで管理したり、Bicep/Terraformでデプロイしたりする運用が現場では一般的です。GUIで試作してJSONをエクスポートし、環境ごとにパラメーターを差し替えて展開するサイクルが組みやすい構造になっています。
2つのホスティングモデル — ConsumptionとStandard
Logic Appsには料金・性能特性が異なる2種類のホスティングモデルがあります。選択を誤るとコストが想定外に膨らむため、事前の把握が重要です。
1. Consumptionプラン（マルチテナント型・従量課金）
実行されたアクション数に応じて課金される従量課金型です。ワークフローごとに1つのロジックアプリリソースが作成され、Azureが管理するマルチテナント環境で動作します。
・課金単位: アクション実行1回ごと（トリガーとアクションそれぞれ1実行として数える）
・組み込みコネクター: 毎月100万アクション実行まで無料、超過分は安価
・マネージドコネクター（Enterprise）: SalesforceやSAPなどは1実行あたりの単価が高く、高頻度では積み上がりやすい
・向いているケース: 実行頻度が低い・PoC段階・不定期バッチ・開発・検証環境
2. Standardプラン（シングルテナント型・固定課金）
Azure App Serviceと同様のvCoreベース固定課金型です。1つのロジックアプリリソース内に複数のワークフローを同居できるため、ワークフロー数が多いほどコスト効率が高まります。
・課金単位: vCore×稼働時間（ストレージ料金別途）
・組み込みコネクター: アプリ内で実行するため追加料金なし
・VNet統合: Standardプランのみ対応。オンプレやプライベートエンドポイントへの接続が必要な本番環境で必須
・向いているケース: 高頻度実行・本番ワークフローが多数・閉域ネットワーク接続が必要なケース
3. プラン選択の判断基準
| 観点 | Consumptionプラン | Standardプラン |
|---|---|---|
| 課金モデル | 従量課金（アクション単位） | 固定課金（vCore×時間） |
| 実行頻度 | 低頻度・不定期向き | 高頻度・常時稼働向き |
| VNet統合 | 非対応 | 対応 |
| 1リソース内のワークフロー数 | 1つのみ | 複数同居可能 |
| 組み込みコネクター追加費用 | 無料枠あり・超過分あり | 追加費用なし |
おおむね1日数十回以下の実行であればConsumptionが有利ですが、Enterpriseコネクター（SalesforceやSAP）を多用するケースでは予想外にコストが上がります。正確な見積もりは Azure Pricing Calculatorで事前確認する習慣をつけましょう（Azureにも同様の計算ツールがあります）。
料金の実例（2026年9月時点・東日本リージョン）
Consumptionプランの主要な料金区分は以下のとおりです（2026年9月時点）。
・組み込みアクション: 毎月最初の100万アクション実行が無料。それ以降は約¥0.003/実行
・マネージドコネクター（Standard）: Office 365・SharePointなど、約¥0.019/実行
・マネージドコネクター（Enterprise）: Salesforce・SAPなど、約¥0.19/実行
具体例として、「1日5回・20アクション構成のワークフローを1か月稼働」する場合、月間実行数は5×20×30＝3,000アクションとなり組み込みコネクターのみであれば実質無料枠に収まります。しかし同じ構成でEnterpriseコネクターを使うと月3,000×¥0.19＝約570円となり、ワークフロー数が増えるにつれコストが積み上がります。
AWS Step Functionsとの違いと使い分け
AWSユーザーにとって AWS Step Functions は比較対象として真っ先に浮かぶはずです。両サービスの本質的な違いは設計思想にあります。
| 観点 | Azure Logic Apps | AWS Step Functions |
|---|---|---|
| 主な用途 | システム間連携・外部SaaS統合（iPaaS） | マイクロサービスのオーケストレーション |
| 設計スタイル | GUIフロー中心（ローコード寄り） | Amazon States Language（コード寄り） |
| 外部SaaS連携 | 400以上のマネージドコネクター | AWSサービス中心・外部連携はLambda経由 |
| エラーハンドリング | Run After設定・Scope単位でtry/catch | CatchとRetryをJSONで厳密に定義 |
| 状態管理 | ステートレス/ステートフル両対応 | ステートフル管理が得意（実行履歴保持） |
| ローコード度 | 高い（GUIで大半が完結） | 低い（定義はすべてコード記述） |
「SalesforceやTeams・Office 365といった外部SaaSとAzureサービスをノーコードで繋ぎたい」「開発チームのコーディング負担を減らしたい」場合はLogic Appsが適しています。一方「複雑な分岐条件を持つマイクロサービスの状態管理が必要」「ビジネスロジックをコードで厳密に定義・テストしたい」場合はStep Functionsの発想の方が自然です。
Azureのイベント駆動アーキテクチャでは、Logic Appsを Azure Service Bus や Azure Event Grid と組み合わせる構成が実務でよく使われます。EventGridがイベントをService Busに流し、Logic AppsがService Busをポーリングして後続処理を起動する、というパターンはオンプレの非同期バッチ処理を置き換える際に有効です。
実務設計のポイント
1. コネクター選択の落とし穴
コネクターには「組み込みコネクター（Built-in）」と「マネージドコネクター（Managed）」の2種類があります。マネージドコネクターはMicrosoftが管理するIPCサーバー上で実行されるため、Consumptionプランでは呼び出しのたびに課金されます。Standardプランでは主要なコネクター（Service Bus・SQL・Storageなど）が組み込みとして動くため、1日数百回以上使う連携にはStandardプランを選んだ方が結果的に安くなるケースがほとんどです。設計前にコネクターの種別と料金区分を確認する習慣をつけましょう。
2. エラーハンドリングとべき等性
各アクションにはデフォルトで自動リトライ（最大4回・指数バックオフ）が設定されています。便利な反面、連携先のAPIがべき等（同じリクエストを複数回送っても副作用が一度だけ）でない場合、リトライによる二重処理が発生します。発注・決済など重要なビジネスロジックには、リクエスト側でユニークキー（べき等キー）を付与するか、連携先側でトランザクション管理を実装する設計が必要です。
エラー発生時の後続処理制御は「Run After」設定で行います。成功時のみ実行・失敗時のみ実行・タイムアウト時も実行など、アクション単位で柔軟に分岐できます。重要なワークフローには必ずエラー通知アクション（Teamsへのアラート送信など）を組み込みましょう。
3. VNet統合とプライベート接続
オンプレや閉域ネットワーク上のシステムと接続する場合はStandardプランのVNet統合を使います。Azure Private Link と組み合わせることで、パブリックインターネットを通らずにAzure SQLやStorage Accountにアクセスできます。金融・医療など通信経路に厳しい要件がある本番ワークフローでは必須の設計パターンです。
よくあるトラブルと対処法
・コネクターの接続が突然切れる: OAuth2.0を使うマネージドコネクター（Office 365など）はアクセストークンが期限切れになると接続エラーになります。サービスプリンシパルまたはManaged Identityに切り替えることで自動更新の手間をなくせます。
・HTTPアクションのタイムアウト: ConsumptionプランのHTTPアクションはデフォルト90秒でタイムアウトします。長時間処理が必要な場合は202 Acceptedを返す非同期パターン（状態確認ポーリングループ）を実装してください。
・実行ログが追えない: ワークフロー実行履歴はConsumptionプランで30日保持ですが、件数が多いと調査しにくくなります。Application Insightsとの統合を設定して長期ログを確保しましょう。
・送信元IPが変わってIP制限に引っかかる: StandardプランのVNet統合では、明示的にNAT Gatewayを設定しないと送信元IPが変動します。外部システムにIP制限をかけている場合は必ずNAT Gatewayまたは固定IPの設計を入れてください。
本記事のまとめ
Azure Logic Appsは、外部SaaS統合・クラウドサービス連携・イベント駆動ワークフローを素早く構築するためのiPaaSです。AWS Step Functionsとは用途が異なり、「コードを書かずにサービスを繋ぐ」という場面で本領を発揮します。
・低頻度実行・PoC: Consumptionプランから始め、コスト感を把握する
・高頻度・VNet統合・本番: Standardプランに移行し、複数ワークフローを同居させてコストを最適化
・Step Functionsとの使い分け: Logic AppsはiPaaS（外部サービス連携）、Step Functionsはマイクロサービスオーケストレーション
・エラー設計を先に決める: リトライのべき等性とRun After設定は設計段階から組み込む
・VNet統合が必要なら最初からStandard: ConsumptionからStandardへの後付け移行はワークフローの再作成が必要になるケースがある
Service BusやEvent Gridと組み合わせることで、Azureのイベント駆動アーキテクチャをより堅牢に設計できます。まずはConsumptionプランで小さなワークフローを試し、運用感を掴んでから本番設計に進めるのがオンプレ経験者には合っているアプローチです。
PR
AWSを中心としたクラウド設計のベストプラクティスを体系的に解説。ワークフロー設計やサービス連携パターンも含め、クラウド移行を進めるインフラエンジニアにとって手元に置きたい一冊です。
