「エラーが出た時にどの関数で失敗したのか追いかけるのが大変……」
こういった悩みを、AWSでサーバーレスアーキテクチャを構築している現場でよく耳にします。Lambda同士をコード内で直接呼び出す「チェーン構造」は、最初はシンプルに見えますが、ワークフローが複雑になるほどエラーハンドリングもリトライ管理も難しくなっていきます。
AWS Step Functionsは、こうした非同期ワークフローを「ステートマシン」として定義することで、LambdaやECS・SNS・DynamoDBといったAWSサービスをコードなしでオーケストレーションできるマネージドサービスです。ワークフロー全体の実行状態・履歴はAWSが7年間保存するため、自前でDynamoDB等に記録する必要がなくなります。
この記事では、Step Functionsのステートマシン設計の基本から、直列・並列処理パターン、エラーハンドリング・リトライ設計まで実践的に解説します。Amazon Linux 2023 / AWS CLI v2(2.17以降)での動作確認手順も含めています。
この記事のポイント
・ステートマシンはTask・Parallel・Wait・Choiceなど8種のStateで構成される
・直列連鎖は "Next" で次Stateを指定し、"End:true" で終端を定義する
・Parallel Stateで複数Lambdaを並列実行しWall Clockを短縮できる
・Retry/Catchでエラーハンドリングを宣言的に定義、コード修正不要
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
なぜStep Functionsが必要なのか
Lambda同士をコード内で直接呼び出す設計(Lambda-to-Lambdaチェーン)では、次のような問題が起きやすくなります。・エラーハンドリングを各Lambdaのコードに書く必要があり、仕様変更のたびに複数の関数を修正しなければならない
・実行状態をDynamoDB等に自前で記録・管理するコードが必要になる
・Lambda単体のタイムアウトは最大15分のため、長時間処理はワークフロー外でのポーリングが必要
・CloudWatchのログをまたいで追跡しなければならず、障害時のデバッグが大変
Step Functionsを使うと、これらの課題をサービス側に任せられます。
・ワークフローをASL(Amazon States Language)というJSON形式で宣言的に定義し、コンソール上でフロー図を確認できる
・実行履歴・状態・入出力をAWSが7年間保存(Standard Workflowの場合)
・リトライ・エラーハンドリングをASL内に記述するだけでコード修正不要
・Lambda以外にもECS・SNS・SQS・DynamoDB・Bedrockと直接統合(Lambda不要で呼び出し可能)
「Lambdaを減らすことよりも、ワークフローの見通しを良くする」ことがStep Functionsの本質的な目的です。
ステートマシンの基本概念
Step Functionsのステートマシンは、State(状態)の集合と、State間の遷移で構成されます。ASLで定義できるStateのタイプは以下の8種類です。・Task: LambdaやAWSサービスを呼び出す(最頻出)
・Parallel: 複数のStateブランチを並列実行する
・Map: 配列の各要素に対して同じ処理を繰り返す
・Choice: 条件に応じて遷移先を分岐させる
・Wait: 指定時間またはタイムスタンプまで待機する
・Succeed: ワークフローを成功として終了する
・Fail: ワークフローをエラーとして終了する
・Pass: 入力をそのまま出力に渡す(テスト・デバッグに便利)
ASLの基本構造は次のとおりです。
{ "Comment": "ワークフローの説明(省略可)", "StartAt": "最初のState名", "States": { "最初のState名": { "Type": "Task", "Resource": "arn:aws:lambda:リージョン:アカウントID:function:FunctionName", "Next": "次のState名" }, "次のState名": { "Type": "Task", "Resource": "arn:aws:lambda:リージョン:アカウントID:function:FunctionName2", "End": true } } }
EC2スナップショット自動化で学ぶ直列処理パターン
「EC2スナップショット取得 → タグ付け → SNS通知」という3ステップのワークフローを例に、実際の構築手順を解説します。1. ステートマシン定義ファイルの作成
まず state-machine.json を作成します。# state-machine.json { "Comment": "EC2スナップショット自動化ワークフロー", "StartAt": "CreateSnapshot", "States": { "CreateSnapshot": { "Type": "Task", "Resource": "arn:aws:lambda:ap-northeast-1:1234XXXX89012:function:CreateSnapshot", "ResultPath": "$.snapshotResult", "Next": "TagSnapshot" }, "TagSnapshot": { "Type": "Task", "Resource": "arn:aws:lambda:ap-northeast-1:1234XXXX89012:function:TagSnapshot", "ResultPath": "$.tagResult", "Next": "SendNotification" }, "SendNotification": { "Type": "Task", "Resource": "arn:aws:states:::sns:publish", "Parameters": { "TopicArn": "arn:aws:sns:ap-northeast-1:1234XXXX89012:backup-notification", "Message.$": "States.Format('スナップショット {} の作成が完了しました', $.snapshotResult.snapshotId)" }, "End": true } } }
$.snapshotResultと書けば、後続のStateから$.snapshotResult.snapshotIdとして参照できます。SendNotificationではLambdaを介さず、Step FunctionsのSDK統合でSNSを直接呼び出しています。2. IAMロールとステートマシンの作成
# Step Functionsが引き受けるIAMロールの信頼ポリシーを定義 cat > trust-policy.json << 'EOF' { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": {"Service": "states.amazonaws.com"}, "Action": "sts:AssumeRole" }] } EOF # IAMロールを作成 aws iam create-role --role-name StepFunctionsExecutionRole --assume-role-policy-document file://trust-policy.json # ステートマシンを作成 aws stepfunctions create-state-machine --name "ec2-backup-workflow" --role-arn "arn:aws:iam::1234XXXX89012:role/StepFunctionsExecutionRole" --definition file://state-machine.json --type STANDARD --region ap-northeast-1
3. 実行開始と状態確認
# ワークフローの実行を開始する aws stepfunctions start-execution --state-machine-arn "arn:aws:states:ap-northeast-1:1234XXXX89012:stateMachine:ec2-backup-workflow" --input '{"instanceId": "i-0a1b2c3d4e5f67890"}' --region ap-northeast-1
{ "executionArn": "arn:aws:states:ap-northeast-1:1234XXXX89012:execution:ec2-backup-workflow:550e8400-e29b-41d4", "startDate": "2026-09-10T10:00:00.123Z" }
aws stepfunctions describe-execution --execution-arn "arn:aws:states:ap-northeast-1:1234XXXX89012:execution:ec2-backup-workflow:550e8400-e29b-41d4"
{ "executionArn": "arn:aws:states:ap-northeast-1:1234XXXX89012:execution:ec2-backup-workflow:550e8400-e29b-41d4", "stateMachineArn": "arn:aws:states:ap-northeast-1:1234XXXX89012:stateMachine:ec2-backup-workflow", "name": "550e8400-e29b-41d4", "status": "SUCCEEDED", "startDate": "2026-09-10T10:00:00.123Z", "stopDate": "2026-09-10T10:00:04.876Z", "input": "{"instanceId": "i-0a1b2c3d4e5f67890"}", "output": "{"snapshotResult":{"snapshotId":"snap-0abc123def456789"},"tagResult":{"success":true}}" }
並列処理パターン(Parallel State)
複数の処理を同時並行で走らせたいケースには Parallel State を使います。「マルチリージョンへの同時バックアップ確認」を例にします。{ "Comment": "マルチリージョン同時バックアップ確認", "StartAt": "CheckAllRegions", "States": { "CheckAllRegions": { "Type": "Parallel", "Branches": [ { "StartAt": "CheckTokyo", "States": { "CheckTokyo": { "Type": "Task", "Resource": "arn:aws:lambda:ap-northeast-1:1234XXXX89012:function:CheckBackup", "Parameters": {"region": "ap-northeast-1"}, "End": true } } }, { "StartAt": "CheckOsaka", "States": { "CheckOsaka": { "Type": "Task", "Resource": "arn:aws:lambda:ap-northeast-3:1234XXXX89012:function:CheckBackup", "Parameters": {"region": "ap-northeast-3"}, "End": true } } } ], "Next": "AggregateResults" }, "AggregateResults": { "Type": "Task", "Resource": "arn:aws:lambda:ap-northeast-1:1234XXXX89012:function:AggregateResults", "End": true } } }
どれか1つのブランチが失敗した場合は、Parallel State全体が失敗として扱われ、他のブランチも中断されます。ブランチごとに異なるエラーハンドリングが必要な場合は、ブランチ内にRetry/Catchを設定してください。
エラーハンドリングとリトライ設計
Step FunctionsではエラーハンドリングをコードではなくASLの Retry と Catch で宣言的に定義します。1. Retry(リトライ)の設定
"CreateSnapshot": { "Type": "Task", "Resource": "arn:aws:lambda:ap-northeast-1:1234XXXX89012:function:CreateSnapshot", "Retry": [ { "ErrorEquals": ["Lambda.ServiceException", "Lambda.TooManyRequestsException"], "IntervalSeconds": 2, "MaxAttempts": 3, "BackoffRate": 2.0, "JitterStrategy": "FULL" } ], "Next": "TagSnapshot" }
・Lambda.ServiceException: Lambda側の内部エラー(一時的な障害に多い)
・Lambda.TooManyRequestsException: Lambda同時実行数の上限に達した場合
・States.TaskFailed: Lambdaがエラー終了した場合
・States.ALL: すべてのエラーに一致(フォールバック用)
BackoffRate: 2.0 は前回の待機時間を2倍に増やす指数バックオフです。MaxAttempts: 3 なら「2秒→4秒→8秒」と間隔を広げて最大3回リトライします。JitterStrategy: FULL を指定すると待機時間をランダムに分散させ、複数のワークフローが同時にリトライして負荷が集中する「サンダリングハード問題」を防ぎます。
2. Catch(エラー捕捉)の設定
リトライを使い果たした後、またはリトライ対象外のエラーが発生した場合は Catch でハンドリングします。"CreateSnapshot": { "Type": "Task", "Resource": "arn:aws:lambda:ap-northeast-1:1234XXXX89012:function:CreateSnapshot", "Retry": [ { "ErrorEquals": ["Lambda.TooManyRequestsException"], "IntervalSeconds": 2, "MaxAttempts": 3, "BackoffRate": 2.0 } ], "Catch": [ { "ErrorEquals": ["States.ALL"], "Next": "HandleError", "ResultPath": "$.error" } ], "Next": "TagSnapshot" }, "HandleError": { "Type": "Task", "Resource": "arn:aws:lambda:ap-northeast-1:1234XXXX89012:function:NotifyFailure", "End": true }
$.error キーに追記して HandleError State に渡します。エラー内容をSlackやSNSに通知するLambdaを HandleError として実装するのが一般的なパターンです。Standard ワークフローとExpress ワークフローの使い分け
ステートマシンの作成時に--type で Standard または Express を選択します。用途によって使い分けます。| 項目 | Standard Workflow | Express Workflow |
|---|---|---|
| 最大実行時間 | 1年 | 5分 |
| 実行保証 | Exactly-once(1回のみ) | At-least-once(少なくとも1回) |
| 実行履歴保存 | 7年間(自動) | なし(CloudWatch Logsに転送要) |
| 料金基準 | 状態遷移回数 | 実行数+実行時間 |
| 向いている用途 | 注文処理・承認フロー・バッチ処理 | IoT処理・高スループットETL・Webhook |
【注意】Express WorkflowはAt-least-once保証のため、同一の入力が複数回処理される可能性があります。冪等性(同じ処理を2回行っても結果が変わらない設計)のないLambdaには使用しないでください。DynamoDBへの書き込みは「条件付き書き込み(ConditionExpression)」でユニーク制約を設けるなど、二重実行に備えた設計が必要です。
AWSでのサーバーレスアーキテクチャやIAM設計について体系的に学びたい場合は、AWSセミナーの詳細はこちらからご確認いただけます。
本記事のまとめ
AWS Step Functionsのステートマシン設計について、直列・並列処理パターンとエラーハンドリングの実践手順を解説しました。| やりたいこと | 使うState/設定 |
|---|---|
| Lambdaを順番に呼び出す | "Type": "Task" + "Next" で連鎖 |
| 複数の処理を並列実行する | "Type": "Parallel" + Branches配列 |
| リトライ回数・間隔を制御する | Retry + IntervalSeconds/MaxAttempts/BackoffRate |
| エラー時に別の処理へ分岐する | Catch + ErrorEquals/Next/ResultPath |
| ステートマシンを作成する | aws stepfunctions create-state-machine |
| ワークフローを実行する | aws stepfunctions start-execution |
| 実行状態を確認する | aws stepfunctions describe-execution |
Step Functionsの設計パターンを学ぶなら、AWSの「型」を体系的に身につけることが先決
ステートマシンの定義は書けます。でも「どのIAMポリシーで最小権限を実現するか」「Expressと Standard の選択基準を説明できますか?
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル(図解60P)』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、AWSを含む現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら
- 前のページへ:AWS Network Firewallの設計入門|インライン配置とルートテーブルでVPC境界を守る構成パターン
- この記事の属するカテゴリ:AWS(Amazon Linux)へ戻る

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます