AI に年末調整の申告画面を作らせてみた — 直近で作った4つが、全部ゼロ摩擦で使われた（やってみた #41）

やってみたシリーズ: 自作のデザインシステム @gunjo/ui（群青）を、文脈ゼロの cold な AI に実 UI で作らせる連載。給与2枚目——年末調整 申告（扶養親族・保険料控除の編集・各種控除計算・過不足税額の精算）。

結果 — 4.5/5

tsc/build 緑・console 0・375px で編集グリッドがカード化・過不足額がライブ再計算（還付/追徴を明示）・提出フロー動作・h1 1個。

この回の主役 — 直近で作った4つが、全部ゼロ摩擦で使われた

ここ数回で私は CurrencyInput(#176)・EditableDataTable(#199)・ApprovalSteps(#207)・formatCurrency(#180) を作って出荷してきた。年末調整という、税申告の濃い新画面で、cold AI が4つ全部を見つけて使った:

• CurrencyInput — USED, ¥金額9フィールド全部に（保険料・所得見積額・住宅借入金等・配偶者所得）。contract がドンピシャ——controlled value:number＋onValueChange、¥プレフィックス、入力中に桁区切り、右揃え tabular-nums、min クランプ、aria-invalid で赤枠。ゼロ摩擦。このドメインで single best な部品。
• EditableDataTable — USED, 扶養親族と保険料控除の両リストに。getRowError・renderFooterCell（控除額合計）・自動モバイル card 化。as-is で戦わず。
• ApprovalSteps — USED, 申告者→人事確認＋差戻し。state→アイコン＋トーン＋テキスト・差戻しコメント。ゼロ修正で適合。
• formatCurrency — USED, 全 read-only ¥表示に。signed で -¥66,100。

「穴を見つける → 作る → 翌回以降の別画面で composition の部品として効く」——fintech/会計/給与の「金額を扱う層」を作り切った成果が出た。税計算（控除の上限・累進税額・過不足精算）はドメインロジックなので DS は作らないのが正解で、cold AI もそう書いた。

新しい穴は "アーキ層" に

満点(5/5)に届かなかったのは、品質でなく未整備のアーキ primitive:

• 🟠 条件付きセクションの primitive が無い（最大）。配偶者控除ブロックや確認パネルの表示/非表示を role=region＋aria-live で毎回手巻き（#213）。
• 🟠 精算結果バナーの primitive が無い。還付/追徴の見出し金額を Alert＋手書きの大きな数字で構成（#214）。
• 🟡 ThemeProvider が consumer の layout に未配線だと OS ダーク無視（#171 footgun・3回目・install-doc の問題）。

今回は src の小修正 無し——kit が持ちこたえ、残る穴は新規 primitive とドメインロジックだった。誠実に、そう記録する。

学び — 作り切った層は、新画面で "composition" になる

〜#40: 金額/グリッド/承認/フォーマッタの穴を1つずつ埋める
#41: 4つ全部が、新画面で composition の部品としてゼロ摩擦で効く

primitive を積み上げると、ある時点から cold AI は「探して・組み合わせる」だけになる。41回回して、fintech/会計/給与の金額系画面はその段階に達した。次のフロンティアは条件付きフォーム・結果表示といった別のアーキ層——穴は質から「未整備の上位 primitive」へ、また一段収束した。

次回予告（やってみた #42）

• 別業界（POS/医療/物流）か、条件付きセクション(#213)を作るか。金額系は強い、次は別の層。

試す

• gunjo.jp ／ npm @gunjo/ui ／ GitHub
• 前回まで: #1〜#40
• GunjoUI by UIXHERO

まだ alpha。作り切った層が、新画面で composition になった回。

---

<!-- 公開前: 相互URL差込／スクショ確定／EN(dev.to)ミラー -->