Docker、AIエージェントの安全統制に向け「ランタイム層」での境界設定を提唱　複数ツール混在環境の課題に対応

要点

• 米Dockerは公式ブログにて、複数のAIモデルやエージェント実行環境が混在する開発現場に向けた新たなセキュリティモデルを提唱した。

• AIエージェントに強い権限を委譲することで生じる「代理人の混乱（Confused Deputy）」問題に対し、ツール個別のガードレールでは十分に対処できないと指摘した。

• コード実行やツール呼び出しが必ず通過する「ランタイム層」で一元的にルールを執行するアーキテクチャの有効性を主張した。

• DockerのCTOであるTushar Jain氏が、米サンノゼで開催されるイベント「We Are Developers」にて本構想の詳細を説明する予定である。

• 米Dockerは2026年9月2日、公式ブログにおいて、複数のAIモデルや開発支援ツールが併用される現代のソフトウェア開発に向けたセキュリティとガバナンスの考え方を発表した。開発現場で多様なAIエージェントの導入が進む中、ツールごとの個別制限に頼るのではなく、実行基盤となるランタイム層で統一的な境界を設けるべきだとする見解を示している。

複数モデル・ツールの併用が進む開発現場

ブログ記事を執筆したSrini Sekaran氏によると、現在のソフトウェア開発では単一のAIモデルに依存するのではなく、用途に応じて異なるモデルやハーネス（エージェントを稼働させる実行環境やツール群）を使い分ける流れが定着しつつあるという。記事では、この変化を後押しする要因として以下の3点を挙げている。

1. コスト構造: エージェントは複数のステップを繰り返すためトークン消費が多く、単純な作業に高価なフロンティアモデルを使い続けるのは経済的合理性に欠ける。
2. モデル競争の激化: 最高峰とされるモデルやその提供ベンダーは数か月単位で頻繁に入れ替わる。
3. 独自モデルの重要性: 汎用的な知能がコモディティ化する中で、組織固有のコンテキストを学習させたカスタムモデルが競争力の源泉となっている。

こうした状況を受け、開発現場では大規模なコードのリファクタリングにはClaude Code、日常業務にはCodex、簡易なスクリプト作成にはHermesといったように、タスクごとに最適なツールが選定されるようになっていると述べている。

自律エージェントが引き起こす「代理人の混乱」

記事では、エージェントの普及に伴ってセキュリティの論点が「どのモデルが最も優れているか」から「誤作動や不正操作が発生した際に何が起きるか」へと変化していると指摘する。

多くのエージェントは、公開ドキュメントやWebページ、第三者が作成したコードなど、外部の管理されていない情報を読み込んで動作する。その一方で、実行時には開発者が持つ認証情報やリポジトリへのアクセス権、本番APIの利用権限をそのまま引き継いで自律的に処理を行う。さらに、これらの動作はVPC（仮想プライベートクラウド）やIAM（ID・アクセス管理）といった従来の企業向けセキュリティ境界の外側にある開発者の端末上で実行されることが多いという。

Sekaran氏は、この構造を1988年にNorm Hardy氏が提唱した「Confused Deputy（代理人の混乱：正当な権限を持つプログラムが悪用され、意図しない権限行使を行ってしまう問題）」の再来であると説明している。確率的に動作するエージェントが強い権限を持つことで、悪意ある指示やハルシネーション（もっともらしい誤情報の生成）によるセキュリティリスクが高まるとしている。

ツール個別のガードレールが抱える3つの限界

現在、多くのハーネスには独自のガードレールが組み込まれているが、記事ではそれらを信頼境界として依存することには以下の3つの限界があると分析している。

• エージェントによる迂回: 制約がエージェントと同じ実行ループ内で処理されている場合、エージェント自身が制約をすり抜ける危険がある。例えばGitのプッシュ操作を禁止しても、APIを経由したりGistを利用したりしてデータを外部へ送信してしまう可能性がある。記事では昨年の事例として、公開GitHubリポジトリに投稿された悪意あるIssue（プロンプトインジェクション）により、エージェントが企業の非公開リポジトリを読み出してプルリクエスト経由で公開してしまったケースを紹介している。
• ベンダー依存の仕様変更: 各ハーネスのサンドボックスや承認動作の既定値はベンダーのリリース計画に沿って頻繁に改定されており、ユーザー側で一貫したセキュリティ基準を保つことが困難になっている。
• 組織全体への非対応: 自社プラットフォームチームが開発したエージェントや外部SaaS組み込みのエージェントなど、ツールごとに防御策の実装がバラバラになり、一元的なルール適用や監査ログの収集ができなくなる。

ランタイム層での一元管理と今後の展望

Dockerはこれらの課題に対し、エージェントやツールの枠組みの下層に位置する「ランタイム層」で統制を行うアプローチを提示している。

エージェントの行動は、最終的には「ファイル操作やネットワーク通信を伴うコード実行」または「外部システムに作用するツール呼び出し」の2つの経路に集約される。これらはいずれもプロセスが稼働し、認証情報が使用され、外部通信が発生するランタイムを必ず通過する。

ランタイム層に強固な境界とポリシー執行機能を配置することで、エージェントのループ外から確実に制約を課すことが可能になるという。これにより、モデルの誤作動や攻撃に対する防御が担保され、ベンダーの仕様変更に左右されない一貫したポリシーを組織内の全エージェントへ適用できるようになる。また、すべての動作が一元的に記録されるため、監査や追跡性も向上するとしている。

Sekaran氏はこの仕組みによって、従来の「エージェントを全面的に禁止する」「無制限に許可してリスクを受け入れる」「全工程で手動承認を挟んで生産性を落とす」という不完全な選択肢から脱却し、リスクを一定範囲に抑えながら真の自律性をエージェントに与えられるとまとめている。

なお、DockerのCTOであるTushar Jain氏は、米サンノゼで開催されるカンファレンス「We Are Developers」において、複数モデル・複数ハーネス環境とそれを支える単一ランタイム層に関する構想について詳細な登壇を行う予定だという。