- 公開日
用途ごとのAIリスク分類では、誤ったときの影響と回復可能性から、任せる範囲、確認者、実行前の承認を決めます。その区分をプロンプトだけでなく、利用できるツールや権限にも対応させ、判断の根拠を用途ごとの記録に残します。利用目的や外部への作用が変わったら、以前の区分をそのまま使わず、責任者が見直す仕組みが必要です。
AI製品ではなく使い方を分類する
同じAIでも、提案書の要点を担当者向けにまとめる用途と、提案の採否を決める資料を作る用途では、誤りが影響する先が違います。さらに、その結果を取引先へ送るなら、文書の確認に加えて送信先や送信内容の承認が問題になります。「この製品は低リスク」という登録だけでは、こうした違いを扱えません。
ここでいう用途は、作業名に加え、使う人、入力情報、出力の利用先、AIが行う操作までを含む単位です。「文書要約」よりも「設備担当者が、入力を許可された提案書を読み、検討用メモを作る。採否の決定と外部送信は行わない」と記した方が、許可した範囲を確認できます。
NISTのAI RMF Coreでは、用途や利用状況の把握、役割の明確化、リスクに応じた対応を扱っています。以下の区分や記録欄は、それらを業務へ落とし込むための設計例です。NISTが定める等級や法令上の分類ではありません。AI RMFは任意に利用する枠組みで、業務条件に応じて適用内容を選びます。参照するのはAI RMF 1.0で、確認時点の公式ページには改訂作業中と表示されています。国内の資料では、総務省・経済産業省のAI事業者ガイドライン（第1.2版）が別添7にチェックリストを収めており、点検の観点を洗い出す参考になります。どの用途にどの区分を付けるかは、組織が業務条件に合わせて判断します。
まず、失敗した場合に何が起こるかを書きます。検討用メモの誤りなら、原資料との照合で直せるかもしれません。設備案の比較条件を落とすと、採否や予算配分に影響します。誤った採否通知を送れば、取引先が手配を始める可能性があります。影響は金銭だけでなく、業務の停止、信用、人の権利や安全も対象にします。
次に、誤りにいつ気付き、誰がどこまで戻せるかを確かめます。文書の修正が可能でも、相手が読んだ情報や、それを受けて始めた行動は元に戻せないことがあります。回復可能性を「取り消しボタンがあるか」だけで判断せず、発見までの時間と影響の残り方を含めて考えます。
起こりやすさも、過去の不具合、資料の欠落、利用回数などから検討します。ただし、未測定の発生率を数字で埋める必要はありません。「担当者が確認するから問題ない」と結論する前に、原資料を見られるか、判断する時間があるかも確認します。根拠が不足する場合は、区分を確定するために何を確かめるかを記録します。
同じ設備提案から三つの用途を分ける
架空の会社が、業務用設備の更新案を検討する場面を考えます。提案書には「候補Aは既存設備と接続できる。保守範囲は別紙による。候補Bは接続条件を確認中」とあります。別紙は未入手です。AIが利用する提案書と社内の比較基準は、指定のサービスへ入力できることを確認済み、という前提にします。
元の依頼は「提案を整理して、良さそうな案を進めて」です。このままでは、要約、採否の判断支援、取引先への通知のどこまでを任せるのか分かりません。入力資料を同じに保ち、出力の利用先と許可する操作を変えて、次のように用途を分けます。表の区分名は、この架空の会社で使う運用上の呼び名です。
| 用途と区分例 | 影響と回復可能性 | 適用する制御 | 不足時の扱い |
|---|---|---|---|
| 担当者向け要約／限定利用 | 読み違いは検討メモへ波及。判断前なら原資料へ戻して修正可能 | 参照箇所を付け、担当者が照合。送信・発注機能は付与しない | 別紙の保守範囲と候補Bの接続条件を未確認として残す |
| 設備案の採否判断支援／判断支援 | 条件の抜けが予算配分や設備選定へ影響。決定後は手戻りが増える | 比較基準と根拠を提示し、設備担当者が検証。採否は決裁者が判断 | 未確認条件で結論が変わるなら、推薦を保留して照会する |
| 決定内容の取引先への送信／外部実行 | 誤通知で相手が手配を開始するおそれ。訂正だけでは回復しない | 決裁記録、宛先、本文、添付を照合し、権限のある人が承認 | 決定内容または宛先が未確認なら送信しない |
区分は危険度の順位だけを示すものではありません。要約では原資料との一致が中心で、判断支援では比較条件と決定権限、外部実行では実行対象と承認内容の一致が加わります。用途ごとに必要な制御が異なるため、単に「高リスク」と書くより、何を切り替えるのかを対応させます。
この例で要約に期待するのは、「候補Aは接続可能と記載。保守範囲は別紙未入手。候補Bの接続条件は確認中」という出力です。同じ情報から採否を支援するときは、「候補Aが優位」と決め切らず、保守範囲と接続条件が比較基準を満たすか確認する作業へつなぎます。資料に書かれていることと、採用に必要な条件が満たされたことは別です。
外部送信では、資料が揃ったことだけでも足りません。採否の決裁を得ていなければ、作成できるのは未送信の文案までです。ここで示す出力や分岐は設計上の期待であり、実際のモデルで動作を検証した結果ではありません。
区分を決める人と制御を設定する人をつなぐ
分類の提案は、業務の目的と影響を説明できる業務責任者が作ります。システム管理者は、使うサービス、連携機能、実際の権限が提案された範囲に収まるかを確かめます。情報管理の担当者は、入力する資料や出力の共有条件を照合します。その上で、組織内で権限を与えられた承認者が、利用範囲と残るリスクを確認して適用を決めます。
これは役割の分担例であり、部署を四つ設けるという意味ではありません。兼務する場合も、誰が何を確認したかは分けて残します。利用者の都合だけで分類を緩められないよう、区分の承認者と例外の承認者を決めておくと、迷った案件の相談先が明確になります。
また、用途の利用許可と一件ごとの実行承認は区別します。「外部送信用の用途として登録済み」は、あらゆる相手への送信許可を意味しません。送信のたびに、認められた範囲の宛先、内容、操作であるかを確かめます。分類記録が有効でも、実行する人に権限がなければ進めません。
情報の区分も別に照合します。「要約だから限定利用」という扱いは、機密資料を任意のサービスへ入力する許可にはなりません。入力可能なサービス、保存条件、共有先が変わる場合は、用途の影響評価と情報の利用条件を両方見直します。分類表を細かくするより先に、この二つを別々に照合します。
プロンプトと実行権限を一組で切り替える
分類を決めたら、各用途でAIに求める出力と、実行環境が許す操作を対応させます。共通のプロンプトに「リスクに応じて慎重に」と追加するだけでは、何を変えるのか不明です。分類を確定するのは登録された判断者とし、AIには資料不足や用途の変化を報告させます。
前の例なら、要約用の指示は次のようにできます。
提案書から各候補の接続条件と保守条件を抽出してください。
参照箇所を示し、未入手の別紙に依存する内容は未確認と記してください。
採否の推薦や外部操作は行わず、担当者向けの検討メモを作成してください。採否判断支援では、抽出した情報を比較基準へ対応させます。
指定した比較基準ごとに、候補の条件、根拠、未確認事項を並べてください。
未確認事項で採否が変わる場合は、推薦を保留し、必要な資料と確認先を示してください。
採否の決定や取引先への通知は行いません。外部送信用の文案では、承認された決定内容が起点になります。
承認済みの決定記録に基づき、指定した宛先への通知案を作ってください。
記録にない約束や条件を加えず、本文と添付の確認点を示してください。
決定記録との不一致や未確認事項があれば、送信を保留して確認へ戻してください。これらは説明用の文例です。差し替えるのは参照資料、比較基準、決定記録、宛先などで、実際に利用を認めた範囲に合わせます。回答後は、未確認事項が事実へ変わっていないか、採否や約束を勝手に追加していないかを原資料と照合します。モデルの自己申告を分類や承認の証拠にはしません。
システム側では、要約と判断支援の用途に送信や発注の権限を与えず、外部送信の用途でも許可された操作だけに限定します。OWASPのLLM06:2025 Excessive Agencyは、機能・権限の最小化、高影響の操作への人の承認、下流システムでの認可を挙げています。プロンプト中の「送信しない」を、アクセス制御の代わりにはできません。
用途の記録に判断と証拠を残す
分類結果だけの一覧では、条件が変わったときに見直せません。一方で、すべての用途に長い審査票を課すと記録の負担が重くなるため、まず実際に使う用途から記録を始めます。一つの用途について、範囲、判断理由、担当者、制御、証拠がたどれるようにします。次は、設備案の採否判断支援を登録する際の記入例です。記載した資料名や版は架空であり、記録項目の構成も一例です。
| 記録する項目 | 記入例 |
|---|---|
| 用途と対象範囲 | 設備更新案の比較資料作成。設備担当者が使用。採否決定・発注・送信は対象外 |
| 区分と判断理由 | 判断支援。条件の欠落が設備選定へ影響し、決定後の変更に手戻りが生じる |
| 判断者と確認者 | 業務責任者が区分を提案、設備担当者が比較条件を確認、管理者が権限を確認、部門の承認者が利用を許可 |
| 判断の証拠 | 提案書の対象版、社内比較基準、情報入力の許可記録、権限設定の確認記録 |
| 適用する設定 | 比較支援プロンプト第2版、読み取りと文案作成のみ。送信・発注機能なし |
| 未確認事項と対応 | 別紙の保守範囲が未入手。調達担当者へ照会し、採否の推薦は保留 |
| 残るリスクと扱い | 原資料の誤りや確認者の見落としは残る。比較結果を原資料と照合して決裁へ回す |
| 承認日と再確認 | 承認日と見直し期限を記入。用途、接続機能、入力条件の変更時は期限前でも再審査 |
| 変更履歴 | 旧区分、変更理由、変更した設定、確認者、適用開始日を保存 |
記録には用途を特定する名前や識別子を付け、適用状態も示します。上の例なら「比較資料の作成は利用可、採否の推薦は保留」と分けられます。保守範囲を確認する別紙が届いても、自動的に保留を解除せず、設備担当者が比較基準との対応を確認し、承認された範囲で先へ進めます。登録の承認、案件の資料確認、実行の承認を一つの「承認済み」にまとめないことが、後からの追跡に役立ちます。
「人が確認する」と記すだけでは、根拠を確認した証拠になりません。原資料のどの箇所を照合したか、どの設定で送信機能が使えないかを、対応する記録へ結び付けます。保存するのは必要な参照情報と判断結果を中心にし、提案書や個人情報を台帳へ重複保存しない方法も選べます。
確認前に「実装済み」とは記入しません。制御を設計した段階、設定を反映した段階、動作を確かめた段階を分け、未確認なら確認者と実施予定を残します。重要な制御を確認できない間は、その制御が働くことを前提にした利用を許可しません。
用途変更と例外を同じままにしない
再分類のきっかけは、モデルの更新だけではありません。要約を決裁資料へ転用する、外部送信を追加する、対象者や利用件数を広げる、資料やサービスを変更する、といった変化も含みます。事故や苦情、想定外の出力を受けた場合も、現在の区分と制御が実態に合うかを見直します。
設備案の要約に「そのまま取引先へ結果を知らせて」という依頼が加わったら、以前の要約用途の許可では進めません。利用者は変更内容を業務責任者へ渡し、責任者が影響と回復可能性を再評価します。管理者は必要な権限と承認経路を確認し、承認者が新しい範囲を認めた後に設定を切り替えます。判断中は、引き続き許可されている社内向けメモの作成にとどめられます。
変更記録には、旧用途の「要約のみ」と新用途の「採否通知」を並べ、追加される影響、必要な決裁記録、送信権限を明記します。新しい経路で承認を確かめられないなら、その用途の開始は保留です。こうして変更前後を残せば、後日「送信できるようになった理由」と「許可していない送信」を区別できます。
切り替え後は、新しいプロンプトを保存したことだけで完了にせず、適用される設定と利用可能な操作を確かめます。旧版を使い続ける経路があれば、対象を特定して失効させるか、利用範囲を限定します。見直し期限は業務の変化や影響に応じて決め、一律の期間を置くだけで変更の監視を済ませないようにします。
急ぎの案件で通常の確認者が不在なら、誰でも確認を省略できる例外にはしません。代替の確認者を指名できる権限者、対象案件、理由、補完する制御、終了条件を記録します。たとえば、指定された代理の設備担当者が原資料を確認し、その案件に限って比較資料を決裁へ回す扱いです。この例外手続きは、法令・契約の制限や、承認者自身が持たない権限を解除するものではありません。
期限付きの例外は、期限後に元の条件へ戻ったかを確認して閉じます。繰り返されるなら、その理由を調べて通常ルールの改定を検討しますが、例外の蓄積だけで新しい許可が成立したことにはしません。最初の運用では、実際に使う一つの用途について、判断者と証拠、設定、変更時の連絡先までを埋め、現場の使い方と照合するところから始められます。
複数の用途で使い回す統制の一覧はAIの統制一覧を作る――用途ごとに「適用する理由」まで記録するで、一つの作業の中で確認の厳しさを切り替える考え方はAIの確認をどこまで厳しくする？ 同じ作業でも変わるリスクの見方で説明しています。AIエージェントに任せる範囲から動作確認までの順番はAIエージェントの安全設計で整理しています。
基本から確認する：この記事の前提になる考え方は、「AIを使う前の安全確認チェックリスト（AIKYで確かめる12項目）」にまとめています。
