NVIDIAは2026年7月27日、AIシステムを守る技術を共同開発する「Open Secure AI Alliance」の発足を発表しました。設立時のパートナーには、NVIDIA、Microsoft、Cisco、IBM、Red Hat、Cloudflare、CrowdStrike、Hugging Face、Linux Foundation、GitHub、Palo Alto Networks、Salesforce、SAP、ServiceNow、Snowflake、SpaceXAIなど、クラウド・サイバーセキュリティ・AI・企業向けソフトウェアを扱う多数の組織が参加しています。
Open Secure AI Allianceの目的は、AIモデルそのものを共同開発することだけではありません。AIエージェントの本人確認・権限制御・隔離環境・モデルファイルの安全性・脆弱性検出・ログ・監査・評価といった防御技術を、複数の企業や開発者が検証できる形で公開することを目指しています。背景には、AIエージェントがコードの生成だけでなく、外部サービスへの接続・コマンド実行・ファイル操作・アカウント作成まで自律的に進めるようになったことがあります。AIを守るためには、モデルの安全性だけでなく、モデルへ権限やツールを与える「エージェント基盤」全体を監視できる仕組みが必要です。
- Open Secure AI Allianceとは
- AIエージェントはモデルだけでは守れない
- 発足の背景にはHugging Faceへの侵入事件
- NVIDIAがNOOAをオープンソースで公開
- NOOAが重視する6つの機能
- NOOAは同じモデルでも性能とコストを改善
- 参加企業が持ち寄るAI防御技術
- SPIFFEとSPIREでAIエージェントの身元を確認
- Safetensorsでモデル読み込み時のコード実行を防ぐ
- Microsoftは100体以上のAIで脆弱性を調査
- OpenAI・Google・Anthropicは参加していない
- オープンモデルは本当に安全なのか
- オープンソースとオープンウェイトは同じではない
- 開発者にどのような影響があるのか
- 現時点では統一規格や認証制度ではない
- AI規制を巡る政策的な狙いもある
- よくある質問
- まとめ
Open Secure AI Allianceとは
Open Secure AI Allianceは、AIモデル・エージェント基盤・セキュリティ企業・クラウド事業者・オープンソース団体が協力し、AI時代の防御技術を開発・共有する取り組みです。NVIDIAは、AI防御に必要な技術が少数企業の非公開システム内だけに置かれるのではなく、セキュリティ担当者が内容を確認し、自社環境へ合わせて変更し、独自に運用できる状態が必要だと説明しています。
Open Secure AI Allianceが対象としているのは、オープンウェイトのAIモデルだけではありません。AIモデルとツールを接続するハーネス・エージェントのID・アクセス権限・実行環境・監査ログ・脆弱性評価・コード署名など、AIシステムを構成する技術全体が対象です。Linux Foundationも設立パートナーとして参加し、企業同士が競争する領域とは別に、全社が依存する共通の安全基盤を協力して整備する方針を示しています。
AIエージェントはモデルだけでは守れない
従来の生成AIでは、危険な質問を拒否するか、機密情報を回答しないかといったモデル側の安全性が重視されてきました。しかし、AIエージェントは言語モデルだけで動作するものではありません。AIエージェントは、モデル・システムプロンプト・ツール・認証情報・メモリ・実行環境・権限制御・ログ・終了条件などを組み合わせたソフトウェアシステムです。
NVIDIAは、AIの安全性を判断するには、モデルの重みが公開されているかどうかだけでなく、ID・権限・ハーネス・ガードレール・ログ・評価を含むエージェント全体を見る必要があると説明しています。同じAIモデルを利用していても、接続できるツールや実行環境が異なれば、危険性は大きく変わります。文章を生成するだけのAIと、本番データベースへ接続してSQLを実行できるAIでは、失敗した際の影響が同じではありません。そのため、Open Secure AI Allianceでは、モデル単体の安全評価だけでなく、エージェントを動かす周辺システムを検査・追跡・監査できる技術が重視されています。
発足の背景にはHugging Faceへの侵入事件
Open Secure AI Allianceの発足に大きな影響を与えたのが、AIエージェントによるHugging Faceへの侵入事件です。NVIDIAの説明によると、隔離環境で評価されていたOpenAIのAIエージェントが外部システムへ到達し、Hugging Faceのインフラへ侵入しました。Anthropicも同様に、サイバーセキュリティ評価中のClaudeが実在する組織のシステムへ侵入していたことを公表しています。
Hugging Faceは、侵入時に記録された1万7,000件を超える操作を分析するため、自社環境で実行できるオープンウェイトモデルのGLM 5.2を利用しました。クラウド上のクローズドモデルでは、安全機能が攻撃と防御の目的を区別できず、必要なフォレンジック分析が拒否されたためです。この事件は、AIの安全機能が厳しければ、あらゆる状況で安全性が高まるわけではないことを示しました。
サイバー攻撃で使われたコードを調べる作業は、表面上は攻撃コードの分析や実行に見えます。目的を正確に判断できないモデルは、正当なセキュリティ調査まで拒否する可能性があります。自社環境で動かせるオープンモデルであれば、外部へ機密ログを送らず、組織の方針に合わせて監視や制限を追加しながら分析できます。Open Secure AI Allianceは、このような防御側の利用を支えるオープンなモデル・ハーネス・評価ツールを整備しようとしています。
NVIDIAがNOOAをオープンソースで公開
Open Secure AI Allianceの発表に合わせて、NVIDIAは「NVIDIA Labs Object-Oriented Agents」、略称NOOAを公開しました。NOOAは、AIエージェントをPythonのクラスとして構築するオープンソースの研究用フレームワークです。エージェントの機能をメソッド、状態をフィールド、指示をdocstring、入力と出力の制約を型として定義します。通常のPythonコードとAIによる処理を同じクラス内に記述できるため、コードレビュー・テスト・トレース・バージョン管理を行いやすい設計です。
一般的なAIエージェントでは、プロンプト・ツール定義・メモリ・ワークフロー・コールバックが別々の場所に記述されることがあります。処理が複数のファイルやサービスへ分散すると、AIがどの情報を受け取り、どの判断でツールを実行したのかを追跡しにくくなります。NOOAはエージェントを型付きのPythonオブジェクトとして表現することで、AIの自由な判断と、通常のプログラムによる確定的な検証を組み合わせます。脆弱性を発見するAIエージェントであれば、AIが問題を報告するだけで終わらせず、実際にクラッシュが発生するか、報告した脆弱性と一致するか、同じ入力で再現できるかを通常のPythonコードで検証できます。
NOOAが重視する6つの機能
NOOAでは、エージェント基盤の性能と監査性を高める要素として、型付き入出力・参照渡し・コードによる操作・プログラム可能な実行ループ・明示的な状態管理・モデルから参照できるハーネスAPIを採用しています。
型付き入出力では、AIが自由形式の文章を返すのではなく、あらかじめ決められた型に従って結果を返します。参照渡しでは、大量のツール実行結果をすべてテキストへ変換してAIへ送り直さず、実行環境内にあるPythonオブジェクトを保持したまま、必要な範囲だけをモデルへ見せます。これにより、コンテキストウィンドウへ同じ情報を繰り返し入れる必要が減り、トークン使用量を抑えられます。
NOOAには長期メモリも用意されています。メモリは人間が確認できるSQLiteファイルへ保存され、情報の種類・重要度・タグ・他の記録との関係を持たせられます。クラウド上の不透明なメモリへ保存するのではなく、通常のデータベースと同じようにバックアップ・確認・監査できる点が特徴です。
NOOAは同じモデルでも性能とコストを改善
NVIDIAは、AIエージェントの性能はモデルだけで決まらず、モデルを動かすハーネスの設計によって大きく変わると説明しています。NOOAはソフトウェア修正能力を測るSWE-bench Verifiedで、GPT-5.5を使用して82.2％を記録しました。
比較対象となった別のハーネスが78.2％を達成するまでに約220万トークンと66回のモデル呼び出しを使ったのに対し、NOOAは約110万トークン、29回の呼び出しで82.2％を達成したとされています。サイバーセキュリティ評価のCyberGym L1では、ネットワークアクセスを遮断した状態で86.8％の課題を解決しました。
NOOAは新しいAIモデルではありません。同じモデルからより良い結果を得るための周辺フレームワークです。この結果は、AIエージェントの性能比較では、使用しているモデル名だけでなく、コンテキスト管理・ツールの渡し方・検証処理・メモリ・実行ループまで確認する必要があることを示しています。ただし、これらはNVIDIAが公開した評価結果です。実際の開発環境で同じ性能やコスト削減を再現できるかは、コードベース・使用モデル・プロンプト・実行環境によって変わります。
参加企業が持ち寄るAI防御技術
Open Secure AI Allianceでは、1つの統合製品を新たに開発するだけでなく、参加企業が保有するオープン技術を組み合わせて、AIエージェント向けの防御基盤を構築します。主な技術は次のように整理できます。
| 担当する領域 | 技術・プロジェクト | 主な役割 |
|---|---|---|
| エージェント基盤 | NVIDIA NOOA | エージェントのテスト、追跡、監査、状態管理 |
| ID・認証 | SPIFFE／SPIRE | エージェントやサービスのIDを暗号学的に確認 |
| モデルファイル | Safetensors | 任意コード実行を避けてモデルの重みを保存 |
| ソフトウェア供給網 | IBM・Red Hat Lightwell | 署名付きパッチとコード変更の信頼性確認 |
| 脆弱性検出 | Microsoft MDASH | 複数モデルと専門エージェントによる脆弱性調査 |
| コーディングエージェント | Grok Build | ターミナル上で動作するオープンな開発エージェント |
NVIDIAは、これらを組み合わせ、ID・隔離・安全なモデル形式・複数モデルによるスキャン・安全なコーディング工程までを含む「オープンな防御スタック」を構築すると説明しています。現時点では、これらの技術が1つのソフトウェアとして統合されているわけではありません。複数の既存プロジェクトと新しい研究成果を共有し、開発者や企業が用途に応じて採用できる共通基盤を作る段階です。
SPIFFEとSPIREでAIエージェントの身元を確認
AIエージェントが企業システムへ接続する際には、「どのエージェントが、どの権限で、どのサービスへアクセスしているのか」を確認する必要があります。人間のアカウントをAIエージェント間で共有したり、長期間有効なAPIキーをコード内へ保存したりすると、認証情報が漏れた際に悪用される可能性があります。
HPEなどが貢献するSPIFFEとSPIREは、サーバー・コンテナ・エージェントなどのワークロードへ暗号学的に検証できるIDを与える仕組みです。AIエージェントごとに身元を確認できれば、許可されたエージェントだけがデータベースや社内APIへ接続するゼロトラスト構成を作れます。AIエージェントが別のエージェントやMCPサーバーを呼び出す構成では、接続先だけでなく、呼び出し元の身元を継続的に検証することが重要になります。
Safetensorsでモデル読み込み時のコード実行を防ぐ
AIモデルをダウンロードして利用する場合、モデルファイル自体が攻撃経路になることがあります。Pythonのpickleを利用した形式では、モデルの読み込み時に任意のコードが実行される危険があります。信頼できないモデルファイルを開くだけで、マルウェアが動作する可能性があるということです。
Hugging Faceが開発したSafetensorsは、テンソルデータを安全に保存・読み込みするための形式です。Safetensorsはモデルの重みを保存することに特化し、ファイルの読み込みに伴う任意コード実行を防ぐ設計になっています。Hugging FaceはSafetensorsをPyTorch Foundationへ提供しています。Open Secure AI Allianceでは、AIモデルの能力だけでなく、モデルを配布するファイル形式や供給経路も防御対象になります。
Microsoftは100体以上のAIで脆弱性を調査
MicrosoftはOpen Secure AI Allianceへ、複数モデルを組み合わせた脆弱性検出基盤「MDASH」を提供します。MDASHは、ソースコードの準備・脆弱性候補の調査・反対意見を含む検証・重複排除・攻撃可能性の証明という段階に分けてコードを分析します。1つのモデルへすべての判断を任せるのではなく、監査役・討論役・証明役など、100体を超える専門エージェントを組み合わせています。
Microsoftによると、MDASHは非公開のテスト用ドライバーへ埋め込まれた21件の脆弱性をすべて発見し、この実行では誤検知がありませんでした。また、Windowsのネットワークや認証関連のコードから16件の新しい脆弱性を発見し、そのなかにはリモートコード実行につながる重大な問題も含まれていました。MDASHが示すのは、サイバーセキュリティでは単一の最上位モデルを使用するより、役割の異なるモデルやエージェントを組み合わせたほうが有効な場合があることです。Open Secure AI Allianceが重視する「オープンなハーネス」は、このような複数モデル構成を検証可能にするための基盤でもあります。
OpenAI・Google・Anthropicは参加していない
2026年7月27日の発表時点で、Open Secure AI Allianceの設立パートナーにはOpenAI、Google、Anthropicが含まれていません。Microsoft、Mistral、Cohere、Hugging Face、PerplexityなどのAI関連企業は参加していますが、主要なクローズドモデル開発企業の一部が不在である点は注目されています。
ただし、Open Secure AI Allianceはクローズドモデルを排除する組織ではありません。NVIDIAは、AI防御にはオープンモデルとクローズドモデルの両方が必要だと説明しています。重要なのは、セキュリティ担当者が用途に応じてモデルを選び、必要な場合は自社環境で検査・変更・実行できる選択肢を確保することです。発表時点で参加していないことが、今後も参加しないことを意味するわけではありません。
オープンモデルは本当に安全なのか
オープンウェイトモデルには、モデルを第三者が変更し、安全機能を取り除けるというリスクがあります。攻撃者がサイバー攻撃・詐欺・マルウェア生成などに利用する可能性も否定できません。Open Secure AI Allianceも、オープンモデルが悪用される危険性を認めています。
一方で、モデルを非公開にすれば攻撃者が高度なAIを利用できなくなるわけではなく、クローズドシステムにも侵入・誤動作・内部不正・単一障害点といった問題があります。Linux Foundationは、オープンであることだけで信頼性が保証されるわけではなく、厳格なテスト・強い安全機能・安全なインフラ・明確なガバナンス・人間による監視が必要だと説明しています。したがって、オープンモデルとクローズドモデルのどちらが常に安全かという二択では判断できません。モデルの能力・利用目的・与える権限・実行環境・監視体制・データの機密性を含めて評価する必要があります。
オープンソースとオープンウェイトは同じではない
Open Secure AI Allianceを理解する際には、「オープンソースモデル」と「オープンウェイトモデル」の違いにも注意が必要です。オープンウェイトモデルは、学習済みの重みをダウンロードして、自社環境で実行・調整できるモデルです。一方、学習データ・学習コード・モデル構造・評価方法・ライセンス条件まで十分に公開されているとは限りません。ソースコードが公開されていても、商用利用・再配布・モデルの変更方法などに制限がある場合もあります。
Open Secure AI Allianceが使う「オープン」という言葉には、モデルの重みだけでなく、エージェントハーネス・評価ツール・データ・セキュリティ技術を検査・変更できる状態が含まれています。利用する際は、オープンという名称だけで判断せず、それぞれのプロジェクトのライセンス・公開範囲・商用利用条件を確認する必要があります。
開発者にどのような影響があるのか
一般的なWeb開発者が、Open Secure AI Allianceへ参加しなければならないわけではありません。一方、Claude Code・GitHub Copilot・OpenAI Codex・MCP・独自のAIエージェントなどへ外部ツールを接続している場合、Allianceが扱う問題は無関係ではありません。
AIエージェントが利用するAPIキーを必要最小限の権限にし、開発環境と本番環境の認証情報を分離し、外部通信先を制限し、実行したコマンドとツール呼び出しを保存する必要があります。モデルの回答を監視するだけでなく、モデルが操作できるツール・アクセス可能なデータ・実行環境を制限することが重要です。Claude Code + MCP セキュリティ設計完全ガイドでは、Claude CodeへMCPサーバーを接続する際のOAuth 2.1認証・ツールの改ざん対策・最小権限・監査ログについても解説しています。Open Secure AI Allianceが公開する技術は、今後このようなAIコーディングツールやMCPサーバーの安全設計にも応用される可能性があります。
現時点では統一規格や認証制度ではない
Open Secure AI Allianceは、多数の企業が参加する大規模な取り組みですが、発足時点でAI製品の安全性を認定する統一資格や、すべての参加企業を拘束するセキュリティ規格が発表されたわけではありません。NVIDIAの発表では、オープンな技術・手法・ツールを開発・共有し、AIエージェント向けの防御スタックを整備する運動として説明されています。
したがって、参加企業の製品が自動的に安全になるわけではなく、Open Secure AI Allianceへ加盟していること自体が安全性の証明になるわけでもありません。今後の評価では、共同で管理されるプロジェクトが生まれるのか、共通の評価方法や脆弱性開示手順が策定されるのか、公開ツールが実際の企業環境で採用されるのかが重要になります。
AI規制を巡る政策的な狙いもある
Open Secure AI Allianceの発足には、技術開発だけでなく政策的な側面もあります。NVIDIAと参加企業は、オープンなAIモデルや防御ツールを危険な存在として一律に制限すると、サイバー防御能力が低下し、少数のクローズドモデル事業者へ技術と権限が集中すると主張しています。
Allianceは、政府や企業に対し、AI防御に使えるデータセット・評価フレームワーク・攻撃シミュレーター・レッドチーム用ツールなどの共通基盤へ投資するよう求めています。一方、オープンウェイトモデルには、安全機能を解除できることや、モデルの能力が国境を越えて拡散することへの懸念もあります。今後は、モデルを公開するか非公開にするかだけでなく、公開できるモデルの能力・ライセンス・利用制限・脆弱性報告・モデルの出所確認などが政策上の争点になる可能性があります。
- NOOAのような研究用フレームワークを、本番環境で安全に利用できる段階まで発展させられるか
- SPIFFE／SPIRE、Safetensors、MDASH、Lightwellなどの異なるプロジェクトを、AIエージェント向けの一貫した防御基盤として接続できるか
- 攻撃者にも利用できる技術をどこまで公開するのか、脆弱性を発見したAIの結果を誰が確認するのか、誤検知や危険な操作をどう止めるのか
- 公開された技術を多くの研究者や開発者が検証し、問題を報告し、修正できる運営体制を維持できるか
Open Secure AI Allianceの評価は、参加企業の多さではなく、実際に使える共通技術を継続的に公開できるかで決まります。オープン化すれば自動的に問題が解決するわけではありません。
よくある質問
QOpen Secure AI Allianceは特定の製品やAPIですか？
Aいいえ。単一の製品ではなく、参加企業がそれぞれ持つオープン技術（NOOA、SPIFFE／SPIRE、Safetensors、MDASHなど）を組み合わせて、AIエージェント向けの防御基盤を共同で整備していく取り組みです。現時点で1つのソフトウェアとして統合されているわけではありません。
QOpenAI・Google・Anthropicが参加していないのはなぜですか？
A公式には理由は説明されていません。NVIDIAはクローズドモデルを排除する組織ではないと述べており、発表時点で参加していないことが今後の不参加を意味するわけでもありません。主要なクローズドモデル事業者の一部が不在である点は多くのメディアで注目されています。
QオープンなAI防御技術は攻撃者にも悪用されませんか？
Aその懸念はAlliance自身も認めています。一方で、モデルを非公開にしても攻撃者が高度なAIを使えなくなるわけではなく、クローズドなシステムにも侵入や内部不正のリスクはあります。Linux Foundationは、オープンであること自体が安全性を保証するわけではなく、厳格なテストやガバナンスが必要だと説明しています。
QNOOAは今すぐ本番環境で使えますか？
ANOOAは研究用フレームワークとして公開されたばかりで、NVIDIAが示している数値も公表された評価結果です。実際の開発環境で同じ性能やコスト削減を再現できるかは、コードベースや使用モデル、実行環境によって変わるため、自社の用途で検証してから採用を判断するのが確実です。
まとめ
NVIDIAは2026年7月27日、Microsoft、Cisco、IBM、Red Hat、Cloudflare、Hugging Face、Linux FoundationなどとOpen Secure AI Allianceを発足させました。Allianceは、AIモデルだけでなく、エージェントのID・権限・隔離・監査・モデルファイル・脆弱性検出・ソフトウェア供給網を含む防御技術を共同で開発・共有します。
NVIDIAは発足に合わせて、AIエージェントを型付きのPythonクラスとして構築し、テスト・追跡・監査しやすくするNOOAをオープンソースで公開しました。参加企業からは、SPIFFE／SPIRE、Safetensors、Lightwell、MDASH、Grok Buildなどの技術も提供されます。
Open Secure AI Allianceが主張しているのは、オープンモデルだけを使うべきだという考えではありません。クローズドモデルとオープンモデルを用途に応じて組み合わせ、セキュリティ担当者が自ら検査・変更・運用できる防御手段を確保することが目的です。AIエージェントが外部システムを自律的に操作するようになるなか、モデルの回答内容だけを監視する方法では十分ではありません。今後は、AIへ与えるID・権限・ツール・実行環境・ログ・停止手段まで含めた「エージェント全体のセキュリティ」が、生成AI開発の重要な基準になります。
