AI に人事評価を作らせてみた — 3回手組みされた「人物セル」を、その場でコンポーネントにした（やってみた #85）
/performance-review375px のビューポートで撮影。縦長のページはフレーム内をスクロールします。
解説記事
AI に人事評価を作らせてみた — 3回手組みされた「人物セル」を、その場でコンポーネントにした（やってみた #85）
やってみたシリーズ: 自作のデザインシステム
@gunjo/ui（群青）を、群青のことを一度も見たことのない AI に、実際の画面で組ませていく連載。人材・採用 3枚目——人事評価 / 目標管理（MBO）。評価サイクルの進捗、目標達成度、360度評価、評価ワークフロー、評価分布（キャリブレーション）。
採用3枚目。観測の核は明確だった——PersonCell（人物セル）が3回目の手組みになれば、3回ルールが発火してその場で固まる。 #83 採用パイプライン・#84 名簿で別々の予備知識ゼロの AI が独立に手組みした、あの組み合わせ。
結果 — 4.5/5・そして PersonCell を作る
tsc/build 緑・375px・0 console error。評価サイクル進捗・S/A/B/C/D キャリブレーション・被評価者一覧・360度レーダー・評価ワークフロー・人事確定ダブルチェック。
観測 — 評価/承認系はライブラリのド真ん中
予備知識ゼロの AI（群青を一度も触っていない設定）のレポートから:
ApprovalWorkflow（いちばんの見どころ） — 自己評価提出 → 一次 → 二次 → 人事確定。次へ/差戻し(記録ロールバック)/却下を最初から持ち、各遷移に実行者＋時刻＋コメントを刻む。「この課題に対してライブラリで最良の一致。承認の状態遷移という、普通いちばん難しい部分が、props を渡すだけになった」。
CoSign — 人事確定のダブルチェック。2人目署名＋必須同意チェック＋同一人物ガード。二重承認がそのまま。Meter(達成度・size="inline"がテーブルセル用)・DistributionBar(S/A/B/C/D キャリブレーション)・RadarChart(自己/上司/同僚/部下の360度を1行)・Rating も全部「この用途のために作られたよう」。
ApprovalWorkflow(#267)・CoSign(#239)・Meter(#230)・DistributionBar・RadarChart・Rating ——会計/医療/公共で育てた評価/承認コンポーネントが、人事評価でまた丸ごと効いた。
核 — 3回目が出たので、その場で固めた
人物セル（唯一の本物の欠落） — 「avatar + 氏名 + 部署/役割 (+ status/trailing)」が全ての被評価者（テーブル8行＋モバイル8カード）と全ての評価者（詳細の4コメント）に出る。
Avatarはあるが「人」を表す cell が無いのでPersonCell.tsxを手組み。「<Person avatar name secondary trailing />があればこのファイルは丸ごと消えた。HR/人物系プロダクトの最頻出の最小コンポーネント。」
これで PersonCell の手組みは3回連続（#83 採用・#84 名簿・#85 評価・別々の予備知識ゼロの AI が独立に再発明）＝3回ルール発火。なのでこの回でそのまま作った：
→ PersonCell を @gunjo/ui に追加（PR #332・#329 をクローズ）。avatar＋name＋secondary/tertiary＋presence dot＋trailing の差込口、氏名から頭文字フォールバック（日本語の姓に対応）、sm/md/lg、全部 truncate でテーブルセルに収まる。表示専用が既定（行が onRowClick で活性なら素のまま置く＝#85 で踏んだ「カードに button をネストして role=button が二重」というハマりどころを回避）。合成 spec で反映・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回目の独立した手組みが揃った瞬間に作った。これは消極的な先延ばしではない——3つの別々の予備知識ゼロの AI が、3つの別業務画面で、同じ組み合わせを独立に再発明したという、設計を正当化する最強の証拠が揃うのを待つ規律。揃った今、PersonCell は「誰かの意見」ではなく「観測された必然」として固まった。予備知識ゼロの AI に作らせるループが、欠落の発見 → 規律ある待機 → その場でのコンポーネント化、まで一周した回。
次回予告（やってみた #86）
- 人材・採用4〜5枚目（勤怠
ScheduleGrid/ オンボーディングCheckListなど）。今 反映したPersonCellが、次の HR 画面の予備知識ゼロの AI に自力で発掘されるか＝複利の即観測。
試す
まだ alpha。だが「3回手組みされた欠落を、同じループの中でそのままコンポーネントにする」——予備知識ゼロの AI に作らせるテストの本来の目的が、最もきれいに回った回。
この連載は、作者が AI（Claude と Codex）と協働で制作しています。実験・検証の設計、判断、公開前の事実確認は人間が行い、実作業と下書き執筆は AI が担っています。
使用した @gunjo/ui コンポーネント
この画面のソースが直接 import しているコンポーネントです。
cold AI が組み上げた実コード
ファイル名をクリックでソースを展開できます。