SharePoint リスト（Microsoft Lists）で「ビューの書式設定」を使い、交互の行スタイルに“罫線（Border／境界線）”を付けたいのに、ボタンがマウスオーバーしても反応せず選択できない──この症状に遭遇すると、設定が壊れたのか、権限の問題かと不安になります。本記事では、原因の考え方と、現場で止まらないための現実的な回避策（高度なモード／JSON運用）を具体例つきでまとめます。
起きていること：UIの「境界線」だけが押せない／効かない
問題のポイントは「境界線（Border）をUIで選べない」ことです。一般的に、以下の操作経路で発生します。
- リストのビュー（例：すべてのアイテム）を開く
- 「現在のビューの書式設定（Format current view）」を開く
- 「交互の行スタイル（Alternating row styles）」→「行スタイルの編集（Edit row styles）」
- 「その他のスタイル（More styles）」→「境界線（Borders）」
本来は「その他のスタイル」内から境界線（罫線）を設定できる設計で、Microsoftのサポート記事でも「More styles から border を追加できる」旨が説明されています。
ところが、該当の不具合では、境界線の選択肢が表示されていても、マウスオーバーやクリックに反応せず選択できません。一方で「高度なモード（Advanced mode）」に切り替えてJSONを貼り付けると、罫線表示が正しく反映される──というのが典型パターンです。
まず切り分け：SharePoint（サイト）とMicrosoft Lists（アプリ）で挙動がズレる場合がある
ここで混乱しやすいのが、同じ“リスト”でも開き方が複数ある点です。たとえば、SharePoint サイト上のリスト表示と、Microsoft Lists（lists.microsoft.com 側の体験）での表示が完全に同一とは限らず、「プレビューでは見えるが保存後に表示されない」「SharePointでは見えるがListsでは見えない」といった別種の現象も報告されています。
| 観点 | 症状例 | よくある勘違い | 最初にやる対処 |
|---|---|---|---|
| UI操作そのもの | 境界線ボタンがホバーしても反応しない／選べない | 「権限不足」「ブラウザ設定が原因」と思い込みがち | JSONで回避しつつ、再現情報を整理して報告 |
| 表示反映 | プレビューでは罫線が見えるのに保存後に消える（特にLists側） | 「JSONが間違い」と思い込みがち | SharePoint側とLists側の差分を切り分け（どちらで再現するか） |
今回の質問文の状況（UIが選べないが、JSONは効く）は「表示エンジンは生きているが、UIのスタイル選択部分が壊れている」タイプで説明がつきます。
原因の考え方：ユーザー環境より“サービス／UI側の不具合”の可能性が高い
この現象は、単発のユーザー環境起因というより「Microsoft 側でも再現している／長期にわたり同様の報告が継続している」ことが強い根拠になります。
- 2023年8月の時点で、境界線をUIから選べない問題が投稿され、Microsoft側スタッフが「こちらでも再現できた」と回答しています。
- その後も、2024年5月、2025年6〜7月、2025年8月末の時点でも「未解決」とする投稿が同一スレッド内で継続しています。
また、公式サポート記事では現在も「交互の行スタイル → More styles から border を追加できる」操作が前提として案内されています。つまり“機能が廃止されたから選べない”というより、UIの回帰（ある時期の更新でクリック判定が壊れた等）として捉える方が自然です。
最優先の回避策：高度なモード（JSON）で罫線を定義して運用する
結論から言うと、JSONが効いているなら「機能自体は使える」ので、UIが直るまでの現実解は 高度なモード（Advanced mode）でJSON管理に切り替える ことです。公式サポートでも、ビュー書式をJSONで行う場合は Advanced mode を使う流れが案内されています。
手順（最短）
- 対象リストを開く
- 「現在のビューの書式設定（Format current view）」を開く
- 右ペインの下部にある「高度なモード（Advanced mode）」を選ぶ
- JSONを貼り付けて保存
すぐ使えるJSON例：全行に下罫線（1px・実務で一番扱いやすい）
罫線を“行の区切り”として見せたい場合、上下両方に線を引くより、下罫線だけ にする方が太りにくく、見た目も安定します。
{
"$schema": "https://developer.microsoft.com/json-schemas/sp/view-formatting.schema.json",
"additionalRowClass": "sp-field-borderBottomRegular sp-field-borderBottomSolid sp-css-borderBottomColor-neutralPrimary"
}ここで使っている sp-field-border* 系のクラスは、SharePoint / Lists の書式サンプル集でも「Regular=1px、Semibold=2px、Bold=3px」「Solid/Dashed/Dottedで線種を変える」と整理されています。
交互の行色＋罫線（UIでやりたかった内容をJSONで再現）
交互の行スタイル相当は、@rowIndex を使って偶数行だけ背景色クラスを返すのが定番です。Microsoft Learn のビュー書式サンプルでも additionalRowClass と @rowIndex%2 を用いた例が示されています。
{
"$schema": "https://developer.microsoft.com/json-schemas/sp/view-formatting.schema.json",
"additionalRowClass": "=if(@rowIndex%2==0,'ms-bgColor-themeLight sp-field-borderBottomRegular sp-field-borderBottomSolid sp-css-borderBottomColor-neutralPrimary','sp-field-borderBottomRegular sp-field-borderBottomSolid sp-css-borderBottomColor-neutralPrimary')"
}ポイントは、ifの返り値（文字列）にクラスをスペース区切りで複数入れられる ことです。これで「交互の行色」と「罫線」を一度に適用できます。
罫線を太く／点線にしたい場合の変更表
| やりたいこと | 置き換えるクラス | 例 |
|---|---|---|
| 線を太くする | Regular → Semibold / Bold | sp-field-borderBottomSemibold（2px）、sp-field-borderBottomBold（3px） |
| 点線／破線にする | Solid → Dotted / Dashed | sp-field-borderBottomDotted / sp-field-borderBottomDashed |
| 上下に線を出す | Bottom → TopBottom | sp-field-borderTopBottomRegular sp-field-borderTopBottomSolid |
色は sp-css-borderBottomColor-* などの系統で指定することが多く、質問文のように neutralPrimary を使うと“目立ちすぎないが読みやすい”線になりやすいです（テーマに追従するため）。
補足：rowFormatterを使う前に知っておきたい注意点
ビュー書式には additionalRowClass のほかに rowFormatter がありますが、rowFormatter は行の描画そのものを上書きする強力な方法です。その代わり、rowFormatterを指定するとadditionalRowClassは無視される（併用できない） ことが明記されています。まずは additionalRowClass で目的が達成できるかを優先すると、安全に運用しやすいです。
JSON運用を“事故らせない”ための実務チェックリスト
UIが直ったタイミングで「なんとなくUIで触って保存」すると、せっかくのJSONが上書きされることがあります。運用上は “設定をコードとして扱う” 意識が効きます。
| 観点 | おすすめ | 理由 |
|---|---|---|
| 保管場所 | テキストファイルとして別管理（社内Wiki／SharePoint文書／Git等） | 事故で消えても復旧が早い |
| 命名 | 「List名_View名_目的_日付」などで管理 | どれがどのビューのJSONか迷わない |
| 変更手順 | 変更前に必ず現行JSONをコピーして退避 | UI更新や誤操作で崩れたときに即戻せる |
| 横展開 | テンプレJSONを作って、クラス名だけ差し替え | 複数ビューに同一の“見た目ルール”を適用しやすい |
根本対応：Microsoft 365 管理センターから“不具合として報告”する
この症状は、現場で回避しながらも、根本的にはサービス側の修正が必要です。実際、Microsoft側スタッフも「Microsoft 365 管理センター → Health（正常性）→ Service health（サービス正常性）から問題を報告してほしい」と案内しています。
報告の通りやすさは “再現性の伝え方” で大きく変わります。最低限、次の情報を添えるのが現実的です。
| 添える情報 | 具体例 | 意図 |
|---|---|---|
| 発生画面 | SharePointサイト／Microsoft Lists（Web）／Teams内タブ など | “どのホスト”の不具合か特定しやすい |
| 再現手順 | Format current view → Alternating row styles → Edit row styles → More styles → Borders でクリック不可 | サポートが同じ操作で追える |
| 発生開始時期 | 「2025/12上旬から」など | サービス更新との相関を追える |
| 影響範囲 | 特定リストのみ／複数リストで発生／複数ユーザーで発生 | データ依存かUI全般か判断材料になる |
| ブラウザー情報 | Edge/Chrome、バージョン、拡張機能有無 | 回避策（拡張機能・互換性問題）を潰せる |
| 証跡 | 短い画面録画（ホバーしても反応しないのが分かるもの） | 説明が難しい“不反応系”の最短理解 |
切り分けとして試す価値があること（ただし“根治”は期待しすぎない）
本件は“同様の再現が複数年にわたり報告されている”ため、個別環境の最適化で直る可能性は高くありません。とはいえ、サポートへ報告する前の切り分けとしては有効です。
| 試すこと | 狙い | メモ |
|---|---|---|
| シークレット／InPrivateで再現するか | キャッシュ・Cookie・拡張機能の影響を除外 | 再現したら“ユーザー環境要因”の線が薄くなる |
| 拡張機能（広告ブロッカー等）を無効化 | UI部品のクリック判定を阻害していないか確認 | 業務端末で多い原因なので一度は試す |
| 別ブラウザー（Edge/Chrome）で比較 | ブラウザー依存の不具合か確認 | 両方で同じならサービス側寄り |
| 表示倍率を100%に戻す | レイアウト崩れ・当たり判定ズレの可能性を排除 | とくに125%運用端末は試す価値あり |
| 別端末／別ユーザーで再現 | 端末固有・ユーザー固有の問題か確認 | 複数で再現する情報は報告で強い |
よくある質問
JSONで罫線を付けると、リストのデータ自体は変わりますか？
変わりません。ビュー書式は“表示（見え方）”を調整する機能で、リストデータを変更しないことがサポート記事でも明記されています。
そもそもビューの書式設定ができる権限は？
目安として「ビューを作成・管理できる人」がアクセスできます。サポート記事でも「ビューを作成・管理できる人が view formatting にアクセスできる」と説明されています。
@rowIndexは並び替えやフィルターでズレませんか？
@rowIndex は“ビュー上で描画された行のインデックス”を表すトークンで、並び替えやフィルター後の表示順に対して 0 から振られます（描画位置に基づく）。仕様として説明されています。
まとめ：止めないための現実解は「JSONで運用」＋「報告で根本修正を促す」
UIで境界線が選べないのに、JSONを貼ると反映する──この時点で、リストの書式機能そのものが死んでいるわけではなく、UI側の不具合として考えるのが合理的です。同様の報告が長期にわたり継続していることからも、まずは高度なモード（JSON）で運用を止めず、同時に Microsoft 365 管理センターから再現情報を添えて報告する、という二段構えが最も実務的です。
最後に、運用で一番効くコツは「JSONを資産化する」ことです。テンプレ化しておけば、UIが不安定な時期でも、同じ見た目を再現するコストが一気に下がります。
コメント