AWS Nitro Sandboxes提供開始、AIエージェントをVMで隔離【2026年11月】

AI エージェントにコードを書かせて、そのまま実行させる——そんな使い方が当たり前になるほど、「エージェントが変なコードを動かしても、周りに被害が出ないか」が気になってきます。

2026年11月9日（米国時間）、AWS は 「AWS Nitro Sandboxes」の提供を開始したと発表しました。EKS のポッドや ECS のタスク、AI エージェントを、1つずつ専用のハードウェア隔離の仮想マシン（VM）で動かせる仕組みです。追加料金はなく、東京・大阪を含む世界の商用リージョンで使えます。

Introducing AWS Nitro Sandboxes on Amazon EKS, ECS and EC2 for hardware isolated pods, tasks and VMs

コンテナの手軽さはそのままに、1つずつを VM の壁で区切る——AI エージェントの時代に合わせた、AWS の隔離の新しい基本部品という位置づけです。

AWS Nitro Sandboxesとは？一言でまとめると

「EC2 インスタンスの中に作れる、ハードウェアで隔離された小さな VM」です。EC2 の土台である Nitro Hypervisor が管理し、中で動くものは親のインスタンスやほかのサンドボックスのメモリに手を出せません。

What’s New は、信頼できないコード・複数の顧客（マルチテナント）・規制のあるワークロードを、1台のインスタンスの中で安全に動かせると説明しています。

なぜ必要？コンテナの「カーネル共有」の弱点

ふつうのコンテナは、1台のマシンの中で1つの Linux カーネル（OS の中心部分）を共有しています。軽くて便利な反面、AWS のブログは次の弱点を挙げています。

• カーネルの弱点を1つ突かれると、同じマシンのほかのコンテナにも被害が広がりうる
• 共有クラスターの運用者は、中で動くすべてのタスクに手が届く

Nitro Sandboxes では、ポッド・タスク・エージェントがそれぞれ自分の VM と自分のカーネルを持つので、1つのサンドボックスで起きたカーネルの問題が隣に及びません。しかも AWS によると、クラスターの管理者もプラットフォームのチームも、AWS 自身も、EKS のポッドや ECS のタスクのメモリを読めない設計になっています。

土台は、AWS が何年も運用してきた Nitro Enclaves と同じ隔離の技術です。Enclaves はとても小さく閉じた環境でしたが、Sandboxes では CPU を親と時分割で共有でき、ふつうのネットワークやディスクもつなげるように広げた——というのが AWS の説明です。

何ができる？主な使い道

AWS のブログは、次のような使い道を挙げています。

① AI エージェントのコード実行

コードを書いて実行するエージェントを、セッションごとに別のサンドボックスで動かせます。プロンプトインジェクション（悪意ある指示の埋め込み）でエージェントが変なコードを動かしても、その VM の中に閉じ込められ、セッションが終われば VM ごと消せます。

② SaaS の顧客ごとの隔離

SaaS の事業者は、顧客ごとに専用のインスタンスを用意する代わりに、共有の EKS ノードや ECS Managed Instances の上で、顧客ごとのサンドボックスを並べられます。1台を相乗りできる分、利用率が上がりコストが下がるとされています。

③ CI/CD のビルド

権限の強いビルドや、外部から届いたプルリクエストのコードを、専用のビルド機ではなくジョブごとの VM の中で動かせます。

④ 機密のモデル・監査

機密モードでは、モデルの提供者が重みを公開しないモデルを顧客のアカウントに置いても、復号は証明済みのサンドボックスの中だけにできます。規制のある業界では、何が動いたかの暗号学的な証拠を監査に出せるとしています。

AI エージェントに本物の AWS を触らせずに試させる、という点では、同じ週に出た AWS 公式のエミュレーターも関係が深い話題です。

あわせて読みたい

AWS公式のローカルエミュレーター登場、無料・アカウント不要【2026年11月】

2つのモード：隔離モードと機密モード

EKS と ECS では、「誰を信頼するか」で2つのモードを選びます。

機密モードでは、起動したイメージやポリシーを測った「証明書（アテステーション）」が作られます。AWS KMS（鍵の管理サービス）のキーポリシーにその値を条件として書くと、正しいコードが動いていると証明できたサンドボックスにだけ、秘密の鍵が渡されます。

EKS では、ポッドごとに Cedar というポリシーの言語で、読み込めるイメージや exec・ログの可否まで決められます。また、生成したコードを動かすときなどは、ネットワークのデバイス自体を持たせない設定（sandbox.amazonaws.com/network-isolated）もできます。

なお EC2 で直接使う場合は、機密モード（既定）と、親がメモリを読める代わりにアテステーションの無い直接モードの2つです。モードは起動時に選び、あとから変えられません。

料金・提供状況：東京・大阪でも使える？

What’s New には「すべての商用リージョン」とだけあり、リージョンごとの一覧は載っていません。東京・大阪は AWS のリージョン一覧で通常のリージョンとされているため、東京・大阪でも使えることになります。使うインスタンスタイプが対応しているかは、EC2 ユーザーガイドの表で確かめてください。

使い始め方：EKS・ECS・EC2

① EKS（いちばん簡単）

AWS が推奨するのは EKS Auto Mode です。追加の設定も AMI の作成も要らず、ポッドの spec に1行足すだけで動きます。

spec:
  runtimeClassName: isolated-sandbox   # 機密モードは confidential-sandbox

あとは kubectl apply するだけで、ポッドはサンドボックスの中で動きます。ユーザーガイドによるとアプリのコードの変更は不要です。ただし Kubernetes 1.36 以降が必要で、eksctl で作るときは --version を指定するよう注意されています。自前のノードグループでは、Nitro Sandbox のランタイム入りの AMI と、起動テンプレートでの Nitro Enclaves の有効化（EnclaveOptions.Enabled=true）が必要です。

② ECS

ECS Managed Instances で使えます。キャパシティプロバイダーで nitroEnclavesEnabled を有効にし、タスク定義の trustedExecutionConfiguration で isolationMode を ISOLATED_SANDBOX か CONFIDENTIAL_SANDBOX にします。ネットワークモードは awsvpc で、タスクごとに専用のネットワークインターフェースが付きます。

③ EC2 で直接

自分でプラットフォームを作る場合は、自分の AMI・オーケストレーション・VMM で EC2 の上に直接起動できます。今ネイティブに対応しているのは Amazon Linux と Firecracker です。

注意点・制限

EC2 ユーザーガイドには、使う前に押さえたい制限がまとまっています。

① GPU は使えない

GPU パススルーは現在使えません。GPU 付きのインスタンスでも、サンドボックスの中はCPU の処理だけです。

② 数とサイズに上限がある

親の vCPU 1つあたり最大5個、1台で最大896個まで。メモリは1つあたり 256 MiB 以上を割り当てるよう案内されています。

③ 親と運命をともにする

親のインスタンスを止める・再起動する・終了すると、サンドボックスも止まります。実行中に vCPU やメモリを変えることも、スナップショット・一時停止・ライブマイグレーションもできません。

④ 親から見えるもの・届くもの

親に渡したディスクは、親から読めます（EBS の暗号化では親からは守れない）。また、親が通信を中継すると、サンドボックスから親の IAM ロールの認証情報に届いてしまうことがあるため、親で 169.254.169.254 への通信を拒否するよう求めています。

⑤ EKS Auto Mode の一時的な制限

提供開始時点では、r5a・r5ad・m5ad は EKS Auto Mode のサンドボックスで使えません（AWS は一時的な制限としています）。

Lambda・Nitro Enclavesとの使い分け

EC2 ユーザーガイドは、「どこまで自分で管理したいか」で選ぶよう整理しています。

• 何も管理したくない → AWS Lambda MicroVMs（インスタンスもネットワークも管理不要）
• 自分のインスタンスで、境界は AWS に強制してほしい → Nitro Sandboxes（エージェント・顧客ごと・ビルドなど、1台を相乗りさせる一般的な場合）
• 小さく閉じた処理で、とても機密性の高いデータを扱う → Nitro Enclaves（外部ネットワークも保存先も持たない）
• 自分のハイパーバイザーや OS を動かしたい → 入れ子の仮想化（Intel のインスタンスだけ）

AWS のサーバーレスの新しい動きは、Lambda Web Functions の記事でも紹介しています。

あわせて読みたい

Lambda Web Functionsとは？Next.jsもそのまま【2026年10月】

開発者の反応

技術系コミュニティ Hacker News では、発表の投稿にコメントが付いています。数はまだ多くありません。

• CI やエージェントの作業場の顧客ごとの隔離に Sysbox を使っているという投稿者は、ランタイムクラスと少しの設定で済むなら、置き換えられそうだとコメントしています（出典）
• 別の投稿者は、Kubernetes のクラスター管理のまま、スタック全体でハードウェアの隔離が得られる点を高く評価しています（出典）

IT Picks的な所感

「AI エージェントが動かすコードは、信用しない前提で囲う」という考え方を、AWS が追加料金なしの標準の部品にした意味は大きいと考えています。AWS のブログも、強い境界が要るワークロードには別々のインスタンスを用意するのがこれまでの答えだったと書いています。それが既存のインスタンスに相乗りさせたまま、EKS なら1行で済むのは手軽です。

一方で、GPU が使えない・親と一緒に止まる・親に渡したディスクは親から読めるなど、制限もはっきりしています。とくに機密モードを使うなら、KMS のキーポリシーでアテステーションを確かめないと守りが完成しないと EKS のガイドが強調している点は要注意です。まずは隔離モードで、エージェントや CI のジョブから試すのが現実的だと思います。

AI エージェントに VPS やサーバーを操作させる仕組みは、こちらの記事で比べています。

あわせて読みたい

AIエージェントでVPSを操作するには？主要3社のMCP比較【2026年版】

まとめ

AWS Nitro Sandboxes のポイントをまとめます。

• 発表日：2026年11月9日（米国時間）
• 何ができる：EKS のポッド・ECS のタスク・AI エージェントを、1つずつ専用の VM で隔離
• モード：隔離モード（ノードは信頼）／機密モード（ノードも信頼しない・アテステーション）
• 料金：追加料金なし（EC2 と、EKS Auto Mode・ECS Managed Instances の通常の料金）
• リージョン：すべての商用リージョン（東京・大阪を含む）
• 始め方：EKS は Auto Mode で runtimeClassName: isolated-sandbox（Kubernetes 1.36 以降）
• 制限：GPU 不可・flex インスタンス不可・親と一緒に停止

AI エージェントや外部のコードを EKS で動かしているなら、まずは1つのポッドを隔離モードに切り替えるところから始めてみてはいかがでしょうか。

IT Picks 編集部

ITツール・Webサービス紹介メディア

IT Picks 編集部。VPS・クラウド・AIツール・SaaSを中心に、実際に検証した情報を届けるITメディアです。「本当に使えるか」を基準に、初心者からエンジニアまで役立つ記事を制作しています。