「AIのリスクと言われても、何から洗い出せばいいのか分からない」「導入は進むのに、リスクの全体像が描けない」「リスク一覧は作ったが、どれから対処すべきか優先順位がつかない」——AI活用が実務に広がるほど、リスクマネジメントの側が追いつかなくなる。これは特定の企業の問題ではなく、構造的なギャップ として各種調査に一貫して表れている。

McKinsey の State of AI 2025（2025年11月）では、回答企業の74%が「不正確性（ハルシネーション）」を、72%が「サイバーセキュリティ」を重要なリスクと認識していた。にもかかわらず、実際の緩和行動は認識に追いつかない「認識と実装のギャップ」が世界共通の課題として指摘されている。国内に目を向けると、帝国データバンクの調査（2024年6〜7月・4,705社）でAIの指針・ガイドラインを「策定している」企業は19.5%にとどまり、従業員1000人以上では61.3%、100〜1000人未満では37.0%と、規模による差が大きい。IPA「AI利用時のセキュリティ脅威・リスク調査」（2024年7月）でも、AI利用者の約6割（重大な脅威27.1%＋やや脅威33.3%＝60.4%）が脅威を感じる一方、利用ルールは「検討中」「利用者個人任せ」が多く、特に中小規模で整備が遅れていた。

脅威は認識されているのに、対策が体系化されない。 その根本原因は、リスクを「情報漏洩・著作権・ハルシネーション」といった項目の羅列で捉え、分析・優先順位づけ・対応ができる単位に構造化できていないことにある。本稿では、AIリスクを「分析できる単位」に落とすためのタクソノミー（分類学）、国際標準に沿ったアセスメント手順、リスクレジスター、そして業務別の許容度設計までを、実務目線で整理する。

なお、ガバナンス体制そのものの作り方は企業のAIガバナンス実務ガイド、規制・ガイドラインの読み方は経済産業省のAIガバナンスを読み解くで扱っている。本稿は、それらの基盤の上で「リスクを分析の単位として扱う」方法論に焦点を絞る。

なぜ「リスク一覧」では不十分なのか

多くの社内資料やWeb記事は、AIリスクを「情報漏洩・著作権・誤情報・バイアス……」とフラットに列挙して終わる。だが、フラットな一覧には3つの限界がある。

第一に、性質の異なるリスクが同じ平面に並ぶため、対処方法を設計できない。ハルシネーションは出力の検証で抑える技術・運用の問題だが、著作権侵害は法的判断を要する問題であり、ベンダーロックインは調達戦略の問題である。同じ「リスク」という言葉で括っても、打ち手の置き場所が違う。

第二に、優先順位がつかない。一覧は「網羅したつもり」にはなるが、「発生可能性が高く影響も大きいリスク」と「理論上あり得るが実害が小さいリスク」を区別しない。結果として、すべてに同じ重さで身構えるか、逆にすべてを後回しにするかのどちらかに陥る。

第三に、業務によってリスクの重みが違うことを表現できない。営業の提案資料作成でのハルシネーションと、法務の契約レビューでのハルシネーションでは、許容できる度合いがまったく異なる。一覧はこの差分を捨象してしまう。

そこで本稿では、リスクを3つの層に分けて構造化し、アセスメントの手順で優先順位をつけ、業務別の許容度で重みづけする、という3段階で整理する。

AIリスクを技術・運用・戦略の3層で切り分ける

AIリスクは、「どこで・誰が対処すべきか」という観点から、技術・運用・戦略の3層に分けると扱いやすくなる。AX Boostが支援の現場で立ち上げ時にまず描くのもこの切り分けで、打ち手の所在（技術部門／運用部門／経営）が層ごとに異なる以上、ここを最初に決めておかないと対応設計が始まらないからである。

層 リスクの性質 主な対処の担い手
第1層：技術リスク モデルそのものの挙動に由来する AI開発・技術部門
第2層：運用リスク 使い方・運用プロセスに由来する 情報セキュリティ・推進部門・現場
第3層：戦略リスク 法的・社会的・経営的な帰結に由来する 経営・法務・調達

第1層：技術リスク

第1層は、モデルの内部的な性質そのものから生じるリスクを束ねる。代表格はハルシネーション（不正確性・コンファビュレーション）で、事実と異なる情報をもっともらしく生成してしまう。最も広く認識されているリスクでもあり（McKinsey 74%）、対処は出力の検証プロセスやRAGによる根拠付けに寄せることになる（AIハルシネーション対策の実装論、Fine-tuning vs RAG）。

これと性質が近いようで打ち手が変わるのがバイアス・不公平な出力だ。学習データに含まれる偏りが差別的・不公平な出力として現れるもので、採用・与信・評価といった意思決定に使う局面ほど重くのしかかる。AI事業者ガイドライン第1.2版では、この「差別的出力」が技術的リスクから倫理・法的側面に関わるものへとリスク分類が見直された点も押さえておきたい——つまり、純粋な技術問題として現場に投げきれないリスクへと位置づけが動いている。

残る2つは、運用開始後にじわじわ効いてくる類のものだ。ひとつは精度の劣化・再現性の欠如で、モデル更新やデータ分布の変化によって、これまで安定して動いていた処理の精度が静かに落ちていく。一度作って終わりではなく継続的な評価設計が要る所以である（AI評価フレームの実装論）。もうひとつは説明可能性・解釈可能性の限界で、なぜその出力に至ったかを説明できないこと自体が、規制業種や対外説明を求められる業務ではボトルネックになる。

第2層：運用リスク

第2層は技術そのものではなく、使い方や運用プロセスの側から生じる。地味に見えるが、実害として表面化しやすいのはむしろこの層であり、その分だけ対策の費用対効果も高い。

最もわかりやすいのが機密情報・個人情報の漏洩だ。外部AIに機密データを入力すれば、その情報は外部へ渡りうる。実例として、Samsung電子は2023年4月の約20日間に、半導体のソースコードや社内会議の文字起こしを ChatGPT に入力する3件の漏洩を起こし、5月には生成AIの利用を全面禁止する事態に至った（Bloomberg 報道）。漏洩は外部からの攻撃ではなく、善意の従業員の便利使いから起きる点が運用リスクらしい。

入力ミスとは逆に、外から仕掛けられるのがセキュリティ上の敵対的脅威である。プロンプトインジェクション（悪意ある指示の注入）、ジェイルブレイク（制約の回避）、モデルやデータの窃取などがこれにあたり、IPA「情報セキュリティ10大脅威2026」組織編（2026年1月29日決定）では「AIの利用をめぐるサイバーリスク」が初めて選出され、第3位にランクインした。攻撃対象としてのAIが、もはや理論上の話ではなくなったことを示す動きである。

組織の統制が及ばないところで膨らむのがシャドーAIだ。会社が把握しない個人利用のAIツールが現場で先行してしまう現象で、日本企業では稟議文化のもとで全社規程の整備に時間がかかり、その空白期間に現場利用が広がる、という順序になりやすい。そして、こうした入力が法的論点に直結することを示すのが個人情報の不適切な取り扱いである。個人情報保護委員会は2023年6月、OpenAI に対し、要配慮個人情報の取得制限を含む注意喚起を行った。AIへの入力そのものが個人情報保護法上の論点を生みうることを、規制当局が早い段階で示した事例といえる。

第3層：戦略リスク

第3層に並ぶのは、法的・社会的・経営的な帰結に関わり、現場のチェックでは収まらず経営判断を要するリスクだ。

筆頭は法的責任・著作権で、AIの誤案内や生成物が、そのまま企業の法的責任に転化する。カナダの Moffatt v. Air Canada（2024 BCCRT 149）では、チャットボットの誤案内が「過失による不実表示」と認定され、航空会社が賠償を命じられた。米国の Mata v. Avianca（2023年6月）では、弁護士が ChatGPT の生成した存在しない判例を提出して Rule 11 違反となり、5,000ドルの制裁を受けている。こうした事案は例外ではなく、AI Hallucination Cases のデータベースにはハルシネーション起因の法廷提出が世界で486件（うち米国324件）記録されている。著作権リスクの詳細はAI著作権リスクの実務対応に委ねる。

誤出力ではなく悪用の側から実害が出るのがディープフェイク詐欺・なりすましだ。英 Arup の香港拠点では2024年1月、偽の CFO らが登場するビデオ会議に騙された担当者が、15回に分けて2,560万ドル（約2億香港ドル）を送金している。生成AIの悪用が、もはや実害を伴う段階に入ったことを示す象徴的な事例である。

さらに2つ、経営の文脈で見落とせないものがある。ひとつはレピュテーション・ガバナンスの失敗で、不適切な出力や情報漏洩が報道に乗れば、ブランドや顧客信頼そのものが毀損される。もうひとつはベンダー集中・地政学リスクで、特定のモデル・ベンダーへの依存は、価格・可用性・規制変更に対する脆弱性へと裏返る（業務AIインフラの技術選定）。

この3層は、「リスクを排除するため」ではなく、「どの部門が、どの打ち手で対処すべきか を切り分けるため」の枠組みである。技術リスクを法務に投げても解決しないし、戦略リスクを現場のチェックだけで抑えることもできない。

リスク分類学の国際的な裏付け

3層フレームは実務のための整理だが、リスク項目そのものの網羅性は、国際的なフレームワークで補強できる。

米国 NIST が2024年7月26日に公表した Generative AI Profile（NIST AI 600-1）は、生成AI固有のリスクを12のカテゴリに整理し、200を超える推奨アクションを示している。カテゴリには、コンファビュレーション（ハルシネーション）、データプライバシー、有害バイアス・均質化、情報の完全性、情報セキュリティ、知的財産、CBRN（化学・生物・放射性物質・核）情報、人間とAIの構成、価値連鎖・コンポーネント統合などが含まれる。自社のリスク一覧に漏れがないかを点検する際のチェックリスト として有用である。

また ISO/IEC 23894:2023（AIリスクマネジメントのガイダンス、2023年2月発行）は、汎用的なリスクマネジメント規格 ISO 31000:2018 の構造を踏襲しつつ、AI固有の論点（データ依存、複雑性に起因する透明性・説明可能性の課題、自動意思決定の影響）を上乗せしている。リスク源の一覧（附属書B）やAIライフサイクルとのマッピング（附属書C）は、自社のタクソノミーを設計する際の参照点になる。

リスクアセスメントの手順 — 一覧を「優先順位」に変える

リスクを層に分けたら、次は優先順位をつける段階である。ここで使うのが、ISO 31000／ISO/IEC 23894 が示す標準的なプロセスであり、NIST AI RMF の MAP・MEASURE・MANAGE 機能にも対応する。

手順 内容 対応する枠組み
① 特定 どんなリスクがあるかを洗い出す NIST: MAP
② 分析 各リスクの「発生可能性」と「影響度」を見積もる NIST: MEASURE
③ 評価 分析結果から優先順位をつけ、対応の要否を判断する NIST: MEASURE
④ 対応 回避・低減・移転・受容のいずれかを選ぶ NIST: MANAGE
⑤ モニタリング 対応後の残存リスクと環境変化を継続的に監視する NIST: GOVERN（横断）

② 分析と ③ 評価 — リスクマップで可視化する

分析では、各リスクを「発生可能性（高・中・低）」×「影響度（大・中・小）」の2軸で見積もり、リスクマップ（ヒートマップ） 上に配置する。これにより、「発生可能性が高く影響も大きい（最優先で対処）」「発生可能性は低いが影響が甚大（移転や事業継続計画で備える）」「発生可能性は高いが影響は軽微（運用ルールで抑える）」といった対応方針の差が一目で分かる。

フラットな一覧が優先順位をつけられないのに対し、この2軸評価は「どこから手をつけるか」の判断を可能にする。重要なのは、すべてのリスクをゼロにしようとしないことである。リスクマネジメントの目的はリスクの根絶ではなく、便益とのバランスの中で、許容できる水準までコントロールすること にある。

④ 対応 — 回避・低減・移転・受容を使い分ける

評価したリスクへの打ち手は、ISO 31000 が示す回避・低減・移転・受容の枠に整理できる。

  • 回避: そのリスクを生む活動自体を行わない（例：個人情報は外部AIに入力しない）。
  • 低減: 発生可能性や影響を下げる（例：出力の人間レビュー、最小権限設定、RAGによる根拠付け）。
  • 移転: 第三者に転嫁する（例：保険、契約上の責任分配、ベンダーのSLA）。
  • 受容: 残存リスクを認識した上で受け入れる（例：軽微なリスクは運用で対応）。

「すべて低減」でも「すべて受容」でもなく、リスクの重みに応じて使い分けることが、現実的なリスクマネジメントである。

リスクレジスター — 管理の実体をつくる

アセスメントの結果を、継続的に管理できる形に落とす道具がリスクレジスター（リスク管理台帳） である。これがないと、リスク評価は「一度やって終わり」の文書になり、形骸化する。最低限、次の項目を持たせる。

項目 内容
リスクID／名称 識別子と簡潔な名称
層・分類 技術／運用／戦略のどれか
該当する主体・業務 どの部門・ユースケースで生じるか
発生可能性／影響度 2軸評価の結果
対応方針 回避／低減／移転／受容
具体的な対策 実施する施策
オーナー 責任を持つ部門・担当
残存リスク 対策後に残るリスクの水準
レビュー日 次回見直しの時期

ポイントはオーナーと残存リスクの欄である。誰が責任を持つかが空欄のリスクは、結局誰も対処しない。また、対策をしても残存リスクはゼロにはならない——その水準を明示し、経営として受け入れる判断を記録しておくことが、後のインシデント対応や説明責任において効いてくる。

業務ごとにリスク許容度を変える

同じリスクでも、業務によって許容できる度合いは大きく異なる。これを無視して全社一律のルールを敷くと、リスクの高い業務には甘く、低い業務には過剰に厳しい、という的外れな統制になる。そこでAX Boostが現場で使うのが、主要なリスクと業務をクロスさせて重みづけする許容度マトリクスだ。次の表は、典型的な業務についてその差分を一枚に落としたものである。

業務 ハルシネーション許容度 情報漏洩リスク 出力に対する責任の重さ 主な統制の力点
営業・提案資料作成 中（人がレビュー前提） 中 中 出力の事実確認、顧客情報の入力制限
カスタマーサポート 低〜中 中 中〜高 回答の根拠付け、エスカレーション基準
ソフトウェア開発 中 高（ソースコード） 中 コードの秘匿、脆弱性レビュー
管理部門（経理・人事） 低 高（個人・財務情報） 高 PII入力の禁止、承認フロー
法務・コンプライアンス 非常に低 高 非常に高 一次情報での検証必須、人間の最終判断

このマトリクスは、「どの業務に、どの統制を、どの強さでかけるか」を設計するための地図 である。営業の提案資料作成では人によるレビューを前提にハルシネーションをある程度許容できるが、法務の契約判断では一次情報での検証と人間の最終判断が不可欠になる。業務ごとの差分を設計に織り込むことで、現場の利便性とリスク統制を両立させる。職種別のユースケースは顧客接点業務のAI活用ガイド、管理部門のAI活用ガイドも参照されたい。

自律型AIエージェント時代の新しいリスク層

2025〜2026年にかけて、リスクマネジメントの焦点は自律型AIエージェントへと移りつつある。エージェントは自らツールを呼び出し、複数ステップのタスクを自律的に実行するため、従来の「入力と出力をチェックする」発想だけでは捉えきれないリスクを生む。

新しさの中心は、リスクが入出力の一点ではなく実行プロセスの連鎖に宿る点にある。たとえばツール呼び出しのハルシネーション（function-calling hallucination）では、エージェントが不正・危険なツールを誤って呼び出してしまう。複数のツール・サービスを横断する過程では、本来渡すべきでない情報が連鎖の途中で流出するツールチェーンを跨ぐ情報漏洩も起こりうる。そして、これらの被害を一気に拡大させるのが過剰な権限付与である。エージェントに与えた権限が広すぎれば、ひとつの誤動作や乗っ取りが、その権限の及ぶ範囲すべてに波及してしまう。

OWASP は2025年12月に Top 10 for Agentic Applications（2026） を公開し、エージェントの目標の乗っ取り（ASI01）やプロンプトインジェクション、過剰な権限付与を最重要リスクに位置づけた。McKinsey の State of AI trust 2026 では、責任あるAIの成熟度が平均2.3（前年2.0）に上昇した一方、エージェントを実験中の組織が62%、どこかでスケールしている組織が23%あるのに対し、エージェントのガバナンスが成熟している組織は約3分の1にとどまり、ガバナンスがデプロイ速度に2段階遅れている と指摘された。回答者の約3分の2が、セキュリティ上のリスクをエージェントAIをスケールさせる最大の障壁に挙げている。

実務上の打ち手は、AI事業者ガイドライン第1.2版が新たに加えた留意事項とも重なる。出発点は Human-in-the-Loop（人間の判断を必須化する仕組み） で、重要な意思決定や不可逆な操作には人間の承認を挟む。前述の調査でも、ガバナンス成熟度の高い企業の65%がHITLを導入しているのに対し、低成熟企業では23%にとどまり、成熟度との相関がはっきり出ている。次に効くのが最小権限の原則で、エージェントに与える権限・アクセス範囲を必要最小限に絞れば、先に述べた過剰な権限付与のリスクをそもそも小さくできる。そして、これらの統制を機能させる前提として、把握できていないエージェント利用を可視化し承認の仕組みに乗せること——シャドーAIの管理が欠かせない。見えていないものには、HITLも最小権限もかけようがないからである。

エージェント設計そのものの実務はAIエージェント業務導入の設計論で詳述している。本稿の観点で重要なのは、ガバナンス・リスク管理を、デプロイと同じ速度で内製化すること である。導入だけ先行してガバナンスが2段階遅れる、という構造こそが、最大のリスクになる。

国際標準の使い分け — どれを、どの順で使うか

AIリスクマネジメントには性格の異なる国際標準が並立しており、「どれか1つ」ではなく役割分担で使い分けるのが定石である。

標準 性格 役割
AI事業者ガイドライン（経産省・総務省） 国内ソフトロー 国内コンプライアンスの土台
NIST AI RMF 1.0（NIST AI 100-1、2023年1月） 任意適用のフレームワーク リスク特定・測定・管理の柔軟な実装
NIST Generative AI Profile（NIST AI 600-1、2024年7月） 生成AI向けプロファイル リスク網羅性の補強（12カテゴリ）
ISO/IEC 23894:2023 リスク管理のガイダンス リスク評価の作法（ISO 31000準拠）
ISO/IEC 42001:2023 認証可能なマネジメントシステム規格 監査可能な仕組みの構築（第三者認証）

実務的には、次の三層で順に整えるのが現実的である。第一に、AI事業者ガイドラインで国内コンプライアンスの土台をつくる。第二に、リスク特定の網羅性を NIST Generative AI Profile の12カテゴリ で補強する。第三に、グローバル取引・調達・対外説明の必要があれば、ISO/IEC 42001 認証で「監査可能な仕組み」を整える。日本のAIセーフティ・インスティテュート（AISI）は、AI事業者ガイドラインと NIST AI RMF の対応関係を整理した「クロスウォーク」を公開しており、国内基準と国際フレームは地続きで運用できる。さらにAISIは NIST AI RMF 本体とプレイブックの公式日本語訳 も公開しているため、英語の壁なく実装に着手できる。GOVERN・MAP・MEASURE・MANAGE の4機能を自社の成果物に落とし込む具体的な手順はNIST AI RMF 実践ガイド近日公開で詳述している。これらの規制・ガイドラインの全体像は経済産業省のAIガバナンスを読み解くで扱っている。

なお、EU市場にAIシステムを提供する、あるいはAIの出力がEU域内で使われる企業は、EU AI Act の域外適用にも注意が必要である。EU AI Act（規則EU 2024/1689、2024年8月1日発効）は、AIシステムを許容できないリスク（禁止）・ハイリスク・透明性リスク（欧州委員会は第3層を「透明性リスク」と呼ぶ。一般には「限定的リスク」とも）・最小リスクに分類し、禁止AI違反には最大3,500万ユーロまたは全世界年間売上高の7%という制裁金を科す。2026年5月7日には、欧州議会と理事会が「Digital Omnibus」でハイリスク義務の適用延期（Annex III は2026年8月2日→2027年12月2日、Annex I は2027年8月2日→2028年8月2日）に暫定合意したが、これは「免除」ではなく「準備期間の延長」である。延期されたものと、既に適用中のもの（禁止AI・汎用AIモデル義務）を切り分けて備える必要がある。

限界と誤解 — リスクゼロを目指さない

最後に、AIリスクマネジメントを進める上での限界と、避けるべき誤解を整理しておく。出発点に置くべきなのは、リスクゼロは目的ではないという認識だ。あらゆるリスクを根絶しようとすればAI活用そのものが止まってしまう。目的はあくまで、便益とのバランスの中でリスクを許容水準までコントロールすることにある。むしろ「使わない」という選択がもたらす機会損失こそ、立派なリスクの一つである——ヒトがやる必要のない仕事を見極めて引き算し、空いた工数を価値ある仕事へ再配置するという機会を、過剰な警戒で逃すことの代償は小さくない。

次に陥りやすいのが、タクソノミーがカタログで終わる罠だ。せっかくリスク分類を作っても、それが現場のリスク特定・測定・運用に接続されなければ、ただ眺めるだけのカタログになる。「標準は導入したが、現場でリスクが管理されていない」という失敗の多くは、分類と統制システムが切れていることに起因する。前述したリスクレジスターとオーナーの設定が、この断絶を埋める役割を担う。

逆方向の誤りもある。過度な萎縮は、それ自体が別のリスクを生む。厳しすぎる統制は現場のシャドーAIを助長し、かえって可視化できないリスクを増やしてしまう。だからこそ業務別許容度マトリクスで「使ってよい範囲」を明確にすることが、結果的にリスクを下げる近道になる。そして見落とされがちなのが、一度きりの評価は時間とともに無効化するという点だ。AI技術もリスクも変化が速い以上、リスクアセスメントは半年〜1年ごとの見直しと、技術・規制の環境変化に応じた再分析を前提に設計しておく必要がある。

これらは、AI事業者ガイドラインが採用するアジャイル・ガバナンス（環境・リスク分析からゴール設定、設計、運用、評価、再分析までを継続的に回す考え方）と地続きである。リスクマネジメントは、一度作って終わる文書ではなく、回し続けるプロセスとして捉えたい。

まとめ — リスクを「分析できる単位」に変える

AIリスクマネジメントが空回りするのは、リスクを項目の羅列で捉え、分析・優先順位づけ・対応ができる単位に落とせていないことが原因である。本稿の処方は3つだった。技術・運用・戦略の3層で打ち手の所在を切り分け、発生可能性×影響度のアセスメントで優先順位をつけ、業務別の許容度マトリクスで統制の強弱を設計する。そして、それをリスクレジスターという実体に落とし、アジャイルに回し続ける。

自律型AIエージェントの普及で、リスクはデプロイの速度に追いつくことがますます難しくなっている。だからこそ、リスクマネジメントを「導入の後で整える付帯作業」ではなく、実装と同じ速度で内製化する経営プロセス として組み込む必要がある。

AX Boostでは、PoCから本番運用に移す過程で、リスクの特定・評価・統制設計を技術実装と一体で進めるFDE型コンサルティングを提供している。ガバナンスとリスク管理をデプロイと同速で内製化することで、「導入は進んだがリスクが野放し」「リスクを恐れて活用が止まる」という両極を回避し、便益とリスクのバランスの取れたAI活用の定着を支援している。

主要参照ソース

関連記事: