NO IMAGE

AIF-C01 D2 生成AIの基礎 徹底解説（2025年最新）｜LLM・Bedrock・hallucination対策

NO IMAGE
目次

はじめに — D2「生成AIの基礎」とは

本記事は「AWS AIF-C01試験対策」シリーズの Vol2 です。
シリーズ全体の学習ロードマップはVol0をご参照ください。

ここで扱うのは試験の第2ドメイン、D2「生成AIの基礎（Fundamentals of Generative AI）」 です。
公式試験ガイドにおける出題比率は 24% であり、採点対象50問換算で約12問相当です。
問題バンク400問の中では104問を占め、D3（28%）に次ぐ第2の大ドメインです。

生成AIは急速に進化する分野です。AIF-C01はFoundational（基礎）レベルゆえ、「何か・どんな特性を持つか・いつ使うか」という概念理解と用途判断 が問われます。実装詳細（コーディング・ハイパラ調整）は出題範囲外であるため、本記事も概念を中心に解説します。

この記事（Vol2）で得られること

  • D2の全出題範囲とカバー率（§1）
  • トークン・エンベディング・ベクトルの基礎（§2）
  • Transformer/LLM/FMアーキテクチャの概要（§3）
  • 拡散モデル・マルチモーダルFMの区別（§4）
  • FMライフサイクルとトークン課金の仕組み（§5）
  • 生成AIの利点・限界・hallucination対策（§6–§7）
  • Agentic AIとOrchestrationの概念（§8）
  • AWS生成AIサービス（Bedrock/JumpStart/Amazon Q/PartyRock）の整理（§9）

D2 出題範囲と配点（104問・24%）

AIF-C01 D2は3つのタスクステートメントで構成されています。

タスクステートメント概要頻出論点
2.1 生成AIの基本概念トークン/FM/LLM/アーキテクチャ/拡散モデルトークン化・エンベディング・Transformer
2.2 生成AIの能力と限界利点（適応性）・欠点（hallucination/非決定性）hallucination定義・バイアス・コンテキスト長
2.3 AWSインフラ・技術Bedrock/JumpStart/Amazon Q/PartyRockサービス用途の使い分け・agentic AI
D2学習のコツ

  • 「トークン」と「エンベディング」と「ベクトル」は混同されやすい3概念です。それぞれの役割をセットで押さえましょう
  • hallucinationは「誤情報を生成する現象」ですが、その根本原因（確率的推論）を理解すると対策問題にも対応しやすくなります
  • AWS生成AIサービスの整理は「誰が使うか・何ができるか」で分類すると記憶しやすいです

トークン・エンベディング・ベクトルの基礎

生成AIを理解する上で最初に押さえるべき3つの概念がトークン（Token）・エンベディング（Embedding）・ベクトル（Vector）です。

トークン（Token）

トークンとは、テキストを処理する際の最小単位です。
たとえば「こんにちは世界」というテキストは、英語のLLMでは単語や形態素単位で分割されます（例: 「こんにち」「は」「世」「界」のようなサブワード単位）。
英語では通常1トークン ≒ 4文字、日本語では1文字が複数トークンになることが多く、同じ意味でも英語より多くのトークンを消費します。

トークンが特に重要な理由は課金単位であるためです。Amazon BedrockなどのAPIでは、入力トークン数・出力トークン数でコストが決まります。また、モデルが一度に処理できるトークン数の上限をコンテキスト長（context length / context window） と呼びます。コンテキスト長が長いほど、長い会話履歴や長文書類を一度に処理できます。

チャンキング（Chunking） は、長いドキュメントをコンテキスト長内で処理できるサイズに分割する技法です。RAG（検索拡張生成）を実装する際の基本手法として頻出です。

エンベディング（Embedding）とベクトル（Vector）

テキストをそのままコンピュータで処理するのは困難です。エンベディングとは、テキストや画像などのデータを数値ベクトル（複数の数値の配列）に変換する処理です。

たとえば「犬」というテキストが [0.2, 0.8, 0.1, ...] という数値ベクトルに変換されます。意味的に近い概念（「犬」と「猫」）は、ベクトル空間内でも近くに配置されます。この性質を利用して意味的類似度検索が実現します。

ベクトルDB（Vector Database） は、これらのベクトルを効率的に格納・検索するデータベースです。RAGシステムではドキュメントをエンベディング化してベクトルDBに格納し、ユーザーの問いに意味的に近い情報を高速検索します。Amazon Bedrockでは Knowledge Bases 機能がこの処理をマネージドに提供しており、バックエンドのベクトルDBとして Amazon OpenSearch Serverless・Aurora PostgreSQL・Neptune Analytics などを選択できます（2025年時点）。

試験頻出：トークン・エンベディング・ベクトルの使い分け

  • トークン: テキストの最小処理単位・課金単位・コンテキスト長の基準
  • エンベディング: テキスト→数値ベクトルへの変換プロセス（意味を数値化する）
  • ベクトル: エンベディング後の数値表現。意味的類似度をコサイン類似度等で測定可能
  • ベクトルDB: ベクトルを格納し意味検索を高速実行するデータベース（RAGの心臓部）

Transformer/LLM/FM アーキテクチャの概要

Transformer アーキテクチャ

現代の生成AIの根幹を成すのが Transformer アーキテクチャです。
2017年に発表されたこのアーキテクチャは、Self-Attention（自己注意） メカニズムを活用して、入力テキスト中の各トークンがほかのすべてのトークンと関係性を計算します。これにより、文脈を考慮した高精度なテキスト処理が可能になりました。

AIF-C01試験では、Transformerの詳細な数式は不要です。「現代LLMの基盤アーキテクチャはTransformerである」という理解で十分です。

LLM（Large Language Model）と FM（Foundation Model）

概念定義特徴
LLM（大規模言語モデル）大量のテキストデータで事前学習された大規模なTransformerモデルテキスト生成・翻訳・要約・質問応答に特化
FM（Foundation Model / 基盤モデル）大量の多様なデータで事前学習された大規模モデル（LLMを含む上位概念）テキスト・画像・音声など複数モダリティに対応可能

LLMはFMの一種です。すべてのFMがLLMではなく、画像生成モデルや音声モデルもFMに含まれます。試験では「FM ⊃ LLM」という包含関係を押さえておきましょう。

プロンプトエンジニアリングの基礎

生成AIモデルへの入力（命令文）をプロンプト（Prompt） と呼びます。プロンプトの設計次第でモデルの出力品質が大きく変わります。AIF-C01で頻出の手法は以下の通りです。

技法説明使いどころ
Zero-shot例示なしに直接タスクを依頼する汎用的なタスク、シンプルな質問
Few-shot例（shot）を数件示してからタスクを依頼する特定の形式・スタイルで出力させたい場合
Chain-of-Thought（CoT）「ステップバイステップで考えてください」と推論過程を記述させる数学・論理・複雑な推論タスク

Context Engineering（コンテキストエンジニアリング） は、モデルに渡すコンテキスト全体（プロンプト・メモリ・ツール結果・検索結果等）を最適化する概念であり、プロンプトエンジニアリングの拡張版として2025年時点で注目されています。

生成AIワークフロー図
生成AIワークフロー（プロンプト入力→FM処理→出力）

拡散モデル・マルチモーダルFM

拡散モデル（Diffusion Model）

テキスト生成に特化したLLM/FMとは異なり、拡散モデルは主に画像生成に使用されます。拡散モデルは「ノイズを加えて壊したデータを、逆プロセスで復元する」という原理で訓練され、テキストプロンプトから高品質な画像を生成します。

代表的な拡散モデルには Stability AI の Stable Diffusion があります。Amazon Bedrock では Stability AI のモデルを API 経由で利用でき、テキストから画像を生成するユースケースに対応しています（2025年時点）。

試験では「画像生成の生成AIモデルが使う主要アーキテクチャ → 拡散モデル（Diffusion Model）」という対応関係を覚えておきましょう。

マルチモーダルFM（Multimodal Foundation Model）

マルチモーダルとは、テキスト・画像・音声・動画など複数の入出力モダリティを扱えることを指します。

たとえば Amazon Nova シリーズ（Amazon独自開発モデル）は、テキストと画像を組み合わせた入力（Vision機能）が可能です（2025年時点）。マルチモーダルFMを使うと、「この画像を説明してください」「この写真の問題点を指摘してください」といったユースケースが実現します。

モダリティ入力例出力例主な用途
テキストのみ文章・質問文章・コード質問応答・翻訳・要約
テキスト+画像（マルチモーダル）写真+質問文章画像説明・内容分析
テキスト→画像（生成）テキストプロンプト画像画像生成（拡散モデル）
音声→テキスト音声ファイル文字起こし文字起こし（Amazon Transcribe等）

FMライフサイクルとトークン課金モデル

FMライフサイクル

基盤モデルは以下のライフサイクルで開発・運用されます。

フェーズ内容担い手AIF頻出論点
事前学習（Pre-training）大量の多様なデータでゼロからモデルを訓練するモデル開発者（Amazon/Anthropic/Meta等）莫大なコストがかかるためAPIで利用するのが現実的
ファインチューニング（Fine-tuning）事前学習済みモデルを特定タスクのデータで追加学習する利用企業・開発者専門ドメイン適応・言語スタイル調整
デプロイ（Deployment）モデルをAPIエンドポイントとして公開するプラットフォーム側スループット・コスト・レイテンシの最適化
推論（Inference）デプロイ済みモデルに入力を与えて出力を得るエンドユーザー・アプリリアルタイム/バッチ/非同期/サーバーレスの使い分け
評価（Evaluation）モデルの精度・安全性・コストを評価する利用企業・開発者ROUGE/BLEU/BERTScore/LLM-as-judge
FMライフサイクル図
基盤モデル(FM)のライフサイクル

AIF-C01では「事前学習は莫大なコストがかかるため、通常は既存FMのAPIを活用する」という前提が頻出です。ゼロから事前学習するケースは非常に限定的であり、ほとんどの企業はファインチューニングやRAGでモデルを自社用途に適応させます。

トークン課金モデル

生成AIサービスの多くはトークン単位で課金されます。

  • 入力トークン（Input Tokens）: プロンプトのトークン数
  • 出力トークン（Output Tokens）: モデルが生成したテキストのトークン数

通常、出力トークンの方が入力トークンより高単価に設定されています。コスト最適化の観点では、不要なコンテキストを削除してプロンプトを短くし、出力を必要最低限に抑えることが有効です。

Amazon Bedrockでは On-demand（従量課金） と Provisioned Throughput（スループット確保） の2つの課金オプションがあります（2025年時点）。頻度の高い本番ワークロードではProvisioned Throughputがコスト面で有利な場合があります。また Batch Inference（バッチ推論） は非リアルタイムのまとめ処理に使用でき、On-demandより低コストで実行できます。

生成AIの利点（適応性・スケーラビリティ）

D2の試験問題では、生成AIが「なぜ・どのような場面で有用か」を問う問題も出題されます。

生成AIの主な利点

利点内容具体例
適応性（Adaptability）少ないタスク固有データでファインチューニングでき、さまざまな業務に転用可能カスタマーサポートBot・法律文書要約・コード生成
スケーラビリティ（Scalability）サーバーレス・マネージドAPIで需要に応じた自動スケーリングが可能同時接続数の急増にも対応
対話的インタラクション自然言語で人間と対話しながら段階的に結果を改善できるチャット形式での要件定義・文章推敲
コンテンツ生成の自動化文章・コード・画像の生成を自動化し、創造的作業を補助マーケティングコピー生成・テストコード自動生成
大規模データの理解長文ドキュメントをコンテキスト内で処理し、要点を抽出できる決算報告書の要約・契約書レビュー

生成AIが特に有効なユースケース

試験では「このユースケースに生成AIを使うべきか、従来のルールベースAIを使うべきか」という比較問題も出題されます。

生成AIは、入力パターンの多様性・自然言語処理の必要性・柔軟な応答が求められる場面で有効です。一方、単純なルール判定・高精度な数値計算・決定論的な結果が必須の場面では従来の機械学習や確定的アルゴリズムを選ぶべきです。

生成AIの限界（hallucination・非決定性・バイアス）

Hallucination（幻覚・誤情報生成）

生成AIの最重要な限界が Hallucination（ハルシネーション） です。モデルが事実と異なる情報を、あたかも正確であるかのように生成してしまう現象です。

Hallucination が発生する根本原因

LLMは「次のトークンとして統計的に最もらしいトークンを生成する」確率モデルです。「真実かどうか」ではなく「それらしさ」で出力が決まるため、自信を持って誤った情報を生成することがあります。これはモデルの欠陥ではなく、確率的生成という設計の本質的な特性です。

AIF-C01では、hallucinationへの対策手法として以下が出題されます。

対策手法説明
RAG（Retrieval-Augmented Generation）外部の信頼できる情報源を検索してコンテキストに追加し、モデルの回答根拠にする
Grounding（グラウンディング）生成された回答が提供したドキュメントに基づくものかを検証する
Human-in-the-loop重要な判断をAIだけに委ねず人間が確認・修正するプロセスを設ける
Temperature を下げる出力のランダム性を低くして、より保守的・決定論的な回答を促す
出力検証（Output Validation）生成された内容を別のモデルや外部ソースで検証する

非決定性（Non-determinism）

同じプロンプトを入力しても、毎回異なる出力が返ります。この性質を非決定性と呼びます。推論パラメータの Temperature（温度）で制御します。

  • Temperature = 0（または低い値）: 最も確率の高いトークンを毎回選ぶ（決定論的・再現性高）
  • Temperature 高: ランダム性が増し、多様で創造的な出力（再現性低）

本番システムで再現性が求められる場合はTemperatureを低く設定します。Top-p（nucleus sampling） も非決定性に影響する推論パラメータで、採用するトークンの累積確率上限を設定します。

バイアス（Bias）

事前学習データに偏りがあると、モデル出力にも同様の偏りが現れます。この現象をバイアスと呼びます。具体的には、特定の性別・人種・地域に対する偏った表現が出力されるケースも見られます。

バイアスの主な発生源は学習データの偏り（特定グループのデータが過多・過少）であり、完全な排除は困難です。バイアス検出・緩和には Amazon SageMaker Clarify が活用されます。詳細はVol4「責任あるAI」をご参照ください。

その他の限界

限界内容対策（概念）
解釈性の低さモデルがなぜその出力をしたかの根拠が不透明（ブラックボックス問題）説明可能AI（XAI）・SageMaker Clarify
コンテキスト長の制限コンテキスト長を超えた情報は処理できないチャンキング・RAG・要約
最新情報の欠如事前学習データのカットオフ日以降の情報は持たないRAGで最新ドキュメントを検索・追加
高コスト大規模モデルの推論は計算資源・コストが高いモデルサイズ選定・キャッシュ活用
セキュリティリスクプロンプトインジェクション・データ漏洩のリスクBedrock Guardrails・IAMポリシー

Agentic AI の概念（Agents・Orchestration）

Agentic AI（エージェント型AI） は、生成AIの最新トレンドであり、AIF-C01の2025年時点の試験ガイドに明記されています。

Agentic AI とは

従来の生成AIは「プロンプトを受け取り、1回の推論で返答を返す」静的な対話が主でした。Agentic AIは、AIエージェントが複数ステップのタスクを自律的に計画・実行します。

具体的には、ユーザーの依頼を受けてサブタスクに分解し、外部ツール（Web検索・コード実行・API呼び出し等）を利用し、その結果を評価して次のアクションを決定し、最終的な成果をユーザーに返します。このサイクルを人間の介入なしに繰り返せる点が「エージェント的」な特性です。

マルチエージェント（Multi-Agent）

複数のAIエージェントが協調してタスクを完遂する構成をマルチエージェントと呼びます。

  • Orchestrator（オーケストレーター）: 全体の計画を立て、サブエージェントへタスクを割り当てる
  • Sub-Agent（サブエージェント）: 担当タスクに特化して処理を行い、結果をOrchestratorに返す

マルチエージェント構成は複雑なワークフローの並列処理・専門分化に有効です。Amazon Bedrockでは、この構成をマネージドに実装できます（2025年時点）。

MCP（Model Context Protocol）

MCP（Model Context Protocol） は、AIエージェントと外部ツール・データソースを接続するための標準プロトコルです（2025年時点・オープンソース仕様）。MCPを使うと、エージェントがWebブラウザ・データベース・コードエディタなど多様なツールを標準化されたインタフェースで呼び出せます。AIF-C01の最新試験ガイドにも記載されているトピックです。

Memory Management（メモリ管理）

エージェントが長期的なタスクを実行する際、過去の会話・アクション結果を保持する仕組みがメモリ管理です。

  • Short-term Memory: 現在のセッション内の会話履歴（コンテキストウィンドウ内）
  • Long-term Memory: セッションをまたいで保持される知識・ユーザー設定（外部ストレージ）

Amazon Bedrock AgentCore はこのメモリ機能を含むエージェント基盤を提供します（2025年時点）。

AWS の Agentic AI サービス

サービス役割
Amazon Bedrock AgentsBedrockモデルを使ったAIエージェントの構築・実行環境
Bedrock AgentCoreエージェントランタイム・メモリ・ゲートウェイ・IDフェデレーションを提供するエージェント基盤（2025年時点）
Strands AgentsAWSが提供するオープンソースのエージェント構築SDKフレームワーク（2025年時点）
KiroAIエージェントを活用した開発者向けIDE。スペック駆動開発を支援（2025年時点）

AWS生成AIサービス（Bedrock/JumpStart/Amazon Q/PartyRock）

AIF-C01 D2の核心はAWSの生成AIサービスを用途別に整理することです。問題バンクでBedrockは268回出現しており、このサービスの理解が試験の合否を左右します。

Amazon Bedrock

Amazon BedrockはAIF-C01全体の中核サービスです。Anthropic（Claude）・Meta（Llama）・Mistral・Stability AIなど複数プロバイダーの基盤モデルをAPIでフルマネージド提供するサービスです。AWS インフラ上で動作するため、企業データが外部に送信されることなくセキュアな利用が可能です。

Amazon Bedrock の主要機能（AIF試験頻出）

  • モデル選択: 複数プロバイダーのFMをAPIで切り替えて利用できる（モデル選定はコスト・モダリティ・レイテンシ・言語対応で判断）
  • Knowledge Bases（RAG）: S3などのデータをベクトルDBに格納し、検索拡張生成（RAG）をマネージドに実装する
  • Agents: ツール呼び出しと複数ステップの推論を行うAIエージェントを構築・実行する
  • Guardrails: 有害コンテンツ・プロンプトインジェクション・個人情報の出力をフィルタリングする安全機構
  • Model Evaluation: 自動評価・人手評価でモデルの性能をデータドリブンに測定する
  • Fine-tuning / Continued Pre-training: 独自データでのモデルカスタマイズ（Bedrockマネージド環境内で実施）
  • Prompt Management: プロンプトのバージョニング・管理・A/Bテスト

Bedrockが提供するモデルはAmazon独自モデル（Amazon Novaシリーズ等） とサードパーティモデル（Claude/Llama/Mistral等） に大別されます。AIF-C01では「どのモデルがどのモダリティ・用途に対応しているか」という知識が問われます（2025年時点の情報を参照）。

SageMaker JumpStart

SageMaker JumpStartは、Hugging FaceなどのオープンソースFMをSageMakerエンドポイントにワンクリックでデプロイできるサービスです。

BedrockはマネージドなモデルをAPIで利用するのに対し、JumpStartは自分のAWSアカウント上のSageMakerインスタンスに独自デプロイする点が異なります。カスタマイズ性が高い反面、インフラ管理も伴います。

比較軸Amazon BedrockSageMaker JumpStart
管理レベルフルマネージド（インフラ管理不要）半マネージド（SageMakerインスタンス管理あり）
モデル取得元プロバイダーとのパートナーシップHugging Face等オープンソースモデル
カスタマイズFine-tuning/RAG/Guardrailsをマネージドで実施より低レベルなカスタマイズが可能
主なユーザー層アプリ開発者・非ML専門家MLエンジニア・データサイエンティスト

Amazon Q

Amazon Qは、AWSが提供するエンタープライズ向けAIアシスタントファミリーです。

サービス対象用途
Amazon Q Business社内ユーザー社内ドキュメント・データベースに接続したエンタープライズチャットボット。RAGベースで社内ナレッジを活用
Amazon Q Developer開発者コード生成・コードレビュー・バグ修正提案・AWSコンソール操作支援
Amazon Q in QuickSightビジネスユーザー自然言語でBI分析・ダッシュボード生成
Amazon Q in Connectコンタクトセンター担当者顧客問い合わせへのリアルタイム回答支援

AIF-C01では「コードの自動生成や開発者支援 → Amazon Q Developer」「社内ナレッジに基づく質問応答システム → Amazon Q Business」の使い分けが出題されます。

PartyRock（Amazon Bedrock Playground）

PartyRockは、コーディング不要でAIアプリを作成・共有できるBedrockベースのプレイグラウンドです。対象ユーザーはAI初学者・非エンジニアで、ブラウザから直感的にFMを試せます。試験対策上は「ノーコードでAIアプリを試す → PartyRock」というように整理すると覚えやすいです。

その他の生成AI関連AWSサービス

サービス用途
Amazon Quick自然言語でAWSリソースを検索・操作できるAWS管理コンソールのAIアシスタント（2025年時点）
AWS Trainium生成AIモデルの学習に特化したAWS独自アクセラレータチップ。大規模事前学習のコスト効率化に使用
AWS Inferentia生成AIモデルの推論に特化したAWS独自アクセラレータチップ。本番推論のコスト・レイテンシ最適化に使用
AWSサービスの使い分け早見（試験頻出）

  • マネージドFM API + RAG + Guardrails を使いたい → Amazon Bedrock
  • オープンソースFMを自社インスタンスにデプロイしたい → SageMaker JumpStart
  • 社内ドキュメントに基づく社内Q&Aシステムを作りたい → Amazon Q Business
  • 開発者のコーディング・AWS操作を支援したい → Amazon Q Developer
  • ノーコードでFMを試したい・プロトタイプしたい → PartyRock
  • 複数ステップのタスクを自律実行するエージェントを作りたい → Amazon Bedrock Agents

CertTrend LMS で400問チェック

本記事の D2「生成AIの基礎」で学んだ概念を、CertTrend LMS の AIF-C01 コース（400問）で実力確認しましょう。ドメイン別の学習モードで D2 の104問を集中演習し、定着度を確かめてください。


CertTrend LMS で400問チェック →

実務で深掘り — 生成AI本番運用記事

AIF-C01 D2で学んだ概念をさらに深く実装レベルで理解したい方は、以下の本番運用記事もご参照ください。試験対策（概念理解）→ 本番運用記事（実装詳細）の順で学習すると知識が定着します。

→ Amazon Bedrock 本番運用Vol2 — Amazon Q・データ自動化・カスタムモデル詳解
→ MLA-C01試験対策Vol3 — 生成AI実装（Bedrock/RAG/エージェント）深掘り版

AWSの最新記事8件