AWS Step Functionsで非同期ワークフローを設計する方法|ステートマシンでLambdaをオーケストレーションする実践パターン

宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
HOMELinux技術 リナックスマスター.JP(Linuxマスター.JP)AWS(Amazon Linux) > AWS Step Functionsで非同期ワークフローを設計する方法|ステートマシンでLambdaをオーケストレーションする実践パターン
「Lambda関数が増えるにつれて、関数間の呼び出しロジックがどんどん複雑になってきた……」
「エラーが出た時にどの関数で失敗したのか追いかけるのが大変……」

こういった悩みを、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でエラーハンドリングを宣言的に定義、コード修正不要


「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

なぜ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 } } }

StartAtに最初のState名を指定し、各TaskStateでNextに次のStateを指定することで直列に連鎖させます。最後のStateには 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 } } }

ResultPathは「Lambdaの戻り値をどのキーに格納するか」を指定します。$.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" }

executionArnを使って実行状態を確認します。

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}}" }

statusは SUCCEEDED / RUNNING / FAILED / ABORTED / TIMED_OUT のいずれかです。SUCCEEDED であればワークフロー全体が正常に完了しています。

並列処理パターン(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 } } }

Parallel Stateは全ブランチが完了するまで待機し、各ブランチの出力を配列にまとめて次のStateに渡します。2リージョン分のチェックを直列に行うと2倍の時間がかかりますが、Parallelなら最も遅いブランチの時間だけで済みます。

どれか1つのブランチが失敗した場合は、Parallel State全体が失敗として扱われ、他のブランチも中断されます。ブランチごとに異なるエラーハンドリングが必要な場合は、ブランチ内にRetry/Catchを設定してください。

エラーハンドリングとリトライ設計

Step FunctionsではエラーハンドリングをコードではなくASLの RetryCatch で宣言的に定義します。

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 }

ResultPath: "$.error" を指定すると、エラー情報を入力データの $.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
一般的なバックエンド処理(注文・通知・定期バッチ)は Standard を選ぶのが安全です。秒あたり数千回以上の高スループットが必要なケースのみ Express を検討してください。

【注意】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を導入することで、Lambda間の呼び出しロジックをコードから切り離せます。ワークフローの変更はASL定義の更新だけで済み、各Lambdaはビジネスロジックに集中できる構造になります。AWSの構成設計については体系的に学ぶことで一気に理解が深まります。AWSセミナーを開講していますので、詳細はこちらからご確認ください。

Step Functionsの設計パターンを学ぶなら、AWSの「型」を体系的に身につけることが先決

ステートマシンの定義は書けます。でも「どのIAMポリシーで最小権限を実現するか」「Expressと Standard の選択基準を説明できますか?
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル(図解60P)』を完全無料でプレゼントしています。

「独学の時間がもったいない」「プロから直接、AWSを含む現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。