Microsoft Entra ID のサインインログをCSVでダウンロードしようとしたのに、NonInteractive／MSI／Application だけ「Download failed」「The specified data URL is not correctly formatted…」で失敗するケースがあります。原因の考え方と、最短で復旧する具体手順（レガシー画面への切り替え）を、運用の注意点まで含めて整理します。
Entra ID サインインログのCSVダウンロードが「一部だけ失敗」する現象
Microsoft Entra admin center（Entra ID ポータル）のサインインログ画面から、複数種類のログをCSVで出力しようとした際に、特定の種類だけダウンロードできないことがあります。画面操作としては、次の導線です。
[監視] ＞ [サインイン ログ] ＞ [ダウンロード] ＞ [CSV]
このとき、失敗時に表示されやすいメッセージが以下です。
- Download failed
- The specified data URL is not correctly formatted using the data URL syntax
今回のパターンでは、6種類のうち、対話型だけ成功し、それ以外（非対話／マネージドID／アプリケーション）が失敗しています。
| CSVとしてダウンロードするログ | ファイル名（例） | 結果 | 画面に出る代表的なエラー |
|---|---|---|---|
| 対話型サインイン | InteractiveSignIns | 成功 | — |
| 対話型サインイン（認証詳細） | InteractiveSignIns_AuthDetails | 成功 | — |
| 非対話サインイン | NonInteractiveSignIns | 失敗 | Download failed / data URL syntax |
| 非対話サインイン（認証詳細） | NonInteractiveSignIns_AuthDetails | 失敗 | Download failed / data URL syntax |
| マネージドIDサインイン | MSISignIns | 失敗 | Download failed / data URL syntax |
| アプリケーション サインイン | ApplicationSignIns | 失敗 | Download failed / data URL syntax |
まず整理：Interactive / NonInteractive / MSI / Application は何が違う？
「なぜ一部だけ失敗するのか？」を理解するために、ログの性質（発生頻度・データ量・内容のクセ）を押さえておくと切り分けが早くなります。
| ログ種別 | 主な対象 | よくある発生例 | データ量が増えやすい理由 |
|---|---|---|---|
| InteractiveSignIns（対話型） | ユーザーが画面操作して行うサインイン | ブラウザでMicrosoft 365へログイン、条件付きアクセスでMFA要求など | 人間の操作が前提のため、頻度が比較的限定される |
| NonInteractiveSignIns（非対話） | ユーザー主体だが“裏側”で行われるサインイン | Teams/Outlook/OneDriveのバックグラウンド更新、トークン更新、端末/クライアントの定期アクセス | バックグラウンドで大量に発生しやすく、短期間でも件数が膨らみやすい |
| MSISignIns（マネージドID） | Azure リソースのManaged Identity（システム割り当て/ユーザー割り当て） | Function/App Service/VMがKey VaultやGraph等へアクセス | アプリの動作頻度に比例し、秒〜分単位で継続的に増えることがある |
| ApplicationSignIns（アプリケーション） | サービスプリンシパル（アプリ）によるサインイン | Client Credentials（アプリのみ認証）、デーモン/バッチ処理、監視ツールの定期実行 | 自動処理のため、対話型より桁違いにイベントが出ることがある |
| AuthDetails（認証詳細） | サインインの“追加情報” | MFAの手段、条件付きアクセスの評価、認証ステップの内訳など | 1件のサインインに対して詳細が増えるため、CSV化の処理量が増えやすい |
ポイントは、NonInteractive / MSI / Application は短期間でも件数・内容が重くなりやすいということです。今回の症状（対話型は成功し、それ以外が失敗）と非常に整合します。
結論：新しいサインインログ画面（プレビュー）のUI側不具合が濃厚
今回のケースは、ユーザー操作や権限不足というより、画面（UI）側の問題である可能性が高いパターンです。背景として、現在利用している新しいサインインログ画面が「プレビュー機能」として提供されていることが挙げられます。
プレビュー機能は、正式版に比べて次の特徴があります。
- 機能が順次追加・変更される（挙動が頻繁に変わる）
- 一部の条件で不具合が混入することがある
- 同じ操作でも、旧画面（レガシー）と結果が一致しないことがある
また、表示されているエラー文言が「data URL syntax（data URL の形式が正しくない）」となっている点から、次のような状況が推測できます。
- CSVの生成・ダウンロードが、サーバー側ではなくブラウザ側（フロントエンド）で処理されている
- 生成したCSVを
data:形式のURLに埋め込んでダウンロードさせる実装になっており、データ量や文字列処理の不整合でURLが壊れるとエラーになる - 件数が増えやすい NonInteractive / MSI / Application でだけ失敗しやすい
つまり、「ログが存在しない」「権限がない」よりも、プレビューUIのCSV出力機能が特定種類のログに耐えられていない、という見立てが最も自然です。
最短の解決策：レガシー（従来）のサインインログ画面へ切り替える
この症状は、プレビューを終了してレガシー画面に戻すことで解消するケースが多いです。特に、今回のように「4種類だけ失敗する」場合は、まずこの手順を試すのが最短ルートです。
手順：プレビューを終了してレガシー画面に戻す
- Entra ID ポータルで サインイン ログ 画面を開きます。
- 画面上部（多くはページ最上部）に表示される、プレビューに関する案内メッセージを探します。
例：「Want to switch back to the legacy signin logs experience? Click here to leave the preview.」
日本語環境では「従来のサインインログ エクスペリエンスに戻しますか？」のようなリンクとして表示されることがあります。 - リンク（leave the preview／プレビューを終了／従来のエクスペリエンスに戻る 等）をクリックします。
- 画面が切り替わったことを確認します（レイアウトやフィルター配置が変わることが多いです）。必要に応じてページを再読み込みします。
- 改めて [監視] ＞ [サインイン ログ] ＞ [ダウンロード] ＞ [CSV] から、
NonInteractiveSignIns／MSISignIns／ApplicationSignInsを含む各ログをダウンロードします。
この切り替えによって、プレビュー画面で失敗していた4種類を含め、CSV出力が正常化することが報告されています。
切り替え後に「成功したか」を確認するチェックポイント
- 同じフィルター条件（例：過去24時間、特定アプリ、特定ユーザーなど）で再度ダウンロードし、エラーが消えるか
- 4種類（NonInteractive／NonInteractive_AuthDetails／MSI／Application）が最後までダウンロード完了するか
- ダウンロードされたCSVの先頭行（ヘッダー）と最終行が欠けていないか
- 文字化けがないか（Excelで開く場合は文字コード影響が出ることがあります）
「リンクが見つからない」「切り替わらない」ときの実務的な対処
プレビューの案内が見当たらない、またはクリックしても挙動が変わらない場合は、次を順に試すと復旧しやすいです。
- ページを再読み込み（キャッシュでバナー表示が崩れることがあります）
- シークレットウィンドウ（InPrivate）で同じ画面を開く（拡張機能・キャッシュの影響を排除）
- 別ブラウザ（Edge / Chrome）で再現性を確認する
- 組織のプロキシやセキュリティ製品がある場合、ダウンロード時のブロックが出ていないかを確認する
- 条件を極端に絞って（例：過去1時間、フィルターあり）試し、データ量依存かどうかを切り分ける
ただし、今回のように「特定のログ種別だけ恒常的に失敗する」場合は、根本がUI側であることが多いため、最終的にはレガシー画面を使う運用に寄せた方が安定します。
なぜレガシーに戻すと直るのか（現場での理解）
レガシー画面は長く使われてきた経緯があり、CSV出力も比較的安定しています。一方、プレビュー画面は改善途中で、次のような“落とし穴”に当たることがあります。
- CSVの生成方式が異なり、プレビュー側の生成処理が重いログに弱い
- 特定ログ種別の列構成（値の長さ、入れ子構造、特殊文字など）を想定しきれていない
- 認証詳細（AuthDetails）のように、1イベントあたりの情報量が多いものは失敗確率が上がる
現場目線で言うと、「プレビューは便利だが、いざというときは旧画面（レガシー）に逃がす」が最も堅い戦い方です。
運用上の注意：プレビューUIは“試す場所”、レガシーUIは“確実に回す場所”
プレビュー機能を全面否定する必要はありません。ただし、監査・障害調査・インシデント対応でログ出力が必要な場面では、安定性のほうが重要です。日々の運用を安全にするための使い分け例をまとめます。
| やりたいこと | 推奨する画面 | 理由 | 補足 |
|---|---|---|---|
| 大量ログの一括CSV出力 | レガシー | UIの成熟度が高く、失敗率を下げやすい | 特に NonInteractive/MSI/Application はレガシー推奨 |
| 日常的な簡易確認（数件の確認） | プレビュー/レガシーどちらでも | 閲覧中心なら影響が少ない | 不審イベントの深掘りは別経路も用意すると安心 |
| 認証詳細の確認（MFA/条件付きアクセス） | 状況次第 | 表示はプレビューが見やすい場合もある | CSVが必要ならレガシーへ切替 |
| インシデント時の証跡確保 | レガシー＋別保管 | 「今すぐ確実に出す」ことが最優先 | 後述のLog Analytics/Storage転送が有効 |
おすすめの運用ルールとしては、次のように手順を標準化すると迷いません。
- まずプレビューで操作して失敗したら、すぐレガシーへ切り替えて再実行
- 月次・週次など定期のログ保管作業は、最初からレガシーで実施
- インシデント対応用に、ポータル以外の取り出し口（転送・API）も用意する
レガシーに戻せない／大量データで詰まるときの回避策
組織の事情で画面切り替えが難しい、あるいは件数が多すぎて何をしても落ちる、といったケースもあり得ます。その場合は、次の回避策が役に立ちます。
回避策：条件を絞ってCSVを小さくする（まず最初に試す）
プレビュー画面のCSV生成がデータ量に弱い場合、対象を絞るだけで成功することがあります。
- 期間を短くする（例：過去7日 → 過去24時間 → 過去1時間）
- アプリケーション（クライアント）で絞る（例：特定のサービスプリンシパルのみ）
- ユーザーで絞る（例：調査対象ユーザーのみ）
- 条件付きアクセスポリシーの結果、失敗のみ、リスク検出のみ…など、絞り込み項目を活用する
ただし、今回のように「特定ログ種別が恒常的に落ちる」場合は、絞り込みで回避できないことも多いので、早めにレガシーへ切り替える方が結果的に早いことがあります。
回避策：診断設定でログを別の場所へ転送し、そこからエクスポートする
ログを「ポータルから都度取り出す」運用は、UI不具合に引きずられやすいのが弱点です。安定した運用を目指すなら、サインインログをLog Analyticsやストレージへ転送して保管し、必要なときにそこから取り出す方式が堅いです。
代表的な転送先と向いているケースを整理します。
| 転送先 | 向いているケース | メリット | 注意点 |
|---|---|---|---|
| Log Analytics ワークスペース | 検索・相関分析・アラートをしたい | KQLで柔軟に絞り込み、必要な列だけCSV出力しやすい | コスト（取り込み/保持）設計が必要 |
| ストレージアカウント（Blob） | 長期保管・監査証跡を確実に残したい | 保管に強く、データを失いにくい | 分析には別途加工やツールが必要 |
| Event Hub | SIEM連携、リアルタイム処理 | 外部製品と統合しやすい | 構成がやや複雑になりがち |
インシデント対応や監査で「あとから出せない」を避けたい場合、Sign-in logs の転送設定は投資対効果が高いです。ポータルのCSVに頼り切りにならないため、今回のようなUI起因の障害でも業務が止まりにくくなります。
回避策：Microsoft Graph で取得してCSV化する（自動化・再現性重視）
「手作業で毎回CSVを落とす」のではなく、手順を自動化したい場合は、Microsoft Graph からサインインログを取得してCSV化する選択肢もあります。代表的な考え方は次の通りです。
- Graphのサインインログ（例：signIns）を期間指定で取得する
- 必要な列だけ整形してCSVに保存する
- 定期実行（タスクスケジューラ、Automation、Functions等）で保管を自動化する
この方式は、UIの影響を受けにくい反面、権限設計や取得制限（ページング・スロットリング）を考慮する必要があります。まずは「緊急時の代替ルート」として手順だけ整備しておき、必要になったら実装する、という段階的な導入も現実的です。
トラブルシューティング：失敗パターン別の切り分け表
「本当にUIの問題なのか？」を短時間で判断できるよう、現場で使える切り分け表を用意しました。
| 症状 | 疑うポイント | まず試すこと | 次の一手 |
|---|---|---|---|
| NonInteractive/MSI/Application だけ落ちる | プレビューUI不具合、データ量依存 | レガシーへ切替して同条件で再実行 | 診断設定（Log Analytics/Storage）で別経路を確保 |
| すべてのCSVが落ちる | ブラウザ/プロキシ/拡張機能、権限 | 別ブラウザ/シークレットで再試行 | 権限（閲覧・エクスポート権限）やネットワーク制御を確認 |
| 期間を短くすると成功する | データ量が閾値を超えている | 期間・フィルターで分割して複数回ダウンロード | 長期はLog Analytics/Storageへ転送する運用に移行 |
| ダウンロードはできるが内容が欠ける/不自然 | UI側の整形・列変換の不整合 | レガシーで同条件を出力し比較 | 必要ならAPI/Log Analyticsで取得し正を確保 |
よくある質問
「UIの問題なら、ログ自体が欠損しているの？」
多くの場合、欠損しているのはログそのものではなく、ポータルのCSV出力機能です。レガシー画面で同期間を出せるなら、バックエンドのログが消えている可能性は低く、UI側の処理に問題があると判断できます。
「プレビューを使い続けたい。完全に戻さないとだめ？」
普段の閲覧や簡易調査はプレビューでも問題ないことがあります。ただし、CSV出力が必要なタイミングだけレガシーへ切り替えるという運用を用意しておくと、安定性と利便性の両立ができます。
「認証詳細（AuthDetails）も落ちるのはなぜ？」
AuthDetailsは、1つのサインインに対して認証の内訳が付くため、データの構造や量が増えやすい傾向があります。プレビューUIのCSV生成が弱い状況だと、通常ログよりも先に失敗しやすい要因になります。
「過去3日ずっと落ちている。こちらの設定ミス？」
同じ環境で対話型が成功しているのに、特定ログ種別だけ失敗する場合、設定ミスよりも画面側の不具合を疑うのが合理的です。まずはレガシーへ切り替えて同じ操作を行い、再現性で判断すると早いです。
まとめ：Entra ID サインインログCSVが一部だけ落ちるときの最短復旧
- NonInteractiveSignIns／MSISignIns／ApplicationSignIns だけ「Download failed」「data URL syntax」で落ちるのは、新しいサインインログ画面（プレビュー）のUI不具合が原因になりやすい
- プレビューを終了し、レガシー（従来）のサインインログ画面に切り替えると、CSV出力が通ることが多い
- 重要な運用（監査・証跡確保・定期保管）は、レガシー画面を優先し、必要ならログ転送やAPI取得も組み合わせると安定する
ログ出力は「できるときにやる」ではなく、「いつでも確実にできる」ことが重要です。プレビューUIで詰まったら、迷わずレガシーへ戻す——この逃げ道を手順として整備しておくと、いざというときの対応速度が変わります。
コメント