🌟 はじめに

この記事は Microsoft Azure Tech Advent Calendar 2025 9 日目の記事です。
あくまでも現時点での公開情報と実際に動作させてみて分かったことベースでの記載となります。
将来的に動作が変わる可能性があることはご承知おきください。

⚡ TL;DR

App Service のリクエストタイムアウト 4 分は正確にはアイドルタイムアウト。
SSE なら 4分超えることができる。
LLM と連携するなら stream=true として SSE を使うのがいいんじゃないでしょうか。

⏱️ Azure App Service におけるリクエストタイムアウト

App Service ではアプリケーションが約 240 秒以内 (Windows アプリでは 230 秒、Linux アプリでは 240 秒) に応答が返されない場合 504 Gateway Timeout が発生します。

これは App Service と同じプラットフォームで提供される Azure Functions についても同様です。
また、この動作は良く知られた仕様で下記の FAQ にも記載があります。

アプリケーションのパフォーマンスに関する FAQ - Azure | Microsoft Learn

230 秒後に要求がタイムアウトになるのはなぜですか?
Azure Load Balancer には、4 分という既定のアイドルタイムアウト設定があります。この設定は一般的にウェブリクエストのための妥当な応答時間の制限です。そのため、アプリケーションが約 240 秒以内 (Windows アプリでは 230 秒、Linux アプリでは 240 秒) に応答が返されない場合、App Service はクライアントにタイムアウトを返します。

🧱 4分の壁を超える方法

そもそも HTTP要求に対してで 4 分かかるのを是とするかどうかはおいといて、4 分を超える処理を実現する方法を考えます。

🔍 一般的なワークアラウンド

このような場合の対策としては一般的には HTTP 202 応答を用いた「非同期要求-応答パターン」を用いることができます。また、それを実現するフレームワークとして Durable Functions などが提供されています。

🕵️ タイムアウトはどこで発生するのか

前述の FAQ に記載のとおり、この 4 分という制限は Azure Loadbalancer の構成に起因するものとなります。
HTTP応答自体は返却されているので、この 4 分を下回るように、App Service 側のミドルウェアが返却しているものと推測されます。Windows 環境と Linux 環境で10秒のずれがあることから下記のブログ記事を引用するとWorker 側のミドルウェア(Windows の場合は IIS、Linux の場合は Yarp + Kestrel)である可能性が考えられます。

App Service を構成する主要な要素とそれぞれの役割 - Japan PaaS Support Team Blog

次にロードバランサー側のドキュメントを見てます。以下のドキュメントに 4 分 というキーワードがあります。

ロードバランサーの TCP リセットおよびアイドルタイムアウトを構成する - Azure Load Balancer | Microsoft Learn

Azure Load Balancer の規則には、Load Balancer 規則、アウトバウンド規則、インバウンド NAT 規則に対して、4 分から 100 分の既定のタイムアウト範囲が設定されています。既定の設定は 4 分です。

ロードバランサーの仕組みとしては変更可能のようですが、App Service プラットフォームを構成するロードバランサー自体をユーザーが変更することはできないため、4分を変更することはできません。
ここで気になるのはロードバランサー側のドキュメントには アイドルタイムアウト と記載されています。

アイドルタイムアウトってことはパケットが通り続ければ接続は維持されることが見込まれます。

検証

以下の2つのAPIを用意してみました。

Server-sent events(SSE) を返す API

content-type は text/event-stream として指定回数だけイベントを返すやつ

単純に応答スループットが遅い API

content-type は text/plain; charset=UTF-8 だけど、応答が書き終わるまで指定秒スリープするやつ

検証結果

どちらの API も 250 秒かけて完了していることが確認できました。すなわち、4分というのはあくまでもアイドルタイムアウトで、その間パケットが流れていれば切断されて 504 になることはありません。

Server Sent Event といえば

ここでようやく昨今の LLM 連携アプリケーションに話がつながります。
LLMの応答も stream=true とすることで SSE で応答を得ることができます。

Streaming API responses - OpenAI API

Azure OpenAI の Microsoft Foundry Models v1 REST API リファレンス - Azure OpenAI | Microsoft Learn

App Service 等にデプロイしたアプリケーションから LLM の APIを呼び出し、応答を加工してさらにクライアントにSSEで返却することで LLM からの応答が巨大になっても大丈夫ということですね。

参考
Azure OpenAIの返答をAzure Functionを中継してStream(SSE)したい

また、最近サイドカーとしてで Phi-4 を SLM として動作させるチュートリアルがあります。
チュートリアル: SLM 拡張機能を使った Express.js チャットボット - Azure App Service | Microsoft Learn

ここでも SLM の API をストリームとして呼び出し、クライアントへも SSE で中継する実装となっています。

Phi-4 サイドカーちょっと試してみましたが SKU を渋ると応答がとてつもなく遅い¹のでストリーム化は必須と思われます。

Azure Container Appsはどうなの

Azure Container Apps についても同様の制限があります。

Azure Container Apps でのイングレス | Microsoft Learn

要求のタイムアウトは 240 秒です

ただし、Premium イングレスを用いることで上限を緩和することが可能です。

Azure Container Apps 環境でイングレスを構成する | Microsoft Learn

~~これは Azure Containe Apps の場合マネージドリソースとして専用のロードバランサーが用意されるため変更可能なものと推測できます。~~

そんなことなかった。。。
Premium イングレスでアイドルタイムアウトを変更してもマネージドリソース LB の負荷分散規則のアイドルタイムアウトは変わらず。

なので別の仕組みっぽい。

P2mv3 レベル以上が推奨されています。https://learn.microsoft.com/ja-jp/azure/app-service/tutorial-ai-slm-fastapi#how-does-pricing-tier-affect-the-performance-of-the-slm-sidecar ↩