AI倫理とバイアス

倫理を実務の作業に落とす

AI倫理は原則の一覧として語られることが多く、実務からは遠く感じられます。しかし本章で扱う内容は、いずれも具体的な確認作業に落とせます。

本章の方針は、原則の解説ではなく「何を測り、何を記録し、誰が判断するか」を示すことです。第19章(法規制)と第16章(ガバナンス)と接続しています。

公平性 ― 測らないと分からない

公平性の問題が実務で厄介なのは、出力を見ただけでは偏りが分からないことです。個々の出力は妥当に見えても、集計すると特定の属性に不利な傾向が現れることがあります。

偏りが入る経路

1. 学習データの偏り ― 過去の実績を学習させると、過去の傾向をそのまま再現します。過去の採用実績で学習した仕組みは、過去の偏りを引き継ぎます。
2. データの量の差 ― 特定の属性のデータが少ないと、その属性についての精度が低くなります。
3. 代理変数 ― 属性そのものを入力しなくても、相関する項目(居住地、出身校、勤務歴の空白期間)から間接的に影響が生じることがあります。
4. 評価基準の設定 ― 何を「良い結果」と定義するかに、すでに価値判断が入っています。

3番目が重要です。属性を入力から除外すれば公平になる、というのは誤りです。相関する項目から間接的な影響が生じるため、除外だけでは足りません。

実務的な検証方法

人に対する判断にAIを使う用途では、次の検証を行います。

1. 属性ごとに結果を集計する ― 合格率、判定の分布、精度を属性別に出します。
2. 差があるかを確認する ― 差が業務上正当な理由で説明できるかを検討します。
3. 件数が少ない属性を確認する ― データが少ない属性では精度が低い可能性があります。
4. 継続的に監視する ― 入力データの傾向が変わると、偏りも変わります(第24章)。
5. 検証の記録を残す ― 実施したこと自体が説明の材料になります。

この検証を行わない設計は、偏りがないことを確認していないという状態です。「偏りはないと考えている」は確認ではありません。

説明可能性 ― 何を説明する必要があるか

説明可能性は技術的な難問として語られますが、実務で求められる説明は多くの場合もっと具体的です。分けて考えます。

実務で求められることの多くは、上の3行で満たせます。「AIの内部は説明できない」という理由で、記録や出典の表示を省略するのは筋が違います。説明できる部分は説明する設計にしてください。

用途別の設計方針

• 人に対する判断 ― 判断の根拠を示せる方式を選ぶ。生成系のみで判定する設計は避け、判定に使う要素を明示できる構成にします。
• 社外への回答 ― 出典を必ず表示し、原文を確認できる経路を残します。
• 社内の下書き作成 ― 使用の事実と入力の記録で足ります。

透明性とアカウンタビリティ

AIを使っていることを伝えるか

用途によって判断が分かれます。整理の軸を示します。

• 対話の相手がAIである場合 ― 伝えるのが原則です。人間の担当者と誤認させる設計は避けます。EU AI Act でも透明性の義務として扱われている領域です(第19章)。
• 生成物を公開する場合 ― 分野の慣行と、規制の要求を確認します。報道・広告・学術では扱いが異なります。
• 業務の効率化に使う場合 ― 成果物の責任が自社にあることが明確であれば、個別の表示は必ずしも必要ではありません。ただし社内では記録します。

アカウンタビリティの実装

責任を果たせる状態にするために必要なものは、第16章で扱った記録です。再掲します。

• AIの出力(ログ)
• 人が修正したか、その内容
• 最終的に業務で使った内容
• 判断した担当者

これらがあれば、事後に説明できます。説明責任は、記録の設計とほぼ同義です。

差別的判断の回避と検証

公平性の節と重なりますが、運用として何を行うかを整理します。

用途を分類する

すべての用途に同じ検証は不要です。次に該当する用途を「要検証」として扱います。

• 採用・配置・評価・処遇に関わる判断
• 与信・保険引受・料金設定に関わる判断
• 給付・許認可に関わる判断
• 個人に対する推奨・表示の優先順位付け
• その他、個人の不利益につながり得る判断

要検証の用途で行うこと

1. 属性ごとの結果の集計(前掲)
2. 判断根拠を示せる設計の採用
3. 人による最終判断と、その記録
4. 不服がある場合の申し出の経路
5. 定期的な再検証(データの傾向の変化に対応)

4番目は見落とされがちですが、実務上重要です。結果に疑問を持った人が問い合わせる経路がないと、問題の発見が遅れます。

AI倫理委員会と社内ガイドライン

専門の委員会を設置する形が推奨されることがありますが、規模によっては現実的ではありません。機能から考えます。

必要な機能

1. 高リスクの用途を判定する ― 誰が「これは要検証だ」と判断するか。
2. 検証の実施を確認する ― 属性ごとの集計が行われたかを確認する。
3. 判断の記録を残す ― なぜ許可したか、どの条件を付けたか。
4. 問題が起きたときの対応を決める ― 停止の権限を持つ者を決める。

この4機能は、既存の会議体に割り当てることができます。専門の委員会を作ることが目的ではなく、4つの機能が誰かの責任になっていることが目的です。

形骸化を避ける

「倫理委員会を設置した」ことが実態のない形になる場合があります。実効性の指標を挙げます。

• 過去1年で、条件付き承認または不承認とした案件があるか
• 属性ごとの検証結果が、実際に文書として存在するか
• 停止の判断を行った実績があるか、または権限が明記されているか
• 判定の基準が文書化されており、現場が自分で判定できるか

1番目が最も端的な指標です。すべての案件を承認している委員会は、判定を行っていない可能性があります。

アクセシビリティへの配慮

AIを組み込んだサービスが、障害のある利用者にとって使えるものになっているかという観点です。見落とされやすいため、具体的に扱います。

AIによって改善する面

• 音声の文字化(聴覚に障害のある利用者への情報提供)
• 文章の読み上げ(視覚に障害のある利用者)
• 文章の平易化(理解を助ける)
• 画像の説明文の生成(代替テキスト)
• 操作の音声入力

AIによって悪化し得る面

• 音声のみの対話 ― 音声インターフェースだけを提供すると、利用できない人が生じます。
• 応答時間の変動 ― 処理に時間がかかる場合、待ち時間の状態が伝わらないと操作できません。
• 生成された文章の分かりにくさ ― 冗長な出力、専門用語の多用。
• 画像による情報提供 ― 生成した図表に代替テキストがない場合。
• 認証・確認の手順 ― 追加の操作が負担になる場合。

設計上の原則は、AIを使った機能を唯一の経路にしないことです。音声入力に加えてテキスト入力を残す、自動応答に加えて人への連絡経路を残す。この設計は、アクセシビリティだけでなく障害時の代替手段としても機能します(第10章)。

子ども・未成年の保護

未成年が利用するサービスにAIを組み込む場合、成人向けより厳しい配慮が求められます。教育分野では直接関わります(第5章)。

確認すべき論点

• 年齢の確認 ― サービスの対象年齢と、確認の方法。
• 保護者の同意 ― 個人情報の取得に関する要件。
• 収集する情報の範囲 ― 必要最小限に絞る。学習履歴・行動履歴の扱い。
• 不適切な出力の抑制 ― 年齢にふさわしくない内容が出力されないための対策と、その検証。
• 依存への配慮 ― 長時間の利用を促す設計になっていないか。
• 評価への影響 ― 学習支援の出力が成績評価に直結する場合の説明可能性。

実務的な進め方は、未成年が利用する可能性がある場合は、それを前提に設計を確認することです。「対象は成人」と規約に書いても、実際には利用されます。

倫理の観点を工程に組み込む

本章の内容を、実行できる形にまとめます。

1. 要検証の用途の判定基準を文書化する ― 5項目(人に対する判断・与信等・給付等・個人への推奨・不利益につながる判断)。
2. 該当する場合、属性ごとの集計を実施する ― 実施と結果を記録します。
3. 説明できる部分は説明する設計にする ― 使用の事実・入力と根拠・判断の主体は、記録すれば説明できます。
4. 不服の申し出の経路を用意する ― 問題の発見が早まります。
5. AIを使った機能を唯一の経路にしない ― アクセシビリティと事業継続の両方に効きます。
6. 未成年の利用可能性を前提に確認する ― 規約の記載だけでは足りません。
7. 4つの機能(判定・検証確認・記録・停止権限)を誰かの責任にする ― 専門委員会の設置は必須ではありません。