DockerがOpen Secure AI Allianceに参加し、AIエージェントの信頼を実行環境まで広げる

Dockerは2026年7月30日、NVIDIAのOpen Secure AI Allianceに参加したと発表しました。一次ソースの中心は、AIエージェントの価値そのものではなく、それを企業の中心的なワークフローに置けるほど信頼できるのか、という問いです。

Dockerは、信頼はモデルの知能だけから生まれるものではなく、runtime、identity、governance、securityを含む周辺の層から生まれると説明しています。ここが今回の読みどころですね。AIエージェントを「よく答えるモデル」ではなく、「権限を持って作業するソフトウェア実行主体」として扱う視点に寄っています。

一次ソースでは、Dockerがどの成果物をいつ出すかまでは書かれていません。したがって、この記事ではDockerの参加そのものを確定事実として扱い、具体的なロードマップや担当範囲は未確認事項として分けておきます。

NVIDIAのOpen Secure AI AllianceはオープンなAI防御基盤づくりを掲げる

NVIDIAの公式発表によると、Open Secure AI Allianceは2026年7月27日に発表され、AIの責任ある利用と信頼を支えるオープンなツールを作り共有することを目的にしています。NVIDIA Blogの発表では、Dockerを含む多くの企業・財団・研究組織が初期パートナーとして挙げられています。

このアライアンスの説明では、オープンモデルとクローズドモデルのどちらか一方だけを選ぶ話にはしていません。NVIDIAは、防御側が検証、適応、自前実行できるオープンなモデルやハーネスを持つことを、AI時代のサイバー防御に必要な選択肢として位置づけています。

Dockerの一次ソースも、オープンウェイトモデルとフロンティアモデルを用途に応じて切り替えられることを重視しています。ただし、これはDocker自身の主張であり、どの顧客環境でも同じ採用状況だと断定する材料ではありません。

Hugging Faceの2026年7月インシデントが、ローカルに動かせる防御モデルの必要性を示した

NVIDIAの発表が背景として参照している大きな出来事に、Hugging Faceの2026年7月のセキュリティインシデントがあります。Hugging Faceの公式開示では、侵入は自律的なAIエージェントシステムによって進められ、17,000件を超えるイベントログをLLM駆動の解析エージェントで調べたと説明されています。Hugging Faceの開示では、商用API側の安全ガードにより実攻撃コマンドを含む解析が止まり、最終的にGLM 5.2を自社インフラ上で動かしてフォレンジック解析を行った流れも示されています。

ここから分かるのは、AIセキュリティでは「モデルが高性能か」だけでは判断できないという点です。インシデント対応では、ログや攻撃痕跡、認証情報に近いデータを外部APIへ送れるのか、送るべきなのか、そして安全ガードが防御側の解析を止めないか、という運用上の問題が出てきます。

Dockerの発表がruntimeやgovernanceを強調しているのも、この文脈で読むと自然です。AIエージェントの能力を上げるだけではなく、どこで動き、何に触れ、どの権限で作業し、何を記録できるかまで設計対象に入ってきます。

NOOAはモデルではなくエージェントハーネスの検証しやすさに焦点を当てる

NVIDIAはOpen Secure AI Allianceへの貢献として、NVIDIA Labs Object-Oriented Agent、略称NOOAにも触れています。NVIDIA Developer Blogでは、エージェント開発をコードレビュー、単体テスト、トレース、バージョン管理の対象に近づける設計としてNOOAが説明されています。

公開リポジトリの説明では、NOOAはモデル非依存のPythonフレームワークです。NVIDIA-NeMo/labs-OO-Agentsは、エージェントの状態、能力、プロンプト、型付きインターフェースをPythonクラスにまとめる方向を示しています。モデルの重みそのものではなく、モデルが道具をどう呼び、状態をどう見て、結果をどう返すかを扱う層ですね。

これはDockerの一次ソースにある「信頼はモデルの周辺から生まれる」という主張と近い位置にあります。エージェントのふるまいを観測、監査、検証しやすくするには、モデルだけでなくハーネス、ログ、権限、実行環境をそろえて見なければなりません。

koharu tone="tip" portrait="characters/deformed/confident-smile.webp" AIエージェントを見るときは、モデル名だけで判断しないのが大事だね。どこで動くか、何にアクセスできるか、あとから追跡できるかも一緒に見てみよう！

Docker利用者はModel RunnerとSandboxesの設計点を棚卸ししたい

Dockerの既存ドキュメントを見ると、今回の発表は唐突な話ではありません。たとえばDocker Model Runnerは、Docker Hub、OCI互換レジストリ、Hugging Faceなどからモデルを扱い、OpenAIやOllama互換APIで提供できると説明されています。ローカルや管理下の環境でモデルを動かす選択肢は、Hugging Faceの事例で見えた「自前で動かせる防御モデル」の話ともつながります。

一方で、Docker DocsはModel Runner APIが認証されていないため、到達できるクライアントがモデルのpull、load、推論リクエストを実行できるとも明記しています。便利なローカル推論基盤ほど、ネットワーク到達性や開発端末内の境界を棚卸ししておきたいところです。

Docker Sandboxesは、AIコーディングエージェントを隔離されたmicroVMサンドボックスで実行し、各サンドボックスが独自のDocker daemon、ファイルシステム、ネットワークを持つと説明されています。Dockerが一次ソースで語ったruntimeやgovernanceは、こうした実行境界、ネットワーク、ファイルシステム、組織ポリシーの話と地続きです。

Dockerの個別成果物とOpen Secure AI Allianceでの担当範囲は今後の確認点

現時点で一次ソースから確定できるのは、DockerがOpen Secure AI Allianceに参加したこと、AIエージェント時代の信頼をruntime、identity、governance、securityの層で捉えていること、そしてオープンウェイトモデルとフロンティアモデルを選べることを重視していることです。

まだ分からないのは、Dockerがアライアンス内でどの仕様、ツール、標準化作業、リファレンス実装を担うのかです。Docker製品へどのような形で反映されるのか、既存のModel Runner、Sandboxes、MCP関連機能とどう結びつくのかも、公式の続報を待つ必要があります。

実務では、今すぐ大きな移行を始める発表というより、AIエージェントの実行基盤を見直すための合図として読むのがよさそうです。開発端末、CI、MCPサーバ、ローカルモデル、外部モデルAPIの境界を一度図にすると、自分たちのAI利用でどこに信頼の根拠があるか見えやすくなります。

出典

• Title: The Future of Agentic AI Depends on Openness and Trust. That’s Why Docker Is Joining Nvidia’s Open Secure AI Alliance.
• URL: https://www.docker.com/blog/docker-joins-nvidia-open-secure-ai-alliance/