--- title: "AWS Step Functionsとは？ステートマシンの仕組み・料金と2種のワークフロー・採用判断を実装者目線で解説" url: "https://www.issoh.co.jp/tech/details/15429/" published: 2026-07-21 updated: 2026-10-17 categories: ["AWS"] publisher: "株式会社一創" --- # AWS Step Functionsとは？ステートマシンの仕組み・料金と2種のワークフロー・採用判断を実装者目線で解説 AWS Step Functionsは、複数のAWSサービスをまたぐ処理の流れを「ステートマシン」という状態遷移の形で定義し、AWSがマネージドに実行するサービスです。処理をつなぐ制御を自前のコードから切り離し、リトライやエラー分岐、並列実行を宣言的に記述できます。この記事では、ステートマシンとASL（Amazon States Language）の仕組み、標準ワークフローとExpressワークフローの違い、AWS CLIで作って動かすまでの手順、JSONataと変数による新しい書き方、25,000イベントや256KiBといったクォータ上限、状態遷移ごとの料金、採用すべき要件と自前実装で足りる見送り場面までを実装者の目線で整理します。Azureで同種のワークフローを組む場合は、コネクタによるSaaS統合まで内包する[Azure Logic Apps](https://www.issoh.co.jp/tech/details/15523/)が対応するサービスです。 ## まとめ：AWS Step Functionsの要点と標準・Express型の選び分け Step Functionsの本体は、処理の各段階を状態（State）として並べ、遷移をJSONベースのASLで記述する仕組みです。Lambda関数を順に呼び、条件で分岐し、失敗したら決めた回数だけリトライする——その制御を、アプリ側のコードに埋め込まず外側の定義へ追い出せます。どこで止まったかを実行履歴から追えるのが、自前のキュー制御にない持ち味です。 選び分けの軸は明快です。監査ログや長時間バッチのように実行履歴と厳密な1回実行が要るなら標準ワークフロー、秒間の大量イベントを短時間でさばくならExpressワークフローを選びます。[AWS公式のワークフロータイプ選択ガイド](https://docs.aws.amazon.com/step-functions/latest/dg/choosing-workflow-type.html)が明記するとおり、この型は作成後に変更できません。料金は標準型が状態遷移ごとの課金で毎月4,000回まで無料、Express型はリクエスト数と実行時間による従量課金です。数個の処理を順に呼ぶだけで分岐もリトライも要らないなら、Step Functionsを挟まず[AWS Lambda](https://www.issoh.co.jp/tech/details/15407/)単体や自前のキューで足ります。設計・運用の相談は[AWSを含むインフラ構築](https://www.issoh.co.jp/service/system/aws/)で対応しています。 ## AWS Step Functionsの仕組みとステートマシン・ASLによる状態定義 理解の起点は、ワークフロー全体を1つの状態機械として捉えることです。処理の各段階を「State」と呼び、遷移を並べたものがステートマシンになります。 ### ステートマシンとStateで表現するワークフローの実行モデル 1つのステートマシンは、開始状態から終了状態まで、Stateを順にたどりながら実行されます。各Stateは入力のJSONを受け取り、処理結果のJSONを次のStateへ渡す——このデータの受け渡しが実行の背骨です。[AWS公式の開発者ガイド](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)も、ワークフローをステップの集合とその遷移として定義すると説明しています。 ### Amazon States Language（ASL）による状態と遷移の記述 定義はAmazon States Language（ASL）というJSONベースの言語で書きます。トップレベルに各Stateを列挙し、それぞれに種類（Type）と次の遷移先（Next）を指定する構造です。仕様は[Amazon States Languageの公開仕様](https://states-language.net/spec.html)として読めるため、Choiceの比較演算子やRetryのフィールド名で迷ったら仕様側を引くほうが早い場面もあります。JSONで宣言するので、定義そのものをバージョン管理下に置き、差分レビューやIaCでの配布に載せられます。 ### TaskやChoiceなど代表的なステートタイプの種類と役割 Stateには用途ごとの種類があります。実処理を呼ぶ`Task`、条件分岐の`Choice`、並列実行の`Parallel`、配列を反復する`Map`、一定時間待つ`Wait`などです。中心は`Task`で、Lambda関数やSQSへの送信、ECSタスクの起動といったAWSサービス呼び出しをここで表します。分岐や反復を専用のStateに切り出すことで、制御ロジックをアプリのコードから引き剥がせます。 ## AWS CLIでステートマシンを作成し実行を開始するまでの手順 ここからは手を動かす側の話です。ASLのJSONを1ファイル用意し、AWS CLIで登録して実行するところまでを、そのまま打てる形で示します。使うサブコマンドは[AWS CLIのstepfunctionsリファレンス](https://docs.aws.amazon.com/cli/latest/reference/stepfunctions/)にあるものだけです。 ### Retry・Catchを含むASL定義ファイルを1本用意する作業 最初に定義ファイルを書きます。注文の検証と決済を順に呼び、失敗したら2秒間隔で3回まで再試行し、それでも落ちたら通知用のStateへ逃がす構成です。後述のJSONata記法で書いてあります。 ``` { "Comment": "order pipeline", "QueryLanguage": "JSONata", "StartAt": "ValidateOrder", "States": { "ValidateOrder": { "Type": "Task", "Resource": "arn:aws:states:::lambda:invoke", "Arguments": { "FunctionName": "validate-order", "Payload": "{% $states.input %}" }, "Assign": { "orderId": "{% $states.input.orderId %}" }, "Retry": [ { "ErrorEquals": ["Lambda.ServiceException", "States.TaskFailed"], "IntervalSeconds": 2, "MaxAttempts": 3, "BackoffRate": 2 } ], "Catch": [ { "ErrorEquals": ["States.ALL"], "Next": "NotifyFailure" } ], "TimeoutSeconds": 30, "Next": "ChargePayment" }, "ChargePayment": { "Type": "Task", "Resource": "arn:aws:states:::lambda:invoke", "Arguments": { "FunctionName": "charge-payment", "Payload": { "orderId": "{% $orderId %}" } }, "End": true }, "NotifyFailure": { "Type": "Fail", "Error": "OrderPipelineFailed" } } } ``` `Retry`と`Catch`に書けるフィールドは[AWS公式のエラー処理ドキュメント](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-error-handling.html)にまとまっています。`States.ALL`は個別のエラー名より後ろ、配列の最後に置きます。 ### create-state-machineで登録しstart-executionで実行 定義ができたら登録して動かします。`--type`を省くとSTANDARDになり、型は後から変えられません。 ``` # 定義ファイルからステートマシンを作成する aws stepfunctions create-state-machine \ --name order-pipeline \ --definition file://definition.json \ --role-arn arn:aws:iam::123456789012:role/StepFunctionsOrderRole \ --type STANDARD # 実行を開始する（返るのは実行ARNと開始時刻だけ） aws stepfunctions start-execution \ --state-machine-arn arn:aws:states:ap-northeast-1:123456789012:stateMachine:order-pipeline \ --input '{"orderId":"ORD-1234"}' # どのStateで落ちたかを実行ARNから確認する aws stepfunctions describe-execution \ --execution-arn arn:aws:states:ap-northeast-1:123456789012:execution:order-pipeline:5f0c # 実行履歴のイベントを時系列で読む aws stepfunctions get-execution-history \ --execution-arn arn:aws:states:ap-northeast-1:123456789012:execution:order-pipeline:5f0c \ --max-items 20 ``` リージョンは東京（ap-northeast-1）の例です。アカウントIDとロール名は自分の環境のものへ置き換えてください。 ### test-stateで1つのStateだけを入力付きで検証する使い方 全体を動かす前に、1つのStateだけを入力付きで試せます。TestState APIは2023年11月にHTTPSエンドポイント呼び出しと同時に入った機能で、CLIからは`test-state`で呼びます。デプロイ前の構文検証に使うコマンドは`validate-state-machine-definition`です。 ``` # 定義の構文だけを先に検証する aws stepfunctions validate-state-machine-definition \ --definition file://definition.json # Stateを1つだけ入力付きで実行し、入出力を見る aws stepfunctions test-state \ --definition file://validate-order-state.json \ --role-arn arn:aws:iam::123456789012:role/StepFunctionsOrderRole \ --input '{"orderId":"ORD-1234"}' ``` ASLのtypoは実行して初めて分かることが多いため、この2つをCIへ組み込んでおくと、IaCで配布する前に定義の不備を落とせます。 ## JSONataと変数で状態間のデータ受け渡しを書き換える移行手順 ここが既存の解説記事といちばん食い違う箇所です。2024年11月22日に変数（Variables）とJSONataのサポートが入り、[AWS公式のJSONataドキュメント](https://docs.aws.amazon.com/step-functions/latest/dg/transforming-data.html)のとおり入出力の書き方が変わりました。古い記事のサンプルはほぼJSONPath前提のままです。 ### JSONPathの5フィールドをArgumentsとOutputへ寄せる置き換え JSONPathでは`InputPath`、`Parameters`、`ResultSelector`、`ResultPath`、`OutputPath`の5つを使い分けていました。`QueryLanguage`にJSONataを指定すると、この5つは無効になり、`Arguments`と`Output`の2フィールドに集約されます。式は`{% %}`で囲み、キー名に付けていた`.$`の作法も不要です。Step Functionsが実装するのはJSONata 2.0.6系の仕様で、`$eval`だけは使えず`$parse`で代替します（2026年9月時点）。 ### Assignで変数に置き中間Stateを削って遷移数を減らす作業 [変数（Variables）の公式ドキュメント](https://docs.aws.amazon.com/step-functions/latest/dg/workflow-variables.html)が示すとおり、`Assign`で値を変数に入れておけば、後続のStateから直接参照できます。前段の出力を後段まで運ぶためだけにPass Stateを挟む設計が要らなくなり、状態遷移の回数が減ります。標準型は遷移ごとの課金なので、この置き換えは可読性とコストの両方に効果的です。上のASL例でも、`ValidateOrder`で`orderId`を変数へ退避し、`ChargePayment`から拾っています。 ### 既存ステートマシンを一括ではなくState単位で移行する進め方 `QueryLanguage`はステートマシンのトップレベルにも個々のStateにも書けます。State側の指定が優先されるため、動いているワークフローを全部いっぺんに書き換えず、手を入れるStateから1つずつJSONataへ寄せられます。トップレベルで省略した場合の既定値はJSONPathなので、既存の定義が勝手に壊れることはありません。式の評価が1秒を超えるとエラー`States.QueryEvaluationError`になるため、重い変換はLambda側に残す判断が要ります。変換前後の定義例と、Outputを省略したときに入力が消える落とし穴は[Step FunctionsのJSONataの記事](https://www.issoh.co.jp/tech/details/18434/)で解説しています。 ## 標準ワークフローとExpressワークフローの違いと使い分けの判断基準 実行タイプは2種類あります。どちらもASLで書けますが、最大実行時間・課金方式・実行保証が異なり、向く処理がはっきり分かれます。 ### 標準ワークフローの最大1年間実行と厳密に1回の実行保証の特性 標準ワークフローは最大実行時間が1年で、長時間のバッチや承認待ちを含む業務フローに向きます。各実行の履歴が残り、どのStateでどんな入出力だったかを後から追跡できます。履歴の保持期間は実行終了後90日間で、コンプライアンス要件で短くしたい場合はクォータリクエストで30日へ短縮することが可能です。実行はExactly-once（厳密に1回）を保証するため、二重実行を避けたい決済や在庫更新の処理に適します。課金は状態遷移の回数に対して発生します。 ### Expressワークフローの最大5分実行と2種類の実行保証の違い Expressワークフローは最大実行時間が5分と短い代わりに、状態遷移レートに上限がなく、大量イベントの処理に向きます。実行保証は非同期（Asynchronous）がAt-least-once、同期（Synchronous）がAt-most-onceと、同じExpress型でも呼び方で変わる点は見落とされがちです。実行履歴はCloudWatch Logsへ出力する形になります。API Gatewayから`StartSyncExecution`で呼んで結果をそのまま返す構成が同期型の典型で、コンソールから同期実行すると60秒で打ち切られるためCLIかSDKを使います。 ### 標準型とExpress型の料金・実行時間・保証の比較と選び分け 両タイプの違いを一覧にすると、選択の判断がつけやすくなります。監査性と厳密性なら標準型、量とコストならExpress型、という軸で読み分けてください。 | 観点 | 標準ワークフロー | Expressワークフロー | | --------------- | -------- | ------------- | | 最大実行時間 | 1年 | 5分 | | 課金方式 | 状態遷移ごと | リクエスト＋実行時間 | | 実行保証 | 厳密に1回 | 少なくとも1回／最大1回 | | 実行履歴 | 終了後90日保持 | ログへ出力 | | 状態遷移レート | 上限あり | 上限なし | | コールバック待ち受け | 対応 | 非対応 | | Distributed Map | 対応 | 非対応 | | 向くケース | 長時間・監査重視 | 大量・短時間処理 | 迷ったときは、実行時間が5分を超えうるか、実行履歴の保持が要るかで切り分けます。どちらか一方でも該当すれば標準型が無難です。Express型は`.sync`のジョブ実行連携と`.waitForTaskToken`のコールバック連携に対応しないため、外部の応答を待つフローは標準型一択になります。 ## Workflow StudioとASL・IaCによるステートマシンの実装方法 ステートマシンは、画面上の視覚的な操作でも、コードとしての定義でも組み立てられます。試作はWorkflow Studio、運用配布はIaCという分担が実務では収まります。 ### Workflow Studioのドラッグ＆ドロップによる視覚的な設計 Workflow Studioは、マネジメントコンソール上でStateをドラッグ＆ドロップして並べ、ワークフローを図として設計できるツールです。並べた結果はそのままASLのJSONとして出力されます。2024年11月からは、描いたワークフローをAWS SAMテンプレートやCloudFormationテンプレートとして書き出す機能も入りました。ASLの文法をゼロから覚えなくても、分岐や並列の骨格を短時間で試せます。 ### ASLによる状態定義とステート間のパラメータ受け渡しの基本構造 本番の定義を管理するために使うのはASLです。JSONPathで書くなら各Stateの`Type`と`Next`で流れを組み、`InputPath`や`ResultPath`で入出力JSONのどの部分を次へ渡すかを制御します。受け渡しの経路を定義に明示しておくと、処理の依存関係がレビューで追えます。 ### CloudFormationやCDKによるステートマシンのコード管理 ステートマシンはCloudFormationや[AWS CDK](https://www.issoh.co.jp/tech/details/3161/)、Terraformでコードとして定義し、環境ごとに再現性を持って配布できます。ASLのJSONをテンプレートに埋め込むか、CDKの構文から生成する形が一般的です。CDKの`aws-stepfunctions-tasks`モジュールにはJSONata向けのpropsがあり、L2コンストラクトのまま新しい記法へ寄せられます。開発・検証・本番へ同じ定義を流し込む運用は、[オーケストレーション](https://www.issoh.co.jp/tech/details/13632/)を任せる基盤ほど効いてきます。 ## Lambda・SQS・ECSなどAWSサービスを連携するオーケストレーションの構成例 主戦場は、複数のAWSサービスを1つの流れにつなぐことです。個々のサービスは疎結合のまま、順序と分岐だけを外側から指揮します。 ### Lambda関数の順次・並列実行を制御するオーケストレーション 最も多い構成は、複数の[AWS Lambda](https://www.issoh.co.jp/tech/details/15407/)関数を順番に呼び、途中の結果で分岐させるパターンです。前処理・本処理・後処理を別の関数に分け、`Task`で順に呼び出します。独立した処理は`Parallel`や`Map`でまとめて走らせ、全体の待ち時間を縮める構成も定番です。関数側は自分の仕事に集中し、順序制御はステートマシンが担う分担になります。 ### SQS・SNS・ECSなど各種AWSサービスとの連携パターン 連携先はLambdaに限りません。SQSへのメッセージ送信、SNSでの通知、ECSやAWS Batchでのコンテナ実行、DynamoDBの読み書きなどを`Task`から直接呼び出せます。ECSタスクを起動する定義例と失敗時の扱いは[Step FunctionsでECSタスクを実行する：runTask.syncの定義例とコンテナ上書き・失敗時の扱い](https://www.issoh.co.jp/tech/details/18436/)で解説しています。2026年3月にはBedrock AgentCoreを含む28サービスのSDK統合が追加され、同年6月にはエージェント推論を1つのStateとして差し込めるようになりました（東京リージョンは2026年9月時点で対象外）。サービス間の非同期な連携は、[イベント駆動アーキテクチャ](https://www.issoh.co.jp/tech/details/13226/)の考え方と地続きです。 ### Distributed Mapで大量データを並列処理する構成と上限値 S3上の大量ファイルを処理するなら、通常のMapではなく[Distributed Map](https://docs.aws.amazon.com/step-functions/latest/dg/state-map-distributed.html)を使います。1つのMap Run内で最大10,000の子実行を並列に走らせられ、ディスパッチ速度はExpressの子実行で毎秒1,000件、標準の子実行で毎秒100件です。2025年2月と9月の更新でデータソースの選択肢が広がり、Athenaのマニフェストやparquetファイルも直接入力にできます。標準型のみの機能で、Express型の親ワークフローからは使えません。インラインMapとの選び分けや、ItemReader・ItemBatcherの定義例は[Step FunctionsのMapステート：インラインと分散マップの違いとS3大量ファイルの並列処理手順](https://www.issoh.co.jp/tech/details/18428/)で解説しています。 ### 実行時のエラー処理・リトライ・タイムアウト制御と冪等性の確保 実利は、失敗時の制御を定義側で書ける点にあります。各`Task`に`Retry`で再試行回数と待ち時間、`Catch`で失敗時の遷移先、`TimeoutSeconds`で打ち切りを指定できます。リトライで同じ処理が複数回走りうるため、呼ばれる側は同じ入力なら同じ結果になる[冪等性](https://www.issoh.co.jp/tech/details/13382/)を確保しておく設計が前提です。2023年11月に入った[redrive](https://docs.aws.amazon.com/step-functions/latest/dg/redrive-executions.html)なら、失敗した標準型の実行を終了から14日以内に限り、落ちたStateから再開できます。 ## クォータ上限に先に当たる失敗パターンと実装前に確認する設定値 設計レビューで見落とされやすいのが上限値です。[Step Functionsのサービスクォータ](https://docs.aws.amazon.com/step-functions/latest/dg/service-quotas.html)には、料金より先に設計を縛る数字が並んでいます。ここを知らずに組むと、本番のデータ量で初めて落ちます。 ### 実行履歴25,000イベント上限と長時間ループが落ちる失敗パターン 標準型の実行履歴は1実行あたり25,000イベントが上限で、超えると実行そのものが失敗します。ハードクォータなので引き上げ申請もできません。ループで数千回まわす設計や、Mapのインライン反復で大量の要素を処理する設計はここに当たります。逃げ道は2つで、子ワークフローを別の実行として起動して履歴を分けるか、大量反復をDistributed Mapへ寄せるかです。AWSも[ベストプラクティスのドキュメント](https://docs.aws.amazon.com/step-functions/latest/dg/sfn-best-practices.html)で、履歴上限に達しないよう新しい実行を開始する方法を案内しています。 ### 入出力256KiB制限とS3へのポインタ受け渡しという回避策 StateやTaskの入出力は、UTF-8文字列で256KiBが上限です。標準型もExpress型も同じ値で、こちらも引き上げ申請ができないハードクォータです。画像やCSVの中身をJSONに乗せて次のStateへ渡す設計は、この壁でそのまま止まります。実装としては、実体をS3に置いてバケット名とキーだけをStateの入出力に流す形へ組み替えます。ペイロードが肥大しはじめたら、渡しているのがデータなのかデータの在りかなのかを見直す合図です。 ### 状態遷移レートとStartExecutionの上限がリージョンで変わる点 標準型の状態遷移は、トークンバケット方式でスロットリングされます。バージニア北部・オレゴン・アイルランドはバケットサイズ5,000・毎秒5,000の補充ですが、東京を含むそれ以外のリージョンは800・毎秒800です。`StartExecution`も前者がバケット1,300・毎秒300、後者が800・毎秒150と差があります。いずれもソフトクォータで引き上げ申請はできますが、東京リージョンで検証して本番も同じと見積もると桁を間違えます。新規アカウントは遷移クォータが絞られており、利用実績に応じてAWS側が自動で引き上げる仕組みです。 ## 料金体系と状態遷移ごとの課金・無料枠4,000回を踏まえたコスト試算 料金の考え方はタイプで異なります。標準型は状態遷移の回数、Express型はリクエスト数と実行時間という別々のものさしが基準です。以下は2026年9月時点で[AWS公式の料金ページ](https://aws.amazon.com/step-functions/pricing/)が掲示する米国東部（バージニア北部）リージョンの数字をもとにした概算で、実際の金額はリージョンで異なります。 ### 標準ワークフローの状態遷移ごとの課金と月4,000回の無料枠 標準ワークフローは、状態遷移1回ごとに課金されます。公開料金は米国東部で1遷移あたり0.000025ドル、100万遷移で25ドルの換算です。毎月4,000回の状態遷移までは無料枠が適用され、この枠は新規・既存を問わず継続して使えます。リトライで発生した遷移も1回として数えるため、再試行を多く設計するほど遷移数が積み上がる点は見落とさないでください。前述のJSONata変数で中間のPass Stateを削る改修は、そのまま遷移数の削減になります。 ### Express型のリクエスト数と実行時間・メモリによる従量課金 Expressワークフローは、実行回数（リクエスト数）と、実行時間×メモリ量による従量課金の2本立てです。米国東部では100万リクエストあたり1.00ドルに加え、GB時間の単価が最初の1,000GB時間で0.06000ドル、次の4,000GB時間で0.03000ドル、それ以降は0.01642ドルと段階的に下がります。状態遷移の回数では課金されないため、遷移が多く短時間で終わる大量処理では標準型より割安になりやすい設計です。 ### 月あたりの実行回数から見た標準型とExpress型のコスト試算 標準型のコストは状態遷移数にほぼ比例します。無料枠を踏まえた概算は次のとおりで、あくまで遷移単価からの目安です。 | 月間の状態遷移数 | 標準型の課金目安 | 備考 | | -------- | -------- | ----------- | | 4,000回まで | 0ドル（無料枠） | 無料枠は毎月適用 | | 100万回 | 25ドル | 米国東部リージョン基準 | | 1,000万回 | 250ドル | 遷移数に比例 | 1回の実行で状態遷移が10回なら、月10万実行で約100万遷移という換算です。遷移数の見積もりが料金の勘所になります。 ## Step Functionsを採用すべきワークフロー要件と自前実装で足りる見送り場面 ここは判断を言い切ります。Step Functionsは万能ではなく、挟むほど得をする条件があるツールです。分岐・リトライ・並列・可視性のどれかが効くフローでこそ価値が出ます。 ### Step Functionsを採用すべきワークフロー要件の判断基準 採用が効くのは、複数サービスをまたいで、条件分岐やリトライ、並列実行を含む処理を組むときです。「どのStateで失敗したかを実行履歴から追いたい」「二重実行を避けたい」という要件があるなら、標準型の実行保証と履歴保持が直接効きます。長時間の承認待ちや、外部応答を挟むコールバック型のフローも、自前で状態管理を書くより定義に寄せたほうが破綻しにくい構成です。2025年10月に追加されたメトリクスダッシュボードで、実行数やエラー率をサービス側の画面から把握できます。 ### 自前のキュー・cronで足りるケースと過剰投資となる見送り場面 逆に見送るべき場面もあります。関数を2〜3個順に呼ぶだけで分岐もリトライも要らないなら、Lambdaの中で直接呼ぶか、SQSとcron相当のスケジュールで足ります。単一の処理をトリガーするだけなら[Amazon EventBridge](https://www.issoh.co.jp/tech/details/15513/)で十分で、ステートマシンを挟むと定義と課金の管理が増えるだけです。状態遷移ごとの課金は、遷移が多い割に処理が軽いフローでは割高に感じられます。「フローが1本道で、失敗しても手動で流し直せばよい」規模なら、Step Functionsは過剰投資です。 ### AirflowやTemporalと比べたときのStep Functionsの守備範囲 比較対象はAWS内のサービスだけではありません。データパイプラインのDAGをPythonで書き、スケジュールとバックフィルを回したいなら[Apache Airflow](https://www.issoh.co.jp/tech/details/1441/)のほうが素直です。ワークフローをアプリのコードとして書き、長時間の待ち合わせを型付きの関数で表現したいなら[Temporal](https://www.issoh.co.jp/tech/details/9090/)が候補になります。Step Functionsが優位なのは、AWSサービス呼び出しが処理の大半を占め、実行基盤そのものを持ちたくない場合です。ワークフローのロジックが複雑な業務ルールの塊で、ASLのJSONにすると読めなくなる規模なら、コードで書くエンジンへ振ったほうが保守が楽になります。 ### 料金と運用負荷・可視性から見た内製実装とマネージド利用の選択 内製の状態管理とマネージドのStep Functionsは、料金だけでなく運用負荷と可視性で比べます。自前実装は課金がない代わりに、リトライ・タイムアウト・履歴保持を全て自作し、保守まで抱える負担があります。Step Functionsは遷移課金を払う代わりに、その制御と可視化を肩代わりする仕組みです。状態管理の作り込みに人手を割くより[サーバーレス](https://www.issoh.co.jp/column/details/13005/)のマネージド機能に寄せたほうが総コストが下がるなら、採用の判断が立ちます。設計から迷う場合は[AWS基盤の構築支援](https://www.issoh.co.jp/service/system/aws/)で要件整理から相談できます。 ## よくある質問 AWS Step Functionsの検討でよく挙がる疑問を、実装者の視点で簡潔に答えます。 ### AWS Step FunctionsとAWS Lambdaの違いは何ですか？ Lambdaは1つの処理（関数）を実行するサービス、Step Functionsはその関数を含む複数の処理を「どの順で、どう分岐・リトライして呼ぶか」を指揮するサービスです。役割が重ならないため、実務では両者を組み合わせ、Lambdaが個々の仕事を担い、Step Functionsが全体の段取りを担います。単一の処理だけならStep Functionsは不要です。Lambda単体で済ませるかの切り分け条件と、lambda:invoke統合でのリトライ定義例は[Step FunctionsとLambdaの違い：役割の切り分けとlambda:invoke・リトライの実装手順](https://www.issoh.co.jp/tech/details/18426/)で解説しています。 ### 標準ワークフローとExpressワークフローはどう使い分けますか？ 実行が5分を超えうる、または実行履歴の保持と厳密な1回実行が要るなら標準型を選びます。秒間に大量のイベントを短時間でさばく用途ならExpress型が向きます。課金も標準型は状態遷移ごと、Express型はリクエスト数と実行時間と異なるため、量が多く軽い処理はExpress型が割安になりやすいです。なお型は作成時に決まり、後から変更できません。 ### Step Functionsの料金は高いですか？無料枠はありますか？ 標準型には毎月4,000回の状態遷移の無料枠があり、小規模なら実質無料の範囲で収まります。超過分は2026年9月時点の米国東部で1遷移0.000025ドル、100万遷移あたり25ドルです。リトライも遷移として数えるため、再試行の設計次第で遷移数が増える点に注意してください。金額はリージョンで異なります。 ### ステートマシンの定義に使うASLとJSONataの関係は何ですか？ ASL（Amazon States Language）はステートマシンを記述するJSONベースの言語で、JSONataはその中で入出力を選択・変換するためのクエリ言語です。2024年11月から`QueryLanguage`にJSONataを指定でき、従来のJSONPath用5フィールドが`Arguments`と`Output`に集約されます。State単位で指定できるので、既存の定義を残したまま段階的に移せます。 ### Step FunctionsとAmazon EventBridgeはどう違いますか？ EventBridgeはイベントを受けて処理を起動する「きっかけ」を担い、Step Functionsは起動した後の「一連の段取り」を担います。単一の処理を発火させるだけならEventBridgeで足り、分岐・リトライ・並列を含む流れを制御したいときにStep Functionsを組み合わせる形です。両者は競合せず補完関係にあります。 ## 関連記事 - [AWS Lambdaとは](https://www.issoh.co.jp/tech/details/15407/)：Step Functionsが順序制御する個々の関数の仕組みと料金・採用判断 - [サーバーレスとは](https://www.issoh.co.jp/column/details/13005/)：Step Functionsを含むマネージド構成の全体像とコンテナとの使い分け - [FaaSとは](https://www.issoh.co.jp/tech/details/13204/)：連携するLambdaの実行時間やコールドスタートの制約を掘り下げた記事 - [イベント駆動アーキテクチャとは](https://www.issoh.co.jp/tech/details/13226/)：サービス間の非同期連携を設計する考え方の土台 - [オーケストレーションとは](https://www.issoh.co.jp/tech/details/13632/)：Step Functionsが担う指揮という上位概念の整理 --- 出典: [AWS Step Functionsとは？ステートマシンの仕組み・料金と2種のワークフロー・採用判断を実装者目線で解説]()（株式会社一創）