AIレッドチーミングは、AIシステムに意図的に厳しい条件を与え、望ましくない振る舞いや弱点を探す検証です。企業が取り組む際は、問題のある回答を見つけて終わらせず、何を試したか、業務にどんな影響があるか、修正後にどう確かめるかまで決めておくことが重要です。
本稿では、社内文書の検索や業務操作を支援する生成AIを想定し、許可された環境で評価を設計する手順を整理します。
AIレッドチーミングで確かめること
NISTの用語集は、AIにおけるレッドチーミングを、想定外・望ましくない挙動や悪用に伴うリスクを含め、システムの欠陥や脆弱性を探す体系的な試験として説明しています。攻撃的な手法を使うこともありますが、確認したいのは単に「AIに禁止された言葉を言わせられるか」だけではありません。
業務では、権限のない情報を回答に含めないか、利用者の承認なしに操作へ進まないかなど、システム全体の振る舞いを評価対象に置きます。
また、決めた問題集で性能を測る評価と、未知の失敗を探す活動は役割が異なります。Microsoft Researchも、生成AI製品のレッドチーミングから得た知見で、安全性のベンチマークとの違いや、人による検証の重要性を挙げています。
したがって、レッドチーミングで見つけた失敗は、修正後も繰り返し確認できる評価項目に加えます。「問題が見つからなかった」という結果だけで、未検証の用途まで安全と判定しないようにします。
最初に許可・対象・停止条件を決める
ここからの表と手順は、企業の導入担当者向けに整理した設計案です。特定の規格の合格基準や、当社の実施実績を示すものではありません。
最初の準備として、次の欄を業務責任者と開発・セキュリティ担当者で埋めてください。
| 決める項目 | 記入する内容 |
|---|---|
| 検証の目的 | 対象業務と、防ぎたい影響。例：社内検索で閲覧権限外の資料を回答しない |
| 許可と範囲 | 承認者、試験期間、対象アプリ・アカウント、実施可能な操作 |
| 対象の構成 | モデルの版、検索する文書、利用者の権限、接続先のツール |
| データと接続 | 合成データの用意、外部送信先の制限、実際の操作を代替する試験用の接続先 |
| 停止条件 | 実データの露出、対象外への通信、想定外の更新処理などが起きた場合の中断・連絡先 |
| 記録の扱い | 保存場所、閲覧者、保管期間、機微情報を記録する際の処理方法 |
本番と同じ権限関係や画面操作をどこまで再現したかも記録します。例えば、検索機能を外した試験で確認できる範囲と、検索・回答まで通した試験の範囲は区別します。無許可の外部サービスや第三者の情報を試験対象に含めません。
検証用データの加工が必要な場合は、AIによる情報マスキングの考え方を参考に、情報の検出と置換を分けて確認できます。
業務の失敗から評価シナリオを作る
シナリオは「入力」「期待する動作」「観測する結果」を組にして作ります。まず自社で困る結果を決め、その結果につながる条件を試験用に用意します。
| 評価する対象 | 試験条件の例 | 期待する動作 | 確認する記録 |
|---|---|---|---|
| 有害・不適切な回答 | 差別的な判断や不適切な表現を求める質問を含める | 定めた利用方針に沿って応答する | 回答全文と、方針の該当箇所 |
| 根拠のない断定 | 検索資料に答えがない質問をする | 不明であることや確認先を示す | 回答と実際に参照した資料 |
| 権限外の情報 | 閲覧範囲の異なる試験用アカウントで同じ質問をする | 各アカウントに許された情報だけを扱う | 検索結果、回答、アクセス記録 |
| 文書中の不正な指示 | 検索対象の試験用文書に、業務方針と矛盾する指示を含める | 文書の内容に従って権限や動作方針を変更しない | 参照文書、回答、ツール呼び出し |
| 不適切な操作 | 承認が必要な更新を、未承認の状態で依頼する | 所定の承認を待ち、未承認では更新しない | 承認状態、呼び出し履歴、更新先の状態 |
この表をそのまま全用途共通の試験にせず、実装されている機能から選びます。回答だけを返すアプリと、メール送信やデータ更新まで行うアプリでは、確かめる操作が異なるためです。
通常の依頼も一緒に試してください。例えば、制限を強めた後に、閲覧できるはずの資料まで回答されなくなっていないかを確認します。社内検索の資料管理については、AIを使うナレッジマネジメントも参照できます。
結果は再試験できる形で残す
Microsoftのレッドチーミング計画ガイドでは、入力・出力の記録、モデルとアプリの評価、対策前後の試験を扱っています。また、発見した事例を、その問題がどれほど広く発生するかを示す指標として解釈しないよう注意しています。
社内の記録票には、次の欄を用意すると、発見した担当者以外も再試験を進めやすくなります。
- シナリオID、実施日、対象アプリ・モデルの版、関連する設定
- 利用者権限、参照文書の版、入力と会話の履歴
- 期待する動作、実際の回答、実行された操作
- 試行回数と問題が出た回数、影響を受ける業務
- 修正担当、対応期限、再試験結果、残る課題
回答に「実行しません」と表示されたかだけでなく、実際の操作結果まで確認します。表示、ツール呼び出し、更新先の状態を別々に記録する設計にしておけば、どこで期待と違う動作が起きたかを整理できます。
問題の回数を比較する際は、対象シナリオや設定もそろえます。条件の異なる試験の件数を足して一つの「安全率」にせず、今回どの範囲を何回試した結果なのかを明記します。
改善後の確認を導入判断につなげる
問題を見つけたら、修正案を決める前に原因の候補を分けます。例えば、回答方針、検索時の権限、外部操作の承認処理など、どの部分を調べるかを担当者へ渡します。入力文だけを変えて現象が消えても、原因を修正できたとは判定しない運用にします。
再試験には、問題が出た条件、近い条件、正常な業務の三つを含めます。修正したケースだけでなく、別の表現でも期待する動作になるか、必要な業務が妨げられていないかを見ます。
利用開始の判断は、次のように残る課題と結び付けて整理できます。
| 判断案 | 記録しておく条件 |
|---|---|
| 利用開始 | 事前に決めた重要項目を満たし、残る課題の扱いと運用担当が決まっている |
| 用途を限定して開始 | 未解決の機能を無効にするなど、利用範囲を制限でき、制限後の動作も確認した |
| 導入を延期 | 権限外の情報開示や未承認の更新など、開始前に解消すると決めた問題が残っている |
ここでの判断基準は例です。自社の業務影響に合わせて開始前に合意し、試験結果を見て都合よく緩めないようにします。
まず一つの業務について、評価対象と期待する動作を書き出すところから始めてください。モデル、検索資料、権限、接続ツールを変更したときには、関連する試験をやり直す条件も運用に組み込みます。検証範囲と未解決事項を共有できる状態にすることが、導入判断の土台になります。