結論から言うと、今回の Microsoft Azure documentation update は、Azure Confidential Computing の概要で「Intel SGX を使うアプリケーションエンクレーブ向け VM」の説明から DCsv2 を外し、DCsv3 / DCdsv3 を中心に案内する変更です。新しい Azure Portal の設定や API が追加されたわけではありません。
ただし、これは単なる文言修正として見過ごすべきではありません。DCsv2-series VM はすでに廃止予定が示されており、DCsv2 上で VM、VM Scale Sets、AKS の app-enclave aware containers を動かしている環境では、移行計画・クォータ・リージョン・一時ディスク・動的 IP・構成証明方式まで確認する必要があります。Microsoft の PR では、対象ファイル overview-azure-products.md の Intel SGX の説明から DCsv2 を削除し、DCsv3 / DCdsv3 のみを残す差分が確認できます。(GitHub)
Microsoft Azureの公式ドキュメント更新で何が変わったのか
今回の更新対象は、Azure Confidential Computing の製品概要にあたるドキュメントです。差分は小さく、GitHub 上では 1ファイルに対して 1行追加・1行削除の変更として扱われています。内容は、Intel SGX を使うアプリケーションエンクレーブ向け VM の記述から DCsv2 を削除するものです。(GitHub)
| 項目 | 変更前 | 変更後 | 実務上の意味 |
|---|---|---|---|
| Intel SGX を使うアプリケーションエンクレーブ向け VM | DCsv2、DCsv3、DCdsv3 | DCsv3、DCdsv3 | 新規設計や説明資料では DCsv2 を前提にしない |
| 変更対象 | Azure Confidential Computing の概要ページ | 同左 | VM が自動停止される変更ではない |
| 管理者への影響 | 既存 DCsv2 利用の棚卸しが必要 | DCsv3 / DCdsv3 または別方式への移行検討 | 廃止予定と合わせて対応する |
| 開発者への影響 | SGX エンクレーブの実行基盤に DCsv2 を含めて説明できた | DCsv3 / DCdsv3 を基準に考える | SDK、構成証明、性能検証を再確認する |
Microsoft Learn の英語版では、Intel SGX のアプリケーションエンクレーブ向け VM として DCsv3 and DCdsv3 が記載されています。一方、ローカライズ版の反映には時間差が出ることがあるため、日本語ページだけを見て判断せず、英語版や GitHub の差分も確認するのが安全です。(Microsoft Learn)
これはDCsv2の即時停止ではなく、移行判断を促すサイン
今回のドキュメント更新そのものは、Azure リソースを停止したり、設定を変更したりするものではありません。重要なのは、DCsv2 が Azure Confidential Computing の概要から外されたことが、既存の DCsv2 廃止予定と同じ流れにある点です。
Microsoft Learn の DCsv2-series retirement ガイドでは、DCsv2-series VM は 2026年6月30日に廃止予定 とされ、DCsv2 を使う VM、Virtual Machine Scale Sets、AKS の app-enclave aware containers が影響を受けると説明されています。(Microsoft Learn)
つまり、今回の更新を見た管理者が最初にやるべきことは、「概要ページから名前が消えたかどうか」を眺めることではなく、自社環境に DCsv2 が残っていないかを棚卸しすることです。
Azure Confidential Computingの中でDCsv2が担っていた位置づけ
Azure Confidential Computing は、保存時や通信時だけでなく、処理中のデータを保護するための仕組みです。Azure の公式ページでは、AMD SEV-SNP、Intel TDX、Intel SGX などの技術を使い、使用中のコードやデータへの不正アクセスや改ざんを防ぐことを目的としたオファリングが整理されています。(Microsoft Learn)
この中で DCsv2 は、Intel SGX を使ったアプリケーションエンクレーブ向けの旧世代 VM として位置づけられていました。SGX エンクレーブは、アプリケーションの一部を分離された領域で実行し、OS、ハイパーバイザー、管理者権限を持つユーザーからも保護する設計です。
ただし、現在の新規設計では DCsv2 を選ぶのではなく、次のように目的別に候補を考えるべきです。
| 目的 | 主な候補 | 判断のポイント |
|---|---|---|
| Intel SGX エンクレーブを継続したい | DCdsv3、DCsv3 | 既存 DCsv2 からの移行では一時ディスクの有無が重要 |
| 既存アプリをなるべく変更せず VM レベルで保護したい | DCasv5 / ECasv5、DCesv6 / ECesv6 など | SGX ではなく Confidential VM としての要件を満たすか確認 |
| コンテナー化したワークロードを保護したい | Confidential containers on ACI、AKS 関連オプション | オーケストレーション要件、CCE ポリシー、構成証明を確認 |
| AI / 機械学習で GPU も使いたい | NCCadsH100v5 など | リージョン、価格、GPU 容量、データ保護要件を確認 |
Azure Confidential Computing の概要では、AMD SEV-SNP を使う Confidential VM、Intel TDX を使う Confidential VM、GPU 付き Confidential VM、AKS ワーカーノード、ACI 上の Confidential containers などが整理されています。DCsv2 の削除は、「Azure Confidential Computing 全体が縮小する」という意味ではなく、古い SGX VM から現行の選択肢へ案内を寄せる変更と捉えるのが自然です。(Microsoft Learn)
影響を受ける可能性が高い対象者
DCsv2 VMを本番・検証環境で使っている管理者
最も影響が大きいのは、Standard_DC1s_v2、Standard_DC2s_v2、Standard_DC4s_v2、Standard_DC8_v2 などの DCsv2 サイズを使っている環境です。DCsv2 の公式ページでも、DCsv2-series VM は 2026年6月30日に廃止予定とされています。(Microsoft Learn)
特に以下の環境は優先して確認してください。
- 本番系の機密データ処理に DCsv2 を使っている
- PoC のまま長期間残っている DCsv2 VM がある
- VM Scale Sets で DCsv2 を使っている
- Azure Kubernetes Service の SGX / enclave 関連ノードで DCsv2 を使っている
- ARM テンプレート、Bicep、Terraform、CI/CD に DCsv2 サイズが直書きされている
SGXエンクレーブ前提で開発している開発者
開発者は、単に VM サイズを変えるだけでなく、アプリケーションの SGX 利用方法を確認する必要があります。特に、構成証明の方式、EPC メモリ使用量、SDK、ライブラリ、起動スクリプト、テストデータの置き場所を見直してください。
DCsv3 / DCdsv3 は Intel SGX と Intel Total Memory Encryption – Multi Key を使い、DCsv2 より大きな EPC メモリやメモリ容量を提供する世代として説明されています。(Microsoft Learn)
ただし、性能が上がるからといって、無検証で本番移行できるわけではありません。エンクレーブ内で扱うデータサイズ、初期化時間、構成証明のフロー、障害時の再起動手順は、必ずステージング環境で確認しましょう。
セキュリティ・監査・コンプライアンス担当者
セキュリティ担当者は、設計書や監査資料に「DCsv2」を前提とした記述が残っていないか確認してください。Azure Confidential Computing は「データ使用中の保護」を説明する場面で使われるため、金融、医療、公共、AI、マルチパーティ分析などの資料に古い VM サイズが残りやすい領域です。
監査対応で問題になりやすいのは、実際の Azure 構成ではなく、説明資料や運用手順書だけが古い状態です。ドキュメント更新を機に、クラウド設計標準、セキュリティ標準、テンプレート、ナレッジベースをまとめて更新してください。
管理者がまず確認すべきAzure上の設定
DCsv2 の有無は、Azure Portal で VM サイズを確認するだけでも分かります。ただし、複数サブスクリプションを運用している場合は、Azure Resource Graph や Azure CLI で棚卸しする方が確実です。
Resources
| where type =~ 'microsoft.compute/virtualmachines'
| where tostring(properties.hardwareProfile.vmSize) in (
'Standard_DC1s_v2',
'Standard_DC2s_v2',
'Standard_DC4s_v2',
'Standard_DC8_v2'
)
| project name, resourceGroup, subscriptionId, location, vmSize=tostring(properties.hardwareProfile.vmSize)VM Scale Sets も使っている場合は、次のように SKU を確認します。
Resources
| where type =~ 'microsoft.compute/virtualmachinescalesets'
| where tostring(sku.name) in (
'Standard_DC1s_v2',
'Standard_DC2s_v2',
'Standard_DC4s_v2',
'Standard_DC8_v2'
)
| project name, resourceGroup, subscriptionId, location, sku=tostring(sku.name)確認後は、単に「DCsv2 がある / ない」で終わらせず、次の観点で分類します。
| 確認項目 | 見るべきポイント | 対応の方向性 |
|---|---|---|
| VM サイズ | DCsv2 が使われているか | DCdsv3 など移行先を検討 |
| リージョン | 移行先 SKU が同一リージョンにあるか | クォータ申請またはリージョン移行を検討 |
| 一時ディスク | アプリやスクリプトが一時ディスクに依存していないか | DCdsv3 への移行や設計修正を検討 |
| パブリック IP | 動的 IP を使っていないか | 事前に静的 IP 化を検討 |
| 可用性要件 | 停止・再起動を許容できる時間帯があるか | メンテナンスウィンドウを確保 |
| 予約・課金 | Reserved Instances やコスト影響があるか | 予約の交換や Savings Plan を確認 |
| 構成証明 | Intel EPID / IAS 依存が残っていないか | 対応方式への移行を検討 |
移行先はDCdsv3を第一候補にしつつ、要件で分ける
DCsv2 からの移行で最初に検討しやすいのは DCdsv3-series です。Microsoft の移行ガイドでも、Intel SGX のエンクレーブベースの提供を継続したい場合は DCdsv3 への移行が推奨されています。(Microsoft Learn)
DCdsv3 はローカル一時ディスクを持つため、DCsv2 からの移行で一時ディスクの有無による差を抑えやすい選択肢です。DCdsv3 の仕様では、1〜48 vCPU、8〜384 GiB メモリ、75〜2,400 GiB のローカルストレージが示されています。(Microsoft Learn)
一方で、DCsv3 はローカル一時ディスクを持たないサイズです。Microsoft の FAQ では、ローカル一時ディスクを持つ VM サイズから持たない VM サイズへ、またはその逆へはリサイズできないと説明されています。DCsv2 から DCsv3 へ直接リサイズするのではなく、再作成やスナップショットを使った移行が必要になるケースがあります。(Microsoft Learn)
| 移行先 | 向いているケース | 注意点 |
|---|---|---|
| DCdsv3 | SGX エンクレーブを継続し、DCsv2 から近い形で移行したい | クォータ、リージョン、再起動時間を確認 |
| DCsv3 | 一時ディスクに依存せず、SGX エンクレーブを使いたい | DCsv2 からの単純リサイズが難しい場合がある |
| DCasv5 / ECasv5 | アプリを大きく変えず VM レベルの Confidential VM に寄せたい | SGX エンクレーブ用途とは保護モデルが異なる |
| DCesv6 / ECesv6 | Intel TDX ベースの Confidential VM を検討したい | 提供状況やプレビュー/GAの状態を公式情報で確認 |
| Confidential containers | コンテナー化済み、または今後コンテナー化する | CCE ポリシー、AKS/ACI の運用設計が必要 |
移行時に失敗しやすいポイント
リサイズではVMの再起動が発生する
DCsv2 から DCdsv3 などへリサイズする場合、VM の停止・割り当て解除・リサイズ・起動が必要になります。Microsoft の移行ガイドでも、リサイズは再起動を伴うため、業務ピークを避けて実施することが推奨されています。(Microsoft Learn)
本番環境では、事前に次の内容を決めておきましょう。
| 項目 | 事前に決めること |
|---|---|
| メンテナンス時間 | 何分まで停止を許容するか |
| ロールバック | 元の VM サイズやイメージへ戻す手順 |
| 監視 | 起動後に確認するメトリック、ログ、アプリの正常性 |
| 通知 | 業務部門、監査担当、開発チームへの連絡方法 |
動的IPが変わる可能性がある
VM を deallocate すると、割り当てられている動的 IP アドレスが解放される場合があります。Microsoft のガイドでも、deallocate により動的 IP が解放されること、OS ディスクやデータディスクは影響を受けないことが説明されています。(Microsoft Learn)
外部システムから IP 固定で接続されている場合は、移行前に静的 IP、DNS、Private Endpoint、Firewall ルールを確認してください。
リージョンによっては同じ場所で移行できない
DCdsv3 の利用可否はリージョンに依存します。Microsoft の移行ガイドでは、North Central US、Canada East、Australia Southeast、UK West で DCsv2 を実行している場合、利用可能なリージョンへの移行や新世代オファリングの検討が案内されています。(Microsoft Learn)
日本の利用者であれば、Japan East / Japan West の対応状況、サブスクリプションのクォータ、災害対策設計を合わせて確認してください。リージョンを変える場合は、レイテンシ、データ所在地、バックアップ、監査要件も影響します。
一時ディスク依存を見落とす
DCsv2 では一時ディスクを使っていたが、移行先で一時ディスクの有無や容量が変わることがあります。アプリケーションのキャッシュ、ログ、ページファイル、スクラッチ領域、カスタムスクリプトが一時ディスクを前提にしている場合、起動後に動作不良が起きる可能性があります。
Microsoft の FAQ でも、ローカル一時ディスクを指すカスタム OS イメージやスクリプトがある場合、ディスクレスサイズでは正しく動かない可能性が示されています。(Microsoft Learn)
Intel EPID / IAS依存を残さない
SGX の構成証明で Intel SGX Attestation Service の EPID / IAS に依存している場合は注意が必要です。Microsoft の DCsv2 移行 FAQ では、DCdsv3 VM では Intel SGX Attestation Service Utilizing Intel EPID を継続できないと説明されています。(Microsoft Learn)
これは VM サイズ変更だけでは解決しない問題です。アプリケーション側の構成証明フロー、証明書検証、外部サービス連携、運用手順まで確認してください。
開発者が確認すべき実装・展開上のポイント
開発者は、インフラ担当から「DCdsv3 に変える」と聞いた時点で、次の確認を始めるべきです。
| 確認対象 | 確認内容 |
|---|---|
| SGX SDK / ランタイム | 移行先 OS イメージ、ドライバー、ライブラリと互換性があるか |
| エンクレーブサイズ | EPC メモリ使用量、ピーク時の動作、エラー処理 |
| 構成証明 | IAS / EPID 依存がないか、Azure Attestation などの設計と整合するか |
| CI/CD | VM サイズ、リージョン、イメージ ID が固定されていないか |
| テスト | 本番相当データ量で性能、起動時間、再起動後の復旧を確認したか |
| ログ | 機密データが通常ログや一時ディスクに出ていないか |
よくある失敗は、「VM サイズだけ変えてアプリはそのまま」と考えることです。Confidential Computing は、通常の VM リサイズよりもアプリケーション実装とセキュリティ設計の結びつきが強い領域です。特に SGX エンクレーブでは、エンクレーブ内外のデータ受け渡し、鍵管理、構成証明の失敗時の処理を含めてテストしてください。
展開計画は4段階で進める
まずDCsv2の存在を棚卸しする
最初の作業は、全サブスクリプションで DCsv2 を洗い出すことです。Azure Portal だけでなく、Azure Resource Graph、Azure CLI、IaC リポジトリ、CI/CD の変数、社内手順書も確認してください。
特に Terraform や Bicep に VM サイズが固定されている場合、Azure 上のリソースを変更しても、次回デプロイで古い設定に戻る恐れがあります。
次に移行タイプを分類する
DCsv2 が見つかったら、次の3種類に分けます。
| 分類 | 例 | 対応 |
|---|---|---|
| 廃止できる | PoC、検証後に放置された VM | バックアップ後に削除 |
| SGXを継続する | エンクレーブ前提の本番アプリ | DCdsv3 / DCsv3 を検証 |
| 保護モデルを変える | VM レベル保護で十分な既存アプリ | Confidential VM やコンテナーを検討 |
すべてを DCdsv3 に置き換えるのではなく、業務要件ごとに「SGX が本当に必要か」を見直すことが重要です。
ステージング環境で検証する
本番移行前に、同じ OS、同じアプリバージョン、同じ構成証明フローでステージング検証を行います。確認すべき項目は、起動可否だけではありません。
- エンクレーブ初期化が成功するか
- 構成証明が成功するか
- ピーク時の EPC メモリ使用量に問題がないか
- ログに機密情報が出ないか
- 停止・起動・障害復旧後に正常化するか
- 監視アラートが正しく出るか
- バックアップと復元が機能するか
本番移行は停止時間とロールバックを決めてから行う
本番移行では、メンテナンスウィンドウ、関係者通知、ロールバック手順、移行後チェックリストを用意します。移行後に問題が起きた場合、「VM は起動しているが、構成証明だけ失敗している」「アプリは動くが性能が落ちている」といった状態もあり得ます。
移行完了後は、Azure リソースだけでなく、設計書、運用手順書、監査資料、社内ナレッジから DCsv2 の記述を削除または更新してください。
よくある疑問
今回の更新でDCsv2 VMはすぐ止まるのか
いいえ。今回のドキュメント更新自体で DCsv2 VM が即時停止されるわけではありません。ただし、DCsv2-series には 2026年6月30日の廃止予定が示されているため、既存環境がある場合は早めに移行計画を立てる必要があります。(Microsoft Learn)
新規構築でDCsv2を選んでもよいのか
新規構築では避けるべきです。公式の概要から DCsv2 が外され、DCsv2 の廃止予定も示されているため、SGX エンクレーブが必要なら DCsv3 / DCdsv3 を前提に設計する方が現実的です。
DCsv3とDCdsv3はどちらを選ぶべきか
DCsv2 からの移行では、ローカル一時ディスクの有無が大きな判断材料です。DCdsv3 はローカル一時ディスクを持ち、Microsoft の移行ガイドでも SGX 継続時の移行先として案内されています。一方、DCsv3 はローカル一時ディスクを持たないため、既存構成によっては単純なリサイズではなく再構築が必要になる場合があります。(Microsoft Learn)
日本語ドキュメントにDCsv2が残っている場合はどう判断するのか
ローカライズ版は反映が遅れることがあります。実務判断では、英語版の Microsoft Learn、GitHub の差分、Azure retirement ガイドを優先して確認してください。特に今回のような VM SKU や移行期限に関わる情報は、日本語ページだけで判断しない方が安全です。(Microsoft Learn)
今回の更新で取るべき次の行動
今回の Microsoft Azure documentation update は、Azure Confidential Computing の概要から DCsv2 を外す小さな差分です。しかし、実務上は DCsv2 廃止対応を進めるための明確な確認ポイントになります。
まず、Azure Resource Graph や Azure CLI で DCsv2 VM と VM Scale Sets を棚卸ししてください。次に、SGX エンクレーブを継続するのか、Confidential VM や Confidential containers へ設計を変えるのかを分類します。そのうえで、クォータ、リージョン、一時ディスク、動的 IP、構成証明、予約課金を確認し、ステージング検証から本番移行へ進めるのが安全です。
DCsv2 の名前が概要から消えたことよりも重要なのは、自社の構成・コード・手順書に DCsv2 がまだ残っていないかです。この記事を読んだ後は、まず DCsv2 の棚卸しを行い、該当リソースがあれば移行先候補と検証スケジュールを決めましょう。
コメント