業務システムや複雑なSaaSのUI、特にダッシュボードをデザインする際、際限なく増え続ける「色」の扱いに頭を抱えたことはないでしょうか。
リリース初期はブランドカラーをベースにした数色で美しく整っていた画面も、機能追加でグラフのデータ系列が増えたり、表示したいラベルなどが増えた途端、一気に画面が見にくくなってしまいがちです。
最初はシンプルだったはずが、いつの間にか視覚的なノイズだらけの画面になってしまう現象は、デザイナーだけでなく、サービスの成長を追うPMやエンジニアなど、多くのプロダクト関係者が直面する「あるある」であり、非常に根深い課題です。
ここで最も避けるべきは、「色が足りないから」と安易に目立つ色やプライマリーカラーに合う色などを追加してしまうことです。例えば、赤や緑などは、UIにおいて「エラー（危険）」や「完了（安全）」を直感的に伝えるための重要なセマンティックカラー（意味を持つ色）です。これらを無秩序にグラフに混ぜ込むと、ユーザーは「数値の異常」なのか「単なるカテゴリの色」なのかを瞬時に判断できなくなります。その結果、大きな認知負荷を与え、混乱を招く原因となります。
本記事では、「業務システムにおける『データ配色』の設計」と題し、機能的な意味を持つ色と共存しながら、将来的な拡張にも耐えうる「破綻しないUIルール」の作り方を解説します。
目次
なぜ「きれいな色」だけではダメなのか
例えば、グラフやラベルの配色の際、単に「ブランドイメージに合う色」や「見た目がきれいなパレット」を選んで満足していませんか。
業務システムのUIデザインにおいて、そのアプローチは将来的に破綻を招くことが多いです。
なぜなら、画面内にはすでに絶対的な権限を持つ「セマンティックカラー（意味のある色）」が存在しているからです。
セマンティックカラーとは、完了を示す緑、注意を促す黄、そしてエラーを示す赤。これらは、ユーザーの状態判断を即座に誘導する「機能的な色（Status）」です。
ここで、売上グラフの棒として安易に「目立つから」と赤を使ってしまえば、ユーザーは無意識に「売上が悪い（危険な状態）」と誤読しかねません。これが「認知的な競合」です。
データ可視化に必要な色は、良し悪しを判断する「Status」ではなく、あくまで項目を区別するための「Identity（識別）」の色です。
つまり、私たちが目指すべきデータ配色の設計とは、既存のステータスカラーが占有している領域を避けつつ、残された「空いている色相」を慎重に探し出す作業になります。
それは、美的センス以上に、将来データが増えても既存のルールと干渉しない「安全地帯」を見つけ出す、極めて論理的な思考が必要なのです。
論理で色を管理する「3つの実装ルール」
では、実際にどのようにして「セマンティックカラーと共存し、かつ拡張可能なカラーパレット」を構築すればよいのでしょうか。
私が推奨するのは、以下の3つのロジックで色を機械的に決定するアプローチです。
ルール1：意味のある色を「聖域化」する
まず最初に行うのは、色の選定ではなく「除外」です。
ユーザーのアクションを促す「赤（Error/Delete）」「緑（Success/Complete）」「黄（Warning）」の3色は、システム上の聖域（Reserved Zone）として定義します。
データ可視化用のパレットを作成する際は、この聖域の色相を避けるか、もしくは「トーンを明確にずらす」ことが絶対条件となります。
例えば、どうしても赤系の色が必要な場合は、警告色として認識される鮮やかな「#FF0000」周辺を避け、彩度を落とした「小豆色」や、青みを含んだ「ラズベリー色」を採用します。（一例です。）
これにより、ユーザーは「これは危険信号ではなく、単なるカテゴリAである」と直感的に区別できます。
ルール2：隣り合う色に「明度のリズム」をつける
多くの方が陥る罠は、色相（色味）だけで差をつけようとすることです。
しかし、色数が増えると色相環の距離が縮まり、隣り合う色の境界が曖昧になります。
これを解決するのが、IBM Carbon Design Systemなどでも採用されている「明度の交互配置」です。
1色目を「暗い青」にしたら、2色目は「明るい紫」、3色目は「暗いティール」……というように、「暗・明・暗・明」のリズムで配置します。
このルールを適用すれば、たとえ色覚多様性を持つユーザーや、モノクロ印刷された資料であっても、グラフの境界線（コントラスト）が物理的に保たれます。
配色の美しさ以上に、この「識別可能性」こそが業務システムには不可欠です。
ルール3：色の名前を「抽象化」する
最後のルールは、運用と拡張性のためのものです。カラーパレットを開発者に渡す際、 Blue や Orange と名付けず、これらは Data-01, Data-02……といった「順序付きのトークン」として定義します。
なぜなら、ビジネスの要件変更で「ブランドカラーが変わったから、1色目の青を紫に変えたい」という事態は頻繁に起こるからです。色名を固定せず、役割（ID）として定義しておくことにより、デザインの変更がコード全体に波及するのを防ぎ、CSS変数の値を書き換えるだけでシステム全体の色を安全にアップデートできる「安定した構造」が完成します。
現場の「例外」と戦う：ブランドカラーの矛盾と限界の突破法
前セクションで定義したルールは強力ですが、実際のプロジェクトでは「理想通りにいかない」場面に遭遇します。
特に多くのデザイナーを悩ませるのが、「ブランドカラーとの衝突」と「色数の枯渇」です。これらに対する解決策も、事前にルール化しておく必要があります。
ケース1：ブランドカラーが「赤」の場合のジレンマ
「コーポレートカラーが赤なので、グラフのメイン色も赤にしたい」。この要望は、楽天やYouTube、Adobeのように、赤をアイデンティティとする企業のプロダクトで頻繁に発生します。
これらのサービスでは、ブランディングの観点から「購入する」「登録する」といったポジティブなプライマリアクションにあえて「赤」を採用しているケースが多く見られます。しかし、これをそのままデータ可視化（グラフ）の世界に持ち込むことは極めて危険です。
なぜなら、ユーザーのメンタルモデルには以下の2つの矛盾した定義が混在することになるからです。
- UIの赤（ブランド）：「進め」「実行」（例：楽天の購入ボタン）
- データの赤（世界共通）：「止まれ」「危険」「赤字」（例：売上の急落）
もし、売上が好調なグラフを「ブランドカラーだから」という理由で赤く塗ってしまったらどうなるでしょうか？ ユーザーは直感的に「数値が悪化した（Danger）」と誤読するか、あるいは画面内の「進め」と「止まれ」の矛盾に脳内でブレーキがかかり、認知的なストレスを感じてしまいます。
ここで採用すべきは、コンテキストによる「意味の分離」です。
- 原則： データ可視化パレットにおいて、ブランドカラー（赤）の使用を禁止する。代わりに寒色系の「Data-01（青やティールなど）」を使用し、誤解を未然に防ぐ。
- 特例： どうしても使用する場合は、その用途を「自社の強調（Subject）」にのみに限定する。「競合他社（グレー）対 自社（赤）」のような比較グラフであれば、赤は「危険」ではなく「主役」として機能します。しかし、単なる円グラフの1要素として赤を使うことは決して許容しないこと。
ケース2：「色が足りない」問題への対処
「カテゴリが20個あるから20色欲しい」。この要望に対し、単に色をループさせたり、微細な違いの色を追加したりするのは極端な手段です。冒頭で触れた通り、それはユーザーの認知の限界を超えているからです。
システム側で実装すべき「限界突破」の解決策は以下の2つです。
- 「その他（Others）」への強制集約
事前に「グラフの描画は上位N件（例：9件）までとし、残りは自動的にグレーの『その他』にまとめる」という仕様で合意しておく。これにより、どんなにデータが増えても、配色の崩壊をシステム側で阻止できます。 - テクスチャ（模様）の併用
法規制や業務要件で、どうしても上記のような「その他」にまとめられず、厳密な区別が必要な場合は、「色」ではなく「柄（パターン）」を併用します。 Data-1（青）を使い切ったら、次は Data-1-Stripe（青の斜線）を表示する。これにより、色相を増やすことなく、識別可能なIDを拡張することが可能です。WCAG(Web Content Accessibility Guidelines)の実装方法である[G111]においても、「色に依存することなく情報を伝達するためにパターンを併用する」ことは、アクセシビリティを担保する有効な方法として定義されています。ただし、近年のUI実装においてはRetinaディスプレイのような高精細な画面で密度の高いストライプや細かすぎるドットなどを描画すると、「モアレ（干渉縞）」と呼ばれる視覚的なノイズやチラつきが発生し、逆に可読性を損なうリスクがあります。
そのため、パターンを採用する際は、あくまで区別できない状況下での補助的な手法として止め、斜線やドットなどは「間隔を広めに取り、控えめにデザインする」ことを鉄則とし、[G111]の要件を満たしつつ、情報の等価性を保ちながら設計することが必要です。
ケース3：ダークモードへの対応
最後に、近年の業務システムで必須となるダークモード対応です。 ライトモードで作った「Data-01（暗い青）」をそのまま黒背景に置くと、視認性が著しく低下します。
ここで第3章の「トークン化」が効いてきます。 Data-01 というトークンに対し、ライトモード用のHEX値と、ダークモード用のHEX値（明度を上げ、彩度を少し落とした色）をペアで登録しておきます。 「背景が変われば、色も自動で適切なコントラストのものに切り替わる」。これこそが、感覚ではなくシステムで色を管理する最大のメリットです。
デジタルと物理世界の「色の衝突」をどう解くか
WebやSaaSの一般的なセマンティックルールが通用しない、特殊かつ重要な領域があります。それは、物理的なハードウェアや現場業務と密接に連携する「デジタルツイン（IoT/O2O）」の領域です。
ここでは、モニターの中の正解（UIデザイン）と、現場の正解（物理的なメンタルモデル）が真っ向から対立することがあります。この時、私たちはどちらを優先すべきでしょうか。
ケース1：現場の「慣習」vs UIの「セマンティック」
ある産業機器の管理システムの事例です。現場の計器では、ある重要な数値が伝統的に「赤色のグラフ」で表示されていました。 しかし、Webアプリ化する際、デザイナーは「赤はエラー色だから」というUIの正論に基づき、これを青色のグラフに変更しました。
結果はどうなったか。現場の作業員は「いつもの赤い波形がない」と混乱し、直感的な数値把握ができなくなってしまいました。
このケースにおける教訓は、「現場（ドメイン）のメンタルモデルは、UIルールよりも優先される場合がある」ということです。
長年染み付いた「あの数値＝赤」という認知は、理屈では覆せません。この場合、UIデザイナーが採るべき解決策は、その赤を「エラー（Danger）」としてではなく、「固有の属性色（Brand/Symbol）」として扱い、エラー表示の方を「枠線」や「アイコン」など、色以外の手段で強調する「棲み分け」のデザインです。
ケース2：物理錠の「赤」は、システムエラーの「赤」か？
あるセキュリティ管理システムの事例です。連携している物理的なスマートロック（電子錠）の仕様は、本体のLEDランプで以下のように状態を示しているとします。
- 青点灯： 施錠中（Locked）＝ 安全
- 赤点灯： 解錠中（Unlocked）＝ 警戒・注意
これをUIに落とし込む際、単純に「現物の色」をそのまま採用して、解錠状態を「赤いアイコン」で表示するとどうなるでしょうか。 Webシステムにおいて、赤は本来「通信エラー」や「故障」を示す色です。
画面上に赤いアイコンが並んでいるのを見た管理者は、「鍵が開いているだけ（正常動作）」なのか、「機器が故障している（異常事態）」なのか、瞬時に判別できなくなります。
逆に、Webのセオリー通り「解錠＝ニュートラル（グレー）」にしてしまうと、今度は「鍵が開いている」という物理的な警戒レベル（Danger）が伝わりにくくなり、現場の感覚と乖離します。
ここで採用すべきは、「状態（State）と評価（Health）の分離」というアプローチです。
- 状態（施錠/解錠）： 色に依存させない。（形状で語る。）
- 「鍵が閉まっているアイコン」「開いているアイコン」という「形状（Shape）」で状態を伝える。色はニュートラルなグレーや、物理ランプに寄せた色を使うとしてもあくまで補助とする。
- 評価（正常/異常）： セマンティックカラーを使う。（赤はセマンティックカラーのために残す）
- システムエラーや通信断絶といったシステム的な「異常」に対してのみ、セマンティックカラーの赤を使用する。
物理世界では「赤＝開いている」が正解でも、デジタル世界では「赤＝エラー」という強力なメンタルモデルが存在します。このコンテキストの違いを理解し、色以外のメタファー（形状や文字）へ翻訳し直すことこそが、物理とデジタルを繋ぐUIデザインの要諦です。物理世界のルールを尊重しつつ、デジタル上で誤解を生まない翻訳を行うことこそが、産業用アプリケーションにおけるUIデザインです。
ケース3：録画中の「赤」は、エラーなのか？
Web会議システムや監視カメラのダッシュボードにおける事例です。
皆さんが普段使っているPCのWebカメラを想像してみてください。カメラが起動している時、レンズの横にある物理的なランプは「緑色」や「白色」に光っているはずです。これは「カメラが正常に動いていますよ（Active）」という安心感をユーザーに与えるためのハードウェア設計です。
しかし、ZoomやMicrosoft Teamsで会議を「録画（Recording）」し始めた瞬間、画面上のステータスアイコンは何色になるでしょうか？ ハードウェアが緑色で光っているにも関わらず、画面上には必ず「赤い丸（● REC）」（録画ボタン）が表示されます。
ここで、UIデザイナーは強烈な矛盾に直面します。 Webのガイドライン通りなら、「正常に録画が進んでいる」のだから、ステータスは「緑（Success）」であるべきです。 しかし、世界的スタンダードであるZoomやTeamsでさえ、この「緑」のルールを破り、あえて「赤」を採用し続けています。
なぜなら、ここでは「正常稼働（System Health）」を伝えることよりも、「現在、あなたの映像が記録されています」という緊張感（Alert）を伝えることの方が、UXとして優先度が高いからです。
- カメラ起動（Active）： 緑（安心・正常）
- 録画実行（Recording）： 赤（警戒・記録中）
同じ「カメラが動いている」という状態でも、ユーザーに「安心（見てるだけ）」を伝えたいのか、「警戒（記録してるぞ）」を伝えたいのかによって、選ぶべき色は180度変わります。
もしあなたが「防犯カメラの管理画面」を作るなら、正常稼働中であっても「赤」を使うのが正解かもしれません。「今、証拠を記録している」という事実が最も重要だからです。 逆に「オンライン診療アプリ」なら、患者を怖がらせないために、録画中でもあえて「青」や「緑」の優しいUIを選ぶべきかもしれません。
「赤＝エラー」というWebのルールは絶対ではありません。 「ユーザーにどのような感情（安心感 or 緊張感）を持ってほしいか」という目的こそが、最終的な色を決定するのです。
もっと身近な例を挙げれば、皆さんの手元にあるiPhoneのカメラも同じです。「写真モード」の時、シャッターボタンは「白」ですが、「ビデオモード」に切り替えた瞬間、ボタンは「赤」に変わります。
通常、iOSのUIデザインにおいて、赤は「削除」や「キャンセル」を意味する破壊的な色です。 しかしAppleは、ビデオ撮影というコンテキストにおいてのみ、その鉄則をあえて破っています。なぜなら、ユーザーの頭の中には「ビデオの録画ボタン＝赤」という物理的な記憶が深く刻まれているからです。
もしAppleがUIの整合性を優先して、ビデオの録画ボタンを「緑（Start）」にしていたらどうでしょう？ ユーザーは一瞬「これは録画なのか？」と迷いが生じるはずです。「理屈（UIルール）」よりも「直感（メンタルモデル）」を優先する。 この柔軟性こそが、使いやすいUIを作るための最後の鍵なのです。
結論：色は「感性」ではなく、管理可能な「機能」として実装せよ
ここまで、業務システムにおけるデータ配色の複雑さと、それを解決するための論理的なアプローチについて解説してきました。
私たちが目指すべきゴールは、単に「きれいなグラフ」を作ることではありません。ユーザーが膨大なデータの中から重要なインサイトを瞬時に発見し、迷いなく意思決定できる「ノイズのないUI」を構築することです。
本稿で紹介した「セマンティックカラーの聖域化」「明度のリズム」「トークンによる管理」といったルールは、一見するとデザイナーの自由を奪う制約のように思えるかもしれません。しかし、実際はその逆です。 色選びという「正解のない悩み」をシステム化（自動化）することで、デザイナーはより本質的な「情報の構造化」や「ユーザー体験の向上」に時間を割くことができるようになります。
また、このルールはエンジニアやPMとの「共通言語」にもなります。 「なぜここは青なのか？」「なぜ赤を使ってはいけないのか？」という議論が個人の好みではなく、明確なロジックに基づいて行われるようになるため、コミュニケーションコストは劇的に下がります。
データ可視化において、色は装飾ではありません。それは、数値という無機質な情報を、人間が理解可能な形に翻訳するための「機能（Function）」そのものです。
「色が足りない」と嘆く前に、まずは色を引いてみてください。そして、感情ではなく論理でパレットを再構築してみてください。その先にこそ、ユーザーにとっても、運用チームにとっても、持続可能で健やかなUIデザインが待っているはずです。
UIの課題解決はNCDCへ
NCDCは、これまで多種多様な業務システムやモバイルアプリの開発において、UX/UIデザインの側面からプロジェクトを支援してきました。今回取り上げたテーマ「業務システムのデータ配色」は、プロダクトの品質を左右する極めて重要な要素です。
私たちは、単に見た目を整えるだけでなく、ビジネスの目的とユーザーの利便性を両立させるための深い分析と、それに基づいた最適なソリューションをご提案します。
現状のUIに課題を感じている方はもちろん、開発プロセスの改善やデザインガイドラインの策定、内製化支援など、UX/UIに関するお悩みについて、どのような段階からでも対応可能です。
UX/UIデザインに関する課題解決の第一歩として、まずはNCDCへお気軽にお問い合わせください。
