SharePoint Add-In retirement in Microsoft 365の要点は、Microsoft 365上のSharePoint Add-In拡張モデルが終了し、2026年4月2日以降は全テナントで動作しないという点です。新規テナントでは2024年11月1日から利用できなくなっており、既存テナントもすでに最終期限を過ぎています。代替としては、SharePoint Framework、Microsoft Entra ID、Microsoft Graph、SharePoint Webhooksなどへの移行が基本方針です。(Microsoft Learn)
SharePointだけの話に見えますが、OneDrive for BusinessのファイルやライブラリをSharePoint API、旧Add-In、Azure ACS認証経由で扱っているカスタム連携がある場合は確認が必要です。OneDrive同期クライアントそのものの廃止ではありませんが、「SharePoint上のコンテンツを古い仕組みで拡張・連携していないか」を棚卸しすることが重要です。
SharePoint Add-In retirement in Microsoft 365で何が変わったのか
SharePoint Add-Inは、SharePoint 2013時代から使われてきた拡張モデルです。ページ上に独自UIを表示したり、外部アプリケーションからSharePointサイトへ処理を戻したりする用途で利用されてきました。Microsoftはこのモデルを廃止し、今後はSharePoint Framework、Microsoft Entra ID、Microsoft Graphなどのより新しい開発モデルを使う方針を示しています。(Microsoft Learn)
今回の変更で特に重要なのは、単なる「非推奨」ではなく、すでに最終的な停止日を迎えていることです。
| 日付 | 変更内容 | 管理者・開発者への意味 |
|---|---|---|
| 2023年11月27日 | SharePoint Add-Inモデルが非推奨化 | 新規開発では採用しない。既存資産の棚卸しを開始する段階 |
| 2024年3月1日 | パブリックマーケットプレイスへの新規SharePoint Add-In登録受付を終了 | ベンダー提供Add-Inの新規公開に依存できない |
| 2024年7月1日 | パブリックマーケットプレイスからSharePoint Add-Inを取得不可 | 既存導入済みAdd-Inやテナントアプリカタログの確認が必要 |
| 2024年11月1日 | 新規テナントでSharePoint Add-Inが動作停止 | 新しいMicrosoft 365環境では旧Add-In前提の設計ができない |
| 2026年4月2日 | すべてのテナントでSharePoint Add-Inが動作停止 | 未移行のAdd-In、ACS依存、関連業務アプリは障害化する可能性が高い |
Microsoftの公式情報では、2026年4月2日の停止はGovernment Cloudsや米国国防総省環境を含むすべての環境に適用されると説明されています。(Microsoft Learn)
影響を受ける環境と受けない環境
影響を受けるのは、SharePoint Onlineで使われていたSharePoint Add-Inモデルです。大きく分けると、SharePoint-hosted Add-Inとprovider-hosted Add-Inの両方が対象になります。(Microsoft Learn)
SharePoint-hosted Add-Inは、インストール先サイトやAdd-In用のapp webにUI部品やデータを持つタイプです。典型例は、SharePointページ上にAdd-In Webパーツを表示するような実装です。一方、provider-hosted Add-InはSharePoint外部で動くアプリケーションがあり、Azure ACSを認証基盤としてSharePointへアクセスする構成です。(Microsoft Learn)
| 確認対象 | 影響 | 確認ポイント |
|---|---|---|
| SharePoint-hosted Add-In | あり | app web、Add-In Webパーツ、旧UI部品、Add-In内のリストデータ |
| Provider-hosted Add-In | あり | 外部ホストアプリ、Azure ACS、クライアントID、権限スコープ |
| Project Onlineで使うSharePoint Add-In | あり | Project OnlineはSharePoint Online上の拡張として同じ廃止パスの対象 |
| Azure ACSに依存するRemote Event Receiver | あり | ACS登録の場合は2026年4月2日でイベント発火に影響 |
| SharePoint Framework（SPFx） | なし | 推奨される代替技術として継続サポート |
| テナントアプリカタログ／サイトコレクションアプリカタログ | 一部あり | SPFx展開用途は継続。SharePoint Add-In展開は廃止対象 |
| SharePoint Serverオンプレミスのアプリカタログ | 基本的に対象外 | オンプレミスのアプリカタログ経由のAdd-In利用は廃止対象ではないが、パブリックマーケットプレイスからの取得は2026年4月以降不可 |
| CSOM／JSOMそのもの | 直接の廃止対象ではない | 継続利用は可能。ただし新規・更新ではMicrosoft GraphやSharePoint RESTの検討が推奨される |
SPFxは今回の廃止対象ではなく、SharePoint Add-Inの主要な代替技術です。App CatalogもSPFxソリューションの展開基盤としては継続利用できます。(Microsoft Learn)
OneDrive環境で見落としやすい確認ポイント
今回の公式告知が直接対象としているのはSharePoint Add-Inモデルです。そのため、OneDrive同期アプリや通常のOneDriveファイル共有機能がこの告知によって終了する、という意味ではありません。
ただし、企業環境ではOneDrive for Businessの実体がSharePoint Onlineの個人用サイトやドキュメントライブラリとして扱われるため、次のような仕組みがある場合は確認が必要です。
| OneDrive周辺で確認すべき例 | 確認理由 |
|---|---|
| OneDrive内のファイルを旧SharePoint Add-In経由で処理する業務アプリ | Add-InモデルやACS認証に依存している可能性がある |
| ユーザーのOneDriveライブラリを対象にした棚卸し、移動、分類、承認アプリ | SharePoint APIや旧認証方式を使っている場合がある |
| 外部SaaSがSharePoint／OneDriveのファイルへアクセスする連携 | ベンダー側がAdd-InモデルやACSから移行済みか確認が必要 |
| OneDrive上のファイル変更をトリガーにする旧イベント処理 | Remote Event ReceiverやACS依存が残っていないか確認する |
判断のポイントは、「OneDriveという名前の機能を使っているか」ではなく、裏側でSharePoint Add-In、Azure ACS、旧Add-In principalを使っていないかです。利用者からは普通のファイル操作に見えても、部門アプリや外部連携が古い認証・拡張モデルに依存していることがあります。
管理者が最初に確認すべきこと
まず実施すべきは、影響範囲の棚卸しです。Microsoftは、テナント内のSharePoint Add-In利用状況を確認する手段としてMicrosoft 365 Assessment toolの利用を推奨しています。このツールのSharePoint Add-In Reportでは、テナント内およびサイトごとのAdd-In、Add-Inの入手元、インストールしたユーザー、provider-hosted Add-Inで使われるAzure ACS principalや権限スコープを確認できます。(Microsoft Learn)
| 作業 | 確認する内容 | 実務上の注意点 |
|---|---|---|
| Microsoft 365 Assessment toolを実行 | テナント内のAdd-In利用状況 | 主要サイトだけでなく、部門サイトや古いプロジェクトサイトも対象にする |
| SharePoint Add-In Reportを確認 | Add-In名、サイト、入手元、インストール者 | 「誰も管理していないAdd-In」を洗い出す |
| テナントアプリカタログを確認 | 旧Add-Inパッケージの有無 | SPFxパッケージと混同しない |
| サイトコレクションアプリカタログを確認 | 個別サイトに展開されたAdd-In | 部門管理サイトに残りやすい |
| Microsoft Entra管理センターを確認 | ACS関連のEnterprise Applicationや権限 | 不要な高権限アプリが残っていないか確認する |
| ベンダー製品を確認 | SPFx版、Entra ID版、Graph対応版の有無 | 「最新版に更新済み」だけでAdd-In非依存とは限らない |
Azure ACS principalの削除や確認では、サイト単位の権限は_layouts/15/appprincipals.aspx、テナント権限はMicrosoft EntraのEnterprise Applicationsから確認・削除する流れが公式FAQで示されています。不要なACS app-onlyアクセスをテナント全体で無効化することも、業務上必要な利用が残っていないことを確認したうえでの推奨事項として説明されています。(Microsoft Learn)
開発者が選ぶべき移行先
SharePoint Add-In retirement in Microsoft 365への対応では、単に古いAdd-Inを作り直すだけでは不十分です。認証、UI、イベント処理、データ保存場所、権限設計を分けて見直す必要があります。
| 旧実装 | 主な移行先 | 判断基準 |
|---|---|---|
| SharePoint-hosted Add-In | SharePoint Framework Webパーツ／拡張機能 | SharePointページ内にUIを表示したい場合 |
| Provider-hosted Add-In | Microsoft Entra ID登録アプリ＋外部ホストアプリ | SharePoint外部で業務ロジックやAPIを動かす場合 |
| ACS app-only認証 | Microsoft Entra ID、Microsoft Graph、SharePoint REST | アプリ権限、委任権限、最小権限を再設計する |
| Add-In Webパーツ | SPFx Webパーツ | モダンページでの表示やMicrosoft 365との統合を重視する場合 |
| Remote Event Receiver | SharePoint Webhooks、Microsoft Graph change notifications | イベント通知を非同期処理に移行できるか確認する |
| JSOM中心のクライアント実装 | Microsoft Graph JavaScript SDK、PnPjs、SharePoint REST | 新規開発ではGraph優先。必要に応じてRESTやCSOMを併用 |
| SharePoint Add-In model Workflow Apps | Power Automate | 承認、通知、定型処理をローコードで置き換える場合 |
Microsoftのモダナイズガイダンスでも、SharePoint Add-InはSharePoint Frameworkへ、ACSを使うアプリ登録はAzure AD登録アプリへ、JSOMはGraph JS SDKやPnPjsへ、SharePoint WorkflowはPower Automateへ移行する対応関係が示されています。現在の名称では、Azure ADはMicrosoft Entra IDとして扱うのが自然です。(Microsoft Learn)
Remote Event Receiverを使っている場合の注意点
Remote Event Receiverは、SharePointのリストやライブラリの変更時に外部処理を呼び出す仕組みとして使われてきました。公式FAQでは、Azure ACSに依存するRemote Event Receiverは今回の廃止対象であり、ACSが無効になるとイベントが発火しなくなると説明されています。推奨される移行先はSharePoint Online WebhooksやMicrosoft Graph change notificationsです。(Microsoft Learn)
ここで注意したいのは、Remote Event ReceiverからWebhookへ置き換えると、処理モデルが変わることです。Webhookは非同期処理が基本です。そのため、従来のように「保存前に処理を止める」「条件に合わない更新をキャンセルする」といった同期的な制御はそのまま再現できない場合があります。
たとえば、機密フォルダーへの誤更新をRemote Event Receiverでブロックしていた場合、単純にWebhookへ置き換えるだけでは不十分です。代替策としては、フォルダーやライブラリの権限を見直す、保護対象データを別ライブラリに分離する、更新後に検知して自動修復・通知するなど、業務ルール側の再設計が必要になります。
なお、Entraアプリケーションで登録されたRemote Event Receiverについては、ACS登録のものとは異なる廃止パスが示されており、公式FAQでは2027年7月1日まで動作すると説明されています。ただし、MicrosoftはRemote Event ReceiverよりWebhookへの移行を強く推奨しています。(Microsoft Learn)
app webに保存されたデータはアンインストール前に退避する
SharePoint-hosted Add-Inでは、Add-In専用のapp webにリストや設定データを保存していることがあります。SPFxへ移行する場合、同じ場所に自動的にデータが引き継がれるとは限りません。公式FAQでは、app web内のデータを保持したい場合、SharePoint APIを使って必要なデータをコピーし、新しいアプリケーションで利用できる形式と場所に再作成する必要があると説明されています。(Microsoft Learn)
特に危険なのは、先にAdd-Inをアンインストールしてしまうことです。SharePoint Add-Inをアンインストールするとapp webも削除されるため、データ退避前に削除すると業務データを失う可能性があります。誤って削除した場合は、ごみ箱からAdd-Inを復元すればapp webも復元されると説明されていますが、移行計画では「アンインストールは最後」と決めておくべきです。(Microsoft Learn)
テナントで新規Add-In利用を止める設定
移行済みの環境や、これ以上旧Add-Inを増やしたくない環境では、SharePoint Online Management ShellのSet-SPOTenantを使ってSharePoint Add-Inの利用を無効化できます。
Connect-SPOService -Url https://<tenant>-admin.sharepoint.com
Set-SPOTenant -IsSharePointAddInsDisabled $trueこの設定を有効にすると、ユーザーはサイトにSharePoint Add-Inを追加できなくなり、管理者もテナントアプリカタログやサイトコレクションアプリカタログへ新しいSharePoint Add-Inを追加できなくなります。一方で、設定時点でサイトに追加済みのSharePoint Add-Inは利用可能なままと説明されています。(Microsoft Learn)
ただし、2026年4月2日の最終停止後は、Add-Inモデル自体が全テナントで停止対象です。この設定は「動かないAdd-Inを直すため」ではなく、移行過程や再導入防止、棚卸しの統制に使うものと考えるとよいでしょう。
ベンダー製SharePoint Add-Inを使っている場合の進め方
サードパーティ製品を使っている場合は、社内開発よりも早くベンダー確認を行うべきです。Microsoftは、パブリックマーケットプレイスやサードパーティから取得したSharePoint Add-Inについて、SharePoint Add-In拡張モデルに依存しない更新版があるか提供元へ確認することを推奨しています。(Microsoft Learn)
確認時は、単に「Microsoft 365対応版ですか」と聞くだけでは不十分です。次のように、廃止対象への依存を具体的に確認します。
| ベンダーに確認する質問 | 理由 |
|---|---|
| 現行版はSharePoint Add-Inモデルを使っていますか | 製品名が同じでも内部実装が変わっている場合がある |
| Azure ACSを使っていますか | ACS依存はSharePoint Add-In以外の連携にも残ることがある |
| SPFx版またはEntra ID認証版はありますか | 推奨移行先に沿った代替版か確認できる |
| app web内のデータ移行手順はありますか | アンインストール時のデータ消失を避けるため |
| 既存ページ、Webパーツ、権限、ワークフローへの影響はありますか | ユーザー影響を事前に洗い出すため |
| テスト環境での移行手順書は提供されますか | 本番移行前の検証に必要 |
「最新版へアップデート済み」という回答だけで安心せず、Add-InモデルやACSを使っていないことを明確に確認してください。
移行を進める実務手順
未対応の環境では、まず障害箇所を直す場当たり対応ではなく、影響範囲を短期間で切り分けることが重要です。おすすめの進め方は次のとおりです。
| 手順 | 作業内容 | 成果物 |
|---|---|---|
| 現状把握 | Microsoft 365 Assessment tool、アプリカタログ、部門サイトを確認 | Add-In一覧、影響サイト一覧 |
| 優先度付け | 業務停止、参照のみ、利用頻度低の3段階に分類 | 移行優先順位 |
| 所有者確認 | Add-Inごとの業務部門、開発元、ベンダーを特定 | 連絡先一覧 |
| 代替方針決定 | SPFx、Entra IDアプリ、Graph、Power Automateなどを選定 | 移行設計メモ |
| データ退避 | app webや旧リスト内のデータをコピー | 移行用データ |
| 権限再設計 | ACS権限を棚卸しし、Entra IDで最小権限化 | 権限設計書 |
| テスト展開 | 検証用サイトで新実装を確認 | テスト結果 |
| 本番切替 | ユーザー案内、ページ差し替え、旧Add-In停止 | 切替記録 |
| 後片付け | 不要なACS principal、旧Add-In、古いパッケージを整理 | 廃止完了リスト |
移行では、UIだけを置き換えるのではなく、認証と権限を同時に見直すことが重要です。旧Add-Inでは広い権限を与えていたものを、Entra IDやGraphの権限設計で最小化できれば、単なる延命ではなくセキュリティ改善にもつながります。
失敗しやすいポイント
「使っていないはず」と判断して棚卸しを省略する
SharePoint Add-Inは、情報システム部門が把握していない部門サイトや古いプロジェクトサイトに残っていることがあります。特に、フォーム、ダッシュボード、申請、一覧のカスタム表示、外部連携などは、利用者がAdd-Inと意識していないケースが多いです。
SPFxも止まると誤解する
SPFxは廃止対象ではありません。むしろSharePoint Add-Inの推奨代替技術です。公式FAQでも、SPFxは今回の廃止の影響を受けないと説明されています。(Microsoft Learn)
CSOMやJSOMがすべて使えなくなると誤解する
CSOMやJSOM自体は今回の廃止対象ではなく、継続利用できると説明されています。ただし、新規アプリケーションや既存アプリの更新では、Microsoft GraphやSharePoint REST APIを優先して検討することが推奨されています。(Microsoft Learn)
クライアントシークレットの更新だけで対応したつもりになる
期限切れのシークレット更新は一時的な認証エラー対策にはなりますが、Add-InモデルやAzure ACSへの依存そのものは解消できません。2026年4月2日以降の問題に対しては、Entra IDベースの認証や新しい拡張モデルへの移行が必要です。
Add-Inを先に削除してデータを失う
app webにデータがある場合、Add-Inのアンインストールによってapp webが削除されます。必ずデータ退避、移行先での復元確認、ユーザー受け入れ確認を済ませてから旧Add-Inを削除してください。(Microsoft Learn)
よくある質問
SharePoint Add-Inがまだ画面に見える場合はどう判断すべきですか
画面上に古いパーツやリンクが残っていても、裏側の処理が正常に動いているとは限りません。まずは、その機能がSharePoint Add-Inなのか、SPFxや別のWebアプリなのかを切り分けてください。サイト所有者への聞き取りだけでなく、Assessment tool、アプリカタログ、Entra IDのアプリ登録やEnterprise Applicationsを合わせて確認するのが安全です。
SharePoint Serverオンプレミスも対象ですか
SharePoint Serverオンプレミスのアプリカタログ経由で利用するSharePoint Add-Inは、今回のMicrosoft 365における廃止の直接対象ではありません。ただし、SharePoint Storeやパブリックマーケットプレイスからの取得は2026年4月以降できなくなると説明されています。(Microsoft Learn)
Project Onlineで使っているAdd-Inは対象ですか
対象です。Project OnlineはSharePoint Online上の拡張であり、Project Onlineで使われているSharePoint Add-InもSharePoint Online上のAdd-Inと同じ廃止パスに従うと説明されています。(Microsoft Learn)
OneDriveの通常利用に影響しますか
通常のOneDrive同期、共有、ファイル保存そのものの廃止ではありません。ただし、OneDrive上のファイルやライブラリをSharePoint Add-InやAzure ACSを使って処理している業務アプリ、外部連携、イベント処理がある場合は確認が必要です。
何から始めればよいですか
最初にやるべきことは、Microsoft 365 Assessment toolによる棚卸しです。そのうえで、業務影響が大きいAdd-Inから、SPFx、Entra IDアプリ、Microsoft Graph、SharePoint REST、Webhook、Power Automateなどへ移行方針を決めます。(Microsoft Learn)
まず実行すべきチェックリスト
未対応の管理者や開発者は、次の順番で対応してください。
- Microsoft 365 Assessment toolでSharePoint Add-In利用状況を確認する
- テナントアプリカタログとサイトコレクションアプリカタログを確認する
- 部門サイト、古いプロジェクトサイト、Project Onlineを確認する
- OneDrive連携を含む外部アプリがACSやAdd-In principalを使っていないか確認する
- app webに業務データがないか確認し、削除前に退避する
- ベンダー製品はSPFx版またはEntra ID認証版の有無を確認する
- カスタム開発はSPFx、Entra ID、Microsoft Graph、Webhook、Power Automateへの移行方針を決める
- 不要なACS principalや旧Add-Inを、業務影響確認後に整理する
SharePoint Add-In retirement in Microsoft 365は、古い拡張モデルを使い続けている環境にとって、すでに対応期限を過ぎた変更です。まずは「どこにAdd-InやACS依存が残っているか」を可視化し、業務影響の大きいものから移行・置き換え・廃止を進めてください。SharePointやOneDriveの利用者に見えている画面ではなく、裏側の認証方式、アプリカタログ、app web、イベント処理まで確認することが、トラブルを防ぐ最短ルートです。
コメント