AI に人事評価を作らせてみた — 3回手組みされた「人物セル」を、その場で部品にした（やってみた #85）

やってみたシリーズ: 自作のデザインシステム @gunjo/ui（群青）を、文脈ゼロの cold な AI に実 UI で作らせる連載。人材・採用 3枚目——人事評価 / 目標管理（MBO）。評価サイクルの進捗、目標達成度、360度評価、評価ワークフロー、評価分布（キャリブレーション）。

採用3枚目。観測の核は明確だった——PersonCell（人物セル）が3回目の手組みになれば、3回ルールが発火してその場で結晶化する。 #83 採用パイプライン・#84 名簿で別々の cold AI が独立に手組みしたあの molecule。

結果 — 4.5/5・そして PersonCell を build

tsc/build 緑・375px・0 console error。評価サイクル進捗・S/A/B/C/D キャリブレーション・被評価者一覧・360度レーダー・評価ワークフロー・人事確定ダブルチェック。

観測 — 評価/承認系は kit のド真ん中

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

ApprovalWorkflow（the standout） — 自己評価提出 → 一次 → 二次 → 人事確定。advance/差戻し(記録ロールバック)/却下を最初から持ち、各遷移に actor＋時刻＋コメントを刻む。「brief に対する kit 最良の fit。承認ステートマシンという普通いちばん難しい部分が、props を渡すだけになった」。

CoSign — 人事確定のダブルチェック。2人目署名＋必須同意チェック＋同一人物ガード。maker-checker がそのまま。Meter(達成度・size="inline" がテーブルセル用)・DistributionBar(S/A/B/C/D キャリブレーション)・RadarChart(自己/上司/peer/部下の360度を1行)・Rating も全部「この用途のために作られたよう」。

ApprovalWorkflow(#267)・CoSign(#239)・Meter(#230)・DistributionBar・RadarChart・Rating ——会計/医療/公共で育てた評価/承認 primitive が、人事評価でまた丸ごと効いた。

核 — 3回目が出たので、その場で結晶化した

person cell（the one real gap） — 「avatar + 氏名 + 部署/役割 (+ status/trailing)」が**全 被評価者（テーブル8行＋モバイル8カード）と全 評価者（詳細の4コメント）**に出る。Avatar はあるが「人」を表す cell が無いので PersonCell.tsx を手組み。「<Person avatar name secondary trailing /> があればこのファイルは丸ごと消えた。HR/people プロダクトの最頻出の atom。」

これで PersonCell の手組みは3回連続（#83 採用・#84 名簿・#85 評価・別々の cold AI が独立に再発明）＝3回ルール発火。なのでこの回でそのまま build した：

→ PersonCell を @gunjo/ui に追加（PR #332・#329 close）。avatar＋name＋secondary/tertiary＋presence dot＋trailing スロット、氏名から頭文字フォールバック（日本語の姓に対応）、sm/md/lg、全部 truncate でテーブルセルに収まる。presentational 既定（行が onRowClick で活性なら素のまま置く＝#85 で踏んだ「カードに button をネストして role=button 二重」footgun を回避）。synthetic spec で land・docs/デモ/design:verify 緑・ブラウザ実証（presence dot・在籍/休職中/退職予定 trailing・3サイズ）。

その他の起票（追記）

• 🟠 Drawer も aria-describedby 警告（Sheet/Dialog/Modal と同じ Radix 契約・#323 に追記）。
• 🟡 DataTable.renderCard が既に role=button で、中に button をネストすると二重（JSDoc/docs で明記すべき・#333）。
• Meter/Progress/Gauge・DistributionBar/StackedBar の選別が名前だけだと迷う（docstring が救う・#325 系）。

学び — 3回ルールは「待つ規律」であり「作る引き金」

#83 で穴を見つけ、#84 で再確認し、見送った。普通なら「早く作れば」と思うところを、3回ルールに従って2回は手を出さず、3回目の独立した手組みが揃った瞬間に build した。これは消極的な先延ばしではない——3つの別々の文脈ゼロ AI が、3つの別業務画面で、同じ molecule を独立に再発明したという、設計を正当化する最強の証拠が揃うのを待つ規律。揃った今、PersonCell は「誰かの意見」ではなく「観測された必然」として結晶化した。cold-test ループが、穴の発見 → 規律ある待機 → その場での結晶化、まで一周した回。

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

• 人材・採用4〜5枚目（勤怠 ScheduleGrid / オンボーディング CheckList など）。今 land した PersonCell が、次の HR 画面の cold AI に自力発掘されるか＝複利の即観測。

試す

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

まだ alpha。だが「3回手組みされた穴を、同じループの中でそのまま部品にする」——cold-test の本来の目的が、最もきれいに回った回。

---

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