Azure Functionsで外部DBやAPIのファイアウォール許可リストを設定している場合、最初に押さえるべき結論は「IPアドレスは関数単位ではなくFunction App単位で管理され、特にConsumptionプランとPremiumプランではスケールにより変わる可能性がある」という点です。
2026年5月更新の公式情報では、アウトバウンドIPアドレスのAzure portalでの確認手順が整理され、outboundIpAddressesとpossibleOutboundIpAddressesを確認する流れが明確になりました。固定IP前提で運用している管理者や、接続先サービスの許可リストを設定する開発者は、現在のIPだけでなく「変わる条件」と「固定化する方法」まで確認する必要があります。(GitHub)
Azure Functionsの「IP addresses in Azure Functions」で押さえるべき変更点
今回の更新は、Azure FunctionsのIPアドレス仕様が根本的に変わったというより、Function Appの受信IP・送信IPをどこで確認し、どの条件で変わるのかを運用者向けに整理した内容です。GitHub上の公式ドキュメント履歴では、更新日が2026年5月5日に変更され、Azure portalからアウトバウンドIPを確認する手順が、Azure portal内のResource Explorerを使う説明に差し替えられています。(GitHub)
特に重要なのは、次の3点です。
| 確認ポイント | 実務上の意味 |
|---|---|
| IPアドレスはFunction App単位 | 個別の関数ごとに受信IPや送信IPを固定して管理する考え方ではない |
| 送信IPは複数あり、接続ごとに事前予測できない | DB、API、ストレージなどの許可リストには、必要な送信IPをまとめて登録する必要がある |
| Consumption/PremiumではスケールによりIPが変わり得る | 現在表示されているIPだけを許可すると、負荷増加時やスケール時に通信障害が起きる可能性がある |
Azure FunctionsのIPアドレスを扱うときは、「今見えているIPを控える」だけでは不十分です。プラン、スケール方式、接続先のファイアウォール仕様、将来の移行計画まで含めて判断する必要があります。
受信IPと送信IPの違いを正しく理解する
Azure FunctionsのIPアドレスには、大きく分けて受信IPと送信IPがあります。受信IPは外部からFunction AppへアクセスするときのIP、送信IPはFunction Appから外部サービスへ接続するときの送信元IPです。
| 種類 | 使われる場面 | 主な確認方法 | 注意点 |
|---|---|---|---|
| 受信IPアドレス | HTTPトリガーなど、外部からFunction Appへアクセスする場合 | nslookup | 関数単位ではなくFunction App単位。HTTP要求では既定ドメインまたはカスタムドメインを使う |
| 送信IPアドレス | Function AppからDB、API、Key Vaultなど外部リソースへ接続する場合 | Azure portal、Azure CLI、Azure PowerShell | どの送信IPが使われるかは事前に分からない。プランやスケールで変わる可能性がある |
Microsoft Learnでは、IPアドレスは個別の関数ではなくFunction Appに関連付けられ、HTTP要求で個別関数を呼び出すには受信IPではなくfunctionappname.azurewebsites.netの既定ドメインまたはカスタムドメインを使うと説明されています。(Microsoft Learn)
受信IPアドレスの確認方法
受信IPアドレスは、ローカルPCなどからnslookupで確認できます。
nslookup <APP_NAME>.azurewebsites.net<APP_NAME>にはFunction App名を入れます。カスタムドメインを使っている場合は、そのカスタムドメインに対してnslookupを実行します。公式情報では、Function Appは最初に単一の受信IPアドレスを使い、ConsumptionプランまたはPremiumプランではイベント駆動のスケールアウトにより、受信IPアドレスが追加される可能性があるとされています。(Microsoft Learn)
送信IPアドレスの確認方法
送信IPアドレスは、Azure portal、Azure CLI、Azure PowerShellで確認できます。2026年5月更新では、Azure portalでの確認手順が、Azure portalにサインインしてResource Explorerへ移動し、対象Function AppのJSONからoutboundIpAddressesとpossibleOutboundIpAddressesを確認する流れに更新されています。(GitHub)
Azure CLIでは、次のコマンドを使います。
az functionapp show \
--resource-group <GROUP_NAME> \
--name <APP_NAME> \
--query outboundIpAddresses \
--output tsvaz functionapp show \
--resource-group <GROUP_NAME> \
--name <APP_NAME> \
--query possibleOutboundIpAddresses \
--output tsvPowerShellでは、次のように確認できます。
$functionApp = Get-AzFunctionApp -ResourceGroupName <GROUP_NAME> -Name <APP_NAME>
$functionApp.OutboundIPAddress
$functionApp.PossibleOutboundIPAddressoutboundIpAddressesは現在Function Appで利用可能な送信IPの集合です。一方、possibleOutboundIpAddressesは、他の価格レベルへスケールした場合に使われる可能性があるIPも含みます。許可リストを作るときは、現在値だけでなく、将来的に使われる可能性がある範囲まで確認する必要があります。(Microsoft Learn)
送信IPを許可リストに入れるときの判断基準
Azure FunctionsからAzure SQL Database、外部SaaS、社内API、決済APIなどへ接続する場合、接続先のファイアウォールで送信元IPを制限することがあります。このとき、outboundIpAddressesだけを登録して終わりにすると、プランやスケール条件によっては障害の原因になります。
公式情報では、Function Appからの送信接続は利用可能な送信IPのいずれかを送信元として使い、特定の接続がどのIPを使うかは事前に分からないとされています。そのため、接続先サービス側ではFunction Appの送信IPをすべて許可する必要があります。(Microsoft Learn)
| 運用ケース | 推奨される考え方 | 注意点 |
|---|---|---|
| 小規模な検証環境 | outboundIpAddressesを確認して一時的に許可 | 本番と同じ安定性は期待しない |
| Dedicatedプランで価格レベルを固定 | possibleOutboundIpAddressesも含めて影響を確認 | 価格レベル変更時に送信IPセットが変わる可能性がある |
| Consumption/Premiumで動的スケール | 現在の送信IPだけに依存しない | 確定的な許可リストには向かない |
| 厳密な送信元固定が必要 | PremiumまたはDedicatedでVNet NAT Gatewayを検討 | ネットワーク設計とコスト確認が必要 |
| 受信・送信とも強く制御したい | App Service Environmentを検討 | Isolated層の設計・費用・運用体制が必要 |
特にConsumptionプランとPremiumプランでは、スケール時に新しい送信IP範囲が割り当てられる可能性があります。公式情報でも、これらのプランでは報告される送信IPだけを使って確定的な許可リストを作ることはできず、動的スケール中に使われ得るすべてのアドレスを含めるには、データセンター全体を許可リストに追加する必要があると説明されています。(Microsoft Learn)
ただし、データセンター全体のIP範囲を許可すると、許可範囲が広くなります。セキュリティレビューや監査で「なぜこの広い範囲を許可するのか」を説明できない場合は、NAT Gatewayなどで送信元を固定する設計に寄せたほうが現実的です。
IPアドレスが変わる主なタイミング
Azure FunctionsのIPアドレスは、常に固定されるものではありません。変更条件を知らないままデプロイ、証明書更新、プラン変更を行うと、外部サービスへの接続失敗やアクセス制限の誤動作につながります。
受信IPアドレスが変わる可能性がある操作
受信IPアドレスは、次のような操作で変わる可能性があります。
| 操作 | 起こり得る影響 |
|---|---|
| Function Appを削除し、別のリソースグループで再作成する | 新しい受信IPになる可能性がある |
| 同じリソースグループ・リージョンの最後のFunction Appを削除し、再作成する | 以前のIPを維持できない可能性がある |
| TLSバインドを削除する | 証明書更新作業などで受信IPが変わる可能性がある |
| Consumption/Premiumで運用する | 操作していなくても受信IPが変わる可能性がある |
公式情報では、Function Appの削除・再作成、同じリソースグループとリージョンの最後のFunction Appの削除後の再作成、TLSバインドの削除などが受信IP変更の条件として挙げられています。また、ConsumptionプランとPremiumプランでは、これらの操作をしていなくても受信IPが変わる可能性があります。(Microsoft Learn)
実務では、証明書更新時にTLSバインドを削除して作り直す運用が危険です。事前に影響範囲を洗い出し、DNS、WAF、監視、外部連携先の許可設定を確認してから作業する必要があります。
送信IPアドレスが変わる可能性がある操作
送信IPアドレスの安定性は、ホスティングプランによって異なります。
| プラン | 送信IPの考え方 |
|---|---|
| Consumption | 自動スケールにより、いつ変わってもおかしくない前提で考える |
| Premium | 自動スケールにより変わり得る。固定したい場合はVNet NAT Gatewayを検討 |
| Dedicated | 比較的制御しやすいが、価格レベル変更や受信IP変更につながる操作で変わる可能性がある |
| App Service Environment | 受信・送信の制御を重視する場合の選択肢 |
公式情報では、ConsumptionプランとPremiumプランでは自動スケールの挙動により送信IPがいつでも変わる可能性があるとされています。Dedicatedプランでは、受信IPを変える操作やApp Serviceプランの価格レベル変更により、利用可能な送信IPのセットが変わる可能性があります。(Microsoft Learn)
Dedicatedプランでは、StandardとPremium v2の間でスケール変更し、10分待ってから元に戻すことで、送信IPの変更を意図的に発生させる手順も示されています。ただし、本番環境でこれを行う場合は、接続先ファイアウォール、監視、ロールバック手順を準備してから実施すべきです。(Microsoft Learn)
静的な送信IPが必要な場合はNAT Gatewayを検討する
外部サービス側が「固定された送信元IPのみ許可」という条件を求める場合、Function Appに表示される送信IP一覧だけで運用するのはリスクがあります。特に金融系API、社内閉域API、IP制限付きSaaS、監査要件のあるバックエンドでは、送信元IPを安定させる設計が必要です。
公式情報では、Function Appの送信トラフィックを静的なパブリックIP経由に制御する方法として、Virtual Network NAT Gatewayが挙げられています。この構成はPremiumプランまたはDedicatedホスティングプランで利用できると説明されています。(Microsoft Learn)
設計時は、次の順序で判断すると迷いにくくなります。
| 判断項目 | 確認すべきこと |
|---|---|
| 固定IPが必須か | 接続先がIP制限必須なのか、認証・Private Link・VNet接続で代替できるのか |
| 現在のプランで対応できるか | Consumptionのままでよいのか、Premium/Dedicatedへ移行が必要か |
| 送信だけ固定したいか | 送信元固定だけならNAT Gatewayが候補 |
| 受信も送信も厳密に制御したいか | App Service Environmentを検討 |
| 運用負荷を許容できるか | サブネット、パブリックIP、ルーティング、監視、コストを管理できるか |
NAT Gatewayを使えば送信元IPを制御しやすくなりますが、万能ではありません。Function Appのホスティングプラン、VNet統合、サブネット設計、接続先の許可ルールを合わせて設計する必要があります。
Key Vault参照などで送信IPだけに依存しない
見落としやすいのが、Key Vault参照などのプラットフォームレベル機能です。公式情報では、Key Vault参照のような一部のプラットフォーム機能では、送信元IPがFunction AppのアウトバウンドIP一覧に含まれない場合があり、対象リソース側で特定IPだけに依存する構成は避けるべきだと説明されています。その代わりに、仮想ネットワーク統合を使い、トラフィックをネットワーク経由でルーティングすることが推奨されています。(Microsoft Learn)
つまり、アプリケーションコードから外部APIへHTTP接続する通信と、Azureプラットフォームが内部的に行う参照・取得の通信を同じものとして扱わないことが重要です。
よくある失敗例は次の通りです。
| 失敗例 | なぜ問題になるか | 対策 |
|---|---|---|
outboundIpAddressesだけをKey Vault側で許可する | プラットフォーム機能の送信元が一致しない可能性がある | VNet統合やKey Vault側のネットワーク設定を再確認する |
| 検証環境では動いたため本番も同じ設定にする | 本番のスケールやプランが異なるとIPが変わる | 本番プランでpossibleOutboundIpAddressesまで確認する |
| 接続先ごとに許可IPの管理表がない | 変更時にどの外部サービスへ連絡すべきか分からない | DB、SaaS、社内APIごとに許可リスト管理表を作る |
受信アクセスを制限するならAccess Restrictionsを使う
Azure Functionsへの受信アクセスをIPアドレスや仮想ネットワークで制限したい場合は、App ServiceのAccess Restrictionsを使います。Access Restrictionsでは、IPアドレスやAzure Virtual Networkサブネットを含む許可・拒否リストを優先順位付きで定義でき、ルールに一致しないアクセスを制御できます。Azure Functionsを含むApp Serviceホスト型ワークロードで利用できます。(Microsoft Learn)
管理画面だけでなく、運用ルールとして次の点を決めておくと安全です。
| 項目 | 決める内容 |
|---|---|
| 管理者アクセス | 社内固定IP、VPN、踏み台環境のどこから許可するか |
| アプリ利用者アクセス | 全公開か、特定ネットワーク限定か |
| WAFやFront Doorとの関係 | 直接Function Appへ来るアクセスを許可するか、前段サービス経由に限定するか |
| 緊急時の解除手順 | 誤設定で403になった場合に誰が復旧するか |
| ルール数 | 将来的に512ルール制限に近づかないか |
Access Restrictionsでは、1つ以上のルールがある場合、暗黙的な拒否が最後に存在します。また、ルールにより許可されない要求にはHTTP 403が返されます。ルール数には512の制限があるため、多数の個別IPを登録する設計では、Azure Front Door、Application Gateway、WAFなどの前段サービスも検討すべきです。(Microsoft Learn)
Consumptionプラン利用者は移行方針も確認する
IPアドレスの話だけを見ると、「今のConsumptionプランの送信IPを許可すればよい」と考えがちです。しかし、Azure Functions全体のホスティング方針も確認しておくべきです。
Microsoft Learnのホスティングオプションでは、Consumptionプランはレガシーのホスティングプランと位置づけられ、新しいサーバーレスFunction AppではFlex Consumptionプランの利用が案内されています。既存のConsumptionプランアプリについても、Flex Consumptionプランへの移行が推奨されています。(Microsoft Learn)
ただし、IPアドレス管理の観点では、移行先を「新しいから」という理由だけで決めないことが大切です。次の条件を合わせて確認してください。
| 確認項目 | 管理者・開発者が見るべきポイント |
|---|---|
| OS要件 | Windows依存のランタイムやPowerShellモジュールがあるか |
| ネットワーク要件 | VNet接続、固定送信IP、Private Endpointが必要か |
| スケール要件 | 突発的なイベント増加にどこまで対応するか |
| コスト | 常時起動、Always Ready、NAT Gateway、ASEの費用を含めて試算したか |
| 外部連携 | 接続先のIP許可リスト変更にどれだけ時間がかかるか |
Consumptionプランではインスタンスが着信イベント数に応じて動的に追加・削除され、Linux Consumptionプランには提供終了に関する案内もあります。既存環境では、IPアドレスの許可リスト更新と合わせて、ランタイム、OS、ホスティングプランの移行計画を同じタイミングで確認するのが効率的です。(Microsoft Learn)
デプロイ前に確認したいチェックリスト
Azure FunctionsのIPアドレス変更で障害を起こさないためには、デプロイ前に次の項目を確認します。
| チェック項目 | 確認方法 |
|---|---|
| Function App名とリージョン | Azure portalまたはAzure CLIで確認 |
| 現在のホスティングプラン | Consumption、Premium、Dedicated、ASEなどを確認 |
| 受信IP | nslookup <APP_NAME>.azurewebsites.net |
| 現在の送信IP | outboundIpAddressesを確認 |
| 将来使われ得る送信IP | possibleOutboundIpAddressesを確認 |
| 接続先の許可リスト | DB、SaaS、社内API、Key Vaultなどを洗い出す |
| IP変更を伴う作業 | プラン変更、TLSバインド変更、削除・再作成がないか確認 |
| 固定IP要件 | NAT GatewayまたはASEが必要か判断 |
| 受信制限 | Access Restrictions、WAF、Front Doorの設計を確認 |
| ロールバック | 許可リストの戻し方、DNS、監視アラートを準備 |
開発者だけで完結しない点にも注意が必要です。外部SaaSのIP許可リスト変更は、セキュリティ部門やベンダー側の申請が必要なことがあります。Azure側のデプロイ予定日だけでなく、接続先の設定反映リードタイムも含めてスケジュールを組みましょう。
すぐに取るべき対応
まず、対象のFunction AppについてoutboundIpAddressesとpossibleOutboundIpAddressesを確認し、現在の許可リストがどちらに基づいているかを棚卸ししてください。次に、ConsumptionまたはPremiumで運用しているアプリは、スケール時にIPが変わる前提で、データセンター範囲の許可、NAT Gateway、Dedicatedプラン、App Service Environmentのどれが適切かを判断します。
最後に、IPアドレスを「一度設定したら終わり」の項目として扱わないことが重要です。プラン変更、証明書更新、Function Appの再作成、移行作業のたびに見直す運用項目として管理表に入れておけば、Azure Functionsのネットワーク障害をかなり減らせます。
コメント