SharePoint Framework（SPFx）の2026年4月ロードマップ更新で最も重要なのは、SPFxがSharePoint単体のカスタマイズ基盤から、Microsoft 365全体のAI活用・業務統合・ポータル体験を支える開発基盤へ進みつつあるという点です。
今回の公式更新では、SPFx 1.23のリリース候補、SPFx CLIへの移行、リスト／ライブラリ拡張、AI関連機能の予告、React 18対応の見通しなどが示されました。管理者は「既存SPFx資産の棚卸し」、開発者は「1.23 RCの検証とCLI移行準備」、製品ウォッチャーは「SPFxがMicrosoft 365 CopilotやAIエージェント時代の拡張基盤としてどう位置付けられるか」を見るべき更新です。(Microsoft for Developers)
SharePoint Framework（SPFx）の2026年4月ロードマップ更新で何が変わったか
2026年4月28日にMicrosoft 365 Developer Blogで公開された「SharePoint Framework (SPFx) roadmap update – April 2026」は、単なるバージョンアップ告知ではありません。SPFxの今後の方向性として、次の3点が明確になりました。
- SPFx 1.23がリリース候補段階に到達
- Yeoman Generator中心の開発体験から、SPFx CLI中心の開発体験へ移行
- AIを活用したSharePoint／Microsoft 365ソリューションに向けた機能が準備中
特に注目すべきなのは、MicrosoftがSPFxを「SharePointのWebパーツ開発ツール」だけでなく、Microsoft 365内で業務アプリ、ポータル、AI支援型UIを作るための拡張基盤として扱っている点です。
これまでSPFxは、SharePoint Online上のWebパーツ、拡張機能、リスト操作などで利用されることが多い技術でした。今後はSharePoint、Microsoft Graph、SharePoint Embedded、Microsoft 365 Copilot、AIエージェントなどとの接点が増え、より広いMicrosoft 365開発の中心に近づいていくと考えられます。(Microsoft for Developers)
今回の更新で押さえるべきポイント
今回のロードマップ更新を実務視点で整理すると、特に重要なのは以下の項目です。
| 項目 | 内容 | 影響を受ける読者 |
|---|---|---|
| SPFx 1.23 RC | リストビューコマンドセットのグループ化、SPFx CLIプレビュー、npm audit対応 | 開発者、運用担当 |
| SPFx CLI | 従来のYeoman Generatorを置き換える新しいCLIとして登場 | 開発者、開発基盤担当 |
| テンプレートのオープンソース化 | 企業独自テンプレートやプロジェクト別テンプレートの活用がしやすくなる | 開発チーム、SIer |
| SPFx 1.24 | AI関連機能のパブリックプレビューが予定 | 開発者、製品企画担当 |
| SPFx 1.25 | AI関連機能のGA、ナビゲーションカスタマイザー、SPFx CLI GAが予定 | 管理者、開発者 |
| React 18対応 | 重要テーマだが、時期はまだ確定していない | フロントエンド開発者 |
MicrosoftはSPFxのリリースサイクルを四半期ごとに進める方向を示しており、今後はロードマップを見ながら検証・移行計画を立てる重要性が高まります。(Microsoft for Developers)
SPFx 1.23は安定性と開発体験の改善が中心
SPFx 1.23は、派手な新機能だけでなく、既存ソリューションの安定性や開発体験を整えるための更新が中心です。公式ブログでは、1.23がリリース候補の状態にあり、GAは2026年5月上旬を見込んでいると説明されています。(Microsoft for Developers)
主な内容は次の3つです。
リストビューコマンドセットのグループ化
SPFx 1.23では、リストビューコマンドセットでグループ化をサポートする予定です。これにより、SharePointリストやライブラリのツールバー、コンテキストメニューに表示するコマンドを、より整理して配置しやすくなります。(Microsoft Learn)
たとえば、これまで個別に並んでいた操作を次のようにまとめられます。
| 業務シーン | グループ化の例 |
|---|---|
| 契約書管理 | 「承認」「差し戻し」「法務確認依頼」を1つの業務操作グループにまとめる |
| 社内申請 | 「申請内容を確認」「ステータス変更」「関連部署へ通知」をまとめる |
| ファイル管理 | 「分類」「アーカイブ」「監査ログ確認」を管理者向け操作としてまとめる |
実務では、コマンドが増えすぎるとユーザーが目的の操作を探しにくくなります。グループ化はUIを整えるだけでなく、誤操作の防止や業務フローの理解にも役立ちます。
npm audit対応の継続
SPFx 1.23では、npm auditで報告される脆弱性への対応も継続されています。Microsoftは、npm auditの問題は継続的に対応が必要な領域として扱っており、各リリースで改善を進める方針です。(Microsoft Learn)
開発現場では、SPFxプロジェクトを作成した時点で大量のnpm audit警告が出ると、セキュリティレビューや社内申請で説明が必要になることがあります。今回の対応は、エンタープライズ環境でSPFxを採用しやすくするための土台作りと見てよいでしょう。
ただし、npm auditの警告がゼロになることを前提に運用するのは現実的ではありません。重要なのは、次のようにリスクを分けて判断することです。
| 確認項目 | 判断の目安 |
|---|---|
| 脆弱性が実行時に影響するか | ビルド時のみの依存関係か、本番コードに含まれるかを確認 |
| 修正版が提供されているか | SPFx公式更新、npmパッケージ更新、回避策を確認 |
| 自社環境で悪用可能性があるか | 認証、権限、公開範囲、実行条件を確認 |
| 監査対応が必要か | セキュリティ部門に説明できる記録を残す |
SPFx 1.23 RCは本番投入前の検証対象
SPFx 1.23のプレビューリリースノートでは、現時点のバージョンはテスト用であり、本番環境では公式に推奨されるSPFxバージョンを使用するよう注意されています。(Microsoft Learn)
そのため、SPFx 1.23 RCは「すぐ本番に入れるもの」ではなく、次のような検証に使うのが現実的です。
- 既存Webパーツがビルドできるか
- 既存拡張機能の表示や動作に影響がないか
- リストビューコマンドセットの表示が期待通りか
- npm auditの状況が改善するか
- 新しいSPFx CLIで既存の開発フローを置き換えられるか
開発チームは、検証用テナントや検証用サイトで1.23 RCを試し、GA後に本番適用するかを判断する流れが安全です。
SPFx CLIへの移行は開発チームにとって大きな変化
今回の更新で特に開発者に影響が大きいのが、SPFx CLIです。
SPFxでは長くYeoman Generatorを使ってプロジェクトを作成してきました。しかし、Microsoftは新しいオープンソースのSPFx CLIをプレビューとして提供し、将来的にはYeoman Generatorに代わる足場作成ツールとして位置付けています。(Microsoft for Developers)
SPFx CLIで何が変わるのか
SPFx CLIのポイントは、単にコマンドが変わることではありません。より重要なのは、テンプレートやプロジェクト作成の仕組みが柔軟になることです。
| 観点 | 従来のYeoman Generator | 新しいSPFx CLI |
|---|---|---|
| プロジェクト作成 | Yeoman Generatorを利用 | spfx createなどのCLIを利用 |
| テンプレート | Microsoft提供の生成形式に依存しやすい | オープンソーステンプレートを活用可能 |
| 企業独自テンプレート | カスタマイズには工夫が必要 | 代替テンプレートや社内標準テンプレートを使いやすい |
| リリースとの関係 | SPFxバージョンとの結び付きが強い | CLI自体をSPFxリリースから切り離す方向 |
この変更は、複数のSharePoint開発プロジェクトを抱える企業やSIerにとって大きな意味があります。
たとえば、社内標準として以下を含むテンプレートを用意しやすくなります。
- 共通のフォルダー構成
- 社内標準のESLint設定
- ログ出力の共通処理
- Microsoft Graph呼び出しの共通ラッパー
- 多言語対応の初期構成
- CI/CD向け設定ファイル
- セキュリティレビュー用のREADMEテンプレート
これにより、新規プロジェクトごとに同じ設定を手作業で入れる必要が減ります。開発品質のばらつきを抑え、レビューや保守もしやすくなります。
いきなり全面移行しないことが重要
SPFx CLIは今後の中心になる可能性が高い一方で、2026年4月時点ではプレビュー段階です。MicrosoftはSPFx CLIのGAを今後のロードマップに含めていますが、現時点で既存プロジェクトを急いで全面移行する必要はありません。(Microsoft for Developers)
実務では、次のような段階的な進め方が向いています。
| フェーズ | やること |
|---|---|
| 検証 | 小さなWebパーツをSPFx CLIで作成し、ビルド・デプロイを確認 |
| 比較 | Yeoman Generatorで作ったプロジェクトとの差分を確認 |
| 標準化 | 社内で必要なテンプレート項目を洗い出す |
| 試験導入 | 新規の小規模案件でSPFx CLIを試す |
| 本格移行 | GA後、社内標準手順やCI/CDに組み込む |
失敗しやすいのは、「新しいCLIが出たから既存の全案件をすぐ切り替える」ことです。既存案件では依存パッケージ、ビルド環境、Node.jsバージョン、CI/CD設定が絡むため、まずは新規プロジェクトで検証するのが安全です。
AI関連機能はSPFx 1.24でパブリックプレビュー予定
今回の公式更新では、詳細はまだ公開されていないものの、AIに関する新機能がSPFx 1.24でパブリックプレビューに入る予定であることが示されています。Microsoftは、この機能をSharePointやMicrosoft 365ソリューション内で、よりインテリジェントで支援的な体験を構築するためのものと説明しています。(Microsoft for Developers)
ここで注意したいのは、現時点では具体的な機能名や仕様が公開されていないことです。そのため、「SPFxで何でもAI化できる」といった過度な解釈は避けるべきです。
一方で、Microsoft 365全体の流れを見ると、SPFxがAI時代のUI拡張基盤として重要になる可能性は高いです。たとえば、次のような使い方が考えられます。
- SharePointポータル上で、部門別に必要な情報を提示するAI支援型Webパーツ
- 社内文書やリストデータをもとに、次の作業を案内する業務支援UI
- Microsoft GraphやSharePointのデータを使った、コンテキストに応じた情報表示
- Microsoft 365 Copilotやエージェントと連携する業務画面
ただし、AI機能を業務に組み込む場合は、UIの便利さだけでなく、権限、データ保護、誤回答時の責任範囲、監査ログの扱いまで考える必要があります。
SPFx 1.24と1.25のロードマップを整理
公式ブログでは、今後のSPFxリリース予定として1.23、1.24、1.25の方向性が示されています。ロードマップは変更される可能性がありますが、開発計画を立てるうえで重要な目安になります。(Microsoft for Developers)
| バージョン | 予定時期 | 主な内容 |
|---|---|---|
| SPFx 1.23 | 2026年5月 | コマンドセット改善、SPFx CLIプレビュー、テンプレートのオープンソース化、新規／編集パネルのオーバーライド、npm audit対応 |
| SPFx 1.24 | 2026年6月 | AI関連機能のパブリックプレビュー、npm audit対応 |
| SPFx 1.25 | 2026年9月 | AI関連機能のGA、ナビゲーションカスタマイザー、SPFx CLI GA、更新版Yeoman Generatorの最終バージョン |
特にSPFx 1.25では、SPFx CLIがGAになる予定であり、Yeoman GeneratorからSPFx CLIへ足場作成の中心が移る流れがより明確になります。(Microsoft for Developers)
React 18対応は重要だが、時期はまだ確定していない
フロントエンド開発者にとって気になるのがReact 18対応です。
公式ブログでは、React 18対応は重要な検討事項として挙げられています。ただし、以前のコミュニケーションでは2026年6月を見込んでいたものの、現時点ではスケジュールを確定できないと説明されています。理由として、Microsoft標準のWebパーツをReact 18レベルに更新する作業が進行中であり、それが完了するまでカスタムWebパーツ側だけで有効化することはできない、という事情が示されています。(Microsoft for Developers)
つまり、React 18対応については次のように判断するのが現実的です。
| 立場 | 取るべき対応 |
|---|---|
| 新規SPFx開発者 | React 18前提で設計しすぎず、現行サポート範囲を確認する |
| 既存Webパーツ運用者 | React依存ライブラリのバージョンを棚卸しする |
| フロントエンドリード | React 18対応時に影響が出るUIライブラリやHooks利用状況を確認する |
| 管理者 | React 18対応を理由にした大規模改修は、正式情報を待って計画する |
React 18対応は歓迎すべき流れですが、未確定情報を前提にリリース計画を組むと手戻りが発生します。今やるべきことは、移行作業そのものではなく、依存関係の把握と影響範囲の見える化です。
管理者が今すぐ確認すべきこと
SharePoint管理者やMicrosoft 365管理者は、SPFxのコードを直接書かない場合でも、今回のロードマップ更新を無視しないほうがよいです。SPFxはサイトのUI、リスト操作、業務ポータル、拡張機能に関わるため、開発チームだけの問題ではありません。
特に確認したいのは、次の項目です。
既存SPFxソリューションの一覧化
まず、テナント内でどのSPFxソリューションが使われているかを把握します。
確認すべき情報は次の通りです。
| 確認項目 | 理由 |
|---|---|
| ソリューション名 | 影響調査の単位になる |
| 利用サイト | 重要業務サイトかどうかを判断する |
| 開発元 | 内製、外部ベンダー、過去案件の区別が必要 |
| 使用しているSPFxバージョン | アップデート方針を決める材料になる |
| 最終更新日 | 保守されているか判断できる |
| 利用している権限 | Microsoft Graphや外部API連携の確認に必要 |
古いSPFxソリューションが放置されている場合、将来の更新時にビルドできない、依存パッケージが更新できない、担当者が不明といった問題が起こりやすくなります。
AI機能を入れる前にデータ境界を整理する
SPFxでAI支援型のポータルやWebパーツを作る場合、最初に整理すべきなのは「どんなAI機能を入れるか」ではなく、「どのデータを誰に見せてよいか」です。
特にSharePointでは、サイト、ライブラリ、リスト、ファイル単位で権限が分かれます。AI機能が便利になるほど、誤って広い範囲の情報を参照・表示するリスクも高まります。
AI活用を検討する前に、次の観点を確認しておくと安全です。
| 観点 | 確認内容 |
|---|---|
| 権限 | ユーザーが本来見られない情報をAIが表示しないか |
| データ分類 | 機密情報、個人情報、社外秘データの扱い |
| ログ | AIの回答や参照データをどこまで記録するか |
| 責任範囲 | AIの提案を業務判断に使う場合の確認フロー |
| 運用 | 誤回答や不適切表示が起きた時の問い合わせ先 |
AI機能は導入そのものより、運用設計で差が出ます。特にグローバル企業では、国や地域ごとのデータ保護要件にも注意が必要です。
開発者が今やるべき準備
開発者は、SPFx 1.23 RCとSPFx CLIを早めに検証しておくと、今後の移行が楽になります。
検証用プロジェクトでSPFx 1.23を試す
SPFx 1.23のプレビューリリースノートでは、@nextタグを使って最新プレビューをインストールする方法が案内されています。ただし、本番環境向けではなくテスト用途で扱うべきです。(Microsoft Learn)
検証では、次のような観点をチェックします。
| 検証項目 | チェック内容 |
|---|---|
| ビルド | 既存コードと同じNode.js環境でビルドできるか |
| パッケージ | 依存関係の警告やnpm auditの変化 |
| UI | Webパーツや拡張機能の表示崩れがないか |
| 権限 | Graph APIやSharePoint APIの呼び出しに影響がないか |
| デプロイ | App Catalogへの配布手順が変わらないか |
| CI/CD | Azure DevOpsやGitHub Actionsのワークフローが動くか |
SPFx CLIで社内テンプレート化を考える
SPFx CLIの価値は、単発のプロジェクト作成よりも、継続的な標準化にあります。
たとえば、次のようなチームではSPFx CLIの検証効果が高いです。
- 複数部門向けにSharePoint Webパーツを継続開発している
- 外部ベンダーと共同でSPFx案件を進めている
- プロジェクトごとにフォルダー構成や設定がばらついている
- セキュリティレビューやコードレビューを標準化したい
- Microsoft 365 CopilotやGraph連携を含む業務UIを増やしたい
逆に、年に1回程度しかSPFxを触らないチームでは、まず公式テンプレートの動向を追い、GA後に移行判断しても問題ありません。
製品ウォッチャーが見るべきSPFxの方向性
今回の更新は、SPFxがMicrosoft 365の将来像に深く組み込まれていることを示しています。
Microsoftは今後の方向性として、SPFx、SharePoint Embedded、Agents and AI、Microsoft Graphを挙げています。つまり、SharePoint上にUIを作るだけでなく、Microsoft 365内外のコンテンツ、業務データ、AI体験をつなぐ開発基盤としてSPFxを位置付けていると読めます。(Microsoft for Developers)
この流れを製品戦略として見ると、SPFxの役割は次のように変わっていきます。
| 従来の見方 | 今後の見方 |
|---|---|
| SharePointのWebパーツ開発基盤 | Microsoft 365全体の業務UI開発基盤 |
| サイト単位のカスタマイズ | ポータル、業務アプリ、AI体験の統合 |
| SharePointリストやページの拡張 | Graph、AI、Embedded、Copilot周辺との連携 |
| 開発者向けの専門技術 | 管理者、情報システム、業務部門にも関係する基盤 |
特に、グローバル企業では「どの国・部門でも同じ体験を提供しながら、ローカル要件に合わせて調整する」ニーズがあります。SPFx CLIやテンプレートのオープンソース化は、こうした標準化と個別最適の両立に役立つ可能性があります。
既存SPFxプロジェクトで失敗しやすいポイント
今回のロードマップを受けて動く場合、よくある失敗は次の4つです。
新機能だけを見て既存資産の棚卸しを後回しにする
AI機能や新しいCLIは魅力的ですが、既存SPFx資産が整理されていない状態で新機能を入れると、保守対象がさらに増えます。
まずは、既存ソリューションの一覧、利用サイト、担当者、依存関係を整理することが重要です。
プレビュー版を本番前提で扱う
SPFx 1.23 RCやSPFx CLIのプレビューは、検証には有用です。しかし、本番システムで使う場合は、GA、既知の問題、サポート状況を確認してから判断する必要があります。
特に業務ポータルや承認フローに関わるWebパーツでは、プレビュー版の採用に慎重になるべきです。
React 18対応を前提に先行改修する
React 18対応は重要ですが、公式ブログではスケジュールが確定していないとされています。現時点では、React 18前提の大規模改修ではなく、依存ライブラリやコンポーネント構成の確認に留めるのが安全です。(Microsoft for Developers)
AI機能をUI改善だけで考える
AIをSharePointポータルに組み込む場合、ユーザー体験だけでなく、情報管理とガバナンスが重要です。
「便利な回答を出すWebパーツ」を作る前に、「どのデータを参照してよいか」「誰に表示してよいか」「誤った回答をどう扱うか」を決める必要があります。
今回のロードマップ更新を受けた実務アクション
最後に、読者の立場別に次の行動を整理します。
| 立場 | まずやること |
|---|---|
| SharePoint管理者 | テナント内のSPFxソリューションを棚卸しする |
| Microsoft 365管理者 | AI活用前にデータ分類と権限設計を確認する |
| SPFx開発者 | 1.23 RCとSPFx CLIを検証用環境で試す |
| 開発リーダー | 社内標準テンプレート化の可能性を検討する |
| セキュリティ担当 | npm audit、依存関係、AI利用時のデータ境界を確認する |
| 製品企画担当 | SPFxをAIポータルや業務統合UIの基盤として評価する |
今回の「SharePoint Framework (SPFx) roadmap update – April 2026」は、SPFxの将来が単なるSharePointカスタマイズに留まらないことを示す更新です。
短期的には、SPFx 1.23 RC、リストビューコマンドセット、SPFx CLI、npm audit対応を検証しましょう。中期的には、SPFx CLIへの移行、社内テンプレート標準化、React 18対応の準備を進めるのが現実的です。さらに、AI関連機能が具体化する前に、SharePoint内のデータ管理、権限、ガバナンスを整えておくことが、今後のMicrosoft 365活用で大きな差になります。
コメント