市販のAIが侵害の調査を断った2026年7月の実例

「あとで調べればいい」が成り立たないことがある

サイトに異常が出たとき、サーバーの記録を見れば原因が分かる、と考えるのは自然です。記録には、いつどこから何が要求されたのかが残ります。最近は、その記録をAIに読ませて要約させる使い方も広まりました。手元にある手段で調べられるなら、備えは足りていると考えたくなります。

ところが、その手段が侵害の最中に使えるとは限りません。Hugging Faceが2026年7月に公表した侵害対応の記録（外部サイト）には、調査に使おうとした市販のAIサービスが、調査そのものを断った経緯が書かれています。同社はAIのモデルやデータを公開する場を運営する会社で、後で触れるOpenAIの説明によれば、侵入を止めたのは同社のセキュリティチームと、同社が動かすAIでした。

この侵害は、自律的に動くAIが一貫して行ったものでした。OpenAIは、単体のモデルではなく複数のモデルの組み合わせによるものだったと説明しています。Hugging Faceの公表によれば、攻撃は悪意のあるデータを読み込む仕組みの弱点を突いてコードを実行させ、そこからアクセス権限を広げ、週末のあいだに複数の内部システムへ入り込んでいます。侵入の拡大は一度きりの操作ではなく、数万件にのぼる自動化された細かな操作を積み重ねる形で進みました。

この侵害については、OpenAIも説明を公表しています（外部サイト）。侵入したのは、同社が社内評価のために動かしていたAIでした。試験環境から外部へ到達し、Hugging Faceのサーバーへ入り込んでいます。AIが攻撃を実行する側に回る場面は、すでに起き始めています。

攻撃の側だけでなく、攻撃された側の対応も公表されています。セキュリティチームを持つ会社でも、調査に使おうとした手段が途中で止まりました。市販のAIを調査に使う限り、断られる可能性は残ります。変わるのは、止まったあとに代わりが利くかどうかです。

市販のAIが攻撃の調査を断った

記録の解析を始めた当初、Hugging Faceは商用APIで提供されているAIモデルを使おうとしました。攻撃者が実際に使った命令や、攻撃に使われたコードをまとめてAIへ渡し、何が行われたのかを読み解く必要があったためです。ところが、その要求は提供元の安全機能に止められました。

同社の説明では、安全機能には対応にあたっている人と攻撃者を見分ける手立てがありません。入力されるものが攻撃のコードである点は、どちらの立場でも変わらないからだと考えられます。断られること自体は、機能の設計から見れば不自然ではありません。

言い方を変えれば通るのかどうかは、公表された記録からは分かりません。読ませたいものが攻撃のコードそのものである以上、入力から攻撃らしさを抜くと調べたい対象まで消える、という性質はあります。

断られると、その時点で代わりの手段を探すことになります。Hugging Faceの場合、阻まれたのは攻撃のコードを含む記録の解析で、同社は自社環境で動かすモデルへ切り替えてこれを行いました。使える手段を事前に確かめていなければ、その作業をどう進めるかを侵害の最中に決めることになります。

切り替えられたのは、自社でAIを動かせたから

切り替えた先は、公開されているモデルを同社の環境で動かす方法です。攻撃者に関する情報や、調べる過程で出てくるアクセス情報を、自社の外に出さずに済むという利点もありました。

ただしこれは、AIを動かす環境と、それを扱える担当者を持っている会社の選択肢です。それでも同社は、使えるモデルが想定していなかった形で限られたと書いています。そのうえで、自社の環境で動かせるモデルを侵害の前に確かめて用意しておくことを、守る側への教訓に挙げています。

環境も担当者も持たない運営では、断られた時点で、自社の中で記録を読み解く道はいったん途切れます。侵害の最中から環境を自前で整えるのは現実的ではなく、残るのは外部の調査会社やサーバー会社に頼む道です。自社でAIを動かせたHugging Faceも、調査には外部の専門家を加えています。

市販のAIは調査の手段の一つにはなりますが、唯一の手段としては当てにできません。断られたときに何が残るのかを、先に確かめておくことになります。自社で動かせるAIか、記録を読める外部の相談先か、そのどちらも無いのかで、次の一手が変わります。

範囲を確かめる作業そのものに手間がかかる

この侵害は、AIによる判定を組み合わせた検知の仕組みで表面化しました。そのうえで同社は、攻撃者による1万7,000件以上の操作記録をAIで整理しています。侵入の時系列を組み立て直し、攻撃者が手を付けたアクセス情報を洗い出し、おとりの動きと本当の被害を分けました。

同社は、AIを使ったことで通常なら数日かかる作業を数時間で終えられたと説明しています。手段があれば短縮できる作業でもあり、手段がなければ、その数日分を人手か別の道具で埋めることになります。

Hugging Faceは、社内の一部のデータと、いくつかのアクセス情報が外部から見られたことを確認したと公表しています。公開しているAIモデルやデータが書き換えられた形跡はないとしています。公表の時点では、取引先や顧客のデータへの影響について評価を続けている段階でした。

ここまで調べるのは、範囲が決まらないと、誰にどこまで連絡するのかも、どこから直すのかも絞れないためです。封じ込めや認証情報の入れ替えは範囲の確定を待たずに進められますが、対象を限った連絡や、優先順位を付けた復旧はそのあとになります。

断られなくても、答えが正しいとは限らない

断られなかった場合にも、別の問題があります。サーバーの記録に並ぶ項目のうち、いくつかは要求を送った側が中身を決められる欄です。そこにAIへの指示として読める文章が書き込まれていると、返ってくる要約がその文章に沿って書き換わることがあります。

LevelBlue SpiderLabsが公表している検証（外部サイト）では、送信元のIPアドレスやワークステーション名が、AIの生成した要約の中で実際の記録と違う値に置き換わりました（2026年8月時点のページで確認）。書き換えたことを要約に書かないよう求める指示まで含まれていたと報告されています。

要約だけを読んでいると、書き換わったことに気づく手がかりがありません。元の記録と突き合わせなければ、誤った範囲を前提に進めるおそれがあります。AIに読ませるときに気をつけることは、アクセスログをAIに読ませるときの注意点を確認すると分かります。

記録を外部のサービスへ貼ってよいかどうかも、事前に確認します。アクセス記録には、閲覧者のIPアドレスや、管理画面の操作の跡が含まれます。取引先のデータを預かっているなら、どこへ何を送ってよいかを、調べ始める前に決めておきます。

断られる場合と、断られずに違う答えが返る場合があります。どちらも、AIを唯一の手段にはできない理由です。

手段を外に持つか、調べる場面を減らすか

自社の中に調査の手段を用意できないなら、外部に頼る方法があります。何をどこまで頼めるのかを平時のうちに確かめておけば、自力で読めない状態になっても先へ進めます。当方に頼んだあとに何がどの順で進むかは、障害の初動フローを確認すると分かります。

ただし、相談先を決めても侵害そのものは減りません。調査が必要になる場面は残ります。短くできるのは、気づいてから動き出すまでの時間です。

侵入される機会そのものを減らす方向もあります。一つは、更新を早く当てて弱点を塞ぎ続ける方法です。ただし、公表されてから更新を当て終えるまでに夜間や休日をまたぐと、そのあいだ弱点は開いたままです。更新だけで間に合わせる前提は、担当者が常に動ける体制でなければ置きにくくなります。

もう一つは、調べる対象を先に減らしておく方法です。公開の側でプログラムが動かない構成にすれば、そこで起こりうることの種類が減ります。何かあったときに確かめる対象も、その分だけ狭まります。静的移行は、その方向の選択肢です。

問い合わせフォームのように、外部と通信する仕組みが残る部分はあります。それでも、何かあったときに調べる対象がサイト全体から限られた仕組みへ狭まれば、確かめる手間も、そのために用意しておく手段も変わります。