「AIに断られた」
2026年7月、AIモデルの公開・共有プラットフォームを運営する米Hugging Faceのセキュリティチームが直面したのは、そんな状況だった。
同社が実際にサービスを動かしている基盤にOpenAIのAIエージェントが侵入したため、被害状況を調べようと普段使う商用の最先端AIに攻撃コードの解析を頼んだところ、安全機能が「攻撃の実行」と見なして拒否してしまったのだ。
防御目的の調査であっても、AIの側には攻撃者と防御者の区別がつかず、同社は結局、自社インフラの中だけで動かせるオープンウェイトのモデルに切り替えて、調査を完遂した。
この事案が公になった直後の7月27日、NVIDIAは、AIを狙う攻撃から防御するための技術を各企業が共同で開発・共有する新たな連合「Open Secure AI Alliance（OSAA）」の発足を発表した。
これら一連の事案から読み取れるのは、平時に頼りにしていた防御手段が、有事に使えなくなるかもしれないという問題は、業種や規模を問わず、どの企業にも起こり得ることであり、対策を考えなければならないということだ。
経営として問われるのは、自社がどこに依存し、どこで代替手段を持つかを、平時のうちに意識的に設計しているかどうかだ。
そこで本稿では、Hugging Faceの事案とOSAAの発足の経緯を整理したうえで、この設計の視点から捉え直す。
きっかけとなったHugging Face侵入事案
まずは、Hugging Face侵入事案の背景を押さえておく。
Hugging Faceの公表によると、侵入は7月9日から約4日半にわたって続き、攻撃者による操作の記録は約1万7600件に上った。
同社の技術レポートによれば、攻撃側のAIエージェントは、本来閉じ込められているはずの試験用の隔離環境（サンドボックス）から、ソフトウェアの管理まわりにあった弱点を突いて抜け出した。
そこを足がかりに、Hugging Faceのシステムの弱点を悪用し、本来アクセスできないはずのファイルを読み取ったり、不正なコードを実行させたりしたという。
その結果、外部に公開していない内部データや、システムへのアクセスに使う認証情報の一部が閲覧された。ただし、一般に公開されているAIモデルやデータセット自体が改ざんされた形跡は確認されていない。
この攻撃の主体については、OpenAI自身が公表した報告で、サイバー能力の評価中に、社内専用の研究モデルを中心とする複数のモデルが、インターネットから隔離するための制御を回避し、自社の内部基盤とHugging Faceのシステムに侵入したと認めている。
OpenAIはこれを、AIエージェントが技術的な制御をすり抜け、承認されていない経路で連携し、人間が指示していない危険な行動を取り得ることを示す、いわば「事前の警告」だと位置づけている。
注目すべきは、攻撃の速度と、その後の調査のてん末だ。攻撃側がAIを使ったことで、人間の対応では追いつけないペースで被害が広がった。
Hugging Faceは「機械の速度で攻撃されると、これまで軽視されがちだったありふれた弱点でも、対応が間に合わず、被害や対応コストが一気に膨らむ」と説明している。
そして、その後の調査の場面において、冒頭で触れた「AIに断られる」という事態が起きた。
商用の最先端AIが、攻撃コードの解読を「攻撃の実行と同じもの」として扱い、拒否する場面が繰り返されたのだ。
そこでHugging Faceが選んだのが、GLM-5.2というオープンウェイトモデルだった。
オープンウェイトモデルとは、AIモデルの中身（重み）が公開されていて、誰でもダウンロードし、自社の環境で動かせるモデルのことだ。
今回Hugging Faceは、クラウド上のAPIを外部から呼び出すのではなく、このGLM-5.2の重みを丸ごと自社のサーバーに持ち込んで動かし、その環境だけで攻撃ログの解析を完結させたのだ。
つまり、攻撃の痕跡という機密性の高いデータを、一度も社外に送らずに済んだことになる。
モデルの中身ごと自社で動かせるオープンウェイトだからこそ可能になった、データの持ち出しを避ける選択をとった形だ。
そして、この事案が公になった直後の7月27日に、NVIDIAは事態を受けて「Open Secure AI Alliance（OSAA）」の発足を発表した。次に、その中身を見ていく。
Open Secure AI Allianceとは何か
OSAAは、防御側が最先端級のAI技術を自ら検査・改変し、自社のインフラで運用できるようにすることを目的に、NVIDIAが呼びかけた連合だ。
具体的には、NVIDIA自身が持つAIモデルや計算基盤に、各参加企業のセキュリティ技術を組み合わせ、オープンウェイトモデルを自社のインフラで安全に検査・改変・運用するための土台を提供する。
発表直後の報道ではNVIDIAを含む37社とされ、Microsoft、Cisco、Cloudflare、CrowdStrike、Palo Alto Networks、IBM、Red Hat、Hugging Face、Palantir、SAP、ServiceNowのほか、Linux Foundationなどが名を連ねている。
技術面では、いくつかの具体的な取り組みが示されている。
その一つとして、NVIDIAが公開した研究用フレームワーク「NOOA」が挙げられる。これは、AIエージェントの挙動をテスト・追跡・監査し、統制しやすくするためのものだ。
そのほか、Microsoftによる複数モデル連携の脆弱性スキャン「MDASH」、HPEが取り組むAIエージェント向けのゼロトラストなID検証(SPIFFE/SPIRE)、Hugging FaceのモデルファイルフォーマットSafetensors、IBMとRed Hatによる署名付きパッチ配布の仕組み「Lightwell」などが並ぶ。
一方で、OpenAI、Google、Anthropicは、発足時のメンバーに入っていない。
その理由としては、この3社の最上位モデルは、利用者はモデルの機能を使うことはできても、モデルの中身を検査したり、自社の環境に持ち込んで動かしたりすることはできないからだと考える。
本質は「オープンかクローズドか」ではなく「依存と統制の設計」
Hugging Faceの事件では、モデルの中身が非公開であるモデルが調査を拒否したため、一見「オープンウェイトモデルの方が優っている」ように見えるかもしれない。
しかし、この話を「オープンウェイトモデルの方が優っている」と読むのは早計と言えるだろう。
冒頭で見た、Hugging Faceの調査を安全機能が拒否したAIもモデルの中身が公開されていないものだったが、AIが悪用されないための正当な設計の帰結であり、責められるべきものではない。
モデル中身を非公開のままにしておくクローズドな考え方にも、筋の通った主張がある。
Anthropicは2026年4月に「Project Glasswing」を立ち上げ、AWS、Apple、Google、Microsoft、NVIDIA、Linux FoundationなどAnthropic自身を含む12社を立ち上げパートナーとし、さらに40超の重要ソフトウェア関連の組織に、防御目的での最先端モデル「Mythos Preview」へのアクセスを提供している。
このモデルは一般には提供されず、限られた組織にだけ使わせる「ゲート付き」のアプローチだ。
なお、Anthropicは同じ土台の技術に安全対策を加えた「Fable」というモデルを、商用サービスとして一般にも提供している。
「Fable」はサイバーセキュリティに関わる質問には応じない設計になっており、Glasswingで限定公開されている「Mythos Preview」は、その制限を外した、脆弱性の発見だけでなく攻撃コードの作成までできてしまう、より高性能でリスクの高いバージョンにあたる。
つまり、危険な能力を持つモデルを無制限に広めない、という合理的な考えだ。
そのため、オープンかクローズドかという論争は、どちらが正しいかを決める対立ではなく、防御力を高めるために何を優先するかの違いだ。
OSAAといったオープン側は、自社で検査・運用できる自由度とベンダー依存の低減を重視し、Anthropicなどのクローズド側は、能力の統制と悪用防止を重視している。
経営者にとって重要なのは、自社の業務継続の観点から、どこに依存し、どこで代替手段を持つかを、意識的に設計することだ。
関連記事：
AnthropicやOpenAIのAIが起こした事故に学ぶ、自社点検のための視点
米政府に公開3日で停止されたAI「Claude Fable 5」、その能力と企業が今すぐ動くべき理由とは
OSAAを例にした検証視点
この「意識的な設計」は、心構えだけでは成立しない。
実際に頼ろうとしている選択肢が、何を提供し、どこに限界があるのかを一つひとつ具体的に検証して初めて、依存先と代替手段の見取り図が描ける。
ここでは、その検証作業の一例として、OSAAを実際に点検してみる。日本企業がOSAAを判断材料にする際は、少なくとも次の4つの懸念点を踏まえておく必要がある。
「新しい技術」というより「既存資産の再パッケージ」という面がある
紹介された取り組みのうち、SafetensorsやSPIFFE/SPIREのように、連合の発足前から広く使われている技術は少なくない。
それ自体は悪いことではなく、実績のある部品を「AIの防御」という文脈で束ね直すことには価値がある。
ただし、37社が新たに何を共同で開発するのかと、既存プロジェクトの看板を掲げているだけなのかは、現時点では区別がつかない。
つまり、「参加企業が多い」ことと「新しい防御能力が生まれる」ことは、別の話として捉える必要がある。
ガバナンスが見えない
公開されている資料の範囲では、憲章、運営委員会、作業部会、ロードマップ、共有リポジトリといった、連合の実体を示す情報は確認できていない。
非営利の業界団体であるクラウドセキュリティアライアンス（CSA）の調査ノートも、発足時点で憲章、統治機関、技術的な作業部会、納期、連合共通のコードリポジトリがなく、専用サイトも準備中だったと指摘している。
CSAは企業に対し、特定の連合のロードマップではなく、ベンダー中立の枠組みを軸にAIエージェントのガバナンスを組むよう勧めている。
NOOAの開発はNVIDIAが主導しており、他の参加企業が関われるのは、コードの改善案を提案する程度にとどまる。
また、参加企業が「エンジニアを出して共同作業する」のか、「既存のプロジェクトを提供する」のか、「方向性に賛同する」だけなのかも区別されていない。
経営層にとっての実務的な含意は明確で、この連合の成果物に自社の防御を依存するのはまだ早いということだ。
まずは動向を追い、成果が具体化した段階で評価する、という姿勢が現実的だろう。
NOOA自身が明記する限界
NOOAは、AIエージェントを扱いやすくする研究用フレームワークだ。AIエージェントが生成したコードを事前にチェックしたり、OSのファイルを直接操作するような危険なモジュールの使用を禁止したりする。
ただし開発元のNVIDIA自身が、コードの事前チェックや危険な機能の使用禁止といった仕組みは、いくつもある防御策の一つに過ぎず、これだけで安全が保証されるわけではないと明記している。
例えばAIエージェントが暴走しようとした際に、実際にそれを食い止める最後の砦は、コンテナやVMのような隔離された環境の中でエージェントを動かすことだとして、利用者にその実施を求めている。
これは誠実な記述であり、同時に重要な教訓でもある。
AIエージェントを安全に動かす鍵は、モデルやフレームワークの側だけにあるのではなく、実行環境の隔離と権限の設計にあるということだ。
そしてこれは、Hugging Face自身が事案後に取った対策とも符合する。
中国発モデルという論点
今回の事例で防御に使われたGLM-5.2は、中国のZhipu AI（Z.ai）が開発したモデルだ。
日本企業にとっては、ここに別の論点が加わる。
日本では2025年2月3日に個人情報保護委員会がDeepSeekについて注意喚起を出し、取得されたデータが中華人民共和国のサーバーに保存されること、そのデータに中国の法令が適用されることに留意するよう求めた。
政府内でも、2月6日付の事務連絡で、「業務利用に際してリスクを十分に認識すること」「要機密情報は扱わないこと」「事前にNISCとデジタル庁に助言を求めること」などが示されている。
ただし、こうした注意喚起は、DeepSeekのようにクラウドサービス（API）としてそのまま使う場合を想定したものだ。
GLM-5.2のように重みが公開されたモデルを、自社の環境にダウンロードして動かす場合は、入力したデータが中国を含む外部のサーバーに送られることがないため、リスクの性質が異なる。
日本の解説でも、米国クラウド経由での利用、自社ホスティング、複数モデルを切り替えるゲートウェイの活用といった選択肢が紹介されている。
それでも、ライセンス条項や利用規約の内容、学習データや実装の開示範囲、回答の偏りといった確認事項は残る。
要するに、「オープン」と「安心」は同義ではなく、コスト面の利点とデータ主権・地政学上の懸念を、経営として明示的に天秤にかける段階に来ているということだ。
OSAAが示したのは、防御の選択肢が増えたという事実であって、答えではない。
そして、こうした検証はOSAAだけに課すべきものではない。
Project Glasswingのように能力を統制するクローズド側の選択肢についても、提供範囲や利用条件、依存した場合のリスクを同様に点検する必要がある。
どの技術を、どんな条件で、どこまで信頼するかは、結局のところ自社で判断するしかない。その判断の積み重ねこそが、自社がどこに依存し、どこに代替手段を持つかという設計そのものになる。
経営層への5つの問い
ここまで見てきたHugging Faceの事件とOSAAの発足は、他社の出来事であり、他社が始めた取り組みだ。
しかし、そこから浮かび上がった課題は、業種やAIの利用状況を問わず、多くの企業に共通することだと考える。
そこで最後に、この事件を自社の点検材料に変えるための5つの問いを整理する。
答えられない項目があれば、そこが着手点ということだ。
自社のインシデント対応で、AIに調査を任せられるか
有事に使うAIが、攻撃の解析を拒否したり、機密を含むログを外部に送る必要があったりしないかが、事前に確認しておくべき点だ。
使える手段が一つもない場合は、自社管理下で動かせるモデルや、そうした環境を提供するパートナーを、平時のうちに選定しておく必要がある。
訓練で一度でも試しておけば、実際の制約が見えてくる。
セキュリティ業務が、単一ベンダーのAPIに依存していないか
依存先が一つの場合、その提供が止まったり、利用規約や制限が変わったりした時点で、防御そのものが止まる。
これは、電源や通信回線を冗長化するのと同じで、事業継続の問題だ。
複数のモデルやサービスを切り替えられる構成や、契約上の条件の確認は、情報システム部門だけでなく、経営がリスクとして把握すべき事項だ。
AIエージェントの権限は、人間の社員と同水準で管理されているか
そして、エージェントごとにIDを分け、必要な権限だけを与え、実行環境を隔離し、操作の記録を残しているかを確認する。
NOOAの限界の記述が示すとおり、モデルやフレームワークの内部制御だけを信じるのは危険だ。
実行環境の隔離と、外部から検証できるログが最後の防波堤になる。
使っているモデル、ライブラリ、データの供給元を把握しているか
Hugging Faceの侵入は、データセット処理の脆弱性から始まった。
モデルやデータセットは、外部から取り込む「ソフトウェア部品」だ。
「どの経路で」「誰が作ったものを」「どの環境で読み込んでいるのか」
Safetensorsのような安全な形式の採用や、署名付きの配布物の利用は、この供給網の管理を支える手段だ。
現場の担当者が個人判断で外部のモデルを取り込んでいないか、という点も、シャドーAIの観点で棚卸しが必要だ。
オープンとクローズドの方針を決める責任者は誰か
最後は、「どのモデルをどの用途に使い、どこまで自社で運用し、どこを外部に委ねるのか」という問いだ。
これは技術選定であると同時に、コスト、データ主権、地政学、事業継続を含む経営判断だ。
情報システム部門、セキュリティ部門、現場、法務、調達がそれぞれ別々に判断していると、全体像が誰にも見えなくなる。
方針を決め、例外を許可する責任者を明確にすることが、他のすべての問いに先立つ前提だ。
まとめ
攻撃者が最先端のAIを使うなら、防御側にも、それに対抗できる手段が要る。
そして、その手段が有事に確実に使える状態にあるかどうかは、平時の設計で決まる。
自社がどこに依存し、どこで代替手段を持つかを、平時のうちに意識的に設計しているかどうかが問われている。
その設計に向けた小さな一歩が、AI時代の経営における実質的な防御力になるだろう。
現在、デジタルをビジネスに取り込むことで生まれる価値について研究中。IoTに関する様々な情報を取材し、皆様にお届けいたします。
