Azureトラブルシューティング大全:Microsoft Q&Aから学ぶよくあるエラーと解決策

Azure や Microsoft Entra ID を本番運用していると、「よくある落とし穴」で思わぬ時間を失うことがあります。本記事では Microsoft Q&A で繰り返し相談されている代表的なトラブルを「課題と解決策」に絞って整理し、現場目線のチェックポイントや CLI 例も交えてまとめます。

目次

Azure トラブルシューティングの全体像

まずは、本記事で扱う代表的なトラブルを一覧で俯瞰します。気になる行だけブックマークしておくと、実際に障害が起きたときに素早く辿れます。

カテゴリ主な課題典型的な症状主な解決策の方向性
サブスクリプションリソース作成が失敗する「Subscription … could not be found or is invalid」リソースプロバイダー(Microsoft.Web など)の登録・再登録
Static Web Appsデプロイ後に Azure 404トップページや特定パスが 404output_location・ビルド成果物・staticwebapp.config.json を再確認
Static Web Apps.NET SDK の食い違いローカルでは成功するが Oryx で失敗dotnet_version/global.json/事前ビルドで Oryx をコントロール
Front DoorURL 長・IP・リライト長い URL でエラー、ルールが意図通り動かないURL 長さ制限・Service Tag・ルール構文の理解と設計整理
Cosmos DBリージョン移行止めずに別リージョンへ移したいリージョン追加 → 手動フェイルオーバー → 旧リージョン削除
App Service & SQLPrivate Endpoint 接続不可突然接続エラーが発生WEBSITE_VNET_ROUTE_ALL / WEBSITE_DNS_SERVER / NSG / DNS を総点検
セキュリティTLS / MFA / Default OutboundTLS1.2 未接続、MFA 無料化、送信経路の廃止対応暗号スイート・Security Defaults・NAT Gateway 等で明示的な制御
AVD & VM一般ユーザーが接続できない管理者だけサインイン可能targetisaadjoined:i:1 と Virtual Machine User Login ロール付与
Azure SQL / ADFバージョン/古いファイル削除サーバー版の上げ方が不明、xx日より古い条件式が難しいサービス層/互換レベルの理解、動的式で End に基準日時
Document Intelligence処理遅延・請求額が高いrunning のまま終わらない、請求が想定外モデル種別・リージョン状況・課金単位の再確認とサポート連携
学習・認定試験バウチャー未着イベント参加後もコードが届かないMicrosoft Credentials / Learning サポートへ問い合わせ

サブスクリプションとリソースプロバイダーの落とし穴

サブスクリプションが無効扱いでリソース作成できない

Static Web Apps など新しい種類のリソースを作ろうとしたときに、次のようなエラーで止まるケースがあります。

  • Subscription “xxxx” could not be found or is invalid
  • このサブスクリプションではこのリソースタイプは利用できません など

課金停止・無効化されたサブスクリプションの場合もありますが、実務で圧倒的に多いのは 対象リソースプロバイダーが登録されていないケースです。特に新サービスやプレビュー機能で起こりがちです。

チェックポイント

  • Azure ポータルでサブスクリプションを開き、「リソースプロバイダー」を確認
  • Static Web Apps なら Microsoft.Web、監視系なら Microsoft.Insights など

ポータルからの登録手順

  1. Azure ポータルで対象サブスクリプションを開く
  2. 左メニューの「リソースプロバイダー」を選択
  3. 検索で Microsoft.Web など必要な名前空間を探す
  4. 状態が “NotRegistered” なら「登録」をクリック

CLI での登録例

az provider register --namespace Microsoft.Web
az provider show --namespace Microsoft.Web --query registrationState

反映には数分かかることがあります。状態が Registered になったことを確認してから、再度リソース作成を試します。障害対応の現場では、影響範囲を考慮して よく使うリソースプロバイダーは事前に一括登録しておくと安全です。

Azure Static Web Apps でのよくあるトラブル

デプロイ後に Azure 404 が表示される

GitHub Actions などでデプロイは成功しているのに、ブラウザでアクセスすると Azure 404 になる場合、多くは「ビルド成果物のパスか設定」が原因です。

観点典型的な問題確認ポイント
output_locationビルドアウトプットの配置ミスワークフローファイルの output_location と実際のビルド出力フォルダーが一致しているか
アプリルートpublic/dist などが一階層ズレている静的ファイルが「index.html を含むルート」に置かれているか
ルーティングSPA の F5 リロードで Azure 404staticwebapp.config.json で navigationFallback が設定されているか
ビルド実はビルドが空(差分なし)GitHub Actions / Azure Pipelines のログでビルド結果とアップロード対象を確認

特に SPA(React / Vue / Angular など)の場合は、次のような navigationFallback 設定がないと、サブパスへ直接アクセスしたときに Azure 404 になりがちです。

{
  "navigationFallback": {
    "rewrite": "/index.html",
    "exclude": ["/assets/*", "/images/*", "/api/*"]
  }
}

Azure 404 に遭遇したら、まずはビルドアウトプットと staticwebapp.config.json を疑うのが近道です。

Oryx と .NET SDK バージョンが食い違う

GitHub Actions で actions/setup-dotnet を使っているのに、Azure Static Web Apps のビルドログでは別バージョンの .NET SDK が使われてしまうことがあります。これは、SWA のビルドエンジンである Oryx が別コンテナで動いているためです。

Oryx を意図したバージョンに合わせる方法

  1. SWA デプロイ Action で dotnet_version を明示する
- name: Build and deploy
  uses: Azure/static-web-apps-deploy@v1
  with:
    azure_static_web_apps_api_token: ${{ secrets.DEPLOY_TOKEN }}
    app_location: "src"
    api_location: "api"
    dotnet_version: "8.0.0"
  1. global.json をアプリのルート直下に置く
{
  "sdk": {
    "version": "8.0.0",
    "rollForward": "latestFeature"
  }
}
  1. API / Web を事前ビルドして成果物のみデプロイする(skip_api_build などを利用)
  2. どうしても未サポートの SDK の場合は、Oryx 側の対応を待つかホスト方式を見直す

「Runner に SDK を入れたのに効かない…」と悩んでいる場合は、Oryx とランナーの境界を意識して設定を整理すると解決に近づきます。

Azure Front Door 設計の注意点

URL 長さ制限(URL が長すぎるとエラーになる)

認証トークンや大量のクエリパラメーターを付与しているシステムでは、Front Door 経由で突然エラーになることがあります。Azure Front Door にはおおよそ次の制限があると考えて設計するのが安全です。

  • URL 全体:およそ 8,192 バイト
  • クエリ文字列部分:およそ 4,096 バイト

実務上の対策としては、次のような方針が有効です。

  • 長大なパラメーターは POST ボディ に移行する
  • JWT などのトークンを URL ではなくヘッダーで渡す
  • 一時的な ID のみをクエリに渡し、実データはバックエンドで参照する

Front Door をファイアウォールで許可する(IP アドレス/Service Tag)

Front Door 経由のアクセスだけをファイアウォールで許可したい場合、個別 IP を固定で登録するのは現実的ではありません。実務では Service Tag を利用するのが定石です。

方向Service Tag 名用途
クライアント → Front DoorAzureFrontDoor.Frontendインターネットから Front Door のエッジまで
Front Door → オリジンAzureFrontDoor.BackendFront Door から App Service や VM などのオリジンへの接続

NSG や Azure Firewall でこれらの Service Tag を許可しておくことで、毎週更新される IP リストを追いかける必要がなくなります。

URL リライトの構文と設計の考え方

Front Door のルールセットでは、「Source pattern」「Destination pattern」など独自の書き方に戸惑うことが多いです。「パス」と「クエリ」が分離されている点を押さえると理解しやすくなります。

  • パス:/foo/bar/{path} のようにプレースホルダーを使う
  • クエリ:条件やアクションの中でキー/値を指定する(?id={path} のようにパスをクエリに流用することも可能)

ただし、Front Door だけでは実現しづらい複雑な変換(パスの一部を分解して別のパスに埋め直す等)は、次のような役割分担がシンプルです。

  • Front Door:WAF / キャッシュ / 地理ルーティングに専念
  • App Gateway:より柔軟なリライトが必要な場合
  • アプリケーション:ビジネスロジックに依存するリダイレクトや URL 生成

「何でも Front Door で書き換える」のではなく、責務を分けると運用・トラブルシューティングのコストが下がります。

Cosmos DB・Azure SQL・Data Factory などデータ基盤のトラブル

Cosmos DB を別リージョンへ移したい(止めずに移行)

Cosmos DB アカウントを動かしたいが、停止は避けたい…。その場合は、Cosmos DB が持つマルチリージョン機能を活かすのが王道です。

  1. 新リージョンを追加する(読み取り専用リージョンとして追加)
  2. 手動フェイルオーバーで書き込みリージョンを新側に切り替える
  3. 旧リージョンを削除する

アプリケーション側では、接続文字列に複数リージョンを指定するか、SDK が提供するリトライ機能を活用することで ほぼゼロダウンタイムで移行できます。リージョンによっては一時的に選択できない(キャパシティ制限中)こともあるため、事前にポータルで選択可能か確認しておくと安心です。

App Service から Azure SQL(Private Endpoint)に突然つながらなくなった

VNet 統合済みの App Service から、Private Endpoint 経由の Azure SQL に接続できていたのに、ある日突然つながらなくなることがあります。典型的には、次のようなポイントのどこかが変わっています。

観点チェック内容
ルーティングApp Service の構成に WEBSITE_VNET_ROUTE_ALL=1 が設定されているか
DNSWEBSITE_DNS_SERVER=168.63.129.16(Azure 既定 DNS)になっているか
NSGPrivate Endpoint サブネットへの TCP 1433 が許可されているか
名前解決Private DNS ゾーン(privatelink.database.windows.net)の A レコードが正しいか

接続文字列は FQDN(xxxxx.database.windows.net)を使い、証明書検証を有効にするために TrustServerCertificate=False を指定するのが推奨です。ポータルの「Diagnose and solve problems」からネットワーク診断を実行すると、DNS や到達性の問題を自動チェックしてくれるので、まずここを確認すると効率的です。

Azure SQL Database の「サーバーバージョン」を上げたい

オンプレ SQL Server の感覚で、「Azure SQL Database のサーバー版を 2019 から 2022 に上げたい」と考えてしまうことがあります。しかし PaaS の Azure SQL Database では、サーバーバージョンの概念が異なり、サービスとして常に最新系です。

バージョンアップでやりたいことは、次のいずれかに分解できます。

  • 性能を上げたい → サービス層(DTU / vCore)、ストレージサイズ、Hyperscale / Serverless などの構成を見直す
  • 互換性レベルを上げたい → データベースの互換レベル(例: 140 → 150)を変更する
  • 機能を使いたい → 対象機能が Azure SQL Database に対応しているかをドキュメントで確認する

「サーバーバージョンを変える」というより、「サービスプランと互換レベルをチューニングする」と捉えると、設計の考え方が整理されます。

Data Factory で「xx 日より古いファイルを削除」したい

Azure Data Factory / Synapse の Delete アクティビティで「60 日前より古いファイルを削除」といった条件を動的に書く場合、Start/End の指定が分かりにくいという声が多いです。

ポイントは次の 2 点です。

  • 「xx 日より古い」は Start を空にして、End に基準日時を入れる
  • 日付計算は式(Expression)で行う

例:60 日より古いファイルを削除する場合の End の式

@formatDateTime(addDays(utcNow(), -60), 'yyyy-MM-ddTHH:mm:ssZ')

サブフォルダーも対象にする場合は Recursively を ON にします。また、Delete アクティビティのログを有効にしていると、「ログ用フォルダー/CSV」が追加で生成される点にも注意が必要です。削除対象から除外したい場合は、パスのフィルターを工夫しましょう。

ネットワーク・セキュリティ・認証まわりのトラブル

App Service が TLS 1.2 を受け付けない

App Service の設定で「最小 TLS バージョン 1.2」としているのに、TLS 1.2 のクライアントから接続できないことがあります。この場合、TLS バージョンというより 有効化している Cipher Suite の組み合わせが問題になっているケースがあります。

  • カスタムドメインのバインド設定を再確認する
  • 最低限必要な Cipher Suite が有効かを確認する
  • サーバー側・クライアント側の双方で使える暗号スイートをそろえる

実例では、Cipher を TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 などに変更することで解決したケースが報告されています。セキュリティ要件に応じて、より強いスイートに順次移行していくのが望ましいです。

Azure Virtual Desktop(AVD)で一般ユーザーがサインインできない

管理者だけ AVD に接続でき、一般ユーザーは認証エラーになる場合、次の 2 点が設定されていないことが多いです。

  1. セッションホストが Microsoft Entra ID 参加の場合、Host Pool の RDP プロパティに
    targetisaadjoined:i:1; を追加する
  2. 接続させたいユーザーに「Virtual Machine User Login」ロールを付与する

また、ユーザー側が Entra ID で正しくサインインしているか(UPN のドメインや既定ブラウザなど)も併せて確認しておくと、切り分けがスムーズです。

MFA を無料で有効にしたい(管理者・開発者向け)

App Service で公開しているアプリケーションの管理者や開発者に対して、多要素認証(MFA)を有効化したいが、できれば無料で済ませたい…という相談もよくあります。

この場合、Microsoft Entra ID の Security Defaults を有効化することで、追加費用なしでテナント全体に MFA を適用できます。ただし、次のような制約があります。

  • ユーザー・グループ単位で細かく制御できない(テナント全体が対象)
  • 条件付きアクセス(アクセス元 IP やアプリごとのポリシー)は利用できない

より柔軟な制御(特定グループだけ強制、特定条件のみ MFA など)が必要な場合は、Entra ID P1/P2 ライセンスを検討することになります。

Default Outbound Access(既定のインターネット送信)廃止への対応

Azure VM などからの「暗黙のインターネット送信経路」が段階的に廃止されることに伴い、「通知メールは来たが何をすればよいか分からない」という声も多く聞かれます。

ポイントは、これまで自動的に提供されていた送信経路を、明示的な経路に置き換えることです。

  • NAT Gateway をサブネットに割り当てる
  • ロードバランサーの Outbound 設定を構成する
  • パブリック IP を VM に明示的に割り当てる

どの VM が対象か分からない場合は、Azure Advisor の推奨事項で「Add explicit outbound method」を確認すると、影響を受けるリソースを洗い出しやすくなります。

Basic SKU Public IP の移行(特に VPN Gateway 利用時)

従来の Basic SKU の Public IP を Standard SKU に移行したいが、IP アドレスが変わるのでは…という不安もよく挙がります。特に VPN Gateway と組み合わせている場合は慎重になりがちです。

関連情報によると、標準/High Performance など一部のレガシー VPN Gateway SKU については、

  • 新 SKU への無停止自動移行が行われる
  • その後、ポータルからの手順で Basic IP から Standard IP へ移行する
  • SKU 移行に伴ってグローバル IP が変わらないことが FAQ で示されている

2026 年 1 月末を一つの目安とした猶予が言及されており、計画的な移行が推奨されています。とはいえ、実環境では構成や地域によって細部が異なるため、必ず最新の公式ドキュメントと自サブスクリプションの通知内容を確認した上で進めてください。

Document Intelligence と Microsoft Learn 関連のトラブル

Azure Document Intelligence が極端に遅い

Document Intelligence(旧 Form Recognizer)で、1 ページのドキュメントですら running のまま終わらない、という相談もあります。考えられる要因はおおまかに次の通りです。

  • 利用しているリージョンで一時的な障害や負荷が発生している
  • プレビュー中のモデル(SLA 対象外)を利用している
  • 入力ファイルサイズが極端に大きい、あるいは一度に処理する量が多すぎる

対策としては、次の順番で切り分けるのが効率的です。

  1. 別リージョンや別モデル(安定版)で同じファイルを試す
  2. 入力画像の解像度やファイルサイズを抑える(PDF 分割や画像圧縮)
  3. 並列実行数を制限してスループットを下げてみる
  4. それでも改善しない場合は、時刻・リソース名・サブスクリプション ID を添えてサポートへエスカレーション

Document Intelligence の請求額が想定より高い

メトリクス上の処理ページ数に比べて、実際の請求額が明らかに高いように見える場合、次のようなポイントを見落としていないか確認します。

  • 利用しているモデルの種類(Layout のみか、事前構築モデル/カスタムモデルか)
  • 高精度オプションや追加機能(署名検出など)を使っていないか
  • 再試行や失敗分にも課金されるモデルかどうか
  • コミットプラン(一定ページ数まで定額)の超過分が発生していないか
  • 通貨・税金・リージョンによる単価差

運用上は、「利用量メトリクス」+「請求のダウンロード(CSV)」をつき合わせて、どのモデル/どのリソースがコストを押し上げているかを特定することが重要です。疑問点は、その情報を添えてサポートに問い合わせると調査がスムーズになります。

Microsoft Learn の試験バウチャーが届かない

Azure Fundamentals(AZ-900)などの公式トレーニング参加後にも関わらず、割引コードや受験バウチャーが届かないケースも報告されています。Microsoft Q&A では個別のアカウント・バウチャー情報を確認できないため、基本的には次の窓口へ問い合わせることになります。

  • Microsoft Credentials / Learning サポート
  • 試験配信ベンダー(Pearson VUE / Certiport)のサポート

問い合わせの際は、トレーニングへの参加日時・アカウント情報・案内メールの有無・ジャンクメールフォルダーの確認状況などをまとめておくと、対応が早くなりやすいです。

横断チェックリスト:Azure トラブルを減らすための運用のコツ

最後に、ここまでの内容を踏まえた「日々の運用で意識しておくと、トラブルを減らせるチェックリスト」をまとめます。新しく環境を作るときや、構成レビューのタイミングで見直してみてください。

テーマチェック項目ねらい
リソースプロバイダー主要サービス(Microsoft.Web / Microsoft.Storage / Microsoft.Insights など)はサブスクリプションごとに事前登録しているか新サービス導入時の「サブスクリプションが無効」エラーを防ぐ
Static Web AppsOryx の SDK バージョン指定(dotnet_version / global.json)と output_location の整合を確認しているかデプロイ後の Azure 404 やビルド失敗を防ぐ
Front DoorURL 長さ制限を設計に織り込んでいるか、Service Tag(AzureFrontDoor.Frontend/Backend)で IP 管理をシンプルにしているか長大 URL 起因のエラーと IP 管理の煩雑さを回避
Private EndpointApp Service では WEBSITE_VNET_ROUTE_ALL / WEBSITE_DNS_SERVER を設定し、NSG・Private DNS を定期的にレビューしているか突然の接続不可や名前解決トラブルを抑止
ネットワーク送信Default Outbound Access 廃止に向け、NAT Gateway 等の明示的な送信経路を計画済みか将来的なインターネット接続断を防ぐ
認証・MFAまずは Security Defaults で全体を守り、必要に応じて P1/P2 と条件付きアクセスを検討しているか運用コストとセキュリティのバランスを最適化
コスト管理Document Intelligence など高単価サービスは、利用量メトリクスと請求 CSV を定期的に突合しているか想定外のコスト増を早期に検知

Azure 環境のトラブルシューティングは、一度経験したパターンを「ナレッジ化」できるかどうかで、次回の対応スピードが大きく変わります。本記事の内容を、自社 Wiki や Runbook、IaC テンプレート(Bicep/ARM/ Terraform)などに落とし込んでおくと、「同じことで何度も悩まされる」状況を減らすことができます。

今後新しいサービスや仕様変更が出てきたときも、「サブスクリプションとリソースプロバイダー」「ネットワーク経路と DNS」「認証・MFA」「コストと課金単位」といった観点で整理すると、原因に素早く辿り着きやすくなります。

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次