Microsoft Entra アプリを使って SharePoint Online の Remote Event Receivers（RER）を登録している場合でも、2027年7月1日までに SharePoint webhooks または Microsoft Graph change notifications へ移行する必要があります。Microsoft が2026年6月29日に公開した公式情報では、2027年7月1日以降、登録方式に関係なくすべての Remote Event Receivers はイベントを発火しなくなると案内されています。(Microsoft for Developers)
今回のポイントは、「Azure ACS 依存の RER だけが対象」ではないことです。Microsoft Entra アプリで登録した RER も最終的には廃止対象です。SharePoint Online の変更検知、承認前チェック、外部システム連携、ドキュメントライブラリ更新時の処理などに RER を使っている組織は、単なる設定変更ではなく、アプリケーション設計の見直しとして移行計画を立てる必要があります。
Microsoft Entra 関連で押さえるべき更新ポイント
今回の更新は名称だけ見ると SharePoint Online の開発機能廃止に見えますが、実務では Microsoft Entra のアプリ登録、アプリケーション権限、証明書認証、SharePoint API へのアクセス設計に影響します。
従来の Remote Event Receivers は、SharePoint Add-in モデルや Azure Access Control Services（Azure ACS）と強く結び付いていました。Azure ACS の廃止に伴い、Microsoft は一時的な移行策として Microsoft Entra アプリを使った RER 登録モデルを用意していました。しかし、これは恒久的な代替策ではありません。公式ブログでは、Microsoft Entra アプリで登録された RER も含め、2027年7月1日にすべての RER が停止すると説明されています。(Microsoft for Developers)
つまり、今後の判断基準は次のようになります。
| 現在の状態 | 影響 | 管理者・開発者が取るべき対応 |
|---|---|---|
| Azure ACS で登録した RER を利用 | 2026年4月2日時点で正常動作しない可能性が高い | 早急に利用有無を確認し、webhooks または Graph 通知へ移行 |
| Microsoft Entra アプリで登録した RER を利用 | 2027年7月1日までは継続可能だが、その後は停止 | 延命策として扱わず、移行計画を開始 |
| SharePoint Add-in モデルに依存 | Add-in モデルの廃止影響を受ける | SPFx、SharePoint REST、Microsoft Graph を前提に再設計 |
| RER の利用有無が不明 | テナント全体での自動検出手段はまだ限定的 | コード、PnP PowerShell、アプリ台帳、外部連携一覧から棚卸し |
特に注意したいのは、「Microsoft Entra アプリで登録しているから安全」と誤解しないことです。Microsoft Entra ベースの RER 登録は、Azure ACS 依存を外すための橋渡しであり、最終的な移行先ではありません。
Remote Event Receivers とは何か
Remote Event Receivers は、SharePoint Online 上でリスト、ライブラリ、アイテムなどに変更が発生したとき、外部のサービスやアプリケーションを呼び出すための仕組みです。
たとえば、次のような処理に使われてきました。
- ドキュメントライブラリにファイルが追加されたら外部システムへ連携する
- リストアイテム更新時に独自の検証処理を実行する
- アイテム削除前に条件を確認し、削除をキャンセルする
- SharePoint の変更を基幹システム、ワークフロー、監査基盤へ通知する
- SharePoint Add-in の一部としてイベント処理を外部サービスに任せる
RER の特徴は、同期イベントと非同期イベントの両方を扱えたことです。同期イベントでは、たとえば「アイテム追加前」「削除前」のようなタイミングで処理を行い、条件に合わなければ操作をキャンセルすることができました。
一方、移行先として推奨される SharePoint webhooks は非同期イベントのみを扱います。つまり、変更が発生した後に通知を受け取る仕組みであり、操作の事前ブロックには使えません。(Microsoft for Developers)
この違いは、単純な API 置き換えでは済まない重要ポイントです。
廃止スケジュールと影響範囲
Microsoft の公式情報に基づく主なスケジュールは次の通りです。(Microsoft for Developers)
| 日付 | 内容 | 実務上の意味 |
|---|---|---|
| 2024年11月1日以降 | 新規テナントでは Azure ACS 依存の RER が利用できない | 新規導入で従来方式を前提にできない |
| 2026年4月2日 | Azure ACS で登録された RER が正常に機能しなくなる | 既存の ACS 依存アプリは障害化している可能性がある |
| 2027年7月1日 | すべての RER がイベントを発火しなくなる | Microsoft Entra アプリ登録の RER も含めて完全停止 |
影響範囲は、SharePoint Online のカスタマイズや外部連携を持つ組織に広がります。特に、長年運用している SharePoint Add-in、プロバイダー ホスト型アドイン、社内開発のワークフロー、外部ベンダー製アドオンは確認が必要です。
影響を受けやすいシステムの例
古い SharePoint Online 環境では、RER が明示的に「重要機能」として管理されていないことがあります。次のようなシステムは、優先的に確認してください。
| システムの種類 | 確認すべき理由 |
|---|---|
| 文書管理システム | ファイル追加・更新・削除を契機に外部処理を起動している可能性がある |
| 申請・承認ワークフロー | 申請前チェックや差し戻し処理に同期 RER を使っている場合がある |
| 基幹システム連携 | SharePoint リスト更新を ERP、CRM、会計システムへ連携している可能性がある |
| 監査・コンプライアンス連携 | 操作ログや変更通知を外部監査基盤へ送っている場合がある |
| ベンダー提供アドイン | 内部実装で RER を使っていても管理者が把握していないことがある |
「ユーザーから見える画面は SharePoint 標準でも、裏側でイベント処理だけ外部サービスに飛ばしている」という構成は珍しくありません。移行漏れを防ぐには、画面単位ではなく、イベント処理単位で棚卸しすることが重要です。
SharePoint webhooks への移行で変わること
Microsoft は RER の代替として SharePoint webhooks を推奨しています。SharePoint webhooks は、特定のリストやドキュメントライブラリで変更が起きたときに、指定した HTTP エンドポイントへ POST 通知を送る仕組みです。Microsoft Learn でも、webhooks は WCF サービスを使う RER より通常の HTTP サービスとして実装しやすいと説明されています。(Microsoft Learn)
ただし、webhooks は RER と完全互換ではありません。移行時に特に重要なのは次の違いです。
| 比較項目 | Remote Event Receivers | SharePoint webhooks |
|---|---|---|
| イベント処理のタイミング | 同期・非同期の両方に対応 | 非同期のみ |
| 操作のキャンセル | 同期イベントで可能 | 不可 |
| 通知内容 | イベント種別や一部プロパティを扱える | 通知自体には詳細な変更内容が含まれない |
| 変更詳細の取得 | RER 側のイベント情報で処理しやすい | GetChanges API などで別途取得 |
| 実装方式 | WCF ベースの古い実装が多い | HTTP API として実装 |
| サブスクリプション期限 | RER とは考え方が異なる | 最大180日を前提に更新処理が必要 |
SharePoint webhooks の通知ペイロードは、「何かが変更された」ことを知らせるものであり、変更内容の詳細をすべて含むわけではありません。実際の変更内容は、保存しておいた change token を使って GetChanges API などから取得する設計が必要です。(Microsoft Learn)
Microsoft Graph change notifications も選択肢になる
SharePoint webhooks だけでなく、Microsoft Graph change notifications も移行候補になります。公式ブログでも、SharePoint リストの変更を購読する代替手段として Microsoft Graph の利用が挙げられています。(Microsoft for Developers)
どちらを選ぶかは、既存システムの設計と今後の拡張方針で判断します。
| 選択肢 | 向いているケース | 注意点 |
|---|---|---|
| SharePoint webhooks | 既存処理が SharePoint リストやライブラリ中心 | 通知後に変更詳細を取得する実装が必要 |
| Microsoft Graph change notifications | Microsoft 365 全体のイベント通知基盤を統一したい | Graph の対応範囲、権限、購読管理を確認する必要がある |
| SPFx などへの再構築 | UI カスタマイズやユーザー操作に近い処理を作り直す | 単なるイベント置換ではなく画面・権限設計も見直す必要がある |
たとえば、SharePoint のドキュメントライブラリ更新だけを外部 API に流すなら SharePoint webhooks が分かりやすい選択肢です。一方、Teams、Outlook、OneDrive、SharePoint をまたいだ通知基盤として整理したい場合は、Microsoft Graph を中心に設計した方が将来の運用をそろえやすくなります。
同期イベントを使っていた場合は設計変更が必要
移行で最も失敗しやすいのは、同期 RER の置き換えです。
RER では、たとえば ItemAdding や ItemUpdating のような「処理前イベント」を使い、ユーザー操作をキャンセルする設計が可能でした。しかし SharePoint webhooks は変更後に通知する仕組みです。そのため、「不正な更新を検知して止める」用途にはそのまま使えません。
同期 RER の代替設計例
| 既存の処理 | そのまま移行できない理由 | 代替案 |
|---|---|---|
| 削除前に条件を確認してキャンセル | webhooks は削除後に通知される | 権限設定で削除権限を制限する |
| 特定フォルダーへの更新を禁止 | 変更後通知では事前ブロックできない | 保護対象を権限分離したライブラリへ移す |
| 入力値が不正なら追加を拒否 | 追加後にしか通知されない | リストの入力制御、Power Apps、SPFx、別フォームで検証する |
| 承認前のファイル変更を止める | 変更操作そのものは先に完了する | ライブラリのバージョン管理、承認、権限設計を組み合わせる |
| 監査対象ファイルを削除不可にする | 後追い通知では復旧対応になる | 保持ポリシー、アクセス制御、別ライブラリ保管を検討する |
重要なのは、「イベントで止める」から「そもそも操作できないようにする」へ発想を変えることです。禁止したい操作をアプリケーションコードで後追い制御するより、SharePoint の権限、ライブラリ設計、保持設定、入力フォーム設計で前段に寄せた方が安定します。
管理者がまず確認すべきポイント
今回の変更に対して、Microsoft 365 管理者、SharePoint 管理者、Microsoft Entra 管理者、アプリケーション担当者が確認すべき項目は異なります。部門ごとに分担すると、移行漏れを減らせます。
| 担当 | 確認項目 | 具体的なアクション |
|---|---|---|
| Microsoft 365 管理者 | 影響を受ける業務部門 | SharePoint を使う主要業務システムの一覧を作る |
| SharePoint 管理者 | サイト・リスト・ライブラリ単位のイベント処理 | 古いアドイン、外部連携、カスタム機能を確認する |
| Microsoft Entra 管理者 | アプリ登録と権限 | SharePoint API 権限、証明書、アプリ所有者を確認する |
| 開発者 | RER 実装箇所 | コード内の EventReceivers、Add-PnPEventReceiver、WCF エンドポイントを検索する |
| セキュリティ担当 | 操作ブロック・監査要件 | webhooks 移行後も要件を満たせるか確認する |
| ベンダー管理担当 | 外部製品の対応状況 | RER 利用有無と移行ロードマップをベンダーへ確認する |
公式ブログでは、現時点で開発者や管理者がテナント全体の RER 利用状況を横断的に検出する方法はまだ用意されておらず、Microsoft が対応を進めていると説明されています。(Microsoft for Developers)
そのため、現段階ではアプリ台帳、ソースコード、PnP PowerShell の運用履歴、外部連携一覧、ベンダーへの確認を組み合わせる必要があります。
RER 利用有無を洗い出す実務的な方法
テナント全体の自動検出が難しい場合でも、実務では次の観点からかなり絞り込めます。
ソースコードを検索する
社内開発や保守ベンダーにソースコードがある場合は、次のようなキーワードで検索します。
EventReceivers
RemoteEventReceiver
ProcessEvent
ProcessOneWayEvent
ItemAdding
ItemAdded
ItemUpdating
ItemUpdated
ItemDeleting
ItemDeleted
Add-PnPEventReceiver
Get-PnPEventReceiver特に ProcessEvent や ProcessOneWayEvent は、RER の受信サービス側で使われる典型的な実装です。古い .NET Framework、WCF、Azure Functions、App Service 上のエンドポイントも確認対象になります。
PnP PowerShell の利用履歴を確認する
過去に PnP PowerShell でイベントレシーバーを登録している場合、スクリプトや運用手順書に Add-PnPEventReceiver が残っていることがあります。Git リポジトリ、運用端末、Azure Automation、CI/CD パイプラインのスクリプトを確認してください。
Microsoft Entra のアプリ登録を確認する
Microsoft Entra アプリを使った RER 登録では、SharePoint へのアプリケーション権限や証明書認証が関係します。Microsoft Learn では、Entra アプリで RER を登録する場合、SharePoint の Sites.Selected 権限や証明書を使ったアプリケーション権限が必要になると説明されています。(Microsoft Learn)
確認すべき項目は次の通りです。
| 確認対象 | 見るべきポイント |
|---|---|
| アプリ登録の所有者 | 担当者不明のアプリがないか |
| API のアクセス許可 | SharePoint、Microsoft Graph の権限が過剰でないか |
| 証明書・シークレット | 期限切れ、所有者不明、更新手順不明がないか |
| エンタープライズ アプリケーション | 使われていない ACS 関連プリンシパルが残っていないか |
| アプリの説明・命名 | RER、SharePoint、Webhook、Add-in などの手掛かりがないか |
ただし、アプリ登録だけを見ても RER の有無を完全には判断できません。アプリが SharePoint API を使っていても、RER 以外の用途である可能性があるため、コードと運用実態を合わせて確認する必要があります。
移行手順：2027年7月1日から逆算して進める
RER 廃止対応は、期限直前に API だけ置き換える作業ではありません。特に同期イベントを使っている場合は、業務フロー、権限、例外処理、監査要件まで見直す必要があります。
推奨する移行ステップ
| ステップ | 作業内容 | 完了の判断基準 |
|---|---|---|
| 1 | RER 利用箇所を棚卸し | 対象サイト、リスト、ライブラリ、外部エンドポイントが一覧化されている |
| 2 | イベント種別を分類 | 同期イベント、非同期イベント、通知のみ、操作ブロック用途が分かれている |
| 3 | 移行先を決める | SharePoint webhooks、Microsoft Graph、SPFx、権限設計変更の方針が決まっている |
| 4 | Webhook 受信エンドポイントを実装 | 検証リクエストに応答し、通知を受信できる |
| 5 | 変更詳細の取得処理を実装 | change token を管理し、GetChanges API などで差分を取得できる |
| 6 | サブスクリプション更新を実装 | 最大180日を前提に自動更新できる |
| 7 | 障害時の再処理を設計 | 通知失敗、重複通知、遅延、エンドポイント停止に対応できる |
| 8 | 本番移行・RER 無効化 | 新旧処理の二重実行を避け、RER 依存をなくす |
Microsoft の公式ブログでも、RER の登録箇所と WCF エンドポイントの棚卸し、HTTP エンドポイントの用意、検証ハンドシェイクの実装、サブスクリプション更新の追加が移行手順として示されています。(Microsoft for Developers)
Webhook 実装で見落としやすいポイント
SharePoint webhooks はシンプルに見えますが、本番運用ではいくつかの落とし穴があります。
| 注意点 | なぜ重要か | 対策 |
|---|---|---|
| 通知に変更詳細が含まれない | 通知だけでは何が変わったか判断できない | GetChanges API と change token を使う |
| サブスクリプションが期限切れになる | 更新しないと通知が止まる | 更新ジョブを定期実行する |
| 通知が重複する可能性がある | 同じ変更を二重処理する恐れがある | 冪等性のある処理にする |
| エンドポイント停止時に通知を取り逃す | 障害中の変更を処理できない可能性がある | 再取得処理と監視を用意する |
| 非同期処理になる | ユーザー操作をその場で止められない | 権限・入力フォーム・ライブラリ設計で前段制御する |
Microsoft Learn では、Webhook サブスクリプションの有効期限は既定で180日、指定する場合も180日以内が前提とされています。また、通知エラー時には一定回数の再試行が行われるものの、最終的に配信されない可能性があるため、アプリ側で復旧できる設計が重要です。(Microsoft Learn)
グローバル環境での移行時に注意すべきこと
グローバル企業や複数リージョンに Microsoft 365 テナントを展開している組織では、単一システムの修正だけでなく、運用体制の整理も必要です。
タイムゾーンと期限管理
公式期限は 2027年7月1日です。日本時間で見れば余裕があるように見えても、グローバル環境では開発拠点、運用拠点、ベンダー、ユーザー部門の稼働日が異なります。
特に欧米拠点の休暇シーズンや日本の年度末・四半期末に重なると、テストや承認が遅れやすくなります。期限の3〜6カ月前には本番移行を終える前提で計画した方が安全です。
マルチテナント製品の確認
SaaS ベンダーや外部アドインを使っている場合、自社テナントの管理画面だけでは RER 利用有無を判断できないことがあります。ベンダーに確認する際は、単に「2027年7月1日の RER 廃止に対応していますか」と聞くのではなく、次のように確認すると実効性が高まります。
SharePoint Online の Remote Event Receivers を使用していますか。
使用している場合、Azure ACS 登録か Microsoft Entra アプリ登録かを教えてください。
2027年7月1日以降の代替方式は SharePoint webhooks、Microsoft Graph change notifications、その他のどれですか。
同期イベントで操作をキャンセルしている機能はありますか。
移行版の提供時期、管理者側で必要な権限変更、テスト手順を教えてください。この確認を早めに行うことで、ベンダー都合のアップデート待ちや、直前の権限追加申請を避けやすくなります。
いつまでに何をすべきか
2027年7月1日が最終期限ですが、現実的には段階的に進める必要があります。
| 時期の目安 | やるべきこと |
|---|---|
| すぐ | RER 利用箇所、SharePoint Add-in、Microsoft Entra アプリ登録を棚卸しする |
| 2026年内 | 同期イベント利用の有無を特定し、代替設計を決める |
| 2027年前半 | webhooks または Graph 通知の実装・テスト・本番移行を完了する |
| 2027年7月1日前 | 旧 RER の停止、監視、ベンダー対応状況を最終確認する |
優先順位は、業務影響の大きさで決めると効率的です。
最優先は、申請・承認、監査、基幹連携、削除防止、コンプライアンス関連の処理です。単なる通知やログ記録よりも、「止まると業務が進まない」「誤操作を防げなくなる」「監査証跡が欠ける」機能を先に確認してください。
今回の更新で管理者が取るべき結論
Microsoft Entra アプリで登録した Remote Event Receivers は、Azure ACS 依存を避けるための一時的な仕組みであり、2027年7月1日以降も使える移行先ではありません。SharePoint Online で RER に依存しているアプリケーションは、SharePoint webhooks または Microsoft Graph change notifications への移行を前提に設計を見直す必要があります。
まず行うべきことは、RER を使っている可能性があるサイト、アドイン、外部連携、Microsoft Entra アプリ登録を棚卸しすることです。次に、同期イベントで操作を止めている処理と、非同期通知だけでよい処理を分けてください。通知だけでよい処理は webhooks へ移行しやすい一方、操作キャンセルや事前検証を行っていた処理は、権限設計、ライブラリ構成、入力フォーム、SPFx などを含めた再設計が必要です。
2027年7月1日を「対応開始日」ではなく「完全停止日」と捉え、早めに棚卸し、設計、実装、検証、旧機能停止まで進めることが、今回の更新で最も重要な管理ポイントです。
コメント