Japan Eastでgpt-5などReasoningモデルでweb_search_previewを使用すると、ストリームの完了処理が遅くなる

Question

Japan Eastでgpt-5などReasoningモデルでweb_search_previewを使用すると、ストリームの完了処理が遅くなる

津﨑　友一郎 5

Japan Eastでgpt-5などReasoningモデルでweb_search_previewを使用すると、ストリームの完了処理が遅くなる事象に出くわしました。

web検索と生成AIによるテキストの回答は問題なく進みますが、最後の最後で、終了処理が実行されずに数十秒待つ必要がある状態です。

他のリージョンですが、EastUS2では再現しませんでした。

リージョンに違いがあるように感じられました。

Naveena Patlolla 9,665 評価のポイント Microsoft 外部スタッフモデレーター

2026-02-14T12:09:35.47+00:00

Hi 津﨑　友一郎
東日本リージョンで GPT-5 推論モデルを使用した web_search_preview 機能を使用すると、ストリームの完了時間が遅くなるようです。米国東部 2 リージョンではこの遅延は発生していないため、リージョンの問題と考えられます。

この問題を解決するために、以下の点を検討することをお勧めします。

バックエンドログの分析：Azure ポータルの Azure Monitor セクションでログを確認してください。応答時間に影響を与える可能性のある、リクエスト量が多いパターンや時間帯がないか確認してください。

負荷分散の評価：リージョンの負荷によって遅延が発生している場合は、負荷分散を設定す
ることで、リクエストをノード間でより均等に分散できる可能性があります。

複数リージョンへのデプロイ：可能であれば、ソリューションを複数のリージョンにデプロイすることを検討してください。これにより、特定のリージョンで発生するパフォーマンスの問題を軽減できます。

パフォーマンスメトリックの監視：Azure Monitor でパフォーマンスメトリックを継続的に確認してください。これにより、特定の時間帯にレイテンシが一貫して高いかどうかを特定し、スケーリングや構成の調整について情報に基づいた意思決定を行うことができます。

ストリーミングモードの活用: まだ使用していない場合は、モデルリクエストのストリーミングを有効にしてください。これにより、コンテンツが完全に準備されていない場合でも、レスポンスがすぐに受信できるようになります。

この問題はリージョン固有の問題であると思われるため、東日本におけるキャパシティの問題やバックエンドサービスの安定性に関連している可能性があるため、Azure に直接サポートケースを開いて詳細を調査することも有効です。

お役に立てれば幸いです。実装の詳細やその他の具体的な情報をお持ちでしたら、ぜひお知らせください。

フォローアップの質問:

Azure Monitor で、遅延に関する洞察が得られる可能性のあるバックエンドログを確認しましたか？

現在、東日本リージョンではどのような負荷を処理していますか？米国東部 2 リージョンよりも大幅に高い負荷ですか？

現在、デプロイメントで負荷分散やスケーリング戦略を実施していますか？

レスポンスにストリーミングモードを使用してみましたか？使用した場合、体感パフォーマンスは向上しましたか？

参照ドキュメント:
Performance and Latency in Azure OpenAI

Understanding Costs Associated with Provisioned Throughput
Manas M 17,270 評価のポイントモデレーター

2026-02-16T10:23:13.9066667+00:00
こんにちは**、津崎祐一郎**

こんにちは。

私は自分の側で最小限のレプリケーションを選び、日本東部地域(新しいファウンドリーUIから)でもウェブ検索の遅さを観察できました。

モデル構成で6000トークンで150万TPMで約12〜16秒です。

サポートチケット作成のリンクをプライベートメッセージで共有しておき(製品グループにエスカレーションするため)

サポートチケット作成時に詳細を添付して、正しく再現できるようにしてください。

最大TPM

FoundryのリソースID

仮想ネットワークの存在。

プロキシやファイアウォールでAzure URLのホワイトリスト化について。

サンプルプロンプトとプロンプトのサイズ

ご意見ありがとうございます。
Manas M 17,270 評価のポイントモデレーター

2026-02-17T09:30:00.1433333+00:00

こんにちは**、津崎祐一郎**

プライベートメッセージでご要望いただいたご意見を、優先順位付けと関連サービスエリアオーナーへのエスカレーションをまだお待ちしています。

すでに社内製品グループに到達しており、上記の観察で同様のことをしています。

ありがとうございます。

1 件の回答

お客様の回答

Manas M 17,270 評価のポイントモデレーター

2026-02-16T10:23:13.9066667+00:00

こんにちは**、津崎祐一郎**

こんにちは。

私は自分の側で最小限のレプリケーションを選び、日本東部地域(新しいファウンドリーUIから)でもウェブ検索の遅さを観察できました。

モデル構成で6000トークンで150万TPMで約12〜16秒です。

サポートチケット作成のリンクをプライベートメッセージで共有しておき(製品グループにエスカレーションするため)

サポートチケット作成時に詳細を添付して、正しく再現できるようにしてください。

最大TPM

FoundryのリソースID

仮想ネットワークの存在。

プロキシやファイアウォールでAzure URLのホワイトリスト化について。

サンプルプロンプトとプロンプトのサイズ

ご意見ありがとうございます。
Manas M 17,270 評価のポイントモデレーター

2026-02-17T09:30:00.1433333+00:00

こんにちは**、津崎祐一郎**

プライベートメッセージでご要望いただいたご意見を、優先順位付けと関連サービスエリアオーナーへのエスカレーションをまだお待ちしています。

すでに社内製品グループに到達しており、上記の観察で同様のことをしています。

ありがとうございます。

Answer 1

Manas M 17,270 モデレーター

Hi 津﨑　友一郎

Could you share your observation in East US and Japan East. As per my trials, Japan East looked bit slower but looks Ok to operate (27 second in Japan East 3334 token, 20 second 2755 token in East US)

Considering the fact, we are using GPT 5 reasoning models, with streaming response, response time look reasonable to me as per last experience with product group on this.

Confirmed with product group.

If you have any counter observation with respect to prompt size and TPM configuration. Please share the details requested via private message.

Thank you for using Azure Services.

Manas M 17,270 評価のポイントモデレーター

2026-02-19T10:59:57.1733333+00:00

Hi Yuichiro Tsuzaki

If you found the above answer helpful, please take a minute to accept this answer.

Thank you.