AWS Step Functions徹底解説：Cloud Workflows・Azure Logic Apps比較で学ぶサーバーレスワークフロー設計ガイド

はじめに（要点とこの記事で得られること）

AWS Step Functions は、Lambda や ECS、SageMaker など複数の AWS サービスを「ワークフロー（ステートマシン）」としてつなぎ、分散アプリケーションや業務プロセスを視覚的にオーケストレーションできるサーバーレスサービスです。

Google Cloud では Cloud Workflows、Azure では Logic Apps が近い立ち位置で、それぞれ「マネージドなワークフロー / オーケストレーション基盤」として、マイクロサービスやバッチ処理、データパイプラインの自動化に使われています。

この記事では、

Step Functions の仕組み・特徴
代表的なユースケース（ETL、マイクロサービス連携、機械学習パイプラインなど）
標準ワークフローと Express ワークフローの違い
エラー処理・リトライ・並列処理などの設計ポイント
GCP Cloud Workflows、Azure Logic Apps との比較

を、具体例とサンプル定義を交えながら丁寧に解説します。

想定している読者像は、次のような方たちです。

Lambda やコンテナをすでに使っていて、そろそろ「ワークフロー」を整えたいバックエンドエンジニア
データパイプラインやETL、MLパイプラインをサーバーレスで実装したいデータエンジニア・MLエンジニア
障害時のリトライや人手レビューを含む業務フローを自動化したい SRE / 情シス・業務システム担当
GCP Cloud Workflows や Azure Logic Apps と比較しながら、自社に合うクラウドを検討しているアーキテクト・テックリード

読み終わるころには、「この処理は Lambda 単体ではなく Step Functions で組んだ方が良さそう」「GCP / Azure で同じことをするならこういうサービス」といった判断を、チームに説明できる状態を目指しますね。

1. AWS Step Functions とは？──「処理の流れ」をクラウドに描くサービス

1-1. サービス概要と基本コンセプト

AWS Step Functions は、AWS 上のサービスや自前の Lambda / コンテナなどを「状態（ステート）」として組み合わせ、順次・分岐・並列・待機などを定義したワークフロー（ステートマシン）を実行するためのサーバーレスオーケストレーションサービスです。

特徴をざっくりまとめると、次のようなイメージになります。

各処理ステップは Lambda・Activity（独自コンポーネント）・他AWSサービス呼び出しなど
ステップ間の流れ（成功時・失敗時の分岐、並列実行、待機など）を JSON（Amazon States Language）で定義
コンソール上で視覚的なフローチャートとして確認・デバッグできる
エラー時のリトライ・フォールバック・タイムアウトなどを宣言的に設定可能
実行履歴がタイムライン形式で残り、どのステップで失敗したか追いやすい

「コードの中に if / for / try-catch でギチギチに書いていた処理の流れを、一段外側に取り出してクラウド側で管理してもらう」というイメージを持っていただくと、感覚が掴みやすいと思います。

Step Functions 自体もサーバーレスで、同時実行数やスループットに合わせて自動的にスケールします。

1-2. どんな場面で使うもの？

よくあるパターンとしては、次のようなものがあります。

いくつかの Lambda や ECS タスクを順番・条件付きで実行したい
外部APIやバッチ処理が絡み、タイムアウト・リトライ・エラー分岐をきちんと設計したい
ETL や機械学習パイプラインなど「段階的な処理」をサーバーレスで作りたい
人間の承認ステップ（メール・チャット・専用画面など）を含む業務フローを自動化したい

これらをすべてアプリケーションコード側で制御すると、どうしても処理フローが肥大化してしまいがちですが、Step Functions に「流れ」を切り出すことで、個々の Lambda / コンテナは純粋なビジネスロジックに集中させることができます。

2. 他クラウドの類似サービス：Cloud Workflows・Logic Apps の立ち位置

2-1. Google Cloud Workflows

Google Cloud Workflows は、GCP 上のサービス（Cloud Run、Cloud Functions、BigQuery など）や任意の HTTP API を、定義した順序や条件で実行することができるフルマネージドのワークフローサービスです。

特徴としては：

YAML / JSON でワークフローを定義
Cloud Run / Cloud Functions / 各種REST API をステップとして呼び出せる
条件分岐・ループ・エラー処理などが記述可能
データパイプラインやバッチジョブの自動化にもよく使われる

Step Functions 同様、GCP版の「分散処理オーケストレーター」と考えるとよいです。

2-2. Azure Logic Apps

Azure Logic Apps は、ローコードでワークフローを組める Azure の自動化・統合プラットフォームです。Web ベースのデザイナーで各種コネクタ（Teams、Outlook、Salesforce、SAP、Service Bus、オンプレシステム等）をつなぎ、業務プロセスを自動化できます。

主な特徴は：

GUI でコネクタを並べてフローを設計できるローコード志向
Azure 内外・オンプレミスの多様なサービスと接続可能
ビジネスプロセス自動化・システム連携・EDIなどのエンタープライズ用途でよく利用
従量課金プランと Standard（シングルテナント）プランがあり、VNet 連携・オンプレホストなども可能

Step Functions / Cloud Workflows が「開発者向けオーケストレーション寄り」、Logic Apps は「業務統合・ローコード寄り」という色合いが少し強いイメージです。

3. Step Functions の基本構造：ステートマシンと Amazon States Language

3-1. ステートマシン（State Machine）とは？

Step Functions では、ワークフロー全体を「ステートマシン（State Machine）」として定義します。各ステップは「ステート（状態）」と呼ばれ、代表的な種類として：

Task（具体的な処理：Lambda呼び出しなど）
Choice（条件分岐）
Parallel（並列分岐）
Map（配列に対する繰り返し処理）
Wait（待機）
Pass（データの受け渡しのみ）
Succeed / Fail（正常終了 / 失敗）

などがあります。

これらを JSON で記述したものが「Amazon States Language（ASL）」で、コンソールでそのままフローチャートとして可視化されます。

3-2. かんたんな ASL の例

たとえば、「入力を検証して、OKなら処理、本番エラーなら別処理」という超シンプルなフローは、イメージとして次のように書けます。

{
  "Comment": "シンプルなサンプルフロー",
  "StartAt": "ValidateInput",
  "States": {
    "ValidateInput": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:REGION:ACCOUNT_ID:function:validate-input",
      "Next": "Process"
    },
    "Process": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:REGION:ACCOUNT_ID:function:process",
      "Catch": [
        {
          "ErrorEquals": ["States.ALL"],
          "Next": "HandleError"
        }
      ],
      "End": true
    },
    "HandleError": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:REGION:ACCOUNT_ID:function:handle-error",
      "End": true
    }
  }
}

ASL では、Catch や Retry などの構文でエラー処理を宣言的に書けるため、アプリケーションコード側の try-catch がかなりスッキリしてきます。

3-3. データの受け渡しと JSON 変換

各ステートは、入力 JSON を受け取り、出力 JSON を次のステートへ渡します。このとき、JSONPath 記法や JSONata ベースの変換機能を使って、必要な項目だけ抜き出したり、形を変えたりできます。

特定フィールドだけを次ステップに渡す
入力と出力をマージする
配列をフィルタリングする

など、ちょっとした加工であればコードを書かずに ASL だけで実現できるのも、Step Functions の魅力のひとつです。

4. 標準ワークフローと Express ワークフローの違い

Step Functions には、大きく分けて 2 種類のワークフロータイプがあります。

4-1. 標準ワークフロー（Standard Workflows）

標準ワークフローは、次のような特徴を持つ「信頼性重視」のワークフローです。

実行履歴が最大 1 年間保持される
長時間実行（数分〜数日単位）にも対応
可観測性が高く、ステップごとの実行状況・入力出力を詳細に確認できる
料金は、ステートトランジション数に基づいて課金

向いているケース：

業務プロセスや承認フローなど、履歴を長く残したいもの
長時間にわたる ETL / データパイプライン
機械学習のトレーニングパイプライン
重要度の高いバッチジョブやバックオフィス処理

4-2. Express ワークフロー（Express Workflows）

Express ワークフローは、より「ハイスループット・低レイテンシ」寄りのワークフロータイプです。

短時間で大量に呼び出されるユースケース向け
実行時間は短め（数分以内）を想定
実行履歴保持期間は短く、メトリクス中心のモニタリング
課金は実行リクエスト数や実行時間に基づくモデル（Lambda に近い感覚）

向いているケース：

API Gateway や EventBridge から高頻度でトリガーされる軽量ワークフロー
リアルタイム分析やイベント処理パイプライン
低レイテンシでのオーケストレーションが求められる場面

「履歴をしっかり残したいゆったり目の処理」は Standard、「秒間数百〜数千単位で回るイベント処理」は Express、と覚えておくと選びやすいです。

5. 代表ユースケース：どんなときに Step Functions を選ぶ？

5-1. マイクロサービスのオーケストレーション

複数のマイクロサービス（Lambda / ECS / EKS / Fargate / 外部APIなど）が協調して動く処理では、全体の流れ・エラー処理・リトライを一箇所で管理したい場面が多いです。

例として「注文確定〜決済〜在庫引き当て〜メール送信」の流れを考えると：

入力検証（Lambda）
決済サービス呼び出し（外部API or Lambda）
在庫管理サービス呼び出し（ECS / EKS / Lambda）
メール送信（SNS + Lambda）
各ステップでエラー時のロールバックやアラートを実行

この「順番や条件」を Step Functions に任せ、個々のサービスは「自分の責任範囲の処理だけ」を担当させる設計にすると、サービス間の結合度が下がり、テストや保守がしやすくなります。

5-2. ETL・データパイプライン・バッチ処理

Step Functions は、ETL やデータパイプラインのオーケストレーションにもよく使われます。AWS 公式のユースケースとしても、複数の長時間 ETL ジョブを順番に実行し、成功・失敗を管理する例が挙げられています。

たとえば：

S3 にデータが到着
Glue ジョブ or EMR クラスターを起動して前処理
加工後のデータを Redshift / Athena / OpenSearch へロード
検証クエリを投げて問題なければ完了
問題があれば管理者へアラート＋ロールバック処理

という一連の流れをステートマシンとして表現できます。

GCP では、Cloud Workflows から BigQuery / Dataflow / Cloud Run などを呼び出して同様の ETL フローを構成できますし、Azure では Logic Apps や Data Factory が似た役割を担います。

5-3. 機械学習パイプライン

SageMaker や自前の ML 基盤を使う場合も、Step Functions がかなり活躍します。

一例として：

学習データを S3 から取得し、前処理（Lambda / Glue）
SageMaker Training Job でモデルトレーニング
モデル評価スコアに応じて、
- OK → SageMaker Endpoint 更新
- NG → アラートを送信し、人手レビューを要求
デプロイ完了後、検証リクエストを投げて動作確認

といった「ML Ops 的な一連の流れ」を、Step Functions で定義しておけます。

5-4. 業務プロセス・承認フロー

「申請→審査→承認→処理」のような業務フローにも、Step Functions は向いています。

User が API / フロントエンドから申請
Step Functions が審査用の Lambda / 外部API を呼び出す
審査結果に応じて、通知や追加情報要求を分岐
必要に応じて Wait ステートで一定時間待機し、リマインド通知を送る
最終的な承認後に本処理を実行

GCP では Cloud Workflows＋Cloud Functions、Azure では Logic Apps＋Functions / Power Automate のような組み合わせで、似たイメージの業務フローが構築できます。

6. エラー処理・リトライ・並列処理の設計ポイント

6-1. Retry / Catch で「失敗したらどうするか」を宣言する

ASL では、各 Task ステートに Retry と Catch を定義できます。

シンプルな例：

"CallApi": {
  "Type": "Task",
  "Resource": "arn:aws:lambda:REGION:ACCOUNT_ID:function:call-api",
  "Retry": [
    {
      "ErrorEquals": ["States.Timeout", "States.TaskFailed"],
      "IntervalSeconds": 5,
      "BackoffRate": 2.0,
      "MaxAttempts": 3
    }
  ],
  "Catch": [
    {
      "ErrorEquals": ["States.ALL"],
      "Next": "NotifyFailure"
    }
  ],
  "Next": "NextStep"
}

コードの中に複雑なリトライロジックを書かなくても、「どのエラーなら何秒ごとに最大何回リトライするか」「すべてダメだったらどこへ飛ぶか」を宣言的に指定できるのがとても便利です。

6-2. Parallel / Map で大規模並列処理

大量のファイル・レコード・メッセージに対して同じ処理を繰り返す場合、Parallel や Map ステートが役立ちます。

Parallel：互いに独立した分岐を同時に実行し、全て完了してから次へ進む
Map：配列に対してサブステートマシンを適用する（各要素ごとに並列 or 逐次）

例えば、1000 件の画像をサムネイル変換したい場合、

S3 のオブジェクト一覧を取得
Map ステートで配列として受け取り、各要素に対して Lambda を実行
すべての Lambda が終わったら次ステップへ

という構成が考えられます。大規模な並列処理も、Java や Python コードを複雑に書かずに ASL で表現できるのは大きなメリットです。

6-3. 待機・タイムアウト・サーキットブレーカー的な動き

Wait ステートを使えば、「5分待ってから次のステップへ」「指定した日時まで待つ」といった時間制御も簡単です。

さらに、あるサービスが一定期間エラーを返し続けた場合に、Step Functions 側で一時停止・エラールートへ切り替えるなど、サーキットブレーカーに近い挙動を実現することもできます。

7. 実装スタイル比較：Step Functions vs Cloud Workflows vs Logic Apps

7-1. 定義方法の違い

Step Functions
- JSON（ASL）でステートマシンを定義
- ややコード寄りだが、表現力が高い
Cloud Workflows
- YAML / JSON で定義（YAMLが多い）
- HTTP 優先の設計で、REST API 呼び出しがとても書きやすい
Logic Apps
- GUI デザイナーでドラッグ＆ドロップしながら作成
- JSON（Logic Apps 定義）としても管理可能だが、ローコード寄りのユーザー体験

開発者が中心のチームなら Step Functions / Cloud Workflows のコード定義スタイルが好まれることが多く、業務部門や情シス主導でのフロー自動化には Logic Apps のようなローコードツールがフィットしやすいです。

7-2. 統合するサービスの違い

Step Functions
- AWS サービスとの統合が最優先（Lambda / ECS / SageMaker / Glue / DynamoDB / SNS / SQS など）
Cloud Workflows
- Cloud Run / Cloud Functions / BigQuery / Pub/Sub など GCP サービス＋任意の HTTP API と統合
Logic Apps
- Azure サービスに加え、Office 365・Salesforce・SAP・オンプレミスDBなど多数のコネクタ

どのクラウドが「中心」なのか、既存のSaaSやオンプレ資産は何か、という観点で選ぶと自然です。

7-3. 料金モデルとスケーラビリティ（ざっくり）

細かな単価は変動するので公式ページの確認が必須ですが、ざっくりとしたイメージだけ。

Step Functions
- Standard：ステート遷移数ベース
- Express：実行回数＋実行時間ベース（ハイボリューム向け）
Cloud Workflows
- 実行ステップ数と外部APIコール数ベース。無料枠も用意されています。
Logic Apps
- 従量課金プランではトリガー・アクションごと、Standardプランでは App Service 的なリソース単位など複数モデルあり

「1回のフローでステップ数は多いが頻度は低い」のか、「1ステップは軽いが秒間何百件と流れる」のかで、どちらのワークフロータイプ / サービスが向いているかが変わってきます。

8. 誰がどう得をするか（読者別の具体的なメリット）

8-1. バックエンドエンジニア・API開発者

Lambda やコンテナの中に入り込んでいた「処理の流れ」「リトライ・タイムアウト」「外部APIの順番管理」を、一段外に出して Step Functions へ任せられるようになります。
GCP Cloud Workflows や Azure Logic Apps も合わせて理解しておくことで、「AWS なら Step Functions・GCP なら Workflows・Azure なら Logic Apps」という頭の切り替えが自然にできるようになります。

結果として、

コードは「単一のビジネスロジック」に集中
処理フローは ASL / YAML / GUI で見える化

という、レビューや保守がしやすい構成をチームで共有しやすくなります。

8-2. データエンジニア・MLエンジニア

Glue / EMR / Athena / Redshift / SageMaker などを組み合わせたデータ基盤・ML基盤を、「スクリプトと手順書」で粘るのではなく、「ワークフロー」としてクラウドに落とし込めるようになります。
再現性の高いパイプラインが整うことで、障害時の再実行・リカバリ・スケールアウトがとてもやりやすくなります。

GCP / Azure を使う場合も、Workflows や Logic Apps / Data Factory の概念にスムーズに乗れるようになり、クラウド間での知識転用性が高まります。

8-3. SRE・プラットフォームエンジニア

どのステップでどれくらい時間がかかっているか、どこでエラーが発生しているか、などを視覚的に追えるようになるため、運用・監視・容量計画が驚くほどやりやすくなります。
Retry / Catch / DLQ（SQS併用）などを組み合わせて、「失敗しても壊れにくい」ワークロードを設計しやすくなります。

また、GCP・Azure のオーケストレーションサービスも合わせて理解することで、マルチクラウド環境における「全体像の絵」が描きやすくなります。

8-4. 情シス・業務システム担当・業務改善に関わる方

申請・承認・通知・レポート生成など、これまで Excel とメールと人力で回してきたような業務フローを、少しずつ Step Functions＋Lambda で自動化するイメージが持てるようになります。
Azure 中心の環境であれば Logic Apps、GCP なら Workflows という形で同じ発想を持ち込めるので、「特定クラウドに閉じない業務改善の考え方」を社内に広げやすくなります。

9. 今日からできる 3 ステップ

既存システムの中から、「実はフローっぽくなっている処理」を1つ選ぶ
- 例：バッチ処理の多段ステップ、複数 API 呼び出しを順番に行う処理、データ取り込み→検証→メール通知など。
その処理を、紙やホワイトボードに「ステップ」と「矢印」で描いてみる
- どこで失敗しうるか、どこで待機したいか、人の判断はどこに入るかを一緒に書き出してみてください。
Step Functions（or Cloud Workflows / Logic Apps）で最小版を作ってみる
- まずは 2〜3 ステップだけのミニ状態マシンで構いません。
- 実際に実行し、コンソールで実行履歴やフロービューを眺めるだけでも、かなり感触が掴めるはずです。

10. まとめ：Step Functions は「イベントとサービスのあいだにある、もうひとつのコード」

AWS Step Functions は、

分散アプリケーションや業務プロセスを「視覚的なワークフロー」として表現し、
エラー処理・リトライ・並列処理・待機などを宣言的に管理できるサーバーレスオーケストレーションサービスです。

GCP には Cloud Workflows、Azure には Logic Apps という良い仲間たちがいて、クラウドが違っても

「処理の本体」は関数やコンテナで書き
「処理の流れ」はワークフローサービスで組み立てる

という考え方は変わりません。

すべてを一つの巨大なサービスやスクリプトに詰め込んでしまうのではなく、「イベント」「ワークフロー」「実際の処理」というレイヤーに分解することで、変更に強く・運用しやすく・可視性の高いシステムに育てやすくなります。

いきなり完璧な大規模フローを作る必要はありません。まずは、小さな手作業タスクや小さなバッチをひとつ、Step Functions に置き換えてみるところから始めてみてくださいね。
その一歩が、サーバーレス時代の「気持ちよいオーケストレーション設計」への入り口になってくれると思います。

参考リンク（公式ドキュメント・解説）

※バージョン・料金・制限値などは随時更新されますので、実際に設計される際は必ず最新の公式ドキュメント・料金ページをご確認ください。