ある企業のDevOpsチームが、データベース接続プール枯渇インシデントへの対応フローをAWS Step Functionsで自動化しています。ワークフローの要件は以下の通りです。 1. CloudWatchアラーム発火時に診断情報を収集する（自動） 2. 接続プールの自動スケールアップを試みる（自動） 3. 自動対応が解決しない場合、担当エンジニアに承認メールを送り、エンジニアの「承認」または「ロールバック指示」を待機する（人手） 4. エンジニアの応答に基づいて次のアクションを実行する ステップ3の「人間承認の待機」を実装するための最適なStep Functionsパターンはどれですか？
.waitForTaskTokenパターンはStep Functionsの標準パターンで、人間承認ワークフローや外部システムのコールバック待機に最適です。Step Functionsは実行固有のタスクトークン（ユニークID）とともに処理を一時停止し、SNS・メール等でトークンを担当者に配布します。担当者がSendTaskSuccess（承認）またはSendTaskFailure（拒否）APIをトークン付きで呼び出すと実行が再開されます。待機中のコスト発生はなく、HeartbeatSecondsでタイムアウト設定も可能です。 選択肢A: Wait状態は固定時間だけ待機するものであり、人間の応答を待つ機能はありません。担当者が応答する前にタイムアウトしてデフォルトのロールバックが実行されてしまう可能性があり、実際の承認ワークフローには不適切です。 選択肢C: Lambdaにsleep()を30分実行させようとしていますが、AWS Lambdaの最大実行タイムアウトは15分（900秒）のため30分のsleepは実行できません。また「Choice状態でSQSをポーリングする」という構造はStep Functionsのアーキテクチャとして成立しません。 選択肢D: Activityワーカーも人間承認に利用可能ですが、常時稼働するポーリングサーバーが必要となりインフラコストと管理負担が大きく、.waitForTaskTokenパターンと比べてサーバーレスの利点を生かせません。