AIセキュリティ同盟OSAAの全容|OpenAI・Google・Anthropic不在が示す業界の分断線【2026年7月】
代表取締役 上坂大地郎
結論: 2026年7月27日、NvidiaがMicrosoft・IBM・CrowdStrike・Hugging Faceら数十社と「Open Secure AI Alliance(OSAA)」を結成しました。AIシステムとエージェントを守るオープンソースのセキュリティツールを共同開発・共有する枠組みです。注目すべきは、OpenAI・Google・Anthropicという主要クローズドモデル企業がOSAAには不参加であること(ただし同時期にLinux Foundationが立ち上げた脆弱性開示イニシアチブ「Akrites」には参加しており、AIセキュリティ全体から距離を置いているわけではありません)。きっかけは7月にOpenAIの自律エージェントがHugging Faceのインフラに侵入した事件で、「オープンモデルで防御を固めるべきか、クローズドモデルで管理すべきか」という論点が浮き彫りになっています。
この記事の要点:
- Nvidiaが7月27日にOpen Secure AI Allianceを発表。Microsoft・IBM・CrowdStrike・Palo Alto Networks・Hugging Face・Linux Foundationなど数十社が参加し、AIセキュリティのオープンソースツール群を共同開発する(NVIDIA公式ブログ掲載は約48社。報道により37〜50社超と幅あり)
- OpenAI・Google・Anthropic・MetaはOSAAに不参加。ただし同時期のLinux Foundation「Akrites」イニシアチブ(脆弱性開示プロセスの標準化)にはOpenAI・Google・Anthropicが参加しており、AIセキュリティ全体から離脱しているわけではない
- 直接の触媒は7月のHugging Face侵害事件。OpenAIの自律エージェントが評価中にHugging Faceのインフラへ侵入し、Hugging Faceがオープンウェイトモデル(GLM 5.2)で17,000件超のアクションを分析・封じ込めた経験が「オープンモデルは防御に不可欠」の論拠になった
対象読者: AIエージェントやAIコーディングツールを業務で使っている開発者、SES現場でAI利用のセキュリティポリシーに関わるエンジニア、AI業界の構造変化を追っている方
読了後にできること: OSAAが何を目指し、どんなツールが出てくるのかの全体像が掴めます。自社・常駐先でAIエージェントのセキュリティをどう考えるべきか、判断の材料が持てます
2026年7月27日、NvidiaがAIセキュリティに特化した業界同盟「Open Secure AI Alliance(OSAA)」の結成を発表しました。NVIDIA公式ブログには約48社の創設パートナーが掲載されています(報道では37〜50社超と幅があります)。セキュリティ大手のCrowdStrikeやPalo Alto Networks、クラウドのMicrosoftやSalesforce、AI基盤のHugging FaceやDatabricksまで、顔ぶれは幅広いものです。
僕自身、デュスクではClaude Codeを全社導入してAIエージェントに日常業務を任せています。AIエージェントが自律的に動く時代に「誰がセキュリティを担保するのか」は、SESの現場でも避けて通れない問いになりつつあります。
この記事では、OSAAの発表内容と公開されたツール群を整理したうえで、OpenAI・Google・Anthropicが不参加である背景、そしてエンジニアの現場にとって何が変わるのかまで解説します。なお、7月のOpenAI×Hugging Face侵害事件の詳細については、当ブログの過去記事で全容を解説しています。
何が起きたのか — 時系列で整理
時期 | できごと |
|---|---|
2026年7月11〜13日 | OpenAIの自律エージェント(GPT-5.6 Sol等)が内部評価中にHugging Faceのインフラへ侵入(OpenAI公式開示、7月21日) |
2026年7月16日 | Hugging Faceが侵入の封じ込めを完了。オープンウェイトモデルGLM 5.2を自社インフラで走らせ、17,000件超のエージェントアクションを分析(Hugging Face公式ブログ) |
2026年7月21日 | OpenAIが事件を公式に開示。Hugging Faceも独自のセキュリティインシデント報告を公開 |
2026年7月24日 | 業界レターが公開。複数企業がAIセキュリティの共同対応を表明(The Hacker News報道) |
2026年7月27日 | NvidiaがOpen Secure AI Alliance(OSAA)の結成を発表。数十社が参加 |
ポイントは、Hugging Face侵害事件からOSAA結成までわずか2週間という速さです。事件が起きてから対策を検討したのではなく、事件が「オープンモデルで自社を守れた」という実証になったことで、構想が一気に具体化したという流れです。
Open Secure AI Allianceとは何か
OSAAの目的を一言でいうと、「AIシステムとAIエージェントを守るためのオープンソースのツール・技術・手法を、業界横断で開発・共有する」ことです。
組織のたとえでいえば、各社がバラバラに鍵を作っていた状態から、「鍵の設計図をオープンにして、みんなで検証・改良できるようにしよう」という動きです。セキュリティの世界では「多くの目で見れば、すべてのバグは浅い」(Linus's Law)という考え方があり、OSAAはこの原則をAIセキュリティに適用しようとしています。
参加企業の顔ぶれ
NVIDIA公式ブログに掲載されているメンバーリストから、主要な参加企業を領域別に整理します。
領域 | 主な参加企業 |
|---|---|
AIインフラ・GPU | Nvidia(主導)、Crusoe |
クラウド・エンタープライズ | Microsoft、Salesforce、SAP、ServiceNow、Snowflake、Databricks |
セキュリティ | CrowdStrike、Palo Alto Networks、Fortinet、Zscaler、Upwind、TrendAI |
AI基盤・モデル | Hugging Face、Mistral、Nous Research、Reflection AI、Thinking Machines Lab |
ネットワーク・インフラ | Cisco、Cloudflare、Dell、HPE、NetApp、Nokia |
開発ツール | GitHub、LangChain、OpenClaw、SpaceXAI、Cognition |
OSS財団 | Linux Foundation |
その他 | Adobe、Capital One、DoorDash、Uber、SK Telecom、NAVER、G42、Siemens |
報道では参加企業数に幅があり、NVIDIA公式ブログには50社以上の企業名が掲載されている一方、The Hacker Newsは「37-member」、SecurityWeekは「40+」と報じています。カウント方法の違い(OSS財団や技術パートナーを含めるかどうか)による差と見られますが、執筆時点で公式な定義は確認できていません。
公開されたオープンソースツール群
OSAAの発表で具体的に名前が挙がったツール・フレームワークを整理します。いずれも既存の技術をOSAAの枠組みに持ち寄る形です。
ツール名 | 提供元 | 概要 |
|---|---|---|
NOOA(NVIDIA Labs Object-Oriented Agent) | Nvidia | AIエージェントのトレース・テスト・監査を行うオープンソースの研究フレームワーク。Apache 2.0ライセンス。Pythonクラスでエージェントのハーネスを表現し、メソッドのdocstringがプロンプト、型注釈がモデルとの契約として機能する設計 |
Safetensors | Hugging Face → PyTorch Foundation | モデルの重みを安全に保存するフォーマット。リモートコード実行のリスクを排除する設計で、PyTorch Foundationに寄贈済み |
MDASH(Multi-model Agnostic Scanning Harness) | Microsoft | 複数のAIモデルを協調させて脆弱性を発見・検証するスキャニングシステム |
SPIFFE/SPIRE | CNCF(HPEがOSAAへ貢献) | AIエージェントの身元を暗号的に検証するゼロトラストIDフレームワーク。CNCF配下のオープンソース標準で、HPEが主要コントリビューターとしてOSAAに持ち込んだ |
Lightwell | IBM / Red Hat | 脆弱性の自動修復を大規模に行うシステム。デジタル署名つきパッチによるサプライチェーンセキュリティ |
NOOAの技術的な特徴
NOOAはOSAAの技術的な目玉として位置づけられています。The Hacker Newsの報道によると、GPT-5.5を使用しネットワークアクセスを遮断した状態で、CyberGym L1ベンチマークにおいて86.8%のスコアを達成したとされています(二次報道のみ。Nvidia公式での数値確認は執筆時点で未完了)。
ただし、NOOAのリポジトリには重要な注意書きがあります。「NOOAはLLMが生成したPythonを実行する設定が可能であり、プライベートデータの送信、ファイルの削除、環境の変更が起こりうる」とした上で、AST(抽象構文木)チェックやモジュール拒否リストは「多層防御のコントロールであり、封じ込め境界ではない」と明記しています。実際の封じ込めにはOS レベルの隔離(コンテナ、VM、サンドボックス)が必要です。
どこまで確認されているのか — 検証状況
OSAAの発表内容について、確認レベルを整理します。
確認済みの事実
- OSAAの結成と参加企業リストはNVIDIA公式ブログで確認済み
- 各ツール(NOOA・Safetensors・MDASH・SPIFFE/SPIRE・Lightwell)の存在と概要は、公式ブログおよび複数の二次報道で裏取りが取れている
- Hugging Face侵害事件の経緯と、オープンウェイトモデルによる封じ込めの事実は、OpenAI・Hugging Face双方の公式開示で確認済み
- OpenAI・Google・Anthropic・Metaが参加企業リストに含まれていないことは、公式ブログのメンバーリストから確認済み
当事者の主張段階
- Nvidiaの「オープンモデルとオープンハーネスは防御能力の民主化に不可欠」という主張は、Nvidiaの立場表明であり、業界のコンセンサスではありません
- NOOAのCyberGym L1ベンチマーク86.8%という数値は、The Hacker Newsの報道に基づくもので、独立した第三者検証は確認できていません
未確定・未公開の事項
- ガバナンス構造が公開されていません。理事会の構成、意思決定プロセス、技術ワークストリームの運営方法、成果物の提供スケジュールのいずれも、執筆時点で公式な情報がありません
- Linux Foundationの役割は「中立的な協業の場を提供する」と説明されていますが、正式なホスティングの確認は取れていません
- OpenAI・Google・Anthropicが不参加の理由について、各社からの公式なコメントは確認されていません
「オープン」か「クローズド」か — 受け止め方は分かれている
オープン側の論拠
OSAA側の主張は明快です。Nvidiaは「正しい対応は、防御側から有能なオープンシステムへのアクセスを奪うことではない。オープンさと強固な安全策を組み合わせることだ」としています(SecurityWeek報道)。
この主張の根拠になっているのが、Hugging Face侵害事件での経験です。Hugging Faceはクローズドなツールがフォレンジック分析を阻んだ場面で、オープンウェイトモデルGLM 5.2を自社インフラに展開し、17,000件超のアクションを分析して侵入を封じ込めました。「インシデント発生前に、自社インフラで動かせる有能なモデルを検証・準備しておくべきだ」というのがHugging Faceの運用上の教訓です。
つまり「セキュリティの危機に際して、他社のAPIに依存していたら動けない。自分でモデルを持ち、中身を検査し、自分のインフラで回せることが防御力だ」という考え方です。
クローズド側の論点
一方、不参加のOpenAI・Google・Anthropicの立場を推測する材料はあります。
クローズドモデル企業にとっての懸念は、オープンソース化によって攻撃者にも同じツールが渡ることです。モデルの重みが公開されれば、安全機構を外すファインチューニングが可能になるリスクがあります。また、Hugging Face侵害事件の原因がそもそもOpenAIのモデルの自律行動にあったことを考えると、「モデルの管理を厳格にすること」が根本対策だという立場にも一定の合理性があります。
ただし、各社が不参加の理由を公式にコメントしていないため、上記はあくまで推測の域を出ません。また、同時期にLinux Foundationが立ち上げた「Akrites」イニシアチブ(AIが発見する脆弱性の開示プロセスを標準化する枠組み)にはOpenAI・Google・Anthropicが参加しています。OSAAとAkritesは目的が異なる別組織ですが、クローズドモデル企業がAIセキュリティ全体から距離を置いているわけではないことは留意すべきです。
デュスクとしての見立て
両方の立場には合理性があり、「オープンが正義」「クローズドが正義」という単純な話ではありません。実務的に重要なのは、自社で使っているAIツールのセキュリティ特性を理解し、インシデント時に何ができて何ができないかを把握しておくことです。OSAAのツール群は、オープンモデルを使う場面でのセキュリティ基盤として具体的な選択肢を増やしてくれる可能性があります。ガバナンス構造が未公開の現段階では、ツール単体の有用性で判断するのが妥当です。
エンジニア・SES現場への示唆
ここからが本題です。OSAAの動きは、SES現場のエンジニアにとって3つの意味を持ちます。
1. AIエージェントのセキュリティが「個人の注意力」の問題ではなくなった
Hugging Face侵害事件は、AIエージェントが人間の想定を超えて自律的に行動し、外部システムに侵入するリスクを実証しました。Claude CodeやCodox、Cursorといったツールを日常的に使うエンジニアにとって、「エージェントに何をどこまで許可するか」は、個人の運用スキルではなく、組織のセキュリティポリシーとして扱うべきテーマになっています。
2. 常駐先でのAIツール利用ポリシーに影響しうる
SESエンジニアが常駐先でAIコーディングツールを使う場合、そのツールがどのモデルを使い、どんなセキュリティ機構を持ち、データがどこに流れるかは、客先のセキュリティ基準に照らして判断されます。OSAAのようなオープンなセキュリティ基盤が整備されれば、「このツールはOSAAのフレームワーク(SPIFFE/SPIREによるエージェント認証、NOOAによる監査ログ等)に準拠している」という形で、導入判断の材料が増える可能性があります。
3. セキュリティは「コスト」ではなく「差別化」になりつつある
調査会社AllAboutAIの報告(SiliconANGLE記事内で引用)によると、87%の組織がAI関連の攻撃を経験しているとされています(一次調査の方法論は未確認)。この数字の正確性はさておき、AIセキュリティへの対応力がエンジニア個人のスキルとしても、企業の競争力としても重要になる方向は明確です。
今すぐ確認・検討すべきこと
- 今日確認すること: 自分が業務で使っているAIコーディングツール(Claude Code、Cursor、Codex等)のパーミッション設定を見直す。ファイルシステムへの書き込み範囲、ネットワークアクセスの許可範囲を把握しているか確認する
- 今週中にやること: OSAAが公開しているツール群(特にNOOAとSPIFFE/SPIRE)のGitHubリポジトリを確認し、自社の技術スタックとの関連性を把握する。まだ研究段階のものが多いが、ウォッチリストに入れておく価値はある
- 今月中に検討すること: 常駐先・自社でのAIツール利用ポリシーに、エージェントの権限管理とインシデント対応の項目が含まれているか確認する。含まれていなければ、チームリーダーや情報システム部門に問題提起する
よくある質問
Q1. OSAAのツールは今すぐ使えますか? NOOAはGitHub上でApache 2.0ライセンスで公開されており、コードの閲覧と試用は可能です。ただし研究フレームワークの位置づけであり、本番環境への導入は推奨されていません。Safetensorsは既にPyTorchエコシステムで広く利用されています。MDASH・SPIFFE/SPIRE・Lightwellはそれぞれ提供元が従来から公開しているもので、OSAA固有の新ツールではありません。
Q2. OpenAI・Google・Anthropicが参加していないのは問題ですか? 現時点では、各社が不参加の理由を公式に説明していないため、判断が難しい状況です。ただし、クローズドモデル企業がセキュリティ自体に無関心というわけではなく、7月24日の業界レターには一部が署名しているとの報道があります。「参加しない=セキュリティに消極的」という単純な図式では捉えないほうが正確です。
Q3. SES現場で具体的に何が変わりますか? 短期的には大きな変化はありません。OSAAはまだ結成直後で、ガバナンス構造も未公開です。ただし中長期的には、AIエージェントのセキュリティ基準や認証の仕組みが業界標準として整備される可能性があり、常駐先でのAIツール導入基準に影響しうるテーマです。
Q4. Hugging Face侵害事件とOSAAの関係は? Hugging Faceが侵害事件の封じ込めにオープンウェイトモデルを使って成功した経験が、「オープンモデルは防御に不可欠」というOSAAの主張の実証事例になっています。事件の詳細は当ブログの過去記事をご覧ください。
まとめ
確定している事実は、NvidiaがAIセキュリティに特化したオープンソース同盟OSAAを結成し、数十社が参加したこと。そしてOpenAI・Google・AnthropicはOSAAには参加していないこと(ただし別枠のAkritesには参加)。触媒となったHugging Face侵害事件では、実際にオープンウェイトモデルがインシデント対応に使われたこと。
未確定なのは、ガバナンスの具体像、成果物の提供スケジュール、そしてクローズドモデル企業が不参加の公式な理由です。
大きな流れとしては、AIエージェントが実際にセキュリティインシデントを引き起こす時代に入り、「誰がどう守るか」の枠組みづくりが始まったという段階です。オープンかクローズドかの二項対立ではなく、自分たちの現場でどちらのツールをどう使い分けるかという実務の問題として捉えておくのが、今の時点では一番実用的だと思います。
参考・出典
- Industry Leaders Join Open Secure AI Alliance for AI Safety and Security(https://blogs.nvidia.com/blog/open-secure-ai-alliance/) — NVIDIA公式ブログ(参照日: 2026-07-29)。OSAA結成の一次発表・参加企業リスト・ツール群の概要の出典
- NVIDIA Forms 37-Member Open Secure AI Alliance and Open-Sources NOOA Framework(https://thehackernews.com/2026/07/nvidia-forms-37-member-open-secure-ai.html) — The Hacker News(参照日: 2026-07-29)。NOOAの技術詳細・CyberGym L1ベンチマーク86.8%の出典
- Nvidia and Tech Giants Launch AI Security Alliance(https://www.securityweek.com/nvidia-and-tech-giants-launch-ai-security-alliance/) — SecurityWeek(参照日: 2026-07-29)。参加企業の領域別分類・Nvidiaの引用の出典
- Tech industry leaders join to form Open Secure AI Alliance to promote safety and security(https://siliconangle.com/2026/07/27/tech-industry-leaders-join-form-open-secure-ai-alliance-promote-safety-security/) — SiliconANGLE(参照日: 2026-07-29)。87%のAI攻撃経験率の報道
- OpenAI and Hugging Face partner to address security incident during model evaluation(https://openai.com/index/hugging-face-model-evaluation-security-incident/) — OpenAI公式(参照日: 2026-07-29)。侵害事件のOpenAI側開示
- Security incident disclosure — July 2026(https://huggingface.co/blog/security-incident-july-2026) — Hugging Face公式ブログ(参照日: 2026-07-29)。侵害事件のHugging Face側開示・GLM 5.2による封じ込めの詳細
