第5章 リスク評価と説明責任

学習目標

• AIリスクを、影響を受ける人、発生条件、被害からなる被害シナリオとして記述する。
• NIST AI RMFの4機能と信頼できるAIの7特性、生成AIプロファイルのリスク区分を説明する。
• リスク対応の4つの選択肢と残余リスクを区別し、等級に比例する統制を配置する。
• 法令が求める記録と、組織が判断を説明するための記録を設計する。
• マネジメントシステム認証とフロンティア安全フレームワークの目的と限界を説明する。

はじめに

ある会社が、20件のAI活用事例をすべて「高リスク」と分類したとします。すべての事例で事前審議、二重レビュー、月次報告が求められました。3か月後、委員会は書類に埋もれ、本当に顧客に影響を与える2件を詳しく検討できなくなっていました。反対に、すべての事例を「低リスク」とすれば、誰も確認しません。リスク評価は、リスクをなくすための作業ではなく、限られた注意と資源をどこに使うかを決める作業です。すべての箇所を同じように守ろうとすると、どの箇所も十分には守れなくなります。

その判断は後から説明できる必要もあります。監督機関、顧客、翌年の担当者の誰に聞かれても、「なぜこの統制を選び、何を引き受けたか」に答えられる記録こそ、説明責任の実体です。

本章で扱うフレームワークは法令ではなく、判断を整理するための道具です。そのため、第2・3章の法定義務とどう結び付くかに特に注意してください。まずリスクの書き方から始め、NIST AI RMFの構造、信頼できるAIの特性、生成AIのリスク区分を整理します。続いて対応の選択肢と等級別の統制のマッピング、法定要件との区別、記録と監査、運用中の監視を扱います。最後に、ISO/IEC 42001とフロンティア安全フレームワークが何を示し、何を示さないのかを考えます。

重要な概念

リスクを被害シナリオで書く

「バイアスリスク」「ハルシネーションリスク」というラベルだけでは評価できません。誰が、どの条件で、どの被害を受けるかと書いて初めて測定・統制できます。

悪い例：バイアスリスク
よい例：方言を含む音声の問い合わせを意図分類モデルが「苦情ではない」と誤分類し、
        高齢顧客の解約依頼が平均より遅れて処理される。（影響を受ける人：高齢顧客、
        条件：非標準的な発話、被害：処理遅延と追加料金、回復：返金で一部可能）

シナリオごとに、影響（被害の大きさ、権利への影響、回復可能性、影響を受ける人数）と、可能性（発生頻度、その条件がどのくらい一般的か）を評価します。リスク等級は費用ではなく、人と権利への影響を中心に定めます。倉庫と校舎で安全点検の周期が違うのは、建物の値段ではなく、その中にいる人が違うためです。

NIST AI RMFの構造と始め方

NIST AIリスクマネジメントフレームワーク（AI RMF 1.0、2023年1月26日公開）は4機能に分けます。

NISTは、Governが定着した後、多くの場合はMapから始めてMeasureやManageへ進み、必要に応じて機能間を行き来しながら繰り返すと説明しています。一度完了すればよい順番ではなく、繰り返し回る循環です。

信頼できるAIの7つの特性

AI RMFは7特性を挙げます。妥当性と信頼性（valid and reliable）、安全性（safe）、セキュリティとレジリエンス（secure and resilient）、説明責任と透明性（accountable and transparent）、説明可能性と解釈可能性（explainable and interpretable）、プライバシーの強化（privacy-enhanced）、有害なバイアスが管理された公平性（fair with harmful bias managed）です。

NISTは「妥当性と信頼性」を、信頼できるAIであるための必要条件とし、「説明責任と透明性」を他のすべての特性に関係するものと説明しています。特性同士は衝突することがあるので、文脈に応じたバランスが必要です。例えば、説明を詳しくすればするほど、プライバシーやセキュリティと衝突する可能性があります。

一見似ている3つの特性ですが、答える問いは異なります。透明性はシステムで「何が起きたか」、説明可能性は決定が「どのように」行われたか、解釈可能性は決定が「なぜ」そうなり、利用者に何を意味するかに答えます。ログで入力とモデルのバージョンを再現できることは透明性に当たり、顧客が自分の結果の理由を理解できるようにすることは解釈可能性の問題です。

生成AIプロファイルの12のリスク

NIST AI 600-1（生成AIプロファイル、2024年7月）は、生成AI特有または拡大するリスクを12に整理しています。

この表は、被害シナリオを見落とさないためのチェックリストとして便利です。事例ごとに12区分に目を通して該当するものを選び、選んだ区分ごとに具体的なシナリオを書きます。

リスク対応の4つの選択肢と残余リスク

AI RMFは、文書化したリスクへの対処を影響・可能性・利用可能な資源で優先順位付けし（MANAGE 1.2）、**緩和（mitigating）、移転（transferring）、回避（avoiding）、受容（accepting）**を挙げます（MANAGE 1.3）。

すべての統制を適用しても残るリスクを、残余リスクと呼びます。AI RMFは、下流の購入者と最終利用者に対する負の残余リスクを文書化するよう求めています（MANAGE 1.4）。残余リスクは隠すのではなく書き残し、受容権者が署名し、必要に応じてシステムを引き継ぐ側にも知らせます。移転もリスクをなくすわけではありません。契約で費用を分担できても、影響を受ける人の被害は残るため、人への影響が大きいリスクは移転だけで対処してはいけません。

リスク等級別の統制のマッピング

本章のスキル目標は「リスクレベルごとに統制をマッピングする」です。等級ごとに統制の組み合わせを定めれば、迅速かつ一貫した判断が可能になります。

マッピングでは2つの考えを避けてください。1つは、同じ等級なら統制も同じだという考えです。被害の原因が異なれば、統制も異なる必要があります。個人情報の漏えいが原因なら入力の最小化、誤答が原因なら根拠の確認と人によるレビューが中心となります。もう1つは、点数が低ければ法定義務も免除されるという考えです。これについては次節で扱います。

法定要件と裁量的統制を区別する

リスク登録簿の統制には、性格の異なる2種類が混在しています。一方は法令が要求するもの、もう一方は組織がリスクに比例して選ぶものです。

登録簿に「根拠」の列を設け、法令・契約・内部判断のどれかを示せば、裁量的統制はリスクに比例して減らしながら、法定要件は見落とさずに守れます。

記録と監査

説明責任は「後から説明できるか」で確かめます。次の記録は法令上必要、または実務上不可欠です。

ここではバージョン管理が中心になります。モデルを変更するたびにリスク管理文書を上書きすると、過去の時点での判断を説明できなくなります。版ごとに日付を付け、新たな記録として残してください。同時に、記録そのものも個人情報処理です。監査ログにプロンプト全文を丸ごと残せば、そのログが新しいリスクになります。必要な項目だけを、アクセス権限を制限し、保管期間を定めて残します。他法令に保管義務がある記録は、個人情報保護法第21条第3項に従い、他の個人情報と分離して保管します。

監査では2つを別々に確認します。設計の適切性は、リスクに対処できるよう統制が正しく設計されているかを問います。運用の有効性は、その統制が実際に機能したかを問います。規程に人によるレビューがあっても、サンプルを調べるとレビューの形跡がないことがあります。

運用中の監視と事故対応

AIは展開後も変わります。入力の分布が変化し、ベンダーがモデルを更新し、利用者が想定外の方法で使うためです。AI RMFは、展開後の監視計画を実行し（MANAGE 4.1）、影響を受けるコミュニティを含む関係者に事故や誤りを知らせ（MANAGE 4.3）、最終利用者と影響を受ける人が問題を報告し結果に異議を申し立てられる手続きを設けるよう求めています（MEASURE 3.3）。

監視計画には3つを記します。何を見るか（誤り率、集団ごとの性能差、苦情、人のレビューで修正された割合）、いつ行動するか（指標が超えてはならないしきい値）、誰が何をするか（停止、再評価、通知）です。法定通知とも結び付けます。会話ログの漏えい等を知った場合や、不正アクセスは確認したが情報主体を特定しにくい場合など、施行令の漏えい可能性の要件に該当すれば、第3章の72時間通知手続きが始まります。

ISO/IEC 42001：マネジメントシステム認証

ISO/IEC 42001（2023）は、AIを開発・提供・利用する組織が、AIマネジメントシステムを構築、実施、維持し、継続的に改善するための要求事項を定めた国際規格です。認証はISO自身が行うのではなく、独立した認証機関が審査して発行します。

認証が示すのは、「その組織にAIを管理する仕組みがあり、審査を通過した」という事実です。特定のAI製品の正確性・公平性の保証ではなく、法令遵守に代わるものでもありません。営業資料に使う場合は、どの組織、どの事業場、どの活動が対象か、認証範囲を正確に示す必要があります。供給者の認証を調達審査資料に使う場合も、自社のユースケースのリスク評価は別途行います。

フロンティア安全フレームワーク

一部のAI開発元は、最先端モデルの深刻なリスクを扱う自主的なフレームワークを公開しています。

こうしたフレームワークの目的は、甚大な被害につながりうる極端な能力リスクを、モデルの開発・展開段階で管理することです。調達審査では供給者の安全管理水準を示す資料になります。ただし、データ処理契約ではなく、個別出力の正確性や公平性を保証せず、導入企業が自社用途のリスクを評価し、法定責務を履行する責任も移しません。人工知能基本法第32条の安全性確保義務も、極めて大きな演算量の最先端システムを対象とする点で問題意識は似ていますが、法定義務と自主的フレームワークは、根拠と効力が異なります。

さらに深く

点数の落とし穴

影響5点×可能性5点などの点数表には、3つの落とし穴があります。異なる被害を1つの数字にまとめると、何を防ぐべきかが曖昧になります。発生可能性が低くても回復不能なリスクが、低い点数に埋もれます。そして、根拠の乏しい推定も数字になった瞬間、事実のように見えてしまいます。

解決策は、点数の隣に2つの事項を併記することです。1つは不確実性です。この評価は何を根拠としているのか、測定できていない集団や条件はないかを記します。もう1つは点数に関係なく対処する条件です。法定義務、回復不可能な被害、子どもや脆弱層への影響などが該当します。測定できなかった部分は「低リスク」ではなく「未測定」と表示し、引き継ぎを受ける側にも伝えます。生命・安全や権利に関わる重要な指標が未測定である場合には、展開を保留するかどうかを、リスクの受容権限を持つ人が明示的に決めます。

非決定的な出力と再現性

生成AIは次の語を確率的に選んで回答するため、同じ入力でも異なる答えを出すことがあります。そのため「あのとき、なぜその回答が出たのか」を完全に再現するのは困難です。それでも説明を諦めるわけにはいきません。再現の代わりに状況を示す証拠を残します。要求時刻、モデルとバージョン、システムプロンプトの版、検索で渡した文書の識別子、主要な設定、出力、人によるレビュー結果です。この一式があれば、同じ回答を再び作れなくても、どの条件で出た回答かを説明できます。

実務の場面

ヌルプム食品：初めてのリスク登録簿

食品メーカー「ヌルプム食品」は、AIユースケース9件を初めてリスク登録簿に載せることにしました。需要予測、生産ラインの異物検査の映像分析、マーケティング文生成、顧客問い合わせチャットボット、協力会社の書類要約などです。経営支援チームは当初、「食品安全に関わるので、すべて高にしよう」と提案しました。

リスク担当者は、事例ごとにまず被害シナリオを書きました。異物検査AIが見逃せば消費者が負傷し回復も難しいので、高としました。ただし既存の金属検出器と人によるサンプル検査を置き換えず、追加する構成にしました。マーケティング文は虚偽・誇大表示のリスクがあるため中（掲載前に担当者がレビュー）、協力会社の書類要約は内部の下書きなので低でした。

顧客問い合わせチャットボットでは意見が分かれました。アレルギー成分を尋ねる顧客への誤答が、健康被害につながりうるためです。担当者は全体を高にする代わりに、アレルギー・成分の質問には回答せず、公式成分表と相談員につなぐリスク回避の設計を選びました。それ以外の配送・注文は中のままです。生成AIサービスなので、人工知能基本法第31条の告知・表示は、等級と無関係な法定要件として別に示しました。

登録簿には、受容権者の名前と再評価日、そして「異物検査AIの夜間照明条件での性能は、まだ測定できていない」という不確実性のメモも併せて記載しました。

ドランドラン：自動的な利用制限の誤判定後の監査

地域コミュニティアプリ「ドランドラン」はAIで投稿を審査し、暴言や詐欺の疑いがある投稿を自動で非表示にし、繰り返されるとアカウントを一時停止します。先月ベンダーがモデルを新版に変更してから、地域の方言や、高齢者の分かち書き（韓国語の単語間に空白を入れる書き方）の習慣を含む投稿が、詐欺の疑いとして非表示にされることが増えたとの苦情が寄せられました。

監査担当者は、まず、何が変更されたのかを記録から調べました。幸い、この会社では、判定ごとに、モデルのバージョン、分類基準の版、判定の点数を残していました。バージョンを切り替える前後を比較すると、新しいバージョンでは、特定の表現に対する誤判定の割合が高くなっていることが分かりました。また、以前の評価は、標準語を中心とするテストデータだけで行われていたことも判明しました。そのため、このような集団ごとの差を測定できていなかったのです。

担当者は、3つの改善を勧告しました。第1に、アカウントの停止は自動で行わず、運営者が確認した後に行う方式に変更します。個人情報保護委員会の告示の別表が、自動検知した後に一時的に遮断し、要求があれば人が最終的に決定する運用を、自動化された決定の例外として挙げている点も参考にしました。第2に、投稿を非表示にされた利用者には、その理由と異議申立ての方法を知らせます。異議申立ては、人が7日以内にレビューします。第3に、モデルの切り替えを変更管理の対象とし、新しいバージョンは、地域別・年齢集団別のサンプルで検証してから適用します。ベンダーが公表した性能の点数は以前より良くなっている、という開発チームの説明は、この判断を変える理由にはなりませんでした。その点数は、自社の利用者集団を対象に測定した結果ではなかったからです。

監査報告書では設計の問題（評価データの代表性）と運用の問題（変更管理の欠落）を分け、誤って停止したアカウントの復旧と、個別の案内の結果を証拠として添えました。

間違えやすいポイント

1. 「全事例に最高の統制をかければ安全だ」 資源が分散し、本当に危険な場所を守れません。
2. 「供給者に認証があるから自社評価を省略する」 利用文脈のリスクは導入組織が評価します。
3. 「フロンティア安全フレームワークでバイアスや誤りも管理される」 極端な能力リスクを扱う枠組みです。
4. 「AI RMFは順に一度終えればよい」 機能は反復し、Governは全体に関わります。
5. 「契約で移転すればリスクは消える」 費用は分担できても被害は残ります。
6. 「低点数なら法定義務も減らせる」 点数と無関係に履行します。
7. 「ログで再現できれば説明したことになる」 再現は透明性、本人の理由の理解は解釈可能性です。
8. 「モデル変更時に最新版で上書きすればよい」 過去の説明には版別記録が必要です。

ひと目でわかるまとめ

公式ドキュメントで確認する

• NIST — AI Risk Management Framework：AI RMF 1.0、改訂通知、Playbook、生成AIプロファイル。
• NIST AIRC — AI RMF Core：4機能と下位区分（MANAGE 1.2〜1.4、4.1、4.3、MEASURE 3.3）。
• NIST AIRC — Trustworthy AI characteristics：7特性、透明性・説明可能性・解釈可能性の区別。
• NIST AI 600-1 — Generative AI Profile：12リスクの定義。
• ISO — ISO/IEC 42001 explained：AIマネジメントシステムと認証。
• Anthropic — Responsible Scaling Policy：現行版と改訂履歴。
• Google DeepMind — Frontier Safety：目的と版の履歴。
• OpenAI — Preparedness Framework (v2)：追跡区分と能力基準。

セルフチェック

5-1. 「ハルシネーションリスク」というラベルを、影響を受ける人、発生条件、被害、回復可能性が分かる、1文の被害シナリオに書き換えてください。

5-2. NISTが示す信頼できるAIの7つの特性を書き、そのうち必要条件とされるものと、他のすべての特性に関わるとされるものを選んでください。

5-3. NIST AI 600-1が整理した12のリスク区分から5つを書き、この一覧をリスク登録簿の作成にどう活用するか、1文で説明してください。

5-4. リスク対応の4つの選択肢を書き、人への影響が大きいリスクを契約上の移転だけで処理してはいけない理由を書いてください。

5-5. 本章で扱った人工知能基本法と個人情報保護法上の記録のうち、保管期間が定められたものを2つ、期間とともに書いてください。

5-6. AIマネジメントシステム規格の認証書が証明する範囲と、証明できない範囲を、それぞれ2つずつ対比して書いてください。

5-7. （設計）AIユースケースを4つ仮定してリスク登録簿を作ってください。各行には被害シナリオ、影響、可能性、等級、統制、根拠（法令・契約・内部）、受容権者、不確実性を書いてください。

実習課題