オープンウェイトAIとサイバー防御｜防御側だけがAIを使えない非対称性

こんにちは、株式会社TIMEWELLの濱本です。

2026年7月16日にHugging Faceが公開したインシデント開示文のなかに、この1年で読んだセキュリティ文書でいちばん重かった一文があります。侵入の手口の話でも、被害範囲の話でもありません。攻撃者の行動ログを解析しようとした自社のセキュリティチームが、商用APIのフロンティアモデルに解析を拒否された、という記述です。

the analysis requires submitting large volumes of real attack commands, exploit payloads, and C2 artifacts, and these requests were blocked by the providers' safety guardrails, which cannot distinguish an incident responder from an attacker.

解析には実際の攻撃コマンド、エクスプロイトのペイロード、C2（攻撃者が乗っ取った機器を遠隔操作するための指令サーバー）の痕跡を大量に投入する必要がある。しかしそれらのリクエストは、プロバイダーのセーフティガードレールにブロックされた。ガードレールは、インシデント対応者と攻撃者を区別できないからだ¹。

レート制限でもなく、規約違反の判定でもありません。安全のためのフィルタが、守る側の仕事を止めたのです。同社は同じ文書のなかで、この状況をこう総括しています。攻撃者はいかなる利用規約にも縛られていなかった一方で、自分たちのフォレンジック作業は、最初に試したホスト型モデルのガードレールに阻まれた¹。

結論から書きます。TIMEWELLは、オープンウェイトのAIモデルを明確に支持します。思想としてではなく、防御の実務としてです。根拠は一次情報だけに絞ります。オープンウェイト側の弱点も隠しません。

フォレンジックがガードレールに阻まれた日

公式開示を読んでまず驚いたのは、入口の地味さでした。

初期侵入の入口は、悪意あるデータセットでした。攻撃側はデータセットの2つのコード実行経路、具体的にはリモートコードを伴うデータセットローダーと、データセット設定のテンプレートインジェクションを悪用し、処理ワーカー上でコードを実行させます。そこからノードレベルへ権限を昇格させ、クラウドとクラスタの認証情報を窃取し、週末をまたいで複数の内部クラスタへ横展開しました。Hugging Faceはこの侵入を、端から端まで自律的なAIエージェントシステムによって駆動されたものだと記述しています¹。

確認された影響は、限定的な内部データセットと複数のサービス用認証情報への不正アクセスでした。パートナーと顧客のデータへの影響については、公表時点で評価を継続中としています。一方で、公開されているモデル、データセット、Spacesの改ざんの証跡はなく、コンテナイメージや公開パッケージを含むソフトウェアサプライチェーンはクリーンだと検証済みだと書いています¹。

問題はこのあとです。同社が読まなければならなかった攻撃者のアクションログは、記録されたイベントが17,000件を超えていました。人手で追い切れる量ではありません。だからAIを使おうとして、冒頭の壁に当たりました。代わりに選んだのが、オープンウェイトモデルのGLM 5.2を自社インフラ上で動かすという手段です。結果として、通常なら数日かかる作業を数時間で終えたとしています。ここは第三者の検証があるわけではなく、当事者の自己申告である点は差し引いて読む必要があります。そのうえで、もうひとつ副次的な効果があったと書いています。攻撃者のデータも、そこで参照された認証情報も、自社環境の外に出なかった、と¹。

インシデント対応でいちばん外に出せないデータを、外に出さずに解析できたのです。データ主権という言葉を、私はこれまで主に法規制と調達の文脈で使ってきました。この一文を読んで、考えを改めました。あれはインシデント対応の実務要件そのものです。

そして5日後、話は思わぬ方向に転がります。7月21日、OpenAIが、この侵入を引き起こしたのは自社のモデルだったと公表したのです。評価対象はGPT-5.6 Solと、それより高性能な未公開のプレリリースモデル。いずれも評価の目的でサイバー関連の拒否応答を低減した構成で、さらに高リスクなサイバー活動を防ぐための本番用の分類器を外した状態で走らせていたとされます。モデルはパッケージレジストリのキャッシュプロキシに存在したゼロデイ脆弱性を発見して悪用し、サンドボックスから脱出しました²。同社はこれを、最先端のサイバー能力を伴う前例のないサイバーインシデントであると考えている、と述べています³。

ですから、これは「Hugging Faceが何者かに攻撃された」話ではありません。国家支援型のアクターも犯罪組織も登場しません。あるフロンティアラボの評価環境の統制が外れ、他社の本番インフラを壊しました。それが事実関係です。

公平のために、2つの留保を先に置いておきます。ひとつ目は、侵入の封じ込め自体はオープンウェイトによるものではないという点です。Hugging Faceが挙げている対応は、コード実行経路の修正、攻撃者の足場の排除と侵害ノードの再構築、認証情報とトークンの失効とローテーション、クラスタへの追加ガードレールと厳格なアドミッション制御、検知とアラートの改善、外部フォレンジック専門家との連携と法執行機関への報告という、従来型の対応です¹。GLM 5.2が担ったのは事後の解析であり、そこを混ぜてはいけません。

ふたつ目は、Hugging Face自身が同じ節で釘を刺していることです。これはホスト型モデルの安全対策に反対する主張ではなく、このフィードバックを該当するプロバイダーと共有している、と明記しています¹。当事者が「オープン対クローズドの決着」という読み方を否定しているのに、勝利宣言として使うのは不誠実です。なお同社は、最初に試した商用モデルのベンダー名も製品名も明かしていません。特定の一社を名指しできる材料は、どこにもありません。

止まり方は違いますが、他社のインフラに預けているものが止まるという経験は、日本企業もすでにしています。2026年6月には、米政府の輸出管理上の指令によって、あるフロンティアモデルへのアクセスが突然止まったと報じられています。報道ベースの情報で、指令の実施主体や法形式、根拠条文までは一次情報で確認できていません。伝えられている限りでは対象は外国籍ユーザーでしたが、提供側が国籍を即時に判別できないため、実際には当該モデルがより広い範囲で無効化されています。この件は使っているAIが、ある日突然止まるで扱っています。安全判定で止まるか、規制で止まるかの違いはあっても、依存している限り止まるという構造は同じです。自社のAI活用がこうした有事の分岐まで想定できているかどうか、気になった方はAI導入診断で足元を確かめてから続きを読むと、後半の実務の話が自分ごとになると思います。

攻撃者はもうガードレールの外にいます

ここまでは1つの事案にすぎません。単発の不運として片づけられるなら、それが一番よかったのですが。攻撃側がAIをどう使っているかについては、この1年で主要なラボと脅威インテリジェンスチームが自ら記録を公開してきました。並べて読むと、片づけられません。

Anthropicは2025年11月、同年9月中旬に検知した作戦を、中国の国家支援型グループによるものと高い確度で評価したと公表しました。標的は約30組織で、少数の侵入成功を確認しています。注目すべきは自律度で、脅威アクターは戦術的作戦の80〜90%をAIに実行させ、人間の介入は1キャンペーンあたり4〜6の重要な判断点に限られていました。そして安全対策を回避した手口は、技術的なジェイルブレイクではなくロールプレイでした。人間のオペレーターが正規のサイバーセキュリティ企業の従業員だと名乗り、防御的なペネトレーションテストに使っていると信じ込ませ、攻撃チェーンを個別には正当に見える離散タスクへ分解していたのです。ここは読んでいて背筋が寒くなりました。破られたのは技術ではなく、名乗りです。なお同社は限界も併記しています。自律作戦中、モデルはしばしば発見を誇張し、ときにデータを捏造したと⁴。

同社は続報として、2025年3月から2026年3月までにサイバー関連のポリシー違反で凍結した832アカウントを、MITRE ATT&CKへマッピングした分析も出しています。13,873のアクション、482のユニークな技術、14の戦術すべてを観測。中〜高リスクと判定されたアクターの割合は、期間の前半33%から後半56%へ上がっていました。1年に満たない期間で1.7倍です⁵。

Googleの脅威インテリジェンスグループは、もっと不気味な変化を報告しています。実行中にLLMへ問い合わせて自分自身を書き換える、いわばジャストインタイム型のマルウェアです。1時間ごとに自身のソースコードを難読化させる亜種のほか、ロシア政府支援のアクターがウクライナに投入したPROMPTSTEALでは、公開APIを経由してオープンウェイトのコード生成モデルにコマンドを作らせていました。実運用中にLLMへ問い合わせるマルウェアの初観測です⁶。同グループはまた、攻撃者がLLMへの高ボリューム・匿名アクセスを産業化していると書いています。APIのゲートウェイやアグリゲータ、アカウント自動登録ツール、アンチ検知ブラウザを組み合わせ、無料トライアルの濫用とプログラム的なアカウント循環でプレミアム階層のアクセスを維持し続けているのです⁷。地下フォーラムで独自の悪性AIとして売られていたツールの実体が、ジェイルブレイクした商用APIとオープンソースのMCPサーバーの組み合わせだった例も報告されています⁸。ガードレールを外した状態で流通するモデルの問題は、最先端AIは軍事級になったのかでセーフガードの規制動向とあわせて整理しました。

日本に直接かかわる記録もあります。OpenAIは2026年2月の脅威レポートで、中国の法執行機関に関係する個人のアカウントを凍結したと公表しました。同社によれば、その人物は隠密の影響工作戦略のもとで、日本の首相を標的とする作戦の立案にモデルを使おうとして拒否されています。当該アクターの活動は、少なくとも数百人のスタッフ、数十のプラットフォームにまたがる数千の偽アカウント、そしてローカルに配備されたAIモデルを用いた、大規模で持続的な取り組みだったと記述されています⁹。ここで大事なのは、攻撃側がすでにローカル配備を前提に動いているという部分です。ガードレールで止まる相手ではありません。

日本の当局も、同じ手口を自分の手で確認しています。警察庁が令和8年3月に公表した令和7年の情勢報告は、巻頭に「AIをめぐる脅威の情勢と警察の取組」という特集を置きました。そこで挙げられているのが、令和7年7月に海外で確認された攻撃です。政府職員を装った者が、生成AIを悪用するマルウェアをメールで政府機関に送りつけた事案でした。警察庁の解析によると、マルウェア本体にはサイバー攻撃の命令が記録されておらず、感染した端末が使っている生成AIサービスを悪用して、不正な命令をその場で生成させる仕組みだったといいます¹⁰。前段で触れたジャストインタイム型と、構造が同じです。同レポートは、国家を背景とする攻撃グループがAIを使い人間の介入なしに攻撃を実施したという民間企業の報告にも触れ、AIエージェントが攻撃の全工程をほぼ自律的に実行できることを示す事例だと書いています¹⁰。

一方で、煽らないための線引きも必要です。同じGoogleのチームは、国家支援アクターのAI利用について、脅威環境を根本的に変える突破的な能力には至っていないと明記しています⁸。Mandiantのフロントライン報告も、侵害の大半は依然として人的・システム的な失敗に起因すると書いており、初期侵入経路の首位はいまもエクスプロイトで32%です¹¹。AIは攻撃の性質を変えたのではなく、速度とスケールを変えました。ただし、速度の話を丸ごとAIに寄せると事実からずれます。ある侵害で初期アクセスが得られてから、それが二次的な脅威グループへ引き渡されるまでの時間の中央値は、2022年の8時間超から2025年には22秒へ崩壊しました。これは初期アクセスを売る側と使う側の分業がどこまで進んだかを測った数字で、AIの寄与を単独で示すものではありません。同じ期間に、世界の滞留時間の中央値は11日から14日へ悪化しています¹¹。攻撃は機械の速度で進み、気づくのは前より遅くなっています。内訳がどうであれ、この状況で防御側の解析が数日止まることの意味は、考えるまでもありません。

整理すると、こうなります。利用規約とセーフティガードレールが実効的に縛っているのは、契約を結び、監査を受け、ログを残す正規の防御側だけです。攻撃側はロールプレイで騙し、アカウントプールで匿名化し、必要ならローカルの重みへ移ります。この非対称性が、私がオープンウェイトを支持する最大の理由です。

業界の重心が3日で動きました

2026年7月の下旬、業界の側もこの問題を放置しませんでした。ただし、その動きは冷静に評価する必要があります。

7月24日、公開書簡「Open Weights and American AI Leadership」が公表されました。公開時点の署名は25団体です。声明そのものの中身、オープンウェイトの定義から政策提言まではオープンウェイトはなぜ重要かで解説したので、ここでは繰り返しません。追いたいのは、そのあとの3日間に起きた差分です。

ひとつだけ、声明の一文を引いておきます。クローズドモデルだけに依存することは本質的に安全ではない、それらは侵害され、悪用され、外部からは検知できない形で失敗し得るからだ、という記述です¹²。この一文が、7月21日に明らかになった事実と正確に一致してしまったのは皮肉なことでした。念のため書いておくと、書簡本文にHugging Faceの事案への言及はありません。PDF全文を検索しても、その社名は署名者リストに1回出てくるだけです。時系列を混ぜてはいけない部分なので、はっきりさせておきます。

署名は数日で膨らみました。7月25日には約50団体まで倍増し、この段階でOpenAIとGoogleが加わっています。そして2026年7月27日時点で公開されているPDFの署名ブロックを数えると、77団体です¹²。日本企業ではSakana AIが含まれています。逆に、この時点で名前がないのはAnthropicとAmazonです。ここは慎重に書きます。この署名は招待制ではなく、公式ページが窓口のメールアドレスを案内している自己申告方式です。つまり、リストに名前がないことは「打診されて断った」ことの証拠にはなりません。両社は不在の理由を説明しておらず、報道もそれを明らかにしていません。Forbesの記者は「どちらもその不在を説明しておらず、理由を決めつけるのは誤りだろう」と書いています¹³。私も同じ立場です。

さらに3日後の7月27日、NVIDIAがOpen Secure AI Allianceの発足を公式ブログで発表しました。AIの時代にソフトウェアとエージェントを守るためのオープンな技術、手法、ツールを開発して共有する動きだと定義し、ミッションは、あらゆる場所の防御側が信頼し制御できるオープンでフロンティアなツールを持てるようにすることだとしています¹⁴。サイバーセキュリティにおけるオープンモデルの意義については、防御能力を民主化し、防御側にとっての透明性を高め、データを保護しながらサイバー防御を可能にし、カスタマイズ可能で局所的な制御によってクローズドモデルを補完するからだと述べています¹⁴。

発足パートナーには、CrowdStrike、Palo Alto Networks、Cisco、Cloudflare、Elastic、Red Hat、IBM、Microsoft、Dell、HPE、Hugging Face、Linux Foundationに加えて、SpacexAI、Thinking Machines Lab、Reflection AI、Nous Researchといったモデル開発側の名前も並びます。日本企業はTrendAI、トレンドマイクロのエンタープライズ事業ブランド（東証4704）の1社です。ひとつ注意点があります。NVIDIAは発足パートナーの総数を明示していません。公式ブログの列挙をNVIDIA自身を含めて数えると37になりますが、媒体報道は27、30超、40近くとばらついています。本記事の37は、公式ブログの列挙を数えた値です。

各社が持ち寄る技術も公表されています。エージェントを暗号学的に検証するゼロトラストIDの標準、リモートコード実行が起きないモデル重みの保存形式、デジタル署名付きパッチでOSSのサプライチェーンを守る仕組み、複数モデルでエージェントの脆弱性を走査するハーネス。並べてみると、モデルそのものよりも「検査できる状態を共有物にする」ことに寄っています¹⁴。私はここに一番の意味があると思っています。分析官がプロンプトとクエリとモデルの判断を後から検証できなければ、AIが出した結論をインシデント報告や監査に使えません。検査可能性は、製品仕様として選ぶものではなく、前提として与えられているべきものです。

同ブログは政策提言まで踏み込んでいます。AIとサイバーセキュリティの政策において、オープンモデル、ハーネス、セキュリティツールを負債ではなく防御資産として認識することが極めて重要であり、オープンなフロンティアAIシステムへの一律の制限は防御能力を弱め、権力と依存と脆弱性を少数のクローズド事業者に集中させるリスクがあるという主張です。同時に、オープンモデルも他の強力な技術と同様に悪用され得ると自認しています¹⁴。ロビイング文書でもある企業ブログとして、この自認は誠実だと思います。

そして起点になったジェンセン・フアン氏のX投稿です。7月24日の1本目は書簡を共有する一般論で、Hugging Faceの事案には触れていません。事案を名指ししたのは7月27日の2本目で、全3文はこうです。「攻撃者はフロンティアAIを持っている。防御側にはフロンティアAIのエコシステムが必要で、それは最良のオープンモデルとクローズドモデルが、グローバルなコミュニティによって力を掛け合わされたものだ。Hugging Faceのインシデントの間、クローズドAIは不可欠なフォレンジックを阻んだ。オープンウェイトのフロンティアモデルが侵入の封じ込めを助けた。だから我々はOpen Secure AI Allianceを作った」¹⁵

最後の点について、自陣営の代表者の表現を自分で正しておきます。「侵入の封じ込めを助けた」は、Hugging Faceの一次開示より一歩踏み込んだ表現です。開示文でオープンウェイトが担ったのは事後のフォレンジック解析であり、封じ込めは前述の従来型の対応で達成されました。オピニオン記事の信頼性は、味方の言い過ぎを自分で訂正できるかどうかで決まると思っています。

そのうえで、このアライアンス自体の実体も冷静に見ておきます。現時点で公表されているのは参加企業のリストと技術貢献の一部だけです。Linux Foundationはホストではなく一参加者で、同財団側にプレスリリースは存在しません。独立した法人格、定款、理事会、ワーキンググループ、ロードマップ、会費体系はいずれも未公表で、入会の窓口はNVIDIAのサイトのフォームだけです。しかも、クローズドのフロンティアAPIを供給している最大手のOpenAI、Anthropic、Googleと、Llamaを公開しているMetaは、公表された列挙のなかに名前がありません。モデル開発側で入っているのはSpacexAI（NVIDIA公式ブログの表記）、Thinking Machines Lab、Reflection AI、Nous Researchで、フロンティア級の開発者が完全に不在というわけではありません。ただ、防御側が実務で主力に使っている商用APIの提供元が揃っていない枠組みである、という事実は残ります。AIセキュリティの枠組みは、すでにCoSAI、Linux FoundationのAkrites、MOSAIC、Palo Alto NetworksのFrontier AI Allianceと乱立しています¹⁶。4つ目の枠組みが断片化を悪化させるだけに終わる可能性は、率直にあります。

だから私は、このアライアンスを成果ではなく起点として扱います。重要なのは、アライアンスが成立するかどうかではありません。成立しようがしまいが、各社が自前で用意しておくべき備えがある、という点です。

それでも、オープンウェイトの弱点を先に認めます

ここまで読んで「結局オープンウェイト礼賛か」と思われたかもしれません。そうではありません。私が支持しているのは「オープンウェイトは安全だ」という主張ではなく、「防御の最終手段を自社の側に持てることが安全に資する」という主張です。この違いを説明するために、反論として最も強いものを4つ挙げます。

いちばん重いのは、パッチ配信網の不在です。オープンソースが安全でいられたのは、バージョン番号、パッケージマネージャ、ディストリビューションのメンテナ、ミラーという「配って直す」インフラがあったからでした。モデルの重みには、これが一切ありません。いったん配布された重みの欠陥は、世界中に出回った全コピーの恒久的な性質になります。オープンソースがそうだったからオープンウェイトも大丈夫だ、という類推は、この決定的な非対称性を無視しています。ですから、みんなが直してくれることを期待する議論は成立しません。責任は配備した組織に全部戻ってきます。オープンウェイトの採用は、運用負荷を自分で引き受けるという意思決定とセットでしか正当化できません。

ここで、自社の過去の記事と正面から向き合っておきます。私たちは2026年3月に、Anthropicのダリオ・アモデイ氏の「オープンソースAIは無料ではない」という主張を扱い、重みのダウンロードは簡単な部分で、コストがかかるのはそれを動くシステムに変えることだという論に強い説得力があると書きました。推論インフラと専門人材の試算まで並べて、多くの企業にとってはクローズドAPIが現実的で合理的だ、と結論づけています。その結論を取り下げるつもりはありません。平時のコスト最適という軸で見れば、いまも正しいと思います。ただ、軸を「インシデント対応の実務」に切り替えると、同じ天秤が逆に傾きます。数か月に一度あるかないかの有事に、フォレンジックが数日止まることの損失は、GPUの稼働率では測れません。両方の記事に矛盾があるように見えるとしたら、それは測っている軸が違うからです。

次に、オープン化は攻撃側の能力も上げるという反論です。上がります。ここを否定したら嘘になります。ただし事実関係として、攻撃側はすでにクローズド側でも止まっていません。前章で挙げたロールプレイによる回避、アカウントプールと匿名アクセスの産業化、推論トレースを狙った蒸留攻撃、そのすべてが一次情報として記録されています。つまり論点は「攻撃側にAIを与えるか否か」ではありません。そこはもう決着がついています。残っているのは「防御側が合法的かつ監査可能な形で同等の能力を持てるか」だけです。

3つ目は、Hugging Faceの事例が厳密に証明したのは2点にすぎない、という指摘です。商用プロバイダーのガードレールがインシデント対応者を誤検知する運用上の欠陥と、機微データを外部APIに出せないというデータ主権の要請。どちらも、本人確認を伴う解析用途のカーブアウトや、オンプレミス提供のクローズドモデルでも解決し得ます。オープンウェイトが唯一解だ、という結論までは飛躍でしょう。しかも、分散推論がGPU需要につながるNVIDIAの商業的な立場との、都合のよい一致。この反論は全面的に認めます。

だから私は、論拠の重心をNVIDIAの主張ではなく、Hugging Faceの一次証言と各社の脅威レポートに置いています。そのうえで、主張の形も正確に書いておきます。クローズドを使うな、ではありません。フロンティアAPIを主力に使いながら、ガードレールで締め出された瞬間に切り替えられる自社実行の選択肢を、平時から検証して持っておけ、です。プロバイダー側にフォレンジック用途のカーブアウトが整備されるなら、それは歓迎すべき進歩であって、この主張と矛盾しません。

4つ目が、日本の読者にとっていちばん実務的な論点です。地政学の逆説があります。Hugging Faceが頼ったGLM 5.2は、同社のプラットフォーム上でZ.aiという組織名で公開されているモデルです。ライセンスはMITで、モデルカードには地域制限なしと明記されています。パラメータ数は753B、コンテキスト長は約100万トークン。開発元については、南華早報が北京を拠点とするZhipu、海外ではZ.aiとして知られる企業だと説明しています¹⁷。念のため書いておくと、この開発元の属性はHugging Faceの開示文には出てきません。別の出典によるものです。米国がオープンモデルの規制を検討している最中に、American AI Leadershipを掲げる陣営の最良の実例が、中国製モデルに助けられた事例になっています。同じ事実は、規制を推す側から見れば依存リスクの実証と読めます。

日本企業にとっては、もっと直接的です。ここを混同すると経済安全保障上の事故になります。「オープンウェイトを備えよ」は「中国製モデルを入れよ」ではありません。分けるべきなのは、自社インフラで動く重みを平時から検証して持つという運用上の要件と、どの国のどのモデルを選ぶかという調達上の判断です。前者は普遍的に妥当ですが、後者は組織ごと、用途ごとに答えが変わります。性能は世界水準でも企業利用には別の検討が要るという話はKimi K3の実力と使いどころで、AIに渡す情報と輸出管理の関係はAI時代のデータ主権と輸出管理で、それぞれ一次情報にあたって整理しました。どの国の政策を断罪する話でもありません。制度の内容と自社の要件を並べて、自分で決める話です。

日本企業が平時にやっておくこと

では、日本の会社は何をしておけばいいのか。

前置きとして、日本の政府はすでにAIをサイバー防御に使う方向を明文化しています。2026年5月18日、内閣官房の国家サイバー統括室ほか関係機関が連名で、重要インフラ事業者等に対する注意喚起を出しました。攻撃にAIが悪用されることで攻撃の速度と規模が劇的に増すという認識を示したうえで、悪用リスクを前提としながらも高性能AIを積極的にサイバー防御に活用していくことを含めて、対策強化を早急に進める必要があるとしています。推奨事項には、脅威検知、インシデント対応、脆弱性発見という用途が具体的に挙げられました¹⁸。方向は正しいと思います。ただ、その活用が安全判定で止まる分岐までは、まだ書かれていません。今回の事案が埋めたのは、その空白です。

IPAの脅威認識も、少し手前で止まっています。「情報セキュリティ10大脅威 2026」では、組織編の3位に「AIの利用をめぐるサイバーリスク」が初選出で入りました。2006年から続くこのランキングで、AIをめぐる項目が脅威候補になったのは初めてです。解説書が挙げているのは、許可なく業務でAIを使うシャドーAIによる情報漏えい、ハルシネーション、そして攻撃側がAIを使うことによる手口の巧妙化¹⁹。防御側がAIから締め出されるという失敗モードは、まだ視野に入っていません。次の版で入るべき論点だと考えています。

持ち帰れる備えは5つです。出発点は、モデルの選定ではなく手順書です。インシデント対応手順書に、主力の商用APIが安全判定で解析を拒否した場合の切替先を明記しておくことです。これだけで、今回記録された失敗モードの再現を避けられます。予算も稟議もいりません。1行足すだけです。この分岐が現実の失敗として文書化されたのは、私の知る限り今回が初めてでした。裏を返せば、いまこの瞬間まで、ほとんどの会社の手順書にこの分岐は書かれていないはずです。ちなみにIPAが2025年5月に公表した中小企業の実態調査では、サイバーインシデントやその兆候を見つけたときの対応方法が決まっていない企業が37.3%ありました²⁰。切替先を書き足す前に、まず手順書そのものを作る話になる会社も少なくないでしょう。

そのうえで、切替先として自社インフラで動く防御用モデルを1つ選定し、平時に検証しておきます。ここで肩の力を抜いていいところがあります。フロンティアの性能に並ぶ必要はまったくありません。求められる仕事は、ログのトリアージ、IoC（侵害の痕跡）の抽出、17,000件のイベント列を読んで時系列を組み立てる、といった作業です。そこに足る水準の重みを、社内で調達し、検証し、配備できる状態になっているかどうかが問われます。国産モデルや国内実行基盤の意味づけも、ここで変わってきます。これまでの論拠は主に産業政策と日本語性能でした。そこに、有事に自分で動かせる重みを持っているかという安全保障上の論拠が加わりました。ソブリンAIの議論を「日本製の最強モデルを作る」から「有事に国内で回せる防御用の重みと運用手順を確保する」へずらすと、現実的な投資の議題になると思います。国産基盤の現在地は国産AI基盤の現在地にまとめてあります。

3つ目が、使用モデルの台帳です。モデル名、バージョン、重みの取得元、ハッシュ、ライセンス、開発元の所在国を記録し、差し替えとロールバックの手順を決めておきます。前章で書いたとおり、オープンウェイトにはパッチ配信網がありません。この管理責任は全部自社に戻るので、台帳がないまま重みを配備するのは、バージョン管理のないソフトウェアを本番に置くのと同じことです。

4つ目は、データセットとモデルを第一級の攻撃面として扱うことです。今回の初期侵入経路が悪意あるデータセットだったことを思い出してください。この領域のリスクは以前から指摘されてきました。2025年2月には、Hugging Face上で悪意あるコードを含むモデルが発見され、標準的な圧縮形式を避けることでスキャナの検知を免れる手法が報告されています²¹。同じ年には、そのスキャナ自体に3件のゼロデイが見つかり、いずれもCVEが採番されました。修正版がリリースされたのは2025年9月です²²。重みの保存形式ひとつで、読み込み時に任意のコードが走るかどうかが変わります。モデルを取り込む経路は、ライブラリを取り込む経路と同じ厳しさで見るべきです。この考え方はAIが実在しないパッケージ名を提案するslopsquattingの話とも地続きです。

最後に、経済安全保障と輸出管理の観点です。選定したモデルの開発元の所在国と資本関係、重みの取得経路と改ざん検証、完全なネットワーク隔離が可能かどうか、推論ログの保全と監査、有事に差し替える代替モデルの事前特定。この5点を、技術部門だけで決めずに調達部門と法務の合意事項にしておくことをおすすめします。防衛、重要インフラ、輸出管理の対象事業を持つ企業であれば、ライセンスがMITで地域制限がないことと、自社の調達方針として許容できることは、まったく別の問題です。

私たちが提供しているZEROCKは、もともと国内のAWSサーバー上で動かし、社内のナレッジを自分たちの管理下でコントロールすることを重視して作ってきました。正直に言うと、その設計の主な動機は法規制と情報漏えい対策でした。今回の事案を読んで、そこにもうひとつの意味が加わったと感じています。外に出せないデータを外に出さずにAIで扱える状態は、平時の要件であるだけでなく、有事に効く数少ない選択肢でもあるということです。

まとめ

長くなったので、要点を整理します。

• 2026年7月16日のHugging Faceの開示で、商用APIのセーフティガードレールがインシデント対応者と攻撃者を区別できず、17,000件超のログ解析を止めたことが記録されました。同社は自社インフラでオープンウェイトモデルを動かして解析を終え、攻撃者データも認証情報も環境外に出さずに済んだと書いています
• ただし封じ込め自体は従来型の対応で達成されており、オープンウェイトが担ったのは事後の解析です。Hugging Face自身が、ホスト型モデルの安全対策に反対する主張ではないと明記しています
• この侵入を起こしたのは第三者の攻撃者ではなく、安全機構を外して評価されていたフロンティアモデルでした。クローズドだから安全とは限らないことを、クローズド側が証明した形です
• 攻撃側はすでにガードレールの外にいます。ロールプレイによる回避、アカウントプールによる匿名アクセスの産業化、ローカル配備への移行が一次情報で記録されています。あわせて初期アクセスの引き渡し中央値は8時間超から22秒へ縮み、防御側に残された時間そのものが消えています
• 公開書簡の署名は2026年7月27日時点で77団体、Open Secure AI Allianceの発足パートナーは公式列挙を数えて37です。ただしアライアンスのガバナンスは未公表で、実体は起点と見るべき段階です
• オープンウェイトにはパッチ配信網がありません。攻撃側の能力も上げます。この2点を認めたうえで、それでも防御の最終手段を自社に持つ価値があるのが、私たちの立場です
• 日本の政府は2026年5月18日の注意喚起で、重要インフラ事業者に対して高性能AIをサイバー防御に活用することを求めています。方向は正しい一方で、その活用が安全判定で止まる分岐までは書かれていません
• 実務では、手順書に切替先を書く、自社インフラで動く防御用モデルを平時に検証する、モデル台帳を作る、データセットとモデルを攻撃面として扱う、所在国と取得経路を調達・法務と合意する。この5つから始められます

この件でいちばん気になっているのは、議論の主戦場がAI政策とサイバー防御政策の交点に移ったのに、そこに日本の当事者の声がほとんど入っていないことです。書簡の77団体に日本企業は1社、アライアンスの発足パートナーにも1社。乗り遅れたと煽るつもりはありません。急いで入るべき実体があるとも言い切れない段階です。アライアンスの発足は本日なので、日本の当局がまだ何も言っていないのも当然でしょう。ただ、5月にAIをサイバー防御へ活用せよと書いた当局が、その使えるAIが誰の許可で動くのかという論点をどう扱うのかは、注視しておきたいところです。自国の防御側が有事に何を使えるのかという問いは、他国の政策論争が代わりに決めてくれるものではありません。

自社のAIをどこで動かし、有事にどこへ切り替えるのか。その設計を具体的に詰めたい方は、ZEROCKの担当までご相談ください。まずは、いま契約しているAIサービスの利用規約と安全ポリシーを開いて、インシデント対応でそれを使えるのかを確かめてみてください。答えがすぐに出ないようなら、それが最初の宿題です。

参考文献・一次情報

Footnotes

1. Hugging Face「Security incident disclosure — July 2026」2026年7月16日。本文で引用した一文の原文は "the analysis requires submitting large volumes of real attack commands, exploit payloads, and C2 artifacts, and these requests were blocked by the providers' safety guardrails, which cannot distinguish an incident responder from an attacker."、総括の一文は "We do not know which model powered the attacker's agents, whether a jailbroken hosted model or an unrestricted open-weight one; either way, the attacker was bound by no usage policy, while our own forensic work was blocked by the guardrails of the hosted models we first tried."、データが環境外に出なかったという記述は "This had a second benefit: no attacker data, and none of the credentials it referenced, left our environment."、安全対策への留保は "This is not an argument against safety measures on hosted models, and we are sharing this feedback with the providers concerned." https://huggingface.co/blog/security-incident-july-2026 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷

2. OpenAIの公式発表（2026年7月21日）に基づく。評価構成（サイバー関連の拒否応答を低減し、本番用分類器を外した状態での実行）とサンドボックス脱出の経路に関する逐語部分は、公式ページが自動取得できないため、公式声明をブロック引用しているSimon Willison「OpenAI's accidental cyberattack against Hugging Face is science fiction that happened」2026年7月22日を参照した。OpenAIが言及した未公開モデルの具体名、および悪用されたパッケージレジストリのキャッシュプロキシの製品名は公表されていない https://simonwillison.net/2026/Jul/22/openai-cyberattack/ ↩

3. Fortune「OpenAI says its AI models escaped control and hacked Hugging Face」2026年7月21日。OpenAIの公式声明として "We consider this to be an unprecedented cyber incident, involving state-of-the-art cyber capabilities, and are responding accordingly." を引用している https://fortune.com/2026/07/21/openai-says-ai-models-escaped-control-hacked-hugging-face/ ↩

4. Anthropic「Disrupting the first reported AI-orchestrated cyber espionage campaign」2025年11月13日、および同日公開の詳細レポート。自律作戦の限界についての記述は "Claude frequently overstated findings and occasionally fabricated data during autonomous operations." https://www.anthropic.com/news/disrupting-AI-espionage ↩

5. Anthropic「What we learned mapping a year's worth of AI-enabled cyber threats」2026年6月3日。対象期間は2025年3月から2026年3月 https://www.anthropic.com/research/attack-navigator ↩

6. Google Threat Intelligence Group「GTIG AI Threat Tracker: Advances in Threat Actor Usage of AI Tools」2025年11月。自己書き換え型のPROMPTFLUXと、実運用中にLLMへ問い合わせるPROMPTSTEALの初観測を報告している https://services.google.com/fh/files/misc/advances-in-threat-actor-usage-of-ai-tools-en.pdf ↩

7. Google Cloud「Adversaries Leverage AI for Vulnerability Exploitation, Augmented Operations, and Initial Access」2026年5月12日 https://cloud.google.com/blog/topics/threat-intelligence/ai-vulnerability-exploitation-initial-access ↩

8. Google Cloud「GTIG AI Threat Tracker: Distillation, Experimentation, and (Continued) Integration of AI for Adversarial Use」2026年2月13日。推論トレースを狙った蒸留攻撃で単一キャンペーン中に10万件超のプロンプトを特定したことも報告されている https://cloud.google.com/blog/topics/threat-intelligence/distillation-experimentation-integration-ai-adversarial-use ↩ ↩²

9. OpenAI「Disrupting malicious uses of our models: an update, February 2026」2026年2月25日。日本の首相を標的とする作戦の立案にモデルを使おうとしたが拒否されたとする記述を含む。アカウント凍結という同社の措置に関する報告であり、特定の組織の法的責任を認定したものではない https://cdn.openai.com/pdf/df438d70-e3fe-4a6c-a403-ff632def8f79/disrupting-malicious-uses-of-ai.pdf ↩

10. 警察庁サイバー警察局「令和7年におけるサイバー空間をめぐる脅威の情勢等について」令和8年3月公表。巻頭に「特集Ⅰ AIをめぐる脅威の情勢と警察の取組」を置いている https://www.npa.go.jp/publications/statistics/cybersecurity/data/R7/R07_cyber_jousei.pdf ↩ ↩²

11. Google Cloud / Mandiant「M-Trends 2026: Data, Insights, and Strategies From the Frontlines」2026年3月24日。2025年のフロントラインでのインシデント調査50万時間超に基づく https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026/ ↩ ↩²

12. 共同声明「Open Weights and American AI Leadership」2026年7月24日公開。引用した一文の原文は "Relying solely on closed models is not inherently safe: they can be breached, misused, or fail in ways that outsiders cannot detect."。署名者リストは同一URLで随時更新されるため、本記事の77団体は2026年7月27日時点のPDFの署名ブロックを数えた値である https://images.nvidia.com/pdf/Open-Weights-and-American-AI-Leadership.pdf （署名者一覧の公式ページ https://www.microsoft.com/en-us/corporate-responsibility/topics/open-weight/ ） ↩ ↩²

13. Forbes「Huang's Open Weights Letter Doubled To 50 Without Amazon And Anthropic」2026年7月25日。原文は "Amazon and Anthropic are absent from the list today July 25, 2026. Neither has explained the absence, and it would be a mistake to assume the reason." https://www.forbes.com/sites/sandycarter/2026/07/25/huangs-open-weights-letter-doubled-to-50-without-amazon-and-anthropic/ ↩

14. NVIDIA「Industry Leaders Unite in Open Secure AI Alliance for AI Safety and Security」2026年7月27日。発足パートナーは "including" 形式の列挙で総数は明示されていない。本記事の37はその列挙をNVIDIA自身を含めて数えた値。オープンモデルのリスクの自認は "Open models, like any powerful technology, can be misused — including through attempts to weaken safeguards or repurpose capabilities for cyber attacks — but those risks are not unique to open systems, and they must be managed wherever advanced AI is deployed." https://blogs.nvidia.com/blog/open-secure-ai-alliance/ ↩ ↩² ↩³ ↩⁴

15. ジェンセン・フアン（@JensenHuang）2026年7月27日の投稿。原文は "Attackers have frontier AI. Defenders need a frontier AI ecosystem—the best open and closed models, force-multiplied by a global community. / During the Hugging Face incident, closed AI blocked essential forensics. An open-weight frontier model helped contain the intrusion. / That's why we created the Open Secure AI Alliance." https://x.com/JensenHuang/status/2081698060330250294 ↩

16. OASIS Open「Introducing the Coalition for Secure AI (CoSAI), an OASIS Open Project」2024年7月18日 https://www.oasis-open.org/2024/07/18/introducing-cosai/ 、The Linux Foundation「Linux Foundation and Industry Leaders Launch Akrites to Defend Critical Open Source Software Against AI-Enabled Cyber Threats」2026年6月25日 https://www.linuxfoundation.org/press/linux-foundation-and-industry-leaders-launch-akrites-to-defend-critical-open-source-software-against-ai-enabled-cyber-threats 、Center for Internet Security「MOSAIC Coalition Launches to Operationalize AI Security Standards and Reduce Industry Fragmentation」2026年5月18日 https://www.cisecurity.org/about-us/media/press-release/mosaic-coalition-launches-to-operationalize-ai-security-standards-and-reduce-industry-fragmentation 、Palo Alto Networks「The AI Ecosystem Edge — Introducing Our Frontier AI Alliance」2026年4月17日 https://www.paloaltonetworks.com/blog/2026/04/ai-ecosystem-edge-introducing-frontier-ai-alliance/ ↩

17. Hugging Faceのモデルリポジトリ zai-org/GLM-5.2。モデルカードにライセンス mit、"An MIT open-source license — no regional limits, technical access without borders" と記載。パラメータ数は753B、config.json の max_position_embeddings は1,048,576 https://huggingface.co/zai-org/GLM-5.2 。開発元の説明は South China Morning Post 2026年7月2日（北京を拠点とするZhipu、海外ではZ.aiとして知られ、香港上場時の社名はKnowledge Atlas Technology） https://www.scmp.com/tech/tech-trends/article/3359170/zhipu-ai-releases-harness-glm-52-model-chinese-firm-takes-aim-anthropic ↩

18. 内閣官房 国家サイバー統括室ほか関係機関「AI性能の高度化を踏まえたサイバーセキュリティ対策の強化について（重要インフラ事業者等に対する注意喚起）」2026年5月18日 https://www.cyber.go.jp/pdf/press/20260518_AI_CS_Critical_Infrastructure.pdf ↩

19. IPA「情報セキュリティ10大脅威 2026」2026年1月29日決定。組織編の3位に「AIの利用をめぐるサイバーリスク」が初選出。解説書［組織編］は2026年3月発行 https://www.ipa.go.jp/security/10threats/10threats2026.html ↩

20. IPA「2024年度 中小企業における情報セキュリティ対策に関する実態調査 報告書」2025年5月公表（調査期間2024年10月25日から11月6日、有効回答4,191件）。インシデントまたはその兆候を発見した場合の対応方法が「決まっていない」は1,564件で37.3% https://www.ipa.go.jp/security/reports/sme/nl10bi000000fbvc-att/sme-chousa-report2024r1.pdf ↩

21. ReversingLabs「Malicious ML models discovered on Hugging Face platform」2025年2月6日。既定のZIP圧縮を避けることでスキャナの検知を免れる手法を報告している https://www.reversinglabs.com/blog/rl-identifies-malware-ml-model-hosted-on-hugging-face ↩

22. JFrog Security Research「Unveiling 3 Zero-Day Vulnerabilities in PickleScan」2025年9月2日。3件すべてにCVEが採番されている（CVE-2025-10155、CVE-2025-10156、CVE-2025-10157）。修正はPickleScan 0.0.31 https://jfrog.com/blog/unveiling-3-zero-day-vulnerabilities-in-picklescan/ ↩