EU AI法「データガバナンスとバイアス検証」完全講義──Art. 10 と Recital (44-55) を深掘りする

最終更新日：2025-06-22

はじめに ――データ品質なくして安全な AI なし

前回は、ハイリスク AI の判定方法と CE マーキング取得プロセスを概観しました。今日はその心臓部である Art. 10 データガバナンス に焦点を当てます。EU AI法は、AI インシデントの約七割が”データの歪み”に起因すると断じ、GDPR 以上に厳格なデータ品質要件を課しました。もし要件を怠れば、ハイリスク AI 向けには最高で全世界売上の 7% という 巨額制裁金 が待ち受ける点を忘れないでください（Art. 104）。しかも域外適用原則により、日本企業でも EU 市場に SaaS を提供していれば当然対象です。

Recital (44)-(55) は「代表性」「関連性」「無偏り」「完全性」を手引書のように説きますが、条文を眺めるだけでは具体的な開発フローに落とし込みづらい。そこで本講義では、欧州委員会が意図した”データ管理のライフサイクル思考”を一歩ずつ紐解き、明日から MLOps パイプラインに「データカード」「バイアス検証ジョブ」「残留リスクジャーナル」を組み込むための実装ロードマップを提示します。

今日のゴールは、① Art. 10 が掲げる四要件を自社用語に翻訳し、② オープンソースとクラウドを組み合わせたミニマム実装計画を描き、③ 当局監査に耐える証跡ドキュメントを”自動生成”する仕組みを身につけることです。

1. Art. 10 が突き付ける”品質の四要件”を読み解く

まず条文 Art. 10(2) を読んでみましょう。

“Training, validation and testing data shall be relevant, representative, free of errors and complete, and shall have the appropriate statistical properties, including, where applicable, taking into account the particularities of the geographical, behavioural and functional setting in which the AI system is intended to be used.”（Art. 10(2)）

ここで示された四語「関連性（relevance）、代表性（representativeness）、無偏り（free of errors）、完全性（completeness）」は、ISO 5259-1 が挙げる 19 品質指標の中でも AI 安全性と直接相関が高いものを抜き出した”精鋭部隊”です。

関連性（Relevance）

「その特徴量は目的に直接的か」という問いです。退職予測モデルに婚姻歴を入れればプライバシー侵害に加え性差別を誘発するため、関連性が低いと判断されます。

代表性（Representativeness）

対象母集団（ターゲットユーザー）を統計的に再現しているかどうか。Recital (46) は「サブグループの分布差」を例示し、男女比だけでなく障がい者、難民、マイノリティ言語話者を明示的に挙げています。

無偏り（Free of Errors）

英米の統計用語で言えば statistical unbiasedness ではなく「差別性の欠如」に近い広義概念です。

完全性（Completeness）

欠測データの取り扱いを厳格に監視し、インピュテーション処理をログで説明できることを要求します。

代表性と無偏りは”似て非なる双子”

多くの開発チームが陥る誤解は「代表性を確保すれば自動的に無偏りも満たされる」という短絡です。仮に男性 60%、女性 40% の応募者データを同割合でサンプリングしても、女性だけ誤判定率が高ければ条文は違反とみなします。EU AI法は予測誤差の分布まで精査するため、「入力サンプルの均衡」と「出力誤差の均衡」という二段階検査が必要になります。

2. Recital (44-55) を”現場用語”で翻訳する

条文の背後にある Recital は立法趣旨を示す”解釈指針”です。ここを読み替えられると、実装方針に迷わなくなります。

収集・測定・生成──データ取得 3 モデル

Recital (44) はデータ取得を「収集」「測定」「生成」の三類型に分けました。衛星画像のような”生成データ”はセンサー仕様から統計誤差が入りやすく、取得後に ground-truth verification を行えと指示します。合成データもこのカテゴリーに含まれます。ここで合成データベンダー Mostly AI 社が 2025 年 3 月に発表した「EU AI Act 対応ホワイトペーパー」は必読です[^1]。統計的特性を χ² 検定で照合した実例が掲載されています。

公平性メトリクスの”スーパーメニュー”

Recital (48) は EEOC が採用する “Statistical Parity Difference””Equalized Odds” 等を例示したうえで、「加盟国は自国法に鑑み追加指標を要求してよい」と留保を付けます。つまりフランスで展開する SaaS は「年齢差別防止法」に基づき、20-29 歳層と 50-59 歳層の誤差差分を別途報告する可能性があるわけです。実務では メトリクス辞書 を作り、国別に必要項目を ON/OFF できる YAML を用意しましょう。

# fairness_metrics.yml
france:
  age_groups:
    - "20-29"
    - "50-59"
  required_metrics:
    - statistical_parity_difference
    - equal_opportunity
    - calibration_error
  threshold: 0.05

germany:
  protected_attributes:
    - disability_status
    - migration_background
  required_metrics:
    - equalized_odds
    - average_odds_difference
  threshold: 0.04

合成データの許容範囲

Recital (55) が歴史的に画期的なのは「希少現象を補完する目的なら合成データを正当化できる」と初めて EU 法文に明記した点です。ただし「実世界データの統計的特性を歪めないこと」が条件。肌色や年齢分布が現実離れしていないか、GAN 出力を T-SNE 投影して視覚確認するなど、QA 工程を組み込みましょう。

3. データガバナンス三層アーキテクチャ

では抽象論を具体論に落とします。Art. 10 を”監査可能な一筆書き”にするために、私は テクニカル層 — プロセス層 — ガバナンス層 の三段ピラミッドを提案しています。

3.1 テクニカル層——バージョン管理されたデータ製品

ここではデータレイクを単なるファイル置き場から「データ製品の集合」へ昇華します。Apache Iceberg や Delta Lake を用い、パーティションごとに DATASET_VERSION を自動インクリメント。各スナップショットのメタデータに ISO 5259-1 の 19 指標を JSON 化して添付します。Git のタグと相互参照することで「このモデル v2.1.7 はデータ v0.13 を使用」とトレーサビリティが確立します。

{
  "dataset_version": "v0.13",
  "iso_5259_1_metrics": {
    "completeness": 0.987,
    "consistency": 0.994,
    "accuracy": 0.991,
    "timeliness": "2025-06-20T14:32:00Z",
    "validity": 0.996,
    "uniqueness": 0.999
  },
  "bias_metrics": {
    "statistical_parity_difference": 0.032,
    "equalized_odds": 0.041,
    "calibration_error": 0.028
  }
}

3.2 プロセス層——CI/DP（Continuous Integration for Data Pipelines）

ソースコードに PR を出すたび、GitHub Actions が Great Expectations でスキーマ差分を検証。同時に Aequitas が統計的公平性メトリクスを走らせ、誤差差分が閾値超過なら PR をブロックします。ここで閾値を動的に管理できるよう fairness.yml を国別コンフィグに分割しておくと、海外展開時に速やかに切り替えられます。

# .github/workflows/data-quality-check.yml
name: Data Quality & Fairness Check
on: [pull_request]

jobs:
  quality-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run Great Expectations
        run: |
          great_expectations checkpoint run data_quality_checkpoint
      - name: Run Fairness Analysis
        run: |
          python scripts/fairness_check.py --config fairness_metrics.yml
      - name: Generate Risk Journal Entry
        if: failure()
        run: |
          python scripts/generate_risk_journal.py >> risk_journal.md

3.3 ガバナンス層——データステワードと残留リスクジャーナル

テクニカルな自動化だけでは「誰がサインオフしたか」が曖昧になります。そこでデータステワード（業務部門のデータ責任者）、AI プロダクトオーナー、外部倫理監査人の三職務で Data Governance Board を結成し、四半期ごとに残留リスクジャーナルをレビューします。ジャーナルは Markdown で良いので、「検出されたバイアス→修正→再学習→残留リスク」の 4 列を必ず記載。Recital (51) が命じる”利用終了ポリシー”に従い、モデル廃止時にはデータ削除を自動呼び出す Sunset Script が実行される設計とします。

4. バイアス検証を MLOps に溶け込ませる

モデルがオンライン学習を続ける限り、データ分布は絶えず変化します。Art. 10(3) はまさにその点を突き、「市販後監視をデータ品質まで拡張せよ」と宣言しました。

Fairness Job——AI の”定期健診”

実装の中核は Fairness Job。Airflow などで日次バッチを走らせ、推論ログから 1% をサンプリング。属性別に Equalized Odds と Calibration Error を計算し、閾値を超えたら即座に Canaries をロールバックします。なお EU AI法は固定閾値を示していないため、当局との事前協議で「誤差差分 5%」など自主基準を宣言すると後々の監査が楽です。

# fairness_job.py
import pandas as pd
from aequitas.group import Group
from aequitas.bias import Bias

def run_fairness_check(predictions_df, protected_attributes, threshold=0.05):
    """日次バイアス検証ジョブ"""
    g = Group()
    xtab, _ = g.get_crosstabs(predictions_df, attr_cols=protected_attributes)
    
    b = Bias()
    bias_df = b.get_disparity_predefined_groups(
        xtab, 
        original_df=predictions_df,
        ref_groups_dict={'gender': 'male', 'language': 'english'}
    )
    
    # 閾値チェック
    violations = bias_df[bias_df['equalized_odds_disparity'] > threshold]
    
    if not violations.empty:
        trigger_rollback()
        generate_risk_journal_entry(violations)
        
    return bias_df

残留リスクジャーナルを自動生成

Fairness Job がトリガーを踏んだら、CI/CD パイプラインで Markdown 形式のレポート を生成して PR に貼り付ける仕組みを組みましょう。GitHub 上で差分が可視化されるため、監査人が「いつ・誰が・何を修正したか」を一目で追えます。この自動化は White & Case が 2024 年 5 月の解説ブログで「ドキュメント作成の機械化は将来の訴訟リスクを半減させる」と推奨したアプローチと合致します[^2]。

5. ケーススタディ――採用スクリーニング AI を法適合させる

理屈はわかった、では実例に当てはめましょう。あなたの会社が提供する 動画面接スクリーニング AI を想像してください。応募者が 2 分間の自己紹介動画をアップロードすると、モデルが 300 点満点でコミュニケーション能力をスコアリングします。ユースケースは Annex III「雇用・労働分野」に該当し、ハイリスクです。

Step 1: 代表性の確保

収集した 5,000 本の動画のうち、日本語話者はわずか 5% でした。Recital (46) に従い、語学学校と提携して日本語話者 500 本を追加収集。単なるデータ増強ではなく現実の分布を再現するための実データ補完です。

Step 2: 無偏り検証

Equalized Odds を用い、言語別 False Negative Rate を比較したところ、日本語話者と英語話者で 9% の乖離。自主閾値 5% を超えたため、Fairness Job がデプロイをブロックし旧バージョンにフォールバックしました。

Step 3: リスク低減と再学習

開発チームは SHAP 値ヒートマップで”日本語アクセント”クラスタが過剰に重み付けされていることを特定。重み正則化とデータオーグメンテーションを施し、乖離を 3% に圧縮。Data Governance Board の承認を得てステージング環境へ再リリース。

Step 4: 残留リスクジャーナル

以上の流れを Markdown 1 ファイルにまとめ、risk-journal/2025-06-20-interview-model.md として Git に登録。削除トリガーとして「モデル v3.2 が廃止されたらデータセット v1.5 を S3 lifecycle policy で自動削除」を設定。

# 残留リスクジャーナル - 動画面接AI v3.2

## 検出日時: 2025-06-20 14:32 JST

### 検出されたバイアス
- 影響グループ: 日本語話者
- 誤判定率乖離: 9% (英語話者比)
- 影響レコード数: 250件

### 実施した修正
1. 日本語データ500件追加収集
2. 音声特徴量の重み正則化 (L2=0.01)
3. ピッチ・速度変換によるデータ拡張

### 再学習結果
- 新モデルバージョン: v3.2.1
- 誤判定率乖離: 3% (改善)
- 検証データセット: test_set_v1.5

### 残留リスク
- 方言話者での精度未検証
- 継続的モニタリング実施中

### 承認
- データステワード: 山田太郎 (2025-06-21)
- AI倫理委員会: 承認 (2025-06-22)

これで当局の抜き打ち監査に呼ばれても、「検知→停止→改善→検証→再リリース」のサイクルを文書で示せます。

6. 中小企業でも回るミニマム実装ロードマップ

巨人企業のように CDO Office を抱えられない？ 問題ありません。私は 三カ月スプリント×四本 で立ち上げるミニマム計画を推奨します。

Sprint 1: データカタログ導入（月額 3万円）

• OpenMetadata を Docker で立ち上げ
• 5 主要テーブルのスキーマとオーナーを登録
• データ辞書の初版作成

Sprint 2: スキーマ & 欠測チェック自動化（月額 5万円）

• Great Expectations を CI に統合
• Pull Request 単位で “Data Diff” を可視化
• 基本的な品質ルール設定

Sprint 3: Fairness Job 雛形構築（月額 8万円）

• Aequitas を Docker 化
• Airflow DAG に日次ジョブとして登録
• Slack への自動通知設定

Sprint 4: 残留リスクジャーナル公開（月額 10万円）

• GitHub Pages で /doc/compliance/ を公開
• DoC（適合宣言書）ドラフトを Markdown で配置
• 四半期レビュー体制の確立

トータル: 初期構築 26万円 + 運用 10万円/月で、大企業と同等のガバナンス体制を”コードとして”所有できます。

7. 質疑応答――典型的な落とし穴

Q1: 合成データ主体のモデルは認められるのか？

A: Recital (55) は希少現象補完を目的とするなら許容すると明記。ただし合成比率が実データを上回る場合、統計的妥当性を証明する負担が跳ね上がるため注意。推奨は合成データ 30% 以下。

Q2: 外部ベンダーに前処理を委託したら責任は分担できる？

A: Art. 28 は委託先にも協力義務を課すが、最終責任はプロバイダであるあなたに残る。SLA に以下を必須記載：

• Recital (46) 準拠条項
• 品質ログの四半期提出義務
• インシデント時の 48時間以内報告
• 監査受け入れ条項

Q3: 市販後監視インシデントの閾値は？

A: EU 委員会は横串の数値を定めておらず、各加盟国がセクター別ガイドラインを策定中。推奨自主基準：

• 重大: 本番トラフィック 0.1% 以上で系統的誤判定
• 中程度: 特定属性で 10% 以上の精度劣化
• 軽微: 単発エッジケースでの誤動作

まとめ ――データに始まりデータに終わる

本日の核心は、Art. 10 に適合するとは、データライフサイクルを”監査可能な一本線”にすること。モデル精度は今日の研究で上げられますが、過去データのメタ情報は今日ログを仕込まなければ永遠に残りません。

今すぐ実行すべきアクション

• [ ] データカタログツールの選定（1週間以内）
• [ ] Fairness Job のプロトタイプ作成（2週間以内）
• [ ] 残留リスクジャーナルのテンプレート作成（3日以内）
• [ ] 当局との事前協議スケジュール設定（1か月以内）

これができれば、EU AI法で最も重いハードルの一つを越えたと胸を張れます。

1.Mostly AI「Synthetic Data under EU AI Act」（ホワイトペーパー, 2025-03） ↩

2.White & Case「EU AI Act: Documentation Automation as Risk Mitigation」（2024-05 解説記事） ↩