SharePoint Onlineの「SharePoint アドイン」は2026年4月2日に完全廃止され、Project Online（PWA）にも影響します。さらにカスタムスクリプト制御の強化により、PDP編集やWebパーツ追加が突然できなくなるケースも。企業が“止まらない”ために、影響範囲の棚卸し・暫定回避・SPFx/Power Platform移行を具体策としてまとめます。
結論：Project Onlineは「放置＝現場が詰む」リスクが高い
まず結論から言うと、SharePoint アドイン廃止は「特定の拡張だけが止まる」話ではありません。Project OnlineはSharePoint Onlineの上に成り立っているため、SharePoint側の廃止・制限の影響を“そのまま”受けます。特に、アドイン（Add-In）で作った拡張・連携は2026年4月2日以降に動作しなくなり、Azure ACS（旧来の認証基盤）に依存した仕組みも同日までに作り替えが必要です。
加えて見逃せないのが「カスタムスクリプト制御」の強化です。Project Onlineでは“日常運用の延長”に見える操作（PDPへのカスタムフィールド追加など）でも、SharePoint側の制御に引っ掛かると編集内容が保存されない／Webパーツが見えないといった実害が出ます。
さらに状況を難しくしているのが、Project Online自体が2026年9月30日に退役（retire）するとMicrosoftが案内している点です。2026年4月のアドイン廃止は、その“退役前”に来るため、最終的に使い切るつもりの企業でも2026年4月を跨ぐ運用は手当てが必要になります。
まず押さえるべき公式スケジュール
| 日付 | 何が変わるか | Project Online（PWA）で起きやすい影響 | 企業がやるべきこと |
|---|---|---|---|
| 2023年11月27日 | SharePoint Add-In / Azure ACS が「非推奨」扱い | 新規投資が止まり、将来の廃止を前提に計画が必要 | 「使っているかどうか」を棚卸しし、廃止日を前提にロードマップ化 |
| 2024年3月1日 | ストアへの新規Add-In登録受付が停止 | 新規導入の選択肢が縮小 | 購入予定のアドインはベンダーに移行版（SPFx等）の提供計画を確認 |
| 2024年7月1日 | ストアからAdd-Inを取得できなくなる | 追加導入・横展開が難しくなる（条件次第で例外あり） | テナント内の導入状況を整理し、必要なら“早めに”導入・代替検討 |
| 2024年11月1日 | 新規テナントではAdd-In/ACSが動作しない | 新規テナント移行・新規導入で拡張が再現できない | 新規テナント前提のプロジェクトでは最初からSPFx/Entra前提で設計 |
| 2025年10月1日 | Project Online単体SKUが新規販売終了（新規顧客向け） | 契約更新・ライセンス戦略の再検討が必要 | 現行契約の形態を確認し、代替製品への移行計画を前倒し |
| 2026年4月2日 | SharePoint Add-Inが全テナントで停止／Azure ACSも停止 | アドイン拡張・ACS依存連携が“確実に止まる” | この日までにSPFx/Entra/Power Platform等へ置き換え完了 |
| 2026年9月30日 | Project Onlineが退役 | PWA自体が終了するため、最終移行が必須 | Planner（Premium含む）/ Project Server SE / D365 Project Operations等を比較し決定 |
この表の読み方はシンプルです。2026年4月2日は「拡張（Add-In/ACS）が止まる締切」、2026年9月30日は「Project Onlineそのものが終わる締切」です。これを同時に逆算しないと、現場は“直前で詰む”確率が上がります。
なぜProject Onlineが直撃を受けるのか
Microsoftの公式ドキュメントでは、Project OnlineはSharePoint Onlineの上に成り立つ拡張であり、SharePoint Add-Inの廃止はProject Onlineにも同じように適用される、と整理されています。つまり「Project Onlineだから例外」という扱いは基本的に期待できません。
さらに、認証基盤のAzure ACSもSharePoint Online向けが2026年4月2日に完全停止するため、Provider-hosted型Add-Inや、SharePointの“ACS App-Only”に依存する自動化・連携がある場合は、同日までにMicrosoft Entra ID（旧Azure AD）へ移行が必要です。
「標準機能が使えない」と感じやすい症状
Project Onlineの現場で特に困りやすいのは、「壊れる」というより変更できないタイプの影響です。MicrosoftのProject Support Blogでは、SharePoint Onlineのカスタムスクリプト設定変更がProject Online（PWA）にも影響し、以下のような症状が報告されると整理されています。
| 症状 | 現場の困りごと | 背景にある要因 | 暫定対応の方向性 |
|---|---|---|---|
| PWA Webパーツがカテゴリに表示されない | 既存ページの編集・追加ができず、情報の見せ方を変えられない | カスタムスクリプト制御により、編集時の機能がブロックされる | SharePoint管理者が一時的に許可して編集する運用へ |
| 「サイトをテンプレートとして保存」が消える | 標準テンプレート運用が崩れ、展開・再利用が難しくなる | 同上 | 必要な作業時だけ許可し、作業後に戻す |
| Script Editor / Content Editor Webパーツを追加できない | PWAに独自機能（ボタン等）を乗せる運用が破綻 | 同上（編集時にスクリプト挿入可能なため制限） | SPFx/Power Apps等で再構成（恒久対応） |
| PDPに追加したカスタムフィールドが「反映されない」 | 新規カスタムフィールドを作っても画面に載せられず、運用が詰まる | 編集が許可されないため、変更が“保存されない”挙動になり得る | 編集のための許可プロセスを整備し、改修窓口を一本化 |
| 上記を自動化していたサードパーティが動かない | 無人運用が崩れ、手作業が増える／期限に間に合わない | 自動化が同じ制御に引っ掛かる | ベンダーへ移行版・代替手段を確認し、段階移行 |
重要なのは、「閲覧や日常操作は動くことが多いが、変更（編集・追加）が詰まる」という点です。Project Support Blogでも、既存のカスタムスクリプトが即座に全面停止するというより、上記のような“変更系”に追加の解除（unblock）が必要になる、と説明されています。
短期の現実解：PWAサイトで「一時的に許可して編集する」運用を作る
現時点での短期対応は、SharePoint側のカスタムスクリプト制御を理解し、PWAサイトで編集が必要な時間帯だけ一時的に許可する運用を作ることです。ここを曖昧にすると、PWA管理者が編集できずに現場が止まります。
PowerShellでの典型例（テナント側の設定）
Project Support Blogでは、SharePoint Management Shellの特定バージョン以降で、制御の挙動に関するテナント設定を操作できる旨が記載されています。実施前にセキュリティ上の注意点を理解する必要がある点も明示されています。
Connect-SPOService -Url https://<tenantname>-admin.sharepoint.com
Set-SPOTenant -DelayDenyAddAndCustomizePagesEnforcement $TruePowerShellでの典型例（PWAサイト単位の許可）
Connect-SPOService -Url https://<tenantname>-admin.sharepoint.com
Set-SPOSite <SiteURL> -DenyAddAndCustomizePages 0SharePoint管理センターでの典型例（GUI）
GUIでも、SharePoint管理センターの「アクティブなサイト」から該当サイトを選び、設定タブでカスタムスクリプトをBlocked→Allowedに切り替える手順が示されています。作業後に元に戻す（あるいは自動で戻る）設計である点を踏まえ、変更作業の“窓”を作って管理するのが現実的です。
おすすめの運用設計（そのまま社内標準にできる形）
- 「PDP編集／Webパーツ追加」の申請窓口を一本化（誰がいつ解除するのか不明だと監査で困る）
- 変更作業の時間帯を固定（例：毎週水曜 16:00〜18:00）し、SharePoint管理者が関与しやすくする
- 作業後は“許可状態を戻す”（もしくは戻る前提の手順にする）
- 変更ログを残す（何をPDPに追加したか、いつ誰が許可したか）
この運用は“暫定”ですが、2026年4月までの移行期間を支える土台になります。「編集できない」状態を放置するより、短期でもルール化して事故を減らすのが先です。
SharePoint アドイン廃止の本題：何が止まるのか
SharePoint Add-Inは、2024年11月1日以降は新規テナントで動作せず、2026年4月2日には全テナントで動作しなくなります。またストア経由の取得は2024年7月1日以降できません。Project OnlineでAdd-Inを使って拡張している場合も同じです。
さらにAdd-Inには大きく2タイプがあり、置き換え方針も変わります。Microsoft Learnでは、SharePoint-hosted型は主にUX要素（Webパーツ等）を提供し、Provider-hosted型はSharePoint外部で動くサービスで、SharePointへの戻り通信にAzure ACSを利用する、と整理されています。
| Add-Inのタイプ | Project Onlineでよくある使い方 | 2026/4/2以降の状態 | 推奨される置き換え | 移行の注意点 |
|---|---|---|---|---|
| SharePoint-hosted | ページ上に表示するWebパーツ、簡易UI、リストベースの機能 | 動作停止 | SPFx Webパーツとして再実装 | App Webにデータがある場合は移行設計が必要 |
| Provider-hosted | 外部サービス（ポータル等）＋SharePoint連携、イベント連動 | 動作停止（ACS依存も同時に締切） | 外部サービス＋Microsoft Entra ID認証＋必要ならSPFxでUI統合 | ACS App-Only/Remote Event Receiver等の依存を洗い出す |
地味に重要：App Webのデータは「消える前に」救出計画が必要
SharePoint-hosted Add-InがApp Web（Add-In専用のWeb）にデータを保存している場合、SPFxに置き換える際にデータの置き場所が変わります。Microsoft LearnのFAQでは、Add-InをアンインストールするとApp Webが削除されるため、必要なデータは削除前に取得して移行する必要がある、と注意されています。
イベント連動（Remote Event Receiver等）は要警戒
FAQでは、Remote Event Receiverもこの廃止の対象であり、Azure ACSに依存するものは2026年4月2日で動かなくなる、と整理されています。イベント連動で業務ルールを実装していた場合、SharePoint Online WebhooksやMicrosoft Graphの変更通知へ設計変更が必要になり得ます。
最優先タスク：影響範囲を“数字で”可視化する（アセスメント）
「うちはアドイン使ってないはず」という状態が一番危険です。Microsoftは、テナント内のAdd-In利用を把握するためにMicrosoft 365 Assessment toolの利用を推奨しており、スキャン結果をPower BIレポートで確認できます。
SharePoint Add-In向けアセスメントで分かること
- テナント内／サイト別に、どのAdd-Inが存在するか
- 取得元（ストア、App Catalogなど）や、誰がインストールしたか
- Provider-hostedの場合、利用しているAzure ACSプリンシパルや権限スコープ
Azure ACS向けアセスメントで分かること
- 利用中のAzure ACSアプリケーションプリンシパル（権限スコープ、App-Only可否など）
- 各プリンシパルがアクセス可能なサイト一覧
この棚卸しを先にやる理由は、移行の議論を「感覚」から「事実」に変えるためです。どのPWAサイトに何が入っているかが分かれば、移行の優先順位（止まったら困る順）を決められます。
優先順位の付け方：影響度×置き換え難易度で“捨てるもの”も決める
| 分類 | 例 | おすすめ判断 | アクション |
|---|---|---|---|
| 影響度：高 / 難易度：低 | 特定ページに表示するだけのWebパーツ | 早期に置き換え | SPFxで再実装、モダンページへ寄せる |
| 影響度：高 / 難易度：高 | 認証（ACS）＋外部サービス＋イベント連動 | 最優先プロジェクト化 | Entra ID化、API設計、Webhook/通知の再設計 |
| 影響度：低 / 難易度：低 | 使われていない部門向け小機能 | 廃止の検討 | 利用実態を確認し、削除・統合 |
| 影響度：低 / 難易度：高 | 古い拡張で誰も仕様を説明できない | “作り直す前に”止める | 影響調査→停止→問い合わせが出たら必要性を再評価 |
ここでのポイントは、全部を同じ熱量で救おうとしないことです。廃止日が固定されている以上、優先順位付けとスコープ調整は避けられません。
「標準機能」を企業向けにどう維持するか：3つの現実解
質問者の本音は「Project Onlineの標準機能が、SharePoint側の廃止で使えなくなるのでは？」という不安です。これに対する企業側の現実的な答えは、次の3パターンになります。
現実解1：運用で“編集の詰まり”を回避しつつ、変更頻度を下げる
- PDPやページ編集は、SharePoint管理者が関与する変更手順に寄せる
- 2026年4月までに必要なカスタムフィールド定義を固め、以降の変更を抑える
- 「変更できない」状況を前提に、改修依頼の導線を整える
これは延命策ですが、短期的に現場を止めない効果があります。
現実解2：標準画面に固執せず、SPFx / Power Platformで“必要な画面”を作り直す
- SharePoint-hosted型のUIはSPFx Webパーツ化が王道
- 入力・承認・表示といった業務画面はPower Appsで再構成し、Power Automateで周辺自動化
- 外部サービスがある場合はEntra IDで保護し、SharePoint側にはSPFxで薄いUIを置く
「PDPの中で全部やる」発想から、「業務に必要なUIを安全な方法で再構成する」発想へ切り替えると、移行の選択肢が増えます。
現実解3：Project Online退役（2026/9/30）を前提に、移行先を決めて段階移行する
MicrosoftはProject Onlineの退役日と、移行先の選択肢（PlannerのBasic/Premium、Project Server Subscription Edition、Dynamics 365 Project Operations、Project desktopなど）を案内しています。2026年4月のアドイン廃止は「移行までの間に拡張が止まる」問題なので、最終的には移行先を決めない限り“根治”しません。
移行先を検討する際の比較軸（Project Onlineの穴を埋めるために）
| 比較軸 | Planner（Basic/Premium） | Project Server Subscription Edition | Dynamics 365 Project Operations |
|---|---|---|---|
| 狙い | 日々の作業管理・コラボ中心（モダン体験） | Project Onlineに近いPPM/計画・スケジュール・リソース管理 | タイムシート、リソーススケジューリング、プロジェクト遂行＋財務 |
| 移行の現実味 | 小〜中規模の段階移行がしやすい | 既存のPMO/PPM運用を保ちやすい | 業務プロセス含めた再設計になりやすい |
| 注意点 | 企業向け要件（権限・ポートフォリオ等）とのギャップ評価が必須 | 基盤が別物（SharePoint Server系）になるため、運用体制を確認 | ライセンス/導入規模が大きくなりがち |
ここで大事なのは「機能の多寡」ではなく、自社の業務（承認、権限、ガバナンス、レポート、監査）に乗るかです。Project Onlineを長年使っている企業ほど、周辺の作り込みが多いので、移行先の“標準機能”に合わせて業務を見直す部分が必ず出ます。
ロードマップ例：廃止日から逆算して、やることを固める
| フェーズ | 到達目標 | 具体タスク | 成果物 |
|---|---|---|---|
| 棚卸し | 影響範囲が“見える” | Assessment toolでAdd-In/ACSをスキャン、PWAサイトの編集依存を洗い出し | 影響リスト、優先順位表 |
| 暫定運用整備 | 編集が止まらない | カスタムスクリプト許可の申請・実施・復旧の手順化、変更窓の設定 | 運用手順書、変更記録テンプレ |
| 置き換え設計 | 2026/4/2を跨げる | Add-Inをタイプ別にSPFx/Entra/Power Platformへ置き換え、データ移行設計（App Web含む） | アーキテクチャ図、実装計画 |
| 移行先決定 | 2026/9/30までの移行が現実的 | Planner/Project Server SE/D365 PO等を比較、PoC、パイロット、移行方式決定 | 移行ロードマップ、PoC結果 |
| 移行実行 | Project Online退役に間に合う | 段階移行、ユーザートレーニング、並行稼働、カットオーバー | 新環境、本番移行完了 |
よくある落とし穴チェックリスト
- 「Add-Inは使ってない」前提で進めてしまう（実は部門サイトで入っている）
- ACS App-Onlyでの連携を見落とす（止まるのはAdd-Inだけではない）
- App Webに保存されたデータの扱いを後回しにする（アンインストール後に消えて詰む）
- Remote Event Receiver等のイベント依存を放置する（廃止後に業務が動かない）
- PWA管理者だけで完結すると思い込む（SharePoint管理者の関与が必要な作業が増える）
まとめ：2026年4月は「拡張の締切」、2026年9月は「Project Onlineの締切」
SharePoint Add-InとAzure ACSの完全停止は2026年4月2日、Project Onlineの退役は2026年9月30日です。これらは別々の問題ではなく、同じロードマップ上で同時に解く必要があります。
最短で現場の混乱を抑える順番は、①アセスメントで事実を出す → ②編集が止まらない暫定運用を整える → ③SPFx/Entra/Power Platformへ置き換える → ④移行先を確定して段階移行です。特に②がないと、移行中に“変更できない”障害でプロジェクトが進まなくなります。
「Microsoftの対応方針が見えないから待つ」よりも、廃止日が確定している領域（Add-In/ACS/Project Online退役）から逆算して、社内の意思決定を先に進めることが、結果的にコストとリスクを最小化します。
コメント