2026年4月2日、Microsoftはとうとう引き金を引いた。SharePoint Add-Ins、ACS（Azure Access Control Services）、ドメイン分離Webパーツ（Domain Isolated Web Parts）、そしてSharePoint 2013ワークフローの4コンポーネントが正式廃止となった。予告は何年も前から出ていたが、それでも対応が追いついていないテナントはまだある。今回の廃止はもはや「予告」ではなく「実行」だ。

廃止された4コンポーネントの概要

SharePoint Add-Ins（旧称 Apps for SharePoint）

SharePoint 2013時代に導入されたアドインモデル。サードパーティ製のカスタム機能をSharePointに追加する仕組みとして広く使われてきたが、クラウド時代には明らかに設計が古すぎた。後継はSharePoint Framework（SPFx）。

ACS（Azure Access Control Services）

SharePointと外部サービスを連携させるための認証基盤。「高信頼アドイン」と呼ばれるServer-to-Server認証で長年使われてきた。今後はMicrosoft Entra ID（旧Azure AD） を使ったOAuth 2.0ベースの認証に完全移行する必要がある。

ドメイン分離Webパーツ（Domain Isolated Web Parts）

SPFxのWebパーツを独立ドメインのiframeで分離実行する機能。セキュリティ上の理由で設計されたが、複雑さの割にメリットが限定的だったためMicrosoft自身が廃止を決断した。

SharePoint 2013ワークフロー

2013年当時のワークフローエンジン。オンプレミス時代の産物であり、クラウドネイティブなフローとは根本的に設計が異なる。移行先はPower Automate一択。

移行先と実務での作業ポイント

1. Add-Ins → SPFx移行

  • まず現環境のアドイン一覧を棚卸しする（SharePoint管理センター→アプリカタログで確認可能）
  • カスタム開発したアドインはSPFxのReactベースWebパーツへ再実装
  • サードパーティ製アドインはベンダーにSPFx版への移行確認を取る
  • SPFx 1.18以降を使う場合はNode.js 18のLTS環境が必要

2. ACS → Entra ID（旧Azure AD）移行

  • Get-SPOTenantコマンドレットでDisableCustomAppAuthenticationの状態を確認
  • アプリ登録をEntra IDに移し、クライアントシークレットまたは証明書で認証するよう変更
  • .NETやCSOMを使っている場合はPnP.PowerShellまたはMicrosoft Graph SDKへの切り替えを検討

3. 2013ワークフロー → Power Automate移行

  • Power Automateの「SharePointリストのアイテムが作成されたとき」トリガーを起点に再設計
  • 承認フローは承認アクションを使うとほぼそのまま再現できる
  • 移行ツール「SharePoint Migration Tool（SPMT）」はワークフロー移行には使えない点に注意。手動での再設計が必要

4. 情報保護関連はPurviewへ

  • ドキュメントのラベリングや保持ポリシーはMicrosoft Purviewに一元化する方向で整理する

日本のIT現場への影響

日本企業では2013〜2016年ごろにオンプレミスのSharePoint環境を整備し、その後クラウド移行を行ったが「設定だけ移してカスタマイズは放置」というパターンが非常に多い。特に製造業・金融・官公庁系のSIer案件では、Add-InsやACSを使ったカスタム認証ポータルが今でも現役で動いていることがある。

廃止後の挙動としては、テナントによっては即座に動作不能になるケース、しばらくは動くが新規追加不可になるケースなど差がある。いずれにせよ「今日は動いているから大丈夫」は通用しなくなった。影響調査を先送りにしているIT管理者は、今すぐアドイン棚卸しを始めるべきだ。

筆者の見解

ぶっちゃけ、「なんで今さら」という感情が先に来る。ACSの廃止予告は2023年、Add-Insの廃止予告は2024年からずっと出ていた。にもかかわらず未対応のテナントが残っているのは、SIerが「動いているものを触るな」文化で提案を避けてきたからだと思う。その結果、今頃になって慌てて移行対応が走る。日本のIT業界の悪い癖がここにも出ている。

技術的には、この廃止は正しい判断だ。ACSはOAuth 2.0どころかモダン認証の概念すら存在しなかった時代の産物で、セキュリティの観点からいえばさっさと消えてほしかった。2013ワークフローも同様——あのXAMLベースのワークフローエンジンは、Power Automateと比べて設計が複雑すぎて保守地獄になりがちだった。

Microsoftにはここ数年でかなり失望しているが、こういうレガシー整理の断行は評価している。Copilotで失った信頼とは全く別の話だ。プラットフォームをクリーンに保つ意志は感じる。

SPFxとPower Automateへの移行が完了したテナントは、次のステップとしてMicrosoft Graph APIの活用を検討してほしい。Add-Ins時代の「SharePointだけで完結」という発想を捨てて、Teams・Entra ID・Purviewを含めた統合プラットフォームとして使い倒す——それが今のMicrosoft 365の正しい使い方だ。バラバラに使っていたら本当にもったいない。

出典: この記事は SharePoint Add-Ins, ACS, Domain Isolated Web Parts, and 2013 Workflows Retirement — April 2, 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。