Azure Container Apps（ACA）から外部CRMへAPIを叩くとき、CRM側で送信元IPをホワイトリスト化したいのに、ポータルやログで見えるIPがバラバラで混乱しがちです。本記事では「CRMが実際に見る送信元IP」の確かめ方と、NAT Gatewayで固定IP化する定番設計を具体的にまとめます。
「どのIPを許可すべきか分からない」問題が起きる理由
Azureのマネージドサービスでは、アプリが外部へ出る経路に複数のネットワークレイヤー（内部ネットワーク、ロードバランサ、SNAT など）が挟まります。そのため、同じシステムを見ているつもりでも「参照している場所」が違うだけで、見えるIPが変わります。
特にAzure Container Appsでは、次のような“別物のIP”を同時に見てしまうことが多いです。
| どこで見えるIPか | そのIPが表すもの | CRMの許可リストに使える？ | よくある落とし穴 |
|---|---|---|---|
| Azureポータルの「ドメイン」欄などで見えるIP | 主に受信（Ingress）や管理トラフィック側のパブリックIP（外部公開時） | 基本的に不可 | 「ポータルに出ている=送信元」と思い込む |
コンテナ内で ip a / hostname -I などで見えるIP | サブネット内のプライベートIP（10.x/172.16.x/192.168.x等） | 不可 | 外部からは見えないIPを許可しても意味がない |
| バックエンドのログに出てくるIP | 中継レイヤー（ロードバランサ等）や、アプリが見ている「相手」のIP | ケースによるが多くは不可 | ログ上のIPが“最終的な送信元”とは限らない |
| 外部サービス（ifconfig系）やCRMのアクセスログで見えるIP | インターネットへ出た後のSNAT済みグローバルIP | 可（これが権威的） | ここを見ずに推測で運用してしまう |
結論だけ先に言うと、CRMが許可／拒否を判断する材料は「CRMが受け取ったHTTPリクエストの送信元IP」です。つまり、インターネット側から見える最終的なグローバルIP（SNAT後）が“権威的な送信元IP”になります。
権威的な送信元IPを特定する最短ルート
IPホワイトリストの設計で最重要なのは、「推測」ではなく「観測」することです。観測対象は、必ず“外から見えるIP（=CRMが見るIP）”に寄せます。
外部IP確認サービスで「いま外に出ているIP」を観測する
Container Appsのコンソール（Console / Exec）から、外部に対して“自分の送信元IPを返してくれる”サービスへアクセスします。結果に出るIPが、その時点で外部から見える送信元IPです。
curl -s https://ifconfig.me
# または
curl -s https://api.ipify.orgポイント
セキュリティ観点では、検証でも-k（証明書検証スキップ）は極力避け、HTTPSを正しく検証できる状態で確認するのがおすすめです。
CRM側のアクセスログで「受け取った送信元IP」を確認する
CRMがアクセスログ（または監査ログ）を持っている場合、最も確実なのはCRM側で「実際に入ってきた送信元IP」を確認することです。外部IP確認サービスとCRMのログが一致すれば、ホワイトリストに登録すべきIPが確定します。
Azureポータルの「Outbound IP」表示は参考情報として扱う
Azure Container Apps環境には「Outbound public IP（アウトバウンドのパブリックIP）」の概念がありますが、ドキュメント上もアウトバウンドIPは時間と共に変わり得ます。特に“固定IPのホワイトリスト運用”という要件に対しては、表示されているIPを盲目的に信じるのではなく、上の観測（curlやCRMログ）で確認するのが安全です。
Microsoft管理の動的IPと、IPホワイトリスト運用が噛み合いにくい理由
「Microsoftが公開しているIPレンジをCRMで許可すればいいのでは？」という発想は自然ですが、実運用では次の壁に当たりやすいです。
- 公開されているのはサービス／リージョン単位の広いIPレンジで、CRM側で許可範囲が大きくなりがち
- AzureのIPレンジ／Service TagのJSONは定期更新され、週次で追従が必要になる（更新ファイルを毎週ダウンロードする前提が明記されています）
- CRMが「AzureのService Tag」を理解してくれるわけではない（多くは単純なIP制限のみ）
そのため、セキュリティ強化の方向性としては「Azureが持つ巨大なIPレンジを許可」ではなく、自分たちでコントロールできる“出口（Egress）”を作って、そこからのIPだけを許可に寄せる方が現実的です。
まず確認すべき前提: Container Apps環境タイプでできることが変わる
Azure Container Appsには大きく分けて環境タイプがあり、NAT Gatewayによる固定Egressはどの環境でも無条件にできるわけではありません。
| 環境タイプ | サポートされるプラン | NAT Gateway/UDRなどのカスタムEgress | 最小サブネットサイズ | 送信元IP固定のしやすさ |
|---|---|---|---|---|
| ワークロード プロファイル環境 | 従量課金、専用 | サポート（NAT Gateway経由のEgress、UDRなど） | /27 | ◎（固定IP運用に寄せやすい） |
| 消費量のみ環境 | 従量課金 | 非サポート（NAT Gateway経由EgressやUDRなど不可） | /23 | △〜×（固定IP前提の設計にしにくい） |
ドキュメント上も、Container Apps環境のアウトバウンドIPは変わり得ること、そしてNAT Gatewayなどの制御されたアウトバウンドはワークロードプロファイル環境でのみサポートされることが明記されています。
重要
「消費量のみ環境」で“必ず固定IPでホワイトリスト運用したい”場合は、環境タイプ自体をワークロードプロファイル環境へ作り直す設計が現実解になります。Microsoft Q&Aでも、消費量のみ環境では固定アウトバウンドIPを強制できない旨と、ワークロードプロファイル環境＋NAT Gatewayで固定化する流れが案内されています。
結論: VNet統合したサブネットにNAT Gatewayを関連付け、送信元IPを固定する
CRM側で「特定のIPだけ許可」を実現したいなら、王道はこの形です。
- 自分たちで用意した 固定パブリックIP を持つ
- そのIPを紐付けた NAT Gateway を作る
- Container Apps環境が使う サブネットにNAT Gatewayを関連付け、外向き通信を集約する
Microsoft Learnでも、ワークロードプロファイル環境でサブネットにNAT Gatewayを構成すると、環境に静的パブリックIPが提供され、Container Appのアウトバウンドがその静的IPを経由する旨が説明されています。
手順: NAT Gatewayで固定アウトバウンドIPを作り、CRMにホワイトリスト登録する
事前に整理する情報
作業前に、次の情報を手元に揃えると迷子になりません。
| 項目 | 例 | 補足 |
|---|---|---|
| Container Apps環境（Managed Environment）名 | prod-aca-env | “アプリ”ではなく“環境”側のネットワーク設定が肝です |
| VNet名／サブネット名 | prod-vnet / aca-infra-subnet | NAT Gatewayはサブネットに紐付くため、対象サブネット特定が重要 |
| 環境タイプ | ワークロードプロファイル環境 | NAT Gatewayを使うなら必須（消費量のみ環境では非サポート） |
| CRM側のIP許可形式 | 単一IP、CIDR、範囲指定など | CRMに合わせて“/32”か“プレフィックス”かを選びます |
固定パブリックIPアドレスを作成する（Standard SKU）
Azureで Standard SKU のパブリックIPを作成し、割り当て方法は Static を選びます。NAT GatewayはStandard SKUのパブリックIP／プレフィックスをサポートします。
Portal作業の目安（例）:
- リソースの作成 → 「パブリック IP アドレス」
- SKU: Standard
- 割り当て: Static
- リージョン: Container Appsと同じリージョン
NAT Gatewayを作成し、固定パブリックIPを紐付ける
次に、NAT Gatewayを作成して先ほどのパブリックIPを関連付けます。これが“外への出口”になります。
- NAT Gatewayリソースを作成
- アウトバウンドIPに、作成したパブリックIP（例:
natPublicIp）を追加
NAT Gatewayはサブネット単位でアウトバウンドを提供し、外部の宛先側ファイアウォールを“予測可能なIP”で設定できる、という思想で設計されています。
Container Apps環境が使用するサブネットにNAT Gatewayを関連付ける
ここが一番重要です。NAT Gatewayは「Container Apps」そのものに付くのではなく、Container Apps環境が使うサブネットに付けます。
- 対象VNet → サブネット → 対象サブネットを開く
- サブネットの設定で NAT Gateway を選択し、作成したNAT Gatewayを関連付け
- 保存
補足
Container Apps環境は、作成時にサブネットのリソースID（infrastructure-subnet-resource-id）を指定し、そのサブネット上に基盤コンポーネントとアプリコンテナが配置される、という考え方です。対象サブネットを間違えると、IP固定化が効きません。
Container Appsを再デプロイ／再起動して経路を更新する
ネットワーク設定は即時に効くケースもありますが、実務では新しいリビジョンをデプロイする、または再起動して“確実に経路が切り替わった状態”で検証するのが安全です。
外部から見える送信元IPを確認する
再起動後、Container Appsのコンソールから次のように確認します。
curl -s https://ifconfig.me
curl -s https://api.ipify.org表示されたIPが、CRMが受け取る送信元IPの候補です。NAT Gatewayの「送信パブリックIP（アウトバウンドIP）」として設定したものと一致すれば、固定化の成功と判断できます。
CRM側の許可リストに、固定IP（またはIPプレフィックス）を登録する
CRM側の設定で、次のいずれかを登録します。
- 単一IPで許可できる場合: x.x.x.x（または x.x.x.x/32）
- 将来SNATスケールを見越して複数IPを持つ場合: IPプレフィックス（例: /28） を許可
NAT Gatewayは、パブリックIPを最大16個まで組み合わせられ、IPを増やすことでSNAT枯渇を避けやすくなります。単一IPにこだわりすぎず、必要なら“最小限の範囲”でプレフィックス許可にするのも設計のコツです。
固定IP化で解決できること・できないこと
解決できること
- CRMの許可リストに登録すべきIPが明確になる（見えていた複数IPの混乱が解消）
- Microsoft管理の動的IP変更に振り回されない
- 許可範囲を最小化できる（巨大なAzure IPレンジ許可を避けられる）
注意が必要なこと
- 消費量のみ環境では、NAT Gateway経由の制御されたEgressがサポートされないため、固定IP要件があるなら環境タイプの見直しが必要
- NAT Gatewayは“アウトバウンド”の仕組みであり、外部から新規に内向き接続を開始できるものではない（設計上それで安全）
運用でハマりやすいポイントと対策
「NATを付けたのにIPが変わらない」
- 付けたサブネットが違う: Container Apps環境が実際に使っているサブネットに関連付けできているか再確認
- 環境タイプが消費量のみ: そもそもNAT Gateway経由Egressのサポート外の可能性
- 検証が1回だけ: スケールやリビジョン更新後にも再確認（複数回）
「単一IPに集約したら通信が不安定になった」
大量の短時間接続を作るワークロード（HTTPの新規コネクションが多い、DBへ大量接続する等）では、SNATポート枯渇が疑われます。NAT GatewayではパブリックIPを追加したり、プレフィックスを使うことでSNAT枯渇を避けやすく、各IPあたり 64,512 のエフェメラルポートが提供されます。
アプリ側の改善としては、次が効きます。
- HTTP Keep-Alive を有効化し、接続を再利用する
- 外部API呼び出しをキュー化し、ピーク時の同時接続数を平準化する
- 外部CRMのレート制限や同時接続制限も合わせて設計する
「VPN/特殊ルーティングを入れたら想定通りにならない」
0.0.0.0/0 を別の経路（仮想アプライアンスやVPNゲートウェイ）へ送るUDRを入れている場合、NAT Gatewayのインターネット向け経路が上書きされることがあります。ネットワークチームと、ルートテーブル（UDR）とNATの優先関係を必ず擦り合わせてください。
動的IPが前提のとき、送信元IP制限をどう設計するのがベストか
「IP制限したい」という要求の背景は、多くの場合“なりすまし・不正アクセスのリスクを下げたい”です。そこで、IP制限だけに寄せるのではなく、次のレイヤーを組み合わせると現実的に強くできます。
| 設計パターン | 概要 | 強み | 注意点 |
|---|---|---|---|
| NAT Gatewayで固定IP化 | サブネットの出口を固定IPに集約 | 構成がシンプル、CRMのIP許可と相性が良い | L7の検査やURL単位制御はできない |
| Azure Firewall + UDR | 強制トンネルでFirewall経由にして、固定IP＋制御 | ログ・制御が強い（宛先制限、監査） | コスト・運用が重くなる。ワークロードプロファイル環境前提 |
| 中継プロキシ（API ManagementやVM） | プロキシを固定IPで運用し、CRMへはプロキシから出す | 変換・認証・再送など“統合”がしやすい | 追加コンポーネントが増える |
| IP制限を補助にして、認証を主戦力にする | OAuth2（Client Credentials）、mTLS、署名付きJWTなど | IPが揺れてもセキュリティを担保しやすい | CRM側が対応している方式に依存 |
| Azure公開IPレンジの許可＋自動追従 | ServiceTags JSONを週次更新してCRM側へ反映 | 環境変更が難しい場合の最終手段 | 許可範囲が広くなりがち。更新運用が必須 |
要件が「CRM側はIP制限しかできない」「許可範囲を極小にしたい」「運用負荷を減らしたい」であれば、固定IP化できる出口（NAT GatewayやFirewall）を自分たちで持つのがベストプラクティスです。
チェックリスト: 公開前にここだけは確認する
- CRMが見ている送信元IPが、NAT GatewayのパブリックIPと一致している
- スケールアウト（複数レプリカ）後も送信元IPが変わらない
- 新しいリビジョンをデプロイしても送信元IPが変わらない
- CRM側の許可リスト形式（単一IP/CIDR/範囲）で正しく登録できている
- 将来の接続数増に備えて、SNAT枯渇の対策方針（IP追加 or プレフィックス）を決めている
まとめ
Azure Container Appsから外部CRMへアクセスする場合、ポータルやログに見えるIPが一致しないのは珍しくありません。ホワイトリストに入れるべき“本当の送信元IP”は、外部から観測できるSNAT後のグローバルIPです。そして固定IP運用を成立させたいなら、ワークロードプロファイル環境＋VNet統合＋NAT Gatewayで出口を自分たちの静的IPに揃えるのが最短で安全な選択肢になります。
コメント