Azure や Microsoft Entra ID を本番運用していると、「よくある落とし穴」で思わぬ時間を失うことがあります。本記事では Microsoft Q&A で繰り返し相談されている代表的なトラブルを「課題と解決策」に絞って整理し、現場目線のチェックポイントや CLI 例も交えてまとめます。
Azure トラブルシューティングの全体像
まずは、本記事で扱う代表的なトラブルを一覧で俯瞰します。気になる行だけブックマークしておくと、実際に障害が起きたときに素早く辿れます。
| カテゴリ | 主な課題 | 典型的な症状 | 主な解決策の方向性 |
|---|---|---|---|
| サブスクリプション | リソース作成が失敗する | 「Subscription … could not be found or is invalid」 | リソースプロバイダー(Microsoft.Web など)の登録・再登録 |
| Static Web Apps | デプロイ後に Azure 404 | トップページや特定パスが 404 | output_location・ビルド成果物・staticwebapp.config.json を再確認 |
| Static Web Apps | .NET SDK の食い違い | ローカルでは成功するが Oryx で失敗 | dotnet_version/global.json/事前ビルドで Oryx をコントロール |
| Front Door | URL 長・IP・リライト | 長い URL でエラー、ルールが意図通り動かない | URL 長さ制限・Service Tag・ルール構文の理解と設計整理 |
| Cosmos DB | リージョン移行 | 止めずに別リージョンへ移したい | リージョン追加 → 手動フェイルオーバー → 旧リージョン削除 |
| App Service & SQL | Private Endpoint 接続不可 | 突然接続エラーが発生 | WEBSITE_VNET_ROUTE_ALL / WEBSITE_DNS_SERVER / NSG / DNS を総点検 |
| セキュリティ | TLS / MFA / Default Outbound | TLS1.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など
ポータルからの登録手順
- Azure ポータルで対象サブスクリプションを開く
- 左メニューの「リソースプロバイダー」を選択
- 検索で
Microsoft.Webなど必要な名前空間を探す - 状態が “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 404 | staticwebapp.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 を意図したバージョンに合わせる方法
- 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"
global.jsonをアプリのルート直下に置く
{
"sdk": {
"version": "8.0.0",
"rollForward": "latestFeature"
}
}
- API / Web を事前ビルドして成果物のみデプロイする(
skip_api_buildなどを利用) - どうしても未サポートの 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 Door | AzureFrontDoor.Frontend | インターネットから Front Door のエッジまで |
| Front Door → オリジン | AzureFrontDoor.Backend | Front 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 が持つマルチリージョン機能を活かすのが王道です。
- 新リージョンを追加する(読み取り専用リージョンとして追加)
- 手動フェイルオーバーで書き込みリージョンを新側に切り替える
- 旧リージョンを削除する
アプリケーション側では、接続文字列に複数リージョンを指定するか、SDK が提供するリトライ機能を活用することで ほぼゼロダウンタイムで移行できます。リージョンによっては一時的に選択できない(キャパシティ制限中)こともあるため、事前にポータルで選択可能か確認しておくと安心です。
App Service から Azure SQL(Private Endpoint)に突然つながらなくなった
VNet 統合済みの App Service から、Private Endpoint 経由の Azure SQL に接続できていたのに、ある日突然つながらなくなることがあります。典型的には、次のようなポイントのどこかが変わっています。
| 観点 | チェック内容 |
|---|---|
| ルーティング | App Service の構成に WEBSITE_VNET_ROUTE_ALL=1 が設定されているか |
| DNS | WEBSITE_DNS_SERVER=168.63.129.16(Azure 既定 DNS)になっているか |
| NSG | Private 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 点が設定されていないことが多いです。
- セッションホストが Microsoft Entra ID 参加の場合、Host Pool の RDP プロパティに
targetisaadjoined:i:1;を追加する - 接続させたいユーザーに「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 対象外)を利用している
- 入力ファイルサイズが極端に大きい、あるいは一度に処理する量が多すぎる
対策としては、次の順番で切り分けるのが効率的です。
- 別リージョンや別モデル(安定版)で同じファイルを試す
- 入力画像の解像度やファイルサイズを抑える(PDF 分割や画像圧縮)
- 並列実行数を制限してスループットを下げてみる
- それでも改善しない場合は、時刻・リソース名・サブスクリプション 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 Apps | Oryx の SDK バージョン指定(dotnet_version / global.json)と output_location の整合を確認しているか | デプロイ後の Azure 404 やビルド失敗を防ぐ |
| Front Door | URL 長さ制限を設計に織り込んでいるか、Service Tag(AzureFrontDoor.Frontend/Backend)で IP 管理をシンプルにしているか | 長大 URL 起因のエラーと IP 管理の煩雑さを回避 |
| Private Endpoint | App 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」「コストと課金単位」といった観点で整理すると、原因に素早く辿り着きやすくなります。

コメント