Azure DevOps を South India リージョンで使っているのに、オンプレミスのファイアウォール（Palo Alto など）から dev.azure.com への通信が頻繁にブロックされる――Front Door/CDN 経由の“動的 IP”が原因で、運用設計に悩んでいる方は多いはずです。本記事では「South India 専用の固定 IP だけを許可したい」という素朴な要望から出発し、Microsoft 公式情報をベースに、現実的かつセキュアに Azure DevOps を通すためのベストプラクティスを具体的に整理します。
Azure DevOps（South India）をオンプレ FW で通すときにハマるポイント
まず、問題の構造を整理します。
- Azure DevOps（dev.azure.com）は、リージョン別サービスではなく「グローバルサービス」として提供されます。
- ユーザーのブラウザや自社ホストエージェントからのアクセスは、Azure Front Door / CDN 経由で最寄りのエッジに収容されます。
- このエッジの IP は Anycast + 動的エッジの仕組みで随時変わるため、「South India 組織だから South India の IP だけ」では運用できません。
- 2025 年には Edgio CDN 退役に伴い、ダウンロード用ドメインとネットワーク要件が更新されました（
download.agent.dev.azure.comの追加など）。
その結果、「dev.azure.com だけ許可したのに、実際は Azure Front Door / CDN の IP で落ちる」「South India 専用の単一 IP で運用したいが無理」という状況になります。
前提：Azure DevOps の接続モデル（Outbound / Inbound）
Microsoft 公式ドキュメントでは、Azure DevOps のネットワーク要件を以下の 2 つに分けて説明しています。
- Outbound 接続：社内 → Azure DevOps（ユーザーのブラウザ、Self-Hosted Agent など）
- Inbound 接続：Azure DevOps → 社内（Service Hooks、オンプレ Git/DB、Audit Streaming など）
この 2 つは設計思想も IP の扱いも異なるため、必ず分けて考える必要があります。
Outbound（社内 → Azure DevOps）
Outbound 側で重要なのは次のポイントです。
- 基本ポート：443/TCP（Web/UI、REST API、Self-Hosted Agent → Azure DevOps など、ほぼすべて）
- SSH Git を使う場合のみ 22/TCP（
ssh.dev.azure.com） - 許可すべき代表的な FQDN：
dev.azure.com/*.dev.azure.comdownload.agent.dev.azure.com（Self-Hosted Agent のダウンロード用・2025 年から特に重要）- 互換性のため
*.visualstudio.comも開放が推奨
- Azure DevOps 用の Outbound IPv4 範囲として、次のプレフィックスが公式に公開されています。
13.107.6.0/2413.107.9.0/2413.107.42.0/2413.107.43.0/24150.171.22.0/24150.171.23.0/24150.171.73.0/24150.171.74.0/24150.171.75.0/24150.171.76.0/24
- サービス タグ（AzureDevOps）は Outbound には使えない（公式に明記）。
Inbound（Azure DevOps → 社内）
Inbound 側は Azure DevOps が発信元なので、リージョンごとに IP プレフィックスが決まっています。
- South India 組織からの Inbound 接続に使われる IPv4 範囲は：
20.41.194.0/24
- これには Service Hooks、データインポート、Audit Streaming などが含まれます。
- Inbound に対しては サービス タグ
AzureDevOpsが利用可能- Azure Firewall / NSG でのルール簡素化
- オンプレ FW でも JSON を取り込める製品なら、サービスタグ JSON を EDL として利用可能
「South India 専用の固定 IP だけで運用」はなぜ無理なのか
よくある誤解は「組織リージョンが South India なら、South India の IP だけ許可すればいいのでは？」というものです。しかしこれは Outbound では成り立ちません。
- dev.azure.com の実体は Azure Front Door / CDN のエッジ群であり、ユーザーに最も近いエッジにトラフィックが流れます。
- Front Door / CDN は Anycast アドレスと動的エッジを採用しており、同じ FQDN に対しても時間・経路によって異なる IP が返されることがあります。
- 2025 年の Edgio CDN 退役では、新たな CDN（Akamai + Azure Front Door）の背後にある IP 範囲が追加されており、今後も増減の可能性があります。
つまり：
- Outbound：世界中の Front Door/CDN エッジが相手になるため、「South India 固定 IP」前提は破綻します。
- Inbound：Azure DevOps 側から社内に来る通信は South India 用の
20.41.194.0/24に収束するので、リージョン別の固定 IP 運用が可能です。
この構造を理解すると、「Outbound は FQDN または公開 IP 範囲」「Inbound はリージョン固定 IP or サービス タグ」という住み分けが自然に見えてきます。
結論：優先順位付きベストプラクティス
South India の Azure DevOps 組織をオンプレ FW から通すときの推奨順は次の通りです。
- 可能なら FQDN ベースで許可（最優先）
- FQDN がどうしても使えない場合のみ、公開 IP プレフィックスを明示許可
- 必要に応じて Proxy / Azure Egress などのネットワーク設計で FQDN 制御を実現
以降で、それぞれを詳しく見ていきます。
最優先：FQDN ベースでの許可（Outbound）
Microsoft 公式も、「dev.azure.com と *.dev.azure.com を 443/TCP で開ける」ことを強く推奨しています。
最低限許可すべき FQDN 一覧
| 種別 | FQDN | 用途 | ポート | 備考 |
|---|---|---|---|---|
| 必須 | dev.azure.com | ポータル UI / REST API / 多くの機能 | 443/TCP | 組織 URL（例：https://dev.azure.com/{org}） |
| 必須 | *.dev.azure.com | 各種サブドメイン（aex, vsrm など） | 443/TCP | ワイルドカード許可が推奨 |
| 重要 | download.agent.dev.azure.com | Self-Hosted Agent / VMSS Agent / Managed DevOps Pools のエージェントダウンロード | 443/TCP | 2025 年の CDN 変更後に追加。ワイルドカード不可環境では特に必須。 |
| 互換 | *.visualstudio.com | 旧 URL / 一部機能との互換 | 443/TCP | ドキュメント上も引き続き許可が推奨。 |
| SSH Git | ssh.dev.azure.com | Git over SSH | 22/TCP | SSH 利用時のみ必須 |
このほかにも、認証（login.microsoftonline.com）や CDN（*.vsassets.io）など、多数の FQDN が公式に列挙されていますが、Azure DevOps の UI / Pipelines / Self-Hosted Agent を使ううえで最低限必要なのは上記群になります。
Palo Alto などでの FQDN 許可の考え方
多くの FW（Palo Alto など）では、次のような制約があります。
- NAT ルールでは宛先 FQDN を指定できないことが多い（IP または any）
- 一方で、セキュリティポリシー側では FQDN オブジェクトや SNI/URL カテゴリベースで制御できる
従って、現実的な構成は次のようになります。
- NAT ルールは「社内 → インターネット宛」を汎用的に定義（宛先 any）。
- セキュリティポリシーの宛先に FQDN オブジェクト（
dev.azure.com/*.dev.azure.com/download.agent.dev.azure.com）を指定して許可。 - その他の宛先は別ポリシーで遮断 or プロキシ経由にする。
「NAT で FQDN 指定はできないが、セキュリティポリシーでは FQDN を使う」という分離がポイントです。
FQDN がどうしても使えない場合：IP プレフィックスでの Outbound 制御
一部の組織では「ポリシー上 FQDN 制御が認められない」「機器側の制約で FQDN オブジェクトが使えない」といった理由から、IP ベースでの運用を強いられることがあります。その場合は、Azure DevOps 用に公開されている Outbound IP 範囲を利用します。
許可すべき Outbound IPv4 範囲（443/TCP）
| アドレス範囲 | 備考 |
|---|---|
13.107.6.0/24 | Azure DevOps / Front Door / CDN 用 |
13.107.9.0/24 | 同上 |
13.107.42.0/24 | 同上 |
13.107.43.0/24 | 同上 |
150.171.22.0/24 | 同上 |
150.171.23.0/24 | 同上 |
150.171.73.0/24 | 同上 |
150.171.74.0/24 | 同上 |
150.171.75.0/24 | 同上 |
150.171.76.0/24 | 同上 |
IPv6 も公開されていますが、多くの企業では v4 のみで運用しているため、本記事では IPv4 に絞って解説します。
サービス タグが Outbound で使えない理由
Azure DevOps の「Allowed IP addresses and domain URLs」では、Outbound には Azure Service Tags が使えないことが明記されています。
- Outbound の通信（ユーザーのブラウザ / Self-Hosted Agent → Azure DevOps）は、Azure の外（インターネット側）から見れば「任意のクライアント → dev.azure.com」です。
- サービス タグは Azure 内のリソース向け（NSG / Azure Firewall）で設計されており、「オンプレ FW の Outbound にはそのまま使わないでほしい」というのが公式のスタンスです。
そのため、オンプレ側で IP ベース運用をする場合は：
- 公式の Outbound IP プレフィックスをそのまま許可する
- あるいは JSON ファイルから AzureDevOps / AzureFrontDoor など関連サービスの範囲を抽出し、EDL として取り込む
IP 範囲の更新をどう自動化するか
Azure の IP 範囲とサービス タグは、Microsoft の公式 JSON ファイルとして週次で公開されています。
- ダウンロード元：
Azure IP Ranges and Service Tags – Public Cloud（最新のServiceTags_Public_YYYYMMDD.json） - 週 1 回更新されます。
- 新しい IP 範囲は、JSON に現れてから少なくとも 1 週間は Azure で使用されません（公式に保証）。
これを利用し、次のような週次自動更新フローを組むのが現実的です。
- 週 1 回のスケジュールでスクリプト（PowerShell / Python / Azure Function など）を実行。
ServiceTags_Public_*.jsonをダウンロード。"name": "AzureDevOps"など関係するサービスタグ、あるいは Azure DevOps ドキュメントで指定されているプレフィックスを抽出。- 抽出した IP 範囲をテキストファイルに整形し、FW の 外部動的リスト（EDL） の配信元として配置。
- FW 側では、その EDL を参照するセキュリティポリシーで Azure DevOps 通信を許可。
「新しい範囲は 1 週間は未使用」という仕様のおかげで、週 1 回の自動更新で十分追従可能です。
Inbound（South India → 社内）の設定：サービスフック等
Service Hooks や Azure DevOps から社内に向かう webhook を利用する場合、接続元は South India の Azure DevOps になります。このときのポイントは次の通りです。
- South India の Inbound IPv4 範囲：
20.41.194.0/24
- この範囲からの 443/TCP を、Service Hooks の受信サーバや API Gateway などに向けて許可します。
- Azure 側であれば、サービス タグ
AzureDevOpsを Inbound ルールで利用可能（NSG / Azure Firewall）。 - オンプレ FW でも、Service Tags JSON から AzureDevOps の範囲だけを抜き出し、EDL として扱うことで似た運用が可能です。
| 方向 | 送信元 | 宛先 | 許可する IP/タグ | 主な用途 |
|---|---|---|---|---|
| Outbound | 社内 | Azure DevOps | FQDN（推奨） or Outbound IPv4 範囲 | ブラウザ / Self-Hosted Agent / API など |
| Inbound | Azure DevOps（South India） | 社内エンドポイント | 20.41.194.0/24 または サービスタグ AzureDevOps | Service Hooks / データインポート / Audit など |
どうしてもドメイン許可を使いたいときのネットワーク設計パターン
組織ポリシー上、「NAT で明示的に宛先 IP を指定しなければならない」「FW 上でワイルドカード FQDN を扱えない」といった制限が厳しい場合は、ネットワーク設計を工夫して FQDN 制御を実現するのが現実解です。
パターン 1：L7 プロキシ（Web Proxy / SWG）を経由させる
最もオーソドックスなのは、「すべてのインターネット向け通信を L7 プロキシ経由にする」方式です。
- オンプレ FW からは「プロキシサーバーへの通信」だけを許可。
- プロキシサーバー側で
dev.azure.com/*.dev.azure.com/download.agent.dev.azure.comを URL カテゴリ / FQDN で許可。 - Azure Pipelines の Self-Hosted Agent は、プロキシ経由通信に対応しています（環境変数
HTTP_PROXY、HTTPS_PROXYなどを利用）。
この構成にすると、オンプレ FW は 宛先 IP ではなく「プロキシへの通信だけを許可」すればよくなり、実際の FQDN 制御はプロキシに任せられます。
パターン 2：Azure 側に Egress を集約し、Azure Firewall で FQDN 制御
もう 1 つのパターンは、社内からのインターネット向けトラフィックを一度 Azure 側に引き込み、Azure Firewall（または Azure 上の NVA）からインターネットに出す方式です。
- オンプレ ⇔ Azure 間は VPN / ExpressRoute で接続。
- オンプレからの「外向き通信」はいったん Azure の Hub VNet に集約。
- Azure Firewall のアプリケーションルールで FQDN ベース制御（
dev.azure.com/*.dev.azure.com/download.agent.dev.azure.comなど）。
この構成でも、Azure DevOps ドキュメントが言う通り、Outbound に AzureDevOps サービス タグは使えない点は変わりません。ただし、Azure Firewall は FQDN/MAL カテゴリによるアプリケーションルールを持っているため、オンプレより柔軟に URL 制御が可能になります。
Palo Alto を例にした具体的な設計イメージ
ここでは Palo Alto を例に、「最小変更で Azure DevOps を通す」ケースをイメージしてみます（実装は各組織のポリシーに合わせて調整してください）。
ケース A：FQDN 制御が可能な場合
- FQDN オブジェクトの作成
dev.azure.com*.dev.azure.comdownload.agent.dev.azure.com- 必要であれば
*.visualstudio.comなど
- セキュリティポリシーの作成
- From：社内ゾーン、To：インターネットゾーン
- 宛先アドレス：上記 FQDN オブジェクト
- アプリケーション：
ssl/web-browsingなど - サービス：443/TCP（SSH 利用時は 22/TCP）
- Action：Allow
- NAT ルールは汎用的に
- From：社内ゾーン、To：インターネットゾーン、宛先 any
- 変換先：グローバル IP（NAT プール）
- NAT ルールで宛先 FQDN は使わず、実際の制御はセキュリティポリシー側に寄せる。
この構成なら、「NAT は既存のまま」「セキュリティポリシーだけ追加」という最小変更で Azure DevOps の通信を通すことができます。
ケース B：FQDN 制御不可で IP ベース運用を強いられる場合
FQDN が使えない厳しい環境では、次のような構成が現実解になります。
- 外部動的リスト（EDL）用のテキストファイルを用意
- 内部の Web サーバー（IIS / nginx など）に、Azure DevOps 用 IP リストを公開。
- 内容は前述の Outbound IPv4 範囲 + 必要に応じて ServiceTags JSON から抽出した範囲。
- 週次スクリプトで JSON → EDL ファイルを生成
- PowerShell / Python / Azure Function で
ServiceTags_Public_*.jsonを取得し、対象サービスのaddressPrefixesを抜き出す。 - FW の EDL が読み取れるフォーマット（1 行 1 プレフィックス）で出力。
- PowerShell / Python / Azure Function で
- Palo Alto 側で EDL を参照するアドレスオブジェクトを定義
- セキュリティポリシーで EDL オブジェクトを宛先に指定して許可
こうすることで、「IP を直接ルールにベタ書き → 変更のたびに手作業」という状態を避けつつ、組織ポリシーで求められる IP ベース運用を維持できます。
週次自動同期フローの具体例
実際に Azure IP Ranges JSON を自動処理するフローのイメージを、もう少し具体的に書いてみます。
- 週に 1 回、オンプレ or Azure の自動実行基盤（Azure Automation / Functions / cron など）からジョブを起動。
https://www.microsoft.com/…/Azure IP Ranges and Service Tags – Public Cloudから最新の JSON（ServiceTags_Public_YYYYMMDD.json）をダウンロード。- JSON の
values配列から、必要なタグ（例："name": "AzureDevOps"、"name": "AzureFrontDoor.Frontend"など）をフィルタ。 - それぞれの
properties.addressPrefixesを集約し、重複を除去。 - 1 行 1 プレフィックスのテキストファイルに書き出し、HTTP で公開（Basic 認証などで保護）。
- Palo Alto（他ベンダーでも同様）の EDL 機能を使い、その URL を参照する IP リストオブジェクトを作成。
- セキュリティポリシーでそのオブジェクトを宛先に指定した「Azure DevOps 許可ルール」を作る。
JSON のパース方法自体は、Microsoft 公式やコミュニティでもサンプルコードが多数公開されていますので、既存のサンプルをベースにするのが楽です。
South India 環境での検証手順（ハンズオン）
設定変更後、本当に Azure DevOps が通っているかを確認するための簡単な検証手順を紹介します。
ステップ 1：DNS 解決の確認
- クライアント PC または Self-Hosted Agent から、次を実行：
nslookup dev.azure.comnslookup download.agent.dev.azure.com
- 返ってきた IP アドレスが、Azure DevOps Outbound プレフィックス（例：
13.107.x.x、150.171.x.x）に含まれているかを確認します。
ステップ 2：CDN への到達性テスト
- Self-Hosted Agent 上で、例えば次のようなテストを行います（Windows の例）：
> curl -I https://download.agent.dev.azure.com/agent/4.252.0/vsts-agent-win-x64-4.252.0.zip
ステータスコードが 200 台で返ってくれば、CDN への到達性は問題ありません。Pipeline 内で PowerShell / bash から HEAD リクエストを行う簡易ジョブを追加しておくと、「エージェント更新だけが失敗している」ようなケースの切り分けにも有効です。
ステップ 3：Pipeline 実行と FW ログの確認
- シンプルなビルド Pipeline を 1 本用意し、Self-Hosted Agent で実行。
- FW ログで、許可された通信の宛先 IP が「前述の Outbound プレフィックスに含まれているか」「意図しない IP がブロックされていないか」を確認。
- Service Hooks を利用している場合は、テスト用の webhook を発火させ、South India の
20.41.194.0/24からのアクセスが正しく通っているかを確認。
よくある質問と、ネットワークチームからのツッコミへの対処
Q1：IP が週ごとに増えると、旧 IP を他社が使うのでは？
A：Microsoft 公式の JSON では、「新しい IP 範囲は JSON に登場してから少なくとも 1 週間は使用されない」と明記されています。
- 週次で JSON を取り込み、EDL を更新する運用をとれば、「常に最新の範囲のみ許可」という状態を維持可能です。
- 旧範囲をいつまで許可するかは組織ポリシーによりますが、「最新 JSON に含まれないアドレスは毎週自動で削除」する仕組みを組めば、「旧 IP が第三者に再利用されるリスク」を最小化できます。
Q2：South India 組織だから South India の IP だけ許可でよくない？
A：Outbound では不可、Inbound では可能というのがポイントです。
- Outbound（社内 → dev.azure.com）は Front Door/CDN を通るため、世界中のエッジ IP が使われます。特定リージョンの IP だけ許可する、という考え方は成り立ちません。
- Inbound（Azure DevOps → 社内）は South India の
20.41.194.0/24に収束するので、South India 専用の固定 IP 運用が可能です。
Q3：Microsoft-Hosted Agent も同じ IP 範囲でよい？
A：Microsoft-Hosted Agent は Azure の各リージョンに分散配置されており、IP 範囲は Azure 全体のデータセンター IP にまたがります。
- Azure DevOps 自体とは別に、「AzureCloud.<region>」ごとの IP 範囲を JSON から取得し、地理単位で許可する必要があります。
- 「IP を絞りたい」「社内へのアクセスを最小化したい」場合は、Self-Hosted Agent / Managed DevOps Pools / VMSS Agent の方が設計しやすいケースも多いです。
Q4：Palo Alto で South India の IP だけ許可したのに、別 IP からの通信が来るのはなぜ？
A：それは多くの場合、Outbound と Inbound を混同していることが原因です。
- Service Hooks のような「Azure DevOps → 社内」の通信は South India 範囲から来ます。
- しかし、ブラウザや Self-Hosted Agent から dev.azure.com へアクセスする「社内 → Azure DevOps」の通信は、Front Door/CDN エッジ IP（前述の 13.107.x.x / 150.171.x.x など）であり、South India に限られません。
このあたりを図示しながらネットワークチームと共有すると、「South India 固定 IP だけ許可したい」という要求のどこまでが実現可能で、どこからが Front Door/CDN の設計思想と矛盾するかを理解してもらいやすくなります。
まとめ：最小変更で Azure DevOps（South India）を通すポイント
最後に、本記事の要点をチェックリスト形式でまとめます。
Outbound（社内 → Azure DevOps）
- 理想解：セキュリティポリシーで FQDN 許可
dev.azure.com/*.dev.azure.comdownload.agent.dev.azure.com（Self-Hosted Agent 用）- 可能なら
*.visualstudio.comも
- FQDN 不可の場合：公式 Outbound IPv4 範囲を FW で許可
13.107.6.0/24,13.107.9.0/24,13.107.42.0/24,13.107.43.0/24150.171.22.0/24,150.171.23.0/24,150.171.73.0/24,150.171.74.0/24,150.171.75.0/24,150.171.76.0/24
- サービス タグは Outbound では使えないので、JSON + EDL でプレフィックスを自動更新する運用を採用する。
Inbound（Azure DevOps → 社内）
- South India 組織からの Inbound は
20.41.194.0/24を許可。 - Azure 内（Azure Firewall / NSG）ではサービス タグ
AzureDevOpsを利用可能。
ネットワーク設計・運用の工夫
- 可能であれば、L7 プロキシ経由またはAzure 側での Egress 集約により、FQDN 制御を実現する。
- Palo Alto 等では、NAT ルールは汎用、セキュリティポリシーで実際の制御という役割分担を徹底する。
- Azure IP Ranges JSON を週 1 回自動で取り込み、「最新のプレフィックスだけ許可する」代わりに、旧プレフィックスを自動で除外する仕組みを整える。
要するに――
- Outbound は FQDN 優先（無理なら JSON 連携による IP プレフィックス許可）
- Inbound は South India 固定範囲（
20.41.194.0/24）またはサービスタグAzureDevOps - NAT は汎用にし、実際の制御は L7 / セキュリティポリシー / EDL 側に寄せる
この 3 点を押さえておけば、「South India の Azure DevOps 組織をオンプレ FW で安全に通す」ための設計と運用は、余計なルール追加やトラブルを最小限に抑えつつ実現できます。
コメント