Azure DevOps（Azure Repos / Azure Pipelines）のセルフホスト エージェントを社内ネットワークに置くと、最初にぶつかるのが「ファイアウォールの許可リスト（IP/FQDN）は何をどこまで開けるべきか？」という悩みです。この記事では、Microsoft ドキュメントに並ぶ CIDR の意味と通信方向、運用で破綻しない許可方法（Service Tag / FQDN 許可 / 更新運用）を実務目線で整理します。
Azure DevOps のセルフホスト エージェントが通信する仕組みを押さえる
まず重要なのは、Azure DevOps のセルフホスト エージェント（Self-hosted agent）は外部（Azure DevOps）から「呼び出される」のではなく、エージェント自身が Azure DevOps に対して接続を張りにいくという点です。多くの社内ネットワークで「inbound を開けないとジョブが飛んでこないのでは？」と誤解されがちですが、実際には逆で、エージェントは Azure DevOps サービスへ HTTPS で接続し、一定間隔でジョブを取りに行く（ポーリングする）方式で動きます。
このため、ネットワーク設計で最初に考えるべきはエージェント → Azure DevOps の outbound（送信方向）です。一般的なステートフル FW であれば outbound を許可すると戻り通信（応答）はセッションとして自動的に許可されるため、エージェント向けの inbound を個別に開ける必要は通常ありません。
通信の向きと用途を一枚で把握する
| 観点 | 結論（セルフホスト エージェント） | 補足 |
|---|---|---|
| 通信開始の主体 | エージェント側が開始 | ジョブ取得・ログ送信・成果物アップロード等をエージェントが実施 |
| 基本プロトコル | HTTPS（TCP 443） | Git を HTTPS で扱う場合も 443 が中心 |
| 許可すべき方向 | エージェント → Azure DevOps への outbound | ステートフル FW なら戻り通信はセッションとして許可される |
| inbound（外部→エージェント） | 通常は不要 | エージェントを外部公開する運用は推奨されない |
結論：ドキュメント記載の IP 範囲は「宛先（Azure DevOps 側）」として許可すればよい
Microsoft のドキュメントや公開情報で見かける複数の IP 範囲（CIDR）は、セルフホスト エージェントが Azure DevOps サービスへ到達するために許可すべき宛先（Azure DevOps 側）として扱う理解で問題ありません。
エージェントは、ジョブの取得、パイプライン実行結果の報告、ログ/成果物のアップロードなどを、原則としてエージェント→Azure DevOps の outboundで行います。ファイアウォールで「送信先 IP をホワイトリストに入れたい」場合、これらの CIDR を宛先（Destination）として登録し、TCP 443 を許可する形になります。
許可すべき IP 範囲（代表例）
下記はドキュメント等で例として挙げられることが多い代表的な CIDR です。IP 範囲は将来変更される可能性があるため、固定リスト運用をする場合は「定期更新」の前提で設計してください。
| 許可候補（CIDR） | 扱い | FW ルールのポイント |
|---|---|---|
| 13.107.6.0/24 | Azure DevOps 側宛先 | エージェントからの outbound（TCP 443）を許可 |
| 13.107.9.0/24 | Azure DevOps 側宛先 | 同上 |
| 13.107.42.0/24 | Azure DevOps 側宛先 | 同上 |
| 13.107.43.0/24 | Azure DevOps 側宛先 | 同上 |
| 150.171.22.0/24 | Azure DevOps 側宛先 | 同上 |
| 150.171.23.0/24 | Azure DevOps 側宛先 | 同上 |
| 150.171.73.0/24 | Azure DevOps 側宛先 | 同上 |
| 150.171.74.0/24 | Azure DevOps 側宛先 | 同上 |
| 150.171.75.0/24 | Azure DevOps 側宛先 | 同上 |
| 150.171.76.0/24 | Azure DevOps 側宛先 | 同上 |
「どの方向の通信を許可すべきか？」を現場の言葉で言い換える
許可リストを検討する場面では、ネットワーク担当者と運用担当者の会話がすれ違いがちです。そこで、よくある質問を「FW ルールの観点」で言い換えて整理します。
| よくある質問 | FW ルールに落とすと | 判断のコツ |
|---|---|---|
| この IP はエージェント側？Azure DevOps 側？ | 宛先（Destination）として登録する | エージェントが外へ出るための到達先として考える |
| inbound（外部→社内）も開ける必要がある？ | 基本は不要。outbound 許可で足りる | エージェントは受信待ちではなくポーリング |
| ポートは何を開ける？ | 基本は TCP 443 | HTTPS が中心。SSH を使う場合のみ例外があり得る |
| 許可リストは固定でよい？ | 固定なら定期更新が必須 | 変更に追従しないと突然つながらなくなる |
運用で破綻しないベストプラクティス：Service Tag を優先する
IP の固定運用がつらい最大の理由は、Microsoft 側の都合で IP 範囲が増減し得るためです。そこで推奨されるのがService Tag（例：AzureDevOps）を使った許可です。Service Tag は「特定の Microsoft サービスが利用する IP 群」を抽象化したラベルで、Azure 側のネットワーク制御（Azure Firewall / NSG など）で宛先をまとめて扱えます。
もしセルフホスト エージェントが Azure（仮想マシン/仮想ネットワーク）上にいる場合は、まず Service Tag を検討する価値が高いです。ルールが「タグ」になるため、IP 変更の追従が自動化され、運用負荷と障害リスクが大きく下がります。
Service Tag を使うときの実務ポイント
- 許可ルールは「宛先：AzureDevOps」「プロトコル：TCP」「ポート：443」が基本形
- エージェントがいるサブネットに対して、NSG で egress 制御する場合も同じ考え方
- Azure Firewall を使う場合は、ネットワークルール（IP/タグ）とアプリケーションルール（FQDN）を使い分ける
- 企業ネットワークの FW に Service Tag が直接使えない場合は、次の「更新運用（JSON 取り込み）」が現実解
オンプレ/社内 FW で Service Tag が使えない場合の現実解：IP 範囲の定期更新
社内の境界 FW（UTM/プロキシ/次世代 FW）では Service Tag をそのまま扱えないケースが多くあります。その場合は、Microsoft が公開している「Azure の公開 IP 一覧（Service Tag を含む JSON）」を定期的に取得し、AzureDevOps 相当の IP 群を抽出して許可リストを更新する運用が現実的です。
ポイントは「人手でページを見て書き換える」ではなく、更新を自動化して差分検知することです。Azure DevOps の通信は突然途切れるとパイプライン全体が止まり、影響範囲が大きくなりがちです。更新作業を属人化させず、監査ログを残す仕組みにしておくと運用が安定します。
更新運用のおすすめ手順
| ステップ | やること | 狙い |
|---|---|---|
| 取得 | Microsoft 公開の IP/Service Tag JSON を定期ダウンロード | 最新の IP 変更を取り込む |
| 抽出 | Service Tag（AzureDevOps）に紐づくアドレスだけを抽出 | 許可範囲を最小化する |
| 差分 | 前回との差分を比較し、追加/削除をリスト化 | レビューしやすくする |
| 反映 | FW のアドレスグループへ反映（API/CLI があれば自動化） | 手作業ミスを減らす |
| 監視 | 更新失敗や通信失敗をアラート | 「気づいたら止まっていた」を防ぐ |
実際の自動化は組織の標準（PowerShell / Python / CI など）に合わせればよいですが、最低限の発想としては「JSON を取る → AzureDevOps を探す → addressPrefixes を出す」という流れになります。
# 例：考え方（疑似コードのイメージ）
# 1) JSON を取得
# 2) values[] の中から name が "AzureDevOps" 相当の要素を探す
# 3) properties.addressPrefixes を抽出して許可リストへ反映
FQDN 許可ができる FW なら「ドメイン許可」も強力な選択肢
次に、FW が FQDN（ドメイン名）ベースの許可に対応している場合は、IP よりもFQDN 許可の方が運用しやすいことがあります。Azure DevOps は CDN やフロントドアなどの仕組みで IP が変動し得るため、IP 固定よりも「名前で追従する」方が自然です。
ただし、FQDN 許可は万能ではありません。製品によっては「DNS で引いた IP を一定時間キャッシュして許可する」方式で、DNS キャッシュのタイミングや TTL、TLS の SNI 対応などが絡みます。導入前に、必ず PoC で挙動確認するのがおすすめです。
代表的に検討される FQDN 例
*.dev.azure.com（現行の Azure DevOps Services）*.visualstudio.com（旧ドメインを使う組織/接続形態が残っている場合）
加えて、利用機能によっては追加のホストが必要になることがあります。たとえば Azure Artifacts（パッケージ）を使う、外部リポジトリから取得する、コンテナレジストリへアクセスする、といったケースです。ここは「Azure DevOps だからこれだけで終わり」と決め打ちせず、実際のパイプラインがどこへ通信するかをログで確認しながら許可範囲を詰めるのが安全です。
アウトバウンド許可だけで足りる理由：ジョブは「外から来る」のではなく「取りに行く」
セルフホスト エージェントは、Azure DevOps に対して常時（または一定間隔で）接続し、空きがあればジョブを要求します。つまり「ジョブを投げる側」がエージェントへ inbound 接続する必要がありません。
社内セキュリティの観点でも、エージェントはビルドやデプロイの実行権限を持つため、インターネットから到達可能にするのはリスクが高い運用です。原則として、エージェントは社内側に閉じたまま、必要最小限の outbound のみを開ける設計が推奨されます。
設計を強くするチェックリスト：最小許可と追加許可を分けて考える
「Azure DevOps に接続できる」ことと「パイプラインが成功する」ことは別問題です。接続は通っても、ジョブ内で必要な外部通信が塞がれて失敗することがあります。そこで、許可を設計するときは最小構成（エージェント登録・ジョブ受信）とパイプライン実行で追加される通信を分けて整理すると、関係者間の合意が取りやすくなります。
| 区分 | 目的 | 許可の考え方 | 例 |
|---|---|---|---|
| 最小構成 | エージェントが Azure DevOps と通信し、ジョブを受け取る | Azure DevOps 宛の outbound（443）をまず通す | IP（CIDR）許可 / Service Tag（AzureDevOps）/ *.dev.azure.com |
| 追加（パイプライン依存） | ジョブ内で外部サービスへアクセスする | 必要に応じて段階的に許可を追加 | GitHub/社内アーティファクトサーバー/NuGet レジストリ/コンテナレジストリ など |
プロキシ環境の落とし穴：許可リストが合っていてもつながらないケース
社内ネットワークでは、直接インターネットへ出さずにアウトバウンド プロキシ経由にしていることも多いです。この場合、FW の許可リストが正しくても、エージェントがプロキシを使えていなければ通信できません。逆に、プロキシ経由で出す場合は「宛先 IP を FW で許可する」のではなく、エージェント → プロキシさえ通れば、その先はプロキシの制御ポリシーになります。
プロキシ設定で確認したい代表項目
| 項目 | 確認ポイント | ありがちな症状 |
|---|---|---|
| HTTP/HTTPS プロキシ | OS 設定または環境変数でプロキシが指定されているか | エージェント登録時にタイムアウト |
| プロキシ認証 | 認証方式（Basic/NTLM/Kerberos）とエージェント対応 | 401/407 が出て接続できない |
| SSL インスペクション | 社内で HTTPS を復号する場合、証明書信頼が取れているか | 証明書エラーで通信失敗 |
| 除外設定（NO_PROXY） | 社内宛て通信をプロキシ経由にしない設計になっているか | 社内リソースへのアクセスが遅い/失敗する |
とくに SSL インスペクション（HTTPS 復号）を行っている環境では、Azure DevOps への TLS 通信が中間者証明書で置き換わるため、エージェント実行環境がその証明書を信頼していないと接続できません。許可リストの議論だけでは解決しない領域なので、ネットワーク/セキュリティ部門と早めに前提を共有しておくとスムーズです。
疎通確認の実務手順：FW 変更前後で「何が通っているか」を可視化する
「許可したはずなのに接続できない」を最短で潰すには、疎通確認を段階的に行うのが効果的です。以下の流れでチェックすると、原因の切り分けがしやすくなります。
- DNS 解決：対象 FQDN が社内 DNS で正しく引けるか（名前解決できないと IP 許可以前に失敗します）
- TCP 接続：443 へ到達できるか（FW/プロキシの層を疑う）
- TLS ハンドシェイク：証明書エラーがないか（SSL インスペクションやルート証明書の問題）
- エージェント登録：PAT/認証の問題か、通信の問題かをログで判断
Windows 環境なら、PowerShell の Test-NetConnection で 443 の到達性を見たり、FW のログ（送信先 IP とポート、deny 理由）で「落ちている先」を確認すると原因が見えやすくなります。Linux なら curl -v で TLS の段階まで確認するのが有効です。
現場でハマりがちなポイントと対策
最後に、許可リスト設計でありがちなつまずきを「症状→原因→対策」の形でまとめます。すでに FW ルールを入れているのに不安定、特定のパイプラインだけ失敗する、といったケースのヒントになります。
| 症状 | 原因の例 | 対策 |
|---|---|---|
| エージェント登録がタイムアウトする | アウトバウンド 443 が閉じている / プロキシ未設定 / DNS 解決不可 | まず *.dev.azure.com への 443 到達性を確認し、プロキシ前提ならエージェントに設定 |
| たまにオフラインになる | IP 変更に追従していない / FQDN 許可の DNS キャッシュ挙動 | Service Tag の採用、または IP リスト更新を自動化。FW の FQDN 実装仕様も確認 |
| Git クローンだけ失敗する | Azure Repos への経路は通るが、別経路（ミラー/外部）や認証が原因 | 実際の接続先（URL）をログで確認し、必要な宛先だけを追加許可 |
| 成果物のアップロードで失敗する | Azure DevOps 以外のストレージ/関連エンドポイントがブロック | Azure DevOps だけでなく、実際にアクセスしているホストを FW ログで特定して許可 |
| 証明書エラーが出る | SSL インスペクションで証明書が差し替わり、信頼できない | 社内 CA 証明書の配布、または Azure DevOps 宛て復号除外を検討 |
まとめ：許可リストは「IP を並べる作業」ではなく「運用設計」
Azure DevOps のセルフホスト エージェントをファイアウォール配下で動かすとき、ドキュメントにある CIDR は「エージェントが接続する Azure DevOps 側の宛先」として扱い、エージェント→Azure DevOps の outbound（主に TCP 443）を許可するのが基本です。
そして、長期的に安定させるには「固定 IP を一度入れて終わり」ではなく、Service Tag の活用、IP リストの定期更新、FQDN 許可の採用といった、変更に追従できる運用を前提に設計することが重要です。最初は最小構成でつなぎ、パイプラインの要件に合わせて許可範囲を段階的に拡張していけば、セキュリティと開発生産性を両立しやすくなります。
コメント