SharePointハブサイト計画の要点|2026年7月公式情報と管理者の対応

SharePointハブサイトの計画に関する今回の公式情報は、新機能の追加や管理画面の大幅な変更を知らせるものではありません。主眼は、SharePointのサイトをどのような単位で分け、ハブサイトを使ってナビゲーション、検索、ニュース、ブランドをどう束ねるかという情報設計の見直しです。

2026年7月6日付の更新情報として扱われていますが、Microsoft Learnの対象ページには、少なくとも現時点で「最終更新日:2026年6月25日」と表示されています。また、段階的ロールアウト、対象指定リリース、管理者による有効化期限などは案内されていません。そのため、7月6日から利用者の画面や操作が変わる更新ではなく、イントラネットの新設・再編時に参照すべき計画ガイドと捉えるのが適切です。(Microsoft Learn)

目次

SharePointハブサイト計画の結論

今回の情報に対する対応要否は、次のように判断できます。

確認項目結論
新機能の追加当該文書には記載なし
SharePointの画面変更新しいボタンや操作経路の変更は記載なし
展開時期段階展開や適用期限の記載なし
主な対象SharePoint管理者、イントラネット管理者、ハブサイト所有者、情報設計担当者
一般利用者への影響原則として即時対応不要
OneDriveへの影響同期アプリや個人用ファイル画面の変更は記載なし
管理者が行うこと既存ハブ、関連付け、権限、ナビゲーション、検索範囲の点検

緊急の設定変更は必要ありません。ただし、複数部門のサイトを1つの巨大なハブに集約している組織、サブサイトを多用している組織、非公開サイトをハブナビゲーションに掲載している組織は、今回のガイドを基に設計を見直す価値があります。

「Planning your SharePoint hub sites」で扱われている内容

SharePointハブサイトは、複数のチームサイトやコミュニケーションサイトを、物理的な親子関係ではなく「関連付け」によってまとめる仕組みです。

ハブサイトが提供する中心的な役割は、次の3点です。

  • 共通のナビゲーションとブランド
  • 関連サイトからのコンテンツ集約と検索
  • 特定の業務領域における入口となるホームサイト

従来のサブサイトは、URLやサイトコレクションの階層に依存します。組織変更や事業再編が発生すると、サイトの移動やURL変更が大きな負担になりがちです。

一方、モダンSharePointでは、業務、プロジェクト、部門などの作業単位ごとに独立したサイトを作成し、関連するサイトをハブでつなぐ「フラットな情報アーキテクチャ」が推奨されています。独立したサイトであれば、組織変更時にも別のハブへ関連付け直しやすく、権限やライフサイクルも個別に管理できます。(Microsoft Learn)

対象となるプラットフォームとサイト

今回の公式文書が直接対象としているのは、Microsoft 365上のSharePointです。

対象位置付け
SharePoint in Microsoft 365直接の対象
モダンコミュニケーションサイトハブサイトの基盤として特に推奨
モダンチームサイトハブサイトとして登録可能
クラシックチームサイト利用可能だが、ハブナビゲーションなどはモダンページに限定
OneDrive for Businessハブサイト計画による直接の操作変更なし
SharePoint Server今回のMicrosoft 365向け文書の対象外

Microsoftは、ハブサイトにするサイトとして、コミュニケーションサイトまたはモダンテンプレートを使用したチームサイトを推奨しています。クラシックチームサイトを使用した場合、ハブナビゲーションやハブ設定が表示されるのはモダンページのみです。

また、すでに別のハブに関連付けられているサイトは、そのままではハブサイトとして登録できません。既存サイトをハブへ昇格させる場合は、現在の関連付け状況を先に確認する必要があります。(Microsoft Learn)

OneDriveはSharePointと共通する管理基盤を持ちますが、今回の文書はコミュニケーションサイト、チームサイト、イントラネットの情報設計を扱っています。OneDrive同期クライアント、個人用ファイル、フォルダー共有の操作変更を説明するものではありません。

サイトをハブに関連付けると何が変わるのか

今回の文書自体は機能更新ではありませんが、サイトをハブへ関連付けた際に何が変わるかを理解しておくことが重要です。

ハブのテーマと共有ナビゲーションが適用される

関連付けられたサイトには、ハブサイトのテーマと共有ナビゲーションが適用されます。部門ごとに別々のサイトを運営しながら、利用者には同じサイト群として見せることができます。

ただし、サイトをハブへ関連付けても、そのサイトが自動的にハブナビゲーションへ追加されるわけではありません。ナビゲーションに表示するリンクは、ハブサイト所有者が別途設定します。(Microsoft Learn)

検索範囲に関連サイトが含まれる

ハブサイト上で検索した場合、関連付けられたサイトを含む検索範囲が形成されます。

たとえば、人事ハブに「福利厚生」「採用」「研修」「評価制度」の各サイトを関連付ければ、利用者は全社検索ではなく、人事領域に絞って情報を探せます。

ハブサイトは単なるリンク集ではなく、利用者が情報を探す際の検索コンテキストを定義する仕組みと考えると理解しやすくなります。

ニュースやコンテンツを集約できる

ニュース、強調表示されたコンテンツ、サイト、イベントなどのWebパーツでは、ハブに関連付けられたサイトを情報源として指定できます。

ただし、ニュースは基本的に関連サイトからハブへ集約される方向です。ハブに掲載したニュースが、関連サイトへ自動的に配信されるわけではありません。全社や部門全体へ知らせたい重要ニュースは、関連サイトではなくハブサイト側で公開する方法も検討する必要があります。(Microsoft Learn)

サイトの権限は変わらない

サイトをハブに関連付けても、ハブサイトや関連サイトのアクセス権限は自動変更されません。

閲覧権限のないサイトから集約されたコンテンツは、セキュリティトリミングによって利用者には表示されません。一方、ナビゲーションに非公開サイトへのリンクを追加すると、権限のない利用者にもリンクだけが見え、クリック後にアクセス拒否となる場合があります。

非公開サイトや制限付きサイトを掲載する場合は、次のいずれかで対応します。

  • ナビゲーションの対象ユーザー設定を利用する
  • 非公開サイトをナビゲーションへ掲載しない
  • リンク名に「制限付き」「部門内限定」などを明記する
  • 必要に応じてハブの閲覧者グループを関連サイトへ付与する

ハブへの関連付けとアクセス権の付与は別の操作です。この点を混同すると、利用者から「リンクは見えるのに開けない」という問い合わせが増えます。(Microsoft Learn)

ハブ同士を関連付けた場合の注意点

SharePointでは、ハブサイトを別のハブサイトへ関連付け、複数のハブにまたがる検索範囲を構成できます。

たとえば、次のような構成です。

  • 全社ポータル
  • 国内事業ハブ
    • 東日本営業ハブ
    • 西日本営業ハブ

ハブ同士を関連付けると、関連するハブのコンテンツを最大3レベルまで検索対象にできます。

ただし、ハブ同士の関連付けで主に広がるのは検索範囲です。通常の画面上では、検索結果のパンくずなどを除いて大きな表示変化はありません。

また、「ハブ内のすべてのサイト」を情報源に指定したWebパーツは、ハブ同士を関連付けても、元の親ハブに属するサイトを引き続き対象とします。子ハブのニュースやイベントが自動的にすべて集約されるわけではありません。(Microsoft Learn)

ハブ同士のナビゲーションリンクも自動更新されません。管理センターで親ハブの関連付けを変更した後は、必要に応じてハブナビゲーション側も修正してください。

管理者が対応要否を判断する基準

次のいずれかに該当する場合は、既存のハブサイト構成を確認すべきです。

現在の状況推奨する対応
多数のサブサイトを使用している独立サイトとハブによるフラット構造への移行を検討
すべてのサイトを1つのハブに集約している部門、地域、業務領域ごとの分割を検討
組織図だけを基準にハブを作成している利用者の業務や検索行動を基準に再評価
非公開サイトをナビゲーションに掲載している対象ユーザー設定と権限を確認
外部共有サイトをハブに関連付けている外部利用者に共有ナビゲーションを見せてよいか確認
ハブ所有者が退職・異動している正副2名以上の管理体制へ変更
誰でもサイトをハブへ関連付けられる関連付け可能なユーザーまたはグループを制限
検索結果が多すぎて目的の情報が見つからないハブの範囲を業務コンテキストごとに分割

一般利用者や、OneDriveのみを利用しているユーザーには、今回の情報を理由とする即時対応は必要ありません。

ハブサイトは組織図ではなく「利用者の目的」で設計する

ハブサイトを計画するときに最も重要なのは、「どの部署に所属しているか」だけで分類しないことです。

Microsoftの公式ガイドでは、次の2つの問いから設計を始めるよう案内しています。

  • 対象となる利用者は誰か
  • その利用者は何を達成する必要があるか

たとえば、地域別と業務機能別の両方にサイトを分類できる営業組織を考えます。

「長野営業サイト」は、長野拠点ハブにも、国内営業ハブにも関連しそうです。しかし、1つのサイトが同時に直接所属できるハブは1つです。

この場合は、利用者が日常的にどの単位で情報を探すかを基準に主ハブを決めます。

  • 商品情報や営業資料を探すことが多いなら営業ハブ
  • 総務、設備、地域行事など拠点情報を探すことが多いなら地域ハブ
  • 両方必要なら、主ハブを1つ決め、もう一方とはリンクやWebパーツ、ハブ同士の関連付けで接続

この考え方により、組織変更があってもサイトそのものを移設せず、関連付けの変更で対応しやすくなります。(Microsoft Learn)

1つの巨大なハブに集約しない

組織全体で1つだけハブサイトを使う構成も可能です。しかし、すべてのサイトを1つのハブへ集約すると、検索範囲が広がりすぎ、部門や業務ごとの文脈が失われます。

たとえば、人事サイトで「ビジョン」と検索した利用者が、福利厚生制度ではなく経営ビジョンの資料を大量に受け取るような状態です。

全社共通の移動経路は、SharePointアプリバーのグローバルナビゲーションで提供できます。ハブナビゲーションは、人事、営業、IT、拠点など、関連するサイト群の移動と検索に使うのが基本です。

SharePointのナビゲーションは、次の3層で分けて考えると整理しやすくなります。

ナビゲーション対象範囲
グローバルナビゲーション組織全体
ハブナビゲーション関連するサイト群
ローカルナビゲーション個別サイト内

ハブサイトに全社ナビゲーション、部門ナビゲーション、サイト内ナビゲーションのすべてを詰め込むと、リンク数が増え、利用者が現在地を理解しにくくなります。(Microsoft Learn)

ハブサイトの上限と実務上の目安

SharePointでは、組織あたり最大2,000件のハブサイトを作成できます。ただし、上限まで作成することが推奨されているわけではありません。

目的別の実務上の目安は次のとおりです。

目的上限・目安
テナント内のハブサイト数最大2,000件
1つのハブへ関連付けるサイト数明確なハード上限なし
ナビゲーションの子リンク数各レベル最大500件
ハブナビゲーションへ掲載するサイト数利便性と性能の面から100件以下を推奨
サイトWebパーツで「ハブ内のすべてのサイト」を表示最大99サイト
検索を主目的とする関連サイト数約2,000サイトが実務上の目安
ハブナビゲーションの階層最大3レベル
ハブ同士を関連付けた検索範囲最大3レベル

「最大2,000ハブ」と「検索対象として約2,000サイト」は別の数字です。前者はテナント内で作成できるハブ数の上限、後者は大規模な検索範囲を設計する際の実務的な目安です。

また、共通テーマを適用したいだけでハブを増やすのは適切ではありません。コンテンツ量が少ない場合は、サイトを分割せず、1つのサイト内に複数のドキュメントライブラリやページを作る方が管理しやすいことがあります。(Microsoft Learn)

管理者が準備すべきこと

既存サイトの棚卸しを行う

最初に、SharePoint管理センターのアクティブなサイトから、次の情報を整理します。

  • サイト名とURL
  • サイトの種類
  • 現在のハブ関連付け
  • サイト所有者と予備管理者
  • 主な利用者
  • 外部共有の有無
  • 非公開・制限付きサイトか
  • 最終利用時期
  • 廃止や統合の候補か

サイト名だけで分類せず、「誰が、どの業務で、何を探すサイトか」を記録することが重要です。

ハブの目的を1文で定義する

各ハブについて、次の形式で目的を書きます。

このハブは、対象利用者が、関連する情報を探し、必要な手続きを開始するための入口である。

目的を1文で説明できないハブは、対象範囲が広すぎるか、ハブとして作成する必要性が薄い可能性があります。

関連付けを許可するユーザーを限定する

ハブサイトを登録する際は、サイトを関連付けられるユーザーまたはセキュリティグループを指定できます。

この欄を空欄にすると、サイト所有者が自分のサイトをそのハブへ関連付けられる状態になります。大規模な組織では、意図しない関連付けや命名の混乱を防ぐため、専用の管理グループへ限定するのが安全です。(Microsoft Learn)

権限とナビゲーションを別々に設計する

関連付け、権限、ナビゲーションはそれぞれ別の設定です。

確認順序は次のとおりです。

  1. サイトをハブへ関連付けるか決める
  2. 誰がサイトを閲覧できるか確認する
  3. ハブナビゲーションへ掲載するか決める
  4. 必要なら対象ユーザーを設定する
  5. ニュースやWebパーツの集約範囲を設定する

この順序を守ると、「検索には出るがナビゲーションにはない」「リンクは見えるが開けない」といった混乱を減らせます。

小規模なハブで先行テストする

全社規模で一度に変更せず、まず1部門のハブと3~5件程度の関連サイトでテストします。

確認する項目は次のとおりです。

  • ハブナビゲーションから目的の情報へ到達できるか
  • 権限のないコンテンツが表示されないか
  • 非公開サイトへの不要なリンクが見えていないか
  • ハブ検索で期待する情報が見つかるか
  • ニュースとイベントの集約範囲が正しいか
  • スマートフォンでもナビゲーションが理解できるか
  • サイト所有者が更新手順を理解しているか

技術的に正しい構成でも、利用者が情報を見つけられなければ情報設計としては成功していません。

よくある失敗と回避方法

関連付ければ権限も統一されると思い込む

ハブへの関連付けだけでは権限は変わりません。

必要な場合は、共通の閲覧者グループを関連サイトへ付与します。ただし、機密性の高いサイトまで一律に公開しないよう、サイトごとに確認してください。

関連サイトが自動でナビゲーションへ追加されると思い込む

関連付けとナビゲーション登録は別です。

新しいサイトを関連付けた後は、ナビゲーションに掲載するかをハブ所有者が判断し、必要なリンクを追加します。

ハブ同士を関連付ければWebパーツもすべて横断すると考える

ハブ同士の関連付けで拡大する中心的な機能は検索です。

「ハブ内のすべてのサイト」を指定したニュースやサイトWebパーツが、子ハブ配下まで自動的に横断するわけではありません。必要なコンテンツは、Webパーツごとに情報源を設定します。

外部共有サイトを安易に関連付ける

外部利用者がアクセスするサイトをハブへ関連付けると、共有ナビゲーションが外部利用者にも表示される可能性があります。

外部利用者に社内ナビゲーションを見せたくない場合は、ハブへ関連付けず、社内側のナビゲーションから外部サイトへのリンクだけを追加する方法を検討します。(Microsoft Learn)

組織図をそのままサイト階層にする

組織図は管理者には分かりやすくても、利用者の検索行動と一致するとは限りません。

人事、IT、総務など、利用者が目的を認識しやすい業務単位を優先します。組織変更のたびにハブを作り直す構成ではなく、業務やサービスが継続する単位で設計することが重要です。

今回の情報を受けて行うべき対応

今回の「Planning your SharePoint hub sites」は、すべてのテナントに即時変更を求める更新ではありません。まずは、既存環境について次の3点を確認してください。

  • ハブが組織図ではなく利用者の業務目的に沿っているか
  • 関連付け、権限、ナビゲーションを別々に管理できているか
  • 1つのハブへサイトを集めすぎていないか

問題がなければ、緊急対応は不要です。

問題が見つかった場合は、既存サイトをすぐに移動するのではなく、サイト棚卸し、ハブ構成案、権限確認、小規模テストの順に進めます。SharePointハブサイトの価値は、サイト数を増やすことではなく、利用者が必要な情報へ迷わず到達できる検索範囲とナビゲーションを作ることにあります。

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次