Liberkaデザインガイドライン

状態: Liberka株式会社および同社が提供する製品・サービス・成果物のデザインに適用する正本。スタイルガイドを内包する。

1. この文書の役割

この文書は、Liberkaのデザイン思想、視覚言語、情報設計、インタラクション、アクセシビリティおよび品質基準を定める。媒体ごとの流行や個別製品の一時的な実装ではなく、誰が、何を、どの媒体で作る場合にも共有する判断基準である。

対象は次のすべてとする。

• Liberkaのコーポレートサイト、ブランドサイト、採用・広報物
• Liberkaが提供するWebアプリ、モバイル表示、管理画面および組込みUI
• プレゼンテーション、営業資料、社内説明資料、研修資料
• 文書、報告書、仕様書、提案書、PDFおよび印刷物
• グラフ、表、ダッシュボード、図解およびデータ可視化
• 製品内外の文言、通知、画像、アイコン、背景およびモーション
• AIが生成または補助する、利用者に提示されるすべての成果物

本書にはスタイルガイド、コンポーネント語彙、モーション規範、媒体別規範および製品プロファイルを含める。これらと重複する独立したスタイルガイドは作らない。媒体または製品固有の詳細が必要な場合は、本書の原則を上書きしない補足として管理する。

本書へ、個別成果物の不適合一覧、改修計画、移行結果、リリース記録、日付付き変更履歴を記載してはならない。ガイドラインへの不適合と例外はGitHub Issue、規範そのものの変更理由はPull RequestとGit履歴で管理する。

1.1 規範語

1.2 判断の優先順位

判断が競合する場合は、次の順序を用いる。

1. 人の安全、尊厳、法令、セキュリティおよびプライバシー
2. アクセシビリティと情報の正確性
3. 利用者が達成すべき目的と、製品・資料の機能要件
4. このデザインガイドライン
5. 媒体プロファイルと製品プロファイル
6. 個別成果物の慣例

慣例は一貫性を保つための参考にはなるが、望ましいデザインの根拠にはしない。

1.3 ブランド、媒体、製品の三層

Liberkaのデザインは、次の三層で構成する。

1. Liberka Core: すべての成果物に共通する思想、品質、意味色、文字、余白、曲線、アクセシビリティ。
2. Medium Profile: Webアプリ、スライド、文書、図表など、媒体の制約に応じた表現方法。
3. Product Profile: Schediaなど、製品の役割、色、署名表現、固有語彙。

下位層は上位層を具体化する。下位層が上位層の禁止事項を解除してはならない。

2. Liberkaのデザイン思想

2.1 目的を先に置く

装飾や容器を加える前に、利用者が何を理解し、判断し、実行するのかを明確にする。画面、スライド、ページ、図表には中心となる目的を一つ置く。複数の目的がある場合は、優先順位と読む順序を明示する。

2.2 思考の負担を減らす

見た目を解読するために思考を使わせない。影、枠、色、アイコン、動きを増やす前に、情報の順序、見出し、文章、整列、余白で解決する。同じ形には同じ意味を持たせ、媒体が変わっても意味を入れ替えない。

2.3 判断権を人に残す

利用者が確認、編集、取消し、復旧できる状態を作る。AIの提案と人の確定、確定と実行済み、内部処理と外部送信を区別する。破壊的操作や重要な意思決定を、勢い、曖昧な文言、視覚的誘導で選ばせない。

2.4 状態と次の一歩を隠さない

処理中、未完了、確認待ち、成功、警告、失敗、空の状態でも、何が起きていて次に何ができるかを示す。進行する作業には、可能な限り現在地点、完了済み、残り、失敗地点を示す。

2.5 静かだが曖昧にしない

威圧的、評価的、過度に陽気な表現を避ける。一方で、危険、失敗、責任範囲を淡い色や婉曲表現で隠さない。重要度は、色だけでなく文言、位置、形、余白を組み合わせて伝える。

2.6 一貫性を学習可能性に変える

一度学んだ語彙、部品、色、操作、ページ構造を、別の画面や資料で別の意味に使わない。統一は見た目を揃えることではなく、利用者が次の場面を予測できることを目的とする。

2.7 素材の質を細部まで保つ

文字間隔、折返し、図表の単位、整列、フォーカス、待機状態、ページ番号、代替テキストまでを完成品質に含める。内容の正確さと同じ水準で、読む・見る・操作する品質を扱う。

2.8 表現には性能とアクセシビリティの上限を置く

曲線、透明素材、動く背景、映像、切替え効果は、理解、操作、表示性能を損なわない範囲で使う。表現のために製品を重くしたり、資料を読みにくくしたりしない。

3. ブランド人格と言葉

3.1 ブランド人格

Liberkaの成果物は、次の印象を共有する。

• 静か: 内容より先に装飾が主張しない。
• 明晰: 情報の順序、責任、次の行動が分かる。
• 人間的: 人を数値や処理対象として扱わない。
• 信頼できる: 事実、推定、提案、未確定を区別する。
• 前へ進める: 過度に鼓舞せず、現実的な次の一歩を示す。

3.2 言葉の原則

• 見出しは内容を要約し、雰囲気だけのコピーにしない。
• 操作名は、保存、削除、今日の記録へ→のように実際に起こることを動詞で書く。
• 確認文はよろしいですか？だけにせず、対象と結果を含める。
• エラーは謝罪だけで終わらず、起きたこと、影響、次にできることを示す。
• AIの提案は断定せず、編集、採用、拒否できることを示す。
• 内部用語、モデル名、処理IDは、復旧に必要な場合を除き主要メッセージへ露出しない。
• 利用者へ示す日付は20XX年M月D日を基準とし、曜日は（月）、時刻はその後へ続ける。20XX/M/DやM/Dのスラッシュ表記は、年月日の区切りを曖昧にするため使用しない。
• 「革新的」「シームレス」「可能性を解き放つ」など、具体的な価値を説明しない語を主文にしない。
• 実データのない効果、利用者数、推薦文、比較優位を作らない。
• 成功時も、製品ではなく利用者が行った仕事を主役にする。

3.3 情報の確度

事実、推定、例、提案、目標値を同じ外観で示さない。資料と製品の双方で、必要に応じて出典、基準日、単位、対象範囲、算出方法を付ける。装飾のための架空データは禁止する。

4. 視覚基盤

4.1 カラーシステム

色は見た目の名前ではなく意味で管理する。媒体固有の色指定へ変換する場合も、同じ意味役割を保つ。

必須事項:

• 破壊的操作とエラーは赤系、警告と注意はオレンジ系で示す。
• 通常情報、選択、成功は製品プロファイルの主色で示す。
• 色だけで意味を伝えず、文言、形、アイコン、位置の少なくとも一つを併用する。
• 通常文字は4.5:1以上、大きな文字と情報理解に必要なUI境界は3:1以上を基準とする。
• 半透明面、画像、映像、動く背景の上の文字は、最も読みにくい状態で検査する。
• 印刷、グレースケール、投影、画面共有でも重要な区別を失わない。
• 同じ意味役割の色を成果物ごとに即興で追加しない。

4.2 タイポグラフィ

文字は雰囲気ではなく、読みやすさ、情報階層、対象者、媒体、言語から選ぶ。装飾的な明朝見出しと丸みの強いゴシックを機械的に組み合わせるなど、書体の対比だけで個性を作らない。

共通原則:

• 日本語、英数字、記号、矢印が一つの文中で調和する書体を使う。
• 本文、操作、図表、注釈に必要なウェイトと字形が揃うことを確認する。
• 日本語本文の字間は原則0から0.02em相当とし、広い字間で高級感を演出しない。
• 短いラベルでも0.04em相当を超える字間を常用しない。
• 太さ700以上を全体へ多用せず、サイズ、位置、余白と合わせて階層を作る。
• 小ささや低コントラストだけで補足情報を表現しない。
• 数値比較には等幅数字を用い、桁、単位、小数点を揃える。
• 書体の追加は、役割、ライセンス、配布方法、フォールバック、表示性能を確認してから行う。

媒体別基準:

4.3 余白とグリッド

Liberkaの構造リズムは12を基準単位とする。主要な余白、グリッド、領域寸法には12 / 24 / 36 / 48 / 72 / 96 / 120を優先し、媒体の単位へ変換しても、近接、整列、反復、対比の関係を保つ。

12は2 / 3 / 4 / 6で等分できるため、境界に近い微調整、アイコンと文字の光学調整、密度の高いControl内部に限り2 / 3 / 4 / 6を使用できる。本文16 CSS px、1 pxの境界、44 CSS pxの操作対象など、可読性、物理寸法、アクセシビリティを満たす値を、倍数へ合わせるために崩してはならない。12基準はすべての数値を機械的に12の倍数へ丸める規則ではなく、構造上の関係を一貫させる規則である。

Web実装では--spacing-unit: 12pxを起点とする--spacing-12から--spacing-120までのトークンを使い、同じ階層に理由のない近似値を混在させない。プレゼンテーションと文書では、CSS pxをそのまま移植せず、12基準の比率をpt、mm、グリッドへ置き換える。

Webアプリのgap、padding、margin、inset、固定要素の補正には、生のpx、rem、emではなく正式な余白トークンを使う。この規則は認証後画面だけでなく、公開画面、認証画面、管理画面、Dialog、Popoverにも適用する。操作対象の44 CSS px、1 pxの境界、文字寸法、図形の描画位置など、余白とは異なる寸法は対象外とする。個別の例外値が構造上必要な場合は、用途が分かる名前のトークンとして定義し、同じ役割で共有する。

• 関連するラベルと値は近づけ、異なる話題は広く離す。
• 外枠を増やす代わりに、見出し、整列、余白、区切りで階層を作る。
• 余白を埋めるためにカード、図、文章を増やさない。
• スライドと文書では、全ページで共通する安全領域と基準線を定める。
• 例外的なはみ出しは意図を持つ場合だけ許容し、本文、操作、注記を裁ち落とし領域へ置かない。

4.4 角と曲線

大きな輪郭や署名表現では、一定曲率の円弧だけで形を作らない。クロソイド、サイン曲線、スーパー楕円、調整済みBezier曲線のように、接線と曲率が自然に変化する形を優先する。

• 複雑な輪郭は事前計算したベクターパスまたは少数の制御点として保持する。
• 表示時に高価な曲線計算を繰り返さない。
• 小さな操作部品、入力、カードは、互換性と性能のため標準的な角丸を許容する。
• 標準角丸は、Control 10、Card 14、Surface 18相当を基準とする。
• 左右端が円になるピル形状は、Buttonと短いLabelに限って許容する。
• すべてを大きな角丸にして柔らかさを演出しない。

4.5 境界と奥行き

影を階層表現の既定手段にしない。影が多い構成は、何が浮き、何が操作対象かを毎回解読させる。

• 通常のカード、一覧行、ボタン、図表に影を付けない。
• モーダル、ポップオーバー、メニューなど、実際に別レイヤーへ一時表示するものだけに一段の控えめな影を許容する。
• Chat Composerを会話面の下端に固定し、前後関係が境界と面の明度だけで判別できない場合は、一段の控えめな影を許容する。影の有無にかかわらず、ComposerはMessage Logを隠さない。
• 複数段の影、色付きグロー、ホバー時の浮上、常時浮く統計カードは禁止する。
• 階層は、面の明度、全周境界、余白、重なり、背景の抑制で示す。
• スライドや文書で、段落や数値を装飾カードへ入れて階層を作らない。

4.6 透明素材とガラス表現

透明度は、背後との関係を保ちながら一時レイヤーまたはナビゲーションを区別する場合に使える。透明であること自体を装飾の目的にしない。

必須条件:

• 文字の直下は安定した明度を保つ。
• 半透明色だけで境界を作らない。
• 不透明なフォールバックを持つ。
• ガラス面の上へさらにガラス面を重ねない。
• 印刷、PDF化、画面共有では不透明面へ変換して情報を保つ。
• Reduced Transparencyを利用できる環境では尊重し、それだけに依存しない停止手段も設ける。

4.7 アイコン、画像、イラスト

• 一つの成果物または製品で、線幅、端部、塗りの方針が揃ったアイコン体系を使う。
• 絵文字を機能アイコンとして使わない。
• アイコンだけの操作にはアクセシブルネームを付ける。
• 写真とスクリーンショットは実物を使い、架空のブラウザ、端末、IDE枠で飾らない。
• 画像には目的に応じた代替テキストまたは本文中の説明を付ける。
• AIをSparkles、ロボット、脳、魔法の杖で一律に表現しない。
• 意味のない人物イラスト、3D物体、発光球を余白埋めに使わない。

5. 情報構造と構成

5.1 一つの面に一つの中心目的

画面、ダイアログ、スライド、文書ページ、図表には、中心となる問いまたは行動を一つ置く。目的が複数ある場合は分割するか、主要・補助・詳細の順を明示する。

5.2 読む順序

• 結論または現在地を先に置き、根拠と詳細を後へ置く。
• 見出しだけを追っても全体の論理が分かるようにする。
• 左右・上下の配置だけへ順序を依存させず、読み上げ順と一致させる。
• 複数ページでは、現在地、全体量、次の遷移先を必要に応じて示す。
• 重要な注意を脚注、Tooltip、折りたたみの中だけに置かない。

5.3 容器の節度

カードは情報の一区切りを示す骨格であり、余白を埋める装飾ではない。スライドや文書では、見出し、段落、表、図の整列を優先し、Webアプリのカード外観をそのまま持ち込まない。

5.4 密度

密度は情報量ではなく、判断に必要な情報と視線移動の量から決める。重要な内容を薄く広げてスクロールやページ数を増やさず、同時に、異なる判断を一つの面へ詰め込まない。

6. 媒体プロファイル

6.1 WebアプリとWebサイト

• Semantic HTMLを優先し、見た目のために意味を壊さない。
• 320 CSS pxから大画面まで、情報の優先順位を保って再配置する。
• Hoverへ情報や操作を依存させない。
• LoadingとEmptyでも、Page Header、Navigation、Toolbar、入力領域、一覧、表、図表など、完了後に使う実際の構造を先に表示する。
• 一連の処理ではProgressまたはStepperで現在地点を示す。
• ブラウザ標準のalert()、confirm()、prompt()を製品体験に使わない。
• 主要操作は44×44 CSS pxを目安とし、WCAG 2.2のターゲットサイズ基準を下回らない。
• 通常レイアウトで100vwを使って意図しない横スクロールを発生させない。
• 印刷スタイルでは、ナビゲーションと装飾を除き、本文、出典、図表を保持する。

6.2 プレゼンテーションとスライド

• 一枚のスライドには一つの主張を置く。
• タイトルは話題名ではなく、そのスライドで伝える主張を表す。
• 導入、根拠、結論、次の行動が全体を通して追える順序にする。
• 本文を読み上げ原稿にせず、話者がいなくても誤解しない最小限の文脈を残す。
• 均等な三列カードやBento配置を、内容の関係がないまま使わない。
• 図、表、数値には単位、期間、母数、出典を必要に応じて付ける。
• 強調色は一枚につき一つの意味を基本とし、装飾のために色を散らさない。
• トランジションは構造理解に必要な場合だけ使い、全要素のfade-upやbounceを使わない。
• 画面共有、PDF書出し、白黒印刷でも意味が保たれるようにする。
• 発表者名、機密区分、ページ番号、日付は必要な資料だけに一貫して配置する。

6.3 文書、報告書、提案書、PDF

• 見出し階層、目次、ページ番号、図表番号、参照関係を一貫させる。
• 一段落には一つの論点を置き、長い箇条書きで論理を代替しない。
• 本文の一行は、日本語でおおむね35–45字を読みやすさの目安とする。
• 見出し直後の孤立、段落一行だけの改ページ、表見出しと表本体の分離を避ける。
• 表は列見出しを繰り返し、単位と注記を表の近くに置く。
• PDFは検索・選択可能な文字を保持し、可能な形式ではタグ、見出し、読み順、代替テキストを設定する。
• 色、背景画像、透過効果がなくても論理と重要度が伝わるようにする。
• 装飾カード、引用風の大きな符号、意味のない英大文字ラベルを反復しない。
• 外部文書では、版、発行主体、基準日、連絡先、機密区分を用途に応じて明示する。

6.4 グラフ、表、データ可視化

• 図表は問いに答えるために選び、見栄えのために種類を増やさない。
• タイトルは何を比較しているかを表し、読み手に結論を強制する誇張表現を避ける。
• 軸、単位、期間、母数、集計方法、欠損、出典を必要に応じて示す。
• 比較に不要な3D、影、グラデーション、過剰な補助線を使わない。
• 色だけで系列を区別せず、直接ラベル、線種、記号、配置を併用する。
• 円グラフは少数の構成比に限り、比較が目的なら棒グラフを優先する。
• 切断軸、面積、遠近法で差を誇張しない。
• インタラクティブなグラフには、同じ情報へ到達できる要約または表形式の代替を用意する。
• 表の数値は桁、小数点、単位を揃え、並び順に意味を持たせる。

6.5 マーケティング、広報、採用

• 製品の具体的な仕事と対象者を先に説明する。
• 架空の顧客ロゴ、推薦文、導入効果、利用者数を作らない。
• 内容のない100vhヒーロー、意味のない3Dオブジェクト、汎用的なAIコピーで価値を代替しない。
• 実画面を示す場合は実データを匿名化したものか、例示であることが明確なデータを使う。
• Call to Actionは実際の遷移または結果を表し、複数の同格な主要操作を競合させない。

7. Webコンポーネントの正式語彙

7.1 画面骨格

• Desktop SidebarとApp Top Barはviewportへ固定し、ページ固有のMain Contentだけをdocument scrollで移動させる。Page全体を独自の全画面Scroll Containerへ入れない。
• Main Contentは、固定Sidebarの幅と固定Top Barの高さをApp Shellのトークンから正確に差し引き、内容を背後へ隠さない。アンカー移動、フォーカス移動、エラー位置への移動にも同じ上部補正を適用する。
• 高さが不足する場合はDesktop SidebarのNavigation部分だけをスクロール可能にし、製品名、現在地、アカウント操作を同時に失わない。
• モバイルではDesktop Sidebarを隠し、固定Mobile Top BarとMobile Navigation Panelへ再構成する。Main ContentはTop Barとsafe-areaの高さを補正し、document scrollを維持する。
• SchediaのDesktop Sidebarにある「今日の記録」はCardではなくSidebar Navigation Tabとして扱う。情報面に見える外観であっても、内側に小さなLinkを置かず、余白を含む面全体を単一のLinkとする。Hover、Focus、現在地表示も同じ面へ適用する。
• Table、ログ、チャットなど、境界と目的が明確な領域だけに局所的なScroll Containerを許容する。bodyとMain Contentの二重縦スクロールを作らない。

7.2 Card

Cardは四隅が角丸になった、情報の一区切りを示す構造である。

• 全周1 px相当の境界で外部と区切る。
• 見出しは通常の文字階層で示し、Label形状で囲まない。
• Card全体を選択、モード切替え、表示切替え、ページ遷移に使わない。
• クリック可能に見せるHover、pointer、浮上、拡大をCard自体へ付けない。
• 操作はCard内部のButtonまたはLinkへ置く。
• Card内Cardは、独立した情報境界が必要で、余白やSectionでは表現できない場合に限る。
• 同じ視点で比較するCard群は、各Cardの最小可読幅を保てる間は複数列で一覧できるようにする。ブレークポイントを越えただけで早く一列へ落とさない。
• Table、ログ、チャットのように領域内スクロール自体が機能でない限り、Card本体は内容の高さまで広げ、内容を切る縦スクロールを作らない。
• 一辺だけに色線を置くCardは禁止する。

7.3 Button

Buttonは、ユーザーの操作によって同じ画面内の状態またはデータを変更する部品である。

• 色と塗りで周囲から区別し、Hover時は色を変える。
• 形状は角丸四角またはピルを許容する。
• マウスカーソルはpointerとする。
• Dialog、Popover、Menuを開くButtonには矢印を付けない。
• Button外観で画面遷移するNavigation Buttonには末尾に→を付ける。
• 破壊的Buttonは赤系で示す。
• Disabledは理由が分からない状態を作らず、必要に応じて説明を近くに置く。
• Hover時に位置、寸法、形を変えない。

SchediaではProduct Primary #009EA1を主要操作の識別色とする。ただし、通常サイズのButton Labelに月白#F6F7F8を重ねると4.5:1を満たさないため、通常Action Buttonは--button-primary-action-background（#007477）、Hover時は--button-primary-action-background-hover（#005456）、文字は--button-primary-action-color（月白#F6F7F8）を使う。#009EA1を面に使う場合はInkなど4.5:1以上となる文字色と組み合わせ、状態ごとに背景色と文字色を一組で定義する。

--button-square-backgroundは正式tokenではない。consumer repositoryに互換目的で残っていても、新規または変更する通常Action Buttonの根拠として使用せず、Primary Action Tokenへ移行する。

濃緑の--button-emphasis-backgroundは、チーム作成、ワークスペース作成、ユーザー招待のように、利用者の明示操作で新しい主体または参加関係を作るButtonだけに限定する。保存、更新、移動、表示、画面遷移などの通常操作へ多用しない。DangerとWarningにはPrimaryの配色を流用しない。

補助操作は--button-secondary-background、--button-secondary-colorと対応するHover tokenを使い、画面固有の淡色と文字色を追加しない。補助操作の選択中はPrimaryへ切り替え、aria-pressedと近接する状態文を併用する。

7.4 Label

Labelは、件数、状態、種類など数語の情報を伝える非操作要素である。

• 原則一行、数語に限定する。
• Hoverで色を変えず、クリックへ反応せず、pointerを使わない。
• CardまたはSectionの見出しとして使わない。
• 色だけで状態を伝えない。

7.5 Tabs

Tabsは、同じ文脈の中で表示面を切り替える操作部品である。

• 選択中は下線、濃い文字、必要に応じた件数Labelで示す。
• Hover時は背景色を変える。
• tablist、tab、tabpanelの関係を持たせる。
• Arrow keysで同じTablist内を移動し、HomeとEndを支援する。
• ページ間ナビゲーション、単独の絞込み、実行操作へ流用しない。
• CardやLabelの外観でTabsを代用しない。

7.6 Link

Linkは別のURLまたはページへ移動する。

• 本文Linkは下線または文脈上明確なLink表現を持つ。
• Button外観にする場合も、実装上はLinkの意味を保つ。
• 新しいタブを開く場合は、必要に応じて事前に伝える。
• ここをクリックではなく遷移先を説明する文言を使う。

7.7 Form Controls

• Label、Control、Help、Errorを意味的に関連付ける。
• PlaceholderだけでLabelを代用しない。
• 必須と任意をフォーム全体で一貫して示す。
• エラーは対象の近くに置き、原因と修正方法を説明する。
• 入力値を失敗後も可能な限り保持する。
• 選択肢が少なく比較が重要ならRadio、多い場合はSelect、独立した二値設定にはSwitchを使う。
• Selectの既定値は、利用者が最初に比較すべき最上位の範囲を選ぶ。ワークスペースと個別チームが並ぶ場合はワークスペース、全社と部門が並ぶ場合は全社を既定とし、下位項目を一覧の先頭という理由だけで選ばない。権限外の範囲は候補にも既定値にも含めない。
• Selectの選択肢はHoverとFocus Visibleで操作対象だと分かる面を作り、文字とのコントラストを保つ。SchediaではHover面を#009EA1、文字を月白#F6F7F8とし、Defaultの外観は変えない。
• 日付入力は保存値やAPI値にISO形式を使用してよいが、利用者に見えるControl面は20XX年M月D日で表示する。ブラウザやOSによって見え方が変わるネイティブ日付文字列を、そのまま表示面にしない。

7.8 Dialog、Popover、Menu、Tooltip

• 製品内でユーザーが見る確認、選択、入力は、製品のデザインに統一したDialogを使う。
• 初期フォーカス、フォーカストラップ、Escape、フォーカス復帰、背後の操作抑止を持つ。
• 破壊的操作は、対象と影響を示したうえで赤い実行Buttonによる確認を必要とする。
• 警告はオレンジを使い、破壊と混同しない。
• Dialogの上へDialogを重ねず、同じ面のステップ切替えを優先する。
• PopoverとMenuは起点との関係を保ち、画面外へはみ出さない。
• Tooltipへ重要情報、エラー、操作を置かない。

7.9 Progress、Loading、Empty State

• Loading中は、最終表示で使うPage Header、Tabs、Toolbar、Card、List、Table、Chart、入力領域を先に配置し、そのデータ領域内へ読込状態を示す。
• 「骨格を保つ」とは、最終画面と無関係なSkeleton Cardや仮の図形を追加することではない。汎用の大きなSkeleton面、実際の行数を示さない反復Placeholder、意味のない灰色の線は禁止する。
• 読込前後で、外枠の幅と高さ、見出し、Tabsの選択位置と外観、Toolbar、入力、文字体系を同じにする。利用可能になったデータだけを、予約済みの領域へ表示する。
• Page全体のLoading画面を、画面遷移や再取得のたびに必ず挟んではならない。見出し、入力、取得済みデータなど用意できた内容は順に表示し、本当に未取得のデータ領域だけへLoading状態を置く。見せるための最低表示時間を設けない。
• 同じ対象と期間を再取得するときは、表示済みの有効な内容を消さず、同じ骨格のまま更新状態を伝える。対象、権限、ワークスペースを切り替え、旧内容が新しい選択の内容だと誤認される場合に限り、旧データを除いて新しい対象の骨格を表示する。
• 読込中のTabや入力を一時的な配色、透明度、代替書体で示さない。操作不能であることはaria-busy、aria-disabled、状態文で伝え、完了時に外観を切り替えない。
• 読込状態は、対象を表す文言、aria-busyまたはrole="status"、必要最小限の進捗表示で示す。Empty Stateを中央配置する領域では読込文も同じ基準で中央配置し、文言の切替えで視線位置を動かさない。
• Spinnerだけを大きな空白の中央へ置かない。
• Empty StateでもPage Header、Tabs、Toolbar、追加操作を必要に応じて残す。
• 段階処理は現在地点、完了済み、残り、失敗地点を示す。
• 終了時はProgressを消すだけでなく、成功または失敗を通知する。

7.10 List、Table、Tree、Chart

• 順序だけならList、行列比較ならTable、親子関係ならTreeを使う。
• List Row全体を疑似Buttonにせず、行内操作を明示する。
• Treeの階層はインデント、開閉、親子関係で示し、Card左縁の色線で示さない。
• ドラッグ操作には可視ハンドル、grab状態、キーボード代替、結果通知を用意する。
• Tableは見出し、並び順、単位、横スクロール範囲を明確にする。
• Chartは要約、説明、表形式の代替を持つ。
• Chartの表、凡例、詳細を展開しても、先に表示されているプロット領域を縮小または押しつぶしてはならない。プロットの寸法を保ち、追加内容を下へ展開するか、所属する領域をスクロールさせる。

7.11 Chat

Chatは、継続する会話、質問、記録または支援を時系列で扱う領域である。会話が画面の中心目的である場合は、必要な現在地と状態を保ったうえで、残りのviewportを履歴と入力へ優先配分する。Chatの外側に別の中心目的がある場合は、画面全体をChat専用構成に置き換えない。

会話領域とナビゲーション

• App Top Barに現在地が表示されている場合、Main Contentの先頭へ同じPage Titleを反復しない。
• 新規セッション、履歴、検索、設定など会話を直接構成しない補助操作は、専用SidebarまたはApp Top Bar内の一つのMenuへまとめる。補助操作のためだけに常設Toolbarを追加しない。
• モバイルでは、同じ位置へ複数のHamburger Buttonを並べない。App ShellのMobile Navigation Panelへ画面固有操作を統合するか、役割の異なる操作だと名称と外観から判別できる構成にする。
• 画面の中心目的であるChatは、Message LogにHeaderとComposerを除いた利用可能な高さを与え、Message Logだけを局所的に縦スクロールさせてよい。埋込みChatはdocument scrollを優先し、不要な二重縦スクロールを作らない。
• 公開範囲、保存の有無、利用上の重要な注意は、利用者が送信前に確認できる位置に示す。継続的な判断に不要な説明は、Empty Stateまたは導入メッセージへ簡潔に統合する。

セッションと履歴

• 履歴の保存は機能要件、利用者の理解、プライバシーに基づいて決める。外観またはチェックリストへ合わせるために、保存しないChatへ履歴やセッションを追加しない。
• 履歴を保存するChatは、新規セッションと既存セッションを混在させず、各項目から題名、更新日時、必要な状態、現在選択中のセッションを判別できるようにする。件数や反復的な探索により目視での発見が難しくなる場合は検索を用意する。
• 履歴の表示形式に応じて操作モデルを分ける。常設Sidebarと非モーダルPanelは通常のフォーカス順序を保ち、フォーカスを閉じ込めたり背後の会話操作を抑止したりしない。MenuはEscapeによる閉じる操作と起点へのフォーカス復帰を持つ。フォーカストラップと背後の操作抑止は、背後操作を止めるモーダルPanelまたはDialogだけに適用する。
• セッションを開いたときはMessage Logの末尾または最初の未読位置を基準に表示し、読み込みによってComposer、Header、フォーカスを移動させない。過去のMessageを追加する場合は、読んでいた位置を維持する。

Messageと動的更新

• Message Logは視覚的かつアクセシブな名称を持ち、Messageを古い順からDOM上の読み順と一致させる。新着Messageはrole="log"、live region、または同等の方法で通知し、既存履歴全体を再度読み上げさせない。ストリーミング中は文字ごとでなく、意味のある単位または完了時にまとめて通知する。

• Messageの追加、生成中の更新、送信結果の通知でフォーカスを奪わない。利用者が末尾付近を読んでいる場合だけ新着へ自動追従し、過去を読んでいる場合は位置を保って、新着位置へ移動する操作を示す。

• Message Bubbleは全周境界とSurfaceで背景から区切り、基本形を角丸とする。発話者側の下角だけ半径を小さくして方向を補助できるが、方向を形だけへ依存させない。Tailとして別要素または疑似要素の三角形を継ぎ足さない。

• AI、利用者、システムの通知、外部操作、承認待ちを、文言、読み上げ、構造の組合せで区別する。内部実装名を主要メッセージへ露出させず、アクセシブな発話者情報を保ったうえで、連続する同一発話者の名前、時刻、AvatarまたはLogoの反復は省略してよい。

• Bubbleは長文、URL、改行、長い日本語、コードまたは構造化内容で横幅を越えない。必要な折返しを行い、Message Log全体へ意図しない横スクロールを作らない。

Composerと送信

• ComposerはChat領域の下端へ固定またはsticky配置し、safe-areaとソフトキーボードを考慮する。Messageが増えても入力位置を見失わせず、ComposerがMessage Logの内容を隠さない余白を確保する。
• 一行時の入力面は左右端が円になるピル形状を許容する。複数行時は高さだけを上方向へ拡張し、ControlまたはSurfaceの一定半径へ切り替える。高さに比例して半径を増やさない。
• 原則五行までは内容に応じて自動拡張し、それを超える場合は高さを固定して入力内部だけを縦スクロールさせる。利用者によるサイズ変更を無効にする場合は、200%の文字拡大で入力と送信を失わない。
• 送信Buttonは44×44 CSS px以上の操作対象を保ち、flexまたは狭幅で押しつぶさない。Iconだけの円形Buttonを使う場合は、視覚的かつアクセシブな名前から送信操作だと判別できるようにする。
• Send Buttonは、送信可能、未入力、生成または送信中、失敗、文字数超過を判別できる状態を持つ。処理中は重複送信を防ぎ、完了または失敗まで状態を示す。
• キーボード送信を提供する場合は、改行と送信の操作をComposerの近くへ明記する。日本語などのIME変換中にEnterを押しても送信せず、変換確定と送信を区別する。ショートカットを使えない環境でも、送信Buttonから同じ目的を達成できるようにする。
• 文字数制限がある場合は現在値と上限を示し、超過時は送信不能の理由を色だけでなく文言で示す。
• モバイルの入力文字は16 CSS px以上とし、Focus時の自動拡大を起こさない。Focusやソフトキーボード表示によってMessage Log全体が画面外へ移動したり、Composerがキーボードの背後へ隠れたりしないことを実機相当で確認する。

8. 状態、インタラクション、AI

8.1 インタラクション状態

操作部品は、必要な範囲で次の状態を設計する。

8.2 AIを介する体験

AIらしさを装飾で示さず、責任、確度、状態を明確にすることで示す。

• AI生成内容を、人が確定した事実と同じ外観にしない。
• 外部送信文は、送信前に内容と相手を確認できるようにする。
• 重要な根拠と注意を折りたたみ内だけに置かない。
• AIが利用不能でも、人が確認、編集、実行できる安全な経路を残す。
• ShimmerをAIの象徴として使わず、Skeleton、Progress、状態文を使う。

9. アクセシビリティ、レスポンシブ、モーション

9.1 アクセシビリティ

WCAG 2.2 AAを最低目標とし、企画、構成、制作、実装、書出しの各段階で確認する。

• キーボードだけで、移動、選択、編集、送信、閉じる操作を完了できる。
• フォーカス順序と読み上げ順を視覚順序に一致させる。
• フォーカス表示を消さない。
• 色、位置、形、音、動きの一つだけへ意味を依存させない。
• 200%ズームと文字拡大で操作を失わず、400%相当の狭い表示でも再配置する。
• forced-colors、高コントラスト、OSの支援設定を意図的に妨げない。
• スライドと文書も、読み順、代替テキスト、コントラスト、言語設定を確認する。
• 自動更新、タイムアウト、消える通知には停止、延長、再確認の方法を用意する。

9.2 レスポンシブ

レスポンシブは縮小ではなく再構成である。

1. 主要な内容と主要操作を残す。
2. 複数列を一列へ再配置する。
3. 補助情報を本文の後または開閉可能な領域へ移す。
4. Toolbarを折返し、Popover、Menuへ再配置する。
5. 表とTabsだけ、意味を失わない範囲で領域内横スクロールを許容する。

複数列から一列への再配置は、Card内の文字、操作、進捗表示が読めなくなる直前に行う。関連する概要Cardが十分な幅を保てるときは複数列を維持し、一画面での比較可能性を優先する。次の行動、推奨、手順の短いListは項目をすべて表示し、List内の縦スクロールや末端の見切れを作らない。

320、375、414、768、1024、1440 CSS pxを代表幅として確認する。safe-area、ソフトキーボード、長い日本語、最大件数、文字拡大、Hoverのない入力環境を含める。

9.3 モーション

• 動きは、状態変化、空間関係、操作結果を理解させるために使う。
• Controlの反応は120–180 ms、DialogやPanelは180–260 msを基準とする。
• 装飾だけの常時移動、カーソル追従、視差スクロール、浮遊物を使わない。
• transition: allを使わず、変化するプロパティを限定する。
• レイアウトを連続的に動かすプロパティより、transformとopacityを優先する。
• prefers-reduced-motion: reduceでは非本質的な動きを停止する。
• スライドでは全要素へ同じ登場アニメーションを付けず、順序理解に必要な段階表示だけに使う。

10. Schedia製品プロファイル

SchediaはLiberka Coreを、日々の記録、ToDo、QA、資料、振り返りを扱う業務製品として具体化する。

10.1 人格と利用状況

Schediaは、デジタル習熟度、年齢、役割、利用端末が異なる人の日常業務を支える。感情、失敗、相談、非公開QAなど慎重な情報を扱うため、評価されている印象や過度な緊張を生まない。

製品の印象はLiberka Coreと同じく、静か、明晰、人間的、信頼できる、前へ進めるとする。

10.2 Schediaカラー

Schediaでは、ミント、クローバーを想起させる緑と白の関係を製品署名として積極的に使う。

通常情報、成功、選択は青ではなくSchedia greenを使う。#009EA1はSchediaの濃い緑として主要操作と選択に、#8ECCB0は淡い強調と浸潤表現に用いる。色を増やす前に、この二色と背景白、月白の組合せで意味を構成する。

10.3 Schediaタイポグラフィ

Schediaの製品UIは、OSのUIと調和するニュートラルなsystem UI sans-serifを基準とする。画面ごとに明朝、丸ゴシック、英字ディスプレイ書体を追加しない。

10.4 ライトテーマ

Schediaはダークモードへ対応しない。

• color-scheme: lightを明示する。
• OS設定に応じた独自の暗色配色を追加しない。
• 外部の埋込みUIも、可能な範囲でライトテーマへ統合する。
• 強制色、高コントラスト、色反転などの支援機能を妨げない。

10.5 Schedia Static Infusion Background

Schediaの署名背景は、白い液体へ緑の液体を落とし、その色が穏やかに浸潤した後の状態を表す静止背景である。背景アニメーション、ランダム座標、時間変化は使用しない。

• 背景白#E4EFEE、白、ミント#8ECCB0を低コントラストのGradientとして構成する。
• 静止した濃淡は情報、進捗、状態を表さず、本文や操作より背面に置く。
• Sidebar、Header、Cardなど内容を載せる面で可読性を確保し、背景との境界を色だけに依存しない。
• 画面遷移、スクロール、カーソル、ユーザー情報に応じて位置、濃度、形を変えない。
• blob、発光orb、粒子、動画、Canvas、WebGLを背景表現へ追加しない。
• 背景に起因するCLSや、入力、スクロール、Dialog操作への遅延を発生させない。

10.6 Schediaの確認と危険操作

製品内でユーザーが見る確認、選択、入力は、すべてSchediaの外観と操作に統一する。ブラウザによって異なる確認ポップアップは使用しない。

• 破壊的操作は確認を必須とし、対象、影響、復旧可否、赤い実行Buttonを示す。
• 忠告はオレンジ、通常情報と選択はSchedia greenを使う。
• Dialog内から追加確認が必要な場合は、Dialogを重ねず同じ面の確認ステップへ切り替える。

11. 禁止パターン

11.1 絶対禁止

• カードの左縁など、一辺だけにアクセント線を置くside-stripe card
• カードによる選択、モード切替え、表示切替え、ページ遷移
• ブラウザ標準のalert()、confirm()、prompt()
• 確認のない破壊的操作
• 破壊的操作を赤系以外で示すこと
• LabelをCardまたはSectionの見出しとして使うこと
• 実在しない数値、顧客、推薦文、効果、出典を事実として示すこと
• アクセシビリティまたは情報の正確性を、ブランド表現を理由に下げること

11.2 採用しないAI定型表現

• すべてをCardへ入れる構成、意味のないCard内Card、均等なBentoグリッド
• 三列の均等なアイコンCard
• 影だけで階層を示す構成、全Cardの浮上、色付きグロー
• 全面Glass、Glassの入れ子
• 紫から青、紫からピンクのグラデーション
• グラデーション文字
• Sparkles、ロボット、脳、魔法の杖をAIの既定記号にすること
• 発光orb、汎用blob、オーロラ、意味のない3D物体
• すべて中央揃え、内容のない100vhヒーロー
• 全CardのHover拡大、transition: all
• 全Sectionのfade-up、bounce、cursor follower
• 英大文字の短いLabelをすべての見出しの上へ反復すること
• 機能を説明しない抽象的なAIコピー

奇抜さそのものを目的にしてはならない。定型表現を避ける場合も、利用者、内容、媒体、製品固有の仕事に根拠を持たせる。

12. デザイン受け入れ基準

12.1 すべての媒体

• [ ] 中心目的と読む順序を説明できる。
• [ ] 事実、推定、提案、例示を区別している。
• [ ] 文字、色、余白、図形が意味役割に従っている。
• [ ] 影、Card、Glass、動きが装飾のために増えていない。
• [ ] 実データでない数値、推薦、効果を事実として示していない。
• [ ] 対象者が使用する最終サイズと環境で読める。
• [ ] 色、画像、音、動きがなくても重要な意味を失わない。
• [ ] 出典、単位、期間、版など必要な文脈がある。

12.2 Webアプリ

• [ ] Default、Hover、Focus、Active、Disabled、Loading、Success、Warning、Errorの必要な状態がある。
• [ ] 0件、少数、大量、長文、読込失敗、権限不足を確認した。
• [ ] LoadingとEmptyでも実際の画面骨格を保ち、汎用Skeleton Cardや意味のないPlaceholderを追加していない。
• [ ] マウス、キーボード、タッチで同じ目的を達成できる。
• [ ] 破壊的操作は製品内Dialogで確認する。
• [ ] 320、375、414、768、1024、1440 CSS pxで意図しない横スクロールがない。
• [ ] 200%ズーム、Reduced Motion、forced-colorsで主要操作を失わない。
• [ ] LCP、CLS、INP、Long Taskへ有意な悪化を加えていない。

12.3 プレゼンテーション

• [ ] 各スライドのタイトルだけで論理の流れを追える。
• [ ] 最後列、画面共有、PDF書出しで本文と図表を読める。
• [ ] 一枚に一つの主張があり、要素の関係が配置から分かる。
• [ ] 図表に単位、期間、母数、出典がある。
• [ ] アニメーションなしでも内容と順序を理解できる。
• [ ] 色覚差、白黒表示、低品質な投影でも重要な区別を失わない。

12.4 文書とPDF

• [ ] 見出し階層、目次、ページ番号、図表番号が一貫している。
• [ ] 改ページ、表、脚注、参照が分断されていない。
• [ ] 文字が検索・選択可能で、読み順と言語が設定されている。
• [ ] 画像と図表に代替説明がある。
• [ ] 画面と印刷の両方でコントラストと情報階層を保つ。
• [ ] 版、基準日、発行主体、機密区分が用途に応じて分かる。

13. 運用と適合管理

13.1 ガイドライン本文の純度

本書は恒久的な規範だけを保持する。次の情報を本書へ追加しない。

• 個別画面、スライド、文書の違反一覧
• 改修予定、移行順序、担当者、期限、進捗
• 実装済み項目、リリース結果、検証ログ
• 日付順の変更履歴、過去の判断理由、失敗事例集
• 特定リポジトリのファイルパス、行番号、Pull Request番号

規範の変更理由とレビューはPull Request、文面の履歴はGit、不適合と是正はIssueを正本とする。

13.2 不適合を発見した場合

本書に反する成果物を発見した場合は、放置せずGitHub Issueへ登録する。原則として、一つの違反または同じ原因を持つ密接な違反群を一つのIssueとする。大規模監査のIssueは、個別違反を発見するための親Issueとして使い、是正作業は子Issueへ分ける。

Issueには次を含める。

• 対象となる製品、媒体、成果物、URLまたはファイル
• 違反している本書の章と規範
• スクリーンショット、ページ番号、再現手順などの客観的な証拠
• 利用者、アクセシビリティ、理解、操作、ブランドへの影響
• 期待する状態と、完了を判断できる受け入れ条件
• 優先度、担当範囲、関連IssueまたはPull Request
• 例外を求める場合は、その理由、代替策、終了条件、期限

リポジトリに用意されたdesign-guidelineラベルとデザインガイドライン違反Issueテンプレートを使用する。

13.3 Pull Requestでの適合確認

• デザインへ影響する変更は、該当する受け入れ基準をPull Requestで確認する。
• 視覚変更には、対象媒体に適した比較画像または書出し結果を添える。
• Webでは、代表幅、キーボード、状態差、アクセシビリティ、性能を確認する。
• スライドと文書では、編集画面だけでなく、発表、PDF、印刷など最終出力を確認する。
• 不適合を解消するPull Requestは対応Issueを参照する。
• 既存表現を正当化するためにガイドラインを緩めてはならない。

13.4 例外

例外はIssueで期限付き管理する。適用範囲、理由、影響、代替策、終了条件、期限、責任者を明記する。期限のない一時対応は認めない。

安全、アクセシビリティ、正確性、確認のない破壊的操作、架空の事実には例外を設けない。

13.5 ガイドラインを変更する場合

規範の変更は、個別成果物への追認ではなく、Liberka全体で繰り返し使える原則として提案する。Pull Requestでは、影響する媒体と製品、変更後の判断方法、アクセシビリティへの影響をレビューする。変更理由や議論を本文の変更履歴として複製しない。

14. 参考資料

• Apple Human Interface Guidelines: Design principles
• Apple Human Interface Guidelines: Materials
• デジタル庁デザインシステム
• デジタル庁デザインシステム: デザインシステムとは
• デジタル庁デザインシステム: スタイルガイド
• デジタル庁デザインシステム: アクセシビリティ
• Material Design 3: Interaction states
• WCAG 2.2
• ARIA Authoring Practices Guide
• MDN: prefers-reduced-motion
• Hallmark: Anti-AI-slop design skill