SharePointを運用していると、「デザインや操作感が異なるサイトが混在している」「マニュアル通りに設定できない」といった混乱に直面することがあります。その原因の多くは、モダンUIとクラシックUIという2つの異なるインターフェースが併存していることにあります。
本記事では、SharePointのモダンとクラシックの定義から、画面上での見分け方、機能・仕様の違い、そして選択・移行の判断基準まで、実務に必要な知識を体系的に解説します。
既存サイトの現状把握から、新規サイト作成時の選択、クラシックからモダンへの移行計画まで、自社環境の最適化に向けた具体的なアクションを整理できるようになります。
目次
SharePointのモダンUIとクラシックUIとは？
SharePointには、2016年以降に導入されたモダンUIと、それ以前から存在するクラシックUIという2つのインターフェースがあります。この章では、それぞれの定義と登場した歴史的背景、そしてMicrosoftが現在進めているモダン推奨の方針を、提供形態・特徴・サポート方針の順に見ていきます。
なお、UIの混在による管理の複雑化を避け、情報の属人化を防ぐために、SharePointよりもシンプルなNotePMのようなナレッジ管理ツールを検討する企業も増えています。
モダンUIの特徴と提供形態
モダンUIは、2016年にSharePoint Onlineで導入されたクラウド時代の標準インターフェースです。レスポンシブデザインを採用しており、PC・タブレット・スマートフォンのいずれでも最適な表示を自動で提供します。
現在、SharePoint Onlineで新規にサイトを作成する際は、コミュニケーションサイトやチームサイトといったモダンUIのテンプレートが標準として提供されます。これらのサイトは、Microsoft 365の各種サービス（Teams、Outlook、Plannerなど）との連携が組み込まれており、グループ管理や権限設定もシームレスに行えます。
モバイルアプリやブラウザでのレスポンシブ表示に標準で対応しているため、場所やデバイスを問わず一貫した操作感を提供できる点が大きな特徴です。
クラシックUIの特徴と提供形態
クラシックUIは、オンプレミス版のSharePoint Serverから引き継がれた伝統的なインターフェースです。サブサイトによる階層構造の構築や、マスターページを用いた独自デザインの適用など、高度なカスタマイズが可能な設計思想を持ちます。
一方で、PC表示を前提とした設計であるため、モバイル対応には個別のカスタマイズを要する場合が多く、タブレットやスマートフォンでの閲覧時に表示崩れやスクロールの煩雑さが発生しやすい構造です。
現在でもSharePoint Server（オンプレミス版）や、SharePoint Onlineの一部の既存サイトでクラシックUIが残っていますが、新規作成時にクラシック形式を選択する機会は限定的になっています。
Microsoftの移行方針とサポート終了リスク
Microsoftは、モダンUIを優先的に開発しており、クラシックUIへの新機能追加は既に停止しています。AI機能やCopilot連携、最新のWebパーツなど、今後リリースされる利便性向上機能は、モダンUIでのみ提供される方針です。
クラシックUIの完全廃止時期は明示されていませんが、段階的な非推奨化が進んでおり、将来的にサポート対象外となるリスクがあります。サポート終了済みのソフトウェアを使い続けることは、セキュリティパッチが提供されなくなり、重大なサイバー攻撃のリスクを増大させるため、早期のモダンUI移行が望ましいとされています。
国内企業のクラウド利用率は約8割に達しており、SharePoint Onlineのモダン化も加速しています。既存のクラシックサイトを保有している場合は、計画的な移行の検討が推奨されます。
SharePointのモダンとクラシックの違い
目の前にあるSharePointサイトがどちらのUIであるかを即座に判別する方法を、画面構成、設定メニュー、URLの3つの観点から解説します。
画面レイアウトとナビゲーションの違い
最も視覚的に分かりやすい識別ポイントは、ナビゲーションバーの配置です。
モダンUIでは、ナビゲーションが画面左側に縦型で配置され、フラットでシンプルなデザインが特徴です。サイトロゴやタイトルが上部に表示され、メニュー項目が左サイドに並びます。
クラシックUIでは、上部に横型のグローバルナビゲーションバーが配置され、リボンUIと呼ばれる詳細なメニューが表示されることがあります。全体的に情報密度が高く、グレーやブルーを基調とした従来のSharePointデザインが残っています。
ナビゲーションバーが左側にあればモダン、上部のリボンUIならクラシックの可能性が高いと判断できます。
設定メニューと管理画面の違い
管理者やサイト作成者が識別しやすいのが、設定画面内のメニュー構成です。
モダンUIでは、画面右上の歯車アイコンをクリックすると、シンプルに整理された設定メニューが表示されます。「サイト情報」「サイトのデザイン」「サイトの権限」など、主要な設定項目が分かりやすくカテゴリ分けされています。
クラシックUIでは、歯車アイコンから「サイトの設定」をクリックすると、詳細なリンク集が一覧表示されます。「サイトの管理」「ユーザーと権限」「ギャラリー」など、多数の設定項目が並ぶページに遷移するのが特徴です。
設定メニューがシンプルに整理されているのがモダンUI、詳細なリンク集が表示される場合はクラシックUIと判断できます。
URLパターンによる識別方法
画面を見ずとも判断できる方法として、URLの文字列パターンがあります。
クラシックUIのサイトでは、URLに「_layouts/15/start.aspx」や「_layouts/15/settings.aspx」といった文字列が含まれることが多く、これはクラシックUIの管理画面やページを示す典型的なパターンです。
モダンUIでは、URLがシンプルで「/SitePages/」や「/Lists/」といった構造になっており、「_layouts」が含まれることは少なくなっています。
URLに「_layouts/15/」が含まれる場合、クラシックUIのサイトである可能性が高いと判断できます。
SharePointのモダンとクラシックの機能・仕様の違い
実務に直結する機能面の違いとして、レスポンシブ対応、Webパーツの仕様、サイト構造の設計思想における決定的な差異を、この章で詳細に比較します。
レスポンシブ対応とモバイル表示の違い
モダンUIは、PC、タブレット、スマートフォンの画面サイズに合わせて自動でレイアウトが最適化されるレスポンシブデザインを標準装備しています。モバイルアプリからのアクセス時も、タッチ操作に適したインターフェースが提供されます。
クラシックUIは、PC表示を前提とした設計であり、モバイル対応には個別のモバイル設定やカスタマイズが必要になります。標準状態ではスマートフォンで閲覧した際に文字が小さく、横スクロールが必要になるなど、ユーザビリティが低下しやすい構造です。
テレワークやモバイルワークが増加している現在、モダンUIのスマホ対応が標準である点は、業務効率に直結する重要な違いといえます。
Webパーツとカスタマイズ性の違い
モダンUIでは、ヒーロー、ニュース、イベント、画像ギャラリーなど、視覚的で直感的なWebパーツが豊富に用意されています。開発者向けには、SharePoint Framework（SPFx）による安全で標準化された拡張が可能であり、カスタムWebパーツの追加もサポートされています。
クラシックUIでは、コンテンツエディタやスクリプトエディタといった自由度の高いWebパーツが利用できますが、セキュリティリスクや保守性の観点から、これらの機能は段階的に廃止される方向にあります。独自のJavaScriptやCSSを埋め込むことができる反面、バージョンアップ時の互換性リスクが高まります。
モダンUIは視覚的なパーツが豊富で、SPFxによる安全な拡張が可能である一方、クラシックUIは自由度が高いものの、将来的なサポート継続性に懸念があります。
SharePointは多機能ですが、その分設定やデザイン調整に専門知識が必要です。「もっと手軽に情報を共有したい」「ファイルの中身まで検索したい」という場合は、高機能エディタとAI支援を搭載したNotePMが役立ちます。
サイト構造と権限管理の違い
モダンUIは、フラットなサイト構造を推奨しており、ハブサイトという仕組みで複数のサイトを緩やかに関連付けます。各サイトは独立した権限管理を持ちながら、共通のナビゲーションやブランディングを共有できます。また、Microsoft 365グループと統合されており、TeamsやOutlookと共通の権限管理が行えるため、管理負荷が軽減されます。
クラシックUIは、サブサイトによる階層構造を推奨しており、親サイトの下に子サイト、孫サイトといった多層構造を構築できます。権限の継承や個別設定が細かく制御できる反面、構造が複雑化しやすく、管理が属人化しやすいという課題があります。
モダンはハブサイトによるフラットな構造、クラシックはサブサイトによる階層構造を推奨する点が、サイト設計における大きな違いです。
SharePointのモダンとクラシックどちらを選ぶべきか
新規サイト作成時における選択基準を、ユースケース、将来的なメンテナンスコスト、ITスキルの観点から整理します。この章では、新規作成時の判断基準、ハイブリッド運用時の注意点、Microsoftの公式方針とサポート終了リスクの順に見ていきます。
新規サイト作成時の判断基準
新規サイトを作成する場合、原則としてモダンUIを選択すべきであり、これがMicrosoftの公式推奨です。特殊なアドインや古いカスタマイズを継承する必要がない限り、モダンUI一択といえます。
モダンUIを選択すべき理由は以下の通りです。まず、レスポンシブ対応が標準であり、モバイルワークに対応できます。次に、最新機能やセキュリティアップデートが継続的に提供されます。さらに、Microsoft 365の各種サービスとの連携がシームレスであり、業務効率化が進めやすい環境です。
一方、クラシックUIを選択する必要があるのは、既存のクラシックサイトとの互換性維持が必須の場合や、特定のレガシーアドインを使い続ける必要がある場合など、極めて限定的なケースに限られます。
ただし、現場のITスキルに不安があり、SharePointの多機能さを使いこなせない懸念がある場合は注意が必要です。教育コストを抑えて即座に情報共有を始めたい組織には、マニュアル不要で直感的に使えるNotePMが有力な選択肢となります。
ハイブリッド運用時の注意点とガバナンス
既存のクラシックサイトと新規のモダンサイトが混在する環境では、ユーザーが混乱しないための管理上の工夫が必要です。
まず、サイトごとにUIを統一し、マニュアルで操作感の違いを明示することが混乱回避に繋がります。例えば、部門ごとにモダンサイトへの移行スケジュールを定め、移行済みサイトと未移行サイトを一覧で管理する方法が有効です。
また、新規サイト作成時のルールを明文化し、特別な理由がない限りモダンUIを選択するガバナンスを設けることで、将来的な管理負荷を軽減できます。サイト作成権限を適切に管理し、無秩序なサイト増殖を防ぐことも重要です。
Microsoftの公式方針とサポート終了リスク
Microsoftは、AI機能やCopilot連携など、最新の利便性をモダンUIでのみ提供する方針を明確にしています。クラシックUIへの新機能追加は既に停止しており、今後もこの方針が継続される見込みです。
サポート終了済みのソフトウェアを使い続けることは、セキュリティパッチが提供されなくなり、重大なサイバー攻撃のリスクを増大させるため、早期のモダンUI移行が推奨されます。
将来的な機能拡張やセキュリティ対応を考慮すると、クラシックUIを使い続けることは、中長期的なリスクとコスト増加に繋がります。計画的な移行スケジュールを立て、段階的にモダンUIへ移行することが、安全かつ効率的な運用の鍵となります。
SharePointのクラシックからモダンへの移行方法
既存のクラシックサイトをモダン化するための具体的なステップ、推奨ツール、および移行時の注意点を、移行前の準備、モダンUI有効化とデータ移行の手順、移行時に失われる機能と代替手段の順に解説します。
移行前の準備と現状調査
移行の成否を分けるのは、既存資産の調査と優先順位付けです。まず、現在利用中のクラシックサイトの一覧を作成し、各サイトの利用頻度、カスタマイズ内容、重要度を評価します。
特に、スクリプトエディタやマスターページによるカスタマイズ、サードパーティ製のWebパーツ、独自のJavaScript/CSSの埋め込みなど、モダンUIで再現できない機能の有無を確認することが重要です。
利用頻度の低いサイトは移行せず整理・削除することで、移行コストと管理負荷を削減できます。また、移行対象サイトの中でも、カスタマイズが少なくシンプルなサイトから優先的に移行することで、段階的な移行が可能になります。
モダンUI有効化とデータ移行の手順
クラシックサイトをモダンUIに切り替える方法は、主に以下の2つです。
1. サイト設定からのモダンUI有効化
既存のクラシックサイトの一部機能（リストやライブラリの表示）をモダンUIに切り替えることができます。サイト設定から「モダンUIの有効化」を選択することで、段階的にモダン化を進められます。ただし、サイト全体の構造やマスターページはクラシックのまま残るため、完全なモダン化ではありません。
2. 新規モダンサイトへのデータ移行
完全にモダンUIに移行する場合は、新規にモダンサイトを作成し、クラシックサイトからコンテンツを移行する方法が推奨されます。大規模なライブラリ移行には、Microsoft公式のSPMT（SharePoint Migration Tool）が推奨されます。
SPMTは、ドキュメントライブラリ、リスト、メタデータ、権限設定などを一括で移行できるツールであり、Microsoftが無償で提供しています。移行前にテスト環境で動作確認を行い、移行計画を立てることが重要です。
また、PowerShellを用いた自動化スクリプトを作成することで、複数サイトの一括移行や、定期的な差分同期も可能です。ただし、PowerShellの実行には管理者権限と一定の技術スキルが必要なため、社内にリソースがない場合は、外部のコンサルタントやMicrosoftパートナーへの委託も検討すべきです。
移行時に失われる機能と代替手段
クラシックUIからモダンUIへ移行する際、一部の機能が利用できなくなるため、代替手段を検討する必要があります。
1. スクリプトエディタとコンテンツエディタ
クラシックUIで利用できたスクリプトエディタは、モダンUIでは廃止されます。代替手段として、SPFx（SharePoint Framework）Webパーツでの再実装や、標準機能への置き換えが必要です。簡易的なカスタマイズであれば、Power Automateやカスタムリストの活用で代替できる場合もあります。
2. サブサイトの階層構造
クラシックUIのサブサイトによる階層構造は、モダンUIではサポートされません。代替手段として、ハブサイトによるフラットな構造への再設計が推奨されます。ハブサイトは、複数のサイトを緩やかに関連付けながら、共通のナビゲーションやブランディングを提供できます。
3. マスターページによる独自デザイン
クラシックUIのマスターページによる独自デザインは、モダンUIでは利用できません。代替手段として、サイトテーマ、カスタムロゴ、カラースキームの設定による標準的なブランディングが推奨されます。高度なデザインカスタマイズが必要な場合は、SPFxによるカスタムヘッダー/フッターの実装が可能です。
このように、クラシックからモダンへの完全な移行には多くの工数がかかります。無理にSharePoint内で完結させず、マニュアルや社内規定などのナレッジ情報はNotePMへ移管・集約することで、移行プロジェクトをスリム化し、検索性を大幅に向上させることができます。
SharePointのモダンとクラシックの違いまとめ
本記事では、SharePointのモダンUIとクラシックUIの定義、見分け方、機能・仕様の違い、選択基準、移行方法について解説しました。
見分け方は、ナビゲーション配置（左側がモダン、上部がクラシック）、設定メニューの構成（シンプルがモダン、詳細リンク集がクラシック）、URL構造（「_layouts/15/」がクラシック）の3つで判断できます。
新規サイトは原則としてモダンUIを選択すべきであり、これがMicrosoftの公式推奨です。既存のクラシックサイトは、計画的な移行スケジュールを立て、段階的にモダンUIへ移行することが、安全かつ効率的な運用の鍵となります。
移行時には、スクリプトエディタやサブサイト構造など、一部の機能が利用できなくなるため、SPFxやハブサイトといった代替手段を検討する必要があります。移行前の現状調査と優先順位付けを丁寧に行い、自社の運用体制に合わせてNotePMなどのツールも組み合わせながら、快適な情報共有環境を構築してください。
