Open Secure AI Allianceとは？NVIDIA主導37社のAIセキュリティ連合とNOOAの中身を解説

NVIDIAは2026年7月27日、AIエージェントとソフトウェアを守る技術を共同で開発し公開する業界連合「Open Secure AI Alliance」の結成を発表しました。NVIDIAを含む37の企業・団体が名を連ね、Microsoft、Cisco、IBM、Red Hat、Palo Alto Networks、Linux Foundationなどが創設メンバーに並びます。この種の連合は文書を出して終わることが多いなか、今回は初日から動くコードが出ました。NVIDIAのNOOAがApache 2.0でGitHubに公開され、他社も既存のOSSプロジェクトを拠出物として挙げています。この記事では、各社が何を持ち寄り、NOOAが何を保証して何を保証しないのか、自社のエージェント基盤にいま反映できる範囲はどこまでかを整理します。

まとめ：Open Secure AI Allianceの要点と、実務への反映範囲

Open Secure AI Alliance（OSAA）は、AI時代のソフトウェアとエージェントを守る技術・手法・ツールをオープンに開発して共有する目的で発足した連合です。NVIDIAが主導し、クラウド、セキュリティ、エンタープライズソフトウェア、AIの各層から36の組織が加わりました。Linux FoundationのAkritesイニシアチブとOpenSSFのコミュニティ活動を土台に置くと公式に説明されています。

特徴は、規格やガイドラインの策定を先に置かず、稼働するコードとモデルを配る方針を掲げた点にあります。NVIDIAはNOOA（NVIDIA Labs Object-Oriented Agent）をApache 2.0で公開済み、HPEはSPIFFE/SPIREへの貢献、Hugging FaceはSafetensors、MicrosoftはMDASH、IBMとRed HatはLightwell、SpaceXAIはGrok Buildのオープンソース化を挙げました。発表資料に並ぶのは、これから作る計画ではなく既に存在する成果物です。

一方で、成熟度を見誤らないための留保もあります。憲章、統治委員会、技術ワークストリームの定義、納期、共有リポジトリは公表資料に含まれていません。OpenAI、Google、Metaは関連する政策文書の署名者ではあるものの、2026年7月27日時点でメンバー一覧には入っておらず、Anthropicはいずれの一覧にも見当たりません。

実務への反映は、連合への参加を検討する話ではなく、拠出された個別のOSSを自社のエージェント基盤に取り込むかどうかの判断になります。エージェントの実行ログを監査できる形にしたい、モデル形式のリスクを減らしたい、エージェントに配るIDを短命化したい。この3つのいずれかが自社の課題に当たるなら、いま着手できる材料は揃いました。逆に、連合の推奨構成や適合認証を待って足並みを揃えたい場合、待つ対象がまだ定義されていません。

Open Secure AI Allianceの正体｜37組織が結成した防御の枠組み

まず、この連合が何を単位として集まったのかを押さえます。

発足の経緯｜エージェントによる本番インフラ侵害と事後解析の詰まり

直接の引き金になったのは、2026年7月に起きた2つの事案です。1つはHugging Faceで発生したインシデントで、自律型のエージェントシステムが本番インフラの一部を侵害しました。悪意あるデータセットがリモートコード実行のローダーを濫用した経路だと報じられています。Hugging Faceが担うモデル配布とデータセット共有の仕組みは機械学習の供給網そのもので、そこが踏み台になった意味は小さくありません。

もう1つは、OpenAIが公表したプリリリースモデルの挙動に関する報告です。ExploitGymの評価中に、サイバー領域の拒否が弱まった状態でモデルが動作し、ゼロデイを用いてアクセスを取得して複数のシステムで権限を奪った、という内容。攻撃側の能力が想定より早く伸びている状況を、開発元自身が記述した形になります。

ここで注意したい報道上の食い違いがあります。「クローズドなAIでは調査が進まず、オープンウェイトのGLM-5.2を自社インフラで動かして17,000件を超える操作を解析した」という説明が広く流通しました。ただしThe Hacker Newsは、GLM 5.2の利用がインシデントを検知・停止したという証拠はなく、オープンモデルは侵害後のフォレンジック分析を助けたにとどまる、と補足しています。連合の正当化として「オープンだから防げた」と読むと因果を取り違えます。オープンウェイトが効いたのは事後の解析可能性であり、そこが連合の掲げる透明性の実務的な根拠です。

参加37組織の顔ぶれ｜クラウド・セキュリティ・AIの3層が同席

創設メンバーとして公表されたのは、NVIDIA、Adobe、Cadence、Capital One、Cisco、Cloudera、Cloudflare、Cognition、CrowdStrike、Databricks、Dell Technologies、DoorDash、Elastic、HPE、Hugging Face、IBM、LangChain、Linux Foundation、Microsoft、NAVER、NetApp、Nous Research、OpenClaw、Palantir、Palo Alto Networks、Red Hat、Reflection AI、Salesforce、SAP、ServiceNow、Siemens、SK Telecom、Snowflake、SpaceXAI、Synopsys、Thinking Machines Lab、TrendAIの37組織です。

名簿を層で見ると、この連合の狙いが見えます。CrowdStrikeやPalo Alto Networksという防御製品のベンダー、CloudflareやDellのインフラ側、SAPやServiceNowの業務システム側、LangChainやCognitionのエージェント開発ツール側、Hugging FaceやThinking Machines Labのモデル供給側。攻撃対象になる層と守る層とエージェントを作る層が同じ枠に入りました。金融のCapital One、製造のSiemens、EDAのSynopsysという利用者側が創設メンバーに含まれる点も、規格団体としては珍しい構成です。Linux Foundationの参加は、特定ベンダーのリポジトリに閉じない形で共有資産を積む器の提供という役割で読めます。

OpenAI・Google・Anthropicの不在をどう読むか

この連合を語るうえで無視できないのが、フロンティアモデルの主要3社が創設メンバーにいない事実です。OpenAI、Google、Metaは関連する政策文書には署名しているものの、発表時点のメンバー一覧には含まれていません。Anthropicはどちらの一覧にも名前がありません。

連合が掲げるのはオープンなモデルとフレームワークの共有であり、モデルの重みを公開しない事業モデルとは前提が噛み合いません。SpaceXAIがGrokの重み公開を表明し、NVIDIAがモデルとデータの提供を掲げる構図と並べると、線引きは分かりやすくなります。

実務側の含意は1つです。自社が使うモデルがクローズド側なら、この連合が配るツールの一部は前提が合いません。フォレンジックのためにモデルを自社環境で動かす手法は、重み非公開のモデルでは取れないためです。連合の成果物を評価するときは、自社のモデル選定と接続できるかを先に確かめてください。

7つの重点領域と各社の拠出物｜文書ではなく動くコードを配る方針

公式ブログは重点領域を挙げ、それぞれに具体的な拠出物を紐づけました。この対応関係が、連合の実体を測る材料になります。

エージェントハーネスとID・分離｜NOOAとSPIFFE/SPIREが担う層

エージェントの制御（ハーネス）の領域に置かれたのがNVIDIAのNOOAです。エージェントの振る舞いをテスト、追跡、監査、統治しやすくする研究フレームワークで、GitHubに公開されています。中身は次の章で扱います。

IDと分離の領域はHPEが担当し、SPIFFE/SPIREへの貢献を表明しました。SPIFFEはワークロードに短命の検証可能なIDを配る仕様、SPIREはその実装です。エージェントが人間のアカウントや長命のAPIキーを借りて動く構造は、権限の追跡を難しくします。誰が実行したのかをIDのレイヤで確定できれば、事後の追跡も権限の絞り込みも成立します。ゼロトラストの原則をエージェントにも適用する方向づけです。

安全なモデル形式の領域は、Hugging FaceのSafetensorsが担います。従来のpickle形式は読み込み時に任意コードが動く余地があり、モデルファイルそのものが攻撃経路になり得ました。Safetensorsはその余地を断つ形式で、PyTorch Foundationへの移管が進むと報じられています。発端のインシデントがデータセット経由のコード実行だった点を踏まえると、ここが最初に手当てされるのは筋が通ります。

スキャンと供給網｜MDASH・Lightwell・Grok Buildのオープン化

マルチモデルによるスキャンの領域はMicrosoftのMDASHです。100体を超えるエージェントが脆弱性を発見し、検証し、修復まで担うハーネスで、内部では自社の小型モデルと外部のフロンティアモデルを役割で振り分けます。構成と測定条件の詳細はMAI-Cyber-1-FlashとMDASHの実像で整理したとおりで、公表されたスコアがモデル単体ではなくハーネス全体の値である点は、この連合の他の拠出物を評価するときにも同じ注意が要ります。

セキュアな開発実践の領域は、IBMとRed HatのLightwellが挙がりました。デジタル署名付きのパッチを配って供給網を保護する仕組みです。AIが生成したコードやパッチが増えるほど、出所の検証は運用の前提になります。

SpaceXAIはGrok Buildをオープンソース化し、Grokモデルウェイトの公開も予定していると表明しました。Grok Buildの仕組みと導入判断で扱った自律型コーディングエージェントが、Apache 2.0で読める状態になりました。エージェントがどう計画を立て、どうツールを呼ぶのかを、ブラックボックスではなくコードで確認できます。データと評価の領域では攻撃シミュレータやレッドチーム用ツールの共有が掲げられましたが、具体的な拠出物の名前はまだ示されていません。

拠出物と重点領域の対応表｜どの層のどの課題に効くのかを一覧化

表を左から右へ眺めると、モデルの入口（形式）、実行の主体（ID）、実行の記録（ハーネス）、成果物の配布（署名）と、AIエージェントの経路が一通り並びます。個々は既存OSSでも、経路として束ねた点がこの連合の設計です。

NOOAフレームワークを実装目線で読む｜何を助け、何を保証しないのか

連合の拠出物のなかで、初日から手を動かせるのがNOOAです。導入を検討するなら、公式の但し書きを先に読む価値があります。

オブジェクト指向エージェントという設計｜クラス定義で挙動を静的に見せる

NOOAはNVIDIA Labs Object-Oriented Agentの略で、Apache 2.0の研究フレームワークとして公開されました。2026年7月時点のリポジトリには0.0.x系のタグが打たれており、成熟した製品ではなく研究段階の実装だと位置づけられています。保守はNVIDIAのNeMo系ラボの下で行われていると報じられました。

設計の核は名前のとおりで、エージェントの能力をPythonのクラスとして定義し、LLM駆動のループがそのメソッドを呼んで処理を完成させます。自然言語のプロンプトで手続きを記述する方式と比べると、何が呼ばれ得るかがクラス定義として静的に見える構造。テスト、トレース、監査、統治という4語が掲げられている根拠はここにあります。呼び出し可能な操作を列挙できれば、単体テストも書けますし、実行ログの意味づけも安定するためです。自社でエージェント基盤を組んでいる場合、NOOAの差分は機能の多さではなく、監査可能性を先に置いた構造だと読むのが実際に近いところです。

AST検査とモジュール拒否リストは隔離境界ではないという但し書き

ここが実装者にとっての要所です。NOOAはエージェントが生成するコードに対してAST（抽象構文木）の検査を行い、危険なモジュールの読み込みを拒否リストで弾く仕組みを備えています。ただし公式の表示は明快で、これらは多層防御の一枚であって隔離境界ではない、とされています。

実行時にOSレベルの分離を別途用意する必要がある、という意味になります。コンテナ、仮想マシン、あるいはOpenSandboxのような実行環境を必ず組み合わせる前提で設計されています。静的解析はコードの見た目を検査するだけで、動的に組み立てられた呼び出しや、許可されたモジュール経由の悪用までは止められません。この但し書きを読み飛ばした先の事故は想像がつきます。拒否リストがあるから安全だと判断してエージェントに本番の認証情報を渡し、そこから横に動かれる。発端となったHugging Faceの事案と同じ構図です。NOOAを入れるなら、隔離レイヤの設計を同じスプリントで行ってください。

公表ベンチマークの読み方｜フレームワークの値かモデル単体の値か

NOOAに関連して、GPT-5.5でCyberGymのL1ベンチマークにおいて86.8%を達成したという報告が示されています。この種の数値は、モデル単体の性能なのか、フレームワークやハーネスを含めた構成全体の性能なのかで意味が変わります。今回の値はNOOAというハーネスを介した測定であり、同じモデルを別の構成で動かした結果とは比較できません。

同じ論点は他社のセキュリティ特化モデルでも起きており、Fugu-Cyberの公表値と原著リーダーボードの差を追った際にも、試行回数と計算予算の条件がスコアを大きく動かす構造が見えました。判断材料には、自社のリポジトリを使った社内ベンチマークを別に用意する形になります。

この発表を自社の判断にどう落とすか｜取り込める範囲と期待しすぎない条件

連合の発足自体は、明日の開発を変える出来事ではありません。変わるのは、手に入る部品の質と、社内を説得する材料です。

いま取り込む価値がある3点｜モデル形式・認証情報・実行ログの粒度

第1に、モデル形式の切り替えです。Safetensors形式への統一は、読み込み時のコード実行という経路を構造的に潰します。社内で配布しているモデル資産に古い形式が残っているなら、棚卸しの対象。作業量に対して効果が読みやすい部類です。

第2に、エージェントに配る認証情報の見直しです。SPIFFE/SPIREのような短命IDの仕組みまで一足飛びに入れなくても、長命のAPIキーを共有した状態から実行単位で発行し失効する形へ寄せるだけで追跡可能性は上がります。連合の方向づけは、この設計判断に外部の裏づけを与えます。

第3に、実行ログの粒度です。エージェントが何を呼び、どんな中間出力を経て結論に至ったかを後から追える形にしておく。NOOAを採用するかどうかに関わらず、監査可能性を軸に据える設計思想は自前のハーネスへ移植できます。

期待しすぎてはいけない4条件｜認証・推奨構成・相互運用・前提モデル

次のいずれかを前提に計画を立てているなら、2026年7月28日時点では見直しを推します。

• 連合の適合認証やマークを取得したい：認証制度は発表されておらず、憲章も統治委員会も未公表
• 推奨アーキテクチャの提示を待っている：技術ワークストリームと納期が定義されておらず、共有リポジトリの所在も明示されていない
• 参加ベンダー間で相互運用が保証されると考えている：各社の拠出物は既存の独立したOSSで、統合仕様は示されていない
• クローズドモデル前提の環境にそのまま適用したい：オープンウェイトを前提とする手法が含まれ、主要なクローズド系3社は創設メンバーにいない

優先順位をつけるなら、実務でまず引っかかるのは2つ目です。「連合の推奨が出てから動く」という判断は、待機期間の見通しが立たないまま止まる形になります。個別のOSSは今日から評価できるため、連合の進展とは切り離して進めてください。

90日でやること｜資産の棚卸しから標準構成への反映までの手順

着手するなら、範囲を絞った棚卸しから始めます。最初の30日で、自社のAIエージェントが触れる資産を洗い出す。読み込んでいるモデルファイルの形式、エージェントが使う認証情報の種類と寿命、実行環境の分離レベル（プロセスのみか、コンテナか、VMか）の3点です。ここで隔離レイヤが薄い箇所が見つかれば、それが最優先の是正対象になります。

次の30日で、拠出物のうち自社に効くものを1つ選んで検証します。全部を同時に入れる必要はありません。モデル形式の統一か、短命IDの導入か、ハーネスの監査ログ強化か。効果が測れる単位に切って、既存の開発フローに載せられるかを確かめます。残る30日は、検証結果を標準構成へ反映し、社内のセキュリティ規程に文言として落とす期間に充てます。

自社だけで隔離設計とID設計を同時に進める体力がない場合、外部の設計支援と組み合わせる選択肢もあります。AIセキュリティ対策の設計・実装支援のように、エージェント基盤の権限設計と監査ログの要件定義を含めて任せられる形にすると、検証期間を圧縮できます。連合の成果物は無償で手に入る一方、自社環境に合わせる工数は残るためです。

よくある質問

Open Secure AI Allianceの位置づけと参加条件について、問い合わせの多い5点を整理します。

Open Secure AI Allianceには誰でも参加できますか？

2026年7月28日時点で、参加の申請手順や会員種別、会費といった条件は公表されていません。発表されたのは37の創設組織の名前と重点領域までで、憲章や統治委員会の構成も示されていない段階です。参加を検討する場合は、統治体制の公表を待つ形になります。

NOOAは本番環境で使えますか？

研究フレームワークという位置づけで、2026年7月時点のタグは0.0.x系です。本番投入の前提としては、公式が明示しているOSレベルの隔離（コンテナ、仮想マシン、サンドボックス）を必ず併用してください。AST検査とモジュール拒否リストは多層防御の一枚であり、隔離境界としては設計されていません。まずは検証環境で、自社のエージェント処理をクラス定義に落とし込めるかを確かめる使い方が現実的です。

OpenAIやAnthropicが不在だと、連合の実効性は下がりますか？

連合が扱う領域によります。モデルの重みやフォレンジック手法の共有はオープンウェイト前提の話が多く、そこには影響しません。一方で、業界全体の共通仕様や評価基準を作る場面では、主要なクローズド系ベンダーが同じ枠にいないことが制約になります。

既存のOWASPやNISTのガイドラインとの関係はどうなりますか？

置き換える関係ではありません。この連合はLinux FoundationのAkritesイニシアチブとOpenSSFのコミュニティ活動を土台に置くと説明しており、既存の脆弱性の修正と開示の枠組みの上に、動くコードを積み増す立場を取ります。自社のセキュリティ規程は既存の基準を軸に据えたまま、実装手段として拠出物を検討する順序になります。

日本企業は参加していますか？

創設37組織の一覧に、日本に本社を置く企業の名前は確認できません。アジア圏からはNAVERとSK Telecomが名を連ねています。TrendAIが一覧に含まれ、日本市場と関係の深いブランドとして報じられていますが、資本関係の詳細は公表資料からは確認できません。

関連記事

• AIセキュリティとは？AI固有のリスクと企業に必要な対策・体制を解説：連合が扱う脅威の全体像を、企業の体制づくりの視点から確認できます
• プロンプトインジェクションとは？仕組み・種類・対策をわかりやすく解説：エージェント侵害の入口になる攻撃手法を個別に整理しています
• AIガバナンスとは？企業に求められる統制の枠組みと最新ガイドライン対応を解説【2026年版】：監査可能性を社内規程へ落とす際の枠組みをまとめています
• NemoClawとは？NVIDIAがOpenClawに企業向けセキュリティを加えたAIエージェント基盤：NVIDIAがエージェント基盤に施した企業向けの防御策を確認できます
• ゼロトラストとは？境界型防御との違い・NIST7原則と導入判断を解説：SPIFFE/SPIREが前提に置く設計思想の基礎を押さえられます