- Amazon EKSのPodを専用の軽量仮想マシンで動かし、ホストや隣接する処理との境界をハードウェアで保護する。
- 通常の隔離と、管理者も信頼対象から外す機密モードを、扱うデータと証明の要件に応じて選ぶ。
- 企業は実行環境の条件に加え、AIに渡す認証情報と外向き通信の許可範囲を具体的に確認する。
AWSは2026年11月9日、コンテナの運用サービスAmazon EKS向けにNitro Sandboxesを発表した。コンテナをまとめて実行する単位であるPodごとに、専用の軽量仮想マシンを割り当てる。AIエージェントがコードを実行する環境で、同じ機械で動く他の処理への影響を隔離する仕組みだ。日本企業の担当者が選ぶべきモードと、実行権限・通信の設定を整理する。[1]
何が起きたのか
Nitro Sandboxesでは、各Podに専用のOSを持たせる。AWSの仮想マシン基盤であるNitro Systemが、CPUとメモリの境界をハードウェアで保護する。コンテナを動かすホストや隣接するPodから、その仮想マシンのメモリやCPUの状態を読み取ることを防ぐ設計である。利用者は、Podの実行方式を指定するRuntimeClassという設定で、この隔離を選ぶ。[1]
処理は通常のPodと同じように配置された後、専用の仮想マシン内で始まる。仮想マシン側の部品がPodの指定とCedarポリシーを受け取り、許可された処理かを確認してコンテナを起動する。Cedarポリシーは、この実行条件を表す規則である。ログ、稼働状況の確認、ストレージ、認証情報などは、既存のKubernetesの運用と接続する。[1]
EKSがPodを配置し、Nitroが専用仮想マシンの境界を保護する
Pod専用の軽量仮想マシン
出典 AWS「AWS Nitro Sandboxes: Hardware-enforced workload isolation on Amazon EKS」（2026年11月9日）
用意された実行方式は2つある。隔離モードは、コンテナ内で起きた問題からホストと周囲のPodを守る。機密モードは、機械を管理する担当者も信頼対象から外し、実行しているシステムイメージとポリシーを暗号技術で証明する。鍵管理サービスAWS KMSは、その証明を条件に復号を許可する。機密データを扱う企業は、誰からデータを保護する必要があるかでモードを選べる。[1]
なぜ今なのか
AWSが背景に挙げるのは、AIエージェントによるコードの生成・実行と、複数の顧客が計算資源を共有するサービスの拡大である。通常のコンテナは、OSの中核であるカーネルを共有する。コンテナを抜け出す問題が起きると、同じホストの秘密情報や他の処理へ影響が及ぶ可能性がある。外部の文書や課題を読むAIエージェントでは、入力に紛れた指示から意図しないコードを実行するリスクも考慮する必要がある。[1]
従来の対応としてAWSが示すのは、機密性の高い処理ごとに専用の機械を用意する方法だ。この方法では、空いている計算資源が増えやすい。今回の仕組みは、同じノードに複数のPodを配置しながら、それぞれを専用の仮想マシンで隔離する。隔離の単位をPodに合わせることで、機械の共有と処理の分離を組み合わせる。[1]
共有するカーネルから、Podごとに専用のOSを持つ構成へ変わる
出典 AWS「AWS Nitro Sandboxes: Hardware-enforced workload isolation on Amazon EKS」（2026年11月9日）
資源の共有では、CPUやメモリ以外も確認点となる。ネットワーク帯域、ディスクの入出力、名前解決、ログ出力、接続追跡の領域には、設定可能な制限が標準で用意される。大量に処理するAIやビルド作業が隣のPodへ影響するのを抑えるためだ。担当者は隔離の強さと合わせて、業務に必要な通信量や処理量を制限値の中で確保できるかを見る。[1]
日本の企業にとって何が変わるか
Amazon EKSを使う日本企業は、まずクラスタのバージョンとノードの構成を確認したい。必要なKubernetesのバージョンは1.36以降である。ノード管理を自動化するEKS Auto Modeでは実行方式が用意され、対応するノードを必要に応じて起動する。標準のEKSで独自のノードを管理する場合は、Nitro Sandboxesに対応したマシンイメージを準備する手順となる。[1]
AIの作業権限は、隔離環境と併せて設定する。AWSの開発エージェントの例では、モデル利用にはPod Identityで与えた権限を使い、Amazon Bedrockのモデル呼び出しへ範囲を絞った。GitHubへの接続には、有効期間が短く、対象リポジトリを限定したトークンを渡す。AIが使えるサービスと操作を認証情報ごとに絞ることが、実行を任せる範囲を明確にする。[1]
外向きの通信も別に制御する。紹介例では、EKS Auto ModeのApplicationNetworkPolicyで名前解決と必要なサービスへのHTTPS通信を許可する。適用にはネットワーク制御機能の有効化が必要だ。ホスト名の許可は同じ接続先アドレスを使う名前にも及び、GitHubの中でアクセスできるリポジトリはトークンの権限で制限する。ネットワークと認証の両方で許可範囲を確認する必要がある。[1]
機密モードを選ぶ場合は、復号を許可するイメージとポリシーを具体的に決める。仮想マシン内で起動した内容の証明をAWS KMSへ渡し、想定した環境だけで秘密情報を使えるようにする流れだ。外部通信が要らない処理では、ループバック以外のネットワークを持たせない設定も用意される。業務の接続要件を先に整理すると、許可する通信と完全に切り離せる処理を分けられる。[1]
- クラスタがKubernetes 1.36以降で、対応するノードを使えるか。
- AI用のモデル権限、GitHubトークン、通信先が業務に必要な範囲か。
- 機密モードで証明するイメージとポリシーを、復号条件へ反映できるか。
まとめ
Nitro Sandboxesは、AIが動かすコードの実行環境を、Podごとの仮想マシンへ分離する仕組みである。AWSの紹介例は、隔離された中で開発エージェントが課題を読み、修正、テスト、PR作成まで進める構成を示している。日本企業が導入を判断する際は、自社のAIにどこまでの操作を任せるかを、Podの設定と認証・通信の規則へ落とし込むことが重要になる。[1]
日々の運用では、既存のログや監視を使いながら、処理が所定の仮想マシンで起動したかを確認できる。機密データの処理では、さらに実行内容の証明を復号の条件にする。業務が必要とする操作と、実行環境が許可する操作を一致させることが、今回の機能を使う際の具体的な確認点である。[1]
技術・取り組み / 2026年11月9日
実行環境、認証情報、通信先を業務の要件に合わせる
専用の仮想マシンでAIのコードを実行する。
1 AIが生成したコードを実行する
2 複数の利用者がノードを共有する
3 機密処理の実行内容を証明する
1 EKSとノードの対応条件
2 トークンと通信の許可範囲
3 証明するイメージと復号条件
出典 AWS「AWS Nitro Sandboxes: Hardware-enforced workload isolation on Amazon EKS」（2026年11月9日）
