～ 生成 AI 時代の AWS スキルを証明する ～
目次
- はじめに：この資格の位置づけと学習戦略
- 試験概要と出題ドメイン
- ドメイン別 重要知識の整理
- 3.1 基盤モデルの活用と選定
- 3.2 プロンプトエンジニアリング
- 3.3 RAG（検索拡張生成）アーキテクチャ
- 3.4 ファインチューニングとモデルカスタマイズ
- 3.5 AI エージェントの開発
- 3.6 セキュリティと責任ある AI
- 3.7 AgentCore（新サービス）
- 実務で何ができるようになるか
- 学習方法と教材ガイド
- 試験直前チェックリスト
1. はじめに：この資格の位置づけと学習戦略
本ドキュメントは AWS Certified Generative AI Developer – Professional（通称 AIP）の試験対策用に作成したものです。
この資格で証明できること
この認定は、AWS 上で生成 AI アプリケーションを開発・最適化するスキルを証明するものです。2026 年現在、生成 AI の実務スキルを持つエンジニアへのニーズは急速に高まっており、この資格を取得することで「AWS の生成 AI スタックを実務レベルで扱えるエンジニア」として市場価値を明確に示すことができます。
学習の基本方針
アドバイス： この試験は「暗記」ではなく「理解」が問われます。各サービスが「なぜ必要か」「どんな課題を解決するか」を常に意識しながら学習を進めてください。
2. 試験概要と出題ドメイン
| 項目 | 内容 |
|---|---|
| 試験名 | AWS Certified Generative AI Developer – Professional |
| 正式開始 | 2026 年 4 月～（それ以前はベータ版） |
| 出題形式 | 選択式（単一選択・複数選択） |
| 試験時間 | 180 分 |
| 合格ライン | 750 点/1000 点（スケールドスコア） |
| 受験料 | 44,000 円（税込） |
主な出題ドメイン
| ドメイン | 主要テーマ |
|---|---|
| ドメイン 1 | 基盤モデルの選定と活用 |
| ドメイン 2 | プロンプトエンジニアリング |
| ドメイン 3 | RAG アーキテクチャの設計・構築 |
| ドメイン 4 | ファインチューニングとカスタマイズ |
| ドメイン 5 | AI エージェントの開発 |
| ドメイン 6 | セキュリティ・ガバナンス・責任ある AI |
3. ドメイン別 重要知識の整理
3.1 基盤モデルの活用と選定
★ 試験での出題ポイント
Amazon Bedrock を通じてアクセスできる基盤モデル（Foundation Model: FM）の特徴を理解し、ユースケースに応じて最適なモデルを選定できるかが問われます。
押さえるべきモデル一覧
| モデルファミリー | 提供元 | 主な特徴・得意分野 |
|---|---|---|
| Claude | Anthropic | 長文理解、論理的推論、安全性重視 |
| Titan | Amazon | テキスト生成、埋め込み（Embedding）、画像生成。AWS ネイティブ |
| Llama | Meta | オープンソース系、カスタマイズ性が高い |
| Mistral | Mistral AI | 軽量・高速、コスト効率が良い |
| Stable Diffusion | Stability AI | 画像生成に特化 |
| Command/Embed | Cohere | テキスト生成、埋め込みに強い |
選定の判断基準（試験頻出）
モデルを選定する際に考慮すべき要素：
- タスクの種類：テキスト生成、要約、コード生成、画像生成、埋め込み（Embedding）など
- 精度要件：高精度が必要か、ある程度で十分か
- レイテンシー要件：リアルタイム応答が必要か
- コスト：入力/出力トークン単価、推論コスト
- コンテキストウィンドウ：入力できるトークン数の上限
- マルチモーダル対応：テキスト＋画像の処理が必要か
試験テクニック： 「コスト最適化」と「精度」のトレードオフを問う問題が多く出ます。「最もコスト効率が良い方法は？」という問いでは、まず小さいモデルで試し、必要に応じてスケールアップする考え方が正解になりやすいです。
Amazon Bedrock の主要機能
| 機能 | 説明 |
|---|---|
| モデルアクセス | 複数プロバイダーの FM に API 経由でアクセス |
| プレイグラウンド | GUI 上でモデルを試せるテスト環境 |
| ナレッジベース | RAG 構築のためのマネージドサービス |
| エージェント | 外部ツール連携による自律的タスク実行 |
| ガードレール | 有害コンテンツのフィルタリング |
| モデル評価 | モデルのパフォーマンス比較機能 |
| カスタマイズ | ファインチューニング、継続事前学習 |
3.2 プロンプトエンジニアリング
★ 試験での出題ポイント
プロンプトの各手法の名前・特徴・使い分けが問われます。「この状況ではどのプロンプト手法が最適か？」という形式の問題が頻出です。
主要なプロンプト手法
Zero-shot プロンプティング
例示なしで指示のみを与える方法。モデルの事前知識に依存します。
以下のテキストを3行で要約してください：
[テキスト]
使いどころ：シンプルなタスク、モデルの一般能力で十分対応できる場合
Few-shot プロンプティング
いくつかの入力と出力の例を示してから、本題を与える方法。
レビュー：「この製品は素晴らしい！」→ 感情：ポジティブ
レビュー：「壊れていて使えない」→ 感情：ネガティブ
レビュー：「普通です」→ 感情：
使いどころ：特定のフォーマットや分類基準を守らせたい場合
Chain-of-Thought（CoT）プロンプティング
段階的な推論プロセスをモデルに踏ませる手法。「ステップバイステップで考えてください」などの指示を追加します。
問題：店に12個のリンゴがあり、8個売れ、その後5個入荷しました。
何個ありますか？ステップバイステップで考えてください。
使いどころ：数学的推論、論理的思考が必要な複雑なタスク
システムプロンプト
モデルの役割・制約・振る舞いを定義するプロンプト。ユーザーからは見えない部分です。
あなたはAWSの技術サポートエンジニアです。
AWSサービスに関する質問のみに回答してください。
回答は200文字以内にしてください。
使いどころ：一貫した応答品質を維持したいアプリケーション全般
プロンプト最適化のベストプラクティス
| プラクティス | 説明 |
|---|---|
| 具体的に指示する | 曖昧な指示は避け、出力形式・長さ・トーンを明示 |
| 区切り記号を使う | XML タグや区切り線で入力セクションを分離 |
| 反復的に改善する | 一度で完璧を目指さず、テストと修正を繰り返す |
| ネガティブ指示も活用 | 「〜しないでください」という制約も有効 |
| 温度パラメータの調整 | 低温度＝確定的、高温度＝創造的 |
推論パラメータ（試験頻出）
| パラメータ | 役割 | 値の影響 |
|---|---|---|
| Temperature | 出力のランダム性を制御 | 低い→正確で一貫性のある出力、高い→多様で創造的な出力 |
| Top P | 累積確率で候補トークンを制限 | 低い→保守的、高い→多様 |
| Top K | 上位 K 個の候補トークンから選択 | 小さい→保守的、大きい→多様 |
| Max Tokens | 出力の最大トークン数 | コストとレスポンス長に影響 |
| Stop Sequences | 生成を停止する文字列 | 出力フォーマットの制御に有用 |
試験テクニック： 「正確性が重要なタスク（コード生成、事実に基づく回答）」→ 低い Temperature 「創造性が重要なタスク（ブレスト、物語作成）」→ 高い Temperature この判断は頻出です。
3.3 RAG（検索拡張生成）アーキテクチャ
★ 試験での出題ポイント
RAG のアーキテクチャ構成、各コンポーネントの役割、ベクトルデータベースの選定が重点的に問われます。特に Amazon Bedrock ナレッジベースを使った構築パターンは最重要テーマの一つです。
RAG とは何か？
RAG（Retrieval-Augmented Generation：検索拡張生成）は、外部のデータソースから関連情報を検索し、その情報をコンテキストとして LLM に渡して回答を生成するアーキテクチャです。
LLM 単体の課題であるハルシネーション（もっともらしいが誤った回答）を軽減し、最新の社内データに基づいた正確な回答を実現します。
RAG のアーキテクチャ（処理フロー）
┌──────────────────────────────────────────────────────────────┐
│ RAG 処理フロー │
│ │
│ ユーザー質問 │
│ ↓ │
│ ① 質問をEmbeddingモデルでベクトル化 │
│ ↓ │
│ ② ベクトルDBで類似度検索（セマンティック検索） │
│ ↓ │
│ ③ 関連ドキュメント（チャンク）を取得 │
│ ↓ │
│ ④ 取得した情報 + 元の質問 をプロンプトに組み込む │
│ ↓ │
│ ⑤ LLM が回答を生成 │
│ ↓ │
│ ユーザーに回答 │
└──────────────────────────────────────────────────────────────┘
データ取り込みパイプライン（インジェスト）
┌──────────────────────────────────────────────────────────────┐
│ データ取り込みパイプライン │
│ │
│ データソース（S3, Webクローラー等） │
│ ↓ │
│ ① ドキュメントの読み込み・パース │
│ ↓ │
│ ② チャンキング（文書を小さな単位に分割） │
│ ↓ │
│ ③ Embeddingモデルでベクトル化 │
│ ↓ │
│ ④ ベクトルDBに格納 │
└──────────────────────────────────────────────────────────────┘
チャンキング戦略（試験頻出）
| 戦略 | 説明 | 適した場面 |
|---|---|---|
| 固定サイズ | 一定トークン数で機械的に分割 | シンプルで高速、汎用的 |
| セマンティック | 意味のまとまりで分割 | 意味の一貫性が重要な場合 |
| 階層的 | 親チャンクと子チャンクに分割 | 文脈の広さと詳細度の両方が必要な場合 |
| オーバーラップ付き | チャンク境界を重複させる | 情報の欠落を防ぎたい場合 |
試験テクニック： チャンクサイズが大きすぎる→ノイズが増え精度低下、コスト増 チャンクサイズが小さすぎる→文脈が失われ、意味のある回答ができない 「適切なチャンクサイズの選択」に関する問題が出ます。
ベクトルデータベースの選択肢
| サービス | 特徴 | 試験での位置づけ |
|---|---|---|
| Amazon OpenSearch Serverless | サーバーレス、フルテキスト＋ベクトル検索のハイブリッド | 最頻出。RAG 問題で最もよく登場 |
| Amazon Aurora PostgreSQL (pgvector) | RDB にベクトル検索を追加 | 既存の RDB を活用したい場合 |
| Amazon Neptune | グラフ DB＋ベクトル検索 | ナレッジグラフとの組み合わせ |
| Pinecone | サードパーティ、ベクトル検索特化 | Bedrock ナレッジベースから接続可能 |
| Redis Enterprise Cloud | 高速インメモリ＋ベクトル検索 | 低レイテンシー要件 |
Amazon Bedrock ナレッジベースの構成
Amazon Bedrock ナレッジベースは、上記の RAG パイプラインをマネージドで構築できるサービスです。
データソース対応：
- Amazon S3（最も一般的）
- Web クローラー
- Confluence
- SharePoint
- Salesforce
主要設定項目：
- Embedding モデルの選択（Titan Embedding 等）
- チャンキング戦略の選択
- ベクトル DB の選択
- メタデータフィルタリングの設定
試験テクニック： 「社内文書を使って正確な回答を返すチャットボットを構築したい」→ RAG（Bedrock ナレッジベース） が第一選択肢です。ファインチューニングではなく RAG を選ぶ理由（データの鮮度、コスト、実装の容易さ）を理解しておきましょう。
RAG vs ファインチューニング（超頻出の比較）
| 観点 | RAG | ファインチューニング |
|---|---|---|
| 目的 | 外部知識の参照による回答精度向上 | モデルの振る舞い・スタイルの変更 |
| データの鮮度 | リアルタイムで最新データを参照可能 | トレーニング時点のデータに依存 |
| コスト | 推論時のトークン増（コンテキスト付与分） | トレーニングコスト（GPU 時間）が必要 |
| 実装の複雑さ | 比較的シンプル（Bedrock ナレッジベース利用時） | データ準備・トレーニング・評価が必要 |
| 適したユースケース | 社内 FAQ、ナレッジ検索、最新情報の参照 | 特定のトーン・フォーマット、専門用語の習得 |
3.4 ファインチューニングとモデルカスタマイズ
★ 試験での出題ポイント
ファインチューニングの種類、用途、コストとトレードオフ、RAG との使い分けが問われます。
カスタマイズ手法の比較
| 手法 | コスト | 効果 | 適用場面 |
|---|---|---|---|
| プロンプトエンジニアリング | 最も低い | 限定的 | 最初に試すべき手法 |
| RAG | 中程度 | 知識の拡張に高い効果 | 外部知識の参照が必要な場合 |
| ファインチューニング | 高い | モデルの振る舞い変更に高い効果 | 特定ドメインの専門的タスク |
| 継続事前学習 | 最も高い | ドメイン知識の根本的な追加 | 新しい言語や専門分野の追加 |
試験テクニック： 問題文で「最もコスト効率が良い」「まず最初に」という表現があれば、 プロンプトエンジニアリング → RAG → ファインチューニング の順で検討するのが正解パターンです。
ファインチューニングのプロセス
- トレーニングデータの準備：JSONL 形式で入力 - 出力ペアを用意
- S3 にデータをアップロード
- Bedrock でカスタマイズジョブを作成
- モデルのトレーニング（プロビジョンドスループットが必要）
- カスタムモデルの評価
- デプロイ・利用
ファインチューニングを選ぶべき場面
- 特定の応答スタイルやトーンを学習させたい
- 業界固有の専門用語や略語を理解させたい
- 特定のフォーマット（JSON、XML など）で一貫した出力を得たい
- プロンプトエンジニアリングや RAG では十分な精度が出ない
3.5 AI エージェントの開発
★ 試験での出題ポイント
Amazon Bedrock Agents の仕組み、アクションとナレッジベースの統合、Lambda 関数との連携が問われます。
Amazon Bedrock Agents とは
Bedrock Agents は、LLM が外部 API やデータソースと対話しながら、複数ステップのタスクを自律的に実行する機能です。
エージェントの構成要素
| 要素 | 説明 |
|---|---|
| 基盤モデル | エージェントの「頭脳」となる LLM |
| 指示（Instructions） | エージェントの役割・制約を定義するプロンプト |
| アクショングループ | エージェントが実行できる外部操作（Lambda 関数で実装） |
| ナレッジベース | エージェントが参照できる社内データ（RAG） |
エージェントの動作フロー
ユーザーの質問
↓
エージェントが質問を分析（オーケストレーション）
↓
必要に応じてアクションを選択
├→ ナレッジベースに検索 → 関連情報を取得
├→ Lambda関数を呼び出し → 外部API/DB操作
└→ 追加の推論が必要 → 再度モデルに問い合わせ
↓
最終回答を生成してユーザーに返答
アクショングループの定義
アクショングループはOpenAPI スキーマで定義し、バックエンドの Lambda 関数と紐づけます。
# OpenAPI スキーマの例
paths:
/getOrderStatus:
get:
summary: "注文のステータスを取得する"
parameters:
- name: orderId
description: "注文ID"
required: true
試験テクニック： 「ユーザーの質問に応じて外部システムのデータを取得・更新したい」→ Bedrock Agents + アクショングループ（Lambda） が正解パターンです。
3.6 セキュリティと責任ある AI
★ 試験での出題ポイント
ガードレールの設定、データプライバシーの確保、IAM によるアクセス制御、有害コンテンツのフィルタリングが問われます。
Amazon Bedrock ガードレール
| 機能 | 説明 |
|---|---|
| コンテンツフィルター | 暴力・性的・差別的コンテンツの検出・ブロック |
| 拒否トピック | 特定のトピックへの回答を拒否 |
| ワードフィルター | 特定の単語やフレーズをブロック |
| PII（個人情報）検出 | 個人情報の検出・マスキング |
| コンテキストグラウンディング | ハルシネーション検出（ソースとの一致確認） |
セキュリティのベストプラクティス
- IAM による最小権限の原則：Bedrock のモデルアクセスを必要最小限に制限
- VPC エンドポイントの使用：インターネットを経由せず Bedrock にアクセス
- データの暗号化：保存時（KMS）・転送時（TLS）の暗号化
- CloudTrail による監査：API 呼び出しの記録
- モデル呼び出しログ：入出力のログ記録（S3/CloudWatch Logs）
責任ある AI の原則（試験で問われるポイント）
- 公平性：バイアスの検出と軽減
- 説明可能性：モデルの判断根拠を提示できること
- プライバシー：個人データの適切な取り扱い
- 安全性：有害な出力の防止
- 透明性：AI が生成した内容であることの開示
試験テクニック： 「PII を含む可能性のあるデータを LLM で処理する際、情報漏洩を防ぐには？」 → Bedrock ガードレール（PII 検出・マスキング） が正解です。
3.7 AgentCore（新サービス：2025 年発表）
★ 試験での出題ポイント
AgentCore は比較的新しいサービスのため、深い知識よりも基本的な位置づけと主要コンポーネントの理解が問われます。設問によっては「AgentCore が最適だが選択肢にない」ケースもあります。概要を押さえておけば十分対応できます。
AgentCore とは何か？
AgentCore は、「モデルを呼び出す」設計から「自律エージェントを運用する」設計へのシフトを支える、本番運用基盤のマネージドサービスです。
AgentCore 登場前は「LLM を呼び出してレスポンスを返す（＋RAG）」が主流でしたが、2025 年は「計画・実行・学習・自律動作するエージェント」を構築する方向へ根本的に変化しました。
POC から本番への「6 つの課題」
AgentCore は以下の課題を解決するために構築されました：
| 課題 | 説明 |
|---|---|
| ① 精度 | 実際のユーザーはデモ通りには動かない |
| ② スケーラビリティ | 多ユーザー・多ドメインへの対応 |
| ③ メモリ | ユーザー間・エージェント間の安全なメモリ管理 |
| ④ セキュリティ | 本番システムや実データへのアクセス制御 |
| ⑤ コスト | 推論トークンやホスティングコストの制御 |
| ⑥ 観測性 | エージェントの動作をリアルタイムで可視化 |
AgentCore の主要コンポーネント（7 つ）
| コンポーネント | 役割 |
|---|---|
| Runtime | 任意のフレームワーク（LangChain、Strands 等）・任意のモデル（Bedrock、OpenAI、Gemini 等）で動作するサーバーレスホスティング |
| Memory | セッション内の短期記憶とセッションをまたぐ長期記憶 |
| Gateway | 内部 API・Lambda・MCP サーバーを一元的に公開 |
| Identity | Okta・Entra ID・Cognito と連携したアクセス制御 |
| Policy | ツールコールをリアルタイムで制御（例：「100 ドル以上の取引を禁止」） |
| Browser/Code Interpreter | ウェブ閲覧や安全な分離環境でのコード実行 |
| Observability/Evaluations | エンドツーエンドのトレース可視化と品質評価 |
AgentCore 登場前後の変化（重要比較表）
| 観点 | 以前 | AgentCore 以降 |
|---|---|---|
| 観測性 | 後付け・自前実装 | Day 1・OpenTelemetry で自動トレース |
| ツール管理 | 個別実装 | MCP＋集中カタログ |
| セキュリティ | 静的 IAM のみ | リアルタイムポリシー制御（Cedar 言語に自動変換） |
| 品質保証 | 手動テスト | 継続的自動評価（マネージド） |
| 実行環境 | 共有環境 | マイクロ VM 分離 |
| スコープ | 単一 LLM 呼び出し | マルチエージェントアーキテクチャ |
9 つのベストプラクティス（試験対策要約）
| # | 原則 | ポイント |
|---|---|---|
| 1 | 小さく始めてスコープを定義 | 狭いユースケースで POC を作り、素早く改善を繰り返す |
| 2 | 初日から観測性を確立 | OpenTelemetry トレースを最初から設定 |
| 3 | ツールに明確な説明を付与 | ツールの名称・パラメータ・期待動作を曖昧なく定義 |
| 4 | マルチエージェントアーキテクチャ | 複数の専門エージェントを組み合わせ。MCP/A2A プロトコル対応 |
| 5 | ユーザー固有のメモリと ID 制御 | 企業認証基盤と連携し、ユーザーごとのメモリ分離を保証 |
| 6 | 計算には決定論的コードを使用 | LLM に数値計算させず、Code Interpreter で正確性を担保 |
| 7 | 継続的なテストと評価 | AgentCore Evaluations で本番動作を継続モニタリング |
Policy 機能の特徴（試験注目ポイント）
- ツールコールをリアルタイムでインターセプト
- 自然言語でポリシーを記述するとCedar（AWS のオープンソースポリシー言語）に自動変換
- エージェントが定義された境界内に収まることを保証
試験テクニック： 「エージェントのツール呼び出しに対してリアルタイムで制約を適用したい」→ AgentCore Policy を想起してください。 「エージェントの動作をトレースして問題を特定したい」→ AgentCore Observability（OpenTelemetry） です。
コスト管理に関する注意点
AgentCore 以降、エージェントの内部推論・ツールコール・反復的な改善がすべてトークンを消費するため、アーキテクチャの設計段階からコスト監視を組み込むことが必須となっています。これは試験でも問われるポイントです。
4. 実務で何ができるようになるか
この資格の学習を通じて、以下のような実務スキルが身につきます：
| 実務スキル | 使用する AWS サービス |
|---|---|
| 社内チャットボット・ナレッジ検索システムの構築 | Bedrock, ナレッジベース, OpenSearch Serverless |
| コード生成・要約・翻訳の業務自動化 | Bedrock（各種 FM）, Lambda |
| マルチモーダルアプリケーション（テキスト＋画像） | Bedrock（Claude, Titan Image 等） |
| AI エージェントによる複雑なワークフロー自動化 | Bedrock Agents, AgentCore, Lambda |
| 安全で信頼性の高い AI アプリケーションのデプロイ | ガードレール, IAM, KMS, CloudTrail |
これらを Lambda、S3、DynamoDB などの AWS サービス群と組み合わせて本番環境にデプロイする一連の流れを担えるようになります。
5. 学習方法と教材ガイド
推奨学習方法（優先度順）
第 1 位：AWS Skill Builder（最推奨）
AWS Skill Builder は、AWS が提供する公式オンライン学習プラットフォームです。 無料のコンテンツもありますが、サブスクリプション（月額 USD 31.90）で提供されています。
| コンテンツ | 料金 | 内容 |
|---|---|---|
| 公式模擬問題 | 有料 | 最大のメリット。解答解説が充実しており、間違えた選択肢もなぜその選択肢になったのかを理解できる |
| AWS SimuLearn | 有料 | 実際の AWS Management Console 環境でガイド付きラボを実施。実践経験を積める |
| Domain Review | 無料 | 試験範囲の解説。英語のみだが、生成 AI で日本語要約しながら進めると効果的。ボリューム大 |
| Domain Practice | 有料 | Official Bonus Questions として追加の模擬問題。英語コースだが模擬問題は日本語対応 |
アドバイス： 模擬問題は「正解を覚える」のではなく、すべての選択肢について「なぜ正解か／不正解か」を説明できるレベルを目指してください。これが最も効果的な学習法です。
第 2 位：生成 AI との壁打ち
生成 AI（ChatGPT、Claude 等）を活用した学習は非常に効果的です。
| 活用方法 | 具体例 |
|---|---|
| 概要を聞く | 「Amazon Bedrock ナレッジベースの仕組みを説明して」 |
| 問題集を作ってもらう | 「RAG に関する 4 択問題を 5 問作って、解説付きで」 |
| 疑問点を聞く | 「ファインチューニングと RAG の使い分けが分からない」 |
| サービスを深掘り | 「OpenSearch Serverless のベクトル検索の仕組みを詳しく」 |
| 比較を整理 | 「各ベクトル DB のメリットデメリットを表にして」 |
| 「なぜ必要か」を掘り下げ | 「なぜガードレールが本番環境で不可欠なのか」 |
第 3 位：関連書籍
- 正式な大手出版社からの対策テキストは2026 年 4 月時点で出ていない
- 個人発行のテキスト・問題集は質が不安定なため非推奨
- Bedrock についての書籍やAWS の AI に関する書籍は参考になる
アドバイス： 書籍は全部理解しようとしないこと。重要と思われる部分を重点的に理解し、他は流し読みや飛ばして、後で重要だと思ったら見返す程度にしましょう。
非推奨：ウェブ問題集（ブレインダンプサイト）
AWS の試験対策としてウェブ問題集サイトを勧める声もありますが、公式で「ブレインダンプ（問題流出サイト）」は受験ポリシー違反です。発覚した場合、資格の取消しや受験禁止の処分を受ける可能性があります。推奨しません。
学習スケジュールの目安
| フェーズ | 期間 | 内容 |
|---|---|---|
| Phase 1：基礎理解 | 1〜2 週間 | Domain Review で試験範囲の全体像を把握。生成 AI に概要を聞きながら進める |
| Phase 2：深掘り学習 | 2〜3 週間 | 各ドメインの重要テーマを掘り下げ。模擬問題を解き始める |
| Phase 3：弱点補強 | 1〜2 週間 | 模擬問題で間違えた分野を集中的に復習 |
| Phase 4：仕上げ | 1 週間 | 模擬問題の総仕上げ。時間配分の練習 |
6. 試験直前チェックリスト
試験前に以下の項目を確認してください。
サービス知識チェック
- ⬜︎ Amazon Bedrock の主要機能（モデルアクセス、ナレッジベース、エージェント、ガードレール）を説明できる
- ⬜︎ 主要な FM（Claude、Titan、Llama、Mistral）の特徴と使い分けを説明できる
- ⬜︎ RAG のアーキテクチャと処理フローを図示できる
- ⬜︎ チャンキング戦略の種類と使い分けを説明できる
- ⬜︎ ベクトルデータベースの選択肢と特徴を説明できる
- ⬜︎ プロンプトエンジニアリング手法（Zero-shot、Few-shot、CoT）を使い分けられる
- ⬜︎ 推論パラメータ（Temperature、Top P 等）の影響を説明できる
- ⬜︎ RAG とファインチューニングの使い分けを判断できる
- ⬜︎ Bedrock Agents の構成要素と動作フローを説明できる
- ⬜︎ ガードレールの各機能を説明できる
- ⬜︎ IAM、VPC エンドポイント、KMS 等のセキュリティ対策を説明できる
- ⬜︎ AgentCore の位置づけと主要コンポーネントを説明できる
- ⬜︎ AgentCore 登場前後のベストプラクティスの変化を説明できる
頻出パターンチェック
- ⬜︎ 「最もコスト効率が良い方法は？」→ まずプロンプトエンジニアリング → RAG → ファインチューニングの順
- ⬜︎ 「社内データを活用した正確な回答」→ RAG（Bedrock ナレッジベース）
- ⬜︎ 「外部 API と連携して自律的にタスク実行」→ Bedrock Agents（+ Lambda）
- ⬜︎ 「有害コンテンツの防止、PII 保護」→ Bedrock ガードレール
- ⬜︎ 「正確性重視のタスク」→ 低 Temperature
- ⬜︎ 「創造性重視のタスク」→ 高 Temperature
- ⬜︎ 「エージェントのリアルタイム制御」→ AgentCore Policy
- ⬜︎ 「観測性・トレース」→ OpenTelemetry / AgentCore Observability
最後に
最終メッセージ：
この試験で最も大切なのは、各サービスが「何の課題を解決するために存在するのか」を理解することです。暗記ではなく「なぜ？」を常に考えながら学習してください。
生成 AI は急速に進化する分野です。試験対策を通じて得た知識は、そのまま実務で活きるものばかりです。合格はゴールではなくスタートです。一緒に頑張りましょう！