あるヘルスケアテクノロジー企業が、患者オンボーディング（新規患者の登録と初期設定）プロセスをAWSで自動化するシステムを設計しています。患者がWebポータルから登録すると、以下の処理フローが実行されます。 【処理フロー】 1. 外部保険会社APIで保険適格性（保険が適用されるか）を確認する。APIのレスポンス時間は数秒から最長30分と不定 2. 適格性確認後、以下を並行して実行する： a. 主治医への患者登録通知を送信し、医師のシステムから確認コールバックを受信する（確認まで最大24時間かかることがある） b. オンプレミスのEMR（Electronic Medical Record：電子カルテ）システムとAWS Direct Connect経由で患者データを同期する（一時的な接続障害で失敗する場合がある） 3. 適格性確認後、AIケアプラン生成APIを呼び出す（処理時間：10〜60秒） 【エラー要件】 - オンプレミスEMR同期が3回リトライ後も失敗した場合：リクエストをS3にアーカイブしてSNSアラートを送信する補償処理（Compensating Transaction：分散システムで失敗した処理を取り消すための逆操作）を実行する - 各ステップのタイムアウトと再試行ポリシーを柔軟に設定できること 【コンプライアンス要件】 - 全ステップの実行履歴（入出力データ・タイムスタンプ）を監査ログとして保持すること - 最長で48時間に及ぶワークフロー全体のトレーサビリティを確保すること 【規模】1日あたり5,000件の新規患者登録 このワークフローを実装するための最適なAWSアーキテクチャはどれですか？
スタンダードワークフローがこのユースケースに最適な理由： ①最大実行時間が1年のため、最長48時間のワークフローに対応可能。 ②WaitForTaskToken パターンにより、外部の保険APIや医師確認システムからのコールバックを受信するまで実行を一時停止し、コールバック受信後に自動再開できる。 ③Parallel ステートで並行処理（医師通知とEMR同期）を宣言的に定義できる。 ④Catch/Retry ステートで補償処理（サガパターン）とリトライポリシーを設定できる。 ⑤全実行履歴はStep Functionsに自動記録され監査要件を満たす。1日5,000件はスタンダードワークフローの料金体系に適した規模。 不正解B：Step Functions エクスプレスワークフローの最大実行時間は5分間であり、最長48時間のワークフローには根本的に対応できない。複数のエクスプレスワークフローをチェーンすると状態管理が複雑化し、エクスプレスワークフロー自体に実行履歴の永続保存機能がないため監査ログの構築に追加実装が必要となる。 不正解C：SQS FIFO + Lambdaでもステップ間の処理は実現できるが、外部コールバック待機・複雑な分岐と並行処理の同期・補償処理のサガパターン・監査ログ管理をすべてカスタムコードで実装する必要があり、実装・運用コストが大幅に増大する。Step Functionsが提供するネイティブ機能を自前で再実装することになる。 不正解D：EventBridgeはイベントルーティングに優れるが、ワークフローオーケストレーション（複数ステップの実行順序・状態・補償処理の管理）には設計されていない。外部コールバック待機や並行処理の同期完了検知など、複雑なワークフローパターンの実装にはStep Functionsと比較して大幅に多くのカスタムロジックが必要で、信頼性と可視性も低下する。