AIをわざと攻撃して弱点を探す｜出す前に自分で試す手順

「作ってはみたものの、外に出してよいかの判断がつきません」「社内で試したときは何も起きなかったんです」——公開の直前で止まっている担当者から、よく届く言葉です。判断材料が無いのは当然で、動かして何も起きなかったことは、攻められても壊れないことの証明にはなりません。ある大手ソフトウェア企業の専門チームは2021年以降、100を超える生成AIの製品を攻める側から検証し、2024年10月の時点で80件を超える演習を積み上げています。2025年1月に公表されたその報告で、8つの教訓のうち2番目に置かれたのが勾配を計算しなくてもAIの仕組みは壊せるという指摘でした。込み入った機械学習の攻撃ではなく、手で書いた指示文や入力を機械的に変える単純な方法が通ってしまう。この記事では、公開前に自分たちの仕組みを自分で攻めて弱点を洗い出す運用を、範囲の決め方から記録・再検証・報告まで、順番に沿って整理します。

100を超える製品を攻めた記録が、最初に示したこと

先ほど触れた専門チームは2018年に発足し、2021年以降に100を超える生成AIの製品を検証してきました。2024年10月の時点で演習は80件を超えます。2025年1月に公表された報告書は、その積み上げから8つの教訓を挙げています。読んで最初に効くのが2番目で、高度な数式の操作をしなくてもAIの仕組みは壊せるという指摘です。

実際に通ったのは、手で書いた指示文や、入力を少しずつ変えながら当たりを探す方法でした。報告書は、言語モデルの根本的な制約として、信用できない入力を与えられたモデルは任意の出力を出しうると考えるべきだ、とも書いています。研究者しか扱えない攻撃を想定して身構えるより、素朴な手が通るかを先に試すほうが、見つかる弱点は多いということです。

挙げられている事例も、派手さはありません。画像の中に文章として指示を重ねて制限を外させたもの、生成した文章を読み上げに変換して詐欺の会話を自動で組み立てたもの、そして古い動画処理の部品の版が残っていたために内部の資源へ手が届いてしまった不備。最後のものは生成AIに固有の弱点ではなく、昔からある種類の穴です。

ここから実務に持ち帰れるのは、着手の敷居の話です。専門の道具や人材が揃っていないから始められない、という理由は成り立ちません。手で3件試して記録を残せば、それは立派な1周目になります。

レッドチーミングとは、何を確かめる作業か

国内にも指針があります。AIセーフティ・インスティテュートが2024年9月25日に第1.00版、2025年3月31日に第1.10版として手法のガイドを公開しました。そこでの定義は、攻撃者がどのようにAIシステムを攻撃するかの観点で、AIセーフティへの対応体制および対策の有効性を確認する評価手法というものです。

この一文には、確かめる対象が2つ書かれています。対策の有効性と、対応体制です。仕組みに穴があるかどうかだけでなく、穴が見つかったときに気づいて直せる並びになっているか。ここを見落とすと、指摘の一覧だけが残って誰も直さないまま公開日を迎えます。

進め方は3段階に整理され、全体は15の手順に分かれています。14番目で改善策を検討して改善計画としてまとめ、15番目で改善後の進み具合を確認する。直すところと、直ったことの確認までが手順の内側にあるのがこのガイドの特徴です。

第1.10版では対象が言語モデルから、文章・画像・音声など複数の形式を扱う基盤モデルまで広がりました。あわせて、外部の資料を検索して答える仕組みを実装したシステムでの実施例が付き、成果物の文書も例として公開されています。自社の様式を一から起こす必要はありません。

精度の評価とも、守りの設計とも別物

報告書の3番目の教訓は、この作業は安全性の物差しで点をつけることではない、というものです。既存の物差しは、あらかじめ名前のついた危険について測ります。対して攻める側からの検証は、まだ名前のついていない害や、その仕組みに固有の文脈でだけ起きる危険を見つけるためのものです。点が高いことと、攻められて耐えることは別に確かめます。

混同しやすいのが、エージェントが正しく動くかの評価です。あちらは狙った仕事をこなせるかを測る作業で、判定の基準は「使える品質か」。こちらの基準は「悪意のある使われ方に耐えるか」。測る対象が違うので、片方の結果はもう片方の証明になりません。この区別さえ押さえておけば十分で、評価の組み立て方はここでは扱いません。

もう1つ、守り方の設計とも分けて考えます。外部の文章に紛れた指示に乗っ取られないよう、読ませる場面と実際に操作できる場面を切り分けるといった設計は、この記事の外側です。ここで扱うのは設計した守りが本当に効いているかを、自分から攻めて確かめる運用のほうです。

順番としては、守りを設計してから攻める、が原則になります。何も守っていない状態で攻めれば当然すべて通り、記録は「全部だめ」の一行で終わります。攻める側の演習は、守りの設計が一通り終わった直後に置くと、いちばん情報量が多くなります。

まず決めるのは、やってよい範囲

手を動かす前に、書面で範囲を固めます。ここを飛ばすのがいちばん危険で、試してよいのは自社が管理している仕組みだけです。他社が提供しているサービス、外部の基盤モデルそのもの、複数社で共有している環境に対して同じことを試してはいけません。利用規約に反するだけでなく、法に触れる恐れがあります。

書面に入れる項目は5つです。対象（どの機能・どの環境・どの版か）、期間、やらないこと、止める条件、連絡先。やらないことの欄には、本番の顧客データを使わない、本番から外部へ実際に送信させない、第三者のサービスに影響が及ぶ操作をしない、を明記します。

• 他社のサービス、外部の基盤モデル本体、共有環境への実施は範囲外。委託先に依頼する場合も同じ範囲で縛る
• 本番の顧客データは使わない。必要なら値を置き換えた写しを用意する
• 止める条件を先に決める（想定外の外部通信が出たら中断する、など）。判断を現場に委ねない
• 演習中に見つけた通ってしまう入力は、その場で社内に共有せず、限定した保存先に置く

環境は本番ではなく検証環境を使い、ただし設定は本番と同じにします。権限だけ緩めた環境で試すと、通ったのか通らなかったのかが分からなくなります。逆に守りを厳しくした環境で試して問題なしと結論づけるのも、同じ種類の誤りです。

外部に委託する場合も、同じ書面を先に交わします。委託先が持ち込む道具が外部へ通信するかどうか、生成した入力の原文をどこに保存するか。演習そのものが新しい持ち出し経路にならないよう、道具と保存先を先に確認します。

誰がやるか：作った本人だけでは穴が見えない

報告書の5番目の教訓は、人の要素が決定的だというものです。分野の知識、文化的な背景の理解、相手の状態を読む力。これらは自動の道具では置き換えられません。日本語で運用する仕組みなら、日本語特有の言い回しや社内の呼称を知っている人が入らないと、通る入力そのものを思いつけません。

役割は4つに分けます。進行役、攻める役、仕組みを分かっている人、判定する人。ここで大事なのは、作った本人を外すことではなく攻める役を別の人に割り当てることです。作った人は同席して、なぜそう作ったのかを答える側に回ります。設計の意図が分かると、攻める側は狙いを絞れます。

業務側の人を1人入れると、見つかるものの質が変わります。技術者は「情報が漏れるか」を見ますが、業務側は「この回答が顧客に届いたら何が起きるか」を見ます。何が起きたら困るかを知っている人が同席していないと、通ったのに軽く扱われる指摘が出ます。

人数は1本目なら3名から4名で足ります。全員が終日拘束される必要はなく、攻める役だけが手を動かし、他は区切りごとに集まる形で回せます。体制を大きくすることより、判定する人を攻める役と分けることのほうが効きます。

何を守りたいかを、対象の絞り込みとして書き出す

1番目の教訓は、その仕組みが何をできて、どこで使われているのかを理解せよ、というものです。両方を見ることで、現実に害が出やすい筋書きから順に試せるようになります。逆に言えば、これを書かずに始めると、思いついた順に試して日程が終わります。

書き出すのは3つの問いへの答えです。この仕組みは何ができるか（読む・書く・送る・買う・消す）。誰が入力を入れられるか（社員だけか、顧客も入れられるか、外部の文書を経由しても入るか）。出力はどこへ届くか（画面に出るだけか、メールとして送られるか、別の仕組みへ渡るか）。

この3つのうち、取り消せない操作と、外部へ出ていく経路に先に印を付けます。送信、購入、削除、公開。ここへ届く経路が1本でもあれば、その経路が最優先の対象です。画面に表示されるだけの機能は、同じ弱点が見つかっても影響の大きさが違います。

危険の大きさに点数を付けて並べる作業は、別の枠組みが担います。ここでは点数化まで踏み込まず、攻める対象をどこまでに絞るか、という一点にだけ使います。絞れていれば、限られた日数でも同じ場所を繰り返し攻められます。

試す攻め方は、5つの系統で持つ

個別の手口を集めると数が際限なく増え、しかもすぐ古くなります。系統で持ち、系統ごとに通ったかどうかを記録するほうが運用として続きます。ここでは5つに分けます。

系統	狙われるもの	通ったときに起きること	確かめる場所
指示の乗っ取り	外部から入ってくる文章	書いた覚えのない操作が実行される	取引先のメールや外部の文書を読ませている経路
制限の回避	出してはいけない回答	方針で禁じた内容がそのまま出力される	利用者が直接入力できる画面
情報の持ち出し	設定の文や社内の資料	参照しているだけの資料が本文に現れる	検索して答える仕組みの参照範囲
権限のはみ出し	連携先への操作	本来触れない先へ書き込みが届く	外部の道具に接続している部分
従来からの弱点	古い部品や入力の扱い	内部の資源に手が届く	生成AI以外の周辺の部品

7番目の教訓は、言語モデルが既存のセキュリティ上の危険を増幅し、そのうえで新しい危険を持ち込む、というものです。報告書の事例でも、古い動画処理の部品の版が残っていたために内部の資源へ届く不備が見つかっています。生成AIの部分だけを見て終わると、周辺の古い部品が丸ごと抜けます。

この記事では、系統ごとの具体的な入力の作り方は書きません。手口をそのまま並べることは、自社の検証に役立つ以上に、悪用の手引きになるからです。必要なのは「この系統を試したか」を漏らさないことであって、手口の目新しさではありません。系統ごとに数件ずつ試し、通った場合だけ詳細を限定した保存先に残します。

作り話や不適切な回答も、同じ演習で見る

6番目の教訓は、責任あるAIに関わる害は広く存在するが測りにくい、というものです。ここが従来のセキュリティの検証と違う点で、悪意のある人だけでなく、普通に使っている人にも起きる。判定にも主観が入りやすく、通ったかどうかを一行で書けません。

報告書の事例では、職業を性別を指定せずに描かせる指示文について、1つの指示文につき50枚を生成して偏りを見ています。1枚や2枚では偏りは見えません。数を出して分布で見る、という測り方をしないと、この種の害は「たまたま」で流されます。

もう1つの事例は、気持ちが落ち込んだ利用者を想定した複数回のやり取りです。1回のやり取りでは適切に応答していても、役割演技を重ねた末に危うい応答へ至ることがあります。1問1答の確認では出てこないので、5往復・10往復の筋書きを最初から用意しておきます。

判定は複数人で行い、意見が割れたものは割れたまま記録します。全員一致したものだけを指摘として扱うと、いちばん微妙で、いちばん問題になりやすいものが落ちます。割れた件には、それぞれの理由を1行ずつ添えておきます。

AIに判定させない範囲を、先に決める

攻める側にも、判定する側にもAIを使えます。ただし通ったかどうかの最終判定を自動の採点に委ねてはいけません。自動の採点役は、方針で禁じた回答を無害と判定することがあり、その誤りは静かに全件へ広がります。人が抜き取りで確かめても、抜き取った先が偶然そろってしまえば気づけません。

自動でよいのは3つです。入力の量を出すこと、明らかに何も起きなかったものの一次仕分け、直したあとの再実行。人が見るのも3つです。害の程度、業務上の影響、そして公開してよいかの結論。この6つの線を演習の前に文書へ書いておくと、日程が押したときに判定が緩む事故を防げます。

自動の判定を使う場合は、そう判断した根拠となる箇所を必ず出力させます。人はその箇所だけを読みます。根拠を示せない判定は採用しません。この一手間で、人が確認する量を全件から数分の一に減らせます。読む場所が決まっているぶん、見落としも減ります。

4番目の教訓は、自動化が危険の広がりを覆うのに役立つというものです。ただし5番目の教訓が続けて、人の要素は代えがきかないと述べています。2つを並べて読むと、自動化は範囲を広げる道具であって、判断を肩代わりする道具ではないと分かります。

1件の記録の形を、手を動かす前に決める

記録の様式が無いまま始めると、演習が終わった時点で手元に残るのは各自の記憶と断片的な画面の写しだけになります。決めておく項目は9つです。日時、担当、対象の版、系統、入力の要旨、起きたこと、再現できた回数、影響の範囲、想定した立場。

見落としやすいのが最後の「想定した立場」です。報告書は攻める筋書きを5つの要素で整理しています。対象の仕組み、演じる立場、手口、突かれた弱点、影響。同じ入力でも、外部の利用者が入れられるのか、社内の人しか入れられないのかで重みが変わります。立場を書く欄が無いと、この差が記録から消えます。

入力の原文の扱いにも気をつけます。通ってしまった入力をそのまま社内のやり取りに貼ると、演習の記録がそのまま手引きとして広がります。原文は限定した保存先に置き、共有する文書には要旨と系統だけを書きます。閲覧できる人の範囲も、書面の段階で決めておきます。

成果物の形は、公開されている例を借りられます。国内のガイドでは、最終報告書、実施結果の報告書、そして筋書きと実施結果を並べた一覧（表計算の形）の3点が例として示されています。1本目は様式づくりに時間を使わず、公開されている型に自社の項目を足すほうが早く回ります。

何回やれば足りるか：回数ではなく打ち止めの条件

何件試せば十分か、という問いに答えはありません。8番目の教訓は、AIの仕組みを安全にする作業は決して終わらない、と明言しています。守りの目的は完全になることではなく、攻める側にかかる手間と費用を上げることだと報告書は書いています。

終わりが無いなら、区切りは条件で決めます。3つ置きます。決めた系統をすべて1周した。新しい系統の弱点が2回続けて出なくなった。定めた期間の上限に達した。どれかに当たった時点で1周を閉じ、残ったものは次回に送るという運用にします。回数を決め打ちにすると、余った日数で薄い確認を積むことになります。

「見つからなかった」を「無い」と書かないことも決めておきます。記録には試した系統と試していない系統を並べて書き、試していない側は空欄のまま残します。次回の担当者は、この空欄から始められます。空欄が残っていることは失敗ではなく、次の入口です。

頻度は、定期と引き金の併用にします。引き金は3つで、使っているモデルが更新されたとき、参照する資料や連携先が変わったとき、機能が追加されたとき。この3つはいずれも、前回の演習の前提を崩します。前提が変わったのに前回の結果を根拠に使い続けるのが、いちばん危ない状態です。

自動の道具と人の手を、どう割り振るか

4番目の教訓が示すとおり、自動化は覆える範囲を広げます。効くのは量が要る場面です。同じ狙いの言い換えを大量に作る、直したあとの再検証を全件やり直す、複数の言語で同じことを試す。人が同じ量をこなすと集中力が落ち、後半の質が下がります。

人が要るのは、文脈を必要とする場面です。業務の常識に反する回答かどうか、社内の呼称や取引の慣習を踏まえた入力、複数回のやり取りで少しずつずらしていく筋書き。自動の道具が作る入力は、形は正しくても、その業界では誰も言わない言い回しになりがちです。

順番は、人が先です。手で3件通してから道具を入れます。手で通した3件が、道具に何を作らせるかの見本になります。逆にすると、道具が出した大量の結果を前にして、どれが重要かを判断できなくなります。

道具を入れるときは、その道具自体が決めた範囲の外へ出ないことを確認します。外部の基盤モデルへ入力を送る道具なら、送る先と保存の扱いが書面の範囲に入っているか。演習の道具が新しい持ち出し経路になっては本末転倒です。

見つかった弱点を、直す順番に並べる

出てきた指摘を全部同時に直そうとすると止まります。並べる軸は2つで足ります。外部から届くかと取り消せないことが起きるか。この2つで4つの区分ができます。

区分	外部から届くか	取り消せない影響か	扱い
最優先	届く	起きる	直るまで公開を止める。直したあとに再検証して記録を残す
公開前に直す	届く	画面内に収まる	公開日までに直す。間に合わない場合は機能を落として出す
早期に直す	社内のみ	起きる	公開後の早い時期に直す。それまで操作の権限を絞る
受け入れる	社内のみ	画面内に収まる	理由と判断した人の名前を残したうえで受け入れる

危険の大きさを点数化して並べる枠組みは別にありますが、1本目でそこから始めると、点数の付け方の議論だけで日程を使い切ります。この2軸なら、指摘を出した本人がその場で分類できます。分類が割れたら、外側の区分に寄せておけば安全側になります。

受け入れると決めたものには、受け入れた理由と、そう判断した人の名前を残します。この欄が無いと、次の演習で同じ指摘が「新しい発見」として上がってきて、また同じ議論を繰り返します。順番さえ決まれば、直す作業そのものは1つずつ進められます。

直したあと、同じ手が通らないことを確かめる

直したら再検証します。ここまでを1周とし、再現の手順の要旨と、直したあとの結果を1件ごとに残します。国内のガイドでも、14番目の手順で改善計画をまとめ、15番目で改善後の進み具合を確認する形になっています。改善の確認までが手順の内側にある、という設計です。

確かめ方には落とし穴があります。通ってしまった入力そのものが弾かれるようになっただけで、系統としては塞げていない場合です。次のような閉じ方をしていないか確認します。

• 通った入力の文字列だけを禁止語として登録し、言い換えを試さずに直ったことにする
• 直したあとの確認を、指摘を出した本人だけで行い、判定する人を通さない
• 検証環境で直ったことを確認し、本番へ反映したあとの確認を省く
• 直した記録を課題管理の一覧にだけ残し、次回の演習に引き継ぐ一覧へ移さない

塞げているかどうかは、同じ系統の言い換えを3件足して確かめます。3件とも通らなければ、系統として塞げた可能性が高い。1件でも通れば、直したのは入力の見た目だけです。ここで手を止めると、次の演習で同じ弱点が別の言い回しで再登場します。

通らなくなった手は、回帰の一覧に足します。次回の演習は、まずこの一覧を全部流すところから始めます。この一覧が育っていくことが、演習を続けている唯一の目に見える成果になります。

報告の形と、経営に出す1枚

報告は3点に分けます。実施結果の報告書、筋書きと結果を並べた一覧、そして最終報告書。前の2つは手を動かした人が書き、最終報告書は判定する人がまとめます。書く人を分けることで、結果を実際より良く見せる力が働きにくくなります。

経営に出す1枚には5項目を入れます。試した範囲と試していない範囲。通った件数と系統。直した件数。残した弱点と受け入れた理由。次にいつやるか。「残した弱点」の欄を最初から様式に入れておくと、報告が「問題ありませんでした」で終わらなくなります。

判断を求める形も決めておきます。公開してよいかどうかの結論を出すのは判定する人であって、報告書そのものではありません。報告書は材料を並べるところまでで止め、結論の欄は空けて出します。ここを曖昧にすると、書いた人が結論まで背負う形になり、次から報告が甘くなります。

記録の保管期間と、閲覧できる人の範囲も書面の段階で決めます。通った入力の原文を含む資料は、閲覧を演習の参加者に限る。報告のために抜粋するときも、原文ではなく要旨に置き換えます。

1本目で決めておく実務仕様の一覧

最後に、着手前に紙の上で埋めておく項目をまとめます。ここが埋まっていれば、演習そのものは数日で回ります。埋まっていなければ、初日は必ず範囲の議論で終わります。

• 対象：どの機能・どの環境・どの版を攻めるか（他社サービスと外部の基盤モデル本体は範囲外と明記）
• 期間：何日間か。1周の終わりをどの条件で閉じるか
• 体制：進行役／攻める役／仕組みを説明する人／判定する人。攻める役は作った本人以外
• やらないこと：本番データ、本番からの外部送信、第三者への影響が出る操作
• 止める条件：想定外の外部通信、業務への影響が出たときの中断の判断者と連絡先
• 系統：5つの系統のうち今回どこまで扱うか。扱わない系統は空欄で残す
• 判定：自動でよい範囲と人が見る範囲の6項目。自動の判定には根拠の出力を必須にする
• 記録：1件の様式9項目。入力の原文の保存先と閲覧できる人の範囲
• 直す順番：外部から届くか、取り消せない影響かの2軸。受け入れる場合の理由と記名
• 再検証：言い換え3件での確認と、回帰の一覧への追加
• 報告：実施結果の報告書／筋書きと結果の一覧／最終報告書。経営に出す1枚の5項目
• 次回：定期の間隔と、モデル更新・参照先の変更・機能追加の3つの引き金

この一覧は、1周ごとに1行ずつ増えていくものだと考えてください。1本目で完璧な様式を作る必要はありません。足りなかった欄は、演習の途中で必ず気づきます。気づいた欄をその場で足していけば、3周目にはほぼ埋まります。

まとめ

公開前に自分たちで攻める運用は、腕試しの場ではありません。100を超える製品を検証した報告が示したのは、通ってしまう手の多くが単純だという事実と、この作業に終わりは無いという前提でした。だからこそ、範囲・体制・記録・再検証・報告の段取りを先に決めて、何度でも回せる形にしておくほうが効きます。

試してよいのは自社が管理している仕組みだけです。他社のサービスや外部の基盤モデルそのものに同じことを試してはいけません。そして、通ったかどうかの最終判定と、公開してよいかの結論は人が出す。この2つを外さなければ、1本目の演習は小さく始めて構いません。手で3件試し、様式に沿って記録し、直して、同じ手が通らないことを確かめる。その1周が、次の1周の土台になります。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。