背景
Step Functionsで受注処理ワークフロー（検証→並列処理→確定）をコンソールで構築しました。Parallelステートの出力をどう次のLambdaが受け取るか、実装時に見落としやすいポイントでした。
1. Parallelステートの出力は各ブランチの結果をまとめた配列
{
"Type": "Parallel",
"Branches": [
{ "StartAt": "CheckInventory", "States": { "CheckInventory": {...} } },
{ "StartAt": "ProcessPayment", "States": { "ProcessPayment": {...} } }
],
"Next": "ConfirmOrder"
}
def lambda_handler(event, context):
# event はリスト形式
# event[0]: CheckInventory（在庫確認）の結果
# event[1]: ProcessPayment（支払い処理）の結果
inventory_result = event[0]
payment_result = event[1]
Parallelステートの各ブランチが並行実行された後、それぞれの出力が配列としてまとめて次のステートに渡されます。この仕様を知らずにeventを辞書として扱おうとするとlist indices must be integersエラーで詰まります。ブランチの定義順序とevent配列のインデックスが対応している点も覚えておく必要があります。
2. ResultPathでエラー情報を元の入力にマージする
"Catch": [
{
"ErrorEquals": ["States.ALL"],
"Next": "HandleError",
"ResultPath": "$.error"
}
]
def lambda_handler(event, context):
error_info = event.get("error", {})
original_input = {k: v for k, v in event.items() if k != "error"}
CatchブロックのResultPathを"$.error"に指定すると、発生したエラー情報が元の入力全体を保持したままerrorというキーに追加されます。ResultPathを省略すると入力全体がエラー情報で上書きされてしまうため、後続のエラーハンドラで元のリクエスト内容（注文IDなど）を参照したい場合はResultPathの指定が必須です。
3. RetryとCatchは別々に設定できる
"ValidateOrder": {
"Type": "Task",
"Resource": "...",
"Retry": [
{ "ErrorEquals": ["States.ALL"], "IntervalSeconds": 2, "MaxAttempts": 1, "BackoffRate": 2.0 }
],
"Catch": [
{ "ErrorEquals": ["States.ALL"], "Next": "HandleError", "ResultPath": "$.error" }
]
}
1つのTaskステートにRetry（自動リトライ）とCatch（リトライ後もダメなら別ステートへ遷移）を両方設定できます。リトライがすべて失敗した後で初めてCatchが発動する、という2段構えの設計です。実行グラフの「イベント」タブでTaskFailed → TaskScheduled（リトライ）→ TaskFailed → TaskStateExitedという順序を確認すると、リトライが実際に何回行われたかが分かります。
4. Workflow Studio新UIは3択モーダルから始まる
Hello World を実行 / テンプレートを選択 / 自分で作成する
新UIでは最初に3択のモーダルが出ますが、ゼロから定義したい場合は「自分で作成する」を選びます。「テンプレートを選択」を誤って押すと36個のテンプレートギャラリーが開いてしまい、目的のものにたどり着けず迷いやすいポイントです。
5. 実行ロールはASL定義から自動生成される
「設定」タブ → 「新しいロールを作成」（デフォルト）
→ ASL内のLambda ARNに対する lambda:Invoke 権限を持つロールが自動作成される
Step Functionsのステートマシン作成時、ASL定義に記述したLambda ARNを解析して、必要なlambda:Invoke権限を持つIAMロールが自動生成されます。SAM版のLambdaInvokePolicyが担っている自動化を、コンソールでは「新しいロールを作成」の1クリックで代替している形です。
まとめ
Parallelステート後の出力が配列になるという仕様と、ResultPathによるエラー情報のマージ、この2点がStep Functionsワークフロー実装の勘所でした。正常系・在庫切れ・支払い失敗・検証エラーという4パターンの動作テスト手順は元記事にまとめています。