AIP-C01（AWS Generative AI Developer Professional）の勉強方法を合格者が解説

正解：C

A. 2つのプロンプト設計はPrompt Managementのバージョンとして管理し、機密情報フィルターを有効にしたGuardrailsで生成結果を継続的に検査してデモグラフィックグループごとに介入回数を集計します。集計値をCloudWatchカスタムメトリクスとして発行し、アラームとダッシュボードで監視と週次比較を行います。

不正解 Guardrailsの機密情報フィルターは、入力と応答に含まれる個人を特定できる情報（PII）やカスタム正規表現エンティティを検出してブロックまたはマスクする機能で、グループ間の統計的な公平性を測る仕組みは持ちません。集計できるのは `AWS/Bedrock/Guardrails` ネームスペースのInvocationsIntervenedが示す介入回数だけで、提案の偏りを定量化する指標にはなりません。

B. Bedrockのモデル呼び出しログをS3に出力し、Amazon Comprehendの感情分析で生成された提案文をEventBridge Schedulerから定期的にスコア化してデモグラフィックグループごとに集計します。集計値をCloudWatchカスタムメトリクスとして発行し、アラームとダッシュボードで監視と週次比較を行います。

不正解 Comprehendの感情分析が返すのはPOSITIVE、NEGATIVE、NEUTRAL、MIXEDという支配的な感情の判定と各極性の確信度スコアであり、文章の論調を表す指標です。提案内容がデモグラフィックグループ間でどれだけ偏って分布しているかを表すものではないため、感情スコアを集計しても公平性の比較や不一致の判定軸は得られません。

C. デモグラフィックグループ別の評価用データセットを用意し、組み込みのステレオタイプ指標を使うBedrock Evaluationsの評価ジョブをEventBridge Schedulerで定期起動します。スコア差をCloudWatchカスタムメトリクスとして発行し、アラームとダッシュボードで監視と週次比較を行います。

正解 評価ジョブは評価者モデルがジェネレーターモデルの応答をスコアリングする判定モデル方式で動作し、組み込みメトリクスの `Builtin.Stereotyping` が応答に含まれるステレオタイプの有無を採点します。グループごとのデータセットで同じジョブ定義を回せばスコア差が公平性の指標になり、結果はJSON Lines形式でS3に保存されます。

D. 推論ログをAthenaで抽出し、公平性スコアの算出ロジックをGlueジョブとして記述してEventBridge Schedulerから定期起動し、デモグラフィックグループごとのスコアを求めます。求めたスコアをCloudWatchカスタムメトリクスとして発行し、アラームとダッシュボードで監視と週次比較を行います。

不正解 グループの切り出し、スコアの定義、グループ間の比較までをすべてGlueジョブとして書き起こす構成で、公平性の判定基準そのものを設計し、モデルやプロンプトを変えるたびに検証し直す責任が残ります。マネージドの評価機能を使えばジョブ定義と評価用データセットの用意だけで同じスコアが得られるため、カスタム開発を最小限に抑えるという条件に反します。

全体的な説明

問われている要件

• Amazon Bedrockベースのレコメンデーションで、デモグラフィックグループ間の偏りを検出・測定すること
• 2つのプロンプト設計の間で公平性を比較できること
• 公平性スコアを定期的に収集し、継続的に監視すること
• グループ間のスコアの不一致が12%を超えた場合にアラートを受けること
• カスタム開発の労力を最小限に抑えること

前提知識

Amazon Bedrock Evaluationsについて

• Amazon Bedrock Evaluationsは、モデルやナレッジベースのパフォーマンスを評価する機能です。プログラムによる自動評価、ヒューマンワーカーによる評価、判定モデル（LLM-as-a-judge）を使う評価、LLMベースのRAG評価の4種類のジョブを作成できます
• 判定モデル方式では、評価対象の「ジェネレーターモデル」と採点役の「評価者モデル」という2つのモデルを指定し、評価者モデルがプロンプトと応答のペアごとにスコアと採点理由の説明を返します
• 組み込みメトリクスは11種類あり、品質面の Builtin.Correctness、Builtin.Completeness、Builtin.Faithfulness、Builtin.Relevance などに加えて、責任あるAIの観点として Builtin.Harmfulness（有害性）、Builtin.Stereotyping（ステレオタイプ）、Builtin.Refusal（拒否）が用意されています
• 独自の観点が必要な場合は、判定用プロンプトと評定尺度（数値型または文字列型）を定義するカスタムメトリクスを、1つの評価ジョブにつき最大10個まで作成できます
• 結果はコンソールの評価ページで確認できるほか、ジョブ作成時に指定したS3バケットにJSON Lines形式（.jsonl）で保存され、各レコードに automatedEvaluationResult のスコアが含まれます
• 評価ジョブ自体には繰り返し実行のスケジュール機能がないため、定期実行はEventBridge Schedulerなどからジョブ作成APIを呼び出して構成します

Amazon CloudWatchによる監視について

• CloudWatchは PutMetricData APIやAWS CLIを使って、アプリケーションが算出した値を任意のネームスペースにカスタムメトリクスとして発行できます
• 発行したメトリクスに閾値のアラームを設定すればSNSトピック経由で通知でき、同じメトリクスをダッシュボードに並べれば複数系列の週次比較が行えます

Amazon Bedrock Guardrailsの設計目的について

• Guardrailsはコンテンツフィルター、プロンプト攻撃、拒否トピック、単語フィルター、機密情報フィルター、コンテキストグラウンディングチェックなどで構成されるランタイムの安全装置です
• 機密情報フィルターはPIIやカスタム正規表現エンティティの検出・ブロック・マスクを行う機能で、統計的公平性を測る機能は持ちません。メトリクスは AWS/Bedrock/Guardrails ネームスペースに発行され、InvocationsIntervenedは介入した呼び出しの数を表します

Amazon Comprehendの感情分析について

• 感情分析はテキストの支配的な感情をPOSITIVE、NEGATIVE、NEUTRAL、MIXEDのいずれかで返し、あわせて各極性の確信度スコア（0〜1）を返します
• 判定できるのは文章の論調であり、グループ間で提案内容の分布がどれだけ偏っているかという公平性の観点は測定できません

図による解説

アーキテクチャ図

商品レコメンデーションの入力例と生成された提案文を、デモグラフィックグループ別の評価用データセットとしてS3に格納します（①）。EventBridge Schedulerからスケジュール実行でBedrock Evaluationsの評価ジョブを起動し、判定モデルが Builtin.Stereotyping でグループ別スコアを採点します（②）。評価結果のスコア差をCloudWatchカスタムメトリクスとして発行し（③）、12%超の閾値違反をAlarmが検知して（④）SNSで運用チームへ通知します（⑤）。ダッシュボードでは2つのプロンプト設計を週次で比較します。公平性の採点をマネージドの評価ジョブに任せることで、分析コードを書かずに継続監視できます。

解くための考え方

公平性の測定でまず見極めたいのは、「偏りを表すスコアを誰が計算するのか」という点です。生成AIが返す提案文そのものを採点する必要があるため、テキストの内容を評価できる仕組みが要ります。Amazon Bedrock Evaluationsは判定モデル方式の評価ジョブを提供しており、組み込みメトリクスとして応答に含まれるステレオタイプの有無を採点する Builtin.Stereotyping を持ちます。デモグラフィックグループごとに代表的な入力をまとめたプロンプトデータセットを用意し、同じジョブ定義で評価すれば、グループ別のスコアがそのまま公平性の比較材料になります。プロンプト設計を2つ用意してそれぞれ評価すれば、どちらの設計が偏りにくいかも同じ枠組みで比較できます。 継続監視とアラートの面では、評価ジョブに繰り返し実行のスケジュール機能がないため、EventBridge Schedulerなどから定期的にジョブを起動します。結果はS3にJSON Lines形式で保存され、レコードごとにスコアが入っているので、グループ間のスコア差を取り出して PutMetricData でCloudWatchのカスタムメトリクスとして発行します。あとは12%の閾値でアラームを張ればSNS経由で通知でき、同じメトリクスをダッシュボードに並べれば2つのプロンプト設計の週次レポートになります。 残る候補は判別軸が明確です。ガードレールの機密情報フィルターはPIIの検出とマスクが目的で、介入回数を数えるメトリクスは偏りの大きさを表しません。感情分析が返すのは文章の論調であって、グループ間で提案内容がどれだけ偏っているかという分布の話とは別物です。AthenaとGlueで公平性スコアを組み立てる構成は要件自体は満たせますが、採点ロジックの設計と保守を丸ごと抱えることになり、カスタム開発を最小限にという条件から外れます。マネージドの評価機能に採点を任せ、CloudWatchに監視と可視化を任せる組み合わせが、最も労力の小さい構成になります。 参考資料

• Amazon Bedrock リソースのパフォーマンスを評価する
• 別の LLM-as-a-judge を使用してモデルのパフォーマンスを評価する
• メトリクスを使用してモデルのパフォーマンスを把握する
• カスタムメトリクスを使用してモデル評価ジョブを作成する
• モデル評価ジョブの結果が Amazon S3 に保存される仕組み
• CloudWatch にカスタムメトリクスを発行する
• CloudWatch メトリクスを使用して Amazon Bedrock Guardrails をモニタリングする
• ガードレールを作成する - Amazon Bedrock Guardrails のコンポーネント
• Amazon Comprehend - 感情分析
• Amazon EventBridge Scheduler とは