【無料】AWS AIF-C01練習問題10問｜図解解説付き｜Udemy講師作成

正解：B

A. 多言語翻訳システムを開発します。

不正解 翻訳が行うのは、原文の情報量を保ったまま表現を別の言語に置き換える処理です。100ページの報告書を入力すれば出力もおおむね100ページ分になり、どこが重要でどこを落とすかという取捨選択は起こりません。読み手が読める言語をそろえる手段であり、文書の分量を減らして要点を残す作業とは工程が別です。

B. 要約チャットボットを開発します。

正解 要約チャットボットはLLMで文書全体の文脈を理解し、重要な情報を残しながら元より短い文章に書き直す仕組みです。試験項目をまたぐ関係も一つの文章にまとめられるため、長い治験報告書から重要なポイントを抜き出すという要件に合致します。対話形式であれば、まとめた内容について続けて質問を重ねることもできます。

C. 感情分析（センチメント分析）システムを構築します。

不正解 感情分析が返すのは、文章全体の感情の向きを肯定的・否定的・中立などに分類したラベルと、その確からしさを表すスコアです。読み取った内容を短くまとめる工程を持たないため、治験報告書を入力しても戻ってくるのは感情の判定結果であって、要件が求める要点のまとめにはなりません。事実の記述が中心の文書には判定すべき感情も乏しい処理です。

D. 固有表現抽出（NER）システムを構築します。

不正解 固有表現抽出が返すのは、薬剤名・疾患名・日付・数値といった、あらかじめ決めた種類に当てはまる語句の一覧です。抜き出された語句は元の文章の並びから切り離されるため、「どの試験でどんな結果が出たのか」といった文と文のつながりを含む要点は出力に現れません。拾えるのは語句までで、その意味づけは読み手の側に残ります。

全体的な説明

問われている要件

• 長い治験報告書を、LLMを活用したアプリケーションで処理する。
• 文書を読み取って重要なポイントを抜き出し、短くまとめて出力する。
• 出力は、それだけ読めば内容が把握できる短い文章である必要がある。
• 要約・翻訳・感情分析・固有表現抽出のうち、この入出力に合う処理を見極める。

前提知識

LLMと要約について

• 大規模言語モデル（LLM）とは、大量の文章で事前学習され、質問応答・要約・翻訳・分類といった幅広い言語タスクを1つのモデルでこなせるモデルです。文の前後関係をとらえるため、何が主張で何が補足かを判断できます。
• 要約（Summarization）とは、文書全体を読んだうえで残すべき情報を選び、元より短い文章として書き直す処理です。出力は語句の一覧ではなく、それだけ読めば内容が把握できるまとまった文章になります。
• LLMには一度に扱える入力長（コンテキストウィンドウ）の上限があるため、長大な報告書は章ごとに要約し結果をまとめ直します。

文章を扱う他の処理との違いについて

• 固有表現抽出（NER、Named Entity Recognition）とは、文章の中から人名・地名・組織名・日付・金額など、あらかじめ決めた種類に当てはまる語句だけを拾い出す処理です。出力は語句とその種類の組で、文章としての説明は伴いません。
• 感情分析（センチメント分析）とは、文章全体の感情の向きを肯定的・否定的などに分類する処理です。出力は感情のラベルであり、元の文章を短くまとめる働きはありません。
• 機械翻訳とは、原文の内容を保ったまま別の言語の表現に置き換える処理です。言語は変わりますが情報量は基本的に保たれます。

AWSでの実現手段について

• Amazon Bedrockでは、Anthropic ClaudeやAmazon Novaなどの基盤モデルをAPIで呼び出し、報告書の本文をプロンプトに渡して要約させる形で実装できます。
• Amazon Comprehendは固有表現抽出と感情分析をAPIで実行するサービスで、感情分析は肯定的・否定的・中立・混在の4ラベルと確信度スコアを返します。
• Amazon Translateは機械翻訳を担うサービスで、原文と同じ内容を別言語で出力します。

図解

アーキテクチャ図

解くための考え方

求めているのは、長い治験報告書を読み込ませたうえで返ってくる、それだけ読めば内容の要点が分かるまとまった文章です。入力は1件の文書、出力は元より短い文章、という組み合わせになります。 この観点で選択肢を並べると、それぞれの入口と出口が違うことが分かります。固有表現抽出は文書を入力に取りますが、出口は語句の一覧であり、試験項目同士の関係を含む要点にはなりません。感情分析も文書を入力に取りますが、出口は感情のラベルであって、内容のまとめではありません。翻訳は文書を入力に取り文章を出力する点までは一致しますが、出口の分量が入力とほぼ同じで、短くする働きがありません。残る要約チャットボットだけが、長い文書を入口に取り、要点を残した短い文章を出口に返します。対話形式であれば、まとめられた内容についてその場で追加の質問を重ねられるため、担当者が原文と突き合わせる確認作業とも噛み合います。 文章を扱うAIの用途では、選択肢を見る前に「何を入れて何が返ってきてほしいか」を書き出します。返ってくるものが語句なら抽出、感情のラベルなら感情分析、同じ内容の別言語なら翻訳、同じ内容の短い文章なら要約、と一対一で対応づけられます。

参考資料

• 生成 AI とは何ですか?
• 大規模言語モデル (LLM) とは何ですか?
• Amazon Comprehend とは
• 自然言語処理 (NLP) とは何ですか?
• Amazon Translate とは

正解：D

A. Root mean squared error（RMSE、二乗平均平方根誤差）

不正解 RMSEが測っているのは、予測が実際の値からどれだけ離れているかという誤差の大きさで、単位は予測したい数値と同じものになります。分類の結果には当たりと外れの二通りしかなく、外れ方の大小を測る目盛りがありません。何枚当たったかという件数を知りたい今回の目的とは、そもそも測っている量が異なります。

B. 適合率（Precision）

不正解 適合率は、モデルが「正」と予測した対象のうち、実際に正しかった割合を示す分類向けの指標です。同じ分類の評価指標ではありますが、数えるのは予測全体に対する正解数ではなく、正と判定した範囲に限った内訳です。何枚の写真を正しく分類できたかという全体の割合とは、分母の取り方が異なります。

C. R-squared score（決定係数）

不正解 決定係数が表すのは、予測した数値が実際の値のばらつきをどれだけ説明できたかという回帰モデルの当てはまりの良さです。算出には実測値と予測値の差を取る計算が必要になりますが、この画像分類モデルの出力は不良の種類という名前のラベルで、引き算のできる数量ではありません。指標を計算する前提そのものが揃わない場面です。

D. Accuracy（正解率）

正解 Accuracyはモデルが行った予測全体のうち、正しく分類できた件数の割合を示す指標です。評価した写真の枚数を分母、正しい不良種別に振り分けられた枚数を分子に取るため、「何枚正しく分類できたか」という企業の知りたいことにそのまま答えます。画像分類の成績を示す代表的な指標としても広く使われています。

全体的な説明

問われている要件

• 部品の外観写真から不良の種類を判定する画像分類モデルの性能を測る。
• 知りたいのは「何枚の写真を正しく分類できたか」という当たりの割合である。
• モデルの出力は不良の種類というラベルであり、大小を比べられる数量ではない。
• 候補の指標が分類向けか回帰向けか、また集計の分母がどこに置かれるかを見極める。

前提知識

分類問題の評価指標について

• Accuracy（正解率）とは、モデルが行った予測全体のうち正しく分類できた件数の割合です。100枚中92枚を正しい不良種別に振り分けたなら0.92となり、「何枚当てられたか」という問いにそのまま答える形になります。
• ただしAccuracyは、データの偏りに弱い面があります。写真の99%が良品であれば、すべてを良品と答えるだけで0.99になるため、まれな不良を見逃していても高い値が出ます。こうした場面では適合率や再現率、F1スコアを併せて確認します。
• 適合率（Precision）とは、モデルが「正」と予測した対象のうち実際に正しかった割合です。Accuracyと同じ分類向けの指標ですが、集計の範囲（分母）が「予測全体」ではなく「正と判定した対象」に限られる点が異なります。

混同行列から導かれる指標について

• 混同行列（Confusion Matrix）とは、実際のクラスと予測したクラスの組み合わせごとに件数を集計したものです。どの不良種別をどの種別と取り違えたかまで追えます。
• 再現率（Recall）とは、実際に「正」であった対象のうち、モデルが正しく「正」と予測できた割合です。見逃しの少なさを表し、分母が実際の正例である点で適合率と対になります。F1スコアはこの2つの調和平均です。
• Accuracyは混同行列の対角成分の合計を全件数で割った値にあたり、行列全体を1つの数値に要約したものです。

回帰問題の評価指標について

• R-squared score（決定係数）とは、回帰モデルの予測が実際のデータのばらつきをどれだけ説明できているかを表す値で、1に近いほど当てはまりが良いことを意味します。
• RMSE（二乗平均平方根誤差）とは、予測値と実測値の差を二乗して平均し、平方根を取った値です。予測対象と同じ単位で誤差の大きさを表し、値が小さいほど予測が正確です。

図解

アーキテクチャ図

解くための考え方

評価指標を選ぶ判断は、モデルが何を出力しているかを確定させるところから始まります。このモデルが部品の外観写真に対して返すのは不良の種類という名前であって、大小を比べたり差を取ったりできる数量ではありません。つまり分類問題であり、企業が知りたいのは「予測がどれだけ惜しかったか」ではなく「何件当たったか」です。 この整理で選択肢は二段階に分かれます。まず決定係数とRMSEは、実測値と予測値の差を計算に使う回帰向けの指標です。不良の種類という名前同士では差を取れないため、この2つは今回のモデルには当てはめられません。残る2つはいずれも分類向けの指標ですが、集計の範囲が違います。適合率が数えるのは、モデルが正と判定した対象のうち実際に正しかった割合であって、全体の写真のうち何枚当たったかという割合ではありません。Accuracyだけが、当たりと外れを全体で数えて割合を出す指標であり、企業の知りたい件数の割合に直接答えます。 評価指標では、予測結果が数量か名前かをまず見ます。数量ならRMSEや決定係数のように差を測る指標、名前ならAccuracyや適合率・再現率のように件数を数える指標が候補になります。そのうえで、全体に対する正解率を求めているのか、正と判定した範囲の内訳を求めているのかで、さらに絞り込むと確実です。

参考資料

• 機械学習とは何ですか?
• メトリクスと検証 – Amazon SageMaker AI
• アルゴリズムのタイプ – Amazon SageMaker AI
• カスタム分類子メトリクス – Amazon Comprehend
• コンピュータビジョンとは?

正解：A

A. プロンプトを調整します。

正解 プロンプトの中に「簡潔にまとめてください」「英語で回答してください」のように出力の長さと言語を直接書き込むことで、モデルの応答を企業の要望どおりに制御できます。分量と言語という2つの条件を同じ指示文で同時に満たせるうえ、追加の学習もパラメータの変更も要らず、出力を見ながら文言を直す試行も短い間隔で回せます。

B. 応答の最大トークン数を増やします。

不正解 最大トークン数は、モデルが生成を続けられる長さの上限を決める推論パラメータです。値を大きくすれば長い応答も許容されるようになりますが、これは上限を緩める設定であって、簡潔にまとめさせる働きはなく、要望とは逆方向です。しかもこの推論パラメータで扱えるのは長さに関する数値だけで、英語で書くといった言語の指定を表現する余地はありません。

C. temperatureの値を上げます。

不正解 temperatureが動かすのは、次の単語を選ぶときの確率分布の形です。値を上げるほど確率の低い単語も選ばれやすくなり、応答のばらつきが大きくなります。要望は簡潔さと言語の統一なので、変化の向きがむしろ逆です。なお長さについては、推論パラメータの中に応答の最大トークン数という別の項目があり、上限はそちらで設けます。

D. 検索拡張生成（RAG）を導入します。

不正解 検索拡張生成（RAG）は、外部の資料を検索して得た情報を回答の根拠として付け加える仕組みです。応答の正確さや裏付けの提示には効きますが、出力を短くまとめることも、英語で書かせることも、この仕組みでは指定できません。要望は分量と言語であって知識の追加ではないため、対策の向きがずれています。

全体的な説明

問われている要件

• 事前学習済みのLLMで、海外の顧客向けの商品紹介文を自動生成する。
• 出力を短くまとめ、かつ英語で記述させる必要がある。
• 分量と言語という2つの条件を同時に満たせる手段を選ぶ。
• プロンプトの調整、推論パラメータの変更、検索拡張生成の導入のうち、どれがこの2つの条件に対応するかを見極める。

前提知識

プロンプトとプロンプトエンジニアリングについて

• プロンプト（Prompt）とは、モデルに何をしてほしいかを伝える入力です。依頼内容だけでなく、口調、書式、文字数の目安、使用する言語といった条件も、そのまま文章として書き添えられます。
• プロンプトエンジニアリングとは、望ましい出力を引き出すためにプロンプトの言葉や構成を工夫する技術です。「3文以内で」「英語で」のように条件を明示する、出力例を1つ添えるといった手当てで、応答の形を揃えていきます。モデルの重みは変更しないため、試して直すまでの間隔が短いことが特徴です。

LLMの推論パラメータについて

• temperature（テンパラチャー）とは、次のトークンを選ぶ確率分布の形を調整する数値です。値を上げると確率の低いトークンも選ばれやすくなって表現が多様になり、下げると高確率のトークンに寄って安定した応答になります。
• 最大トークン数（レスポンスの長さ）とは、応答が生成を続けられるトークン数の上限を決める推論パラメータです。値を大きくするほど長い応答を許容するようになり、途中で特定の文字列が出た時点で打ち切る停止シーケンスと合わせて、長さの上限を制御する目的で使われます。
• これらの推論パラメータはいずれも「上限を決める」「ばらつきを増減させる」という数値の調整であり、「簡潔にまとめる」という書き方そのものや使用する言語の指定はプロンプト側で行います。

検索拡張生成（RAG）について

• 検索拡張生成（RAG、Retrieval-Augmented Generation）とは、モデルが回答を作る前に外部のデータソースを検索し、得られた情報を回答の根拠として加える手法です。回答の正確さや最新情報への追従には効果がありますが、出力の長さや言語を制御する手段ではありません。

図解

アーキテクチャ図

解くための考え方

要望を2つに分けて見ると、判断の軸がはっきりします。1つは「短く」という分量の話、もう1つは「英語で」という書き方の話です。このうち言語の指定は、数値をいくつに設定しても表現できない種類の要求で、言葉として伝えるほかに手段がありません。この時点で、数値を上下させる選択肢は要望の半分にも届かないと分かります。 残る分量についても、temperatureと最大トークン数は担当が違います。temperatureが操作するのは次のトークンをどの範囲から選ぶかという確率の扱いであり、動かした結果として変わるのは応答の多様さです。この案は値を上げる提案で、ばらつきを増やす方向ですから、簡潔にそろえたいという意図とは逆を向いています。最大トークン数は応答の長さに関わる推論パラメータですが、これは上限を緩めたり狭めたりする設定にすぎず、値を上げる操作は要点を絞って短くまとめさせるどころか長い応答を許容する方向に働きます。検索拡張生成（RAG）も、回答の根拠となる情報を外部から引いてくる仕組みであって、分量と言語を指定する経路にはなりません。 一方、プロンプトに「200文字以内で」「英語で回答してください」と書き添えれば、分量と言語の両方を同時に、追加学習もパラメータ変更もなしに指定できます。結果を見て文言を直す試行も短い間隔で回せます。 出力の何を変えたいのかで手段を選び分けます。書式・言語・口調・観点といった「内容や体裁の指定」はプロンプトの担当、揺らぎの大きさや語彙の広がりといった「生成のばらつき」は推論パラメータの担当、そして知識そのものを足したい場合はRAGやファインチューニングの担当、と対応させると迷いません。

参考資料

• 生成 AI とは何ですか?
• プロンプトエンジニアリングとは何ですか?
• 推論パラメータでレスポンスの生成に影響を与える
• プロンプトエンジニアリングの概念
• 大規模言語モデル (LLM) とは何ですか?

正解：D

A. S3バケットのバージョニングを有効にします。

不正解 バージョニングは、上書きや削除が起きても以前の状態のオブジェクトを残しておくための設定です。有効にしてもBedrockのサービスロールに与えられている取得や復号の許可には何の影響もなく、いま拒否されている取得処理はそのまま拒否され続けます。手を入れる対象が権限ではなくオブジェクトの保護に向いている提案です。

B. モデルにS3内の情報を探し出すよう、プロンプトを工夫して指示します。

不正解 プロンプトを工夫して届くのは、モデルが受け取る入力の中身までです。S3のオブジェクトを取り出せるかどうかは、それより前の段階でAWSが要求元の権限を照合して決めます。探し出すよう言葉で頼んでも、拒否された取得処理は通りません。アシスタントは参照できる資料がないまま回答を作り続けます。

C. 基盤モデル（FM）を性能の異なる別モデルに切り替えます。

不正解 利用するモデルを別のものに差し替えても、S3へのアクセスを実際に実行するのは同じサービスロールです。許可不足という原因はそのまま残るため、同じロールが同じバケットを読みに行く限り、同じ拒否が返り続けます。手を入れるべき対象が権限ではなくモデル側に向いている提案です。

D. BedrockのサービスロールにS3の取得と復号の許可が付いているか確認します。

正解 Bedrockが利用者に代わってS3を読む処理は、そのサービスが引き受けたロールの権限で実行されます。オブジェクトの取得にはs3:GetObjectとs3:ListBucketが要ります。SSE-S3なら復号はS3が取得の工程で行うため呼び出し側の追加許可は不要ですが、カスタマー管理のKMSキーを使う構成ではkms:Decryptとkms:DescribeKeyがさらに必要になります。今回の失敗はこのロールに必要な許可が欠けていることが原因なので、権限を正しく付与することが解決策です。

全体的な説明

問われている要件

• Amazon Bedrock上の基盤モデル（FM）に、Amazon S3へ保存された就業規則や社内規定を参照させる。
• 参照対象のデータはAmazon S3が管理する暗号化キー（SSE-S3）で暗号化されている。
• 現状はFMがこのS3バケットのデータにアクセスしようとすると失敗している。
• 失敗している原因そのものに手を入れ、アシスタントが資料を読める状態にする解決策を選ぶ。

前提知識

Amazon Bedrockによる社内データの参照について

• FM（基盤モデル、Foundation Model）とは、大量のデータで事前学習された汎用的なAIモデルです。Amazon BedrockはこのFMをAPI経由で利用できるようにするサービスで、社内データはナレッジベースなどを通じてS3上の資料を読み込ませます。
• モデル自身がS3へ接続するのではなく、Bedrockが利用者に代わって資料を取り出し、プロンプトに添えてモデルへ渡します。

サービスロールと必要なS3の許可について

• IAMロールとは、サービスや利用者が一時的に引き受ける権限のまとまりです。Bedrockが利用者に代わってS3を読む処理は、利用者本人ではなくBedrockが引き受けたサービスロールの権限で実行されます。S3側の操作が許可されているかはこのロールのポリシーで決まります。
• S3のデータを読むためにロールが必要とする代表的な許可は、オブジェクトを取得するs3:GetObjectと、一覧を得るs3:ListBucketです。

S3の暗号化方式と必要な許可について

• SSE-S3（Server-Side Encryption with Amazon S3-managed keys）とは、S3が鍵の生成から管理までを引き受け、保存時の暗号化と取得時の復号を自動で行う方式です。呼び出し側は復号を意識せず、取得の許可があれば平文のデータを受け取れます。
• SSE-KMS（AWS KMSの鍵を使う方式）では、鍵の利用可否をKMSのキーポリシーとIAMポリシーが別途判定します。カスタマー管理キーの場合は読み取り側のロールにkms:Decryptとkms:DescribeKeyが必要で、欠けると取得時にアクセス拒否となります。
• どの方式でも、アクセスの可否はデータの中身ではなく要求元に与えられた許可で決まります。

図解

アーキテクチャ図

解くための考え方

失敗の原因を切り分けるときの出発点は、いまどの主体が何をしようとして止められているのかを特定することです。この場面で要求を出しているのは人事部門の担当者でも利用者でもなく、Bedrockが引き受けたサービスロールです。そのロールがS3にオブジェクトの取得を求め、拒否された状態なので、手を入れるべきはロールに紐づくポリシーだと分かります。 残る3つは、働きかける場所がそれぞれ外れています。バージョニングが向き合うのはオブジェクトの上書き・削除からの保護であって、署名付きの要求を出すロールの許可には関係せず、有効にしても取得の可否は変わりません。プロンプトの工夫が及ぶのはモデルへの入力までで、その前段で行われる権限の照合は動かせません。モデルの差し替えも、アクセスを実行するサービスロール自体は変わらないため、許可不足という原因を解消しません。 権限を確認するときは、s3:GetObjectとs3:ListBucketがロールに付いているか、バケットポリシー側でこのロールが拒否されていないかを順に追います。暗号化は、SSE-S3であれば復号をS3が引き受けるため追加の権限は要りませんが、カスタマー管理のKMSキーを使う構成ではkms:Decryptの許可が欠かせません。 AWSサービスが別サービスのデータを読めないときは、まず「その操作を実行している主体は誰か」を言葉にします。主体がサービスならサービスロールのポリシー、暗号化が絡むなら鍵側の許可、と確認する場所が決まります。するとバージョニングの変更やモデルの差し替えといった、原因に触れない提案を自然に切り分けられます。

参考資料

• Amazon S3 バケットへのアクセスを設定する – Amazon Bedrock
• Amazon S3 マネージドキーによるサーバー側の暗号化 (SSE-S3)
• IAM ロールとは
• Amazon Bedrock のためのアイデンティティとアクセス管理

正解：A

A. シンプルなルールと計算を使用したコードで確率を計算します。

正解 ボールの個数から確率を求める処理は、対象の個数を全体の個数で割るだけの決まった計算式で厳密に答えが導けます。同じ問題には常に同じ答えが返り、なぜその値になるのかも式をたどれば説明できます。学習データの用意も再学習も監視も要らないため、運用上のオーバーヘッドを最も小さく抑えたいというこの企業の要件に合致します。

B. 転移学習を使用して、確率を返すモデルを構築します。

不正解 転移学習は、別のタスクで学習済みのモデルの知識を流用して、新しいタスク向けに少量のデータで調整する手法です。ボールの個数から確率を求める今回の処理には持ち込むべき既存知識がなく、個数を割るだけで答えが確定します。学習済みモデルを用意して調整する工数と、推論環境を維持する手間だけが残ります。

C. 教師あり学習を使用して、確率を予測する回帰モデルを作成します。

不正解 教師あり学習で作った回帰モデルが返すのは、学習データから推定した近似値です。5個を15個で割った3分の1という厳密な答えに対し、0.31や0.35といった微妙にずれた値を返す余地が残り、学習用の教材としては困った結果になります。正解付きの事例を集めて学習させ、精度を保ち続ける作業も加わります。

D. 教師なし学習を使用して、確率密度を推定するモデルを作成します。

不正解 確率密度の推定は、観測されたデータがどのあたりに集まっているかという分布の形を、限られた標本から推し量る作業です。今回は箱の中身の個数がすべて分かっており、推し量る対象となる未知の分布がありません。標本を集めて近似するより、個数を割り算する方が速く、しかも常に正確です。

全体的な説明

問われている要件

• 小学生向けの算数ドリルアプリで、抽選箱に入ったボールの色と個数から確率を求めて出題する。
• 求める確率は、対象の色の個数を全体の個数で割るという決まった計算で一意に定まる。
• 機械学習の手法で解かせるか、決まった計算をそのままコードで実装するかを見極める。
• 運用上のオーバーヘッドが最も少ない方法を選ぶ。

前提知識

機械学習の学習スタイルについて

• 教師あり学習（Supervised Learning、正解ラベル付きのデータを使って入力と出力の関係を学ぶ手法のこと）とは、模範解答付きの問題集で勉強するように、正解が分かっているデータから規則性を学ぶ方法です。
• 教師なし学習（Unsupervised Learning、正解ラベルのないデータから規則性やまとまりを見つけ出す手法のこと）とは、大量の写真を似ているもの同士に仕分けるように、正解を教えられない状態でデータからパターンを見つける方法です。
• 転移学習（Transfer Learning、既存の学習済みモデルの知識を別のタスクへ流用する手法のこと）とは、ゼロから学習させる代わりに、似たタスクで学習済みのモデルを出発点として、新しいタスク向けに少量のデータで調整する方法です。

運用オーバーヘッドについて

• 運用オーバーヘッド（Operational Overhead、システムを開発し動かし続けるために必要な継続的な手間やコストのこと）とは、学習用データの収集、モデルの再学習、精度の劣化の監視、推論環境の維持などにかかり続ける負担を指します。一度作って終わりにならない点が、単純なコードとの大きな違いです。

ルールベースの処理と機械学習の使い分けについて

• ルールベースの処理とは、あらかじめ決められた計算式や条件分岐だけで結果を導く仕組みです。同じ入力には必ず同じ出力が返り、なぜその答えになったかも式をたどれば説明できます。
• 機械学習が必要になるのは、答えを導く規則を人が書き下せない場合です。写真に写っているものの判別や需要の予測のように、データから規則を推定するほかない場面が該当します。逆に規則が既に分かっているなら、それをそのままコードにする方が正確で軽く済みます。

図解

アーキテクチャ図

解くための考え方

選択肢を比べる前に、そもそも機械学習を持ち出す必要があるかを確かめます。判断の基準は、答えを導く規則を人が書き下せるかどうかです。青いボールを引く確率は、青の個数を全体の個数で割るという定義そのもので決まり、5個と15個なら3分の1が常に正しい答えになります。規則が完全に分かっているのですから、データから規則を推定する仕組みは出番がありません。 むしろ、モデルを使うと不利になります。学習で得られるのは推定値なので、厳密に3分の1と答えるべき場面でわずかにずれた値が返る可能性が残り、学習用の教材としては望ましくありません。運用面でも、学習データの用意、再学習、精度の監視といった負担が続きます。 3つの学習手法は、それぞれ成立するための前提を欠いています。教師あり学習は正解付きの事例を大量に必要とし、教師なし学習は未知の分布を標本から推し量るもので、転移学習は既存の学習済みモデルを流用する枠組みです。今回はいずれの前提も当てはまらず、割り算1回で確定する答えに対して仕組みだけが重くなります。残る選択肢である計算コードが、正確さと運用の軽さの両方で要件を満たします。 運用上のオーバーヘッドが最も少ない方法を選ぶときは、まず答えが計算式や条件分岐で書き切れるかを確認します。書き切れるならコードで実装するのが最も軽く、書き切れないときに初めて機械学習が候補になります。そのうえで学習手法を選ぶ段階では、正解ラベルがあるか、分布を知りたいのか、学習済みモデルを流用したいのか、という前提の違いで振り分けます。

参考資料

• 機械学習とは何ですか?
• 転移学習とは何ですか?
• AI (人工知能) とは何ですか?
• データラベリングとは何ですか?

正解：B

A. 温度（生成される文章のランダム性を調整する推論パラメータ）

不正解 温度が調整するのは、次の単語を選ぶ際の確率分布の広がりです。値を上げれば思いがけない表現が出やすくなり、下げれば一貫した言い回しに寄ります。こうして変わるのは生成される文章の性質であって、モデルが一度に受け付ける文書の長さには一切関わりません。

B. コンテキストウィンドウ（一度に扱えるトークン数の上限）

正解 コンテキストウィンドウは、モデルが一度の処理で扱えるトークンの上限を指す値です。プロンプトと回答がこの枠を分け合うため、値が大きいモデルほど長い文書をまとめて読み込ませられます。設計仕様書を丸ごと渡すという要件に対し、入力量そのものを決めるこの項目が判断材料になります。

C. モデルサイズ（学習で調整されるパラメータの個数）

不正解 モデルサイズが数えるのは、学習で調整されるパラメータの個数です。回答の質や計算資源を見積もる目安にはなりますが、それはモデルが一度に扱える文章量とは別の尺度です。長い入力を受け付けるかどうかは、モデルごとに定められたトークンの上限で決まり、パラメータの多さでは決まりません。

D. プロビジョンドスループット（安定した性能で処理できるリクエスト量を確保するBedrockの購入オプション）

不正解 プロビジョンドスループットが確保するのは、決まった量のモデル呼び出しを安定した性能でさばき続けるための処理能力です。同時にどれだけのリクエストをこなせるかという運用面の余裕には効きますが、1回のプロンプトに入力できる文書の分量そのものを増やすわけではありません。文書が長すぎて枠に入らないという困りごとは、この設定を変えても解消されません。

全体的な説明

問われている要件

• Amazon Bedrockで、製品の設計仕様書を丸ごと読み込ませて質問に答えさせる生成AIアプリケーションを構築する。
• アプリケーションで利用する基盤モデル（FM）を選定する必要がある。
• 1回のプロンプトにどれだけの情報を入力できるかを、モデル選定の判断材料にしたい。
• 入力量の上限を決める項目を、温度・モデルサイズ・プロビジョンドスループットと区別する。

前提知識

コンテキストウィンドウとトークンについて

• トークン（Token）とは、文章を単語や文字などの単位に分割したもので、モデルが扱う文章量を数える単位です。日本語ではおおむね1文字が1トークン前後に相当します。
• コンテキストウィンドウとは、モデルが一度の処理で扱えるトークン数の上限です。入力するプロンプトと出力される回答の両方がこの枠を分け合って消費するため、長い文書を渡すほど回答に使える余地は狭まります。
• 上限値はモデルによって大きく異なり、数千トークン規模のものから数十万トークンを超えるものまであります。長い文書を丸ごと渡すなら、この値の大きいモデルを選ぶことが前提になります。
• 枠を超えた入力は、そのままでは処理されず切り捨てやエラーになるため、分割して渡すなどの工夫が別途必要になります。

出力の性質とモデルの規模を表す値について

• 温度（Temperature）: 次の語を選ぶときの確率分布の広がりを調整する推論パラメータです。出力の性質に効く設定であり、扱える文章量の枠とは無関係です。
• モデルサイズ: モデルが持つパラメータの個数です。回答の質や必要な計算資源の目安になりますが、扱えるトークン数の上限とは別の指標で、パラメータが多いほど枠が広いという対応関係もありません。

プロビジョンドスループットについて

• プロビジョンドスループット（Provisioned Throughput）とは、モデル呼び出しの処理能力を事前に確保するBedrockの購入オプションです。確保の単位はモデルユニット（MU）で、1分間に処理できる入力トークン数と生成できる出力トークン数で定義されます。
• 単位が「1分あたり」である点が示すとおり、確保できるのは時間あたりの処理量です。1件のリクエストに入るトークン数の上限は購入量では動かせず、モデルのコンテキストウィンドウで決まります。

図解

アーキテクチャ図

解くための考え方

この企業が知りたいのは「1回のプロンプトにどれだけの情報を入力できるか」です。並んだ4つの値はそれぞれ指す対象が異なるため、判定の分かれ目は「その値が、モデルに一度に渡せる文章量を決めているか」という一点に絞られます。 温度が変えるのは、次の語を選ぶときの確率分布です。表現の出やすさが変わっても、読み込ませる分量には届きません。プロビジョンドスループットが確保するのは1分あたりに処理できるトークン量、つまり時間あたりの処理能力であって、1件のリクエストに入る文書の長さとは軸が違います。モデルサイズが数えるのはパラメータの個数で、回答の質や必要な計算資源の目安にはなっても、入力の上限を決める値ではありません。パラメータが多いほど長い入力を受け付ける、という関係も成り立ちません。 一方、コンテキストウィンドウが示すのは、モデルが一度の処理で扱えるトークンの上限そのものです。この枠は入力するプロンプトと生成される回答の双方で共有されるため、設計仕様書を丸ごと渡すほど回答に残る余地は狭まります。しかもこの上限はモデルごとに定められた値で、後から設定を変えて広げられるものではありません。だからこそ、長い文書を扱う前提のアプリケーションでは、モデル選定の段階で真っ先に確認すべき値になります。 生成AIの設定値を仕分けるときは、その値が「入る量」「出る内容」「処理能力の確保」「モデルの規模」のどれに効くかを見ます。長い文書を丸ごと扱いたいという要件なら、入る量を縛る値だけが答えになり、出力の調整・処理能力の確保・規模の指標は候補から外れます。

参考資料

• 基盤モデルとは何ですか?
• プロンプトエンジニアリングとは何ですか?
• 推論パラメータでレスポンスの生成に影響を与える – Amazon Bedrock
• コンテキストウィンドウオーバーフローとその対策

正解：D

A. Application Load Balancer（ALB）を使用してモデルをホストし、予測結果を提供します。

不正解 Application Load Balancerが行うのは、受け取ったリクエストを設定済みのターゲットグループへ振り分けることです。振り分けた先で写真を受け取り分類結果を計算する仕組みは自社で別に用意する必要があり、ロードバランサー自体にモデルを載せて推論を計算する機能はありません。窓口を一枚用意しただけでは、予測結果を返す実体は生まれません。

B. Amazon API Gatewayを使用してモデルをホストし、予測結果を提供します。

不正解 Amazon API Gatewayが受け持つのは、リクエストの受け口としての認証、流量制限、転送先への振り分けまでです。受け取った写真は背後のLambda関数や推論エンドポイントへ渡す設計になるため、転送先となるモデルの置き場所は別に用意することになります。窓口だけを作っても予測結果を返す実体は生まれません。

C. Amazon SageMakerのリアルタイム推論エンドポイントを使用してモデルをデプロイします。

不正解 リアルタイム推論はモデルを常時稼働させて低遅延で応答する方式です。予測結果は返せますが、インスタンスタイプや台数を利用する側が指定し、オートスケーリングも自分で設定する必要があるため、基盤の管理を利用者に残す点で「インフラを一切管理しない」という要件を満たしません。

D. Amazon SageMaker Serverless Inferenceを使用してモデルをデプロイします。

正解 Amazon SageMaker Serverless Inferenceはモデルのホスティングと予測の提供に特化した推論オプションであり、コンピューティングリソースのプロビジョニングやスケーリング設定を自分で行う必要がありません。アクセスがない時間帯は自動的に規模をゼロまで縮小するため、このアプリのように利用が不定期な場面でもインフラ管理の手間をかけずに画像分類モデルの予測結果を提供できます。

全体的な説明

問われている要件

• 利用者が撮影した商品写真から品目カテゴリを判定する学習済みモデルを、本番環境へ導入する。
• スマートフォンアプリからこのモデルを呼び出し、予測結果を受け取れるようにする。
• モデルをホストして予測結果を返す実体そのものを用意する。
• 基盤となるインフラストラクチャを一切管理しない構成にする。

前提知識

推論（Inference）とデプロイについて

• 推論とは、学習済みのモデルに新しいデータを入力して予測結果を得る処理です。モデルを本番環境へ導入するとは、この推論をアプリケーションから呼び出せる状態にすることを指します。
• 呼び出し方には、リクエストに即座に応答する同期的なものと、結果を後から受け取る非同期・一括処理のものがあります。利用者が画面の前で結果を待つ場面では前者が必要です。
• 推論を提供する側は、モデルを載せる計算資源、その台数の増減、障害時の入れ替えを用意することになります。この部分をどこまでAWSに任せられるかが、マネージドかどうかの分かれ目です。

リアルタイム推論とサーバーレス推論の違いについて

• Amazon SageMakerは2024年12月にAmazon SageMaker AIへ改称され、推論オプションの構成と名称はそのまま引き継がれています。
• リアルタイム推論: エンドポイントを常時稼働させて低遅延で応答します。インスタンスタイプと台数を利用する側が指定し、オートスケーリングも自分で設定します。
• Serverless Inference: インスタンスの指定や台数管理を行わず、メモリサイズと最大同時実行数を指定するだけで済む推論オプションです。メモリは1024MBから6144MBまでの6段階から選び、リクエストがない間は自動的にゼロまで縮小されます。一方で、しばらく呼び出しがなかった後の初回応答には起動待ち（コールドスタート）が生じます。

そのほかの推論オプションについて

• 非同期推論: 大きな入力データや処理時間の長い推論を、キュー経由で受け付けて結果を後から返します。利用者が画面の前で結果を待つ用途には向きません。
• バッチ変換: 蓄積済みのデータをまとめて推論し、結果をファイルとして出力します。定期的な一括処理向けです。

図解

アーキテクチャ図

解くための考え方

条件が2つ重なっています。1つはモデルをホストして予測を返すこと、もう1つはそのための基盤を一切管理しないことです。片方だけを満たす選択肢が混ざっているため、両方を通過するものだけが残ります。 まず「予測を計算する実体になれるか」で絞ります。リクエストをターゲットへ振り分ける仕組みも、リクエストの受け口を作る仕組みも、その手前や周辺を担当するものであって、画像を受け取って分類結果を導く計算そのものは行いません。窓口を用意しても、その奥に置くモデルの実行環境がなければアプリケーションは答えを受け取れません。 残るのは、いずれもSageMakerが提供する推論オプションです。ここで2つ目の条件が効きます。リアルタイム推論は予測そのものは返せますが、インスタンスタイプと台数の指定、オートスケーリングの設定が自社の管理対象として残るため、「基盤を一切管理しない」という要件を満たしません。SageMaker Serverless Inferenceであれば、指定するのはメモリサイズと同時実行数だけで、インスタンスの選定も台数の増減もAWS側が引き受けます。利用が不定期なアプリという条件とも噛み合います。 デプロイ先を選ぶときは、その選択肢がモデルの実行そのものを担うのか、その前後の通信や配信を担うのかをまず切り分けます。そのうえで「管理不要」という条件が付いていれば、インスタンスの指定が残る選択肢は落ちる、という順で絞り込むと確実です。

参考資料

• Amazon SageMaker AI の推論オプション
• Amazon SageMaker Serverless Inference を使用してモデルをデプロイする
• Application Load Balancer とは何ですか?
• Amazon API Gateway とは何ですか?

正解：B

A. Amazon Macieを使って、S3に保存された下書き文書に機密情報が含まれていないか検出します。

不正解 Amazon Macieが得意とするのは、S3に保存されたデータの中に個人情報や機密情報らしきものが含まれていないかを機械学習で検出することです。発表前の文書の取り扱いを可視化するのには役立ちますが、Bedrock上のモデルを誰が呼び出せるかという権限や、モデルの出力そのものを制御する仕組みではありません。

B. プロンプトを具体的に設計し、IAMロールとポリシーを最小権限の原則で構成します。

正解 モデルに期待する振る舞いを指示文へ具体的に書き込み、InvokeModelなどモデルを呼び出す操作を許す相手をIAMロールとポリシーで最小限に絞ります。この2つの手当てが揃うと、出力が意図から外れる事態と、関係のない相手がモデルを呼び出す事態の両方を事前に抑えられます。未公開情報を扱う部門がLLMを業務に載せるうえで、最初に整えるべき土台になる対策です。

C. Amazon Bedrockの評価ジョブを定期実行して、モデルの出力性能を採点します。

不正解 モデル評価ジョブがやるのは、評価用データセットのプロンプトをモデルに実行させ、出てきた回答を正確性や頑健性といった指標で採点することです。この結果は「どのモデルを採用するか」の判断材料であって、誰にモデルを呼ばせるかという権限の制御には触れていません。

D. AWS CloudTrailでBedrockのAPI呼び出しを記録し、利用状況を追跡します。

不正解 CloudTrailが残すのは、誰がいつInvokeModelなどのBedrock APIを呼び出したかというイベントの記録です。管理イベントは既定で記録され、後から利用状況をたどる助けにはなりますが、記録が残るのは操作が実行された後であって、モデルを呼び出せる相手を絞ったり出力の内容を抑えたりする仕組みではありません。

全体的な説明

問われている要件

• Amazon Bedrock上でLLMを安全に利用するための基本対策を選ぶ。
• 未公開の情報を扱う前提で、モデルの出力と呼び出し権限の両方に手を打つ。
• IAMによる最小権限アクセスとプロンプト設計が、なぜセキュリティ対策として機能するかを理解する。
• 評価・監査・データ検出を担う機能との役割の違いを見分ける。

前提知識

Amazon Bedrockにおけるアクセス制御について

• IAM (AWS Identity and Access Management) とは、AWSの中で「誰が」「どのサービスに」「何をしてよいか」を定める仕組みです。Bedrockでは、モデルを呼び出す操作（InvokeModelなど）や利用できるモデルを、IAMポリシーで利用者やアプリケーション単位に絞り込めます。
• 最小権限アクセスとは、業務に本当に必要な権限だけを与える考え方です。権限を絞っておくと、認証情報の漏えいや誤操作が起きたときに影響が及ぶ範囲を、その権限で届く場所までに抑えられます。
• Bedrockの利用開始時には、アカウントごとにどの基盤モデルへアクセスするかを有効化する手順があり、この段階でも利用対象を必要なモデルに限定できます。

プロンプト設計とLLM利用時のリスクについて

• プロンプトとは、LLMに与える指示文や質問文です。役割、参照してよい情報の範囲、答えてはいけない事柄、出力の形式を具体的に書くほど、想定外の内容が返る余地が狭まります。
• LLMには、事実と異なる内容をもっともらしく生成する現象や、利用者の入力によって当初の指示を上書きされる攻撃（プロンプトインジェクション）といったリスクがあります。指示を曖昧にしたままにすると、これらが表に出やすくなります。

評価・監査・データ検出が担う範囲について

• Bedrockのモデル評価ジョブとは、評価用データセットを使ってモデルの出力を採点し、用途に合うモデルを見極めるための機能です。指標で機械的に採点する自動評価、別のモデルに採点役を任せるLLM-as-a-judge、担当者が出力を見比べる人間による評価の3通りが選べます。
• AWS CloudTrailとは、AWSアカウント内で誰がどのAPIを呼び出したかをイベントとして記録するサービスです。BedrockではInvokeModelやConverseが管理イベントとして既定で記録され、エージェントやナレッジベースの呼び出しは高度なイベントセレクターを設定するとデータイベントとして記録されます。残るのは実行済みの操作の記録であり、操作そのものを止める仕組みではありません。
• Amazon Macieとは、S3に保存されたデータを機械学習で走査し、個人情報や機密情報らしきものが含まれていないかを検出するサービスです。データの中身に対する検出であり、誰がAPIを呼び出せるかというアクセス制御とは別の役割です。

図解

アーキテクチャ図

解くための考え方

LLMを業務に乗せるときのリスクは、2つの種類に分けられます。モデルが想定外の返答をする入出力のリスクと、使わせるべきでない相手にモデルを呼ばれる権限のリスクです。安全に利用するという要望は、この2つへの事前の手当てを意味します。 選択肢を「事前に防ぐものか、事後に気づくものか」で見ると違いが際立ちます。モデル評価はモデルの出来栄えを採点する作業で、その結果はモデル選定の材料にはなっても、運用中に誰が何を投げ込めるかを制限しません。操作の記録は、誰がいつモデルを呼び出したかを後からたどるための仕組みです。不審な利用に気づく手掛かりにはなりますが、記録が残ること自体に、その場で呼び出しを止める力はありません。Macieの検出も同じく、すでにS3に置かれたデータの中身を後から走査するものであり、誰がBedrockのモデルを呼び出せるかという権限を制御するものではありません。 残る対策だけが、2つのリスクを同時に事前処理します。指示に役割・参照してよい範囲・答えてはいけない事柄・出力形式を具体的に書けば、モデルの振る舞いを要件の内側に留めやすくなります。IAMロールとポリシーを最小権限で組めば、Bedrockのモデルを呼び出せる相手を広報部門の業務に必要な範囲へ絞れます。発表前の広報資料づくりという日常業務にLLMを組み込むうえで、最初に整えるべき土台はこの2つです。 セキュリティ対策を選ぶときは、その選択肢が「起きる前に防ぐもの」か「起きた後に気づくもの」かを仕分けます。予防が要件なら、権限設定や入力の制御といった事前の手当てが答えになり、評価・監査・データ検出のような事後の可視化は、それだけでは要件を満たしません。

参考資料

• Amazon Bedrock のセキュリティ
• Amazon Bedrock のアイデンティティベースのポリシー例
• Amazon Bedrock 評価を使用して最もパフォーマンスの高いモデルを選択する
• CloudTrail を使用して Amazon Bedrock API 呼び出しをモニタリングする
• Amazon Macie とは
• IAM とは (AWS Identity and Access Management)

正解：A

A. GPT（生成系の大規模言語モデル）

正解 GPTは膨大な文章で事前学習した大規模言語モデルで、入り口も出口も文章というテキストtoテキストの処理を担えます。日本語の依頼文の意図を読み取り、SQLクエリという形の整った文字列に置き換える作業にそのまま向くため、ITに疎いスタッフでも普段の言い回しで問い合わせ文を作れる要件を満たします。

B. ランダムフォレスト（分類・回帰を行う手法）

不正解 ランダムフォレストが返せるのは、あらかじめ定めたクラスのどれか、もしくは1つの数値に限られます。複数の決定木の判定をまとめて多数決や平均を取る手法なので、答えを「選ぶ」か「測る」かしかできません。語を次々と選んで好きな長さの文を生み出す生成の手順は備えていません。

C. ResNet（画像認識向けの深層学習モデル）

不正解 ResNetは画素の並びを入り口に、写っている物がどの分類かを出口に返す、画像認識を目的とした構造です。層を深くしても学習が滞らないよう近道を設ける工夫が精度を支えてきました。入り口も出口も画像に寄っているため、日本語の依頼文からSQL文を作る仕事とは対象が噛み合いません。

D. WaveNet（音声合成モデル）

不正解 WaveNetが出力するのは音声の波形です。文章を受け取って人の話し声に近い音へ仕立てる仕事を担い、新たなデータを作り出す点では生成モデルの仲間に入ります。ただし出来上がるのは耳で聞く音であって、データベースへ渡せるSQL文のような文字列は成果物になりません。入力が文章でも、出口の形式が要件と噛み合いません。

全体的な説明

問われている要件

• 目的に応じた生成AI・機械学習モデルを使い分ける。
• 従業員が入力した日本語の文章を、SQLクエリという構造化された文章に変換できるモデルを選ぶ。
• ITシステムの操作経験が乏しいスタッフでも、普段の言い回しのまま入力できる方式にする。
• 画像認識・音声合成・分類手法とは入力と出力の形式が違う点を見分ける。

前提知識

文章を生成するモデルについて

• GPT（Generative Pre-trained Transformer、生成事前学習済みトランスフォーマー）とは、大量の文章データで事前学習された大規模言語モデルの一種です。与えられた文脈に続く語を確率的に選ぶ処理を繰り返して、任意の長さの文章を組み立てます。
• 入力も出力も文章であるため、翻訳・要約・言い換えのほか、自然な言葉での依頼をプログラムのコードやSQLクエリといった構造化された文字列へ変換する用途にも使えます。この種の使い方はText-to-SQLと呼ばれます。
• 生成された問い合わせ文が意図どおりとは限らないため、実運用ではテーブル定義を文脈として渡す、参照のみの権限で実行するといった補助的な設計が併せて必要になります。

文章以外を出力するモデルについて

• 残差ニューラルネットワーク（ResNet）とは、層と層の間に「近道」の経路を設けることで、非常に深い構造でも学習が進むようにした画像認識向けの深層学習モデルです。画像を入力として、分類結果や検出された物体の位置を返します。
• WaveNetとは、音声の波形を直接生成する深層学習モデルです。文章を人の話し声に近い音へ変換する音声合成の用途で使われ、出力は音のデータになります。

分類・回帰を行う機械学習手法について

• ランダムフォレストとは、複数の決定木を組み合わせ、各木の判定結果を多数決（分類）や平均（回帰）でまとめる教師あり学習（正解付きデータから規則を学ぶ学習方法）の手法です。
• 出力は、決められたクラスのいずれかという判定か、連続した数値のどちらかです。文章のように長さが定まらないものを新しく作り出す仕組みは持ちません。

図解

アーキテクチャ図

解くための考え方

要件を「入り口と出口がそれぞれ何か」に分解すると、選択肢の当て方が定まります。入り口は店頭スタッフが打ち込んだ日本語の文章、出口はデータベースが理解できるSQLクエリです。文章を別の文章へ作り直す、テキストからテキストへの変換が求められています。 入り口の形式が合わないものが1つあります。画素を前提に組まれたモデルは、写真の内容を当てる仕事では力を発揮しますが、文章を受け取る構造になっていません。出口の形式が合わないものが2つあります。決定木の判定をまとめてクラスか数値を返す手法は、答えの候補が決まっている問題向きで、その場で語を連ねて長さの定まらない文を作ることはしません。音の波形を作るモデルは、生成という点では近いものの、成果物が音なのでデータベースへ渡せる文字列にはなりません。 入り口と出口の両方が文章として成り立つのは、大規模言語モデルだけです。事前学習で言葉のつながり方とSQLの書き方の双方に触れているため、「先月の売上を店舗別に出して」という平易な依頼を、対応する問い合わせ文へ組み替えられます。操作経験の乏しいスタッフが普段の言葉のまま入力できるという条件とも噛み合います。 モデル選定では「何を入力し、何を出力するか」の2点で要件を切ります。新しい文章やコードを出すなら生成系の言語モデル、決まったカテゴリを返すなら分類手法、画像や音声を扱うならその形式に特化したモデル、という対応で絞ると迷いが減ります。

参考資料

• GPT（Generative Pre-trained Transformer）とは
• 大規模言語モデル（LLM）とは
• Amazon Polly の仕組み
• 人工知能におけるトランスフォーマーとは何ですか?
• コンピュータビジョンとは?