AI に通所介護の運営画面を作らせてみた — 介護5枚目、もう手組みする所が無い（やってみた #93）

やってみたシリーズ: 自作のデザインシステム @gunjo/ui（群青）を、文脈ゼロの cold な AI に実 UI で作らせる連載。介護・福祉 5枚目（介護を締め）——通所介護（デイサービス）当日運営管理。来所・送迎・入浴/食事/機能訓練・加算・担当。

介護5枚目で介護を締める。観測：成熟した primitive 群（PersonCell/RelationshipRow/RouteStops/SignedRecord/ScheduleGrid/Meter）が、5枚目でどれだけ手組みを消すか。

結果 — 4.5/5・構造の手組みほぼゼロ

tsc/build 初回緑・375px 横溢れゼロ・0 console error。本日の利用者・稼働率・送迎ルート・入浴/食事/訓練マトリクス・加算メーター・担当ペア・記録サイン。

観測 — prompt が挙げた3つ、全部既製だった

cold AI に「(a)人物セル (b)2人ペア (c)サマリ指標行 をどう作ったか」を聞いた。答え：

3つとも既製コンポーネントがあり、手組みゼロ——(a) PersonCell、(b) RelationshipRow（利用者⟷担当・⟷コネクタ）、(c) Statistic をグリッドに。これが kit の際立った強み。

さらに RouteStops（送迎ルート・予定vs実績の符号付き遅延・不在は status:failed で一発）・SignedRecord（記録確定＝確定後修正不可/追記のみ）・Meter（稼働率 target マーカー＋加算 fill-is-good 進捗）・ScheduleGrid（利用者×入浴/食事/訓練/レク）も既製。「doc comment が 訪問介護/ケアプラン/利用者⟷担当ケアマネ/バイタル/入浴拒否 を literal に挙げる＝この domain のために設計されたよう」。

介護5枚目（#89-93）で、業務の骨格（人・関係・送迎・スケジュール・署名記録・稼働メーター）が全部既存部品で組めた＝care/people ドメインを作り切ったサイン。cold AI は「構造はほぼ何も手組みしなかった・初回から型もビルドも緑」。

残った小さな穴

• 🟠 PersonCell の interactive 変種が無い（#93 単一最大要望・presentational なので行を nav target にするたび <button> で包む・全 care/HR/CRM 画面が同じ wrapper を再実装・onActivate/href+chevron が欲しい・#341）。
• 🟢 status→tone の Badge ヘルパー（実施/予定/拒否→variant を毎回手書き・同issue）・discoverability（RelationshipRow が generic 命名・Meter fill-is-good が名前から非自明・flagValue が ReferenceValue.tsx に埋もれ・#325 強補強）。

今回 src build なし（4.5/5・成熟 primitive の総再利用が成果）。

学び — 「作り切った」は、5枚目で手組みが消える時に分かる

医療6枚(#53-59)で「画面まるごと別業界部品で完成」を見た。介護5枚(#89-93)で同じ段階に達した——#89 で PersonCell/ScheduleGrid 越境、#90 で RelationshipRow を build、#91 でそれを発掘、#92 で会計金額 primitive 越境、そして #93 で人・関係・送迎・スケジュール・署名・メーターが全部既製＝手組みする構造が無い。3回ルールで1つずつ結晶化した部品が、5枚目で集合して業界を丸ごと賄う。残るのは機能でなく「interactive な人物セル」「サマリ指標行（StatGroup #340）」「発見可能性」——整え方の polish。

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

• StatGroup を build（#340・~93枚 全画面が冒頭で手組みしてきたサマリ指標行）＝人・関係に続く「指標行」の結晶化。＋次業界へ。

試す

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

まだ alpha。だが介護5枚目で「手組みする構造が無い」段に達した——3回ルールの結晶が、業界を丸ごと組み上げる。

---

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