AI法チャンネル│日本一わかりやすい EU AI法・AI規制メディア
最終更新日：2025-06-21
はじめに ――”禁止”の次に控える最大のハードル
前回は、EU AI法が黒と白を峻別する「禁止AI」（Article 5）を学びました。今日はそのすぐ下の階層、すなわちハイリスクAIに焦点を当てます。
禁止ラインを越えない限り安心かというと、決してそうではありません。EU AI法はリスクピラミッドの第二層に、医療機器、重要インフラ、教育評価、雇用選考など――社会・経済の根幹を支える領域で動く AI を一括して封じ込め、組織に前例のない”製品安全法レベル”の遵守義務を課しています。
施行のタイムリミットは 2026年8月2日。二年などあっという間に過ぎます。
本講義では、条文 Art. 6-15 と Annex III を縦横に読み解きつつ、あなたの現場で「これはハイリスクか？」を迷わず判定できるチェックリストを提供し、さらに CE マーキング取得までのロードマップを示します。
1. ハイリスクAIとは何か――定義条文の核心を読む
EU AI法の Art. 6 と Art. 7 は、まるで二重ゲートのように機能します。
第一ゲート Art. 6(1) は「Annex III 記載の用途に該当するか」だけを問います。教育の学習成果評価、職場の採用・昇進判断、移民管理、司法判断支援など、合計八つの分野が列挙されています。
第二ゲート Art. 7 では「実質的リスクを減じる仕組みが備わっていないか」をチェックポイントとして挟み込み、技術的・組織的対策が著しく高水準なら”ハイリスク相当外”へ回避させる逃げ道を残します。
ここで大切なのは、Annex III が単なる”ラベル集”ではないという点です。
条文は「Annex III の用途に”使用される”AI システム」と書き、開発主体の意図ではなく実際のユースケースと流通経路で該当性を決める仕組みをとります。
ある顔認識 SDK が医療画像分析にも使われるならハイリスクの網にかかりますし、プロンプト調整一つで客室清掃ロボに組み込まれるだけなら軽微リスクに落ちるかもしれない――同じ技術が用途で運命を分けるのです。
2. 八つのハイリスク領域――Annex III を講義形式で一気に走破する
Annex III は表形式で八部門を列挙しますが、ここでは講義調で場面ごとに想像してみましょう。
まずバイオメトリクス。生体識別は原則禁止 AI の隣室に位置し、許されるのは事後解析や少量データでの身元確認検証など限定的なケースのみです。警察が捜査資料を照合するフェーズ、空港の自動ゲートでパスポートと顔を突き合わせるフェーズが具体例です。リアルタイム監視は Art. 5 に跳ね返るので注意してください。
次に重要インフラです。送電網や上下水道制御システムに AI が入り込む場面を想像してください。誤作動ひとつで都市が停電しますから、欧州委員会は「リスク管理システムを自動車のエアバッグ並みに冗長化せよ」と要求しています。
三番目は教育・職業訓練。ここが日本企業に最も影響します。入試の適性診断、オンライン試験の不正検知、社員研修のコンピテンシー評価――これらは全てハイリスクです。国境を越えて SaaS を展開する EdTech 企業や、社員評価に ChatGPT API 連携ツールを使う人事部門は、否応なく CE マーキングの対象となります。
四番目雇用・労働管理。募集、書類選考、面接アセスメント、昇進判定――採用プロセスのどこかで AI 推薦エンジンを挟むとハイリスク枠行きです。EU の均等雇用指令や差別禁止指令との複合コンプライアンスが必要になり、透明アルゴリズムの説明責任が他領域より重くのしかかります。
五番目公共サービス、六番目法執行、七番目移民管理と続きますが、日本の民間企業でも BPO として行政向けシステムを受託する場合は射程に入ります。
最後が司法機関支援。判例検索エンジンや量刑推奨ツールはまさにここ。リーガルテック企業は EU 対応モードに切り替えるしかありません。
3. ハイリスク認定されたら何が起きるか――義務条文 Art. 8-15 を分解
さあ、あなたのサービスがハイリスク枠に舞い込んだとしましょう。その瞬間から適用されるのが Art. 8 以降の具体義務です。まず Art. 9 はリスクマネジメントシステムを求めます。ISO 14971 医療機器リスク管理に似た PDCA サイクルを AI 開発ライフサイクル全体に張り付け、危険事象の識別から残留リスク評価、低減措置、市販後監視まで――大学院の安全工学講義を丸ごと社内に導入するイメージです。
次に Art. 10 がデータ・データガバナンス。訓練・検証・試験データの品質、バイアス防止、欠測データの取り扱い、結果検証の統計的妥当性まで要求します。単に「学習用データ 1M レコード確保」で終わらず、成分表レベルでメタデータを添付しなければ CE マーキングは通りません。
Art. 11 では技術文書、つまり”AI システム取扱説明書”の提出を義務付けます。モデル構造、ハイパーパラメータ、前処理パイプライン、バージョン管理――Git リポジトリをそのまま印刷する勢いで透明化する必要があります。
Art. 12 は自動ログ保持、Art. 13 は透明性と提供者情報の開示。特に後者はユーザーマニュアルに「AI が意思決定プロセスをどこまで自動化しているか」「誤判定時の救済フロー」を記載することを義務付けます。
Art. 14 は人間の介在（Human Oversight）。停止スイッチの物理実装や、異常値を検知して運用者にアラートを投げるダッシュボード構築などが典型例です。
最後の Art. 15 が精度、ロバストネス、サイバーセキュリティ。攻撃者が敵対的サンプルを注入しようとしても、ファジングテストをクリアできるしきい値を保持することが求められます。
これらを総合して初めて CE マーキング申請の入口に立てるというわけです。
4. CE マーキング取得までの四段階ロードマップ
ハイリスク AI の開発企業は、家電メーカーのように「CE マーク」を本体や UI に表示しなければ欧州市場に流通できません。プロセスは四段階です。
第一段階：内部監査。リスクマネジメント計画とデータガバナンス計画をドラフトし、独立監査人を社外から招いてギャップ分析を受けます。
第二段階：適合性評価。自社宣言（Module A）か第三者認証（Module B+C）かを選択しますが、Annex III の大半は原則として Notified Body による審査が必須です。
第三段階：EU 適合宣言書（DoC）作成。これは GDPR の DPA と同じく公開文書であり、製品名、モデル番号、規格適合基準、残留リスク、保守体制などをフルオープンにします。
第四段階：市販後監視（Post-Market Monitoring）。アプリ公開後もログを収集し、重大インシデントを 15 日以内に各加盟国当局へ報告する義務が続きます。MITRE ATLAS の脅威列挙を元にインシデント分類ツリーを構築しておくと報告業務が楽になります。
5. 講義実践編――”ハイリスクか否か”を5分で判別するチェックリスト
条文が多すぎて覚えられない？ 安心してください。現場で使える五問チェックを伝授します。
- 最終用途は Annex III に列挙されているか。教育、採用、インフラ、医療など八項目のいずれかへ Yes と答えた瞬間、ハイリスク候補。
- 判断結果が個人の権利・利益を直接左右するか。Yes なら第二のスイッチが入る。
- 誤判定時の救済手段を人間が握っているか。No ならハイリスク濃厚。
- 訓練データの偏りを測定し、統計的妥当性を証明できるか。No の場合 CE マークはまず通らない。
- 市販後監視のインシデント報告窓口を開けているか。No なら実運用で違法状態へ直行。
この五問で三つ以上 No が付いたら、ほぼ確実にハイリスク相当と判断して準備を始めましょう。
6. ユースケースで深掘りするハイリスク判定
実例を一つ見てみましょう。オンライン試験監督システム ProctorX（仮称）は、受験者の顔を認識し、不正行為をリアルタイムに検知し、試験官に警告を送ります。
用途は教育評価で Annex III に列挙、顔認識自体は生体識別、誤判定が学生の成績や卒業可否に影響し、人間のレビューは後追い――完璧にハイリスクです。
もし同社が「試験後の録画を教員がレビューし、AI はフラグ立てのみ」という運用に切り替えれば、人間の介在度合いが増してリスクが緩和される可能性があります。
別の例として、電力会社が送電網監視に用いる異常検知 AI。これは重要インフラの安全運用に関わるためハイリスク。ところがデータソースが IoT センサーのみで、個人情報も差別要素も無い場合、データガバナンス義務は比較的軽めです。
このように、ハイリスクと宣言されたからといって一律で超重装備をしなければならないわけではない。Annex III が射程を定め、その中で Art. 9-15 がリスクプロファイルに応じて要求を調整する。”パーソナライズド規制”という、EU AI法の隠れた美点を覚えておいてください。
7. スタートアップはどう準備するか――アジャイル開発と法規制の橋渡し
アジャイル開発は高速リリースとユーザーフィードバックを重視しますが、ハイリスク AI の世界では「安全性検証がパスしなければリリースしない」が絶対原則です。
スクラムのスプリントレビューに”リスクレビュー”を追加し、Definition of Done に「Annex VIII のテストケースをすべて通過したこと」を必須条件として書き込みましょう。
また、デザインスプリントの初日にリーガル担当者をメンバーに組み込み、データ権利処理とライセンス互換性を同時チェックする文化を定着させてください。MLOps にセキュリティを埋め込む DevSecOps がトレンドですが、今後は “DevRegOps”――法規制に適合するコードを書く、という新しい開発様式が求められます。
8. 監督当局との関係構築――サンドボックスと事前相談
EU AI法は、ハイリスク AI のイノベーション阻害を懸念し、各加盟国に AI 規制サンドボックス を設けるよう求めています。スタートアップが規制当局と共同で試験運用しながらフィードバックを得られる制度で、日本の金融サンドボックスに近い発想です。
事前相談（Pre-market Dialogue）を通じてログ項目やバイアス検証指標の妥当性を当局に確認しておくと、正式審査で”宿題のやり直し”を食らうリスクを削減できます。
9. よくある誤解を払拭する
最後に三つの誤解だけクリアにしましょう。
第一に「オープンソースモデルならハイリスク義務を免れる」という誤解。条文は”AI システムを提供する者”と”使用する者”を分け、いずれかが EU 市場に関与すれば適用すると定めています。OSS でも実装した瞬間からユーザー責任が発生します。
第二に「CE マークさえ取れば何でもできる」。いいえ。市販後監視で重大インシデントを報告しなかった場合、認証は取り消されますし罰金も科されます。
第三に「PoC は規制外」。これも誤解です。法案は「市場投入またはサービス提供に向けて利用可能な形態」を広く製品とみなし、PoC であっても外部クライアントへ提供した時点で義務が生じます。
10. 講義のまとめと次回への架け橋
ハイリスク AI は”危険物”ではありません。適切な管理下に置けば社会を前進させる原動力になります。ただし管理コストと透明性負担は軽くありません。今日学んだ Annex III 判定 → Art. 6-15 義務チェック → CE マーク取得 → 市販後監視 の流れを組織にインストールし、2026 年の本格施行までに「DevRegOps 文化」を育ててください。
次回の講義では、ハイリスク AI の実装現場で必ず直面する データガバナンス設計とバイアス検証の実践手法 を取り上げます。具体的には Art. 10 と Recital (44-55) を紐解きながら、差別検知アルゴリズムと統計的公正性指標を Python で検証するワークショップを行う予定です。ぜひご参加を。
