翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Step Functions の問題のトラブルシューティング
Step Functions の操作中に問題が発生した場合は、次のトラブルシューティングのリソースを使用してください。
以下のトピックでは、Step Functions ステートマシン、サービス統合、アクティビティ、ワークフローに関連して発生する可能性のあるエラーや問題のトラブルシューティングに関するアドバイスを提供します。ここに記載されていない問題が見つかった場合は、このページの [**Feedback**] ボタンを使用して報告することができます。
トラブルシューティングに関するアドバイス、およびサポートへの一般的な質問に対する回答については、[AWS ナレッジセンター](https://aws.amazon.com/premiumsupport/knowledge-center/#AWS_Lambda)にアクセスしてください。
**Topics**
+ [一般的な問題](#troubleshooting-general)
+ [サービス統合](#troubleshooting-service-integrations)
+ [アクティビティ](#troubleshooting-activities)
+ [Express ワークフロー](#troubleshooting-express-workflows)
## 一般的なトラブルシューティング
### ステートマシンを作成できません。
ステートマシンに関連付けられた IAM ロールには、[十分な許可](auth-and-access-control-sfn.md#auth-and-access-control-sfn.title)があるわけではないかもしれません。 AWS サービス統合タスク、X-Ray、CloudWatch ログ記録など、IAM ロールのアクセス許可を確認します。`.sync` タスク状態には、追加許可が必要です。
### JsonPath を使用して前のタスクの出力を参照できません。
JsonPath の場合、JSON キーは `.$` で終わる必要があります。つまり、JsonPath はキーバリューペアでのみ使用できます。JsonPath を配列などの他の場所で使用する場合は、[組み込み関数](intrinsic-functions.md)を使用できます。例えば、以下のようなものを実行できます。
**タスク A の出力:**
```
{
"sample": "test"
}
```
**タスク B:**
```
{
"JsonPathSample.$": "$.sample"
}
```
### 状態遷移に遅延がありました。
Standard ワークフローでは、状態遷移の数に制限があります。状態遷移の制限を超えると、Step Functions はクォータのバケットがいっぱいになるまで、状態遷移を遅らせます。状態遷移制限のスロットリングは、CloudWatch メトリクスページの [実行メトリクス](procedure-cw-metrics.md#cloudwatch-step-functions-execution-metrics) セクションにおける`ExecutionThrottled` メトリクス をレビューしてモニタリングできます。
### 新しいStandard ワークフローの実行をスタートすると、`ExecutionLimitExceeded` エラーがあれば、失敗します。
Step Functions には、各 ごとに 1,000,000 件のオープン実行の制限 AWS アカウント があります AWS リージョン。この制限を超えた場合、Step Functions は、`ExecutionLimitExceeded`というエラーをスローします。この制限は Express Workflow には適用されません。`OpenExecutionCount` を使用して、`OpenExecutionLimit` に近づいているタイミングを追跡し、そのイベントで事前に通知するアラームを作成できます。`OpenExecutionCount` は、Open ワークフローの概算数です。詳細については、「[実行メトリクス](procedure-cw-metrics.md#cloudwatch-step-functions-execution-metrics)」を参照してください。
### 並列状態の 1 つのブランチで障害が発生すると、実行全体が失敗となります。
これは想定される動作です。parallel 状態を使用するときに障害が発生しないようにするには、Step Functions が各ブランチからスローされる[エラーを補足](concepts-error-handling.md#error-handling-fallback-states.title)できるように設定します。
## サービス統合のトラブルシューティング
### ジョブはダウンストリームサービスで完了していますが、Step Functions ではタスクの状態が「進行中」のままになるか、完了が遅れます。
`.sync` サービス統合パターンについては、Step Functions は、EventBridge ルール、ダウンストリーム API、またはその両方の組み合わせを使用して、ダウンストリームジョブのステータスを検出します。一部のサービスでは、Step Functions はモニタリングのため EventBridge ルールを作成しません。たとえば、 AWS Glue サービス統合の場合、EventBridge ルールを使用する代わりに、Step Functions が`glue:GetJobRun`呼び出しを行います。API 呼び出し頻度のため、ダウンストリームタスク完了と Step Functions タスクの完了時間は異なります。Step Functions には、EventBridge ルールを管理し、ダウンストリームサービスを呼び出すために IAM 許可が必要です。実行ロールへの許可が不十分であるために、タスクの完了にどれほどの影響がでているのかついての詳細は、[.sync を使用するタスクに必要な追加のアクセス許可](service-integration-iam-templates.md#connect-iam-sync-async) を参照してください。
### ネストされたステートマシンの実行から JSON 出力を返したいと思っています。
Step Functions には、`startExecution.sync` と `startExecution.sync:2` の 2 つの Step Functions 同期サービス統合があります。どちらもネストされたステートマシンが完了するのを待機しますが、異なる `Output` 形式を返します。`startExecution.sync:2` を使用して、`Output` で JSON 出力を返すことができます。
### Lambda 関数を別のアカウントから呼び出すことはできません。
**クロスアカウントサポートによる Lambda 関数へのアクセス**
リージョンで AWS リソースの[クロスアカウントアクセス](concepts-access-cross-acct-resources.md)が利用可能な場合は、次の方法を使用して別のアカウントから Lambda 関数を呼び出します。
ワークフローで、クロスアカウントリソースを呼び出すには次の操作を行います。
1. リソースを含むターゲットアカウントに IAM ロールを作成します。このロールは、ステートマシンを含むソースアカウントに、ターゲットアカウントのリソースにアクセスするアクセス許可を付与します。
1. `Task` ステートの定義で、クロスアカウントリソースを呼び出す前にステートマシンが引き受けるターゲット IAM ロールを指定します。
1. ターゲット IAM ロールの信頼ポリシーを変更して、ソースアカウントがこのロールを一時的に引き受けることができるようにします。信頼ポリシーには、ソースアカウントで定義したステートマシンの Amazon リソースネーム (ARN) を含める必要があります。また、 AWS リソースを呼び出すための適切なアクセス許可をターゲット IAM ロールに定義します。
1. ソースアカウントの実行ロールを更新して、ターゲット IAM ロールを引き受けるのに必要なアクセス許可を含めます。
例として、チュートリアルの「[Step Functions でのクロスアカウント AWS リソースへのアクセス](tutorial-access-cross-acct-resources.md)」を参照してください。
**注記**
複数の AWS アカウントからリソースにアクセスするための IAM ロールを引き受けるようにステートマシンを設定できます。ただし、ステートマシンは指定された時間に 1 つの IAM ロールしか引き受けられません。
クロスアカウントリソースを指定する `Task` ステート定義の例については、「[タスク状態の認証情報フィールドの例](state-task.md#task-state-example-credentials)」を参照してください。
**クロスアカウントサポートなしで Lambda 関数にアクセスする**
リージョンで AWS リソースのクロスアカウントアクセスが利用できない場合は、次の方法を使用して別のアカウントから Lambda 関数を呼び出します。
`Task` 状態の `Resource` フィールドでは、パラメータ内で `arn:aws:states:::lambda:invoke` を使用し、`FunctionArn` を渡します。ステートマシンに関連付けられている IAM ロールには、クロスアカウント Lambda 関数 `lambda:invokeFunction` を呼び出す適切な許可が必要です。
```
{
"StartAt":"CallLambda",
"States":{
"CallLambda":{
"Type":"Task",
"Resource":"arn:aws:states:::lambda:invoke",
"Parameters":{
"FunctionName":"arn:aws:lambda:{{region}}:{{account-id}}:function:my-function"
},
"End":true
}
}
}
```
### `.waitForTaskToken` 状態から渡されたタスクークンが表示されません。
`Task` 状態の `Parameters` フィールドでは、タスクトークンを渡す必要があります。例えば、以下のようなコードを実行できます。
```
{
"StartAt":"taskToken",
"States":{
"taskToken":{
"Type":"Task",
"Resource":"arn:aws:states:::lambda:invoke.waitForTaskToken",
"Parameters":{
"FunctionName":"get-model-review-decision",
"Payload":{
"token.$":"$$.Task.Token"
},
},
"End":true
}
}
}
```
**注記**
任意の API アクションを使用して、`.waitForTaskToken` の使用を試みることができます。ただし、一部の API には適切なパラメーターがありません。
## アクティビティのトラブルシューティング。
### ステートマシンの実行がアクティビティ状態でスタックされます。
アクティビティタスクの状態は、[[GetActivityTask]](https://docs.aws.amazon.com/step-functions/latest/apireference/API_GetActivityTask.html) API アクションを使用してタスクトークンをポーリングするまでスタートされません。ベストプラクティスとして、スタックの実行を回避するために、タスクレベルのタイムアウトを追加します。詳細については、「[タイムアウトを使用して Step Functions ワークフローの実行のスタックを回避する](sfn-best-practices.md#sfn-stuck-execution)」を参照してください。
ステートマシンが [ActivityScheduled](https://docs.aws.amazon.com/step-functions/latest/apireference/API_ActivityScheduledEventDetails.html) イベントで停止している場合は、アクティビティのワーカーフリートに問題があるか、スケールが不足していることを示しています。[`ActivityScheduleTime`](procedure-cw-metrics.md#cloudwatch-step-functions-activity-metrics) CloudWatch メトリクスをモニタリングし、その時間が長くなるとアラームを設定する必要があります。ただし、`Activity` 状態が `ActivityStarted` 状態に遷移しないようなステートマシンの実行をタイムアウトさせるには、ステートマシンレベルでタイムアウトを定義してください。これを行うには、`States` フィールドの外側のステートマシン定義の先頭に `TimeoutSeconds` フィールドを指定します。
### タスクトークンを待っている間に、アクティビティワーカーがタイムアウトします。
ワーカーは、[GetActivityTask](https://docs.aws.amazon.com/step-functions/latest/apireference/API_GetActivityTask.html) API アクションを使用して、実行中のステートマシンにより、実行スケジュールがある指定されたアクティビティ ARN を持つタスクを取得する API アクション。`GetActivityTask` はロングポールをスタートするため、サービスは HTTP 接続を開いたままにして、タスクが使用可能になるとすぐに応答します。応答前にサービスがリクエストする最大時間は 60 秒です。60 秒以内に利用可能なタスクがない場合、ポーリングは Null 文字列を持つ `taskToken` を返します。このタイムアウトを回避するには、 AWS SDK または API コールを行うために使用しているクライアントで[、タイムアウトが 65 秒以上の](https://docs.aws.amazon.com/step-functions/latest/apireference/API_GetActivityTask.html)クライアント側ソケットを設定します。
## Express ワークフローのトラブルシューティング
### `[StartSyncExecution](https://docs.aws.amazon.com/step-functions/latest/apireference/API_StartSyncExecution.html)` API コールからの応答を受信する前にアプリケーションをタイムアウトします。
API コールを行うために使用する AWS SDK またはクライアントでクライアント側のソケットタイムアウトを設定します。応答を受信するには、タイムアウトには Express ワークフローの実行時間よりも長い値を指定する必要があります。
### Express Workflow 障害をトラブルシューティングするために、実行履歴を表示できません。
Express ワークフローは、 AWS Step Functionsに実行履歴を記録しません。代わりに、CloudWatch ログ記録を有効にする必要があります。ログ記録を有効にした後は、CloudWatch Logs Insights クエリを使用して Express ワークフロー実行を確認できます。**[実行]** タブの **[有効化]** ボタンを選択すると、Express Workflow 実行の実行履歴を Step Functions コンソールに表示することもできます。詳細については、「[Step Functions コンソールでの実行の詳細の表示](concepts-view-execution-details.md)」を参照してください。
所要時間に基づいて実行を一覧表示するには:
```
fields ispresent(execution_arn) as exec_arn
| filter exec_arn
| filter type in ["ExecutionStarted", "ExecutionSucceeded", "ExecutionFailed", "ExecutionAborted", "ExecutionTimedOut"]
| stats latest(type) as status,
tomillis(earliest(event_timestamp)) as UTC_starttime,
tomillis(latest(event_timestamp)) as UTC_endtime,
latest(event_timestamp) - earliest(event_timestamp) as duration_in_ms by execution_arn
| sort duration_in_ms desc
```
失敗した実行とキャンセルされた実行を一覧表示するには:
```
fields ispresent(execution_arn) as isRes | filter type in ["ExecutionFailed", "ExecutionAborted", "ExecutionTimedOut"]
```