Azure VPN Gateway の Point-to-Site（P2S）VPN を Microsoft Entra ID 認証で使っている管理者がまず確認すべきことは、Azure VPN Client の Audience 値と、ゲートウェイ側の Microsoft-registered App ID 設定が一致しているかです。特に、従来の手動登録アプリを使っている環境では、Microsoft 登録済み Azure VPN Client App ID への移行計画が必要です。手動登録 Azure VPN Client は、Azure Public Cloud では 2028年3月31日、Azure Government と 21Vianet では 2029年3月31日に廃止予定とされています。期限後は手動登録クライアントが機能しなくなるため、早めにゲートウェイ設定とクライアント配布方法を見直す必要があります。(Microsoft Learn)
この記事では、Azure の公式情報をもとに、Windows 向け Azure VPN Client で Microsoft Entra ID 認証を構成する際の更新ポイント、影響範囲、設定変更、移行期限、管理者が確認すべき実務上の注意点を整理します。なお、参照した Microsoft Learn の当該 Windows クライアント設定ページでは、ページ上の最終更新日は 2025年9月10日と表示されています。関連する移行ページやバージョン情報ページは 2026年に更新されており、本記事ではそれらの周辺情報も含めて、2026年7月時点で確認すべき内容として解説します。(Microsoft Learn)
Azure VPN Client の Microsoft Entra ID 認証設定で何が重要なのか
今回のポイントは、Azure VPN Client の単なるインストール手順ではありません。重要なのは、P2S VPN の認証方式として Microsoft Entra ID を使う場合に、ゲートウェイ、Audience 値、クライアントプロファイル、配布済みクライアント設定の整合性を保つことです。
Microsoft の公式ドキュメントでは、Windows コンピューター上の Azure VPN Client を使い、Azure VPN Gateway の P2S VPN に Microsoft Entra ID 認証で接続するための流れが説明されています。対象となる Windows は Windows 10 と Windows 11 で、X64、X86、ARM64 アーキテクチャがサポート対象です。(Microsoft Learn)
管理者目線では、次の3点が特に重要です。
| 確認項目 | 見るべきポイント | 放置した場合のリスク |
|---|---|---|
| App ID / Audience | Microsoft-registered App ID の Audience 値を使っているか | 旧方式のまま期限を迎えると接続不可になる可能性 |
| クライアントプロファイル | azurevpnconfig.xml または azurevpnconfig_aad.xml の値が最新か | ユーザーごとに接続可否がばらつく |
| 配布方法 | 手動更新、再インポート、Intune などの配布方針 | 移行時に問い合わせや接続障害が集中する |
特にグローバル企業では、Azure Public、Azure Government、21Vianet などクラウド環境ごとに期限や運用ルールが異なる場合があります。単に「Windows クライアントを更新する」だけでなく、利用している Azure クラウド、テナント、VPN Gateway、配布済みプロファイルの棚卸しから始めるべきです。
Microsoft-registered App ID とは
Microsoft-registered App ID は、Microsoft が登録済みの Azure VPN Client アプリケーション ID を利用する方式です。従来は、Microsoft Entra テナント側で Azure VPN Client 用のアプリを手動登録し、管理者同意や権限設定を行う必要がありました。Microsoft-registered App ID を使うと、この手動登録プロセスを省略できる構成になります。(Microsoft Learn)
公式情報では、Microsoft-registered Azure VPN Client App ID の Audience 値として、次の値が示されています。
c632b3df-fb67-4d84-bdcf-b95ad541b5c8この値は、Azure Public、Azure Government、Azure Germany、Microsoft Azure operated by 21Vianet に対して利用できる Audience 値として案内されています。(Microsoft Learn)
従来の手動登録 App ID との違い
手動登録 App ID と Microsoft-registered App ID の違いは、管理作業と将来性にあります。
| 項目 | 手動登録 App ID | Microsoft-registered App ID |
|---|---|---|
| アプリ登録 | テナント側で手動登録が必要 | Microsoft 登録済みアプリを利用 |
| 管理者同意 | 必要になる場合がある | 追加の手動登録プロセスを省略しやすい |
| 今後の扱い | 廃止予定あり | 今後の推奨構成 |
| 主な対応 | 既存環境の移行が必要 | 新規構成・移行先として利用 |
新規に Azure VPN Gateway の P2S VPN を Microsoft Entra ID 認証で構成するなら、原則として Microsoft-registered App ID を前提に設計するのが現実的です。既存環境では、現在の Audience 値を確認し、手動登録 App ID を使っていれば移行対象として扱います。
影響範囲：誰が対応すべきか
この更新ポイントの影響を受けやすいのは、次のような環境です。
| 対象環境 | 対応優先度 | 理由 |
|---|---|---|
| Azure VPN Gateway の P2S VPN で Microsoft Entra ID 認証を使っている | 高 | App ID と Audience 値の確認が必要 |
| 過去に Azure VPN Client アプリを Entra ID に手動登録した | 高 | 廃止対象に該当する可能性がある |
| Windows 端末に Azure VPN Client プロファイルを大量配布している | 高 | クライアント側設定更新の計画が必要 |
| カスタム Audience を使っている | 中〜高 | XML の applicationid 追記が必要になる場合がある |
| 証明書認証のみで P2S VPN を使っている | 低 | 今回の中心は Microsoft Entra ID 認証 |
注意したいのは、「Azure VPN Client を使っている」だけでは影響範囲を判断できない点です。見るべきなのは、P2S VPN の認証方式が Microsoft Entra ID かどうか、そして Audience 値がどの App ID に紐づいているかです。
移行期限：手動登録 Azure VPN Client はいつまで使えるのか
Microsoft の移行ドキュメントでは、手動登録 Azure VPN Client の廃止期限が次のように示されています。(Microsoft Learn)
| クラウド環境 | 手動登録 Azure VPN Client の廃止期限 |
|---|---|
| Azure Public Cloud | 2028年3月31日 |
| Azure Government | 2029年3月31日 |
| Microsoft Azure operated by 21Vianet | 2029年3月31日 |
期限後は、手動登録クライアントは機能しなくなり、Microsoft-registered VPN Client のみがサポートされるとされています。移行は期限直前ではなく、少なくとも次の順序で段階的に進めるべきです。
| フェーズ | 実施内容 | 目安 |
|---|---|---|
| 棚卸し | VPN Gateway、Audience 値、配布済みプロファイルを確認 | すぐ実施 |
| 検証 | 検証用端末で Microsoft-registered App ID の接続を確認 | 本番前 |
| 展開 | 新しいクライアントプロファイルを段階配布 | 部門単位・地域単位 |
| 旧設定整理 | 旧 App ID や古いプロファイルを削除・無効化 | 安定稼働後 |
特に、海外拠点や外部委託先を含む環境では、クライアント端末が管理外に近い状態になっていることがあります。移行期限だけを見て後回しにすると、最後に「誰の端末に古いプロファイルが残っているのか分からない」という問題が起こりやすくなります。
Windows 向け Azure VPN Client の設定手順
公式ドキュメントの Windows 向け手順は、大きく次の流れです。(Microsoft Learn)
| 手順 | 作業内容 | 管理者が確認すること |
|---|---|---|
| 1 | Azure VPN Client をインストール | 最新バージョンか、Windows 10/11 対象端末か |
| 2 | VPN client profile configuration package を取得 | 対象 VPN Gateway から生成されたものか |
| 3 | ZIP を展開 | AzureVPN フォルダーがあるか |
| 4 | XML を確認・必要に応じて編集 | audience、tenant、issuer、applicationid |
| 5 | Azure VPN Client にプロファイルをインポート | Audience がゲートウェイ側と一致するか |
| 6 | 接続テスト | 認証ポップアップ、接続状態、ルーティングを確認 |
Azure VPN Client の入手方法
Windows 向け Azure VPN Client は、インストールファイル、Microsoft Store、Windows Package Manager（WinGet）などの方法で導入できます。公式ドキュメントでは、WinGet を使う場合のコマンドも示されています。(Microsoft Learn)
winget install Microsoft.AzureVPNClient --source winget企業管理端末では、ユーザーに個別インストールさせるより、Intune、ソフトウェア配布基盤、端末キッティング手順に組み込む方が安全です。バージョン差による挙動の違いを避けるため、配布前に標準バージョンを決めておきましょう。
プロファイル構成ファイルを取得する
Azure VPN Client のプロファイル設定には、Azure P2S Gateway からダウンロードする VPN client profile configuration package を使います。ZIP を展開すると、AzureVPN フォルダー内に azurevpnconfig.xml または azurevpnconfig_aad.xml が含まれます。Microsoft Entra ID 認証が含まれない、または OpenVPN トンネルタイプになっていない場合、想定する XML が見つからないことがあります。(Microsoft Learn)
ここで失敗しやすいのは、過去にダウンロードした古い ZIP を再利用してしまうことです。ゲートウェイ側の Audience 値を変更した後は、原則として新しい構成パッケージを生成し直してください。
カスタム Audience を使う場合の注意点
カスタム Audience を使っている環境では、通常の Microsoft-registered App ID 構成より確認項目が増えます。公式ドキュメントでは、P2S 構成が Microsoft-registered App ID に関連付けられたカスタム Audience を使っている場合、VPN クライアントプロファイルに custom audience ID と Microsoft application ID の両方が必要と説明されています。これが不足すると、接続時に資格情報入力や認証を繰り返し求められることがあります。(Microsoft Learn)
XML の aad セクションでは、次のように applicationid を追加します。
<aad>
<audience>{customAudienceID}</audience>
<issuer>https://sts.windows.net/{tenant ID value}/</issuer>
<tenant>https://login.microsoftonline.com/{tenant ID value}/</tenant>
<applicationid>c632b3df-fb67-4d84-bdcf-b95ad541b5c8</applicationid>
</aad>この設定が必要かどうかは、すべての環境で同じではありません。判断基準は次のとおりです。
| 状況 | applicationid 追記の必要性 |
|---|---|
| Microsoft-registered App ID の標準 Audience 値をそのまま使う | 通常は不要 |
| カスタム Audience を使い、Microsoft-registered App ID と関連付けている | 必要になる場合がある |
| 従来の手動登録 App ID を使っている | 移行計画を優先 |
| 接続時に毎回認証ポップアップが出る | XML の applicationid と Audience 整合性を確認 |
カスタム Audience は、ユーザーやグループ単位で VPN 接続先を制御したい場合に有効です。ただし、管理すべき App ID、スコープ、権限、プロファイルが増えるため、小規模環境で安易に採用すると運用が複雑になります。
ゲートウェイ側の設定変更で見るべき値
Windows クライアント側だけを更新しても、ゲートウェイ側の設定と一致していなければ接続できません。Microsoft Entra ID 認証を使う P2S VPN Gateway では、主に次の値を確認します。(Microsoft Learn)
| 設定項目 | 代表的な値・確認内容 | 注意点 |
|---|---|---|
| Tunnel type | OpenVPN（SSL） | Microsoft Entra ID 認証では OpenVPN が前提 |
| Authentication type | Microsoft Entra ID | 旧表記で Azure Active Directory と表示される場合あり |
| Tenant | https://login.microsoftonline.com/{TenantID} | 環境により URL が異なる |
| Audience | c632b3df-fb67-4d84-bdcf-b95ad541b5c8 | クライアント側と一致させる |
| Issuer | https://sts.windows.net/{TenantID}/ | 末尾のスラッシュ漏れに注意 |
公式ドキュメントでは、Issuer 値の末尾にスラッシュが必要で、欠けていると接続に失敗する可能性があるとされています。細かい点ですが、移行時のトラブルとして非常に起こりやすい箇所です。(Microsoft Learn)
Azure Active Directory 表記が残っている場合
Microsoft は Azure Active Directory から Microsoft Entra ID への表記変更を進めています。ただし、Azure Portal や Azure VPN Client の画面では、環境やバージョンによって旧表記が残る場合があります。公式ドキュメントでも、Microsoft Entra ID の値が画面にまだ反映されていない場合は、対応する Azure Active Directory の値を選ぶよう案内されています。(Microsoft Learn)
実務では、画面上のラベル名だけで判断せず、設定値そのものを確認してください。
既存環境を Microsoft-registered App ID に移行する流れ
既存の P2S VPN Gateway が手動登録 App ID の Audience 値を使っている場合、移行は次の流れで進めます。公式の移行ドキュメントでは、Audience 値を更新する場合、P2S VPN Gateway と既存の VPN クライアントの両方を更新する必要があると説明されています。(Microsoft Learn)
| ステップ | 作業 | 実務上の注意 |
|---|---|---|
| 1 | 現在の Audience 値を確認 | 手動登録 App ID か Microsoft-registered かを判定 |
| 2 | 検証用 Gateway または検証時間帯でテスト | 認証、DNS、ルート、業務アプリ接続を確認 |
| 3 | Gateway の Audience 値を変更 | 変更時に短時間の停止を見込む |
| 4 | 新しい VPN client profile configuration package を生成 | 古い XML を使い回さない |
| 5 | Windows 端末にプロファイルを再配布 | 手動インポートだけに頼らない |
| 6 | 旧 App ID や旧プロファイルを整理 | ロールバック期間後に削除・無効化 |
公式移行ページでは、既存ゲートウェイの Audience 値変更時に 5 分未満のダウンタイムが発生すると説明されています。重要システムへのアクセスに使っている場合は、利用者の少ない時間帯に作業し、事前に代替アクセス手段を用意しておくべきです。(Microsoft Learn)
Azure VPN Client のバージョン確認も必須
Azure VPN Client はバージョンによって利用できる機能や挙動が変わります。公式のバージョン情報では、Windows 向け Azure VPN Client 3.3.1.0 で Microsoft-registered App ID Audience のサポートが追加され、4.0.0.0 では前提条件チェック、システムトレイ対応、コンパクト表示、Entra ID 認証の rekey などが追加されています。さらに 4.0.5.0 では Device SSO authentication が有効化されています。(Microsoft Learn)
管理者は、少なくとも次の観点で標準バージョンを確認しましょう。
| バージョン観点 | 確認内容 |
|---|---|
| Microsoft-registered App ID 対応 | 古すぎるクライアントを使っていないか |
| 前提条件チェック | 4.0.0.0 以降の診断機能を使えるか |
| Device SSO | 4.0.5.0 以降の機能を利用する設計か |
| 不具合修正 | 切断、ポート、通知、UI エラーなどの修正が含まれるか |
現場では「接続できるから更新しない」という判断になりがちです。しかし、認証方式や App ID の移行が絡む場合、古いクライアントが一部端末に残っているだけで、問い合わせが散発的に発生します。移行前にバージョン分布を把握し、更新対象を明確にしてください。
Device SSO を使う場合の確認点
Device SSO は、ユーザーが Windows デバイスにサインインした認証状態を Azure VPN Client の接続に活用しやすくする機能です。公式ドキュメントでは、Windows 向け Azure VPN Client プロファイルの aad セクションに enabledevicesso を設定する例が示されています。(Microsoft Learn)
<aad>
<audience>{customAudienceID}</audience>
<issuer>https://sts.windows.net/{tenant ID value}/</issuer>
<tenant>https://login.microsoftonline.com/{tenant ID value}/</tenant>
<applicationid>c632b3df-fb67-4d84-bdcf-b95ad541b5c8</applicationid>
<enabledevicesso>true</enabledevicesso>
</aad>ただし、Device SSO は「設定すれば必ず全ユーザーの認証が完全に省略される」というものではありません。条件付きアクセス、多要素認証、端末登録状態、サインイン頻度、セッション制御など、Entra ID 側のポリシーに影響されます。
導入前に、次の観点で検証してください。
| 確認項目 | 具体例 |
|---|---|
| 対象端末 | Entra 参加済み、Hybrid Entra 参加済み、BYOD の違い |
| 条件付きアクセス | VPN 接続時に MFA を要求するか |
| ユーザー体験 | 初回接続、再接続、ロック解除後の挙動 |
| 障害対応 | SSO 失敗時に通常認証へ戻れるか |
Device SSO は便利ですが、セキュリティ要件を弱めるための機能ではありません。むしろ、端末準拠性や条件付きアクセスと組み合わせて、ユーザー体験と統制を両立させる設計が必要です。
DNS・ルーティング設定で失敗しやすいポイント
Azure VPN Client では、必要に応じて DNS サフィックス、カスタム DNS サーバー、カスタムルート、強制トンネリングなどを構成できます。公式ドキュメントでは、これらは Azure VPN Client プロファイル XML を編集して設定する方法が説明されています。(Microsoft Learn)
特に注意すべきなのは、強制トンネリングです。公式ドキュメントでは、VPN Gateway 経由ではインターネット接続が提供されないため、すべてのトラフィックを VPN トンネルに向ける構成では、インターネット宛てトラフィックがドロップされると説明されています。(Microsoft Learn)
| 設定 | よくある失敗 | 対策 |
|---|---|---|
| DNS サーバー | 名前解決できず業務アプリに接続できない | NRPT と DNS 設定を確認 |
| DNS サフィックス | FQDN では接続できるが短縮名で失敗 | 必要なサフィックスを XML に追加 |
| Split tunneling | 想定外の経路で通信する | 業務アプリ単位で通信経路を確認 |
| Forced tunneling | インターネット通信が途切れる | ルート設計と出口構成を事前検証 |
| Exclude routes | 除外したつもりの通信が VPN 側に流れる | 宛先ごとに route タグを分ける |
VPN の認証移行時には、認証だけを見て接続確認を終えがちです。しかし、ユーザーにとって重要なのは「接続できた」ではなく「業務システムが正しく使える」ことです。認証、DNS、ルート、業務アプリ接続までを一連の検証項目にしてください。
管理者が移行前に確認すべきチェックリスト
移行作業に入る前に、次のチェックリストを使うと抜け漏れを減らせます。
| チェック項目 | 確認内容 |
|---|---|
| 認証方式 | P2S VPN が Microsoft Entra ID 認証か |
| Gateway SKU | Basic SKU や policy-based VPN など非対応構成でないか |
| Tunnel type | OpenVPN（SSL）になっているか |
| Audience 値 | Microsoft-registered App ID の値か、手動登録値か |
| Tenant / Issuer | テナント ID と URL 形式が正しいか |
| Issuer 末尾 | 末尾の / が入っているか |
| クライアント XML | audience、applicationid、tenant が正しいか |
| クライアントバージョン | Microsoft-registered App ID 対応版か |
| 配布済みプロファイル | 古い XML が残っていないか |
| 接続テスト | 認証、DNS、ルート、業務アプリまで確認したか |
| ロールバック | 失敗時に戻す手順と連絡体制があるか |
このチェックリストで重要なのは、Azure 側と Windows 端末側を別々に見ないことです。P2S VPN は、Gateway、Entra ID、Azure VPN Client、XML プロファイル、Windows ネットワーク設定が連動します。どれか1つだけ更新しても、全体として正しく動くとは限りません。
実務でおすすめの移行方針
既存環境を安全に移行するなら、いきなり全社展開するのではなく、段階的に進めるべきです。
小規模環境の場合
ユーザー数が少ない場合は、メンテナンス時間を決めて Gateway の Audience 値を更新し、新しい VPN client profile configuration package を配布する方法が現実的です。各ユーザーには、古いプロファイルを削除してから新しいプロファイルをインポートしてもらうと、誤接続を減らせます。
ただし、手順書だけを配って終わりにするのは避けましょう。ユーザー側で古いプロファイルを残したままにすると、「どちらを使えばよいか分からない」という問い合わせが起こります。
中〜大規模環境の場合
中〜大規模環境では、次のような段階移行が向いています。
| 段階 | 対象 | 目的 |
|---|---|---|
| パイロット | 情シス・一部ユーザー | 接続、DNS、ルート、MFA の確認 |
| 第1展開 | IT リテラシーの高い部門 | 手順と問い合わせ対応の改善 |
| 第2展開 | 主要部門 | 業務影響の確認 |
| 全社展開 | 残りのユーザー | 旧設定の回収・削除 |
| 監査 | 全端末・全プロファイル | 古い Audience 値の残存確認 |
Intune などで端末管理している場合は、Azure VPN Client の導入、プロファイル配布、古いプロファイルの削除をできるだけ自動化すると安定します。手動作業を完全にゼロにできなくても、対象端末の一覧化と進捗管理だけでも障害対応の負担は大きく下がります。
よくあるトラブルと対処法
接続時に何度も認証を求められる
カスタム Audience を使っている場合、XML に applicationid が入っていない可能性があります。audience にカスタム Audience ID、applicationid に Microsoft-registered App ID が入っているか確認してください。(Microsoft Learn)
クライアントでは保存できるが接続できない
Gateway 側の Audience 値と Azure VPN Client 側の Audience 値が一致していない可能性があります。移行時は、Gateway 側だけでなく、配布済みの既存クライアント設定も更新してください。(Microsoft Learn)
Issuer の値は正しいはずなのに失敗する
Issuer URL の末尾に / がないケースがあります。公式ドキュメントでは、Issuer の末尾にスラッシュを含める必要があると説明されています。(Microsoft Learn)
DNS が引けず業務システムに接続できない
Microsoft Entra ID 認証利用時、Azure VPN Client は DNS Name Resolution Policy Table（NRPT）エントリを利用するため、ipconfig /all だけでは実際の DNS 設定を確認しにくい場合があります。PowerShell の Get-DnsClientNrptPolicy などで確認しましょう。(Microsoft Learn)
プロファイルを配布したのに一部ユーザーだけ接続できない
古い Azure VPN Client、古い XML、別テナントのプロファイル、条件付きアクセス、MFA 要求、端末準拠性などが原因として考えられます。まずは Azure VPN Client のバージョン、Audience 値、Tenant、Issuer、ユーザーの Entra ID サインインログを確認してください。
今回の更新ポイントをどう判断すべきか
Azure VPN Client の Microsoft Entra ID 認証設定は、単なるクライアント設定ではなく、今後の P2S VPN 運用方式に関わる変更です。特に重要なのは次の3点です。
- 手動登録 Azure VPN Client には廃止期限がある
- Microsoft-registered App ID の Audience 値へ移行するには、Gateway とクライアントの両方を更新する必要がある
- カスタム Audience や Device SSO を使う場合は、XML の追加設定と検証が必要になる
まずは、現在の VPN Gateway の Audience 値を確認してください。手動登録 App ID を使っているなら、期限まで余裕があっても、検証用端末で Microsoft-registered App ID への移行テストを始めるべきです。すでに Microsoft-registered App ID を使っている環境でも、Azure VPN Client のバージョン、プロファイル配布方法、DNS・ルーティング設定、Device SSO の利用有無を見直しておくと、将来の接続トラブルを減らせます。
コメント