SharePoint リストフォームで特定セクションだけ色付けしたい時の限界と現実的な回避策【JSON 解説】

「このセクションだけ赤くしたいんだけど、JSONでいじれない?」――モダン SharePoint のリスト フォームを触っていると、ほぼ必ず出てくる要望です。ところが実は、ネイティブ機能(JSON を含む)だけでは「特定セクションの色・枠線変更」はできません。本記事ではその理由と、現実的な回避策・代替案、そして JSON の範囲で使える“擬似強調テクニック”をまとめて解説します。

目次

SharePoint リスト フォームの仕組みを整理する

まずは「どこまでが JSON で制御できるのか」を整理しておきます。モダン SharePoint のリスト フォームは、大きく次の 3 つのパートに分かれています。

  • ヘッダー(Header):フォーム上部。タイトルやアイコン、メッセージなどを JSON でカスタマイズ可能。
  • 本文(Body):実際の入力欄(フィールド)が並ぶ部分。JSON では「セクション」と「セクション内に並べる列」を定義。
  • フッター(Footer):フォーム下部。補足説明やボタン風 UI などを JSON で追加可能。

このうち「セクション」に関係するのは本文(Body)の JSON です。公式ドキュメントでも、Body の JSON は「セクションを定義し、そのセクションに含めるフィールドを指定する」ためのものであると説明されており、CSS 風のスタイル指定は対象外とされています。

フォーム JSON でできること・できないこと一覧

対象主な用途色・枠線の変更対象範囲
フォーム ヘッダー JSONタイトル・説明文・アイコンなどを表示背景色・文字色などを JSON で指定可能フォーム全体
フォーム Body JSONセクション分割、フィールドの並び順を制御不可(セクション単位の色・枠線などは指定できない)フォーム全体(構造のみ)
フォーム フッター JSON注意書き・リンク・簡易ボタン風 UI など背景色・文字色などを JSON で指定可能フォーム全体
列(カラム)書式 JSONリスト ビュー 上のセル表示を変更セルの背景色・文字色などを条件付きで変更可能ビューのみ(フォームには影響しない)

この表からも分かる通り、フォーム本文のセクションそのものにはスタイルを当てる仕組みがありません。「第 2 セクションだけ赤く」「このセクションの枠線だけ太く」といったことは、JSON だけではどうやっても実現できない仕様です。

なぜ JSON だけでは「特定セクションの色変更」ができないのか

Body の JSON は「構造定義専用」に近い

フォームの Body JSON は、ざっくりいうと「どの列をどの順番で並べるか」「どの列をどのセクションに属させるか」を宣言するだけの仕組みです。実際の JSON の骨組みは次のようになります。

{
  "sections": [
    {
      "displayname": "基本情報",
      "fields": [ "Title", "Category", "Status" ]
    },
    {
      "displayname": "詳細情報",
      "fields": [ "Description", "DueDate" ]
    }
  ]
}

ここで指定できるのは、あくまで displayname(セクションの見出し)と、fields(その中に含める列)だけです。「style」や「class」を付けるプロパティは用意されておらず、DOM や CSS に直接触れることもできません。

ヘッダー/フッターの JSON は「全体」にしか効かない

ヘッダーとフッターは、elmType や style を使ってかなり自由にデザインできます。例えば、フォーム全体の上部に赤い帯を出すことは簡単です。

{
  "elmType": "div",
  "style": {
    "background-color": "#a80000",
    "color": "white",
    "padding": "12px",
    "font-weight": "600"
  },
  "children": [
    {
      "elmType": "span",
      "txtContent": "重要情報を入力してください"
    }
  ]
}

ただし、このヘッダー JSON はフォーム上部の「帯」に対してだけ適用され、セクションの背景色・枠線には一切影響しません。フッターも同様で、「特定のセクションだけ」を狙い撃ちすることはできない設計になっています。

列(カラム)書式はあくまで「ビュー表示専用」

「列の JSON で色付けできるのだから、フォームの入力欄も同じように変えられそう」と考えがちですが、ここにも落とし穴があります。

  • 列書式は「リストビュー(一覧)」に表示されるセル・行のレイアウトを変える機能。
  • 新規アイテム/編集フォームで表示される入力コントロール(テキストボックスなど)は別物。

そのため、列書式でどれだけ派手に装飾しても、フォームの見た目はまったく変わりません。これは公式ドキュメントやコミュニティ Q&A でも繰り返し説明されているポイントです。

Microsoft Q&A でも「セクションの色変更は JSON では不可」と明言

Microsoft Q&A でも「特定のフォーム セクションだけ赤くしたい」という質問に対して、Microsoft スタッフから「セクションの境界線や色を JSON で変えることはできない」と明確に回答されています。

つまり現在の仕様では、「ネイティブ JSON だけでセクション単位の色付けをする」ことは不可能と考えてよく、いわば仕様の“壁”に当たっている状態です。

JSON の範囲でできる「擬似的な強調テクニック」

とはいえ、現場でよくあるのは「とにかくこのセクションを目立たせたい」というビジネス要件です。「色は変えられない」と分かっていても、ユーザーに気付いてもらう工夫はできます。ここでは JSON と標準機能だけで実現できる“擬似強調”のパターンを紹介します。

セクション名に記号・絵文字を使って視線を集める

一番手軽で効果が高いのが、セクション名(displayname)に絵文字や記号を入れる方法です。

{
  "sections": [
    {
      "displayname": "🔴 重要セクション(必ず入力)",
      "fields": [ "Title", "FieldA", "FieldB" ]
    },
    {
      "displayname": "📄 補足情報",
      "fields": [ "FieldC", "FieldD" ]
    }
  ]
}

色は変えられませんが、一覧でフォームを開いた瞬間に「赤い丸+『重要』」という文字が目に入るため、実務上はかなり高い注意喚起効果があります。複数の重要セクションがあるなら、絵文字を変えて“章立て”感を出すのもおすすめです。

セクションの順序で強弱をつける

人は上から順に入力していくことが多いので、「とにかくここから入力してほしい」セクションは一番上に持ってくるのが鉄則です。

  • 重要セクションを先頭に置く
  • 「必須入力ゾーン」「任意入力ゾーン」の順に配置する
  • 関連性が高い項目同士を 1 セクションにまとめる

これは JSON で sections の順番を変えるだけで実現でき、視線誘導という意味では非常に強力です。

フォーム ヘッダー JSON で“全体注意”を出す

特定セクションだけに限定することはできませんが、「このフォームには重要な入力欄がある」というメッセージをフォームヘッダーに常に表示しておくのは有効です。例えば次のような JSON です。

{
  "elmType": "div",
  "style": {
    "border-bottom": "1px solid #e1e1e1",
    "padding": "8px 12px",
    "background-color": "#fff4ce"
  },
  "children": [
    {
      "elmType": "span",
      "style": { "font-weight": "600" },
      "txtContent": "⚠️ 「重要セクション」を優先して入力してください。"
    }
  ]
}

これだけでも、「どこかに重要なセクションがある」という前情報を持った状態でフォームを読み進めてもらえるようになります。

必須列・検証式で「無視できない」状態を作る

見た目の強調と合わせて、「入力しないと先に進めない」仕組みを作るのも現実的です。

  • 重要セクション内の列を 必須列 にする。
  • 列の「検証設定」で、他列との組み合わせ条件をチェックする。
  • 検証エラーメッセージに「重要セクション」「赤丸マーク」などのキーワードを入れ、ユーザーに場所を知らせる。

例えば、あるチェックボックスがオンのときだけ、説明欄を必須にしたい場合:

  • 列 A:承認が必要(はい/いいえ)
  • 列 B:承認理由(複数行テキスト)

という構成にし、列 B の検証式を

=IF([承認が必要]="はい",LEN([承認理由])>0,TRUE)

のように設定しておくと、「承認が必要=はい」のときだけ「理由を必ず入力してください」とエラーを出せます。視覚的強調はなくても、入力漏れは確実に防げます。

擬似強調テクニックの比較

手法実現手段メリット注意点
絵文字・記号付きセクション名Body JSON(displayname)簡単・即効性あり色は変わらないので、デザインポリシーによっては好みが分かれる
セクション順序による強調Body JSON(sections の順番)視線誘導として非常に強いフォームの構造を変更するため、既存利用者に軽い戸惑いが出る可能性
ヘッダーの注意メッセージヘッダー JSONフォーム全体に注意喚起できるどのセクションのことかを文言ではっきり書く工夫が必要
必須列・検証式リスト設定(列の設定)入力漏れを実務的に防止できるエラー内容が分かりやすいよう、メッセージ文言をていねいに

「どうしても色を変えたい」場合の現実的な選択肢

ビジネス的に「見た目で一目瞭然にしてほしい」という要望が強い場合、JSON だけにこだわるといつまでも実現できません。その場合は、フォームそのものを別の仕組みで作り直す選択肢を検討するのが現実的です。

Power Apps でフォームをカスタマイズする

モダン SharePoint リストのフォームは、Power Apps を使って置き換えることができます。Power Apps でフォームを作り直せば、次のようなことが可能になります。

  • セクション(グループ)ごとに背景色を指定する。
  • 条件によって色やアイコンを切り替える(例:エラー時は赤、完了時は緑)。
  • ツールチップやヘルプテキストを動的に表示する。
  • タブ形式・ステップ形式など、フォームのレイアウト自体を変える。

一方で、次のようなデメリットもあります。

  • Power Apps アプリとしてのライフサイクル管理(権限・更新・テスト)が必要。
  • 標準フォームに比べて読み込み時間が長くなりやすい。
  • 「フォームだけ軽く直したい」レベルの要望に対してはオーバースペックになりがち。

したがって、「長く使われる重要な業務フォーム」「入力ミスのコストが高いフォーム」など、投資対効果が見込める箇所に絞って採用するのが賢い選び方です。

SPFx Form Customizer でフォームを差し替える

SharePoint Framework(SPFx)の Form Customizer を使うと、特定リストの New/Edit/Display フォームをフルカスタマイズできます。

  • CSS や React コンポーネントを駆使して、完全に独自の UI を構築できる。
  • 対象リストを限定できるため、サイト全体に影響を広げずに済む。
  • テナント標準のテーマやデザインポリシーと合わせることも可能。

ただし、こちらも以下のようなコストを伴います。

  • 開発スキル(TypeScript, React, SPFx)の習得が必要。
  • アプリカタログへの配置・更新が必要で、ガバナンスとの調整が発生する。
  • SharePoint Online のアップデートの影響を考慮した保守が必要。

「JSON では要件を満たせない」「Power Apps も運用上採用が難しい」といった場合の“最後の一手”として検討するイメージです。

JSON/Power Apps/SPFx の棲み分けイメージ

手段強み弱み向いているケース
JSON(フォーム書式)ノーコードで導入が早い。標準機能の範囲内。セクション色変更など見た目の自由度に制約。軽いカスタマイズ、入力欄の整理・グルーピング。
Power Apps見た目・ロジックともに自由度が高い。パフォーマンス・運用負荷が増加しがち。重要業務フォーム、入力ロジックが複雑なフォーム。
SPFx Form CustomizerWeb アプリ並みの UX を実現可能。開発・保守コストが高い。大規模・長期運用前提の業務システム。

ビジネス側と合意するための説明フレーズ例

現場では「他の画面みたいにここだけ赤くしてよ」と軽く言われがちですが、SharePoint のフォーム JSON には明確な限界があります。そんなときに使える説明の仕方をいくつか紹介します。

  • 「フォームの構造は JSON で変えられますが、セクションの色や枠線は仕様上変更できません。」
  • 「色を変えるには Power Apps や SPFx でフォーム自体を作り直す必要があり、その分の開発・運用コストがかかります。」
  • 「見た目は変えられませんが、絵文字・順序・必須入力・ヘッダーの注意書きなどで、ユーザーに十分気付いてもらえる工夫はできます。」

こうした言い回しを準備しておくと、「できない理由」と「代わりにできること」の両方をバランスよく伝えられます。

実務で使いやすいフォーム JSON サンプル

セクション構成を整理したシンプルな Body JSON

まずは、実務でよくある「基本情報」「詳細情報」「管理情報」の 3 セクション構成の例です。

{
  "sections": [
    {
      "displayname": "🔴 基本情報(必須)",
      "fields": [
        "Title",
        "Requestor",
        "Department"
      ]
    },
    {
      "displayname": "📌 詳細情報",
      "fields": [
        "Description",
        "Category",
        "DueDate"
      ]
    },
    {
      "displayname": "🔒 管理用情報(担当者のみ)",
      "fields": [
        "Assignee",
        "Status",
        "CompletedDate"
      ]
    }
  ]
}

ポイントは次の通りです。

  • 一番上のセクションに「🔴」「必須」と入れて、自然と目が向くようにしている。
  • 閲覧者全員が触る必要のない管理項目は一番下にまとめ、鍵マークで印象付け。
  • 色は変えていないが、“章立て”が明確になることでフォーム全体の理解度が上がる。

ヘッダー JSON で重要列の未入力を知らせる(応用編)

ヘッダー JSON では、列の値を条件にメッセージ表示を制御することもできます。

{
  "elmType": "div",
  "style": {
    "padding": "8px 12px",
    "margin-bottom": "8px",
    "background-color": "=if([$Title] == '', '#fde7e9', '#ffffff')",
    "border": "1px solid #e1e1e1"
  },
  "children": [
    {
      "elmType": "span",
      "style": {
        "font-weight": "600",
        "color": "=if([$Title] == '', '#a4262c', '#323130')"
      },
      "txtContent": "=if([$Title] == '', '⚠️ 「件名」が未入力です。基本情報セクションから入力してください。', '基本情報を確認のうえ登録してください。')"
    }
  ]
}

この例では、「Title(件名)」が空のときだけヘッダー背景を薄い赤にし、警告メッセージを表示しています。これにより、重要セクションの入力漏れを視覚的にもテキスト的にも知らせることができます。

あくまでヘッダー部分だけの色変更ではありますが、「どのセクションのどの列がまだなのか」を具体的に書くことで、ユーザーの迷いをかなり減らせます。

フッター JSON で“次のアクション”を明示する

フッター JSON には、「入力が終わったらこうしてください」という次のアクションを表示するのもおすすめです。

{
  "elmType": "div",
  "style": {
    "margin-top": "12px",
    "padding": "8px 12px",
    "background-color": "#f3f2f1",
    "font-size": "12px"
  },
  "children": [
    {
      "elmType": "span",
      "txtContent": "✅ すべての必須項目を入力したら、「保存」をクリックしてください。"
    }
  ]
}

これにより、「どこまで入力すればよいのか」「保存してよいのか」といったユーザーの不安を軽減できます。特にフォームの項目数が多い場合、フッターに一言ガイドがあるだけで運用の問い合わせ数が減ることもあります。

運用設計のポイント:JSON で“やりすぎない”

JSON を使えば使うほど、「もっと細かいところまでいじりたい」という欲が出てきますが、やりすぎはメンテナンス性を下げてしまいます。次のような観点で、カスタマイズのレベルを決めておくと安心です。

  • JSON のメンテナンス担当者を明確にする
    誰が JSON を管理するのか、引き継ぎ可能な形でドキュメント化しておく。
  • フォーム構造変更の影響範囲を意識する
    セクションを追加・削除した場合、マニュアルやトレーニング資料の更新も必要になる。
  • 「フォームはシンプルに、ロジックは Power Automate へ」という分担も検討
    フォーム側で複雑な条件分岐を持たず、ワークフロー側で処理する方がシンプルになる場合も多い。

特に、「このセクションだけ色を変えたい」といった要望は、往々にして「どこが重要なのかがユーザーに分かりづらい」という根本課題の表れです。色に頼れないからこそ、セクション名の付け方や項目の並べ方、説明文の書き方を丁寧に設計することが、長期的にはもっと大きな効果を生みます。

まとめ:ネイティブ JSON の限界を理解したうえで“現実解”を選ぶ

  • モダン SharePoint のフォーム JSON では、Body のセクションに対して色・枠線などのスタイルを直接指定する機能はありません。
  • 列書式 JSON はあくまでリスト ビュー 用であり、フォームの入力欄の見た目には影響しません。
  • ヘッダー/フッター JSON はフォーム全体には効きますが、「第 2 セクションだけ赤く」といった部分的な強調はできません。
  • 色まで変えたい場合は、Power Apps や SPFx Form Customizer など、フォーム自体を置き換える手段を検討する必要があります。
  • JSON の範囲であれば、セクション名の工夫(絵文字・文言)、セクション順序、ヘッダーの注意書き、必須列・検証式といった“擬似的な強調”で UX をかなり改善できます。
  • 技術要件(JSON の制約)とビジネス要件(ユーザーに気付いてほしい)を両方踏まえ、「どこまでなら標準機能で頑張るか」「どこから先は Power Apps / SPFx に投資するか」を合意しておくことが重要です。

「特定セクションだけ色付け」は残念ながら JSON だけでは叶いませんが、発想を少し変えれば、標準機能の範囲でもユーザーにとって十分使いやすいフォームを作ることはできます。まずはこの記事で紹介した擬似強調テクニックから試しつつ、必要であれば Power Apps や SPFx も検討してみてください。

この記事を書いた人

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

コメント

コメントする

目次