Liberkaデザインガイドライン

Liberkaのすべての成果物に共通する思想・言葉・ブランド・品質の基準です。媒体固有の作り方はIndividual Media Guidelinesで確認できます。

1. このガイドラインの読み方

適用層: 基本原則（Liberka Core）

1.1 何に適用するか

このガイドラインは、Liberkaの名前で人へ届くすべての成果物に適用します。公開サイトや製品画面だけでなく、営業資料、社内文書、通知、図表、AIが補助した文章も対象です。媒体や製品に固有の規則がない場合も、基本原則はなくなりません。

• 必須: 成果物の所有者は、基本原則、対応する媒体別標準、該当する製品別規則の順に確認します。
• 必須: AIが生成または補助した成果物も、人が作った成果物と同じ基準で検証します。
• 禁止: 個別の製品やページに、この正本と競合する独自のデザイン規範を作りません。
• 禁止: 個別成果物の不適合一覧、改修計画、リリース記録、日付順の変更履歴を本文へ混ぜません。それらはIssue、Pull Request、Git履歴で管理します。

1.2 規範語

規則は強さを曖昧にしません。本書と、本書から参照する仕様では、次の四語を明示します。

• 必須: 規範的な箇条書きには、四つの規範語のいずれかを付けます。
• 原則: 数値だけで品質を説明せず、その値が守る読みやすさ、意味、操作を併記します。
• 禁止: 「なるべく」「いい感じに」「適切に」のように、合否を判断できない言葉だけで規則を終えません。

1.3 判断の優先順位

規則が競合するときは、次の順序で判断します。

1. 人の安全、尊厳、法令、セキュリティ、プライバシー
2. アクセシビリティと情報の正確性
3. 利用者が達成すべき目的と機能要件
4. 基本原則（Liberka Core）
5. 媒体別標準（Medium Standard）
6. 製品別規則（Product Profile）
7. 個別成果物の慣例

• 原則: 慣例は学習済みの操作を守る根拠にはできますが、望ましいデザインであることの証明にはしません。
• 禁止: ブランドらしさ、見栄え、慣例を理由に、上位の安全性やアクセシビリティを下げません。

1.4 三つの適用層

三層は、ファイルの種類ではなく、判断の責任を分ける仕組みです。

• 必須: 下位層は上位層を具体化します。
• 必須: consumer repositoryとの接続情報は「適用設定」として管理します。適用設定はデザイン上の第四層ではありません。
• 禁止: 媒体別標準や製品別規則が、基本原則の必須事項または禁止事項を解除することはできません。

1.5 共通原則と媒体別の具体化を分ける

共通原則には、目的、判断権、正確性、言葉、読む順序、意味色、ブランド、可読性、アクセシビリティを置きます。ブランドpaletteや構造リズムなど、意図して共有する基準値は共通に保持します。共通であることは、全媒体を同じ見た目や寸法にすることではありません。

• 必須: 特定媒体の操作、出力条件、実装技術を前提とする規則は、媒体別の所有先に置きます。共通原則には守る目的と参照先を残します。
• 必須: 規則の適用は成果物の目的と実際の機能で判断します。操作を持つHTMLでは第8章・第9.4節も参照し、HTML制作であることだけを理由に資料全体をWeb媒体へ切り替えません。
• 禁止: 共通tokenファイルに値が存在することだけを理由に、Webの背景、操作部品、角丸、時間指定を他媒体へ適用しません。

たとえば「情報の階層を読み取れる」は共通原則です。投影用の文字寸法、文書の本文書体と改ページ、WebのFocusやCSSは媒体別で具体化します。製品の人格・固有語彙は製品別規則に置きます。

2. Mission・Vision・Valueから「選べる状態」をつくる

適用層: 基本原則（Liberka Core）

2.1 Mission

人が自分の人生を“選べる状態”へ導く仕組みをつくる。

選択肢を並べるだけでは、人は選べる状態になりません。状況が分かり、結果を想像でき、やり直せて、決めないことも選べる必要があります。デザインは、選択肢の数より先に、判断できる条件を整えます。

• 必須: 利用者が何を理解し、何を決め、次に何が起こるかを説明できる構成にします。
• 必須: 重要な操作には、確認、編集、取消し、復旧のうち必要な経路を用意します。
• 禁止: 勢い、曖昧な文言、視覚的な誘導によって、重要な決定を急がせません。

2.2 Vision

選択できる生き方が当たり前になる社会をつくる。

特別な知識や身体条件を持つ人だけが使える仕組みでは、選択できる状態は当たり前になりません。読み方、操作方法、端末、言語、経験が異なっても、中心となる目的へ到達できる必要があります。

• 必須: 支援技術、キーボード、タッチ、文字拡大、狭い画面でも中心目的へ到達できるようにします。
• 原則: 初めて使う人が、過去の経験から次の操作を予測できる一般的な語彙と構造を使います。
• 禁止: Hover、色、音、動きのいずれか一つだけへ意味や操作を依存させません。

2.3 Value

Choose with Love — 大切なものを最優先に選ぶ

大切なものは、画面上で最も派手なものとは限りません。利用者の安全、時間、尊厳、関係性を、装飾や短期的な指標より先に置きます。

• 必須: 中心目的と、それを支える情報の優先順位を定めます。
• 禁止: 利用者の不安や見落としを利用して行動を促しません。

Grow to Choose — 選択を増やすために成長する

一貫性は、変えないためではなく、学んだことを次の場面で使えるようにするためにあります。より良い根拠が得られたときは、規範そのものも更新します。

• 必須: 規範を変更するときは、影響範囲と変更後の判断方法を説明します。
• 原則: 同じ形、語、色、操作には、媒体が変わっても同じ意味を持たせます。

Honest Dialogue — 感情も問題も誠実に向き合う

静かな表現は、問題を小さく見せることではありません。失敗、危険、不確実さ、責任範囲を、強すぎないが見落とせない形で伝えます。

• 必須: 事実、推定、提案、未確定、失敗を区別します。
• 必須: エラーでは、起きたこと、影響、次にできることを示します。
• 禁止: 謝罪や婉曲表現だけで原因と影響を隠しません。

Give First — 価値も愛も出し惜しみしない

利用者が必要な情報を、登録、クリック、スクロール、Tooltipの奥へ不必要に隠しません。装飾より先に、判断に必要な内容を渡します。

• 必須: 重要な条件、費用、公開範囲、取消し可否は、決定前に確認できる位置へ置きます。
• 禁止: 重要な注意を脚注、Tooltip、閉じたAccordionの中だけに置きません。

Long-term Choice — 長期で正しい選択をする

一時的な流行や短期の数値を追うために、性能、保守性、信頼を損ないません。数か月後にも意味が説明でき、別の担当者が再現できる判断を残します。

• 原則: 余白、文言、Semantic HTML、標準部品で解決してから、特殊な装飾や独自操作を検討します。
• 禁止: 表現のために表示性能、検索性、印刷性、アクセシビリティを下げません。

2.4 哲学を検証可能にする

哲学は、反対意見を封じる合言葉ではありません。規則が目的を守れていないなら、規則を疑う必要があります。

• 必須: 規則には、守る目的、適用範囲、確認方法を持たせます。
• 原則: 良い例と悪い例は外観の好みではなく、利用者が理解・判断・操作できるかで比較します。
• 許容: より上位の目的を守るために原則から外す場合は、期限、責任者、代替策、終了条件を持つ例外として管理できます。
• 禁止: 既存実装を正当化するためだけに、規範を弱めません。

2.5 デザイン思想を日々の判断へ落とす

2.5.1 目的を先に置く

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

2.5.2 思考の負担を減らす

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

2.5.3 判断権を人に残す

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

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

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

2.5.5 静かだが曖昧にしない

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

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

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

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

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

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

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

3. 基本原則（Liberka Core）

適用層: 基本原則（Liberka Core）

3.1 言葉は判断を助ける

読みやすい文章は、短い文章と同義ではありません。読み手が迷わず意味を組み立てられる文章です。

• 必須: 見出しだけを追っても、話の順序と結論が分かるようにします。
• 必須: 操作名は「保存」「削除」「記録を見る」のように、起きることを動詞で表します。
• 原則: 説明は結論、理由、詳細の順に置き、一段落には一つの論点を置きます。
• 原則: 説明文はです・ます調で書きます。短いラベル、表、規範語に続く規則は簡潔な常体を許容します。
• 禁止: 「革新的」「シームレス」「可能性を解き放つ」など、具体的な価値を説明しない語を主文にしません。
• 禁止: 一般的な言葉で説明できる概念へ、独自の造語を追加しません。

良い例: 「チームを削除すると、所属する記録も閲覧できなくなります。」は対象と結果が分かります。

悪い例: 「本当によろしいですか？」だけでは、何が起きるか判断できません。

• 禁止: 機能を説明しない抽象的なAIコピーを使いません。

3.2 情報の確度を見分けられるようにする

• 必須: 事実、推定、例、提案、目標値を、文言と構造で区別します。

• 必須: 必要に応じて出典、基準日、単位、対象範囲、算出方法を示します。

• 必須: AIの提案は未確定であること、編集・採用・拒否できることを示します。

• 禁止: 装飾のための架空データ、顧客、推薦文、効果を事実として示しません。

• 禁止: 利用者の感情や仕事を、点数やランキングだけへ縮減しません。

• 禁止: 実在しない数値、顧客、推薦文、効果、出典を事実として示しません。

内容品質の共通条件

内容の品質は、文字数や図の数ではなく、読み手の問いに根拠を伴って答えられるかで判断します。以下は説明・分析・提案を含む部分に適用し、操作ラベルや目次に論証を強制しません。

• 必須: CQ-01 読み手、理解・判断・行動の目的、前提知識、閲覧方法、対象範囲を整理し、説明の順序・深さ・情報密度を選びます。判断を求める場合は、今回決める事項と未決事項を区別します。
• 必須: CQ-02 判断に影響する主張には追跡可能な根拠を対応させ、根拠から結論に至る理由と成立条件を説明します。未確認事項は明示し、主張を根拠の対象・期間・精度より広げません。
• 必須: CQ-03 比較では評価軸、単位、母数、期間、対象の条件を揃えるか、比較できない違いを明示します。実績と予測、意向と行動、変動と確認できた変化を区別します。
• 必須: CQ-04 提案・選定では必須条件と比較観点を分け、実質的な代替案と不採用理由、重要な弱点・依存条件を説明します。選択肢が指定済みの場合は、その制約を明示し、架空の比較を作りません。
• 必須: CQ-05 要約・見出し・図表に短縮しても、判断を変える留保や反対の証拠を隠しません。根拠が足りない場合は不足と、それによって判断できない範囲を示します。
• 必須: CQ-06 実行を求める提案では、行動、担当、時期、成功の確認方法を示すか、未決の項目を明示します。承認されていない役割や期限を確定事項にしません。
• 必須: CQ-07 説明・分析・提案の重要な用語と指標は、意味、適用範囲、単位・期間・比較基準を揃えます。同義語の使い分けと同じ語の異なる意味を点検し、区別に理由がある場合は明示します。「拡大」「急増」「有効」などの評価語には根拠と成立条件を定め、根拠のない閾値を作りません。
• 禁止: 孫引きされた同じ情報を独立した複数の証拠として数えたり、相関や図の矢印だけで因果関係を断定したりしません。
• 禁止: 必須条件の不合格を総合点で相殺したり、推奨案を勝たせるために比較条件を変えたりしません。

読者と用途に応じた内容設計

• 必須: 読者・目的・前提知識・閲覧方法は、まず会話・資料・利用場面から判断します。重要な仮定と構成の選択理由を必要な範囲で記録し、判断材料がない重大な分岐だけ第12.3節に従って質問します。読者の肩書きだけで知識量や必要な説明を決めません。
• 原則: 意思決定、学習、実行、検証、紹介など、求める理解・行動から構成を選びます。結論先行、提案中心、比較表、詳細な分析は選択可能な型であり、コンサル資料の構成や情報量を一律に適用しません。
• 原則: 情報密度は、必要な情報の充足と理解・参照のしやすさで判断します。投影では話を追える量と視認性、単独閲覧では自足する説明、作業時の参照では検索性と実行順序を重視します。複数用途を兼ねて成立しない場合は本文と補足、投影版と配布版などを分けます。必要な根拠・条件の保持と最小文字寸法は維持します。
• 禁止: 内容品質を情報量や分析項目の多さだけで評価したり、用途に不要な提案・意思決定・結論を型に合わせて作ったりしません。用途への適応を理由に、正確性、用語整合、適用される根拠・論理・留保の条件を弱めません。

状況に応じて選ぶ内容設計の手法

以下は選択可能な手法です。全件実施や不採用の例外申請は要求しません。ただし上記の必須条件は、手法を選ばない理由で解除できません。

分類は同じ問い・抽象度で揃え、因果・部分・時間順序を単なる並列へ変えません。項目数の少なさやMECEという呼称だけを、内容品質の証拠にしません。

3.3 一つの面に一つの中心目的を置く

• 必須: 視覚的な順序と、出力形式が持つ構造上の読み順・読み上げ順を一致させます。

• 必須: 画面、Dialog、スライド、文書ページ、図表には中心となる問いまたは行動を一つ置きます。

• 原則: 複数の目的がある場合は分割するか、主要・補助・詳細の順を明示します。

• 禁止: 余白を埋めるためにCard、図、文章、操作を増やしません。

3.4 色は名前ではなく意味で管理する

• 必須: 通常文字は4.5:1以上、大きな文字と情報理解に必要なUI境界は3:1以上のコントラストを確保します。
• 必須: 色へ文言、形、アイコン、位置の少なくとも一つを併用します。
• 必須: 破壊とエラーは赤系、警告はオレンジ系、通常情報と選択はLiberka greenを使います。
• 禁止: 成果物ごとに同じ意味の色を即興で追加しません。

3.5 見出しは大きさとコントラストで階層を作る

大きい文字ほど明るくする、小さい文字ほど暗くする、といった単純な明度順は使いません。背景との関係、文字サイズ、太さ、余白を合わせて、どこから読むかを決めます。

• 必須: Page Titleは、その面で最も高い文字の視覚的優先度とコントラストを持ちます。

• 必須: 見出しレベルを飛ばさず、見出しだけを読んでも構成を理解できる文言にします。

• 原則: 章見出しにブランド色を使う場合も、Page Titleや本文より弱く見える組合せを避けます。

• 禁止: 色だけで見出し階層を作りません。

• 禁止: 見出しの直前へ、カテゴリ名や雰囲気だけを表す小さな文字のkicker、eyebrow、overlineを反復しません。必要な分類は見出し本文、Breadcrumb、Navigationで示します。

• 禁止: 英大文字の短いLabelをすべての見出しの上へ反復しません。

• 禁止: kicker、eyebrow、overlineとして、小さなカテゴリ名や雰囲気語を見出しの上へ反復しません。

3.6 文字は長く読めることを優先する

• 必須: 書体、文字寸法、行間は対象媒体の規範とtokenから選び、別媒体の本文用設定を機械的に流用しません。

• 必須: 数値比較では桁、単位、小数点を揃え、必要に応じて等幅数字を使います。

• 原則: 日本語本文の字間は0から0.02em、短いラベルも0.04emを超える字間を常用しません。

• 許容: 長文の読み味を改善する書体は、ライセンス、字形、ウェイト、フォールバック、性能を検証した場合に本文だけへ使えます。

• 禁止: 見出し、操作、ブランド名を本文用書体へ機械的に合わせません。

3.7 余白は関係を説明する

余白は空いた場所ではありません。近いものが同じ話題で、遠いものが別の話題だと伝える構造です。

• 必須: 関連するラベルと値は近づけ、異なる判断は広く離します。
• 原則: 構造リズムは12を基準とし、媒体の単位へ変換しても近接、整列、反復、対比を保ちます。
• 原則: 生の値より、役割が分かる意味的な余白tokenを使います。
• 禁止: すべての数値を12の倍数へ丸めるために、16pxの本文、1pxの境界、操作対象の寸法を崩しません。

3.8 境界、角、奥行きは実際の構造を示す

• 原則: 階層は面の明度、全周境界、余白、重なりで示します。

• 原則: Control、Card、Surfaceの角丸は役割ごとに一貫させ、すべてを大きな角丸にしません。

• 許容: Dialog、Popover、Menuなど、実際に別レイヤーへ一時表示するものだけに一段の控えめな影を使えます。

• 禁止: 通常のCard、一覧行、Button、図表へ影、色付きglow、Hover浮上を付けません。

• 禁止: Cardの一辺だけに意味のないアクセント線を置きません。

• 禁止: カードの左縁など、一辺だけにアクセント線を置くside-stripe cardを使いません。

• 禁止: 影だけで階層を示す構成、全Cardの浮上、色付きグローを使いません。

3.9 ロゴとブランド名を混同しない

• 必須: 花形をLiberka共通シンボルとして、brand/liberka.mdの資産と余白規則に従って使います。
• 必須: 公式ロックアップが必要な場所では画像資産を使います。
• 必須: 通常文章中のブランド名は正確にLiberka、Schediaと綴ります。
• 禁止: 任意の書体で「Liberka」や「Schedia」を組み、公式ロゴのように扱いません。
• 禁止: シンボルの変形、回転、縁取り、影、再着色、切り抜き、要素追加を行いません。

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

• 必須: 状態を持つ成果物では、現在の状態、完了したこと、未完了のこと、次にできることを区別します。
• 禁止: 状態が変わったように見せるだけの演出で、実際の結果や未完了の作業を隠しません。

操作状態と読込表示の具体的な設計は第8章で扱います。静的な資料へ操作状態の一覧を機械的に適用しません。

3.11 アクセシビリティは後付けにしない

• 必須: 対象者と利用環境に応じ、読み順、代替説明、識別、理解、必要な操作を最終出力で確認します。

WCAG 2.2 AAを最低目標とします。準拠チェックだけでなく、利用者が実際に目的を達成できるかを確認します。

• 禁止: ブランド表現を理由に、コントラスト、代替テキスト、読み順、操作対象を弱めません。

• 禁止: アクセシビリティまたは情報の正確性を、ブランド表現を理由に下げません。

3.12 AIは責任と確度で示す

• 必須: AI提案、人の確認、確定、実行中、実行済み、失敗を区別します。
• 必須: 外部送信や重要な変更は、実行前に対象、内容、相手、結果を確認できるようにします。
• 必須: AIが利用不能でも、人が確認、編集、実行できる安全な経路を残します。
• 禁止: Sparkles、ロボット、脳、魔法の杖をAIの既定記号にしません。

3.13 ブランド人格と言葉の実務

3.13.1 ブランド人格

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

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

3.13.2 言葉の原則

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

3.13.3 情報の確度

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

4. 視覚基盤

適用層: 基本原則（Liberka Core）

4.1 カラーシステム

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

Liberka Core palette

次の色は、Schediaを含むすべてのLiberka製品が共有するCore tokenです。製品別規則は使い方を限定できますが、同じ意味の値を再定義できません。

必須事項:

• 必須: 破壊的操作とエラーは赤系、警告と注意はオレンジ系で示します。

• 必須: 通常情報、選択、成功は製品プロファイルの主色で示します。

• 必須: 色だけで意味を伝えず、文言、形、アイコン、位置の少なくとも一つを併用します。

• 必須: 通常文字は4.5:1以上、大きな文字と情報理解に必要なUI境界は3:1以上を基準とします。

• 必須: 半透明面、画像、映像、動く背景の上の文字は、最も読みにくい状態で検査します。

• 必須: 印刷、グレースケール、投影、画面共有でも重要な区別を失いません。

• 禁止: 同じ意味役割の色を成果物ごとに即興で追加しません。

• 禁止: 紫から青、紫からピンクのグラデーションを使いません。

• 禁止: グラデーション文字を使いません。

4.2 タイポグラフィ

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

共通原則:

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

具体的な書体・寸法・行間は第6章の対象媒体に置きます。

4.3 余白とグリッド

媒体の単位と出力条件で構造の比率を具体化します。CSS pxを資料へそのまま移植せず、pt、mm、グリッドへ置き換えます。

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の倍数へ丸める規則ではなく、構造上の関係を一貫させる規則です。

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

4.4 角と曲線

角や曲線は、情報のまとまり、境界、関係を示すために使います。媒体が変わっても役割の一貫性を保ちますが、操作部品の寸法を資料の図形へ流用する規則ではありません。

• 原則: すべてを大きな角丸にして柔らかさを演出しません。
• 原則: 大きな輪郭や署名表現でも、クロソイド、サイン曲線、スーパー楕円、調整済みBezier曲線のように、接線と曲率が自然に変化する形を優先します。
• 禁止: 形状のために情報の境界、可読性、必要な操作を失わせません。

Webのradius、corner、fallbackと部品別の適用条件は第6.1節で定めます。

4.5 境界と奥行き

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

• 必須: 階層は、面の明度、全周境界、余白、重なり、背景の抑制で示します。
• 原則: 通常のカード、一覧行、ボタン、図表に影を付けません。
• 許容: モーダル、ポップオーバー、メニューなど、実際に別レイヤーへ一時表示するものだけに一段の控えめな影を使えます。
• 禁止: 複数段の影、色付きグロー、ホバー時の浮上、常時浮く統計カードを使いません。
• 禁止: スライドや文書で、段落や数値を装飾カードへ入れて階層を作りません。

4.6 透明素材とガラス表現

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

必須条件:

• 原則: 文字の直下は安定した明度を保ちます。

• 原則: 不透明なフォールバックを持ちます。

• 原則: 印刷、PDF化、画面共有では不透明面へ変換して情報を保ちます。

• 原則: Reduced Transparencyを利用できる環境では尊重し、それだけに依存しない停止手段も設けます。

• 禁止: 半透明色だけで境界を作りません。

• 禁止: ガラス面の上へさらにガラス面を重ねません。

• 禁止: 全面GlassやGlassの入れ子を使いません。

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

アイコンは、機能や情報の種類を素早く見分け、繰り返す文字を減らすために使います。 「なるべく使う」は識別に役立つ場所で優先する意味であり、すべての文字を絵へ置換する意味ではありません。

アイコンの共通方針

• 原則: 一つの成果物または製品で、線幅、端部、塗りの方針が揃ったアイコン体系を使います。
• 原則: 機能アイコンはLucide公式カタログのoutline体系を第一候補にし、取得元、採用名、版または取得日、ライセンスを制作記録に残します。必要な著作権・許諾表示を保持します。
• 原則: 同じ意味には同じアイコンを対応させ、文字を省略する場合も対象と意味を理解できるようにします。
• 原則: 読み上げでは、装飾による重複を避け、情報を持つ図案には名前や代替説明を用意します。
• 許容: 適切な意味のアイコンがない場合は文字だけにできます。別体系や独自図案が必要なら、意味、取得元、ライセンス、既存体系で表せない理由を所有先のPRに記録します。
• 禁止: 絵文字を機能アイコンとして使いません。

ブランドロゴは公式資産を使います。Webの名前付きimport、SVGの読み上げ属性、アイコンだけの操作、機能見出しへの配置は第6.1節を参照します。スライド・文書の見出しへ操作画面の配置を機械的に持ち込みません。

画像とイラスト

• 原則: 写真とスクリーンショットは実物を使い、架空のブラウザ、端末、IDE枠で飾りません。

• 原則: 画像には目的に応じた代替テキストまたは本文中の説明を付けます。

• 原則: AIをSparkles、ロボット、脳、魔法の杖で一律に表現しません。

• 禁止: 意味のない人物イラスト、3D物体、発光球を余白埋めに使いません。

• 禁止: 発光orb、汎用blob、オーロラ、意味のない3D物体を使いません。

5. 情報構造と構成

適用層: 基本原則（Liberka Core）

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

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

5.2 読む順序

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

5.3 容器の節度

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

• 禁止: すべてをCardへ入れる構成、意味のないCard内Card、均等なBentoグリッドを使いません。

• 禁止: 三列の均等なアイコンCardを、内容上の理由なく使いません。

5.4 密度

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

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

適用層: すべて

12.1 対象と判定

• 必須: 対象成果物、版またはcommit、媒体、主要な利用経路、確認者、確認日、確認環境を記録します。
• 必須: 該当する共通原則、Component、Layout / Flow、製品条件を特定し、それぞれの仕様から確認項目を選びます。
• 必須: 各項目を合格・不合格・未確認・対象外で記録し、対象外には理由を添えます。未確認を合格に含めません。
• 必須: 合格には再現手順、期待結果、実際の結果、証拠を添えます。自動検証と実際の最終出力の確認を区別します。
• 禁止: 必須項目の未確認や不合格が残った状態を受け入れ完了としません。例外は第13.4節に従います。

受け入れ条件と比較観点の区別

受け入れ条件は、適用される規範と利用者の要件を、対象成果物で確認できる形に具体化したものです。チェックリストは条件の正本ではなく、出典、適用理由、確認方法、結果を残す記録です。第1.2節の規範語の強さを維持し、禁止事項は「禁止された状態がないこと」として確認します。原則から外す場合は第13.4節の例外管理へ接続し、単に対象外とはしません。

理解の速さ、操作の負担、情報の比較しやすさ、保守性などの比較観点は、要件に照らして案を選ぶために使います。明示された要件に測定可能な下限がある場合は受け入れ条件へも記録します。比較の高評価で、規範違反や必須条件の不合格を相殺しません。

設計中の想定と最終出力での実測は区別します。最終確認が未実施の案を制作対象として選ぶことは、受け入れ完了を意味しません。未確認項目と確認計画を引き継ぎます。

12.2 確認範囲

12.3 実施と記録

• 必須: 制作前に共通規範・媒体・製品・使用部品から必須条件と禁止事項を列挙し、制作後は同じ項目を最終成果物で確認します。

• 必須: 最終判定では禁止事項を独立して再点検し、不適合を修正した後に影響範囲を再検査します。検査後に変更した成果物へ以前の合格を流用しません。

• 必須: 自動検査の合格は、その検査が実際に観測した対象・状態・範囲に限定します。意味・事実・読み順・未操作状態の確認を自動検査で代替しません。

• 必須: Webは第9章の代表幅、200%拡大、400%相当の再配置、Reduced Motion、forced-colorsと、使用Componentの必要状態を確認します。

• 必須: 性能へ影響する変更では、同じ端末・通信・データ条件で変更前後を比較し、測定値と採用した性能予算を記録します。予算や比較結果が未定なら合格にしません。

• 必須: 最終出力の確認には、実際に配布または公開する版を使用します。

• 原則: 受け入れ記録テンプレートを使い、仕様本文を別のチェックリストへ複製しません。

情報の充足確認と自律的な進行

• 必須: 制作前と監査で情報不足を見つけた際は、既存の会話・提供資料・適用規範を確認し、調査で補える情報と利用者の判断が必要な情報を分けます。情報の充足確認は質問の実施を意味しません。
• 必須: 未確認の事実・数値・社内決定を仮定で確定させません。重要な分岐の回答待ちや根拠不足が解消しない部分は未確定の草稿とし、沈黙を同意と扱いません。自律的な進行は、公開・破壊的操作等に必要な権限や承認を代替しません。
• 原則: 通常の編集・構成・実装は自律的に進めます。質問は「回答によって結論・構成・適用範囲が大きく変わる」かつ「既存情報や調査では判断できない」重大な分岐に絞ります。既に示された意図や決定を聞き直さず、影響が小さく容易に修正できる選択は合理的な仮定で進めます。結果に影響する仮定だけを簡潔に明示します。
• 原則: 質問が必要なら、何が変わるかと推奨案・理由を示し、関連する重要な質問をまとめます。回答待ちも依存しない作業を進めます。先に試作を求められた場合は、未確定部分を区別した試作で具体化できます。

内容検査の判定境界

監査回数が明示された場合は、対象版・観点・指摘・修正・再確認証拠を巡ごとに記録して履行します。同じ自動検査の再実行やチェック項目数は監査巡数に数えません。自己監査と独立したレビュー、実際の読者による確認を区別します。回数を満たしても必須違反・未確認は解消したことになりません。

必須かどうかと、自動判定できるかどうかは別の軸です。CQ・SL-C・DOC-Cの適用条件ごとに、確認対象、根拠、判定を記録します。

• 必須: 自動検査で警告された候補は、該当箇所を確認して修正または適用しない理由を記録します。警告の件数だけで不合格にせず、警告なしを内容合格にしません。
• 必須: 根拠の十分性・正確さ、推論の妥当性、比較の公平性、重要な反証、要約による意味の保持は内容レビューで確認します。AIの評価だけを事実確認の証拠にしません。

制作前原稿と監査・改善ループ

• 必須: 文書・スライドの原稿を短縮、分割、並べ替え、図表化する場合は、重要な成立条件・未決事項・根拠の掲載先を追跡し、編集後の実文と照合します。情報の存在だけで意味の保持を合格にしません。各候補の構成変更を原稿の関係・参照へ反映します。

• 原則: 全量制作の前に、実際の文言と固定の枠、図表、注記、出典を用いた代表的な難しいページで構成を試します。収まらない場合は原稿と分割を見直し、文字の縮小や重要な条件の削除で済ませません。代表ページの確認を最終出力全体の確認へ代用しません。

• 必須: 文書・スライドは、全体構成、用語・指標、制作前原稿、内容監査、制作、最終出力監査の順に進めます。全体構成では各単位が目的にどう寄与するか、前提・理由・具体化・比較・反証・結論などの関係を確かめます。隣接しているだけの項目を論理的につながっていると扱いません。

• 必須: 内容監査では、全体の問いへの回答、根拠から主張への推論、単位間の重複・欠落・矛盾、用語・数値・留保の一貫性、読み手が理解・判断できる順序を別々の観点で確認します。最終出力では原稿との意味の一致と実際の表示を確認します。

• 必須: 指摘には対象と版、該当条件、問題と読み手への影響、修正内容、再確認範囲、再確認の証拠と結果を残します。根拠不足は調査、論理の欠落は構成、表現の問題は原稿または制作へ戻し、修正後に再監査します。反証や未確認事項を削除して合格にしません。

• 必須: 用語定義の変更は全使用箇所、結論の変更は要約・根拠・提案、数値や図表の変更は参照箇所へ影響をたどり、該当する判定を再開します。原稿から出力を再生成し、影響部分を確認するまで以前の合格を流用しません。

• 必須: 完了は監査回数ではなく、適用される必須条件の不合格・未確認がなく、重要な不整合が解消し、変更の影響範囲が再確認されていることで判断します。情報・手段が不足する場合は残件を明示した草稿とします。AI同士の合意や自己採点の反復は根拠の検証を代替しません。

• 許容: 記録は作業規模に応じて簡潔にまとめられます。固定の監査回数、別担当者、毎段階の利用者承認を要求しません。任意の改善提案と必須違反を分離し、任意の改善を無限に続ける条件にしません。

原稿を批評してから変換する

• 必須: 文書・スライドの本制作前に、内容・論理・視覚表現・背景演出・読者の理解の各観点から、採用案を崩しうる最も強い指摘とその根拠を記録します。修正または維持の判断と理由を示し、修正が必要な指摘は原稿へ戻し、影響範囲を再確認します。攻撃的な検討は案に向け、人への侮辱には向けません。
• 必須: 原稿には実文・根拠・前後関係に加え、視覚表現の検索候補と不採用理由、背景、読む順序、強調、情報密度の理由、素材の対応を記録します。代表ページは現行原稿の入力から試作し、その検討を経て全量変換へ進めます。
• 禁止: 観点別チェック件数を改稿回数や独立レビュー人数と呼びません。原稿版、指摘、実際の変更、再確認を分け、同じ案への賛成を重ねて品質を証明したことにしません。利用者が回数を指定しても、回数によって未解決条件を解除しません。
• 必須: 本制作への変換で主要な文言・論理・構図を選び直す必要が出た場合は、原稿を未確定へ戻して修正・再監査します。最終描画の検査は省略せず、一度の生成で必ず完成することを保証しません。

メッセージと主図を同時に設計する

• 必須: 文書・スライドの本文を確定する前に、各内容単位について読者の作業、図から読み取る答え、視覚で説明する内容と残す本文・補足へ移す内容を決めます。視覚中心の場合は主図と補助素材を実際の原稿nodeへ結び付け、文字中心の場合はその適用理由を記録します。表紙・扉は内容単位と分けて扱います。
• 必須: 原稿監査では、図の有無とは別に、配置・長さ・包含・接続等が何を伝えるか、図と本文が同じ説明を重ねていないか、図がなくても同じ文章一覧のままではないかを確認します。主図の説明機能をアイコン・ハイライト・月桂冠だけで満たしたとしません。図へ移した重要な条件を消しません。
• 必須: 資料全体で、文章中心の単位、同じ表現の連続、説明を担わない装飾への偏りを確認し、変更または維持の根拠を原稿へ戻します。固定の図数・文字数・画像比率は合格条件とせず、記録の充足と意味・見た目の妥当性を別々に判定します。