AIF-C01 Domain 3 完全攻略 — 基盤モデルの応用、最大配点 28% を制する

AIF-C01（AWS Certified AI Practitioner）の Domain 3「Applications of Foundation Models」は配点 28%。5 ドメイン中最大であり、この試験の合否を最も左右する主戦場だ。モデル選択の設計判断、推論パラメータ、RAG、プロンプトエンジニアリング、ファインチューニング、そしてモデル評価。出題範囲は広いが、貫いているのは 1 つの問いだ — 「この要件に、最小のコストで応える手段はどれか」。本記事は公式試験ガイドの 4 タスクステートメント（3.1〜3.4）に沿って、判断基準を体系化する。

生成 AI の基礎概念はAIF-C01 Domain 2 完全攻略（2026-06-10 公開）で整理した。トークン・埋め込み・基盤モデルライフサイクルが前提知識になる。

Domain 3 の全体像 — 4 つのタスクステートメント

公式試験ガイドの構成を押さえる。

4 タスクのうち 3.1 が突出して広い。RAG・ベクトル DB・エージェント・カスタマイズ手法のコスト比較がすべて 3.1 に詰め込まれており、Domain 3 の学習時間の半分はここに投じることになる。

モデル選択の設計判断 — 8 つの選定基準

タスク 3.1 の出発点は、アプリケーション要件に対する基盤モデルの選定だ。公式ガイドが例示する判断基準は 8 つ — コスト、モダリティ、レイテンシ、多言語対応、モデルサイズ、複雑性、カスタマイズ可能性、入出力長。モダリティとは、テキスト・画像・マルチモーダルといった入出力の種別を指す。

試験で問われるのは、要件文からこれらの基準を読み取る力だ。「グローバル展開する EC サイトのチャットボット」なら多言語対応が必須基準になる。「リアルタイム音声対話」ならレイテンシが支配的で、大型モデルは除外される。「社内規程に準拠した回答が必要」ならカスタマイズ可能性が効いてくる。

ここでも原則は「最高性能ではなく最小十分」だ。モデルサイズが大きいほど能力は上がるが、トークン単価とレイテンシも上がる。FAQ への定型応答に最大級のモデルを使う選択肢は、技術的には動いても設計判断としては誤りになる。SAA-C03 でコストと性能のバランスを学んだ読者なら、同じ思考回路がそのまま使える。AWS Solutions Architect Associate SAA-C03 完全攻略入門（2026-05-30 公開）で扱った設計判断の生成 AI 版だと考えていい。

推論パラメータ — temperature と出力の制御

モデルを選んだら、次は推論時の挙動制御だ。公式ガイドは推論パラメータの例として temperature と入出力長を挙げている。

temperature は出力のランダム性を制御する。低くすれば決定的で一貫した出力に、高くすれば多様で創造的な出力になる。「請求書からの情報抽出」のような正確性重視のタスクは低 temperature、「キャッチコピーの案出し」のような発散タスクは高 temperature。この対応はシナリオ問題の定番だ。

出力長の上限はコストとレイテンシに直結する。出力トークン数を制限すれば、応答は速く安くなるが、途中で切れるリスクがある。同種のパラメータとして、確率上位の候補だけからサンプリングする top-p も押さえておくと、temperature との違い（分布の形を変えるか、候補を絞るか）を問う問題に対応できる。

シナリオでの使い分けを具体化しておく。「カスタマーサポートの回答が毎回違う表現になり品質管理できない」という相談には temperature を下げる。「ブレインストーミング支援ツールの案が毎回似通う」なら temperature を上げる。「要約が長すぎてコストがかさむ」なら出力長の上限を絞る。問題文の「困りごと」をパラメータに翻訳する練習をしておくと、この領域は数十秒で解けるサービス問題になる。

重要なのは、推論パラメータが「モデルを変えずに挙動を変える最も安い手段」だという位置付けだ。後述するカスタマイズのコスト勾配の最下段に位置し、「まずパラメータとプロンプトで調整し、足りなければ RAG、それでも足りなければファインチューニング」という段階的アプローチの起点になる。

RAG の仕組みと Amazon Bedrock Knowledge Bases

タスク 3.1 の中心テーマが RAG（Retrieval Augmented Generation、検索拡張生成） だ。動作の流れを順序ごと覚える。ordering 問題の最有力候補でもある。

1. 準備フェーズ: 社内文書をチャンキングし、埋め込みモデルでベクトル化して、ベクトルデータベースに保存する
2. 質問受付: ユーザーの質問を同じ埋め込みモデルでベクトル化する
3. 検索: ベクトル DB で意味的に近いチャンクを取得する
4. 生成: 取得したチャンクをプロンプトに注入し、基盤モデルが「与えられた文脈に基づいて」回答する

RAG が解決するのは、Domain 2 で学んだ限界のうち「ハルシネーション」と「知識カットオフ」だ。モデルの重みは一切変えずに、回答の根拠を手元のデータに差し替える。だから「最新の社内情報に基づいて回答させたい」「出典を示したい」という要件には RAG が正解になり、「モデルの口調や形式そのものを変えたい」ならファインチューニング側に倒れる。この境界線が Domain 3 最大の判断ポイントだ。

AWS では Amazon Bedrock Knowledge Bases が RAG のマネージド実装にあたる。データソースを指定すれば、チャンキング・埋め込み・ベクトル保存・検索の一連を Bedrock 側が面倒を見る。「RAG を自前で組まずに使いたい」というシナリオでの解答はこれだ。

なお、RAG は「ファインチューニングより安い」とはいえ無料ではない。埋め込みの生成、ベクトルデータベースの維持、検索のたびの計算が運用コストとして乗り続ける。文書が数件で更新もないなら、プロンプトに直接貼り込む in-context learning の方が合理的なこともある。「RAG が常に正解」ではなく、知識の量と更新頻度がしきい値を超えたときに RAG が効く、という相場観まで持っておくと、コスト比較問題で一段深い判断ができる。

ベクトルデータベース — AWS の 5 つの選択肢

RAG の検索部分を支えるベクトル DB について、公式ガイドは AWS サービスを 5 つ例示している。matching 問題で問われ得るので、それぞれの本来の役割とセットで覚える。

AIF-C01 レベルで問われるのは各サービスの内部実装ではなく、「埋め込みの保存先として使える AWS サービスはどれか」という識別だ。逆に、ベクトル DB として例示されていないサービス（DynamoDB 等）を選択肢に混ぜる問題が想定されるので、この 5 つを正のリストとして覚えておくのが効率的だ。

カスタマイズ 4 手法のコスト勾配

タスク 3.1 の総仕上げが、基盤モデルをユースケースに適応させる手法のコスト比較だ。公式ガイドは事前学習、ファインチューニング、in-context learning（文脈内学習）、RAG の 4 つを挙げている。コストの低い順に並べる。

1. In-context learning: プロンプト内に例示を入れて挙動を誘導する。モデルもデータ基盤も変えない。最安・最速
2. RAG: 外部知識を検索して注入する。ベクトル DB の構築・運用コストが乗る
3. ファインチューニング: モデルの重みを追加学習で更新する。学習データの整備と学習ジョブのコストが乗る
4. 継続的事前学習 / 事前学習: 大規模データでモデル自体を育てる。桁違いの計算資源が必要で、ほとんどの組織には不要

この順序は ordering 問題でそのまま出題され得るうえ、シナリオ問題の判断軸にもなる。「まず安い手段から試す」が原則で、要件が「知識の追加」なら RAG、「挙動・スタイルの変更」ならファインチューニング、「例を見せれば済む程度の調整」なら in-context learning。手法と目的のマッピングを即答できるようにしておく。

エージェント — マルチステップタスクの自動化

3.1 の残る論点がエージェントだ。公式ガイドは Amazon Bedrock のエージェント機能（Bedrock Agents）を例示している。

エージェントは「一往復の質問応答」を超えて、目標達成までの複数ステップを自律的に実行する仕組みだ。タスクを分解し、必要に応じて API や検索を呼び出し、結果を踏まえて次の行動を決める。「在庫を確認して、足りなければ発注し、結果を報告する」という業務フローを、1 つの指示から完遂させるイメージになる。

試験対策としては、「単発の生成 → 基盤モデル + プロンプト」「社内知識に基づく回答 → RAG」「複数ステップの業務実行 → エージェント」という 3 段の使い分けを押さえれば十分だ。エージェントが内部でツール呼び出しと推論を繰り返す、という動作イメージを持っておくと、ケーススタディ形式でフロー順を問われても対応できる。

プロンプトエンジニアリング — 技法の使い分け

タスク 3.2 はプロンプトエンジニアリングの各論だ。公式ガイドが挙げる概念は、コンテキスト、指示（instruction）、ネガティブプロンプト、潜在空間。技法としては zero-shot、single-shot、few-shot、chain-of-thought、プロンプトテンプレートが並ぶ。

• Zero-shot: 例示なしで指示だけを与える。モデルの汎用能力に任せる
• Single-shot / Few-shot: 1 つまたは複数の入出力例を見せてから本番の入力を与える。形式や粒度を揃えたいときに効く
• Chain-of-thought（CoT）: 「段階的に考えて」と促し、推論過程を出力させる。多段の論理が必要なタスクで精度が上がる
• プロンプトテンプレート: 変数部分を差し替えて使い回す定型プロンプト。アプリケーションへの組み込みで必須になる

ネガティブプロンプトは「含めてほしくないもの」を明示する技法で、画像生成の文脈で特に使われる。潜在空間は、モデルが内部で概念を表現している高次元空間のことで、「プロンプトは潜在空間内の出力候補を絞り込む操作」という直感を持っておくと用語問題に対応できる。

技法選択のシナリオはこう判別する。「出力形式を厳密に揃えたい」→ few-shot。「複雑な計算や多段推論」→ chain-of-thought。「コストを最小にしつつ汎用タスク」→ zero-shot。例示はトークンを消費するため、few-shot は精度と引き換えにコストが上がるというトレードオフも添えて覚えておく。

プロンプトの攻撃リスク — 4 つの脅威

タスク 3.2 の後半は、プロンプトエンジニアリングのリスク面だ。公式ガイドは 4 つを例示している。セキュリティ用語として matching 問題に出やすい。

• Exposure（露出）: プロンプトや応答に機密情報が含まれ、漏洩する
• Poisoning（汚染）: 学習データや参照データに悪意ある内容を仕込み、モデルの挙動を歪める
• Hijacking（ハイジャック）: プロンプトインジェクションにより、本来の指示を上書きして意図しない動作をさせる
• Jailbreaking（脱獄）: 安全制約を回避させ、本来拒否すべき出力を引き出す

対策側の代表が Amazon Bedrock Guardrails で、有害コンテンツのフィルタリングや話題の制限をモデルの外側で適用する。「ユーザー入力がシステム指示を上書きするのを防ぎたい」という文には Hijacking（プロンプトインジェクション）、「規約違反の出力を引き出す試み」には Jailbreaking を対応付ける。この 4 用語は Domain 5 のセキュリティ文脈でも再登場する。

学習とファインチューニング — 手法とデータ準備

タスク 3.3 は、基盤モデルの学習プロセスを一段深く問う。事前学習・ファインチューニング・継続的事前学習の区別に加え、ファインチューニングの具体的手法が並ぶ。

• Instruction tuning: 指示と模範応答のペアで学習させ、指示追従能力を高める
• ドメイン適応: 医療・法務・製造など特定分野のデータで追加学習し、専門領域に強くする
• 転移学習: 既存モデルの能力を別タスクに引き継ぐ、ファインチューニング全般の土台となる考え方
• RLHF（人間のフィードバックからの強化学習）: 人間の好みの評価を報酬としてモデルを調整する。Domain 1 で学んだ強化学習の応用形

データ準備の論点も出題範囲だ。キュレーション(データの選別・清掃)、ガバナンス（権利・プライバシーの管理）、サイズ、ラベリング、代表性（偏りのないデータ分布）。「ファインチューニングの成否はデータの質で決まる」という文脈で、これらの要素が選択肢に並ぶ。

試験での判別ポイントは「何を変えたいか」だ。指示への従い方なら instruction tuning、専門知識ならドメイン適応、人間の好みに合わせるなら RLHF。そして「知識を足したいだけなら、そもそもファインチューニングではなく RAG」という 3.1 への巻き戻しが、最頻出の引っかけ構造になる。

基盤モデルの評価 — ROUGE・BLEU・BERTScore

タスク 3.4 は評価手法だ。人間評価とベンチマークデータセットの使い分け、そして 3 つの自動評価指標が範囲になる。

matching 問題では「要約タスクの評価 → ROUGE」「翻訳 → BLEU」「言い換えを許容する意味比較 → BERTScore」の対応が問われる。ROUGE と BLEU は表層的な単語の一致を見るため、意味は同じでも表現が違う出力を低く評価してしまう。その弱点を埋めるのが埋め込みベースの BERTScore、という関係で覚えると忘れない。

自動指標で測れない品質 — 有用性、トーン、安全性 — は人間評価やベンチマークで補う。そして最終的には「ビジネス目標を達成したか」で判断する。技術指標とビジネス指標の二層構造は Domain 1 から一貫するテーマで、AIF-C01 Domain 1 完全攻略（2026-06-09 公開）で扱った評価の考え方が、基盤モデルにもそのまま延長される。

メイカーの現場で考える Domain 3 — カスタマイズ判断の実地演習

Domain 3 の判断フレームは、モノづくりの現場課題に当てはめると一気に手触りが出る。3 つの課題で「どの手法を選ぶか」を演習してみる。

課題 1: 「うちのプリンターの設定について答える AI が欲しい」。必要なのは知識の追加であって、モデルの挙動変更ではない。答えは RAG だ。プリンターのマニュアル、スライサーの設定ガイド、自分の実験ノートをチャンキングして埋め込み化し、質問時に関連箇所を注入する。ファインチューニングを選ぶと、データ整備と学習のコストがかかるうえ、設定値を更新するたびに再学習が必要になる。RAG ならドキュメントの差し替えだけで知識が更新される。この「更新頻度が高い知識は RAG」という判断は試験でも実務でも同じだ。

課題 2: 「サポート除去のコツを、毎回同じテンプレ形式で出力させたい」。形式の統一は few-shot プロンプトの領分だ。期待する出力例を 2〜3 個プロンプトに入れるだけで、モデルの重みには触れない。in-context learning で済む課題にファインチューニングを持ち出さない、というコスト勾配の最下段から試す原則がそのまま適用される。

課題 3: 「失敗報告を受けたら原因候補を調べ、設定変更案を作り、印刷キューに再投入までさせたい」。これは複数ステップの業務実行なので、エージェントの領分になる。失敗ログの取得、ナレッジ検索（内部で RAG を呼ぶ）、設定ファイルの生成、キュー API の呼び出し。単発の質問応答では完結しないタスクの自動化、という条件がエージェント選択のトリガーだ。

3 つの課題は、そのまま「RAG / in-context learning / エージェント」の判別問題になっている。自分の趣味や業務の課題で同じ演習を 5 分やっておくと、本番のシナリオ問題で迷いが消える。

まとめ — Domain 3 の得点戦略

最大配点 28% の Domain 3 は、次の 5 つの「即答セット」を作れば得点源になる。

1. カスタマイズのコスト勾配: in-context learning < RAG < ファインチューニング < 事前学習。目的（例示で済む/知識追加/挙動変更/ゼロから）との対応込みで
2. RAG のフロー 4 段階: チャンキング・埋め込み → 質問の埋め込み → 検索 → 注入生成（ordering 対策）
3. ベクトル DB 5 サービス: OpenSearch Service / Aurora / RDS for PostgreSQL / Neptune / DocumentDB の正リスト暗記
4. プロンプト技法と攻撃 4 種: zero/few-shot・CoT の使い分け + Exposure/Poisoning/Hijacking/Jailbreaking
5. 評価指標 3 点: ROUGE=要約、BLEU=翻訳、BERTScore=意味類似

Domain 3 を固めれば、試験の 52%（Domain 2+3）に判断の軸が通る。残るは配点 28% 分のガバナンス系 2 ドメイン — 責任ある AI とセキュリティだ。ここまでの技術知識を「統制の言葉」に翻訳する作業が次のステップになる。

参照

• AWS Certified AI Practitioner (AIF-C01) 試験ガイド Domain 3（公式）
• AWS Certified AI Practitioner (AIF-C01) 試験ガイド PDF（公式）
• Amazon Bedrock Knowledge Bases（公式）
• Amazon Bedrock Agents（公式）
• Amazon OpenSearch Service（公式）

ブラウザだけでできる本格的なAI画像生成【ConoHa AI Canvas】

swiftwand

X

AIを使って、毎日の生活をもっと快適にするアイデアや将来像を発信しています。 初心者にもわかりやすく、すぐに取り入れられる実践的な情報をお届けします。 Sharing ideas and visions for a better daily life with AI. Practical tips that anyone can start using right away.