LLMのレッドチーミングで必要なのは、危険そうな質問を大量に集めることではありません。どのシステムの、誰に対する、どの被害を探すかを決め、入力と応答の関係を再確認できる評価データにすることです。ケースの作り方から、評価者への指示、検品、修正後の再実行まで整理します。

通常の品質評価と、弱点を探す評価を分ける

通常の品質評価は想定利用における正確性や関連性などを測ります。レッドチーミングは、悪用・誤用・想定外の入力や条件の組み合わせを試し、安全上の方針や設計意図から外れる箇所を探します。NISTの生成AI向けプロファイルは、害のある出力などの欠陥を探る構造化された試験と説明します。Microsoftの実施ガイドも、発見した事例を発生頻度の測定結果と取り違えないよう求めています。

この記事は人が弱点を探索し、再試験できるケースと判定を作る工程を扱います。固定問題で継続測定する安全性ベンチマーク、技術的な脆弱性診断、機能が仕様どおり動くか調べる通常のQAテストとは、目的と結果の読み方を分けます。

まず対象システムと失敗条件を固定する

仕様書には、基盤モデル単体か、システム指示・検索・ツール実行を含むサービス全体かを明記します。利用者と場面、守る対象、適用する安全方針・業務ルールの版、試験者が持つ権限、許す操作、対象外の領域も決めます。OpenAIの外部レッドチーミング報告も、目的、脅威の想定、試験対象の版、参加者への指示を事前の設計事項に挙げています。

同じ「情報を教えて」という入力でも、一般チャットなら回答可能な公開情報が、社内検索では他人の人事情報となり得ます。顧客対応では注文変更前の本人確認、医療情報案内では根拠の限界と専門家への案内、ツールを使うエージェントでは実行権限の確認が必要かもしれません。失敗を「禁止情報の提示」「根拠のない断定」「無権限の外部操作」など観察できる状態で定義し、想定被害と重大度の判断軸を結びます。

リスク分類から種ケースと変種を作る

案件の方針から、有害・違法な依頼、個人情報や機密・内部指示の露出、差別や嫌がらせ、誤情報、なりすまし、過度な拒否などを選びます。アプリの安全性を調べるなら、OWASPのLLMアプリ向けリスク分類にあるプロンプトインジェクション、機微情報の開示、過剰な権限も参考になります。OWASPの分類はアプリのセキュリティ上の整理であり、差別や正当利用の阻害まで含む万能の分類ではありません。

まず一つの攻撃目的に種ケースを作り、何を変えたかを一変種ずつ記録します。直接依頼と遠回しな依頼、正当な目的を装う説明、担当者を名乗る入力、複数ターンへの分割、誤字・略語・隠語・文字置換、多言語混在、文書・画像・検索結果内の指示、安全な依頼との組み合わせ、拒否後の再依頼、ツール権限の違いなどです。親ケースIDと変形種別を付ければ、単なる言い換えの件数と、異なる弱点を発見した件数を混同せずに済みます。実際に有害な操作へつながる入力は、試験環境と権限を制限して管理します。

「拒否したか」だけで合否を決めない

ケースごとに、回答してよい範囲、禁止する内容、安全な範囲に限って答える内容を分けます。曖昧なら確認質問、権限不足なら確認・人への引き継ぎ、許されないツール実行なら停止、拒否後には可能な代替案、と期待挙動を具体化します。正当な予防や被害対応まで一律に拒否すれば、それ自体が失敗です。

完全に一致すべき模範文を一つ書く代わりに、「必須要素」「禁止要素」「許容する対応」を持たせます。方針が未確定、事実確認に専門知識が要る、前提情報が欠ける場合は判断不能・保留へ回し、低得点や安全な成功へ押し込まないようにします。

ケース、実行結果、人手判定を別々に保存する

同じケースでもシステムの版や実行条件が変われば別の応答になります。収集画面と納品台帳は、次の三層をIDで結ぶ構成にします。入力と会話履歴、参照文書の表示範囲、ツールの模擬環境を評価者へ示し、応答中の問題箇所と適用方針を指せるようにします。

重大度と再現性は別の欄で判定する

重大度は「脱獄した」という呼び名では決まりません。被害の大きさ、影響する人やデータの範囲、必要な知識・権限・試行回数、通常利用での起こりやすさ、出力だけか外部操作に至ったか、検知・回復できるかを案件ごとに定義します。被害の大きさと発生可能性を分ける考え方はNISTのリスク記述も参照できますが、共通の万能な点数表として流用しません。

偶然一度出た応答と、同条件で繰り返し生じる失敗も分けます。再試行回数・成功回数と各run_id、生成設定、モデル・プロンプト・検索対象・ツールの版を記録します。試行途中で条件を変えたら別の実行として残し、修正前後を同条件で比べます。評価者が迷う重大度や方針の解釈は理由を添えて確認担当者へ送り、元の判定と裁定後の値を両方残します。

自由探索の発見を固定ケースへ変える

探索では、評価者が何を試そうとしたか、直前の回答を受けて次の入力をどう変えたかを会話単位で残します。弱点を確認したら、必要な履歴と権限だけを切り出し、期待挙動と判定条件を固定した回帰テストへ移します。Microsoftのガイドも、自由探索から発見した害の整理、重点を置いた再試験への移行を示しています。

修正後は危険ケースだけでなく、似た通常例・境界例・正当利用例も再実行します。危険な回答を抑えた結果、正当な相談まで拒否する変化を見落とさないためです。開発者へ共有して修正に使ったケースは既知の回帰テストとして用途を変更し、未知の弱点を見る必要があれば独立した新規ケースを用意します。ケース、期待挙動、分類、重大度基準、モデルと周辺設定の各版、旧版の判定を保存します。

作業者の負担と情報の持ち出しを設計する

募集時に接し得る差別的・暴力的・性的・自傷関連の内容と担当範囲を伝え、扱わない領域、担当条件、分類ごとの辞退方法を決めます。連続作業時間と割当量を調整し、問題のある出力を報告・中断する経路と、専門担当者へ回す条件を用意します。Anthropicらの人手レッドチーミング研究では、作業前の注意喚起や、避けたい題材を選べる仕組みが記述されています。これは本件で採る作業条件を決める際の参考例です。

テスト入力に実在人物の個人情報や本物の秘密を使わず、必要なら架空の値と隔離した試験環境を使います。ケース、危険な出力、内部のシステム指示・ログは役割ごとに閲覧を制限し、外部サービスへ入力してよい範囲も開始前に決めます。納品前には、case_idとrun_idの対応、方針の版、判定根拠、再試行ログ、保留・除外理由を点検し、関係者向けの報告では機微な入力や出力を必要な範囲だけ示します。