Docker と CNCF：エージェントができることを t と同じくらいポータブルにするエージェント自体
10年前、ソフトウェア業界はある選択を迫られました。各ベンダーが独自のイメージフォーマットと独自のランタイムを提供し、開発者がどちらかを選ばなければならない状況になるか、あるいは業界全体で1つのアーティファクトに合意するかです。選ばれたのは後者でした。Dockerは独自のイメージフォーマットとRuncランタイムをLinux Foundationに寄贈し、それらを中心にOpen Container Initiative（OCI）が設立されました。現在では、どこでビルドされたDockerイメージでも、どこでも実行できます。このフォーマットは、クラウドネイティブエコシステムのバックボーンであり、デファクトスタンダードです。
現在、エージェントに関しても同様の問題が生じつつあります。エージェントに何が許可されているかを定める共通フォーマットは存在しません。私たちが提案するのも、OCIを基盤として構築され、オープンに管理される1つのアーティファクトという、同じような答えです。
エージェントにも同様の問題
コンテナはイミュータブルなソフトウェアのために作られました。イメージそのものがアプリケーションです。変更したい場合は再ビルドすれば、どこでも同じように動作します。そのため、コンテナイメージにはソフトウェアがどのようにビルドされるかが記述されているだけで、実行後に何を行うかについては何も記述されていません。Webサービスであれば、それでも問題ありませんでした。ネットワークとポートが割り当てられ、それで十分でした。
エージェントは、その性質上、可変です。Claude CodeやCodexは、ユーザーに代わってパッケージをインストールし、APIを呼び出し、認証情報を使用します。自身が実行されている環境を変更し、次に何をすべきかを自ら判断します。そのため、各チームはエージェントがアクセスできる範囲について、独自のルールを作成しています。ネットワークルールがあったり、トークンがあったり、タスクを完了するためのボリュームマウントがあったりします。そうしたルールは、シェルの履歴やダッシュボード、あるいは覚えている誰かの記憶に頼るしかありません。数か月も経つと、「このエージェントには何が許可されているのか？」というシンプルな問いに、誰も答えられなくなります。
現在、各チームがそれぞれ独自にその答えを出しており、各ランタイムベンダーも、それに答える独自の方法を提供する可能性があります。それこそが、OCIが防ぐために作られた断片化です。
今回発表するもの
Kitsは新しいものではありません。Kitsは、エージェント、そのツール、アクセス可能な対象を、チームで共有できる形にパッケージ化する方法として、Docker Sandboxesの一部でした。新しいのはアーティファクトです。Kitsは現在、通常のOCIイメージであり、それを記述する形式はオープンです。
本日、WeAreDevelopersで、Apache 2.0ライセンスのもとオープンソースとして提供されるDocker Sandbox Kit Specを発表しました。Kitは、エージェント、そのツール、そしてホスト、認証情報、ボリュームなど、アクセスを要求するすべての対象の型付きリストという3つの要素を1つのイメージに含みます。リストはイメージの一部であるため、イメージを固定すると、エージェントとその要求内容もまとめて固定されます。
Kitは新しいアーティファクトタイプではなく、OCI仕様のフォークでもありません。OCIがすでに定義している拡張ポイントを使用しています。現在実行している他のイメージと同様に、ビルド、プッシュ、プル、署名、スキャンが可能です。Kitもイメージだからです。
本日、イメージ形式を OCI に移管したときと同様に、この仕様を CNCF の中立的なガバナンスのもとに移管します。
なぜ重要なのか
導入は無料です。 KitはOCIイメージであるため、すでに運用しているすべてのレジストリ、スキャナー、署名ツールでそのまま扱えます。 新たにデプロイするものはありません。
その答えはエージェントとともに移動します。要求内容がイメージに含まれているため、「このエージェントには何が許可されているのか」という問いに対する答えは1つだけです。チームメンバーは、そのKitをプルできます。レビュアーは、そのKitの差分を確認できます。仕様に準拠したランタイムは、その内容を強制的に適用できます。新しいバージョンが追加の権限を要求すると、その変更は追加された行として表示され、人間がそれを拒否できます。
フォーマットではなく、エコシステム
Dockerは常に、エコシステムを第一に考える姿勢を持ってきました。Dockerfileが重要だったのは、誰でも作成でき、どのレジストリでもその結果を保存でき、どのランタイムでも実行できたからです。Kitsも同じアプローチに従っており、私たちだけで構築したものではありません。
AWS、Box、Datadog、Dynatrace、JFrog、NanoClaw、OpenClaw、Palo Alto Networks、Snykなどと協力し、それらのツール向けのKitを構築してきました。クラウドプラットフォーム、オブザーバビリティ、セキュリティ、アーティファクト管理、コンテンツ、エージェントフレームワークなど、幅広い分野が網羅されています。本日WeAreDevelopersのオープニング基調講演で発表したKitは、これまでの取り組みの成果であり、今後続く多くのKitの第一弾です。
MCPにより、エージェントはツールとやり取りするための標準的な方法を手に入れました。Kitsにより、エコシステムは、エージェント、そのツール、アクセスを求める対象という一連の構成を、誰でもプルできる1つのイメージとして公開する標準的な方法を得られます。それによって、フォーマットがサプライチェーンの一部になります。たとえば、データベースベンダーは、自社が推奨するスコープで任意のエージェントをサービスに接続するKitsを公開できます。エージェントの作成者は独自のKitsを公開するため、要求リストはエージェントを構築した人たちが定義したものになります。プラットフォームチームは会社向けに1つを公開し、すべてのエンジニアが同じ出発点から始められます。
フォーマットが1つのベンダーに属していると、そうしたことは一切実現しません。エージェントに何が許可されているかを決めるための標準が、ランタイムの提供元に属していれば、その価値は大きく損なわれます。Docker Sandboxesは、この仕様を強制的に適用する最初のランタイムです。Docker Sandboxesだけが唯一の実装であるべきではありません。CNCFのガバナンスのもとでは、そうはなりません。
コンテナによって、ソフトウェアは移植可能になりました。Kitsによって、権限も移植可能になります。意図的にエージェントに与えた一連の権限がエージェントとともに同じイメージに含まれ、準拠したランタイムであれば、どこで実行しても同じ意味を持ちます。
「標準規格があるからこそ、エコシステムは分断することなく迅速に前進できます。それをDockerほどよく理解している企業はほとんどありません。Sandbox Kitsを標準的なOCIイメージとして提供することで、Dockerは業界に対し、AIエージェント、そのツール、ガードレールを1つのアーティファクトとしてパッケージ化するためのオープンで再現性のある方法を提供しています。OCIはクラウドネイティブエコシステムの基盤であり、OCIをベースにしたエージェント向けの標準規格は、エコシステム全体に一挙に行き渡ります。CNCFはこの取り組みを歓迎しており、これが広く普及するようDockerやコミュニティと協力して取り組めることを楽しみにしています。」
クリス・アニシュチク
CNCFのCTO
キットをビルド
エージェントが使用するツールを作成したら、そのツールのKitを公開しましょう。エージェントを実行する場合は、まず1つのKitから始めて、チームと共有しましょう。仕様、ケイパビリティのページ、実際のKitを使った詳しい解説は、docker/sandbox-kit-specで確認できます。表現できないKitや、ランタイムが実装できないルールがある場合は、Issueを作成してください。公開されたすべてのKitと提出されたすべてのIssueが、標準を形作っていきます。
