NVIDIAらがOpen Secure AI Allianceを発足しNOOAを公開｜エージェント運用の現場に効くこと・効かないこと

2026年7月27日、NVIDIAが多数の企業・団体とともに「Open Secure AI Alliance」の発足を公表しました。あわせて、NVIDIA Labsのエージェント研究フレームワーク「NOOA」がGitHubでオープンソース公開されています。業界団体の発足はニュースとしては大きく扱われますが、実際にエージェントを本番で動かしている側からすると、知りたいのは「明日からの設計が何か変わるのか」です。この記事では、NVIDIAの公式ブログとGitHubリポジトリ、論文といった一次情報で確認できる範囲に絞って内容を整理し、そのうえで自社の設計に効く部分と、依然として自分で手当てするしかない部分を切り分けます。

まず何が発表されたのかを確認する#

NVIDIAの公式ブログ「Industry Leaders Join Open Secure AI Alliance for AI Safety and Security」(2026年7月27日付)によれば、Open Secure AI Allianceは「AIの時代においてソフトウェアとエージェントを守るための、オープンな技術・手法・ツールを開発し共有する動き」と位置づけられています。ゼロから作られた組織というより、既存の取り組みの上に乗る形をとっており、ブログはLinux Foundationの「Akrites」イニシアチブのリーダーシップとOpenSSFのコミュニティ活動を土台にすると明記しています。

Akritesは、Linux Foundationが2026年6月25日に発表した取り組みです。公式プレスリリースによれば、重要なオープンソースソフトウェアの脆弱性を悪用される前に発見・修正し、責任ある開示を行うための業界横断イニシアチブで、共有のセキュリティインシデント対応チーム(SIRT)と標準化された協調的脆弱性開示プロセスを運営します。Open Secure AI Allianceは、この土台の上で「オープンな技術を用いて脆弱性を修正し開示する」役割を担うと説明されています。

参加社数の数字が資料によって違う#

先に、細かいながら混乱しやすい点を片付けておきます。参加社数の数字が情報源によってばらついています。The Hacker Newsは「NVIDIAと他36組織で計37」、Help Net Securityは「NVIDIAと他26社」と書いており、一方でNVIDIAの公式ブログには、本記事作成時点(2026年7月29日)でNVIDIA自身を含む52の企業・団体名が列挙されています。

これは矛盾というより、時間差と考えるのが自然です。公式ブログの当該箇所は「Leaders across ... including(以下の名前を含むリーダーたちが)発足パートナーである」という書き方で、列挙は網羅リストではありません。社内資料に数字を書くなら、いつの時点の何を数えたのかを添えるのが安全です。

公式ブログに名前が挙がっている中には、クラウド・セキュリティ・エンタープライズソフトウェアの大手(Microsoft、IBM、Red Hat、Dell Technologies、Cisco、Cloudflare、CrowdStrike、Palo Alto Networks、Fortinet、Zscaler、Databricks、Snowflake、Salesforce、SAP、ServiceNow、Siemens、GitHubなど)に加えて、Hugging Face、Mistral、LangChain、vLLM、Thinking Machines Lab、Nous Research、Reflection AI、Perplexity、SpaceXAIといったAI寄りの名前、そしてLinux Foundationが含まれます。報道ベースでは、OpenAI・Google・Anthropicが発足時のリストに見当たらない点が指摘されています。

なぜいまこの動きなのか#

公式ブログは、発足の文脈として直近のHugging Faceのセキュリティインシデントを名指しで挙げています。同社の開示によれば、インシデント対応でログ解析にAIを使おうとしたところ、攻撃コマンドやエクスプロイトのペイロードを大量に投入する必要があるため商用APIのガードレールにブロックされ、結果としてオープンウェイトモデル(GLM 5.2)を自社インフラで動かして1万7千件を超える攻撃者アクションを解析し、侵入を封じ込めました。

NVIDIAのブログはこの経緯を引いて、「防御側が自分のインフラ上で先端AIを検査し、適応させ、実行できないとき、まさに速度が最も重要な瞬間に対応能力が制約される」と述べています。つまりこのアライアンスの主張の核は、モデルの性能競争ではなく「インシデント対応の現場で使えるAIを、防御側が自分で持てるようにする」という点にあります。

同時に、ブログは開かれたモデルの悪用リスクを否定していません。オープンモデルもセーフガードを弱める試みやサイバー攻撃への転用を含めて悪用されうる、ただしそれらのリスクはオープンなシステムに固有のものではなく、先端AIが展開される場所ではどこでも管理されなければならない、という書き方をしています。オープン対クローズドの二者択一ではなく「両方必要」という立場を明示している点は、読み取っておくべきニュアンスです。

対象範囲は「エージェントスタック全体」#

技術的に最も重要なのは、アライアンスがスコープをどこに置いたかです。公式ブログは次のように述べています。AIエージェントは単なる言語モデルではなく、モデル・ハーネス・ガードレールから成る複雑なシステムである。したがって現実のAIの安全性とセキュリティは、モデルの重みが公開か非公開かだけでなく、アイデンティティ・権限・ハーネス・ガードレール・ログ・評価というスタック全体に依存する、と。

そのうえで、アライアンス全体としては「アイデンティティと分離から、安全なモデルフォーマット、マルチモデルのスキャン、セキュアなコーディングワークフローまで」を対象に、エージェント向けのオープンな防御スタックを構築すると書かれています。ブログで名前が挙がっている具体的な貢献は次のとおりです。

この一覧を眺めると方向性が見えてきます。並んでいるのは新しい発明ではなく、既存のセキュリティ原則をエージェントに適用し直すための部品です。ワークロードIDの検証、実行時にコードを走らせないシリアライズ形式、署名付きパッチ、スキャン、隔離。どれも従来のインフラセキュリティで見慣れた概念であり、それを「エージェントという新しい実行主体」に当てはめようとしている、と読むのが正確です。

NOOAは何をするフレームワークなのか#

もうひとつの発表がNOOA(NVIDIA Labs Object-Oriented Agent、リポジトリ名はlabs-OO-Agents)です。ライセンスはApache 2.0で、GitHubで公開されています。技術報告は2026年7月22日にarXivへ投稿された「NVIDIA-labs OO Agents: Native Python Object-Oriented Agents」(arXiv:2607.20709)です。

中心にある考え方は単純で、「エージェントは1つのPythonオブジェクトである」というものです。論文の記述に沿えば、メソッドがモデルの取りうるアクション、フィールドが状態、docstringがプロンプト、型アノテーションが契約になります。そしてメソッドの本体が...だけの場合、そのメソッドは実行時にLLM駆動のループで実装され、通常の本体を持つメソッドは決定的なPythonのまま残ります。

from nooa import Agent


class FeedbackAgent(Agent, llm=llm):
    """You are an agent specializing in analyzing customer feedback."""

    # 本体が ... のメソッドは実行時にLLMが実装する
    async def analyze_feedback(self, text: str) -> str:
        """Analyze customer feedback for sentiment and key topics in one sentence."""
        ...

READMEはこの設計の狙いを、「エージェントの振る舞いを、他のソフトウェアと同じようにテスト・トレース・リファクタリング・バージョン管理できるようにする」ことだと説明しています。プロンプトテンプレート、ツールスキーマ、コールバック、ワークフローグラフが別々の抽象に散らばる従来のやり方に対して、それらをPythonクラス1つに寄せる、という提案です。

論文は、NOOAが1つの面に組み合わせた「モデルに向いた6つのアイデア」として、型付き入出力、ライブオブジェクトの参照渡し、アクションとしてのコード実行、プログラム可能なループ設計、明示的なオブジェクト状態、コンテキストとイベントに対するモデル呼び出し可能なハーネスAPI、を挙げています。個々の要素はコミュニティでも部分的に採用が進んでいるとしたうえで、それらを1つのインターフェースに統合した点を貢献としています。

性能の主張と、その読み方#

NVIDIAの技術ブログは、ハーネス設計がベンチマーク結果に二桁のスイングをもたらしうると述べたうえで、NOOAの測定値を公開しています。SWE-bench VerifiedでGPT-5.5と組み合わせて82.2%(投稿時点の公開リーダーボードのSOTAは79.2%)、Opus 4.6で79.8%を、ベンチマーク固有のプロンプトを持たない253行の汎用エージェントで達成したとしています。サイバーセキュリティ領域では、CyberGym L1でGPT-5.5と組み合わせて86.8%を、ネットワークアクセスを遮断し全軌跡にルールベースの「カンニング検査」をかけた条件で測定したと説明されています。効率面では、SWE-bench Verifiedにおいてタスクあたり29回のLLM呼び出しと約110万トークンで82.2%に達する一方、比較対象のハーネスは66回・220万トークンで78.2%だった、という主張も添えられています。

「入れれば安全になる」わけではない#

ここが実務上いちばん重要な点です。NOOAのREADMEは、安全性について踏み込んで注意書きをしています。曰く、NOOAは研究用ソフトウェアであり、エージェントはLLMが生成したコードを実行するよう構成できる。生成されたコードは、私的なデータを制御外の場所へ送る、ファイルを削除する、環境を改変するといった危険または望まない動作をしうる。したがって主ファイルシステムから隔離されたサンドボックス環境で実行すること、と。

さらに具体的です。NOOAは生成コードをASTチェックで検証し、実行前にモジュールの拒否リストを適用しますが、READMEはこれを「多層防御のガードレールであって封じ込め境界ではない」と明言しています。理由も書かれています。Pythonに対する静的チェッカーでは保証を与えられない。open()は任意のファイルアクセスを与えるし、importlibはパスから直接モジュールを読み込めるし、リフレクションが残りに手を伸ばす、と。そのうえで「封じ込め境界はOSレベルの隔離である」とし、コンテナ・VM、あるいはNVIDIAが公開しているOpenShellのようなサンドボックスの中で実行するよう求めています。

OpenShell自体もGitHubで公開されているApache 2.0のプロジェクトで、READMEによれば自律エージェントを安全に実行するためのランタイムです。ポリシーで強制されるegress(外向き通信)ルーティング、ネットワーク・ファイルシステム・プロセスに対するYAMLベースのポリシー、サンドボックスへ鍵を露出させずにAPIキーを注入する資格情報のプロバイダといった機能が挙げられています。ただしREADMEはプロジェクトをアルファ段階と自己申告しており、本番導入の前提で読むべきものではありません。

現場の何が変わり、何が変わらないのか#

整理します。まず、変わらないことです。

アライアンスの発足によって、自社のエージェント基盤のセキュリティが自動的に改善することはありません。本記事作成時点で公開されているのは、発足の宣言と参加者リスト、各社の既存プロジェクトの紹介、政策提言、そしてNVIDIAのNOOAというコードです。NVIDIAが用意した参加窓口のページも問い合わせフォームで、憲章・運営体制・技術ワークストリーム・成果物のスケジュール・共有リポジトリといった情報は掲載されていません。The Hacker Newsもこの点をガバナンスの空白として指摘しています。現時点では「意思表明の段階」と読み、具体的な成果物が出てから評価するのが妥当です。

また、エージェントの権限設計・分離・監査ログという課題の中身も変わりません。どのツールをどの権限で呼べるか、外向き通信をどこまで許すか、資格情報をどう分離するか、どのログをどこに残すか。これらは引き続き各社が自分の環境で決める問題です。

一方で、変わる可能性があるものは3つあります。

1つ目は、部品の共通化です。エージェントのIDにSPIFFE/SPIRE、モデル重みの受け渡しにsafetensorsといった選択肢が業界の合意に近づけば、自社で独自方式を作る理由が減ります。広く使われているものを使うことは、監査対応や外部連携のコストを下げます。

2つ目は、防御側がオープンモデルを自社インフラで動かす構成の正当性です。これまでその構成はコストや性能の文脈で語られがちでした。インシデント対応で商用APIのポリシーに阻まれるという具体的な失敗例が業界共通の参照点になったことで、可用性と主権の文脈で説明しやすくなります。

3つ目は、政策の議論の枠組みです。ブログは政策担当者と規制当局に対して、オープンモデル・ハーネス・セキュリティツールを負債ではなく防御資産として認識するよう求め、オープンな先端AIシステムへの一律の制限は防御能力を弱めると主張しています。業界側のポジションであって決定事項ではありませんが、今後の規制議論の対立軸を示す材料にはなります。

いま自社でできることに落とす#

標準の整備を待つ必要がない部分から手をつけるのが現実的です。エージェントを本番または本番相当の環境で動かしているなら、次の項目を点検してみてください。

点検の順序としては、次のように進めると詰まりにくいです。

社内で説明するときの論点#

最後に、社内で共有するときの論点を短くまとめます。

• 発足そのものは、自社のセキュリティ水準を変えない。変わるのは、部品の共通化が進む見通しと、防御側がオープンモデルを持つ構成の説明のしやすさ。
• スコープの置き方(モデル単体ではなくエージェントスタック全体)は、自社の点検項目の設計にそのまま流用できる。
• NOOAは、エージェントを通常のソフトウェアとして扱うためのフレームワークであり、研究用ソフトウェアと明示されている。可視性は上がるが、隔離は依然としてOS側の責務。
• 参加社数や成果物のスケジュールなど、まだ確定していない情報が多い。数字を引用するときは、いつ時点の何かを添える。

アライアンスの発足日(2026年7月27日)、ミッションの文言、発足パートナーの列挙、対象範囲(アイデンティティ・権限・ハーネス・ガードレール・ログ・評価、およびアイデンティティと分離から安全なモデルフォーマット・マルチモデルスキャン・セキュアコーディングワークフローまで)、各社の貢献(SPIFFE/SPIRE、Safetensors、Lightwell、MDASH、Grok Build)、政策提言の内容は、NVIDIA公式ブログ「Industry Leaders Join Open Secure AI Alliance for AI Safety and Security」(2026年7月27日)に基づきます。参加者の列挙は「including」と書かれた例示であり、網羅リストではありません。参加社数は本記事作成時点(2026年7月29日)の公式ブログ掲載を数えたもので、報道各社の数字とは差があります。NOOAの設計・ライセンス(Apache 2.0)・安全上の注意書き・トレース機能・インストール方法はGitHubリポジトリ(NVIDIA-NeMo/labs-OO-Agents)のREADMEに、6つのアイデアと位置づけはarXiv:2607.20709に、ベンチマーク数値はNVIDIA技術ブログ「Six Agent Harness Capabilities for Higher Model Performance」に基づく自社公表値です。Akritesの発足日(2026年6月25日)と役割はLinux Foundationのプレスリリース、Hugging Faceのインシデント対応の詳細は同社が2026年7月16日に公表した開示文、OpenShellの機能とアルファ段階という位置づけは同リポジトリのREADMEに基づきます。ガバナンス情報が未公開である点は、NVIDIA公式ブログと参加窓口ページの記載範囲を確認した結果です。参加社数の食い違い、特定企業が発足リストに含まれないという指摘、ガバナンスの空白という評価は報道ベースです。

よくある質問#

まとめ#

Open Secure AI Allianceの発足は、業界が「エージェントのセキュリティは、モデル単体ではなくスタック全体の問題である」という認識を共有し始めたことを示すものです。アイデンティティ、権限、ハーネス、ガードレール、ログ、評価という並びは、そのまま自社の点検リストとして使えます。同時に公開されたNOOAは、エージェントを通常のPythonオブジェクトとして扱うことで、テストとトレースとレビューを既存のソフトウェア開発と同じ道具に載せようとする提案です。

ただし、着地点は冷静に置く必要があります。団体ができたことも、フレームワークが公開されたことも、それ自体は自社の安全性を高めません。NOOAのREADMEが自ら「これは封じ込め境界ではない」と書いているとおり、隔離と権限設計と監査という地味な作業は各社の手元に残ります。この発表の実務的な価値は、その地味な作業の項目を業界共通の言葉で示してくれた点にあります。まずは自社で最も自律度の高い構成を1つ選び、隔離の実体がどのレイヤーにあるのかを図に落とすところから始めてみてください。標準の整備を待つ理由は、そこにはありません。