AI-901 Responsible AI Page 01 — Fairness + 概念導入

【正解: A】の理由
Microsoft の Responsible AI Standard は、Fairness (公平性) / Reliability and safety (信頼性と安全性) / Privacy and security (プライバシーとセキュリティ) / Inclusiveness (包括性) / Transparency (透明性) / Accountability (説明責任) の 6 原則を定義しています。Azure AI Foundry での開発・運用も、この 6 原則に沿った設計判断が求められます。

【他選択肢が違う理由】

• B: 性能 / コスト系の指標であり、Responsible AI 原則ではありません。
• C: 機械学習モデルの評価指標であり、原則とは異なる概念です。
• D: ISO/IEC 25010 ソフトウェア品質特性であり、AI 倫理原則ではありません。

【正解: B】の理由
Fairness 原則は、AI システムが個人の属性に基づき不当な差別や不平等な扱いを生じさせないことを目的とします。具体的には、訓練データの代表性確保 / グループ別性能評価 / バイアス緩和ツール (Fairlearn) の活用が求められ、Azure AI Foundry の Responsible AI dashboard でも disparity 指標を継続的に監視できます。

【他選択肢が違う理由】

• A: パフォーマンスの均一化は信頼性の話で、公平性の中核ではありません。
• C: 開発コストの社内配分は組織運営の問題で、Responsible AI 原則ではありません。
• D: 料金体系のことであり、公平性原則の対象ではありません。

【正解: C】の理由
機械学習モデルは訓練データから統計的パターンを学習するため、過去の人事判断に含まれる歴史的バイアスをそのまま再現してしまいます。これはデータ起源のバイアスと呼ばれ、Fairness で最も注意すべきリスクです。代表性のあるデータ収集 / 属性間性能評価 / Fairlearn 等での緩和が必要となります。

【他選択肢が違う理由】

• A: デプロイ設定の誤りは可用性問題で、特定グループへの偏向結果は生じません。
• B: レイテンシは速度の問題で、判定結果のバイアスとは無関係です。
• D: クォータ制限は処理停止を起こすだけで、バイアスは生まれません。
• E: 認証エラーであり、バイアスとは無関係です。

【正解: B】の理由
Fairness の評価は、全体精度だけでは不十分で、性別 / 年齢 / 地域などの属性グループ別の性能差を計測する必要があります。Fairlearn は selection rate や false positive rate などをグループ別に比較できる OSS ツールで、Azure AI Foundry の Responsible AI dashboard / scorecard と統合されています。

【他選択肢が違う理由】

• A: 全体精度が高くても特定グループに対し低性能となる可能性があり、不十分です。
• C: API レイヤーの可用性指標で、Fairness とは無関係です。
• D: プロンプト長は出力品質の話で、公平性評価ではありません。

【正解: A, C】の理由
Fairness 改善はデータ層 (代表性の確保) と学習層 (緩和アルゴリズム) の両方で行います。A は不均衡なデータセットでマイノリティ クラスを増強するデータ層の対策、C は Fairlearn の ExponentiatedGradient や ThresholdOptimizer 等で学習・後処理層の disparity を直接緩和する対策で、両者を組み合わせるのが推奨アプローチです。

【他選択肢が違う理由】

• B: 全体精度向上は公平性に寄与せず、特定グループの精度が下がる可能性すらあります。
• D: API パフォーマンスの話で、Fairness とは無関係です。
• E: プロンプト長は出力スタイルの話で、公平性とは無関係です。

【判定: はい】の理由
Responsible AI dashboard はモデルの性能をセンシティブ属性 (地域 / 年齢層など) のグループ別に分解して可視化する標準ツールであり、selection rate / false positive rate / accuracy の disparity を一目で確認できます。Fairlearn ライブラリと統合され、Azure AI Foundry のプロジェクトから直接呼び出せます。グループ間の差を定量化することで、Fairness 評価の第一歩として適切に機能し、その後の緩和策 (データ補強 / 再重み付け / ThresholdOptimizer 等) の必要性判断にも繋がります。

【「いいえ」が違う理由】
本解決策はグループ別性能の計測という Fairness 評価の根幹に直接対応しており、Microsoft が公式に推奨する Responsible AI dashboard を活用しています。デプロイ前のバイアス検出という目的に完全に合致するため、「いいえ」と判定する根拠はありません。

【判定: いいえ】の理由
センシティブ属性カラムを削除しても、郵便番号 / 勤務先 / 取引履歴などの代替変数 (プロキシ変数) を通じてモデルが同じ偏向を学習してしまうため、バイアスは解消されません。これは「fairness through unawareness」と呼ばれる古典的な誤った緩和策で、Microsoft Responsible AI 公式ガイダンスでも非推奨とされています。正しいアプローチは、属性を保持して disparity を計測したうえで Fairlearn 等の緩和アルゴリズムや事後しきい値調整を組み合わせる方法です。

【「はい」が違う理由】
センシティブ属性の削除だけではプロキシ変数経由のバイアスを止められず、結果として地域や年齢層による不均衡が温存されます。むしろ削除により監査時にグループ別性能を再評価できなくなり、Accountability の観点でも不利になります。「目的を満たす」と判定するのは Fairness 評価・緩和の本質を見誤っており、「はい」は適切ではありません。

【判定: はい】の理由
Fairness はデプロイ前の評価だけで終わらず、本番運用中もデータ分布のドリフトに伴って disparity が変化するため、継続的な監視が必須です。Responsible AI scorecard は Azure AI Foundry のプロジェクトから生成でき、グループ別性能 / 公平性指標 / 説明可能性などを定期的にスナップショットとして残せます。しきい値超過時の再評価フローを組み込むことで、長期にわたって Fairness を保証する運用が実現します。

【「いいえ」が違う理由】
継続監視と再評価ループは Microsoft Responsible AI Standard が推奨するベスト プラクティスで、本番運用中の品質維持に直結します。一度の事前評価だけでは新規申込者の属性分布変化や外的要因によるドリフトを捕捉できず、Fairness 保証の不完全さを生むため、「いいえ」と判断する根拠はありません。

【正しい順序】Identify intended use → Identify harms → Measure harms → Mitigate harms の流れです。最初にシステムの用途とステークホルダーを定義し (Identify use)、次にその用途下で起こりうる被害を網羅的に列挙し (Identify harms)、各被害について発生確率と深刻度を測定し (Measure)、最後に Fairlearn / Content Safety / 人間レビュー等の緩和策を実装します。順序を入れ替えると評価の網羅性や優先順位付けが破綻するため、この順番が Microsoft Responsible AI Impact Assessment の標準フローとして定められています。