翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Step Functions でワークフロータイプを選択する
ステートマシンを作成する際は、*[標準]* (デフォルト) または *[Express]* いずれかの **[タイプ]** を選択する必要があります。これらは一般に、標準ワークフローまたは Express ワークフローと呼ばれます。
どちらのステートマシンタイプも [Amazon States Language を使用して Step Functions ワークフローを定義する](concepts-amazon-states-language.md) を使用して定義します。
Standard ワークフローと Express ワークフローはどちらも、Amazon API Gateway からの HTTP リクエスト、IoT ルール、Amazon EventBridge の 140 以上の他のイベントソースなどのイベントに応じて開始できます。
**ワークフロータイプは変更不可**
ワークフロータイプはステートマシンの作成後に更新することは**できません**。
**Standard ワークフロー**は、長時間実行され (最長 1 年)、耐久性が高く、監査可能なワークフローに最適です。実行完了後 90 日以内であれば [Step Functions API](https://docs.aws.amazon.com/step-functions/latest/apireference) を使用して完全な実行履歴を取得できます。
Standard ワークフローは *exactly-once* モデルを採用しており、ASL で `Retry` 動作を指定しない限り、タスクとステートが複数回実行されることはありません。exactly-once モデルにより、Standard ワークフローは、Amazon EMR クラスターの起動や支払処理など、**べき等でない**アクションのオーケストレーションに適しています。
標準ワークフローの実行は、処理された状態遷移の数に応じて課金されます。
**Express ワークフロー**は、IoT のデータインジェスト、ストリーミングデータ処理と変換、モバイルアプリケーションのバックエンドなど、大容量のイベント処理ワークロードに最適です。これらのワークフローは最大 5 分間実行できます。
Express ワークフローは *at-least-once* モデルを採用しており、実行が複数回行われる可能性があります。at-least-once モデルにより、Express ワークフローは、PUT アクションを使用して Amazon DynamoDB に保存する入力データを変換するなど、**べき等** アクションのオーケストレーションにより適しています。
Express ワークフローの実行は、実行数、実行の合計所要時間、消費メモリ量に基づいて課金されます。
**ヒント**
Express ワークフローの例をデプロイするには、*「 AWS Step Functions ワークショップ*」の[「データの並列処理](https://catalog.workshops.aws/stepfunctions/parallel-state)」を参照してください。
**Standard ワークフロータイプと Express ワークフロータイプの比較**
| タイプ/カテゴリ | 標準ワークフロー | エクスプレスワークフロー:同期および非同期 |
| --- | --- | --- |
| 最大所要時間 | 1 年 | 5 分 |
| サポートされている実行開始レート | サポートされている実行開始レートに関連するクォータについては、「[API アクションのスロットリングに関連するクォータ](service-quotas.md#service-limits-api-action-throttling-general)」を参照してください。 | サポートされている実行開始レートに関連するクォータについては、「[API アクションのスロットリングに関連するクォータ](service-quotas.md#service-limits-api-action-throttling-general)」を参照してください。 |
| サポートされている状態遷移レート | サポートされている状態遷移レートに関連するクォータについては、「[状態のスロットリングに関連するクォータ](service-quotas.md#service-limits-api-state-throttling)」を参照してください。 | 無制限 |
| [料金](https://aws.amazon.com/step-functions/pricing) | 状態遷移回数による価格設定。状態遷移は、実行のステップが完了するたびにカウントされます。 | 実行回数、実行時間、およびメモリ消費量によって価格設定されます。 |
| 実行履歴 | 実行は、Step Functions API を使用して一覧表示および記述できます。実行は、コンソールから視覚的にデバッグできます。ステートマシンでのログを有効にすることで、CloudWatch Logs で実行を検査することもできます。 コンソールでの標準ワークフロー実行のデバッグの詳細については、「[Standard コンソールと Express コンソールのエクスペリエンスの違い](concepts-view-execution-details.md#console-exp-differences)」と「[ワークフローの実行の表示](concepts-view-execution-details.md)」を参照してください。 | 実行履歴は無制限に、つまり 5 分以内に生成できる限り多くの実行履歴エントリが保持されます。 ステートマシンでログ記録を有効にすることで、実行を CloudWatch Logs または Step Functions コンソールで検査できます。 コンソールでの Express ワークフロー実行のデバッグの詳細については、「[Standard コンソールと Express コンソールのエクスペリエンスの違い](concepts-view-execution-details.md#console-exp-differences)」と「[ワークフローの実行の表示](concepts-view-execution-details.md)」を参照してください。 |
| [実行セマンティクス](#express-at-least-once-execution) | Exactly-once ワークフロー実行。 | *非同期 Express ワークフロー*: *At-least-once* ワークフロー実行。 *同期 Express ワークフロー*: *At-most-once* ワークフロー実行。 |
| [サービス統合](integrate-services.md) | すべてのサービス統合とパターンをサポートします。 | すべてのサービス統合をサポートします。Express ワークフローはジョブ実行 (`.sync`) やコールバック (`.waitForTaskToken`) サービス統合パターンをサポートしていません。 |
| [分散マップ](state-map-distributed.md) | サポート | サポートされていません |
| [アクティビティ](concepts-activities.md) | サポート | サポートされていません |
**ワークフロータイプの最適化**
ワークフロータイプの比較およびコストへの影響の例については、「Step Functions を使用した大規模データ処理ワークショップ」の「[ワークフロータイプの選択](https://catalog.workshops.aws/serverless-data-processing/advanced/optimization/workflow-type)」を参照してください。
## Step Functions での同期および非同期 Express ワークフロー
選択できる Express ワークフローには、非同期 Express ワークフローと同期 Express ワークフローの 2 種類があります。
+ **非同期 Express ワークフロー**は、ワークフローが開始されたことの確認を返しますが、ワークフローの完了を待機しません。結果を得るには、サービスの [[CloudWatch Logs]](cw-logs.md) ポーリングを行う必要があります。非同期 Express ワークフローは、メッセージングサービスや、他のサービスが依存しないデータ処理など、即時のレスポンス出力が必要ではない場合に使用できます。非同期 Express ワークフローは、イベントに応えて、Step Functions 内のネストされたワークフローまたは `[StartExecution](https://docs.aws.amazon.com/step-functions/latest/apireference/API_StartExecution.html)` API コールを使用して開始できます。
+ **同期 Express ワークフロー**はワークフローを開始して、それが完了するまで待機してから、結果を返します。同期 Express ワークフローはマイクロサービスのオーケストレーションに使用できます。同期 Express ワークフローを使用すると、エラー処理、再試行、並列タスクの実行のための追加のコードを開発しなくても、アプリケーションを開発できます。Amazon API Gateway から呼び出された同期 Express ワークフローを実行するか AWS Lambda、 `[StartSyncExecution](https://docs.aws.amazon.com/step-functions/latest/apireference/API_StartSyncExecution.html)` API コールを使用して実行できます。
**注記**
Step Functions Express ワークフローをコンソールから同期的に実行した場合、`StartSyncExecution` リクエストは 60 秒後に失効します。Express ワークフローを最大 5 分間同期的に実行するには、Step Functions コンソールの代わりに AWS SDK または AWS Command Line Interface (AWS CLI) を使用して`StartSyncExecution`リクエストを行います。
同期 Express 実行 API コールは、既存のアカウント容量制限には影響しません。Step Functions は、オンデマンドで容量を提供し、持続的なワークロードを使って、自動的に拡張します。容量が利用可能になるまで、ワークロードの急増をスロットリングできます。
## Step Functions ワークフローの実行の保証
| 標準ワークフロー | 非同期 Express ワークフロー | 同期 Express ワークフロー |
| --- | --- | --- |
| Exactly-once ワークフロー実行 | At-least-once ワークフロー実行 | At-most-once ワークフロー実行 |
| 実行状態は状態遷移の間も内部的に持続します。 | 実行状態は状態遷移の間は持続しません。 | 実行状態は状態遷移の間は持続しません。 |
| 現在実行中のワークフローと同じ名前で実行を開始すると、自動的にべき等性の応答が返されます。新しいワークフローは開始せず、現在実行中のワークフローが完了すると例外がスローされます。 | べき等性は自動的には管理されません。同じ名前で複数のワークフローを開始すると、同時に実行されます。ステートマシンのロジックがべき等でないと、内部ワークフローの状態が失われる可能性があります。 | べき等性は自動的には管理されません。Step Functions は実行が開始されると待機し、完了時にステートマシンの結果を返します。例外が発生しても、ワークフローは再開されません。 |
| 実行履歴データは 90 日後に削除されました。ワークフロー名は古い実行データを削除した後も再利用できます。 コンプライアンス、組織、または規制の要件を満たすために、クォータリクエストを送信することによって実行履歴の保持期間を 30 日に短縮できます。これを行うには、 を使用して新しいケース AWS Support Center Console を作成します。 | 実行履歴は Step Functions ではキャプチャされません。ログ記録は Amazon CloudWatch Logs を通じて有効にする必要があります。 | 実行履歴は Step Functions ではキャプチャされません。ログ記録は Amazon CloudWatch Logs を通じて有効にする必要があります。 |