Cloud

概要 AWSは、ドイツのブランデンブルクを拠点としEU居住者のみで運用する「AWS European Sovereign Cloud」について、AWSグローバルネットワークのバックボーンから意図的に切断する実証演習を2026年10月24日(土)に数時間にわたって実施すると発表した。目的は、同クラウドがEU域外のインフラに依存せずに独立して運用できることを技術的・運用的に証明することにある。演習中はAWSの拠点間を結ぶ専用バックボーン接続を遮断し、代わりに欧州のインターネットサービスプロバイダー(ISP)が提供する専用接続と公開インターネット経由の安全な経路変更によってトラフィックを処理する。 演習の狙いと規制基準との関係 AWS European Sovereign Cloudは、顧客データをEU域内に留めることを前提に設計されたクラウド基盤で、欧州委員会が掲げる「EU Cloud Sovereignty Framework」の目的や、ドイツ連邦情報セキュリティ庁(BSI)が定める「C3A」基準への適合を目指している。今回の演習は、これらの枠組みが求める「運用の独立性」を机上の説明ではなく実地の切断テストという形で示す狙いがある。欧州では近年、米国系クラウド事業者に対して、データ主権やレイヤーの地政学的リスクを懸念する声が強まっており、今回の実証はそうした懸念に対するAWS側からの具体的な回答と位置づけられる。 技術的な仕組みと想定される影響 演習では、AWS European Sovereign CloudとAWSグローバルネットワークバックボーンとの接続を切断し、その間のデータトラフィックは公開インターネット経由で安全に経路変更される。並行して、欧州のISPが提供する専用接続のみを用いてサービスを継続できるかを検証する。AWSは、演習期間中も通常のサービス可用性は基本的に維持されるとしているが、切断の開始時と終了時には短時間の接続中断が発生する可能性があるとしている。 今後の見通し AWSは演習終了後、得られた結果を規制当局や顧客と共有し、コンプライアンス・保証パッケージを裏付ける追加的な証拠として活用する方針を示している。欧州ソブリンクラウドを巡っては各国政府機関や規制の厳しい業種からの需要が高まっており、今回のような独立性の実地検証は、今後他のクラウド事業者にも同様の説明責任を求める流れを後押しする可能性がある。

概要 日本時間10月1日未明、Microsoft Azureで日本Westを含む世界18〜19リージョンにわたり、ExpressRoute Gateway、VPN Gateway、Azure Firewall、Azure VMware Solutionなど接続系サービスの障害が発生した。発生は米国時間9月30日20:30 UTC(日本時間10月1日5:30)で、Microsoftによる緩和作業は日本時間同日11時15分頃に完了し、障害全体は約5時間45分に及んだ。Microsoftは原因について、リージョナルゲートウェイ管理サービスへの最近の変更作業と、本来無関係だったインフラOSのメンテナンス作業が重なったことで、依存先サービスへの負荷が想定以上に増大したためと説明している。 障害の原因と技術的詳細 Microsoftによると、ゲートウェイ管理サービスへの変更が、依存するサービスの需要増大に対してスケールしきれず、複数リージョンにまたがる予期しない負荷を引き起こした。これに加えて、本来は障害の発生とは無関係のはずだったインフラOSのメンテナンス作業が同時間帯に重なったことが、問題を広範囲に拡大させた一因とみられる。一部のネットワーク管理コンポーネントでは自動復旧(オートリカバリ)の仕組みが機能せず、エンジニアリングチームが正常なインスタンスを使って手動で復旧作業を行う必要があった。Microsoftは問題のあったサービス変更をロールバックし、メンテナンス作業を一時停止した上で、各リージョンに順次設定修正を適用して復旧を進めた。 影響範囲とユーザーへの影響 影響を受けたリージョンは、日本Westのほか西ヨーロッパ、北ヨーロッパ、フランス、ドイツ、スイス、英国、東アジア、東南アジア、韓国、オーストラリア、南アフリカ、UAE、インドなど18〜19に及んだ(Azure VMware Solutionについては、メキシコ中部やドイツ北部など一部リージョンは対象外)。障害の多くは完全な接続断ではなく、接続品質の劣化や遅延の増加、冗長性の低下として現れたケースが目立ち、これは「むしろ例外的」な障害パターンだったとの指摘もある。ヨーロッパでは深夜帯だったため業務への影響は限定的だったが、アジア圏の利用者はより大きな影響を受けたとされ、ハイブリッドクラウド環境やオンプレミスとの接続に依存する企業の業務が広く妨げられた。 今後の対応 Microsoftは今回の障害について責任を認め、14日以内に詳細なインシデント報告書(Post-Incident Review)を公開すると表明している。なお、AzureおよびMicrosoft 365では今年7月にもメンテナンス関連の不具合による障害が発生しており、インフラの保守プロセスそのものの信頼性が繰り返し問われる格好となっている。今回の件も含め、変更管理とメンテナンス作業のスケジューリングをどう見直すかが、今後公開される報告書の焦点になるとみられる。

概要 Googleは、2026年5月に一般提供(GA)が始まったGKE Pod Snapshotsの性能ベンチマーク結果を公開した。実行中のワークロードのメモリ状態をチェックポイントとして保存し、必要に応じて復元する仕組みにより、Pod起動時の遅延を最大89%削減できるという。特にAI推論ワークロードでの効果が大きく、70Bパラメータ規模のモデルは37秒、8Bパラメータのモデルは15秒でロードが完了したと報告されている。実例としてCodewayのケースも紹介されており、従来のカスタムキャッシング層では1分かかっていた処理がPod Snapshotsの導入で8秒まで短縮されたという。 技術的な仕組み Pod SnapshotsはgVisorランタイムを基盤としており、利用にはGKE Sandboxが必須となる。Autopilotクラスタではデフォルトで有効だが、Standardクラスタの場合はgVisorを有効化したノードプールの設定が必要だ。スナップショットにはCPU/GPUメモリ、ファイルディスクリプタと実行中スレッド、CPUレジスタ、EmptyDirボリュームやtmpfsマウント、コンテナのルートファイルシステムまでが含まれ、データはCloud Storageに保存される。各ノード上のエージェントがスナップショットのライフサイクル管理を担い、記事のタイトルが示す通り、処理の重点が実行時の最適化からこのライフサイクル管理側へと移っている。 ライフサイクル管理と互換性検証 記事では、実務上の最大の課題としてスナップショットの無効化が挙げられている。GKEは「distilled Pod spec」と呼ばれるハッシュをスナップショットに埋め込み、復元時にPod仕様が同一のハッシュを生成することを要求する。復元先ノードは同じマシンシリーズ・CPUアーキテクチャである必要があり、gVisorカーネルやGPUドライバのバージョンも一致していなければならない。ノードプールの更新でこれらのバージョンが変わると既存のスナップショットは互換性を失い、エラーを出すことなく通常起動にフォールバックしてしまう点は運用上注意が必要だ。一方で、プロセスメモリの復元を諦める代わりにマシンファミリをまたいだ復元を許可する「rootfs-only scope」というオプションもあり、柔軟性と速度のトレードオフを選べるようになっている。 設定はPodSnapshotStorageConfig(保存先バケットの指定)とPodSnapshotPolicy(ラベルによるPod選択、自動/手動トリガー、保持期間)という2つのカスタムリソースで制御する。復元時はgVisorカーネルが数秒で復帰し、メモリの読み込みはバックグラウンドで継続しながらアプリケーションの実行が始まる仕組みだ。ただし暗号化キーや証明書の再作成、環境変数を/proc/gvisor/spec_environから読み込む必要があるなど、アプリケーション側に求められる対応もある。外部接続は復元時に切断され、Persistent Volumeはチェックポイント対象外、iptables/nftablesルールも復元されないため、ステートレスな設計がより重要になる。 ハードウェアの制約と今後の展望 現時点ではE2マシンでの完全なスナップショットは利用できず、マルチGPU環境ではL4 GPUのみがサポート対象で、Multi-Instance GPUにも非対応といった制約がある。また、スナップショットはワークロードの完全なメモリ内容をファイル化したものであり、エージェントサンドボックス環境では信頼できないモデル生成コードのメモリも含まれうるため、Workload Identity FederationとIAMバインディングを通じたアクセス制御が重要になる。この技術は、同じく2026年5月にGAとなったGKE Agent Sandbox(毎秒最大300サンドボックスを割り当て、90%が200ミリ秒以内に完了)でアイドルエージェントの一時停止に活用されているほか、Googleが並行して進めるオープンソースプロジェクト「Agent Substrate」でも、より高密度な一時停止・復帰の多重化が検討されている(ただし現時点ではプロダクション非対応)。AI推論ワークロードのスケーリング効率を高める基盤技術として、今後の発展が注目される。

概要 Amazon Web Services（AWS）は、GPTやClaude、Gemini、Ollamaなど主要なLLM・LLMランタイムを基に高性能なAIエージェントを簡単に構築できるオープンソースツール「Strandsハーネス」を公開した。AWSの公式Xアカウントは「自作エージェントを作ったことがあるなら、ツールやメモリ、コンテキスト処理の配線に苦労し、それがちゃんと機能するよう祈った経験があるはずだ。Strandsハーネスはワンインポートで導入できる、あらかじめ配線済みのオープンソースエージェントだ」と紹介しており、「ワンインポート、任意のモデル、トークン消費28%減」を謳っている。agentic AI基盤をめぐる主導権争いが激化する中、AWSは自社クラウドやBedrockに縛られないオープンな選択肢を提示した形だ。 ハーネスとは何か AIエージェントは、LLM単体ではなく、LLMと「ハーネス」と呼ばれる周辺環境の組み合わせによって成り立っている。ハーネスは、指示された目標や環境設定といったコンテキストを長期的に記憶する仕組み、ファイルやネットワーク・実行環境へのアクセス、データベースやAPIなど外部ツールへのアクセス、ポリシーや権限から逸脱しないよう制御するガードレールなどで構成される。エージェントが無駄なトークンを消費せず効率的に目標へ向かって作業できるか、ガードレールが適切に介入できるかといった点は、このハーネスの設計に大きく左右される。今回AWSが公開したStrandsハーネスは、同社が2026年8月に公開した「Strands Harness SDK」を基盤としている。 技術的な特徴 Strandsハーネスは、Amazon Bedrock上で動作するLLMに加え、Anthropic Claude、OpenAI GPT、Google Gemini、Ollama、Lite LLMに対応しており、わずか数行のコードでAIエージェントを構築できる。構築されたエージェントにはシェルの実行、ファイルの読み書き、Web検索といった機能が最初から組み込まれている。コンテキスト管理の面では、デフォルトで約1500トークンを超えるツール実行結果を切り捨てるほか、コンテキストウィンドウの使用率が85%を超えると要約による自動圧縮が働き、オーバーフローが発生した場合はループ内でコンテキストを復元する仕組みを備える。プロンプトキャッシングにも対応し、セッションIDを指定すれば以前の会話を再開できるほか、「スキル」機能もサポートする。 AWSが公開したベンチマークでは、同じ「Fable 5」をベースにしたClaude CodeとStrandsハーネス製エージェントを比較しており、Strandsハーネス側がより低コストで高い能力を発揮したとしている。公開された結果ではStrandsハーネス製エージェントがスコア69.7でトップ、コストは56.29ドルで2位につけた一方、Claude Codeは最下位だったという。 柔軟なLLM切り替えとデプロイ Strandsハーネスで構築したエージェントは、後からLLMを入れ替えることも可能だ。例えば「@strands-agents/harness」パッケージのcreateHarnessを使い、model: "anthropic/claude-opus-5"と3行ほど記述するだけでエージェントを作成でき、この指定を"google/gemini-3.5-flash"や"ollama/llama3.1"に書き換えるだけで別のLLMへ切り替えられる。デプロイ先もAWSに限定されず、Linuxコンテナさえ用意できればあらゆる環境に展開可能だ。非エンジニア向けにはウィザード形式でLLMやツール、プラグイン、外観を設定できる「Strands CLI」も用意されており、構築したエージェントはTypeScriptまたはPythonのコードとしてエクスポートして保存できる。デモ動画では、Bedrock上のClaude Opus 4.8を選択してエージェントを構成し、Playwright MCPサーバーを追加した上でブログの動画レイテンシーをチェックさせる様子が示されており、エージェントが自律的にブラウザを操作して計測・判定を行っている。LLMにもデプロイ先にも依存せず、オープンソースゆえに機能追加やカスタマイズも自由に行える点が、Strandsハーネスの大きな特徴といえる。

概要 Google Cloudは9月24日、Google Kubernetes Engine(GKE)向けの新機能「ambient networking」をアローリスト制のプレビューとして公開した。これはPodごとにサイドカーコンテナを配置する従来のサービスメッシュ方式に代わり、プロキシ機能をノードレベルのコンポーネントへ移行するアプローチで、サイドカー不要のサービスメッシュ展開モデルを実現するものだ。GKEにすでに組み込まれているデータプレーン技術「Dataplane V2」に統合される形で提供され、メッシュのライフサイクル管理を簡素化する狙いがある。 技術的な詳細 従来のサイドカー方式では、メッシュに参加する各Podにプロキシコンテナを注入するため、アイドル状態のプロキシであってもCPUやメモリを消費し続け、また設定やプロキシのバージョンを更新する際にはワークロード自体の再起動が必要になるという課題があった。ambient networkingはプロキシ機能をノードレベルのコンポーネントに集約することで、こうしたアイドル時のリソースオーバーヘッドを削減し、プロキシ更新に伴うワークロードの再起動も不要にする。インフラ管理の手間を簡潔にできる点も利点として挙げられている。 現時点のプレビューでは、単一クラスター内でのレイヤー4メッシュ機能をサポートし、Gateway APIを用いてmTLSによる通信の暗号化、サービスディスカバリー、トラフィック管理、テレメトリー収集に対応する。利用にはアローリストへの登録が必要で、まだ全ユーザーに開放された機能ではない。 今後の展望 サイドカーレスのサービスメッシュはIstioの「Ambient Mesh」など業界全体で進んでいる潮流であり、GKEが同様のアーキテクチャをDataplane V2に統合したマネージド機能として提供することで、Kubernetes運用者はリソース効率とアップグレード時の運用負荷を大きく改善できる可能性がある。現段階では単一クラスター・レイヤー4機能に限定されているが、今後はマルチクラスター対応やレイヤー7機能の拡充が期待される。

概要 BlackRockが支援する「Artificial Intelligence Infrastructure Partnership(AIP)」とオーストラリアの機関投資家IFM Investorsから成る投資グループが、データセンター事業者Stack Infrastructureのアジア太平洋部門を最大250億ドルで買収する独占交渉に入ったと報じられた。Stackの現所有者であるBlue Owl Capitalとの間で、今後デューデリジェンスを実施し、早期の合意成立を目指しているとされる。ただし交渉はまだ最終段階に至っておらず、条件次第では延長や不成立となる可能性も残る。 買収の背景とAIPの狙い AIPは2024年9月に発足したBlackRock主導の投資枠組みで、データセンターやエネルギー関連施設を中心にAI関連インフラへ300億ドル超を投じる計画を掲げてきた。今回の交渉はその具体化の一つで、生成AIの学習・推論需要の急拡大を受けて世界的に逼迫するデータセンター容量を確保する狙いがある。一方、Stackを保有するBlue Owl Capitalは当初300億ドルを超える評価額を求めていたとされ、現在交渉されている200億〜250億ドルという水準はそれを下回る。買い手側が需要の強さを踏まえつつも評価額の妥当性を慎重に見極めていることがうかがえる。 対象資産と今後の見通し 買収対象となるStackのアジア太平洋事業は、東京、大阪、シドニー、メルボルンといったAPACの主要都市にデータセンター拠点を持つ。いずれも電力供給や土地確保の制約が強まる中で希少性の高い立地であり、AI向けGPUクラスターのホスティング拠点としての需要が見込まれる。投資グループは今後デューデリジェンスを進め、Blue Owl Capitalとの最終合意を目指すとみられるが、規模の大きさから独占禁止当局や各国の対内投資審査の対象となる可能性もある。実現すればAI関連インフラ分野で今年最大級の取引となり、機関投資家によるデータセンター資産への資金流入がさらに加速する兆しとして注目される。

概要 Cloudflareは9月28日、既存のCLIツール「Wrangler」を置き換える新ツール「cf」をオープンベータとして公開した。Wranglerが対応してきた操作は約280にとどまっていたのに対し、cfはCloudflareの全API、3,000を超える操作をカバーする。背景には、各プロダクトチームが個別にWranglerの機能を開発してきたことで用語やアプローチに一貫性を欠いていたという課題があり、cfでは統一的なAPI生成パイプラインからコマンドを自動生成することでこれを解消したという。インストールはnpm i -g cfで行え、既存のWranglerプロジェクトはcf migrateコマンドで自動移行できる。 AIエージェント時代を意識した設計 cfの設計思想の中心にあるのは、人間だけでなくAIエージェントによる利用を前提とした「agentic CLI」というコンセプトだ。Cloudflareの利用統計によれば、Wranglerのエージェント経由での利用率は2026年3月時点の25%から現在は48%まで上昇しており、エージェントは人間の開発者と比べて1日あたりほぼ2倍の異なるコマンドを使用し、6つ以上のコマンドを使う確率も4倍高いという。この傾向を踏まえ、cfは出力形式をJSON優先に変更し、従来のようにテーブル出力に--jsonフラグを付け加える手間とフィルタリングコストを削減した。またcf cli searchコマンドにより、エージェントが自然言語で3,000のルートから適切な操作を素早く発見できるようにしている。ドメイン購入のような複雑な操作についても、検証済みのフォーム入力を通じて簡素化されている。 設定ファイルとビルド環境の刷新 設定ファイルは従来のTOML形式から、cloudflare.config.tsというTypeScriptベースの形式に移行した。bindings.kv()やbindings.d1()、bindings.r2()など用途別のヘルパー関数を通じて、KVストア、D1データベース、R2オブジェクトストレージ、キューサービス、ベクトル検索といった各種バインディングを型安全に定義できる。LSP対応エディタでの自動補完に加え、設定ファイルサイズを最大40%削減できる点もメリットとして挙げられている。TypeScript化により、Claude CodeやCodexのようなLSP対応のコーディングエージェント自身が設定内容を解釈・編集できるようになったことも、AIエージェント対応という設計方針と一致する。ビルド面では、cfはViteをデフォルトのビルドツールとして採用し、Rustベースの高速バンドラーRolldownによる最適化やホットモジュールリプレースメント(HMR)、Vitestによるテスト環境の統一を実現した。esbuildを使う既存のWranglerプロジェクトも段階的にViteへ移行できるとしている。 OSS基盤「Forge」と今後の展望 cfのコマンド群は、OpenAPIスキーマに追加のメタデータアノテーションを付与してCLIコマンドを自動生成する内部基盤「Forge」によって生成されており、Cloudflareはこの生成基盤自体も同日にオープンソースとして公開した。これにより、手作業で1,000行を超えるカスタムコードを書く必要がなくなったという。ベータ期間終了後にはWranglerの最終メジャーバージョンがリリースされ、その後18か月間のメンテナンスサポートが提供される予定で、新規プロジェクトはcf initやcf init/deployで即座に立ち上げられる。静的サイトであれば設定ファイルなしでcf deployだけでデプロイ可能など、段階的な採用パスも用意されている。Cloudflareは今後、DNS設定やゾーン管理、ポリシー設定などもcloudflare.config.tsに統合していく方針を示唆しており、cfをCloudflare全体を管理する単一の入り口として位置づけていく考えとみられる。

概要 Google Cloudは、AIエージェントからの大量アクセスが本番データベースの性能に影響を及ぼさないようにする新機能「PostgreSQL for agents in AlloyDB」を発表した。複数のAIエージェントが正確な情報を求めて同時にデータベースへアクセスすると、予期できないほどのアクセス急増が発生し得る。こうした負荷が本番のプライマリデータベースに直接波及すると、既存のアプリケーションやサービスの性能低下を招きかねないという課題に対応するものだ。 技術的な仕組みと機能 新機能では、AIエージェント専用にサンドボックス化されたPostgreSQLのデータベースインスタンスを数秒で自動プロビジョニングできる。このサンドボックスインスタンスは、プライマリ、スタンバイ、リードレプリカといった本番系のインスタンスから完全に隔離された構成となっており、AIエージェントがどれだけ激しくアクセスしても本番環境の可用性や性能に影響を与えない設計になっている。 サンドボックスインスタンス自体もAIエージェントの負荷に応じて自動的にスケールし、1秒間に数百万件規模のクエリを処理できる性能を備える。加えて、インデックス、ベクトル検索、全文検索、空間検索を含むPostgreSQLのフル機能をそのまま利用できる点も特徴で、AIエージェント向けだからといって機能が制限されることはない。タスクが完了すればインスタンスは自動的にゼロまでスケールダウンされ、不要なコストが発生し続けることもない。 導入のしやすさと今後の展望 この仕組みの利点は、ETLパイプラインなどでデータを別システムへ複製・同期する必要がなく、単一のAlloyDBサービス内で完結する点にある。データの二重管理や同期遅延といった運用上の負担を増やすことなく、AIエージェントに本番相当のデータアクセスを提供できることになる。 現時点ではプレビュー版として利用登録の受付が始まっており、今後正式リリースに向けて機能拡充が進むとみられる。AIエージェントによるデータベース利用が急速に広がる中、本番システムへの影響を抑えつつエージェント向けの拡張性を確保するアプローチとして、他のクラウドベンダーやデータベース製品への波及も注目される。

概要 Microsoftは9月25日、Copilot StudioやCopilot Cowork、Copilot Codeなどで作成したアプリのコードを、Microsoft 365テナント内でMicrosoftが直接ホスト・実行できるエンタープライズ向けプラットフォーム「Copilot Managed Runtime」のパブリックプレビューを公開した。業務部門がAIを使って手軽にアプリを作れるようになった一方、IT部門はそのコードがどこでどう動いているのかを把握・統制しづらいという課題が生じていた。Copilot Managed Runtimeは、こうしたAI生成アプリの実行基盤をMicrosoft自身が引き受けることで、作成のしやすさと企業統治の両立を図るものだ。 解決しようとしている課題 Microsoftは、これまで開発チームがアプリを1つ動かすたびに、クラウドリソースのプロビジョニングとセキュア化、ID・セキュリティモデルの構成、組織ポリシーの遵守、デプロイプロセスの確立といった運用作業を個別に積み上げる必要があったと説明する。こうした「作成のたびに発生する運用作業」がチームの足を引っ張り、余計なリソースを消費させ、しかも使うツールごとに異なるガバナンスモデルを生み出してきたという。AIがアプリ作成のハードルを下げ続けるほど、信頼性や管理体制もそれに見合う速度で追いつく必要がある、というのがMicrosoftの問題意識だ。 技術的な仕組みとガバナンス機能 Copilot Managed Runtimeでは、Microsoftが運営するクラウド上で、テナント内のコードをホスト・実行する。開発者向けにはSDKとCLIが用意され、プロジェクト構成、データ接続の定義、TypeScriptの型付けサービス生成、開発時のプレビュー、デプロイとバージョニングまでを一貫してサポートする。ガバナンス面では、Microsoft Entraベースのアクセス制御により認可されたアクセス管理を行うほか、コネクタやデータアクセス、承認エンドポイントといった組織ポリシーを適用でき、監査ログも取得される。運用面ではGit連携による自動バージョン管理、デプロイメントのライフサイクル管理に加え、IT部門はMicrosoft 365管理センターからアプリの一元的なインベントリ管理・使用状況監視・ヘルスモニタリングを行える。 対象ユーザーとエコシステムへの広がり このプラットフォームは、ビルド経験の違いを問わず一貫したガバナンスモデルを提供する点が特徴だ。業務部門のユーザーはCopilot CoworkやCopilot Codeで直感的にアプリを構築でき、専門的な開発者はSDKを用いてより高度な開発を行える。すでにCopilot Cowork、Copilot Code、Copilot Studioの3つは本ランタイム上で稼働しており、SDKプラグインを通じて第三者製のローコード・AIアプリ構築ツールとの連携も可能になっている。実際、AIアプリ構築サービスのLovableはグローバルパートナーシップ責任者Lan Roche氏のコメントとして、SDKを利用することでLovableで作成したアプリが企業テナント内で同じサインイン、ポリシー、アプリインベントリのもとで実行できるようになると述べており、Microsoft純正のツールにとどまらないエコシステム形成を進めていることがうかがえる。IT部門は管理センターのアプリ体験からポリシー設定と機能の有効化を行えるため、既存の統制フレームワークに組み込みやすい設計になっている。 今後の展望 Copilot Managed Runtimeは現時点ではプレビュー段階であり、対応ツールの拡大やガバナンス機能の充実が今後の焦点になるとみられる。企業内でAI生成アプリが急速に増える中、実行基盤とガバナンスをMicrosoft 365のエコシステムに統合するこの動きは、いわゆる「シャドーIT」化しがちな業務部門主導の開発を、IT部門の管理下に取り込む狙いがあると考えられる。SDKを介したサードパーティツールとの連携が今後どこまで広がるかが、このプラットフォームがMicrosoft製品の枠を超えた業界標準的な基盤になれるかどうかを左右しそうだ。

概要 Dockerは9月24日（現地時間）、米カリフォルニア州パロアルトで開催されたWeAreDevelopers North Americaにおいて、AIエージェント向けのクラウド実行環境「Docker Cloud Sandboxes」を発表した。2月に発表済みのローカル版「Docker Sandboxes」と同じCLI、信頼モデル、そしてエージェント構成をパッケージ化する「Kits」をそのままクラウドへ拡張したもので、開発者のノートPCがシャットダウンした後もエージェントのワークフローをクラウド上で継続実行できる。稼働中のサンドボックスはsbx move my-project --to cloudという単一コマンドでローカルとクラウドの間を移動でき、ファイルシステムをキャプチャして移動先で再現する仕組みにより作業を中断せずに引き継げる。 技術的な特徴と価格体系 基盤にはローカル版と同じハードウェア強化型のmicroVM分離を採用しており、数百ミリ秒という高速起動を保ちながら1〜16 vCPUまで弾力的にスケールする。エージェント本体・ツール（MCPゲートウェイを含む）・アクセス制御ルール・エージェント設定をひとつにまとめる「Kits」は、v3仕様で標準OCIイメージとしてパッケージ化され、Docker Hubやgithubで配布しbuildやpullの対象にできるようになった。これによりベンダーロックインを避けつつ、Mixinsから構成を組み立てられる。価格は従量課金制で、最小構成の「Micro」インスタンス（1 vCPU、メモリ2GB）が1時間0.07ドル程度からとなっており、新規申し込み者には250ドル分の無料クレジットが提供される。無人のオフィスでマシンを起動し続ける運用を避けたい開発者にとって、数十〜100以上のサブエージェントを並列実行するような大規模なコーディング作業や、5〜21時間に及ぶ長時間タスクを最初はローカルの無料環境で、規模が拡大すればクラウドへとスムーズに切り替えられる点が実務上のメリットとして挙げられている。 Dockerの狙いとCNCFへの標準化提案 Docker社長のMark Cavageは「最新のエージェント型ワークフローは、隔離に対して根本的に異なるアプローチを必要とする。Dockerを象徴するコンテナは今も重要な役割を担うが、AIエージェントが求める水準の隔離を想定して設計されたものではない」と述べ、コンテナとは別次元の隔離基盤としてSandboxesを位置づける。またCPOのMat Velloso氏は、エージェントを安全なガードレール付きで大規模に稼働させる仕組みが依然として業界共通の課題だと指摘した。DockerはKits仕様をCNCFに提出する計画も明らかにしており、CNCFのCTOであるChris Aniszczyk氏は「標準OCIイメージとしてSandbox Kitsを提供することで、AIエージェントとそのツール、ガードレールを一つの成果物としてパッケージ化するオープンで再現可能な方法を業界に提供する」とコメントしている。Deutsche Bankのリード DevOps エンジニアも、microVM環境における安全で自律的なコーディングを可能にする取り組みとして評価を寄せた。 残る課題と今後の展望 一方で、サンドボックスによる隔離だけではエージェントが外部サービスにアクセスする際の制御まで保証できないという指摘も出ている。Redditのユーザーからは、サンドボックス化されたエージェントがサンドボックスの外に出なくても外部サービスと通信して被害を及ぼし得るとの懸念が示され、Hacker Newsでも従来型のサンドボックスは適切な抽象化ではなく、オブジェクト能力（object-capability）に基づくハーネスが必要だとの主張が上がっている。Dockerは今回のCloud SandboxesをAI Governance製品と組み合わせることで組織全体のポリシー管理を強化する方針を示しており、Kits仕様のCNCFへの提出とあわせて、コンテナ時代に築いた立ち位置をAIエージェント時代の「ビルドプラットフォーム」として拡張できるかが今後の焦点となる。