Azure Functions のデプロイ成功なのに 404？原因は引き継ぎベンダーの requirements.txt だった話

小規模な改修をして、「ちょっと直しただけだし、久しぶりだけどサクッとデプロイして終わりやろ」と思って Azure Functions にデプロイしたときの話です。デプロイログは成功。エラーもなし。Azure Portal 上でも Function のコードはちゃんと見えている。

「よし、動いたな」と思って Function の URL を叩いたら──

404 Not Found

……は？ Function の PG は Azure Portal 上で普通に見えているのに？デプロイ成功って出てるのに？なんで Not Found？

しかも今回は 引き継ぎ前のベンダーが作った requirements.txt をそのまま使っていたため、「前に動いてたし大丈夫やろ」と完全に油断していました。冷静に考えれば分かる話なのですが、久しぶりのデプロイ＋小規模改修という油断が重なり、原因特定にかなり時間を使いました。

結論から言うと、requirements.txt のバージョン未指定がすべての元凶でした。

❗ Function のコードは見えているのに「Not Found」になる理由

Azure Functions はデプロイ時に Linux 上で pip install を実行します。 requirements.txt にバージョン指定がないと、最新バージョンを勝手にインストールします。

ここで問題が起きると、次のような流れになります。

つまり、

デプロイ成功 ≠ Function が正常に起動している

という落とし穴です。

特に以下のライブラリは最新バージョンが Azure の Linux 環境と相性が悪いことが多いです。

最新バージョンが Linux 用 wheel を提供していなかったり、依存関係が壊れていたりすると、Azure Functions のビルド環境では次のようなエラーが発生します。

そしてこのエラーは、デプロイログの最後の方にひっそりと埋もれているので気づきにくい。 Function 自体は起動できず、結果として Not Found になるわけです。

Azure Functions の pip install はローカルとは違う制約があります。

つまり、ローカルで動く＝Azure で動く ではありません。

引き継ぎ前ベンダーの requirements.txt が「とりあえず動く」状態のまま放置されていたのですが、Azure Functions のような環境ではそれが致命傷になります。久しぶりのデプロイだったこともあり、「前は動いてたし大丈夫やろ」と油断していたのも大きかったです。

最も安全なのは、ローカル環境で動いているバージョンをそのまま固定する方法です。

pip freeze > requirements.txt

これで Azure Functions とローカルの環境差がなくなり、デプロイが安定します。

また、不要なライブラリ（pywin32 など Windows 専用のもの）が混ざっている場合は削除しておくとさらに安全です。

Azure Functions に Python アプリをデプロイする際、 requirements.txt のバージョン未指定は本当に危険です。

ローカルでは動くのに本番で落ちる、デプロイ成功なのに Function が Not Found、という最悪のパターンを避けるためにも、バージョン固定は必須だと痛感しました。

同じような状況で焦る人の助けになれば嬉しいです。