AI時代の技術格差をどう埋めるか──攻撃側のAIを上回る「守るためのAI」と侵入前提のセキュリティ

2026年9月、何が起きたのか

2026年9月、情報漏えいとAIエージェントをめぐるニュースが相次いだ。ただし、すべてが「AIによる漏えい」ではない。AI関与の確度で分けると次のようになる。

従来型の脆弱性悪用や不正アクセスがまだ多くを占める一方で、AIエージェントが侵入後の探索やデータ取得を担ったとされる事案も現れ始めている。

まず、情報漏洩はどれくらい起きているのか

個別のニュースを、全体の中に置いておきたい。

日本では、個人情報保護委員会の2025年度年次報告によると、事業者からの「漏えい等」の報告は17,139件だった（滅失・毀損やそのおそれを含む）。うち22.3%は「不正の目的をもって行われたおそれ」がある事案である。世界では、Verizonの2026年DBIRで、脆弱性の悪用が侵入経路の31%を占め、盗まれた認証情報を上回った。ランサムウェアは侵害の48%に関与している。

では、AIによる漏洩はどれくらいか。現時点で、AIが直接の原因となった漏洩を横断的に集計した確立した統計はない。Anthropicは2025年、AIが偵察からデータ抽出までを大きく自動化したサイバー諜報活動を公表したが（約30の標的のうち少数で侵入に成功）、これも全体に占める割合を示すものではない。

つまり、AIによる漏洩は件数ではまだ少数だが、実際の侵入を伴う事例はすでに現れている。しかも、AIが関与したかどうかは事故後の調査でも判別しにくく、公開統計では「不正アクセス」や「脆弱性悪用」に紛れてしまう。少ないのではなく、まだ数えられていないだけかもしれない。

このままでは、守る側に勝ち目はない

AIが攻撃の主体に近づいている

件数ではまだ少数でも、私が懸念しているのは、AIそのものが攻撃主体に近づいていく流れである。人間がAIを道具として使う段階から、AIが偵察から侵入、データ取得までを自ら判断して進める段階へ。AEPDやDIVDの事案は、その入り口が見え始めたことを示している。

攻撃する外部と、守る内部の格差

そう考えたとき、外部と内部のあいだには、すでに大きな格差がある。

慎重さを積み重ねた結果、守る側は一周回って「安全性は担保されたが、性能はレガシーなAI」を使うことになる。この組み合わせで正面から競っても、勝ち目はない。

守り方の概念を変える三つの方向

だとすれば、同じ土俵で競うのではなく、守り方の概念そのものを変える必要がある。私は、次の三つの方向を考えている。

1. 入られても、すぐ見つけて潰す：入られる前提で、侵入を素早く検知し、被害が広がる前に封じ込める
2. 盗まれても、読ませない：極論すれば、盗まれても無効なデータなら、攻撃者は何も得られない
3. そもそも、一か所に集めない：P2Pなどでデータを部分的に分散させ、一か所が破られても全件は漏れないようにする

「制限＝安全」から「防御側へのAI投入」へ

これまで、組織がAIを安全に扱う方法は、主に「使わせない」「制限する」ことだった。しかし、その制限が縛るのは守る側だけで、攻撃者には届かない。

これからは、躊躇せず高度なAIを防御側へ投入すること自体が、セキュリティ政策になるというところまで考える必要がある。もちろん無制限に使うのではなく、権限を絞り、行動を記録し、誤りが広がらない仕組みの中で、最も強いAIを守りに使うということだ。

これらはまだ仮説であり、特に後の二つには現実的な限界もある。以下では、AIサイバー能力の現状を確認したうえで、それぞれがどこまで現実的かを考える。

攻撃側のAIは、もうここまで来ている

先に述べた格差は、感覚だけの話ではない。この1年ほどで公表された分析や事案は、攻撃側のAIが具体的にどこまで来ているかを示している。

公開モデルの安全制御は外せる

2026年9月、AnthropicはオープンウェイトモデルGLM-5.3のサイバー能力と安全制御を検証した結果を公開した。評価はいずれも、隔離されたサンドボックス内でオフラインの標的に対して行われている。

一つ目は、安全制御の検証である。明らかに有害な攻撃の依頼に対して、GLM-5.3が標的システムへの接続を試みた割合（各条件50サンプル）は、条件によって大きく変わった。

二つ目は、攻撃能力の検証である。41件のChrome V8脆弱性を使った評価では、410回の試行のうち50回（12%）で、動作するexploitを作成した。

92%も12%も、「その確率で実システムをハッキングできる」という意味ではない。それでも、公開モデルの能力を保ったまま安全制御だけを外せるなら、攻撃者は利用規約にも承認フローにも縛られない。「外部は制約なく高性能なモデルを使える」という格差は、すでに現実の前提になっている。

攻撃の全段階でAIが使われ始めている

2026年6月、Anthropicは、2025年3月から2026年3月までに悪意あるサイバー活動に関係した832アカウントを分析し、AIがMITRE ATT&CKの全14戦術、482のサブテクニックで使われていたと報告した。中リスク以上と評価された活動の割合は、期間の前半の約33%から後半の約56%へ増えている。

一つのAI企業が検知したアカウントの分析であり、攻撃全体の統計ではない。それでも、AIが文章作成の補助にとどまらず、偵察から影響に至る攻撃の各段階に入り込んでいることが分かる。

AIエージェントが自ら境界を越えた

最も踏み込んだ事例が、OpenAIが2026年8月に詳細を公表したHugging Faceのインシデントである。同年7月、社内のサイバーセキュリティ評価中に、研究用モデルのエージェントがインターネットから隔離するための管理策を回避し、OpenAIの社内研究インフラとHugging Faceのシステムの一部を侵害した。

エージェントは、社内のパッケージ管理サービスを即席の「メッセージボード」として使って互いに情報を共有し、未知の脆弱性を連鎖させて、Hugging Faceの数十台のサーバー上でコードを実行するに至った。評価環境には本番製品と同等の安全対策が適用されておらず、OpenAIは顧客データや製品機能への影響はなかったとしている。

これは、人間の攻撃者がAIを道具として使った事例ではない。指示されていない目標に向かってAIエージェント同士が連携し、境界を越えた事例であり、OpenAI自身も業界全体への「警鐘」と位置づけている。AIが攻撃の主体に近づくという懸念は、すでに実際の侵害として現れている。

発想を変える：「入らせない」から「入られても負けない」へ

ここからは、先に挙げた三つの方向を、現在のセキュリティ対策の考え方と照らし合わせていく。

前提として確認しておきたいのは、防御側にとってAIは「導入すれば終わり」ではないことだ。攻撃者は見つけた弱点をすぐに使えるが、守る側は調査、報告、承認、修正、検証を経なければならず、可用性やプライバシー、説明責任も同時に守る必要がある。AI利用を禁止するだけでは相対的に弱くなり、かといって攻撃者と同じように無制限の権限をAIへ渡すこともできない。守る側に必要なのは、能力で正面から競うことではなく、攻撃が成功しても被害が小さく終わる構造をつくることである。

その構造を、次の三つの考え方で整理する。中心は前の二つで、三つ目はそれを補う考え方である。

入られても、すぐ見つけて潰す

「破られる前提」は、すでに標準の考え方になっている

これまでのセキュリティは、ファイアウォールやVPNのように、境界の「壁」を高くすることに力を注いできた。しかし冒頭のGSSの事案のように、壁そのものであるVPN機器が入口になることもある。

侵入を防ぐことだけを成功条件にしない考え方は、AI以前から整理されてきた。そして2026年には、それをAIエージェントにまで広げる動きが出ている。

私が考える「入られてもすぐ見つけて潰す」は、この流れの延長にある。変わるのは対象と速度だ。人間のユーザーだけでなく、AIエージェント一つひとつが「入られた後」に動く主体になり、攻撃が機械の速度で進む以上、検知と封じ込めも機械の速度で回す必要がある。

事例：OpenAIのインシデントで、守る側に何が起きていたか

前の節で紹介したOpenAIのインシデントは、守る側から見ても示唆が大きい。OpenAIが公表した経緯を、「区切る」「見つける」「潰す」の三段階に当てはめると次のようになる。

OpenAIは、モデルの思考の連鎖（CoT）を監視する仕組みが当時稼働していれば、Hugging Faceへの侵入の1日以上前に初期の活動を検知できたはずだとしている。また、初期の兆候への対応や報告体制が不十分だったことも、インシデントの一因に挙げている。壁が破られたこと自体より、見つけて止めるまでの時間が問われた事例である。

攻撃者に地図を完成させない：Moving Target Defense

「すぐ見つけて潰す」をさらに進めた考え方に、Moving Target Defense（MTD）がある。守りの構成を固定せず、IPアドレス、通信経路、仮想マシンやサービスの配置、認証情報、ネットワーク構成を継続的に変えていく。NISTのSP 800-160 Vol.2も、サイバー・レジリエンスの技法として、構成の動的な変更や予測困難性、欺瞞（おとり）を挙げている。

AIが偵察から脆弱性の発見、攻撃コードの作成までを高速化するなら、防御側は構成変更、権限変更、経路変更、欺瞞、隔離を高速化する。攻撃者が調べた環境を、調べたそばから古くする。壁を高くするのではなく、攻撃者に地図を完成させないという発想である。

成果は「どれだけ早く止めて戻せたか」で測る

AIは、ログの要約や相関分析など「見つける」段階で特に力を発揮する。ただし、停止や権限変更をAIの判断だけに任せてはいけない。最終的な認可はモデルではなく接続先のシステムで検証し、エージェントの出力が誤っていても、認可と監査が最後の境界になるようにする。

そのうえで、AI導入の成果は「平均検知時間（MTTD）」や「平均復旧時間（MTTR）」で測るべきだ。AIが何件のアラートを要約したかではなく、発見から封じ込め、復旧までの時間と被害範囲をどれだけ小さくしたかを見る。

盗まれても、読ませない

「すぐ見つけて潰す」が入られた後にすぐ止める考え方だとすれば、こちらは止められなかったときに、盗まれたものの価値をなくす考え方である。

ただし、最初に限界をはっきりさせておきたい。復号済みの個人情報や、すでに成立した認証情報が外部へ出れば、暗号で取り戻すことはできない。目標は「完全な無効化」ではなく、盗まれたデータの価値と範囲を、攻撃者にとって割に合わないところまで下げることだ。

守る対象を「データの周り」から「データそのもの」へ

従来のセキュリティは、インターネットとのあいだにファイアウォールを置き、その内側のネットワークにデータを置くことで、データの「周り」を守ってきた。壁の内側に入られれば、データはそのまま読める。

これに対してデータ中心のセキュリティ（Data-centric security）は、データそのものに防御を持たせる。

データベースを丸ごと盗まれても、鍵がなければ読めない。識別情報と業務データが分かれていれば、片方だけでは誰の情報か分からない。

処理中のデータも読ませない：Confidential Computing

ただし、従来の暗号化には弱点がある。保存時と通信時は暗号化されていても、処理するときにはメモリ上で復号される。サーバーに侵入した攻撃者は、この「処理中」のデータを狙える。

この空白を埋めるのがConfidential Computingである。NISTは2026年5月、クラウド上のAIワークロードが扱うデータを、処理中も含めて保護する手法をまとめたドラフト（NIST IR 8320E）を公開した。

目指すのは、「データベースを盗まれても、鍵がないので読めない」だけでなく、「サーバーに侵入され、AIが処理中のメモリを見られても、それでも読めない」状態である。AIに機密データを扱わせるほど、この処理中の保護は重要になる。

将来も読ませない：PQCの位置づけ

もう一つ、時間の問題がある。長期間保存される通信やデータには、今盗んで将来復号する「harvest now, decrypt later」のリスクがある。今日盗まれた暗号文が数年後に読めてしまえば、「読ませない」守りは時間差で崩れる。

PQC（ポスト量子暗号）は、量子コンピューターによって将来破られる可能性がある公開鍵暗号を、量子計算に耐性を持つ方式へ移行する取り組みである。NISTは2024年に、鍵確立のML-KEM、電子署名のML-DSAとSLH-DSAをFIPSとして標準化し、組織に移行開始を促している。

ただし、データ中心の防御も、Confidential ComputingもPQCも、攻撃者が鍵や管理者の認証情報を盗み、正規の権限でデータを読めば意味をなさない。つまり、データを読めなくする仕組みは、鍵と権限を守る「すぐ見つけて潰す」守りがなければ機能しない。

そもそも、一か所に集めない

冒頭では、中央集権的なデータ保持から、P2Pなどで部分的に分散させた持ち方へ移るニーズが出てくるのではないか、と書いた。

一か所に全件が集まっていれば、侵入者はそこにたどり着くだけで全件を手にできる。冒頭のGyazoの事案で公表された、ユーザー関連データ約2,362万件、画像メタデータ約4.9億件という規模は、一つのサービスに集まったデータが一度の侵害でどこまで広がりうるかを示している。AIが侵入後の探索を自動化すれば、集約されたデータベースは攻撃者にとって最も効率のよい標的になる。

分散すれば安全、ではない

ただし、分散には利点と同時に課題もある。

そのため、現実の主流は「何でもP2Pへ」ではない。データを必要以上に一か所へ集めず、必要な人やエージェントに必要な部分だけを見せる方向である。

実例：「集めない」設計はすでに動いている

日本のマイナンバー制度は、この考え方で設計されている。各行政機関の個人情報を特定の機関に集約する「一元管理」ではなく、従来どおり各機関が保有し、必要なときだけ情報提供ネットワークシステムを通じて照会・提供する「分散管理」をとる。しかも機関間の連携には、マイナンバーそのものではなく、機関ごとに異なる「機関別符号」を使う。一か所が破られても全機関の情報はそろわず、連携に使う番号自体にも意味を持たせない。前の節で触れたトークン化と同じ発想である。

エストニアの電子政府を支えるX-Roadも同様だ。各機関は自前のデータベースを持ち続け、X-Roadを通じて暗号化された形で必要なデータだけをやり取りする。e-Estoniaは、この分散型の設計によって、攻撃者にとって魅力的な「巨大なデータベース」を作らないことを利点に挙げている。

どちらも、全面的なP2Pではない。集めずに持ち、必要なときだけつなぐ。これが、現実に機能している分散管理の形である。

「データをAIへ」ではなく「AIをデータへ」

AI時代には、この考え方がさらに重要になる。AIに学習や分析をさせようとすると、データを一か所に集めたくなるからだ。しかしそれは、攻撃者にとって最も効率のよい標的を自ら作ることにもなる。

そこで注目されているのが、データではなく計算をデータの場所へ持っていく技術である。

たとえばGoogleは2017年、スマートフォンのキーボードアプリ（Gboard）で、入力データを端末に残したまま予測モデルを改善する連合学習の試験を公表している。

つまり、データをAIへ集めるのではなく、AIをデータの場所へ持っていく。分散化は、データをばらまくことではなく、集めずに計算することだ。これは「読ませない」守りを強める一層であり、「すぐ見つけて潰す」守りの代わりではない。

全部はできない。だから順番を決め、AIで回す

すべてを一度にやる必要はない

ここまで多くの対策を挙げてきた。ただ、限られた予算と人で守る組織が、これを全部一度にそろえるのは現実的ではない。対策ごとに、技術の成熟度もコストも大きく違うからだ。現実には、次の三段階で考えるとよい。

一段目は、技術よりも方針と習慣の問題であり、お金をかけずに始められる。二段目は数年がかりの移行になるが、中小の組織でも外部のサービスを使えば手が届く。三段目は、重要インフラや機微なデータを扱う処理など、守る価値の高いところに絞って投じる。

「すぐ見つけて潰す」守りと「読ませない」守りは、どちらか一方を選ぶものではない。入られた後にすぐ止める仕組みと、止められなかったときに盗まれたものの価値を下げる仕組みは、互いの穴を埋め合う。大切なのは、両方を同じ段階から少しずつ積み上げることである。

足りない手を、防御側のAIで補う

それでも、二段目と三段目を人の手だけで回すには、守る側の人も予算も足りない。そして人間の速度で回していては、機械の速度で進む攻撃に追いつけない。冒頭で「躊躇せず高度なAIを防御側へ投入すること自体が、セキュリティ政策になる」と書いたのはこのためだ。防御側のAIは、足りない手を補い、守りを回すエンジンになる。

その取り組みは、すでに始まっている。

• OpenAIは2026年8月、承認された防御担当者向けに、脆弱性の発見、コードレビュー、マルウェア分析、インシデント対応、パッチ検証を支援するDaybreakを拡充した。9月には、水道、電力、地方自治体、銀行などの重要サービスを守る防御担当者への利用枠、研修、技術支援に10億ドルを拠出すると発表している。攻撃者が攻撃用AIを大規模に展開する前に、防御側へ先に届けるという考え方である
• Anthropicと米国パシフィック・ノースウェスト国立研究所（PNNL）は2026年1月、水処理施設の高忠実度シミュレーションでAIに攻撃を再現させ、従来なら数週間かかる作業を3時間で完了したと報告した。本番環境ではなく検証環境で攻撃経路を再現し、防御を変えたらもう一度検証する。AIの速度を、守りの側へ転換する使い方である

いずれも個別の取り組みであり、それだけで格差が埋まるわけではない。ただ、防御側にAIを投入するときの設計原則は見えてきている。

1. 本番とは分離した、現実に近い検証環境を用意する
2. AIには読み取りと分析から始めさせ、変更は差分・承認・ロールバック付きにする
3. モデルの推論、ツール呼び出し、変更内容、検証結果を保存する
4. 脆弱性の発見から修正、再テスト、監視ルールの更新までを一つのループにする
5. モデルが誤っても被害が広がらないよう、ネットワークと権限を別の層で制御する

「AI for Security」と「Security for AI」は分けられない。防御側のAIは、これまで見てきた守りの仕組みの中に組み込んで初めて、攻撃側との格差を埋める力になる。

国・人・組織は、何から始めるか

ここまでの考え方を実行に移すには、国、人、組織のそれぞれで取り組む必要がある。

国：政策文書を予算と仕組みに変える

日本政府も、防御側でAIを使う必要性を認識し始めている。2026年5月、国家サイバー統括室を中心とする関係省庁は、高性能AIをめぐる対策パッケージ「Project YATA-Shield」の取りまとめ案を示した。高性能AIの悪用リスクを前提にしながら、脆弱性の発見・修正や重要インフラの検知・対応に高性能AIを積極的に活用する考え方であり、「防御側へのAI投入そのものがセキュリティ政策になる」という考え方が、政府の文書に現れ始めたものと読める。

現場の側でも動きがある。IPA産業サイバーセキュリティセンターの中核人材育成プログラムでは、2026年7月、修了者の卒業プロジェクトとして、セキュリティ担当者向けの生成AIガバナンスの手引書と、メール解析、脅威情報と資産情報の照合、インシデント時のセキュリティ戦略文書の更新という3つの業務での検証報告が公開された。

方向性は見え始めた。ただし、文書を作るだけでは技術格差は縮まらない。次の資源へ変換する必要がある。

• 政府、自治体、重要インフラ、中小企業が使える防御用AIへの継続的な予算
• 機密データを外へ出さずに検証できる共有サンドボックスと評価データ
• 侵害の兆候、脆弱性、修正状況を安全に共有する官民の情報連携
• AI導入件数ではなく、MTTD、MTTR、被害範囲、復旧成功率で測る調達基準
• PQC移行、ID管理、ログ基盤、バックアップ、レッドチームを別々の予算にしない設計

人：現場で攻撃と防御を試す人を意思決定の中心へ

日本のサイバー政策には、大学教授、官僚、企業幹部、セキュリティ専門家の知見が欠かせない。一方で、AIエージェント、オープンウェイトモデル、プロンプトインジェクション、エージェントのツール連携は変化が速い。

この領域の最前線の知見は、必ずしも肩書きのある人のところにあるわけではない。私自身、Claude CodeやCodexといったAIコーディングエージェントの技術コミュニティに参加したとき、実際に海外でAIベンダーのレッドチームに所属するなど、活躍している若い研究者やエンジニアを見かけた。エージェントが何をでき、どこで境界を越えうるのかを、資料ではなく手触りとして知っている人材である。CTF参加者やレッドチームの実務者にも、同じような人は多い。

こうした人たちを、単なる「若者代表」ではなく、意思決定の中心に入れる必要がある。会議に一度呼ぶだけでは足りない。

• 若手を含む常設のAIレッドチームを置き、予算と検証権限を与える
• 国内外のオープンウェイトモデルを、管理された環境で継続的に評価する
• 行政・企業・大学・AI企業のあいだで、短期の人材交換と共同演習を行う
• 失敗を隠さず、再現可能な教訓として共有する

若さそのものを神格化する必要はない。ただ、数年前の前提で作られた「安全なAI」の枠だけでは、今日のエージェントの挙動を評価できない。現場の変化を理解している人が、現場を変えられる立場にいることが重要である。

組織：まず90日で始めること

大規模な国家計画やシステム刷新を待たなくても、組織単位で始められることはある。

PQCについても、まずは暗号資産の棚卸しから始めるべきだ。どのシステムがRSAや楕円曲線暗号に依存し、どのデータを何年守る必要があり、どの製品が暗号アジリティを持つのかが分からなければ、移行計画も立たない。

まとめ：防御側の制約を、弱点のままにしない

AIが攻撃の主体に近づき、外部の攻撃者は最新のモデルと無制限のトークンを使える。ガイドラインと予算の制約の中で一世代前のAIを使う守る側が、同じ土俵で競っても勝ち目はない。

だから守り方を変える。入られても、すぐ見つけて潰す。盗まれても、読ませない。そもそも、一か所に集めない。そして、全部を一度にやろうとせず順番を決め、足りない手を防御側に投入した高度なAIで補う。

「AIを制限すること＝安全」という発想だけでは、守る側の制約は弱点のまま残る。権限と検証の仕組みを整えたうえで、躊躇なく防御側のAI能力を引き上げること。それ自体が、これからのセキュリティ政策である。

AI時代の安全保障で問われるのは、誰が最も賢いモデルを持つかだけではない。誰が、そのモデルを最も速く、狭い権限で、検知と復旧まで含む仕組みにできるかである。

情報ソース：