AIが危険な質問に答えなければ、安全と言えるのか？――AIレッドチームで確かめたいこと
会員照会AIの診断を選ぶ会議で、調達担当者が比較表を示しました。
「こちらは一万件、もう一社は十万件の質問を試すそうです」
CISO（最高情報セキュリティ責任者）が知りたいのは、どちらの数字が大きいかではありません。別会員の購入履歴を取得できてしまう経路を、どちらが確かめてくれるかという点でした。
これは、サービス選定を考えるための想定場面です。質問数の多い検証を否定する話ではありません。件数を比較する前に、自社が防ぎたい被害、調べる接続経路、判定に使う証拠を揃える必要があります。AIが実行する操作と権限の問題は、質問の文章だけでは評価し切れないからです。
十万件の中に、何が含まれているか
質問数は、検証に投入する作業量や試験の広がりを知る材料になります。ただし、質問の表現を変えた十万件と、権限や接続先を変えた十万件では、確かめている範囲が違います。同じ数でも、自社の被害に対する意味は変わります。
例えば、すべて同じテスト利用者で試しているなら、会員本人と代理担当者の権限差は調べていないかもしれません。モデル単体へ質問しているなら、本番のAPI（システム同士がデータや機能をやり取りする接続口）が何を返すかは確認できません。最終回答に問題がなくても、途中で過剰な取得があった可能性は残ります。
一方、共通の試験集にも価値があります。よく知られた問題を一定の条件で繰り返し確認し、変更前後を比較しやすくなります。大切なのは、それを共通の土台として使い、自社の業務と接続方式に固有の確認を追加することです。
選定会議の最初の問いを、「何件試すか」から「どの被害が起きなかったと、何を根拠に判断するか」へ変えます。すると、数字の後ろにある検証設計が見え始めます。
三つの評価は、役割を分けて組み合わせる
モデルの応答評価は、不適切な回答や望ましくない振る舞いを、定めた入力条件で調べます。WebやAPIの診断は、認証・認可（誰にどの操作を許すかの判断）を含むアプリケーションや接続部分の弱点を調べます。AIエージェントの業務検証は、依頼から検索、ツール実行、承認、結果までの一連の動きで、統制が働くかを確かめます。
この三つは、競合する一択ではありません。既存のWeb診断で見つかる不備もあれば、複数の正常な機能をAIがつないだ結果として生じる問題もあります。AI向けの診断という名称だけで、従来のセキュリティ確認を省かない方がよいでしょう。
AISIは、AIに施した対策を攻撃者の視点から評価する手法を整理し、レッドチーミング手法ガイド第1.10版にRAGを備えたシステムの実施例を加えています。評価対象と工程を具体化する公的な参考資料として使えます。
また、KPMGジャパンは2025年10月の発表で、攻撃シナリオの策定から演習、監視・対応の評価、改善提案を含む支援を説明しています。公開情報からも、AIレッドチームを質問生成だけへ狭める必要はないと読み取れます。各社の実際の契約範囲は、個別に確認しておきましょう。
被害から工程を組み立てる、AIL ARCAの考え方
AILが提案するのは、検証結果を改善と再確認までつなぐ見方です。AIL Red Team Xでは、独自のAIL ARCA（Agent Risk & Control Assurance）Methodologyに基づき、次の六工程で進める計画です。国際的な認証や、第三者から安全を保証された方式を意味する名称ではありません。
工程名を並べることが目的ではありません。入力と成果物がつながることが重要です。別会員の履歴取得を防ぐなら、その被害が、権限の図、試験条件、実行の証拠、認可の修正、修正後の拒否結果まで一貫して追えるかを見ます。
生成AIによって試験案を増やす場合も、判定をAIだけに任せません。専門家が、実行の証拠と業務上の許可範囲を突き合わせます。もっともらしい報告文ができたことと、統制を確認できたことを分けるためです。
一つの業務を通すと、提案書の空欄が見える
冒頭のCISOは、両社へ同じ条件を渡します。対象は予約履歴の照会です。会員本人には本人の予約だけを許します。別会員の予約を取得してはいけません。代理の窓口担当者には、正式な権限に沿った照会を認める、という想定です。
その上で、どのIDを使い、接続先の結果をどう確認し、拒否を何で判定するかを尋ねます。回答の評価だけが範囲なら、その限界を理解して利用できます。APIの認可まで対象なら、必要な環境と担当者が変わります。この違いを価格や件数より先に揃えておきましょう。
さらに、弱点が見つかった後の責任を確認します。診断側は原因の仮説まで示すのでしょうか。開発側が修正した後は、誰が同じ条件で再検証するのでしょうか。再検証が別料金や別契約なら、その前提も比較表へ記載します。
ここを曖昧にすると、報告書は納品されたが、業務を再開してよいか決められない状態が残ります。見つける作業と、改善を確かめる作業の間を、調達の段階でつないでおく必要があります。
「見つからなかった」の読み方も、契約前に決める
同じ試験でも、接続先へ到達しなかった場合と、到達した上で正しく拒否された場合は違います。準備不足で試せなかった経路を、問題なしの結果へまとめると、検証範囲を誤解します。
報告には、実行した範囲、確認できなかった範囲、その理由を残します。時間切れ、権限不足、証拠不足などは、それぞれ次の対応が異なります。予定件数の消化率だけでは、この判断に必要な情報が見えません。
また、AIの動作にばらつきがある場合、一回の成功や拒否をどこまで一般化するかも合意します。繰り返し回数、条件の固定、結果が分かれたときの扱いを決めておきましょう。任意の回数で問題が見つからなかったことから、将来のすべての動作を保証することはできません。
反対に、権限外の取得が一度確認されたなら、その後の多数の正常結果で相殺するのも適切ではありません。再現条件の調査と暫定的な制限が必要かを判断します。平均的な成績と、重大な一件の扱いを分ける方が、個人情報を扱う業務の判断には役立ちます。
調達担当者が持ち帰る、五つの比較軸
AILとして勧めたい比較軸は、対象、方法、判定、成果物、改善への接続です。比較表には、次の内容を記します。
対象：業務と接続システム
方法：使用する環境と許可する試験
判定：期待結果と証拠
成果物：未確認事項
改善への接続：修正担当と再検証の範囲
この五つが揃うと、件数の多さを適切に評価できます。共通試験の広さに価値がある提案も、重要な業務経路を深く調べる提案も、自社の目的に照らして選べます。サービス名や会社の知名度だけで判断する必要が減ります。
予算が限られるなら、すべてを薄く試す前に、重要な一業務の確認範囲を明確にする方法があります。ただし、絞った範囲の外に残るリスクは、別の評価や今後の計画として示します。小さく始めることが、全体を確認したという説明に変わらないようにしましょう。
比較表へ、想定外の発見への対応も加える
検証中に、当初の対象外にある情報へ接続している疑いが見つかったとします。その場でさらに調べれば有益な結果が出るかもしれません。しかし、許可していない対象まで自動的に試験範囲を広げてよいわけではありません。停止し、責任者へ確認し、必要なら追加の範囲を合意する運用が求められます。
選定時には、こうした想定外の発見をどう扱うかも尋ねておきましょう。技術的な能力だけでなく、許可の境界を守り、証拠を保護し、適切な担当者へ連絡できることが、顧客情報を扱う検証には必要になります。
同じ理由で、発見した内容の報告方法も重要です。重大な問題があった場合に、最終報告会まで待つのか、合意した連絡先へ途中で知らせるのかを確認します。通常の担当者が不在なら、誰へ連絡するかも決めておきます。報告の速さが、その後の対応を左右することがあります。
一方、問題らしい動きをすべて確定的な漏えいとして連絡すれば、依頼側は判断に困ります。確認した現象、想定する影響、まだ確認していないことを分けて報告する条件を揃えておきます。検証環境での発見と、本番での被害の有無も別の確認です。
冒頭の比較表なら、質問件数の列を残したまま、その隣へ一つの業務シナリオの確認範囲を置きます。さらに、重大な発見の連絡、原因の説明、再検証の範囲を追加します。これなら、件数が少ない提案を無条件に優れていると評価することも、多い提案を自動的に選ぶこともなくなります。
最後に、検証を受け入れる側の工数も比べます。試験環境の準備、実行記録の取得、権限の説明、修正担当者との調整が必要になる場合があります。診断会社の作業だけを見て予定を組むと、試したい経路へ到達できないまま期間が終わるおそれがあります。依頼側が提供する条件まで揃えた比較が、実施可能な計画につながります。
診断を、次の判断につながる仕事にする
AIL Red Team Xは、AIL Governance X内のサービスとして2026年11月の提供開始を予定しています。顧客が許可した範囲で、攻撃者視点の検証、統制改善の支援、修正後の再検証と証跡の整理をつなぐ構成です。継続的な再検証は個別契約に応じた提供となります。
既存のネットワーク侵入テストやWeb脆弱性診断を置き換えるものではなく、すべての攻撃の阻止や完全な安全性を保証するものでもありません。だからこそ、何を確認したかと、何が残ったかを説明できる成果物が必要になります。
まず、自社の重要な一業務について、被害、接続経路、期待する拒否、確認する証拠を一枚へ書いてみましょう。それを提案書と照らせば、十万件という数字の前に尋ねるべきことが見えてきます。
本番の個人情報を使わずに、現実の権限と業務の問題をどこまで再現できるかを考えます。
参考情報
AILのサービス仕様とARCA六工程：AIL Red Team Xのサービス発表案。提供開始は予定。選定会議と試験条件は架空の例であり、導入実績ではありません。確認基準日：2026年10月22日。
AILのサービス・プロダクトについて
AILでは、人材育成、実践知の蓄積・活用、導入に向けたコンサルティング、プロダクトの提供を通じて、企業のAI活用を支援しています。自社の課題に合った支援を、サービス紹介ページでご覧いただけます。
AI Librariumについて
本記事は、AI Librarium（アイブリウム）株式会社が発信しています。
AILは、専門家の知見や判断基準を、実務で使えるAI Skillとして届け、研修やコンサルティングを通じて企業の業務変革を支援します。その実践で得られた成果や課題を、AI Skillの改善と人材育成に活かし、次の変革につなげていくことを目指しています。
