AWS Step Functionsとは｜使い方・料金とLambdaとの違い

AWS Step Functionsとは｜ワークフローを状態機械で組み立てるサービス

結論から言うと、Step Functionsはアプリケーションの「手順書」をAWS側に持たせるサービスです。どのタスクをどの順で呼び、失敗したら何回リトライし、条件によってどちらへ分岐するか。これらをJSONで宣言しておくと、実行状態の保持と再開をAWSが面倒を見てくれます。

条件として、Step Functions自体はビジネスロジックを実行しません。計算や変換はLambda、コンテナ処理はECS、データ保存はDynamoDBやS3が担当します。

例外として、簡単な値の加工や分岐の判定であれば、Lambdaを挟まずステートマシン内で完結させることもできます。

ステートマシンとASL（Amazon States Language）

ワークフローの定義体をステートマシンと呼びます。記述言語はJSONベースのAmazon States Language（ASL）で、仕様はAWS公式ドキュメントに公開されています。

定義のサイズ上限は1MB。実運用のワークフローで1MBに届くことは稀ですが、Mapの中にParallelを重ねた巨大な定義では意識する場面もあります。

8種類のステートを覚えれば読める

ASLのステートは次の8種類です。これだけ押さえれば、他人が書いたステートマシンもだいたい読めます。

Taskステートには、Lambdaのように個別最適化された統合と、AWS SDK経由で各サービスのAPIを直接呼ぶ統合があります。後者を使うと、「APIを1回叩くだけのLambda」を作らずに済みます。この削減効果は地味ですが、保守対象の関数が10個減ると体感が変わります。

Workflow Studioとコード、どちらで書くか

マネジメントコンソールのWorkflow Studioを使えば、ドラッグ＆ドロップでステートを並べられます。生成されたASLはそのままエクスポートできるため、最初の1本はGUI、以降はIaCという進め方が現実的です。

本番運用に乗せる段階では、TerraformやAWS CDKで定義を管理する構成がよく採られます。IaCの考え方はTerraformとは？IaCの仕組み・できること・フリーランス案件の単価をエンジニア視点で解説で整理しています。

ミニFAQ：ASLを手書きできないと案件で困りますか。

Workflow Studioで骨格を作り、差分をコードで調整できれば実務は回ります。ただし差分レビューはJSONで行うため、読んで意味が分かる程度の理解は必要です。

AWS Lambdaとの違いと組み合わせ方

結論は役割分担です。Lambdaは「何をするか」、Step Functionsは「どの順でやるか」を持ちます。両者は競合せず、組み合わせて使うのが標準的な構成です。

Lambdaそのものの仕組みや料金はAWS Lambdaとは？特徴・できること・料金・フリーランス案件の単価をエンジニア視点で解説で解説しています。Azure側の対応サービスはAzure Functionsとは？サーバレスの仕組み・AWS Lambdaとの違い・案件単価をフリーランス視点で解説を参照してください。

Lambdaだけで組むと苦しくなる3つの状況

Lambda単体で頑張れる範囲は、意外と広い。問題が出るのは次のケースです。

1. 関数の中から別の関数を呼び、その中からまた別の関数を呼ぶ構成になったとき。呼び出し元が死ぬと途中経過が消え、どこまで進んだか分からなくなります

2. 処理時間がLambdaの上限15分に収まらないとき。分割すると今度は分割後の順序管理が必要になります

3. 人の承認や外部システムの応答を待つとき。待機中にLambdaを起動し続けるのは課金の無駄です

切り出しの判断基準

設計の目安として、次のいずれかに当てはまるならStep Functionsへの切り出しを検討する価値があります。

• リトライまたは分岐の制御が必要なステップが3つ以上ある

• 一連の処理の合計所要時間が15分を超える、または超える可能性がある

• 分〜日単位の待機（承認、外部バッチ、人手の確認）が挟まる

• 失敗したステップから再実行（redrive：失敗した実行を最初からではなく失敗地点から再開する機能）できる必要がある

• 実行の進捗を、ログを読まずに可視化して説明する必要がある

逆に、ステップが2つ以内で待機もリトライも単純なら、Lambdaの中に直書きしたほうが安い。状態遷移が課金対象である以上、細かく刻むほどコストは増えます。

ミニFAQ：Lambdaの非同期呼び出しやSQSで代替できませんか。

単純なファンアウトや一方向の非同期連携なら代替できます。分岐・集約・エラー時の補償処理まで必要になると、SQSの先に自前の状態管理を作ることになり、結局Step Functionsを再実装する形になりがちです。

基本的な使い方｜最小構成の作成手順

結論：最初の1本はWorkflow Studioで10分あれば作れます。Lambdaを1つ呼ぶだけのステートマシンから始めるのが、理解の早道です。

手順1：呼び出し先のLambda関数を用意する

入力をそのまま返すだけの関数で構いません。Step Functions側の挙動を確認するのが目的なので、処理の中身は後回しにします。

手順2：ステートマシンを作成する

Step Functionsコンソールで「ステートマシンの作成」を選び、タイプにStandardを指定します。Workflow Studioが開いたら、左のアクション一覧から「AWS Lambda Invoke」をキャンバスへドラッグし、関数名を選ぶだけです。

このとき、Step Functions用のIAMロールは作成ウィザードが自動生成します。既存ロールを使う場合は、対象Lambdaに対するlambda:InvokeFunction権限が必要です。

手順3：ASLの中身を読む

Workflow Studioの「コード」タブに切り替えると、生成されたASLが見えます。最小構成は次の要素だけで成立しています。

StartAtで入口を宣言し、Statesの中に名前付きのステートを並べ、最後のステートにEndをtrueで付ける。この3点がASLの骨格です。分岐を足すならNextで次のステート名を指定し、Choiceステートで条件を書きます。

手順4：実行して履歴を見る

「実行を開始」から任意のJSONを入力すると、グラフ上のステートが成功なら緑、失敗なら赤で色分けされます。各ステートをクリックすれば、そこに渡った入力と返った出力をそのまま確認できます。

この「どこで何が入って何が出たか」が追えることが、Lambdaのログを横断して追う作業との最大の違いです。

手順5：RetryとCatchを足す

実用段階で必ず入れるのがこの2つ。TaskステートにRetryを追加すると、指定したエラー種別に対して間隔・回数・バックオフ係数を指定して自動再試行します。Catchを追加すると、失敗時に別のステート（通知やクリーンアップ）へ飛ばせます。

Retryの既定値に任せず、最大試行回数と間隔を明示的に書く。ここを省略すると、下流サービスのスロットリング時に想定外の再試行が走ります。

ミニFAQ：Workflow Studioで作った定義をそのまま本番に使えますか。

動作はします。ただしエクスポートしたASLをIaCに取り込み、環境ごとにARNを差し替えられる形にしてから本番へ乗せるのが安全です。

StandardとExpressの違いと選び方

ワークフロータイプは作成時に選び、後から変更できません。ここを間違えると作り直しになるため、最初に決めます。

出典：Step Functions でワークフロータイプを選択する（AWS公式ドキュメント）

選定フロー

上から順に当てはめれば、ほぼ機械的に決まります。

1. 処理が5分を超える可能性があるか → はい：Standard

2. 外部の完了待ち（.sync）やコールバック（.waitForTaskToken）を使うか → はい：Standard

3. 冪等でない処理（冪等＝同じ処理を複数回実行しても結果が変わらない性質。決済やクラスタ起動は冪等ではありません）を含むか → はい：Standard

4. 1日数十万回以上の高頻度イベント処理で、各処理が短く冪等か → はい：Express

5. いずれにも当てはまらない → 実行回数が多くない前提ならStandard。可観測性と再実行のしやすさで有利です。ただし実行数が月数十万回を超える見込みがあるなら、両方のコストを試算してから決めてください

ExpressはIoTのデータ取り込みやストリーム変換のような大量イベント処理向けです。同期Expressを使えばAPI Gatewayの背後でマイクロサービスのオーケストレーションもできますが、コンソールから同期実行すると60秒で失効する点に注意してください。5分まで使うにはSDKかCLIから呼びます。

APIの前段設計についてはAPI Gatewayとは｜役割・主要サービス比較と設計のポイントも参考になります。

料金の仕組みとコスト試算

結論：Standardは「ステップを刻むほど高い」、Expressは「長く動かすほど高い」。この性質の違いがそのままコスト設計になります。

本章およびクォータ章の数値は、2026年11月6日時点でAWS公式の料金ページとドキュメントを確認した内容です。単価はリージョンで異なり、AWS側で改定される場合もあるため、見積もりの前に公式ページで対象リージョンの最新値を確認してください。

Standard：状態遷移で課金

課金単位は状態遷移の回数で、実行内のステップが完了するたびに1回とカウントされます。無料利用枠として月4,000回の状態遷移が案内されており、米国東部（バージニア北部）の単価は状態遷移1回あたり0.000025 USDです。リージョンで単価は異なるため、AWS Step Functions の料金ページで対象リージョンの最新値を確認してください。

試算してみます。1実行あたり10ステップのワークフローを、1日1,000回動かす場合。

• 状態遷移：10 × 1,000 × 30日 ＝ 月300,000回

• 無料枠を差し引く：300,000 − 4,000 ＝ 296,000回

• 概算：296,000 × 0.000025 USD ＝ 約7.4 USD／月（米国東部の単価で計算）

同じ条件でステップを30に増やすと、月90万遷移で約22 USD。ステップ数が3倍になれば、おおむね料金も3倍です。

Express：リクエストと実行時間で課金

Expressは実行回数と、実行時間×メモリ（GB-秒）で課金されます。米国東部では100万リクエストあたり1.00 USD、GB-秒あたり0.00001667 USDが提示されています（実行時間の単価は段階的に下がる区分があります）。

月100万回、平均1秒、メモリ64MBのワークフローなら、リクエスト分が1.00 USD、実行時間分が62,500 GB-秒で約1.04 USD。合計で約2 USDという桁感です。

注意したいのは、同じ処理量でも課金モデルが違うため、StandardとExpressで総額が大きく離れるケースがある点です。高頻度・短時間ならExpressが有利になりやすく、低頻度・長時間ならStandardが有利になりやすい。実際の差は1実行あたりのステップ数と実行時間で変わるため、両方の式に自分のワークロードの数字を入れて比べてください。

コストを抑える3つの設計

• 連続する軽い処理を1つのLambdaにまとめ、状態遷移の数を減らす

• ループ回数が読めないMapは、件数の上限をChoiceで検査してから回す

• 高頻度の前処理だけをExpressの子ワークフローに切り出し、Standardから呼ぶ（ネスト構成）

ミニFAQ：無料利用枠はExpressにも適用されますか。

公式の料金ページで無料利用枠として示されているのはStandardの状態遷移4,000回／月です。Expressの請求条件は料金ページの記載を確認してください。

実務で多いユースケース

ETL・バッチ処理のオーケストレーション

S3へのファイル到着をEventBridgeで検知し、Step Functionsがバリデーション→変換→ロード→通知を順に実行する構成は定番です。途中で失敗しても、どのステップで落ちたかがコンソールで一目で分かります。

データ基盤まわりの案件動向はデータ基盤案件の単価相場｜ETL・DWH・BIレイヤー別の目安とスキル、取り込み方向の整理はリバースETLとは｜ETLとの違い・主要ツール比較と導入判断で扱っています。

人の承認を挟むワークフロー

コールバックパターン（.waitForTaskToken）を使うと、タスクトークンを発行して処理を止め、承認APIが叩かれるまで待機できます。待っている間は課金対象の処理が動きません。数日単位の承認待ちでも、Standardの最大1年という実行時間に収まります。

分散マップによる大量データ処理

分散マップは、1回のマップ実行で最大10,000の子実行を並列に走らせられます。S3に置かれた数十万件のオブジェクトを並列処理する用途が典型です。ディスパッチのレートはExpress子実行で最大1,000 TPS、Standard子実行で最大100 TPSとされています。詳細は分散マップステート（AWS公式ドキュメント）を参照してください。

なお、同時にオープンにできるマップ実行は1,000までというハードクォータがあります。

マイクロサービス間のSaga

複数サービスにまたがる更新で、途中失敗したら前のステップを打ち消す（補償トランザクション）。この設計をCatchとTaskの組み合わせで素直に表現できます。マイクロサービスとは｜モノリスとの違い・採用判断・案件動向を解説も併せてどうぞ。

知っておくべきクォータと詰まりやすいポイント

ここが実務の肝です。AWSのサービスクォータ一覧から、特に当たりやすいものを抜き出します。

256KiBの壁には「渡さない」で対応する

最頻出の事故がこれです。前のステップが返した大きなJSONを次に渡そうとして落ちます。

回避策は単純で、実データをS3に置き、ステート間ではキーだけを渡す。いわゆるクレームチェックパターンです。S3の基本はAWS S3とは｜オブジェクトストレージの仕組み・料金・案件単価をフリーランスエンジニア視点で解説に整理しています。中間状態をDynamoDBに置く構成も有効です（DynamoDBとは｜AWSのNoSQL DBの特徴・RDSとの違い・案件単価）。

25,000イベント上限はループ設計で避ける

実行履歴が25,000イベントに達すると実行自体が失敗します。1回のMapで数千件を回すような設計だと到達し得るため、件数が多い処理は分散マップに切り替えるか、子ワークフローへ分割します。

JSONPathの読みにくさは解消されつつある

Step Functionsのデータ加工は長らくJSONPathで、入れ子のパス指定が増えるとレビューが苦痛でした。2024年11月に変数（Variables）とJSONataによる変換が追加され、あるステートで代入した値を後続ステートから参照できるようになっています（AWS公式のアナウンス）。

日付整形や四則演算をJSONataで書けるため、「値を整えるだけのLambda」を減らせます。既存のJSONPathベースのワークフローも引き続き動作するので、新規に書くステートから段階的に移すのが現実的でしょう。

テストは部分テストと構造化ログで

ステートマシン全体のユニットテストは書きにくい領域です。実務では、個々のステートをTestState APIで単体検証し、ワークフロー全体はステージング環境で通す運用が多くなります。CloudWatch Logsへのログ出力は、ExpressだけでなくStandardでも有効にしておくと調査が早い。

EventBridge・Airflow・Temporalとの使い分け

「ワークフロー」と名のつくサービスは複数あり、ここを混同したまま設計すると後で苦しくなります。

判断の目安として、実行時間が数分以内でAWS内の連携が中心ならStep Functions、コードで複雑なワークフローを表現したいならTemporalという切り分けになります。Temporalの仕組みはTemporalとは｜ワークフローの仕組みと分散処理での使いどころで詳しく扱っています。

イベント連携そのものの設計思想はイベント駆動アーキテクチャとは｜同期APIとの違いと採用判断を読むと、Step FunctionsとEventBridgeの境界が整理しやすくなります。

フリーランス案件でのStep Functions

結論から言えば、Step Functionsを単独スキルとして指定する募集は見かけにくく、サーバーレス構成のAWS案件で必要スキルの一つとして並ぶ形が中心です。

募集要件での現れ方としては、Lambda・API Gateway・DynamoDB・S3といったサーバーレス定番の並びに加えて記載されるパターン、データ基盤案件でETLのオーケストレーション担当として記載されるパターンが見られます。

単価については、Step Functions単体のレンジを示せる公開データはありません。参考になるのは、AWSエンジニアとしてのレンジです。

以下は、フリコンの既存記事で整理した観測値です。母集団は、2026年1〜6月に首都圏／フルリモート中心の主要フリーランスエージェント数社が公開していた、週4〜5日・業務委託（準委任中心）のAWS関連案件。いずれも掲載時点の提示単価であって、成約単価や手取りではありません。

この表はAWSエンジニア全般の目安であり、Step Functionsを扱う案件に限定したレンジではありません。前提や内訳はAWSエンジニア フリーランスの単価相場｜経験・案件レイヤー別に解説で詳しく整理しています。

自分の経歴でどのレンジを狙えるか把握しておきたい方は、無料のフリーランスエンジニア単価診断で市場単価の目安を確認できます。単価を体系的に上げる考え方は【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？に整理されています。

スキルシートでどう書くか

「Step Functions使用」とだけ書いても評価につながりません。設計判断を書くと読み手の見え方が変わります。

• 選定理由（なぜLambda単体ではなくStep Functionsにしたか）

• ワークフロータイプの選択と根拠（Standard／Express）

• 規模の数値（1日の実行回数、1実行あたりのステップ数、並列度）

• 運用改善の結果（再実行の手間、障害検知までの時間）

案件選びの優先順位づけは案件の選び方｜フリーランスエンジニアが単価・稼働・スキルで決める優先順位が参考になります。AWS案件を探す場合はフリコンのAWS案件一覧から条件を絞り込めます。

学習ロードマップと導入前チェックリスト

学習の順序（目安は2〜4週間）

1. 1〜3日目：Workflow StudioでLambdaを2つつなぐだけのStandardワークフローを作る

2. 4〜7日目：Choice・Map・Retry・Catchを足し、意図的に失敗させてコンソールの挙動を見る

3. 2週目：S3イベント起点のETLを作り、256KiB対策（S3キーの受け渡し）を体験する

4. 3週目：ASLをCDKまたはTerraformに移し、CI/CDでデプロイする

5. 4週目：Expressと分散マップを試し、CloudWatchでコストと実行時間を比較する

AWS全体の知識を体系化したい場合はAWS認定資格一覧【2026年最新】全12種の難易度・受験料とおすすめ取得順も選択肢になります。

導入前チェックリスト

着手前にこの7項目を埋めておくと、作り直しがほぼ発生しません。

• ☐

  最大実行時間は5分を超えるか（超えるならStandard確定）

• ☐

  冪等でない処理を含むか

• ☐

  ステート間で渡すデータは256KiBに収まるか

• ☐

  1実行あたりのステップ数と月間実行回数から、概算コストを出したか

• ☐

  失敗時に再実行するのは全体か、途中からか

• ☐

  実行履歴の保持90日で監査要件を満たすか

• ☐

  定義をIaCで管理する前提になっているか

まとめ

Step Functionsは、Lambdaなどの処理を「順序・分岐・リトライ・待機」として束ねるマネージドなワークフローサービスです。処理そのものではなく、処理の状態を預けるサービスだと捉えると設計を誤りません。

• ワークフロータイプはStandard（最長1年・exactly-once・状態遷移課金）とExpress（最長5分・at-least-once・実行回数と時間で課金）。作成後は変更不可

• Lambdaから切り出す目安は、制御が必要なステップ3つ以上／合計15分超／承認待ちあり／途中再開が必要のいずれか

• コストはStandardがステップ数、Expressが実行時間に比例する。10ステップ×1日1,000実行なら月およそ7.4 USD（米国東部の単価）

• 実務で先に当たるのは入出力256KiB・実行履歴25,000イベント・HTTPタスク60秒。S3へのデータ退避と分散マップで回避する

• 2024年11月に追加された変数とJSONataで、JSONPath時代の可読性の問題はかなり軽くなった

• 案件では単独スキルではなく、サーバーレスAWS構成の一部として求められる。スキルシートには選定理由と規模の数値を書く

次の一歩としては、Workflow Studioで3ステートのワークフローを1本作り、わざと失敗させて実行履歴を眺めてみてください。コンソールで失敗箇所が色分けされる体験が、このサービスの価値を一番短時間で伝えてくれます。

参照した一次情報は以下のとおりです。

• Step Functions でワークフロータイプを選択する｜AWS公式ドキュメント

• Step Functions のサービスクォータ｜AWS公式ドキュメント

• AWS Step Functions の料金

• Amazon States Language｜AWS公式ドキュメント

• 分散マップステート｜AWS公式ドキュメント

• AWS Step Functions simplifies developer experience with Variables and JSONata transformations