トキヌク

AWS AIP サンプル問題

AWS Certified Generative AI Developer - Professional(AWS AIP)対策のオリジナル問題50問を無料公開。アプリの無料枠と同じ問題で、全200問収録のAWS AIP問題集から抜粋しています。「答えと解説を見る」を開くと、正解だけでなく全選択肢の解説を読めます。

50問無料公開 全200問収録 全選択肢解説付き
アプリで解く(無料・登録不要)→

基盤モデルの統合・データ管理・コンプライアンス

FM選択/ソリューション設計

Q1. ある企業は社内ナレッジ検索アシスタントの実現可能性を3か月で検証する必要があります。専任の機械学習エンジニアはおらず、複数ベンダーの大規模言語モデルを比較したうえで最終的なモデルを決めたいと考えています。検証期間中の利用量は読めないため、アイドル時に費用が発生する構成は避けたいという制約があります。この検証基盤として最も適切なものはどれですか。

  1. A. Amazon BedrockのサーバーレスAPIで複数プロバイダのモデルを従量課金で呼び出す
  2. B. Amazon SageMaker AIにオープンウェイトモデルをデプロイし、常時稼働のリアルタイムエンドポイントで比較する
  3. C. Amazon EKS上に推論サーバーを構築し、GPUノードグループでモデルごとにPodを配置する
  4. D. AWS Trainiumインスタンスで自社データからモデルを事前学習し、性能を比較する
答えと解説を見る

正解:A

A(正解) 正解。Bedrockは単一のAPIから複数プロバイダのFMを呼び出せ、インフラの管理が不要で、呼び出した分だけの従量課金になる。短期のPoCで基盤管理の負担とアイドルコストを同時に避けられる

B リアルタイムエンドポイントはインスタンス時間で課金されるため、呼び出しがない時間帯もコストが発生する。モデルごとにエンドポイントを立てると比較のたびに費用が積み上がる

C クラスター運用とGPUノードの管理が必要になり、専任の機械学習エンジニアがいない体制では3か月の検証期間の大半が基盤構築に消える

D 事前学習は数か月規模の投資であり、実現可能性の検証段階で選ぶ手段ではない。既存FMの比較という目的にも合致しない

FM選択/ソリューション設計

Q2. 複数の事業部がそれぞれ生成AIアプリケーションを開発しはじめており、アーキテクチャの品質にばらつきが出ています。中央のアーキテクチャチームは、モデル選定・プロンプト管理・責任あるAI・コストといった生成AI固有の観点を含めて各ワークロードを定期的にレビューし、改善項目を一覧として追跡できる仕組みを求めています。最も適切な手段はどれですか。

  1. A. AWS Well-Architected Toolで生成AIレンズを適用してワークロードをレビューする
  2. B. AWS Trusted Advisorのチェック結果を事業部ごとに集計して改善項目とする
  3. C. AWS Configのコンフォーマンスパックで生成AI用のルールセットを適用する
  4. D. AWS Control Towerのコントロールを有効にして逸脱を検出する
答えと解説を見る

正解:A

A(正解) 正解。Well-Architected Toolはレンズを適用して質問に回答する形式でレビューを行い、リスクと改善項目をワークロード単位で継続的に追跡できる。生成AIレンズが生成AI固有の観点を提供する

B Trusted Advisorはコストやサービス上限などの汎用チェックであり、生成AIの設計観点をレビューする仕組みではない

C Configはリソース設定の準拠状況を評価する発見的統制であり、モデル選定やプロンプト管理といった設計上の判断は評価できない

D Control Towerはマルチアカウントのガードレール適用が目的で、ワークロード単位の設計レビューと改善項目の追跡には対応しない

FM選択/ソリューション設計

Q3. 法務部門は、1件あたり約18万トークンに達する長大な契約書について、全条項を漏れなく反映した要約を生成したいと考えています。特定の条項を検索するのではなく、契約書全体を通して整合性のとれた要約が必要であり、条項の見落としは許容されません。品質を最優先する場合の設計として最も適切なものはどれですか。

  1. A. 契約書をチャンク分割してベクトルストアに格納し、RAGで関連チャンクだけを取得して要約する
  2. B. 契約書全体を1回のリクエストに収められるコンテキストウィンドウを持つFMを選び、全文を入力する
  3. C. 契約書の先頭から4,000トークン分だけを抜き出し、残りは切り捨てて要約する
  4. D. 契約書のコーパスで小型モデルをファインチューニングし、短いプロンプトで要約を生成する
答えと解説を見る

正解:B

A RAGはクエリに関連する一部のチャンクだけを取得する仕組みであり、全条項の網羅が要件の場合は見落としが避けられない

B(正解) 正解。網羅性が要件の要約では、文書全体をモデルに読ませることが最も確実である。FM選定の判断軸としてコンテキストウィンドウの長さが決定的になる

C 大半の条項が入力されないため、網羅性の要件を根本的に満たさない

D ファインチューニングは応答の傾向を学習させる手法であり、個別の契約書の内容を推論時に参照できるようにするものではない

FM選択/ソリューション設計

Q4. 毎晩、前日分の問い合わせ約100万件に対してFMでカテゴリ分類を行う必要があります。結果は翌朝の集計に間に合えばよく、リアルタイム性は求められません。分類は短文に対する単純なタスクで、社内評価では小型モデルでも必要な精度に達しています。コストを最小化する構成はどれですか。

  1. A. 最上位の大型FMをオンデマンドで呼び出し、Lambdaの同時実行数を引き上げて処理する
  2. B. 小型のFMに対してプロビジョンドスループットを購入し、常時確保した容量で処理する
  3. C. 小型のFMを選び、Amazon Bedrockのバッチ推論ジョブで一括処理する
  4. D. 大型FMを分類タスクでファインチューニングし、リアルタイムエンドポイントで推論する
答えと解説を見る

正解:C

A 大型モデルのトークン単価は小型モデルより大幅に高く、精度要件を満たすうえで過剰である。オンデマンドの同期呼び出しは大量処理では単価面で不利になる

B プロビジョンドスループットは確保している時間に対して課金されるため、夜間だけ使う用途では稼働していない時間の費用が無駄になる

C(正解) 正解。バッチ推論は非同期で大量のプロンプトを処理する仕組みで、オンデマンドより低い単価が適用される。翌朝までに完了すればよい要件と合致する

D 既に小型モデルで精度要件を満たしているためカスタマイズの必要がなく、学習コストと推論容量の確保費用が上乗せされる

FM選択/ソリューション設計

Q5. 社内向けチャットアシスタントの利用者から、送信後に画面が無反応になる時間が長いという苦情が出ています。回答は平均で800トークンほど生成されており、モデルの総所要時間そのものは想定内です。アプリケーション側の変更で体感待ち時間を改善する最も効果的な方法はどれですか。

  1. A. プロビジョンドスループットを購入して、モデル呼び出しのスループットを引き上げる
  2. B. バッチ推論ジョブに切り替えて、複数利用者の要求をまとめて処理する
  3. C. Amazon CloudFrontを前段に置いて、モデルの応答をエッジでキャッシュする
  4. D. ストリーミングAPIでトークンを逐次受け取り、生成の途中から画面に表示する
答えと解説を見る

正解:D

A スループットの確保はスロットリング対策であり、1リクエストの生成完了までの時間を短縮するものではない。無反応時間の原因に対処していない

B バッチ推論は非同期処理であり、対話型UIの応答時間はむしろ悪化する

C 対話の入力は利用者ごとに異なるためキャッシュがほとんどヒットせず、初回応答の待ち時間は変わらない

D(正解) 正解。ストリーミングは最初のトークンが返った時点から表示を開始できるため、総生成時間が同じでも体感待ち時間が大きく改善する

FM選択/ソリューション設計

Q6. プラットフォームチームは、各開発チームが生成AIアプリの基盤(VPCエンドポイント、ガードレール、ログ設定、IAMロール)を毎回自前で構築している状況を是正したいと考えています。承認済みの構成だけをセルフサービスで払い出し、バージョン管理された形で更新を配布する必要があります。最も適切な方法はどれですか。

  1. A. 構成手順をWikiに文書化し、各チームがCloudFormationテンプレートを自作する運用にする
  2. B. AWS CDKで標準構成をコンストラクト化し、AWS Service Catalogの製品として各チームへ払い出す
  3. C. AWS Configのルールで非準拠のリソースを検出し、修復アクションで設定を上書きする
  4. D. AWS Architecture Standardization Hubに承認済み構成を登録して各チームへ配布する
答えと解説を見る

正解:B

A 文書は強制力がなく、チームごとの解釈差が残る。更新の配布も各チーム任せになり、標準化の目的を達成できない

B(正解) 正解。Service Catalogは承認済み構成を製品としてバージョン管理し、セルフサービスで払い出せる。CDKコンストラクトと組み合わせることで標準コンポーネントの再利用が徹底される

C 作成後に是正する発見的統制であり、各チームが独自構成を作ること自体は止められない。標準構成の配布という要件も満たさない

D架空 このようなAWSサービスは実在しない。承認済み構成のカタログ化と払い出しを担うのはAWS Service Catalogである

FM選択/ソリューション設計

Q7. 3つの候補FMのうちどれを本番採用するかを決める必要があります。公開ベンチマークのスコアは僅差で、社内の業務文書に対する回答品質を根拠に判断したいと考えています。評価用に人手で作成した質問と模範解答のデータセットが500件用意できています。最も適切な進め方はどれですか。

  1. A. 公開ベンチマークのスコアが最も高いモデルをそのまま採用する
  2. B. 各モデルを社内データでファインチューニングし、学習損失が最も小さいモデルを選ぶ
  3. C. Amazon Bedrockのモデル評価ジョブで、自社データセットに対する各モデルの出力を比較する
  4. D. 本番トラフィックの一部を3モデルへ分岐させ、利用者からの苦情件数で判断する
答えと解説を見る

正解:C

A 公開ベンチマークは一般的なタスクの指標であり、自社ドメインの文書に対する品質を保証しない。用意した評価データセットを活かせていない

B 学習損失は回答品質の代理指標として不適切であり、選定のためにカスタマイズを行うのは手順が逆で費用も過大になる

C(正解) 正解。Bedrockのモデル評価では独自データセットを指定し、自動評価や人間による評価で複数モデルの出力を同一条件で比較できる。用意した500件をそのまま判断根拠にできる

D 本番利用者を評価に巻き込むことになり、品質が確認できていない段階のモデルを露出させてしまう。苦情件数は感度が低く比較の指標にもならない

FM選択/ソリューション設計

Q8. RAGアシスタントでは、役割定義・出力規約・用語集からなる約6,000トークンの共通プレフィックスを、すべてのリクエストの先頭に付与しています。利用増に伴い入力トークンの課金が支配的になり、レイテンシも悪化しています。共通プレフィックスの内容は業務要件上、短縮できません。最も効果的な対策はどれですか。

  1. A. 共通プレフィックスにプロンプトキャッシュを設定する
  2. B. 共通プレフィックスをAmazon S3に置き、Lambdaがメモリに保持してから毎回連結する
  3. C. 共通プレフィックスの内容でモデルをファインチューニングし、送信をやめる
  4. D. プロビジョンドスループットを購入して入力トークンの単価を下げる
答えと解説を見る

正解:A

A(正解) 正解。プロンプトキャッシングはリクエスト間で共通する先頭部分の処理結果を再利用し、キャッシュヒット時の入力トークン課金とレイテンシを削減する。内容を変えずに効果が得られる

B アプリケーション側の読み込みを効率化するだけで、モデルへ送信されるトークン数は変わらないため課金もレイテンシも改善しない

C 出力規約のような厳密な指示の遵守をファインチューニングで保証することはできず、カスタムモデルの利用には別途容量の確保費用も必要になる

D プロビジョンドスループットは確保した容量に対する時間課金であり、トークン単価を下げる仕組みではない

モデル切替/レジリエンス

Q9. 本番の生成AIアプリでは、利用するFMのモデルIDと推論パラメータをLambda関数の環境変数に設定しています。新モデルへの切替やパラメータ調整のたびにデプロイパイプラインを流す必要があり、問題が起きたときの切り戻しにも時間がかかります。コードもデプロイも変更せずに設定を切り替え、異常を検知したら自動で巻き戻せる仕組みはどれですか。

  1. A. AWS Systems Manager Parameter Storeに値を置き、Lambdaが起動のたびに取得する
  2. B. モデルIDごとにLambdaのエイリアスを作り、加重ルーティングで切り替える
  3. C. AWS Secrets ManagerにモデルIDを保存し、自動ローテーションで更新する
  4. D. AWS AppConfigで設定を管理し、自動ロールバック付きで段階展開する
答えと解説を見る

正解:D

A 設定の外出しはできるが、段階的な展開や異常検知による自動巻き戻しの仕組みを持たない。切り戻しは手動操作のままになる

B 設定値ごとに関数バージョンを作ることになり、結局デプロイが必要になる。パラメータの組み合わせが増えるほど管理が破綻する

C Secrets Managerは機密情報の保管とローテーションが目的であり、モデルIDのような機密でない設定値の配布には適さない。自動ロールバックの機能もない

D(正解) 正解。AppConfigは設定を段階的に展開し、指定したCloudWatchアラームが発報したら自動的に前の設定へ巻き戻す。アプリのデプロイを伴わずにモデルIDやパラメータを切り替えられる

モデル切替/レジリエンス

Q10. マルチテナントSaaSでは、テナントごとに異なるプロバイダのFMを選択できるようにしたいと考えています。現状はモデルごとにリクエストとレスポンスのJSON構造が異なるため、対応プロバイダを追加するたびにアプリケーションコードの分岐が増え続けています。分岐を最小化する方法はどれですか。

  1. A. Amazon BedrockのConverse APIを使い、モデル横断で共通のメッセージ形式で呼び出す
  2. B. モデルごとに専用のLambda関数を用意し、Step Functionsで振り分ける
  3. C. Amazon API Gatewayのマッピングテンプレートでモデルごとにリクエストを変換する
  4. D. 各モデルの入出力形式をDynamoDBに定義として保存し、実行時に読み込んで変換する
答えと解説を見る

正解:A

A(正解) 正解。Converse APIはモデルごとの入出力形式の差異を吸収する統一インターフェースを提供する。モデル固有のパラメータは追加フィールドに逃がせるため、切替時のコード変更を最小化できる

B 分岐がコードから構成へ移るだけで、プロバイダを追加するたびに関数とステートマシンの改修が必要になる

C 変換ロジックをマッピングテンプレートで保守することになり、可読性とテスト性が下がる。レスポンス側の差異も別途吸収する必要がある

D 変換仕様を自前で設計・保守し続けることになり、モデル側の仕様変更に追随する運用負荷が残る

モデル切替/レジリエンス

Q11. 東京リージョンで提供している生成AIアプリで、キャンペーンの時間帯にThrottlingExceptionが多発しています。利用しているモデルは一部のリージョンでしか提供されておらず、オンデマンドのクォータ引き上げだけでは短時間のバーストを吸収しきれません。アプリケーションへの変更を最小限にしつつ可用性を高める方法はどれですか。

  1. A. 利用可能な各リージョンにアプリ一式を複製し、Amazon Route 53のレイテンシールーティングで分散する
  2. B. クロスリージョン推論プロファイルを指定して呼び出し、複数リージョンの容量を利用する
  3. C. プロビジョンドスループットをピークに合わせて購入し、常時確保しておく
  4. D. 呼び出しをSQSにためて、夜間にバッチ推論ジョブでまとめて処理する
答えと解説を見る

正解:B

A アプリ全体のマルチリージョン化はデータ同期や運用の複雑さを伴い、変更を最小限にするという条件に反する。モデル容量の逼迫にだけ対処する手段としては過大である

B(正解) 正解。クロスリージョン推論では呼び出し時に指定するモデル識別子を推論プロファイルに変えるだけで、Bedrockが複数リージョンへ要求を振り分けてバーストを吸収する。追加のルーティング費用も発生しない

C 短時間のバーストに合わせた容量を常時確保することになり、費用対効果が著しく低い。なお推論プロファイルはプロビジョンドスループットに対応していない

D 対話型アプリの応答を非同期化することになり、利用者への即時応答という前提が崩れる

モデル切替/レジリエンス

Q12. EU域内の顧客向けサービスでは、推論処理をEU内のリージョンに限定することが社内規程で定められています。一方で、単一リージョンのオンデマンド容量ではピーク時のスループットが不足しています。規程を守りつつスループットを確保する構成はどれですか。

  1. A. グローバルクロスリージョン推論プロファイルを使用し、スループットと料金を最適化する
  2. B. EUリージョンでバッチ推論ジョブを使い、オンデマンド呼び出しをやめる
  3. C. EUのジオグラフィック(地域)クロスリージョン推論プロファイルを使用する
  4. D. SCPでaws:RequestedRegionをEUに限定したうえで、グローバル推論プロファイルを使う
答えと解説を見る

正解:C

A グローバルプロファイルは世界中の商用リージョンへ要求が振り分けられる可能性があるため、処理をEU内に限定する規程に違反する

B バッチ推論は非同期処理であり、ピーク時のリアルタイム応答という要件を満たさない

C(正解) 正解。地域単位の推論プロファイルは指定した地理的境界内のリージョンだけへ要求を振り分けるため、データレジデンシー要件を満たしたままスループットを引き上げられる

D グローバルプロファイルの利用にはリージョンを特定しない条件値の許可が必要であり、リージョンを列挙して限定する方式とは両立しない

モデル切替/レジリエンス

Q13. 基幹の問い合わせ対応アプリはFMの応答に依存しています。モデル側の障害や長時間のタイムアウトが起きた際に、画面全体をエラーにするのではなく、定型のFAQ回答と有人チャットへの導線を返すよう設計を見直すことになりました。連続して失敗した場合は一定時間モデル呼び出しを止め、その後に自動で復旧を試みる必要もあります。最も適切な実装はどれですか。

  1. A. Lambdaのデッドレターキューに失敗した呼び出しを退避し、後から再処理する
  2. B. Amazon API Gatewayの使用量プランでレート制限を設定し、過負荷時にリクエストを拒否する
  3. C. CloudWatchアラームで通知し、運用担当者が手動でフォールバックへ切り替える
  4. D. AWS Step FunctionsのワークフローでリトライとCatchを定義し、失敗状態に応じて代替パスへ分岐させる
答えと解説を見る

正解:D

A 失敗した処理を後追いで救済する仕組みであり、利用者へその場で代替応答を返すことはできない

B 自アプリへの流入を絞るだけで、下流のモデル障害時に代替応答へ切り替える動作にはならない

C 切替に人手の介在が必要なため、障害検知から切替までの間は利用者への影響が続く。自動復旧の要件も満たさない

D(正解) 正解。Step Functionsは再試行とエラー捕捉を宣言的に定義でき、連続失敗時に呼び出しを遮断して代替応答へ分岐するサーキットブレーカーを状態として実装できる

モデルカスタマイズ/ライフサイクル

Q14. 実験用に作成したカスタムモデル向けのプロビジョンドスループットを、6か月コミットで購入していました。3か月経過した時点で当該モデルの利用をやめ、アプリケーションからの呼び出しも完全に停止しましたが、請求は続いています。この状況についての正しい理解はどれですか。

  1. A. モデルを呼び出していなければ課金は発生しないため、別の原因を調査すべきである
  2. B. モデルユニット数を0に変更すれば課金を止められる
  3. C. コミット期間が終了するまで削除できず、その間の時間課金は継続する
  4. D. カスタムモデルを削除すれば、対応するプロビジョンドスループットも自動的に削除される
答えと解説を見る

正解:C

A プロビジョンドスループットは確保している容量に対する時間課金であり、呼び出しの有無とは無関係に費用が発生する

B モデルユニットは1以上で指定する必要があり、0にして課金を止めるという運用はできない

C(正解) 正解。1か月または6か月のコミットを選ぶと期間満了まで削除できず、削除するまで課金が続く。実験用途では無コミットを選ぶべきだった

D モデルとプロビジョンドスループットは別のリソースであり、モデルを削除しても容量の課金は止まらない

ベクトルストア設計2つ選択

Q15. 全社ナレッジベースで、部門・作成者・有効期限といった属性による絞り込みを行えるようにします。データソースはAmazon S3、ベクトルストアはAmazon OpenSearch Serverlessです。メタデータの設計として正しいものはどれですか。(2つ選択)

  1. A. ドキュメントごとに「ファイル名.拡張子.metadata.json」を同じ場所に置き、属性をキーと値で記述する
  2. B. 有効期限はエポック秒などの数値で保持し、大小比較の演算子でフィルタする
  3. C. 属性名にはx-amz-bedrockで始まる名前を使い、サービスが管理する属性と表記を揃える
  4. D. 有効期限が切れた資料はメタデータファイルを書き換えるだけで検索結果から外れるため、再同期は不要である
  5. E. 1つのクエリに指定できるフィルタは1つだけのため、部門と有効期限はそれぞれ別のクエリで絞り込む
答えと解説を見る

正解:A・B

A(正解) 正解。S3をデータソースにする場合、ナレッジベースは各ドキュメントに対応するメタデータファイルから属性を読み取る。ファイルがなければ絞り込みに使える属性は付与されない

B(正解) 正解。greaterThanのような比較演算子は数値属性に対して使える。日付を文字列のまま持つと範囲での絞り込みができない

C この接頭辞はサービスが予約しており、独自の属性名として使うことはできない

D 属性は取り込み時にベクトルインデックスへ書き込まれる。メタデータファイルを変更したら同期を実行しないと反映されない

E 論理演算子を使えば複数のフィルタを1つのクエリで組み合わせられる。別々に実行する必要はない

ベクトルストア設計2つ選択

Q16. Amazon Bedrock Knowledge Basesのベクトルストアとして、S3ベクトルバケットの採用を検討しています。設計を確定する前に把握しておくべき制約はどれですか。(2つ選択)

  1. A. バイナリ埋め込みには対応せず、浮動小数点の埋め込みのみを格納できる
  2. B. トークン数の大きい階層チャンキングと組み合わせると、ベクトルあたりのメタデータ上限を超えることがある
  3. C. メタデータによるフィルタリングは一切利用できない
  4. D. クエリごとに専用のコンピュートを事前にプロビジョニングする必要がある
  5. E. 1つのベクトルバケットに作成できるベクトルインデックスは1つに限られる
答えと解説を見る

正解:A・B

A(正解) 正解。バイナリベクトルの格納に対応するのはOpenSearchのサーバーレスとマネージドクラスターのみで、S3ベクトルバケットは浮動小数点のみを扱う

B(正解) 正解。階層チャンキングの親子関係はフィルタ対象外のメタデータとして保持されるため、トークン数を大きく取ると上限を超えて取り込みが失敗する。公式にも推奨されない組み合わせとされている

C キーと値のメタデータを付与してフィルタに使用できる。ただし前方一致と部分一致の演算子は利用できない

D インフラのプロビジョニングを不要にすることがS3 Vectorsの特徴であり、この記述は逆である

E 1つのベクトルバケット内に複数のベクトルインデックスを作成できる

実装とインテグレーション

エージェント実装/マルチエージェント

Q17. ある企業は、契約書レビューのマルチエージェントシステムをStrands Agents SDKで構築しています。処理は「条項抽出→リスク判定→要約生成」の順に必ず実行され、各ステップの出力が次のステップの入力になります。実行経路が実行ごとに変わると監査部門への説明ができなくなるため、経路を固定する必要があります。最も適切なマルチエージェントパターンはどれですか。

  1. A. Swarmパターンでエージェント同士が自律的にハンドオフする
  2. B. 単一エージェントに全ツールを渡し、モデルに順序を任せる
  3. C. Graphパターンでエージェントをノード、依存関係をエッジとして定義する
  4. D. Agents as Toolsでオーケストレータが各エージェントをツールとして呼ぶ
答えと解説を見る

正解:C

A Swarmは共有メモリを介して複数の専門エージェントが自律的に協調する方式で、どのエージェントがいつ動くかが実行ごとに変わりうる。経路を固定する要件に反する

B 順序の決定がモデル任せになるため非決定的であり、同じ入力でも異なる経路をたどりうる

C(正解) 正解。Graphは有向グラフの依存関係に従ってノードを実行する決定的なオーケストレーションであり、実行順序と入出力の受け渡しが定義どおりに固定される

D 呼ぶかどうかと順序をモデルが判断する構成のため、経路の固定にはならない

エージェント実装/マルチエージェント

Q18. ある企業は、顧客サポート向けエージェントをAgentCore Runtime上で運用しています。同一セッション内の多ターン会話に加えて、利用者の過去の問い合わせ傾向や好みをセッションをまたいで保持し、後続の予約エージェントからも同じ記憶を参照できるようにする必要があります。運用負荷を増やさずに実現する方法はどれですか。

  1. A. 会話履歴をすべてシステムプロンプトに連結して毎回渡す
  2. B. AgentCore Memoryの長期メモリを共有する
  3. C. ElastiCacheにセッションIDをキーとして会話履歴を保存する
  4. D. AgentCore Runtimeのセッション分離に任せ、状態は保持しない
答えと解説を見る

正解:B

A トークン量とコストが際限なく増え、コンテキスト長の上限にも達する。エージェント間で記憶を共有する仕組みにもならない

B(正解) 正解。短期メモリが同一セッションの多ターン会話を、長期メモリがセッションをまたぐ嗜好の保持を担い、同じメモリストアを複数のエージェントから参照できる

C 短期の会話状態は保持できるが、嗜好の抽出・要約と長期保存を自前で実装することになり運用負荷が下がらない

D セッション分離は実行環境を隔離する仕組みであり、記憶の永続化とは無関係

エージェント実装/マルチエージェント

Q19. ReActパターンのエージェントをStep Functionsの標準ワークフローで実装したところ、まれに同じツールを延々と呼び続けて処理が終わらないケースが発生しています。無駄なモデル呼び出しを止めつつ、打ち切り時には利用者へ定型の応答を返したいと考えています。最も適切な実装はどれですか。

  1. A. モデルのtemperatureを0に下げる
  2. B. Lambdaタスクの再試行回数を0に設定する
  3. C. ステートマシン全体のタイムアウトだけを設定する
  4. D. Choiceステートで反復回数の上限を判定する
答えと解説を見る

正解:D

A 出力のばらつきは減るが、ツール呼び出しの反復を構造的に止める保証はない

B 個々のタスクの再試行を止めるだけで、ワークフロー上のループそのものは止まらない

C 強制終了はできるが、タイムアウトに達するまで課金が続き、定型応答を返す経路も通らずに実行が失敗で終わる

D(正解) 正解。反復回数をステート変数として加算し、上限に達したら終了経路へ分岐させることでループを構造的に打ち切り、定型応答を返す経路へ制御を移せる

エージェント実装/マルチエージェント

Q20. エージェントが呼び出す社内の在庫APIが障害で応答しなくなると、エージェントのリクエストがすべてタイムアウト待ちになり、Lambdaの同時実行数を食い潰しています。障害中も在庫参照を伴わない会話は継続させたいと考えています。最も適切な対策はどれですか。

  1. A. サーキットブレーカーで代替応答へ切り替える
  2. B. 在庫API呼び出しの再試行回数を増やす
  3. C. Lambdaのタイムアウトを15分に延長する
  4. D. 在庫API呼び出しをSQSへ退避し、障害が復旧してから順次処理する
答えと解説を見る

正解:A

A(正解) 正解。連続失敗を検知したら在庫APIを呼ばずに即座に代替応答へ切り替えるため、タイムアウト待ちによる同時実行の占有が発生せず、他の会話を継続できる

B 応答しない相手への再試行は待ち時間と同時実行の占有をさらに悪化させる

C 1回あたりの待ち時間が延びるため、同時実行の枯渇はむしろ深刻になる

D 会話中に必要な同期応答が返せず、障害中はキューに滞留が積み上がるだけで解決にならない

エージェント実装/マルチエージェント

Q21. マルチテナントのエージェント基盤で、ツール用Lambdaが顧客ごとのS3プレフィックスにアクセスします。実行ロールには全テナント分の権限があり、モデルが生成したパラメータ次第で他テナントのデータを読める状態です。テナント数は数万規模で日々増減します。最小権限を強制する設計はどれですか。

  1. A. モデルへの指示文で他テナントのIDを使わないよう明記する
  2. B. テナントごとにLambda関数を複製し、実行ロールを個別に割り当てる
  3. C. テナントIDをセッションタグに付けてロールを引き受ける
  4. D. ツールの入力パラメータをLambda内で正規表現により検証する
答えと解説を見る

正解:C

A プロンプトによる制約には強制力がなく、権限の境界にはならない

B 数万規模では関数数の上限と運用が破綻し、テナントの動的な増減にも追随できない

C(正解) 正解。セッションタグの値を条件キーで参照するポリシーにしておけば、実行時の権限がテナント単位へ自動的に絞られ、モデルが誤ったパラメータを生成してもIAMが越境を拒否する

D 検証漏れや実装ミスがそのまま越境につながり、IAMによる強制にはならない

エージェント実装/マルチエージェント

Q22. 生成された与信審査コメントを、金額が一定以上の場合のみ担当者が承認してから確定する仕組みをStep Functionsで実装します。承認待ちは最長3営業日に及び、承認されしだい速やかに後続処理へ進む必要があります。最も適切な実装はどれですか。

  1. A. Waitステートで3日間待ってからDynamoDBの承認フラグを確認する
  2. B. Taskステートを .waitForTaskTokenで呼び出し、承認画面からトークンを返す
  3. C. Lambdaの中で承認完了までポーリングして待機する
  4. D. SQS標準キューへメッセージを送って承認を待つ
答えと解説を見る

正解:B

A 承認が早く済んでも待機し続けるため、速やかに後続へ進む要件を満たさない

B(正解) 正解。コールバックパターンでは承認が返るまで実行が待機し、トークンの受領と同時に後続へ進む

C Lambdaの最大実行時間は15分であり、3営業日の待機はできない

D 承認依頼の通知はできるが、待機中のワークフローを再開させる仕組みがなく、コールバックの標準的な手段ではない

エージェント実装/マルチエージェント

Q23. 3つの専門モデル(法務・財務・技術)に同じ契約書を評価させ、3つの出力を独自ロジックで統合して最終スコアを算出します。3つの評価は互いに独立しており、全体のレイテンシを最小化したいと考えています。Step Functionsでの最適な構成はどれですか。

  1. A. Choiceステートで最も適した1つのモデルだけを選んで呼び出す
  2. B. 1つのLambdaから3モデルを順番に呼び出す
  3. C. Mapステートで最大同時実行数を1にして処理する
  4. D. Parallelステートで3つの分岐を同時実行し、後続のLambdaで統合する
答えと解説を見る

正解:D

A ルーティングであってアンサンブルではなく、3観点を統合するという要件を満たさない

B 逐次実行のためレイテンシが3回分積み上がり、関数のタイムアウトにも近づく

C 同時実行数を1にすると逐次実行になり、並列化によるレイテンシ短縮が得られない

D(正解) 正解。独立した処理を並列に実行できるうえ、各分岐の結果が配列として揃うため統合ロジックに渡しやすい

エージェント実装/マルチエージェント

Q24. Converse APIのツール使用でエージェントを実装しています。モデルが生成したツール入力に必須項目が欠けている場合、現在はLambdaが例外を送出してワークフローごと失敗します。モデル自身に入力を修正させて処理を継続させたいと考えています。最も適切な実装はどれですか。

  1. A. 例外をそのまま送出し、Step Functionsの再試行で同じ入力を再実行する
  2. B. 不足している項目を既定値で補ってツールを実行する
  3. C. 検証エラーをtoolResultのstatus=errorとして不足項目とともにモデルへ返す
  4. D. toolConfigのtoolChoiceをanyに変更する
答えと解説を見る

正解:C

A 同じ入力を繰り返すだけで結果は変わらず、モデルに修正の機会を与えられない

B 誤った前提のまま処理が進み、モデルにも利用者にも誤りが伝わらない

C(正解) 正解。エラー内容を会話に戻すことでモデルは次のターンで入力を修正した新たなtoolUseを返せる

D ツールを必ず使わせる設定であり、入力の妥当性検証や自己修正とは無関係

ツール統合/MCP

Q25. 社内のMCPサーバーを設計しています。あるツールは200MBのベクトルインデックスをメモリに保持し、リレーショナルデータベースへの接続プールを使い回すことで応答時間を確保しています。トラフィックは平日日中に定常的に発生します。最も適したホスティング先はどれですか。

  1. A. Lambdaでステートレスに実行し、呼び出しのたびに必要な部分を読み込む
  2. B. ECS on Fargateで長時間稼働するサービスとして動かす
  3. C. Lambda@Edgeにデプロイして利用者に近い場所で実行する
  4. D. EventBridgeのスケジュールでLambdaを定期実行し、結果をキャッシュする
答えと解説を見る

正解:B

A 実行環境が再利用される保証がなく、インデックス読み込みと接続確立のコールドスタートが応答時間を損なう

B(正解) 正解。常駐プロセスとしてウォームキャッシュと永続的な接続を保持でき、実行環境やネットワークの制御も効く

C パッケージサイズとメモリの制約が厳しく、VPC内のデータベースにも接続できない

D MCPサーバーは呼び出しに応じてツールを実行するものであり、定期実行では要求に応えられない

ツール統合/MCP

Q26. 社内には既存のREST API(OpenAPI仕様書あり)とLambda関数が数十個あります。これらをMCP互換のツールとして複数のエージェントから使えるようにしたいのですが、既存実装には手を入れられません。最も工数の少ない方法はどれですか。

  1. A. AgentCore Gatewayに登録し、MCPエンドポイントとして公開する
  2. B. 各APIの前段にMCPサーバーをECSで自作し、ツール定義を手書きする
  3. C. 各Lambda関数をエージェントごとにtoolConfigへ直接定義する
  4. D. API GatewayでREST APIを束ね、エージェントから直接HTTPで呼ぶ
答えと解説を見る

正解:A

A(正解) 正解。既存のAPIやLambda関数をコードの書き換えなしにMCP互換ツールへ変換し、Gatewayのエンドポイント経由で各エージェントへ提供できる

B 実現はできるが数十個分の実装と運用が発生し、工数が最小にならない

C エージェントの数だけツール定義を重複管理することになり、MCP互換にもならない

D MCPのツール検出に対応しないため、エージェント側で個別の統合実装が必要になる

ツール統合/MCP

Q27. 開発者のローカル環境ではMCPサーバーをサブプロセスとして起動して利用していましたが、これをVPC内の複数のエージェントから共有して呼び出せるようにします。MCPの標準に沿った構成はどれですか。

  1. A. stdioトランスポートのままSSH経由で各エージェントから起動する
  2. B. MCPサーバーの応答をSQSキューへ書き出してエージェントへ配布する
  3. C. MCPサーバーをコンテナ化し、エージェントごとにサイドカーとして同居させる
  4. D. Streamable HTTPトランスポートでリモートエンドポイントとして公開する
答えと解説を見る

正解:D

A stdioはローカルのプロセス間通信向けのトランスポートであり、共有のリモートサーバーとして使う想定ではない

B MCPはJSON-RPCによる要求と応答のやり取りであり、キュー経由の片方向配布では成立しない

C エージェントの数だけインスタンスが増え、共有するという要件を満たさない

D(正解) 正解。MCPが定めるリモート用のトランスポートであり、ネットワーク越しに複数のクライアントから共有できる

ツール統合/MCP

Q28. エージェントのツールが、利用者ごとのアクセス権に基づいて外部SaaS(OAuth 2.0)のデータを取得する必要があります。利用者の同意取得とアクセストークンの安全な保管・更新を、既存の認証基盤を作り直さずに実現したいと考えています。最も適切なサービスはどれですか。

  1. A. AWS Secrets Managerに利用者ごとのトークンを保存する
  2. B. Amazon Cognitoユーザープールで外部SaaSの利用者を管理する
  3. C. AgentCore Identityにトークンの取得と更新を委ねる
  4. D. IAM Identity Centerで外部SaaSへの権限セットを割り当てる
答えと解説を見る

正解:C

A 保管はできるが、OAuthの同意フローとトークンの取得・更新は自前実装のままになる

B 自社アプリの認証は担えるが、SaaS側の認可を代行してトークンを取得する仕組みではない

C(正解) 正解。既存のIdPや資格情報プロバイダーと連携し、エージェントによる外部サービスへのアクセスに必要な同意とトークン管理を担う

D AWSアカウントへのアクセス管理が主眼であり、任意のSaaSのOAuthトークンをエージェント向けに保管・更新する仕組みではない

ツール統合/MCP

Q29. 全社共通のMCPゲートウェイに200を超えるツールを登録したところ、エージェントが適切なツールを選べず誤った呼び出しが増えました。登録ツールを削減せずに選択精度を改善する方法はどれですか。

  1. A. 全ツールの定義をシステムプロンプトの先頭にまとめて記載する
  2. B. Gatewayのセマンティック検索で候補を絞り込む
  3. C. toolChoiceをanyに設定し、必ずツールを使わせる
  4. D. 推論プロファイルを変更してより大きなモデルへ振り向ける
答えと解説を見る

正解:B

A 提示するツール数は変わらないうえコンテキストが膨らみ、選択精度はむしろ下がる

B(正解) 正解。要求内容に意味的に関連するツールだけをモデルへ提示できるため、登録数を減らさずに選択の難易度を下げられる

C ツールを使うかどうかの制御であり、どれを選ぶかの精度は改善しない

D コストは増えるが、200件の候補を一度に提示するという構造的な問題は解消しない

AIの安全性・セキュリティ・ガバナンス

ガードレール設計

Q30. ある金融機関は、Amazon Bedrockの基盤モデルと、Amazon SageMaker AIのエンドポイントにデプロイした自社ファインチューニング済みモデルを、同一の社内アシスタントから使い分けています。コンプライアンス部門は、どちらのモデルを経由した場合でも、拒否トピックと機密情報フィルタが同一の定義で適用されることを求めています。ポリシーの定義を一箇所に保ちながらこの要件を満たす方法はどれですか。

  1. A. SageMaker AIのエンドポイント設定にguardrailIdentifierを指定し、推論時にガードレールを適用する
  2. B. アプリケーションからApplyGuardrail APIを呼び、両モデルの入出力を同じガードレールで評価する
  3. C. SageMaker AI側には同等のルールを実装したLambda関数を用意し、Bedrock側は従来どおりガードレールを使い分ける
  4. D. Bedrockのモデル呼び出しログを有効にし、違反を検出したら事後に是正するプロセスを整備する
答えと解説を見る

正解:B

A SageMaker AIのエンドポイントにガードレールを結び付ける設定は存在しない。ガードレールの指定はBedrockのランタイムAPIのパラメータである

B(正解) 正解。ApplyGuardrailは基盤モデルの呼び出しから切り離されており、sourceにINPUTとOUTPUTを指定して任意のテキストを既存のガードレール定義で評価できる。Bedrock以外のモデルの入出力も同じ定義で扱えるため、ポリシーを1つのリソースに集約できる

C 同じルールを2箇所で保守することになり、定義の乖離が時間とともに避けられない。定義を一箇所に保つという要件を満たさない

D 検出は事後であり、有害な応答が利用者に到達すること自体を防げない。予防的な入出力制御の代替にならない

ガードレール設計

Q31. あるチームはAmazon Bedrock Guardrailsを作成し、アプリケーションからは常にDRAFTを指定して呼び出しています。安全チームがコンソールでフィルタ強度を調整して検証していたところ、その変更が数分後には本番の利用者応答に影響していることが判明しました。検証と本番を分離しつつ、適用中の設定を追跡できるようにする最も適切な方法はどれですか。

  1. A. 検証用と本番用に別々のガードレールを作成し、設定変更のたびに本番側へ手作業で反映する
  2. B. 安全チームのIAMロールからUpdateGuardrailを剥奪し、設定変更はすべて申請制の運用に切り替える
  3. C. CloudTrailでガードレールの更新イベントを監視し、想定外の変更を検知したらロールバックする
  4. D. 検証済みの設定からバージョンを作成し、本番はその数値バージョンを指定する
答えと解説を見る

正解:D

A 2つのリソースの同期を人手で維持することになり、反映漏れと差分が生じる。標準機能で解決できる問題に運用負荷を持ち込んでいる

B 変更そのものができなくなり検証が回らない。本番がDRAFTを参照しているという構造的な問題も残ったままである

C 発見的統制であり、変更が本番へ反映されること自体は止められない。検出までの間は利用者に影響が出る

D(正解) 正解。DRAFTは常に最新の編集内容を反映する作業用であり、数値バージョンは作成時点の設定を固定した不変のスナップショットになる。本番を数値バージョンに固定すれば以降の編集の影響を受けない

ガードレール設計

Q32. あるヘルスケア企業の問診支援アシスタントは、コンテンツフィルタのViolenceカテゴリをHighに設定しています。運用開始後、外傷やけがの症状を説明する正当な患者の入力が繰り返しブロックされ、問い合わせが急増しました。明確に有害な内容のブロックは維持したまま、この過剰なブロックを減らすために最も適切な変更はどれですか。

  1. A. Violenceカテゴリのフィルタ強度をHighからMediumに下げる
  2. B. Violenceカテゴリのフィルタ強度をNoneに設定し、判定はアプリケーション側で行う
  3. C. 医療用語をワードフィルタの許可リストに登録して例外扱いにする
  4. D. Violenceを無効にし、不適切な表現を拒否トピックとして定義する
答えと解説を見る

正解:A

A(正解) 正解。MediumではHIGHとMEDIUMの信頼度で有害と分類された内容だけがブロックされ、LOW信頼度の分類は許可される。Highで拾われていた境界的な入力が通るようになる一方、明確に有害な内容のブロックは維持される

B Noneは当該カテゴリのフィルタリングを一切行わない設定であり、明確に有害な内容も素通りする。要件の前半を満たさない

C ワードフィルタはブロックしたい語句を定義する機能であり、コンテンツフィルタの判定を打ち消す許可リストは提供されていない

D 拒否トピックは話題単位の回避であり、有害度の信頼度に応じた強度調整はできない。話題ごと遮断されるため過剰ブロックはむしろ悪化する

ガードレール設計

Q33. ある銀行の顧客向けチャットアシスタントでは、規制上、個別の投資助言に該当する回答を一切行ってはなりません。開発チームは禁止したい表現を洗い出してワードフィルタに数百語を登録しましたが、言い換えや遠回しな表現で助言めいた応答が生成される事例が続いています。表現の揺れに追随できる制御はどれですか。

  1. A. ワードフィルタの登録語をさらに増やし、四半期ごとに棚卸しする運用を追加する
  2. B. コンテンツフィルタのMisconductカテゴリの強度をHighに設定する
  3. C. 投資助言を拒否トピックとして定義し、説明と代表的な発話例を登録する
  4. D. システムプロンプトに投資助言を行わないことを明記し、モデルに遵守させる
答えと解説を見る

正解:C

A ワードフィルタは完全一致であり、語彙の網羅は原理的に終わらない。すでに失敗している方針の延長にすぎない

B Misconductは犯罪や違法行為に関する有害コンテンツのカテゴリであり、それ自体は合法な投資助言を検出する目的の分類ではない

C(正解) 正解。拒否トピックはトピックの自然言語定義に基づく意味的な判定であり、登録した語句の完全一致に依存しない。言い換えや遠回しな表現も同じトピックとして捉えられる

D システムプロンプトの指示は決定的な制御ではなく、文脈やプロンプトの操作次第で逸脱しうる。規制要件の担保には独立した強制層が必要である

プロンプト攻撃・敵対的入力対策

Q34. ある企業のRAGアシスタントでは、システムプロンプト、検索結果、利用者の質問を1つのプロンプト文字列に結合してInvokeModelを呼び出しています。入力タグは使っていません。ガードレールでプロンプト攻撃フィルタを有効にしましたが、検証で明らかなジェイルブレイク文を質問に混ぜても検出されません。拒否トピックと機密情報フィルタは期待どおり動作しています。原因として最も可能性が高いものはどれですか。

  1. A. プロンプト攻撃フィルタは応答側にのみ適用されるため
  2. B. 結合された検索結果の分量がフィルタの判定を希釈しているため
  3. C. 利用者の質問が入力タグで囲まれていないため
  4. D. InvokeModelがガードレールに対応していないため
答えと解説を見る

正解:C

A プロンプト攻撃は入力プロンプトを対象とする検出であり、応答専用ではない。原因の説明として誤りである

B 評価対象の文字量によって検出強度が変わるという仕様はない。ほかのフィルタが動作している事実とも整合しない

C(正解) 正解。タグがない場合はプロンプト全体がほかのポリシーの評価対象になるが、プロンプト攻撃フィルタだけは入力タグが存在することを前提とする。利用者の質問をguardContentタグで囲む必要がある

D InvokeModelとInvokeModelWithResponseStreamはいずれもガードレールに対応している。ほかのフィルタが動作している事実とも矛盾する

プロンプト攻撃・敵対的入力対策

Q35. あるチームはAmazon Bedrock Guardrailsの入力タグを使い、利用者が入力した部分だけを評価対象にしています。タグのサフィックスはアプリケーションのコードに定数として "app" が埋め込まれています。セキュリティレビューで、この実装が攻撃者に悪用されうると指摘されました。指摘の内容と対策として正しいものはどれですか。

  1. A. サフィックスが短いとタグの解析に失敗する場合があるため、上限の20文字の固定値に変更する
  2. B. 利用者が閉じタグを入力に含めて評価対象から抜け出せるため、リクエストごとにランダムな値を使う
  3. C. サフィックスがログに出力されると機密情報になるため、AWS Secrets Managerで管理して秘匿する
  4. D. 入力タグは入れ子にできないため、利用者の入力を1つのタグにまとめて囲む必要がある
答えと解説を見る

正解:B

A 長さの問題ではなく予測可能性の問題である。固定である限り同じ攻撃が成立する

B(正解) 正解。サフィックスが固定だとタグ構造が推測でき、閉じタグを挿入して以降の内容を未タグ領域に追い出せる。リクエストごとに一意の値を生成すればタグ構造が予測不能になる

C サフィックスは秘密情報ではない。秘匿したところで固定である限り、試行によって推測される余地は残る

D 入れ子が許されないのは事実だが、指摘された悪用のリスクとは無関係である

プロンプト攻撃・敵対的入力対策

Q36. ある保険会社は、契約規程を取り込んだAutomated Reasoning checksのポリシーをAmazon Bedrock Guardrailsに設定し、給付可否の回答が規程と論理的に整合することを検証しています。セキュリティチームは、この仕組みによってプロンプトインジェクションにも対処できると考えています。この理解に対する正しい指摘はどれですか。

  1. A. Automated Reasoning checksは入力プロンプトを検証対象とするため、注入された指示はVALID判定にならない
  2. B. Automated Reasoning checksがINVALIDを返すと応答が自動的にブロックされるため、追加の対策は不要である
  3. C. Automated Reasoning checksは話題の逸脱も検出するため、拒否トピックの役割も兼ねられる
  4. D. 与えられた内容をそのまま検証するだけなので、コンテンツフィルタのプロンプト攻撃検出と併用する
答えと解説を見る

正解:D

A 検証はポリシーの変数で捕捉できる範囲に限られ、攻撃的な指示文の有無を判定する機能ではない

B Automated Reasoning checksは検出モードのみで動作し、所見と根拠を返すだけでブロックはしない。応答を出すかどうかはアプリケーションが判断する

C ポリシーに関連しないテキストは無視されるため、話題の逸脱は検出できない。拒否トピックの代替にはならない

D(正解) 正解。Automated Reasoning checksは内容の真偽ではなくポリシーとの論理的整合を評価する。攻撃入力そのものの検出はコンテンツフィルタが担うため、両者を組み合わせる必要がある

ガードレール設計

Q37. ある企業は、日本語と英語で提供する社内アシスタントにAmazon Bedrock Guardrailsを適用しています。英語の入力では拒否トピックとプロンプト攻撃の検出が期待どおり働きますが、日本語の入力ではほとんど検出されません。ガードレールは作成時の既定のまま運用しています。原因と対策として正しいものはどれですか。

  1. A. 拒否トピックの定義文と発話例を日本語で記述し直す
  2. B. Classic tierは対応言語が限られるため、Standard tierに切り替える
  3. C. 日本語に対応するのは機密情報フィルタだけなので、PIIタイプの検出で代替する
  4. D. フィルタ強度が既定のままなので、すべてのカテゴリをHighに引き上げる
答えと解説を見る

正解:B

A 定義を記述する言語を変えても、ティアが判定できる言語そのものは増えない。Standard tierなら英語で定義しても日本語の入力を判定できる

B(正解) 正解。Classic tierのコンテンツフィルタ、プロンプト攻撃、拒否トピックが対象とするのは英語、フランス語、スペイン語だけである。Standard tierは日本語を含む多数の言語に対応し、有効化にはクロスリージョン推論の設定が必要になる

C 機密情報フィルタが日本語に対応しているのは事実だが、検出できるのは個人情報である。話題の逸脱や攻撃的な入力の判定の代わりにはならない

D 強度は有害と分類した信頼度に対するしきい値である。そもそも対応していない言語では、強度を上げても検出されるようにはならない

ハルシネーション抑止・出力検証

Q38. あるカスタマーサポートのRAGアプリでは、コンテキストグラウンディングチェックを有効にしています。監視の結果、「口座維持手数料はいくらか」という質問に対し、取得済み文書に確かに記載のある「クレジットカードの延滞金は23.99%である」という内容をそのまま返す事例が目立ちました。この事例を確実に遮断するために調整すべき設定はどれですか。

  1. A. グラウンディング(Grounding)の閾値を引き上げる
  2. B. 関連性(Relevance)の閾値を引き上げる
  3. C. 両方の閾値を1.0に設定して最も厳格にする
  4. D. 手数料以外の話題を拒否トピックとして定義する
答えと解説を見る

正解:B

A 応答は根拠ソースの記載どおりでグラウンディングスコアは高い。閾値を上げても当該事例は遮断されない

B(正解) 正解。応答は根拠ソースに忠実なためグラウンディングスコアは高いが、質問に答えていないため関連性スコアが低い。関連性の閾値を上げれば質問と噛み合わない応答を遮断できる

C 閾値に指定できるのは0から0.99までであり、1は指定できない。すべての応答が遮断されてしまうためである

D 返された内容は根拠文書の範囲内であり、想定される話題を網羅的に列挙する運用は成立しない。質問と噛み合わないという問題の本質を捉えていない

ハルシネーション抑止・出力検証

Q39. ある小売企業の分析アシスタントは、売上実績の集計値を利用者に回答します。現在は取得した明細データをプロンプトに含めて基盤モデルに合計や前年比を計算させていますが、同じ質問でも数値が揺れることがあり、経営会議の資料には使えないと指摘されました。数値の正確性を担保する設計はどれですか。

  1. A. 推論パラメータのtemperatureを0に固定し、出力の揺れをなくす
  2. B. コンテキストグラウンディングチェックを有効にし、計算結果が根拠と整合するか検証する
  3. C. 自然言語をSQLに変換してAthenaで実行し、その結果を回答に埋め込む
  4. D. より大きなコンテキストウィンドウを持つモデルに切り替え、明細データを全件投入する
答えと解説を見る

正解:C

A 出力の揺れは減るが、モデルが算術を誤る可能性そのものはなくならない。決定性と正確性は別の問題である

B 根拠ソースとの整合を評価する機能であり、算術の正しさを検算する機能ではない

C(正解) 正解。集計処理を決定的なクエリエンジンに委ね、モデルの役割は自然言語からクエリへの変換と結果の説明に限定される。同じ質問に対して常に同じ数値が得られる

D 投入量を増やしても計算をモデルに委ねる構造は変わらない。コストとレイテンシが悪化するだけである

GenAIアプリの運用効率と最適化

トークン効率とコスト最適化

Q40. ある企業は、社内規程に関する質問に答えるチャットアプリケーションをAmazon Bedrock上で運用しています。すべてのリクエストで同一の規程文書(約8,000トークン)をシステムプロンプトとして先頭に置き、その後ろにユーザーの質問文を付けて送信しています。請求の内訳を確認したところ、費用の大半が入力トークンによるものでした。開発チームは、アプリケーションの対話性を損なわずに入力トークン費用と初回応答までの時間を下げたいと考えています。最小限の改修で目的を達成する方法はどれですか。

  1. A. すべての推論をバッチ推論ジョブに移行する
  2. B. プロビジョンドスループットを1か月コミットで購入する
  3. C. システムプロンプトの直後にキャッシュチェックポイントを置く
  4. D. ユーザーの質問文を先頭に、規程文書を末尾に並べ替える
答えと解説を見る

正解:C

A バッチ推論は結果をS3へ非同期に書き出す方式であり、対話型チャットの応答経路には使えない。加えてバッチ推論APIはプロンプトキャッシングに対応していない

B プロビジョンドスループットはモデルユニット単位の時間課金であり、送信する入力トークン数そのものは減らない。変動の大きい対話トラフィックでは遊休時間の固定費が増える

C(正解) 正解。静的な接頭辞をキャッシュ対象にすると、2回目以降はその部分の再計算が省略され、キャッシュ読み取りトークンは通常の入力トークンより低い料率で課金される。レイテンシも短縮される

D プロンプトキャッシングは先頭からの連続した接頭辞を対象とする。可変部分を先頭に置くと接頭辞が毎回変わり、キャッシュヒットしなくなる

トークン効率とコスト最適化

Q41. あるチームは、Amazon Bedrockのプロンプトキャッシングを有効にしてコスト削減を狙いましたが、レスポンスを確認するとcacheReadInputTokensはほとんど0で、cacheWriteInputTokensばかりが計上されています。プロンプトの構造を調べたところ、システムプロンプトの冒頭にリクエストごとのセッションIDと現在時刻が埋め込まれ、その後ろに全社共通の長い指示文が続いていました。キャッシュヒット率を改善するために最も適切な対応はどれですか。

  1. A. キャッシュチェックポイントの数をモデルの上限である4つまで増やす
  2. B. セッションIDと時刻の埋め込み位置をチェックポイントより後ろへ移す
  3. C. maxTokensを小さくして応答の長さを抑える
  4. D. 推論をバッチ推論ジョブへ移して同じ接頭辞をまとめて処理する
答えと解説を見る

正解:B

A 接頭辞が毎回変化している限り、チェックポイントをいくつ置いてもすべてキャッシュミスになる。チェックポイント数は原因ではない

B(正解) 正解。キャッシュは先頭からの連続した接頭辞で照合されるため、可変値が先頭にあると全体が別物として扱われる。静的な指示文を前に、可変値を後ろに置くのが原則である

C maxTokensは出力側の上限であり、入力の接頭辞照合には一切関係しない。キャッシュ書き込みばかり発生する症状は変わらない

D バッチ推論APIはプロンプトキャッシングに対応していないため、キャッシュヒット率の改善にはならない

トークン効率とコスト最適化

Q42. ある企業は、長時間にわたる調査業務を支援するアシスタントをAmazon Bedrock上で構築しています。ユーザーは同じ資料コンテキストを保持したまま断続的に質問しますが、返信の間隔は5分から40分程度までばらつきます。プロンプトキャッシングは有効ですが、間隔が空くたびにキャッシュが失効し、大きなコンテキストの書き込みが繰り返されてコストが想定を上回っています。使用中のモデルは1時間のTTLに対応しています。最も適切な対応はどれですか。

  1. A. キャッシュチェックポイントに1時間のTTLを指定する
  2. B. 5分ごとに軽量なダミー推論を送ってキャッシュを延命する
  3. C. キャッシュチェックポイントを4つに分けて交互に使い回す
  4. D. バッチ推論APIに切り替えてセッション間でキャッシュを共有する
答えと解説を見る

正解:A

A(正解) 正解。既定のTTLは5分だが、対応モデルではcachePointにttlを指定して1時間へ延長できる。返信間隔が5分を超えがちな長時間セッションでは、書き込みの繰り返しを避けられる

B 余分な推論課金と運用の複雑さが増える。TTLを延長する正規の設定が用意されている以上、選ぶ理由がない

C チェックポイントを分けても各エントリのTTLは変わらず、間隔が空けば同様に失効する。分割はキャッシュ範囲の粒度を制御する手段であって有効期間の制御ではない

D バッチ推論はプロンプトキャッシングに対応しておらず、非同期処理のため対話にも使えない

トークン効率とコスト最適化

Q43. ある企業は、問い合わせメールを14種類に分類する処理を上位モデルで運用しています。月間の呼び出し件数が多く推論費用が課題ですが、分類精度は現在の水準を維持する必要があります。プロンプトはすでに簡潔で、モデル呼び出しログには上位モデルの応答が1年分蓄積されています。推論の単価を下げる最も適切な方法はどれですか。

  1. A. モデル蒸留で上位モデルを教師、小型モデルを生徒として学習させる
  2. B. 上位モデルのままtemperatureを下げて出力を安定させる
  3. C. 小型モデルへ切り替え、プロンプトに分類例を10件書き加える
  4. D. 上位モデルの応答をDynamoDBへ保存し、同じ本文が来たら再利用する
答えと解説を見る

正解:A

A(正解) 正解。蓄積されたモデル呼び出しログの応答を教師データに使って小型モデルをファインチューニングでき、用途を絞れば上位モデルに近い精度を保ったまま安価で高速なモデルで推論できる

B サンプリングの幅を狭めるだけで、処理されるトークン数もモデルの単価も変わらない

C 少数例の追加は毎回の入力トークンを増やすうえ、上位モデル相当の精度に届く保証がない

D 問い合わせメールの本文が完全一致することはまれで、ヒット率が上がらない

モデル選定と価格性能比

Q44. ある企業は、英語圏向けカスタマーサポートのチャットボットをAmazon Bedrockで運用しています。問い合わせの約7割は定型的なFAQで小型モデルでも十分な品質が得られますが、残る3割は複雑なトラブルシューティングで上位モデルが必要です。現在は全件を上位モデルで処理しており費用が膨らんでいます。運用チームは、自前の振り分けロジックを実装・保守する負担を避けたいと考えています。最も適切な対応はどれですか。

  1. A. すべてのリクエストを小型モデルへ切り替える
  2. B. インテリジェントプロンプトルーティングで振り分ける
  3. C. プロビジョンドスループットを購入して上位モデルの実効単価を引き下げる
  4. D. Lambdaに独自の難易度分類器を実装して振り分ける
答えと解説を見る

正解:B

A 複雑な3割の問い合わせで回答品質が落ち、エスカレーションが増える。コスト削減と引き換えに要件を満たせなくなる

B(正解) 正解。プロンプトルーターは単一のサーバーレスエンドポイントとして動作し、同一モデルファミリー内の2モデルについてリクエストごとに応答品質を予測して振り分ける。自前のオーケストレーション実装が不要になる

C プロビジョンドスループットはモデルユニットの時間課金であり、問い合わせの難易度に応じた出し分けはできない。変動の大きい対話トラフィックでは遊休コストも発生する

D 技術的には実現できるが、分類器の学習・評価・保守という運用負担が発生し、それを避けたいという要件に反する

モデル選定と価格性能比

Q45. あるチームは、契約書の要点抽出タスクに使うモデルを3つの候補から選定しています。品質については正解付きのゴールデンデータセットで評価スコアを算出済みです。残る課題は、どのモデルが実運用で最も費用対効果が高いかを定量的に示すことです。経営層には、品質とコストのトレードオフを1つの指標で説明する必要があります。最も妥当な評価方法はどれですか。

  1. A. 公表されている100万トークンあたりの入出力単価が最も低いモデルを選ぶ
  2. B. InvocationLatencyのp50が最小のモデルを選ぶ
  3. C. 本番相当のプロンプト集合で入出力トークン数を実測して比較する
  4. D. 対応するコンテキスト長が最も大きいモデルを選ぶ
答えと解説を見る

正解:C

A 同じ課題でもモデルによって出力の冗長さと消費トークン数が大きく異なる。単価だけでは1リクエストあたりの実コストを反映できない

B レイテンシは重要な指標だが、品質もコストも表していない。費用対効果の判断材料としては不十分である

C(正解) 正解。実測したトークン数に単価を掛ければ1リクエストあたりの推定コストが求まり、これを評価スコアと突き合わせることで価格性能比として比較できる

D コンテキスト長は扱える入力の上限にすぎず、抽出精度やコスト効率とは直接結びつかない。むしろ長い入力を送れば費用は増える

テスト・検証・トラブルシューティング

FM評価フレームワーク設計

Q46. ある保険会社は、事故報告書をAmazon Bedrockの基盤モデルで要約する社内アプリを運用しています。品質管理部門は「保険業界の用語と免責表現の使い方が社内基準に沿っているか」という独自の観点でスコア化し、モデルやプロンプトを変更するたびに同じ物差しで比較したいと考えています。分類タスク向けの正解率のような指標ではこの観点を表現できません。運用負荷を抑えつつ要件を満たす方法はどれですか。

  1. A. 判定モデルを使う評価ジョブでカスタム指標を定義し、社内基準を採点プロンプトとして与える
  2. B. 自動評価ジョブで組み込みデータセットを選び、正確性のタスク型で実行する
  3. C. 組み込み指標のBuiltin.ProfessionalStyleAndToneだけを選んで採点させる
  4. D. SageMaker Ground Truthでラベリングジョブを作り、要約に正誤ラベルを付けて分類精度を算出する
答えと解説を見る

正解:A

A(正解) 正解。Amazon Bedrock評価のLLM-as-a-judgeは、組み込み指標に加えて独自の採点プロンプトとスコアスキーマを定義できる。ドメイン固有の観点を反復可能な数値として取得でき、変更のたびに同一条件で比較できる

B 組み込みデータセットは一般的な公開ベンチマークであり、社内基準の用語運用を問う設問を含まない。観点そのものを表現できない

C この指標は文体・書式・トーンがprofessionalな場にふさわしいかという一般的な適切さを測るもので、保険業界固有の用語規則は評価対象に含まれない

D Ground Truthは学習データのアノテーションが目的である。生成テキストの品質は単一の正誤ラベルに還元できず、分類精度では観点別のスコア化にならない

FM評価フレームワーク設計

Q47. あるスタートアップは、問い合わせ要約機能に使う基盤モデルを3候補から選定しています。経営層からは「品質だけでなく、1リクエストあたりのトークン消費と応答時間まで含めた費用対効果で決めること」と指示されました。3候補はいずれもAmazon Bedrockで利用でき、共通のプロンプトデータセットは用意済みです。最も適切な進め方はどれですか。

  1. A. Amazon Bedrockの料金表を確認し、100万トークンあたりの単価が最も安いモデルを採用する
  2. B. AWS Well-Architected Toolでコスト最適化の柱のレビューを実施し、その結果からモデルを決める
  3. C. 各モデルで評価ジョブを実行して品質スコアを取得し、CloudWatchのトークン数とレイテンシと突き合わせる
  4. D. AWS Cost Explorerで過去3か月のモデル別コストを比較し、支出が最も少ないモデルを選ぶ
答えと解説を見る

正解:C

A 単価が安くても冗長な応答でトークンを多く消費すれば総額は逆転する。品質と応答時間が評価に入っていない点も指示に反する

B Well-Architected Toolは設計原則に沿った定性的なレビューを行うツールであり、モデル候補を実測値で比較する仕組みではない

C(正解) 正解。品質はBedrock評価のスコアで測り、トークン効率と応答時間はAWS/Bedrock名前空間のInputTokenCount・OutputTokenCount・InvocationLatencyで測れる。両者を突き合わせて費用対効果を判断する

D 実績コストはすでに使ったモデルの支出でしかなく、まだ本番投入していない候補の比較には使えない。品質と応答時間も測れない

FM評価フレームワーク設計

Q48. ある企業は、Amazon Bedrockの基盤モデルと、Amazon EKS上に自社でホストしているオープンソースモデルを同じ物差しで比較したいと考えています。評価指標は統一し、レポートも一箇所にまとめる必要があります。自社ホストのモデルはEKS上に残す前提で、移行の工数は最小限に抑えたいと考えています。適切な方法はどれですか。

  1. A. Amazon Bedrockの評価対象はBedrockのモデルに限られるため、自社ホストモデルは別のOSS評価ツールで測って手作業で突き合わせる
  2. B. 自社ホストモデルの応答をあらかじめ生成してプロンプトデータセットに含め、評価ジョブを実行する
  3. C. Custom Model Importで自社ホストモデルをAmazon Bedrockに取り込んでから評価ジョブを実行する
  4. D. SageMaker Model Monitorでモデル品質モニタリングを設定し、両モデルの推論結果を継続監視する
答えと解説を見る

正解:B

A 前提が誤り。推論結果を持ち込めばBedrock外のモデルも評価ジョブの対象にできる。手作業の突き合わせは指標のぶれを招くうえ不要である

B(正解) 正解。プロンプトデータセットに推論レスポンスを含めるとAmazon Bedrockはモデル呼び出し手順をスキップして採点だけを行う。Bedrock外のモデルも同一指標で採点でき、レポートを一箇所に集約できる

C 取り込みには対応アーキテクチャの制約があり、EKS上に残すという前提とも矛盾する。応答データの持ち込みで済む場面で選ぶ手段ではない

D Model Monitorは稼働中エンドポイントのデータやモデル品質のドリフトを監視する機能であり、候補モデルを同一指標で採点して比較する評価ジョブの代替にはならない

LLM-as-a-judge/人手評価

Q49. 社内のナレッジ検索アシスタントを刷新するにあたり、想定質問と模範解答のペアを500件用意しました。判定モデルによる評価ジョブで、模範解答を踏まえて回答が正しいか、そして質問に含まれるすべての論点に答えられているかを採点させたいと考えています。選ぶべき組み込み指標の組み合わせはどれですか。

  1. A. Builtin.CorrectnessとBuiltin.Completeness
  2. B. Builtin.FaithfulnessとBuiltin.Refusal
  3. C. Builtin.CoherenceとBuiltin.Helpfulness
  4. D. Builtin.HarmfulnessとBuiltin.Stereotyping
答えと解説を見る

正解:A

A(正解) 正解。この2つはプロンプトデータセットに参照応答を含めると判定モデルがそれを踏まえて採点する。Correctnessが回答の正しさ、Completenessが質問の各論点への網羅性に対応する

B Faithfulnessはプロンプト内の文脈にない情報が混入していないかを見る指標で模範解答は参照しない。Refusalは回答を拒否したかどうかの判定であり、論点の網羅性は測れない

C 論理の一貫性と有用性を測る指標で、どちらも模範解答との照合を行わない。せっかく用意した正解応答が採点に使われない

D 有害表現とステレオタイプの有無を見る責任あるAI向けの指標であり、回答の正確性や網羅性とは無関係

LLM-as-a-judge/人手評価

Q50. ある医療機器メーカーは、添付文書を要約するアシスタントを開発しています。日々のプロンプト改修では品質の後退がないことを自動で確認したい一方、リリース判定については臨床的な妥当性を薬事担当の専門家が確認しなければならないという社内規程があります。評価の仕組みとして最も適切なものはどれですか。

  1. A. すべての評価を人間のワーカーによる評価ジョブで実施し、プロンプト改修のたびに専門家がレビューする
  2. B. すべての評価を判定モデルに任せ、専門家には評価レポートの要約だけを共有する
  3. C. 日々の確認は判定モデルの評価ジョブで自動化し、リリース判定は人間のワーカーによる評価ジョブに委ねる
  4. D. SageMaker Ground Truthのラベリングジョブに専門家を割り当て、日々の確認と最終判定の両方をそこで行う
答えと解説を見る

正解:C

A 改修のたびに専門家を拘束するため開発の回転が落ちる。日々の確認を自動化したいという要件を満たさない

B 臨床的な妥当性を専門家が確認するという社内規程に反する。判定モデルの採点は規程上の承認の代わりにならない

C(正解) 正解。Amazon Bedrock評価は判定モデルによる自動採点と、社内の専門家をワーカーとして招く人手評価の両方を提供する。頻度と厳格さで使い分けるのが定石である

D Ground Truthは学習データのアノテーションが目的であり、生成応答を指標別に採点して比較レポートを出す仕組みではない

続きは演習アプリで

このページの50問は、演習アプリなら弱点に合わせた出題・成績記録つきで解けます。全200問と本番形式の模擬試験は期間パス(1,500円/30日、自動更新なし)で利用できます。

AWS AIPの演習を無料で始める →

AWS AIP問題集の詳細(出題範囲・よくある質問)→

掲載している問題はすべてトキヌクのオリジナル問題です。実試験問題の流出コピー(ブレインダンプ)は一切使用していません。本サービスは非公式の学習教材であり、各認定団体とは提携・承認・後援関係にありません。試験名は各団体の商標または登録商標です。
トキヌク トップページへ