SharePoint Online モダンページの出し分け完全ガイド：Audience Targetingの限界とSPFxでの実装方法

SharePoint Online のモダンページで「ユーザーの所属（部署・役割・地域・グループ）によって、表示する Web パーツやコンテンツを出し分けたい」と考えるのは自然な流れです。一方で、Audience Targeting（対象ユーザー設定）を有効にしたはずなのに“全員が同じ内容を見てしまう”ケースも多発します。本記事では、標準機能でできること／できないことを整理し、要件が厳しい場合に SPFx（SharePoint Framework）で現実的に解決する方法まで具体的に解説します。

SharePoint Online モダンページで「出し分け」が求められる典型シーン

まず、なぜモダンページで出し分けが必要になるのかを整理すると、要件の論点がブレなくなります。現場で多いのは次のようなケースです。

部門ポータルのトップで、営業には営業向けの申請・資料、情シスには運用情報、管理部門には規程改定の告知を優先表示したい
同じ会社ポータルでも、地域（国内／海外、拠点）や雇用形態（社員／委託／派遣）で、案内すべきコンテンツが違う
オンボーディング（入社直後）だけに見せたいガイドやチェックリストがある
Teams から Viva Connections を使っていて、ダッシュボードカードも含めて「その人に必要な導線だけ」を出したい

このような要件は「情報が見えないと困る」だけでなく、「見える情報が多すぎて探せない」を解消する目的（ノイズ削減）でもあります。つまり、出し分けにはパーソナライズ（表示の最適化）とセキュリティ（アクセス制御）の2種類が混ざりがちです。ここを最初に切り分けるのが重要です。

最重要：Audience Targeting は“表示のフィルタリング”であって“権限（セキュリティ）”ではない

Audience Targeting（対象ユーザー設定）は、SharePoint の公式ドキュメントでも「特定のユーザーに優先表示／フィルタ表示する」仕組みとして説明されています。つまり、設計としては「見せたい人に目立たせる」ための機能で、機密情報を守るためのアクセス制御の代替には向きません。

観点	Audience Targeting（標準）	権限（アクセス制御）	SPFx（カスタム）
目的	関連情報を優先表示し、ノイズを減らす	閲覧できる人／できない人を厳密に分ける	要件に合わせて表示ロジックを自由に作る
「見えない＝アクセス不可」	原則NG（表示のフィルタ）	OK（権限で遮断）	設計次第（実装だけだとNGになりがち）
出し分け単位	対応しているWebパーツ／ページ等に限定	サイト／ライブラリ／アイテム単位が中心	Webパーツ内部で任意のブロック単位に可能
条件の自由度	基本はグループ中心	権限設計の範囲内（条件分岐は弱い）	部署・役職・複数条件・期間など柔軟
運用負荷	低〜中（グループ管理次第）	中〜高（権限の設計/変更管理が重い）	中〜高（開発・保守・監視が必要）

結論として、「見せたい人にだけ見せる（機密性あり）」なら権限設計が基本です。「誰でもアクセスできてよいが、表示を最適化したい」なら Audience Targeting で十分なことが多いです。そして、「ページ内の任意ブロックを複雑な条件で出し分けたい」場合は、SPFx が現実解になります。

Audience Targeting（対象ユーザー設定）でできること・できないこと

まず、Audience Targeting が適用できる場所は“何でも”ではありません。Microsoft のサポート情報でも、対象ユーザー設定を有効化できる場所が整理されています。代表的なものをまとめると次の通りです。

対象（モダン）	Audience Targeting の主な用途	現場での使いどころ	注意点
ナビゲーション（グローバル/ハブ/フッター等）	リンクを対象ユーザーにだけ表示	部門ポータルや管理メニューの出し分け	まずサイト側で有効化が必要
ページ（Site Pages ライブラリ）	ページ自体を対象ユーザーに優先表示/フィルタ	ニュースや案内ページの対象者限定表示	公開/再公開が必要
News Web パーツ	ニュースを対象者に優先表示	部門別ニュース、拠点別告知	Webパーツ側でもトグルONが必要
Highlighted Content（強調表示されたコンテンツ）	ライブラリ/リストのコンテンツを対象者にフィルタ表示	関連ドキュメントのロールアップ	ライブラリ側の有効化＆Webパーツ側の有効化が必要
Quick Links Web パーツ	リンク単位で対象者を指定	「あなた向け」導線をページ上に作る	リンクごとの設定漏れが起きやすい
Events Web パーツ	イベントを対象者にだけ表示/優先表示	研修、説明会、拠点イベント	反映に時間がかかることがある
Viva Connections（ダッシュボードカード等）	カードやリソースリンクの出し分け	Teams 入口の導線最適化	フィルタでありセキュリティではない

次に、よく誤解される（＝期待してしまう）が実現が難しいポイントを明確にします。

ページ内の任意ブロック（セクションやWebパーツ）を、条件で自由に表示/非表示：標準機能だけでは難しい
部署・役職・地域などプロフィール属性での複雑な条件分岐：標準は基本グループ中心で、属性条件は“グループの作り方で代替”が必要
SharePoint グループ前提の出し分け：対象ユーザー設定は Microsoft Entra ID（旧 Azure AD）グループが中心
即時反映：新規グループやメンバー変更は反映遅延が起き得る

特に重要なのが「どのグループが対象になるか」です。Microsoft の案内では、対象ユーザー設定はMicrosoft Entra ID（Azure AD）グループ（セキュリティグループ、Microsoft 365 グループ、動的グループなど）をサポートすると明記されています。

また、ナビゲーションの説明では動的グループはテナントによって一部サポートという注意もあり、環境差が出ることがあります。

「全ユーザーで同じ内容が見える」よくある原因と、最短で切り分ける手順

Audience Targeting を設定したのに全員が同じ内容を見てしまう場合、原因は大きく次の4系統に分かれます。

そもそも有効化が足りていない（サイト/ライブラリ/Webパーツのどこか）
対象ユーザーが想定のグループになっていない（SharePoint グループ、未同期、種類の違い）
対象設定をしたつもりでも公開/再公開がされていない
反映遅延やキャッシュ等ですぐに効かない

症状	原因候補	確認ポイント	対処
HCWP（Highlighted Content）で誰でも同じ	ライブラリ側の Audience Targeting 未有効	対象のライブラリ/ページライブラリで「Audience targeting settings」がONか	ライブラリで有効化→アイテム（ページ/ファイル）にAudienceを設定
Quick Links が全員表示	Webパーツ側のトグルOFF、リンク個別設定漏れ	Webパーツの設定で Audience targeting をONにしたか／各リンクにAudienceが入っているか	WebパーツON→各リンクに対象グループ設定
対象グループを選べない/検索で出ない	SharePoint グループ、未同期、グループ種類の問題	Entra ID 側でグループが存在し、対象ユーザー設定のピッカーに出るか	Entra ID グループを使用（必要なら運用見直し）
対象設定したのに効かない	公開/再公開していない	ページ/ニュース/設定変更後に Publish（再公開）したか	再公開して反映
昨日まで効いていたのに効かない	メンバー変更直後、動的グループ評価遅延	グループの更新タイミング／反映遅延の可能性	時間を置く、対象者で再ログイン、キャッシュ影響を確認

特に HCWP は「Web パーツの設定だけ」で完結しません。Microsoft の説明でも、ライブラリ側で Audience Targeting を有効化し、対象を設定し、さらに Web パーツ側でも有効化するという流れが前提になっています。

また、Quick Links も同様で、Web パーツのプロパティで Audience targeting をONにした上で、リンクごとに対象ユーザーを指定する必要があります。

そして見落とされがちなのが「公開/再公開」です。Microsoft の案内でも、ページのメタデータや対象ユーザー設定を変更した場合はPublish（再公開）が必要とされています。

標準機能だけで“それっぽく”実現する設計パターン

要件が「任意のWebパーツ単位で高度に出し分けたい」ほど厳しくない場合、標準機能だけでもかなり近づけられます。ポイントは、出し分ける対象を“ページ丸ごと”か“リンク/カード/ロールアップ”に寄せることです。

パターン：ページを分けて、ナビゲーションと Quick Links を対象ユーザーで出し分ける

「同じページの中でブロックを切り替えたい」欲求を、ページ分割で吸収するやり方です。

営業向けトップ：営業が必要なリンク・ニュース・手順を掲載
情シス向けトップ：障害情報・メンテ告知・申請窓口を掲載
管理部門向けトップ：規程・稟議・勤怠を掲載

そして、上部ナビ/ハブナビ/フッターや Quick Links で、対象ユーザーにだけリンクを見せます。これにより「同じ場所に来たのに迷う」を減らせます。ナビゲーションの対象ユーザー設定はサイト所有者が有効化する必要がある点も押さえましょう。

パターン：News と Events を“対象ユーザーで流す”ことでページの出し分けを代替する

ページ内のセクション出し分けが難しくても、ニュースやイベントを対象別に流せれば、結果として「その人が見るべき情報」がトップに集まります。Microsoft の説明でも News / Events / HCWP / Quick Links が対象として挙げられています。

パターン：プロフィール属性で分岐したいなら“動的グループ”で吸収する

Audience Targeting 自体はグループ中心です。ですが、Entra ID の動的グループを使って「部署=営業」「勤務地=大阪」のような条件でグルーピングし、そのグループを Audience として使えば、プロフィール属性の条件分岐を“グループの作り方”で実現できます。

ただし、動的グループは環境差や反映遅延があり得ます。特にナビゲーションの対象ユーザー設定については、動的グループが部分的にサポートされる旨の注意があるため、本番適用前に必ずテストしてください。

パターン：機密性が高いなら、出し分けではなく「権限で分ける」

「人事評価」「給与」「契約情報」など、見えてはいけない情報が混ざるなら、最初から“見せる/見せない”の設計ではなく、アクセス権限で分けるのが安全です。

機密コンテンツは別サイト／別ライブラリに分離し、閲覧権限を限定する
トップページには“機密コンテンツへのリンク”だけを出す（リンク自体も対象ユーザー設定や権限でコントロール）

Audience Targeting はフィルタであり、権限の代替ではないことは Viva Connections の公式情報でも明記されています。

標準機能の限界が出るポイント：なぜ「Web パーツ単位の出し分け」は難しいのか

結局のところ、質問の核心はここです。

「ページ上の任意のWebパーツ（あるいはセクション）を、ユーザー条件で表示/非表示にしたい」

これに対して、標準の Audience Targeting は以下の理由でハマりやすいです。

対象ユーザー設定を適用できるのは、Microsoft が対応している一部のモダンWebパーツに限定される
ページの自由レイアウト（テキスト、画像、埋め込み、サードパーティWebパーツ等）を、共通の仕組みで条件制御できるわけではない
条件が増えるほど、対象グループ設計（グループ乱立）と運用が破綻しやすい

ここまで来ると、「標準機能を“頑張って組み合わせる”」より、条件分岐を前提に作られたコンポーネント（SPFx）を導入した方が、品質・運用・拡張性の面で結果的に安くなることが多いです。

現実解：SPFx で“出し分けコンテナ Web パーツ”を作る

SPFx（SharePoint Framework）を使うと、モダンページ上に配置するカスタムWebパーツの中で、実行時にユーザー情報を取得し、条件に合うコンテンツだけをレンダリングできます。つまり、「ページ全体の中に、出し分け可能な“箱”を作る」という考え方です。

SPFx でできること（標準の限界を超えるポイント）

ユーザーのグループ所属（Entra ID グループ、Microsoft 365 グループ等）を取得して判定
ユーザーの属性（部署、役職、勤務地など）を取得して判定
複数条件（AND/OR、優先順位、例外、期限）を組み合わせたルールを実装
SharePoint グループやサイト権限の情報など、SharePoint 側の情報を使った判定（要件次第）
「同じWebパーツを置くだけ」で、どのページでも出し分けを再利用できる

ただし重要：SPFx の“表示制御”も、単体ではセキュリティにならない

SPFx はクライアント側で動くことが多いため、画面上で非表示にしても、API でデータを返してしまえば「開発者ツールなどで見られる」リスクが残ります。機密性がある場合は、次のように設計します。

そもそもデータは権限で保護された場所（別サイト/別ライブラリ/別API）に置く
SPFx は“表示の最適化”に徹し、データアクセスは権限ベースで自然に制限されるようにする
必要なら Azure Functions 等の中継APIを用意し、サーバー側で認可してから返す（高度）

SPFx の設計例：運用に耐える「ルール駆動」の出し分け

出し分けを SPFx で実装するときに、長期運用で効くのは「コードに条件を直書きしない」設計です。おすすめは、SharePoint リスト等に“表示ルール”を持たせ、Webパーツはそれを読み込んで表示する方式です。

構成イメージ

設定リスト（例：PersonalizationRules）：誰に何を出すかを定義（運用担当が更新）
SPFx Web パーツ（例：PersonalizedContent）：ユーザー情報を取得→ルール適用→表示
コンテンツの置き場：HTML、リンク、カード、FAQ、埋め込みなど（機密データは権限で保護）

ルール例（イメージ）

たとえばルールを次のように持つと、要件変更に強くなります。

優先度	条件（例）	表示する内容	期限	備考
1	department=営業 AND region=東日本	営業（東日本）向け：週次資料・商談テンプレ	なし	最優先
2	group=「情シス」	情シス向け：障害情報・変更申請	なし	運用導線
3	jobTitle contains “Manager”	管理職向け：承認フロー・KPI	なし	役職判定
99	（デフォルト）	共通：全社ポータル案内	なし	フォールバック

この形にしておくと、組織変更があっても「ルールの修正」で済み、SPFx の再リリース頻度を下げられます。

ユーザー情報の取得方法：どこから何を取るのが正解か

SPFx で出し分け判定をするとき、最初に悩むのが「属性やグループ所属をどこから取るか」です。用途別に整理します。

取得したい情報	候補	メリット	注意点
ユーザーの基本属性（表示名、メール等）	Microsoft Graph（/me）	標準的、拡張しやすい	権限スコープ設計が必要
部署・役職・勤務地などディレクトリ属性	Microsoft Graph（/me の属性）	属性分岐が可能	テナントの属性整備が前提
Entra ID グループ所属（ネスト含む）	Microsoft Graph（transitiveMemberOf）	ネスト含む所属判定が可能	大量グループ環境では性能と権限に注意
SharePoint サイト内の権限・グループ	SharePoint REST / PnPjs	サイト運用に寄せた制御ができる	サイトごとの差分が増えると複雑化
“対象ユーザー設定”の代替としての簡易判定	Entra ID グループ（固定/動的）	運用しやすい	グループ設計が重要（乱立しがち）

Entra ID グループ所属の取得には、Microsoft Graph の transitiveMemberOf がよく使われます。ユーザーの直接・間接（ネスト）所属を取得できる API としてドキュメント化されています。

また、SPFx から Microsoft Graph を呼び出す場合は、Microsoft Learn のガイドにある通り、SPFx が提供する Graph クライアントを使うのが基本です（MSGraphClientV3 など）。

SPFx 実装の具体イメージ（コードに依存しない説明）

ここでは“実装の勘所”がつかめるように、実際に作るときの処理の流れを、コードを最小限にして説明します。

処理フロー

ページ表示時、SPFx Web パーツが起動
現在ユーザーを判定（ログインユーザー）
必要な属性・グループ所属を取得（Graph / SharePoint）
設定リストからルールを読み込む（キャッシュ可）
上から順にマッチ判定し、最初に一致したルールのコンテンツを表示
一致しなければデフォルトを表示

ルールを JSON で持たせる例

設定リストの列に JSON を入れておくと、条件の柔軟性が上がります（運用しやすい形に調整可能です）。

{
  "priority": 10,
  "match": {
    "any": [
      { "groupId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" },
      { "department": "営業" }
    ],
    "all": [
      { "country": "JP" }
    ]
  },
  "content": {
    "title": "営業向けクイック導線",
    "links": [
      { "text": "見積テンプレート", "url": "https://..." },
      { "text": "稟議申請", "url": "https://..." }
    ]
  }
}

このように「条件（match）」と「表示（content）」を分離すると、コンテンツ変更のたびに SPFx を再デプロイする頻度を下げられます。

パフォーマンスと“体感速度”を落とさない工夫

SPFx で出し分けをやると、ユーザーごとに Graph へ問い合わせが走り、ページ表示が重くなるリスクがあります。実装では次の工夫が効きます。

最低限の最適化チェック

ルールの取得はキャッシュ（セッション内キャッシュ、短時間キャッシュなど）
グループ判定は“必要なときだけ”（全グループ一覧取得より、必要グループIDへの所属判定を優先）
初期表示はスケルトン/プレースホルダで「何も出ない時間」を短く見せる
条件を軽い順に評価（部署=営業の判定が取れるなら、巨大なグループ一覧取得より先に）
“ルールが増えたら遅くなる”前提で、運用ガード（上限、レビュー）を用意する

反映遅延を前提にした運用

Audience Targeting と同様に、グループ変更は即時反映しないことがあります。標準機能側でも「新規作成/変更したグループは反映に時間がかかる」旨が案内されています。SPFx 側でも同様の現象は起こり得るため、運用側で「人事異動直後はタイムラグがあり得る」などの周知・手順を用意しておくと、問い合わせが激減します。

要件別：標準機能で行くべきか、SPFx に踏み切るべきか

最後に、判断を短時間で行えるように、要件別のおすすめをまとめます。

要件	おすすめ	理由	補足
ニュースやリンク、イベントを部署ごとに出し分けたい	Audience Targeting（標準）	対応Webパーツで完結しやすい	再公開・反映遅延に注意
ページ内の任意ブロックを条件で切り替えたい	SPFx	標準では柔軟なブロック制御が難しい	“出し分けコンテナ”設計が安定
部署・役職・地域など属性で分岐したい	動的グループ or SPFx	標準はグループ中心、属性は工夫が必要	属性整備が前提
機密情報を対象者以外に見せたくない	権限設計（アクセス制御）	表示制御はセキュリティにならない	必要ならSPFxは補助として使う
SharePoint グループ中心の運用を崩せない	SPFx（または運用再設計）	対象ユーザー設定はEntra ID グループ中心	移行コストと将来性で判断

よくある質問

Audience Targeting を有効化したのに、HCWP で絞り込まれません

HCWP は「Web パーツ側のトグル」だけでは不十分なことが多いです。ライブラリ（例：Site Pages や Documents）側で Audience Targeting を有効化し、ページ/ファイル自体に Audience を設定し、最後に Web パーツ側でも Audience Targeting を有効化する流れを見直してください。

SharePoint グループで出し分けしたいのですが、対象ユーザーに出てきません

対象ユーザー設定は、基本的に Microsoft Entra ID（Azure AD）グループの利用が前提です。運用上どうしても SharePoint グループに寄せたい場合は、SPFx で SharePoint 側の情報を使って判定する、もしくはグループ運用を Entra ID グループに寄せる（将来性が高い）ことを検討します。

動的グループでプロフィール属性分岐をしたいのですが注意点は？

動的グループは便利ですが、評価のタイミングやテナント差（部分サポートの注意）で“すぐに反映されない”ことがあります。重要導線に使う場合は、対象者テストと反映遅延を織り込んだ運用が必要です。

SPFx を作るなら、どこまでを SPFx に持たせるべき？

おすすめは「出し分けロジックと表示の枠」までです。機密性のあるデータや、見えてはいけない情報そのものは、SharePoint の権限・別サイト・別ライブラリなどで守り、SPFx は“最適な導線を出す”に徹する方が、セキュリティも運用も安定します。Audience Targeting がフィルタでありセキュリティではない点は、Viva Connections の公式情報でも明記されています。

まとめ：標準の対象ユーザー設定は“万能”ではない。要件で割り切って設計する

SharePoint Online のモダンページでの出し分けは、まず「パーソナライズ」なのか「アクセス制御」なのかを分けることが成功の近道です。

ニュース／リンク／イベントなどの“優先表示”なら、Audience Targeting（標準）で十分
ページ内の任意ブロックを複雑な条件で切り替えたいなら、SPFx で“出し分けコンテナ”を作るのが現実的
機密情報を守りたいなら、権限設計が基本（表示制御に頼らない）

「標準で何とかする」か「SPFx で確実に作る」かは、機能の好き嫌いではなく、要件の厳しさと運用コストで決めるのが最適です。出し分けが“増え続ける”ことが見えているなら、早い段階でルール駆動の SPFx に寄せた方が、後からの修正が圧倒的に楽になります。

この記事を書いた人

佐藤健司

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