Azure REST APIの「Add SandboxGroup API to Microsoft.ContainerInstance TypeSpec」は、Azure Container Instances系の管理APIに新しいSandboxGroupリソースを追加する更新です。結論から言うと、既存のcontainerGroupsをすぐ置き換える変更ではなく、Microsoft.ContainerInstanceに対してSandboxGroupsの作成・取得・一覧・更新・削除・接続用トークン取得を扱う新しいAPI群が追加される内容として確認すべきです。対象は、Azure REST APIを直接呼び出す開発者、SDK生成やTypeSpec/Swaggerを追跡しているチーム、Azure Container Instances周辺の自動化・ネットワーク・権限管理を担当する運用者です。PR上では2026-06-01-preview APIバージョンの追加として説明されています。(GitHub)
重要なのは、この更新が「単なるドキュメント文言の追加」ではなく、REST API仕様に新しいリソース型と操作を定義する変更だという点です。2026年5月5日前後のPR更新ではTypeSpec検証やBreaking Change関連の修正も扱われており、実装やSDK生成に影響する可能性があるため、正式に利用する前に最終的なAPI仕様、Microsoft Learnへの反映、SDKの対応状況を確認する必要があります。(GitHub)
Azure REST APIで追加されるSandboxGroup APIの要点
今回の更新では、Microsoft.ContainerInstanceサービスにSandboxGroupという新しいTracked Resourceが追加されます。PR説明では、SandboxGroups_ListBySubscription、SandboxGroups_ListByResourceGroup、SandboxGroups_Get、SandboxGroups_CreateOrUpdate、SandboxGroups_Update、SandboxGroups_Delete、SandboxGroups_Connectの7つの操作が新APIとして挙げられています。CreateOrUpdate、Update、Deleteは非同期処理として扱われる想定です。(GitHub)
| 変更点 | 内容 | 実務で見るべきポイント |
|---|---|---|
| 新リソース | SandboxGroup | 既存のcontainerGroupsとは別の管理対象として扱う |
| APIバージョン | 2026-06-01-preview | previewなので本番採用前に変更リスクを評価する |
| 操作 | 一覧、取得、作成/更新、PATCH更新、削除、connect | CRUDに加えて接続用トークン取得がある |
| モデル | SandboxGroupProperties、SandboxGroupAccessToken、SandboxGroupNetworkProfile、SubnetReferenceなど | ネットワーク、ID、トークン、プロビジョニング状態の扱いを確認する |
| SDK影響 | APIViewでTypeSpec、Go、JavaScript、Python、Java、Swaggerのレビューが作成 | RESTだけでなく生成SDKの型やメソッド名にも波及する可能性がある |
PR上では、APIレビュー対象としてTypeSpec、Go、JavaScript、Python、Java、Swaggerが挙げられています。REST APIを直接呼ばないチームでも、Azure SDKやIaCツールが新しいSwagger/TypeSpecを取り込む場合は影響を受ける可能性があります。(GitHub)
既存のContainer Groupsとの違い
現在のAzure Container Instances REST APIでは、containerGroupsに対してCreate Or Update、Delete、Get、List、Restart、Start、Stop、Updateなどの操作が公開されています。今回のSandboxGroupsは、その既存containerGroups操作群に混ざる単なる別名ではなく、/providers/Microsoft.ContainerInstance/sandboxGroups配下に置かれる新しいリソース操作として定義されています。(Microsoft Learn)
つまり、実務上は「既存コンテナーグループのAPIバージョンだけを変えればSandboxGroupになる」と考えないほうが安全です。エンドポイント、リクエストボディ、更新可能なプロパティ、非同期処理のポーリング方法、権限要件を個別に確認する必要があります。
追加されるSandboxGroups操作一覧
Swagger定義上、主なパスは次のように整理できます。すべてAzure Resource Managerの管理エンドポイントhttps://management.azure.com配下で、api-version=2026-06-01-previewを指定する前提です。Azure Resource Manager系のREST APIでは、要求URIにapi-versionを含め、AuthorizationヘッダーにBearerトークンを付けて呼び出すのが基本です。(GitHub)
| 操作 | HTTPメソッド | パスの概要 | 用途 |
|---|---|---|---|
SandboxGroups_ListBySubscription | GET | /subscriptions/{subscriptionId}/providers/Microsoft.ContainerInstance/sandboxGroups | サブスクリプション配下のSandboxGroup一覧 |
SandboxGroups_ListByResourceGroup | GET | /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ContainerInstance/sandboxGroups | リソースグループ内のSandboxGroup一覧 |
SandboxGroups_Get | GET | /sandboxGroups/{sandboxGroupName} | 指定したSandboxGroupの取得 |
SandboxGroups_CreateOrUpdate | PUT | /sandboxGroups/{sandboxGroupName} | SandboxGroupの作成または置換更新 |
SandboxGroups_Update | PATCH | /sandboxGroups/{sandboxGroupName} | タグやIDなどの部分更新 |
SandboxGroups_Delete | DELETE | /sandboxGroups/{sandboxGroupName} | SandboxGroupの削除 |
SandboxGroups_Connect | POST | /sandboxGroups/{sandboxGroupName}/connect | 接続用エンドポイントとアクセストークンの取得 |
CreateOrUpdateは201応答時にAzure-AsyncOperationとRetry-Afterヘッダーを返す長時間実行操作として定義されています。UpdateとDeleteも長時間実行操作として扱われ、LocationやRetry-Afterを使ったポーリングが必要になる可能性があります。自動化スクリプトでは、PUTやDELETEの直後にリソースが利用可能・削除済みになったと決め打ちしないことが重要です。(GitHub)
SandboxGroupモデルで確認すべきプロパティ
SandboxGroupはTracked Resourceとして定義され、propertiesとidentityを持ちます。properties配下にはprovisioningState、networkProfile、managementResourceGroupIdが含まれます。provisioningStateとmanagementResourceGroupIdは読み取り専用として扱われる定義です。(GitHub)
特に確認すべきなのはnetworkProfileです。networkProfileにはsubnetsが含まれ、SubnetReferenceのidでサブネットのARMリソースIDを指定します。TypeSpec上のコメントでは、サブネットに対してMicrosoft.Network/virtualNetworks/subnets/join/action権限が必要とされています。ネットワーク分離やVNet統合を前提にした運用では、APIを呼ぶIDにContainer Instance側の権限だけを付与しても失敗する可能性があります。(GitHub)
作成時のリクエストイメージは次のようになります。実際の利用可否、必須項目、リージョン対応は最終仕様とAzure環境で確認してください。
{
"location": "japaneast",
"identity": {
"type": "SystemAssigned"
},
"properties": {
"networkProfile": {
"subnets": [
{
"id": "/subscriptions/<subscriptionId>/resourceGroups/<networkRg>/providers/Microsoft.Network/virtualNetworks/<vnetName>/subnets/<subnetName>"
}
]
}
},
"tags": {
"env": "dev",
"owner": "platform-team"
}
}運用上は、provisioningStateを使って作成・更新・削除の完了状態を判断します。PR上の定義ではSucceeded、Failed、Canceled、Updating、Deleting、Acceptedなどの状態が含まれています。監視やCI/CDでは、HTTPステータスだけでなく、最終的なリソース状態まで確認する設計にしてください。(GitHub)
connectアクションの扱いはセキュリティ上重要
SandboxGroups_Connectは、指定したSandboxGroupへ接続するためのエンドポイントとアクセストークンを取得するPOST操作です。戻り値のSandboxGroupAccessTokenにはendpoint、accessToken、notAfterが含まれ、accessTokenはシークレットとして定義されています。(GitHub)
この操作は、単なる状態取得APIではありません。アクセストークンを返すため、ログ出力、監査、保存先、再利用範囲を厳しく管理する必要があります。特に、以下のような実装は避けるべきです。
| 避けるべき実装 | なぜ危険か | 推奨対応 |
|---|---|---|
accessTokenをCIログやアプリログに出す | 接続権限が漏えいする可能性がある | レスポンス全体をログに出さず、必要項目だけマスクする |
notAfterを見ずにトークンを使い回す | 期限切れで接続失敗する | 有効期限を見て再取得する |
| connect権限を広いロールに含める | 不要な利用者が接続情報を取得できる | カスタムロールや最小権限で分離する |
| 本番と検証で同じ自動化IDを使う | 誤操作時の影響範囲が広がる | サブスクリプション、リソースグループ、環境ごとにIDを分ける |
connectは便利な操作ですが、運用設計では「誰が、どのSandboxGroupに、どのタイミングで接続情報を取得できるか」を明確にする必要があります。特に監査ログでは、トークン値ではなく、操作主体・対象リソース・実行時刻・結果だけを追跡できる形にするのが現実的です。
対応が必要なチームと影響範囲
この更新で直ちに全Azure利用者が作業する必要はありません。対応優先度が高いのは、Azure REST APIやAzure Container Instancesを自動化・SDK生成・ネットワーク統合の文脈で使っているチームです。
| 対象者 | 対応優先度 | 確認すべきこと |
|---|---|---|
| Azure REST APIを直接呼ぶ開発者 | 高 | 2026-06-01-preview、新パス、LRO、エラー形式、レスポンスモデル |
| SDK生成を追跡する開発チーム | 高 | Go/JavaScript/Python/Javaなどの生成メソッド名、型、プレビュー版の取り込み時期 |
| IaC・Platform Engineering担当 | 中〜高 | ARM/Bicep/Terraform AzAPIで新リソースを扱えるか、差分検出が安定するか |
| ネットワーク管理者 | 高 | サブネットID、join/action権限、VNet設計、管理用リソースグループの扱い |
| セキュリティ担当 | 高 | connectアクション、アクセストークン、Managed Identity、RBAC最小権限 |
| 既存のContainer GroupsだけをGUIやCLIで使う利用者 | 低 | 現時点では既存運用への強制移行として見る必要は薄い |
PRではAPIレビューのコメントとして、networkProfileがPATCHモデルに含まれていないため更新可能性が曖昧であること、エラーハンドリングの型が操作間で一貫していないこと、ARMリソースIDの型指定に関する指摘などが出ています。これは、最終的な仕様や生成SDKの型が変わる可能性を示します。preview APIを早期検証する場合でも、本番ワークロードへ組み込む前に最終差分を必ず確認してください。(GitHub)
移行ではなく「採用可否の評価」として進める
今回のSandboxGroup APIは、既存のContainer Groups APIをただちに廃止する案内ではありません。まずは移行計画を立てるより、次の順序で採用可否を評価するのが安全です。
既存処理を棚卸しする
最初に、現在どの箇所でAzure Container Instancesを操作しているかを洗い出します。対象はアプリケーションコードだけではありません。CI/CD、運用スクリプト、TerraformやBicep、監視ツール、棚卸しツール、権限付与スクリプトも含めて確認します。
特に、Azure REST APIを直接呼んでいる場合は、URLに固定されたapi-version、containerGroupsを前提にしたパス、レスポンスJSONをパースする処理を確認してください。Azure REST APIはHTTPメソッド、URI、ヘッダー、リクエストボディ、レスポンスボディの組み合わせで動作するため、リソースパスが変わると既存のパーサーやエラー処理も影響を受けます。(Microsoft Learn)
preview APIは検証環境で分離する
2026-06-01-previewという名前のとおり、まずは検証サブスクリプションまたは検証リソースグループで試すべきです。preview APIは便利な一方、正式版までにモデル名、プロパティ、エラー形式、SDKの型が変わることがあります。
検証では、少なくとも次を確認します。
| 確認項目 | 具体的な確認方法 |
|---|---|
| 作成 | PUT後にLROヘッダーを追跡し、最終状態がSucceededになるか |
| 更新 | PATCHで変更できる項目とできない項目を分ける |
| 削除 | DELETE後に204または最終的なリソース消滅を確認する |
| 一覧 | nextLinkが返るケースに備えてページング処理を入れる |
| 権限 | 作成者、更新者、connect実行者を別IDでテストする |
| ネットワーク | サブネットjoin権限がない場合のエラーを確認する |
| 監査 | connect操作時にトークンをログへ出さない設定を確認する |
Azure REST APIの一覧操作では、結果が多い場合にnextLinkを使ったページングが必要になることがあります。SandboxGroupsの一覧定義にもnextLinkが含まれるため、一覧取得処理では1回のGETで全件取得できる前提を置かないほうが安全です。(Microsoft Learn)
CLIで試す場合はaz restを使う
専用のAzure CLIコマンドがまだない段階でREST APIを試す場合、az restを使う方法があります。Microsoftのドキュメントでは、az restは既存のAzure CLIコマンドが利用できない場合に使うものと説明されており、ログイン済み資格情報からAuthorizationヘッダーを自動的に付与できます。(Microsoft Learn)
正式反映後に一覧取得を試す場合のイメージは次のとおりです。
SUBSCRIPTION_ID="<subscription-id>"
az rest \
--method get \
--url "https://management.azure.com/subscriptions/${SUBSCRIPTION_ID}/providers/Microsoft.ContainerInstance/sandboxGroups?api-version=2026-06-01-preview"作成や削除を試す場合は、検証用リソースグループ、検証用サブネット、検証用Managed Identityを使ってください。preview APIの検証を本番サブスクリプションで直接行うと、権限不足、予期しないLRO待ち、削除失敗、監査ログのノイズが運用に影響する可能性があります。
実装前に確認すべきチェックリスト
SandboxGroup APIを追跡するチームは、次のチェックリストを使うと抜け漏れを減らせます。
| 観点 | チェック内容 | 判断基準 |
|---|---|---|
| APIバージョン | 2026-06-01-previewを明示しているか | previewを使う理由と撤退条件を決めている |
| エンドポイント | sandboxGroupsパスを使っているか | containerGroupsと混同していない |
| LRO | PUT/PATCH/DELETE後のポーリング処理があるか | Azure-AsyncOperation、Location、Retry-Afterを処理できる |
| RBAC | 操作主体に必要最小限の権限があるか | 作成、更新、削除、connectを分離できる |
| ネットワーク | サブネットIDとjoin/action権限を確認したか | ネットワーク管理者と事前調整している |
| シークレット | accessTokenを保存・出力していないか | ログ、例外、監視イベントでマスクされる |
| SDK | 利用言語のSDKに反映済みか | 反映前ならREST直呼びまたは生成SDKの扱いを決める |
| IaC | ARM/Bicep/Terraform AzAPIで表現できるか | 差分検出と削除時の挙動を検証している |
| 監視 | provisioningStateを見ているか | HTTP成功だけで完了扱いにしていない |
| 変更追跡 | PRと最終ドキュメントの差分を確認したか | レビューコメントの未解決項目を把握している |
特に失敗しやすいのは、非同期操作とトークン処理です。PUTが201を返した直後に次の操作を実行すると、まだSandboxGroupが準備中で失敗する可能性があります。また、connectのレスポンスをデバッグログに丸ごと出すと、アクセストークンが漏えいするリスクがあります。
本番採用前の判断基準
本番でSandboxGroup APIを使うかどうかは、機能の魅力だけで決めないほうが安全です。以下の条件を満たしてから段階的に採用することをおすすめします。
| 判断項目 | 採用しやすい状態 | まだ待つべき状態 |
|---|---|---|
| 仕様の安定性 | PRがmainへ取り込まれ、公開ドキュメントと一致している | PRレビューでモデルやエラー型の指摘が残っている |
| SDK対応 | 利用言語のSDKで操作と型が確認できる | REST仕様だけ先行し、SDK反映時期が不明 |
| 権限設計 | connect実行者と作成/削除実行者を分離できる | 広いContributor権限で一括運用している |
| 運用監視 | LRO、失敗状態、トークン取得を監査できる | HTTP 200/201だけを成功条件にしている |
| ネットワーク | サブネット権限とVNet設計を検証済み | ネットワーク管理者のレビューが未完了 |
| IaC管理 | 作成・更新・削除の再現性を確認済み | 手作業で作ったリソースが混在している |
PR上では、PublishToCustomersラベルが追加されており顧客向け公開を意識した変更であることが示されています。一方で、後続レビューではTypeSpecモデルやエラー処理に関する指摘も出ています。実務では「使えるか」だけでなく「仕様変更があっても戻せるか」「本番影響を限定できるか」を採用判断に含めるべきです。(GitHub)
まず取るべき次の行動
このAzure REST API documentation updateを見たチームが最初にやるべきことは、既存環境の変更ではなく、影響範囲の切り分けです。Azure Container InstancesをREST API、SDK、IaC、自動化スクリプトで扱っている箇所を洗い出し、SandboxGroup APIを使う必要があるかを判断してください。
必要性がある場合は、検証環境で2026-06-01-previewのGET一覧、PUT作成、POST connect、DELETE削除を小さく試します。その際、LROのポーリング、サブネットjoin権限、Managed Identity、connectトークンのマスク、notAfterによる期限管理を必ず確認します。
既存のcontainerGroupsだけで要件を満たしている場合は、すぐに移行する必要はありません。今後のMicrosoft Learn、Azure SDK、azure-rest-api-specsのmain反映状況を追いながら、SandboxGroupを使う明確な理由が出たタイミングで検証を始めるのが現実的です。
コメント