EU AI法対応の第一歩はExcelから。「データの家系図」で実現するAIガバナンス入門

「EU AI法（EU AI Act）がついに成立しましたが、自社のAIプロダクトは大丈夫でしょうか？ 正直、何から手をつければいいのか……」

実務の現場では、法務担当者の方からこのような相談を受けることが増えています。ニュースを見れば「違反すれば全世界売上の最大7%という巨額の制裁金」という見出しが踊り、経営層からは対応策を求められる一方で、現場のエンジニアからは「技術的に複雑すぎてすぐには対応できない」と返されるケースも少なくありません。板挟みになっているプロジェクトマネージャー（PM）や法務担当者の方々は、対応に苦慮されていることでしょう。

しかし、焦る必要はありません。現場の課題解決を最優先に考えた場合、いきなり高額で高度な「MLOps（機械学習運用）ツール」や自動化システムを導入することは推奨されません。運用ルールが決まっていない段階でのツール導入は、かえって現場の業務フローを混乱させる可能性があります。

EU AI法が求めている核心は、「そのAIがどうやって作られたか、説明できますか？」という一点に尽きます。これを技術用語では「データリネージ（Data Lineage）」と呼びますが、「データの家系図」と呼ぶこともできます。

本記事では、エンジニアではない方々に向けて、この「データの家系図」をどのように構築し、管理していけばよいのかを解説します。まずは手元の表計算ソフトから始められる、スモールスタートかつ実務的な指針を紹介します。

なぜ今、「データの家系図」が必要なのか？

まず、なぜこれほどまでに「データリネージ」が重要視されているのか、その背景を少しだけ整理しておきましょう。ここを理解すると、現場への指示出しがスムーズになります。

EU AI法が求める「透明性」の正体

EU AI法では、特に「高リスクAIシステム」に対して厳格な透明性を求めています。ここで言う透明性とは、単に「アルゴリズムの数式を公開せよ」という意味ではありません。「なぜそのAIがそのような判断を下したのか」を追跡できる状態にしておくこと、つまりトレーサビリティ（追跡可能性）が求められているのです。

AI、特にディープラーニングの世界では、モデル自体がブラックボックスになりがちです。中身の計算処理は複雑怪奇で、人間が直感的に理解するのは困難です。しかし、モデルが学習に使った「データ」は管理できます。AIの振る舞いは、学習データによって決まるからです。

「あなたの家のAIは、どんな教育を受けて育ったのですか？」

この問いに答えられるようにしておくこと。それがデータリネージの本質です。もし、「ネット上のどこかから拾ってきたデータで適当に学習させました」としか答えられなければ、それは「素性の知れないAI」として、規制当局から厳しい目を向けられることになります。

ブラックボックス化が招く法的リスク

技術的な視点から見ても、データの来歴が不明なAIはリスク要因となりえます。一般的な事例として、画像認識AIの精度が急に低下するケースが報告されています。原因を調査しようにも、学習データの出所が不明確な場合、結局プロジェクトを巻き戻してゼロからデータを集め直す事態に陥ることもあります。

これがもし、著作権侵害や差別的なバイアスを含むデータだったとしたらどうでしょう？ リネージがなければ「どのデータが悪さをしたのか」を特定できず、説明責任を果たせません。

結果として、問題が起きた際にモデル全体を廃棄するしかなくなる可能性があります。これはビジネスにとっても大きな損失となりえます。

リネージ管理は、単なる法対応のコストではなく、「自分たちのAI資産を守るための保険」だと捉えてください。ツールを入れる前に、まずは「管理の文化」を作ることが先決です。

Tip 1：データの「出生証明書」を作る

では、具体的にどのような情報を記録すべきか。最初のステップは、データの入り口である「収集」フェーズです。ここではデータの「出生証明書」を作ります。

収集源の特定と権利関係の明記

多くのAIプロジェクトで最初につまずくのが、「このデータ、誰が集めたんだっけ？」という問題です。開発初期のPoC（概念実証）段階では、エンジニアが手元のPCでWebからスクレイピングしたり、オープンデータセットをダウンロードしたりして、とりあえず動くものを作ることがあります。

しかし、製品化の段階でこれが問題になる可能性があります。

管理台帳（表計算ソフトで構いません）には、以下の項目を必ず記録するようにしてください。

• データソース名: 具体的なURLやAPIのエンドポイント
• 取得日時: いつ取得したデータか（Webの情報は日々変わります）
• 取得者: 誰が（どの担当者が）取得したか
• ライセンス情報: 利用規約、CCライセンスの種類（商用利用可か、改変可か）

特に重要なのがライセンス情報です。「研究目的利用に限る」というデータを商用プロダクトに使ってしまうケースが散見されます。出生証明書がないデータは、商用利用の場には出さない。このルールを徹底するだけでも、リスクは大幅に低減できます。

Webスクレイピングデータの扱い方

Webスクレイピングで収集したデータは特に注意が必要です。各サイトのrobots.txt（クローラーへの指示書）を遵守したかどうかの記録も残すべきです。

「なんとなく集めたデータ」を排除し、一つひとつのデータセットに「ID」を振り、そのIDを見れば出自がわかる状態にする。これがデータガバナンスの第一歩です。

Tip 2：「加工レシピ」をバージョン管理する

集めたデータ（食材）は、そのままAIに食べさせるわけではありません。必ず「前処理」や「加工」を行います。この工程を料理の「レシピ」として記録しましょう。

前処理・クリーニングの履歴を残す

生データから学習データへの変換過程は、エンジニアの職人芸になりがちです。

• ノイズ除去（画像のトリミング、音声の背景音カット）
• 正規化（数値データのスケール合わせ）
• 欠損値処理（空白データをどう埋めたか）

これらがブラックボックス化すると、再現性が失われます。「あの時のモデル、すごく性能良かったけど、どうやってデータ加工したんだっけ？」とエンジニアが頭を抱える状況も考えられます。

管理シートには、「加工スクリプトのファイル名」や「バージョン」を紐付けておきましょう。理想的にはGitなどのバージョン管理システムと連携したいところですが、まずは「どのスクリプトを使って加工したデータセットなのか」が明記されているだけで十分です。

「なぜそのデータを捨てたか」を記録する

意外と見落としがちなのが、「除外したデータの理由」です。

例えば、「異常値だから削除した」という処理があったとします。しかし、それが本当に異常値（エラー）だったのか、それとも「珍しいが重要なケース」だったのかで、AIの性能や公平性は大きく変わります。

特定の層のデータを「外れ値」として無自覚に削除してしまうと、バイアスのかかったAIが出来上がります。「なぜ捨てたか」を言語化して残すことは、将来的に「特定の属性に対して差別的な挙動をした」と指摘された際の、重要な反証材料になります。

Tip 3：Human-in-the-Loopの記録を残す

EU AI法では、AIシステムに対する「人間による監視（Human Oversight）」が強調されています。データ作成プロセスにおいても、人の目が入った記録を残すことが重要です。

アノテーション作業者の基準統一

教師あり学習の場合、正解ラベルを付ける「アノテーション」という作業が発生します。これを誰が、どんな基準で行ったかは極めて重要です。

例えば、医療画像の診断AIを作る際、アノテーションをしたのが「医学生」なのか「専門医」なのかで、データの信頼性は大きく異なります。コスト削減のためにクラウドソーシングで専門外の方にアノテーションを依頼した結果、専門用語の解釈が統一されず、実務に耐えうるデータが構築できなかったというケースも報告されています。

• 作業者属性: 専門性、経験年数など
• アノテーションガイドライン: 判断基準を記したドキュメントの版数
• レビュー記録: ダブルチェックを行ったか、意見が割れた際の解決方法

これらを記録しておきましょう。特にガイドラインは頻繁に更新されるため、「どのバージョンのガイドラインに基づいて作業されたデータか」を紐付けておく必要があります。

人の判断が介在した箇所の明示

自動化されたパイプラインの中で、例外的に人間が手修正したデータがあれば、フラグを立てておくべきです。「ここはAIが苦手そうだから人間が直した」という箇所は、AIにとっての弱点でもあります。リネージの中に「Human-in-the-Loop（人間がループに入った）」記録を残すことで、モデルの改善ポイントも見えやすくなります。

Tip 4：データセットの「スナップショット」をとる

システム開発の現場では、データベースは常に更新され続ける「生き物」です。しかし、AIの学習においては、これが仇となることがあります。

学習時点のデータを凍結保存する

「先月のモデルの方が精度が良かった。あの時のデータでもう一度学習させたい」

こう思った時に、データベースが更新されていて元のデータが残っていない。これはよくある失敗です。また、法的な監査が入った際、「問題を起こしたバージョンのAIが、学習した瞬間のデータを見せろ」と言われる可能性もあります。

これに対応するためには、学習に使ったデータセットの「スナップショット（その瞬間のコピー）」を保存する必要があります。

モデルとデータの紐付け管理

ストレージコストの問題ですべてのデータを複製保存するのが難しい場合は、少なくともデータの「ハッシュ値（データの中身から生成される固有の指紋のような文字列）」を記録し、データの同一性を証明できるようにしておきましょう。

管理台帳上では、以下のように紐付けます。

• モデルID: Model_v1.0
• 学習データID: Dataset_20240501_snapshot
• データハッシュ値: a1b2c3d4...

これにより、「Model_v1.0はこのデータセットから生まれた」という親子関係が確定します。

Tip 5：「ゆりかごから墓場まで」の廃棄ルール

最後に、データの「死」についても考えなければなりません。データリネージは、データを集めて終わりではなく、適切に廃棄するところまでを含みます。

目的外利用の防止とデータ削除

GDPR（EU一般データ保護規則）などを意識すれば、個人情報を含むデータには保持期限や利用目的の制限があります。「契約終了後は速やかにデータを削除する」という契約になっている場合、その削除記録もリネージの一部です。

「いつ、誰が、どのデータを、どのような方法で（論理削除か物理削除か）削除したか」

この廃棄証明書がなければ、コンプライアンスを遵守していることを証明できません。削除したつもりでバックアップサーバーに残っていた、なんていうのは情報漏洩の典型的なパターンです。

モデル再学習時の旧データ扱い

また、古いデータが残り続けることで、AIが「過去の常識（今は不適切なバイアス）」を引きずり続けるリスクもあります。データの鮮度を管理し、「賞味期限切れ」のデータを学習セットから外すプロセスも、リネージ管理の一環として定義してください。

まとめ：完璧を目指さず、まずは一覧表から

ここまで、EU AI法に対応するためのデータリネージの考え方を5つのTipで紹介してきました。

1. 出生証明書: 収集元とライセンスを記録する
2. 加工レシピ: 処理手順と除外理由を残す
3. 人の記録: 誰がどんな基準で教えたかを記す
4. スナップショット: 学習時点のデータを凍結する
5. 廃棄ルール: データの最期までを見届ける

これらをすべて自動化しようとすると、コストと時間がかかります。まずは、プロジェクトごとにシンプルな「データ管理台帳」を作ることから始めてみてください。

【スプレッドシートで始める管理項目例】

データID	データ名称	取得元	取得日	ライセンス	加工スクリプト	担当者	状態	廃棄予定
D-001	顧客対話ログ2023	自社CRM	2023/12/01	社内秘	clean_v1.py	佐藤	保存中	2026/12
D-002	Web画像セットA	CC-Search	2024/01/15	CC-BY 4.0	resize_v2.py	鈴木	廃棄済	-

このように一覧化されているだけで、「管理されている」という事実は作れます。そして何より、現場のエンジニアにとっても「どのデータを使えばいいか」が明確になり、開発効率が上がる可能性があります。

法対応は「守り」の側面が強いですが、データリネージを整備することは、高品質なAIを作るための「攻め」の基盤にもなります。難しく考えすぎず、まずは身近な整理整頓から始めてみましょう。