フィンテック企業が、大口送金取引の承認ワークフローにAmazon Bedrockエージェントを組み込んでいます。エージェントが送金指示を作成したとき、実際のLambda実行前に人間のコンプライアンス担当者が承認する必要があります。承認後はエージェントの推論を継続させ、その結果を最終応答として返す設計が求められます。Lambda関数のタイムアウト制限（最大15分）を超える可能性がある承認プロセスにも対応しなければなりません。最も適切な実装はどれですか？
RETURN_CONTROLアクショングループ呼び出しタイプを使うと、エージェントはLambdaを実行せず実行予定の関数名とパラメータを呼び出し元アプリに返す。アプリは人間承認を取得した後、InvokeAgent APIで承認結果をエージェントに渡してセッションを再開できる。Lambdaのタイムアウト制限に依存しないヒューマン・イン・ザ・ループの標準実装パターンです。 選択肢AのアクショングループのLambdaからSQSキューへのメッセージ送信とポーリングは、Lambda内で最大15分待機するためタイムアウト制限を超える可能性があります。 選択肢CのBedrock Guardrailsのカスタムトピックポリシーは未承認送金をブロックするフィルタリングであり、承認プロセスの実装ではありません。 選択肢DのStep FunctionsのwaitForTaskToken パターンはエージェントの代わりにStep Functionsが待機状態を管理する実装ですが、エージェントとの統合が複雑になります。