Azure AI Playgroundで405 Not Allowedが突然発生する原因と対処法（Azure AI FoundryのLlama/Phi/DeepSeek）

Azure AI FoundryのPlaygroundで、LlamaやPhi、DeepSeekなどのサードパーティモデルだけが突然「405 Not Allowed」になり、APIでもポータルでも実行できない――そんなときは、コード修正より先に原因の切り分けとサポート連携が重要です。本記事では判断ポイントと実務的な対処を整理します。

現象の整理：Azure AI Playgroundで「405 Not Allowed」が急に出るパターン

まずは症状を言語化しておくと、調査もサポートへの共有も一気にスムーズになります。今回のポイントは「突然」「Playgroundでも再現」「サードパーティモデルのみ」という3点です。ブラウザから実行するAzure AI Playground（ポータル上のPlayground）でも同じHTTP 405が返る場合、アプリ側の実装だけを疑って時間を溶かさないことが大切です。

観点	典型的な状況	この状況が示唆すること
発生タイミング	直前まで動いていたのに、ある時刻から一斉に失敗	利用者側のコード変更より、プラットフォーム側の変更・障害の可能性が上がる
再現箇所	アプリ（SDK/REST）でも、Azure AI Playgroundでも同じエラー	リクエスト生成のバグより、サービス側のルーティング/ゲートウェイ/モデル提供経路の問題が疑われる
影響モデル	Llama / Phi / DeepSeek など「サードパーティ/カタログ系」だけ失敗。OpenAI系は成功	モデル提供方式ごとのバックエンド差異（経路・ゲートウェイ・提供元）が切り分けの軸になる

なお「405 Not Allowed」はHTTPの意味としては「そのHTTPメソッドは許可されていない（例：GETはOKだがPOSTは不可）」ですが、Azure AI Foundry/Azure AI Playgroundの文脈では、“あなたのPOSTが間違っている”とは限らない点が重要です。特に、同じ操作が昨日まで通っていたのに突然405になった場合、まずは状況証拠を積み上げていきます。

「405 Not Allowed」が出る理由の考え方：作り方より“経路”を疑う

HTTP 405は、アプリケーションそのものが「その操作は受け付けない」と判断したときにも、APIゲートウェイ（例：API Management相当の層）が「そのルートではそのメソッドは許可しない」と判断したときにも返り得ます。Azure側のゲートウェイで返る場合、レスポンスヘッダーに相関ID（例：apim-request-id）が付与されることがあります。

今回のようにAzure AI Playgroundでも同様の405が返る場合、少なくとも次の可能性が高まります。

• サービス側のルーティング不整合（特定モデル群の経路だけ別ゲートウェイに流れる／ポリシー変更で弾かれる）
• モデル提供基盤の一時障害（特定リージョンや特定提供元だけ落ちている）
• プラットフォーム側のロールアウト影響（ポータル/Playgroundの呼び出し先が切り替わり、メソッドやパスの整合が崩れた）

もちろん一般論として、405は「エンドポイントURLやAPIバージョン、パスが合っていない」場合にも起きます。ただし、その場合はPlaygroundは通常は正常に動きやすい（ポータルが正しい呼び出しを行う前提）ため、Playgroundでも再現するかは強力な判断材料になります。

ステータスコード	よくある原因	今回のケースでの優先度	まず確認したいこと
401 / 403	キー・RBAC・権限不足、IP制限、CORS/ポリシー	中	キーの有効性、アクセス許可、ネットワーク制限
404	デプロイ名/パス違い、リソース違い	中	デプロイ名（展開名）と呼び出し先の一致
405	メソッド不一致、ルーティング/ゲートウェイ設定、提供経路の不整合	高	Playgroundでも再現するか、相関ID（apim-request-id）の有無
429	レート制限、クォータ枯渇	低〜中	制限値、利用量、リトライ/バックオフ
5xx	サービス障害、依存基盤障害	中〜高	サービス正常性、リージョン状況

原因切り分け：ユーザー側でできるチェック項目

「Azure側の不具合が濃厚」と思える状況でも、サポートに投げる前に数分でできる切り分けをしておくと、原因特定が早くなります。ポイントは“再現性”と“影響範囲”を定量化することです。

Playgroundでの再現手順を固定する

• 同じプロンプト、同じパラメータ（temperature、max_tokens等）で再実行し、毎回405になるか確認する
• モデルを切り替え、OpenAI系モデルは成功しサードパーティモデルは失敗することをスクリーンショットで残す
• 可能ならブラウザの開発者ツール（Network）でレスポンスヘッダーを確認し、相関IDが取れるか把握する

モデル/デプロイ単位で影響範囲を切る

「サードパーティモデル全部がダメ」に見えても、実際は“特定のデプロイだけ”や“特定の提供元だけ”が壊れていることがあります。サポートがログを追うときは、モデル名よりデプロイ名（展開名）が鍵になります。

確認項目	見るべきポイント	判断できること
デプロイ名ごとの再現	「llama-3-70b」などのモデル名ではなく、実際のデプロイ名（例：prod-llama、test-phi等）で整理	“一部だけ”の不具合か、“系統全体”の不具合か
リージョン差	同一サブスクリプションで別リージョンのAzure AIリソースがあるなら同操作を試す	リージョン障害か、機能全体の障害か
実行経路差	Playground / SDK / REST（curl等）で同じ結果になるか	クライアント実装起因か、プラットフォーム起因か

ネットワークやプロキシの影響を素早く除外する

「突然発生」「特定ドメインだけ失敗」というとき、社内プロキシやセキュリティ製品の更新が原因になるケースもあります。特にサードパーティモデルは、OpenAI系とは異なるホスト名・経路を通ることがあるため、許可/遮断の差が出ることがあります。

• 可能なら別ネットワーク（テザリング等）でPlaygroundを試し、結果が変わるか確認する
• レスポンスに社内プロキシ由来のヘッダーや独自エラーページが混ざっていないか確認する
• ただし、今回のようにapim-request-idが返っているなら、少なくともAzure側ゲートウェイまでは到達している可能性が高い

結論として最も可能性が高い原因：Azure側バックエンド／プラットフォームの問題

提示された状況（突然発生、サードパーティモデルのみ、Playgroundでも再現、OpenAI系は正常）からは、ユーザーの設定ミスやコード不具合よりも、Azure AI Foundryのモデル提供基盤側の問題を疑うのが合理的です。サードパーティモデル群は、提供元・推論基盤・ゲートウェイ・利用制約がOpenAI系と異なることがあり、その差分が“サードパーティだけ壊れる”現象につながりやすいためです。

また「405」という結果が返っている点も重要です。完全に到達できない（DNSやTLSレベルの問題）ならタイムアウトや接続エラーになりやすく、権限問題なら401/403になりやすい一方で、405は“到達した上でメソッド/ルートが受理されない”ことを示唆します。つまり、ルーティングやAPIポリシーの整合性が崩れている可能性が高い、と読むことができます。

推奨される対応：Azureサポートへの問い合わせが最短ルート

この種のプラットフォーム起因の不具合は、利用者側で根本修正できないことがほとんどです。対処としては、Azureサポートチケット（サポート要求）を起票し、Azure側でログ追跡してもらうのが最短です。

チケット起票時に、サポートが調査に必要としやすい情報を最初から揃えておくと、やり取りの往復が減り、復旧までの時間も短くなります。

サポートに渡すべき情報

項目	例	なぜ必要か
相関ID（要求ID）	apim-request-id: cf2a9587-815a-497f-82bf-5d084e24603e	Azure側ログをピンポイントに追跡できる
リージョン	Japan East / East US など	リージョン障害・基盤差を切り分ける
影響を受けるデプロイ名一覧	例：prod-llama-3-70b、prod-phi など	モデル名ではなく“デプロイ”に紐づく実体を特定する
発生時刻（タイムゾーン付き）	例：2025-12-12 10:15 JST	ロールアウト/障害時刻との突合ができる
実行経路	Playground / REST / SDK（言語・バージョン）	クライアント要因を除外しやすい
エンドポイントとパス	（ポータルに表示される呼び出し先）	ルーティング/パス不一致を検証できる
レスポンス本文（マスク済み）	405時の本文やエラーコード	どの層が返しているか推測できる

サポートチケットに貼り付けやすいテンプレート

以下の形式でまとめると、そのままサポート依頼に転用できます（APIキーなどの秘匿情報は絶対に載せないでください）。

【事象】
Azure AI Foundry / Azure AI Playgroundで、サードパーティモデル（Llama, Phi, DeepSeek等）の実行が突然すべてHTTP 405 Not Allowedとなる。
OpenAI系モデルは同一環境で正常。

【再現手順】
1) Azure AI Playgroundで対象デプロイを選択
2) 任意のプロンプトで実行
3) HTTP 405 Not Allowed

【影響範囲】
- 影響あり：サードパーティモデルのデプロイ（デプロイ名：XXXX, YYYY, ZZZZ）
- 影響なし：OpenAI系モデルのデプロイ（デプロイ名：AAAA）

【時刻・リージョン】
- 発生開始：YYYY-MM-DD HH:MM (TZ)
- リージョン：Japan East（例）

【相関ID】
- apim-request-id: cf2a9587-815a-497f-82bf-5d084e24603e

【補足】
- クライアント（SDK/REST）からも同様に405を確認
- 直前に設定変更やコード変更はなし
- 可能ならレスポンスヘッダー一式（秘匿情報はマスク）も添付

Azureサービス正常性（Service Health）の確認も同時に行う

サポートを待つ間に、Azureポータルの「サービス正常性（Service Health）」で、対象リージョンにAzure AI Services / Azure AI Foundry関連の障害やアドバイザリが出ていないかを確認しておくと、社内説明や復旧見込みの判断に役立ちます。

• Azureポータルで「サービス正常性」を開く
• リージョンを対象のものに絞り込む（例：Japan East）
• 対象期間（発生開始時刻付近）に関連する通知がないか確認する

一時回避策：業務影響を止めるための現実的な手段

根本原因がプラットフォーム側の場合、復旧まで“待つ”以外にできることがないこともあります。とはいえ、運用現場では業務影響を抑える工夫が必要です。実務で使いやすい一時回避策を整理します。

回避策	メリット	注意点	向くケース
OpenAI系モデルへ一時切り替え	同一リソース/同一アプリで実装変更が最小になりやすい	精度・コスト・出力方針が変わる。プロンプト調整が必要な場合あり	業務を止められない／最低限の応答が必要
別リージョンのAzure AIリソースで再現確認	リージョン障害なら回避できる可能性がある	データ所在・レイテンシ・コスト・ガバナンスに注意	冗長構成を許容できる／BCPとして切り替えたい
機能を段階的に縮退（フォールバック）	“全面停止”を避けられる（要約→キーワード抽出に落とす等）	UXが下がる。縮退時の説明文言も準備が必要	品質より可用性を優先したい
キューイングして後処理に回す	オンライン処理を守り、復旧後にまとめて処理できる	405はリトライで直らないことも多い。サーキットブレーカが有効	バッチ処理が許容される／遅延OK

特におすすめなのは、アプリ側に“モデルの切り替えスイッチ”を用意しておくことです。具体的には、環境変数やFeature Flagで「通常はサードパーティモデル」「障害時はOpenAI系」へ即座に切り替えられる設計にしておくと、今回のような突発障害への耐性が上がります。

ログの残し方：サポート調査を加速する実務ノウハウ

サポート側が最も困るのは「いつ」「どのデプロイに」「どんなリクエストを投げて」「どんなレスポンスが返ったか」が曖昧な状態です。逆に言えば、ここを押さえるだけで調査は進みやすくなります。

最低限保存したいログ項目

保存するもの	具体例	ポイント
発生時刻	2025-12-12 10:15:23 JST	タイムゾーンを必ず付ける
呼び出し先	ベースURL、パス、クエリ（api-version等）	画面/コードで参照したものをそのまま残す
デプロイ名	prod-llama-3-70b 等	モデル名ではなくデプロイ名が重要
HTTPメソッド	POST	405はメソッド起因と誤解されやすいので明記する
レスポンスヘッダー	apim-request-id、request-id等	秘匿情報はマスクしつつ、相関IDは残す
レスポンス本文	エラーコード、メッセージ	可能なら原文を添付（個人情報・機密は除去）

再現用のシンプルなcurl例（ひな形）

Playgroundで再現したら、同じデプロイに対して最小のRESTリクエストでも再現するか確認しておくと、調査の裏付けになります。以下はイメージです（実際のエンドポイントはポータル表示に合わせて置き換えてください）。

curl -v -X POST "https://{YOUR_ENDPOINT}/{PATH}" \
  -H "Content-Type: application/json" \
  -H "api-key: {YOUR_KEY}" \
  -d '{
    "messages": [
      {"role": "user", "content": "hello"}
    ],
    "temperature": 0.2
  }'

• -v を付けるとヘッダーが取れるため、apim-request-id などの相関IDを拾いやすくなります。
• APIキーやトークンは、チケットや社内共有に貼る前に必ずマスクしてください。

「ユーザー側で無理に直そうとしない」が近道になる理由

Playgroundでも同じ405が出ている場合、設定を大きくいじったり、SDKの差し替えを繰り返したりすると、かえって状況証拠が散らかって原因追跡が難しくなります。特に以下の行動は“やりがち”ですが、優先度は低めです。

• api-versionを片っ端から変える（事象の再現性が崩れる／偶然通っても恒久対策にならない）
• プロンプトやパラメータを大きく変更する（405は多くの場合入力内容ではなくルート/メソッド問題）
• キーの再発行を繰り返す（権限系の症状なら401/403になりやすい）

もちろん、明確に「POSTではなくGETになっていた」「エンドポイントを間違えていた」などが判明した場合は修正すべきです。ただし今回の前提（直前まで正常、Playgroundでも失敗、特定モデル群のみ）では、“自分側の変更で直す”より“証拠を揃えてエスカレーションする”方が成果につながりやすいです。

よくある混同：モデル名とデプロイ名は別物

サポートや社内連携で混乱しやすいのが、「Llama-3-70B」などのモデル名と、Azure上で実際に呼び出すデプロイ名（展開名）の取り違えです。調査やルーティングはデプロイ単位で行われることが多いため、会話の最初からデプロイ名を揃えておくとやり取りが速くなります。

用語	例	どこで使う
モデル名	Llama / Phi / DeepSeek など	選定や比較、要件定義
デプロイ名（展開名）	prod-llama-3-70b、dev-deepseek 等	API呼び出し、ログ追跡、サポート調査

再発に備える設計・運用のヒント

Azure AI Foundryのように複数のモデル提供経路（OpenAI系、サードパーティ/カタログ系など）を使い分ける構成では、障害の出方も“経路ごと”に変わります。次のような備えをしておくと、突発的な405のような事象でも影響を最小化できます。

アプリ側のフォールバック設計

• 一次モデル／二次モデルを決めておき、特定ステータス（405/5xxなど）で自動切り替えする
• 切り替え条件は“即時切り替え”ではなく、一定回数失敗したら切り替える（サーキットブレーカ）
• フォールバック時はユーザーに「一時的に簡易モードで応答」などの説明を出せるようにする

監視とアラートの作り方

監視対象	具体例	アラートの意図
HTTPステータス比率	405の割合が急増、特定デプロイだけ増加	“突然の壊れ方”を早期検知する
モデル別の成功率	OpenAI系は99%維持、サードパーティだけ低下	経路差の障害を切り分ける
相関IDの保存	apim-request-idをログに残す	サポート調査を高速化する
リージョン別の遅延	Japan Eastのみ遅延/失敗	リージョン障害の早期発見

運用手順の標準化

• 「Playgroundで再現 → スクリーンショット → 相関ID採取 → 影響デプロイ整理 → サポート起票」という流れを手順化する
• “変更していないのに壊れた”ときほど、変更履歴（デプロイ更新、ポリシー、ネットワーク）を時系列で整理する
• 障害報告用に、平常時から“正常時のレスポンス”も保存しておく（差分が出せる）

まとめ：Playgroundでも405なら、証拠を揃えて早めにエスカレーション

Azure AI Playgroundでサードパーティモデルだけが突然「405 Not Allowed」になり、OpenAI系モデルは動く――このパターンは、利用者側のコード修正よりも、Azure側のモデル提供経路（バックエンド/ルーティング/ゲートウェイ）の問題である可能性が高い状況です。最短で前進するためには、相関ID（apim-request-id）・リージョン・影響デプロイ名を揃え、Azureサポートへ早めに問い合わせるのが有効です。

同時に、業務影響を抑えるための一時回避（OpenAI系への切り替え、別リージョンの検証、縮退運用）を準備しておくと、復旧までの時間を“耐えられる形”にできます。今回の事象をきっかけに、複数モデル運用のフォールバック設計と監視を整備しておくと、次に同様のトラブルが起きても落ち着いて対処できるはずです。