Azure Logic Appsとは？仕組み・ConsumptionとStandardの違い・料金と採用判断を実装者目線で解説

Azure Logic AppsはMicrosoft Azureのクラウド統合サービスで、アプリ・データ・API・オンプレミスのシステムをコードをほとんど書かずにつなぎ、業務処理を自動化するワークフローを組めます。実装で最初に押さえるべきは、トリガーとアクションを連ねる基本モデル、マルチテナントのConsumptionと単一テナントのStandardという2つのホスティング、そして1,400以上のコネクタと課金の関係です。この記事では定義から、料金を左右するプラン選択、Azure FunctionsやPower Automate・AWS Step Functionsとの違い、そして「どんなシステムで採用し、どこでは見送るか」の判断基準までを、2026年時点の公式ドキュメントに基づいて整理します。

まとめ：Azure Logic Appsの要点と採用判断の分岐

Azure Logic Appsは、複数のサービスをまたぐ業務フローを、視覚的なデザイナーとコードビューの両面で組み立てられるマネージドな統合基盤です。処理はトリガー（起点）とアクション（後続処理）の並びで表現し、SaaSやAzureサービスへの接続はコネクタが担います。ホスティングはConsumption（従量課金・マルチテナント）とStandard（コンピューティング課金・単一テナント）の2択で、旧来のISEは2024年8月に提供を終了しています（2026年時点）。

採用が合理的なのは、Azure中心の環境で、SaaS連携・定期バッチ・イベント駆動の処理を短期間で組み、運用を含めてマネージドに寄せたい場合です。逆に、複雑なビジネスロジックをコードで細かく制御したいならAzure Functions、Microsoft 365中心で現場担当者が自作するならPower Automateが向きます。自社システムでどの基盤を組み合わせるべきか迷う段階なら、設計から相談できる開発会社に早めに当たると手戻りを防げます。

Azure Logic Appsの仕組みとトリガー・アクションの基本構造

Logic Appsは「ワークフロー」を実行単位とする統合サービスです。ひとつのワークフローは、処理を起動するトリガーと、その後に続く一連のアクションで構成します。プログラムのループ・条件分岐・並列実行に相当する制御も、コードではなくワークフロー上の部品として配置します。

iPaaSとワークフローエンジンとしてのLogic Appsの位置づけ

Logic Appsは、システム間連携をクラウド上で提供するiPaaS（Integration Platform as a Service）に分類され、同時にサーバーレスのワークフローエンジンとして振る舞います。想定する用途は、SaaS間のデータ同期、フォーム受信をきっかけにした通知・承認、定期実行のバッチ、ファイル到着やメッセージ受信を起点にしたイベント駆動処理です。サービスやシステムをまたいで処理をつなぐという観点は、オーケストレーションと自動化の違いを整理した記事で前提を確認しておくと、この後のトリガー設計やコネクタの話が読み解きやすくなります。

トリガーとアクションを連ねて組むワークフロー全体の実行モデル

ワークフローは必ず1つのトリガーから始まります。トリガーの型は、一定間隔で起動するRecurrence、HTTP要求を受けるRequest、コネクタがサービスをポーリングして新着を検知する方式、Webhookで通知を待つ方式の4種類です。トリガーが発火すると、後続のアクションが上から順に、または条件・並列・繰り返しの制御に従って実行されます。1回の起動から完了までが1つの「実行（run）」として記録され、各アクションの入出力を実行履歴から追跡できる点が、デバッグと運用監視の土台になります。

デザイナーとコードビュー（ワークフロー定義言語）の二つの編集面

ワークフローは、ブラウザー上のビジュアルデザイナーで部品を並べて組めるほか、コードビューでワークフロー定義言語（JSON形式のスキーマ）を直接編集できます。この定義はAzure Resource Manager（ARM）テンプレートやBicepに載せてデプロイできるため、Gitでのバージョン管理やCI/CDパイプラインへの組み込みに向いた構造です。画面でプロトタイプを作り、確定した定義をコードとして管理する二段構えが、実装者にとっての標準的な進め方になります。

ConsumptionとStandardという2つのホスティングモデル

Logic Appsを実装するうえで最初に決めるのがホスティングです。同じワークフローでも、載せる基盤によって課金・性能・ネットワーク制御が変わります。旧ISEが提供終了した現在、選択肢はConsumptionとStandardの2つです。

マルチテナントで従量課金のConsumptionプランの特性

Consumptionは、Microsoftが運用するマルチテナント基盤上で動く従来型のプランです。1つのロジックアプリに1つのワークフローを持ち、実行したアクションやトリガーの回数に応じて課金される純粋な従量制で、待機中はコストが発生しません。小規模な連携やイベントが散発的な処理、まず素早く動かして検証したい用途に向きます。一方で、専用のネットワーク分離や、1リソースに複数ワークフローをまとめる構成は取れません。

シングルテナントでFunctions基盤のStandardプラン

Standardは、単一テナントのAzure Logic Appsランタイムを、Azure Functionsの拡張機能として動かすプランです。1つのロジックアプリに複数のワークフローを同居させられ、仮想ネットワーク統合やプライベートエンドポイントによる閉域接続に対応します。課金はアクション単位ではなく、割り当てたコンピューティング（Workflow Standardプランのメモリ・vCPU）とストレージトランザクションに基づく形です。安定した処理量があり、閉域要件やローカル開発・コンテナー実行を求める本番システムはStandardが基本線になります。

ステートフルとステートレスという2つのワークフロー実行の違い

Standardでは、ワークフローをステートフルとステートレスから選べます。ステートフルは各アクションの状態と実行履歴をAzure Storageに保存し、長時間実行や中断・再開、詳細な履歴追跡ができる方式です。ステートレスは状態をメモリ上だけで扱い、履歴を既定では残さない代わりに、起動が速く短時間の同期処理に向きます。Consumptionはステートフル相当のみで、ステートレスを選べるのはStandard固有の利点です。応答速度が要る軽量処理はステートレス、監査可能性や長時間処理が要る基幹連携はステートフル、と役割で振り分けます。

コネクタの種類とConsumption・Standardの料金設計

Logic Appsの表現力とコストを同時に左右するのがコネクタです。1,400以上のコネクタが用意され（2026年時点）、これらをどの種類で使うかが、性能と料金の両面に効いてきます。ここを設計段階で意識しないと、動いてから課金が膨らむパターンに陥ります。

組み込みコネクタとマネージドコネクタの実行場所とコストの違い

コネクタは大きく2系統です。組み込み（ビルトイン）コネクタはLogic Appsランタイムと同じプロセス内で動き、スループットが高く、コネクタ実行としての個別課金が乗りにくい種類です。マネージド（Azure）コネクタはMicrosoftが運用する共有基盤上で動き、SalesforceやSAP・SQL・Office 365など外部SaaSへの接続を担う代わりに、呼び出しごとに課金されます。たとえばAzure Blob Storageの仕組みを解説した記事で扱うストレージへの読み書きも、こうしたコネクタ経由でワークフローに取り込めるのが利点です。高頻度で叩く接続ほど組み込み側に寄せられるかを検討すると、コストを抑えやすくなります。

ConsumptionとStandardで異なる課金モデルの構造

課金の考え方はプランで根本的に異なります。実測見積もりでは、この違いを取り違えると桁がずれます。

Consumptionはトリガーとアクションの実行回数、加えてマネージドコネクタの呼び出し回数で課金され、動いた分だけ払う構造です。散発的なイベントほど安上がりです。Standardは処理量にかかわらず割り当てたプランの固定コストがかかる代わりに、実行が多いほど1件あたりの単価が下がり、閉域や複数ワークフロー集約の価値も得られます。月間の実行回数がおおよその損益分岐で、少量ならConsumption、恒常的な負荷ならStandardが目安になります。

Azure Functions・Power Automate・AWSサービスとの違い

Logic Appsは似た役割のサービスと混同されやすく、選定でつまずきやすい領域です。それぞれの守備範囲を押さえると、単独で使うか組み合わせるかの判断がつきます。

Azure Functionsとの使い分け（ローコードかコードか）

Azure Functionsはコードファーストのサーバーレス実行環境で、任意の言語で細かなロジックを書きます。Logic Appsはローコードの統合・オーケストレーションが主眼で、接続と制御フローを部品で組む方式です。両者は競合ではなく補完で、実務では「Logic Appsで全体の流れとSaaS連携を組み、複雑な計算や独自処理だけFunctionsを呼び出す」構成がよく取られます。判断軸は単純で、既製コネクタで足りるならLogic Apps、コードでしか書けない処理が中心ならFunctionsです。

Power AutomateとLogic Appsの対象利用者の違い

Power AutomateはLogic Appsと同じエンジン系譜にありますが、対象利用者が異なります。Power Automateは現場の業務担当者（メーカー）がMicrosoft 365中心の定型作業を自作するための製品で、ユーザー単位・フロー単位のライセンスで提供されます。Logic Appsは開発者・IT部門が、ARMテンプレートやCI/CDでコードとして管理し、Azure Monitorで監視する開発者向けの基盤です。ガバナンスとIaCが要る組織横断の連携はLogic Apps、個人や部門の効率化はPower Automate、と切り分けます。

AWSのStep Functions・EventBridgeとの対応関係

マルチクラウドやAWSからの移行を検討する際は、対応物を押さえると設計を横展開できます。ワークフローのオーケストレーションという役割は、AWSではAWS Step Functionsの仕組みを解説した記事で扱うステートマシンが近い立ち位置です。ただしLogic Appsは1,400以上のSaaSコネクタを内包する点が特徴で、イベントの受配信という側面はAmazon EventBridgeを解説した記事の役割にも重なります。AWS側はStep Functions・EventBridge・各種SDKを組み合わせて実現する範囲を、Azureでは1サービスに寄せられる、と捉えると比較しやすくなります。

Azure Logic Appsを採用すべき場面と見送る場面

ここからは判断です。Logic Appsは万能の自動化基盤ではなく、向く用途と向かない用途がはっきり分かれます。要件から逆算し、条件付きで採否を言い切ります。

Logic Appsの採用が第一候補として合理的になる主な条件

次のいずれかに該当するなら、Logic Appsが第一候補になります。

• Azure中心の環境で、SaaSやAzureサービス間のデータ連携を短期間で組みたい
• ファイル到着・メッセージ受信・スケジュールを起点にした処理を自動化したい
• 承認や通知を含む業務フローを、実行履歴付きで運用・監査したい
• AS2やX12・EDIFACTを使うB2B/EDI連携を統合アカウントで構築したい

いずれもコネクタとマネージド運用の強みが効く領域です。特にサーバー管理を持たずに連携を回したい場合、待機コストのないConsumptionから小さく始められる点が実装のハードルを下げます。

Logic Appsを選ぶべきでない場面と適切な代替サービス

一方で、次の要件にはLogic Appsを選びません。ここを混同すると設計が破綻します。第一に、ミリ秒単位の低遅延や高スループットの計算処理が中心なら、ローコードのオーバーヘッドが不利で、Azure Functionsやコンテナーの領分です。第二に、既製コネクタでは表現できない複雑なビジネスロジックが主体なら、無理にワークフローで組まずコードで書くべきです。第三に、Microsoft 365内で完結する個人の定型作業なら、開発者向けのLogic Appsより現場が自作できるPower Automateが適します。第四に、コスト度外視で高頻度にマネージドコネクタを叩く設計は、呼び出し課金が積み上がる失敗パターンで、組み込みコネクタへの寄せや実行頻度の見直しが要ります。

受託開発におけるワークフロー基盤の設計相談と外注先選定の勘所

実際のシステムでは、Logic Apps単体ではなくAzure Functions・Service Bus・Storage・データベースを役割ごとに組み合わせる構成が普通です。どの処理をどのプラン（Consumption／Standard）に載せ、どこを組み込みコネクタに寄せるかは、実行頻度・閉域要件・月次コストのトレードオフで決まり、運用開始後のプラン変更には移行の手間が伴います。要件定義の段階で全体設計を固めておくほど、後の作り直しを避けられる設計です。Azureを含むクラウド基盤の構築・移行の相談では、ワークフロー基盤の選定を含めた設計から実装・運用までを一貫して支援できます。

よくある質問

Azure Logic Appsの実装検討でよく挙がる質問を、公式ドキュメントの仕様に沿って整理します。

Azure Logic AppsとPower Automateはどう違いますか？

両者は同じワークフローエンジンの系譜ですが、対象と提供形態が異なります。Logic Appsは開発者・IT部門向けで、ARMテンプレートやCI/CDでコードとして管理し、Azureのリソースとして監視・運用する立場です。Power Automateは業務担当者がMicrosoft 365中心の作業を自作する製品で、ユーザー単位のライセンスで使います。組織横断でガバナンスやIaCが要る連携はLogic Apps、個人や部門の効率化はPower Automateが向きます。

ConsumptionとStandardはどちらを選べばよいですか？

実行が散発的で待機時間が長い連携、まず素早く検証したい用途はConsumptionが向きます。恒常的な処理量があり、仮想ネットワークによる閉域接続や1リソースへの複数ワークフロー集約、ステートレス実行が要る本番システムはStandardが基本です。月間の実行回数が損益分岐の目安で、少量なら従量のConsumption、負荷が安定するならコンピューティング課金のStandardが有利になります。

Azure Functionsと併用する必要はありますか？

必須ではありませんが、実務では補完的に併用する構成が多くなります。全体の流れやSaaS連携はLogic Appsのコネクタで組み、既製部品では表現できない複雑な計算や独自ロジックだけをAzure Functionsに切り出して呼び出す形です。既製コネクタで完結するならLogic Apps単体で足り、処理の中心がコードならFunctions主体に寄せる、と役割で判断します。

料金はどの要素で決まりますか？

プランで構造が変わります。Consumptionはトリガーとアクションの実行回数に加え、マネージドコネクタの呼び出し回数で課金される従量制です。Standardは割り当てたWorkflow Standardプランのコンピューティングとストレージトランザクションが基準で、待機中も固定費がかかります。高頻度でマネージドコネクタを叩くほどConsumptionの単価が積み上がるため、実行頻度とコネクタ種別が見積もりの勘所です。

AWSのStep Functionsと互換性はありますか？

直接の互換性はなく、定義形式もAPIも別物です。ただしワークフローのオーケストレーションという役割は対応し、AWSではStep FunctionsのステートマシンとEventBridgeのイベント連携、各種SDKを組み合わせる範囲を、AzureではLogic Appsに寄せられます。移行時は処理の流れを設計思想の対応関係で置き換え、コネクタ相当の連携を作り直す形になります。

関連記事

• オーケストレーションとは？自動化との違いと種類・企業の導入判断を解説：Logic Appsが担う処理連携の土台となる概念を確認できます。
• AWS Step Functionsとは？ステートマシンの仕組み・料金と2種のワークフロー・採用判断を実装者目線で解説：AWS側のワークフロー対応物と読み比べ、クラウド選定の判断材料になります。
• Amazon EventBridgeとは｜イベント駆動連携の仕組み・料金・実装と採用判断を解説：イベント駆動連携の対応物として設計思想を対比できます。
• Azure Blob Storageとは？仕組み・Blobの種類とアクセス層・S3との違いを実装者目線で解説：コネクタの接続先となるAzureストレージの前提を押さえられます。