AI に介護記録を作らせてみた — 前回作った RelationshipRow が、もう使われていた（やってみた #91）
/care-record375px のビューポートで撮影。縦長のページはフレーム内をスクロールします。
解説記事
AI に介護記録を作らせてみた — 前回作った RelationshipRow が、もう使われていた（やってみた #91）
やってみたシリーズ: 自作のデザインシステム
@gunjo/ui（群青）を、群青のことを一度も見たことのない AI に、実際の画面で組ませていく連載。介護・福祉 3枚目——介護記録 / ケア記録。バイタル・食事・排泄・服薬・特記、職員サイン。#92 国保連請求と同時に回した。
#90 で RelationshipRow を3回ルールで作った。#91 の観測：たった今作った RelationshipRow を、何も知らない次の予備知識ゼロの AI が自力で発掘するか。 PersonCell #85→#86 と同じ、複利の最短検証。
結果 — 4.5/5・RelationshipRow は発掘された
tsc/build 緑・375px・0 console error。本日の記録状況・担当割り当て・バイタル異常フラグ・ケア記録入力/確定・経過推移。
観測の主役 — 「2人の関係」も手組みしなかった
RelationshipRow — 「2人を並べる」ペア。既製だった。⟷ コネクタとrelationshipLabel、doc コメントが「利用者↔担当ケアマネ」を明記。利用者⟷担当ヘッダーと担当割り当ての両方に使い、どちらも手組みゼロ。
ReferenceValue+flagValue()（決定的なコンポーネント） — 測定値を基準範囲で判定・H/L/HH/LL チップ・異常は常に sr-only テキストで色だけに依存しない。純関数のflagValue()を一覧の「異常」バッジ・サマリの「バイタル異常2名」・スパークラインの色で再利用。 SignedRecord（下書き→署名→ロック・追記のみ）・CoSign（ハイリスク薬の2人確認）も既製。
#90 で作った RelationshipRow を #91 が翌回発掘＝PersonCell(#85→#86) に続き2つ目のコンポーネントで「作る→翌回自力発掘」が再現。PersonCell も全 利用者/記録者に。コンポーネントがコンポーネント（RelationshipRow=PersonCell×2）を生み、その組み合わせも翌回に発掘される＝複利が階層を上がっても回る。
課題記録（追記・コンポーネントを作らず）
- 🟢 収縮期/拡張期 血圧の対の ReferenceValue が無い（180/110 を2つの独立したフラグで・1回目・軽微）。
- 🔵 発見可能性が単一で最大の要望（まとめて呼び出す入口（
@gunjo/ui）の ~210 export がアルファベット順で ReferenceValue/SignedRecord が埋もれる・JSDoc が救うが src を開かないと見えない・#325 を強く補強）。
今回 src の新規コンポーネントなし（4.5/5・RelationshipRow 発掘＋ReferenceValue 業界越えが成果）。
学び — 複利は「コンポーネントの階層」を上っても回る
#85 PersonCell→#86 で発掘。#90 RelationshipRow→#91 で発掘。最小コンポーネントも組み合わせも、作った次の回で別々の予備知識ゼロの AI に自力発掘される——3回ルールで固めたコンポーネントは、観測された必然なので、必然性が即裏付けられる。残る最大の課題はやはり機能でなく発見可能性（#325）＝「在る最高のコンポーネントを、採用者が見つけられない」。
次回予告
- 介護を進めるか次業界へ（#92 と同時記録）。
試す
この連載は、作者が AI（Claude と Codex）と協働で制作しています。実験・検証の設計、判断、公開前の事実確認は人間が行い、実作業と下書き執筆は AI が担っています。
使用した @gunjo/ui コンポーネント
この画面のソースが直接 import しているコンポーネントです。
cold AI が組み上げた実コード
ファイル名をクリックでソースを展開できます。