ux-design git:20261002.c0e127dA

Immutable. This exact content never changes and is served at /api/v1/blob/75f0a12e152f4581.

---
name: ux-design
description: 設計の実体。業務構造の診断(中心対象・最頻操作・主役と隠すもの・触りたさ・装飾除去テスト)から体験の規律(デフォルト効果・認知負荷・楽さとミス防止・一括操作・下書き保存・正直なUI・エラー回復・データを消さない・ホーム情報設計・知覚パフォーマンス・行動科学の道具箱)と検収までを1冊で持つ。React hooks は assets/ux-patterns.tsx。機能設計/画面フロー/フォーム設計/UX改善/レビュー/「AIっぽい」指摘の対応で必ず参照する。見た目の素材は Skill jp-web-design。
---

# 体験設計(UX)の規律 — 「安心してポチポチ」を仕組みにする

実開発(物件マッチング台帳ほか)の発注者フィードバックから抽出した、どのアプリにも移植できる体験設計のルール集。

**核となる方法論: 体験の理想を感情の言葉で定義し(「安心してポチポチ押せる」「認知負荷を減らしながら」)、それを満たす仕組みを逆算する。** 感情語は一見矛盾を含む(楽に・でも安全に)。その矛盾を両立させる構造を作るのがUX設計の仕事。

本書は中核ルールと判断基準だけを載せる。入力フォーム・一括操作・行動科学の対応表など実装の具体パターンは `references/` に分割してある(索引は末尾の §15)。**該当する作業に入る前に必ず開く。**

## 0. 設計を始める前に内部で確定する3点

1. **最頻シナリオは何か**(1日◯回・一度に◯件) — 体験はこの現実の量を前提に設計する。
2. **絶対に起きてはいけないミスは何か**(重複・誤送信・データ汚染・情報漏れ) — 「注意」ではなく仕組みで防ぐ対象。
3. **ユーザーがアプリを閉じる瞬間、何と感じていれば成功か** — 感情語で書く。これが検収基準になる。

この3点は依頼者への質問票ではない。依頼文・既存画面・データ量・操作ログ・業務資料から推定し、**推奨案を1つ**に絞って代表画面または動くフローへ反映する。業務の「理屈」まで掘り、機能要望の裏にある業界ルールを設計ルールへ変換する。依頼者には成果物への差分だけを求める。

### 0-1. 業務構造を発見する(テンプレートから始めない)

> AIっぽいUIは、UI部品の平均値を並べた画面。AIっぽくないUIは、業務の構造がそのまま画面の構造になっている。

「AIっぽさ」は制作手段ではなく、**設計判断(何を最優先に見せるか・何を隠すか・何を隣に置くか・どこを固定するか・どの操作を一手で終わらせるか・エラー時にどこへ戻すか)が見えるか**の問題。扱う対象を先に決めてから画面を考える。各問いは「はい/いいえ」で終わらせず、**答えを1行の言葉にして残す**(`assets/structure-worksheet.md` を複製して記入。言葉にできない項目は、まだ判断していないという合図)。

- [ ] この画面でユーザーが実際に手を動かして扱う**中心的な対象(名詞)**は何か(「案件」「注文」「申請」など、機能名ではなく業務上の名詞)。
- [ ] その対象を1日/1回の作業で**何件・何回**扱うか。件数や頻度で一覧向きか・単票向きか・比較向きかが変わる。数を把握せずに形式を決めていないか。
- [ ] **最頻の操作**は何か。上位3つを具体的な動詞で言えるか(「確認する」ではなく「担当者を変更する」)。
- [ ] その最頻操作のうち、**現状ページ遷移やモーダルを経由しないと完了しないもの**はどれか。一手で終わらせられないか検討したか。
- [ ] この画面の**主役**(最大の面積・最初に視線が行く場所)は「ユーザーが今から扱う対象」か。装飾的な集計や紹介文になっていないか。
- [ ] 数値やグラフを置くなら、それは**次に取るべき行動に接続しているか**(「見て終わり」の数字になっていないか)。

新規画面・リニューアルは必ずここから始め、既存画面を参考にする場合も参考先の構造を輸入せず、この画面の業務構造で問い直す。§2-3(主役と隠すもの)と §11-1(操作感)は並行して検討してよいが、**この節の答え(中心対象・最頻操作)を先に確定させる**。対象が定まらないまま装飾を判断しても軸がない。画面の型(一覧・単票・分析・操作感)による重心の違いは `references/structure-diagnosis-by-domain.md`。

## 1. デフォルト効果 — 最初から正解を選んでおく(最重要)

最初から選ばれている選択肢はそのまま採用されやすい。これを入力の手間削減に使う。

- **最頻パターンは選択済みで提示する**(例: 条件フォームは「首都圏 × 一棟マンション」が選択済み、提案メールは優先物件がチェック済み)。
- **文脈から推定する**: ユーザー・顧客の既知データからデフォルトを導く(名刺の住所 → 「地元(◯◯県)」を自動推定)。
- 賢いデフォルトの3条件: **①統計的または文脈的に最も確からしい ②いつでも変更できる ③何が選ばれているか見える**。
- **安全の非対称**: 時間節約系(絞り込み・並び順・よくある選択)はON がデフォルト。**課金・送信・削除・公開に関わるものはOFF がデフォルト**(安全側に倒す)。
- デフォルトの責任: そのまま Enter を連打されても壊れない・恥をかかない値であること。
- 誘導は正直に。事業者に都合のよいだけのデフォルト・confirmshaming・ダークパターンは禁止。

## 2. 認知負荷の最小化

**前提: 画面は「表を書く」ところから始めない。** どの情報を消し・束ね・大きくし・加工し・どの器に載せるかを決める8工程(場面の1文 → ラベル剥がし → **伝わらないものだけ最小限に補う** → グループ化 → 優先順位 → 表示用加工 → 表示形式の導出 → 機能と意味づけの装飾)を先に通す。手順は jp-web-design `references/information-design.md`(表示形式は事例から選ばず6判断軸で導出。前例のない要件は同 §9 の自己拡張手順で解く)。**認知負荷の大半は、装飾ではなく情報の並べ方で決まる。**

- **1画面1目的**。判断は一度に1つ。複数の判断が必要ならステップに分ける。
- 選択肢は7個まで。多いときは**2層にする: 「よくある選択肢のワンタッププリセット + その他(全リスト)」**(例: エリア選択の最上段に「東京23区 / 首都圏 / 関西圏 / 地元」、その下に全国リスト)。
- **業界の肌感覚を単位にする**(不動産は東京23区を「区単位」で考える等)。システム都合の分類で選ばせない。
- **段階的開示**: 詳細・根拠・上級設定は折りたたみ。最初の画面は「次の1歩」だけを見せる。
- **認識 > 想起**: 前回の選択・入力済みの値・履歴を見せて選ばせる。ゼロから思い出させない。

### 2-1. モバイルの情報削減(狭い画面では「縮小」ではなく「削減」)

SPで全情報を小さくして詰め込まない。**削る優先順位を情報設計として決める**:

1. **第一階層は原則3項目に絞る**: 一覧の1行/1カードは「名前・キー数値・状態」まで。残りは詳細画面へ送る。突合・比較・入力で超過する方が早い場合は、場面と超過理由を標準の `docs/product/T2-experience-spec.md`(プロジェクトに同等責務の既存正本がある場合はその正本)に残し、表など一覧性の高い形式を選ぶ(テーブル→カード化の実装は jp-web-design `references/layout-responsive.md` §3)。
2. **第2階層はトグルで畳む**: 根拠・履歴・上級設定は `<details>`/アコーディオン。開く前から「開けば何があるか」がラベルで分かること。
3. **上位N件+すべて見る**: SPの一覧は要対応・直近の3〜5件だけ初期表示。
4. **KPIは主要1〜3個**: ダッシュボードの数字はSPでは意思決定に使うものだけ残す。
5. 何を削るかは「最頻シナリオ(§0)で使うか」で決める。使わない情報から畳む。飾りの統計は最初から置かない。

### 2-2. 現在地と退避先は常に見える(固定ヘッダー・固定フッター)

長い一覧を延々とスクロールしながら入力する画面では、**いま自分がどこにいるか(ステップ・タブ・対象期間)と、どこへ退避できるか(保存・戻る・次へ)が常に見えていること**が作業の安心感を決める。見えないと、利用者は保存できているか確かめるためだけに毎回スクロールで往復する。

1. **現在地は固定ヘッダーに、主要アクションは固定フッターに**置く。スクロール量に関係なく到達できること。
2. 固定ヘッダー・固定フッターは**共通レイアウト部品として1箇所に実装**する。画面ごとに同じ `position: sticky` を書き散らさない(実装は jp-web-design `references/layout-responsive.md` §6)。
3. **縦幅の狭い環境で本文が潰れないこと**、**キーボード操作でフォーカスが固定要素の下に隠れないこと**を必ず実測する(Tabで最終行まで送って確認する)。
4. **該当する全画面にMECEに適用する**。適用した画面/適用不要と判断した画面とその理由を残す(1画面だけ違う挙動になるのが最も混乱する)。

### 2-3. 何を主役にし、何を隠すか判断する

判断が見えるUIとは、要素の強さに差がある状態のこと。**差がなければ、それは判断していないのと同じ。**

- [ ] 画面内のすべての箱(カード・パネル・枠線)について、**なぜその境界が必要か**を言えるか。余白のグルーピングだけで意味が伝わるなら、枠は要らない。
- [ ] 角丸・影・色の強さといった装飾的な性質を、**同じ画面内のすべての部品に均一に適用していないか**。押せるもの・選択できるもの・状態を表すものに、意味の違いとして形の違いを与えているか。
- [ ] 視覚的な強さ(サイズ・コントラスト・余白・配置)を**画面全体で一様にしていないか**。すべてを目立たせると、何も目立たなくなる。
- [ ] 比較・走査・判断など、**行うタスクの種類ごとに情報密度を変えたか**(比較する場所は密に、確認・編集する場所は余白を多めに)。
- [ ] 頻繁に使う操作を、ホバーやメニューの奥に**隠しすぎていないか**。「見た目の静けさ」と「操作の発見可能性」を混同していないか。
- [ ] ラベルや見出しの文言は、**この業務で実際に使われる言葉**になっているか(抽象的な体験語ではなく、具体的な業務動作の言葉か)。

## 3. 楽さとミス防止はセット(片方だけで設計しない)

「楽に」とだけ設計すればデータが汚れ、「安全に」とだけ設計すれば面倒になる。**必ず両方を同時に入れる。**

| 楽にする仕掛け | 対になるミス防止 |
|---|---|
| 実物からの自動抽出・プレフィル | 自動入力は「(要確認)」ラベル付き、承認して確定 |
| 一括登録・一括処理 | 必須欠落は「要入力」ハイライトで**対象から自動除外**(揃った分だけ進む) |
| 1クリック送信 | 送信前にその場で内容(文面・添付)を確認できる |
| 自由入力の受け入れ(全角・カンマ) | 入口で正規化、不正値はサーバー側でも拒否 |
| 重複チェックを意識させない | 同一キー(メール等)の二重登録は**サーバー側で拒否** |

- **摩擦の非対称性**: 可逆で頻繁な操作=ゼロ摩擦。不可逆・対外的な操作(送信・削除・課金・公開)=**意図的な摩擦1回**(内容が見える確認)。確認を2回3回に増やさない — 形骸化する。
- **ポカヨケ**: 人の注意力に頼らず、そもそも間違えられない構造にする(不正データは入口で弾く、危険な組み合わせは選べなくする)。

## 4. 入力は「書かせる」より「確認させる」

- 実物(PDF・写真・名刺・CSV)を投げたら、**抽出済み・記入済みの状態で提示**する。人の仕事は入力ではなく確認と修正。
- 読み取れなかった項目は**空欄 + 「要入力」**で正直に示す。推測で勝手に埋めない(静かなデータ汚染が最悪)。
- 精度とコストは利用頻度・データ機微度・予算根拠から推奨値を1つ選び、初期値として実装する。課金開始や自動承認など本人の同意が必要な操作だけ、費用と成果物を見せて確認する。
- 必須項目は業務の生命線だけに絞る(連絡がつかなくなるメール等)。「あったら便利」を必須にしない。
- 全角→半角の自動正規化・カンマ許容・`inputMode` 指定。ユーザーの入力癖に合わせる(直させない)。

フォーム実装時に必ず開く詳細(下書き自動保存/IME・送信トリガ/動作とデザインの一致/自動計算値の扱い/一覧入力の視線移動)は **`references/input-patterns.md`**(§4-1〜4-5)。

## 5. 一括操作は「安心してポチポチ」の4点セット

1. **賢い事前選択** — 優先度の高い対象がチェック済み(§1)。
2. **実行前のその場確認** — 何が送られる/変わるのかを一覧・プレビューで見せる。
3. **実行は1クリック** — 確認済みなら手数を増やさない。
4. **結果は項目ごとに表示** — 成功◯件・失敗◯件と、失敗した個々の理由。

- **部分成功の設計**: 全滅させない。成功分は先へ進め、失敗分は「要確認」キューに隔離して後で個別対応できるようにする。
- **量に耐える**: 「何十件」の現実量を前提に、待ち行列 + 進捗表示(「3/24件目を処理中」)。

一覧・アップローダ・自動化を実装するときに必ず開く詳細(一括選択の標準装備/複数ファイル並行処理/省略とチェックの両立)は **`references/bulk-operations.md`**(§5-1〜5-3)。

## 6. 正直なUI

- **できなかったことを隠さない**: 「13項目を自動入力しました(要確認)」「読み取れませんでした。手入力してください」。ここを誤魔化すと静かにデータが汚れる。
- **結果は説明可能に**: マッチング・判定・集計は決定的なルール(フィルター・条件式)で行い、「なぜこの結果か」を言える状態にする。説明できないブラックボックスをAI任せで作らない。
- **無言の読み取り専用・無言の空表示を作らない**: 編集できない一覧には「なぜ編集できないか」を1行で出す。値が空・ゼロで並ぶときは理由を1つ名指しし、解決する画面への導線を添える。理由のない灰色の画面は「不具合」として報告される(実装の落とし穴と検証方法は app-excellence `references/data-lifecycle.md` §2)。
- 自動処理には人間の確認経路を必ず残す(自動承認は明示的なオプトイン)。
- 費用・利用量が発生する機能は**見える化**する(誰が・いくら使ったかのダッシュボード)。
- 偽の数字・偽の緊急性・煽りは禁止。表示する数字はすべて実際の計算結果。

## 7. エラーは回復の起点

- エラー表示は「**何が起きたか + 次に何をすればいいか**」。ユーザーの入力は絶対に消さない。
- 「対応できません」で終わらせない。失敗した**実物のファイル・データ**で原因を特定し、直し、**その実物で成功するまで**検証する。
- 一度直した問題は、その実物を自動テストに固定して再発を封じる。
- 復旧経路を用意する: 失敗した項目は再試行・手動入力・スキップのいずれかへ必ず進める(行き止まりを作らない)。

## 8. データのライフサイクル — 消さない

- 業務データは削除せず**ステータスで制御**する(成約 → レコメンド対象から外すだけ)。過去の記録は将来の資産(売主は次の買主になる)。
- 削除機能を求められたら、まず非表示・アーカイブ・ステータス変更で満たす可逆案を実装または差分提示する。物理削除だけが要件を満たす場合に限り、対象・バックアップ・復元不可範囲を示して実行承認を得る。
- 原本(アップロードされたPDF・画像)は加工後も必ずストックする。抽出結果だけ残して原本を捨てない。
- **取り込んだ値を人の手修正で上書きしない**(別枠で保持し、「取込値に戻す」を成立させる)。再取込のたびに手修正が消える設計は、消えたことにすら気づけない。定期取込・マスタ・締め処理がある案件は app-excellence `references/data-lifecycle.md` を併読する。

## 9. ホーム画面の情報設計

「何を最初に見せるか」は機能一覧からではなく、**業務の1日**から決める。

1. **いま要対応のもの**(要確認キュー・未処理・失敗) — 放置されると業務が止まるもの。
2. **次の主要アクション**(登録する・作成する) — 最頻の入口を1タップで。
3. **最近の動き**(直近の登録・更新) — 続きから再開できる。
4. **キー数字**(状況が一目で分かる集計) — 飾りの統計は置かない。

- タイトル・アプリ名・メニュー名は「**いつ使うか**」が分かる言葉にする(機能名より場面名)。

## 10. トレードオフは内部比較し、1案を実装する

コストvs品質、セキュリティvs手軽さのような判断は、目的適合・根拠・安全と可逆性・一貫性・複雑性で内部比較し、最有力の1案を実装する。

- 採用案、決め手、却下した主要案を各1行だけ判断記録へ残す。無難な折衷案にはしない。
- 可逆な選択は成果物を先に作り、利用者からは違う箇所だけを受け取る。
- 課金、公開、個人情報の取扱い、不可逆操作など本人しか決められない境界は、推奨と成果物/dry-runを先に示して1回だけ確認する。

## 11. 操作感と知覚パフォーマンス

- 操作への反応は**100ms以内**(押下フィードバック)。1秒を超える処理は進捗を見せる(スケルトン・バー・件数)。
- 待たせるときは「何をしているか」を出す(「PDFを解析中…」)。凍った画面が最も不安を生む。ある対象の処理待ちが画面全体をブロックしていないか。処理は対象の近くに閉じ込める。
- **楽観的更新は可逆な操作だけ**。不可逆(送信・課金・公開)は完了確認後に反映する。
- 読み込みはスピナーよりスケルトン(レイアウトが跳ねない)。具体実装は jp-web-design `references/components.md` §7。
- hoverは「押せる候補」、pressed/focusは「いま操作している対象」、入場は「追加された場所」、progressは「処理の継続」を伝える。動きは状態変化・位置関係・因果を伝えるためだけに使い、装飾のための跳ねる・浮く・フェードを理由なく反復しない(装飾の動きだけをオフにしても機能が失われないこと)。時間・CSS・reduced-motionの正本は jp-web-design `references/motion-a11y.md`。
- 「パッと出る」入場は追加された対象だけへ使い、既存の一覧全体や再レンダーのたびに再生しない。長いstaggerは作業開始を遅らせるため、最大6要素・全体300ms以内。

### 11-1. 触りたさの5要素(操作感の診断)

見た目の秩序だけでは「触りたい」UIにならない。**触りたさ = 操作できる手掛かり × 結果の予測可能性 × 即応性 × 可逆性 × 操作による効果**。Apple の Human Interface Guidelines / Fluid Interfaces が繰り返し重視する軸で、レビュー時に最も低い要素から着手する(背景の考え方は `references/apple-polish.md`)。

- [ ] **操作可能性が形と状態で伝わるか**: 押せる・選べる・ドラッグできる・スクロールできる、を試す前に見た目から判断できるか(hover/focus/pressed/selected を個別に設計したか)。
- [ ] **結果が予測できるか**: 同じ見た目の要素は、画面のどこにあっても同じ結果を返すか。
- [ ] **反応が即座か**: 完了後ではなく操作を始めた瞬間に反応が返るか(上の100ms・進捗表示)。
- [ ] **止めたり戻したりできるか**: 途中で中断・キャンセル・方向転換ができ、誤操作から復帰(Undo・確定前キャンセル)できるか(§3 摩擦の非対称性、§7)。
- [ ] **一手の効果が大きいか**: 1回の操作(フィルタ・一括変更・インライン編集)がまとまった仕事を進めるか。1件ごとに複数ページを往復させていないか(§5)。

## 12. 行動科学の道具箱(アプリへの落とし込み方まで)

出典系譜: Laws of UX(Yablonski)/ NN/g 10ユーザビリティ原則(Nielsen)/『誰のためのデザイン?』(Norman)/『実践 行動経済学』(Thaler & Sunstein)。**全テクニックに倫理ガードが掛かる: ユーザーの目標達成を速く・安全にするためだけに使う。事業者に都合のよい誘導・ダークパターンは禁止。**

道具ごとの原理とアプリでの実装対応表(A. 判断を速くする/B. 操作を軽くする/C. 感情を設計する、計18項目)は **`references/behavioral-toolbox.md`**。新しいテクニックを導入するときは「①どの原理か ②ユーザーの何が速く/安全になるか ③ダークパターン化していないか」の3点を言えること。言えなければ入れない。

## 13. 検収チェックリスト(UX)

### 13-1. 装飾除去テスト(実装が一区切りついたら必ず)

- [ ] 色・カード・影・角丸を**すべて外して**見たとき、何が重要で、どこから見ればよいかが、配置・余白・順序・サイズだけで伝わるか。
- [ ] 画面をぼかして(縮小して)見たとき、**主作業領域が一つに見えるか**。
- [ ] この画面が何をするための画面か、**30秒以内に説明できるか**。
- [ ] 選択中・編集中・保存中・失敗・権限不足・空・読み込み中といった**通常状態以外**が、通常状態と同じ精度で設計されているか。
- [ ] 一つでも崩れる項目があれば、**装飾で整理されているように見せているだけ**。§0-1 / §2-3 に戻って構造から作り直す(装飾の調整では直らない)。崩れ方ごとの戻り先は `references/structure-diagnosis-by-domain.md` 末尾。

### 13-2. 体験の検収

- [ ] 最頻シナリオが最少手数で一巡できるか(**実物のデータを使って自分で通す**。サンプルで済ませない)。
- [ ] 各画面が「使われる場面の1文」から設計されているか。情報がグループ化・優先順位付け・表示用加工を経ているか(jp-web-design `references/information-design.md` §2)。
- [ ] 表示形式を6判断軸から導出し、却下した候補と決め手が1行で言えるか。実件数(0件/1件/最大)で破綻しないか。
- [ ] 画像は識別/証拠/説明/装飾に分類され、装飾だけの画像は原則削除されているか。採用画像は alt・必要なキャプション・焦点を守るトリミングを持ち、375/768/1280/1600pxの4幅で検収したか。
- [ ] 操作の手順を説明文で補っていないか(説明を消してもタスクが完了できる形になっているか)。
- [ ] よくある選択がデフォルトで選択済みか。課金・送信・削除系はOFFがデフォルトか。
- [ ] 「楽」と「ミス防止」が両方入っているか(重複拒否・要入力ハイライト・入口の正規化)。
- [ ] 入力欄2つ以上のフォームに下書き自動保存があり、復元が可視化(復元通知+破棄)され、送信成功で消えるか。
- [ ] IME変換確定のEnterで送信されないか。バリデーションは「blurで判定・修正中に解除」か。
- [ ] 一括操作に「事前選択 + その場確認 + 項目別結果 + 部分成功」があるか。
- [ ] リストに全選択・選択バー・範囲選択があるか。複数ファイルを一度に受け、並行処理で待たせない設計か。
- [ ] 自動化に「結果サマリー + Undo」が付いているか。チェックは全件でなく例外だけに絞られているか。
- [ ] 入力の作法(空欄の意味・初期値・保存単位・Enterの挙動)が全画面・全ステップで同じか。入力部品が共通化されているか。
- [ ] 自動計算値が欄の中に入っており、「自動のまま」と「人が入れた」が見た目とデータの両方で区別され、「自動に戻す」があるか。
- [ ] 現在地(ステップ・タブ)と退避先(保存・戻る・次へ)が常に見えるか。該当全画面にMECEに適用し、除外理由が残っているか。
- [ ] 一覧入力で参照列と入力列が離れすぎていないか。数値が右揃え・等幅で桁がガタつかないか。
- [ ] できなかったことが画面に正直に出るか(要確認・未読取・失敗理由)。編集不可・空表示の理由が画面に1行出るか。
- [ ] エラーに次のアクションがあり、入力が保持され、行き止まりがないか。
- [ ] 削除の代わりにステータス制御になっているか。原本がストックされているか。
- [ ] 1秒超の処理に進捗が見えるか。不可逆操作が楽観的更新になっていないか。
- [ ] hover / pressed / focus / 入場 / 展開 / loading / success・errorの各状態が因果を伝え、タッチでも重要操作が見え、reduced-motionで動きを止めても意味が残るか。
- [ ] ホームが「要対応 → 次のアクション → 最近 → キー数字」の順になっているか。
- [ ] 現実の業務量(一度に◯件)で試したか。
- [ ] **動的パスを実際に操作したか**: 一括実行→部分成功→再試行 / 下書き保存→閉じる→復元→破棄 / エラー→回復。実装しただけで検収を通さない。

見た目(色・組版・部品・状態・モーション)の検収は Skill `jp-web-design` の `references/acceptance-checklist.md` を併用する。

## 14. 実装パターン集(`assets/` — コードが正)

- `assets/structure-worksheet.md` — §0-1 / §2-3 / §11-1 / §13-1 の答えを画面ごとに1枚へ残すワークシート(複製して記入。空欄のまま実装に進まない)。

本スキルの主要規律は **React + TypeScript の汎用hooks/ユーティリティ**として保存されている。該当機能を実装するときはコピーして使う(似たものを毎回書き起こさない)。どのアプリでも使えるようドメイン非依存で書かれている。

| 節 | コード | 内容 |
|---|---|---|
| §4-1 | `useDraft` | 下書き自動保存(debounce・TTL・復元フラグ・破棄・送信時クリア) |
| §5-1 | `useBulkSelection` | 一括選択(表示中のみ全選択・Shift+クリック範囲選択・選択不可の自動除外) |
| §4-2 | `useSubmitKeys` | Enter=次フィールド / ⌘・Ctrl+Enter=送信 / IMEガード / OS別キーラベル |
| §4-2 | `useLateValidation` | blurで判定・修正中に解除 |
| §5-2 | `runWithConcurrency` | 並行キュー(同時N本・項目別ステータスコールバック) |
| §5 | `splitResults` | 部分成功の分割(成功は先へ・失敗は要確認キューへ) |
| §5-3 | `applyWithUndo` | 自動処理の「サマリー+Undo」 |
| §4 | `normalizeNumeric` / `isEmail` | 入力に寛容・出力は厳格(ポステルの法則) |
| jp §3-2 | `formatNumParts` | Excel整形+カンマ縮小(値の文法) |

- vanilla JS の参照実装(同じ挙動の非React版)は Skill `jp-web-design` の `assets/reference/app.js`。
- 見た目のコンポーネント対応(Button/Badge/Field/選択バー等)は Skill `jp-web-design` の `assets/reference/README.md` の移植ルールに従う。

## 15. リファレンス索引(`references/` — 作業内容に応じて読む)

| ファイル | いつ読むか | 内容 |
|---|---|---|
| `references/structure-diagnosis-by-domain.md` | 画面の型(一覧・単票・分析・操作感)で §0-1 の重心を決めるとき、前例のない画面、§13-1 を通らなかったとき | ドメイン別の補足問い、原理への還元手順、装飾除去テストで崩れたときの戻り先 |
| `references/apple-polish.md` | §11-1 の操作感を深掘りするとき、「Appleのように」と求められたとき | 直接操作・即応性・中断可能性・空間的一貫性、状態設計、動きは説明のため、触りたさモデルのレビュー活用 |
| `references/input-patterns.md` | フォーム・入力欄を実装/レビューするとき(§4必読) | 下書き自動保存(§4-1)、IME・送信トリガ・blurバリデーション(§4-2)、動作とデザインの一致(§4-3)、自動計算値の由来表示・入力部品の共通化(§4-4)、一覧入力の視線移動(§4-5) |
| `references/bulk-operations.md` | 一覧・アップローダ・自動化を実装/レビューするとき(§5必読) | 一括選択の標準装備(§5-1)、複数ファイル並行処理(§5-2)、省略とチェックの両立(§5-3) |
| `references/behavioral-toolbox.md` | 行動科学の根拠を確認する・新しい仕掛けを検討するとき(§12必読) | 18の道具(デフォルト効果/ヒック/ミラー/アンカリング/ヤコブ/フォン・レストルフ/系列位置/フィッツ/ドハティ/テスラー/ポステル/目標勾配/ピークエンド/ツァイガルニク/損失回避/美的ユーザビリティ/ポカヨケ/選択アーキテクチャ)の原理とアプリ実装対応表 |

見た目の実装(Button/Badge/Field/選択バー等)は Skill `jp-web-design` の `references/components.md` を参照。