AWS Step Functionsとは？ステートマシンの仕組み・料金と2種のワークフロー・採用判断を実装者目線で解説

AWS Step Functionsは、複数のAWSサービスをまたぐ処理の流れを「ステートマシン」という状態遷移の形で定義し、AWSがマネージドに実行してくれるサービスです。個々の処理をつなぐ制御を自前のコードから切り離し、リトライやエラー分岐、並列実行といった段取りを宣言的に記述できます。この記事では、ステートマシンとASL（Amazon States Language）の仕組み、標準ワークフローとExpressワークフローの違い、Workflow StudioやIaCによる実装方法、Lambdaなどとの連携、状態遷移ごとの料金、そして採用すべき要件と自前実装で足りる見送り場面までを、実装者の目線で整理します。

まとめ：AWS Step Functionsの要点と標準・Express型の選び分け

Step Functionsの本体は、処理の各段階を状態（State）として並べ、遷移をJSONベースのASLで記述する仕組みです。Lambda関数を順番に呼び、条件で分岐し、失敗したら決めた回数だけリトライする——こうした制御を、アプリ側のコードに埋め込まず外側の定義に追い出せます。処理の全体像がフローとして可視化され、どこで止まったかを実行履歴から追える点が、自前のキュー制御にはない持ち味です。

選び分けの軸は明快です。監査ログや長時間バッチのように実行履歴と厳密な1回実行を重視するなら標準ワークフロー、秒間の大量イベントを短時間でさばくならExpressワークフローを選びます。料金は標準型が状態遷移ごとの課金で毎月4,000回まで無料、Express型はリクエスト数と実行時間による従量課金です。逆に、数個の処理を順に呼ぶだけで分岐もリトライも要らないなら、Step Functionsを挟まずAWS Lambda単体や自前のキューで足ります。設計・運用の相談はAWSを含むインフラ構築で対応しています。

AWS Step Functionsの仕組みとステートマシン・ASLによる状態定義

Step Functionsを理解する起点は、ワークフロー全体を1つの状態機械として捉えることです。処理の各段階を「State」と呼び、状態から次の状態への遷移を並べたものがステートマシンになります。

ステートマシンとStateで表現するワークフローの実行モデル

1つのステートマシンは、開始状態から終了状態まで、Stateを順にたどりながら実行されます。各Stateは入力のJSONを受け取り、処理結果のJSONを次のStateへ渡す——このデータの受け渡しが実行の背骨です。分岐や並列があっても、最終的にはどこかの終了状態にたどり着くまで遷移が続きます。状態と遷移だけで組み立てるため、処理の流れがそのまま図として読み取れます。

Amazon States Language（ASL）による状態と遷移の記述

ステートマシンの定義は、Amazon States Language（ASL）というJSONベースの言語で書きます。トップレベルに各Stateを列挙し、それぞれに種類（Type）と次の遷移先（Next）を指定する構造です。JSONで宣言するため、定義そのものをバージョン管理下に置き、差分レビューやIaCでの配布に載せられます。実処理のコードとワークフローの制御を分けられる点が、ASLで定義する狙いです。

TaskやChoiceなど代表的なステートタイプの種類と役割

Stateには用途ごとの種類があります。実処理を呼ぶTask、条件分岐のChoice、並列実行のParallel、配列を反復するMap、一定時間待つWaitなどです。中心になるのはTaskで、Lambda関数やSQSへの送信、ECSタスクの起動といったAWSサービス呼び出しをここで表します。分岐や反復を専用のStateに切り出すことで、制御ロジックをアプリのコードから引き剥がせます。

標準ワークフローとExpressワークフローの違いと使い分けの判断基準

Step Functionsには実行タイプが2種類あります。どちらもASLで書けますが、最大実行時間・課金方式・実行保証が異なり、向く処理がはっきり分かれます。

標準ワークフローの最大1年間実行と厳密に1回の実行保証の特性

標準ワークフローは最大実行時間が1年で、長時間のバッチや承認待ちを含む業務フローに向きます。各実行の履歴が完全に残り、どのStateでどんな入出力だったかを後から追跡できるのも標準型の持ち味です。実行はExactly-once（厳密に1回）を保証するため、二重実行を避けたい決済や在庫更新のような処理に適します。課金は後述のとおり状態遷移の回数に対して発生します。

Expressワークフローの最大5分実行と高スループット処理

Expressワークフローは最大実行時間が5分と短い代わりに、秒間の起動数と状態遷移数が大きく、大量イベントの処理に向きます。実行保証はAt-least-once（少なくとも1回）で、標準型より緩い代わりに高スループットを取ります。実行履歴は標準型のような完全保持ではなく、CloudWatch Logsへ出力する形です。ストリーミングデータの取り込みやIoTイベントの一括処理が典型的な使いどころです。

標準型とExpress型の料金・実行時間・保証の比較と選び分け

両タイプの違いを一覧にすると、選択の判断がつけやすくなります。監査性と厳密性なら標準型、量とコストならExpress型、という軸で読み分けてください。

迷ったときは、実行時間が5分を超えうるか、実行履歴の完全な保持が要るかで切り分けます。どちらか一方でも該当すれば標準型が無難です。

Workflow StudioとASL・IaCによるステートマシンの実装方法

ステートマシンは、画面上の視覚的な操作でも、コードとしての定義でも組み立てられます。試作はWorkflow Studio、運用配布はIaCという役割分担が実務では収まりがよいです。

Workflow Studioのドラッグ＆ドロップによる視覚的な設計

Workflow Studioは、マネジメントコンソール上でStateをドラッグ＆ドロップして並べ、ワークフローを図として設計できるツールです。並べた結果はそのままASLのJSONとして出力されるため、まず画面で全体像を作り、細部を定義で詰めるという進め方ができます。ASLの文法をゼロから覚えなくても、分岐や並列の骨格を短時間で試せる点が入口として使いやすい部分です。

ASLによる状態定義とステート間のパラメータ受け渡しの基本構造

本番の定義はASLで管理します。各StateのTypeとNextで流れを組み、InputPathやResultPathで入出力JSONのどの部分を次へ渡すかを制御します。前段のLambdaが返した値を後段の入力へ引き回す設計を、コードではなく定義側で表現できる点が肝です。受け渡しの経路を定義に明示しておくと、処理の依存関係がレビューで追いやすくなります。

CloudFormationやCDKによるステートマシンのコード管理

ステートマシンはCloudFormationやAWS CDK、Terraformといったツールでコードとして定義し、環境ごとに再現性を持って配布できます。ASLのJSONをテンプレートに埋め込むか、CDKの構文から生成する形が一般的です。手作業のコンソール操作に頼らず、開発・検証・本番へ同じ定義を流し込む運用は、オーケストレーションを任せる基盤ほど効いてきます。

Lambda・SQS・ECSなどAWSサービスを連携するオーケストレーションの構成例

Step Functionsの主戦場は、複数のAWSサービスを1つの流れとしてつなぐことです。個々のサービスは疎結合のまま、順序と分岐だけを外側から指揮します。

Lambda関数の順次・並列実行を制御するオーケストレーション

最も多い構成は、複数のAWS Lambda関数を順番に呼び、途中の結果で分岐させるパターンです。前処理・本処理・後処理をそれぞれ別の関数に分け、Taskで順に呼び出します。独立した処理はParallelやMapでまとめて走らせ、全体の待ち時間を縮める構成も定番です。関数側は自分の仕事だけに集中し、順序制御はステートマシンが担う分担になります。

SQS・SNS・ECSなど各種AWSサービスとの連携パターン

連携先はLambdaに限りません。SQSへのメッセージ送信、SNSでの通知、ECSやAWS Batchでのコンテナ実行、DynamoDBの読み書きなどをTaskから直接呼び出せます。長時間かかる処理はコールバック方式で完了を待ち受け、外部システムの応答を挟むフローも組めます。こうしたサービス間の非同期な連携は、イベント駆動アーキテクチャの考え方と地続きです。

実行時のエラー処理・リトライ・タイムアウト制御と冪等性の確保

Step Functionsの実利は、失敗時の制御を定義側で書ける点にあります。各TaskにRetryで再試行回数と待ち時間、Catchで失敗時の遷移先、TimeoutSecondsで打ち切りを指定できます。リトライで同じ処理が複数回走りうるため、呼ばれる側は同じ入力なら同じ結果になる冪等性を確保しておく設計が前提です。エラーの分岐をコードのtry-catchに散らさず、フロー図の上で一望できることが運用の安心につながります。

料金体系と状態遷移ごとの課金・無料枠4,000回を踏まえたコスト試算

料金の考え方はタイプで異なります。標準型は状態遷移の回数、Express型はリクエスト数と実行時間という別々のものさしが基準です。以下は2026年7月時点の米国東部（バージニア北部）リージョンの公開料金をもとにした概算で、実際の金額はリージョンで異なります。

標準ワークフローの状態遷移ごとの課金と月4,000回の無料枠

標準ワークフローは、状態遷移1回ごとに課金されます。2026年7月時点の公開料金では米国東部で100万遷移あたり25ドル前後、単価にすると1遷移0.000025ドル前後です。毎月4,000回の状態遷移までは無料枠が適用され、この枠は新規・既存を問わず継続して使えます。リトライで発生した遷移も1回として数えるため、再試行を多く設計するほど遷移数が積み上がる点は見落とさないでください。

Express型のリクエスト数と実行時間・メモリによる従量課金

Expressワークフローは、実行回数（リクエスト数）と、実行時間×メモリ量による従量課金の2本立てです。2026年7月時点の米国東部では100万リクエストあたり1ドル前後に加え、GB時間あたりの実行時間課金が段階的に下がります。状態遷移の回数では課金されないため、遷移が多く短時間で終わる大量処理では標準型より割安になりやすい設計です。

月あたりの実行回数から見た標準型とExpress型のコスト試算

標準型のコストは状態遷移数にほぼ比例します。無料枠を踏まえた概算は次のとおりで、あくまで遷移単価からの目安です。

1回の実行で状態遷移が10回なら、月10万実行で約100万遷移という換算です。遷移数の見積もりが料金の勘所になります。

Step Functionsを採用すべきワークフロー要件と自前実装で足りる見送り場面

ここは判断を言い切ります。Step Functionsは万能ではなく、挟むほど得をする条件があるツールです。分岐・リトライ・並列・可視性のどれかが効くフローでこそ価値が出ます。

Step Functionsを採用すべきワークフロー要件の判断基準

採用が効くのは、複数サービスをまたいで、条件分岐やリトライ、並列実行を含む処理を組むときです。とくに「どのStateで失敗したかを実行履歴から追いたい」「二重実行を避けたい」という要件があるなら、標準型の実行保証と履歴保持が直接効きます。長時間の承認待ちや、外部応答を挟むコールバック型のフローも、自前で状態管理を書くより定義に寄せたほうが破綻しにくい構成です。処理の途中経過を運用担当が図で追える点も、障害対応の速さに直結します。

自前のキュー・cronで足りるケースと過剰投資となる見送り場面

逆に見送るべき場面もあります。関数を2〜3個順に呼ぶだけで分岐もリトライも要らないなら、Lambdaの中で直接呼ぶか、SQSとcron相当のスケジュールで足ります。単一の処理をトリガーするだけならEventBridgeで十分で、ステートマシンを挟むと定義と課金の管理が増えるだけです。状態遷移ごとの課金は、遷移が多い割に処理が軽いフローでは割高に感じられます。「フローが1本道で、失敗しても手動で流し直せばよい」規模なら、Step Functionsは過剰投資です。

料金と運用負荷・可視性から見た内製実装とマネージド利用の選択

内製の状態管理とマネージドのStep Functionsは、料金だけでなく運用負荷と可視性で比べます。自前実装は課金がない代わりに、リトライ・タイムアウト・履歴保持を全て自作し、保守まで抱える負担があります。Step Functionsは遷移課金を払う代わりに、その制御と可視化を肩代わりする仕組みです。フローの複雑さと運用チームの規模を踏まえ、状態管理の作り込みに人手を割くよりサーバーレスのマネージド機能に寄せたほうが総コストが下がるなら、採用の判断が立ちます。設計から迷う場合はAWS基盤の構築支援で要件整理から相談できます。

よくある質問

AWS Step Functionsの検討でよく挙がる疑問を、実装者の視点で簡潔に答えます。

AWS Step FunctionsとAWS Lambdaの違いは何ですか？

Lambdaは1つの処理（関数）を実行するサービス、Step Functionsはその関数を含む複数の処理を「どの順で、どう分岐・リトライして呼ぶか」を指揮するサービスです。役割が重ならないため、実務では両者を組み合わせ、Lambdaが個々の仕事を担い、Step Functionsが全体の段取りを担います。単一の処理だけならStep Functionsは不要です。

標準ワークフローとExpressワークフローはどう使い分けますか？

実行が5分を超えうる、または実行履歴の完全な保持と厳密な1回実行が要るなら標準型を選びます。秒間に大量のイベントを短時間でさばく用途ならExpress型が向きます。課金も標準型は状態遷移ごと、Express型はリクエスト数と実行時間と異なるため、量が多く軽い処理はExpress型が割安になりやすいです。

Step Functionsの料金は高いですか？無料枠はありますか？

標準型には毎月4,000回の状態遷移の無料枠があり、小規模なら実質無料の範囲で収まります。超過分は2026年7月時点の米国東部で100万遷移あたり25ドル前後です。リトライも遷移として数えるため、再試行の設計次第で遷移数が増える点に注意してください。金額はリージョンで異なります。

ステートマシンの定義に使うASLとは何ですか？

ASL（Amazon States Language）は、ステートマシンを記述するためのJSONベースの言語です。各State（処理段階）の種類と次の遷移先、入出力JSONの受け渡しを宣言的に書きます。JSONで管理できるため、定義をバージョン管理やIaCに載せ、レビューや再現性ある配布ができます。

Step FunctionsとAmazon EventBridgeはどう違いますか？

EventBridgeはイベントを受けて処理を起動する「きっかけ」を担い、Step Functionsは起動した後の「一連の段取り」を担います。単一の処理を発火させるだけならEventBridgeで足り、分岐・リトライ・並列を含む流れを制御したいときにStep Functionsを組み合わせる形です。両者は競合せず補完関係にあります。

関連記事

• AWS Lambdaとは：Step Functionsが順序制御する個々の関数の仕組みと料金・採用判断
• サーバーレスとは：Step Functionsを含むマネージド構成の全体像とコンテナとの使い分け
• FaaSとは：連携するLambdaの実行時間やコールドスタートの制約を掘り下げた記事
• イベント駆動アーキテクチャとは：サービス間の非同期連携を設計する考え方の土台
• オーケストレーションとは：Step Functionsが担う指揮という上位概念の整理