#79スコア 4.5/5公共・行政

AI に住民異動届の処理を作らせてみた — ApprovalWorkflow が3回連続で別手続きに刺さり、チェックリストを3回出して部品化（やってみた #79）

ルート: /resident-move
デスクトップ表示
モバイル表示

375px のビューポートで撮影。縦長のページはフレーム内をスクロールします。

解説記事

AI に住民異動届の処理を作らせてみた — ApprovalWorkflow が3回連続で別手続きに刺さり、チェックリストを3回出して部品化（やってみた #79）

やってみたシリーズ: 自作のデザインシステム @gunjo/ui（群青）を、文脈ゼロの cold な AI に実 UI で作らせる連載。公共/自治体5枚目——住民異動届 / 各種届出処理（異動内容 × 処理ワークフロー × 本人確認/必要書類 × 関連手続き × 受理記録）。

公共の5枚目は住民課の窓口——転入/転出/転居を受け、本人確認・書類・**関連手続き（マイナンバー/国保/学校/印鑑…）**を案内し、住民票を更新して受理する画面。ApprovalWorkflow が3回連続で別手続きに刺さり、同じ画面で3回出た「チェックリスト」を部品化した回。

結果 — 4.5/5

tsc/build 緑・console 0・375px・異動内容/対象世帯員・処理ワークフロー（受付→本人確認→異動内容確認→住民票更新→完了）・関連手続きチェックリスト・受理記録ロック。

今回の主役 — ApprovalWorkflow が3回連続、CheckList を3回ルールで build

ApprovalWorkflow（#76 build）が、#77 施設予約・#79 住民異動 と3回連続で別ドメインに刺さった:

Processing workflow ← ApprovalWorkflow. Designed for "any staged back-office review" — dropped onto a 自治体 residence-registration pipeline with zero structural changes. Already ships 差戻し/却下/完了 defaults, records actor+timestamp, rolls back on send-back, and canAdvance+advanceHint gating I wired straight to "本人確認済 && 必須書類チェック済" and "関連手続き全件解決済". Discoverable on the first catalog pass.

そして cold AI が1画面で3回手組みしたものがあった——チェックリスト（対象世帯員・必要書類・関連手続き）:

No checklist / selectable-list primitive. List is presentational, Checkbox is a single control — nothing composes "row with leading control + label + description + trailing status/action." All three core domain lists are hand-rolled. The single biggest gap for back-office/case-management screens.

これは #67 リコール範囲確定でも出ていた。#67＋#79（×3）＝明確に3回以上 → 3回ルールで CheckList を build（#135・PR #310）:

  • items[]（id/label/description/trailing/checked/disabled）・枠+区切り線・onCheckedChange(id, checked)。
  • 各チェックボックスが行ラベルをアクセシブル名に（Checkbox の label/description 配線を流用＝ラベル無しコントロールにならない）・trailing（status Badge/アクション/金額）はトグルの外。
  • checked 無しの行は素の表示行（情報行と混在可）。

ブラウザ実証: トグル [T,F,F,F]→[T,T,F,F]・aria-labelledby 配線・行ごとの確認済/未確認 Badge。#135 は「チェックリスト」の顔を build、選択+キーボードナビの ListBox（受信箱/master-detail）は別 primitive として残す。

越境継続: SignedRecord→受理記録・Badge icon→関連手続き状態ピル・DataTable→届出一覧。

起票だけ（軽微）

  • 🟡 DataTable のヘッダ要約が狭い desktop コンテナ（<480px）で崩れる（#311）。
  • 🟢 ApprovalWorkflow + SignedRecord の「この段階は署名必須」合成パターンが docs に無い（#312）。

学び — 「振る舞い」も「行の型」も、3回で結晶化

#79 は2つの3回ルールが同時に効いた回：①振る舞い primitive（ApprovalWorkflow）が3回連続で別手続きに刺さる（複利）。②行の型（CheckList）が3回出て build（新規）。デザインシステムは「画面の骨格」だけでなく「行の骨格（チェック+ラベル+状態）」も primitive 化する価値がある——cold AI が同じ <ul> を1画面で3回書いた痛みが、そのまま設計仕様になった。公共5枚で、規制・back-office ドメインの作法（署名確定・段階審査・チェックリスト・maker-checker）がほぼ揃った。

公共シリーズ総括（#75〜#79）

#画面点ハイライト
75窓口/申請受付4SignedRecord/CoSign 越境・DataTable onRowClick fix
76給付金審査4ApprovalWorkflow build（3回手組み）
77施設予約4.5ScheduleGrid＋ApprovalWorkflow 即再利用
78税申告/納税4.5SignedRecord→課税確定・no-build
79住民異動4.5ApprovalWorkflow 3回連続・CheckList build

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

  • 別業界へ pivot（メディア/出版・HR/人材 など）or 公共をもう1枚。CheckList が別画面で即再利用されるか・系譜#281・連続時間軸#142残りの大型も観測継続。

試す

まだ alpha。ApprovalWorkflow が3回連続で別手続きに刺さり、1画面で3回出たチェックリストを CheckList に結晶化した回。

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

使用した @gunjo/ui コンポーネント

この画面のソースが直接 import している部品です。

AlertAlertDescriptionAlertTitleApprovalWorkflowBadgeButtonCardCardContentCardDescriptionCardHeaderCardTitleCheckboxColumnDefContainerDataTableHStackMetadataListSelectSeparatorSignedRecordVStackWorkflowValue

cold AI が組み上げた実コード

ファイル名をクリックでソースを展開できます。