Private EndpointはDNS設計が9割

山崎行政書士事務所
7月8日
読了時間: 21分

名前解決ミスで通信障害・迂回通信・運用混乱が起きる

情シス・経営層のためのネットワーク設計レビュー

確認日：2026年7月8日対象読者：情シス担当者、Azure運用担当者、ネットワーク担当者、クラウド移行担当者、セキュリティ担当者、監査対応担当者、経営層対象領域：Azure Private Endpoint、Azure Private Link、Azure Private DNS Zone、Azure DNS Private Resolver、オンプレDNS、条件付きフォワーダー、ネットワーク設計レビュー

結論

Azure Private Endpointの設計で最も重要なのは、Private Endpointそのものを作ることではなく、FQDNが正しくPrivate EndpointのプライベートIPへ名前解決されることです。

つまり、実務上は「Private EndpointはDNS設計が9割」と考えて設計レビューすべきです。なお、この「9割」は重要性を示す実務上の表現であり、Microsoft公式の定量値ではありません。

理由は、Private EndpointはAzureサービスへプライベートIPで接続する仕組みですが、アプリケーションは通常、接続先をIPアドレスではなくFQDNで指定するためです。Microsoft公式でも、Private Endpointへ接続するDNS設定では、接続文字列のFQDNをPrivate EndpointのIPアドレスへ解決することが重要であり、既存のAzureサービスのパブリックエンドポイント向けDNS構成をPrivate Endpoint向けに上書きする必要があると説明されています。

数字で見ると、Private Endpointのネットワーク設計レビューで最低限確認すべき項目は15項目です。

No.	レビュー項目	確認内容
1	対象FQDN	アプリが接続する正式なFQDN
2	Private Endpoint IP	NICに割り当てられたプライベートIP
3	Private DNS Zone	Microsoft推奨ゾーン名に沿っているか
4	DNS Zone Group	Private EndpointとPrivate DNS Zoneが紐付くか
5	VNet Link	接続元VNetからPrivate DNS Zoneを参照できるか
6	Hub-Spoke DNS	Hub集約か、Spoke個別か
7	オンプレDNS	条件付きフォワーダーが正しいか
8	Azure DNS Private Resolver	Inbound/Outbound Endpoint設計
9	カスタムDNS	Azure提供DNSとの責任分界
10	Public Network Access	Private Endpoint作成後も公開経路が残っていないか
11	ルーティング	UDR、Firewall、NVA経由時の戻り通信
12	NSG/ASG	Private Endpoint subnetのネットワークポリシー
13	監視	Activity Log、メトリック、接続状態変更
14	変更管理	DNS追加・変更・削除の承認手順
15	切戻し	DNS誤設定時の復旧手順

1. Private Endpointとは何か

Microsoft公式では、Private EndpointはVirtual Network内のプライベートIPアドレスを使うネットワークインターフェイスであり、Azure Private Linkで提供されるサービスへプライベートに接続するものと説明されています。また、Private Endpointには読み取り専用のNICが自動作成され、そのNICにはPrivate Linkリソースに対応するプライベートIPが割り当てられます。

図1：Private Endpointの基本

Azure VNet
┌──────────────────────────────────┐
│                                  │
│  App / VM / AKS / Container Apps │
│             │                    │
│             │ FQDNで接続          │
│             ▼                    │
│     Private Endpoint NIC          │
│     10.10.1.5                     │
│             │                    │
└─────────────┼────────────────────┘
              │
              ▼
        Azure PaaS Service
        Storage / SQL / Key Vault 等

ここで重要なのは、アプリケーションが通常、10.10.1.5のようなIPアドレスではなく、xxxxx.blob.core.windows.netやxxxxx.database.windows.netのようなFQDNで接続することです。

そのため、Private Endpointの通信成否は、DNS設計に大きく依存します。

2. DNS設計を間違えると何が起きるか

DNS設計を誤ると、Private Endpointを作成していても、通信は期待どおりになりません。

表1：名前解決ミスによる典型的な事故

事故	原因	影響
Private Endpointに接続できない	FQDNがPrivate IPへ解決されない	アプリ停止、DB接続失敗
Public IPへ解決される	Private DNS Zone未リンク、DNSフォワード不足	迂回通信、セキュリティ設計違反
オンプレだけ接続できない	条件付きフォワーダー不足	拠点・社内端末から接続不可
Spoke VNetだけ失敗	VNet Link漏れ	特定システムだけ障害
別Private Endpointへ解決される	DNS Zone重複、Aレコード競合	誤接続、原因調査長期化
DNSキャッシュで古いIPへ接続	TTL・キャッシュ管理不足	切替後も障害継続
Firewall経由で想定外通信	DNS解決先がPublic IP	監査上の説明不能
運用担当が切り分け不能	DNS経路図・台帳なし	復旧遅延

Microsoft公式のセキュリティ推奨でも、Private DNS Zoneを正しく構成し、Private Endpointアドレスを解決する必要があるすべてのVNetにPrivate DNS Zoneをリンクすること、誤ったDNS構成によりPrivate EndpointではなくPublic Internet経由で通信がルーティングされ得ることが示されています。

3. 正常系：FQDNは変えず、DNSでPrivate IPへ誘導する

Private Endpointの設計では、原則としてアプリケーションの接続URLを大きく変えません。Microsoft公式では、AzureサービスのパブリックDNSにCNAMEが作成され、Private Endpoint利用時はPrivate IPで名前解決を上書きでき、既存アプリケーションの接続URLは変わらないと説明されています。

図2：正常な名前解決

アプリ
  │
  │ 接続先FQDN
  │ mystorage.blob.core.windows.net
  ▼
DNS問い合わせ
  │
  ▼
Private DNS Zone
privatelink.blob.core.windows.net
  │
  ▼
10.10.1.5
  │
  ▼
Private Endpoint
  │
  ▼
Azure Storage

正常な状態

項目	期待値
アプリ接続先	既存のFQDN
DNS応答	Private EndpointのプライベートIP
通信経路	VNet内またはMicrosoftバックボーン
Public Network Access	原則、無効化または制限
監査説明	「このFQDNはPrivate Endpointへ解決される」と説明可能

4. 異常系：Public IPへ解決される

最も危険なのは、Private Endpointを作成したのに、FQDNがPublic IPへ解決される状態です。

図3：DNS設計ミスによる迂回通信

アプリ
  │
  │ mystorage.blob.core.windows.net
  ▼
誤ったDNS
  │
  ▼
Public IPを応答
  │
  ▼
Public Endpointへ通信
  │
  ├─ Public Network Accessが許可 → 通信できてしまう
  └─ Public Network Accessが拒否 → 接続障害

この状態は、通信できても危険です。なぜなら、「Private Endpointを使っているはず」という設計説明と、実際の通信経路が一致しないためです。

5. Private EndpointはPublic Network Accessを自動で止めない

Private Endpointを作成しただけで、対象PaaSのPublic Network Accessが必ず遮断されるわけではありません。

Microsoft公式では、Private EndpointはAzureサービスへプライベートにアクセスできるIPを提供しますが、それ自体がPublic Network Accessを必ず制限するものではなく、追加のアクセス制御が必要であると説明されています。

表2：Private EndpointとPublic Network Accessの違い

項目	役割
Private Endpoint	プライベートIPでPaaSへ到達する入口
Private DNS Zone	FQDNをPrivate Endpoint IPへ解決する仕組み
Public Network Access	PaaSのPublic Endpointを許可するかどうか
Firewall / Network Rules	許可元ネットワークを制御
RBAC / Entra ID	認証・認可を制御

設計レビューでの重要質問

質問	意味
FQDNはPrivate IPへ解決されていますか	DNS設計確認
Public Network Accessは無効ですか	迂回通信防止
Public Endpointを許可する例外はありますか	例外管理
DNS解決できることとアクセス許可を混同していませんか	認証・認可の分離

Microsoft公式のPrivate Endpoint DNS説明でも、DNS解決はPrivate Endpointが存在することやIPを明らかにするものではなく、データプレーンアクセスを許可するものでもないと説明されています。

6. Private DNS Zone設計の基本

Private Endpointでは、サービスごとに推奨されるPrivate DNS Zone名があります。Microsoft公式は、Private EndpointのプライベートIPを接続文字列のFQDNへ解決するため、各サービスに対応するPrivate DNS Zone値を示しています。

表3：Private DNS Zone設計で確認すべきこと

確認項目	レビュー観点
推奨ゾーン名	Microsoft推奨のPrivate DNS Zone名を使っているか
ゾーン重複	同じ名前のPrivate DNS Zoneが複数作られていないか
VNet Link	接続元VNetにリンクされているか
DNS Zone Group	Private Endpoint作成時に自動登録されるか
手動Aレコード	暫定登録が放置されていないか
複数リージョン	どのリージョンのPrivate IPを返すか
DR構成	フェイルオーバー時のDNS切替方法
権限	アプリ担当がDNSレコードを勝手に変更できないか

Microsoft公式は、使用中のPublic Endpoint向けゾーンを安易に上書きすることは推奨されず、サービスごとの推奨名に従うこと、また複数サービスのレコードを同一Private DNS Zoneへ混在させないよう注意を示しています。

7. DNS Zone Groupを標準化する

Private EndpointとPrivate DNS Zoneを運用で確実に紐付けるには、DNS Zone Groupの利用を標準化します。

Microsoft公式では、Private Endpoint DNS統合シナリオの中でDNS Zone Groupが説明され、各DNS Zone Groupは最大5つのDNS Zoneをサポートし、同じDNS Zone名については1つのPrivate DNS Zoneだけを含められるとされています。また、単一Private Endpointに複数DNS Zone Groupを追加することはサポートされません。

図4：DNS Zone Groupの位置付け

Private Endpoint
   │
   ├─ NIC
   │   └─ Private IP
   │
   └─ DNS Zone Group
        │
        └─ Private DNS Zone
             └─ A Record

表4：DNS Zone Groupレビュー

項目	OK条件
Zone Group有無	Private EndpointにDNS Zone Groupがある
対象Zone	推奨Private DNS Zoneに紐付いている
Aレコード	Private Endpoint IPが登録されている
更新	Private Endpoint再作成時に自動更新される
例外	手動登録の場合、理由と期限が台帳化されている

8. Hub-Spoke構成ではDNSを中央集約する

大企業のAzure環境では、Private DNS Zoneを各アプリチームが個別に持つと、すぐに重複・競合・権限問題が発生します。

Microsoft Cloud Adoption Frameworkでは、Hub-Spoke構成において、Private DNS Zoneは通常Hub VNetがある中央のAzureサブスクリプションにホストされ、オンプレミスDNSや中央DNS解決の要件と結び付くと説明されています。また、アプリチームは自分のSpokeサブスクリプションでPaaSを作成できても、中央のPrivate DNS ZoneにDNSレコードを作成する権限を持たない場合があるため、Private LinkとDNS統合の標準化が必要になります。

図5：Hub-Spoke型Private Endpoint DNS

                 On-prem DNS
                     │
        Conditional Forwarder
                     │
                     ▼
┌────────────────────────────────┐
│ Hub VNet                         │
│  Azure DNS Private Resolver      │
│  Private DNS Zones               │
│  privatelink.blob.core.windows.net│
│  privatelink.vaultcore.azure.net │
└───────────────┬────────────────┘
                │ VNet Link / Ruleset
     ┌──────────┴───────────┐
     ▼                      ▼
 Spoke VNet A            Spoke VNet B
 App Team A              App Team B
 Private Endpoint        Private Endpoint

9. オンプレミスからの接続はAzure DNS Private Resolverを前提に整理する

オンプレミス端末・サーバーからPrivate Endpointへ接続する場合、オンプレDNSだけではAzure Private DNS Zoneを直接解決できません。Azure DNS Private Resolverを利用し、オンプレDNSの条件付きフォワーダーからResolverのInbound Endpointへ転送する設計が標準候補になります。

Microsoft公式では、Azure DNS Private ResolverのInbound Endpointはオンプレミスやその他プライベート環境からの名前解決を受け付けるIPであり、オンプレDNSの条件付きフォワーダーにInbound EndpointのIPアドレスを指定すると説明されています。

図6：オンプレミスからPrivate Endpointへ接続するDNS経路

オンプレ端末
  │
  │ mystorage.blob.core.windows.net
  ▼
オンプレDNS
  │
  │ 条件付きフォワード
  │ blob.core.windows.net → Resolver Inbound IP
  ▼
Azure DNS Private Resolver
  │
  ▼
Azure Private DNS Zone
  │
  ▼
Private Endpoint IP
  │
  ▼
Azure Storage

Microsoftのチュートリアルでも、本番環境ではオンプレミスリソースはローカルDNSを使い、Private EndpointのDNSレコードを解決するためにAzure Private Resolverへの条件付きフォワーダーを使うと説明されています。

10. Virtual WANではPrivate DNS Zone Linkの前提が変わる

Virtual WAN環境では、通常のHub-Spokeと同じ感覚でPrivate DNS Zoneを扱うと失敗することがあります。

Microsoft Architecture Centerでは、Virtual WAN hubにはPrivate DNS Zoneをリンクできないため、FirewallをDNS Proxyとして使ってAzure DNSへ転送しても、Private DNS Zoneを認識できずPublic IPが返る例が示されています。そのため、Virtual WAN環境ではHub Extension VNetにAzure DNS Private Resolverを配置する構成が推奨されています。

図7：Virtual WANで起きやすい失敗

Spoke Workload
  │
  ▼
Virtual WAN Hub Firewall DNS Proxy
  │
  ▼
Azure DNS
  │
  └─ Virtual WAN HubにはPrivate DNS Zoneをリンクできない
        │
        ▼
      Public IPを応答

設計レビューでの確認

質問	確認内容
Virtual WANを使っているか	通常Hub-SpokeとDNS前提が違う
DNS Proxyの転送先はどこか	Azure DNSへ直接か、Resolverか
Private DNS Zoneはどこにリンクされているか	Spoke、Hub Extension VNet等
Private IPへ解決されるか	実テストが必要

11. ネットワーク設計レビュー：全体フロー

図8：Private Endpoint設計レビューの流れ

対象PaaS確認
    │
    ▼
接続元確認
Azure / On-prem / Branch / Partner
    │
    ▼
FQDN確認
    │
    ▼
推奨Private DNS Zone確認
    │
    ▼
DNS解決経路確認
VNet Link / Resolver / 条件付きフォワード
    │
    ▼
Public Network Access確認
    │
    ▼
Firewall / UDR / NSG確認
    │
    ▼
接続テスト
    │
    ▼
台帳・手順・監査証跡化

12. ネットワーク設計レビュー表

表5：Private Endpoint設計レビューシート

項目	確認質問	判定
対象サービス	Private Endpoint対応サービスか	OK / NG
Target subresource	Storageならblob/file/dfs等を区別したか	OK / NG
接続元	Azure VM、AKS、App Service、オンプレ、VDI等を洗い出したか	OK / NG
FQDN	アプリが実際に使うFQDNを確認したか	OK / NG
DNS応答	FQDNがPrivate IPへ解決されるか	OK / NG
Private DNS Zone	推奨ゾーン名か	OK / NG
DNS Zone Group	Private EndpointとZoneが紐付くか	OK / NG
VNet Link	すべての接続元VNetが対象か	OK / NG
Resolver	オンプレ・Hub-SpokeでPrivate Resolverが必要か	OK / NG
条件付きフォワード	オンプレDNSから正しい転送先へ向くか	OK / NG
Public Network Access	無効化または制限する方針か	OK / NG
Firewall	迂回通信・非対称ルーティングがないか	OK / NG
NSG/ASG	Private Endpoint subnetの制御方針はあるか	OK / NG
監視	Private Endpointの状態変更をActivity Logで追うか	OK / NG
変更管理	DNS変更に承認手順があるか	OK / NG
切戻し	DNS誤設定時に戻せるか	OK / NG

13. Target subresourceを見落とさない

Private Endpointは、対象サービスの「どのサブリソースへ接続するか」を指定します。Microsoft公式では、Private EndpointのプロパティとしてTarget subresourceがあり、Private Linkリソースの種類ごとに選択肢が異なると説明されています。また、Azure Storageではblobとfileへアクセスするためには、それぞれ対応するPrivate Endpointが必要になる例が示されています。

表6：Storageでの例

利用内容	必要なサブリソース	DNS例
Blob	blob	privatelink.blob.core.windows.net
File	file	privatelink.file.core.windows.net
Queue	queue	privatelink.queue.core.windows.net
Table	table	privatelink.table.core.windows.net
Data Lake Gen2	dfs	privatelink.dfs.core.windows.net

Blob用Private Endpointを作っただけで、FileやDFSまで自動で使えるとは限りません。この確認漏れは、設計レビューでよく見つかるポイントです。

14. DNSが正しくてもアクセスできるとは限らない

DNS解決は通信の入口ですが、すべてではありません。

表7：DNS以外に確認すべき要素

領域	確認内容
Private Endpoint connection	Approved状態か
Public Network Access	無効化・制限方針と整合するか
Service firewall	VNet/Private Endpointからの接続を許可しているか
Identity	Entra ID、Managed Identity、RBAC
TLS	証明書、SNI、TLSバージョン
Route	Firewall/NVA経由時の戻り通信
NSG/UDR	Private Endpoint subnetのネットワークポリシー
Application	接続文字列、SDK、Proxy設定

Microsoft公式では、Private Endpoint接続はApproved状態のものだけが指定リソースへトラフィックを送信できると説明されています。

15. 設計レビューで確認すべきDNS経路

表8：接続元別DNS経路

接続元	DNS経路	レビュー観点
同一VNet VM	Azure提供DNS → Private DNS Zone	Zone Linkがあるか
Peered VNet	Azure提供DNS → Link済みPrivate DNS Zone	接続元VNetにもLinkがあるか
Hub-Spoke	Spoke → Hub Resolver → Private DNS Zone	中央DNS設計とリンク
オンプレ	On-prem DNS → Conditional Forwarder → Private Resolver	Inbound Endpoint到達性
App Service VNet統合	App Service → VNet DNS	アプリ側DNS挙動
AKS	Node/CoreDNS → VNet DNS	CoreDNSカスタム設定
Virtual WAN	Firewall DNS Proxy / Resolver	Virtual WAN hub制約
外部委託先	委託先DNS → 条件付き転送	責任分界、契約、監査証跡

16. DNSテストは複数地点から実施する

Private Endpointの接続テストは、1台のVMだけで終わらせてはいけません。

表9：テストケース

テスト元	コマンド例	期待結果
Hub VM	nslookup <FQDN>	Private IP
Spoke VM	nslookup <FQDN>	Private IP
AKS Pod	nslookup <FQDN>	Private IP
App Service Kudu/Console	名前解決確認	Private IP
オンプレ端末	nslookup <FQDN>	Private IP
DR拠点	nslookup <FQDN>	設計どおり
監視サーバー	接続監視	TCP接続成功
インターネット端末	nslookup <FQDN>	Public解決または接続拒否設計

PowerShell例

Resolve-DnsName mystorage.blob.core.windows.net

Test-NetConnection mystorage.blob.core.windows.net -Port 443

Linux例

dig mystorage.blob.core.windows.net

curl -v https://mystorage.blob.core.windows.net/

17. Private Endpoint台帳を作る

Private Endpointは増えます。台帳がないと、DNS、Firewall、アクセス制御、監査が追えなくなります。

表10：Private Endpoint台帳

項目	記入例
管理番号	PE-2026-001
対象サービス	Azure Storage
対象リソース	stprodlog001
Target subresource	blob
Private Endpoint名	pe-stprodlog001-blob
VNet/Subnet	vnet-prod-hub / snet-private-endpoint
Private IP	10.10.1.5
FQDN	stprodlog001.blob.core.windows.net
Private DNS Zone	privatelink.blob.core.windows.net
DNS Zone Group	あり
VNet Link	hub, spoke-app01, spoke-batch01
オンプレ接続	あり
条件付きフォワード	blob.core.windows.net → Resolver Inbound IP
Public Network Access	Disabled
所有者	情シス基盤チーム
業務責任者	ログ基盤責任者
監視	Activity Log、Bytes In/Out
作成日	2026-07-08
見直し日	2026-10-01

18. DNS変更管理台帳を作る

DNSは「1レコードの変更」で本番障害を起こせます。そのため、DNS変更はネットワーク変更として扱うべきです。

表11：DNS変更管理台帳

項目	記入例
変更番号	DNS-CHG-2026-010
変更種別	Private DNS Zone Link追加
対象FQDN	stprodlog001.blob.core.windows.net
対象Zone	privatelink.blob.core.windows.net
変更理由	新規Spoke VNetからStorageへPrivate接続
変更前	spoke-app02にZone Linkなし
変更後	spoke-app02をZone Link追加
影響範囲	App02システム
検証方法	VM/AKS/Appからnslookup、curl
切戻し方法	Zone Link削除
承認者	ネットワーク責任者、システムオーナー
実施者	Azure基盤担当
証跡	PR、Activity Log、テスト結果

19. よくあるレビュー指摘

表12：ネットワーク設計レビューで多い指摘

指摘	内容	修正方針
Private DNS ZoneがSpokeごとに重複	同じゾーン名が複数存在	Hubに集約、例外のみ個別
VNet Link漏れ	特定VNetだけPublic IP解決	接続元VNet一覧からLink確認
DNS Zone Groupなし	Aレコードが手動管理	DNS Zone Groupを標準化
Public Network Accessが残存	Private化したつもりでもPublic経路あり	検証後に無効化
オンプレDNS未対応	社内端末から接続不可	Conditional Forwarder追加
Resolver未設計	DNS Forwarder VMが属人運用	Azure DNS Private Resolverへ整理
Virtual WAN hubにZone Linkしようとしている	構成上使えない	Hub Extension VNet＋Resolver
TTL/キャッシュ考慮なし	切替後も古い名前解決	TTL・キャッシュクリア手順
監査証跡なし	誰がDNSを変えたか不明	IaC、PR、Activity Logを保全

20. 監視と証跡

Private Endpointの設計レビューでは、作成時だけでなく運用監視も確認します。

Microsoft公式では、Azure Monitorにより可用性、パフォーマンス、回復性を監視し、Private Linkについてメトリック、リソースログ、Activity Logを収集・分析できると説明されています。

また、Microsoft公式のセキュリティ推奨では、Private Endpoint接続の作成・承認・拒否・削除をActivity Logで追跡し、状態変更にアラートを設定することが推奨されています。

表13：監視すべき項目

監視対象	目的
Private Endpoint connection state	Pending、Approved、Rejected、Disconnectedの検知
Activity Log	作成・承認・削除・変更の監査
Bytes In / Bytes Out	想定外通信量の検知
DNS Query Logs	Private IPへ解決されているか
Firewall Logs	Public Endpointへの迂回通信がないか
Azure Policy	Private Endpoint未設定、Public Access残存の検出
Resource Graph	Private EndpointとDNS Zone Linkの棚卸し

21. Azure Policyで統制する

Private Endpointは、手作業だけでは統制できません。管理グループ・サブスクリプション単位でAzure Policyを使い、Private EndpointやPublic Network Accessを監査・制御します。

Microsoft公式のPrivate Linkセキュリティ推奨では、Azure Policyにより対応サービスでPrivate Endpointを監査または展開すること、Private Endpointだけでなく対象PaaSのPublic Network AccessをブロックするPolicyを併用することが推奨されています。

表14：Policy例

Policy観点	目的
StorageはPrivate Linkを使用	Public経路の抑止
Cosmos DBはPrivate Endpoint必須	データ基盤保護
Key Vault Public Network Access禁止	秘密情報保護
Private Endpointにタグ必須	台帳・所有者管理
Public Network AccessをDeny/Modify	Private化の抜け漏れ防止
DNS Zone Link監査	名前解決漏れ検出

22. RACI：誰が責任を持つのか

Private Endpointは、アプリ担当だけでも、ネットワーク担当だけでも完結しません。

表15：Private Endpoint / DNS運用RACI

作業	アプリ担当	Azure基盤	ネットワーク	DNS担当	セキュリティ	監査/規程	経営層
Private Endpoint要件定義	R	C	C	C	C	I	I
FQDN確認	R	C	C	R	I	I	I
Private DNS Zone設計	C	R	C	R	C	I	I
DNS Zone Group設定	C	R	C	C	I	I	I
VNet Link設定	I	R	R	C	I	I	I
オンプレ条件付きフォワード	I	C	C	R	C	I	I
Public Access無効化	C	R	C	I	A	I	I
Firewall/UDR確認	C	C	R	I	C	I	I
接続テスト	R	R	C	C	C	I	I
変更承認	C	C	C	C	A	R	I
重大障害報告	I	C	C	C	R	C	A

R：実行責任、A：説明責任、C：相談先、I：共有先

23. 運用手順：新しいPrivate Endpointを追加する場合

図9：追加手順

Private Endpoint申請
      │
      ▼
対象PaaS・Target subresource確認
      │
      ▼
接続元一覧確認
Azure / On-prem / 拠点 / 委託先
      │
      ▼
推奨Private DNS Zone確認
      │
      ▼
既存Zone確認
      │
      ├─ 既存あり → 既存Zoneを利用
      └─ 既存なし → 中央Zone作成
      │
      ▼
DNS Zone Group作成
      │
      ▼
VNet Link / Resolver / 条件付きフォワード確認
      │
      ▼
Public Network Access方針確認
      │
      ▼
接続テスト
      │
      ▼
台帳更新・監査証跡保存

表16：作業チェックリスト

No.	チェック項目	OK/NG
1	Private Endpoint対象サービスを確認した
2	Target subresourceを確認した
3	接続元をすべて洗い出した
4	FQDNを確認した
5	推奨Private DNS Zoneを確認した
6	既存Private DNS Zoneの重複を確認した
7	DNS Zone Groupを作成した
8	接続元VNetのZone Linkを確認した
9	オンプレ条件付きフォワーダーを確認した
10	Public Network Access方針を確認した
11	Firewall/UDR/NSG影響を確認した
12	nslookupでPrivate IPを確認した
13	アプリ接続テストを実施した
14	台帳を更新した
15	変更証跡を保存した

24. 運用手順：障害発生時の切り分け

図10：名前解決障害の切り分け

アプリ接続失敗
      │
      ▼
FQDNの名前解決確認
      │
      ├─ Private IP
      │      ├─ 接続状態確認
      │      ├─ PaaS Firewall確認
      │      ├─ RBAC/認証確認
      │      └─ Route/NSG確認
      │
      ├─ Public IP
      │      ├─ Private DNS Zone Link確認
      │      ├─ DNS Zone Group確認
      │      ├─ Resolver/Forwarder確認
      │      └─ DNSキャッシュ確認
      │
      └─ NXDOMAIN
             ├─ Aレコード確認
             ├─ Zone名確認
             ├─ 重複Zone確認
             └─ 条件付きフォワード確認

表17：障害パターン別の確認箇所

症状	確認箇所
Public IPへ解決	Private DNS Zone Link、Resolver、条件付きフォワーダー
NXDOMAIN	Zone名、Aレコード、DNS Zone Group
Spokeだけ失敗	Spoke VNet Link、カスタムDNS
オンプレだけ失敗	On-prem DNS、Inbound Endpoint、ExpressRoute/VPN
接続先はPrivate IPだが失敗	Private Endpoint connection state、Firewall、RBAC
切替後だけ失敗	DNSキャッシュ、TTL、古いAレコード
Firewall経由で想定外	UDR、DNS Proxy、SNAT、ルート対称性
DR時に失敗	複数リージョンDNS設計、フェイルオーバー手順

25. ネットワーク設計レビューで作るべき成果物

表18：レビュー成果物

成果物	内容
Private Endpoint一覧	対象サービス、IP、FQDN、Owner
Private DNS Zone一覧	Zone名、所有者、VNet Link
DNS経路図	Azure内、オンプレ、Hub-Spoke、Virtual WAN
条件付きフォワーダー台帳	転送元、対象ドメイン、転送先
VNet Linkマトリクス	どのVNetがどのZoneを参照するか
Public Access管理表	PaaSごとのPublic Network Access状態
接続テスト記録	nslookup、curl、アプリ接続
障害切り分け手順	DNS、Route、Firewall、RBAC
例外管理台帳	手動Aレコード、Public許可、暫定DNS
変更管理規程	承認、実施、切戻し、記録

26. ネットワーク設計レビュー規程サンプル

第○条（Private EndpointおよびDNS設計レビュー）

1. Azure Private Endpointを新規作成または変更する場合は、
   対象サービス、Target subresource、接続元、FQDN、Private DNS Zone、
   VNet Link、オンプレDNS条件付きフォワーダーの有無を事前に確認する。

2. Private Endpointに関するDNS設定は、Microsoftが示す推奨Private DNS Zone名を
   原則として使用し、同一名前空間のPrivate DNS Zoneを重複作成してはならない。

3. Private Endpoint作成時は、原則としてDNS Zone Groupを利用し、
   手動Aレコード登録を行う場合は、理由、期限、承認者、代替策を記録する。

4. オンプレミス環境からPrivate Endpointへ接続する場合は、
   Azure DNS Private Resolverまたは承認されたDNS転送方式を用い、
   条件付きフォワーダー設定をDNS台帳に記録する。

5. Private Endpointを利用するPaaSリソースについては、
   Public Network Accessの要否を確認し、不要な公開経路は無効化または制限する。

6. DNS変更、VNet Link変更、Private Endpoint接続承認、Public Network Access変更は、
   変更管理手続に基づき、影響範囲、検証方法、切戻し方法、承認者を記録する。

7. 本番反映後は、接続元ごとに名前解決結果と通信結果を確認し、
   証跡として保存する。

27. DNSはセキュリティ基盤である

DNSは単なる名前解決の仕組みではありません。NIST SP 800-81 Rev.3は、DNSを企業ネットワークアーキテクチャの不可欠な要素と位置付け、DNSインフラへの攻撃は企業ネットワーク運用全体を脅かし得ると説明しています。また、DNSをゼロトラストや多層防御の一部として安全に展開するためのガイドラインを提供しています。

Private EndpointのDNS設計も同じです。名前解決が間違えば、セキュリティ設計、可用性、監査説明が崩れます。

28. 経営層向け説明

図11：経営層に伝えるべき構造

Private Endpointを作る
      │
      ▼
FQDNをPrivate IPへ解決する
      │
      ▼
通信をPrivate Link経由にする
      │
      ▼
Public経路を閉じる
      │
      ▼
監査で説明できる

表19：経営層へ説明するポイント

論点	説明
Private Endpointだけでは不十分	DNSがPrivate IPを返さなければPrivate接続にならない
DNSミスは障害になる	DB、Storage、Key Vault、監視基盤に影響する
DNSミスは迂回通信になる	Public IPへ解決されると設計と実通信がずれる
Public Access管理が必要	Private Endpoint作成後もPublic経路が残る可能性
証跡が必要	誰がDNSを変えたか、いつPrivate化したかを説明する
標準化が必要	Private Endpointが増えるほど属人運用は破綻する

29. 山崎行政書士事務所としての支援領域

Private EndpointのDNS設計は、Azure技術だけではなく、企業のクラウドガバナンスそのものです。

山崎行政書士事務所では、Azure技術支援とクラウド法務・ガバナンス支援を一体で行います。

表20：支援できる内容

領域	支援内容
Azure技術支援	Private Endpoint、Private DNS Zone、DNS Zone Group設計
ネットワーク設計レビュー	Hub-Spoke、Virtual WAN、Firewall、UDR、NSG確認
ハイブリッドDNS	Azure DNS Private Resolver、オンプレDNS、条件付きフォワーダー整理
セキュリティ	Public Network Access、Private Link、ゼロトラスト観点
監査対応	Private Endpoint台帳、DNS変更台帳、Activity Log整理
規程整備	DNS運用規程、ネットワーク変更管理規程、例外管理
運用設計	接続テスト、切戻し手順、障害切り分けRunbook
経営説明	迂回通信リスク、通信障害リスク、責任分界資料
契約・委託管理	DNS運用委託、クラウド運用責任分界、報告様式整理

行政書士業務の範囲を踏まえ、個別紛争対応や訴訟代理など弁護士領域に属する事項は切り分けたうえで、企業がクラウドを安全に利用するための規程整備、契約関連資料、監査説明資料、運用ルール整備を支援します。

まとめ

Private Endpointは、作成して終わりではありません。

本当に重要なのは、FQDNが正しくPrivate EndpointのプライベートIPへ解決され、Public経路を迂回せず、障害時に切り分けでき、監査で説明できることです。

Private Endpoint設計で見るべきポイントは、次の5つです。

観点	重要ポイント
DNS	FQDNがPrivate IPへ解決されるか
接続元	Azure、オンプレ、拠点、委託先をすべて確認したか
Public経路	Public Network Accessが残っていないか
運用	DNS変更・障害切り分け・切戻し手順があるか
監査	台帳、承認、Activity Log、テスト結果が残るか

Private EndpointはDNS設計が9割。名前解決を制する企業が、クラウドネットワークを制します。

Azure Private Endpoint、Private DNS Zone、Azure DNS Private Resolver、ネットワーク設計レビュー、DNS運用規程、監査対応資料の整備は、山崎行政書士事務所へご相談ください。

出典・確認日

確認日：2026年7月8日

出典	確認した主な内容	最終更新・公開日
Microsoft Learn：What is a private endpoint?	Private Endpointの定義、NIC、Private IP、承認状態、DNS設定、Public Accessとの関係	2026年3月30日
Microsoft Learn：Azure Private Endpoint private DNS zone values	FQDNをPrivate Endpoint IPへ解決する重要性、推奨Private DNS Zone、注意事項	2026年5月5日
Microsoft Learn：Azure Private Endpoint DNS Integration Scenarios	DNS統合シナリオ、DNS Zone Group、VNet・オンプレ・Resolver構成	2025年9月30日
Microsoft Learn：Private Link and DNS Integration at Scale	Hub-Spokeでの中央Private DNS Zone、アプリチームと中央DNS権限分離	2025年1月14日
Microsoft Learn：Secure your Azure Private Link deployment	DNS漏えい防止、Public Internet迂回リスク、Policy、Activity Log監視	2026年6月5日
Microsoft Learn：Azure DNS Private Resolver Overview	Inbound Endpoint、オンプレ条件付きフォワーダー、Private DNS Zone解決	2026年6月22日
Microsoft Learn：Private Endpoint DNS infrastructure with Azure Private Resolver	オンプレからPrivate Endpoint DNSを解決するチュートリアル、条件付きフォワーダー	2026年2月24日
Microsoft Learn：Guide to Private Link and DNS in Azure Virtual WAN	Virtual WAN hubとPrivate DNS Zoneの制約、Private Resolver設計	2026年確認
Microsoft Learn：Monitor Azure Private Link	Azure Monitor、メトリック、ログ、Activity Log、アラート	2026年3月30日
NIST SP 800-81 Rev.3	DNSは企業ネットワークアーキテクチャの不可欠な要素、DNSセキュリティとゼロトラスト	2026年3月公開