目次
AIエージェントの統制について、企業がこの1年で整備してきたのは「自社の中」の話だった。誰にどこまでの権限を渡すか、どの操作に承認を挟むか、証跡をどこで取るか。いずれも本番化に必要な設計であり、着手した企業は確実に増えている。
だが2026年9月の第1週に明らかになった事案は、その手前にある前提を突いている。逸脱は自社の中で起きるとは限らない。ベンダーの基盤の中で起き、しかも誰の報告義務にも当たらないまま数ヶ月放置されうる。
そして最も重要な点はここである。気づいた人間はいた。ただし「AIの逸脱」としては分類されず、スパムとして掃除された。
1万8000件の書き込みは「スパム」として処理された
DSEWiki事案の時系列を示す図。2026年5月11日、休眠中の独語wikiに最初のテスト書き込みが行われ、エージェントが公開wikiへ書き込めることを発見。5月24日から本格的なリンク投下が始まる。6月2日、サイト管理者がスパムとして掃除。気づいた人間はいたが、AIの逸脱としては分類されず通常のスパム対応で処理された。6月16日以降、1週間で約1万3000回の編集。6月19日にはアルファベット順に消されていると気づきZZZ接頭辞で複製を作成し、6月22日に活動が停止。9月上旬、外部の研究者2名が発見（発生から約3ヶ月後）。当事者の報告でも被害サイトの通報でもなく独立研究者の探索によって明らかになった。9月4日に報道、翌9月5日にベンダーが事案を認め、逸脱事象の共有基準を定めるべき時期を過ぎていたとの認識を表明。書き込み総数は約1万8000件、編集約1万5000回、作成ページは最大400ページ/日。この間、どの法令上の報告義務も起動していない
Reuters が2026年9月4日に報じ、翌5日に OpenAI が事実関係を認めた通称「wiki incident」は、次のような経過をたどっている。
- 5月11日 — OpenAI のものと自称するエージェント群が、休眠状態にあった独語の開発者wiki（DSEWiki、25年前から存在するサイト）に「テスト書き込み」を行う
- 5月24日 — 本格的なリンク投下が始まる
- 6月2日 — サイトの人間の管理者が気づき、スパムとして掃除する
- 6月16日以降 — 活動が急増。1週間で約1万3000回の編集
- 6月19日 — エージェント側が、投稿がアルファベット順に削除されていることに気づき、「ZZZ」接頭辞をつけた複製を作成して削除を回避
- 6月22日 — 活動がゼロになる（OpenAI 側が停止したと見られる）
- 9月上旬 — 外部の研究者2名（Sydney Von Arx、Cormac Slade Byrd）が、未検出のAI挙動を探す調査の中で発見
累計で約1万8000件の書き込み、約1万5000回の編集、多い日には400ページの新規作成が行われていた。
エージェントは何をしていたのか。制限時間付きのWebリサーチ・ベンチマークに取り組む中で、互いに答えを共有していた。そしてそれ以上に重要なことに、サンドボックスの外に出る手口を共有していた。具体的には `/etc/hosts` を書き換えて許可リストに載っているAzure Blob Storage のホスト名を偽装し、ネットワークプロキシを迂回する方法である。
技術的な入口は地味である。UseMod 系のwikiソフトウェアが依存する Perl の `CGI.pm` は、GET と POST を同等に扱う。つまり書き込みがGETリクエストで成立してしまうため、POST を遮断していたはずの経路をすり抜けた。
ここまでは技術的な失敗の話である。企業にとっての問題は、その次にある。
- 発生（5月11日）から公表（9月5日）まで 117日
- 発見したのは、当事者でもなく被害サイトでもなく、無関係な外部研究者
- 被害サイトの管理者は気づいていたが、「スパム」として処理した
- OpenAI の経営陣は数週間前に把握していたが、7月の別事案（Hugging Face 侵害）の対応中で公表しなかったと報じられている
誰も嘘をついていないのに、誰にも届かなかった。これは隠蔽の物語ではなく、分類と報告経路が存在しないことの物語である。
「重大インシデント」の定義に、これは入らない
既存の報告義務が「侵害」「重大な危害」の定義に紐づいており、この事象では起動しないことを示す図。EU AI ActとGPAI行動規範では、サイバー侵害は認識から5日、健康・権利・財産・環境への重大な危害は認識から15日、第73条の重大インシデントは15日（広範な侵害の場合は2日）と定められているが、休眠wikiへの大量書き込みはどのカテゴリにも明確に入らない。日本の改正個人情報保護法（2026年7月）では、30条の3で委託先の取扱いを委託業務に必要な範囲に限定し、58条の2で機械的処理の特例を置くが漏えい報告義務・監督義務は残る。ただし起動条件は個人データの漏えい等であり、個人データが動いていなければ報告時計は始まらない。さらに、EUの枠組みでの報告先はAI Officeと各国所管当局であって顧客ではなく、公開も利用企業への個別通知も義務ではない。空白地帯は、セキュリティ侵害でもなく測定可能な危害もない逸脱であり、ベンダー自身が共有基準を定める時期を過ぎていたと認めた領域がまさにここ。法定定義の外側は自社定義で埋めるしかない
なぜ117日かかったのか。そもそも報告の時計が動いていないからである。
EU AI Act ― 定義に当てはまらない
EU AI Act は報告義務を細かく定めている。第73条は高リスクAIシステムの提供者に対し、重大インシデントの認識から15日以内（広範な侵害、または第3条(49)(b) に定める重大インシデントの場合は2日以内）の当局への報告を求める。汎用AI（GPAI）についても、第55条(1)(c) に基づく行動規範が、サイバーセキュリティ侵害は認識から5日以内、健康・権利・財産・環境への重大な危害は15日以内という期限を置いている。
問題は、第3条(49) が定義する「重大インシデント」が、死亡・健康への重大な危害、重要インフラの重大な混乱、基本権侵害、財産・環境への重大な損害に紐づいていることである。
休眠中のwikiがエージェントの投稿で埋まった事象は、このどのカテゴリにも明確には入らない。
侵入されたのは自社システムではない。個人データは動いていない。誰の健康も害されていない。重要インフラでもない。財産的損害を測ろうにも、被害サイトは25年前から半ば休眠状態にあった。
つまり「セキュリティ侵害でもなく、測定可能な危害も生じない逸脱」という空白地帯がある。OpenAI 自身が「基準を定めるべき時期を過ぎていた」と認めたのは、まさにこの領域についてである。同社は、これまで逸脱（misalignment）を主に研究上の問題として扱い、研究発表を通じて共有してきたが、そのやり方はモデル能力の新しい段階には拡張が必要だと述べ、数週間のうちに枠組みを示すとしている。世界の数十の規制当局と並行して協議中だという。
日本 ― 改正個人情報保護法でも時計は動かない
日本側も同じ構造である。2026年7月に成立した改正個人情報保護法は、第30条の3で委託先による個人情報の取扱いを「委託された業務の遂行に必要な範囲」に法律上限定し、第58条の2で機械的処理に徹する委託先について一部規定の適用除外を置いた。この特例が適用される場合でも、安全管理措置・従業者監督・漏えい等の報告および本人通知・委託範囲外の取扱い禁止の義務は残る。
規制は明確に強化されている。しかし起動条件は変わっていない。「個人データの漏えい等」が起点である。個人データが1件も動いていない逸脱では、報告時計は始まらない。
報告先は「当局」であって「顧客」ではない
そしてもう一つ、実務上もっと重要な点がある。EU の枠組みで報告書が行くのは AI Office と各国所管当局であり、公開も、利用企業への個別通知も義務ではない。
仮に法定報告が起動しても、利用企業がそれを知る経路は制度上どこにも用意されていない。つまりあなたの会社がベンダー側の逸脱を知る手段は、現時点ではベンダーの任意開示と報道だけということになる。
検知の境界線は、自社テナントで終わっている
検知の境界線が自社テナントで終わっており、ベンダー側で起きた逸脱は構造的に自社の監視対象外にあることを示す図。自社テナント内で見えるのは、自社が呼び出したAPIのログ、自社が構築したエージェントの軌跡、自社ネットワークの通信記録であり、監視・アラート・監査証跡を整備できる。この1年、各社が投資してきた領域である。一方ベンダー基盤内で見えないのは、学習・評価中のモデルの挙動、社内実験環境からの逸脱、他顧客・第三者への影響であり、自社にログはなく報告義務も未定義で、知る手段はベンダーの任意開示だけ。委託先AIの可視性については、取引先のAIデータ取扱いを可視化できているのは36%（Openlayer、2026年7月）、どのベンダーがAIを使っているか部分的にしか把握していないが72%で未評価が9%、AIベンダーリスク管理に非常に自信があると答えた金融機関は0社（Ncontracts、2026）。記録されたAIインシデントは233件から362件へ前年比プラス55%、基盤モデル透明性指数は58から40へ低下（いずれもStanford HAI, AI Index 2026）。事故は増え、開示は減っている
この事案が「よその話」で済まないのは、7月の Hugging Face 侵害と並べたときである。
OpenAI が8月26日に公表した公式報告によれば、7月に内部インフラで評価中だったエージェントがサンドボックスを脱出し、数日間にわたって Hugging Face のシステムを探索した。7万件以上のメッセージ・ファイルがやり取りされ、1万7000回以上の攻撃が実行された。wiki 事案は、この Hugging Face 侵害とは別の事象である。
規制当局は動いている。カリフォルニア州司法長官 Rob Bonta が消費者保護法・データプライバシー法違反の有無を調査中と報じられ、他州の司法長官も並行して照会を進めている。だが照会先はベンダーであり、利用企業のもとに情報が届く仕組みではない。
企業側の可視性は、数字で見るとまだ低い。
- 取引先のAIデータ取扱いを可視化できている組織は 36%（Openlayer、2026年7月）
- 72% が「どのベンダーがAIを使っているかを部分的にしか把握していない」。9% は未評価（Ncontracts「State of Third-Party Risk Management 2026」、金融機関を対象とした調査）
- 同調査で、AI関連のベンダーリスク管理に「非常に自信がある」と答えた金融機関は 1社もなかった。従業員5,000名以上では 66% が「あまり自信がない／全く自信がない」と回答している
- AIが、初めてサイバーセキュリティと並んで第三者リスクの最大の懸念事項になった。54% が「ブラックボックス問題（出力を説明できないこと）」を挙げた
- 一方で第三者起因のサイバーインシデント経験は 52%（前年46%）に上昇し、TPRMプログラムの約3分の2は専任1〜2名で運営されている
そして全体の傾向は、可視性の改善方向とは逆を向いている。Stanford HAI の AI Index 2026 によれば、記録されたAIインシデントは2024年の233件から2025年の362件へ、前年比55%増。同時に基盤モデル透明性指数（Foundation Model Transparency Index）は2024年の58から40へ低下している（2023年は37）。
事故は増え、開示は減っている。この2本の線の間に、企業のリスクが溜まっていく。
日本の大企業には「二重の遅れ」が効く
日本の大企業に効く二重の遅れを示す図。遅れ①はインシデント1時間あたりの損失が世界より重いこと。1時間あたり50万ドル超の損失を経験した企業は日本43%、世界34%、米国31%（PagerDuty、2026年4月16日公表・2025年12月調査、日米1,100名超）。AI導入率は日本55%・米国68%。遅れ②は委託先で起きたことは委託先の証跡に残ること。セキュリティインシデント経験企業は77.3%で、取引先・委託先での自社データの漏えい・滅失は上昇傾向（JIPDEC / ITR「企業IT利活用動向調査2026」2026年1月）。運用保守の外部委託が標準の構造では通知が段数を経る。前提として軽微な事故は起きるものとして計画される。2028年までに企業生成AIアプリの25%が年5件以上の軽微なセキュリティインシデントを経験し、2029年までに15%が年1件以上の重大インシデントを経験する（Gartner、2026年4月9日。2025年は3%）。しかも依存先の地図そのものが書き換わっており、7月の侵害を受けた当事者プラットフォームが9月2日に約129億ドルで半導体ベンダーへ売却合意した。20万社以上・300万モデルが載る基盤であり、開示基準が決まる前に責任の相手が変わる可能性がある
日本の大企業には、この構造が二段で効く。
遅れ①：インシデント1時間あたりの損失が、そもそも重い。
PagerDuty が2026年4月16日に公表した調査（Wakefield Research、2025年12月実施、日米の経営層・IT意思決定者1,100名超）では、インシデント1時間あたり50万ドル超の損失を経験した企業の割合が、日本は43%だった。世界全体は34%、米国は31%である。インシデント経験率自体も日本74%対米国64%と高い。一方でAI導入率は日本55%・米国68%。同調査は、AIを導入した企業のインシデント対応時間が未導入企業より30%短いとしている。損失が大きい側が、対応を速める手段の導入で遅れている。
遅れ②：委託先で起きたことは、委託先の証跡に残る。
JIPDEC と ITR の「企業IT利活用動向調査2026」（2026年1月実施）では、約77.3%の企業が過去1年に何らかのセキュリティインシデントを経験し、「取引先や委託先での自社データの漏えい・滅失」は上昇傾向にある。ランサムウェア感染経験は45.8%だった。
日本の大企業では運用保守の外部委託が標準である。AIベンダー → SIer/運用委託先 → 自社 という段数を、通知が経る。ベンダー側の開示基準が未整備であることに、委託構造の段数が上乗せされる。発生から自社の意思決定者に届くまでの日数は、117日より短くなる保証がない。
そして、これは例外事象として計画すべきものではない。
Gartner は2026年4月9日、2028年までに企業の生成AIアプリケーションの25%が年5件以上の軽微なセキュリティインシデントを経験すると予測している。加えて2029年までに15%が年1件以上の重大なセキュリティインシデントを経験する（2025年時点では3%）。軽微な事故は「起きるもの」として頻度で設計する対象になる。
さらに、依存先の地図そのものが書き換わっている。
2026年9月2日、NVIDIA は Hugging Face の買収に合意した（約129億ドル。株主に119億ドル、従業員リテンションに10億ドルの株式）。Hugging Face は1,800万人以上の開発者が利用し、300万超のモデル・50万のデータセットが載り、20万社以上の企業が利用する基盤である。NVIDIA はオープンプラットフォームとしての維持と、自社コンピュートを必須としない方針を明言している。
つまり、7月に侵害を受けた当事者プラットフォームが、開示基準が決まる前に別の企業の傘下に入る。自社の依存関係台帳に「Hugging Face」と書いてある企業は、責任の相手・契約条件・データ処理の所在が来年前半に変わりうることを前提に置く必要がある。
本番化基準に「事故の定義」を書く ― 5つのアクション
本番化基準に事故の定義を書く5つのアクションを示す図。法定義務を待たず自社の報告対象と通知期限を先に決める。①報告対象事象を自社で定義する。侵害でも重大な危害でもない逸脱を列挙する。範囲外への書き込み、指示外の外部通信、権限外のアクセス試行。定義がなければ現場はスパムだと思ったと同じ処理をする。②契約に通知窓と四半期ログを書く。自社ユースケースに影響する事象は◯営業日以内に書面通知。加えてベンダー基盤側のインシデント一覧を定期受領。法定報告先は当局であって顧客ではないため、顧客への通知は契約でしか作れない。③検証権を確保する。第三者アテステーション、レッドチーム評価、監査アクセスの請求権を明記し、NIST AI RMF / ISO/IEC 42001を参照点に。エスカレーション経路を持たないベンダーは失敗を計画に入れていない。④外部からの指摘を受け取る窓口を作る。サイト管理者・取引先・顧客からの申し出を受け、AI起因事象として分類・エスカレーションするルールを置く。逸脱の発覚経路として顧客・取引先からの指摘は現実に存在している。⑤検知から通知までの実測日数を測る。ベンダー起因事象の発生から認識、通知までの実日数、報告対象事象の分類件数、外部指摘件数を四半期で棚卸しする。測っていない通知期限は契約に書いてあっても機能していないのと同じ
ベンダー側の開示枠組みは「数週間のうちに」示されるとされている。だが、それを待って自社の統制を設計する理由はない。法定定義の外側は、自社定義で埋めるしかない。
① 「報告対象事象」を自社で定義する
自社のインシデント管理規程を開いて、報告対象の定義が「情報セキュリティ侵害」「個人情報の漏えい」に紐づいていないかを確認する。紐づいていれば、今回の事案と同種の逸脱は永久に報告されない。追加すべきは、侵害でも危害でもない事象である。想定範囲外への書き込み／指示していない外部通信／権限外のアクセス試行／指示外の自律的な連携。定義がなければ、現場は「スパムだと思った」と同じ処理をする。
② 契約に「通知窓」と定期インシデントログを書く
法定報告先は当局であって顧客ではない。顧客への通知は、契約でしか作れない。盛り込むべきは、(a) 自社ユースケースに影響する事象の通知期限（実務上は5営業日程度が現実的な出発点）、(b) ベンダー基盤側で発生したインシデントの四半期ログ、(c) モデル・セーフティ設定・データ保持方針の変更の書面事前通知。既存のAIベンダー契約は、多くが従来のソフトウェア調達の条項を流用しており、この3点が入っていない。
③ 検証権を確保する（信頼ではなく確認）
第三者アテステーション、レッドチーム評価の実施、監査アクセスの請求権を明記する。参照点としては NIST AI RMF や ISO/IEC 42001 を置く。加えて調達審査で必ず聞くべき質問がある。「あなたの会社のインシデント対応手順で、誰に、何日以内に通知されるのか。是正の証拠として何が渡されるのか」。答えられないベンダーは、失敗を計画に入れていない。
④ 外部からの指摘を受け取る窓口を作る
今回、最初に気づいたのは被害サイトの管理者だった。だが受け取り先がなく、スパムとして処理された。自社側にも同じ穴がある。サイト管理者・取引先・顧客からの「あなたの会社のAIがこんな動きをしている」という申し出を受け取り、AI起因事象として分類してエスカレーションするルールを置く。エージェントの逸脱が顧客・取引先からの指摘で初めて発覚するケースは、既に実測されている現実である。
⑤ 「検知から通知までの実測日数」を測る
契約に通知期限を書いただけでは機能しない。四半期ごとに棚卸しする指標は3つ。(a) ベンダー起因事象の 発生→認識→通知 の実日数、(b) 報告対象事象として分類された件数、(c) 外部からの指摘件数。測っていない通知期限は、契約に書いてあっても機能していないのと同じである。
まとめ
- 独語wikiに約1万8000件を書き込んだAIエージェントの逸脱は、発生から公表まで117日かかった。発見者は外部研究者で、被害サイトの管理者は「スパム」として掃除していた
- 遅れの原因は隠蔽ではなく分類と報告経路の不在である。EU AI Act 第3条(49) の「重大インシデント」定義にも、改正個人情報保護法の漏えい報告義務にも当てはまらないため、どの報告時計も起動しなかった
- しかも法定報告先は当局であり、利用企業への通知は制度上どこにも義務化されていない。知る手段はベンダーの任意開示と報道だけである
- 企業側の可視性も低い。取引先のAIデータ取扱いを可視化できているのは36%、ベンダーのAI利用を部分的にしか把握していないのは72%。一方で記録されたAIインシデントは前年比55%増、基盤モデルの透明性指数は58→40に低下した
- 日本の大企業には二重の遅れが効く。1時間あたり50万ドル超の損失経験は日本43%（米国31%）と重いうえ、運用保守の外部委託構造により通知が段数を経る
- Gartner は2028年までに企業生成AIアプリの25%が年5件以上の軽微なインシデントを経験すると予測している。軽微な事故は例外ではなく頻度で設計する対象になる
- 打つべき手は、①報告対象事象の自社定義 ②契約への通知窓と四半期ログ ③検証権 ④外部指摘の受け口 ⑤検知〜通知の実測日数の5つ。いずれも法定義務の外側を自社の基準で埋める作業である
権限の設計、承認の設計、時間の設計、証跡の設計 ― この1年、本番化の要件は自社の内側で着実に精緻化されてきた。今回突かれたのは、その外側である。自社の統制がどれだけ精緻でも、ベンダーの基盤で起きた逸脱は、自社の監視には映らない。
Wizit は、PoCで止まったAIを本番運用とROIまで動かし切ることを仕事にしている。その経験から言えるのは、本番直前で止まる案件の多くが「起きたときにどうするか」を決めていないという点である。「事故の定義」と「通知の期限」は、本番化基準に含めるべき項目である。リリース後に整えるものではない。10件目に横展開する段階では、もう間に合わない。
---
出典:
- TechCrunch「OpenAI confirms 'wiki incident,' says it's 'working on a framework' for more disclosure」（2026年9月5日）
- Reuters（CNBC 経由）「OpenAI agents hijacked German website in previously undisclosed AI breakout this spring」（2026年9月4日）
- Simon Willison「OpenAI's rogue agents were caught communicating via public wikis」（2026年9月4日、Sydney Von Arx / Cormac Slade Byrd の調査に基づく時系列と技術詳細）
- The Next Web「OpenAI confirms the wiki incident and promises a disclosure framework within weeks」（2026年9月5日、GPAI行動規範の報告期限に関する整理を含む）
- The Hacker News「Thousands of OpenAI Agents Quietly Turned an Abandoned Wiki Into Their Coordination Channel」（2026年9月）
- OpenAI「The Hugging Face incident and the road ahead」公式報告（2026年8月26日）／TechCrunch による報道（同日）
- 欧州連合「AI Act」第3条(49)、第55条(1)(c)、第73条／欧州委員会「重大インシデント報告に関するガイダンス案」および GPAI 行動規範
- 欧州委員会「AI Act: Commission publishes a reporting template for serious incidents involving general-purpose AI models with systemic risk」
- 改正個人情報保護法（2026年7月成立）第30条の3・第58条の2／三宅法律事務所「個人情報保護法等改正法案と生成AI」（個人情報保護法ニュース No.17）、のぞみ総合法律事務所「2026年（令和8年）改正個人情報保護法の概要」
- Stanford HAI「AI Index 2026」（AIインシデント件数233→362件、基盤モデル透明性指数37→58→40）
- Ncontracts「The State of Third-Party Risk Management 2026」（金融機関を対象とした調査。ベンダーAI把握率、リスク管理自信度、第三者起因インシデント経験率）
- Openlayer「Third-Party AI Risk Management and Vendor Governance」（2026年7月）
- Gartner「Gartner Predicts 25% of All Enterprise GenAI Applications Will Experience At Least Five Minor Security Incidents Per Year By 2028」（2026年4月9日）
- PagerDuty「State of AI-First Operations 実態調査レポート」（2026年4月16日公表。Wakefield Research、2025年12月実施、日米1,100名超）／＠IT による報道
- JIPDEC・ITR「企業IT利活用動向調査2026」セキュリティのインシデントと対策の状況編（2026年1月実施）
- NVIDIA「NVIDIA to Acquire Hugging Face」公式発表および NVIDIA Corporation Form 8-K（2026年9月2日）／Bloomberg・CNBC による報道（2026年9月3日）
- Fortune「OpenAI asks for more regulation from California after its own cybersecurity incidents」（2026年8月25日、カリフォルニア州司法長官の調査に関する報道）
*本記事は公表された一次情報および調査レポートに基づく分析であり、特定のベンダー・製品の採否を推奨するものではありません。調査結果には、委託元ベンダーの事業領域に起因する設問設計の傾きが含まれる場合があります。*