SAA Step Functions 設計パターン4選｜標準・Express ワークフロー選択・SAGA・並列処理・エラーハンドリング完全攻略

「Step Functions の問題は、まずワークフロー種別を選び、次に必要なステートを選べ」 — SAA-C03 で Step Functions が絡む問題の正解は、ほぼ「標準 vs Express」と「どのステートパターンを使うか」で決まる。本記事では、要件キーワードからパターンへの逆引きができる粒度で、試験頻出の4つの設計パターンを整理する。

※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます

---

📑 目次

1. 結論：Step Functions 設計パターン4選

SAA-C03 で問われる Step Functions の設計パターンは大きく4つに集約される。

パターン	ワークフロー種別	主なユースケース
Lambda オーケストレーション	標準（Standard）	長時間・ビジネスクリティカルな多段処理
SAGA パターン	標準（Standard）	マイクロサービス分散トランザクション補償
Parallel / Map 並列処理	標準 / Express	並列ジョブ実行・コレクション一括処理
エラーハンドリング（Retry/Catch）	標準 / Express	障害時の自動リトライ・補償・人間承認

---

2. 標準 vs Express ワークフロー 選択の判断軸

Step Functions を選ぶ問題の最初のステップは 標準ワークフロー（Standard）か Express ワークフロー（Express）か の選択だ。

2軸の判断フロー

要件を確認
├─ 実行時間が5分を超える          → 標準ワークフロー
├─ Exactly-once（冪等性）が必須   → 標準ワークフロー
├─ 人間承認ステップが必要          → 標準ワークフロー
├─ 高スループット（100,000回/秒）  → Express ワークフロー
├─ IoT・ストリーミング・ETL パイプライン → Express ワークフロー
├─ コスト最小化・大量短時間処理    → Express ワークフロー
└─ ネストした子ワークフローに使用  → Express ワークフロー（親は標準）

標準 vs Express ワークフロー 機能比較

評価項目	標準（Standard） 推奨	Express
最大実行時間	◎ 最大1年	△ 最大5分
実行保証	◎ Exactly-once	○ At-least-once（Sync: Exactly-once）
最大スループット	△ 2,000実行/秒	◎ 100,000実行/秒
実行履歴	◎ 90日間保存・ビジュアル表示	△ CloudWatch Logs のみ
人間承認ステップ	◎ 対応（WaitForTaskToken）	× 非対応
料金体系	ステート遷移回数課金	実行数 + 時間課金
典型ユースケース	注文処理・承認フロー・SAGA	IoT・ETL・API オーケストレーション

---

3. パターン1：Lambda オーケストレーション（長時間ビジネスプロセス）

概要

Step Functions の最も基本的なパターン。複数の Lambda 関数を順序・条件分岐・並列で組み合わせ、ビジネスロジックをステートマシンとして可視化する。

実装フロー

1. EventBridge / API Gateway → Step Functions 実行開始
2. Task ステート → Lambda A（バリデーション）
3. Choice ステート → 条件分岐
   ├─ 条件A → Lambda B（承認フロー）
   └─ 条件B → Lambda C（却下処理）
4. 完了通知 → SNS / SQS

SAA 試験で押さえるポイント

• Task ステート は Lambda だけでなく ECS タスク・Glue・SageMaker など200以上のサービスを直接呼び出せる（SDK 統合）
• Choice ステート は条件分岐専用（StringEquals / NumericGreaterThan 等）
• Wait ステート は秒単位・特定タイムスタンプまでの待機
• Lambda の15分タイムアウトを超えるジョブは ECS や Glue をタスクとして使う

---

4. パターン2：SAGA パターン（分散トランザクション補償）

概要

マイクロサービスアーキテクチャで複数サービスにまたがるトランザクションの整合性を保つパターン。各ステップが失敗したとき、それまでの処理を逆順に**補償トランザクション（ロールバック相当）**で打ち消す。

実装フロー

正常系：
  注文作成 → 在庫引当 → 決済処理 → 配送登録

異常系（決済失敗時）：
  決済処理 失敗
  ↓
  Catch ステート 発動
  ↓
  在庫引当を取り消す（補償）
  ↓
  注文をキャンセル（補償）

ステートマシン定義のポイント

{
  "States": {
    "ReserveInventory": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:ap-northeast-1:123456789012:function:ReserveInventory",
      "Catch": [
        {
          "ErrorEquals": ["States.ALL"],
          "Next": "CancelOrder"
        }
      ],
      "Next": "ProcessPayment"
    },
    "ProcessPayment": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:ap-northeast-1:123456789012:function:ProcessPayment",
      "Catch": [
        {
          "ErrorEquals": ["States.ALL"],
          "Next": "ReleaseInventory"
        }
      ],
      "Next": "RegisterShipment"
    },
    "ReleaseInventory": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:ap-northeast-1:123456789012:function:ReleaseInventory",
      "Next": "CancelOrder"
    },
    "CancelOrder": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:ap-northeast-1:123456789012:function:CancelOrder",
      "End": true
    }
  }
}

---

5. パターン3：Parallel / Map ステートによる並列処理

Parallel ステート：固定数の並列実行

あらかじめ決まった数のブランチを同時実行し、すべて完了するまで待機する。

Parallel ステート
├─ ブランチ1：商品情報取得（Lambda）
├─ ブランチ2：在庫状況確認（DynamoDB）
└─ ブランチ3：ユーザー与信確認（外部 API）
↓
全ブランチ完了後 → 次のステート

試験頻出シナリオ： 画像処理（サムネイル生成・ウォーターマーク・メタデータ抽出を並行）、承認フローの並列通知（複数部署へ同時送信）

Map ステート：動的コレクション処理

配列の各要素に対して同じ処理を並列実行する。要素数は実行時に決まる。

入力: ["注文001", "注文002", "注文003", ...]
↓
Map ステート（各要素を並列処理）
├─ 注文001 → 処理
├─ 注文002 → 処理
└─ 注文003 → 処理
↓
全要素の結果配列 → 次のステート

試験頻出シナリオ： S3 バケット内ファイルの一括変換、大量レコードの並列バリデーション、ETL パイプラインの並列ロード

Parallel vs Map ステート 使い分け

評価項目	Parallel ステート	Map ステート 推奨
並列数	固定（定義時に決まる）	動的（実行時の配列サイズ）
処理内容	ブランチごとに異なる処理	全要素で同一の処理
典型用途	複数システムへの同時照会	コレクション一括処理
出力	各ブランチの結果配列	各要素の結果配列

---

6. パターン4：エラーハンドリング（Retry / Catch / WaitForTaskToken）

Retry：自動リトライ設定

Task・Parallel・Map ステートに Retry を設定すると、指定エラーを自動でリトライする。

"Retry": [
  {
    "ErrorEquals": ["Lambda.ServiceException", "Lambda.AWSLambdaException"],
    "IntervalSeconds": 2,
    "MaxAttempts": 3,
    "BackoffRate": 2
  }
]

パラメータ	説明
ErrorEquals	対象エラー種別（States.ALL で全エラー対象）
IntervalSeconds	初回リトライまでの待機秒数
MaxAttempts	最大リトライ回数（0 = リトライなし）
BackoffRate	指数バックオフの倍率（2 = 2・4・8秒…）

Catch：エラー捕捉と代替フロー

リトライ上限を超えた場合や特定エラーを捕捉し、代替ステートへ分岐する。

"Catch": [
  {
    "ErrorEquals": ["CustomError.InsufficientFunds"],
    "Next": "HandlePaymentFailure"
  },
  {
    "ErrorEquals": ["States.ALL"],
    "Next": "SendFailureNotification"
  }
]

WaitForTaskToken：人間承認ステップ

人間の承認待ちなど、非同期・不定時間の処理に使うパターン。タスクトークンを発行し、承認者がコールバック API を叩くまでワークフローを停止する。

実装フロー：
1. Step Functions がトークン付きメールを SNS 経由で送信
2. 承認者がリンクをクリック → API Gateway → Lambda
3. Lambda が SendTaskSuccess / SendTaskFailure を呼び出し
4. Step Functions がワークフローを再開

試験頻出シナリオ： 経費精算の上長承認、本番デプロイの人間確認ゲート、医療データの審査ステップ

---

7. 試験頻出キーワード逆引き表

要件キーワード	正解パターン
複数 Lambda を順番に実行	Task ステート（標準ワークフロー）
実行時間が数時間・数日	標準ワークフロー（最大1年）
毎秒数万件のイベント処理	Express ワークフロー
マイクロサービス間の整合性・ロールバック	SAGA パターン
複数システムへ同時照会して結果を統合	Parallel ステート
S3 内ファイルを一括並列処理	Map / Distributed Map ステート
Lambda の一時的なエラーを自動リカバリ	Retry（指数バックオフ）
決済失敗時に在庫を戻したい	Catch → 補償 Lambda
上長の承認後に処理を再開	WaitForTaskToken
コスト削減・子ワークフローに使う	Express ワークフロー（親は標準）
SQS との違いを問われる	Step Functions = 順序制御・状態管理付きオーケストレーション

---

8. Step Functions vs 他サービスの使い分け

シナリオ	適切なサービス
複数ステップの順序制御・条件分岐・エラーハンドリング	Step Functions
非同期メッセージキューイング（疎結合・デカップリング）	SQS
イベントルーティング・スケジュール起動	EventBridge
Pub/Sub 通知（複数サブスクライバーへのファンアウト）	SNS
単一 Lambda の定期実行（簡単なスケジュール）	EventBridge Scheduler

Step Functions は複数ステップ間の「状態」と「遷移」を管理することが本質。単純な非同期処理なら SQS で十分だが、ステップ数が増えるほど Step Functions の価値が高まる。

---

9. まとめ：Step Functions 設計パターン攻略の3つの法則

1. ワークフロー種別で絞る： 長時間・Exactly-once → 標準、高スループット・短時間 → Express
2. ステートパターンで解く： 順序制御 → Task、並列 → Parallel/Map、エラー → Retry/Catch、人間承認 → WaitForTaskToken
3. 他サービスとの違いを押さえる： SQS（キュー）vs Step Functions（ステートマシン）は SAA 頻出の比較問題

---

関連記事

• Lambda サーバーレス設計パターン
• SQS・SNS 疎結合パターン
• API Gateway 設計パターン4選