ux-inputs-and-forms

入力とフォームのスキル

このスキルの動作 (最初にお読みください)

これは生成型のスキルです。よくある失敗パターンは次のとおりです: 過剰な質問 (役に立つかもしれないすべてのフィールドを、すべて必須にする)、誤ったラベリング (プレースホルダーをラベルとして使う、専門用語、任意であることが示されていないフィールド)、遅すぎる検証 (送信時にモーダルでエラーをまとめて表示する)。解決策は「すべてのフォームパターンを適用する」ことではありません。ヘルパーテキスト、ツールチップ、プログレスバー、多段階分割をどこにでも入れると、肥大化したフォームになります。そこでこのスキルでは次のようにゲートします:

1. コンテキストを確立する — そのフォームが何を収集するのか、各フィールドがなぜ必要なのか、プラットフォーム、長さ。
2. 常に当てはまる核心を適用する — 最小限のフィールド、ざっと見渡せる1列レイアウト、常時表示されるラベル、フィールドごとに適した入力タイプ、インライン検証。
3. コンテキストに依存する判断 (多段階、フローティングラベル、ヘルパーテキスト、ピッカー、スマートデフォルト) をトレードオフとともに明示する。

その後、検証のために ux-heuristics-audit、ux-accessibility-audit、ux-aesthetics-audit、ux-microcopy-audit、ux-dark-patterns-audit に引き継ぎます。

---

ステップ0 — 設計する前にコンテキストを確立する

不明な場合は質問してください。回答なしで進める場合は前提を明示してください:

• 各フィールドは何をもたらすのか? すべてのフィールドについて、そのデータを誰が何のために使うのかを明確にします。答えのないフィールドは削除します — フォーム設計で最も効果の高い判断です。
• プラットフォーム — モバイルでは文脈に応じたキーパッド、38px以上のタッチ領域、スクロール中も視界にとどまる送信ボタン、片手で届く範囲が求められます。
• 長さと重要度 — 3フィールドのニュースレター登録と複数ページのチェックアウトでは、必要な構造 (ステップ、進捗、エラーサマリー) が異なります。
• 機微性 — 電話番号、支払い情報、ID: ユーザーは「なぜこれが必要なのか?」と尋ねます — 正当化の説明 (ヘルパーテキスト) を計画し、タスクの要件を超えるものにはダークパターンの精査が及ぶことを想定してください。

---

常に適用する核心 (ほぼすべてのケースで正しい)

尋ねることを減らす

• タスクに必要のないフィールドはすべて削除します。 短いフォームほど完了率が高くなります。システムは、検出できる情報やすでに知っている情報を尋ねるべきではありません (既知のデータは自動入力し、ブラウザのオートコンプリートをサポートし、国/ロケールを自動検出する)。
• 必須フィールドと任意フィールドの両方を明示します — 必須にはアスタリスク (LTRではラベルの前。淡いグレーにしない)、任意にはラベルに「(任意)」を付けます。
  • ❌ 必須フィールドが10個、説明なし ✅ フィールドが5個、1つに「(任意)」の表示、機微なフィールドにはヘルパーテキスト

ざっと見渡せるレイアウト

• 1列、上から下へ。 複数列のフォームは、フィールドの飛ばし読み、誤ったフィールドへの入力、離脱を引き起こします (Baymard)。自然な読み取りの流れが勝ります。
• ラベルは入力欄の上に、入力欄の外側に、常に表示。 プレースホルダーをラベルとして決して使わないでください: フォーカス時に消え、記憶に負担をかけ、入力済みのデータのように見えます。プレースホルダーは例の値のみを示し、目に見えて控えめにします。
• 関連するフィールドをグループ化する (個人 / 請求 / 配送) には見出しと余白を使います — 近接性が構造を作ります: ラベルとその入力欄の間隔 < 入力欄と次のフィールドの間隔、グループ間の余白 > グループ内の余白。
• 入力境界を可視化する — 枠線のない「ミニマル」な入力欄は、ユーザーにどこに入力すべきかを探させます。入力欄の高さは約32〜40px、テキストは16px以上、ラベルは約13〜14px、伝統的で抑制の効いたスタイルにします。

データに応じて入力タイプを選ぶ

• 短い回答には1行、文章には複数行/テキストエリア、パスワードには表示/非表示の切り替え、検索には自動候補表示、選択/ドロップダウンは長いリストにのみ — 約5件までならラジオボタン (単一選択) またはチェックボックス (複数選択) を使います。入力マスクは形式が重要なあらゆる箇所 (電話、日付、カード) に — ユーザーがどのように入力しても受け付け、こちらで整形します。モバイルでは文脈に応じたキーパッド (数字には数値パッド)、貼り付けと自動入力をサポートするOTP入力。
• 日付フィールド: ピッカーをタスクに合わせます — 既知の日付 (生年月日) にはテキスト入力 + マスク、近い将来の予定 (予約) にはカレンダーピッカー。

インラインで、親切に検証する

• 検証は blur 時に行い、キーストロークごとでも送信時でもない。 ユーザーに入力を終えさせ、フォーカスがフィールドを離れたときにチェックします。(例外: 新しいパスワードのリアルタイム要件チェックリスト。)
• エラーメッセージは誤った入力のそばに配置する(右側またはすぐ下 — 決して上部だけにしない)、平易で丁寧、具体的な表現で: 何が起きたか + どう直すか、理想的には 1 行、決して切り詰めない。色 + アイコン + テキスト — 色だけに頼らない。
• エラー状態は入力が実際に有効になるまで表示し続ける、ユーザーが入力を始めた時点で消さない。
• 訂正する前に防ぐ: 制約、寛容なフォーマット、マスクはエラーメッセージに勝ります。

送信はフォームの一部です

• 主要ボタンは常に視界に(フィールドの下。長いモバイルフォームでは固定)、アクションを表すラベルを付ける — ユーザーの文「〜したい」を完成させます: ❌「送信」 ✅「購読する」 / 「注文を確定する」 / 「アカウントを作成する」。
• ボタンの階層: 主要ボタンは視覚的に優勢。 「キャンセル」/「戻る」は控えめ。 誤ったボタンを誤って押せないよう十分な間隔を空ける。 タッチターゲットは ≥1×1cm (約 38px 以上)。
• 3 つの状態をすべて表示する: 送信後のローディング、明確な成功メッセージ、そして丁寧で情報量のある失敗メッセージ(セキュリティに配慮: どの認証情報が間違っていたかを明かさない)。

---

文脈依存の判断 (自動適用せず、提示する)

それぞれをトレードオフと、Step 0 に結びついた推奨とともに提示します。 これらすべてを 4 フィールドのフォームに適用するのは、肥大化という失敗モードです。

判断	適用するとき	避ける / 適応させるとき	既定の推奨
マルチステップ + 進捗トラッカー	論理的なステップが 3 つ以上(チェックアウト、アンケート)。各ページを消化しやすく保つ	短いフォーム — 分割はクリックを増やす。5〜6 ステップを超えると圧倒する	グループ化だけでは機能しなくなるまで 1 ページ
フローティングラベル	ラベル + 例を 1 つのスロットに収めたいスペースの厳しいレイアウト	永続的なラベルのほうが安全な、複雑 / ほとんど使われないフォーム	入力の上に静的ラベル。フローティングラベルはスペース節約のバリエーションとして
ヘルパーテキスト	機密フィールド(「なぜ電話番号が必要ですか?」)、微妙な要件(パスワード規則)	「念のため」すべてのフィールド — シグナルを埋もれさせるノイズ	ユーザーが予測可能にためらう場所のみ。最大 1 行
ガイダンス用のアイコン / ツールチップ	視覚的な疑問(CVV の場所)で、言葉より画像が勝る場合	モバイルでのツールチップのみのヘルプ(余分なタップ、当てにならないホバー)	まずアイコン。ツールチップは補足であり、唯一の伝達手段ではない
オートサジェスト / インクリメンタル検索	長いオプションリスト(国)。一致した文字を太字にする	ラジオ / チェックボックスのほうが速い短いリスト	ユーザーがスクロールしなければならないようなリストにはオートサジェスト
スマートデフォルト / 自動検出	国を地理検出、既知のデータをプリフィル — アクションを減らす	ユーザーが選んだ選択に見えるデフォルト(同意、マーケティングのオプトイン — ダークパターンの領域)	事実はプリフィルするが、判断は決してプリフィルしない
単一のフルネームフィールド	摩擦を減らす。文化を超えてより包括的	製品が姓名を確実に分割しなければならない	データモデルが本当に 2 つを必要としない限り、名前フィールドは 1 つ
上部のエラーサマリー	複数のエラーが画面外になる可能性がある長いフォーム。各項目はそのフィールドにリンクする	短いフォーム — インラインメッセージで十分	常にインライン。長いフォームにはサマリーを追加
CAPTCHA / 検証	悪用が現実。アクセシブルな代替(マジックリンク、OTP、パスキー)を優先	歪んだテキストの CAPTCHA。パスワードフィールドでの貼り付けブロック	リスクベースでアクセシブルな検証。貼り付けは決してブロックしない
左側のラベル	垂直スペースが乏しい極端に長いデスクトップフォーム	モバイル、ラベルの長さが混在する場合、レスポンシブなもの全般	入力の上にラベル

---

結果を検証する（オーケストレーション）

ハンドオフでは、各レンズをインストール可能なスキルの name で指定します。そのスキルがインストールされている場合にのみ呼び出してください。インストールされていない場合でも、このスキル自体のコアにこれらのルールがすでに含まれているため、ブロックせずにそのまま進めてください。

生成または修正を行った後は、完了と宣言するのではなく、結果を監査レンズに引き渡してください。これらは候補のレンズです。姿勢は docs/orchestration-policy.md で設定するか、全体を ux-design-review 経由でルーティングしてください。ここでは、heuristics、microcopy、dark-patterns はティア A（自動実行）、accessibility、aesthetics、mobile-responsiveness はティア B（提案） です。既存のデザインシステムがある場合、aesthetics は抑制され、accessibility は使用状況に絞り込まれます。mobile-responsiveness はモバイルの場合にのみ適用されます。ユーザーがこのスキルを特定の目的で呼び出した場合は、そのスコープを尊重してください。

• ux-heuristics-audit (ティア A) — システム状態の可視性（状態、読み込み中、成功）、エラーの予防、ユーザーの制御、想起よりも認識。
• ux-accessibility-audit (ティア B — 提案。デザインシステムがある場合は絞り込み) — キーボード操作とフォーカスインジケーター、ラベル／コントラストの最小値、aria-describedby によるエラーの関連付け、複数の手がかりによるエラー状態、アクセシブルな認証。
• ux-aesthetics-audit (ティア B — 提案。デザインシステムがある場合は抑制) — 余白のリズム、グループ化の明確さ、「ミニマル」なスタイルによって入力のアフォーダンスが損なわれていないか。
• ux-microcopy-audit (ティア A) — ラベルの明確さ、ヘルパーテキストの簡潔さ、エラーメッセージのトーンと具体性、アクションボタンの文言。
• ux-dark-patterns-audit (ティア A) — 個人データの過剰な収集、事前チェック済みのオプトイン、紛らわしいデフォルト、任意であるべき必須フィールド。
• ux-mobile-responsiveness-audit (ティア B — 提案。モバイルの場合にのみ適用) — コンテキストがモバイルの場合：キーパッド、タッチ領域、固定された送信ボタン、片手でのリーチ。

監査で競合が表面化した場合（例：マーケティングはより多くのフィールドを望むが、完了率は下がる）、主要なタスクに立ち返って解決してください。ユーザーは何かを完了するために来ているのです。すべてのフィールドと中断は、そのコストに見合うものでなければなりません。

---

よくある do/don't パターン

❌ しない	✅ する
いつか役立つかもしれないすべてを尋ねる	すべてのフィールドを、誰がそのデータをなぜ使うかによって正当化する
プレースホルダーテキストを唯一のラベルにする	入力欄の上に常時表示されるラベル。プレースホルダーはあくまで例
「スペース節約」のための 2 列のフィールドグリッド	1 列、論理的なグループ、自然な読み取りの流れ
3 択の選択にドロップダウン	ラジオボタン（単一）／チェックボックス（複数）で約 5 択以下
厳密な入力形式を強制する（「ハイフン禁止！」）	寛容な形式 + ユーザーのために整形する入力マスク
すべてのキーストロークで、または送信時のみ検証する	ブラー時に検証。リアルタイムのチェックリストはパスワード作成時のみ
フィールド番号を列挙した上部のエラーモーダル	エラーのある入力欄に、具体的で丁寧なメッセージ（+ 長いフォームの場合のみ概要）
すべてに汎用的な「送信」	文脈に応じたアクションラベル：「アカウントを作成」「注文を確定」
フィードバックのない送信	読み込み中 → 成功／失敗の状態を常に表示
「スマートなデフォルト」としての事前チェック済みマーケティングオプトイン	事実は事前入力するが、意思決定は決してしない（→ dark-patterns）
確認せずに出荷	heuristics + accessibility + aesthetics + microcopy + dark-patterns に引き渡す

---

出典レッスン（Uxcel）

• How to Design Forms in UIs
• Best Practices for Designing Forms
• Types of UI Inputs & When to Use Them
• Best Practices for Designing UI Inputs
• Best Practices for Styling UI Inputs
• Submitting a Form
• Showing Input Error
• Forms Accessibility