DockerがSandbox KitをCNCFへ寄贈、AIエージェントの権限をOCIで標準化

• 事実と背景：DockerがAIエージェントの権限やツールをOCIイメージに統合する「Sandbox Kit Spec v3」を公開し、CNCFへの寄贈を表明。
• 技術的変革：マニフェストに特定記述を加えるだけで、ネットワークや認証情報の制限をイメージと一体化し、改ざん不可能な形で配布可能に。
• 現場への影響：Claude Code等のエージェントが勝手にシステムを破壊するリスクを防ぐため、開発者は実行環境のサンドボックス化が必須となる。

深夜2時、突然鳴り響くアラート。急いでPCを開くと、開発中のAIエージェントが無限ループに陥り、テスト環境のデータベースを破壊しながら、外部APIに対して数万回ものリクエストを送り続けていた――。これは決して誇張された怪談ではない。Claude CodeやCodexといった強力なAIエージェントが開発者の日常に溶け込むにつれ、我々エンジニアが直面している極めて生々しく、かつ致命的なセキュリティリスクである。彼らは我々の代わりにパッケージをインストールし、APIを呼び出し、ローカルのファイルシステムを縦横無尽に駆け巡る。しかし、その強力な権限（バインドマウント、広範なAPIトークン、開放されたファイアウォールルールなど）は、これまでシェルの実行履歴やダッシュボードの奥深く、あるいは開発者の記憶の中にしか存在しなかった。これでは、かつて我々を苦しめた「スパゲッティコード」や「デッドロック」と同じ、管理不可能なカオスがインフラ層で再現されているに等しい。

Dockerが今回発表した「Docker Sandbox Kit Specification v3」は、このカオスに対する強力なアンサーである。Dockerは、AIエージェントがアクセスできるリソースや権限を、エージェント自身やそのツール群とともに、使い慣れた「OCI（Open Container Initiative）イメージ」としてパッケージ化する仕様を策定した。さらに、この仕様をCNCF（Cloud Native Computing Foundation）に寄贈することをコミットしたのだ。これは、AIエージェントのセキュリティを特定のプラットフォームにロックインさせることなく、業界全体のオープンな標準規格として確立しようという、極めて野心的な試みである。我々エンジニアにとって、コンテナ技術がもたらした最大の恩恵は「ポータビリティ」だった。Docker Sandbox Kitは、そのポータビリティの概念を「アプリケーションの実行環境」から「AIエージェントの安全な行動境界（ガードレール）」へと拡張しようとしているのだと私は考える。

技術的な観点から見ると、今回の「v3」仕様における最大のブレイクスルーは、Sandbox Kitが「独自のアーティファクトタイプ」であることを完全にやめた点にある。カスタムメディアタイプも、サイドカーファイルも存在しない。マニフェストに記述されるのは、わずか1行の宣言 vnd.docker.sandbox.kit.descriptor のみである。これにより、我々は既存の docker buildx build でイメージをビルドし、docker pull で取得し、既存のセキュリティスキャナーや署名ツール（Cosignなど）を一切の変更なしでそのまま適用できる。さらに、Dockerfileの FROM 句に指定してベースイメージとして再利用することすら可能だ。イメージのダイジェスト（Digest）をピン留めすることは、すなわちエージェントのコードと、それに付与された権限を不可分な形で固定することを意味する。

この仕様における権限宣言は、型定義されバージョン管理された「Capabilities」として表現される。例えば、ネットワーク制御を行う com.docker.sandbox/network-policy@2 や、認証情報を扱う com.docker.sandbox/credential@1 などだ。GitHub CLIを例にとると、この仕様に基づき「api.github.com へのアクセスは許可するが、/repos/** に対する DELETE リクエストは拒否する」といった極めて粒度の細かい制御が可能になる。しかも、拒否ルールが常に優先される（deny wins）設計だ。さらに、認証情報の管理もスマートである。サンドボックスの内部にはダミーの「センチネル値」のみを配置し、実際のトークンは適合ランタイムがプロキシ経由でリクエスト時に動的に注入する。これにより、エージェントのコードが万が一乗っ取られても、生のトークンが漏洩するリスクを根本から排除している。以下に、従来のコンテナセキュリティとSandbox Kit Specのアプローチの違いをまとめる。

しかし、シニアエンジニアとして、そして一人のITジャーナリストとして、私はこの美しい仕様に対して冷徹な懸念を抱かざるを得ない。それは「ポータビリティの幻想」と「実装の壁」である。仕様書がどれほど美しく、オープンに策定されようとも、それを強制（Enforce）するランタイムが普及しなければ、ただの「無視されるアノテーション」に過ぎない。現在、このSandbox Kit Specに適合している唯一のランタイムは、Docker自身が提供する「Docker Sandboxes」のみである。これは、軽量なmicroVMを用いてカーネルレベルでエージェントを隔離する高度な技術だが、我々が本番環境で広く利用しているKubernetes（containerdやCRI-O）や、AWS Fargateなどのマネージド環境でこれがネイティブにサポートされる見通しは、現時点では極めて不透明だ。

AWS、Box、Datadog、Snykといった錚々たる企業が共同開発パートナーとして名を連ねていることは心強いが、彼らが自社のプラットフォームにこの仕様を真に統合し、マルチランタイムでの相互運用性を実証するまでは、この技術を「標準」と呼ぶには時期尚早だろう。我々開発者が明日から取るべき実践的な処方箋は、まずローカル開発環境において、AIエージェントを実行する際には必ずDocker Sandboxのような隔離環境を明示的に指定し、場当たり的な権限付与を即座にやめることだ。そして、CI/CDパイプラインにおいて、エージェントに与える権限を「Policy as Code」として定義し、イメージのダイジェストと権限を厳密に紐づける運用をスモールスタートで開始すべきである。

ここで我々は、業界全体に対する痛烈な問いに直面する。我々はAIがもたらす圧倒的な生産性と引き換えに、コンテナエコシステムが10年かけて築き上げてきた「どこでも同じように動く」というポータビリティの原則を、再びセキュリティの断片化によって失ってしまうのだろうか？それとも、このSandbox Kitが新たなデファクトスタンダードとなり、AI時代の安全なインフラを再定義する救世主となるのだろうか？その答えを出すのは、DockerでもCNCFでもない。我々現場のエンジニアが、この仕様をどう評価し、どう実装にフィードバックしていくか、その一歩にかかっている。