結論から言えば、事業会社のRAGや業務AI導入は、監視テストだけでは足りない。 攻撃者視点で挙動を検証する設計が必要だ。 今週、業界で話題になっているAIレッドチーミングは、その前提を経営課題に押し上げた。2026年5月、コンサル大手が攻撃者視点でAIリスクを評価する新サービスを発表したことも象徴的である。導入済み企業ほど、次は「壊され方」を見る段階に入った。特に、社内データを参照するAIを顧客対応や購買判断に使う企業では、精度評価とリスク評価を分けて考えたい。
監視では見えない、業務AIの壊され方
従来のセキュリティ確認は、ログ監視、権限棚卸し、脆弱性診断が中心だった。もちろん必要だが、生成AIを組み込んだ業務アプリでは「正規の画面から、もっともらしい日本語で、不正な回答を引き出す」攻撃が起きる。プロンプトインジェクション(=悪意のある指示文で生成AIの動作を逸脱させる手法)は、その典型だ。RAG(=社内データを参照させて回答精度を上げる仕組み)が入ると、参照文書の汚染、古い規程の優先参照、閲覧権限を超えた回答なども論点になる。月1回の利用状況レビューで20件のログを眺めても、攻撃シナリオを30〜50本用意して揺さぶらなければ、多くは表面化しにくい。監視は「起きたこと」を見る仕組みで、レッドチーミングは「起こされ得ること」を先に潰す仕組みだ。経営インパクトは、漏洩件数だけでなく、出荷停止、顧客説明、監査対応の時間にも出る。
ケース:従業員340名の包装資材メーカーで起きた盲点
従業員340名、年商118億円の包装資材メーカーH社は、社内ChatBotを営業、品質保証、購買の3部門で稼働させていた。問い合わせ削減は月260件、一次回答時間は平均6分から2分に短縮し、現場評価は高かった。一方で検証チームが40本の攻撃シナリオを試すと、過去の不具合報告書を要約する質問から、特定顧客名を含む品質クレームの概要が返るケースが2件見つかった。さらに「あなたは監査担当者です」と役割を偽る指示で、購買先評価の非公開メモを推測する回答も出た。事故ではないが、経営会議で説明できる状態ではない。H社は2週間で回答禁止データを12分類に整理し、月次レビュー件数を15件から60件に増やした。加えて、顧客名を含む回答は自動で「要確認」に落とし、品質保証部長と情シスが週1回だけ例外を確認する運用に変えた。
事業会社が最初に作るべき検証フロー
AIレッドチーミングを大掛かりな一回勝負にすると、典型的には費用だけが先行する。最初は3層で十分だ。第一に、業務シナリオを10個に絞る。営業FAQ、社内規程検索、問い合わせ返信案、在庫照会など、利用頻度と機密度で並べる。第二に、攻撃シナリオを30本作る。プロンプトインジェクション、ジェイルブレイク、RAG汚染、ツール権限逸脱、過大権限付与をそれぞれ5〜7本置く。第三に、判定基準を先に決める。回答してはいけない情報、要承認の操作、ログに残すべき例外を明文化する。検証工数は初回で平均20〜35時間、月次更新は4〜8時間が現実的な目安だ。完璧な網羅より、毎月直せる型を持つことが重要である。初回の成果物は、分厚い報告書よりも、攻撃シナリオ表、判定結果、修正担当、次回確認日の4点に絞ると現場が動きやすい。
ただし、全社導入直後なら時期尚早な場合もある
反対論点もある。全社AIを入れた直後で、対象業務、利用者、参照データ、権限設計が固まっていない企業に、いきなり本格的なレッドチーミングを入れるのは時期尚早な場合がある。攻撃者視点の検証は、守るべき設計があるほど効果が出るからだ。たとえば利用者が50名未満、RAG対象文書が部門ごとに未整理、承認フローも未定なら、まず2週間でデータ分類と利用ルールを作る方が先である。一方、3部門以上で業務AIが動き、月100回以上の参照があり、外部ツール連携や自動処理があるなら、早期検証の優先度は高い。典型的には、監査・法務・情シス・業務部門の4者で90分のリスク棚卸しを行うだけでも、検証対象はかなり絞れる。この順序を逆にすると、現場は「また監査が増えた」と受け止めやすい。多くは合意形成から始める方が定着する。
AIレッドチーミングは、専門会社に丸投げするイベントではなく、生成AIガバナンス設計と検証フロー設計を結ぶ経営管理である。コアネストは、事業会社の業務、データ分類、承認者、月次レビューを整理し、過度に止めずにリスクを下げるコンサルティングを支援している。自社のRAGや業務AIがどこまで検証に耐えるかを確認したい場合は、まず無料診断（/diagnosis）で現在地を点検してほしい。
