Azure Container Apps Sandboxesは、AIエージェントやユーザー投稿コード、CI/CDの一時実行環境など「信頼しきれないコード」を安全に動かすための新しいAzure Container Appsのプレビュー機能です。結論から言うと、既存のAzure Container Appsをすぐ置き換える機能ではなく、分離実行・状態保持・短時間起動・バースト対応が必要なワークロード向けの新しい選択肢です。2026年6月3日時点の公式ドキュメントでは、サンドボックスはMicrosoft.App/SandboxGroupsという最上位リソースとして扱われ、アプリ、ジョブ、動的セッションと並ぶ位置づけになっています。(Microsoft Learn)
特に確認すべきポイントは、プレビュー段階であること、専用RBACロールが必要なこと、エグレス制御を既定拒否で設計すべきこと、スナップショットやボリュームに残る状態を管理対象に含めることです。Azure Updatesの「In preview」は、Azure顧客が非本番の利用・テスト目的で利用できる段階と説明されているため、本番採用は検証結果とMicrosoftの最新サポート状況を確認して判断しましょう。(Microsoft Azure)
Azure Container Apps Sandboxesとは
Azure Container Apps Sandboxesは、高速で安全な一時的コンピューティング環境を提供するAzure Container Appsのプレビュー機能です。サンドボックスは独立したセキュリティ境界で実行され、信頼されていないコードを安全に実行する用途が想定されています。主な特徴として、2秒未満のスタートアップ、アイドル時のスケールゼロ、数百の同時サンドボックスへのスケールアウト、OCIコンテナーイメージの利用、メモリとディスクを含む状態のスナップショット、ライフサイクル制御が挙げられています。(Microsoft Learn)
従来、AIエージェントのツール実行、ユーザーごとの開発環境、マルチテナントSaaS上のコード実行、CI/CDの一時ビルド環境を安全に動かすには、VM、コンテナー、キュー、ストレージ、ネットワーク制御を組み合わせて独自基盤を作る必要がありました。Azure Container Apps Sandboxesは、この領域をAzure Container Appsの管理リソースとして扱えるようにする点が大きな変更です。Microsoftの発表でも、GitHub CopilotのCloud Sandboxes、Foundry Hosted Agents、Azure Container Apps Expressの基盤として使われるインフラを、自社ソリューションでも利用できるようにする趣旨が説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
今回のPublic Previewで変わること
今回の変更は、Azure Container Appsに「ステートフルな分離実行環境」という選択肢が加わったことです。通常のContainer AppsはWebアプリやAPIの継続実行、Jobsは実行完了型のバッチ処理、Dynamic SessionsはLLM生成スクリプトなどのマネージドなコード実行に向いています。一方、Sandboxesは作成、一時停止、再開、削除といったライフサイクルを明示的に制御し、スナップショットやボリュームで状態を扱う用途に向いています。(Microsoft Learn)
| 項目 | 従来ありがちだった構成 | Azure Container Apps Sandboxesでの考え方 |
|---|---|---|
| 信頼できないコードの実行 | VM、Kubernetes、ACI、独自ジョブ基盤を組み合わせる | 分離されたサンドボックスを作成して実行する |
| 状態保持 | 外部DBやストレージに逃がす、またはセッション破棄 | メモリ・ディスクを含むスナップショットやボリュームを使う |
| バースト対応 | 事前確保、キュー制御、スケール設定を自前で調整 | オンデマンドで多数のサンドボックスへ拡張する |
| アイドル時コスト | 待機VMやノードの費用が残りやすい | アイドル時はスケールゼロを前提に設計できる |
| セキュリティ境界 | コンテナー分離に追加対策を重ねる | サンドボックス単位の独立した境界とエグレス制御を使う |
実務上の意味は、「AIが生成したコードをどこで安全に実行するか」「ユーザーごとに分離された作業環境をどう作るか」「短時間だけ大量に必要な実行環境をどう扱うか」という設計課題に、Azure標準の部品で答えやすくなることです。
影響を受ける利用者とシステム
Azure Container Apps Sandboxesの影響が大きいのは、次のようなチームです。
| 対象 | 影響 | まず確認すべきこと |
|---|---|---|
| AIエージェント開発チーム | エージェントが生成したコードやツール呼び出しを分離環境で実行しやすくなる | 実行コードの権限、外部APIへの接続先、状態保持の範囲 |
| SaaS・マルチテナント基盤チーム | テナントごとの分離実行環境を作りやすくなる | テナント分離、ログ監査、ネットワーク許可リスト |
| 開発環境提供チーム | ユーザーごとの一時開発環境をオンデマンドで作れる | スナップショットの保存期間、ボリューム、削除ポリシー |
| CI/CD管理者 | ビルド・テスト用の一時環境として検証できる | 同時実行数、成果物保存先、シークレットの扱い |
| Azure管理者 | 新しいリソース種別、RBAC、ネットワーク制御の管理対象が増える | Container Apps SandboxGroup Data Ownerロール、Entra ID、監査設計 |
一方で、通常のWeb API、長時間稼働するバックエンド、ステートレスなイベント処理をすでにAzure Container Appsで安定運用している場合、すぐにSandboxesへ移す必要はありません。公式ドキュメントでも、長時間稼働サービスはApps、実行完了型タスクはJobs、マネージドなコード実行はDynamic Sessions、ライフサイクル制御付きの分離コンピューティングはSandboxesという使い分けが示されています。(Microsoft Learn)
管理者が最初に確認すべき設定
専用RBACロールを割り当てる
サンドボックスを作成・管理するには、AzureロールのContainer Apps SandboxGroup Data Ownerが必要です。このロールがないとサンドボックス操作を実行できないため、管理者は誰に、どのスコープで付与するかを先に決める必要があります。(Microsoft Learn)
最初からサブスクリプション全体に広く付与するのではなく、検証用リソースグループに限定して付与するのが安全です。AIエージェント開発チーム、CI/CDチーム、プラットフォームチームが別々に使う場合は、サンドボックスグループも用途別に分けると監査しやすくなります。
Microsoft Entra ID要件を確認する
公式ドキュメントでは、サンドボックスへのアクセスはMicrosoft Entra IDアカウントが必要で、個人用Microsoftアカウントはサポートされないと説明されています。検証を始める前に、利用者のアカウント種別、テナント、権限付与フローを確認しておきましょう。(Microsoft Learn)
開発者が個人アカウントで試そうとして失敗する、別テナントのユーザーにロールを付けたつもりで操作できない、というトラブルが起きやすいポイントです。
エグレスポリシーは既定拒否から始める
信頼できないコードを実行する場合、もっとも注意すべきなのは外部通信です。Azure Container Apps Sandboxesにはエグレスポリシーエンジンが組み込まれており、サンドボックスからの送信トラフィックを許可、拒否、変換、書き換えできます。Microsoft Learnでは、信頼できないコードを実行するサンドボックスではdefault_action = Denyにし、必要な宛先だけを明示的に許可する開始姿勢が推奨されています。(Microsoft Learn)
たとえば、AIエージェントが外部APIを呼び出す場合、インターネット全体を許可するのではなく、必要なLLM API、社内API、パッケージ取得先などを用途ごとに許可します。管理者は「どのサンドボックスが、どの宛先へ、どのHTTPメソッドで通信できるか」をレビューできる状態にしておくべきです。
開発者が押さえるべき実装ポイント
OCIコンテナーイメージを前提に環境を標準化する
Sandboxesでは、独自のOCIコンテナーイメージをサンドボックスのルートファイルシステムとして使用できます。(Microsoft Learn)
開発チームは、実行時に毎回パッケージをインストールするのではなく、必要なランタイム、CLI、ライブラリ、検査ツールをイメージに含めておくと起動後の処理を短くできます。特にCI/CDやAIエージェントのツール実行では、同じベースイメージを使い回すことで、再現性と監査性が高まります。
スナップショットに何を残すかを設計する
スナップショットは、実行中サンドボックスのメモリやディスクを含む完全な状態をキャプチャできます。用途としては、一時停止と再開、正常状態からの複製、構成済み環境の共有が挙げられています。(Microsoft Learn)
便利な一方で、スナップショットには作業ファイル、キャッシュ、一時的な認証情報、実行途中のデータが含まれる可能性があります。開発者は「スナップショットに残してよいもの」と「外部ストアやシークレット管理に逃がすもの」を分けて設計する必要があります。
| 状態の種類 | 例 | 推奨される扱い |
|---|---|---|
| メモリ内の状態 | 実行中プロセス、途中計算、エージェントの一時コンテキスト | 再開が必要な短期状態だけを保持する |
| ローカルディスク | /tmp、作業ディレクトリ、生成ファイル | 保存期間と削除条件を決める |
| 外部状態 | Blob Storage、DB、外部APIに保存した結果 | 永続データとしてアクセス制御と監査を行う |
| シークレット | APIキー、トークン、接続文字列 | 原則としてコードやスナップショットに埋め込まない |
ボリュームの使い分けを決める
サンドボックスには永続ストレージとしてボリュームをマウントできます。公式ドキュメントでは、Azure Blobはサンドボックス間で共有するデータや成果物に、データディスクはデータベース、ビルドキャッシュ、大きな作業セットなど高パフォーマンス用途に使うものとして整理されています。(Microsoft Learn)
CI/CDなら成果物はBlob、ビルドキャッシュはデータディスク、AIエージェントの中間ファイルは保持期間を短くした専用領域に置く、といった分け方が現実的です。
Dynamic Sessionsとの違い
Azure Container Appsには、すでにDynamic Sessionsという分離実行の仕組みがあります。Sandboxesと混同しやすいですが、使いどころは異なります。
| 比較項目 | Dynamic Sessions | Azure Container Apps Sandboxes |
|---|---|---|
| 主な用途 | マネージドなコード実行、LLM生成スクリプト | ライフサイクルを制御した分離コンピューティング |
| 状態 | エフェメラル、クールダウン後に破棄 | スナップショットやボリュームでステートフルに扱える |
| 操作モデル | セッションプールの管理エンドポイント経由 | 個別サンドボックスをSDKやCLIで直接制御 |
| 開発者の制御範囲 | プール管理に任せる | ファイル、ポート、ポリシー、ライフサイクルを管理 |
| 向いている例 | 一時的なPython実行、コードインタープリター | 長いエージェントタスク、開発環境、CI/CD、マルチテナント実行 |
公式ドキュメントでも、インフラを抽象化したマネージド実行体験が必要ならDynamic Sessions、状態の永続化を伴う分離コンピューティングをプログラムで制御したいならSandboxesを選ぶ、という整理がされています。(Microsoft Learn)
展開前に確認したい設計チェックリスト
Azure Container Apps Sandboxesを検証する場合は、機能確認だけでなく、運用・セキュリティ・コストを含めたチェックリストを作ることが重要です。
| 確認項目 | 判断基準 |
|---|---|
| ユースケース | 信頼できないコード、AIエージェント、ユーザー別環境、CI/CDなど分離実行が必要か |
| 本番可否 | プレビュー段階のため、まず非本番で検証する |
| RBAC | Container Apps SandboxGroup Data Ownerを最小スコープで付与しているか |
| ネットワーク | エグレスを既定拒否にし、必要な宛先だけ許可しているか |
| シークレット | イメージ、環境変数、スナップショットに秘密情報を残していないか |
| 状態管理 | メモリ、ローカルディスク、外部ストレージの責任範囲を分けているか |
| ライフサイクル | 自動中断、自動削除、保持期間を決めているか |
| 監査 | 作成、実行、通信、削除、拒否された通信を追跡できるか |
| コスト | CPU、メモリ、ディスク、ログ、永続ストレージ、外部API利用料を含めて確認しているか |
| 変更耐性 | プレビュー中のCLI、SDK、API変更に備えているか |
特に注意したいのは、スケールゼロを「すべて無料」と解釈しないことです。公式ドキュメントではアイドル時に支払いが発生しないことが特徴として示されていますが、永続ストレージ、ログ、外部サービス、データ転送など、周辺リソースの費用は別途確認が必要です。(Microsoft Learn)
よくある失敗パターン
プレビュー機能を本番前提で設計してしまう
公式ドキュメントでは、プレビュー中に作成されたサンドボックスは将来のリリースと互換性がない可能性があり、再作成が必要になる場合があると明記されています。また、Python SDKやAzure Container Apps CLIコマンドのAPIサーフェスもプレビュー中に変更される可能性があります。(Microsoft Learn)
そのため、IaCやCI/CDに組み込む場合は、コマンドやAPIの変更を吸収できるようにしておきます。検証段階では、手順書に「確認時点のCLIバージョン」「利用したAPI」「作成したリソース名」「再作成手順」を残すと、仕様変更時の復旧が早くなります。
エグレスを広く許可してしまう
サンドボックスの目的は、信頼できないコードを隔離して安全に実行することです。外部通信を広く許可すると、情報漏えい、意図しないAPI呼び出し、不正なパッケージ取得のリスクが高まります。
実務では、まず本番相当のポリシーをDeny基準で作り、開発環境だけ一時的に緩める形にします。公式ドキュメントでも、開発、ステージング、本番で別々のポリシーを維持し、本番はロックダウンする考え方が示されています。(Microsoft Learn)
スナップショットに秘密情報を残してしまう
スナップショットはメモリとディスクを含むため、便利であるほど取り扱いに注意が必要です。APIキーや一時トークンをファイルに書き出すアプリケーション、CLIの認証キャッシュを残すビルド処理、.envを作業ディレクトリに置く開発環境は、スナップショット化する前に見直すべきです。
認証が必要な外部API呼び出しでは、エグレスポリシーのTransformやRewriteを使ってヘッダーを付与し、サンドボックス内のコードに資格情報を直接持たせない設計も検討できます。Microsoft Learnでは、Transformアクションにより静的値、シークレット参照、マネージドID参照からヘッダーを付与できることが説明されています。(Microsoft Learn)
具体的な活用シーン
AIエージェントのコード実行基盤
AIエージェントが、ユーザーの依頼に応じてPythonコードを生成し、データ加工、検証、ファイル生成を行うケースでは、サンドボックスが有力です。エージェント本体と実行環境を分離し、外部通信を許可リスト化し、タスクの途中状態をスナップショットで保持できます。
たとえば、データ分析エージェントが大きなCSVを読み込み、途中で追加指示を待つ場合、処理済みデータやメモリ上の状態を保持して再開できると、毎回の再ロードや再計算を避けやすくなります。
マルチテナントSaaSのユーザーコード実行
ユーザーが独自スクリプトをアップロードして実行するSaaSでは、テナントごと、ユーザーごと、ジョブごとの分離が重要です。サンドボックスグループをアプリケーション、チーム、環境別に整理し、各サンドボックスを独立したCPU、メモリ、ディスク、ネットワーク境界を持つインスタンスとして扱えます。(Microsoft Learn)
実装では、テナントIDをリソース名やタグ、ログ属性に含め、削除ポリシーと監査ログを連動させると運用しやすくなります。
CI/CDの一時ビルド・テスト環境
CI/CDでは、PRごとに一時環境を作り、テスト完了後に削除する使い方が考えられます。公式ドキュメントでも、CI/CDパイプラインは未使用時にゼロまでスケールする一時的なビルド・テスト環境としてSandboxesの利用シナリオに含まれています。(Microsoft Learn)
ただし、ビルドキャッシュや成果物をどう残すかは別問題です。再現性を優先するならキャッシュを最小化し、速度を優先するならデータディスクやBlobを適切に使います。どちらの場合も、資格情報をビルドログやスナップショットに残さない設定が必要です。
導入判断の目安
Azure Container Apps Sandboxesを試すべきかどうかは、次の基準で判断すると整理しやすくなります。
| 判断 | 条件 |
|---|---|
| すぐ検証すべき | AI生成コード、ユーザー投稿コード、テナント別処理など、信頼できないコードを実行している |
| 検証価値が高い | 開発環境やCI/CDで、一時環境の起動時間やアイドル時コストが課題になっている |
| 慎重に検証すべき | 本番データ、機密情報、厳格なネットワーク制御、長期互換性が必要 |
| 現時点で優先度が低い | 通常のWeb APIやステートレスなバックエンドが安定して稼働しているだけ |
最初の一歩としては、本番移行を急ぐよりも、既存の「危険度が高いが範囲を限定できる処理」を1つ選び、PoCを作るのが現実的です。たとえば、AIエージェントのツール実行、PR単位のテスト環境、社内向けの一時開発環境などです。
管理者・開発者が次に取るべき行動
まず、現在のAzure環境で「信頼できないコードをどこで実行しているか」を棚卸ししてください。次に、候補ワークロードを1つ選び、検証用リソースグループでContainer Apps SandboxGroup Data Ownerを最小権限で付与します。そのうえで、OCIイメージ、エグレス既定拒否、スナップショットの保存方針、自動中断・自動削除、ログ監査をセットで設計します。
Azure Container Apps Sandboxesは、AIエージェント時代の実行基盤として魅力的な機能ですが、プレビュー段階では「使えるか」だけでなく「安全に管理できるか」を確認することが重要です。小さなPoCで、起動時間、状態保持、通信制御、削除漏れ、コストを測定し、既存のDynamic Sessions、Jobs、通常のContainer Appsと比較してから採用範囲を決めるのが失敗しにくい進め方です。
コメント