AI規制（EU AI Act）とは？

2024年8月1日に発効したEU AI法（欧州連合AI法）は、2026年より段階的な本格適用フェーズへ移行しました。EU域内に直接の拠点を持たない日本企業であっても、提供するAIシステムから生成された出力（データ、予測、意思決定など）がEU域内で利用される場合は「域外適用」の対象となります。違反した場合には、最大3,500万ユーロ（約56億円）または全世界の年間売上高の7%という、GDPR（一般データ保護規則）を上回る巨額の制裁金が科されるリスクがあります。グローバル市場において日本企業が直面する具体的な影響範囲、リスクレベル別の技術的要件、組織的なガバナンス設計、およびAI特有のセキュリティ脅威に対する防御策を実務的な視点で詳述します。

EU AI法の適用対象と日本企業における「域外適用」の3大判断基準

EU AI法（EU AI Act）は、EU域内に本社を置く企業だけでなく、EU域外の事業者に対しても「域外適用」の規定を設けています。日本企業であっても、自社のAIビジネスがEU市場と何らかの接点を持つ場合、規制の対象外であると軽視することはできません。EU AI法第2条に基づき、日本企業が規制対象となるか否かをセルフチェックするための「域外適用」の3大判断基準は以下の通りです。

• 基準1：AIシステムから生成された「出力（アウトプット）」がEU域内で使用されるか

  AIシステム自体の開発やサーバーでのホスティングが日本国内で行われていても、そのAIが生成した予測、推奨、決定などのアウトプットがEU域内で利用される場合、日本企業はEU AI法の適用対象となります（第2条1項(c)）。例えば、日本のサーバー上で稼働する与信審査AIのAPIを、EU域内の金融機関が統合して現地の顧客審査を行うケースがこれに該当します。

• 基準2：EU市場においてAIシステムまたは「汎用AI（GPAI）」を「提供者（Provider）」として上市・サービス提供しているか

  EU域内のユーザーに向けて、AIシステムを「上市（Placing on the market）」または「サービス提供（Putting into service）」している場合です（第2条1項(a)）。これには、自社ブランドの生成AI（GPAI：General Purpose AI）モデルをAPIやクラウドサービスを通じてEUの法人・個人に直接提供している日本のソフトウェア企業が含まれます。汎用AI（GPAI）に関するルールは2026年中に適用が開始されるため、早期の対応が必要です。

• 基準3：EU域内のユーザーが使用するAIシステムに対して、日本企業が「導入者（Deployer）」として関与しているか

  EU域内に物理的に所在するAIシステムの「導入者（Deployer）」が、日本企業の開発したシステムを使用する場合や、日本企業のEU現地法人が自ら「導入者」として現地従業員の管理や製造ラインの制御にAIを利用する場合です。この場合、日本本社側も共同責任を問われる、または実質的な提供者としての義務を負うリスクがあります。

日本企業が「提供者」「導入者」として規制対象になるシナリオ

EU AI法の下では、事業者が「提供者（Provider）」と「導入者（Deployer）」のどちらに分類されるかによって、課される法的義務が大きく異なります。日本企業が特に注意すべき具体的な2つの実務シナリオを示します。

• シナリオA：医療・ヘルスケア分野における「提供者」としてのケース

  AI搭載の医療用画像処理システム（クラスIIa以上の医療機器など）を日本国内からAPI経由でEU域内の大学病院に提供するシナリオです。このAIシステムは、人間の健康や生命に関わるため、EU AI法のリスクベースアプローチにおいて「高リスクAI（High-Risk AI）」に分類されます。この場合、提供者である日本企業は、EU域内に「法定代理人（Authorised Representative）」を設置した上で、EUの厳しい適合性評価（Conformity Assessment）をクリアし、CEマークを取得しなければEUでの販売・提供ができません。

• シナリオB：製造・小売業の現場における「導入者」としてのケース

  EU域内の工場や配送センターにおいて、監視カメラ映像から従業員の危険行動を検知する「安全監視AI」を運用するシナリオです。このシステムが雇用や人事管理、労働者の監視に関連する「高リスクAI」と判定された場合、日本企業（および現地子会社）は「導入者」となります。導入者は、AIシステムが提供者の取扱説明書に従って適切に動作しているかを監視する「人間の監視（Human Oversight）」体制を構築し、システムが生成するログを自動的に保存する義務を負います。

特に生成AIの枠組みでは、汎用AI（GPAI）を提供する日本企業は、トレーニングデータの要約開示や、著作権法への準拠、さらにはモデルの脆弱性に対する技術文書の作成が義務付けられます。

GDPRを上回る巨額な制裁金（罰則）の算出基準と最大リスクシナリオ

EU AI法における罰則の最大の特徴は、すでに多くの日本企業が対応を迫られたGDPR（一般データ保護規則）を上回る巨額の制裁金が設定されている点です。違反の内容に応じて、全世界年間売上高に対する一定割合、または規定の固定額の「いずれか高い方」が科されます。

以下に、全世界年間売上高が5,000億円（約31.25億ユーロ、1ユーロ＝160円換算）のグローバル展開する日本企業をモデルケースとした、最大リスクシナリオにおける財務インパクトの試算を示します。

この巨額な財務リスクを回避するためには、単なるチェックリスト方式の対応では不十分です。実務レベルでは、コーポレートガバナンスにおける「3つのラインモデル」を組織体制に適用し、開発・法務・監査がそれぞれの役割を果たす体制を構築することが推奨されます（詳細は後述のセクションを参照）。また、AI特有のセキュリティ脅威に対する防御ログを保持し、監査時に提示できるようにしておくことが、制裁金リスクを極小化するための必須実務となります。

4段階のリスクベースアプローチと生成AI（GPAI）に対する規制義務

EU AI法の根幹をなすのが、AIシステムが社会に及ぼすリスクの大きさに応じて規制の深度を分ける「リスクベースアプローチ」です。2024年に発効されたEU AI法は、2026年にかけて段階的に規制が本格施行されており、各リスク分類の正確な境界線と技術的な要求事項を把握することが実務上極めて重要です。

「禁止」および「高リスク」に分類されるAIシステムの境界線

EU AI法では、AIシステムを「禁止」「高リスク」「限定的リスク」「最小限リスク」の4段階に分類しています。各リスク分類の定義と具体的な規制要件は以下の通りです。

実務者が最も警戒すべきなのは「禁止」と「高リスク」の境界線です。欧州委員会等の公式ガイダンスによると、例えば「職場や教育現場における感情認識」は原則として全面的に禁止されます。具体的には、社内カメラ映像から従業員の表情を分析して「業務への集中度」をスコア化するAIなどがこれに該当します。ただし、運転手の眠気検知など「安全上の明確な理由」があるシステムは例外として許容されますが、この境界を誤ると即座に最高額の制裁金リスクが適用されます。

一方で、入社試験の履歴書フィルタリングAIや、銀行がローン審査で用いる与信評価AIは「高リスク」に分類されます。これらは禁止こそされませんが、開発プロバイダーは事前に厳格な適合性評価を通過し、データセットの偏り（バイアス）評価、ログの自動保存、そしてシステムのサイバーセキュリティ要件を満たすことが義務付けられます。製品の設計変更や開発コストの増加に直結する重要な技術的課題です。

生成AI（GPAI）のプロバイダーが遵守すべき技術ドキュメントと著作権対応

特定の用途に限定されない「汎用AI（GPAI）」、すなわち大規模言語モデル（LLM）をはじめとする生成AIのフレームワークは、上記のリスク分類とは別に構築された独自のルールが適用されます。GPAIモデルのプロバイダー（自社で基盤モデルをトレーニング・提供する企業）は、下流の開発者やエンドユーザーに対して以下の技術的要件および著作権対応の実装が不可欠です。

• 学習データの詳細な要約の開示: 欧州AI事務局（EU AI Office）が策定する標準テンプレートに基づき、モデルのトレーニングに使用したテキスト、画像、その他の著作権保護コンテンツなどのデータソースに関する詳細な要約を作成し、一般公開する義務。これにより、EU著作権法が認める「テキスト＆データマイニング（TDM）例外」に対して、権利者が適切なオプトアウト（学習利用の拒否）を行えるようにします。
• 技術ドキュメント（モデルカードなど）の整備: モデルの構造、学習に使用された計算量（FLOPs）、ハイパーパラメータ、評価指標、動作制限、および安全性検証の結果などを網羅した技術文書を整備し、ダウンストリーム（モデルをAPI経由で組み込む企業など）のインテグレーターに提供する義務。

さらに、学習時の累積計算量が「10^25 FLOPs」を超える超大規模モデル（GPT-4クラス以上の性能を持つ基盤モデル）は、「システムリスクを伴うGPAIモデル」として指定され、追加の高度な義務が課されます。2026年現在、この閾値を超えるモデルを開発する企業は、モデルのセキュリティ脆弱性に対する技術的な評価および、発見されたセキュリティ侵害や機能不全についての迅速な報告体制（欧州AI事務局宛）の構築が実務上必須となっています。

EU AI法「施行スケジュール」と段階的な義務化のタイムライン

EU AI法は、2024年8月1日に発効しました。2026年現在、すでに一部の規制要件は猶予期間を終えて完全施行されており、域外適用の対象となる日本企業にとっても、対応遅れは許されない状況です。本法はリスクレベル（禁止、高リスク、限定的リスク、最小限リスク）に応じて適用スケジュールが異なるため、時系列に沿った厳格なロードマップ対応が必要となります。

2024年〜2027年以降までの適用猶予期間タイムライン

EU AI法の発効から完全義務化にいたるまでのマイルストーンを以下の表にまとめました。2026年現在、すでに「禁止AIの適用」および「汎用AI（GPAI）の基本要件」の移行期間は終了しており、実務上の運用フェーズに入っています。

特に「EU AI法 日本企業 影響」として注意すべきは、EU域内に直接的な拠点がなくとも、自社が提供するAIシステムの出力結果がEU域内で使用される場合は、域外適用の対象となる点です。例えば、日本国内のサーバーから提供される人事選考AIを、EU支店の採用活動で利用するケースでは、Annex IIIの「高リスクAI」とみなされ、第3段階（2026年8月2日）の要件をすべて満たさなければなりません。この義務を怠った場合、制裁金支払いのリスクに直面します。

猶予期限から逆算する日本企業のロードマップと優先タスク

日本企業がこの厳格なタイムラインに適合するためには、開発部門と法務部門が密に連携し、猶予期限から逆算したステップバイステップの対応ロードマップを実行する必要があります。

フェーズ1：AI資産の棚卸しとリスク分類（最優先タスク・すでに実施完了しているべき段階）
社内で開発・利用、または顧客向けに提供しているすべてのAIシステムを洗い出し、「禁止AI」および「汎用AI（GPAI）」に該当するかどうかを仕分けします。これらはISO/IEC 42001（AIマネジメントシステム規格）に準拠した社内規定を構築することで、法的な客観性を担保することが実務上効果的です。

フェーズ2：高リスクAIの「適合性評価」とサイバーセキュリティ要件への対応（2026年現在の必須タスク）
自社サービスがAnnex IIIの「雇用」や「信用評価」などの高リスクAIに該当する場合、適合性評価への対応は遅滞なく進める必要があります。具体的には、AIシステムに偏り（バイアス）がないかを検証するデータガバナンスの確立と、堅牢なサイバーセキュリティ対策が必要となります。一般的なセキュリティ対策に加え、データの完全性を検証するデータアクセス制御などを開発フェーズから組み込む必要があります。

フェーズ3：「3つのラインモデル」に準拠した組織ガバナンスの統合構築（2026年中期以降）
開発・法務・監査がそれぞれの役割を果たせるよう、組織体制を再設計します。次章で詳述する「3つのラインモデル」を社内のAIガバナンス体制に適用し、責任の所在を明確化することで、適用される各マイルストーンを確実にクリアすることが可能になります。

「3つのラインモデル」を応用したグローバルAIガバナンス体制の構築

万が一重大な違反が発覚した場合、最大で「3500万ユーロまたは全世界年間売上高の7%」という、GDPRを上回る巨額の制裁金が科されるリスクがあります。この実務的なリスクを回避するためには、形骸化したガイドラインではなく、実効性のある「3つのラインモデル」をベースとしたガバナンス体制の構築が必要です。

経営・法務・開発部門を繋ぐ「3つのライン（防衛線）」の設計方法

AIシステムのガバナンス体制を組織内で破綻させずに運用するには、第1線（開発・事業部門）、第2線（リスク管理・法務・コンプライアンス部門）、第3線（内部監査部門）が果たすべき役割を明確に分担することが有効です。

この3つのラインが実効性を持つためには、開発現場（第1線）が「ポイズニング」や「回避攻撃」といった機械学習特有のセキュリティ脅威に対し、技術的なテストを実行できる体制が不可欠です。OWASP（Open Web Application Security Project）が公開しているセキュリティ基準を開発プロセスの初期段階で組み込むことで、第1線における検証プロセスの標準化を推進できます。

社内AI資産を可視化する「AIレジストリ」とリスクアセスメント体制の構築

EU AI法への適合において、最初に着手すべきは、自社が利用・開発しているすべてのAI資産を網羅的に把握するための「AIレジストリ（社内AI資産・リスク台帳）」の構築です。利用しているツールが「汎用AI（GPAI）」に該当するのか、あるいは医療機器や重要インフラ制御のような「高リスクAI」に該当するのかを1件ずつ紐解き、台帳に記録していくプロセスが必要です。

実務で直接使えるAIレジストリの構築ステップは、以下の4段階で進めます。

• ステップ1：全社的なAI棚卸し（インベントリ作成）
  事業部門が独自にAPI契約しているサービスも含め、社内で利用・開発されているすべてのAIツールを洗い出します。ここでは、開発・検証中、本番稼働中、外部ベンダー製などのステータスを区別して記載します。
• ステップ2：リスク分類と適合性チェック
  EU AI法の定義（「許容不可」「高リスク」「限定的リスク」「最小限リスク」）に照らし合わせ、自動で一次判定を行うスコアリングシートを整備します。GPAIに該当する場合は、プロバイダーから技術文書やモデルカード（性能・制限事項の記述書類）を入手できる体制が整っているかを確認します。
• ステップ3：技術的な評価（セキュリティ・適正評価）
  高リスクAIに分類されたシステムについては、セキュリティ検証の実施記録（脆弱性テストやバイアス検出テストの結果）をレジストリ上に統合し、監査証跡として残せる仕組みを作ります。
• ステップ4：ライフサイクルマネジメント
  AIは学習データの変化によって挙動が変わる（データドリフト）特性があるため、四半期、またはモデル再学習のタイミングでレジストリの情報を自動更新するルールを定めます。

この台帳管理が表計算ソフトによる手動更新に依存している場合、システムの改変や担当者交代に伴って形骸化するリスクが高まります。実務上は、外部のリスク管理プラットフォーム（OneTrustやServiceNowなど）を導入し、開発パイプラインとレジストリをAPIで直接連動させ、開発現場と法務部門の承認ワークフローを自動化する「生きたガバナンス体制」を構築することが、監査対応における最も堅実な対策となります。

EU AI法が求めるサイバーセキュリティ要件と開発者が講じるべき脆弱性対策

EU AI法は、人間の生命や人権に害を及ぼす可能性のあるAIシステムに対して厳格な「サイバーセキュリティ要件」の遵守を義務付けています。開発拠点が日本国内であっても、EU域内のユーザーにサービスが提供される場合は域外適用の対象となるため、開発初期段階からセキュリティを考慮する「セキュア・バイ・デザイン」の実装は、事業継続における必須要件です。

AI特有 of セキュリティ脅威（ポイズニング・回避攻撃・モデル抽出）と防御技術

AIシステムは、従来のWebアプリケーションが抱えるOSコマンドインジェクションやSQLインジェクションといった脆弱性だけでなく、機械学習モデルの構造や訓練プロセス特有の脆弱性を突く新たな脅威に晒されています。特にLLMや高リスクAIの開発において、以下の3つの脅威への対策は避けて通れません。

第一の脅威は、モデルのトレーニングデータを汚染する「ポイズニング」攻撃です。攻撃者が訓練データセットに不正なデータや特定のトリガーを混入させることで、学習後のモデルにバックドアを仕込み、特定の入力に対して意図的に誤った出力を引き起こさせます。この対策として、データ収集フェーズにおける「データフィルタリング」の徹底が必要です。開発現場では、データのハッシュ値を検証する整合性確認手順を構築するほか、異常値検知アルゴリズム（Isolation Forestなど）を用いて訓練データから外れ値を自動排除するパイプラインを実装します。実務的には、Microsoftが公開しているオープンソースのAIセキュリティ評価ツール「Counterfit」などをパイプラインに組み込み、データインジェクションに対するモデルの耐性を自動テストする手法が活用されています。

第二の脅威は、稼働中のモデルに対する「回避攻撃（Adversarial Attacks）」です。これは、入力データに人間の目では識別困難な微小なノイズ（敵対的サンプル）を加えることで、AIの認識を誤らせる攻撃手法を指します。この脅威に対抗する技術的アプローチが「敵対的訓練（Adversarial Training）」です。意図的に生成した敵対的サンプルをあらかじめ訓練データに含めて再学習させることで、未知の摂動に対するモデルのロバストネス（堅牢性）を向上させます。

第三の脅威は、モデルの挙動や出力から機密情報を割り出す「モデル抽出（およびモデル反転攻撃）」です。API経由で大量の問い合わせを繰り返し、その応答パターンからモデルのパラメータを逆算して複製したり、訓練データに含まれる個人情報や営業秘密を復元したりします。これを防ぐためには、出力の抽象度を上げるノイズ付加技術や、学習時にデータのプライバシー強度を数学的に保証する「差分プライバシー（Differential Privacy）」の適用が不可欠です。Googleが提供する「TensorFlow Privacy」やPyTorch向けの「Opacus」といったライブラリを実装し、訓練時の損失関数計算にノイズを混入させることで、モデルのパラメータから個別の訓練データが復元される確率（ε：イプシロンで定義されるプライバシー収支）を実務的に安全なレベルまで制御します。

適合性評価をクリアするためのセキュリティ監査と国際標準（ISO/IEC 42001）の活用

高リスクAIに分類されるシステムをEU域内で市場に投入する、または稼働させるためには、第三者機関による、あるいは一定の自己宣言による「適合性評価」をクリアし、CEマークを取得しなければなりません。これには、技術的な対策の適用だけでなく、それらを継続的に管理・運用する組織的なガバナンス体制が構築されていることを、監査可能な客観的エビデンスで示す必要があります。

前述の「3つのラインモデル」に基づき、開発部門（第1線）が技術的な脆弱性評価とログ管理を行い、リスク管理部門（第2線）がAIリスク管理方針の策定とEU AI法への適合性を審査し、内部監査部門（第3線）がプロセスを独立して監査する体制を敷きます。これを体系化するための世界的なデファクトスタンダードとして、AIマネジメントシステム規格「ISO/IEC 42001」が策定されています。同規格に準拠した認証を取得し運用することは、EU AI法が要求する「継続的なリスク管理プロセス」を適切に実施している強力な証明となります。

具体的な技術評価基準としては、米国国立標準技術研究所（NIST）が策定した「AI Risk Management Framework (AI RMF 1.0)」との親和性を確保することが推奨されます。これらを基準に社内監査を実施し、システム全体の脅威モデリングを定常化することで、EU AI Actの施行スケジュールに遅滞なく適合するセキュリティ体制を担保できます。

開発現場が適合性評価に向けて準拠すべき具体的な「セキュリティチェックリスト」は以下の通りです。

• データサプライチェーンの安全確保: 外部から調達した訓練データセットのライフサイクル全般（生成、収集、加工、保管）において、ハッシュ値による改ざん検知およびアクセス権限が厳格に管理されているか。
• 敵対的攻撃に対する耐性テスト（ロバストネス評価）: 稼働前のモデルに対し、敵対的サンプルを用いた擬似攻撃シミュレーション（Counterfit等のツールを利用）を開発工程の自動テストに組み込んでいるか。
• 機密データの保護と推論抑制: 訓練データに機密情報（個人情報、知的財産など）が含まれる場合、差分プライバシーの適用や、マスキング処理、またはAPIの応答レート制限により、モデル逆算攻撃を防ぐ仕組みを実装しているか。
• ロギングとトレーサビリティの確保: EU AI法が求める透明性基準を満たすため、モデルのトレーニングに使用した全データ、評価指標、実行ログ、およびエンドユーザーへの出力ログが、監査可能な形で改ざん防止対策を施されたストレージに保存されているか。
• 脆弱性情報の継続的監視: AIシステムを構成するオープンソースライブラリやLLMラッパーなどのOSS（SCA：ソフトウェア構成分析ツール等による管理）に潜む脆弱性を定期的にスキャンし、パッチ適用を行う運用プロセスが存在するか。

よくある質問（FAQ）

監修者プロフィール

近本 彰

大手ITコンサルティングファームにて企業のDX推進に従事。 その後、上場企業やスタートアップにてテクノロジーを活用した新規事業を複数立ち上げ。 現在はIT・テクノロジー系メディア「TechShift」を運営し、最新テクノロジーをわかりやすく解説している。