AIP実装と統合
EC サイト運営会社が Amazon Bedrock を使用して商品説明の自動生成パイプラインを構築しています。パイプラインは次の順序で実行されます：
①商品画像からのテキスト説明生成（Claude multimodal）
②品質チェック（Amazon Nova）
③5言語への翻訳（各言語で別モデル呼び出し）
④SEO 最適化（Claude）
1日あたり最大 10,000 商品を処理する必要があり、各ステップで異なるエラーハンドリング（タイムアウト・スロットリング・コンテンツフィルタリング）が必要です。また、品質チェックで不合格となった商品は人間レビューキューに送られます。この要件に最も適したオーケストレーションアーキテクチャはどれですか？
A単一の Lambda 関数内で全 Bedrock API 呼び出しをシーケンシャルに実装し、try-catch ブロックで各ステップのエラーハンドリングと条件分岐を行う
単一 Lambda 関数は最大実行時間 15 分の制約があり、10,000 商品の処理には不向きです。複数ステップのエラーハンドリングが一か所に集中してコードが複雑化し、障害発生時の再実行も全ステップからやり直しになります。
BAmazon EventBridge を使用して各ステップ完了時にカスタムイベントを発行し、後続の Lambda 関数をトリガーするイベント駆動アーキテクチャを実装する
EventBridge によるイベント駆動アーキテクチャは疎結合で拡張性はありますが、ワークフロー全体の進捗管理・可視化・一貫したエラーリカバリが Step Functions より実装が複雑になります。中間状態の管理にも別途 DynamoDB 等が必要です。
CAWS Step Functions ワークフローで各 Bedrock API 呼び出しをステートとして定義し、ステップ別の Retry・Catch 設定と SQS キューイングでスケーラブルなパイプラインを構築する
✓ 正解
Step Functions は各ステップを独立したステートとして管理し、ステップごとに異なる Retry・Catch ポリシーを設定できます。Choice ステートで品質チェック結果に基づく条件分岐が実装でき、SQS でバッファリングしてスループットを制御でき、10,000 商品/日のスケール要件にも対応できます。
DAmazon Bedrock Flows で全モデル呼び出しを条件分岐ノードと並列処理ノードを使って接続し、マネージドワークフローとして実装する
Bedrock Flows はモデル間のデータフローを視覚的に定義できますが、SQS キューイングや外部の人間レビューシステムとの連携、ステップごとに異なるカスタムエラーハンドリングには制約があります。スケール要件への柔軟な対応も Step Functions の方が優れています。
解説
AWS Step Functions は複雑なマルチステップワークフローのオーケストレーションに最適です。各 Bedrock API 呼び出しをステートとして定義し、ステップごとに異なる Retry・Catch ポリシーでタイムアウト・スロットリング・コンテンツフィルタリングを個別にハンドリングできます。品質チェック不合格時の人間レビューへの条件分岐は Choice ステートで自然に実装でき、SQS との統合でスループット制御も可能です。Bedrock SDK 統合により Lambda なしで直接 API 呼び出しもできます。
選択肢Aの単一 Lambda は最大実行時間（15 分）の制約があり、10,000 商品のシリアル処理はタイムアウトリスクがあります。各ステップのエラーハンドリングロジックも単一関数内に集中して複雑化します。
選択肢BのEventBridge イベント駆動は疎結合で拡張性はありますが、ワークフロー全体の状態管理・可視化・エラーリカバリが Step Functions より実装が複雑です。
選択肢Dの Bedrock Flows はモデル間のデータフロー定義に特化しており、SQS との統合や外部人間レビューシステムへの連携など複雑な要件への対応に制約があります。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでAIPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →