Azure Event Hubs DedicatedのConfidential ComputingがGA｜利用条件・データ境界・管理策

Azure Event Hubs DedicatedのConfidential Computingに対応すべきなのは、Dedicatedを新規構築でき、韓国中部またはUAE北部リージョンを利用でき、機密性の高いイベントデータを扱う組織です。既存の名前空間には後付けできず、日本リージョン、Standard、Premiumは現時点の対象に含まれません。そのため、多くの国内利用者にとって必要なのは、設定変更ではなく、リージョン・費用・移行を含めた採用可否の判断です。(Microsoft Learn)

今回の更新は、Copilotや生成AIモデルを追加するものではありません。一方、顧客情報、決済イベント、IoTデータなどをAI・分析基盤へリアルタイム連携するシステムでは、データ取り込み層の安全性を高める重要な更新です。

この記事では、Azure Event Hubs DedicatedのConfidential Computingで何が保護されるのか、利用条件、データ境界、管理者が実施すべき制御、既存環境からの移行判断まで具体的に解説します。

Azure Event Hubs DedicatedのConfidential ComputingがGAで何が変わったのか

2026年7月8日前後に確認されたAzure Updatesの公式情報では、Azure Event Hubs DedicatedがConfidential Computingをサポートし、処理中のストリーミングデータを保護できるようになったことが案内されています。

Azure Updatesの検索インデックスでは2026年7月7日付となっていますが、関連する技術文書は4月27日、Microsoft公式ブログは5月1日に先行公開されています。そのため、今回の更新は新機能が突然追加されたというより、実運用に利用できるGA機能としてステータスが明確になったものと捉えるのが適切です。(マイクロソフトAzure)

GAは本番利用を想定した正式提供を意味します。ただし、Azure Updates上で「Launched」となっていても、すべての料金プランやリージョンで利用できるわけではありません。(マイクロソフトAzure)

主な提供条件は次のとおりです。

項目	内容
提供状態	GA、本番環境で利用可能
対象料金プラン	Azure Event Hubs Dedicatedのみ
対応リージョン	韓国中部、UAE北部
有効化のタイミング	名前空間を新規作成するとき
既存名前空間への追加	不可
アプリケーションのコード変更	原則不要
主な保護対象	Event Hubsで処理中のイベントデータ
併用できる制御	カスタマーマネージドキー、プライベートエンドポイント、マネージドIDなど

特に重要なのは、既存のEvent Hubs Dedicated名前空間に設定を追加する方式ではない点です。既存環境でConfidential Computingを利用するには、対応する新しいDedicated環境を作成し、送信元やコンシューマーを切り替える必要があります。(Microsoft Learn)

Confidential Computingが保護する「使用中のデータ」とは

クラウド上のデータ保護は、一般に次の3つの状態に分けて考えます。

データの状態	具体例	Event Hubsでの保護
保存中	Event Hubs内部に保持されているイベント	既存の保存時暗号化、必要に応じてカスタマーマネージドキー
転送中	ProducerからEvent Hubs、Event HubsからConsumerへの通信	既存の転送中暗号化
使用中	Event Hubs内部でイベントを処理している状態	今回のConfidential Computingによる保護

保存中や転送中のデータが暗号化されていても、コンピューティング処理を行う際にはデータを使用可能な状態にする必要があります。Confidential Computingは、ハードウェアベースのTrusted Execution Environment、TEEと呼ばれる隔離された実行環境を使い、処理中のデータへの不正アクセスや改ざんのリスクを抑えます。(Microsoft Learn)

Azure Event Hubs Dedicatedでは、イベント処理にハードウェアレベルの分離が加わります。保存時暗号化や転送中暗号化を置き換えるのではなく、これまで別途考慮する必要があった「使用中」の保護を追加する機能です。

Dedicatedのシングルテナント構成との違い

Azure Event Hubs Dedicatedは、もともと単一テナント向けの専用クラスターです。他のテナントと割り当てリソースを共有しないため、クロステナントの負荷干渉を受けにくく、安定した性能を確保しやすい特徴があります。(Microsoft Learn)

ただし、シングルテナントとConfidential Computingは目的が異なります。

機能	主な目的
Dedicatedのシングルテナント構成	他テナントとのリソース共有や性能干渉を避ける
Confidential Computing	自組織のデータを処理している間のアクセスリスクを低減する
カスタマーマネージドキー	保存時暗号化に使うキーの管理権限を自組織で持つ
プライベートエンドポイント	Event Hubsへのネットワーク経路をプライベート化する

Dedicatedを使っているだけで、使用中のデータがConfidential Computingによって保護されるわけではありません。新規作成時に明示的な有効化が必要です。

利用前に確認すべき4つの条件

Event Hubs Dedicatedを採用できるか

Confidential ComputingはStandardやPremiumには追加できません。現在StandardまたはPremiumを利用している場合は、セキュリティ機能だけでなく、Dedicatedへの移行そのものを検討することになります。

Dedicatedは、企業規模のミッションクリティカルなイベントストリーミングを対象とする専用クラスターです。Capacity Unit単位でリソースを確保するため、少量のイベントを処理するシステムでは費用対効果が合わない可能性があります。必要なCapacity Unitは、Producer数、Consumer数、パーティション数、メッセージサイズ、送受信量などによって変わるため、実際のワークロードで検証することが推奨されています。(Microsoft Learn)

Confidential Computingだけを目的にDedicatedへ移行する場合は、次の要素をまとめて比較する必要があります。

• 機密データの重要度
• 想定するイベント流量
• 必要なレイテンシ
• Dedicatedの利用コスト
• 移行と運用に必要な工数
• 他のセキュリティ対策で代替できるか

対応リージョンを利用できるか

現時点で公式文書に記載されている対応リージョンは、次の2つです。

• 韓国中部
• UAE北部

東日本、西日本を含む日本リージョンは記載されていません。(Microsoft Learn)

国内システムで採用する場合は、単にAzure上で利用できるかだけでなく、次の点を確認してください。

確認事項	判断ポイント
データ所在地	契約、社内規程、顧客要件で国外保存が許可されているか
個人情報	国外移転に関する説明や社内手続きが必要か
通信遅延	ProducerとConsumerから対象リージョンまでの遅延が許容範囲か
ネットワーク費用	リージョン間・クラウド間の転送量が大きくならないか
障害設計	対応リージョン内で必要な可用性構成を組めるか
下流サービス	Event HubsのConsumer側も同一または近接リージョンへ配置できるか

日本国内にデータを保持することが必須なら、現時点では導入を急ぐべきではありません。対応リージョンの拡大を監視しつつ、データ最小化、トークン化、暗号化、アクセス制御を強化する方が現実的です。

新規名前空間を作成できるか

Confidential Computingは名前空間作成時に有効化する必要があり、既存名前空間には追加できません。(Microsoft Learn)

「コード変更不要」という説明は、ProducerやConsumerのイベント処理ロジックを書き換えずに利用できるという意味です。既存環境から切り替える場合は、少なくとも次の作業が発生します。

• 新しいDedicatedクラスターと名前空間の作成
• Event Hub、パーティション、Consumer Groupなどの再作成
• RBACやマネージドIDの再設定
• プライベートエンドポイントやDNSの設定
• 監視、アラート、診断設定の再構成
• ProducerとConsumerの接続先変更
• 切り替え前後のイベント欠落・重複対策

アプリケーションコードを変更しなくても、接続文字列、名前空間名、FQDN、マネージドIDの権限、ネットワーク経路は変わる可能性があります。

データの機密性が導入コストに見合うか

すべてのイベントをConfidential Computing対応環境へ移す必要はありません。

たとえば、公開情報だけを扱うアクセスログや、送信前に十分匿名化された統計データであれば、導入効果は限定的です。一方、次のデータでは検討価値が高まります。

• 氏名、住所、位置情報などを含むイベント
• 決済、送金、不正検知に関する取引データ
• 医療、健康、介護に関するデータ
• 工場や社会インフラの制御・稼働情報
• 顧客との会話や問い合わせ内容
• AIモデルへ入力する業務データや特徴量
• セキュリティ監視で収集する詳細ログ

判断の基準は「Confidential Computingが新しいから」ではなく、処理中のデータにアクセスされた場合の影響がどれほど大きいかです。

保護されるデータ境界と保護されない範囲

Confidential Computingを有効にしても、イベントストリーミング全体が自動的に機密コンピューティング化されるわけではありません。

公式情報が示す「Event Hubsで処理中のイベント」という範囲を、一般的なイベントパイプラインに当てはめると次のように整理できます。

処理段階	今回の機能による保護	別途必要な対策
端末・業務システムでイベントを生成	対象外	端末保護、アプリケーション認証、秘密情報管理
ProducerからEvent Hubsへ送信	今回の追加機能の中心ではない	TLS、プライベートエンドポイント、ネットワーク制御
Event Hubs内部でイベントを処理	対象	Confidential Computingの有効化
Event Hubs内部にイベントを保持	既存の保存時暗号化が中心	必要に応じてCMK、Managed HSM
Consumerがイベントを受信	Event Hubsの保護範囲外	マネージドID、RBAC、ネットワーク制御
Functions、Databricks、Fabricなどで処理	対象外	下流サービス側の暗号化、認証、機密コンピューティング
Data Lakeやデータベースへ保存	対象外	保存先の暗号化、CMK、アクセス制御

つまり、Event Hubs DedicatedのConfidential Computingは、パイプラインの中間にあるEvent Hubsの処理部分を強化する機能です。

たとえば、Event Hubsから受信した顧客データを通常構成の仮想マシンで処理すれば、その仮想マシン上のデータは今回の機能では保護されません。エンドツーエンドで使用中のデータを保護したい場合は、Consumer側でもConfidential VMや対応する機密コンピューティングサービスを選ぶ必要があります。

Azure portalで有効化する手順

Azure portalでは、名前空間の新規作成時に設定します。

1. Azure portalでEvent Hubs名前空間の作成画面を開きます。
2. 料金レベルとして「Dedicated」を選択します。
3. リージョンに「韓国中部」または「UAE北部」を選択します。
4. 「Confidential compute」を「Enabled」にします。
5. Dedicatedクラスターや名前空間に必要な項目を設定します。
6. 内容を確認してリソースを作成します。

既存名前空間の設定画面に、後から有効化するための切り替え項目は用意されていません。(Microsoft Learn)

本番環境ではportalから手作業で作成するより、BicepやARMテンプレートを利用し、設定をコードとして管理する方が安全です。

BicepでConfidential Computingを有効にする方法

Confidential Computingは、DedicatedクラスターのplatformCapabilities.confidentialCompute.modeをEnabledにして構成できます。

Microsoft Learnの機能解説にはプレビュー版APIを使った例がありますが、現在のARMリソースリファレンスでは、安定版の2026-01-01にも同じプロパティが定義されています。(Microsoft Learn)

@description('Event Hubs Dedicatedクラスター名')
param clusterName string

@description('Confidential Computing対応リージョン')
@allowed([
  'koreacentral'
  'uaenorth'
])
param location string = 'koreacentral'

@description('Dedicated Capacity Unit')
@minValue(1)
param capacity int = 1

resource eventHubsCluster 'Microsoft.EventHub/clusters@2026-01-01' = {
  name: clusterName
  location: location
  sku: {
    name: 'Dedicated'
    capacity: capacity
  }
  properties: {
    supportsScaling: true
    platformCapabilities: {
      confidentialCompute: {
        mode: 'Enabled'
      }
    }
  }
}

output clusterResourceId string = eventHubsCluster.id

Dedicatedクラスターの作成後、このクラスターのリソースIDをclusterArmIdとして参照する名前空間を作成します。

実務では、リージョンの値を自由入力にせず、上記のように@allowedで制限しておくと、未対応リージョンへの誤デプロイを防げます。

また、CI/CDで次の項目を検証すると設定漏れを減らせます。

• SKUがDedicatedであること
• 対象リージョンが許可リストに含まれること
• confidentialCompute.modeがEnabledであること
• マネージドIDが設定されていること
• パブリックネットワークアクセスの方針に合っていること
• 診断設定とアラートが作成されること

管理者が組み合わせるべきセキュリティ制御

Confidential ComputingだけでEvent Hubsのセキュリティが完成するわけではありません。目的ごとに異なる制御を重ねる必要があります。

管理策	保護する対象	実務上の役割
Confidential Computing	使用中のイベント	Event Hubs内部の処理をハードウェアレベルで分離
カスタマーマネージドキー	保存中のデータ	暗号化キーの管理権限を自組織で保持
Managed HSM	暗号化キー	検証済みハードウェア内でキーを保管
プライベートエンドポイント	ネットワーク経路	パブリックインターネット経由の接続を削減
マネージドID	サービス間認証	接続文字列やシークレットへの依存を軽減
Microsoft Entra IDとRBAC	管理・データ操作権限	最小権限でアクセスを制御
Azure Policy	構成ルール	Confidential Computingの設定漏れを防止
Azure Monitor	運用状況	負荷、エラー、接続異常などを監視

カスタマーマネージドキーとManaged HSMを併用する

Microsoftは、より高いデータ保護が必要な場合、Confidential Computingと、Azure Key Vault Managed HSMで保護したカスタマーマネージドキーを組み合わせる構成を案内しています。

この構成では、役割を次のように分けます。

• Confidential Computingで使用中のデータを保護する
• カスタマーマネージドキーで保存時暗号化キーを管理する
• Managed HSMで暗号化キーをハードウェア保護する

カスタマーマネージドキーは、PremiumとDedicatedで利用できます。ただし、新規または空の名前空間でなければ有効化できません。すでにEvent Hubが存在する名前空間で暗号化設定を追加すると失敗するため、初期設計に組み込む必要があります。(Microsoft Learn)

Managed HSMを使う場合はユーザー割り当てマネージドIDを先に作る

Confidential Computingとカスタマーマネージドキーを組み合わせる場合、Microsoftはユーザー割り当てマネージドIDの利用を求めています。

理由は、Event Hubs名前空間を作成する前に、そのIDへManaged HSMのアクセス権を付与する必要があるためです。システム割り当てマネージドIDは名前空間の作成後に生成されるので、この順序を満たせません。(Microsoft Learn)

推奨する作成順序は次のとおりです。

1. ユーザー割り当てマネージドIDを作成する
2. Key Vault Managed HSMと暗号化キーを用意する
3. マネージドIDへ必要なキー操作権限を付与する
4. Confidential Computing対応のDedicatedクラスターを作成する
5. マネージドIDとカスタマーマネージドキーを指定して名前空間を作成する
6. Event HubやConsumer Groupを作成する

名前空間を先に作成してしまうと、暗号化設定を追加できない場合があります。IaCでは依存関係を明示し、作成順序を固定してください。

Azure Policyで設定漏れを防ぐ

Microsoft Learnでは、Confidential Computingが有効になっていないDedicatedクラスターを監査または拒否するカスタムAzure Policyの例が示されています。

評価に使われる主なエイリアスは次のとおりです。

Microsoft.EventHub/clusters/platformCapabilities.confidentialCompute.mode

値がEnabledではないリソースに対し、AuditまたはDenyを適用できます。ポリシーは管理グループ、サブスクリプション、リソースグループ単位で割り当てられます。(Microsoft Learn)

最初からDenyを適用すると、既存のデプロイパイプラインを停止させる可能性があります。次の順序で展開するのが安全です。

1. Auditで現在の構成を把握する
2. 対象外システムと例外条件を整理する
3. IaCテンプレートを修正する
4. テスト用スコープでDenyを検証する
5. 本番サブスクリプションや管理グループへ展開する

すべてのDedicatedクラスターに一律適用するのではなく、機密データを扱うサブスクリプションやランディングゾーンに限定する方法もあります。

業務や開発で効果が期待できる使いどころ

金融取引と不正検知

カード決済、送金、注文、口座操作などのイベントをリアルタイムで収集し、不正検知エンジンへ送るシステムでは、データがEvent Hubs内で処理される間の保護を強化できます。

ただし、検知モデルや保存先データベースまで自動的に保護されるわけではありません。Consumer側の処理基盤、ログ出力、デバッグ情報にも機密データが残らない設計が必要です。

医療・ヘルスケアデータの取り込み

医療機器、ウェアラブル端末、診療システムなどからイベントを集約するケースでは、健康情報や識別情報が含まれる可能性があります。

Confidential Computingは多層防御の一部として有効ですが、利用リージョン、データの国外移転、保存期間、アクセス権、監査ログなどを含めて評価しなければなりません。

製造業・社会インフラのIoTデータ

工場設備、電力、交通、防災設備などのテレメトリには、稼働状況だけでなく、設備構成や制御に関わる情報が含まれます。

高スループットが必要で、すでにDedicatedを採用する規模のシステムなら、性能の専用性と使用中データの保護を組み合わせやすい用途です。

AI・リアルタイム分析基盤へのデータ連携

顧客との会話、問い合わせ履歴、センサー情報、行動イベントなどをAIモデルや分析サービスへ送るシステムでは、Event Hubsがデータ取り込みの中心になります。

今回の機能によりEvent Hubs内部の処理は強化できますが、次の部分は別途保護する必要があります。

• AIモデルへ渡した後の入力データ
• 推論結果や生成結果
• プロンプトや会話履歴の保存先
• 特徴量ストアや分析データベース
• 開発者が閲覧できるトレースやログ
• 下流システムの一時ファイルやキャッシュ

「AI基盤に接続しているから導入する」のではなく、Event Hubsを通過するデータの機密度と、処理経路全体の保護方針で判断してください。

既存環境から移行する場合の実務手順

既存名前空間へ有効化できないため、移行は新しい環境への切り替えとして計画します。

現在の構成とデータを棚卸しする

最初に、次の情報を一覧化します。

• 現在の料金プランとリージョン
• Dedicatedクラスターの種類とCapacity Unit
• Event Hub数とパーティション数
• Consumer Group
• ProducerとConsumer
• イベント保持期間
• Captureなどの関連機能
• 認証方式
• ネットワーク構成
• カスタマーマネージドキー
• 監視、ログ、アラート
• データ分類と規制要件

この段階で「Confidential Computingが必要なイベント」と「通常環境でよいイベント」を分離すると、Dedicatedのコストを抑えやすくなります。

リージョンと性能を事前検証する

韓国中部またはUAE北部に小規模な検証環境を作り、実際のProducerとConsumerに近い条件で確認します。

検証すべき項目は次のとおりです。

• 平均・最大送信レート
• 受信遅延
• スロットリングやサーバーエラー
• Consumer Lag
• ProducerとConsumerからのネットワーク遅延
• イベントサイズ
• パーティションごとの負荷偏り
• 障害発生時の再送と重複
• Capacity Unitの使用率
• リージョン間通信量

GAだからといって、現在の環境と性能が完全に同じとは限りません。想定負荷を使ったテスト結果でCapacity Unitと構成を決めてください。

新しい環境をIaCで構築する

検証後、次のリソースをBicepやARMテンプレートで作成します。

1. ユーザー割り当てマネージドID
2. Managed HSMと暗号化キー
3. Confidential Computing対応Dedicatedクラスター
4. Event Hubs名前空間
5. Event HubとConsumer Group
6. プライベートエンドポイントとDNS
7. RBAC
8. 診断設定とアラート
9. Azure Policyの割り当て

開発、検証、本番で同じテンプレートを使い、パラメーターだけを変える構成にすると、環境差異を抑えられます。

送信先を段階的に切り替える

切り替え方法は、イベントの重複を許容できるか、送信元を変更できるかによって選びます。

切り替え方法	向いているケース	注意点
一時的な二重送信	Producerを変更でき、重複を処理できる	送信量と費用が増える
Producerを順番に切り替え	複数の送信元がある	新旧環境にイベントが分散する
メンテナンス時間に一括切り替え	短時間停止できる	停止中イベントの再送設計が必要
中継サービスで複製	Producerを変更しにくい	中継部分が新たな障害点になる

切り替え前には、新旧環境でイベント数、オフセット、処理件数、エラー件数を比較できる仕組みを用意してください。

Azure Event Hubsでは、StandardまたはPremiumからDedicatedへデータを自動移行する仕組みは提供されていません。既存イベントの引き継ぎが必要な場合は、再送、複製、保存先からの再投入などを個別に設計します。(Microsoft Learn)

導入時に失敗しやすいポイント

失敗例	問題	対策
GAなら全リージョンで使えると思う	日本リージョンでは作成できない	対応リージョンをデプロイ前に検証する
既存名前空間で有効化しようとする	後付けできない	新規環境と移行計画を用意する
「コード変更不要」を「移行作業不要」と解釈する	接続先、権限、DNSなどの変更が漏れる	アプリ以外の依存関係を棚卸しする
Confidential Computingだけを有効にする	ネットワークや保存時の対策が不足する	CMK、Private Link、RBACと組み合わせる
Managed HSMより先に名前空間を作る	必要なID権限を事前付与できない	ユーザー割り当てマネージドIDを先に作る
最初からAzure PolicyをDenyにする	既存のデプロイが停止する	Auditから段階的に適用する
Event Hubsの下流も保護されたと思う	Consumer側で平文データが露出する	パイプライン全体のデータ境界を確認する
性能への影響がないと決めつける	本番負荷で遅延や容量不足が起きる	実データに近い条件で負荷試験を行う
有効化だけでコンプライアンス対応になると思う	規程、監査、データ所在地が未対応になる	法務・セキュリティ部門と要件を確認する

特に注意したいのは、Confidential Computingはセキュリティ上の技術対策であり、それだけで特定の法令や業界基準への準拠が保証されるわけではない点です。

自社で対応すべきかを判断するチェック表

現在の状況	推奨する対応
Dedicatedを新規構築し、対応リージョンを利用できる	機密データを扱うなら優先的にPoCを実施
対応リージョンの既存Dedicatedを利用している	新規クラスターへの移行費用と効果を比較
StandardまたはPremiumを利用している	Dedicatedの性能・コストを含めて別案件として評価
日本国内のデータ保管が必須	現時点では導入を見送り、リージョン拡大を監視
イベントが公開情報または十分に匿名化済み	導入優先度は低い
個人・医療・金融・重要インフラデータを扱う	データ境界を確認し、導入候補にする
Event Hubsの下流が保護されていない	先にパイプライン全体のセキュリティ設計を実施
Dedicatedの処理規模に達していない	他の暗号化・トークン化・アクセス制御を優先

判断に迷う場合は、次の4項目を順番に確認すると整理できます。

1. 現在の料金プランはDedicatedか
2. 韓国中部またはUAE北部を利用できるか
3. 新しい名前空間へ移行できるか
4. 処理中のイベントに追加保護が必要か

4項目すべてが「はい」なら、Confidential Computingを有効にした新規環境のPoCを進める価値があります。

いずれかが「いいえ」なら、すぐに設定作業を始める必要はありません。特に日本リージョンが必須のシステムでは、対応地域の拡大を確認しながら、プライベートエンドポイント、マネージドID、RBAC、カスタマーマネージドキー、データ最小化を優先してください。

Azure Event Hubs DedicatedのConfidential Computingは、機密性の高いストリーミングデータに対し、保存中・転送中だけでなく使用中まで保護範囲を広げられる機能です。一方で、Dedicated限定、対応リージョン限定、新規作成時のみという制約があります。

まずは現在の料金プラン、リージョン、名前空間、データ分類を確認してください。導入条件を満たす場合は、Bicepによる新規環境の構築、Azure Policy、ユーザー割り当てマネージドID、Managed HSM、プライベートエンドポイントを含む構成で検証を始めるのが、最も安全で現実的な進め方です。