AIF-C01 の無料練習問題
AIプラクティショナー

正解は A である。API のインスタンスをプライベートサブネットに置けば、インターネットから直接アクセスさせない要件を満たせる。そのうえで、業務アプリ層のインスタンスは同じ VPC 内にあるため、API のインスタンスのセキュリティグループに、業務アプリ層のセキュリティグループを送信元に指定したルールを設定すれば、そのグループに属するインスタンスからの通信だけを、IP アドレスを指定し直さずに許可できる。 B は、IAM プリンシパルの認証情報による署名が Amazon Bedrock へ送るリクエストに関する仕組みであり、EC2 上の API への送信元を制限するものではないため誤りである。パブリックサブネットに置く点も1つ目の要件に合わない。 C は、AWS のグローバルネットワークセキュリティが基盤を保護する点は正しいが、インスタンスに許可するトラフィックはセキュリティグループのルールで決まり、これは利用者が設計する範囲であるため誤りである。 D は、業務アプリ層のインスタンスを IP アドレスで指定する設計であり、要件に反する。また、ネットワーク ACL はサブネットに許可するトラフィックを制御し、インスタンスに許可するトラフィックを制御するのはセキュリティグループのルールである。

A：正解。インターネットから直接アクセスさせないインスタンスにはプライベートサブネットを使うため、1つ目の要件を満たせる。また、インスタンスに関連付けたセキュリティグループのルールが、そのインスタンスに許可するトラフィックを決める。業務アプリ層のインスタンスは同じ VPC 内にあるため、このルールの送信元に業務アプリ層のセキュリティグループを指定でき、そのグループに属するインスタンスからの通信だけを許可できる。IP アドレスは指定せず、増減するインスタンスもグループに属させるだけで済むため、2つ目の要件も満たせる。なお、許可の対象は『そのセキュリティグループに属するインスタンス』であり、サブネットの位置では限定していない。

B：誤り。IAM プリンシパルの認証情報による署名は、EC2 上の API から Amazon Bedrock へ送るリクエストに関する仕組みである。EC2 上の API に、どの送信元から到達できるかを決める設定ではないため、業務アプリ層以外からの接続を防ぐ根拠にならない。また、インターネットから直接アクセスさせないインスタンスにはプライベートサブネットを使うべきで、パブリックサブネットへの配置は1つ目の要件にも合わない。

C：誤り。AWS のグローバルネットワークセキュリティは AWS が基盤を保護する仕組みであり、その点自体は正しい。しかし、インスタンスに許可するトラフィックは、そのインスタンスに関連付けたセキュリティグループのルールで決まる。これは利用者が設計する範囲であり、基盤の保護があるからといってパブリックサブネット上のインスタンスへの直接アクセスが防がれるわけではない。インターネットから直接アクセスさせないインスタンスにはプライベートサブネットを使う必要がある。

D：誤り。業務アプリ層のインスタンスを IP アドレスで指定しており、送信元を IP アドレスで指定し続けたくないという要件に反する。また、サブネットに関連付けたネットワーク ACL のルールはサブネットに許可するトラフィックを制御し、インスタンスに許可するトラフィックを制御するのはインスタンスに関連付けたセキュリティグループのルールである。インスタンスの増減に追従できる設計でもない。

学習のポイント：業務アプリ層のインスタンスだけを、IP アドレスに頼らず API のインスタンスへ通す要件は、インスタンスに関連付けるセキュリティグループのルールで設計するものだと判断できるかが鍵である。

公式ドキュメント

• infrastructure-security.html

この要件は、責任ある AI の観点では回答の真実性(veracity)を保つことです。問題文は 3 つの条件を同時に求めています。1 つ目は、モデルの自己申告ではなくトークン確率に基づく指標を使うことです。2 つ目は、回答を JSON オブジェクトとして固定することです。3 つ目は、レイテンシーとスループットへの影響を小さくすることです。A と D は対数確率を使うため 1 つ目の条件を満たします。しかし json_schema と grammar は複雑な制約であり、制約検証によってレイテンシーの増加とスループットの低下を招き得ます。厳密なスキーマ検証が不要なので、これらを選ぶ理由はありません。C は json_object で 2 つ目と 3 つ目の条件を満たしますが、確信度の数値がモデルの出力した値であり、1 つ目の条件を満たしません。B は対数確率で 1 つ目を、単純な制約である json_object で 2 つ目と 3 つ目を満たします。したがって B が正解です。

A：対数確率を使うため、トークン確率に基づく客観的な指標という要件は満たします。しかし json_schema は複雑な制約に分類され、生成中の制約検証によってレイテンシーの大幅な増加とスループットの低下を招き得ます。問題文は厳密なスキーマ検証を求めておらず、より軽い制約で足りるため、性能要件の点で最適ではありません。

B：対数確率は 2025 年 11 月 11 日より後に取り込んだモデルで使え、トークン確率に基づく確信度のしきい値を設けられます。json_object は単純な制約に分類され、性能への影響が小さいタイプです。JSON 形式の固定という要件と、レイテンシー・スループットへの影響を抑える要件を両立できます。客観的な指標、JSON 出力、性能の 3 つの条件を同時に満たすのはこの組み合わせです。なお、対数確率がハルシネーションそのものを防ぐわけではなく、確信度の低い回答を選別して人手確認に回すために使います。

C：json_object は単純な制約で性能への影響が小さく、JSON 形式の固定という要件も満たします。しかし確信度の数値はモデルが出力した内容そのものであり、問題文が求める、トークンの確率から算出される指標ではありません。モデル自身の申告に依存する点で要件を満たしません。

D：対数確率を使うため、客観的な指標という要件は満たします。しかし grammar は複雑な制約に分類され、生成中の制約検証によってレイテンシーの増加やスループットの低下を招き得ます。JSON オブジェクトの形式固定には json_object で足りるため、性能要件の点で最適ではありません。

学習のポイント：トークン確率に基づく確信度は対数確率で得る。JSON の形式固定は、性能への影響が小さい json_object で足りる。確信度をモデルに出力させた値は客観的な指標にならない。

公式ドキュメント

• custom-model-import-advanced-features.html

正解はA・C・Dです。 A:比較評価の5段階評価では、評価ワーカーが2つのモデル応答のどちらをどの程度好むかを段階の値で答えます。結果はこの値の分布としてヒストグラムで示されるため、正しいです。 B:5段階評価で答えるのは、どちらをどの程度好むかを表す5段階の値であり、勝敗の二択ではありません。結果はヒストグラムで示されるため、勝敗件数をモデルごとの表にまとめる形とは一致せず、誤りです。 C:想定される評価数は200件×2名で400件です。これを下回る原因には、プロンプトが原因でモデルがエラーを起こし推論結果が得られなかったこと、またはワーカーが評価を辞退したことがあります。したがって、398件になった原因の候補として正しいです。ただし、不足した2件がどちらの原因によるかはレポートの件数だけでは特定できないため、Amazon S3 の出力データファイルを確認して切り分けます。 D:ヒューマンベース評価のレポートでは、指標の計算に人間のワーカーからの応答だけが使われます。推論結果が得られなかったプロンプトや、評価を辞退されたモデル応答にはワーカーからの評価がないため、指標の計算に使われるのは返された評価だけです。したがって、正しいです。 E:各モデル応答を許容か不許容かで判定し、肯定評価の割合をモデルごとに示すのは Thumbs up/down の方式です。比較評価の5段階評価とは判定の単位も結果の示し方も異なるため、誤りです。

A：正しい。比較評価の5段階評価では、評価ワーカーが指示に従い、2つのモデル応答のどちらをどの程度好むかを5段階で答えます。1件ごとの結果は勝ち負けではなく、選好の強さを表す段階の値です。そのため最終レポートでは、評価値の分布がヒストグラムで示されます。問題文の評価ジョブはモデルXとモデルYを比べる比較評価なので、結果はこの形で示されます。

B：誤り。5段階評価で評価ワーカーが答えるのは、どちらをどの程度好むかを表す5段階の値であり、勝敗の二択ではありません。最終レポートでは、この評価値の分布がヒストグラムで示されます。勝敗件数をモデルごとの表にまとめる示し方は、ヒストグラムで示されるこの方式の結果と一致しません。

C：正しい。想定される評価数は、プロンプト200件×ワーカー2名で400件です。評価数がこれを下回る場合の原因には、プロンプトが原因でモデルがエラーを起こし、推論結果(モデル応答)が得られなかったことがあります。また、1名以上のワーカーがモデル応答の評価を辞退したこともあります。398件は400件より2件少ないため、これらが原因の候補になります。ただし、不足した2件がどちらによるものかは、レポートカードの件数だけでは特定できません。原因を切り分けるには、Amazon S3 バケット内の出力データファイルを確認します。

D：正しい。ヒューマンベース評価のレポートでは、指標の計算に人間のワーカーからの応答だけが使われます。モデルのエラーで推論結果が得られなかったプロンプトや、ワーカーが評価を辞退したモデル応答には、ワーカーからの評価がありません。このジョブでは想定の400件のうち2件が返されていないため、指標の計算に使われるのは、返された評価だけです。

E：誤り。各モデル応答を許容か不許容かで判定し、肯定評価(thumbs up)を受けた割合をモデルごとに示すのは、Thumbs up/down の方式です。比較評価の5段階評価では、評価ワーカーは応答を1つずつ合否で判定するのではなく、2つのモデル応答の間の選好の強さを答えます。結果も割合ではなくヒストグラムで示されます。判定の単位と結果の示し方の両方が、比較評価の5段階評価とは異なります。

学習のポイント：問題文の数値から想定評価数「200件×2名=400件」と実際の「398件」を比べ、差が出る原因の候補(モデルのエラーで推論結果がない、ワーカーの評価辞退)を挙げられること、および指標の計算には返された評価だけが使われることが鍵です。

公式ドキュメント

• model-evaluation-report-human-customer.html

FMのライフサイクルは、データ選択、モデル選択、事前学習、ファインチューニング、評価、デプロイ、フィードバックといった段階で説明されます。Aのデータ選択は最初の方の段階、Bの事前学習はモデル選択に続く段階、Cの評価はモデルの出来を確かめる段階で、いずれもライフサイクルに含まれるため「含まれないもの」には該当しません。DのAWS Transformはサービス名であり、ライフサイクルの段階ではないため、段階だけを載せる資料には含めません。したがって正解はDです。

A：データ選択はFMのライフサイクルの最初の方に置かれる段階で、モデルに使うデータを選ぶ工程です。ライフサイクルの段階に含まれるため、「含まれないもの」を選ぶ本問の正解にはなりません。

B：事前学習(プレトレーニング)は、モデル選択の後に位置づけられる段階で、モデルの基礎となる学習を行う工程です。ライフサイクルの段階に含まれるため、本問の正解にはなりません。

C：評価はFMのライフサイクルの段階の一つで、モデルの出来を確かめる工程です。ライフサイクルの段階に含まれるため、本問の正解にはなりません。

D：AWS Transform はAWSのサービス名であり、ライフサイクルの段階(データ選択、モデル選択、事前学習、ファインチューニング、評価、デプロイ、フィードバック)のいずれでもありません。そのため、段階だけを載せる資料には含めないものとして、これが正解です。

学習のポイント：FMのライフサイクルの段階は、データ選択、モデル選択、事前学習、ファインチューニング、評価、デプロイ、フィードバックである。サービス名はその段階の名称ではない。

公式ドキュメント

• ai-practitioner-01-domain2.md

人手評価で期待される応答数は、プロンプト数に、ジョブで設定した 1 プロンプトあたりの評価者数を掛けた値です。評価対象は 1 つの基盤モデルで、今回のジョブは 300 件×3 名で 900 件ですが、レポートカードの応答数は 846 件で、54 件が不足しています。応答数が期待値より少ないときは、Amazon S3 の出力データファイルを確認します。原因として、プロンプトが原因でモデルがエラーを起こし推論結果が得られなかった場合と、評価者が評価を辞退した場合があります。また、指標の計算に使われるのは人間の評価者の回答のみです。顧客層別の集計では、期待応答数が各 300 件に対して欠落数がいずれも 18 件で、欠落率はどの顧客層も 6% となり、欠落は特定の顧客層に集中していません。C は、期待値との差を出力データで切り分け、顧客層間で欠落率に差がないことを踏まえて、人手回答のみの指標を採用判断に用いるため正解です。A は、比べる相手を今回の設定ではなく前回の 600 件にして欠落がないとみなし、原因の確認も省くため誤りです。B は、回答が得られなかった分は指標の計算に使われないため、不足分が低評価として算入されるという前提が成り立たず誤りです。D は、欠落が集中していなければ人手回答のみで採用判断できるという方針に反して保留を続ける点に加え、推論エラーで推論結果が得られなかった分には評価者が採点する応答がなく、辞退分も評価者の応じ方次第であるため、再採点の依頼だけでは 900 件に揃うとは限らず誤りです。

A：誤りです。応答数と比べる期待値は、前回のジョブではなく今回のジョブの設定で決まります。今回は 1 プロンプトあたり 3 名の設定なので、期待値は 300 件×3 名の 900 件で、846 件は 54 件少ない状態です。前回の 600 件を上回っていても、欠落がない根拠にはなりません。応答数が期待値より少ないときは、Amazon S3 上の出力データファイルで原因を確認する必要があり、確認を省く点も適切ではありません。

B：誤りです。指標の計算に使われるのは人間の評価者の回答のみです。推論結果が得られなかった分や評価者が辞退した分は、回答自体がないため指標に算入されません。したがって、欠落分が低評価として含まれているという前提が成り立たず、指標を厳しめの値とみなす根拠もありません。

C：正解です。評価対象は 1 つの基盤モデルなので、今回の期待値は設定した 3 名に基づく 300 件×3 名の 900 件で、846 件は 54 件不足しています。応答数が期待値より少ないときは、Amazon S3 上の出力データファイルで、推論結果が得られなかった場合と評価者が辞退した場合のどちらが原因かを確認します。指標の計算に使われるのは人間の評価者の回答のみなので、不足分が指標に何らかの値として入っているわけではありません。顧客層ごとの期待応答数は 100 件×3 名の 300 件で、欠落数はどの顧客層も 18 件、欠落率はどの顧客層も 6% で、顧客層間の差は 0 ポイントです。顧客層間で欠落率に目立った差がなく、欠落は特定の顧客層に集中していないため、問題文の方針に従い、得られた人手回答のみの結果を採用判断に用いてよいことになります。

D：誤りです。欠落率はどの顧客層も 6% で差がなく、欠落は特定の顧客層に集中していないため、問題文の方針では得られた人手回答のみの結果で採用判断してよく、900 件に揃うまで保留する必要はありません。また、プロンプトが原因でモデルがエラーを起こし推論結果が得られなかった分は、評価者が採点する応答そのものがないため、再採点の依頼では補えません。辞退分も、依頼に評価者が応じるかは評価者次第で、900 件に揃う保証はありません。

学習のポイント：期待される応答数は、今回のジョブで設定した「プロンプト数×1 プロンプトあたりの評価者数」で決まる。これを下回ったら S3 の出力データで推論エラーと評価者の辞退を確認し、指標の計算に使われるのは人間の評価者の回答のみである点を踏まえて、顧客層ごとの欠落率を比べて判断する。

公式ドキュメント

• model-evaluation-report-human-customer.html
• model-evaluation-prompt-datasets-custom-human.html