qt-ui-design

Qt UI デザイン

UI を出力する前に、対象プラットフォーム、画面形状、デザインシステム、コンテンツの優先度、画面を見る距離、ロケール、入力方法を把握していることを確認します。以下の 7 項目を確認事項として、会話とプロジェクトの状態を照合し、本当に不足している項目だけを質問します。ユーザーが回答できない項目については、妥当な Qt のデフォルトを選び、ユーザーが修正できるよう、回答の中でその内容を明示します。

既存デザインへの小さな変更（例：「OK ボタンを右に移動」「このラベルを変更」「赤色にする」）では、チェックリストを適用しません。セクション 1 を黙って適用し、該当する場合はセクション 2（コントラスト、タップ対象）を確認します。

0. コンテキストの確認（デザインの前に）

以下の 7 項目を使って、すでに分かっていることと、質問すべきことを判断します。会話またはリポジトリですでに回答されている項目は、再度質問しないでください。

1. 対象プラットフォーム — デスクトップ、Web ブラウザー、モバイル、または特定のハードウェア（MCU、Raspberry Pi、その他の組み込みボード）ですか？
   • 特定のボードの場合：そのボード専用のスキルがあるかを尋ね、存在する場合は読み込みます。
2. 画面形状 — 長方形（デフォルト）、正方形、または円形ですか？
3. 解像度と DPI — 画面の解像度と DPI は分かりますか？（おおよそで構いません。）
4. デザインシステム — プロジェクトですでにデザインシステムまたは Qt Quick Controls のスタイルが使われているか確認します。使われている場合は、それに従い、トークンを再利用します。使われていない場合は、Qt Quick Controls のスタイルとして Basic、Fusion、Imagine、Material、Universal、iOS、FluentWinUI3 を推奨します（iOS と FluentWinUI3 のスタイルには Qt 6.7 以降が必要です）。プロジェクトがサードパーティのデザイン言語（Material Design 3、Apple Human Interface Guidelines、Fluent 2）に準拠している場合は、独自のトークン体系を新たに導入せず、そのトークンを対応する Qt Quick Controls のスタイルに割り当てます。
5. コンテンツの優先度 — この画面で最も重要な情報（主要）、次に重要な情報（二次）、それ以外の情報（三次）は何ですか？
6. 画面を見る距離 — ユーザーは画面からどのくらい離れた位置で使いますか？（例：手持ちで約 30 cm、デスクで約 60 cm、パネルで約 1.5 m、壁面で約 3 m）
7. ロケールと入力 — 主なロケール／言語は何ですか？RTL（アラビア語、ヘブライ語、ペルシア語、ウルドゥー語）への対応は必要ですか？対応すべき入力方法（タッチ、キーボード、マウス／ポインター、ハードウェアボタン、音声）は何ですか？ 対象が組み込みデバイスまたは MCU の場合は、デザインを決定する前にセクション 4も全文読んでください。セクション 4 は、デスクトップ向けのデフォルト設定の一部より優先されます。

ユーザーが既存デザインの監査を依頼している場合は、セクション 5（監査）に進みます。

---

1. 適用する設計原則（すべてのターゲット）

設計時には以下を適用してください。各項目について質問せず、判断にあたって黙って考慮してください。

コンテンツとレイアウト：

• 黄金比＋三分割法： 主要な要素を視覚的な交点に配置します。
• プログレッシブディスクロージャー： 現在のステップで必要なものだけを表示します。
• 逆ピラミッド： 重要な情報を先に示し、その後に詳しい説明を加えます。
• モジュール化： 複雑なフローを、小さく自己完結した画面に分割します。
• オッカムの剃刀： 2つのデザインが同等であれば、よりシンプルなものを選びます。
• パフォーマンス負荷： ステップが少ないほど、タスクの完了率が高くなります。
• ファイブ・ハット・ラック： カテゴリー、時間、場所、アルファベット、連続性のいずれかに沿って整理します。 知覚とインタラクション：
• ヤコブの法則： ユーザーがすでに知っているパターンに合わせます。
• アフォーダンス： コントロールは、その機能を見た目で伝えるようにします。
• ヒックの法則： 選択肢が多いほど、判断に時間がかかります。画面ごとの選択肢を絞ります。
• マジックナンバー7： ワーキングメモリーが保持できるのは約7項目です。それに合わせて情報を区切ります。
• 想起より認識： 選択肢を表示し、記憶を求めないようにします。
• 近接性＋類似性： 関連する要素を視覚的にまとめます。
• 一様な連結性： 共通の枠線や色は、同じグループであることを示します。
• フォン・レストルフ効果： 視覚的に異なる要素を1つ置くと注目を集めます。控えめに使います。
• ピーク・エンドの法則： ユーザーの記憶に残るのは、体験のピークと終わりです。完了状態（インストーラーの終了画面など）は、唐突ではなく、達成感を得られるように設計します。
• ドハティの閾値： 400 ms 以内にシステムからフィードバックを返すか、進行状況を示すインジケーターを表示します。
• 美的ユーザビリティ効果： 洗練されたデザインは、使いやすいと認識されます。
• ウェイファインディング： ユーザーが現在地、これまでの経路、次に進める場所を常に把握できるようにします。 読み取りパターン（情報の配置に活用）：
• F字型： テキスト量の多いコンテンツでは、上部バー、より短いセカンダリバー、左端のスキャンを意識します。
• Z字型： コンテンツが少ない場合は、左上 → 右上 → 対角線上 → 右下の順を意識します。
• レイヤーケーキ型： ユーザーは見出しをスキャンし、本文を読み飛ばします。
• スポット型： ユーザーはリンク、大文字、リスト項目などの目印に飛びます。 ボタンと CTA：
• グループごとの CTA ボタンの数を制限します。「OK」＋「キャンセル」は1つのグループです。追加のアクションは視覚的に目立たないようにします。
• 近接性と類似性を使って、主要、セカンダリ、ターシャリのコントロールを区別します。 エラー防止：
• 正しい使い方を促すアフォーダンスを設計します。
• 技術的に可能な限り、元に戻せるようにします。
• 破壊的または取り消せない操作の前に確認を求めます。
• 危険な状態を知らせる警告やプロンプトを追加します。 レスポンシブ対応（デスクトップ／ウェブのみ。組み込みについてはセクション 4 を参照）：
• まず主要ターゲットの解像度に合わせて設計します。デスクトップではブラウザーのクロームを含め、組み込みでは固定解像度を使い、アプリケーションで一般的なウィンドウのリサイズ範囲も考慮します。幅が狭くなったら、コンテンツを積み重ねる、折りたたむ、またはセカンダリコンテンツを非表示にします。
• レイアウトの最小幅：240 px。これを下回る場合は、要素を積み重ねるか折りたたみます。
• スペースが限られている場合は、セカンダリ機能をメニューやドロップダウンの中に隠します。

1.1 モーションとアニメーション（デスクトップ／Web — 組み込み：セクション 4 を参照）

モーションは状態、関係性、因果関係を伝えます。すべてのアニメーションは装飾ではなく、機能を持たせる必要があります。

• 表示アニメーション： 減速イージング（開始は速く、終了は遅く）を使用します。要素は突然現れるのではなく、到着したように見える必要があります。
• 非表示アニメーション： 加速イージング（開始は遅く、終了は速く）を使用します。要素は消えるのではなく、離れていくように見える必要があります。
• 直接操作へのフィードバック： 100 ms 以内に応答します。1 秒を超える操作では進行状況インジケーターを表示し、10 秒を超える操作では推定時間を表示する必要があります。
• 再生時間の目安： 小さな要素（アイコン、バッジ）：100～150 ms。中程度の要素（カード、パネル）：200～300 ms。全画面の切り替え：300～400 ms。UI アニメーションは 500 ms を超えないようにします。遅すぎると動作が壊れているように感じられます。
• 同時にアニメーションさせる要素は 1 つか 2 つまでにします。画面全体を一度にアニメーションさせると、ユーザーが混乱します。
• QML／CSS では transform と opacity のみを アニメーションさせます。これらは GPU で合成されます。ジオメトリ（幅、高さ、アンカー）のアニメーションはレイアウトの再計算を引き起こし、カクつきの原因になります。
• モーションを減らすユーザー設定を尊重します。 Web では、必須ではないアニメーションを prefers-reduced-motion CSS メディアクエリで制御します。Qt 6.x には標準の同等機能がありません。プロジェクトレベルの設定（たとえば、QSettings または実行時のアクセシビリティオプションにバインドされたシングルトンプロパティ）を用意し、それに基づいてアニメーションを制御します。ユーザーが無効にした場合は、アニメーションを即時切り替えに置き換えます。単に速度を落とすだけにしてはいけません。
• 空間的一貫性： 画面間を移動する要素は、移動先に合った方向にアニメーションさせます（LTR レイアウトでは、前に進むときは左にスライドし、戻るときは右にスライドします）。

1.2 タイポグラフィのスケール（デスクトップ／Web）

組み込みのタイポグラフィについては、セクション 4.4 を参照してください。このサブセクションは、デスクトップと Web のターゲットのみを対象とします。

モジュラースケールを使って、すべての文字サイズを決めます。 モジュラースケールとは、一定の比率で関連付けられた数値の並びです。各サイズはほかのすべてのサイズと数学的に比例し、恣意的ではなく調和の取れたスケールを生み出します。比率を以下に示します。対話型ジェネレーターについては https://www.modularscale.com/ も参照してください。

スケールの作り方

1. 基準サイズを選びます — 対象の視聴距離で本文が最も読みやすく見えるサイズです。デスクトップでは、約 60 cm の距離を想定した場合、16 px が信頼できる開始点です。この基準サイズが ms(0) になります。
2. 比率を選びます — 基準サイズにこの比率を掛けると 1 段階大きくなり、割ると 1 段階小さくなります。製品の特性に合わせて選びます。

比率	名称	係数	特性
8:9	長二度	1.125	コンパクトで高密度 — データ量の多い UI、インストーラーのフローに適しています
5:6	短三度	1.200	中程度 — 一般的なデスクトップアプリに適しています
4:5	長三度	1.250	ゆとりがあり快適 — マーケティング、オンボーディングに適しています
3:4	完全四度	1.333	強いコントラスト — ダッシュボード、明確な階層表現に適しています
1:1.618	黄金比	1.618	高いコントラスト — 控えめに使用してください。段階間の差が大きくなります

3. スケールの段階を役割に割り当てます — 各タイポグラフィの役割に段階番号を割り当てます。スケールにない役割を追加してはいけません。必要なサイズがある場合は、最も近い段階を選びます。

例（基準サイズ 16 px、完全四度 1.333）

ms()	値（px、四捨五入）	役割
ms(3)	37.9 → 38 px	ディスプレイ／ヒーローテキスト
ms(2)	28.4 → 28 px	ページタイトル／H1
ms(1)	21.3 → 21 px	セクション見出し／H2
ms(0)	16 px	本文 — 基準サイズ
ms(-1)	12.0 → 12 px	キャプション／ラベル／メタデータ

1 画面で使用する段階は、最大でも3～4 段階にします。4 種類を超えるサイズを同時に使うと、視覚的なノイズが生まれます。

すべてのモジュラースケールに適用されるルール

• 本文（ms(0)）の最小サイズは、デスクトップでの閲覧距離（約60 cm）で16 pxです。 主な読書コンテンツには、ms(-1)以下のサイズを決して使用しないでください。
• 行の高さ： 本文は1.4～1.6倍、見出しは1.1～1.2倍にします（見出しは行間を狭くできます）。
• 行の長さ： 読みやすさのため、1行あたり45～75文字にします。テキストコンテナーにはmax-widthを使用し、文章がビューポート全体に広がらないようにしてください。
• ウェイトの組み合わせ： 本文とキャプションにはレギュラー（400）、見出しにはミディアム（500）を使用します。本文中ではボールド（700）を決して使用しないでください。
• まずシステムフォントを使用します。 デフォルトではOS／プラットフォームのシステムフォントを使用してください（WindowsではSegoe UI Variable、macOSではSF Pro、Android／LinuxではRoboto）。カスタムフォントを導入するのは、ブランド要件があり、それに対応するFigmaトークンが存在する場合に限ります。
• システムの「大」フォントサイズで確認します。 OSのフォントスケールを無視するピクセル値をハードコードしないでください。Qtでは、本文にfont.pixelSizeを使用するより、プラットフォームのDPIスケールを反映するfont.pointSizeを優先するか、Screen.pixelDensityに基づくシングルトンからサイズを算出してください。ウェブでは相対単位（rem）を使用します。

Qt/QML の実装

QMLでは、スケールをシングルトン（例：TypeScale.qml）として定義し、ハードコードした値ではなく、役割名でサイズを参照できるようにします。

// TypeScale.qml — generated from modular scale, base 16, ratio 1.333
pragma Singleton
import QtQuick

QtObject {
    readonly property real base:    16   // ms(0)
    readonly property real h2:      21   // ms(1)
    readonly property real h1:      28   // ms(2)
    readonly property real display: 38   // ms(3)
    readonly property real caption: 12   // ms(-1)
}

コンポーネントではTypeScale.h1を参照してください。ベース値または比率を変更する場合は、シングルトン全体を再計算してください。個別の値だけを変更しないでください。

インポートできるよう、QMLモジュールにシングルトンを登録します。qmldirファイルでは、次のようにします。

module MyApp.Theme
singleton TypeScale 1.0 TypeScale.qml

qt_add_qml_moduleを使用するCMakeでは、次のようにします。

qt_add_qml_module(myapp_theme
    URI MyApp.Theme
    VERSION 1.0
    QML_FILES TypeScale.qml
)
set_source_files_properties(TypeScale.qml PROPERTIES QT_QML_SINGLETON_TYPE TRUE)

1.3 複数の入力方法とキーボード操作（デスクトップ／ウェブ）

すべてのデスクトップおよびウェブインターフェースで、複数の入力方法をサポートする必要があります。ポインターだけを前提に設計しないでください。

• キーボードだけで完全に操作できることが必須です。 Tabキーの移動順序は、視覚的な読み順（LTRでは左上から右下）に従う必要があります。フォーカスインジケーターは常に表示してください。QMLでは、activeFocusに連動させる（例：activeFocusにバインドしたRectangleの枠線やスケールを使う）か、Controlでスタイル固有のフォーカス表示を使用します。ウェブでは、代わりのスタイルを用意せずにフォーカスリングを削除しないでください。
• キーボード操作を妨げるトラップを作らないでください。 キーボードで操作するユーザーが、Escapeキーまたはキーボードで操作できる閉じるコントロールを使って、モーダル、ポップオーバー、オーバーレイから常に抜け出せるようにしてください。
• すべてのインタラクティブ要素は、ポインター、キーボード、そしてQtのアクセシビリティAPIで公開されている場合はスクリーンリーダーから操作できなければなりません。これは推奨事項ではなく、必須要件です。
• ホバー状態は機能の拡張であり、情報を示す主な手段ではありません。 ホバー時に表示される情報は、ポインターがなくても利用できるようにしてください（例：常時表示されるラベル、専用の情報ボタン、キーボードで呼び出すツールチップ）。
• タッチとポインターの両方を利用できるようにしてください。 スタイラスまたはポインターにも対応するタッチデバイスでは、ポインターを検出してもタッチ対象を削除しないでください。

1.4 セマンティックカラー

色はインターフェース全体で一貫して意味を伝えるようにします。根拠のない色の選択は避けてください。

• 生の16進数値ではなく、役割ベースのトークンを使用します。 トークン名には、色の見た目（blue、dark-blue、grey-2）ではなく、その色の役割（interactive、surface、on-surface、error、outline）を表す名前を付けます。上記の役割の語彙は Material Design 3 に準拠しています。プロジェクトのデザイン言語が Fluent 2 または Apple Human Interface Guidelines の場合は、語彙を混在させず、それぞれのシステムで対応する役割名に置き換えてください。プロジェクトに Figma のトークンセットがある場合は、トークンを抽出するツールが利用可能になるまで、手作業でシングルトンにコピーしてください。
• onカラーに関するQMLの命名上の注意点。 トークンをQMLプロパティにする際、onSurface や onPrimary のように、on + 大文字で始まる名前はQMLのシグナルハンドラー構文と衝突します。また、対応するベーストークン（surface、primary）が同じオブジェクト内で宣言されると、読み込み時に「Cannot assign a value to a signal」というエラーが発生します。これは、Materialのonカラーが必要とする組み合わせそのものです。QMLプロパティ名は（textOnSurface、surfaceForeground などに）変更してください。
• インタラクティブな色と装飾的な色を区別します。 ボタンに使って「タップできる」と示す色を、操作を促さない背景のアクセントにも使ってはいけません。インタラクティブな色を装飾目的で使い回すと、タップできないものまでタップするようユーザーに誤って学習させてしまいます。
• 状態を色だけで伝えてはいけません。 セクション2（WCAG）ですでに取り上げていますが、これは無効状態以外にも同様に当てはまります。成功、警告、エラーは、必ず色とアイコンまたはテキストラベルを組み合わせて示してください。
• ダークモード： ライトテーマとダークテーマの両方に、最初から対応するよう設計してください。トークンベースの色システムなら自動的に対応できます。ハードコードされた色を使用する場合は、ダークモード用の色を明示的に定義する必要があります。
• 文化によって異なる色の意味（§1.5も参照）：西洋文化では赤は危険を示しますが、東アジアの一部では幸運を示します。西洋文化では白は純粋さを示しますが、東アジアの一部では喪を示します。安全性が重要な製品や、国際的に提供する製品では、重要な意味を色だけに頼って伝えないでください。必ずテキストまたは普遍的なアイコンと組み合わせてください。

1.5 ローカライズとRTLレイアウト

インテークの質問7を確認し、ここでその回答を反映してください。

• 日付、時刻、数値の形式はロケールに対応させる必要があります。DD/MM/YYYY のような形式文字列をハードコードしてはいけません。Qtの QLocale またはプラットフォームのロケールAPIを使用してください。
• RTLレイアウトのミラーリング： アラビア語、ヘブライ語、ペルシア語、ウルドゥー語では、レイアウト全体を水平方向に反転します。ナビゲーションは右から左へ移動し、戻るボタンは右を指します。方向を示すアイコン（矢印、シェブロン、再生コントロール）は反転させる必要があります。シーンのルート付近で LayoutMirroring.enabled と LayoutMirroring.childrenInherit: true を有効にしてください。アンカーとQt Quick Layoutsはこれで処理できます。LayoutMirroring を有効にしても、次の項目には個別の対応が必要です。Text.horizontalAlignment のデフォルト値、Image のコンテンツ（方向を示すアイコンには mirror: true を使用）、カスタムの Canvas 描画、手動で指定する x 位置。
• テキストの拡張： 翻訳後の文字列は、原文の英語より通常30〜40％長くなります。コンテナーやボタンは文字列が長くなっても収まるように設計し、ユーザーに表示する文字列には固定幅のコンテナーを避けてください。
• アイコン： 文化に特有のものや、地域によって意味が異なるもの（親指を立てるジェスチャーや、特定の手のジェスチャーなど）は避けてください。普遍的なシンボル（成功を示すチェックマーク、閉じることを示すX、検索を示す虫眼鏡）を優先してください。
• 画像やアイコンにテキストを埋め込まないでください。 ローカライズでは、すべてのテキストを文字列リソースに含める必要があります。アセットに焼き込まれたテキストは翻訳できません。

---

2. アクセシビリティ（WCAG 2.2）

納品前に、すべてのデザインが以下を満たしているか確認してください。

• 知覚可能であること： すべての情報に、視覚以外で確認できる同等の手段（代替テキスト、ラベル）があること。コントラスト比は、テキストで 4.5:1 以上、大きなテキストと UI コンポーネントで 3:1 以上にします。
• 操作可能であること： キーボードだけで完全に操作でき、フォーカストラップがないこと。ポインターを使わずに、すべてのインタラクティブな要素に到達できること。
• 理解可能であること： ラベル、説明、エラーメッセージには平易な言葉を使うこと。
• 堅牢であること： マークアップと構造が、スクリーンリーダーや支援ツールで機能すること。
• 状態を伝える際に色だけに頼らないでください。必ず形状、アイコン、またはテキストを組み合わせてください。
• OS のフォントサイズを「大」に設定してテストしてください — テキストを拡大しても、レイアウトでテキストが切れたり、はみ出したりしないことを確認します。
• 色覚異常のシミュレーションでテストしてください（最も一般的なのは 2 型色覚です）— 色がなくても、すべての状態変化を区別できることを確認します。
• フォーカス順序を検証してください — すべてのインタラクティブな要素を Tab キーで順に移動し、その順序が論理的であることを確認します。フォーカスは常に視認できる必要があります — Qt 側のフォーカスインジケーターのパターンについては §1.3 を参照してください。

---

3. AI 固有の UX

AI 機能を含む画面を設計する際は、次の点に注意してください。

• ユーザーによる制御： ユーザーが AI の動作を開始、停止、変更できるようにします。必ず「元に戻す」または「再生成」を用意してください。
• 透明性： AI の判断がユーザーに影響する場合は、その判断理由を示します。
• 適切な失敗時対応： AI が失敗した場合は、明確な手動の代替手段を提示します。
• 目新しさより価値： AI 機能は実際の問題を解決するものでなければなりません。デモ目的で存在させないでください。
• 不確実性の伝達： AI の出力は確率的です。信頼度が低い場合や、結果が誤っている可能性がある場合は、その旨を示してください。控えめな表現（「提案です」「おおよその値です」「使用前に確認してください」）、視覚的な信頼度インジケーター、または明示的なラベルを使用します。確率的な出力を、権威ある事実として提示しないでください。Qt AI Assistant などの機能では、重大な判断に影響する回答について、「ソースを表示」または「理由を確認」の操作手段を用意してください。
• 遅延への対応パターン： AI の処理には通常 1〜15 秒かかります。汎用的なスピナーは表示しないでください。スピナーでは所要時間を推定できず、約 3 秒後にはユーザーが不安になるためです。
  • ストリーミング出力（テキスト生成）：部分的な結果をすぐに表示し始めます。生成中は、挿入位置に点滅するカーソルまたは脈動するインジケーターを表示します。
  • 長時間の処理（コード生成、画像処理）：予想される結果の形状に合ったスケルトン画面またはプレースホルダーを表示します。これにより注意を引きつけ、期待値を設定できます。
  • バックグラウンド処理（インデックス作成、分析）：操作を妨げるモーダルではなく、控えめで常時表示されるステータスインジケーター（ステータスバーのプログレスバー、ツールバーのアニメーションアイコンなど）で示します。
  • AI の応答を待つ間、画面全体を空白にしないでください。
• 操作前の同意： AI 機能がユーザーデータ（ファイル、コード、設定）を読み取る、送信する、または変更する場合は、操作の実行前にそのことを明示します。「提案の生成にプロジェクトファイルを読み取ります」といった 1 行の確認で十分です。モーダルダイアログにする必要はありません。

---

4. 組み込みおよび MCU ターゲット

このセクションはデスクトップの既定のルールに優先します。組み込み、MCU、またはハードウェアに制約のあるターゲット向けに設計する前に、最後まで読んでください。

すべての判断に影響するハードウェアの情報（未回答の場合は、上記の事前確認ステップで収集してください）：

• 物理ピクセル寸法と DPI
• GPU の有無。不明な場合は、ないものとします。
• UI アセットに利用できる RAM とフラッシュメモリ
• 入力方法：タッチスクリーン、ハードウェアボタン、ロータリーエンコーダー、ポインター
• ボード固有のスキルがあるかどうか

4.1 GPU を使わないレンダリング

ソフトウェアラスタライズでは、視覚効果の処理に CPU 時間がかかります。

許可	不可
単色のベタ塗り	グラデーション
1 px の単色の線	ドロップシャドウ
ビットマップ（PNG）のアイコンとフォント	ぼかしや透明度レイヤー
不透明度のみのトランジション	移動とフェードを同時に行うアニメーション
固定ピクセルレイアウト	Flexbox や可変レイアウト

ベクターパスよりもビットマップアイコンを優先してください。ラスタライズのコストは実行時ではなく、コンパイル時に発生します。GPU が搭載されていることを確認できた場合に限り、これらの制約を緩和してください。 例外。 上記の制約は、実行時のソフトウェアラスタライズに適用されます。Qt Quick Ultralite は、静的レンダリングパイプラインを通じて、コンパイル時に焼き込まれるグラデーションをサポートしています。一部の MCU には、ぼかしや透明度を禁止する制約を緩和できる 2D ブリッターや小型 GPU が搭載されています。この表を絶対的な禁止事項として扱う前に、ハードウェアのデータシートと使用中の Qt ツールチェーンを確認してください。

4.2 レイアウト

• 固定ピクセルレイアウトにします。可変グリッドやブレークポイントは使いません。画面の正確な寸法に合わせて設計してください。
• 1 画面につき 1 つのタスクにします。パネルを重ねないでください。
• フラットなナビゲーションにします。画面間を移動し、画面内では移動しません。階層は最大 2 レベルにします。
• システム状態（接続済み、エラー、アクティブなモード）は常に表示します。ツールチップやホバー状態は使いません。

4.3 インタラクション

• ホバー状態は使いません。ホバーをきっかけに表示する情報は、明示的なボタンまたは専用画面に置き換えてください。
• タッチ領域の最小サイズは通常 48 px です。固定グリップの医療機器やセキュリティが確保された産業用パネルなど、管理された環境では、安全性を明示的に確認したうえで、より小さな領域が妥当な場合があります。手袋を着用する環境（産業用、屋外）では 60～72 px にします。
• すべての操作には、ハードウェアボタンによる代替手段が必要です。タッチ操作のみのアクションは使いません。
• ハードウェアでサポートされていることが確認できない限り、ドラッグ、スクロールの慣性、マルチタッチは使いません。
• 物理アクチュエーターを制御する操作の前には、必ず確認を求めます。

4.4 タイポグラフィ

組み込みフォントはビットマップであり、サイズはビルド時に固定されます。最初から適切なサイズにしてください。

視認距離	最小サイズ
約 50 cm（ハンドヘルド機器、家電製品）	最小 14 px、推奨 16 px
約 1.0～1.5 m（HMI、インストルメントクラスター）	最小 20 px
約 2～3 m（壁面パネル、公共ディスプレイ）	最小 28 px

すべてのテキストでコントラスト比を 4.5:1 以上にします。組み込み画面は視野角が狭く、周囲が明るいことも多いため、コントラストは高いほど適しています。

4.5 エラーと安全性

• 取り消せない物理アクチュエーターのコマンドを実行する前には、必ず確認を求めます。これは安全要件です。
• エラー状態のインジケーターは、アプリケーションの状態に基づいて持続的に表示します。一時的な UI 状態に基づいてはいけません。画面の再描画後も表示され続ける必要があります。
• アラームには、色、形状、テキストの 3 つの独立した手掛かりが必要です。
• アプリケーションがクラッシュした場合や通信が失われた場合に UI が戻る、安全なデフォルト画面を定義してください。
• サイレントエラーは許容しません。確認されていないハードウェアコマンドは、目に見える形で表示する必要があります。

4.6 デスクトップから MCU へのクイックリファレンス

ルール	デスクトップ／Web	MCU／組み込み
レスポンシブ対応	Flexbox、可変レイアウト	固定ピクセルレイアウト
アニメーション	イージング曲線、≤ 400 ms	不透明度のみ、< 200 ms
段階的な情報開示	ツールチップ、ホバー	明示的なボタンのみ
タッチ領域	44 px を推奨	48 px が標準（安全性を明示的に確認した場合のみ緩和）
フォントの描画	ベクター、OS による拡大縮小	ビットマップ、ビルド時に固定
状態の伝達	色＋トークンベース	色＋形状＋テキスト
エラーからの復旧	元に戻す	操作前に確認
状態の可視性	ステータスバー／ツールチップ	常に画面上に表示
ナビゲーションの階層	無制限	最大 2 レベル
ローカライズ	QLocale、RTL ミラーリング	QLocale のみ（RTL はほとんど該当しない）

---

5. 監査の指示

既存のデザインを監査する際は、すべての指摘事項を次のように分類します。

1. Critical — UX の基本原則または WCAG のアクセシビリティルールに違反しています。必ず修正してください。
2. Warning — 摩擦や認知負荷の増大につながる可能性があります。修正してください。
3. Opportunity — 改善または AI による機能強化の機会です。検討してください。 対象が組み込み型の場合は、まずセクション 4 の制約を適用してください。

デスクトップ／Web を対象とする場合の拡張監査チェックリスト：

• モーション：アニメーションは 400 ms 以下で、機能的なものになっていますか？ また、動きを減らすための手段はありますか？
• タイポグラフィ：本文のテキストは 16 px 以上で、画面ごとに使用する文字サイズは 3 種類以内ですか？
• キーボード：すべてのインタラクティブ要素に、キーボードのみでアクセスして操作できますか？
• 色：すべての色はトークンに基づいているか、意味のある名前が付いていますか？ すべての状態変化に、色以外の手掛かりも組み合わせていますか？
• ローカライズ：ユーザーに表示されるすべての文字列で、ロケールに応じた書式設定が使われていますか？ 翻訳後のテキストに合わせて、コンテナーを 30～40% 拡張できますか？
• AI 機能：セクション 3 に従って、レイテンシーへの対応、不確実性の伝達、同意の取得を行っていますか？

---

6. 参考資料

• Nielsen Norman Group — ユーザビリティの 10 のヒューリスティック：https://www.nngroup.com/articles/ten-usability-heuristics/
• Laws of UX：https://lawsofux.com/
• WCAG 2.2：https://www.w3.org/TR/WCAG22/
• モジュラースケール計算ツール：https://www.modularscale.com/
• Apple Human Interface Guidelines：https://developer.apple.com/design/human-interface-guidelines
• Microsoft Fluent 2 Design Principles：https://fluent2.microsoft.design/design-principles
• Google Material Design 3 Foundations：https://m3.material.io/foundations
• Qt QLocale（ローカライズ API）：https://doc.qt.io/qt-6/qlocale.html
• Qt LayoutMirroring（RTL）：https://doc.qt.io/qt-6/qml-qtquick-layoutmirroring.html