SharePointで社内ポータルを作る実装手順｜サイト構成・Webパーツ・権限・ナビ設計を上限値から解説

SharePointで社内ポータルを作る作業でつまずくのは、画面の操作ではありません。サイトをどう分けるか、権限の継承をどこで切るか、ナビゲーションをどの系統に持たせるか。この三点を決めないまま作り始めることが、部署や情報が増えた段階で作り直しへ戻る原因です。この記事では、Microsoftが公開している上限値と仕様の記載を基準に、実装で先に決める判断だけを順に整理します。社内ポータルそのものの定義や内製と外注の判断基準を先に押さえたい場合は、社内ポータルサイトとは？機能・作り方・内製と外注の判断基準まで解説から読むと前提が揃います。

まとめ：先に決めるのはサイト分割・権限・ナビの三点

結論から言えば、実装前に確定させるのは次の三点だけになります。一点目はサイトの分け方です。作業単位ごとに独立したサイトコレクションを立て、それをハブサイトで束ねる形がMicrosoftの示す現行の構成であり、サブサイトを掘る構成は推奨されていません。URLに階層が焼き付いてしまい、組織変更のたびにリンクが壊れるためです。

二点目は権限です。一つのリストまたはライブラリで持てる一意のアクセス許可はサポート上限が50,000、推奨は5,000にとどまります。しかも10万アイテムを超えたリストやライブラリでは継承の解除そのものができません。部署ごとにフォルダーを切って個別権限を当てる設計は、この上限に近づくほど破綻します。

三点目はナビゲーションです。サイトナビ、ハブナビ、アプリバーのグローバルナビは担当範囲が異なり、いずれも各レベル500の子リンクで頭打ちになります。表示上の推奨は100以下です。どの階層に何を出すかを先に割り振っておくと、後から出し先を探して回る手戻りが起きません。

コミュニケーションサイトとハブサイトで組む社内ポータルの土台設計

土台の選択肢は実質的に三つ、チームサイトとコミュニケーションサイト、そしてそれらを束ねるハブサイトです。

サブサイトを増やさずにサイトコレクションを並べる設計上の理由

現行のSharePointは、作業単位ごとに独立したサイトコレクションを作る前提で設計されています。コミュニケーションサイトも、Microsoft 365グループに接続されたチームサイトも、それぞれ固有の権限を持つサイトコレクションとして生成されます。

サブサイトは今も機能として残っていますが、Microsoftはハブへの整理を勧めています。理由は二つあります。一つはURLです。サブサイトは物理的な構成要素なので、組織再編でサイトを移すとコンテンツ内のリンクが一斉に切れる構造です。もう一つは保持や分類といったポリシー機能で、これらはサイトコレクション全体に適用されます。一つのサブサイトのためだけに、コレクション全体で機能を有効にする必要が出てきます。

数の目安も押さえておきます。organizationあたりのサイトは200万、サイトあたりの容量は25TB、サイトコレクションあたりのリストとライブラリの合計は2,000です（2026年8月4日時点）。部署単位でサイトを立てても、上限に触れる規模はまず来ません。

サイトをハブに関連付けたときに継承されるものと変わらないもの

ハブサイトが提供するのは、共有ナビゲーションとブランド、コンテンツのロールアップと検索、そしてハブのホーム宛先という三つです。サイトをハブに関連付けると、そのサイトはハブのテーマと共有ナビを継承し、ソースが「ハブ内のすべてのサイト」であるWebパーツのロールアップ対象になり、ハブの検索スコープに入ります。

一方で変わらないものが二つあります。まず権限です。ハブへの関連付けでは、サイトのアクセス許可は変更の対象外となります。制限付きのサイトを関連付けても、ロールアップ表示はセキュリティトリミングされ、アクセス権を持つ人にしか出ません。次にナビゲーションへの自動追加もありません。関連付けただけではハブナビに載らず、載せるかどうかはハブサイト所有者が個別に決めます。

この二点を取り違えると、「ハブに入れたのに見えない」「ハブに入れたのにナビに出ない」という問い合わせが公開直後に集中します。関連付けと公開範囲は別の作業だと整理しておく必要があります。

ハブ設計で先に押さえる関連付けの上限値と表示件数の実務的な制約

ハブの数と関連付けるサイトの数には、性格の違う複数の上限が重なっています。

テナント2,000ハブとナビ500ノードの上限が効いてくる場面

organizationが持てるハブサイトは最大2,000です。この数字に届く組織はまれですが、実務で先に当たるのはナビゲーション側の制限になります。サイトナビ、ハブナビ、グローバルナビ、フッターのすべてが各レベル500の子リンクまでで、超えて追加したノードはエラーを返します。

さらに表示上の推奨は別にあります。ハブ内の全サイトをナビに出す構成なら、読みやすさとパフォーマンスの観点から推奨されるリンク数は100以下です。つまりハブ一つあたりのサイト数も、ナビに全部載せる方針を採るなら100前後が実務上の設計値になります。対象ユーザーのターゲット設定で出し分けるなら、この制約は緩みます。

サイトWebパーツの99件上限とハブ間関連付け3レベルの読み方

ハブ内のサイト一覧を動的に出すサイトWebパーツは、「ハブ内のすべてのサイト」で絞り込める上限が99サイトです。100を超えるサイトを束ねたハブでは、一覧が全件を映さなくなります。検索スコープの共有だけが目的なら技術的な上限はなく、約2,000が実用の目安として示されています。

目的ごとに設計値が違う点を表にすると、次のようになります。

一つのサイトは一つのハブファミリーにしか関連付けられません。営業と地域のように二軸で束ねたい場合は、片方をハブ関連付け、もう片方はナビのリンクで表現する設計です。加えてハブ同士を関連付ける機能があり、最大3レベルまで検索結果を広げられます。全社を一つの巨大ハブにまとめず、機能ハブを並べて上位ハブへ接続する形にすると、部門内の検索と全社検索を両立できます。

トップページのWebパーツ選定とニュースがハブへ集まる向きの設計

ハブでソースを「ハブ内のすべてのサイト」に切り替えられるWebパーツは、ニュース、強調表示されたコンテンツ、サイト、イベントの四つです。トップページの情報量は、この四つの構成でほぼ決まります。

ロールアップの向きを踏まえてニュースWebパーツを二つ置く理由

ニュースの流れには向きがあります。関連付けられたサイトからハブへは集まりますが、ハブから関連サイトへは流れ落ちません。全社に届けたい記事はハブサイト側で投稿する、という運用がここから決まります。

Microsoftが示す構成は、ハブのホームページにニュースWebパーツを二つ置く形です。一つはハブ自身で公開したニュース、もう一つは関連サイトからロールアップしたニュースを表示します。全社の告知と部門の動きが同じ枠で混ざらず、投稿者側も「どちらのサイトに書けばどこに出るか」を迷わずに済みます。

対象ユーザーのターゲット設定をナビとカードのどちらに効かせるか

対象ユーザーのターゲット設定はMicrosoft Entra IDのグループで動きます。効かせられる先はナビゲーションリンク、ニュース、一部のWebパーツです。ここで判断が要るのは、出し分けを権限で実現するのかターゲット設定で実現するのかという点になります。

見せてはいけない情報には権限での制御が必要です。見せても支障はないが関係のない人の画面を埋めたくない、という程度ならターゲット設定で十分です。この切り分けを曖昧にしたまま権限側で処理すると、次章の一意のアクセス許可が増え続けます。掲載する情報の優先順位づけそのものは見やすい社内ポータルのデザイン｜掲載の優先順位と四つのレイアウト型、作り込む判断基準で扱っています。

権限設計で継承を切る前に見ておく二つの上限値とハブの適用範囲

社内ポータルの設計で後戻りが最も高くつくのが権限です。数字を先に置きます。

一意のアクセス許可は上限50,000で推奨は5,000という線

リストまたはライブラリ内のアイテムに対する一意のアクセス許可は、サポートされる上限が50,000、推奨される一般的な上限が5,000です。この二つの数字は性格が違います。50,000は動作を保証する境界、5,000は運用に耐える境界だと読みます。

フォルダー単位で部署ごとに権限を切る設計は、部署数が増えるほど、また階層が深くなるほど一意のスコープを量産します。実装側の対処は、権限を切る単位をアイテムやフォルダーではなくサイトへ寄せることです。部署ごとにサイトを立ててハブで束ねれば、一意のアクセス許可はほぼ発生しません。サイト分割とハブ構成を先に決める理由はここにもあります。

グループ側の制限も併せて確認しておきます。SharePointグループは1グループあたり5,000ユーザー、サイトコレクションあたり10,000グループ、1ユーザーが所属できるのは5,000グループまでです。サイトコレクションあたりのユーザー数は200万となっています。

10万アイテムを超えたリストで権限の継承解除ができなくなる境界

リストは最大3,000万アイテム、ライブラリは最大3,000万のファイルとフォルダーを持てます。ただし10万を超えたリスト、ライブラリ、フォルダーでは、そのオブジェクト自体の権限の継承を解除することも、解除後に再継承することもできなくなります。

文書を集約する社内ポータルでは、この境界に到達したあとで権限設計を見直す事態が起きがちです。順序が逆で、10万に届く前に分割方針を決めておく作業になります。個別アイテムの継承解除は前述の上限内であれば可能なので、全体の設計としては「大きなライブラリは権限を切らない」「権限を分けたいならライブラリごと分ける」という原則で組みます。

三系統のナビゲーションと検索スコープで担当範囲を切り分ける設計

ナビゲーションを一箇所で作ろうとすると必ず破綻します。系統ごとに担当を割り振ります。

サイトナビ・ハブナビ・グローバルナビの三系統で担当範囲を分ける

サイトナビはそのサイト内の回遊、ハブナビはハブファミリー内の移動、グローバルナビはテナント全体の入口を担当します。ハブナビは最大3レベルまで階層を持て、チームサイトでの既定の表示形式はカスケードです。

ハブナビに載せる対象は所有者の判断事項です。プライベートなサイトを載せる場合、対象ユーザーのターゲット設定を併用しないと、アクセスできない人がリンクを踏んでアクセス拒否の画面に当たる形です。ターゲット設定を使わない方針なら、リンク名に「（制限付き）」のような注記を付けておく運用が案内されています。逆に、ハブに関連付けていないサイトをナビに載せることもできます。二軸の組織を表現するときの逃げ道がこれです。

ホームサイトに指定するとイントラネット全体が検索スコープになる

通常のサイトの検索範囲は、そのサイトコレクション内に限定される仕様です。コミュニケーションサイトをホームサイトに指定すると、検索範囲がイントラネット全体へ広がり、既定で組織ニュースの公式ソースにもなります。SharePointアプリバーのグローバルナビゲーションも、ホームサイトがあって初めて使えます。

実装順序での落とし穴は一点です。テナントのルートサイトと入れ替える作業は、ホームサイトに設定する前に済ませます。順序を逆にすると、ホームサイトの設定が失われて再適用が必要になると明記されています。2023年6月以降は、Microsoft 365管理センターでViva Connectionsのエクスペリエンスを作る流れの中でホームサイトを設定する形になりました。

ホームサイトとViva Connectionsへ踏み込む判断基準

SharePointだけで完結させるか、Viva Connectionsまで広げるか。ここは機能の優劣ではなく、ライセンスと拡張の要否で決めます。

ライセンスの条件が分岐する二つ目のエクスペリエンスという境目

Viva Connectionsは、スポットライト、ニュースリーダー、ダッシュボード、リソースで構成されるTeams内のアプリです。スポットライトは最大11項目、リソースのリンクは最大48まで作れます。ホームサイトはConnectionsの必須要件ではなく、両者は補完関係にあります。

判断の分岐点はライセンスです。Connectionsエクスペリエンスの作成にはEnterprise、Frontline、Academicのいずれかのライセンスが要ります。そのうえで、Microsoft 365サブスクリプション単体で作成・利用できるのは1エクスペリエンスまでです。二つ以上（最大50）を扱うには、テナント内の全ユーザーにMicrosoft Viva SuiteまたはViva Communications and Communitiesのライセンスが必要になります（2026年8月4日時点）。

したがって判断は明快です。全社共通の入口が一つで足りるなら、追加ライセンスなしでConnectionsを1本立てる構成が噛み合います。本社の情報系社員と現場スタッフでダッシュボードを分けたい、といった要件が出た時点で、二つ目のエクスペリエンスとなり全社ライセンスの検討事項です。この分岐は費用の桁を変えるため、要件定義の段階で確認します。費用の考え方そのものは社内ポータルの費用相場と内訳｜SaaSと個別開発が逆転する規模と年数の分岐点で整理しています。

SPFxに手を出す条件とノーコードで止めておく条件の切り分け

Connectionsの拡張手段はSharePoint Framework（SPFx）だけです。ダッシュボードのカードはアダプティブカードとSPFxを基盤にしており、基幹システムの情報をカードに載せるところまではローコードで届きます。

SPFxへ進む条件は二つに絞れます。一つは、標準Webパーツでは表現できない業務データの表示が要件に入っているとき。もう一つは、承認や申請といった操作をポータル上で完結させたいときです。逆に、表示するものがニュース、ドキュメント、リンク集、カレンダーの範囲に収まるなら、標準のWebパーツで止めておきます。開発物を作った瞬間から、テナントのサービス更新に追随する保守が発生するためです。実際にどの範囲まで標準機能で組めているかは、社内ポータルの事例を四つの用途パターンで読み解く｜自社に再現できる条件と設計の勘所で用途別に確認できます。

内製で作り切れる範囲と外部の実装支援に切り出す判断の分かれ目

ここまでの内容は、外部に依頼するかどうかにかかわらず社内で決めておく事項です。そのうえで線を引きます。

社内ポータルの初期構築を内製で回せる条件と回らなくなる三つの兆候

初期構築を内製で回せるのは、サイト数が数十までで、権限がサイト単位に収まり、掲載する情報が既存のドキュメントとニュースで足りる場合です。この範囲ならSharePointの標準機能だけで組み上がり、開発物は発生しません。

回らなくなる兆候は三つあります。第一に、アイテム単位の権限要求が積み上がってきたとき。前述の推奨5,000という数字に近づくなら、設計の見直しか外部の設計支援が要ります。第二に、基幹システムの数値をポータルに出したいという要件が出たとき。SPFxかPower Platform側の開発が必要になります。第三に、公開後にページの表示が重いという声が続くとき。ページ診断ツールで測る段階に入り、Webパーツの構成とロールアップの範囲を見直す作業になります。

外部の実装支援に切り出す場合は情報設計と権限設計から先に渡す

外部に依頼する場合、先に渡すのは画面イメージではありません。サイトの分割方針、ハブの束ね方、権限を切る単位、ナビの三系統の割り振りです。これらが決まっていれば、実装は上限値に照らして機械的に組めます。逆に画面から入ると、権限とロールアップの整合が後工程で崩れます。

SharePointの標準機能で届かない部分だけを個別開発に寄せる進め方であれば、開発量を抑えたまま要件を満たせます。当社では既存のMicrosoft 365環境を前提とした社内ポータルの構築と、標準機能では届かない画面・データ連携の開発をポータルサイトシステム開発として承っています。公開直後の負荷を避けるなら、ポータル起動スケジューラで段階的に公開する運用も併せて設計してください。

よくある質問

SharePointの社内ポータルは無料のテンプレートだけで作れますか？

Microsoftが提供するサイトテンプレートを起点にすれば、ニュース、ドキュメント、リンク集、カレンダーを備えたポータルは追加費用なしで組めます。ただしテンプレートが決めるのはページの初期構成だけです。サイトをどう分けるか、権限をどこで切るか、ハブでどう束ねるかは自社で設計する部分になります。作り直しの原因はテンプレート選びではなく、この設計の側にあります。

チームサイトとコミュニケーションサイトはどちらを選べばよいですか？

広く読ませる目的ならコミュニケーションサイト、共同で編集する目的ならチームサイトです。前者は少数の作成者と多数の閲覧者、後者はメンバー全員が作成者という想定で設計されています。社内ポータルのトップはコミュニケーションサイトで作り、部署の作業スペースはチームサイトにして、両方をハブへ関連付ける構成が標準的です。

ハブサイトに関連付けると権限も引き継がれますか？

引き継がれません。ハブへの関連付けはサイトのアクセス許可を変更しない仕様です。ハブに表示されるロールアップはセキュリティトリミングされるため、閲覧権限のない人には出ません。ハブ配下を横断して読ませたい場合は、ハブに閲覧用のグループを用意し、そのグループを関連サイト側にも追加する方法が案内されています。

ハブに関連付けられるサイト数の上限はいくつですか？

検索スコープを共有するだけなら技術的なハード制限はなく、約2,000が実用の目安です。ただし用途によって参照すべき数字は別です。ナビにハブ内の全サイトを出すなら推奨は100以下、サイトWebパーツで一覧を動的に表示するなら99が上限になります。何を実現したいかを先に決めてから、対応する数字を設計値に採ります。

Viva Connectionsは追加費用なしで使えますか？

Enterprise、Frontline、Academicのいずれかのライセンスがあれば、一つのエクスペリエンスの作成と利用まではMicrosoft 365サブスクリプションの範囲です。二つ以上（最大50）を作る場合は、テナント内の全ユーザーにMicrosoft Viva SuiteまたはViva Communications and Communitiesのライセンスが必要になります。対象者ごとに別のダッシュボードを出したい要件が出た時点で費用の検討対象です。

関連記事

• 社内ポータルサイトとは？機能・作り方・内製と外注の判断基準まで解説：社内ポータルの定義と発注前の判断
• 見やすい社内ポータルのデザイン｜掲載の優先順位と四つのレイアウト型、作り込む判断基準：掲載順序とレイアウト型の選び方
• 社内ポータルの事例を四つの用途パターンで読み解く｜自社に再現できる条件と設計の勘所：用途パターン別の再現条件
• 社内ポータルの費用相場と内訳｜SaaSと個別開発が逆転する規模と年数の分岐点：SaaSと個別開発が逆転する分岐点