AIF-C01 Domain 2 完全攻略 — 生成 AI の基礎で 24% を取る

AIF-C01 Domain 2 完全攻略 — 生成 AI の基礎で 24% を取る
AIF-C01(AWS Certified AI Practitioner)の Domain 2「Fundamentals of Generative AI」は配点 24%。Domain 3 と合わせて試験の過半を占める「生成 AI ゾーン」の前半戦だ。トークン・埋め込みといった基礎概念、基盤モデルのライフサイクル、生成 AI の能力と限界、そして Amazon Bedrock を中心とする AWS の生成 AI スタック。本記事は公式試験ガイドの 3 タスクステートメント(2.1〜2.3)に沿って、出題範囲を一気に整理する。
前提となる機械学習の基礎はAIF-C01 Domain 1 完全攻略(2026-06-09 公開)で解説した。「教師あり学習」「ラベル付きデータ」といった用語が曖昧な場合は、先にそちらを固めてほしい。
- Domain 2 の全体像 — 3 つのタスクステートメント
- 生成 AI の基本概念 — トークン・埋め込み・チャンキング
- 生成 AI モデルの種類 — LLM・基盤モデル・マルチモーダル・拡散モデル
- 基盤モデルのライフサイクル — 公式例示の 7 段階
- 生成 AI の強みと限界 — ハルシネーション・非決定性・解釈可能性
- モデル選択の判断要素とビジネス価値指標
- AWS の生成 AI スタック — Bedrock・Amazon Q・PartyRock・JumpStart
- AWS で構築する利点 — コスト体系とセキュリティ
- メイカーの現場で考える Domain 2 — モノづくりへの適用例
- まとめ — Domain 2 の得点戦略
- 参照
Domain 2 の全体像 — 3 つのタスクステートメント

公式試験ガイドの構成はこうだ。
| タスク | 公式名 | 中核テーマ |
|---|---|---|
| 2.1 | Explain the basic concepts of generative AI | トークン・埋め込み・モデル種別・基盤モデルライフサイクル |
| 2.2 | Understand the capabilities and limitations of generative AI for solving business problems | 強みと限界、モデル選択の判断要素、ビジネス価値指標 |
| 2.3 | Describe AWS infrastructure and technologies for building generative AI applications | Bedrock / Amazon Q / PartyRock / JumpStart、コストと セキュリティ |
Domain 1 が「ML 全般の地図」だったのに対し、Domain 2 は生成 AI に焦点を絞り込む。そして Domain 3(基盤モデルの応用、28%)が「使いこなし」を問うのに対し、Domain 2 は「仕組みと判断」を問う。概念→応用の順に積み上がる構造なので、ここを飛ばして Domain 3 に進むと暗記頼みになる。
生成 AI の基本概念 — トークン・埋め込み・チャンキング

タスク 2.1 の用語群は、生成 AI の動作原理を「数式なしで」説明できるレベルが要求水準だ。公式ガイドが明示する用語を、相互の関係で押さえる。
トークンは、モデルがテキストを処理する最小単位だ。単語より細かく、日本語では 1 文字が複数トークンになることもある。LLM の料金も入出力の上限も、すべてトークン数で決まる。コンテキストウィンドウは、モデルが一度に扱えるトークン数の上限を指す。
埋め込み(エンベディング)は、テキストの意味を数値ベクトルに変換したものだ。意味が近いテキストはベクトル空間上でも近くに配置されるため、「意味の近さ」を距離として計算できる。これが セマンティック検索や RAG の検索部分を支える基盤技術になる。ベクトルという用語が出たら「意味の数値表現」と読み替えればいい。
チャンキングは、長い文書を意味のまとまりで分割する処理だ。埋め込みは文書全体ではなくチャンク単位で作ることが多く、チャンクの切り方が検索精度を左右する。「文書 → チャンキング → 埋め込み → ベクトルとして保存」という一連の流れは、ordering 形式で問われ得るプロセスなので、順序ごと覚えておく。
コンテキストウィンドウの実務的な意味も補足しておく。ウィンドウを超えた情報はモデルに「見えない」ため、長大な文書をそのまま渡すアプローチには上限がある。だからこそチャンキングと埋め込み検索で「関連部分だけを選んで渡す」設計(RAG の原型)が生まれた。「コンテキストウィンドウの制約 → チャンキングの必要性 → 埋め込み検索」という因果の鎖で理解しておくと、用語がバラバラの暗記にならず、Domain 3 の RAG 問題にもそのまま接続する。
プロンプトエンジニアリングも 2.1 の用語リストに含まれる。Domain 2 の段階では「モデルの重みを変えずに、入力の書き方だけで出力品質を制御する技法」という定義と、「ファインチューニングより圧倒的に低コストで試せる最初の手段」という位置付けを押さえれば足りる。具体的な技法(zero-shot、few-shot 等)は Domain 3 で掘り下げる。
そして Transformer は、現行の LLM が基づくニューラルネットワークアーキテクチャの名前だ。試験では内部構造の詳細までは問われない。「現在の LLM は Transformer ベースのアーキテクチャの上に構築されている」という位置付けと、自己注意機構により文中の離れた単語同士の関係を捉えられる、という特徴レベルで十分だ。
生成 AI モデルの種類 — LLM・基盤モデル・マルチモーダル・拡散モデル

公式ガイドは生成 AI モデルの種別として、LLM、基盤モデル、マルチモーダルモデル、拡散モデルを例示している。それぞれの関係を整理する。
基盤モデル(Foundation Model) は、大規模データで事前学習され、多様なタスクに適応できる汎用モデルの総称だ。LLM は基盤モデルのうちテキストを扱うもの。マルチモーダルモデルは、テキスト・画像・音声など複数の種類の入出力を扱えるモデルを指す。「画像を見せて質問に答えさせる」「テキストから画像を生成する」がマルチモーダルの典型だ。
拡散モデル(Diffusion Model) は画像生成で主流のアーキテクチャで、ノイズだらけの状態から段階的にノイズを除去して画像を生成する。LLM がトークンを順に予測するのと対照的に、拡散モデルは「ノイズ除去の反復」で出力を作る。この生成原理の違いは matching 問題の候補だ。
ユースケース側の例示は、画像・動画・音声の生成、要約、チャットボット、翻訳、コード生成、カスタマーサービスエージェント、検索、レコメンデーションと幅広い。試験対策上のポイントは、「どのユースケースにどのモデル種別が適するか」の対応付けだ。製品写真の生成なら拡散モデル、契約書の要約なら LLM、音声付き動画への字幕生成と内容質問への回答ならマルチモーダル、という振り分けが即答できれば十分に戦える。
基盤モデルのライフサイクル — 公式例示の 7 段階

タスク 2.1 の最重要トピックが、基盤モデルのライフサイクルだ。公式ガイドは 7 つの段階を例示している。Domain 1 の「ML ライフサイクル 9 工程」と似ているが別物なので、混同しないよう並べて覚える。
- データ選択: 事前学習に使う大規模データを選ぶ
- モデル選択: アーキテクチャと規模を決める
- 事前学習(Pre-training): 大規模データで汎用能力を獲得させる
- ファインチューニング: 特定タスク・ドメイン向けに追加学習する
- 評価: ベンチマークと人間評価で品質を測る
- デプロイ: 推論環境に配置する
- フィードバック: 利用データから改善点を回収し、次のサイクルへ
Domain 1 の ML ライフサイクルとの違いは出発点だ。従来型 ML は「自分のデータで自分のモデルをゼロから学習する」のに対し、基盤モデルは「汎用能力を持つ事前学習済みモデルから出発し、必要に応じて適応させる」。事前学習は膨大な計算資源を要するため、ほとんどの組織は事前学習をスキップして既存の基盤モデルを選び、ファインチューニング以降だけを自分で行う。この「どこから自分でやるか」という視点は、Domain 3 のカスタマイズ手法選択に直結する。
ordering 問題の引っかけとして、ML ライフサイクル(9 工程)の要素と基盤モデルライフサイクル(7 段階)の要素を混ぜた選択肢が想定される。「特徴量エンジニアリング」が並んでいたら従来型 ML の文脈、「事前学習」「フィードバック」が並んでいたら基盤モデルの文脈と見分ける。両者を別の表として覚えておけば、混在型の選択肢に揺さぶられない。
生成 AI の強みと限界 — ハルシネーション・非決定性・解釈可能性

タスク 2.2 は、生成 AI をビジネス課題に適用する際の判断力を問う。強みと限界の両面を、公式ガイドの例示に沿って押さえる。
強みとして挙げられるのは適応性(1 つのモデルが多様なタスクに対応する)、応答性(自然言語での即時対話)、シンプルさ(API 呼び出しだけで高度な機能を実装できる)だ。従来は個別にモデルを開発していた要約・翻訳・分類が、1 つの基盤モデルへのプロンプトで済む。この汎用性が生成 AI のビジネス価値の源泉になる。
限界側は 4 つの例示が重要だ。
- ハルシネーション: もっともらしい誤情報を生成する。事実性が要求される用途では検証層が必須
- 不正確さ: 計算や厳密なロジックは苦手。確定的な正解が必要な処理には向かない
- 非決定性: 同じ入力でも出力が毎回変わり得る。再現性が要求されるワークフローでは制御が必要
- 解釈可能性の低さ: なぜその出力になったかを説明しにくい。規制業種では採用障壁になる
この 4 つは、Domain 1 で学んだ「AI を使わない判断」の生成 AI 版だ。シナリオ問題では「金融機関の与信判定に LLM の出力をそのまま使う」ような選択肢が誤答として置かれる。ハルシネーションと解釈可能性の問題を想起できれば、確実に除外できる。
限界の「緩和策」もセットで覚えておくと応用が利く。ハルシネーションには検証可能なソースに基づかせるグラウンディング(RAG が代表)、非決定性には推論パラメータ(temperature 等)による出力の安定化、不正確な計算には外部ツールへの委譲。つまり限界は「生成 AI を使わない理由」で終わらず、「アーキテクチャで補う対象」として出題される。「ハルシネーションが懸念されるので社内文書に基づいて回答させたい」というシナリオの答えが RAG になる、という連結が Domain 2 と Domain 3 をまたぐ最頻出パターンだ。
モデル選択の判断要素とビジネス価値指標

タスク 2.2 の後半は、ビジネス課題に対する基盤モデル選択の判断要素を扱う。考慮すべき軸は、モデルの種類(テキスト/画像/マルチモーダル)、性能要件(精度とレイテンシ)、能力(コンテキスト長、対応言語)、制約(コスト、データの持ち出し可否)、コンプライアンス要件だ。
ここで重要な考え方は「最大のモデルが最適とは限らない」だ。高性能な大型モデルはトークン単価もレイテンシも大きい。FAQ ボットのような定型性の高いタスクなら、小型モデルの方がコスト効率で勝つ。要件 → 最小十分なモデル、という選択ロジックは AWS 認定全体に通底する思想で、SAA-C03 の「コストと性能のバランス」と同型だ。
ビジネス価値の測定では、技術指標(精度等)に加えて、コンバージョン率、ユーザーあたり平均収益、業務効率といった事業指標で生成 AI 導入の成否を評価する視点が問われる。AWS AI Practitioner AIF-C01 完全攻略入門(2026-06-08 公開)で触れた通り、AIF-C01 は技術者以外も対象とする試験であり、「技術的に動く」と「事業的に成功」を区別させる出題が一貫した特徴になっている。
AWS の生成 AI スタック — Bedrock・Amazon Q・PartyRock・JumpStart

タスク 2.3 は、生成 AI アプリケーションを構築するための AWS サービス群を問う。公式ガイドの例示は 4 つ。役割の違いで整理する。
| サービス | 位置付け | 対象ユーザー |
|---|---|---|
| Amazon Bedrock | 複数の基盤モデルを統一 API で利用するマネージドサービス | 開発者 |
| Amazon Q | 業務・開発向けの完成された AI アシスタント | 業務ユーザー / 開発者 |
| PartyRock | Bedrock ベースのノーコード実験環境(Amazon Bedrock Playground) | 学習者・プロトタイパー |
| SageMaker JumpStart | 基盤モデルを自分の環境にデプロイ・カスタマイズするハブ | ML エンジニア |
判別の軸は「抽象度」だ。完成品のアシスタントが欲しいなら Amazon Q。自分のアプリに生成 AI を組み込むなら Bedrock の API。コードを書かずに生成 AI アプリの感触を掴むなら PartyRock。モデルの中身まで制御したいなら JumpStart。試験では「この要件にはどのサービスか」という振り分け問題が出るので、この 4 行を即答できるようにしておく。
Bedrock の特徴として試験で効くのは「単一モデルのサービスではない」という点だ。Amazon 自社の基盤モデルに加え、複数のサードパーティーモデルプロバイダーのモデルを、同じ API・同じセキュリティ境界の中で切り替えて使える。「ユースケースごとに最適なモデルを選びたいが、統合は一本化したい」という要件に対する答えが Bedrock になる。また、ファインチューニングやエージェント機能、ガードレール(Bedrock Guardrails)までマネージドで提供されるため、「インフラを管理せずに生成 AI アプリの部品を揃えたい」というシナリオでは Bedrock が正解側に置かれることが多い。逆に「特定のオープンモデルの重みを自分の VPC 内で完全制御したい」なら JumpStart 側に倒れる。この境界線の引き方が 2.3 の核心だ。
Amazon Q は 2 系統に分かれる点も押さえたい。Amazon Q Developer はコーディング支援で、恒久無料の Free Tier と Pro($19/ユーザー/月)の 2 ティア。Amazon Q Business は社内文書を横断する業務アシスタントで、Lite($3/ユーザー/月)と Pro($20/ユーザー/月)がある。料金の詳細値より「Developer と Business は別製品で、ティア制」という構造の理解が試験では効く。
AWS で構築する利点 — コスト体系とセキュリティ

タスク 2.3 の残りは、「なぜ AWS 上で生成 AI を構築するのか」という論点だ。公式ガイドは利点として、参入障壁の低さ、効率性、コスト効率、市場投入までの速さを挙げている。自前で GPU クラスタを調達して基盤モデルを運用する場合と比較して、マネージドサービスは初期投資ゼロで従量課金から始められる。
コストのトレードオフ構造は頻出論点だ。Bedrock にはトークン従量課金(使った分だけ払う、変動負荷向け)とプロビジョンドスループット(処理能力を予約する、安定大量負荷向け)の 2 体系がある。応答性・可用性・冗長性・リージョン展開といった要件を上げるほどコストも上がる。「開発初期は従量課金、本番の安定負荷はプロビジョンド」という使い分けは、SAA-C03 のオンデマンド vs リザーブドの考え方と同型で、クラウドのコスト設計思想が生成 AI にもそのまま適用されることを示している。
セキュリティ面では、顧客データが基盤モデルの学習に勝手に使われないこと、データが暗号化され顧客の管理下に置かれること、コンプライアンス認証への対応が利点として挙げられる。生成 AI 導入で企業が最も懸念する「入力した機密データはどこへ行くのか」に対する AWS の答えがこの領域で、Domain 5(セキュリティとガバナンス)への接続点になる。
メイカーの現場で考える Domain 2 — モノづくりへの適用例

抽象的な概念は、自分の現場に引き付けると一気に定着する。3D プリントを例に、Domain 2 の概念を適用してみる。
マルチモーダルモデルの適用: 印刷失敗の写真を見せて「この失敗の原因は何か」を質問する。画像とテキストをまたぐ入出力なので、マルチモーダルモデルの領分だ。一方、failure 検出を 24 時間自動で回すなら、Domain 1 で扱った分類モデル(軽量・低コスト・決定的)の方が適する。「対話的な原因診断は生成 AI、常時監視は従来型 ML」という使い分けは、2.2 の「生成 AI が適する場面・適さない場面」の判断そのものだ。
RAG 的アプローチの適用: プリンターのマニュアル、フィラメントのデータシート、過去のトラブル記録をチャンキングして埋め込み化すれば、「PETG で層間剥離が出るときの設定は」と聞ける社内ナレッジボットが作れる。ハルシネーション対策として手元の文書に基づかせる、という 2.2 の限界緩和がそのまま設計になる。
コード生成の適用: OpenSCAD のようなコードベースの 3D モデリングは、生成 AI のコード生成ユースケースと相性がいい。「幅 80mm、奥行き 120mm、壁厚 2mm のトレイ」という自然言語からパラメトリックなコードを生成させ、寸法は変数で調整する。確定的な寸法計算はコード側(決定的)に持たせ、形状のアイデア出しを生成 AI(確率的)に任せる分担は、非決定性の限界を踏まえた設計例になる。
このように Domain 2 の出題テーマは、「概念を知っているか」の先にある「自分のユースケースで適否を判断できるか」を試している。学習中も、自分の業務や趣味の課題を 1 つ決めて「生成 AI で解くべきか、従来型 ML か、ただのコードか」を自問すると、試験の判断問題がそのまま練習できる。
まとめ — Domain 2 の得点戦略

Domain 2(配点 24%)の学習優先度はこうだ。
- 用語の連鎖で覚える: 文書 → チャンキング → 埋め込み → ベクトル、の流れごと理解する(ordering 対策)
- モデル種別 × ユースケースの対応: LLM / マルチモーダル / 拡散モデルの生成原理と適用場面(matching 対策)
- 基盤モデルライフサイクル 7 段階: Domain 1 の ML 9 工程と混同しない
- 限界 4 点の即答: ハルシネーション・不正確さ・非決定性・解釈可能性。シナリオの誤答除外に直結
- AWS 4 サービスの抽象度マップ: Q(完成品)→ Bedrock(API)→ PartyRock(実験)→ JumpStart(自前運用)
Domain 2 で「仕組みと判断」を固めれば、次の Domain 3(基盤モデルの応用、最大配点 28%)は RAG・ファインチューニング・プロンプトエンジニアリングという「使いこなし」の各論に集中できる。生成 AI ゾーン 52% の攻略は、この 2 ドメインの積み上げで決まる。
参照
- AWS Certified AI Practitioner (AIF-C01) 試験ガイド(公式)
- AWS Certified AI Practitioner (AIF-C01) 試験ガイド PDF(公式)
- Amazon Bedrock(公式)
- Amazon Q Developer 料金(公式)
- Amazon Q Business 料金(公式)
- PartyRock(公式)





