緊急度 A で寄せられるケースと、緊急対応・通常対応の判断ポイント

Published: feedback 共有

こんにちは、Power BI サポート チームの山崎です。

Power BI / Microsoft Fabric のお問い合わせでは、「緊急度Aで起票したほうがよいか」「通常対応でよいか」で迷われるケースが多くございます。本記事では、実際の傾向をもとに、判断の目安と起票時のポイントをわかりやすくご紹介いたします。

この記事の対象： Power BI / Fabric のケースを起票される、管理者・利用担当者の方

この記事を読むと、次の3点がわかります。

  • 緊急度Aにするべきか、通常対応が適切かを判断する目安
  • 緊急対応のまま進むケースと、通常対応へ切り替わるケースの違い
  • 初動を早めるために、起票時に添えるべき情報

重要

本記事は弊社公式ドキュメントの公開情報を元に構成しておりますが、

本記事編集時点と実際の機能に相違がある場合がございます。

最新情報につきましては、参考情報として記載しておりますドキュメントをご確認ください。

目次

1. はじめに ― この記事の目的

Power BI / Microsoft Fabric について、緊急度A（緊急） でお問い合わせいただくケースは日々数多く寄せられます。この記事は、これまでに寄せられたお問い合わせの傾向をもとに、「どんなご相談が緊急度Aで寄せられているか」「そのうち実際に緊急対応として進むのはどんなケースか」「なぜ通常対応に切り替わることがあるのか」を、お問い合わせいただく皆さまにお伝えするものです。

ねらいは、ご状況に合った緊急度を選び、最短で解決につなげること、そして 起票時に添えると初動が早くなる情報を把握すること の2点です。結果として、やり取りの行き違いや確認の往復が減り、よりスムーズな対応につながります。

2. 「緊急度A（緊急対応）」とは

サポートの緊急度にはいくつかの段階があり、緊急度A は「業務に重大な影響が出ており、迅速な対応を要する」状態に選ぶ 緊急対応 の区分です。緊急度Aで起票されると、担当エンジニアが優先的に着手し、まずお電話やTeams会議などで状況を確認します。

一方で 緊急度B・C（通常対応） は、営業時間内で、お客様の状況やご要望に沿った、より丁寧できめ細かな支援を行う区分です。「緊急ではないが相談したい」という内容は、通常対応のほうが、かえって相談内容に合った支援を受けやすいことも多くあります（具体的な対応時間や範囲は、ご契約内容・サポート窓口のご案内によります）。

警告

24時間対応としてのご案内は、原則 緊急度A（重大な影響） で起票され、かつ初動ヒアリングで条件を満たす場合に限られます。

また、緊急対応の目的はまず暫定復旧（業務再開）であり、復旧後の原因調査は通常対応として進行いたします。

24時間対応の主な条件

  • お問い合わせご担当者様と24時間お電話で連絡できること
  • 業務に重大な影響が発生しており、まずは暫定対処を目的とすること

ご注意事項

  • 上記条件を満たさない場合は、緊急度を見直し通常対応としてご案内いたします。
  • 日本では、緊急度B（中程度の影響）の24時間対応は行っておりません。

緊急度Aに該当する状態

緊急度Aは、事業に多大な影響を及ぼす「危機的な状況」 に限られます。次のいずれかにあてはまり、かつ 回避策がなく、いま現に業務が止まっている ことが目安です。判断に迷う場合は、まず状況を具体的にお書き添えください（こちらで適切な緊急度をご提案します）。

  • 重要な業務システムの停止： 基幹業務で使うレポート／ダッシュボードが、テナント全体または多数の利用者にわたって完全に利用できず、業務そのものが遂行できない。
  • 重要な業務システムの著しい劣化： 事業に相当の損失が生じるレベルで、断続的に業務プロセス全体が停止している。

こんな場合は緊急度Aに“該当しません”（通常対応が適切です）

  • 影響が 一部のレポート／一部の利用者 にとどまっている
  • 一時的に発生したが、現在は復旧している
  • 別の方法・回避策で業務を続けられる
  • 開発・検証中で、本番運用には影響していない
  • プロジェクトの締切に間に合わせたいので、対応を加速してほしい
  • すでに復旧している問題の原因を、時間外・休日も継続して調べてほしい
  • 今は使えているが、将来的に問題が起きないか不安

これらは「業務システムの停止・劣化」にはあたらないため、通常対応（緊急度B・C） でのご案内となります。

覚えておきたいこと

起票時の緊急度は、最初のご連絡で状況をうかがったうえで 実際の影響度に合わせて見直されることがあります。「業務が止まっている」ような緊急のケースは緊急対応のまま進み、そうでないケースは通常対応に切り替わります（次章以降でくわしく説明します）。

3. どんなケースが緊急度Aで寄せられるか

お問い合わせを内容で大きく分類すると、全体に占める割合は次のような傾向でした（記載内容のキーワードによる概算で、複数の要素にまたがるものは主な内容に寄せています。割合は大まかな目安です）。

ご相談の分野 割合（概算） 主な内容
セマンティックモデル／データフローの更新失敗 2割強 更新が失敗・終わらない、タイムアウト、増分更新エラー など
アクセス／認証／権限／共有／RLS 2割前後 ログイン・閲覧不可、資格情報エラー、ゲスト共有、行レベルセキュリティ、秘密度ラベル
表示不可・遅延・接続・デプロイ・その他 2割弱 レポート表示の遅延・障害、各種データソース接続、配置パイプライン ほか
レポート／ビジュアル／DAX の作り方・仕様 1割強 スライサー・マップ・カードの挙動、DAX、エクスポート制限などの「ご質問」
ゲートウェイ（オンプレミス データ ゲートウェイ） 1割前後 オフライン・到達不可、インストール／構成エラー、バージョン非対応
容量超過・スロットリング 1割弱 容量制限エラー、CU 100%超過、全レポートが開けない・更新できない
ライセンス／プラン／容量契約／請求 1割弱 Pro / PPU / Premium / Fabric の選定、試用版、請求・解約に関するご相談

ポイント： 「更新の失敗」「アクセス・権限」「作り方のご質問」の3分野が全体の多くを占めます。一方で、「容量超過・スロットリング」やゲートウェイの障害は件数としては中位でも、業務停止に直結するため緊急性が高いグループです。

4. 緊急対応として最後まで進むケース

最後まで緊急対応として進むのは、実害が「今」発生していて続いており、待てない ケースです。代表的なパターンは次のとおりです。

  • 容量超過・スロットリングによる全面停止： テナント全体や容量内の全レポートが「容量制限に達したため、モデルを読み込めません」等で閲覧・更新できず、業務が止まっている。
  • ゲートウェイの全停止・到達不可： オンプレミス データ ゲートウェイがオフライン／到達不可となり、関連する全データの更新が止まる。
  • 大規模なユーザー影響： 数百〜数千人規模、または全社に提供しているサービスで、レポートの表示・更新が一斉にできなくなる。

お問い合わせ後の流れ（緊急対応の場合）

  1. 状況の確認： お電話やTeams会議で、発生状況・影響範囲をすぐに確認します。
  2. 原因の切り分け： 事象によって方法は異なりますが、例えば、容量の消費状況やゲートウェイの状態などを確認し、負荷の高い処理などの原因を特定します。
  3. 専門領域との連携： 必要に応じて関連する専門チームと連携し、調査・対処を行います。
  4. 暫定復旧と恒久対応： まずは業務を再開できる暫定策（負荷の高い処理の停止、自動スケーリングなど）をご案内し、恒久的な原因調査を続けます。

つまり、緊急対応のまま進むのは…

「今まさに止まっている」「多くの人が困っている」「待てない」という 実害・継続・緊急性 が揃っているケースです。

緊急対応中のお願い

緊急対応の目的は、業務を再開できる状態までの復旧・問題回避 です。対応中は、担当エンジニアと 電話・Teams等で連絡が取れる体制の維持 をお願いします。ご連絡が取れない場合は、通常対応に切り替わることがあります。

5. 通常対応に切り替わる（緊急度が下がる）ケースとその理由

緊急度Aで起票されても、最初のご連絡で 「業務は続けられている」「今すぐでなくてよい」 と分かった時点で、通常対応に切り替わります。これは対応を後回しにするためではなく、状況に合った進め方に切り替えるためです。よくあるのは次のパターンです。

  • 暫定策で業務が回復し、原因調査だけが残る： 例）多数の更新失敗のうち大半は手動更新で復旧し、残った少数のみを通常対応で調査。
  • 時間の経過で自然に回復する性質： 例）スロットリングは負荷が平準化されて時間とともに解消するため、その旨をご説明のうえ通常対応へ。
  • 原因となった処理が既に止まっている： 例）容量超過の主因となった処理がすでに終了している場合、手順のご案内に切り替え。
  • 「念のため／翌日への不安」で緊急度Aにしていた： 例）今は使えているが翌日の更新に影響しないか心配、という予防的な起票。実際の影響と締切を確認して通常対応へ。

緊急度が下がっても、調査は続きます

緊急対応は「業務を再開できる状態までの復旧・問題回避」が目的です。業務が回復した時点で緊急対応は完了し、復旧済みの問題の原因調査は通常対応で承ります。

緊急度が下がるのは「もう緊急ではない」という意味で、放置されるわけではありません。「何が解決済みで、何を引き続き調べるか」をお伝えし、以後の調査方針の認識合わせをさせていただきます。

6. 最初から通常対応で受け付けるご質問

次のようなお問い合わせは、緊急度Aで起票されても、最初のご連絡で「業務が止まっているわけではない」と確認され、最初から通常対応として 順にご回答します。

  • 操作方法・仕様（作り方）のご質問： DAXの書き方、スライサー・マップ・カードの挙動、増分更新の設定手順、エクスポートの行数制限など。
  • ライセンス／プラン選定・契約・請求のご相談： Pro / PPU / Premium / Fabric の違いや選び方、試用版、容量ユニット（CU）の意味、請求・解約など。
  • セキュリティ・ガバナンス設定のご相談： 情報漏えい対策（DLP）、組織外への共有方法、行レベルセキュリティ（RLS）の設計など。
  • 新規導入・初期構築時のエラー： まだ本番運用に入っておらず、これからの構築時に出た設定エラー（例：新しいゲートウェイの構築エラー）。実害が発生していないため通常対応。

お急ぎの事情がある場合は

これらは緊急の障害ではないため、通常対応として順にご回答します。導入や提案の締切など お急ぎの背景がある場合は、その理由と期限を書き添えてください。対応の順番を調整しやすくなります。

7. 緊急度の目安と、早く解決するための起票のコツ

緊急度の目安

緊急度A（緊急）がふさわしい 通常対応で十分なことが多い
本番運用が止まっている 操作方法・仕様・作り方のご質問
多数の利用者・全社サービスに影響している ライセンス／プラン・請求のご相談
復旧の締切が直近に迫っている 新規構築中の設定エラー（本番未稼働）
「今は使えているが将来が不安」というご相談

起票時に添えていただくと、早く解決します

以下がそろっていると、初動の切り分けがスムーズになり、解決までの時間が短くなります。

  • 事象： 何が、いつから、どの操作で起きているか
  • 発生開始日時／復旧した時刻： 断続的に起きる場合はその旨も
  • 影響範囲： 影響人数、全社か一部か、対象のワークスペース／レポート名
  • 業務への影響と締切： 止まっている業務、復旧が必要な期限
  • エラーメッセージの全文： アクティビティID・要求ID・相関ID も併記
  • 環境： ライセンス種別（Free / Pro / PPU / Premium / Fabric）、容量SKU、リージョン、ゲートウェイの有無
  • 直近の変更点： 更新・設定変更・PC入れ替え・Windows Update など
  • ご希望の連絡手段： 電話の可否、Teams会議の可否

8. まとめ

緊急度Aで寄せられるケースは、更新の失敗・アクセスや権限・作り方のご質問・ゲートウェイ・容量超過・ライセンスなど多岐にわたります。このうち最後まで緊急対応として進むのは、実害が続いていて待てない障害（容量超過での全面停止、ゲートウェイの全停止、大規模なユーザー影響）です。

一方で、暫定策で業務が回復したケースや自然に回復する性質のもの、そして操作方法・ライセンス・新規構築のご相談は、状況をうかがったうえで 通常対応に切り替わります。緊急度が下がっても調査は続きますので、ご安心ください。

お問い合わせの際に「実害・影響範囲・締切・エラーの詳細・環境」を添えていただくことが、いちばんの近道です。適切な緊急度と十分な情報が、最短の解決につながります。

緊急度は「現在の実害の大きさと緊急性」で選ぶのが基本です。今まさに止まっている障害は緊急度A、じっくり相談したい内容は通常対応（緊急度B・C）と使い分けることで、必要な支援により早くたどり着けます。

関連参考情報

以上、本ブログが少しでも皆様のお役に立てれば幸いです。

本記事はこれまでのお問い合わせ傾向をもとに作成したナレッジです。事例はパターンのみを一般化しています。

※本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。