この記事は EU AI Act 第9条（リスク管理システム）を実装・運用の観点から整理した解説です。条文の逐語訳や法的助言を目的とするものではありません。正確な要件については、原文（末尾の出典）をご確認ください。個別の対応判断は、法務・専門家にご相談ください。

EU AI Act の高リスク AI 向け義務は、当初は2026年8月2日から適用される予定でした。ただし2026年6月時点で、この時期は動いています。2025年11月に欧州委員会が出した Digital Omnibus（AI Omnibus）が2026年5月に暫定的な政治合意に達し、高リスク義務の適用を、附属書III のスタンドアロン型は2027年12月2日へ、附属書I の製品組込み型は2028年8月2日へ後ろ倒しする方向で整理されました。正式採択・官報掲載はまだで、それまでは原文の2026年8月2日が形式上の期限として残ります。

変わるのは時期だけで、求められる中身はそのままです。むしろ、評価基準・ログ・人的監督・データガバナンスを「どういう根拠でそう設計したか」を説明できることの比重が上がります。

日本企業でも、EU 市場に AI を出す場合、EU 域内で利用される場合、または AI の出力が EU で使われる場合は、域外適用の対象になり得ます。EU 向けのプロダクト・SaaS・組込み AI、とくに審査・推薦・分類・本人確認のような用途を扱うなら、第9条は早めに読んでおく条文です。なお、そもそも高リスクに該当するかの判定は別の論点（第6条・附属書III）で、ここでは高リスクと判断された後の義務を扱います。

これまでに第14条（人による監督）と第12条（記録・ログ保持）を扱いました。どちらも特定の義務を1つずつ実装に落とす話です。第9条はその一段上にあって、他の義務をどこまで作り込むかを左右します。

他の義務の実装の深さを左右する

第9条のリスク管理システムは、ライフサイクル全体を通して回り続ける反復プロセスです。1項はこれを確立・実装・文書化・維持することを求めます。ここでの「文書化」は、動いているプロセスを記録に残すことを指します。運用しながら定期的に見直し、更新していくのが前提です。

高リスク AI は、第8条により第2節（第9〜15条）の要件すべてに適合する必要があります。データガバナンス（第10条）、ログ（第12条）、透明性（第13条）、人的監督（第14条）、正確性・堅牢性（第15条）は、どれも等しく効いてきます。第9条が左右するのは、それぞれをどこまで作り込むか、その深さと優先順位です。4項が、対策を選ぶ際に各要件を組み合わせたときの相互作用まで考慮するよう求めているからです。

効きどころは、リスク評価をすること自体より、その結果が各義務にどう反映されたかを後から説明できる状態をつくることです。このログ粒度・この介入条件・この監視基準を、意図した用途・予見可能な誤用・影響を受ける人・残留リスクのどこから決めたのか。それが一本で辿れて、第72条の市販後モニタリングでの見直しもそこへ戻る。そこまで含めて第9条です。

リスク管理システムを負うのは原則としてプロバイダー（提供者）です。デプロイヤー（利用者）の義務は第26条で別に定められており、ここで扱うのは提供者側、設計・開発に紐づく部分です。

何を「リスク」として扱うか

2項は、扱うべきリスクを4つの段階に分けています。

意図した用途で使ったときに、健康・安全・基本的権利へ及びうる、既知および合理的に予見可能なリスクの特定と分析（2項(a)）。
意図した用途での使用に加え、合理的に予見可能な誤用（reasonably foreseeable misuse）の条件下で生じうるリスクの推定と評価（2項(b)）。
市販後モニタリング（第72条）で集めたデータの分析にもとづく、その他のリスクの評価（2項(c)）。
(a) で特定したリスクに対する、適切で的を絞った対策の採用（2項(d)）。

実装で効いてくるのは(b)の「合理的に予見可能な誤用」です。リスク評価は、仕様どおりの使い方に加えて、本来の用途から外れた使われ方まで広げます。たとえば与信スコアリングを、想定外のセグメントの判断に流用する、補助のはずのスコアが実質的な自動拒否に使われる、といった筋です。正常系に加えて、悪用・誤用の経路も最初から想定に入れます。

対象には歯止めもあります。3項により、扱うのは開発・設計、または適切な技術情報の提供によって合理的に低減・除去できるリスクに限られます。問われるのは無リスク化ではなく、手の打ちようがある範囲で打ったか、です。

テストの基準を先に決める

第9条のうち、「何をもって合格とするか」を事前に決めよ、と最も踏み込んでいるのが8項です。テストは開発プロセスのどの時点でも適宜行い、市場投入・運用開始の前には必ず実施する。そのテストは、意図した用途に見合う、事前に定義したメトリクスと確率的しきい値（prior defined metrics and probabilistic thresholds）に照らして行う、とあります。

すべてを単純な数値合否に落とせるとは限りませんが、8項の狙いは、後から都合よく「問題なし」と判断するのを防ぐことにあります。だから、測れるものは測れる基準に落とし、判断方法とその根拠をテスト前に決めておきます。定性的なリスク登録簿（「バイアスのリスク：中」）から、合否を判定できる基準まで具体化する作業です。

与信スコアリングなら、テスト前に決めておく項目はたとえば次のようになります（しきい値は用途とリスクに応じて設定し、その根拠を残します）。

どの指標を、どのデータセット・セグメントで確認するか
グループ間の不採用率の差が、どこまで開いたら再評価とするか
全体の誤判定率を、どの範囲まで許容するか
想定セグメント外の入力や欠損データに対して、どの安全側のふるまいに収めるか
人による確認を必須にする条件をどこに置くか
しきい値を超えたとき、再学習・用途制限・人手確認・リリース延期のどれを取るか

目指すのは、「この用途ではこのリスクが効くから、この指標とこの基準で確認した」と、事前に決めた基準に照らして説明できる状態です。

なお、テストには第60条にもとづく実環境テスト（testing in real-world conditions）を含めることもできます。任意ですが、実施する場合は第60条が定める条件の中で行います。

残留リスクと、対策の順序

対策は、各ハザードに紐づく残留リスクと、システム全体の残留リスクが「許容できる」と判断できる水準まで下げることが求められます。最も適切な対策を選ぶときの順序も決まっています。

適切な設計・開発を通じて、技術的に可能な範囲でリスクを除去または低減する（5項(a)）。
除去しきれないリスクには、適切な緩和・統制策を講じる（5項(b)）。
第13条にもとづく情報提供と、適切な場合はデプロイヤーへの訓練を行う（5項(c)）。

この並びがそのまま実装の優先度です。情報提供と訓練は、設計と緩和でやれることをやった後に置きます。危険な使い方を UI で抑止する、対象外データを入力させない、スコアだけでなく根拠や確信度を出す、人の確認を挟む条件を設ける。こうした設計上の対策が先で、利用者の注意力だけに残るリスクを押し付けない、という建て付けです。渡す情報の中身も、相手の技術的知識・経験・想定される訓練、使われる文脈に合わせて決めます。

運用データを評価に戻す

2項(c)は、市販後モニタリング（第72条）で集めたデータをリスク評価に戻すことを求めています。「継続的・反復的プロセス」という文言の実体はここにあります。運用で見つかったリスク、つまり予期しない使われ方・性能の劣化・特定の層への不利な影響・苦情やインシデントが評価に還流し、対策の見直しに反映される。この還流が回っていること自体が、第9条の要件の一部です。

これは第12条のログとも地続きです。何が起きたかを後から再構成できるログがあってはじめて、市販後モニタリングが意味のあるデータを拾え、それが第9条のリスク評価に戻ります。

性能の劣化やドリフトそのものの監視は、第15条（正確性・堅牢性）と第72条の市販後モニタリングが扱う領域です。第9条はそれを評価へ戻す回路にあたり、第9条・第12条・第15条・第72条が、設計・運用・是正の一つの輪としてつながります。堅牢性や敵対的入力への耐性は第15条の主題なので、別の記事で扱います。

脆弱な集団と、既存枠組みへの組み込み

9項は、リスク管理システムの実装にあたり（1〜7項を対象に）、システムが18歳未満の者や、適切な場合はその他の脆弱な集団に悪影響を及ぼしうるかを考慮するよう求めています。与信・採用・教育・医療・公共サービスのように生活に直結する用途では、平均的な精度だけでなく、誰にどんな不利益がどの程度生じうるかまで見ます。扱いどころは、テストデータの選び方・セグメント別の評価・しきい値・残留リスクの受容で、これらの判断に最初から織り込みます。

10項は、すでに他の EU 法のもとで内部リスク管理の要件を負っているプロバイダーについて、ここまでの内容を既存手続きの一部とする、または統合することを認めています。金融機関のように規制側のリスク管理枠組みを持つなら、AI 固有の論点を既存プロセスに足し込む形で対応できます。第17条が求める品質マネジメントシステム（QMS）も、第9条のリスク管理システムをその構成要素の一つとして含み（17条1項(g)）、第72条の市販後モニタリングや第73条の重大インシデント報告も同じ QMS の中で扱います。ISO/IEC 42001 のような AI マネジメント規格を使っていれば、そこに組み込みます。

残すべきは文書の数ではなく、リスク・管理策・テスト基準・結果・残留リスクの受容・運用監視・見直しという証跡が、一本でつながっていることです。リスク登録簿、テスト計画としきい値の根拠、残留リスクの受容記録（承認者を含む）、市販後モニタリング計画、変更管理の記録、デプロイヤー向けの説明資料は、その一本の証跡を構成する要素です。「既存プロセスがあるから大丈夫」で止まらず、どこで AI 固有のリスクを特定し、どこでテスト基準を承認し、どこで残留リスクを受容し、どこで運用データを評価に戻すのかが、その証跡の中で見えるようにします。

チェックリスト

第9条を実装に落とすときに論点になるのは、だいたい次のあたりです。

リスク管理が、見直し・更新の回る運用になっているか
意図した用途だけでなく、合理的に予見可能な誤用まで評価に入れているか
健康・安全・基本的権利への影響を具体的に見ているか
市販後モニタリング（第72条）のデータがリスク評価に還流しているか
市場投入前に、事前定義したメトリクスと確率的しきい値でテストしているか
残留リスクを「許容可能」と判断する基準と、その承認者が明確か
対策の順序（設計で除去 → 緩和・統制 → 情報提供・訓練）になっているか
デプロイヤーに渡す情報・訓練が、相手の知識・文脈を踏まえているか
18歳未満・脆弱な集団への影響を考慮したか
既存の規制リスク管理や品質マネジメントシステムと統合しているか

まとめ

第9条で効いてくるのは、リスク評価を運用データで回し続けることと、合格の基準をテスト前に決めておくことです。突きつめると、第9条は「なぜこの設計でよいのか」「なぜこの監視で足りるのか」「なぜこの残留リスクを許容できるのか」を説明するための条文で、チェックリストを埋めて終わりにする性質のものではありません。手元の AI で、リスク評価が運用データで更新され、合格の基準が事前に決まっているか。まずはそこを見るところからで十分だと思います。

罰則は、第9条のリスク管理要件への違反が、第16条が定めるプロバイダーの義務（高リスクシステムを第2節の要件に適合させること）を通じて問われる形になります。上限は第99条4項で、最大1,500万ユーロ、または全世界年間売上高の3%のいずれか高い方です（禁止行為に対する第99条3項の3,500万ユーロ／7%枠とは別です）。

出典

EU AI Act / Regulation (EU) 2024/1689, Article 9 (Risk management system)（1項＝確立・実装・文書化・維持、2項(a)〜(d)＝特定/評価/市販後データの還流/対策、3項＝対象リスクの範囲、4項＝第2節要件の組合せ考慮、5項(a)〜(c)＝対策の順序と残留リスクの許容性、6〜8項＝テスト（8項＝事前定義メトリクス・確率的しきい値）、9項＝18歳未満・脆弱な集団、10項＝既存リスク管理との統合）
関連条項：Article 8（第2節要件への適合）、Article 16（プロバイダーの義務）、Article 17（品質マネジメントシステム。17条1項で(g)第9条のリスク管理システム・(h)第72条の市販後モニタリング・(i)第73条の重大インシデント報告を構成要素として列挙）、Article 72（市販後モニタリング）、Article 73（重大インシデント報告）、Article 60（実環境テスト）、Article 13（デプロイヤーへの情報提供）、Article 26（デプロイヤーの義務）
適用時期：原文 Article 113（附属書III 高リスク＝2026-08-02／附属書I 高リスク＝2027-08-02）。Digital Omnibus（AI Omnibus）により、附属書III＝2027-12-02、附属書I＝2028-08-02へ後ろ倒しの方向（欧州理事会プレスリリース 2026-05-07）。2026年6月時点で暫定政治合意・正式採択前のため、官報（OJ）確定後に再確認。
罰則：Article 99(4)（高リスク義務＝最大1,500万ユーロ／全世界年間売上高の3%。第16条のプロバイダー義務を経由）。Article 99(3)（禁止行為＝3,500万ユーロ／7%）とは別枠。

構造化版（要約・要求事項・罰則・関連条項・クロスウォーク）は ConformGrid にまとめています: https://conformgrid.com/ja/regulation/eu-ai-act-art-9