AIP資格演習問題（無料10問）

【AIP-2001】ある金融機関は、コールセンターの通話記録を Amazon S3 に蓄積しています。毎晩、その日に蓄積された約 50,000 件のテキスト記録を Amazon Bedrock の基盤モデルで要約し、結果を S3 に書き戻す処理を計画しています。要約結果は翌朝の業務開始までに利用できればよく、対話的な応答は不要です。1 件あたりの入力は長文で、処理全体のトークン量は膨大になります。同社は要約処理にかかる料金を最小限に抑えたいと考えています。これらの要件を最もコスト効率よく満たす方法はどれですか。

【AIP-2002】ある小売企業は、社内の問い合わせ対応チャットボットの概念実証を 2 週間で完了させる計画です。企業は Amazon Bedrock で利用できる複数の基盤モデルを候補としており、応答の精度、堅牢性、有害性の観点で品質を比較したいと考えています。データサイエンスチームは評価用データセットを保有しておらず、比較用の採点コードを書く余裕もありません。企業は概念実証の段階で、対話型ユースケースに求められるレイテンシーが最小となるモデルを見極める必要もあります。これらの要件を最も効率的に満たす手法はどれですか。

【AIP-2003】ある金融サービス企業は、複数の事業部門が Amazon Bedrock を利用した生成 AI アプリケーションをそれぞれのアカウントにデプロイしています。各部門が独自にリソースを構成した結果、ログ設定や暗号化の指定にばらつきが生じています。同社は、Bedrock の呼び出し基盤と API Gateway、Lambda を含む標準化された技術コンポーネントを全部門に配布したいと考えています。配布物は変更履歴を追跡でき、社内のセキュリティ基準に違反する構成が環境に作成される前に検出される必要があります。これらの要件を満たす方法はどれですか。
(2 つ選択してください。)

【AIP-2004】ある保険会社は Amazon Bedrock を使用した文書要約アプリケーションを開発環境、検証環境、本番環境の 3 つの環境で運用しています。各環境のアプリケーションは AWS Lambda 関数から Bedrock Runtime の InvokeModel を呼び出しています。現在はプロンプト文字列を Lambda 関数のコード内にハードコードしており、文面を修正するたびに 3 環境すべての関数を再デプロイしています。同社はプロンプトを一元的に保存してバージョンを管理し、顧客名や証券番号を差し込む変数を定義したうえで、各環境の Lambda 関数からコード変更なしに参照したいと考えています。運用オーバーヘッドを最小限に抑えてこれらの要件を満たす方法はどれですか。
(2 つ選択してください。)

【AIP-2005】ある製造業の企業は、複数の事業部門で Amazon Bedrock を利用した生成 AI アプリケーションを個別に開発しています。各部門はチャットボット、文書要約、ナレッジ検索といった異なるシナリオでデプロイを進めています。しかし設計の観点が部門ごとに異なり、プロンプトの取り扱い、ガードレールの適用、ベクトルストアの構成に一貫性がありません。企業のアーキテクチャチームは、デプロイシナリオが異なっても同じ設計観点でワークロードをレビューし、生成 AI 固有のリスクと改善項目を洗い出したうえで、標準化された技術コンポーネントの整備につなげたいと考えています。この要件を満たす方法はどれですか。

【AIP-2006】ある保険会社は、契約書類の要約を生成する社内アプリケーションの構築を計画しています。Amazon Bedrock で利用可能な複数の基盤モデルのうち、どのモデルが自社の契約書類に対して最も適切な要約品質を示すかを判断する必要があります。同社はすでに、代表的な契約書の抜粋と期待される要約を組み合わせた 500 件のサンプルを Amazon S3 に JSONL 形式で保存しています。評価は要約精度や堅牢性などの指標に基づいて数値化され、モデル間で横並びに比較できる必要があります。同社には機械学習の専門家がおらず、評価用の基盤を新たに構築することなく、追加コストを最小限に抑えて実施したいと考えています。これらの要件を満たす方法はどれですか。

【AIP-2007】あるメディア企業は、Amazon Bedrock の基盤モデルを呼び出す記事要約機能を AWS Lambda 上で運用しています。編集チームは、要約タスクごとに使用するモデル ID や temperature、最大トークン数を頻繁に見直しており、変更のたびに Lambda 関数の再デプロイが必要になっています。今後はモデルプロバイダーの切り替えも想定されるため、アプリケーションコードを変更せずに設定値を差し替えられる仕組みが求められています。設定値は配信前に形式の妥当性を検証し、問題があれば以前の値に戻せる必要があります。これらの要件を満たす構成はどれですか。

【AIP-2008】ある企業は Amazon Bedrock 上で複数の基盤モデルを利用するチャットアプリケーションを AWS Lambda と Amazon API Gateway で構築しています。リクエストの種類に応じて使用するモデル ID と推論パラメータを切り替える仕組みが必要です。運用チームは、モデルの追加や切り替えの判断を業務時間中に何度も行います。切り替えの際に Lambda 関数のコードや API Gateway のステージを再デプロイすることは避けたいと考えています。設定値は低レイテンシーで参照できる必要があります。これらの要件を満たす構成はどれですか。

【AIP-2009】ある小売企業は、Amazon Bedrock の複数の基盤モデルを呼び出す顧客向けチャットアプリケーションを AWS Lambda 上で運用しています。アプリケーションは、モデル ID、temperature、top-k といったパラメータをコード内にハードコードしています。企業は、モデルのプロバイダーや推論パラメータを切り替えるたびに Lambda 関数の再デプロイが必要になっている状況を改善したいと考えています。切り替えは一部のトラフィックから段階的に適用し、設定値が想定されたスキーマに適合しているかを適用前に検証する必要があります。また、切り替え後に CloudWatch のエラーメトリクスが悪化した場合は、以前の設定へ自動的に戻す必要があります。これらの要件を満たす方法はどれですか。

【AIP-2010】あるコンテンツ配信企業は、Amazon Bedrock 上の複数のプロバイダーの基盤モデルを利用する対話型アプリケーションを AWS Lambda と Amazon API Gateway で構築しています。現在、Lambda 関数はプロバイダーごとに異なる JSON リクエストボディを組み立てており、モデルを切り替えるたびにコードの修正とデプロイが必要です。同社は、モデル ID を AWS AppConfig で管理し、コードを変更せずにモデルとプロバイダーを動的に切り替えられるようにしたいと考えています。同時に、ユーザーへの応答のレイテンシーを最小限に抑える必要があります。これらの要件を満たす方法はどれですか。