私たちはサンフランシスコで開催されたAIエンジニア世界博覧会で、ステージ上や会場内を歩き回りながら一週間を過ごしました。私たちが耳にした情報と、不動産仲介業者を通して家を建てる人にとって、それがどのような意味を持つのか、私たちの見解を以下にまとめました。
SDLCは公開で再構築されている
今週のAIEは、ここ数年開発者ツール業界で起こってきたことの集大成のように感じられた。これは、これまで注目してきた人にとっては特にそうだろう。ソフトウェア開発ライフサイクルはAIネイティブなSDLCへと再構築されつつあり、業界ではこの急速な変革に伴う新たな職種や開発者の懸念事項が明らかになりつつある。
その証拠はトラックリストにありました。評価、コンテキストエンジニアリング、ハーネスエンジニアリング、メモリ、サンドボックスとプラットフォームエンジニアリング、推論、そして「ソフトウェアファクトリー」に関するスレッド全体です。2年前、これらのフレーズのほとんどは、カテゴリーとして認識されるには程遠いものだった。今やそれぞれが独立した分野となり、独自のセッション、独自の専門用語、そしてその分野特有の問題を解決するために展示会場に集まる企業群を持つようになった。
では、主な話し合いの内容は何だったのでしょうか？「エージェントやAIがこれを実行できるかどうか」という議論よりも、「このような構築方法を採用した場合、どのような意思決定やトレードオフを考慮する必要があるのか」という議論に重点を置くべきだ。評価、ループ、ハーネス、コンテキスト、メモリ、分離、コスト。これらはどれも全く新しいものではないが、開発者たちがAIを使ったソフトウェア開発の新たな形を模索するにつれ、どれも全く新しいレベルの注目を集めるようになっている。モデルラボでさえ、ステージ時間の多くを、モデルそのものよりも、モデルを使ってどのように構築するか、つまり統合API、ハーネス、人間工学などに費やした。
私たちが最も重視する仕事：エージェントが活動する場所の安全確保
数ある新興分野の中でも、サンドボックスは今年、臨界点に達した分野と言えるでしょう。サンドボックスとプラットフォームエンジニアリングに特化したセッションが設けられており、その中で行われたセッションでは、サンドボックスとは一体何であるべきか、つまり、完全な仮想マシンなのか、軽量ランタイムなのか、Kubernetesなのか、あるいは専用に構築されたものなのかといった点について、まだ議論が続いていた。協議では、エージェント型サンドボックスを大規模に運用することや、隔離技術を直接比較することといった懸念事項に焦点が当てられた。
これは、Dockerが3つのセッションにわたって語るために登場した仕事内容である。
エージェントに表面積を少なくすることで、エージェントの自由度を高めよう
当社のエンジニアリング担当上級副社長であるトゥシャール・ジェインが、メインステージで「エージェントの自律性を解き放つ：AIネイティブシステムのためのランタイム」と題した講演を行いました。役割は変化しました。エージェントはコードベース全体を読み書きし、サブエージェントを生成し、依存関係をインストールし、ラップトップ、CI、クラウド、組織の境界を越えてAPIを呼び出します。多くの場合、監視なしで実行されます。この変化に積極的に取り組むチームは急速に前進しているが、ほとんどの組織は依然としてエージェントの自律的な運用を認めていない。それはモデルに能力がないからではなく、まだ信頼関係が築けていないからだ。この考え方は、セキュリティ研究者のサイモン・ウィリソンが提唱した「致命的な三位一体」という概念に基づいている。つまり、有用なエージェントは、設計上、プライベートデータへのアクセス、信頼できないコンテンツへの接触、そして外部世界で活動する能力という、この3つの要素すべてを備えることになる傾向があるということだ。プロンプトやポリシー文書でそれを解消することはできません。根本的な解決策は、その一つ下の階層、つまり実行時に存在します。過去10年間、私たちはまさにこの実行時に取り組んできたのです。具体的には、分離、ネットワークポリシー、信頼できるイメージ、認証情報といったものです。エージェント業務は、単なる次の業務負担に過ぎない。
エージェントは悪意がなくても危険になり得る
Dockerのスタッフプロダクトマネージャーであるローワン・クリスマスは、そのリスクを具体的に説明した。「YOLOモードを安全に：あらゆるエージェントのためのmicroVMサンドボックス」という記事の中で、彼は自身のノートパソコン上で、読み取りアクセス権限のみを与え、サンドボックスや特別な権限を一切与えずに、コーディングエージェントを実行した。わずか数分で、システムは受動的に見ることができる情報から、彼のオンラインバンキング活動について驚くほど多くの情報を集めた。rm -rf のような破壊的なコマンドは当然の懸念事項だが、日常的な操作でもリスクは生じる。読み取りアクセス、信頼できないコンテンツ、そして操作を実行できる能力があれば、それだけで損害を与えるのに十分だ。エージェントは悪意がなくても、あなたを暴露する可能性があります。とにかく、物が見えればいいんです。Rowanが示した代替案では、各セッションをマイクロVMに基づいた独自のDockerサンドボックスに配置し、ファイルシステム、ネットワーク、ツールにわたる境界をユーザーが定義します。Claude Code、Cursor、Codexなど、あなたが使っているどんなソフトウェアでも実行できます。
エージェントがパッケージをインストールし、Dockerを実行し、ネットワークにアクセスできるようになった時点で（これはほとんどの真に役立つエージェントに当てはまる）、ハードウェア境界を設けることで、後から簡単に追加できない機能を手に入れることができる。そして、規模拡大に関する議論の多くはクラウドファーストで、サーバー側で実行されるエージェント群向けに構築されているのに対し、Dockerのアプローチは、開発者が既に使用しているラップトップから始まる。なぜなら、現在ほとんどの人が実際にエージェントを実行しているのはラップトップだからだ。（マイクロVMを採用する理由と、サンドボックス方式の比較記事では、その理由についてさらに詳しく解説しています。サンドボックス化にはコストがかかるため、その点についても触れています。なぜなら、サンドボックス化は無料ではないからです。）
エージェントがインストールしたものを誰もレビューしていません
3つ目の講演では、ツール層について取り上げた。MCPチームの主席ソフトウェアエンジニアであるジム・クラークが、「誰がそのMCPサーバーを承認したのか？」というテーマで講演しました。「ツールレイヤーのガバナンス」というタイトルの講演で、聴衆の笑いを誘う一文で幕を開けた。「シャドウMCP」。開発者はセキュリティ担当者が審査するよりも速いペースでMCPサーバーをインストールしてしまうため、審査されていないサーバーはデータへの直接的なアクセス経路となってしまう。その不安は、私たちのセッションだけでなく、イベント全体に蔓延していた。ジムのデモでは、すべてのサーバーを組織が管理する単一のカタログの背後に配置し、審査済みで署名済みのカタログを使用し、承認されていないものはすべてデフォルトで拒否されるように設定し、そのポリシーをステージ上で実際に適用した。
それで私たちはどうなるか
では、それらはどのようにして結びつくのでしょうか？エージェントの信頼性は、その周囲を取り巻く境界の信頼性によって決まります。そして、その境界は、エージェントが構築する基盤、エージェントが動作する場所、エージェントが到達できる範囲という3つの場所に存在します。どれか一つでも間違えると、残りの二つではカバーしきれません。エージェントがサンドボックス化されていないファイルシステム全体を読み取ることができる場合、強化されたイメージ依存関係は役に立たず、エージェントが検証されていないMCPサーバーをサンドボックスから直接呼び出すことができる場合、ロックダウンされたサンドボックスも役に立たない。
今週ずっとDockerが主張してきたのは、エージェントが構築する基盤を強化し、実行場所を分離し、アクセス可能な範囲を制御し、そしてこれら3つすべてを1か所から管理する、ということだった。我々は、この部分を最初に解決する必要があると考えています。なぜなら、ここからAIネイティブの開発者が未来のアプリを構築し始めるからです。
参考文献:
- Dockerサンドボックスはスタンドアロンで動作します（brew install docker/tap/sbx）。
- Docker AI Governanceは、サンドボックスとMCPポリシーを1つのコンソールに統合します。
- MCPカタログ、ツールキット、ゲートウェイが本日Docker Desktopに搭載されました。
- Dockerの強化イメージは、FROM行にそのまま変更を加えるだけで済みます。
