AIリスクアセスメントの進め方｜機密情報、著作権、誤情報、権限の評価項目を整理する
AIのリスク評価というと、危ないか安全かの二択で議論されがちです。ただ、実際の現場では、同じツールでも業務とデータによって見るべきリスクが変わります。
結論から言うと、AIリスクアセスメントは、機密情報、著作権、誤情報、権限、説明可能性の5観点で評価すると整理しやすくなります。さらに生成AIアプリでは、システムプロンプトやツール定義が漏れない前提にせず、秘密情報を入れない、認可をモデル外に置く、出力を検証する、という条件まで含めて判断することが重要です。
本記事のポイント
- AIリスクアセスメントは、ツール単位ではなく、業務、データ、出力用途の組み合わせで行う方が実務に合います。
- 機密情報、著作権、誤情報、権限、説明可能性に加えて、システムプロンプト漏洩を発生前提で見ると優先度を整理しやすくなります。
- リスク評価は利用禁止の判定だけでなく、条件付き承認や追加対策の判断にも使うべきです。
リスクアセスメントの結論は「業務とデータに対して行うこと」
生成AIそのものを一律に危険視しても、現場では判断に使いにくくなります。実務で必要なのは、どの業務で、どのデータを使い、どこへ出すのかに対してリスクを評価することです。
この見方にすると、何が要申請案件で、何が自己判断範囲かを切り分けやすくなります。
AIリスクアセスメントは、危険性を語ることではなく、どの条件なら使えるかを見極める作業です。
| 観点 | 確認すること | 代表的な対策 |
|---|---|---|
| 機密情報 | 持ち込むデータに機密や個人情報があるか | 匿名化、入力禁止、限定環境利用 |
| 著作権 | 出力や学習元に権利リスクがあるか | 引用確認、公開前レビュー |
| 誤情報 | 誤答時の影響が大きいか | 人のレビュー、出典確認 |
| 権限 | 接続先や操作範囲が適切か | 権限分離、HITL導入 |
| 説明可能性 | 後から根拠を説明できるか | ログ、出典、承認記録 |
システムプロンプト漏洩は「発生前提」で評価する
生成AIアプリやAIエージェントを評価するときは、システムプロンプトを隠せるかどうかだけで安全性を判断しない方が現実的です。AWS Security Blog は2026年7月8日の システムプロンプト漏洩対策の記事 で、現在の生成AIシステム上、完全な解消策がないため、漏れる前提で設計し、露出を減らす防御を重ねるべきだと整理しています。
実務で重要なのは、プロンプトに「絶対に開示しない」と書くことではありません。APIキー、認証情報、内部エンドポイント、データベースクエリ、過度に詳細なツール定義をシステムプロンプトへ入れないこと、アクセス制御をモデルの指示ではなくアプリケーション層で実装すること、出力にプロンプト断片やカナリアトークンが混ざらないかを検証することです。
| 評価項目 | 確認すること | 条件付き承認に入れたい対策 |
|---|---|---|
| プロンプト最小化 | 秘密情報、内部API、不要な業務ロジックを入れていないか | 必要最小限の指示と、RAGやツール結果の分離 |
| モデル外の認可 | 「このユーザーには見せない」をプロンプト指示だけにしていないか | 認証、認可、レート制限をアプリケーション層で実装 |
| 攻撃入力の検知 | 指示文の開示要求や多段の抽出要求を検知できるか | プロンプト攻撃フィルタ、テストケース、ログ監視 |
| 出力検証 | 出力にプロンプト断片、内部名、想定外形式が混ざらないか | カナリアトークン、スキーマ検証、類似度検知 |
この観点を入れると、AIリスクアセスメントは「このツールは安全か」ではなく、「漏れても重大事故にならない設計か」を見る作業になります。顧客データや業務権限を扱う用途では、プロンプト管理、認可、監査ログ、出力検証をセットで確認する方が、後から説明しやすくなります。
GRCに接続するなら、評価・統制・証跡を1セットで見る
Salesforce Blog は2026年7月1日の記事で、GRC戦略はデータ保護とAI活用の拡大を両立させるための土台だと整理しています。AIリスクアセスメントでも同じで、評価シートを作るだけではなく、評価結果を統制と証跡に接続して初めて再利用できます。
GRCを難しく考えすぎる必要はありません。AI利用の文脈では、リスクを見つける、必要な統制を置く、判断理由と承認を残す、定期的に見直す、という4つの流れに分けると実務へ落とし込みやすくなります。
| GRCの要素 | AIリスクアセスメントで見ること | 残すべきもの |
|---|---|---|
| 評価 | 業務、データ、出力用途ごとにリスクを判定する | 評価観点、判定理由、前提条件 |
| 統制 | 使ってよい環境、権限、レビュー、停止条件を決める | 承認条件、利用範囲、責任者 |
| 証跡 | 誰が申請し、誰が承認し、どの条件で使ったかを追えるようにする | 申請記録、承認ログ、利用ログ、例外記録 |
| 改善 | 差し戻しや例外案件から基準を更新する | 月次レビュー、ルール改定履歴、再発防止策 |
この形にすると、AIリスクアセスメントは「禁止するための審査」ではなく、使える条件を明確にする仕組みになります。高リスク案件でも、限定環境、権限分離、人の最終確認、ログ保存を条件にすれば進められる場合があります。逆に、証跡が残らない用途は、便利でも本番利用へ進めにくいと判断できます。
要申請案件になりやすいパターン
- 個人情報や顧客データを含む案件
- 顧客向け公開物や契約関連文書
- 外部サービスへの自動接続を含む案件
- 誤情報の影響が大きい案件
- 出力根拠の説明が求められる案件
評価で起きやすい失敗
よくあるのは、機密情報だけに注目して、著作権や誤情報、権限を見落とすことです。逆に、抽象的な倫理論ばかりで、どの案件を申請対象にするかが決まらないケースもあります。
評価観点を固定し、案件ごとに同じ順番で見ると、属人的な判断を減らしやすくなります。
リスクアセスメントの進め方
- まず重要業務を洗い出す。
- 次に入力データと出力用途を確認する。
- 5観点で評価し、要申請ラインを引く。
- 必要な対策を条件付き承認へ反映する。
- 例外案件を月次で振り返る。
条件付き承認で先に決めておきたい標準対策
リスク評価をしても、結論が「気をつけて使う」で終わると運用に落ちません。実務では、高リスクだから即禁止ではなく、どの条件を満たせば利用可能かを標準化しておく方が回りやすくなります。
たとえば、個人情報を含む案件なら匿名化を前提にする、公開文書なら人のレビューを必須にする、といった条件付き承認の型を決めておくと、申請側も承認側も判断が揃います。
| 論点 | 条件付き承認で置きやすい条件 | 承認時に残したい記録 |
|---|---|---|
| 機密情報 | 匿名化済みデータのみ利用可 | 匿名化方法とデータ区分 |
| 著作権 | 公開前に法務または編集レビューを実施 | レビュー者と確認日 |
| 誤情報 | 対外出力は人の最終確認を必須化 | 確認者と出典確認の有無 |
| 権限 | 接続先を限定し、書き込み権限を分離 | 接続先と権限範囲 |
同じツールでも、用途ごとに評価の重みは変わる
社内メモの要約と、顧客向け提案書の初稿では、同じ生成AIでも重く見るべきリスクが違います。前者では機密情報と保存先、後者では誤情報と著作権、さらに説明可能性の重みが上がります。
この違いを無視して一律評価にすると、軽微案件まで重くなり、逆に高リスク案件の論点が埋もれます。業務カテゴリごとに「特に重く見る観点」を先に決めておくと、審査の濃淡をつけやすくなります。
- 社内向け要約は、機密情報と保存先管理を優先して見る
- 顧客向け文書は、誤情報、著作権、レビュー体制を重く見る
- 自動連携を伴う案件は、権限と停止条件を最優先で見る
- 経営判断に使う分析は、説明可能性と根拠保存を厚く見る
評価シートには「判断理由」まで残す
AIリスクアセスメントが形骸化しやすいのは、結果のラベルだけを残して理由を書かないときです。要申請、条件付き承認、承認不要といった判定だけが残っても、後から同種案件が来たときに再利用できません。
そのため、評価シートには点数や区分だけでなく、『なぜその判定になったか』『どの対策を前提にしたか』まで短く残しておく方が有効です。判断理由が残っていれば、月次レビューで基準のばらつきも見直しやすくなります。
- 業務目的と出力用途を最初に書く
- 使用データの区分と保存先を明記する
- 高く評価したリスク観点とその理由を残す
- 承認条件として付けた対策を列挙する
- 再審査が必要になる条件を明記する
評価結果を月次レビューへ戻すと、基準が安定する
案件ごとの評価で終わらせず、月次で振り返ると、どの観点で判断がぶれやすいかが見えてきます。たとえば、著作権だけ厳しく見ている一方で、権限設計が甘い、といった偏りも把握しやすくなります。
月次レビューでは、差し戻し件数、条件付き承認件数、再審査になった理由を見ていくと、評価基準を更新しやすくなります。AIリスクアセスメントは一度作って終わりではなく、案件を通じて調整する運用が前提です。
実際には、営業資料の要約、契約レビュー補助、顧客向け提案書、社内分析レポートでは、同じ5観点でも重みが変わります。こうした実例を評価シートに数本ためておくと、新しい申請が来たときに似た案件と比較でき、審査速度と一貫性の両方を上げやすくなります。
AIエージェント運用で先に決める境界
AI エージェントの記事では、モデルやツールより先に、どこまで自動化し、どこで止めるかを決める方が実装が安定します。入力データ、承認、例外処理、監査ログを分けて設計すると、現場が安心して使いやすくなります。
特に KPI、Runbook、権限、例外対応のテーマは、それぞれ単独ではなく、同じ運用レーンの別要素として読む方が実務ではつながりやすくなります。
| 論点 | 先に決めること | 曖昧だと起きること |
|---|---|---|
| 入力データ | 正本、更新責任、参照範囲 | 出力は出るが根拠が追えない |
| 承認フロー | 誰が確定し、誰が止めるか | 自動化が進んでも現場が使わない |
| 例外処理 | 止め方、戻し方、再実行の条件 | 障害時に復旧が属人化する |
| 評価指標 | 時短だけでなく品質も見るか | PoC で止まり改善が続かない |
PoCで終わらせないための進め方
AI エージェントは、派手なデモより、例外処理と確認ポイントを先に置く方が本番運用に入りやすくなります。どこで人が確認し、どのログを残し、何を再学習やルール変更につなげるかが継続の鍵です。
そのため、本文では実装の前提として、Human in the loop、Runbook、監査ログ、KPI をセットで扱う方が、個別テーマの意味が伝わりやすくなります。
見直し時に確認したいチェックリスト
- 自動化対象と人手判断の境界が visible text で読めるか。
- 障害時の止め方と戻し方が、運用の流れとして説明されているか。
- KPI が時短だけでなく品質や差し戻しも見ているか。
- 監査ログと承認記録が改善に結びつく設計になっているか.
よくある質問
AIリスクアセスメントは法務だけで行えますか？
法務だけでは足りません。情シス、事業部、必要に応じて監査や広報も関与した方が実務に合います。
すべてのAI利用で5観点を評価すべきですか？
重さは案件によりますが、重要案件では5観点を固定した方が判断しやすくなります。
高リスク案件は一律で禁止すべきですか？
必ずしもそうではありません。条件付き承認や追加対策で進められる場合もあります。
リスクアセスメントの結果はどこへ残すべきですか？
申請記録、承認記録、月次レポートに反映すると運用に接続しやすくなります。
AIリスクアセスメントとGRCは何が違いますか？
AIリスクアセスメントは個別案件を評価する作業です。GRCは、その評価結果を統制、証跡、改善サイクルへつなげる枠組みです。評価だけで終わらせず、承認条件、利用ログ、月次レビューまで接続すると、同じ判断を次の案件にも再利用しやすくなります。
システムプロンプト漏洩はAIリスク評価に入れるべきですか？
入れるべきです。システムプロンプトやツール定義は漏れない前提にせず、秘密情報を入れない、認可をアプリケーション層で行う、出力検証やログ監視を置く、という追加対策の有無で評価します。
