Phase 3
UI Design System

Introduction

この章の役割

UI Design Systemは、見た目を整えるためだけのルールではありません。 Knowledge OSを使う人が、画面ごとに新しい操作方法を覚えなくても よい状態をつくるための共通言語です。

同じ役割のボタンは、どの画面でも同じ形、同じ位置、同じ言葉で 表現します。同じ種類の情報は、同じカード、同じ文字サイズ、 同じ余白で表示します。

対象者

この章で定義するもの

01 — Foundation

1 UIの基本方針

Knowledge OSのUIは、業務資料を扱う一般企業向けの製品です。 日常的にITを使う人だけでなく、パソコン操作が得意ではない人、 高齢者、初めて製品に触れる人も対象とします。

UI設計の7原則

02 — Layout

2 レイアウト

Knowledge OSの画面は、原則として 「ナビゲーション」「ページヘッダー」「メインコンテンツ」 の3領域で構成します。

基本構造

ページヘッダー

ページ上部には、原則として次の順番で情報を配置します。

1. ページタイトル
2. 画面の目的を説明する補助文
3. その画面で最も重要な操作ボタン

コンテンツ幅

03 — Grid

3 グリッド

画面内の要素を感覚で配置せず、12カラムグリッドを基準にします。 ただし、利用者にグリッドの存在を感じさせる必要はありません。

デスクトップ

代表的な分割

カード一覧

こう使う

• 資料一覧は、画面幅に応じて1〜3列で表示する。
• 資料詳細では、本文を8カラム、補助情報を4カラムにする。
• 設定フォームは12カラム全体を使わず、中央840px以内にする。
• 主要な情報が左右に分散しないようにする。

04 — Spacing

4 スペーシング

Knowledge OSでは、余白を装飾ではなく情報整理の手段として 使用します。関係の近い情報は近づけ、異なる情報は離します。

基本単位

余白は原則として4px単位で設計します。 日常的には8px、12px、16px、24px、32px、48pxを使用します。

フォームの余白

• ラベルと入力欄の間：8px
• 入力欄と補足文の間：8px
• フォーム項目同士：24px
• フォームグループ同士：40〜48px
• フォーム下部と保存ボタン：32px以上

こう使う

05 — Card

5 カード

カードは、関連する情報や操作をひとまとまりとして見せるために 使用します。画面を区切るためだけにカードを乱用してはいけません。

基本仕様

カードの種類

クリック可能なカード

カード全体をクリックできる場合は、次の条件を満たします。

• マウスポインターを変更する。
• ホバー時に境界線または背景を変化させる。
• キーボードでフォーカスできる。
• 右端に矢印を表示する。
• カード内に別の主要ボタンを置かない。

カード内の構造

1. アイコンまたは種類
2. タイトル
3. 補足情報
4. 状態または更新日時
5. 必要な場合のみ操作

こう使う

• 1枚のカードには、1つの主題だけを入れる。
• 複数の操作が必要な場合は、詳細画面へ移動させる。
• すべてをカードにせず、単純な一覧にはテーブルを使用する。
• カードの高さを揃えるために文章を不自然に省略しない。

06 — Typography

6 Typography

文字はKnowledge OSで最も重要なUI要素です。 装飾的なフォントではなく、読みやすさと日本語表示の安定性を 優先します。

フォントファミリー

font-family:
  -apple-system,
  BlinkMacSystemFont,
  "Segoe UI",
  "Noto Sans JP",
  "Hiragino Kaku Gothic ProN",
  "Yu Gothic",
  Meiryo,
  sans-serif;

OS標準フォントを優先し、追加フォントのインストールを 前提にしません。

文字サイズ

見出し

• 見出しは文章ではなく、短い名詞または動詞句にする。
• 見出し末尾に句点を付けない。
• 見出しを色だけで区別しない。
• 太字を多用せず、情報階層に沿って使用する。

本文

• 1文を長くしすぎない。
• 専門用語を避け、一般的な日本語に置き換える。
• 1段落は3〜5行程度を目安にする。
• 説明は「何が起きるか」を先に書く。

補助文字

補助文字は、入力例、更新日時、任意項目、操作の補足などに 使用します。重要な情報を補助文字だけで伝えてはいけません。

数字と日時

• 件数は「12件」のように単位を付ける。
• 日付は原則「2026年7月12日」と表示する。
• 時刻が必要な場合は「2026年7月12日 14:30」とする。
• 更新直後のみ「たった今」「3分前」を使用してよい。
• ファイル容量は「2.4 MB」のように読みやすく表示する。

07 — Colors

7 Colors

Knowledge OSの色は、製品の装飾ではなく、 操作の優先度と状態を伝えるために使用します。

基本カラー

Primary

Primaryは、主要操作、選択状態、リンク、フォーカス状態に 使用します。

Neutral

Success

保存完了、接続成功、正常状態など、処理が完了したことを 伝えるために使用します。

Warning

処理は続行できるものの、確認や注意が必要な状態に使用します。

Error

処理を完了できなかった場合や、入力の修正が必要な場合に 使用します。

色の使用ルール

• 1画面でPrimaryカラーを使用する主要ボタンは、原則1つ。
• Success、Warning、Errorを装飾目的で使用しない。
• 管理者・特別権限の表示には、adminカラー（紫 #6D28D9）を使用する。
• 状態は、色＋アイコン＋文章で示す。
• 薄い文字色を広い範囲で使用しない。
• 背景色の上に置く文字は、十分なコントラストを確保する。

08 — Components / Button

8 ボタン

ボタンは「何が起きるか」を明確に示す操作要素です。 ボタンの見た目は、操作の重要度と危険度に合わせます。

ボタンの種類

サイズ

ラベル

ボタンのラベルは、原則として 「対象＋動詞」または 「動詞」にします。

「次へ」は、次に何が起きるか明らかな連続フォームのみ 使用できます。可能な限り「内容を確認」「登録を完了」のように 具体的にします。

アイコン付きボタン

• アイコンは意味を補助するために使用する。
• 一般利用者向け画面では、アイコンだけのボタンを避ける。
• 追加は「＋」、検索は虫眼鏡など、一般的な記号を使う。
• 独自アイコンを操作ボタンに使用しない。

無効状態

ボタンを無効にする場合は、利用者が理由を理解できるようにします。

• 必要な入力項目の近くに理由を表示する。
• 無効ボタンだけを表示し、理由を隠さない。
• 条件が複雑な場合は、押下後に説明する方式を検討する。

処理中

• ボタン内にスピナーを表示する。
• ラベルを「保存中…」のように変更する。
• 同じ操作を連続実行できないようにする。
• 画面全体を不必要に操作不能にしない。

こう使う

09 — Components / Tag

9 タグ

タグは、資料の分類、状態、属性を短く示すために使用します。 長い説明や主要操作には使用しません。

用途

• 文書種別
• 案件名
• 顧客名
• 処理状態
• 年度
• 利用目的

仕様

タグとステータスの違い

タグは分類を示します。ステータスは現在の状態を示します。

こう使う

• 一覧では、重要なタグを最大3つまで表示する。
• 4つ以上ある場合は「ほか2件」とまとめる。
• タグだけで文書の内容を説明しない。
• タグの色を利用者が自由に増やしすぎない。
• 削除可能なタグには、明確な削除アイコンを付ける。

10 — Components / Dialog

10 ダイアログ

ダイアログは、利用者の現在の作業を一時的に中断し、 確認や短い入力を求める場合に使用します。

使用してよい場面

• 削除など、元に戻せない操作の確認
• 短い名前の変更
• 保存せずに移動する場合の確認
• 重要なエラーと解決方法の提示
• 1〜3項目程度の簡単な選択

使用しない場面

• 長い入力フォーム
• 複数ステップの設定
• 長文の説明
• 資料の閲覧
• 通常の成功通知

構造

1. タイトル
2. 何が起きるかを説明する本文
3. 必要な場合のみ入力欄
4. Secondaryボタン
5. PrimaryまたはDangerボタン

ボタン配置

デスクトップでは、左にキャンセル、右に実行ボタンを置きます。 モバイルでは縦並びも許可します。

削除確認

削除確認では「本当によろしいですか？」だけを表示してはいけません。 削除対象と結果を具体的に説明します。

閉じ方

• 右上に閉じるボタンを置く。
• Escキーで閉じられるようにする。
• 背景クリックで閉じるかは、入力内容の有無で判断する。
• 未保存入力がある場合は、背景クリックで閉じない。

11 — Components / Empty State

11 Empty State

Empty Stateは、単に「データがありません」と伝える場所では ありません。利用者が次に何をすればよいかを案内する画面です。

Empty Stateの構造

1. やさしいアイコンまたは簡単なイラスト
2. 現在の状態を示す見出し
3. 次にできることを説明する文章
4. 主要操作ボタン
5. 必要な場合のみ補助リンク

Empty Stateの種類

文言例

12 — Components / Loading

12 Loading

Loadingは、システムが止まっているのではなく、 処理を続けていることを利用者に伝えるためのUIです。

処理時間別の表示

文言

AI処理のLoading

AI処理では、「AIが考えています」ではなく、 利用者の資料に対して何をしているかを説明します。

• 資料の内容を確認しています
• 関連する資料を探しています
• 要点を整理しています
• 回答を作成しています

Skeleton

一覧や詳細画面の初期表示では、レイアウトの形を維持する Skeletonを使用できます。

• 実際の画面構造に近い形にする。
• 激しいアニメーションを使用しない。
• 5秒以上続く場合は説明文を追加する。
• 読み込み失敗時は、必ずエラー表示に切り替える。

進捗表示

複数ファイルの登録など、処理件数が分かる場合は、 「3 / 10件」のように具体的な進捗を示します。

こう使う

• 画面全体を覆うLoadingは、初回起動などに限定する。
• 部分更新では、対象部分だけにLoadingを表示する。
• 処理中でも、利用可能な他の操作は残す。
• 終了時には成功または失敗を明確に伝える。

13 — Components / Search

13 Search

検索はKnowledge OSの中心機能です。 利用者が正確なファイル名や専門用語を知らなくても、 必要な資料にたどり着けることを目指します。

検索欄の基本仕様

プレースホルダー

プレースホルダーには、検索できる内容の例を示します。

検索結果

検索結果には、なぜその資料が見つかったかを分かる範囲で 示します。

• 資料名
• 文書種別
• 一致した文章の抜粋
• 更新日
• 保存場所
• 必要な場合のみ関連度

検索語のハイライト

一致した文字列は、背景色と太字で強調します。 文字色だけを変更する方法は避けます。

フィルター

フィルターは、最初からすべて表示せず、 よく使う条件だけを見せます。

検索結果がない場合

併せて、次の操作を表示できます。

• 検索条件をすべて消す
• 似た言葉で検索する
• 新しい資料を追加する

AI検索

AI検索を提供する場合でも、通常検索と別製品のように 分離しません。

• 通常の検索欄から自然な文章を入力できる。
• 「AI検索」という専門用語を前面に出さない。
• 回答と根拠資料を必ずセットで表示する。
• 参照した資料を開けるようにする。
• 確信度を曖昧な数値だけで表示しない。

14 — Components / Form

14 入力フォーム

フォームは、利用者にシステムの都合を押し付けないように 設計します。必要な情報だけを、自然な順番で入力できるようにします。

入力欄

ラベル

• 入力欄の上に常時表示する。
• プレースホルダーをラベルの代わりにしない。
• 必須項目には「必須」と日本語で表示する。
• 任意項目が少ない場合は「任意」と表示する。

エラー表示

エラーは、フォーム上部にまとめるだけでなく、 問題のある入力欄の直下にも表示します。

エラー文の書き方

• 何が問題かを書く。
• どう直せばよいかを書く。
• エラーコードだけを表示しない。
• 利用者を責める表現を使わない。

保存

• 自動保存の場合は、保存状態を表示する。
• 手動保存の場合は、画面下部にボタンを配置する。
• 保存前に不要な確認ダイアログを出さない。
• 未保存のまま移動する場合は警告する。

15 — Navigation

15 ナビゲーション

ナビゲーションは、利用者が現在地と移動先を理解するための 基本構造です。

サイドナビゲーション

デスクトップ版では、左側のサイドナビゲーションを基本とします。

• 主要項目は5〜7個まで。
• アイコンと日本語ラベルを併記する。
• 選択中の項目を背景色と左線で示す。
• 設定など使用頻度の低い項目は下部に置く。
• 階層は原則2段階まで。

推奨構成

1. ホーム
2. 資料
3. 検索
4. 作成・活用
5. 取り込み
6. 設定
7. ヘルプ

名称ルール

パンくず

3階層以上の画面や、一覧から詳細へ移動する場合に使用します。

例： 資料 › 顧客A › 相続手続きの進め方.pdf

戻る操作

• ブラウザやアプリの戻る操作を壊さない。
• 「戻る」と「キャンセル」を混同しない。
• 戻った際に検索条件やスクロール位置を維持する。

16 — Responsive

16 レスポンシブ設計

Knowledge OSはデスクトップ利用を中心としますが、 小型ノートPCやタブレットでも主要操作を継続できるようにします。

ブレークポイント

縮小時の優先順位

1. 主要な情報を残す。
2. 補助情報を折りたたむ。
3. 複数列を1列にする。
4. ボタンを縦並びにする。
5. ナビゲーションをドロワーにする。

テーブル

小さい画面では、横スクロール、重要列のみ表示、 カード形式への切り替えを使い分けます。

• 列を勝手に省略せず、表示切り替えを検討する。
• 横スクロールできることを視覚的に示す。
• 操作列を固定する場合は、本文を隠さない。

17 — Accessibility

17 アクセシビリティ

Knowledge OSは、高齢者、視力の低い人、マウス操作が難しい人も 利用する可能性があります。アクセシビリティは追加対応ではなく、 基本品質として扱います。

最低要件

• 本文文字は原則16px以上。
• クリック領域は44px四方以上。
• キーボードだけで主要操作ができる。
• フォーカス位置が目で分かる。
• 色だけで状態を伝えない。
• 画像やアイコンに代替情報を付ける。
• 入力欄とラベルを正しく関連付ける。

コントラスト

通常文字は、背景とのコントラスト比4.5:1以上を目安とします。 大きな文字でも、薄すぎる色は使用しません。

フォーカス

• フォーカスリングを消さない。
• Primaryカラーの2〜3pxリングを使用する。
• 背景色と区別できるようにする。
• ダイアログを開いたら、ダイアログ内にフォーカスを移す。

アイコン

• アイコンだけで意味を伝えない。
• 装飾アイコンは読み上げ対象から除外する。
• 操作アイコンにはラベルまたはツールチップを付ける。

アニメーション

• 点滅や激しい動きを使用しない。
• 画面遷移は150〜250ms程度にする。
• 動きがなくても意味が理解できるようにする。
• Loading以外の無限アニメーションを避ける。

18 — Icons & Illustration

18 アイコンとイラスト

アイコンは、文章を置き換えるものではなく、 意味を素早く理解するための補助として使用します。

アイコンの基本

• 線の太さと角の形を統一する。
• 標準サイズは20pxまたは24px。
• ボタン内では18〜20pxを使用する。
• 装飾目的で大量に配置しない。
• 一般的でない記号には必ずラベルを付ける。

推奨アイコン

イラスト

イラストは、初回案内、Empty State、セットアップ完了など、 利用者の不安をやわらげる場面に限定して使用します。

• 写実的すぎない、やさしい線画を基本とする。
• 人物属性を固定しすぎない。
• 業務画面の情報より目立たせない。
• 1画面につき1点を基本とする。
• 意味のないキャラクター装飾を常設しない。

19 — Feedback

19 操作結果の伝え方

利用者が操作した後は、「処理されたのか」「次に何をすべきか」が 分かるフィードバックを返します。

Toast

軽い成功通知には、画面端に一時表示するToastを使用できます。

• 表示時間は4〜6秒。
• 重要な内容は自動で消さない。
• 画面下部の操作を隠さない。
• 同時に3件以上積み上げない。

Inline Message

入力エラーや特定領域の問題は、その場所に近い Inline Messageを使用します。

Banner

システム全体の状態、接続切れ、更新案内などは、 画面上部のBannerで示します。

成功通知

保存や登録が完了したら、完了した対象を具体的に示します。

エラー通知

エラーでは、原因、影響、次の操作の3点をできる範囲で示します。

20 — AI Implementation Rules

20 AI・開発者向け実装ルール

新しい画面や機能を実装するときは、このDesign Systemを 個別画面の都合より優先します。

AIに実装を依頼するときの共通指示

Knowledge OS Design Principles v1.0.0に従って実装してください。

必須条件：
- 一画面一目的を守る
- 一般利用者向けのやさしい日本語を使用する
- 専門用語や英語を画面上に出さない
- 本文は16px以上
- 主要ボタンは44px以上
- Primaryボタンは1画面につき原則1つ
- 余白は4px単位で設計する
- カード角丸は12pxを基本とする
- 色だけで状態を表現しない
- Loadingには処理内容を表示する
- エラーには解決方法を表示する
- Empty Stateには次の操作を表示する
- AIの回答には根拠資料を表示する
- 既存コンポーネントを優先して再利用する
- 新しい独自UIパターンを勝手に追加しない

新規コンポーネントを作る条件

次のすべてを満たす場合のみ、新規コンポーネントを作成します。

1. 既存コンポーネントでは目的を達成できない。
2. 複数画面で再利用する見込みがある。
3. 利用者が既存の操作方法から予測できる。
4. アクセシビリティ要件を満たす。
5. 使用方法をDesign Systemへ追記できる。

禁止する実装

• 画面ごとに異なるボタンサイズを作る。
• 独自の色をその場で追加する。
• 文字を小さくして情報を詰め込む。
• 意味のないグラデーションを使う。
• 過度な影やガラス風表現を使う。
• アイコンだけの操作を大量に並べる。
• 専門用語を説明なしで表示する。
• AI処理を自動で確定・保存する。
• 確認なしで削除や上書きを実行する。

デザイントークン例

:root {
  /* Colors */
  --color-primary-50: #eff6ff;
  --color-primary-600: #2563eb;
  --color-primary-700: #1d4ed8;

  --color-success-50: #f0fdf4;
  --color-success-700: #15803d;

  --color-warning-50: #fffbeb;
  --color-warning-700: #b45309;

  --color-error-50: #fef2f2;
  --color-error-700: #b91c1c;

  --color-admin-50: #f5f3ff;
  --color-admin-700: #6d28d9;

  --color-neutral-0: #ffffff;
  --color-neutral-50: #f8fafc;
  --color-neutral-100: #f1f5f9;
  --color-neutral-200: #e2e8f0;
  --color-neutral-500: #64748b;
  --color-neutral-700: #334155;
  --color-neutral-900: #0f172a;

  /* Spacing */
  --space-1: 4px;
  --space-2: 8px;
  --space-3: 12px;
  --space-4: 16px;
  --space-6: 24px;
  --space-8: 32px;
  --space-12: 48px;
  --space-16: 64px;

  /* Radius */
  --radius-sm: 8px;
  --radius-md: 10px;
  --radius-lg: 12px;
  --radius-xl: 16px;
  --radius-full: 999px;

  /* Typography */
  --font-size-xs: 13px;
  --font-size-sm: 14px;
  --font-size-md: 16px;
  --font-size-lg: 18px;
  --font-size-xl: 24px;
  --font-size-page-title: 30px;

  /* Control */
  --control-height-sm: 36px;
  --control-height-md: 44px;
  --control-height-lg: 48px;
}

コンポーネント命名

コード上の名称は、役割が分かる英語名を使用します。 画面上の表示は日本語にします。

UIテキストの管理

• 同じ意味の文言を複数作らない。
• 共通文言は定数または辞書にまとめる。
• 「追加」「登録」「保存」を役割に応じて使い分ける。
• エラーメッセージを技術コード内に直接散在させない。

21 — Usage Examples

21 画面別の使い方

ホーム画面

• 今日確認すべき情報を最上部に表示する。
• 主要操作は「資料を追加」など1つに絞る。
• 機能一覧をすべてカード化しない。
• 未設定項目は、警告ではなく案内として表示する。

資料一覧

• 検索欄を上部に配置する。
• 一覧とカードを目的に応じて使い分ける。
• 文書名、種類、更新日を基本情報とする。
• 操作ボタンを常時大量に表示しない。

資料詳細

• 資料本文またはプレビューを主役にする。
• タグやメタデータは補助領域に置く。
• AI要約は資料本文より上に大きく表示しない。
• 参照元ページや該当箇所へ移動できるようにする。

AI回答画面

• 利用者の質問を明示する。
• 回答を読みやすい文章で表示する。
• 根拠資料を回答の直下に表示する。
• 回答を確定情報として断定しすぎない。
• 「資料を開く」「回答をコピー」を提供する。

設定画面

• 設定をカテゴリ単位に分ける。
• 技術設定と一般設定を分離する。
• 保存結果を明確に表示する。
• 危険な設定は通常設定から距離を置く。
• 初期値に戻す操作は確認する。

初回セットアップ

• 1画面に1つの判断だけを求める。
• 現在のステップを表示する。
• 専門用語を使わず、必要性を説明する。
• 後から変更できる項目は、その旨を示す。
• 完了時に次の操作を1つ案内する。

22 — Review Checklist

22 実装チェックリスト

新しい画面やコンポーネントを完成と判断する前に、 以下を確認します。

画面構成

• 画面の目的が1つに絞られている。
• ページタイトルだけで内容が分かる。
• 主要操作が1つに絞られている。
• 重要な情報が最初に見える。
• 不要なカードや区切りがない。

レイアウトと余白

• 12カラムの考え方に沿っている。
• 余白が4px単位になっている。
• 関連情報が近く配置されている。
• 異なる情報の間に十分な余白がある。
• 画面幅が広くても本文が広がりすぎない。

文字

• 本文が16px以上になっている。
• 13px未満の文字を使用していない。
• 見出しの階層が一貫している。
• 専門用語を一般的な日本語に置き換えている。
• 文章が長すぎない。

色

• Primaryボタンが1画面に多すぎない。
• 色だけで状態を伝えていない。
• Success、Warning、Errorを正しい用途で使用している。
• 背景と文字のコントラストが十分にある。
• 独自カラーを追加していない。

ボタンと操作

• 主要ボタンの高さが44px以上ある。
• ボタンのラベルから結果を予測できる。
• アイコンだけのボタンに説明がある。
• 危険な操作に確認がある。
• 処理中の二重実行を防止している。

状態表示

• データがない場合に次の操作を案内している。
• Loadingに処理内容を表示している。
• 成功時に何が完了したか分かる。
• エラー時に解決方法を表示している。
• 処理が止まったままに見えない。

アクセシビリティ

• キーボードで操作できる。
• フォーカス位置が見える。
• 入力欄にラベルが関連付いている。
• クリック領域が44px以上ある。
• スクリーンリーダー向けの情報が設定されている。

AI機能

• AIを使っていることを必要以上に強調していない。
• 利用者の確認前に確定処理をしていない。
• 回答の根拠となる資料を表示している。
• AIができない場合の代替操作がある。
• 誤りがあり得ることを適切に伝えている。

Closing

UIは、利用者と製品の約束です

利用者は、ボタンの色、文字の大きさ、余白、配置から、 次に何が起きるかを無意識に予測しています。

画面ごとにルールが変わると、利用者は毎回考えなければなりません。 一貫したUIは、操作を覚えやすくするだけでなく、 製品への安心感と信頼をつくります。

最終判断基準

1. 初めて見た人が、目的を理解できるか。
2. 次に押す場所が分かるか。
3. 操作した結果が分かるか。
4. 失敗しても、戻り方が分かるか。
5. 高齢者でも文字と操作が見やすいか。
6. 資料よりAIや装飾が目立っていないか。
7. 他の画面と同じルールで動いているか。

Knowledge OS Design Principles v1.0.0
Phase 3 — UI Design System
Product Design System for Developers, Designers and AI