AIリスクアセスメントは、AIを使う業務で何が起きると困るかを具体化し、利用条件を決める作業です。同じサービスでも、社内の文章案を作る場合と、顧客へ直接回答する場合では、誤りが届く相手も止められる場所も変わります。サービス名に加え、用途と実行範囲を単位に評価します。
評価表を埋めた後には、誰が、どの条件なら利用を認めるかを残します。判断できない事項は保留とし、確認先を決めます。
評価する業務の切り出し方
申請者は、業務の目的、入力する情報、AIが行う処理、出力の行き先を一続きで書きます。顧客対応に使うという説明なら、過去の問い合わせを要約するのか、返信案を作るのか、そのまま送信するのかを分けます。
評価対象の書き方・架空の例
問い合わせ担当者が、承認済みの商品FAQを参照して回答案を作成する。顧客を識別する情報は入力しない。商品担当者が仕様を照合し、問い合わせ担当者が送付する。AIからの直接送信は行わない。
ここまで書けば、確認する資料と担当者を決められます。AIが社内システムを操作する場合は、閲覧できる範囲と、更新できる範囲も加えます。
社内で自動回答へ変更したくなった場合は、評価対象が変わります。過去の承認結果を、そのまま新しい使い方へ引き継がないようにします。
評価で確認する問い
最初から細かな点数を付けるより、想定する誤りと被害を文章で書く方が判断しやすい場合があります。発生頻度の根拠がないのに低いと採点すると、まだ確認していないリスクまで小さく見積もってしまいます。
| 確認する問い | 記録する内容の例 |
|---|---|
| 誰が影響を受けるか | 作成者だけ、社内の複数部門、顧客、採用候補者など |
| 誤ったときに何が起きるか | 文書の作り直し、誤案内、契約上の約束、本人の不利益など |
| 入力情報を扱えるか | 情報区分、契約条件、利用環境の確認結果と未確認事項 |
| 使う前に誰が誤りを見つけられるか | 根拠資料、確認者の知識、確認に割ける時間 |
| 実行後にどこまで戻せるか | 送付前に修正できる、訂正が必要、完全には回収できないなど |
| 問題をどう検知して止めるか | 確認記録、報告先、停止権限、代替の業務手順 |
人が確認するという条件は、確認者と方法まで具体化します。担当者が読んでも正誤を判断できない専門的な文章なら、その確認だけでリスクが小さくなったとは判断できません。
業務ごとの評価と利用条件の例
以下は編集部が作成した仮想例です。公的な採点基準や、どの会社にも当てはまる承認区分ではありません。
| 用途 | 主な懸念 | 利用条件と判断の例 |
|---|---|---|
| 公開済みの会社紹介文の整理 | 実績や対応範囲を勝手に追加する | 原資料と照合し、広報担当者が確認して掲載。条件を満たす範囲で承認 |
| 顧客への回答案の作成 | 仕様の誤りや、未承認の約束が相手に伝わる | 確認できる商品に限定し、送信前に担当者が照合。直接送信を認めず条件付き承認 |
| 顧客管理システムの情報更新 | 対象顧客の取り違えや、複数件の誤更新 | テスト用データで差分と復旧を確認するまで本番更新を保留 |
| 採用候補者の自動順位付け | 本人への不利益、評価の偏り、判断根拠を説明できない | 人事や法務などによる専門的な検討へ回す。文章作成用途の承認範囲には含めない |
条件を付けた後も残る懸念を、残存リスクとして記録します。回答案を人が確認しても、繁忙時に読み飛ばす可能性まではなくなりません。そのため、担当者が処理できる件数に制限する、確認者が不在なら通常の方法へ戻す、といった運用条件も検討します。
影響の大きい用途では、単に人の確認を追加するだけで承認せず、用途そのものを見直す判断も必要です。自社に評価できる専門担当者がいない場合は、判断に必要な知見を確保できるまで保留します。
条件付き承認の記録
評価結果は、申請者が実行できる条件に書き換えます。十分に注意する、適切に確認する、という記載では、開始してよい状態が分かりません。
承認記録の例・架空
対象：商品Cに関する回答案の作成。
開始条件：最新版FAQの管理者を決め、商品担当者による送信前確認を手順に反映する。
対象外：価格交渉、例外対応、自動送信。
残る懸念：確認者が不在の場合に照合できない。
対応：不在時はAI回答案の送付を止め、既存の問い合わせ手順へ戻す。
承認者・期限：権限者の氏名、承認日、試行終了日を記録し、終了時に件数と修正内容を見直す。
開始条件が付いている場合は、条件を満たしたことを誰が確認したかまで残します。承認済みの表示だけが先に共有され、準備前に利用が始まるのを避けるためです。
評価後の確認条件付き承認を出した人は、利用部門が条件を実行できるか確かめます。確認担当者や資料が用意できないなら、条件を増やすだけで進めず、対象業務を絞ります。
再評価が必要になる変更
定期的な見直しに加え、入力情報、利用者、接続先、実行できる操作が変わったときに再評価します。下書き作成から自動送信へ、1部門から全社へ、といった変更は、元の評価で想定した確認工程や影響範囲を変えます。
事故が起きなかった期間だけで、条件を緩める判断はしません。確認者が何件の誤りを修正していたかも見ます。送信前に毎回人が直していたなら、その工程をなくす根拠には使えないためです。
評価の進め方を検討する参考には、IPAサイト掲載のテキスト生成AIの導入・運用ガイドラインがあります。中核人材育成プログラムの卒業プロジェクト成果物で、リスクアセスメントを扱っています。自社の用途や確認体制に合わせて評価項目を選んでください。
よくある質問
リスクを点数化した方がよいですか
同じ基準で案件を比べる助けにはなります。ただし、点数の意味と判定根拠を揃える必要があります。合計点が低くても、解消していない契約上の問題や大きな不利益を見落とさないよう、保留条件を別に定めます。
小さな会社でも評価表が必要ですか
複雑な様式から始める必要はありません。用途、入力情報、誤った場合の影響、確認者、利用条件、承認者を短く記録すれば、後で変更があった際に見直せます。記録量より、実際の使い方と条件が一致しているかを確認します。