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

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

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

ところが、その手段が侵害の最中に使えるとは限りません。Hugging Faceが2026年7月に公表した侵害対応の記録（外部サイト）には、調査に使おうとした市販のAIサービスが、調査そのものを断った経緯が書かれています。同社はAIの開発を本業とし、専任のセキュリティ担当者を置いている会社です。

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

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

攻撃の側だけでなく、攻撃された側が何に手間取ったかも公表されています。備えの厚い会社でも、調査に使おうとした手段が止まりました。止まること自体は、備えの厚さでは避けられません。変わるのは、止まったあとに代わりが利くかどうかです。

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

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

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

言い方を変えて頼み直しても、この壁は残ります。読ませたいものが攻撃のコードそのものである以上、入力から攻撃らしさを抜くと、調べたい対象まで消えてしまうためです。

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

切り替えられたのは、切り替え先を持っていたから

そこでHugging Faceは、市販のAIから、安全上の制限を自社で設定できるAIへ切り替え、自社の環境の中で記録の解析を行いました。攻撃者に関する情報や、調べる過程で出てくるアクセス情報を、自社の外に出さずに済むという利点もありました。

ただしこれは、AIを動かす環境と、それを扱える担当者をあらかじめ持っている会社の選択肢です。切り替え先があったからこそ、断られた時点で止まらずに済みました。

専任のセキュリティ担当者を置けない運営で、同じ切り替え先を自社の中に用意するのは難しいことです。断られた時点で、自社の中で記録を読み解く道はいったん途切れます。外部の調査会社やサーバー会社に頼む道は残りますが、そこから環境を自前で整えるのは、侵害の最中に始める作業としては現実的ではありません。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

侵入される機会そのものを減らす方向もあります。一つは、更新を早く当てて弱点を塞ぎ続ける方法です。ただしセキュリティ企業ZeroFoxの2026年の分析（外部サイト）では、弱点が公表されてから実際に悪用が始まるまでの猶予が、2018年の756日から2026年には約10時間まで縮まったと報告されています。更新の速さだけで守り切るには、この時間と競うことになります。

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

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