1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@Tacitus

AWS Certified Generative AI Developer - Professional 試験で問われる「どれを選ぶか」を全タスク・全ドメインまとめた受験ノート

1
Last updated at Posted at 2026-05-31

初版のため内容の甘いところがあります。随時更新していきます。

受験までの流れ

  1. Official Practice Question Set AWS Certified Generative AI Developer - Professional (AIP-C01 - 日本語) で問題内容のイメージをつかんだ
  2. 以下の試験ガイドをもとに Claude で知識をインプットした（本記事はその出力をベースに整理したもの）
    https://d1.awsstatic.com/onedam/marketing-channels/website/aws/ja_JP/certification/approved/pdfs/docs-aip/AWS-Certified-Generative-AI-Developer-Pro_Exam-Guide.pdf
  3. Udemy の AWS 認定 AWS Generative AI Developer - Professional 模擬問題集 を受講
  4. Official Pretest AWS Certified Generative AI Developer - Professional (AIP-C01 - 日本語) を受講

→ 合格

わからないところは常に Claude に問いかけ、壁打ちを繰り返しながら理解を深めた。
「なぜこのサービスを選ぶのか」「このシナリオでは何が優先されるのか」といった問いを Claude にぶつけ、
対話の中で腑に落ちるまで掘り下げていった。

Claude とともに歩んで、合格できた。

試験ガイド: AWS Certified Generative AI Developer - Professional

各タスクを「試験で問われる判断パターン」「読むべき公式ドキュメント（何を確認するか）」「迷いやすい比較ポイント」のセットで記載。

ドメイン構成（出題比率）

ドメイン 内容 比率
Domain 1 FM統合・データ管理・コンプライアンス 31%
Domain 2 実装と統合 26%
Domain 3 AIの安全性・セキュリティ・ガバナンス 20%
Domain 4 運用効率と最適化 12%
Domain 5 テスト・検証・トラブルシューティング 11%

Domain 1 + 2 だけで出題の 57% を占める。まずここに集中する。

Domain 1: FM統合・データ管理・コンプライアンス（31%）

Task 1.1 ｜ 要件を分析してGenAIソリューションを設計する

試験で問われる判断パターン

  • 「ドメイン知識を持たせたい」→ RAG / Fine-tuning / プロンプトエンジニアリング / CPT のどれを選ぶか

    • 「情報が頻繁に更新される」「引用元を提示したい」「社内ドキュメントを参照させたい」→ RAG（モデルは変えず、外部から都度知識を注入）
    • 「特定の文体・出力フォーマット・専門用語を一貫して再現させたい」→ Fine-tuning（少量のQ&Aペアでモデルの振る舞いを矯正）
    • 「ドメイン固有の膨大な非ラベルテキスト（医療文献・法律文書等）で基礎知識ごと与えたい」→ Continued Pre-training（大量データ・高コスト・モデル全体の再学習）
    • 「数件の例示で十分カバーできる」→ プロンプトエンジニアリング（Few-shot・CoTで最も低コスト）
    • 判別軸：データ更新頻度／必要データ量／コスト／引用可否

  • 「レイテンシ重視 / バッチ処理 / 安定運用」→ オンデマンド・Provisioned Throughput・Batch API のどれか

    • 「ユーザー対話で即応必須・トラフィックが予測不能」→ オンデマンド（従量課金・スロットリングあり）
    • 「夜間に数万件のドキュメント要約をまとめて処理」→ Batch API（最大50%安・非同期・S3入出力）
    • 「高頻度かつ予測可能な常時トラフィック」→ Provisioned Throughput（モデルユニットを月／半年単位で予約・スロットリングなし）
    • 判別軸：応答時間要件／トラフィックパターン／コスト

  • 「コンテキストが長大なPDFを処理したい」→ どのモデルを選ぶか（コンテキスト長の観点）

    • モデルごとに最大入力トークン数（コンテキストウィンドウ）が異なる（例：Claude系は200K前後、軽量モデルは数K〜数十K）
    • 文書全体を一度に渡したい → 長コンテキスト対応モデル（Claude Sonnet/Opus等）を選択
    • 長すぎてコストが膨らむ場合 → RAGで分割検索して必要箇所だけ渡す代替案を検討
    • 判別軸：入力サイズ／コスト／要約精度

読むべき公式ドキュメント

ページ 確認すべきポイント
Amazon Bedrockとは 左ナビで全機能（KB・Agents・Guardrails・Flows・Fine-tuning等）の一覧を把握
RAG・Fine-tuning・プロンプトエンジニアリングの使い分け 3手法の使い分け判断基準を図で理解する
マネージドRAG vs カスタムRAG の選択 ==Bedrock KBを使う場合と、OpenSearch自作の場合の選択基準==
サポートされているFMモデル一覧 モデルのコンテキスト長・モダリティ・Fine-tuning対応可否の比較表
AWS Well-Architected Framework 6本柱（運用上の優秀性・セキュリティ・信頼性・パフォーマンス効率・コスト最適化・持続可能性）の観点
Generative AI Lens（Well-Architected） GenAI固有の設計ベストプラクティス。試験ではアーキテクチャ妥当性の根拠として登場

Task 1.2 ｜ FMを選定して設定する

試験で問われる判断パターン

  • モデル選定問題：要件からFMを選ぶ

    • 「予算が厳しい・低レイテンシ重視」→ 小型モデル（Claude Haiku / Nova Micro / Llama 8B 等）
    • 「高精度・複雑な推論が必要」→ 大型モデル（Claude Sonnet・Opus / Nova Pro 等）
    • 「画像も入力に含めたい」→ マルチモーダル対応モデル（Claude 3系・Nova 系）
    • 「日本語含む多言語処理」→ 多言語対応モデル（Claude / Cohere Command-R 等）
    • 判別軸：コスト × レイテンシ × 精度 × コンテキスト長 × モダリティ × 言語

  • API選定問題：Converse API か InvokeModel API か

    • 「チャット・複数ターン対話・ツールユース・モデル差し替え」→ Converse API（モデル横断で統一フォーマット、messages配列でメンテ容易）
    • 「特殊なモデル固有パラメータが必要」「ConverseがまだサポートしないFM」→ InvokeModel API（モデル個別のリクエスト形式）
    • 判別軸：マルチターン会話の有無／ツールユース要件／モデル切替の頻度

  • スループット問題：オンデマンド か Provisioned Throughput か

    • 「バースト的・予測不能なトラフィック」→ オンデマンド（従量課金）
    • 「常時高トラフィック・スロットリング回避必須・コスト予測したい」→ Provisioned Throughput（モデルユニットを1か月／6か月でコミット）
    • 判別軸：トラフィックの安定性／コスト予測性／SLA要件

  • モデル差し替え柔軟性：「コード変更なしにモデルを切り替えたい」

    • Lambda 内にモデルIDをハードコードすると、変更のたびにデプロイが必要
    • AWS AppConfig にモデルID・プロンプトテンプレート等を外部設定として保管 → Lambda が起動時に取得 → コードデプロイなしで切替可能
    • 段階的ロールアウト・即時ロールバックにも有効

  • 可用性・耐障害性：「リージョン障害でも継続したい」

    • Bedrock クロスリージョン推論プロファイル：単一リージョンで容量・モデル可用性が足りないときに別リージョンへ自動ルーティング（最も簡単な耐障害化）
    • Step Functions サーキットブレーカー：連続失敗時に呼び出しを遮断して大量エラーを防ぐ
    • グレースフルデグラデーション：高精度モデル失敗時に小型モデルへフォールバックして応答継続
    • 判別軸：障害発生時に「機能停止」「精度低下で継続」「自動フェイルオーバー」のどれを許容するか

  • カスタムモデル運用：「ドメイン特化FT済モデルを安全にデプロイ・ロールバックしたい」

    • SageMaker Model Registry でバージョン管理・承認状態管理・ステージング/本番昇格
    • CodePipeline + CodeBuild で自動デプロイ・自動テスト
    • 失敗時は Registry で旧バージョンに即ロールバック
    • 判別軸：バージョニング要件／承認フロー／監査要件

読むべき公式ドキュメント

ページ 確認すべきポイント
サポートされているFMモデル一覧 プロバイダー別の機能比較表。コンテキスト長・マルチモーダル対応・Fine-tuning可否
Converse API マルチターン会話・ツールユースに統一的に対応するAPIの特徴と利点
InvokeModel API モデル固有のリクエスト形式が必要なケース。ConverseAPIとの使い分け
Provisioned Throughput PTの設定単位（モデルユニット）・コミット期間（1か月/6か月）と、オンデマンドとのコスト比較
Bedrock クロスリージョン推論 単一リージョンで容量・モデル可用性が限られる場合の自動ルーティング。耐障害性設計の中核
AWS AppConfig 動的構成でモデルID・プロンプトテンプレート等をコードデプロイなしに切替
SageMaker Model Registry カスタムモデルのバージョニング・承認状態管理・デプロイ／ロールバックのライフサイクル

Task 1.3 ｜ FM消費のためのデータ検証・処理パイプラインを実装する

試験で問われる判断パターン

  • PII除去に使うサービス：Comprehend か Macie か

    • 「FMに入力する文字列の中からリアルタイムにPIIを検出・マスクしたい」→ Amazon Comprehend（DetectPiiEntities API、パイプライン処理向き）
    • 「S3バケット内のファイル全体をスキャンして機密データの所在を把握したい」→ ==Amazon Macie==（ガバナンス・監査・棚卸し向き、リアルタイム処理は不向き）
    • 判別軸：処理対象（テキスト文字列 vs S3ファイル）／処理タイミング（推論時 vs 定期スキャン）

  • データ取り込み経路：ETL か ストリームか

    • 「S3間で大量データを変換・結合してKB用に整形」→ AWS Glue（サーバーレスETL、データカタログ統合）
    • 「ログやイベントをリアルタイムで取り込みたい」→ Amazon Kinesis（ストリーミング）
    • 「Knowledge Base 取り込み時に独自パース処理が必要（HTML特殊形式・社内独自フォーマット等）」→ Lambda カスタム変換を KB データソースに登録

  • データ品質検証：「FM投入前に欠損・型崩れを自動チェックしたい」

    • 「ETLパイプラインに統合してルールベースでチェック」→ ==AWS Glue Data Quality==（欠損・重複・統計外れ値・カスタムルール）
    • 「データサイエンティストがGUIで探索しながらクレンジング」→ ==SageMaker Data Wrangler==
    • 「軽量な前処理チェックをLambdaで実施し、結果を可視化」→ Lambda + CloudWatch カスタムメトリクス
    • 判別軸：チェックの自動度・運用者スキル・処理規模

  • マルチモーダル前処理：データ種別ごとのサービス選定

    • 「音声 → テキスト」→ AWS Transcribe（会議録・コールセンター録音の文字起こし）
    • 「スキャンPDF・画像 → テキスト/表/フォーム抽出」→ Amazon Textract
    • 「画像分類・物体検出」→ Amazon Rekognition
    • 「PDF/画像/動画/音声を一気通貫で抽出」→ ==Bedrock Data Automation==（Textract・Transcribeを内部で組み合わせる新サービス、自前で組む代替）
    • 「巨大なバッチ前処理ジョブ」→ ==SageMaker Processing==

  • FM入力フォーマット：呼び出し先ごとの形式

    • Bedrock InvokeModel → モデル固有のJSON（Anthropic 形式 / Cohere 形式 等）
    • Bedrock Converse API → 統一の messages 配列（role: user/assistant）
    • SageMaker エンドポイント → コンテナの定義に従った構造化JSON
    • 対話アプリ → 会話履歴を含む messages 形式が必須（履歴保持には DynamoDB を併用）

読むべき公式ドキュメント

ページ 確認すべきポイント
Knowledge Base - データソースとS3設定 対応データソース形式（PDF・HTML・CSV・Confluence・Salesforce等）
データ取り込みのカスタマイズ（Lambdaパーサー） Lambda関数を使った独自パーシングロジックの統合方法
Bedrock Data Automation PDF・画像・動画・音声からの情報抽出を自動化する新機能。Textract・Transcribeを個別に組む代替手段
Amazon Comprehend - PII検出 PIIエンティティ種別（氏名・メール・クレカ番号等）の検出とマスキングの仕組み
AWS Glue - ETLパイプライン S3間のデータ加工・変換パイプライン構成とデータカタログ
AWS Glue Data Quality データの欠損・重複・統計外れ値を自動検出するルールセット定義。KB取り込み前のゲート
SageMaker Data Wrangler GUIによるデータ探索・クレンジング・特徴量生成。FT用データ準備に有効
SageMaker Processing 大規模なバッチ前処理ジョブ。マルチモーダル前処理に利用
AWS Transcribe 音声→テキスト変換。会議録FMパイプラインに利用
Amazon Textract スキャンPDF・画像からのテキスト・表・フォーム抽出。Data Automationが内部で利用

Task 1.4 ｜ ベクターストアソリューションを設計・実装する

試験で問われる判断パターン

  • ベクターDB選定：要件からストアを選ぶ

    • 「とにかく早く立ち上げたい・運用負荷を最小化したい」→ Bedrock Knowledge Base + OpenSearch Serverless（マネージド構成、デフォルト最有力）
    • 「BM25（キーワードの一致頻度や文書の長さを考慮した従来型の全文検索アルゴリズム）と組み合わせたハイブリッド検索（意味的な類似度で探すベクター検索と、キーワードの一致で探すBM25検索を両方同時に使う検索方式）、シャード調整（データを複数の小さな塊に分割して並列処理するときの、その塊の数やサイズの設定変更）、独自スコアリング（検索結果の並び順を決めるスコアの計算ロジックをカスタマイズすること）が必要」→ OpenSearch（プロビジョン）
    • 「既存の Aurora PostgreSQL にベクター検索を追加したい・トランザクションと一緒に扱いたい」→ Aurora pgvector
    • 「ミリ秒オーダーの超低レイテンシが必要」→ Redis（MemoryDB / ElastiCache）
    • 「既に Pinecone / MongoDB を使っている」→ そのまま外部マネージドを継続
    • 判別軸：運用負荷／検索カスタマイズ要件／既存DB資産／レイテンシSLA

  • インデックスアルゴリズム選定：HNSW / IVF / Flat

    • HNSW（Hierarchical Navigable Small World）：高精度・高速だがメモリ大。中〜大規模で最も一般的
    • IVF（Inverted File）：超大規模データ向き。クラスタ単位に分割しメモリ効率良いが精度はHNSWに劣る
    • Flat：全件総当たり。小規模・完全一致重視。精度100%だが遅い
    • 判別軸：データ件数／メモリ予算／求めるRecall

  • エンべディングモデル選定

    • 「日英など多言語混在文書を扱う」→ Cohere Multilingual Embeddings や Titan Text Embeddings V2（多言語対応）
    • 「コスト最優先・英語中心」→ Titan の小次元（256/512）モデル
    • 「ドメイン特化（医療・法律）」→ ドメイン特化埋め込み or 必要に応じてカスタム学習
    • 判別軸：言語サポート／次元数 vs コスト／ドメイン適合性

  • メタデータ設計：「検索精度を上げるために何を付与するか」

    • タイムスタンプ：「最新情報のみ」フィルタや時系列ランキングに利用（S3 LastModified + カスタム属性）
    • 著者・部署・所属：アクセス制御（部署外には見せない等）と検索フィルタを同時に実現
    • ドメインタグ：「製品マニュアル」「契約書」「議事録」等で検索範囲を絞る
    • 機密度ラベル：Guardrails や Lake Formation と連携して閲覧権限を制御
    • 付与方法：S3 オブジェクトのカスタムメタデータ（x-amz-meta-*）／KB のメタデータ JSON ファイル

  • 大規模スケール：「数億ベクトル規模」

    • OpenSearch シャーディング戦略：プライマリ／レプリカ数、シャードサイズの目安を計算（1シャード10〜50GB目安）
      • プライマリ：データを実際に保存する本体のシャード（塊）。プライマリ数を増やすほど並列処理が可能になる
      • レプリカ：プライマリのコピー（バックアップ）。障害時の冗長性確保と読み取りの負荷分散に使われる
      • シャード数の計算式：総データ量 ÷ 1シャードのサイズ = プライマリ数、プライマリ数 × (1 + レプリカ数) = 合計シャード数
      • 例：300GB・1シャード30GB・レプリカ1の場合 → プライマリ10、合計シャード20（本体10＋コピー10）
      • シャードが小さすぎると管理オーバーヘッド増、大きすぎると障害時の影響が大きくなるため10〜50GBが目安
    • ドメイン特化マルチインデックス：「製品ごと」「言語ごと」等で別インデックスに分けて検索範囲を絞る
    • 階層型インデックス：粗い検索 → 細かい検索の2段構成で計算量を削減

  • データ鮮度：「KB側を常に最新に保ちたい」

    • 増分更新：S3 イベント → EventBridge → KB Ingest Job 起動（変更分のみ再エンベディング）
    • リアルタイム変更検出：DynamoDB Streams / DocumentDB Streams → Lambda → KB 同期
    • 定期同期パイプライン：Step Functions でスケジュール実行（深夜バッチで全件 sync）
    • 完全再構築：エンべディングモデルを変更した場合は必須（ベクトル空間が変わるため）
    • 判別軸：更新頻度／許容遅延／コスト

読むべき公式ドキュメント

ページ 確認すべきポイント
Knowledge Base - ベクターストア設定 OpenSearch Serverless・Aurora・RDS・Redis・Pinecone等の選択肢と設定の違い
OpenSearch - k-NNベクター検索 k-NNエンジン選択（nmslib / faiss / Lucene）の違いと推奨ユースケース
OpenSearch - Serverlessベクター検索コレクション マネージドな構成。Bedrockとの統合が最も容易
OpenSearch - セマンティック検索 ニューラル検索パイプラインを使ったエンべディング＋キーワードのハイブリッド検索
Aurora PostgreSQL + pgvector 既存RDBにベクター検索を追加するユースケースと設定
OpenSearch - Neural プラグイン（Bedrock統合） OpenSearch内でBedrockエンべディングモデルを直接呼び出すパイプライン構成
OpenSearch - シャーディング戦略 プライマリ／レプリカ数、シャードサイズの目安。スケール時の必須知識
Knowledge Base - データソース同期 フル同期 vs 増分同期、自動同期スケジュール設定
Amazon S3 オブジェクトメタデータ x-amz-meta-*カスタムメタデータでドキュメント属性をベクトル検索のフィルタに活用

Task 1.5 ｜ FM拡張のための検索メカニズム（RAG）を設計する

📝 用語補足：チャンクとチャンキング

  • チャンク：長いドキュメントを検索しやすいサイズに分割した小さなテキストの塊。RAGでは100ページのPDFをそのままLLMに渡せないため、あらかじめ小さく切っておき、質問に関連する部分だけを取り出してLLMに渡す
  • チャンキング：ドキュメントをチャンクに分割する処理のこと
  • ※シャード（OpenSearch側のデータ保存の分割単位）とは別物。チャンクは「何を保存するか（テキスト）」、シャードは「どこに・どう分けて保存するか（インフラ）」の概念

試験で問われる判断パターン

  • チャンキング戦略の選定：文書の性質から戦略を選ぶ

    • 「ログ・CSV・コードなど均質テキスト」→ 固定サイズ（実装シンプル、サイズ・オーバーラップを設定）
    • 「自然文の意味境界を保ちたい・PDFや論文」→ セマンティック（文脈の切れ目で分割、精度高）
    • 「短いチャンクで検索 → 周辺含めて回答させたい」→ 階層（親子）チャンキング（小チャンクで検索ヒット、大チャンクをコンテキストとして渡す）
    • 「HTML・Markdown・独自タグ構造で分割したい」→ Lambda カスタムパーサー
    • 判別軸：文書構造／検索精度要件／実装工数

  • 検索精度が低い場合の改善手段：リランキング・ハイブリッド検索・クエリ変換

    • 「上位k件に正解が含まれるが順位が低い」→ リランキング（Bedrock Rerank で再順序付け）
    • 「専門用語の完全一致もしたい」→ ハイブリッド検索（セマンティック + BM25 を組み合わせ、OpenSearch ニューラル検索）
    • 「ユーザーの質問が曖昧・専門用語不足」→ クエリ変換（後述）
    • 判別軸：失敗パターン（順序問題 / 用語ミスマッチ / 質問曖昧）

  • コンテキスト過多で精度が落ちる

    • 大きすぎるチャンクを渡すと「Lost in the Middle」現象で中盤の情報が無視される
    • → 親子チャンキング：小チャンク（〜300トークン）で検索精度を稼ぎ、ヒットした親チャンク（〜1500トークン）を回答用コンテキストとして渡す
    • 代替：上位k件を絞る、Rerank で必要十分な件数のみ渡す

  • エンべディング選定：次元数 vs 精度 vs 多言語性

    • 「日本語/多言語含む」→ Cohere Multilingual または Titan Text Embeddings V2（多言語版）
    • 「英語中心・コスト最優先」→ Titan V2 の 256次元（最も安価）
    • 「精度最優先」→ Titan V2 の 1024次元 や OpenAI text-embedding-3-large
    • 注意：エンべディングモデルを変更した場合は 全データ再ベクトル化が必須

  • クエリ変換：曖昧な問い合わせの精度を上げる

    • クエリ拡張：同義語・関連語を Bedrock FM で生成して再検索（recall を上げる）
    • クエリ分解：「Aの売上とBの利益を比較」のような複合質問を複数サブクエリに分割し、それぞれ検索 → 統合
    • クエリ書き換え（reformulation）：会話履歴を踏まえて代名詞や省略を補完（Bedrock KB の Query Reformulation 機能）
    • 実装：Bedrock（FMでクエリ生成）／Lambda（前処理）／Step Functions（分解と並列検索のオーケストレーション）

  • アクセス手段：FMから検索をどう呼ぶか

    • 関数呼び出し（Tool Use）：Converse API の toolConfig にベクター検索ツールを登録、FMが必要時に呼び出す
    • MCP クライアント：Model Context Protocol で標準化されたツールとして接続、他エージェントでも再利用可能
    • 標準API（REST）：API Gateway 経由で Retrieve API をラップ、外部システムからも利用
    • 判別軸：エージェント連携の有無／標準化要件／外部公開の必要性

読むべき公式ドキュメント

ページ 確認すべきポイント
Knowledge Base - チャンキング設定 固定サイズ・セマンティック・階層・カスタムの各戦略の設定値と特徴を比較
Knowledge Base - Rerank（リランキング） 初回検索後にFMで再ランク付けして精度を向上させる仕組みと設定
OpenSearch - ニューラル検索パイプライン設定 ハイブリッド検索（セマンティック＋BM25）のパイプライン構成
RAGのベストプラクティス チャンキング・プロンプト設計・コンテキスト管理の推奨パターン
Amazon Titan Embeddings Titan Text Embeddings V2の次元数選択（256/512/1024）とコスト・精度トレードオフ
Bedrock Knowledge Base - クエリ変換 クエリ書き換え（query reformulation）・分解の設定オプション
Model Context Protocol（MCP） Bedrock AgentCore等で利用される、エージェントとツールの標準化された接続プロトコル

⚠️ 比較ポイント：チャンキング戦略

戦略 向いているケース
固定サイズ 均質なテキスト（ログ・CSVなど）。設定がシンプル
セマンティック 文脈の境界を意味単位で分割。精度重視
階層（親子） 検索は小チャンク・回答は大チャンクで文脈を保持
カスタム（Lambda） 独自形式（HTML・Markdown等）に対応

⚠️ クエリ処理パターン（精度改善の引き出し）

パターン 内容 実装
クエリ拡張 同義語・関連語を追加して再検索 Bedrock FM + Lambda
クエリ分解 複雑な質問を複数サブクエリに分解 Lambda
クエリ書き換え 曖昧な質問を明確化 Bedrock KB Query Reformulation
クエリ変換 クエリのフォーマットを検索系に最適化 Step Functions

⚠️ FMから検索を呼ぶ3つのインターフェイス

  1. 関数呼び出し（Tool Use）：Converse APIのtoolConfigにベクター検索を登録
  2. MCPクライアント：標準化プロトコルでツールを共通インターフェイス化
  3. 標準API（REST）：API Gatewayの背後にRetrieve APIをラップして拡張

Task 1.6 ｜ プロンプトエンジニアリング戦略とガバナンスを実施する

試験で問われる判断パターン

  • 「複雑な多段推論が必要」→ Chain-of-Thought（CoT）

    • 「ステップバイステップで考えて」と明示することで、中間推論を生成 → 最終回答の精度が向上
    • 用途：数学問題・論理パズル・複雑な業務判断
    • 注意：トークン消費が増えコストとレイテンシが悪化する

  • 「ツールを使って自律的に行動させたい」→ ReAct

    • Reasoning + Acting：思考 → ツール呼び出し → 観察 → 再度思考、を繰り返すパターン
    • 用途：検索・API呼び出し・データベース照会など外部情報を必要とするタスク
    • Bedrock Agents が内部で採用しているサイクル

  • 「少ない例で形式を揃えたい」→ Few-shot

    • プロンプトに数件（2〜5件程度）の入出力例を含めると、モデルが形式・トーンを模倣
    • 用途：JSON出力の形式統一・分類タスクのラベル形式の指定
    • Zero-shot で不十分な場合の第一選択（Fine-tuningより圧倒的に安価）

  • プロンプトのバージョン管理・チーム共有 → Bedrock Prompt Management

    • プロンプトを コードから分離 して ARN 参照で呼び出す
    • 履歴管理・承認ワークフロー・本番昇格・ロールバックが可能
    • A/Bテストや段階的ロールアウトを安全に運用できる

  • 対話の文脈維持：ユーザー意図の正確な把握と継続的対話

    • 意図認識 → Amazon Comprehend（カスタム分類器で「クレーム」「質問」「予約」等を判定）
    • 明確化ワークフロー：意図不明時にユーザーへ追加質問を返す → Step Functions（分岐制御）＋ Comprehend（意図分類）＋ Lambda（追加質問の生成・返却）の組み合わせで実現。Step Functions 単体では何も判断・生成しない
    • 会話履歴保存 → DynamoDB（セッションID をキー、TTL で自動失効）
    • 判別軸：意図のカテゴリ数／対話の長さ／プライバシー要件

  • プロンプト品質保証：本番投入前の検証ループ

    • 出力検証：応答が期待スキーマ（JSON 等）に沿っているかを Lambda で機械チェック
    • エッジケーステスト：境界値・敵対的入力・極端なケースを一括評価 → Step Functions（並列実行の管理・結果集約）＋ Lambda（Bedrockを呼び出して各テストケースを実行・検証）の組み合わせで実現。Step Functions 単体では評価処理は行わない
    • 回帰テスト：プロンプト変更前後の品質メトリクスを CloudWatch で記録 → 劣化を自動検知
    • 判別軸：チェック対象（形式 / 内容 / パフォーマンス）

  • 構造化プロンプト：複雑タスクの定型構成

    • 「ロール定義（あなたは…の専門家）」+「コンテキスト（前提情報）」+「入力（処理対象）」+「出力フォーマット指定（JSON Schema等）」+「CoT指示（ステップで考えて）」
    • この5要素を XML タグや Markdown 見出しで明確に区切ると、モデルが各部分を識別しやすい（Claude では <role>...</role> 形式が推奨）

読むべき公式ドキュメント

ページ 確認すべきポイント
プロンプトエンジニアリングの概念 Zero-shot / Few-shot / CoT / ReActの定義と使い分け
プロンプトエンジニアリングガイドライン temperature・top-p・top-kの意味と調整方針。モデル別の推奨プロンプト形式
LLMプロンプトエンジニアリングベストプラクティス（Prescriptive Guidance） 各手法の詳細な解説と実装パターン。試験で最も参照価値が高いページ
Bedrock Prompt Management プロンプトのバージョン管理・ARN参照・デプロイの仕組み
プロンプトの自動最適化 Bedrockが自動でプロンプトを書き換えて改善する機能の使い方と制約
Bedrock Prompt Flows 順次プロンプトチェーン・条件分岐・再利用コンポーネント・前後処理を統合した複雑なプロンプトシステム
Amazon Comprehend - 意図検出 / 分類 カスタム分類器で「ユーザーの意図」を判定。対話分岐に利用

⚠️ 比較ポイント：プロンプトパラメータ

LLMが次の単語を選ぶとき、候補となる単語すべてに確率を計算している。これらのパラメータは「その確率をどう使って単語を選ぶか」を制御するもの。

  • temperature（0〜1）：高い → 創造的・ランダム。低い → 決定論的・安定
    • 事実回答・コード生成 → 低め（0.1〜0.3）／創作・アイデア出し → 高め（0.7〜1.0）
  • top-k：確率上位k個のトークンだけを候補にする（例：top-k=50なら上位50単語のみ選択肢にする）
  • top-p：確率の合計がp%に達するまでの単語を候補にする（例：top-p=0.9なら上位から足して90%になるまで）。文脈によって候補数が自動で変わるため top-k より柔軟

Domain 2: 実装と統合（26%）

Task 2.1 ｜ エージェント型AIソリューションとツール統合を実装する

試験で問われる判断パターン

  • 「外部APIをFMに呼び出させたい」→ Bedrock Agents の Action Groups

    • 外部システム（CRM・天気API・社内RPA等）を Lambda で実装し、OpenAPI 仕様 でエージェントに登録
    • FMが自律的に「いつ・どのツールを・どのパラメータで呼ぶか」を判断（ReActパターン）
    • 判別軸：呼び出すツールが固定的か／OpenAPIで仕様化できるか

  • 「複数の専門エージェントを組み合わせたい」→ マルチエージェント連携

    • スーパーバイザー + サブエージェント：Bedrock Agents のマルチエージェント機能。スーパーバイザーが入力を解釈し、適切なサブエージェントへ委譲
    • AWS Agent Squad：OSSのマルチエージェントオーケストレーター。Classifier が入力を分類し、専門エージェントへルーティング
    • 判別軸：マネージド希望（Bedrock）か OSS で柔軟に組みたいか（Squad）

  • 「エージェントランタイムをAWSにフルマネージドで乗せたい」→ Bedrock AgentCore

    • エージェントのホスティング・メモリ（会話履歴・ユーザーごとの長期記憶）・**ツール接続（MCP含む）**を一括提供
    • Strands Agents 等のコードを AgentCore Runtime にデプロイして運用可能
    • 判別軸：自前のエージェントコードを持つか／メモリ管理を自前で書きたくないか

  • 「コード側でエージェントを書きたい・OSS連携したい」→ Strands Agents

    • 軽量な Python フレームワーク（コードファースト）でツール定義・推論ループを記述
    • AgentCore と統合してマネージドホスティング可能
    • 判別軸：複雑な条件分岐や独自ロジックが必要か／LangChain等のOSSと連携したいか

  • 「ツールを標準化して複数エージェントで共有したい」→ MCP（Model Context Protocol）

    • 「ツール定義」をエージェント実装と分離して、複数のエージェント・LLMで使い回せる標準プロトコル
    • Stateless MCP サーバー → Lambda：軽量・短時間のツール呼び出し（Web検索・計算・社内API）
    • Stateful / 複雑 MCP サーバー → ECS / Fargate：長時間稼働・DBコネクションプール・ヘビーな処理
    • 判別軸：状態保持の必要性／処理時間／呼び出し頻度

  • 「エージェントの暴走を防ぎたい」→ 多層の安全制御

    • 停止条件 → Step Functions の MaxIterations / Bedrock Agent の最大ループ回数
    • タイムアウト → Lambda の timeout + Step Functions Heartbeat
    • リソース境界 → IAM ロールで「呼び出し可能なツール」「アクセスできるリソース」を最小権限化
    • サーキットブレーカー → 連続失敗時に Action Group 呼び出しを遮断
    • 判別軸：暴走パターン（ループ／タイムアウト超過／不正リソースアクセス）

  • 「人間レビューを途中で挟みたい」→ ヒューマン・イン・ザ・ループ

    • Step Functions の承認ステップ：エージェントの判断を一時停止 → 人間が承認/却下 → 再開（コールバックパターン）
    • API Gateway + 専用UI：レビュー画面でフィードバック収集 → DynamoDB保存
    • Amazon Augmented AI（A2I）：定型のレビューワークフローを構築
    • 判別軸：レビュー頻度／レビュー画面の作り込み度

読むべき公式ドキュメント

ページ 確認すべきポイント
Agents - 仕組み（ReActサイクル） 思考→行動→観察のサイクル図解。FMがどのタイミングでツールを呼ぶかの流れ
エージェントの作成 作成時の設定項目（ベースモデル・インストラクション・KB紐付け・コードインタープリター）
Action Groupsの作成（Lambda＋OpenAPI仕様） LambdaとOpenAPI仕様でカスタムツールを登録する方法。スキーマの書き方
マルチエージェント連携 スーパーバイザーがサブエージェントに委譲する構成と、メモリ・セッション管理の扱い
Bedrock AgentCore エージェントのホスティング・メモリ・ツール接続（MCP含む）をフルマネージドで提供する新機能
Flows - 仕組み Agentsと異なりノードベースの決定論的ワークフロー。GUIで構成可能
Strands Agents コードファーストで構築するエージェントフレームワーク。AgentCoreと統合可能
AWS Agent Squad マルチエージェントオーケストレーター。Classifierで適切なエージェントへルーティング
MCP（Model Context Protocol） エージェントとツール間の標準化プロトコル。Lambda（軽量）／ECS（複雑）でホスト

⚠️ 比較ポイント：Agents vs Flows vs Step Functions

サービス 特徴
Bedrock Agents FMが自律的に次のアクションを判断するReActパターン
Bedrock Flows 事前定義したノードフローを確定的に実行。分岐・ループ可能
Step Functions 複雑な非同期ワークフロー、エラーハンドリング、長時間処理に強い

⚠️ エージェント実装スタックの選び方

スタック 選ぶ理由
Bedrock Agents（マネージド） コンソールGUIで素早く構築。Action Groups + KB標準連携
Bedrock AgentCore ホスティング・メモリ・MCPツール接続をマネージドで一括提供
Strands Agents コードで細かく制御。複雑なロジックや独自フレームワークが必要
AWS Agent Squad 専門エージェントを並列に持ち、入力を分類してルーティング

⚠️ エージェント安全制御（Guardrails of Agents）

  1. 停止条件：Step FunctionsでMaxIterationsを設定
  2. タイムアウト：Lambda関数のtimeout + Step Functions Heartbeat
  3. リソース境界：IAMロールで呼び出し可能なツール／APIを最小権限化
  4. サーキットブレーカー：連続失敗時はAction Group呼び出しを遮断
  5. ヒューマン・イン・ザ・ループ：承認ステップとフィードバック収集（A2I・API Gateway）

⚠️ MCPサーバーの実装パターン

パターン サービス 用途
Stateless MCP サーバー Lambda 軽量で短時間のツール呼び出し（Web検索、計算等）
Stateful / 複雑 MCP サーバー ECS / Fargate 長時間稼働、コネクション維持、ヘビーなツール

Task 2.2 ｜ モデルデプロイメント戦略を実装する

試験で問われる判断パターン

  • 「AWSのFMをそのまま使う」→ Amazon Bedrock

    • フルマネージド・運用負荷ゼロでClaude / Llama / Titan等を呼べる
    • 「予測不能な利用」→ オンデマンド、「常時高頻度」→ Provisioned Throughput
    • 判別軸：運用負荷を持ちたくない場合の第一選択

  • 「オープンソースFMを自前でホスト」→ SageMaker JumpStart or SageMaker エンドポイント

    • SageMaker JumpStart：Llama・Mistral・Falcon等を GUI / SDK でワンクリックデプロイ（推奨パス）
    • SageMaker エンドポイント：独自モデルやHugging Face モデルを LMI（Large Model Inference）コンテナで配信
    • 判別軸：Bedrock 未提供のモデル／カスタムモデル／推論最適化（量子化・テンソル並列）が必要か

  • 「Fine-tuningでモデルをカスタマイズ」→ FT か Continued Pre-training か

    • Fine-tuning：ラベル付きQ&Aペアなど 少量データ で 特定タスク・形式 を学習させる
    • Continued Pre-training（CPT）：ラベルなしの 大量テキスト で ドメイン知識 を取り込む
    • LoRA / PEFT：パラメータ効率の良い微調整。フルFTよりはるかに安価・小型なアダプタ重みのみ学習
    • 判別軸：データ種類（ラベル有無）／データ量／変えたいもの（形式 vs 知識）

  • 「LLMをコンテナで自前運用」→ ECS / EKS + GPUインスタンス

    • メモリ：モデルパラメータ数 × 精度（FP32=4byte / FP16=2byte / INT8=1byte / INT4=0.5byte）で必要VRAMを計算
    • GPU使用率：常時100%張り付きはレイテンシ悪化 → バッチサイズ・並列度を調整
    • トークン処理容量：tok/s（throughput）でインスタンスタイプを選定（p4d / p5 / g5 / Inferentia等）
    • モデルロード戦略：ウォームスタート（コンテナ起動時にロード）か コールドスタート（リクエスト時にロード）か
    • 判別軸：必要VRAM／同時接続数／レイテンシSLA

  • 「軽い質問は安いモデル、重い質問は強いモデル」→ モデルカスケード戦略

    • 段階1：軽量モデル（Haiku / Nova Micro）で初回判定
    • 段階2：信頼度低・複雑度高のクエリのみ強力モデル（Sonnet / Opus）へ昇格
    • 振り分けは API Gateway + Lambda または Step Functions Choice ステート（入力JSONの値を条件評価し、次に遷移するステートを決定するif/switch相当の機能） で実装
    • メトリクスで品質とコストのバランスを継続評価
    • 判別軸：クエリ複雑度のばらつき／コスト削減目標

読むべき公式ドキュメント

ページ 確認すべきポイント
カスタムモデル概要（Fine-tuning vs Continued Pre-training） 2手法の違い・対応モデル一覧・必要データ量の目安
Fine-tuningの手順 学習データのJSONL形式・ハイパーパラメータ（エポック数・バッチサイズ等）・実行方法
Fine-tuning対応モデルとリージョン どのモデルがFT/CPTに対応しているかの早見表（試験でよく問われる）
Fine-tuning用データ準備 JSONL形式の要件・最低サンプル数・S3への配置方法
Batch推論 非同期で大量リクエストを処理。コスト最大50%削減。S3入出力
SageMaker JumpStart Llama・Mistral等のOSSモデルを簡単にデプロイ。Fine-tuningも対応
SageMaker - LLMホスティングのベストプラクティス LMI（Large Model Inference）コンテナ・テンソル並列・量子化・GPU選定
SageMaker Neo モデルコンパイルでエッジ／推論最適化
Amazon ECS / EKS でのGPUワークロード コンテナベースのLLMホスティング。スケーリング設定の留意点

⚠️ 比較ポイント：Fine-tuning vs Continued Pre-training vs RAG

手法 データ 目的
Fine-tuning ラベルあり（Q&Aペア等）少量 特定タスクの形式・文体を学習
Continued Pre-training ラベルなし大量テキスト ドメイン固有の知識・用語を学習
RAG 任意（検索対象ドキュメント） 最新情報・社内情報を参照

⚠️ モデルカスケード戦略

  1. 軽量モデル（Haiku / Nova Micro 等）で初回判定
  2. 信頼度低 or 複雑クエリのみ強力モデル（Sonnet / Opus 等）に昇格
  3. API Gatewayや Step Functions でルーティングロジックを実装
  4. コストと品質のバランスをメトリクスで継続評価

Task 2.3 ｜ エンタープライズ統合アーキテクチャを設計・実装する

試験で問われる判断パターン

  • 「複数FMを連鎖させる複雑なワークフロー」→ AWS Step Functions

    • エラーハンドリング・リトライ・状態管理・並列実行・長時間処理（最大1年）が強力
    • 用途：複数FM の連鎖、外部API呼び出しを含む複雑なオーケストレーション
    • 判別軸：エラー処理の細やかさ／長時間実行／可視化要件

  • 「LLMの出力をノードで接続する軽量フロー」→ Bedrock Flows

    • GUIノードエディタで「入力 → プロンプト → 条件分岐 → 出力」を構成
    • Step Functions より軽量、GenAI特化、ノーコード
    • 判別軸：エンジニア以外も触るか／GenAI特化機能（プロンプト・KB呼び出し）が中心か

  • 「非同期・疎結合なFM呼び出し」→ SQS + Lambda + Bedrock

    • リクエストを SQS にキューイング → Lambda が消費して Bedrock 呼び出し
    • バックプレッシャー制御（スパイクトラフィックの平準化）と Throttling 緩和 に有効
    • 判別軸：即時応答が不要／大量リクエストを安定処理したい

  • 「レガシーシステムとの統合」→ 統合方式の選定

    • APIベース統合：REST/SOAP を API Gateway 経由で呼び出し
    • EventBridge：イベント駆動（システム間の疎結合、SaaS イベントの取り込み）
    • AppFlow：Salesforce・ServiceNow・SAP等のSaaSデータを コードレス で S3 / Redshift / KB へ転送
    • 判別軸：レガシー側の通信方式（同期REST / イベント / SaaS）

  • 「オンプレ／エッジでGenAIを動かしたい」

    • AWS Outposts：AWSサービスをオンプレ機器に延伸（データ主権・低レイテンシ・規制対応）
    • AWS Wavelength：5G通信事業者のエッジロケーションへデプロイ（モバイル・IoT向け低レイテンシ）
    • 判別軸：データを物理的に外に出せない要件か／エッジ低レイテンシ要件か

  • 「ID連携でアクセス制御」

    • Amazon Cognito：BtoC アプリのユーザー認証・SNSログイン・SSO
    • IAM Identity Center（旧AWS SSO）：BtoB エンタープライズ SSO・社内IdP（Active Directory / Okta）連携
    • 最小権限のIAMポリシーで Bedrock 呼び出しを部署・モデル単位で制限
    • 判別軸：エンドユーザー（一般 vs 社員）／既存IdPの有無

  • 「GenAI専用のCI/CD」→ CodePipeline + CodeBuild

    • 自動テスト（プロンプト回帰・評価ジョブ）→ セキュリティスキャン → 段階デプロイ → 失敗時ロールバック
    • SageMaker Model Registry や Bedrock Prompt Management のバージョンと連動
    • 判別軸：モデル／プロンプトの変更頻度／本番障害許容度

  • 「組織横断のGenAIゲートウェイ」→ API Gatewayを中心とした抽象化レイヤー

    • 複数モデル／プロバイダー（Bedrock・自社FM・OpenAI等）を 統一API で隠蔽
    • Usage Plan + APIキー で部署別スロットリング・コスト配賦
    • CloudWatch + X-Ray で全リクエストを一元観測
    • 判別軸：複数チーム利用／コスト按分／プロバイダー切替の柔軟性

読むべき公式ドキュメント

ページ 確認すべきポイント
Step Functions × Bedrock統合 BedrockをStep Functionsタスクとして呼び出すASL定義。同期・非同期モードの違い
プロンプトチェーニングのサンプル（Step Functions） 複数FMを連鎖させる具体的なステートマシン定義を確認
Bedrock Flows ノードベースのワークフロー。Step Functionsより軽量。GUIで構成可能
Flowsの作成 入力ノード・プロンプトノード・条件分岐ノード・出力ノードの構成方法
Amazon API Gateway - REST API Bedrock APIへの外部アクセスをスロットリング・認証付きで公開する方法
Amazon EventBridge イベント駆動でFM処理をトリガー。SaaS連携にも有効
Amazon AppFlow SalesforceやServiceNow等のSaaSからS3／KBへのデータ転送
AWS Outposts オンプレへAWSサービスを延伸。データ主権が必要な業界向け
AWS Wavelength 5Gエッジに低レイテンシでデプロイ。エッジAI推論
Amazon Cognito ユーザーディレクトリ・SSO・IDフェデレーション
IAM Identity Center エンタープライズSSO・IdP連携（旧 AWS SSO）
CI/CD（CodePipeline / CodeBuild） GenAIコンポーネントの継続的デプロイ・自動テスト・セキュリティスキャン

⚠️ GenAIゲートウェイアーキテクチャの構成要素

  1. 抽象化レイヤー：複数モデル／プロバイダーを統一APIで隠蔽（API Gateway + Lambda）
  2. オブザーバビリティ：CloudWatch + X-Ray でトークン使用量・レイテンシを一元監視
  3. アクセス制御：Cognito / IAM Identity Center による認証・認可
  4. 使用量制御：API Gateway Usage Plan でAPIキー単位のスロットリング
  5. コスト配賦：タグベースで部署別コスト集計

Task 2.4 ｜ FM API統合を実装する

試験で問われる判断パターン

  • 「同期 vs 非同期」：処理特性から呼び出し方式を選ぶ

    • 「ユーザー入力に即応必須・対話UI」→ Bedrock 同期API（InvokeModel / Converse）
    • 「大量バッチ処理・即時性不要」→ SQS + Lambda + Bedrock または Batch API（最大50%安）
    • 判別軸：応答時間SLA／処理件数／コスト

  • 「リアルタイムにテキストを出す」→ ストリーミング応答

    • 「チャット系UXでタイピング風表示」→ InvokeModelWithResponseStream + Lambda Response Streaming
    • 「サーバープッシュ・長時間接続」→ API Gateway WebSocket API
    • 「既存REST環境に組み込みたい」→ API Gateway HTTP API + Chunked Transfer Encoding（レスポンスを小さなチャンクに分割して順次送信するHTTP/1.1の転送方式。全体サイズ未確定のままストリーミング可能で、既存REST構成を変えずに導入できる）
    • 「ブラウザ標準のSSEで一方向ストリーミング」→ Server-Sent Events (SSE)
    • 判別軸：通信方向（一方向 / 双方向）／既存システムの方式

  • 「失敗・スロットリングが頻発」→ 耐障害性API設計

    • 指数バックオフ：AWS SDK の Adaptive retry mode で 5xx / Throttling に自動対応（待機時間が指数的に増加）
    • レート制限：API Gateway Usage Plan でクライアント側を制御 → Bedrockへの過剰呼び出しを未然防止
    • グレースフルデグラデーション：プライマリモデル失敗時に 小型・別リージョン・別プロバイダー のフォールバックモデルへ切替
    • 判別軸：失敗パターン（一時的 / 永続的）／代替手段の用意

  • 「サービス境界をまたぐ可観測性」→ AWS X-Ray

    • API Gateway → Lambda → Step Functions → Bedrock の 分散トレーシング を1つのトレースで可視化
    • どのステップでレイテンシが発生しているかを特定
    • プロンプトID・モデルID 等を アノテーション として付与すると検索が容易

  • 「リクエスト内容に応じてモデルを動的選択」→ ルーティング戦略

    • 静的設定（コード）：環境変数や AppConfig でモデルIDを保持 → コード分岐
    • 動的（Step Functions Choice ステート）：入力JSONのフィールドに応じて分岐先モデルを決定
    • メトリクスベース：CloudWatch アラームをトリガーに、プライマリ障害時に自動でフォールバック先へ
    • 判別軸：振り分けロジックの複雑度／変更頻度／自動切替の必要性

読むべき公式ドキュメント

ページ 確認すべきポイント
Bedrock ストリーミング推論（InvokeModelWithResponseStream） チャンク単位で出力を返すAPI。チャット系UXの基本
API Gateway WebSocket API サーバープッシュでストリーミング応答をブラウザに配信
Amazon SQS - 非同期FM呼び出し バックプレッシャー制御・大量リクエストの平準化
AWS SDK のリトライ・指数バックオフ ThrottlingException時のリトライ戦略。Adaptive retry mode の挙動
API Gateway スロットリング アカウント・ステージ・メソッド単位のレート制限設定
AWS X-Ray Lambda・API Gateway・Step Functions・Bedrockをまたぐ分散トレーシング
Step Functions Choice ステート 入力に応じた動的ルーティングの基本構文

Task 2.5 ｜ アプリケーション統合パターンと開発ツールを実装する

試験で問われる判断パターン

  • 「ノーコードでGenAIワークフローを作りたい」→ Bedrock Prompt Flows

    • GUIノードエディタで「入力 → プロンプト → KB検索 → 条件分岐 → 出力」を構成
    • エンジニア以外（業務担当・PM）でも触れる
    • 判別軸：実装者のスキル／変更頻度（ビジネス側で運用したい）

  • 「フロントエンドを素早く構築」→ AWS Amplify

    • 宣言型UIコンポーネント・ホスティング・認証（Cognito連携）・GraphQL/REST API を統合
    • チャットUIや管理画面を数時間で立ち上げ可能
    • 判別軸：認証/ホスティング/APIを一括解決したい／自前構築よりスピード優先

  • 「API設計を先に固めたい」→ OpenAPI仕様によるAPIファースト開発

    • OpenAPI YAML/JSON でAPIを定義 → クライアント・サーバーコード自動生成
    • Bedrock Agents の Action Groups もOpenAPI仕様でツールを記述するため、設計資産が直接活きる
    • 判別軸：複数チームで並行開発／契約駆動開発／Agentツール定義の流用

  • 「社内ナレッジを横断検索したい」→ Amazon Q Business

    • 40種以上のコネクター（SharePoint・Confluence・Slack・Salesforce等）でデータを統合
    • エンドユーザー向け のチャット型AIアシスタント、自前で RAG を組まなくて良い
    • 判別軸：自前RAG構築 vs マネージドQ Business（カスタマイズの自由度 vs 早期立ち上げ）

  • 「コード生成・リファクタを自動化したい」→ Amazon Q Developer

    • IDE統合（VSCode・JetBrains）で 開発者向け にコード補完・テスト生成・脆弱性スキャン・最適化提案
    • GenAI固有のエラー（コンテキスト超過・JSON崩れ）の特定にも有用
    • 判別軸：誰のためのGenAIか（エンドユーザー → Q Business／開発者 → Q Developer）

  • 「プロンプトと応答を後追い分析したい」→ ログ分析スタック

    • CloudWatch Logs Insights：プロンプト本文・応答をクエリ言語（フィルター・統計）で分析
    • AWS X-Ray：API Gateway → Lambda → Bedrock の呼び出しトレースを可視化
    • 判別軸：ログ内容を分析したい（Logs Insights）／呼び出しチェーンを追いたい（X-Ray）

  • 「ドキュメント処理を自動化」→ Bedrock Data Automation + Step Functions

    • 非構造化（PDF・画像・動画・音声）からの情報抽出を一気通貫で実施
    • Step Functions で「アップロード → BDA抽出 → FM要約 → KB登録」をオーケストレーション
    • 判別軸：複数モダリティが混在／Textract/Transcribeを個別に組む手間を削減したい

読むべき公式ドキュメント

ページ 確認すべきポイント
AWS Amplify 認証・API・ホスティングを統合したフルスタック開発フレームワーク
OpenAPI と Bedrock Agents Action Groups OpenAPI仕様（YAML/JSON）でツールを記述する書式
Bedrock Prompt Flows ノーコードのGenAIワークフロービルダー
Amazon Q Business 社内データを横断したエンタープライズAIアシスタント。コネクター・データソース管理
Amazon Q Business Apps ユーザーがQ Business上で作る目的特化アプリ
Amazon Q Developer IDE統合でコード生成・リファクタ・テスト生成
CloudWatch Logs Insights プロンプト・レスポンスログをクエリ言語で分析
Bedrock Data Automation ドキュメント・画像・動画・音声からの自動データ抽出パイプライン

Domain 3: AIの安全性・セキュリティ・ガバナンス（20%）

Task 3.1 ｜ 入力・出力の安全制御を実装する

試験で問われる判断パターン

  • 「プロンプトインジェクション対策」→ Guardrails のプロンプトアタック検出

    • 「以前の指示を無視して...」「あなたは別のAIになって...」等のジェイルブレイク／インジェクション攻撃を専用検出機能でブロック
    • コンテンツフィルタの6カテゴリ（憎悪・暴力・性的・不正・嫌がらせ・プロンプトアタック）のうちの1つとして設定可能（強度None〜High）
    • ⚠️ 注意：プロンプトアタック検出は独立したコンポーネントではなく、「コンテンツフィルター」内の1カテゴリ
    • 判別軸：システムプロンプト保護／外部入力を扱うアプリの必須対策

  • 「回答を知識ベースの内容のみに制限したい」→ Guardrails のグラウンディングチェック

    • グラウンディングスコア（KBの内容にどれだけ根拠があるか）と 関連性スコア（質問と回答の整合性）の閾値を設定
    • 閾値未満の応答は自動でブロック → 「知らないことを勝手に作る幻覚」を抑制
    • 判別軸：回答の事実性が事業上重要（医療・法律・金融）

  • 「Bedrockを使わない自社モデルにもGuardrailsを適用したい」→ ApplyGuardrail API

    • Guardrails を 独立して呼び出せる API。OpenAI・自社FM・オープンソースモデルの入出力にもガードを適用可能
    • 「入力チェック → 任意のモデル → 出力チェック」のパイプラインで実装
    • 判別軸：マルチプロバイダー戦略／Guardrailsを横断的に統一したい

  • 「自然言語からSQLを生成して決定論的な結果を得たい」→ Text-to-SQL 変換

    • 自然言語の質問 → FMで SQL生成 → DBで実行 → 結果を返す
    • FMが直接数値を捏造するリスクを排し、DBの実データ に基づいた決定論的な回答が得られる
    • 判別軸：構造化データへの問い合わせ／集計・正確な数値が必要

  • 「出力フォーマットを保証したい」→ JSON Schema指定＋構造化出力

    • Converse API の Response Format で JSON Schema を指定 → モデルが従う
    • 後段の Lambda で JSON Schema バリデーション を実施し、形式不一致を検知
    • 判別軸：下流システムが厳密なフォーマットを要求／パース失敗の許容度

  • 「ハルシネーション低減」→ 複数手段の組み合わせ

    • Bedrock ナレッジベース：根拠ドキュメントを引用させ、出典付き応答に
    • Guardrails Contextual Grounding Check：根拠なし回答を機械的にブロック
    • 信頼度スコアリング：応答ごとに自己評価スコアを返させ、低スコアは破棄
    • セマンティック類似度検索：KB側で高品質チャンクをヒットさせる
    • 判別軸：抑制対象（生成側 / 検索側 / 後処理）

  • 「多層防御（Defense in Depth）」→ 複数レイヤーで重ねる

    • 前処理：Amazon Comprehend / Lambda で入力サニタイズ・PIIマスク
    • モデル前後：Bedrock Guardrails / ApplyGuardrail API で有害／攻撃検出
    • 後処理：Lambda + JSON Schema で出力検証
    • API応答：API Gateway / AWS WAF でレート制限・機密データ漏洩防止
    • 判別軸：単一レイヤー突破の影響度／規制要件

  • 「敵対的テスト」→ レッドチーミング

    • プロンプトインジェクション・ジェイルブレイク用の テストスイート を Step Functions で定期実行
    • Guardrails のブロック率・誤検知率を CloudWatch でモニタリング
    • 判別軸：本番投入前の検証深度／継続的な脅威モデル更新

読むべき公式ドキュメント

ページ 確認すべきポイント
Guardrails - 仕組みと評価タイミング 入力評価 → モデル推論 → 出力評価の各ステップで何がブロックされるかの図解
コンテンツフィルタリング設定 6カテゴリ（憎悪・暴力・性的・不正・嫌がらせ・プロンプトアタック）の強度設定
コンテキストグラウンディング（幻覚抑制） グラウンディングスコア・関連性スコアの閾値設定で、根拠のない回答をブロック
Guardrailsコンポーネント設定 拒否トピック・機密情報（PII）マスキング・ワードフィルターの設定方法
ApplyGuardrail API（独立呼び出し） Bedrockモデル以外（OpenAI・自社モデル等）の入出力にGuardrailsを適用する方法

⚠️ Guardrailsで設定できる5つのコンポーネント

  1. コンテンツフィルター：有害カテゴリの強度設定（憎悪・暴力・性的・不正・嫌がらせ・プロンプトアタックの6カテゴリ。各カテゴリをNone〜Highで設定）
  2. 拒否トピック：「競合他社の製品について話すな」等のカスタムトピック拒否
  3. ワードフィルター：特定の単語・フレーズのブロックまたはマスキング
  4. 機密情報：PII（氏名・メール・クレカ等）のマスキング or ブロック
  5. グラウンディング：KBの内容に基づかない回答をブロック（幻覚抑制）

※プロンプトアタック検出は「コンテンツフィルター」内の1カテゴリであり、独立した6番目のコンポーネントではない点に注意

⚠️ 多層防御（Defense in Depth）アーキテクチャ

層 役割 サービス
前処理 入力サニタイズ・PIIマスク Amazon Comprehend / Lambda
モデル前後 プロンプトアタック・有害出力検出 Bedrock Guardrails / ApplyGuardrail API
後処理 出力検証・スキーマ準拠チェック Lambda + JSON Schema
API応答 機密データ漏洩防止・レート制限 API Gateway / AWS WAF

⚠️ ハルシネーション抑制の選択肢

  1. Bedrock ナレッジベースで根拠ドキュメントを引用させる
  2. Guardrails Contextual Grounding Check で根拠なし回答をブロック
  3. 信頼度スコアリング：応答ごとに自己評価スコアを返させる
  4. JSON Schema で出力形式を固定 → 自由生成余地を減らす
  5. Text-to-SQL：自然言語をSQLに変換、DB結果を返すことで決定論的に

Task 3.2 ｜ データセキュリティとプライバシー制御を実装する

試験で問われる判断パターン

  • 「Bedrockへの通信をパブリックインターネットに出したくない」→ VPCインターフェースエンドポイント

    • VPC 内に AWS PrivateLink でエンドポイントを作成 → Bedrock API への通信が AWSバックボーン内 で完結
    • プライベートサブネットの Lambda/EC2 から NAT Gateway なしで Bedrock を呼べる
    • 判別軸：規制業界（金融・医療・公共）／オンプレ接続環境

  • 「Fine-tuningデータやKBのデータを暗号化したい」→ KMS（カスタマーマネージドキー）

    • S3 / OpenSearch / Bedrock のカスタムモデル に CMK（顧客管理キー） を指定
    • キーポリシーで「FT用のIAMロール」「KB取り込みのロール」だけにDecrypt権限を付与
    • 判別軸：AWS管理キー（SSE-S3）で十分か／キーローテーション・監査要件があるか
    • 補足：アプリ層でのエンベロープ暗号化が必要なら AWS Encryption SDK

  • 「IAMで特定ユーザーに特定モデルだけ使わせたい」→ bedrock:InvokeModel にリソース条件

    • IAM ポリシーの Resource にモデルARN（例：arn:aws:bedrock:*::foundation-model/anthropic.claude-3-sonnet-*）を指定
    • Condition で IP制限・タグ条件・MFAなどを追加可能
    • 判別軸：部署・プロジェクト単位でのモデル使用権限の分離

  • 「列・行単位できめ細かいデータアクセス制御」→ AWS Lake Formation

    • データレイク（S3 + Glue Data Catalog）に対し 列レベル・行レベル・タグレベル のフィルタを設定
    • 同じテーブルでも部署ごとに見える行・列を変えられる → RAGバックエンドや分析基盤に有効
    • 判別軸：IAMだけでは粒度が足りない／部署別の見せ方制御

  • 「APIキーや接続文字列の安全な管理」→ AWS Secrets Manager

    • サードパーティFM（OpenAI 等）のAPIキー・DB接続情報を集中管理
    • 自動ローテーション・IAMでアクセス制御・CloudTrailで取得履歴を監査
    • 判別軸：環境変数管理の限界／キーローテーションの自動化要件

  • 「Fine-tuningデータ・ログを一定期間で自動削除」→ S3ライフサイクル設定

    • X日後に S3 Glacier に階層移行（長期保管・低コスト）／ Y日後に 完全削除
    • GDPR・個人情報保護法の保持期間規制への対応
    • 判別軸：保管要件 vs 削除要件／コストとコンプライアンス

  • 「機密データを匿名化してから学習」→ データマスキング

    • Comprehend PII detection で氏名・メール・電話番号等を検出 → 代替トークン（[NAME_1] 等）に置換
    • FT用のS3データをマスク版に作り替え → カスタムモデルがPIIを学習しないようにする
    • 判別軸：個人情報を含むデータでFT/CPTする要件／逆解析リスクの許容度

  • 「Webレイヤの追加防御」→ AWS WAF

    • API Gateway / CloudFront の前段で レート制限・地理ブロック・SQLi/XSSパターン検知
    • GenAIアプリでもインジェクション・スクレイピング対策に有効
    • 判別軸：BtoCで公開／攻撃対象になりやすいか

読むべき公式ドキュメント

ページ 確認すべきポイント
Bedrockのセキュリティ全体像 暗号化・ネットワーク分離・IAMの設定項目の一覧
Bedrock VPCインターフェースエンドポイント VPC内からBedrockをプライベート接続する設定手順とDNS設定
BedrockのIAMアクセス制御 bedrock:InvokeModel・bedrock:RetrieveAndGenerate等のIAMアクション一覧
Amazon Macie S3上のデータのPII自動検出・分類・レポート。Fine-tuningデータのガバナンスに利用
AWS Lake Formation データレイクの列・行・タグレベルできめ細かいアクセス制御
AWS KMS - カスタマーマネージドキー CMKでの暗号化、キーポリシー、ローテーション、IAMポリシーとの併用
AWS Encryption SDK アプリ層でのエンベロープ暗号化。KMSと統合
AWS Secrets Manager APIキー・接続文字列の安全な管理。サードパーティFM呼び出し時に利用
S3 ライフサイクル設定 データ保持期間・自動削除・Glacier階層移行のルール定義
AWS WAF API Gateway/CloudFrontのWebレイヤ防御。レート制限・地理ブロック

Task 3.3 ｜ AIガバナンスとコンプライアンスメカニズムを実装する

試験で問われる判断パターン

  • 「全FMリクエストの入出力を記録・監査したい」→ Bedrock モデル呼び出しログ

    • Bedrock コンソールから モデル呼び出しログ機能 を有効化 → 入力プロンプト・出力・メタデータが S3 または CloudWatch Logs に記録
    • 「データガバナンス・原因究明・モデル評価」に使える唯一の公式ログソース
    • 判別軸：保存先選定（S3=コスト最適・長期保管／CloudWatch Logs=リアルタイム分析）

  • 「誰がいつどのモデルを呼び出したか追跡したい」→ AWS CloudTrail

    • API呼び出しの 主体（IAMロール／ユーザー）・時刻・パラメータ を記録
    • モデル呼び出しログとは異なり、プロンプト本文は記録されない（管理イベント中心）
    • 判別軸：監査対象（誰が＝CloudTrail／何を＝呼び出しログ）

  • 「バイアスや有害性を定期評価したい」→ Bedrock Model Evaluation

    • 自動評価ジョブ：ROUGE / BERTScore 等の指標で参照回答との一致度を測る
    • 人間評価ジョブ：プライベートワーカーがUI上で品質を採点
    • LLM-as-a-judge：別FMを審査員として使い、流暢性・公平性・正確性を自動評価
    • 判別軸：評価対象（テキスト一致／主観品質／大量サンプル）
    • ⚠️ Model Monitor + Clarify との違い：Model Evaluation は「特定タイミングのスポット検査（健康診断）」。Model Monitor + Clarify は「本番稼働中の継続監視（経時的なドリフト検知）」。試験の判別軸は デプロイ前後 と 単発か継続か

  • 「モデルの能力・限界・想定用途をドキュメント化」→ SageMaker Model Cards

    • 想定用途・性能指標・倫理的考慮・トレーニングデータ概要 を構造化ドキュメント化
    • プログラマブル（SDK）で作成 → CI/CD に組み込んで自動更新
    • 判別軸：規制対応／ステークホルダー（経営層・顧客・監査）への透明性提示

  • 「データの出所・加工履歴を追跡」→ ==Amazon DataZone== + メタデータタグ

    • 「どのS3バケットから取り込んで、どの変換を経て、どのテーブルへ流れたか」を可視化
    • コンプライアンス監査での「データ出自証明」に必須
    • 判別軸：GDPR / HIPAA / 業界規制／インシデント時の調査要件

  • 「データソースを集中管理」→ AWS Glue Data Catalog

    • 組織内のデータソース（S3・RDS・Redshift等）のスキーマ・場所を 集中レジストリ に登録
    • Lake Formation・Athena・Q Business のバックエンドとして機能
    • 判別軸：データソースの数／横断検索の必要性

  • 「ポリシー違反・バイアスドリフトを継続検出」→ 自動アラート + 修復ワークフロー

    • 自動検知：CloudWatch カスタムメトリクスで誤用・ドリフト・違反率をモニタ
    • バイアスドリフト：Model Monitor（スケジュール実行・分布変化の検知）と ==Clarify==（DPL・DIなどバイアス指標の定量計算）を組み合わせて使用。Model Monitor が Clarify ジョブを呼び出し、訓練時と推論時の分布差を継続監視する
    • アラート → 修復：CloudWatch Alarms → SNS / EventBridge → Lambda で自動是正
    • トークンレベルリダクション：応答ログ中の機密トークンを自動マスクして保存
    • 判別軸：検知すべき変化（性能 / バイアス / セキュリティ）

読むべき公式ドキュメント

ページ 確認すべきポイント
Bedrockのモデル呼び出しログ設定 ログ保存先（S3 / CloudWatch Logs）の設定方法と、記録される内容（入力・出力・メタデータ）
AWS CloudTrailでのBedrock監査 どのAPI呼び出しがCloudTrailに記録されるかの一覧。「誰がいつ何を呼んだか」の追跡
Model Evaluation - 概要 自動評価・人間評価・LLMジャッジの3種類の違い
評価指標の詳細 ROUGE・BERTScore・正確性など指標の意味と適したユースケース
SageMaker Clarify - 学習後バイアス検出 カスタムモデルのバイアス種別（DPL・DI等）と定量的な検出方法
SageMaker Model Cards 想定用途・性能指標・倫理的考慮・トレーニングデータ概要を構造化ドキュメント化
AWS Glue Data Catalog データソースの集中レジストリ。Lake FormationやAthenaのバックエンド
Amazon DataZone（データリネージ） データの出所・変換履歴を可視化。コンプライアンス対応に必須

⚠️ ガバナンス体制の3層

  1. モデルカード：モデル仕様・制限・倫理を文書化（SageMaker Model Cards）
  2. データリネージ：データの出所・加工を追跡（Amazon DataZone + メタデータタグ）
  3. 意思決定ログ：FMの推論・判断を記録（CloudWatch Logs + CloudTrail）

⚠️ 継続モニタリング・修復のサイクル

  • 自動検知：誤用・ドリフト・ポリシー違反（CloudWatch カスタムメトリクス）
  • バイアスドリフト：Model Monitor（スケジュール検知）+ Clarify（バイアス指標の定量計算）を組み合わせて使用
  • 自動アラート：CloudWatch Alarms → SNS / EventBridge → Lambda 修復
  • トークンレベル リダクション：応答ログ中の機密トークンを自動マスク

Task 3.4 ｜ 責任あるAIの原則を実装する

試験で問われる判断パターン

  • 「ユーザーにモデルの推論過程を見せたい」→ 透明性の3要素

    • 推論表示（reasoning display）：CoT や ReAct の中間ステップ（思考プロセス）を UI 上に表示
    • 信頼度メトリクス：応答ごとに自己評価スコアを返させ、CloudWatch カスタムメトリクスで記録 → UIに「確信度」を表示
    • ソース帰属（attribution）：RAGの引用元ドキュメントとリンクを応答に含めて、ユーザーが原典を確認できるように
    • 判別軸：説明責任の重み（医療・法律・金融で必須）／ユーザー信頼の獲得

  • 「エージェントの内部判断をトレースしたい」→ Bedrock Agent Trace

    • エージェントの「思考 → ツール呼び出し → 観察 → 次の思考」の各ステップを コンソールで可視化
    • 不適切な判断・無限ループの原因究明・説明責任の根拠資料として利用
    • 判別軸：エージェント利用／監査・デバッグ要件

  • 「モデル出力が公平か検証したい」→ A/Bテスト + LLM-as-a-judge

    • A/Bテスト：旧プロンプト vs 新プロンプト／旧モデル vs 新モデル を Prompt Flows で並行運用し、メトリクスで比較
    • LLM-as-a-judge：Bedrock Model Evaluation で別のFMを審査員として使い、大量サンプル に対し公平性・正確性・流暢性を自動評価
    • 統計的有意性を担保しつつ高速に評価可能
    • 判別軸：評価規模（少数 → 人間／大量 → LLM-as-a-judge）

  • 「責任あるAIガイドラインに沿った運用」→ 多層の体制構築

    • Guardrails：技術的な安全制御（コンテンツフィルタ・PIIマスク・グラウンディング）
    • Model Cards：モデルの想定用途・制限・倫理的考慮の文書化
    • 自動コンプライアンスチェック：CodePipeline に組み込んだ評価ジョブで本番投入前にゲート
    • 判別軸：技術 × 文書 × プロセス、3層揃っているか

読むべき公式ドキュメント

ページ 確認すべきポイント
Bedrock Agent Trace エージェントの思考・行動・観察ステップを可視化。説明責任に直結
LLM-as-a-judge（Bedrock Model Evaluation） 別FMをジャッジとして使い、公平性・正確性・流暢性を自動評価
SageMaker Model Cards FMの制限・想定外用途を構造化記述、ステークホルダーへの透明性を担保
Bedrock Prompt Management × 公平性メトリクス プロンプトバージョン管理と組み合わせたA/Bテスト
責任あるAI（Anthropic Claude） Bedrock上での責任あるAI原則の実装ガイダンス

⚠️ 透明性（Transparency）3要素

  1. 推論表示：CoTやReActの中間ステップをUIに表示
  2. 信頼度メトリクス：CloudWatch カスタムメトリクスでスコアを記録
  3. ソース帰属：RAGの引用元ドキュメントとリンクを応答に含める

⚠️ 公平性評価のワークフロー

  1. 公平性メトリクスを事前定義（CloudWatch / Prompt Management）
  2. A/Bテスト：旧プロンプト vs 新プロンプトをPrompt Flowsで比較
  3. LLM-as-a-judge：Bedrock Model Evaluation で大量サンプルを自動評価
  4. 継続モニタリング：閾値割れ時にアラート → ロールバック

Domain 4: 運用効率と最適化（12%）

Task 4.1 ｜ コスト・パフォーマンスを最適化する

試験で問われる判断パターン

  • 「同じシステムプロンプトを毎回送っている」→ Prompt Caching

    • システムプロンプト・ツール定義・参照ドキュメントなど 繰り返し利用される部分 をキャッシュ
    • 2回目以降はキャッシュトークン分のコストが大幅減（モデルによっては最大90%安）、レイテンシも改善
    • 判別軸：プロンプトのうち固定部分の割合（多いほど効果大）

  • 「1日数千件の非同期バッチ処理」→ Batch API

    • S3にプロンプトJSONLを置く → 非同期で処理 → S3に結果出力
    • 最大50%コスト削減、ただし即時応答は不可（処理完了まで時間がかかる）
    • 判別軸：即時性が不要／大量処理／コスト最優先

  • 「高頻度で予測可能なトラフィック」→ Provisioned Throughput

    • モデルユニット単位で 1か月または6か月コミット → 単価が安く、スロットリングなし
    • オンデマンドより損益分岐するのは「継続的に高負荷」な場合のみ（低負荷だと逆に高コスト）
    • 判別軸：トラフィックの安定性／コミット可能な期間／SLA要件

  • 「不要なトークンを減らしたい」→ プロンプト・コンテキスト最適化

    • トークン推定/追跡：CloudWatchメトリクスで入出力トークン数を可視化、コストドライバーを特定
    • コンテキストウィンドウ最適化：上位k件の検索結果に絞る／重複情報の除去
    • 応答サイズ制限：max_tokens を適切に設定して出力の冗長性を抑制
    • コンテキストプルーニング：会話履歴のうち古い・関連性の低い部分を切り捨て
    • 判別軸：コスト構造（入力 vs 出力のどちらが支配的か）

  • 「クエリ複雑度でモデルを使い分けたい」→ 階層化されたFM（tiered FMs）

    • 軽量モデル（Haiku / Nova Micro）→ 中型（Sonnet / Nova Lite）→ 強力モデル（Opus / Nova Pro）の階層構成
    • 入力の複雑度・信頼度で動的にティアを選択
    • 価格対性能比（cost per quality point）を継続測定して構成を更新
    • 判別軸：クエリのばらつき／許容できる品質低下幅
    • 実装パターン：
      1. Lambda で複雑度スコアリング：トークン数・質問数・「比較」「分析」等のキーワード・過去の信頼度スコアを組み合わせて 0.0〜1.0 のスコアを算出
      2. Step Functions Choice ステートで振り分け：score < 0.3 → Haiku/Nova Micro、score < 0.7 → Sonnet/Nova Lite、score >= 0.7 → Opus/Nova Pro
      3. 信頼度による自動昇格（オプション）：軽量モデルの出力信頼度が閾値を下回った場合、上位ティアへ自動エスカレーション
      • Task 2.2 のモデルカスケード戦略と同構成。コスト最適化文脈での再登場
      • AWSサービス構成：Lambda（判定）→ Step Functions Choice（振り分け）→ Bedrock InvokeModel（呼び出し）→ ElastiCache/DynamoDB（キャッシュ）→ CloudWatch（コスト監視）

  • 「同じ問いの繰り返しを止めたい」→ 多層キャッシュ戦略

    • セマンティックキャッシュ：類似クエリをベクトル検索でヒットさせ、Redis等から応答（後述）
    • 決定論的リクエストハッシュ：完全一致クエリはハッシュキーでDynamoDB/ElastiCacheから即返却
    • エッジキャッシュ：CloudFront で共通の問い合わせ応答をエッジ配信、レイテンシも削減
    • 判別軸：クエリの重複パターン（完全一致 / 類似）／地理分散

読むべき公式ドキュメント

ページ 確認すべきポイント
プロンプトキャッシング キャッシュ対象（システムプロンプト・ツール定義・ドキュメント）・TTL・対応モデル・コスト削減率
Batch推論（バッチAPI） S3インプット → 非同期処理 → S3アウトプット。最大50%コスト削減の条件
Provisioned Throughput モデルユニット・コミット期間（1か月/6か月）の計算方法とオンデマンドとのコスト比較
プロンプト最適化のライフサイクルガイダンス プロンプト圧縮・コンテキスト管理・コスト効率化の推奨パターン

⚠️ コスト最適化の優先順位（試験での判断軸）

  1. まず不要なトークンを削る（プロンプト最適化）
  2. 同一プロンプトが繰り返されるなら → Prompt Caching
  3. 非同期で大量処理できるなら → Batch API
  4. 高頻度・安定トラフィックなら → Provisioned Throughput

Task 4.2 ｜ アプリケーションパフォーマンスを最適化する（キャッシュ含む）

試験で問われる判断パターン

  • 「まったく同じ質問への重複FMコールを防ぎたい」→ セマンティックキャッシュ（ElastiCache Redis）

    • クエリをエンベディング化 → Redis のベクター検索で類似クエリを探す → 閾値以上ならキャッシュ応答返却（FM呼び出しスキップ）
    • 単純なハッシュキャッシュと違い、「言い回しが違う同義質問」もヒットさせられる
    • 判別軸：類似質問の頻度（FAQ・カスタマーサポート等で効果大）

  • 「会話履歴・セッション状態の保持」→ DynamoDB（TTL付き）

    • セッションIDをキーに会話履歴を保存、TTL で自動失効
    • 単一テーブル設計でユーザー設定・会話履歴・キャッシュを統合管理可能
    • 判別軸：保持期間／クエリパターン（GSIで横断検索が必要か）

  • 「予測可能なクエリのレイテンシを下げたい」→ 事前計算 + レイテンシ最適化推論

    • 事前計算（pre-computation）：定型FAQやレポートを夜間バッチで作成 → 利用時はキャッシュ参照のみ
    • レイテンシ最適化版モデル：Bedrock の一部モデル（Claude / Llama 等）で Latency-Optimized を選択すると応答時間が短縮
    • 判別軸：応答内容の予測可能性／コスト許容度（最適化版は若干高め）

  • 「複雑なワークフローを高速化」→ 並列リクエスト + 応答ストリーミング

    • 独立したサブタスク（例：3観点の要約）を Step Functions Parallel または Lambda 並列起動 で同時実行 → 合算レイテンシを削減
    • 応答ストリーミング：実時間は変わらなくても、TTFB（最初の文字が出るまでの時間）を短縮し体感レイテンシを大幅改善
    • 判別軸：処理の依存関係（並列化可能か）／UX 重視点

  • 「検索系の精度と速度を両立」→ インデックス最適化 + クエリ前処理 + ハイブリッド検索

    • インデックス最適化：シャード数・refresh_interval・HNSWパラメータ（ef_construction, M値）の調整
    • クエリ前処理：不要語除去・正規化・スペル補正で検索ノイズ削減
    • ハイブリッド検索 + カスタムスコアリング：BM25とベクトルの重みを調整（業務領域に応じた最適化）
    • 判別軸：精度ボトルネック（索引 / クエリ / 重み）

  • 「スループットを上げたい」→ バッチ推論 + 同時呼び出し管理

    • 複数リクエストをまとめて処理する バッチ推論 でGPU使用率を最大化
    • 同時呼び出し管理：セマフォ・キュー深度監視で並列数を最適化（過剰並列はスロットリング誘発）
    • 判別軸：レイテンシ vs スループットのトレードオフ

  • 「動的に容量を変動させたい」→ Auto Scaling

    • SageMaker エンドポイント・ECS タスク等のGenAIワークロード向けにスケーリングポリシーを設定
    • GenAI 特有：スケールアウト遅延（モデルロードに時間がかかる）を考慮した予測スケーリング
    • 判別軸：トラフィック変動パターン／コールドスタート許容度

  • 「ベンチマークで改善を測る」→ A/Bテスト + API プロファイリング

    • A/Bテスト：プロンプト・モデルの新旧を一定比率で並行運用、品質・レイテンシ・コストを比較
    • API call profiling：X-Ray で各APIコールのレイテンシ分布を可視化、ボトルネック特定
    • 判別軸：改善前後の効果測定の厳密性／統計的有意性

読むべき公式ドキュメント

ページ 確認すべきポイント
Amazon ElastiCache（Redis） セマンティックキャッシュの基盤。クエリをベクトル化して類似クエリをキャッシュヒットさせる構成
Amazon DynamoDB - TTL設定 セッション・会話履歴の有効期限管理。TTLで自動削除してコスト制御
Bedrock - レイテンシ最適化推論 一部モデル（Claude / Llama等）でレイテンシ最適化版を選択可能
AWS Auto Scaling SageMakerエンドポイント・ECSタスク等のGenAIワークロード向けスケーリング
CloudFront（エッジキャッシュ） 共通の問い合わせ応答をエッジでキャッシュしてレイテンシ削減
Lambda@Edge エッジでの軽量な前後処理

⚠️ セマンティックキャッシュの仕組み

  1. ユーザークエリをエンべディング化
  2. Redis（ベクター検索機能）で類似クエリをキャッシュ検索
  3. 閾値以上の類似度 → キャッシュから応答を返す（FMを呼ばない）
  4. 閾値未満 → FMを呼び出し → 結果をキャッシュに保存

⚠️ パフォーマンス最適化テクニック

テクニック 効果
レイテンシ最適化Bedrockモデル 同一モデルで応答時間短縮
事前計算（pre-computation） 想定問答を先に計算してキャッシュ
並列リクエスト 複雑なワークフローで独立タスクを並列実行
応答ストリーミング 体感レイテンシ削減（実際のTTFB短縮）
バッチ推論 スループット最大化（コストも削減）
Auto Scaling トラフィック変動への自動追従

⚠️ 検索（RAG）側のパフォーマンス改善

  • インデックス最適化：シャード数・refresh_interval・HNSWパラメータ
  • クエリ前処理：不要語除去・正規化
  • ハイブリッド検索＋カスタムスコアリング：BM25とベクトルの重み調整

Task 4.3 ｜ GenAIアプリケーションのモニタリングシステムを実装する

試験で問われる判断パターン

  • 「FMの入出力ログをS3に保存して後で分析したい」→ モデル呼び出しログ設定

    • Bedrockコンソールで ==Model Invocation Logging== を有効化 → 入力プロンプト・出力・モデルID・トークン数等がS3 / CloudWatch Logs に記録
    • Athena でSQLクエリ・QuickSightでダッシュボード化が可能
    • 判別軸：長期保管・分析（S3）／リアルタイム検索（CloudWatch Logs）

  • 「エージェントの処理ステップごとにトレースしたい」→ AWS X-Ray

    • エージェントの「思考 → ツール呼び出し → 観察」の各ステップを 分散トレース として可視化
    • どのステップでレイテンシ・エラーが発生しているか特定
    • 判別軸：エージェント／マルチコンポーネント構成のデバッグ

  • 「トークン使用量・エラーレートをダッシュボードで見たい」→ CloudWatch カスタムメトリクス

    • Bedrock の デフォルトメトリクス（InvocationLatency・InvocationClientErrors 等）に加え、Lambda から カスタムメトリクス（入出力トークン数・ユーザー別利用量等）を発行
    • CloudWatch Dashboards / Managed Grafana で可視化
    • 判別軸：標準メトリクスで十分か／業務固有KPI（コスト按分・SLA）が必要か

  • 「ハルシネーション率・応答ドリフトの異常検知」→ ゴールデンデータセット + CloudWatch 異常検出

    • ゴールデンデータセット（人間が正解を作った既知のQ&Aペア）に対して定期的に推論 → 一致率を継続記録
    • CloudWatch 異常検出：機械学習で正常範囲を自動学習、バーストやドリフトを検知
    • 判別軸：品質低下の判定方法（絶対基準 / 統計的偏差）

  • 「ツール（Action Group / MCP）の利用状況を監視」→ コールパターン追跡

    • ツール呼び出し成功率・失敗パターン・平均応答時間 を CloudWatch カスタムメトリクスで収集
    • 不要なツール呼び出し・不適切な使い方をパターン分析
    • 判別軸：エージェント運用の最適化／ツール定義の見直し判断

  • 「ベクトルストアの健全性を監視」→ ベクトルDB専用メトリクス

    • クエリレイテンシ・インデックスサイズ・再構築頻度・キャッシュヒット率 をモニタ
    • OpenSearch Dashboards / Aurora の Performance Insights で深掘り
    • 判別軸：RAG精度劣化の原因切り分け（モデル / 検索 / 索引）

  • 「マルチエージェント協調の追跡」→ X-Ray Subsegments + カスタムメトリクス

    • スーパーバイザー → サブエージェント の委譲を Subsegment で記録、エージェントIDをアノテーション
    • エージェント間の依存・ボトルネックを可視化
    • 判別軸：マルチエージェント運用／責任所在の特定

  • 「コスト異常検知」→ AWS Cost Anomaly Detection

    • 機械学習で通常のコストパターンを学習 → スパイクを自動検知してSNS通知
    • 「Bedrock 使用量が突然3倍」「特定モデルだけ急増」などを早期発見
    • 判別軸：固定アラート vs 機械学習ベース／コスト粒度（サービス / タグ）

読むべき公式ドキュメント

ページ 確認すべきポイント
Bedrockのモニタリング（CloudWatchメトリクス） Bedrockがデフォルトで送信するCloudWatchメトリクス一覧（レイテンシ・エラー率等）
CloudWatch - カスタムメトリクスの発行 Lambda等から幻覚率・キャッシュヒット率等の独自メトリクスをCloudWatchに送る方法
AWS X-Ray エージェントパイプラインの分散トレーシング。どのステップでレイテンシが発生しているか特定
CloudWatch 異常検出 メトリクスの正常範囲を機械学習で学習。バースト・ドリフトの自動検知
AWS Cost Anomaly Detection コスト急増を自動検知。Bedrock使用量のスパイク監視
Amazon Managed Grafana CloudWatch・Prometheus等を横断したダッシュボード
CloudWatch Logs Insights プロンプト／応答ログのクエリ分析
SageMaker Model Monitor 推論データ／予測のドリフト・バイアス・品質を定期的に監視

⚠️ GenAI観測すべきKPI

カテゴリ メトリクス サービス
コスト 入力／出力トークン、Provisioned Throughput使用率 CloudWatch + Cost Anomaly Detection
パフォーマンス レイテンシ、TTFB、エラー率 CloudWatch + X-Ray
品質 ハルシネーション率、グラウンディングスコア カスタムメトリクス + ゴールデンデータセット差分
セキュリティ Guardrails ブロック率、プロンプト攻撃検出件数 CloudWatch Logs Insights
ツール／エージェント ツール呼び出し成功率、エージェント反復回数 X-Ray + カスタムメトリクス
ベクトルストア クエリレイテンシ、インデックスサイズ、再構築時間 CloudWatch + OpenSearch dashboards

⚠️ GenAI固有のトラブルシューティング手法

  • ゴールデンデータセット差分：既知の入出力ペアとの一致率でハルシネーション検出
  • 出力差分（output diff）：プロンプト微変更時の応答一貫性を比較
  • 推論パストレース：CoTの中間ステップを記録して論理エラーを特定

Domain 5: テスト・検証・トラブルシューティング（11%）

Task 5.1 ｜ GenAI評価システムを実装する

試験で問われる判断パターン

  • 「RAGシステムの回答品質を測りたい」→ 3指標で多面評価

    • Faithfulness（忠実性）：回答がKBの内容に忠実か。低い → グラウンディング不足・幻覚あり
    • Answer Relevance（関連性）：質問に対して回答が的確か。低い → プロンプト設計・出力指示の問題
    • Context Precision（コンテキスト精度）：検索されたチャンクが本当に必要なものか。低い → チャンキング・インデックス設定の問題
    • 判別軸：失敗箇所の切り分け（検索 / 生成 / プロンプト）

  • 「モデル間を定量比較したい」→ Bedrock Model Evaluation（自動評価ジョブ）

    • ROUGE（N-gram重複）・BERTScore（意味的類似度）・正確性等の 数値指標 で参照回答との一致度を測る
    • 複数モデルを同条件で評価し、コストと品質のトレードオフを定量化
    • 判別軸：参照回答が用意できる／客観指標で十分

  • 「人間の評価者を使いたい」→ Bedrock Model Evaluation（人間評価ジョブ）

    • プライベートワーカー（社内）またはAWS提供チームに、UI上で品質を採点させる
    • 「親しみやすさ」「業務適合性」など主観的な品質を評価
    • 判別軸：主観品質が重要／自動指標では捉えられない側面

  • 「別のFMに評価させたい」→ LLMジャッジ評価（LLM-as-a-judge）

    • 別のFMを審査員として使い、流暢性・正確性・関連性・公平性を 大量サンプル に対し自動評価
    • 人間評価より速く・安く・スケール可能（ただし審査FM自体のバイアスに注意）
    • 判別軸：評価規模（数千〜数万件）／コスト

  • 「本番リリース前のリスク管理」→ A/Bテスト + カナリアテスト

    • A/B テスト：旧バージョン50% / 新バージョン50% の並行運用で 統計的に効果を比較
    • カナリアテスト：新バージョンに 5% → 25% → 100% と段階的にトラフィックを増やす（リスク最小化）
    • 判別軸：効果比較重視（A/B）／リスク最小化重視（カナリア）

  • 「ユーザーフィードバックを評価に反映」→ アノテーション + フィードバックUI

    • Amazon Augmented AI（A2I）：HITL（ヒューマン・イン・ザ・ループ）のレビューワークフロー
    • SageMaker Ground Truth：大規模アノテーション（プライベートワーカー / Mechanical Turk）
    • 「いいね/よくない」ボタンや評価コメントを収集し、Fine-tuning データや評価セットに還元
    • 判別軸：データ量（少量 → A2I／大量 → Ground Truth）

  • 「エージェントの実行品質を測る」→ エージェント特化メトリクス

    • タスク完了率：ゴールに到達した割合
    • ツール使用効率：正しいツールを最小回数で呼べたか（無駄なツール呼び出しがないか）
    • 多段推論の論理整合性：CoT で論理破綻がないか
    • 平均ステップ数：余計な反復をしていないか
    • 判別軸：エージェント運用の改善対象（精度 / 効率 / 安定性）

  • 「検索品質を独立して測る」→ 検索フェーズ単体の評価

    • 関連性スコアリング：上位k件にGold Documentが含まれる割合（Recall@k）
    • コンテキストマッチ検証：検索チャンクが回答生成に実際に使われたか（引用率）
    • 検索レイテンシ：p50 / p99 でSLA達成を確認
    • 判別軸：RAG全体の評価では原因切り分けが困難 → 検索だけ独立で測る

  • 「デプロイ時の回帰を防ぐ」→ 合成ユーザーワークフロー + 自動品質ゲート

    • CloudWatch Synthetics（カナリア）：合成ユーザースクリプトで重要シナリオを定期実行 → デプロイ後すぐに不具合検知
    • 自動品質ゲート：CodePipeline に評価ジョブを組み込み、メトリクスが閾値割れなら自動ロールバック
    • 判別軸：デプロイ頻度／回帰検知の自動度

読むべき公式ドキュメント

ページ 確認すべきポイント
Model Evaluation - 評価タイプの比較 自動評価・人間評価・LLMジャッジの3種類の使い分けと適したユースケース
評価指標の詳細 ROUGE（N-gram重複）・BERTScore（意味的類似度）・正確性の定義と計算方法
LLMジャッジ評価 別のFMをジャッジモデルとして使う設定。評価次元（流暢性・正確性・関連性等）の定義
自動評価ジョブの作成 データセット（プロンプト＋参照回答）・モデル・指標を設定してジョブ起動
Bedrock - エージェント評価 エージェントのタスク完了率・ツール使用効率・推論品質の評価
Amazon Augmented AI（A2I） ヒューマン・イン・ザ・ループのレビューワークフロー
SageMaker Ground Truth 大規模アノテーションタスクの管理。プライベートワーカー／Mechanical Turk
CloudWatch Synthetics カナリアスクリプトで合成ユーザーワークフローを定期実行。デプロイ後の品質ゲート
SageMaker Clarify - LLM評価 FMの説明可能性・バイアス・有害性を自動評価

⚠️ 比較ポイント：RAG評価の3指標

指標 評価内容 低い場合の原因
Faithfulness 回答がKBの内容に忠実か グラウンディングが弱い・幻覚
Answer Relevance 質問に対して回答が的確か プロンプト設計の問題
Context Precision 検索されたチャンクが正確か チャンキング・インデックス設定の問題

⚠️ A/B vs カナリア テスト

方式 内容 適したケース
A/B テスト 一定割合で2バージョンを並行運用 効果比較・統計的有意性
カナリアテスト 新バージョンに段階的にトラフィックを増やす リスク最小化での本番投入

⚠️ エージェント評価のメトリクス

指標 評価内容
タスク完了率 与えられたゴールに到達した割合
ツール使用効率 正しいツールを最小回数で呼べたか
推論品質 多段推論で論理破綻がないか
平均ステップ数 余計な反復をしていないか

⚠️ 検索品質テストの3軸

  1. 関連性スコアリング：上位k件にGold Documentが含まれる割合（Recall@k）
  2. コンテキストマッチ検証：検索チャンクが回答生成に実際に使われたか
  3. 検索レイテンシ：p50 / p99 で評価し、SLA達成を確認

Task 5.2 ｜ GenAIアプリケーションをトラブルシューティングする

試験で問われる判断パターン

  • 「回答が途中で切れる」→ コンテキストウィンドウ超過の対処

    • 原因：入力＋出力の合計トークンがモデル上限を超えている、または max_tokens が小さい
    • 対策：上位k件を絞る／チャンクサイズを小さく／長コンテキストモデルへ変更／動的チャンク戦略（入力長に応じてチャンク数を調整）
    • 判別軸：原因（入力過多 / 出力打ち切り）

  • 「ThrottlingException が多発」→ Provisioned Throughput or リトライ戦略

    • 短期的対処：AWS SDK の 指数バックオフ（Adaptive retry mode）でリトライ
    • 中長期：高頻度なら Provisioned Throughput に移行、または Batch API で非同期化
    • 判別軸：発生頻度・継続性／コスト許容度

  • 「RAGの検索精度が低い」→ 構成要素を順に見直し

    • チャンキング戦略：固定サイズ → セマンティック / 階層に変更
    • エンベディングモデル：多言語非対応モデル使用？ドメイン不適合？ → 別モデルへ
    • リランキング：Bedrock Rerank を導入して順序問題を解決
    • ハイブリッド検索：BM25 と組み合わせて専門用語ヒット率向上
    • 判別軸：問題の起点（チャンク粒度 / 埋め込み / 順序）

  • 「エージェントが無限ループする」→ 反復制御とツール定義の見直し

    • 最大反復回数：Bedrock Agent / Step Functions で MaxIterations 設定
    • ツール定義の明確化：曖昧な OpenAPI description を改善 → 「いつ呼ぶか」をモデルに伝わるように
    • 判別軸：暴走パターン（反復過多 / ツール選択ミス）

  • 「埋め込み品質が悪化している（ドリフト）」→ 埋め込みドリフト診断

    • 埋め込み品質診断：既知の類似質問ペアでcos類似度をベースラインと比較
    • ベクトル化問題の修復：トークナイザの不一致・モデル更新の影響を確認
    • エンベディングモデル再評価：必要に応じて新モデルへ移行し全データ再ベクトル化
    • 判別軸：ドリフトの原因（モデル変更 / データ分布変化）

  • 「JSON出力が崩れる」→ スキーマ検証 + 構造化出力

    • Lambda で JSON Schema バリデーション を実施 → フォーマット不一致を自動検出
    • Converse API の Response Format で JSON Schema を指定 → モデル側でも形式を強制
    • 失敗時は リトライ or フォールバック を実装
    • 判別軸：下流の厳密性／許容できる失敗率

  • 「プロンプトをバージョン横断で観測したい」→ プロンプトオブザーバビリティパイプライン

    • 入力ログ：CloudWatch Logs にプロンプトID・本文・バージョンを記録
    • トレース：X-Ray のアノテーションにプロンプトID／バージョンを付与 → 横断的に追跡
    • メトリクス：応答品質・フォーマット不一致回数を CloudWatch カスタムメトリクスへ
    • アラート：閾値割れ時に SNS / EventBridge で通知
    • 判別軸：プロンプト変更頻度／品質回帰の発見速度

  • 「プロンプトが混乱して支離滅裂」→ ログパターン分析 + テンプレートテスト

    • CloudWatch Logs Insights：クエリで失敗パターン（一定の入力で常に崩れる等）を抽出
    • テンプレートテスト：プロンプトテンプレートに対し境界値・極端入力でテストスイートを実行
    • 判別軸：失敗の再現性（特定パターン / ランダム）

読むべき公式ドキュメント

ページ 確認すべきポイント
Bedrockのエラーコード一覧 ThrottlingException・ModelTimeoutException・ValidationError等の原因と対処法
エージェントのテスト・トレース コンソールでエージェントの各ステップ（思考・ツール呼び出し・回答）をトレースする方法
Knowledge Base - トラブルシューティング データ取り込み失敗・検索で正しいチャンクが返らない場合の確認ポイント
Flowsのテスト ノードごとの入出力を確認してどこで問題が起きているか特定する方法
SageMaker Model Monitor - ドリフト検出 データ分布のドリフトを検出。埋め込みドリフトの監視に応用
JSON Schema バリデーション（jsonschema） Lambdaで出力フォーマット検証する標準的なアプローチ
X-Ray セグメント・サブセグメント プロンプトIDをアノテーション付与してオブザーバビリティパイプラインを構築

⚠️ 検索系トラブルの切り分けフロー

  1. 埋め込み品質診断：既知の類似質問ペアでcos類似度をベースラインと比較
  2. ベクトル化問題の修復：トークナイザの不一致・モデル更新の影響を確認
  3. ドリフトモニタリング：Model Monitorで埋め込み分布の異常検知
  4. チャンク化と前処理の修復：境界・前後文脈の確認
  5. ベクトル検索パフォーマンス：HNSWパラメータ・シャード再配置

⚠️ プロンプトオブザーバビリティパイプライン構成

  • 入力ログ：CloudWatch Logs にプロンプトIDと本文
  • トレース：X-Ray にプロンプトID／バージョンをアノテーション
  • メトリクス：応答品質スコア／フォーマット不一致回数 を CloudWatch カスタムメトリクス
  • アラート：閾値割れ時に SNS／EventBridge で通知

公式ドキュメント早引き一覧

サービス・機能 URL
Amazon Bedrock（全体） what-is-bedrock
Bedrockモデル一覧 models-supported
Knowledge Bases knowledge-base
Agents agents
AgentCore（新機能） agentcore
Guardrails guardrails
Flows flows
Prompt Management prompt-management
Prompt Caching prompt-caching
Fine-tuning / CPT custom-models
Model Evaluation model-evaluation
Data Automation（新機能） data-automation
Rerank（リランキング） rerank
Batch推論 batch-inference
クロスリージョン推論 cross-region-inference
ストリーミング推論 InvokeModelWithResponseStream
OpenSearch - k-NN knn
OpenSearch - Neural Search neural-search
Step Functions × Bedrock connect-bedrock
Amazon Q Business amazonq-business
Amazon Q Developer amazonq-developer
SageMaker Model Cards model-cards
SageMaker Model Registry model-registry
SageMaker Model Monitor model-monitor
AWS Glue Data Quality glue-data-quality
AWS Lake Formation lake-formation
AWS Well-Architected GenAI Lens generative-ai-lens
RAG 選択ガイド（Prescriptive Guidance） rag-options
プロンプトエンジニアリング BP（Prescriptive Guidance） llm-prompt-engineering-best-practices

試験対象 AWS サービス・機能（カテゴリ別チェックリスト）

公式試験ガイドの「試験対象の AWS のサービスと機能」セクションに基づく。試験で名前が出てくる可能性のあるサービスをカテゴリ別に網羅。

分析
Amazon Athena ・ Amazon EMR ・ AWS Glue ・ Amazon Kinesis ・ Amazon OpenSearch Service ・ Amazon QuickSight ・ Amazon MSK

アプリケーション統合
Amazon AppFlow ・ AWS AppConfig ・ Amazon EventBridge ・ Amazon SNS ・ Amazon SQS ・ AWS Step Functions

コンピューティング
AWS App Runner ・ Amazon EC2 ・ AWS Lambda ・ AWS Lambda@Edge ・ AWS Outposts ・ AWS Wavelength

コンテナ
Amazon ECR ・ Amazon ECS ・ Amazon EKS ・ AWS Fargate

カスタマーエンゲージメント
Amazon Connect

データベース
Amazon Aurora ・ Amazon DocumentDB ・ Amazon DynamoDB ・ DynamoDB Streams ・ Amazon ElastiCache ・ Amazon Neptune ・ Amazon RDS

デベロッパーツール
AWS Amplify ・ AWS CDK ・ AWS CLI ・ AWS CloudFormation ・ AWS CodeArtifact ・ AWS CodeBuild ・ AWS CodeDeploy ・ AWS CodePipeline ・ AWS SDK ・ AWS X-Ray

機械学習
Amazon Augmented AI（A2I）・ Amazon Bedrock ・ Amazon Bedrock AgentCore ・ Amazon Bedrock ナレッジベース ・ Amazon Bedrock Prompt Management ・ Amazon Bedrock Prompt Flows ・ Amazon Comprehend ・ Amazon Kendra ・ Amazon Lex ・ Amazon Q Business ・ Amazon Q Business Apps ・ Amazon Q Developer ・ Amazon Rekognition ・ Amazon SageMaker AI ・ SageMaker Clarify ・ SageMaker Data Wrangler ・ SageMaker Ground Truth ・ SageMaker JumpStart ・ SageMaker Model Monitor ・ SageMaker Model Registry ・ SageMaker Neo ・ SageMaker Processing ・ SageMaker Unified Studio ・ Amazon Textract ・ Amazon Titan ・ Amazon Transcribe

マネジメントとガバナンス
AWS Auto Scaling ・ AWS Chatbot ・ AWS CloudTrail ・ Amazon CloudWatch ・ CloudWatch Logs ・ CloudWatch Synthetics ・ AWS Cost Anomaly Detection ・ AWS Cost Explorer ・ Amazon Managed Grafana ・ AWS Service Catalog ・ AWS Systems Manager ・ AWS Well-Architected Tool

移行と転送
AWS DataSync ・ AWS Transfer Family

ネットワークとコンテンツ配信
Amazon API Gateway ・ AWS AppSync ・ Amazon CloudFront ・ Elastic Load Balancing ・ AWS Global Accelerator ・ AWS PrivateLink ・ Amazon Route 53 ・ Amazon VPC

セキュリティ、アイデンティティ、コンプライアンス
Amazon Cognito ・ AWS Encryption SDK ・ IAM ・ IAM Access Analyzer ・ IAM Identity Center ・ AWS KMS ・ Amazon Macie ・ AWS Secrets Manager ・ AWS WAF

ストレージ
Amazon EBS ・ Amazon EFS ・ Amazon S3 ・ S3 Intelligent-Tiering ・ S3 ライフサイクルポリシー ・ S3 クロスリージョンレプリケーション

⚠️ 太字は試験で特に頻出と推定されるGenAI関連サービス。

試験対象外 AWS サービス（混乱注意）

以下は試験対象「外」。問題文に登場した場合は引っかけの可能性が高い：

  • 機械学習：AWS DeepComposer ・ AWS DeepRacer ・ Amazon DevOps Guru ・ Amazon Forecast ・ Amazon Fraud Detector ・ Amazon HealthLake ・ Lookout 系 ・ Monitron ・ Panorama
  • データベース：Amazon Redshift ・ Amazon Keyspaces ・ Amazon QLDB ・ Amazon Timestream
  • 分析：AWS Clean Rooms ・ Amazon DataZone ・ Amazon FinSpace
  • セキュリティ：Amazon GuardDuty ・ AWS Security Hub ・ AWS Shield ・ AWS Network Firewall ・ AWS Firewall Manager
  • ストレージ：Amazon FSx 系 ・ AWS Backup ・ Amazon S3 Glacier ・ AWS Storage Gateway
  • メディア：AWS Elemental 系 ・ Amazon Kinesis Video Streams
  • フロントエンド：Amazon Pinpoint ・ AWS Device Farm
  • その他：Amazon Braket ・ AWS RoboMaker ・ AWS Ground Station

試験概要（公式試験ガイドより）

項目 内容
試験コード AIP-C01
バージョン 1.0
出題形式 択一選択 / 複数選択 / 並べ替え / 内容一致
採点対象問題 65問
採点対象外問題 10問（ベータ統計取得用）
採点方式 合否判定（補整スコアリング、セクション別合格ラインなし）
合格スコア 750（100〜1,000スケール）
推奨経験 プロダクション規模アプリ構築2年以上＋GenAI実装1年
試験対象外 モデル開発/学習・高度ML手法・データ／特徴量エンジニアリング

⚠️ 並べ替え問題への対応
「3〜5つのステップを正しい順序に並べる」問題が登場する。RAG構築フロー（チャンク化→埋め込み→インデックス→検索→生成）、エージェントReActサイクル（思考→行動→観察）、Fine-tuningライフサイクル（データ準備→学習→評価→Registry登録→デプロイ）等を順序で覚えておく。

⚠️ 内容一致問題への対応
「サービス名 ↔ 用途」「指標 ↔ 評価対象」のペア問題が出る可能性。本資料の各セクションの「比較ポイント」表を口頭で言えるように。

試験頻出 AWS サービス用語一覧（早引き）

用語 一行説明
Amazon Bedrock マネージドFM呼び出しの中心サービス
Bedrock AgentCore エージェントランタイム・メモリ・MCP統合のマネージド層
Bedrock ナレッジベース マネージドRAG基盤
Bedrock Prompt Management プロンプトのバージョン管理・承認・デプロイ
Bedrock Prompt Flows ノードベースGenAIワークフロー（ノーコード）
Bedrock Guardrails 入出力安全制御（コンテンツフィルタ・PII・グラウンディング）
Bedrock Data Automation 非構造化データの自動抽出パイプライン
Bedrock Model Evaluation 自動／人間／LLMジャッジ評価
Bedrock クロスリージョン推論 リージョン間の自動フェイルオーバー推論
Amazon Titan AmazonネイティブのFM（テキスト・埋め込み・画像）
SageMaker JumpStart OSS FM（Llama等）の簡易デプロイ
SageMaker Model Registry カスタムモデルのバージョニング・承認管理
SageMaker Clarify バイアス検出・モデル説明可能性
SageMaker Model Monitor データ／予測のドリフト監視
SageMaker Data Wrangler データ準備のGUIツール
SageMaker Ground Truth アノテーション管理
Amazon Q Business エンタープライズ向けAIアシスタント
Amazon Q Developer 開発者向けコーディング支援AI
Amazon Comprehend NLP（PII検出・感情・分類）
Amazon Kendra エンタープライズ検索（RAGの前段で利用可）
Amazon Textract スキャンPDF/画像→テキスト
Amazon Transcribe 音声→テキスト
Amazon Rekognition 画像・動画分析
Amazon Augmented AI（A2I） ヒューマンレビューワークフロー
AWS Glue Data Quality データ品質ルール・自動検証
AWS Glue Data Catalog データソース集中レジストリ
AWS Lake Formation きめ細かいデータアクセス制御
AWS Step Functions サーバーレスワークフロー
Amazon EventBridge イベント駆動統合
Amazon AppFlow SaaS連携データ転送
AWS AppConfig 動的設定管理
AWS Outposts オンプレ向けAWS延伸
AWS Wavelength 5Gエッジデプロイ
AWS Amplify フルスタックフロントエンド開発
Amazon Cognito ユーザー認証・SSO
IAM Identity Center エンタープライズSSO
AWS WAF Webレイヤ防御
AWS Secrets Manager 機密情報管理
AWS KMS 暗号鍵管理
AWS Cost Anomaly Detection コスト異常検知
Amazon Managed Grafana 観測ダッシュボード
CloudWatch Synthetics 合成ユーザー監視
MCP（Model Context Protocol） エージェント↔ツール標準プロトコル
Strands Agents コードファーストエージェントFW
AWS Agent Squad マルチエージェントオーケストレーター
LoRA / PEFT パラメータ効率の良い微調整手法
LLM-as-a-judge 別FMで自動評価する手法

AIP-C01 v1.0 対応 ｜ 2026年5月（公式試験ガイド準拠で全タスク・スキルを網羅）

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?