はじめに
AWS Certified Generative AI Developer - Professional試験対策、意外とタフ。対策の中で学んだことをまとめる。
（※注記）個人の学習中のメモであり、合格を保証するものではない。表中のサービス選定は AWS の公式ドキュメント・公開ブログで語られているベストプラクティスを自分用に並べ直したもので、特定の試験問題の正解を示すものではない。
3つの原則
原則1: AWS の引き出しを開けてから書く
原則2: サービスの得意領域とワークロードを揃える
原則3: 部品の依存と順序を読む
原則1は、自前で書く前に組み込み機能を探す。Lambda でラップして共通処理を入れたくなる場面で、IAM 条件キーやサービスのパラメータで AWS 側に同じことをやらせる仕組みがある。
原則2は、サービスを「キャッチコピー」で選ばない。機能だけでなく課金モデルとワークロードの整合まで見ないと、低頻度ワークロードや特殊な要件で外れる。
原則3は、コンポーネント間の関係を読む。順序、バッファ、依存。検証ステップは生成の後に来る。サービス名で役割を連想すると外す。
チートシート
| 要件カテゴリ | 主な候補 | 分岐ロジック |
|---|---|---|
| ベクトルストア | OpenSearch / Amazon S3 Vectors(2025 GA) / RDS pgvector | 常時の高 QPS なら OpenSearch、低頻度・大規模なら S3 Vectors、メタデータでの SQL 結合が要るなら pgvector |
| 推論スループット強化 | プロビジョンドスループット / クロスリージョン推論(CRI) | 常態として高負荷ならプロビジョンド、一時的なピーク対策なら CRI |
| 推論呼び出しの制御 | API パラメータ / Bedrock Guardrails | 出力フォーマット制御(停止条件・最大長など)はパラメータ、不適切内容ブロックや根拠検証は Guardrails |
| Bedrock 利用の強制 | IAM 条件キー(bedrock:GuardrailIdentifier / bedrock:FoundationModelIdentifier 等) |
ガードレール経由の呼び出しを強制するなら GuardrailIdentifier、利用可能モデルを限定するなら FoundationModelIdentifier |
| ログ・監査 + 長期保管 | CloudTrail / CloudWatch Logs / Bedrock モデル呼び出しログ + S3 Object Lock | API メタは CloudTrail、処理内部は CloudWatch Logs、プロンプトと応答の実内容はモデル呼び出しログ。N 年保管・改ざん防止は S3 Object Lock のコンプライアンスモード併用(出力先バケットのバージョニング有効化と Bedrock からの書き込み権限を確認) |
| PII 処理 | Macie / Comprehend / Bedrock Guardrails | 保存済みデータの検出・通知は Macie、データレイク取り込み前のバッチ変換・マスキングは Comprehend、推論時(入出力)のリアルタイム検出・マスキング・ブロックは Guardrails |
| プロンプト管理 | Bedrock Prompt Management / Git + 自前管理 | バージョン管理と承認フローを組み込みで欲しいなら Prompt Management、軽量で良いなら Git |
| エージェント実装 | Amazon Bedrock Agents / Bedrock AgentCore Runtime / 自前コンテナ(ECS など) | 事前定義のアクション・ナレッジベース呼び出しなど Bedrock 内で完結するなら Agents、HTTP サーバー設定やコンテナ化までマネージドにしたいなら AgentCore Runtime、既存基盤統合や自由度重視なら自前コンテナ |
よく混同するペア
兄弟サービスの取り違えで外す場面が多い。3つだけ書いておく。
Macie と Comprehend と Guardrails：処理タイミングで分ける
Macie は S3 内の PII を検出して通知する監査用。データを書き換える機能はない。Comprehend はバッチ・前処理で PII を伏字にする変換用（データレイク取り込み前など）。Bedrock Guardrails は推論時の入出力に対してリアルタイムにマスキング（ANONYMIZE）またはブロックを行う。「保存済みデータの監査／取り込み前の変換／推論時のリアルタイム制御」のどのタイミングが要件かで使い分ける。
OpenSearch と S3 Vectors：稼働パターンで決まる
OpenSearch は OCU の常時課金で、高 QPS なワークロードでは性能・コスト両面で有利。検索頻度が低い大規模ベクトルだと割高になり、従量課金の S3 Vectors に分がある。「ベクトル検索」をどの稼働パターンで使うかで分かれる。
CloudTrail とサービス固有ログ：粒度を読み分ける
CloudTrail は API メタデータの監査で、「ナレッジベースが呼ばれた」ことは分かるが「どのドキュメントが取り込みに失敗したか」は記録しない。処理の内部状態が必要なら、サービスが CloudWatch Logs に出すログを見る。プロンプトとモデル応答の実内容を残したいなら、Bedrock のモデル呼び出しログを使う。「監査」が指している粒度を最初に確認する。
4 択で迷ったときの当てはめ順
原則の番号順にそのまま当てはめる。
- 選択肢に「自前で実装」「Lambda でラップ」「定期スケジュールで〜」が含まれる → 原則1で切る
- 残った候補が要件のワークロード特性(頻度・サイズ・レイテンシ)と合うか → 原則2で確認
- 順序や接続が絡む問題 → 原則3でデータの流れを追う