【セッションレポート】 AWS Step Functions で実現するワークフロー自動化～大規模処理・エラー制御の実装パターン～（AWS-39） #AWSSummit

AWS Summit Japan 2025

#AWS

#AWS Step Functions

#セッションレポート

石川覚

2025.07.02

クラウド事業本部コンサルティング部の石川です。AWS Summit Japan 2025の2日目に、AWSの菅原太樹さんによる「AWS Step Functionsで実現するワークフロー自動化 ～大規模処理・エラー制御の実装パターン」（AWS-39）、L400（エキスパート：実装経験があり、技術的な深掘りを希望する方向け）のセッションに参加しました。学びの多い内容でしたので、ご紹介いたします。
セッションはオンデマンドで視聴可能です。公開期限は2025年7月11日（金）19時までとなっておりますので、視聴される場合はお早めにアクセスしてください。
https://summitjapan.awslivestream.com/aws-39/live/
資料: AWS Step Functions で実現する ワークフロー⾃動化 〜⼤規模処理・エラー制御の実装パターン〜
 セッション概要DX を加速する上で、複雑化するビジネスロジックの整合性の確保やエラーハンドリング、さらには増え続けるマイクロサービス間での連携に課題があり、想定していたスピードで変化を生み出せていないと感じている方も多いのではないでしょうか。ワークフローの途中でエラーが起こり、これまでの処理をロールバックしないといけないとしたら？連携しているサービスがダウンしたとしたら？そんな悩みは AWS Step Functions の多くの機能の真価を理解し、高度なアーキテクチャパターンを習得すれば解決します。本セッションでは、AWS Step Functions で実現可能なアーキテクチャパターンを解説します。大規模処理の効率的な並列化やコスト最適化、堅牢なエラーハンドリングによる業務継続性の向上、そして新たなデータ変換機能の紹介まで、具体的な実装アプローチとその効果を詳細に共有します。実際のシナリオをもとに、AWS Step Functions を深掘りし、サーバーレスの真価を習得しましょう。
 スピーカー菅原 太樹

アマゾン ウェブ サービス ジャパン合同会社 フィナンシャルサービスインダストリ技術本部 証券・保険第一ソリューション部 ソリューションアーキテクト
 AWS Step Functions の基本AWS Step Functionsは、サーバーレスでローコードなビジュアルワークフローサービスです。
イベントドリブンで動く様々なサービスの構築・追跡・検査を統制できます。
DynamoDBへのクエリを実行するには、Step FunctionsのGUIでGetItem()呼び出しを実装するだけで済みます。
更にリトライ処理やエラー時のデッドレターキュー（DLQ）への詰め込みもネイティブに実行できます。
ビジュアルでログを確認でき、エラー箇所が明確に分かります。
各タスクの入出力はJSON形式で確認でき、デバッグが容易です。
Lambda-lith（単一の大きなLambda関数が全ての処理を行うアンチパターン）を分割し、各API操作ごとにLambdaを分割する手法に対し、API Gatewayの背後にStep Functionsを配置するRESTパターンは、共通処理をシンプルにまとめ、可読性を向上させることが可能です。
 ワークフロータイプの選定 (Standard vs Express)Step Functionsには主に2つのワークフロータイプ、Standard と Expressが存在します。以降では、Eコマースサイトのワークフローを例に比較します。
 Standard ワークフロー 特徴長期実行（最大365日まで状態保持が可能）に特化。
非同期処理が可能。
実行時間が5分を超える場合
コールバック（.waitForTaskToken）や同期（.sync）を使う場合
Exactly-once（確実な1回）の実行が求められる場合に最適
 コストコストは状態遷移の回数に基づいて課金されます。例えば、1000回の実行で17回の状態遷移の場合、0.42ドルかかります。
 Express ワークフロー 特徴短期間実行に特化。
同期/非同期処理が可能。
高スループットで高い費用対効果。
実行時間が5分未満の場合
At least once（少なくとも1回）の実行。
 コストコストはリクエスト数と実行時間に基づいて課金されます。例えば、1,000回の実行で0.01ドルかかります。大規模なワークフローでは、100万回実行した場合、Standardが420ドルに対し、Expressは12ドルとなり、コスト差が顕著になります。
 いいとこ取り「入れ子パターン」また、Standard と Expressのいいとこ取りすることも可能です。Standardワークフローの中にExpressワークフローを入れ子にすることで、Standardの良好な開発者体験とExpressの高スループット・低コストを両立させることが可能です。このパターンにより、1,000回実行あたりのコストを0.42ドルから0.30ドルに削減できます。
 コスト削減Step Functions自体のコストはそれほど高くないものの、さらなる削減方法が紹介します。
 ワークフロー自体のコスト削減Standardワークフローでは遷移数の削減。
Expressワークフローでは実行時間や実行回数の削減、メモリの削減。
 組み込み関数の活用Lambda関数でUUIDを生成するだけの単純な処理を、Step Functionsの組み込み関数States.UUID()に置き換えることで、ソースコード、実行時間、コスト、コールドスタートを削減できます。他にも、データ操作、エンコード/デコード、数学計算、文字列操作などの組み込み関数が存在します。
 コールバックパターンによる遷移数と時間の削減これまでのポーリング処理を、コールバックパターンに置き換えることで、無駄な状態遷移をなくし、コストを削減できます。
Step Functionsがタスクトークンを外部サービスに与え、そのサービスが処理完了後にSendTaskSuccess関数を呼び出すまで、ステートは実行を停止し、コストがかかりません。
タスクトークンが返るまでのタイムアウト時間（"HeartbeatSeconds": xx）の設定も可能です。
 HTTP API統合外部のHTTP APIをLambdaを介さずに直接呼び出すことが可能です。
認証が必要なAPIや、お客様のVPC上に存在するプライベートなAPI（HTTPプライベート統合）も呼び出すことができ、Lambdaの利用を減らせます。
 データフローの改善 (JSONata)昨年、Step FunctionsがJSONataに対応しました。
JSONataは、ワークフローでデータを選択および変換するための強力な言語です。
従来のJSONPathに比べ、ステートの記述が単純化され、{% %}で囲んで記述し、キーの$.が不要になりました。
$statesという予約変数を通じて、入力、結果、エラー出力、コンテキストにアクセスできます。
多様な組み込み関数（文字列、数値、配列、オブジェクト関数）や、Step Functionsが提供するUUID生成、ランダム文字列生成などの関数も利用可能です。
昨年、ワークフロー変数サポートも導入され、ASL（Amazon States Language）内で変数を代入・参照できるようになりました。$記号を用いて変数を簡単に参照できます。
ワークフロー変数のスコープの注意点
変数を代入した直後のステートでは利用できませんが、その後のステートから利用可能です。
ParallelステートやInline Mapステート内では利用可能ですが、Distributed Mapでは利用できません。
Parallelステート内で代入された変数は、その直下のステートでは利用可能ですが、兄弟スコープや親スコープでは利用できません。
 エラーの処理Amazon CTOのWerner Vogels氏の言葉「Everything fails, all the time.」（全てのものはいつでも壊れうる）が引用され、いつ壊れてもおかしくない設計の必要性が求められます。
 Sagaパターン
マイクロサービス環境における分散トランザクションの取り消し（ロールバック）に利用されます。
例えば、旅行予約でホテル、フライト、レンタカーを順に予約する際に、途中でフライト予約が失敗した場合、その後のレンタカー予約を停止し、それまでに成功したフライトやホテルの予約をキャンセルする、といった巻き戻し処理を実現します。
 サーキットブレーカーパターン
呼び出し元サービスが、繰り返しエラーを引き起こす呼び出し先サービスへの再呼び出しを防ぐパターンです。
DynamoDBでサーキットブレーカーの状態（オープンかクローズか）を確認し、オープンであればエラー状態とみなし、すぐに処理を停止します。
 Redrive機能
ワークフロー実行中にエラーが発生した場合でも、以前に成功したタスクをスキップし、失敗したタスク以降から再実行する機能です。これにより、無駄な処理を省き、コストも発生しません。
 単一ステートのテスト
開発時やデバッグ時に、ワークフロー全体を起動することなく、特定の1つのステートだけをテストすることが可能です。これにより、重い処理を毎回待つ必要がなくなります。AWSマネジメントコンソールやVS Codeの拡張機能からも利用できます。
 スケールする Step Functions大規模な処理が入った際に、どのようにタスクを分割・並列化するかを解説します。
 パラレルステート (Parallel State)異なる処理を並列に実行します。
いずれかのブランチでエラーが発生した場合、デフォルトではパラレルステート全体がエラーになりますが、エラーをキャッチすることで他のブランチの完了を許可できます。
 マップステート (Map State)同じ処理を複数のレコードに対して動的に並列実行します。
 Dispatch パターン
前のタスクで渡された配列を一行ずつ取り出し、並列で実行します。例として、AWSブログのRSSフィードを読み込み、各記事に対して同じスクラップ処理を実行し、GitHubにプッシュするケースです。
一度にPUTのAPIが呼ばれて、スロットリングが発生する可能性があります。スロットリングの発生が懸念される場合は、次に紹介するScatter-Gather パターンが有効です。
 Scatter-Gather パターン
複数の処理結果を一度に集約して後続の処理に渡すことで、APIのスロットリングなどを避けることができるパターンです。
 分散マップ State (Distributed Map State)
分散マップステートは、高速でスケーラブルで 最大1万の同時並列実行が可能です。
S3に保存されたCSVやJSONファイルをStep Functionsがネイティブに読み込み、各行や要素を個別の「子ワークフロー」として並列処理できます。
各子ワークフローは独立した実行履歴とペイロード制限を持つため、256KBのペイロード制限を克服し、大量のデータを処理することが可能になります。
 サーバーレスワークフローコレクション
サーバーレスワークフローコレクション (s12d.com/workflows) では、ワークフローの例、IaC（Infrastructure as Code）テンプレート、ASLファイル定義などが公開されており、Step Functionsの知見を深めるための様々なサンプルが提供されています。
https://serverlessland.com/workflows
 最後に最近参加したワークショップで、.waitForTaskToken を使うとコードをこんなに簡潔に書けることに感銘を受けました。このセッションでは、AWS Step Functions の最新機能を反映したベストプラクティスが紹介されており、これを誰よりも自分のためにまとめたいと思い、このレポートを作成しました。
特に、JSONata やワークフロー変数、HTTP API 統合などの新機能、Saga やサーキットブレーカーといったエラー制御パターンは現代的なシステム要件に対応した実装例として大変参考になりました。
説明することが難しい AWS Step Functions を具体例を挙げてわかり易く解説した、AWSの菅原太樹さんに感謝します。