Microsoft は2026年5月1日、SharePoint Online における旧来の認証方式「IDCRL（Identity Client Run Time Library）」を正式に廃止した。セキュリティ近代化の観点からは正しい一手だ。しかし廃止の「後始末」として、統合監査ログ（Unified Audit Log）に大量の謎のイベントが発生している。IT管理者にとっては、セキュリティ強化の恩恵より先に、ノイズとの戦いが始まった格好だ。

IDCRL廃止とは何か

IDCRLとは、SharePointが長年使ってきたMicrosoft独自の認証ライブラリで、モダン認証（OAuth/OpenID Connect）が普及する以前の設計に基づく仕組みだ。Microsoftは段階的な廃止スケジュールを経て、2026年5月1日にIDCRLを完全に停止した。

ここまでは良い話だ。

監査ログに何が起きているのか

問題はここからだ。廃止の約6日前、4月25日16:00 UTC頃から、統合監査ログに IDCRLBlockedDueToSoftEnforcement というイベントが爆発的に記録され始めた。

このイベントは「クライアントまたはアプリがIDCRLを使おうとしたが、SharePointにブロックされた」という意味だ。ところが、ブロックされているのは Microsoft Office Word や Microsoft Office Core Storage Infrastructure といったMicrosoft自身のOfficeアプリであり、なんと Microsoft Office Word 2014 というクライアント名まで現れている。

さらに奇妙なのは、イベントのペイロードを詳しく見ると、実際の認証はOAuthで行われているにもかかわらず、IDCRLイベントとして記録されている点だ。OAuthで認証が完結しているなら、IDCRLブロックイベントを出す理由がない。

もう一つの問題は、ユーザーが Unknown User として記録されることだ。これでは監査ログとして本来の役割——誰がいつ何をしたか——を果たせない。他のイベントとの相関分析も困難になる。

Wordを開くだけで最大6件のイベント

調査によれば、Wordでファイルを開くたびに最大6件のIDCRLイベントが記録され、保存のたびにさらに追加される。Office系アプリを日常的に使う組織では、1日に数千件から数万件のノイズイベントが生成される計算になる。

統合監査ログの「問題歴」

統合監査ログは2016年の登場以来、データの消失、イベントペイロードの切り詰め、検索精度の問題と、幾度となく信頼性の問題を抱えてきた歴史がある。Microsoftは高完全性検索（High Completeness Search）や監査向けGraph APIで改善を試みてきたが、いずれも完全な解決には至っていない。

ログの仕組み自体がExchangeの特殊な監査メールボックスをストレージとして使う設計で、2016年当時としては合理的な選択だったが、2026年の今日、データ量・保持期間・検索負荷のすべてが当時の想定を大きく超えている。

日本のIT管理者への実務的影響

今すぐ確認すべきこと

  • 監査ログのノイズ量を確認する: IDCRLBlockedDueToSoftEnforcement で絞り込み検索をかけてイベント件数を把握する。数千件単位で出ているなら要注意
  • SIEMへの連携設定を見直す: Microsoft Sentinel などにM365監査ログを取り込んでいる場合、このイベントがアラートルールを誤作動させる可能性がある。フィルタリングルールの追加を検討する
  • コンプライアンス担当者への説明を準備する: 監査レポートに大量の Unknown User イベントが出てきた場合、監査人・コンプライアンス担当者からの問い合わせに備えた説明資料を用意しておくとよい

対応の優先度

現時点でMicrosoftから公式の修正情報は出ていない。緊急対応は不要だが、ログ分析やアラートに影響が出ている組織は、上記のフィルタリング対応を早めに実施したい。

筆者の見解

IDCRLの廃止そのものは正しい方向性だ。レガシー認証の排除はゼロトラストへの移行において欠かせないステップであり、むしろもっと早く進めてほしかったくらいだ。

ただ、こうした「廃止の副作用」への対応が粗い点は、率直に言って惜しい。OAuthで正常に認証されているにもかかわらずIDCRLブロックイベントが発生し、しかも Unknown User として記録されるのは、設計レビューで防げた問題のはずだ。

統合監査ログはM365セキュリティ運用の根幹を担うコンポーネントだ。コンプライアンス監査、インシデントレスポンス、内部統制——そのすべてがこのログの信頼性に依存している。それだけに、ノイズイベントの混入は「小さな問題」では済まない。

MicrosoftはEntra IDの機能拡充、Defenderの統合、Purviewの充実と、セキュリティ全体としては着実な進化を続けている。その積み重ねがあるからこそ、監査ログの「詰め」の甘さが目についたときは余計に惜しいと感じる。力はある。あとは仕上げの精度を上げるだけだ、と言いたいところだ。

Microsoft側での修正を期待しつつ、現場のIT管理者としては今できるフィルタリング対応を先に打っておくのが賢明だろう。

出典: この記事は Explosion of Legacy SharePoint Online Legacy Authentication Audit Events の内容をもとに、筆者の見解を加えて独自に執筆したものです。