LearnifyAIP-C01 · 日本語の問題解説
動的なモデル選択：設定配信と瞬時の一貫性を区別する
Learnify学習ノート · 更新：
例題
あるeコマース企業は、規制、コスト最適化、パフォーマンス要件に基づき、Amazon Bedrockで複数の基盤モデル（FM）を切り替える必要があるグローバルな製品レコメンデーションシステムを運営しています。 会社は、独自のビジネスロジックに基づくカスタムコントロールを適用しなければならず、動的コスト閾値、AWSリージョン固有のコンプライアンスルール、そして複数のFMにわたるリアルタイムA/Bテストを含みます。 システムは新しいコードを展開せずにFM間を切り替えることができなければなりません。 システムは、ユーザー層、取引価値、規制ゾーン、そして時間単位で変動し、数千件の同時リクエストに対して即座に伝播する必要があるリアルタイムコスト指標など、複雑なルールに基づいてユーザーリクエストをルーティングしなければなりません。 どのソリューションがこれらの要件を満たしますか？
- A：環境変数を使用してルーティングルールとAmazon Bedrock FM ID を格納する AWS Lambda 関数をデプロイしてください。 ビジネス要件が変更された際には、Lambda コンソールを使用して環境変数を更新してください。 Amazon API ゲートウェイ REST API を設定し、ルーティングの決定を行うためにリクエストパラメータを読み取ります。
- B：Amazon API Gateway REST API リクエスト変換テンプレートを展開し、リクエスト属性に基づくルーティングロジックを実装します。 Amazon Bedrock の FM エンドポイントを REST および API のステージ変数として保存します。 システムがモデル間を切り替えたときに変数を更新します。
- C：AWS Lambda 関数を設定し、各ユーザーリクエストに対して AWS AppConfig エージェントからルーティング構成を取得します。 Lambda 関数でビジネスロジックを実行し、各リクエストに対して適切な FM を選択してください。 単一の Amazon API ゲートウェイ REST API エンドポイントを介して FM を公開します。
- D：Amazon API Gateway REST API の AWS Lambda オーソライザーで、AWS AppConfig に保存されたルーティングルールを評価します。ビジネスロジックに基づく認可コンテキストを返し、各 Amazon Bedrock FM に対応するモデル別 Lambda 関数へリクエストを送ります。
正解と元の解説
正解：C
C：AppConfig の動的設定を Agent から読み、Lambda が業務ルールでモデルを選びます。環境変数や authorizer の認可コンテキストだけでは不向きです。ただし Agent はキャッシュと更新間隔を持ち、全要求への瞬時一貫配信を保証しません。
見分けるポイント
業務ルールによる振り分けは、設定の置き場所と、その設定を使って判断する処理に分けて考えます。設定を動的に更新できることは、すべての同時リクエストがその瞬間に同じ版を見るという意味ではありません。問題の実装方針と、運用上の保証を分けて読みましょう。
考える順序
- モデル選択のルールが、利用者やコストなどのどの入力に依存するか整理する。
- 認可処理に渡す情報と、モデルを選択する業務ロジックを混同しない。
- キャッシュや更新間隔がある前提で、設定反映とロールバックを設計する。