AWS AIP サンプル問題

正解：A

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

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

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

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

正解：A

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

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

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

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

正解：B

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

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

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

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

正解：C

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

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

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

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

正解：D

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

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

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

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

正解：B

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

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

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

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

正解：C

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

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

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

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

正解：A・B

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

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

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

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

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

正解：A・B

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

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

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

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

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

正解：C

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

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

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

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

正解：B

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

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

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

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

正解：D

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

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

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

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

正解：A

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

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

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

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

正解：C

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

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

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

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

正解：B

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

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

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

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

正解：D

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

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

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

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

正解：C

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

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

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

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

正解：B

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

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

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

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

正解：D

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

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

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

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

正解：A

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

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

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

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

正解：C

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

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

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

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

正解：C

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

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

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

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

正解：B

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

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

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

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

正解：C

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

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

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

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

正解：B

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

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

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

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

正解：A

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

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

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

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

正解：A

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

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

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

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

正解：A

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

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

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

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

正解：C

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

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

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

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

正解：B

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

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

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

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