AWS認定資格 WEB問題集＆徹底解説

生成AIデベロッパー-プロフェッショナル

正解 B問題
分野1：基盤モデルの統合、データ管理、コンプライアンス 分野2：実装と統合 タスクステートメント1.2：FM の選定と設定 タスクステートメント2.2：モデルデプロイ戦略の実装
要復習（もう一度解きたい問題） 1 2 3 4
次の問題前の問題
合格に向けて、もっと深く学習する
豊富な問題と詳細なAWSサービス解説を、24時間無料でお試しいただけます
プレミアム会員機能を無料で試す ❯
問題文と選択肢
ある保険会社は、契約者向けの問い合わせチャットボットを AWS Lambda 上で運用しており、現在は基盤モデルとして Amazon Titan Text Express を利用している。プロダクトチームは、応答品質とコストを比較するため、リクエストの15%を Anthropic Claude 3.5 Haiku へルーティングする実験を開始したいと考えている。

運用チームには、初期構築が済んだ後、この配分比率をいつでも 0%〜100% の間で即座に変更できることが求められる。比率の変更に、CI/CD パイプラインでの再デプロイや Lambda 関数のコード修正を伴ってはならない。

この要件を満たす、最も運用負荷の低いソリューションはどれか。
  • Amazon API Gateway のカナリアリリースを設定し、Claude 3.5 Haiku を呼び出す新しい Lambda 関数を並行稼働させる。カナリアステージのトラフィック配分を15%に設定し、新しい Lambda 関数へリクエストを振り分ける
  • AWS AppConfig でマルチバリアント機能フラグを作成し、split 演算子によるトラフィック分割ルールでリクエストの15%を「バリアント」(Claude 3.5 Haiku)に、残りをデフォルト値 (Titan Text Express) にルーティングするよう定義する。Lambda 関数には AWS AppConfig Lambda 拡張を組み込み、フラグの値を取得させる
  • Amazon Bedrock Prompt Flows に条件分岐ノードを追加し、固定の重みパラメータでどちらのモデルを呼び出すか振り分ける。配分比率を変更する際は、新しいバージョンの Prompt Flow を発行してエイリアスを更新する
  • AWS Systems Manager Parameter Store にモデル ID と配分比率を含む JSON 文字列を保存する。Lambda 関数を呼び出しのたびにこのパラメータを取得するよう更新し、取得した比率をもとに自前の乱数判定ロジックで振り分け先を決定する
解説 頻出度★★★★★
この問題は、「2 つの基盤モデルへのトラフィック配分を 0〜100% で即座に変えたい × 再デプロイもコード修正もしない × 運用負荷は最小」の要件で、アプリの挙動を設定として外出しするマネージドなフィーチャーフラグを選べるかがポイント

A. Amazon API Gateway のカナリアリリースを設定し、Claude 3.5 Haiku を呼び出す新しい Lambda 関数を並行稼働させる。カナリアステージのトラフィック配分を15%に設定し、新しい Lambda 関数へリクエストを振り分ける

API Gateway のカナリアリリースは、ステージに紐づくデプロイの段階的な昇格のための仕組みである。比率自体はコンソールや API から変更できるものの、Claude を呼ぶ2 つ目の Lambda 関数を恒常的に維持する必要があり、共通ロジックの二重管理という運用負荷が生じる。
またカナリアは昇格（promote）または削除で終了する前提の一時的な構成で、「実験の比率を 0% と 100% の間で何度も往復させる」という使い方には設計思想が合わない。
実験のたびに API Gateway のステージ構成を触ることになり、最も運用負荷が低い方法とは言えない。

正解

B. AWS AppConfig でマルチバリアント機能フラグを作成し、split 演算子によるトラフィック分割ルールでリクエストの15%を「バリアント」(Claude 3.5 Haiku)に、残りをデフォルト値 (Titan Text Express) にルーティングするよう定義する。Lambda 関数には AWS AppConfig Lambda 拡張を組み込み、フラグの値を取得させる

正解。AWS AppConfig のマルチバリアント機能フラグは、split 演算子（(split pct::15 by::$userId) のような書式）を使って「指定した割合のトラフィックにこのバリアントを返す」というルールを設定として定義できる。
比率を変えるのは AppConfig の設定データを更新してデプロイするだけで、アプリケーションのコードにも Lambda のデプロイパッケージにも一切触れない（AppConfig の「デプロイ」は設定配信であり、CI/CD による再デプロイではない）。0% から 100% まで任意の値を設定でき、seed を指定すれば同一利用者が常に同じモデルに当たる一貫した分割もできる。
Lambda 関数に AWS AppConfig Lambda 拡張を組み込んでおけば、フラグ値は拡張がローカルにキャッシュして提供するため、呼び出しごとの API 往復も不要になる。設定の履歴管理・段階的な配信・CloudWatch アラーム連動の自動ロールバックまで標準で備わっており、運用負荷が最も低い。

C. Amazon Bedrock Prompt Flows に条件分岐ノードを追加し、固定の重みパラメータでどちらのモデルを呼び出すか振り分ける。配分比率を変更する際は、新しいバージョンの Prompt Flow を発行してエイリアスを更新する

Amazon Bedrock Prompt Flows の条件分岐は、入力内容に応じて経路を選ぶためのもので、確率的な重み付け配分を行う機能ではない。
決定的な問題は、選択肢自身が述べているとおり比率を変えるたびに新しいバージョンを発行してエイリアスを更新する点で、これは実質的なデプロイ作業にあたり、「いつでも即座に変更できる」という要件を満たさない。
フローの改版履歴が実験のたびに増えていくのも運用上望ましくない。

D. AWS Systems Manager Parameter Store にモデル ID と配分比率を含む JSON 文字列を保存する。Lambda 関数を呼び出しのたびにこのパラメータを取得するよう更新し、取得した比率をもとに自前の乱数判定ロジックで振り分け先を決定する

Parameter Store の値を書き換えれば比率自体は即座に変えられるため、要件の一部は満たす。しかし振り分けの判定を自前の乱数ロジックとして実装・保守することになり、フラグの履歴管理・段階的な配信・自動ロールバック・利用者単位の一貫性（同じ利用者が呼び出しのたびに別モデルへ飛ばないこと）を、すべて独自に作り込む必要がある。
さらに呼び出しのたびに GetParameter を実行する設計はレイテンシを増やし、API のスロットリング上限にも当たりやすい。
マネージドなフィーチャーフラグが用意されている以上、「最も運用負荷が低い」構成にはならない。

これだけ覚える（記憶フック）
コードを触らず挙動を変えるならフィーチャーフラグ。AWS AppConfig の split 演算子で N% を割り振る。
正解への思考ルート 問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。
要件 判断ポイント
配分比率を 0%〜100% の間でいつでも即座に変更したい 変更のたびにバージョン発行やデプロイが必要な方式は失格。設定値の更新だけで反映される仕組みを探す
→選択肢（C）を消す
比率変更に CI/CD の再デプロイや Lambda のコード修正を伴わない 挙動をコードから設定へ外出しするのがフィーチャーフラグの目的。AWS AppConfig がこの役割の標準サービス
→選択肢（B）が正解
最も運用負荷が低いこと（判断軸） 振り分けロジックを自作すると保守・一貫性・ロールバックまで自前になる。マネージド機能で置き換えられるなら置き換える
→選択肢（D）を消す
対象は Lambda から呼び出す基盤モデルの切り替え（恒常的な実験） API Gateway のカナリアはデプロイ昇格用の一時的な仕組みで、2 つ目の Lambda 関数の維持コストも発生する
→選択肢（A）を消す
ひっかけポイント
  • 選択肢 A のカナリアリリースは「15% に設定できる」ので一見要件を満たすが、Claude 用の Lambda 関数をもう 1 つ作って維持する必要がある。カナリアは新デプロイを昇格させるための一時的な機構であって、比率を何度も往復させる実験基盤ではない
  • 選択肢 C は選択肢の後半が失格条件を自白している。「新しいバージョンを発行してエイリアスを更新する」＝即座の変更ではない。長い選択肢は後半に落とし穴が置かれやすい
  • 選択肢 D は「Parameter Store の値を変えるだけ」に見えて、実際は振り分けの乱数ロジックを自作している。動くことと運用負荷が低いことは別問題
  • AWS AppConfig の「デプロイ」は設定データの配信であって、CI/CD によるアプリの再デプロイではない。この違いを取り違えると、正解の B を「デプロイが必要だから不可」と誤って消してしまう
出題バリエーション 同じ知識が本番では条件を変えて出題されます。
問題文がこう変わったら 正解はこう変わる
「特定の顧客セグメント（法人契約者だけ）に新モデルを出したい」 split ではなく、AWS AppConfig のコンテキストに対する条件ルール（ターゲティング）が正解軸に。
「Lambda 関数の新バージョンを段階的に本番へ昇格させたい」 今度は Lambda エイリアスの加重ルーティング／AWS CodeDeploy のカナリアデプロイが正解になる。
「2 つのモデルの応答品質を定量的に比較・スコアリングしたい」 Amazon Bedrock Model Evaluations（LLM-as-a-judge・人間評価）が正解軸に。
「モデルの選択自体をリクエスト内容の複雑さで自動的に切り替えたい」 Amazon Bedrock のインテリジェントプロンプトルーティングや Step Functions による動的ルーティングが正解軸に。
「新モデルでエラー率が上がったら自動的に切り戻したい」 AWS AppConfig のCloudWatch アラーム連動によるロールバックを含むデプロイ戦略が論点になる。
関連サービスの解説 Amazon Bedrock
AWS Lambda
AWS AppConfig
リファレンス この問題を解くために必要な知識を扱う公式ドキュメントです。
知識項目 公式ドキュメント
AWS AppConfig マルチバリアント機能フラグの split 演算子（割合によるトラフィック分割） Understanding multi-variant feature flag rules - AWS AppConfig
機能フラグのターゲット・バリアント・スプリット対応（機能追加のアナウンス） AWS AppConfig announces feature flag targets, variants, and splits
＋ 質問 / コメント
解答・解説に疑問がある場合や、よりよい解説がある場合など、お気軽にコメントください。ただし、短文コメントは表示されません。また、中傷などコメントの内容によっては、会員機能を停止させて頂きます。教え学び合える場になれば嬉しいです。（コメント投稿にはログインが必要です）
正答率 0%
No.15 解説
ある保険会社は、契約者向けの問い合わせチャットボットを AWS Lambda 上で運用しており、現在は基盤モデルとして Amazon Titan Text Express を利用している。プロダクトチームは、応答品質とコストを比較するため、リクエストの15%を Anthropic Claude 3.5 Haiku へルーティングする実験を開始したいと考えている。

運用チームには、初期構築が済んだ後、この配分比率をいつでも 0%〜100% の間で即座に変更できることが求められる。比率の変更に、CI/CD パイプラインでの再デプロイや Lambda 関数のコード修正を伴ってはならない。

この要件を満たす、最も運用負荷の低いソリューションはどれか。
  • Amazon API Gateway のカナリアリリースを設定し、Claude 3.5 Haiku を呼び出す新しい Lambda 関数を並行稼働させる。カナリアステージのトラフィック配分を15%に設定し、新しい Lambda 関数へリクエストを振り分ける
  • AWS AppConfig でマルチバリアント機能フラグを作成し、split 演算子によるトラフィック分割ルールでリクエストの15%を「バリアント」(Claude 3.5 Haiku)に、残りをデフォルト値 (Titan Text Express) にルーティングするよう定義する。Lambda 関数には AWS AppConfig Lambda 拡張を組み込み、フラグの値を取得させる
  • Amazon Bedrock Prompt Flows に条件分岐ノードを追加し、固定の重みパラメータでどちらのモデルを呼び出すか振り分ける。配分比率を変更する際は、新しいバージョンの Prompt Flow を発行してエイリアスを更新する
  • AWS Systems Manager Parameter Store にモデル ID と配分比率を含む JSON 文字列を保存する。Lambda 関数を呼び出しのたびにこのパラメータを取得するよう更新し、取得した比率をもとに自前の乱数判定ロジックで振り分け先を決定する

次の問題前の問題


(会員限定)当問題の評価をお願いします。改善に活用します。
広告

会員機能

お役立ち情報

姉妹サイト

アンケート

サイト情報