SharePoint モダンページのリストWebパーツでビュー切り替えを非表示にしたい｜新規（New）ボタンを残す対策

SharePoint モダンページの「リスト」Web パーツで、利用者にビュー切り替えをさせず、でも「新規（New）」は残したい――この要件は現場でよく出る一方、標準機能の範囲だと“あと一歩”が届きません。この記事では、できない理由を整理したうえで、権限・ページ設計・SPFx という現実的な落としどころを具体的に紹介します。

結論：標準機能だけで「ビュー切り替え UI だけ」を非表示にするのは難しい

SharePoint モダンページに配置する「リスト」Web パーツは、リストのモダン UI（コマンドバー＋表示オプション）をそのままページ上に持ってくる形です。そのため、「+ 新規」は残して、右上のビュー選択（表示オプション／Switch view options）だけを消すといったピンポイント制御は、標準機能としては用意されていません。

できることの方向性は大きく次の3つに分かれます。

方向性	狙い	要件との相性	現実的な手段
権限制御	ビューの作成・編集をさせない（運用固定）	「UIを消す」ではないが、誤操作抑止に強い	カスタム権限レベル（Manage Lists 等を外す）
ページ設計	コマンドバー自体を出さず、別導線で新規作成へ	「UIを見せない」を満たしやすい	リスト Web パーツでコマンドバー非表示＋ボタン Web パーツ
カスタム開発	特定 UI だけを隠す（見た目をピンポイントで変更）	要件に最も近いが、保守・更新リスクが高い	SPFx（Application Customizer で CSS 注入など）

「ビュー選択だけ」を隠せない理由を押さえる

ビュー切り替えは “表示オプション” としてコマンドバー側の UI に組み込まれている

SharePoint のモダンリストでは、ビューの切り替えは画面右上の「表示オプション（View options）」メニューから行う設計です。つまり、ビューは“ページ上の装飾”というより、リスト体験そのものの一部として提供されています。

JSON のコマンドバー書式設定で隠せるのは「キーで定義されたコマンド」だけ

SharePoint / Microsoft Lists には、コマンドバーを JSON でカスタマイズする仕組みがあります。ここでは「new」「share」「export」など、“コマンドとして定義されているボタン”は非表示にできます。

一方で、ビュー選択（Switch view options）やフィルター／詳細ペインなどの右上アイコン群は、JSON カスタマイズの対象キーとして提供されていないため、JSON だけでビュー選択だけを消すことはできない、という整理になります。

参考として、コマンドバー JSON はたとえば次のように「左側のボタン」中心に制御できます（ビュー選択自体は対象外です）。

{
  "commandBarProps": {
    "commands": [
      { "key": "new", "hide": false, "text": "新規登録" },
      { "key": "share", "hide": true },
      { "key": "export", "hide": true },
      { "key": "editInGridView", "hide": true }
    ]
  }
}

ビュー単位で「見せる／見せない」の権限分離は基本的にできない

「特定のビューだけ一般ユーザーに見せたい」「内部メンバーだけ別ビューを使いたい」という相談は多いのですが、SharePoint Online / Microsoft Lists では、ビュー単位のカスタム権限を OOTB（標準機能）で付ける仕組みは基本的にありません。リストにアクセスできるユーザーは、公開ビュー（Public view）にはアクセスできてしまう、というのが前提になります。

代替策：権限で「ビュー運用」を固定化する（作成・編集させない）

「ビュー選択を隠す」という見た目の要件は満たせなくても、実務上よく効くのが“ビューを増やされない・変えられないようにする”対策です。これにより、運用が崩れにくくなり、結果として利用者の混乱も減ります。

この対策で守れること／守れないこと

観点	期待できること	期待できないこと
誤操作防止	勝手にビューを作る／既存ビューを変更する行為を抑止	既存の公開ビューをユーザーが切り替える行為そのものは残る
UIの見た目	一部の編集メニューが出なくなる（権限次第）	ビュー選択ドロップダウンが消えるわけではない
保守性	標準機能なのでアップデート耐性が高い	要件が「UIを見せない」だとギャップが残る

手順：カスタム権限レベルを作成してユーザーに付与する

基本の考え方はシンプルです。「新規登録（Add Items）」は許可しつつ、「リストの管理（Manage Lists）」や個人用の設定系権限を外す権限レベルを作り、それを一般ユーザー用グループに割り当てます。

1. 設定 → サイトのアクセス許可 → 詳細なアクセス許可設定 を開く
2. 権限レベルへ移動し、既存レベル（例：投稿/編集/共同作成など）をコピーして新しい権限レベルを作成
3. 新しい権限レベルで、少なくともリストのアクセス許可の 「リストの管理（Manage Lists）」 を外す（必要に応じて個人用権限も整理）
4. その権限レベルを付与したSharePoint グループを作り、対象ユーザーを追加

権限設定の目安（新規登録が必要なケース）

リストの種類や運用（登録後に編集させるのか、削除は許すのか、承認があるのか）で最適解は変わりますが、「ユーザーが入力する」用途でよくある目安をまとめます。

権限（例）	推奨	理由／影響
アイテムの表示（View Items）	ON	一覧を見せるなら必須
アイテムの追加（Add Items）	ON	「新規（New）」で登録させるために必須
アイテムの編集（Edit Items）	要件次第	「登録後の修正」を許可するならON。禁止するならOFF＋運用設計で補う
アイテムの削除（Delete Items）	要件次第	削除を許すとデータ消失リスク。通常は制限したい
リストの管理（Manage Lists）	OFF	列・ビュー・フォーム・設定など運用を崩す操作につながりやすい
個人ビュー関連（個人用の設定系）	基本OFF	個人ビューを作られると、サポート負荷が上がる／UIの分岐が増える

「ビューを固定したい」のが主目的なら、まずは公開ビューの数を最小限にする（一般ユーザー向けページでは1ビューしか使わない）という運用も効きます。ビュー選択が残っても、切り替える先が実質1つなら混乱が起きにくい、という発想です。

現実的な落としどころ：コマンドバーを隠して「新規登録」導線を別に作る

要件が「ビュー選択を見せたくない（UIとして存在させたくない）」であれば、ページ設計で解決するのが一番安定します。具体的には、リスト Web パーツのコマンドバーを丸ごと非表示にして、別の Web パーツ（ボタン／クイックリンク）で「新規作成フォーム」に誘導します。

SharePoint の List web part は、ページ上でリストを表示し、上部の + New から新規追加できることが公式にも説明されています。逆に言えば、そのコマンドバーを隠すと、ビュー切り替え UI もまとめて消えます。

手順：リスト Web パーツの「Hide command bar」を使う

環境や表示言語で表記は揺れますが、一般的に「コマンドバーを隠す（Hide command bar）」のようなトグルが用意されています。Microsoft Q&A でも、リスト Web パーツの設定から「Hide command bar」を使える旨が案内されています。

1. 対象ページを編集モードにする
2. 「リスト」Web パーツを選択し、プロパティ（Web パーツの設定）を開く
3. Hide command bar（コマンドバーを非表示） を有効化する
4. 必要なら See all（すべて表示） などのリンクも非表示にする
5. ページを公開する

「新規（New）」ボタン相当をページに置く方法

コマンドバーを非表示にすると「+ 新規」も消えるため、代わりにページ上に“登録ボタン”を用意します。やり方は難しくありません。

• ボタン Web パーツ、またはクイックリンク Web パーツを追加する
• リンク先に「新規作成フォーム」の URL を設定する

新規作成フォームの URL を確実に取るコツは、リスト本体の画面で「新規」からフォームを開き、その URL をコピーすることです。リストの構成（リスト名・サイト構造・フォームのカスタマイズ有無）によって URL が変わり得るため、テンプレート的に決め打ちするより安全です。

この方式が向いているケース／向いていないケース

評価軸	向いている	向いていない
目的	ユーザーに余計な UI を見せず、登録だけさせたい	ユーザーが複数ビューを業務で使い分ける必要がある
運用	ページ設計で導線を固定したい（教育コストを下げたい）	リスト本体の画面での操作も含めて統一したい
保守	標準機能中心で、更新耐性を重視したい	「見た目を完全に同一にしたい」などデザイン要件が強い

この方式のポイントは、「UIを隠す」ことを標準機能で安全に実現しつつ、必要な“新規登録”だけは別の入口として確保するところにあります。要件に対する “壊れにくい現実解” として選ばれやすいパターンです。

どうしてもビュー選択を UI から消したい場合：SPFx で CSS を注入する

「新規はコマンドバーに残したい」「ボタンを別に置くのは嫌」「ビュー選択だけ消したい」という場合、標準機能外のアプローチになりやすく、代表例が SPFx（SharePoint Framework）の Application Customizer を使った CSS 注入です。

Microsoft Tech Community でも、OOTB では不可で、SPFx で要素を隠す（例：title が “Switch view options” のボタンを非表示にする）という回避策が提示されています。ただし、DOM 変更で壊れる可能性がある点も明記されています。

CSS の例（イメージ）

button[title='Switch view options'] {
  display: none !important;
}

SPFx/CSS での非表示が抱えるリスク

リスク	起きやすい問題	現場での対策
更新で壊れる	HTML 構造や属性が変わり、CSS が効かなくなる／別要素を誤って隠す	定期的な回帰テスト、Targeted Release での事前検証
セキュリティにならない	UI を隠しても、URL 直打ちや別導線で到達できる可能性	本当に守りたいのが「データ」なら権限設計を先に固める
サポート負荷	トラブル時の切り分けが難しく、担当者依存になりやすい	実装・運用ドキュメント化、代替導線の確保

“見た目の要件” と “保守性” のどちらを優先するかで、SPFx は最終手段として位置付けるのが無難です。

「ビュー切り替えをさせたくない」の目的別に、最適解は変わる

同じ「ビュー切り替え禁止」に見えても、背景が違うと打ち手が変わります。ここを整理せずに UI 非表示だけに寄せると、後で破綻しやすいです。

本当の目的	ありがちな状況	優先すべき対策
誤操作を減らしたい	「表示が変わった」「見えない」問い合わせが多い	権限制御＋公開ビューの整理（ビュー運用の固定化）
利用者に“入力だけ”させたい	フォーム入力が目的で、一覧は補助的	コマンドバー非表示＋ページ上の登録ボタン（導線固定）
見せてはいけない情報がある	列やアイテムが一部ユーザーには機密	ビューではなく権限（別リスト化、アイテムレベル権限、別サイト等）

特に最後の「機密情報」パターンは注意が必要です。ビューはあくまで“見せ方”であり、閲覧権限があるデータをビューで隠しても、別の表示やエクスポートなどで露出する可能性があります。守りたいのがデータなら、最初に権限設計を固めるのが鉄則です。

おすすめの判断フロー（迷ったときの決め方）

質問	YES の場合	NO の場合
「ビュー選択を消す」ことが絶対条件？	まずページ設計（コマンドバー非表示＋登録ボタン）を検討	権限制御（ビュー作成・編集を抑止）で運用固定化
「+ 新規」をコマンドバーに残す必要がある？	SPFx を含むカスタム（ただし更新リスクあり）	ボタン Web パーツで新規作成へ誘導が最も安定
データ秘匿が目的？	ビューではなく権限（別リスト／別サイト／アイテム権限）	UI・運用の簡素化を優先して設計

よくある質問

公開ビューを1つだけにすれば、ビュー選択の UI は消えますか？

実務上は「切り替える先がなくなる」ため混乱は減りますが、表示オプション（ビュー名＋ドロップダウン）が完全に消えるとは限りません。UI を確実に見せない要件なら、コマンドバー非表示＋登録ボタン方式が確実です。

「ビューだけ内部向けにしたい（一般ユーザーには特定ビューを見せたくない）」はできますか？

標準機能としては、ビュー単位で権限を付ける設計は難しく、リストにアクセスできるユーザーは公開ビューに到達できる前提になります。要件が「特定列は見せない」「内部向けの列がある」なら、ビューではなく権限・設計（別リスト、アイテムレベル権限、分離サイト等）に寄せるのが安全です。

結局、どれが一番おすすめですか？

多くの現場では、「コマンドバーを非表示にして、ページ上に新規登録ボタンを置く」が、要件達成・運用の安定・更新耐性のバランスが良いです。次点で、権限を調整してビュー運用を固定化する方法が「標準機能だけでできる」範囲として堅実です。ピンポイント非表示（SPFx/CSS）は、どうしても必要な場合の最終手段として扱うと事故が減ります。