AI に勤怠管理を作らせてみた — 前回作った部品を、次の AI がもう発掘していた（やってみた #86）

やってみたシリーズ: 自作のデザインシステム @gunjo/ui（群青）を、文脈ゼロの cold な AI に実 UI で作らせる連載。人材・採用 4枚目——勤怠管理 / 工数管理。月次の社員×日マトリクス、36協定アラート、休暇、勤怠承認。

前回 #85 で、3回手組みされた PersonCell をその場で @gunjo/ui に build した。#86 の観測はただ1つ——たった今作った PersonCell を、何も知らない次の cold AI が自力で発掘して使うか。 複利の、最短距離の証明。

結果 — 4.5/5・そして PersonCell は発掘された

tsc/build 緑・375px 横溢れゼロ・0 console error。月次勤怠マトリクス・36協定可視化・有休管理・勤怠承認WF・社員別ステータス・打刻ドリルイン。

観測の主役 — 「手組みしなかった」

cold AI（群青を一度も触っていない設定）のレポートから:

PersonCell — 繰り返し出る「avatar + 氏名 + 部署/役割 + status」セル。avatar+text を手組みしなかった：PersonCell がまさにそのコンポーネントで、name/secondary/tertiary/avatar/avatarClassName/trailing を持つ。社員リストと詳細ヘッダーに使った。brief が問うていた単位が、既製で存在した。

…avatar+name セルと承認タイムラインを手組みしかけて、display/ フォルダを見て PersonCell/ApprovalWorkflow を見つけた。barrel の命名（UserChip でなく PersonCell）が救った。

1ラウンド前に「3回手組みされたから」と build した部品を、次の業務画面の文脈ゼロ AI が、名前で見つけてゼロ摩擦で使った。 これが cold-test ループの完成形——穴を3回観測 → 規律を守って build → 次の回で自力発掘・再利用。PersonCell は「観測された必然」として作られ、その必然性が即座に裏付けられた。

周辺も既存部品で

• ScheduleGrid（the single best fit） — 社員×日マトリクス。docstring が「shift rosters (staff×days)」を明記。rows=社員・columns=30日・per-day tone（有休→info/欠勤→destructive/重残業→warning）・frozen 先頭列＋sticky ヘッダー・contained 横スクロールで1992px幅でも375pxページを破らない・全120セルに合成読み上げ名「6月1日 月曜日 佐藤健太 09:00〜22:06、実働12.1時間、残業4.1時間」。教育(#70)で結晶化した離散グリッドが人材へ越境。
• ApprovalWorkflow+ApprovalSteps（本人提出→上長承認→労務確定）・Meter（36協定ゲージ・target=45/max=80/threshold で warning→destructive）・Statistic/Delta（残業の符号付き）/SparklineChart（残業推移）/SignedRecord も全部既存部品。

起票（追記・no-build）

• 🟡 Banner が h-10 固定 3回目（また Banner に手を伸ばし→複数行クリップ→Alert に乗り換え・#81/#82/#86 で3回・#322 に追記＝build 閾値・最小修正は JSDoc/docs で「1行ストリップ／複数行は Alert」明記）。
• 🔵 docs↔barrel ギャップ（cold AI の「最も価値ある追加」＝「ドメイン部品を公開 docs に名前で出す」・docs は「40+ display」とカテゴリ数しか出さず PersonCell/ApprovalWorkflow/ScheduleGrid を名前で見つけられない・#325 を強く補強＝EventCalendar/TreeView/Legend と同じ・ユースケース別索引が最高レバレッジ）。
• 🟢 Container/Sheet の既定サイズが密な画面に狭め・Table↔DataTable の中間（renderCard 不要の静的表＋モバイルカード）が無い。

今回 src build なし（4.5/5・PersonCell 発掘＝前回 build の即効性が成果）。

学び — 複利は「次の文脈ゼロ AI が、名前で見つけた時」に確定する

#85 で「PersonCell は観測された必然として結晶化した」と書いた。#86 はその必然性を最短で裏付けた——build した部品が、1ラウンド後の別業務画面の cold AI に、UserChip でなく PersonCell という素直な命名のおかげで一発発見され、avatar+text の手組みが消えた。JSDoc 駆動の発見可能性が、文脈ゼロ採用の本当の資産（#82/#83 で繰り返した学びの、自分で作った新部品での実証）。同時に cold AI 自身が指摘する通り、その資産はbarrel には在るが公開 docs には無い——だから残る最大の宿題は機能でなく「docs↔barrel の発見可能性」（#325）。

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

• 人材・採用5枚目（オンボーディング CheckList / 1on1 など）で人材5枚を締め、次業界へ。PersonCell の3回目の越境観測。

試す

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

まだ alpha。だが「昨日作った部品を、今日の AI がもう使っている」——複利が回っている、その最短の証拠が撮れた回。

---

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