先日、AWS Certified Generative AI Developer - Professional (AIP-C01) を受験し、769 点（合格ライン 750 点） で無事合格しました。
AWS All Cert2026の申請をする際にはすでにこの試験もGAされていましたが、AWS Certified Machine Learning - Specialty で代替できたので昨年度はまだ受験していませんでした。しかし、翌年はおそらく代替ができないと思いますので重い腰をあげて今回受験しました。
せっかくなので、勉強中に貯め込んだメモを 頻出レベルまで凝縮して、これから受ける方向けの体験記として残しておきます。
本記事は AWS 認定試験の NDA に配慮し、実際の設問は一切再現していません。AWS 公式ドキュメントで確認できる一般的な概念と、学習の勘所だけをまとめています。
はじめに
- 2025 年後半に Professional 系の新しい試験が追加され、その一つがこの Generative AI Developer - Professional です。
- この試験は Bedrock 前提の実装知識が広く問われるので、範囲が読みにくい。そこで 「よく問われる考え方」だけを絞って共有します。
この試験について
| 項目 | 内容 |
|---|---|
| 正式名称 | AWS Certified Generative AI Developer - Professional |
| 試験コード | AIP-C01 |
| レベル | Professional |
| スコア | 100〜1,000（合格 750） |
注意：Foundational の「AI Practitioner (AIF-C01)」とは別物です。名前が似ていますが、こちらは Amazon Bedrock を使った生成 AI アプリ開発を、設計・運用・最適化のレベルで問う Professional 試験。RAG、推論の最適化、スケーリング、可観測性、ガバナンスあたりが中心です。
私のバックグラウンド
- AWS の実務経験あり（全冠済み）
- 業務では Amazon Bedrock を含む生成 AI は全く触らない
勉強方法
- 模試を解く → 間違えた論点を「概念」に翻訳してメモ化
- 「この要件文なら答えはこれ」という 問われ方 → 答えの型 を作る
- 迷った論点は AWS 公式ドキュメント／試験ガイドで裏取り
MLS（前身）から何が変わったか｜AIP で新しく学ぶ領域
全冠クライテリア上、昨年までは AWS Certified Machine Learning - Specialty (MLS) でこの枠を代替できました。並びとしては MLS の後継に近い位置づけですが、問われるサービスはかなり別物です。ざっくり言うと、
- MLS：自分で「モデルを作る」世界。データ加工・特徴量・アルゴリズム選択・SageMaker での学習／チューニング／デプロイなど、古典的な ML ライフサイクルが中心。
- AIP：出来合いの基盤モデル（FM）を「使いこなす」世界。Amazon Bedrock を軸に、RAG・プロンプト・オーケストレーション・推論の最適化・ガードレール・評価／運用が中心。
| 観点 | MLS（前身） | AIP-C01（今回） |
|---|---|---|
| 主役サービス | SageMaker | Amazon Bedrock |
| モデルの扱い | 自分で学習・チューニング | 既存 FM を選定・利用 |
| データの勘所 | 特徴量エンジニアリング／前処理 | RAG／Knowledge Base／Chunking |
| 品質の作り方 | アルゴリズム・ハイパラ調整 | プロンプト設計・Grounding・評価 |
| スケール／コスト | エンドポイント・インスタンス | Cross-Region／Provisioned／Batch／Prompt Cache |
| 出力の信頼性 | モデル精度・メトリクス | Structured Outputs ＋ 決定論的検証 |
| 運用 | モデル監視・再学習 | Invocation Logging／Prompt 管理／ガバナンス |
そのため、MLS を持っている人でも AIP では以下の領域を新しく厚めに学ぶ必要がありました（後述の頻出ポイント番号に対応）。
- RAG の設計と診断（Retrieval と Generation の切り分け）
- Bedrock のオーケストレーション（Flows／Condition Node／Agent／Converse API）
- FM 推論の最適化とコスト設計（Cross-Region／Batch／Prompt Caching／Latency）
- 生成物の信頼性担保（Structured Outputs ＋ 決定論的検証、Grounding）
- 知識ベースの鮮度管理（S3 → SQS → Lambda での更新反映）
- FM の評価とガバナンス（Model Evaluation、Prompt Management ＋ CloudTrail ＋ Invocation Logging）
逆に、MLS で問われた古典的 ML の理論（アルゴリズムの数式、特徴量エンジニアリング、ハイパラ探索など）は、AIP ではほとんど問われません。「モデルを作る」から「FM を使って良いアプリを設計・運用する」へ頭を切り替えるのが、最初にして最大のコツでした。
頻出ポイント（本題）
1. RAG の不調は「Retrieval」と「Generation」を分けて診断
同じ質問なのに、時々正確・時々幻覚。こういう時は、いきなり対策せず原因を分離します。
- 取得文書を固定して回答が揺れる → Generation / Prompt 側
- Prompt を固定して取得文書が揺れる → Retrieval 側
引っかけ：「Temperature を上げる」「Vector DB をいきなりスケール」は原因分離になっていないので誤り。
2. 正しい文書でも幻覚するなら Contextual Grounding
文書は正しく取れているのに、文書にないことを言う。これは Retrieval の問題ではありません。
- 第一候補は Contextual Grounding
- Prompt で「提供された Context だけを根拠に」「根拠がなければ不明と答える」を明示
覚え方：取れていない → Retrieval 改善／取れているのに嘘 → Grounding 改善。
3. Knowledge Base の更新反映は S3 → SQS → Lambda
S3 が Data Source で、追加・更新・削除を「できるだけ早く」「イベント駆動で」反映したい、という要件の定番構成。
S3 (Object Created / Deleted)
→ S3 Event Notification
→ SQS
→ Lambda
→ Knowledge Base の Ingest / Delete
SQS を挟む理由は、ピーク吸収・リトライ・疎結合・耐障害性。文書単位なら IngestKnowledgeBaseDocuments / DeleteKnowledgeBaseDocuments も選択肢。
4. Prompt の連携は Bedrock Flows / Condition Node
複数 Prompt を順番につなぎ、条件分岐もしたい。コードは最小化したい。→ Bedrock Flows、分岐は Condition Node。
役割の区別が頻出です。
- Prompt を線でつなぐ → Bedrock Flows
- AWS のワークフローを厳密に管理（リトライ・承認など）→ Step Functions
- LLM に動的に Tool を選ばせる → Agent
5. Converse API：system / messages / content を使い分ける
- システム指示 →
system - 過去の user / assistant 会話 →
messages - 画像などマルチモーダル →
messages[].content[]の content block
モデルを変えても会話コードを大きく変えたくない → Converse。モデル固有のリクエスト形式が必要 → InvokeModel。ストリーミングは ConverseStream。
6. Structured Outputs は「形式」保証、値の正しさは別
金利や予測値など、数値の妥当性が要る場面。Structured Outputs は JSON Schema に従わせる機能で、値が正しいことは保証しません。
FM → Structured Output → アプリ側で決定論的に検証 → Business Rule → 顧客
引っかけ：「Temperature を 0 にすれば数値が正しくなる」は誤り。
7. 回答が毎回変わるなら推論パラメータ
Prompt は同じなのに回答がブレる。→ Temperature / Top P / Max Tokens を疑う。低いほど決定的、高いほどランダム。「一貫性を上げたいから Temperature を上げる」は逆なので注意。
8. スケーリングは Cross-Region Inference か Provisioned Throughput
- 予測不能な Burst ＋ 固定費を避けたい → Cross-Region Inference
- 安定した高負荷で容量を確保したい → Provisioned Throughput
「アイドル容量の固定費を避けたい」が Cross-Region の強いヒント。SDK のリトライだけでは継続的な容量不足は解決しない、という点も頻出。
9. 大量・非同期・即時性不要は Batch Inference
数千件を夜間にまとめて処理、即時性は不要。1 件ずつ API を叩かず Batch Inference（入力 S3 → ジョブ → 出力 S3）。
引っかけ：Prompt Caching と混同しない。同じ長い Context をリアルタイムに繰り返すなら Prompt Caching、大量非同期なら Batch。Batch と Prompt Caching を安易にセットで語らないこと。
10. Latency は「測ってから」：層ごとに分解
「変える前に、どこが遅いか特定したい」が定番。層ごとにメトリクスを分解します。
| 層 | 見る指標 |
|---|---|
| API Gateway | Latency / IntegrationLatency |
| ECS | CPU / Memory / Task 使用率 |
| Lambda | Duration / Cold Start |
| Bedrock | InvocationLatency / InvocationThrottles |
| モデル生成 | Output Tokens / トークン生成速度 |
原則は Measure → Isolate → Optimize。まず速くユーザーに返したいなら ConverseStream で TTFT を改善。
11. 長文対策：CountTokens と Chunk → Process → Aggregate
- 推論前にトークン上限を確認したい → CountTokens
- Context Window を超える長文 → 分割（Chunk）→ 個別処理 → 最終統合
「超過する全文を 1 リクエストで送る」は誤り。
12. モデル選定は Model Evaluation でベンチマーク
「本番モデルを主観を減らして選びたい」→ 自動の Model Evaluation（固定 Prompt Dataset ＋ 同じ Metric ＋ 同条件で比較）。LLM-as-a-judge や Human 評価もある。RAG は Retrieval と Generation を分けて評価するのが基本。
13. ガバナンスはログの役割分担
| 監査したいもの | サービス |
|---|---|
| Prompt 本文・バージョン | Prompt Management |
| AWS の API 操作（誰が変更したか） | CloudTrail |
| モデルの入出力 | Model Invocation Logging |
| ランタイムのメトリクス | CloudWatch |
おまけ：同期 / 非同期の即答表
| 要件文 | 答え |
|---|---|
| ユーザーが待っている / Interactive chat | 同期（必要ならストリーミング） |
| 夜間の大量処理 | 非同期 / Batch |
| 低優先度の推薦（類似・トレンド等） | 非同期 / 後追い更新 |
| Traffic burst を吸収 | キュー（SQS） |
Latency 最優先なら、必須処理だけを同期にして Critical Path を短くする。
まとめ
-
Generative AI Developer - Professional は、サービス名の暗記よりも 「その要件をどのレイヤーで解くか」 の判断が問われる試験でした。
-
私のように業務で Bedrock を触っていなくても、AWS の設計思想（まず測る／原因を分離する／適切なレイヤーで解く） が身についていれば十分解けました。
- MLS 取得者なら、生成 AI ネイティブな領域を上乗せする感覚で臨むとよいと思います。これから受ける方の参考になれば嬉しいです。
- セキュリティ・ガバナンス関連はAWSのLog設計を知っていれば新しく知識を導入しなくても解けました。
新設試験もあわせて取得できたので、来年も全冠を維持できそう。引き続き頑張ります。
参考
解いていたudemy試験:AWS 認定 Generative AI Developer Professional（AIP-C01）試験対策問題集
本ブログに掲載している内容は、私個人の見解であり、所属する組織の立場や戦略、意見を代表するものではありません。
また、AWS 認定試験の機密保持ポリシー（NDA）に配慮し、実際の試験問題は含めていません。記載は AWS 公式ドキュメントで確認できる一般的な内容に基づく学習ポイントです。