2026年7月27日、NVIDIAが主導する業界団体「Open Secure AI Alliance（オープン・セキュア・AI・アライアンス）」が発足しました。Microsoft、IBM、Red Hat、Cloudflare、Hugging Face、Linux Foundation などが名を連ねています。
主張は一行です。AIエージェントの安全性は、AIモデルの中身が公開されているかどうかでは決まらない。それを動かす「土台」の作りで決まる。
発表文にはこう書かれています。「AIエージェントは言語モデルではない。モデル・ハーネス・ガードレールから成る複雑なシステムだ」[1]。安全性を構成する要素は6つ——誰の権限で動くか／何をしてよいか／どう動かすか／どこで止めるか／何を記録するか／どう評価するか。モデルの重みが開いているか閉じているかは、そのうちの一部でしかない、というのが同盟の立場です。
この記事で分かること。①何が発足したのか ②「モデルではなくスタック」という主張の中身 ③参加各社が実際に出した実物 ④きっかけになった実際の事件 ⑤CAGが調べて分かった、報道と食い違う参加社数 ⑥冷静に見たときの弱点。
01 何が発足したのか ──「防御側の道具」をオープンに共有する同盟
2026年7月27日、NVIDIAの公式ブログで発表されました[1]。目的は、AI時代のソフトウェアとエージェントを守るための技術・手法・ツールを、オープンに開発して共有することです。
土台になっている取り組みが2つあります。ひとつは Linux Foundation が2026年6月25日に立ち上げた「Akrites」（アクリテス＝広く使われているオープンソースソフトウェアの脆弱性を、悪用される前に修正まで持っていくための業界横断の枠組み）[5]。もうひとつは OpenSSF（オープンソースのセキュリティを扱う既存コミュニティ）です。新しい同盟は、この上に乗る形をとっています。
発表文の主張のうち、AIに詳しくない読者にも効くのはこの部分です。
オープンソースが「ソフトウェアの共有の土台」を作ったように、いま米国とそのパートナーはAIセキュリティで選択を迫られている。インフラを守る防御機構が、少数の不透明なシステムの内側に置かれるのか、それとも防御側の誰もが調べ・適応させ・配備できるオープンなモデル・ハーネス・ツールの上に築かれるのか。[1]
「オープンなモデルは改造されて悪用されるから危ない」という反論には、こう返しています。そのリスクはクローズドなシステムでも消えない。重みを閉じておくことは、本気の攻撃者が強力なAIを手に入れることを防がない。 防御側からアクセスを取り上げるのではなく、開放性に「強力な安全装置・悪用への明確な規則・厳密な評価・迅速な修正」を組み合わせるのが正しい対応だ、と。
02 主張の核 ──「AIエージェントは、言語モデルではない」
AIエージェント（人間の指示を受けて、自分で手順を決めて作業を進めるAI）を業務に入れるとき、注目が集まるのはたいてい「どのAIモデルを使うか」です。ところが発表文の立場では、事故が起きるのはモデルの賢さではなく、その外側です。
それぞれを日常の言葉に置き換えると、次のようになります。識別＝そのエージェントは誰の代理として動くのか。権限＝本番のデータベースに書き込めるのか、読むだけか。ハーネス＝モデルを実際に動かす仕組み（道具の呼び出し方、失敗時の再試行、停止条件）。防護柵＝やってはいけないことを止める仕組み。記録＝何をしたか後から追えるか。評価＝期待どおり動いているかを継続して測れるか。
CAGはこの「モデルよりハーネス」という論点を以前に扱いました。今回、業界側から同じ整理が出てきた形です。
関連記事 ｜ 同じ論点をCAGが先に扱った回「最強モデル」より「強いharness」──frontier AIが"政策で止まる"時代のエージェント設計
→
03 各社が出した実物 ──宣言ではなく、コードとフォーマット
この同盟が声明だけで終わっていない部分がここです。参加各社が、既存の実装を持ち寄っています[1]。
| 提供元 | 出したもの | 何のためのものか |
|---|---|---|
| NVIDIA | NOOA （Object-Oriented Agent） | エージェントの挙動を、テスト・追跡・監査・統治しやすくするための研究用フレームワーク |
| HPE | SPIFFE / SPIRE | AIエージェントやサービスを暗号的に本人確認し、許可されたものだけが通信・アクセスできるようにするゼロトラストの識別基盤 |
| Hugging Face | Safetensors | AIモデルの重みを安全に保存する形式（読み込むだけで任意のコードが実行されないことを保証）。PyTorch Foundation へ提供 |
| IBM / Red Hat | Lightwell | デジタル署名付きのパッチで、オープンソースの供給網までセキュリティを広げる |
| Microsoft | MDASH | 複数の専門AIエージェントを協調させ、悪用可能なバグを発見・議論・証明する多モデル走査ハーネス |
| SpaceXAI | Grok Build | ターミナル上で動くAIコーディングエージェントをOSS化。Grok系モデルの重み公開も予定 |
NOOA は GitHub で公開されています（NVIDIA-NeMo/labs-OO-Agents）。CAGが確認した時点で 665スター・97フォーク、リポジトリ作成は2026年7月20日＝発表の7日前、最終更新は8月1日でした[6]。arXiv に論文も出ています。
04 きっかけになった事件 ──「守る側がAIを使えなかった」
発表文が名指しで挙げている実例があります。Hugging Face のセキュリティ事件です。
クローズドなAIツールが、攻撃者と防御者を区別できずに必要なフォレンジック分析を止めてしまったとき、Hugging Face はオープンウェイトの GLM 5.2 を自社インフラで動かし、17,000件を超える操作を分析して侵入を封じ込めた。[1]
守る側が、自分のインフラの中でAIを動かせなければ、いちばん速さが要る瞬間に対応能力が制限される。 これがこの同盟の出発点になっています。CAGはこの事件そのものを別の記事で扱いました。
関連記事 ｜ 同盟の出発点になった事件AIエージェントが本番インフラに侵入した ──OpenAIとHugging Faceが公表したセキュリティ事故を解説
→
05 CAGが調べたこと ──「37社」はもう古い。ただし4社は来ていない
ここからはCAGが実際に手を動かして確認した部分です。
報道はどれも参加社数を「37社」（The Hacker News・7月27日[3]）あるいは「35社超」と書いています。ところが今日（2026年8月2日）NVIDIAの発表ページを取得して名簿を数えると、74社ありました。
食い違いの理由を調べるため、Internet Archive に残る過去の保存版を取得し、同じ方法で名簿を数え直しました[2]。
| 時点 | 創設パートナー数 | 増分 |
|---|---|---|
| 2026-07-27 11:16 UTC （公開当日） | 37社 | — |
| 2026-07-29 19:00 UTC | 52社 | +15（GitHub・Mistral・Perplexity・Fortinet・vLLM ほか） |
| 2026-08-02 （本記事執筆時） | 74社 | +22（Mozilla・Okta・Docker・Cohere・Wiz・Workday ほか） |
発足から6日で、ちょうど2倍になっています。 しかも表記は「inaugural partners（創設パートナー）」のまま増え続けています。報道の「37社」は発表当日としては正確で、その後ページが静かに書き足されていた、というのが実態です。
名簿を全件突合して分かったことが、もうひとつあります。OpenAI・Anthropic・Google・Amazon は、7月27日の37社にも、今日の74社にも入っていません。 Meta も同様です。
これが効いてくるのは、01章で触れた Akrites との比較です。Akrites（2026年6月25日発足・Linux Foundation）の創設メンバー19社には、AWS・Anthropic・Google・OpenAI・Microsoft・NVIDIA が全員揃っています[5]。
つまり——1か月前に同じ卓についていた顔ぶれのうち4社が、その枠組みの上に建てられた新しい同盟には来ていない。 NVIDIA自身が「Akrites のリーダーシップの上に築く」と書いているだけに、この欠落は目立ちます。
Cloud Security Alliance も7月28日のリサーチノートで同じ点を構造的な弱点として挙げ、「主要なフロンティアモデル開発者が卓につく必要があり、エージェントが権限を越えたときの責任について業界で合意されたルールが要る」という分析を紹介しています[4]。
06 冷静に見る ──憲章のない同盟と、「境界ではない」と自ら書くツール
期待だけで終わらせないために、弱点も並べます。
ひとつめ。組織としての骨格がまだありません。 Cloud Security Alliance によれば、発足時の資料には憲章も、理事会も、技術ワークストリームも、成果物の予定表も、同盟共有のリポジトリもありません[4]。事実上の標準化団体として振る舞える規模と注目度がありながら、統治の仕組みが公表されていない状態です。
ふたつめ。目玉であるNOOAは、自分で自分の限界を書いています。 CAGがリポジトリのREADMEを直接読んだところ、次の記述がありました[6]。
NOOA は生成されたコードを検証し、実行前にモジュールの拒否リストを適用する。これらは多層防御のガードレールであって、封じ込めの境界ではない。（中略）封じ込めの境界はOSレベルの隔離である——生成コードを実行するエージェントは、必ずコンテナやVMなどのサンドボックスの中で動かすこと。プロセス内の検証器だけに頼ってはならない。[6]
同じREADMEには「LLMが生成したコードは、私的データを管理外の場所へ送る・ファイルを削除する・環境を書き換えるといった危険な動作をとりうる」とも書かれています。誠実な記述ですが、裏を返せばこのフレームワークを入れただけでは安全にならないということです。CSAは、注目度と市場での位置づけゆえに、現場のチームが研究段階のコードを「検証済みの管理策」として扱ってしまうリスクを警告しています[4]。
07 まとめ ──明日からできること
AIエージェントを業務に入れようとしている会社にとっての持ち帰りを、専門用語なしで並べます。
- そのAIが「誰の権限」で動いているか言えるか（担当者個人のアカウントを借りたままになっていないか）
- 触れる範囲を決めているか（読むだけでよい作業に、書き込みの権限まで渡していないか）
- 何をしたか後から追えるか（記録が残っているか、残っていても読める形か）
- 止める手段があるか（おかしいと気づいた人が、その場で止められるか）
- 生成されたコードを実行させるなら、隔離された場所で動かしているか
この5つはどれもモデルの性能とは無関係で、モデルを乗り換えても持ち越せます。74社が集まって最初に言ったのが「安全性はスタック全体で決まる」だったというのは、そういう意味です。守るべきものは、賢さの外側にある。
出典・注記
- NVIDIA「Industry Leaders Unite in Open Secure AI Alliance for AI Safety and Security」2026年7月27日（最終更新7月30日）https://blogs.nvidia.com/blog/open-secure-ai-alliance/ 引用は原文（英語）からのCAGによる訳。
- 参加社数の推移＝CAGが Internet Archive の保存版（2026-07-27 11:16 UTC／2026-07-29 19:00 UTC）と現行ページ（2026-08-02取得）の創設パートナー名簿を突合して集計したもの。
- The Hacker News「NVIDIA Forms 37-Member Open Secure AI Alliance and Open-Sources NOOA Framework」2026年7月27日 https://thehackernews.com/2026/07/nvidia-forms-37-member-open-secure-ai.html
- Cloud Security Alliance リサーチノート 2026年7月28日 https://labs.cloudsecurityalliance.org/research/csa-research-note-nvidia-open-secure-ai-alliance-nooa-202607/
- 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/…
- NOOA リポジトリ（NVIDIA-NeMo/labs-OO-Agents）の README および GitHub API のメタデータ、2026年8月2日 CAG取得 https://github.com/NVIDIA-NeMo/labs-OO-Agents 引用は原文（英語）からのCAGによる訳。
本記事の数値・仕様は公式発表と公開リポジトリに基づくもので、参加社数の集計（脚注2）を除き、CAG自身が検証したものではありません。
AIエージェントを、業務に入れる前に
権限・記録・停止・隔離をどう設計するかは、使うモデルが変わっても残る部分です。自社の業務にどう組み込むかの相談は お問い合わせ から。
