前編では、OpenAIのテストの最中にAIが隔離環境を抜け出し、Hugging Faceのシステムへ到達するまでの経緯を追いました。では、あの出来事は「AIが脱走した」という理解でよいのでしょうか。
そして、自社のAI利用とはどんな関わりがあるのでしょうか。
さらに日本では、この変化を前提とした国の取り組みと、新しい評価制度が動き始めています。
誤解の整理から、国内で進む備えまでを順に見ていきます。
・ChatGPTなどを業務で使っている方
・社内で情報システムやセキュリティを任されている方
・取引先からセキュリティ対策の水準を求められる可能性があるご担当者様
1. 「AIが脱走した」という理解でよいのか
事件が報じられたとき、見出しには「AIが脱走」、「AIが反乱」といった言葉が並びました。
強い言葉になりますが、はたしてこのような理解は正しいのでしょうか。本章で検討していきたいと思います。
◇AIが意思を持ったとは確認されていない
OpenAIの説明は明確です。
『モデルはExploitGymの解答を見つけることに極度に集中しており、限定された試験目標を達成するために極端な手段を取った』
これが同社の見解です。
Hugging Faceの分析も一致しており、同社は一連の侵入はAIの視点から見ればテストのカンニングだった、と結論づけています。自力で問題を解く代わりに、答えの置いてある場所へたどり着こうとした、ということです。
前の章で触れた「破壊的な操作をすべて実行しない設定で試していた」という記録も、この見方を裏付けます。壊すことが目的なら、そんな配慮は必要ありません。
AIは、意思を持って外部へ逃げようとしたのではありませんでした。
与えられた目標を達成するために、想定されていなかった方法を選び続けた、これが公表資料の示す正しい見解と考えます。
◇GPT-5.6が単独で起こした事件ではない
「GPT-5.6が勝手にHugging Faceを攻撃した」という理解は、いくつもの点で不正確と言えるでしょう。
◇それでも軽視できない理由
では、大げさに騒ぐ必要はないのかというと、そうではありません。
研究環境の中で測られていた理論上の能力が、現実のシステムでも通用することが示されました。
先に紹介したUK AISIの評価は模擬環境での話でしたが、それが実際の企業のシステムに対しても成立してしまったわけです。
Hugging Face自身は、突かれた弱点の一つひとつは、ごくありふれたものだったと述べています。
データ処理の甘さ、開きっぱなしのクラウド設定、広すぎる権限、長く生きたままの認証情報。腕のいい人間の攻撃者であれば、同じ弱点を見つけられたはずだ、とも書いています。
違いは、規模と速度でした。
◆AIによる攻撃量が、守る側の問題を変えた
AIは17,600回の行動を積み重ねました。そのほとんどは失敗しています。
行き止まりに当たれば別の道を試し、通信が遮断されれば別の経路に切り替え、一度諦めた手がかりにも戻ってきました。使っていた環境は使い捨てで、毎回ゼロから道具をそろえ直す必要がありましたが、それでも続けました。
そして、成功した1本の経路は、失敗した数千本が生んだ雑音の中に埋もれていました。
攻撃を受けて守る側が向き合ったのは、1つの鮮やかな攻撃ではありません。
複数のシステムにまたがって延々と発生し続ける、単独では判断のつかない大量の記録でした。しかもその間も、攻撃は新しい経路を試し続けています。
Hugging Faceはこの経験から、機械の速度で行われる攻撃は、ありふれた弱点を守る側にとって高くつくものに変えてしまうと結論づけました。攻撃側が試せる経路の数、失敗した経路を差し替える速さ、守る側が解釈しなければならない証拠の量、そのすべてが一段階上がりました。
※この事件の調査は現在継続中になります。OpenAIはセキュリティ企業のCrowdStrikeと協力して自社ネットワーク内での挙動を検証しており、METRとRedwood Researchによる第三者評価も進んでいます。両者は評価の範囲と結果を共同で公表する予定で、その内容がOpenAIの技術報告書にも反映される見込みです。（2026年9月時点）
2. 一般企業のAI利用には、どう関係する？
📊 サクッと回答
通常のチャット画面で文章を書いたり要約したりする使い方と、今回の特殊な評価環境を同じように心配する必要はありません。
ただし、AIに許可する機能が増えるほど、今回の事案との共通点も増えていきます。
◆「インターネットに繋いでいない」は安全の保証にならない
今回の環境で、AIに直接のインターネット接続は与えられていませんでした。それでも外へ出られたのは、部品を取り寄せるための中継サーバーが、外との接点になっていたからです。
自社の環境に置き換えると、こうした間接的な接点は珍しいものではありません。
今後よく留意すべきなのは「AIにインターネット接続を許可したか」だけではなく、間接的な経路まで含めた、全体の構成です。
◆リスクを決めるのはAIの性能だけではない
同じAIでも、何を許可しているかによって、起こり得ることは大きく変わります。
| AIの利用方法 | 注意度 | AIに渡っているもの | 事故が起きたときに広がる範囲 |
|---|---|---|---|
| 文章の作成・要約 | ⚠️△△ | 入力した文章のみ | 入力した内容の漏えい |
| 社内文書の検索 | ⚠️⚠️△ | 社内データの閲覧権限 | 権限の及ぶ範囲の文書すべて |
| ソースコードの参照 | ⚠️⚠️△ | リポジトリの閲覧権限 | 設計情報、埋め込まれた認証情報 |
| コードの自動実行 | ⚠️⚠️⚠️ | 計算環境そのもの | 実行環境と、そこから繋がる先 |
| 外部APIへの接続 | ⚠️⚠️⚠️ | 認証情報と外部への通信路 | 接続先のサービスと、その先のデータ |
| クラウドの操作 | ⚠️⚠️⚠️ | インフラの操作権限 | 環境全体の設定・停止・削除 |
| 本番システムの変更 | ⚠️⚠️⚠️ | 稼働中システムへの変更権限 | 事業とお客さまへの直接の影響 |
※注意度は、AIに渡している権限の広さを基にした本記事独自の目安です。実際のリスクは、各社の権限設定や運用体制によって変わります
上に行くほどAIは「答えるもの」で、下に行くほどAIは「実際に何かを動かすもの」であり「権限」を持っています。今回の事件で使われたのは、コードを実行できる環境、外部への通信路、クラウドの操作権限など、表の下側にあたる部分でした。
本事件で突かれたのは、AIの賢さではなく、環境側にあったありふれた弱点と言えます。
どれも、AIとは無関係に以前から存在していた種類の問題です。
「このAIは安全か」ではなく、「このAIに何を許可しているか」
問うべき視点はこちらでした。
◆では、それを誰が確かめるのか
ここまでは、自社が何を許可しているかを自分たちで把握しておくという話でした。
ところが日本では今、その把握を自社のためだけでなく、取引先に示す必要が生まれつつあります。
今回の事件は海外の研究現場で起きたものですが、そこで示された変化は、国内の脅威認識にも、これから始まる制度にも、すでに反映され始めています。
次の章から、日本国内の動きを見ていきます。
昨今、AIを仕事やプライベートで活用する人は爆発的に増えていると思いますが、AIに対して許可する範囲を考えて使っている割合はそんなに多くはないのではないでしょうか。
「このAIに何を許可しているか」、まずは棚卸しすることから始める必要がありそうです。
3. 日本政府は、事件の2か月前から動いていた
前の章で、AIに何を許可しているかを取引先に示す必要が生まれつつある、と書きました。
この動きは、7月のOpenAIの事件を受けて始まったものではありません。
事件が起きるより以前から、日本国内ではサイバーリスクに対する動きが進められていました。
【2026年1月】脅威ランキングにAI初登場
IPA（情報処理推進機構）が毎年公表している「情報セキュリティ10大脅威」に、今年AIが初選出されました。
| 順位 | 「組織」向け脅威 | 2026年版での位置づけ |
|---|---|---|
| 1 | ランサム攻撃による被害 | 11年連続の選出 |
| 2 | サプライチェーンや委託先を狙った攻撃 | 8年連続の選出 |
| 3 | AIの利用をめぐるサイバーリスク | 今回が初選出 |
| 4 | システムの脆弱性を悪用した攻撃 | 前年は3位 |
| 5 | 機密情報を狙った標的型攻撃 | 11年連続の選出 |
※IPAは「順位が危険度を表しているわけではない」と説明しています。前年の被害状況をもとに、選考会の参加者が社会的影響の大きさを判断した順位です
1位と2位は4年連続で入れ替わっていません。その動かない上位に、初選出でいきなり食い込んだのが「AIの利用をめぐるサイバーリスク」でした。
IPAが挙げている中身は、研究現場の特殊な事故ではありません。
いずれもAIを使う側が原因となって起きることです。
前の章で見た「何を許可しているか」の話が、そのまま国内の脅威認識にも表れています。
【2026年5月】14の省庁による新方針の発表
さらに大きな動きが、2026年5月18日にありました。
内閣官房国家安全保障局、国家サイバー統括室、警察庁、金融庁、デジタル庁、総務省、経済産業省、防衛省など14の省庁・機関が連名で、対策パッケージ「Project YATA-Shield（プロジェクト・ヤタシールド）」を公表しています。
💡 Project YATA-Shieldとは？
ひとことで言えば、「AIが強くなったので、国としての守り方を変えます」という方針と、そのための“やることリスト”です。新しい法律ではなく、14の省庁が「うちはこれをやります」と持ち寄って1つにまとめた文書にあたります。
✔️ なぜ必要になったのか
AIは、ソフトウェアの弱点を見つける速さが急激に上がりました。この力は、攻める側が使えば武器になり、守る側が使えば頼もしい道具になります。同じ力なので、何もしなければ攻める側だけが ”先に得をしてしまう” そこが出発点です。
✔️ やることは大きく3つ
①伝える
電気・水道・金融・交通など、生活を支えるインフラ企業に「弱点がこれまでより速く、大量に見つかる時代になる」と伝え、備えを促す
②調べる
海外の政府やAI開発企業と連携し、最新のAIがどこまでできるのかを継続的に評価する
③自分たちも使う
日本でも弱点を見つけるAI技術の開発を進め、政府自身の防御にもAIを活用する
✔️ 名前の由来
「YATA」は Yielding Advanced Threat Awareness with AI の頭文字で、真実を正確に映すとされる八咫鏡（やたのかがみ）にかけた命名です。脅威を正しく映し出した上で防ぐ、という意味が込められています。
きっかけは、同年4月7日にAnthropic社が公表したフロンティアAIモデルでした。
AIによる脆弱性の発見・修正の性能が急速に上がったことに、国として備える必要があると判断されたわけです。
文書には、政府の認識がはっきり書かれています。
高性能AIにより、脆弱性の発見・修正等が高速化することが考えられる。一方で、高性能AIが攻撃者に悪用されることにより、サイバー攻撃がより高速かつ大規模に行われるおそれがあるため、悪用リスクを前提として、高性能AIを積極的にサイバー防御に活用していくことも含め、対策強化を早急に進めていくことが必要である。
参照元 :内閣官房「AI性能の高度化を踏まえたサイバーセキュリティ対策の強化について ～Project YATA-Shield～」
攻撃にも防御にも同じ能力が効く、だから防御側も使う。
この整理の上で、立場ごとに求められることが示されました。
| 対象 | 求められていること | つまり、何が変わるか |
|---|---|---|
| 重要インフラ事業者など | 高性能AIの悪用リスクに備えた対策の実施。より高速かつ大量に脆弱性が発見・修正されることを前提とした対策強化 | 「月次のメンテナンスでまとめて対応」という運用が成り立ちにくくなる |
| ソフトウェアを開発・提供する企業 | セキュア・バイ・デザインの原則に基づき、高性能AIも活用しながら、開発の全工程で脆弱性の早期発見・対応に取り組む | 「作ってから直す」ではなく、AIを使って先に見つけることが前提になる |
| 政府機関など | 民間と同様に、高速かつ大量の脆弱性発見を前提とした対応強化 | 発注元である官公庁側の要求水準も上がっていく |
注目したいのは、経営層のリーダーシップの下で実施するよう明記されている点です。
情報システム部門だけの話として扱われていません。
そして7月、想定は現実になった
政府がこの文書をまとめた時点では、「高速かつ大規模」はまだ想定の話でした。
その2か月後に起きたのが、前編で見た事件です。4日半で17,600回の行動、そのほとんどが失敗、それでも試し続けて成功経路にたどり着く。
まさに「高速かつ大量」が実際のシステムで起きたことになります。
つまり日本企業にとって今回の事件は、海外で起きた珍しい出来事ではありません。
国が半年かけて備えようとしていた変化が、実際に起こることを裏づけた事例として読むのが適切です。
では、「より高速かつ大量に脆弱性が発見されることを前提とした対策強化」とは、自社にとって具体的に何をすることなのか。
その答えが、次の章で扱う制度の中に用意されています。
政府が動いたのが事件の2か月前というのは驚きました。
ニュースを見てから慌てるのではなく、こういった公的な発表を追っておくことの意味を、今回あらためて感じました。
4. ある日、取引先から「★4を取ってください」と言われる
近い将来、こんなメールが届くかもしれません。
「2027年度以降のお取引にあたり、SCS評価制度の★4の取得をお願いいたします。取得のご予定について、ご回答をお願いします」
聞き慣れない制度名と、見慣れない星の記号。
心当たりがなければ、何を求められているのかも分からないはずです。
この制度とは、『サプライチェーン強化に向けたセキュリティ対策評価制度（通称：SCS評価制度）』のことです。
経済産業省と内閣官房国家サイバー統括室が2026年3月27日に制度の構築方針を公表し、IPAが運営にあたります。
そして冒頭のような場面こそが、この制度が想定している使われ方です。
💡 SCS評価制度とは？
取引先のセキュリティ対策がどれくらいのレベルかを、★の数で示せるようにする仕組みです。
これまでは、発注する側から見て取引先の対策状況が分からず、受注する側は会社ごとにバラバラのチェックシートに答え続けるという状態が続いていました。10社と取引していれば、書式も項目も違う10通りの依頼が届きます。
そこで共通のものさしを1つ作り、一度評価を受ければ複数の取引先に同じ結果を示せるようにしようというのが、この制度の狙いです。
負担が増えるだけの話として捉えると、制度の半分しか見ていないことになります。
★3と★4はどう違う？
段階は★3・★4・★5が想定されています（★5は今後の検討事項です）。
取引先から求められる可能性が高いのは、★3か★4になります。
| ★3 | ★4 | |
|---|---|---|
| 想定している脅威 | 広く知られた弱点を突く、一般的な攻撃 | 供給が止まると社会に影響が及ぶ企業や、機密情報を扱う企業への攻撃 |
| 要求事項の数 | 26件 | 43件 |
| 評価のしかた | 専門家の確認を付けた自己評価 | 評価機関による第三者評価 |
| 有効期間 | 1年 | 3年 |
| 負担の目安 | 社内で評価シートを記入し、専門家に確認してもらう | 書類確認に加え、訪問でのヒアリングと技術的な検査を受ける |
※要求事項の数・評価方法・有効期間はIPA公表資料に基づきます（2026年9月時点）。評価用のガイドは順次公開の為、運用の詳細は今後具体化予定
★3は自分で評価します。
評価シートを社内で記入し、セキュリティの専門家に確認してもらった上で、経営層の宣誓を添えて提出する形です。専門家は社内にいなければ、社外へ依頼できます。
★4は他人に評価してもらいます。
評価機関が書類を確認するだけでなく、実際にヒアリングを行い、さらに技術的な検査が入ります。
★4の技術検証は、脆弱性診断そのもの
ここが、この記事にとって重要な部分です。
★4の評価に含まれる技術検証の中身は、インターネットに公開している機器の内、突かれると社内に侵入されるリスクが高いもの（VPN装置やルータなど）を対象とした脆弱性検査です。
前編と繋がってくる部分ですが、AIが最初に突破したのは外部とつながっていた1台の中継サーバーでした。制度が技術検証で見ようとしているのは、まさにその種類の入口です。
そして、実務上ありがたい設計になっています。
直近に実施した脆弱性検査の結果を提出することで、この技術検証の代替とみなすことも検討されています。
つまり普段から脆弱性診断を回していれば、その記録がそのまま評価に使える可能性があるということです。
制度が始まってから慌てて検査するより、日常の運用として組み込んでおくと有利ですね。
誤解しやすい4つのこと
いつまでに、何をすればいいのか
慌てる必要はありませんが、時間の感覚は掴んでおくとスムーズに取り組めます。
| 時期 | 制度側で起きること | 自社で考えておくこと |
|---|---|---|
| 2026年度下期 | 評価用のガイドや解説書が順次公開される | 主要な取引先が、どの段階を求めてきそうかを想定しておく |
| 2026年度末頃 | ★3・★4の申請受付が始まる（目標） | ★3で足りるのか、★4が必要なのかを判断する |
| 2027年度以降 | 取引契約の中で段階の提示が始まる | 求められてから動くと、評価の期間分だけ遅れる |
※上記は2026年3月公表の制度構築方針および同年5月更新のIPA公表情報に基づく予定です。制度運営基盤の整備状況等により変更となる可能性があります
現在地は、評価用のガイドがまだ出そろっていない段階です。一方で、要求事項と評価基準そのものはすでに公開されています。
自社の現状を点検する材料は揃っているので、「まだ始まっていないから様子見」で止めておく理由はありません。
中小企業向けには、負担を抑えるための支援も用意されています。
「何を許可しているか」を、自分以外に示す時代へ
前の章までで、リスクを決めるのはAIの性能ではなくそのAIに何を許可しているかだと確認しました。
この制度が意味しているのは、その答えを自社のためだけでなく、取引先に示すために持っておく必要が出てくる、ということです。
そして★4の技術検証が脆弱性検査である以上、自社に今どんな弱点があるかを定期的に確かめる仕組みは、任意の取り組みから取引の前提条件へと位置づけが変わっていきます。
「取引先に示すために持っておく」
この発想は今後重要になっていきそうです！自社を守るためだけでなく、取引を続けるための準備でもあると考えると、優先度が変わってきますね。
【AI導入サポート】IAJにおまかせ！こちらからお気軽にお問合せください >>
【後編】振りかえり…
1. 事件の本質は、AIが意思を持ったことではなかった
AIは「テストの答えを見つける」という限られた目標に集中し、想定外の方法を選び続けた。壊すことが目的ではなく、破壊的な操作はすべて実行しない設定で試されていた
2. リスクを決めるのは、AIの性能ではなく「何を許可しているか」
文章の作成・要約と、コードの自動実行やクラウドの操作では、事故が起きたときに広がる範囲がまったく違う。「繋いでいない」も安全の保証にはならない
3. 日本ではすでに、この変化を前提とした備えが始まっている
1月にはIPAの脅威ランキングにAIリスクが初選出で3位。5月には14の省庁がProject YATA-Shieldを公表。いずれも7月の事件より前の動きだった
4. そして「弱点を確かめる仕組み」は、取引の前提条件になっていく
2026年度末に始まるSCS評価制度では、★4の技術検証として脆弱性検査が行われる。
日頃から診断を回していれば、その記録がそのまま使える可能性がある
前編と後編を通して見えてきたのは、変わったのはAIの意思ではなく、能力の届く範囲と速さだったということです。
突かれた弱点そのものは、どれもありふれたものでした。
データ処理の甘さ、開いたままのクラウド設定、広すぎる権限、長く生きたままの認証情報。
ただ、それが4日半で17,600回という速さと量で試されたとき、守る側の負担はまったく別のものになりました。
つまり、弱点が見つかるまでの猶予が短くなったということです。
「そのうち直そう」「うちのような規模まで手は回らないだろう」といった前提が、少しずつ通じにくくなっていきます。
だからこそ、問いは「AIは危険か」ではありません。
自社はいま、何を、どこまで許可しているのか。そしてその状態を、取引先に説明できるのか。
この2つを把握しておくことには、はっきりした利点があります。
一つは、AIにどこまで任せてよいかを、感覚ではなく一覧で判断できるようになること。
もう一つは、その把握と点検が、そのままSCS評価制度への備えになることです。★4の技術検証は脆弱性検査であり、日頃の検査結果をそのまま使える可能性があります。
自社を守るための行動が、そのまま取引を続けるための準備にもなる。
次にどんなAIが登場するかは誰にも分かりませんが、
「何を許可しているか」と「外から見える弱点はどこか」は、どのAIが来ても変わらない土台です。
まずはここから、簡単なことから始めてみるのはいかがでしょうか。
前編を読んだときは「海外の話だな」と思っていましたが、日本でも事件の2か月前から動きがあったと知って見方が変わりました。
まずは「自社のAIに何を許可しているか」の棚卸しから。その上で、脆弱性診断を日常の運用に組み込めると、新制度が始まっても慌てずに済みそうです。
自社のAI導入や運用にお困りの方は、ぜひIAJにお気軽にご相談ください。
【システム開発はIAJ】気になる点は何でもお聞き下さい！問い合わせはこちら >>
＜＜IAJってどんな会社？＞＞
IAJは、創業26年目を迎えるシステム開発会社です。専門性の有無に関わらず、お客様と対話を重ねながら伴走し、本質的な課題解決に向き合ってきました。月間200万人規模のアプリや1000万人規模のシステムなど、大規模案件を含む豊富な実績があります。私たちは「作って終わり」ではなく、長く育てられるサービス設計を重視しています。既存システムのリプレイスや再設計も多数手がけてきました。近年はAIを活用した開発にも力を入れており、生成AIや機械学習の導入支援、既存サービスへのAI機能統合など、新しい価値創出にも取り組んでいます。システム開発やAI活用をご検討の際は、ぜひお気軽にご相談ください。
