Amazon SageMaker Clarify｜AIP-C01

ひとことで言うと

データとモデルの「偏り」を、公表済みの標準化された式で数値化し、SHAP で1件ごとの予測の内訳を出す測定器です。公平かどうかの判定はしません。数値を出して人間に渡すところで止まります。

要するに、体組成計です。体脂肪率も筋肉量も骨量も出しますが、「あなたは健康です」とは言いません。しかも Clarify の場合、物差しが何種類もあって、どれを見るかは測る側が決める——公式が「これらの概念はすべてを同時に満たすことはできず、どの指標が自分のユースケースに関係するかを理解し選ぶには人間の判断が必要」と明記しています。指標を選ばずに Clarify を回しても、何も決まりません。

なぜ生まれたか

学習データが特定の層に偏っていれば、モデルはその偏りを学習し、予測で再生産したり増幅したりします。問題は「偏っている気がする」から先へ進めないことでした。公平性には複数の定義があり、定義ごとに別の式が要ります。応募者数を揃えるのか、有資格者の合格率を揃えるのか、拒否率を揃えるのか——どれも「公平」ですが、同時には成立しません。

Clarify がやったのは、この分かれた定義にそれぞれ名前と式と値域を与えて、機械が計算できる形に固定したことです。説明可能性についても同じで、協力ゲーム理論の Shapley 値に基づく SHAP を、スケールする実装として載せています。

その前の不便	Clarify が固定したもの
「偏っている」が主観で終わる	名前・式・値域を持つ指標群（CI、DPL、DPPL、DI ほか）として定義
学習前と学習後で見るものが違うのに区別が曖昧	学習前＝モデル非依存（model-agnostic）／学習後＝予測ラベルが必要と明確に分離
「なぜこの予測になったか」に答えられない	SHAP による特徴量寄与＋PDP（部分依存プロット）
説明が学習時の一度きり	エンドポイントに explainer を積み、推論のたびに説明を返す経路を用意

何に使うか

用途	使い方	関連する試験ドメイン
学習前のデータ偏りの計測	Processing job で pre-training bias metrics（CI / DPL / KL / JS / LP / TVD / KS / CDD）を算出。モデル出力に依存しないのでモデルが存在しなくても走る	D3
学習後のモデル偏りの計測	post-training bias metrics（DPPL / DI / RD / AD / DAR / DRR / DCAcc / DCR / SD / TE / CDDPL / FT / GE）。多くは群ごとの混同行列から作る	D3
予測の説明	SHAP による特徴量寄与（全体の重要度と、1件ごとのローカル説明）＋PDP	D3
画像・テキストの説明	表形式と同じ SHAP アルゴリズムで CV（画像分類・物体検出）と NLP に対応	D3
推論時のリアルタイム説明	`CreateEndpointConfig` に explainer 設定を入れ、`InvokeEndpoint` が予測と説明を一緒に返す	D3
ドリフト監視のベースライン	バイアスドリフト・特徴量寄与ドリフトの constraints ファイルを生成し、Model Monitor が使う	D4 / D5
基盤モデルの評価（FMEval）	かつての担当範囲。公式は Amazon Bedrock Evaluations が置き換えと明記	D5

試験でどう問われるか

Clarify は AIP-C01 の主役ではありません。 この試験は生成AIアプリの実装を問うので、Clarify が単独テーマになる問題は期待できません。出るのは D3.3 / D3.4（ガバナンスと責任あるAI） のシナリオで、「バイアスと説明可能性をどう評価するか」という要件文に対する選択肢の1つとしてです。

そして最も高い確率で出るのは、Clarify が正解ではない側です。生成AI試験なので、シナリオの対象は LLM であることが多く、そのとき正解は Bedrock 側に寄ります。Clarify を正解にするのは「表形式・従来型MLの予測モデル」と書いてあるときだけ、と割り切って構いません。

問われ方	正解に寄る条件	引っかけの選択肢
LLM の出力品質・毒性・堅牢性を評価したい	Bedrock Evaluations（公式が Clarify の FM 評価の置き換えと明記）	Clarify。「バイアス評価＝Clarify」の条件反射で拾わせにくる本命の引っかけ
与信・採用など表形式の予測モデルの公平性を評価したい	Clarify（pre-training / post-training bias metrics）	Bedrock Evaluations（生成AI向けで、予測モデルのバイアス検出の置き換えではないと公式が明記）
「モデルを学習する前にデータの偏りを見たい」	pre-training bias metrics。モデル非依存なのでモデル不要	DPPL・DI などの post-training 指標（予測ラベルが要るので、この時点では計算できない）
「なぜこの申込者が否決されたのか説明せよ」と規制当局に求められた	Clarify の SHAP による特徴量寄与。1件ごとのローカル説明が該当	モデルカード（記録であって、個別予測の理由ではない）／CloudTrail（API 呼び出しの監査であって推論の説明ではない）
推論のたびに説明を返したい	オンライン説明（エンドポイント設定に explainer を追加）	Processing job を都度起動する案（バッチ用の経路）
本番稼働後もバイアスを見続けたい	Model Monitor のバイアスドリフト。Clarify はそのベースラインと計算を担当	Clarify の Processing job を1回だけ回す案（継続監視になっていない）
有害な出力を止めたい	Bedrock Guardrails（実行時のフィルタ）	Clarify。測るのと止めるのは別の層

1問拾える境目: pre-training と post-training を分けるのは「時期」ではなく入力に予測ラベル y’ が要るかどうかです。公式は pre-training 指標を「モデル出力に依存しないので、あらゆるモデルに対して有効」と書いています。したがって学習前でも学習後でも、観測ラベルだけで計算できるものは pre-training 指標。シナリオに「まだモデルを学習していない」「学習データを調達した段階」と書いてあれば、DPPL や Disparate Impact を選ぶ選択肢は自動的に外れます。

実務でどう使うか

Clarify は新規のお客様には提供されていません。公式ドキュメントの全ページ冒頭に「Amazon SageMaker Clarify is no longer open to new customers」と入っており、既存利用者は従来どおり使えるものの、新機能の追加予定は無いと明記されています。試験ガイドの In-Scope サービス表には依然として載っているため、試験対策としては概念と担当範囲を覚える価値がありますが、これから新規に採用する道具ではありません。

置き換え先は「サービス」ではなく部品の組み合わせです。公式が挙げているのは、バイアス指標＝pandas / scikit-learn による直接計算（式が公表された標準的な算術なのでライブラリ依存ではない）、説明可能性＝SHAP ライブラリ（Clarify が内部で使っているのと同じもの）、FM 評価＝fmeval ライブラリまたは Bedrock Evaluations、継続監視＝AWS 公開のオープンソース監視ソリューション＋MLflow＋QuickSight＋CloudWatch。
Clarify の成果物は S3 に残ります。 バイアスレポートの analysis.json、SHAP のローカル値 explanations_shap/out.csv、集約された global SHAP 値、PDP、そして Model Monitor がベースラインに使う constraints ファイル。監査証跡として保持義務がある場合、Clarify をやめてもこの S3 プレフィックスは消さない判断になります。
オンライン説明はタダではありません。 説明リクエストが来るたび、エンドポイント上の explainer がモデルコンテナを呼んで予測を取り、そこから寄与を計算します。つまり推論1回に対してモデル呼び出しが上乗せされる構造です。全リクエストで説明を有効にする設計は、レイテンシとインスタンス消費の両方に効きます。
post-training 指標の「個数」を覚えないこと。 公式本文は eleven（11個）と書いていますが、同じページの一覧表には13個並んでいます。試験で問われるのは名前と意味であって個数ではありません。
facet（バイアスを測る対象の列）と label は自分で指定します。 Clarify は「どの属性が保護属性か」を推論しません。CDD だけは group variable も別途必要です。

取り違えやすいもの

迷う相手	切り分けの一言
Amazon Bedrock Evaluations	生成AI・LLM 用。公式が「Clarify の FM 評価（FMEval）の置き換え」かつ「予測（表形式・従来型ML）のバイアス検出や説明可能性の置き換えではない」と両方書いている。境界はモデルの種類
Amazon Bedrock Guardrails	Guardrails は実行時に止める。Clarify は評価時に測る。同じ「有害性」を扱っても層が違う
Amazon SageMaker Model Monitor	Clarify は1回測る。Model Monitor はスケジュールで測り続ける。ただしバイアスドリフトと特徴量寄与ドリフトの中身は Clarify の計算そのもので、実体は Model Monitor が Clarify を回している
SHAP / fmeval ライブラリ	どちらも Clarify が内部で使っているエンジン。Clarify は「マネージドな Processing job としての皮」であって、アルゴリズムの独自性ではない
SageMaker Model Registry	Registry は版と承認を管理する。Clarify はその版が公平かを測る。Registry は測定結果を持たず、承認の材料として人間が使う

想起チェック

Q1. シナリオに「基盤モデルの出力の毒性と偏りを評価したい」とあります。Clarify を選びますか。

選びません。Bedrock Evaluations（または fmeval）です。 公式が Bedrock Evaluations を Clarify の FM 評価機能の置き換えと明記しており、同時に「予測（表形式・従来型ML）のバイアス検出・説明可能性の置き換えではない」とも書いています。Clarify が正解になるのは後者側です。

Q2. pre-training bias metrics と post-training bias metrics を分ける基準は何ですか。

予測ラベル y’ を使うかどうかです。pre-training はモデル出力に依存しない（model-agnostic）ので、モデルが存在しなくても計算できます。post-training は多くが群ごとの混同行列から作られるため、予測が必要です。

Q3. 「否決理由を個別に説明せよ」という規制要件に対して、Clarify の何が答えになりますか。

**SHAP による1件ごとのローカル説明（特徴量寄与）**です。全体の feature importance や PDP は「モデル全体の傾向」であって、この申込者がなぜ否決されたかには答えていません。

Q4. Clarify を新規プロジェクトで採用する提案が来ました。実務上どう判断しますか。

採用しません。 公式が「新規のお客様には提供されていない／新機能の追加予定は無い」と明記しています。バイアス指標は公表された式なので自前で計算でき、説明可能性は Clarify が内部で使っている SHAP ライブラリを直接使えます。