AI に生保の引受査定を作らせてみた — 昨日作ったコンポーネントを、別のAIが翌日もう見つけて使った（やってみた #104）
/insurance-underwriting375px のビューポートで撮影。縦長のページはフレーム内をスクロールします。
この回の発見
この下の記事から抜き出した、この回で分かったことです。状態は記事の時点ではなく、コンポーネント側のいまの実測です。
この回で要ると分かったもの
- BMIや血圧などの数値が、基準の範囲からどのくらい外れているかまで込みで出ます。
告知・リスク評価（生命保険の引受査定（アンダーライティング））自分の画面で確かめる 検査値を並べた画面で、値そのものと基準からの外れ方の両方が読めるか確かめてください。
状態 対応済み - 主契約と特約と特別条件を積み、割引を引いて保険料を出します。引受をしない判定のときは、合計が0円として出ます。
保険料算定（生命保険の引受査定（アンダーライティング））自分の画面で確かめる 引受をしない判定に切り替えて、合計が0円のまま崩れずに出るか確かめてください。
状態 対応済み
この回でつまずいたところ
- DataTable や StatGroup はデータを渡せば描けるのに、Timeline だけ中身を入れ子で書きます。最初に書いた形が通らず、ソースを読むまで気づけませんでした。
時系列の表示（生命保険の引受査定（アンダーライティング））原因 同じライブラリの中にデータを渡す作法と入れ子で組む作法が混ざっていて、当時はその違いが型名にも、やりたいことからコンポーネントを引く対応表にも出ていなかったためです。自分の画面で確かめる 時系列の表示を、他の一覧と同じようにデータを渡す書き方で組めるか確かめてください。
状態 対応済み
解説記事
AI に生保の引受査定を作らせてみた — 昨日作ったコンポーネントを、別のAIが翌日もう見つけて使った（やってみた #104）
やってみたシリーズ: 自作のデザインシステム
@gunjo/ui（群青）を、群青のことを一度も見たことのない AI に、実際の画面で組ませていく連載。保険 4枚目——生命保険の引受査定（アンダーライティング）（申込審査・告知/リスク評価・保険料算定・承認）。#103 で作ったAmountBreakdownが、もう発掘される回。
#101〜103 は損保（査定/契約/支払）。#104 は生保の引受査定——別作法。観測の核は1つ——前回作ったばかりの AmountBreakdown を、別の予備知識ゼロの AI が保険料計算で自力発見できるか。
結果 — 4.5/5、そして法則が1ラウンドで閉じた
tsc/build 緑・375px・0 console error。KPI・申込査定一覧・告知/リスク評価・保険料算定・承認・2名承認・確定。そして予備知識ゼロの AI（群青を一度も触っていない設定）のレポート：
AmountBreakdown— 保険料の導出。これのために作られていた。 手組みしていない。「既製の『ラベル付き明細＋符号付き調整＋合計』の明細で、保険料の計算に完全に嵌まった」。セクション見出し（主契約/特約/特別条件/割引）・add行・行ごとの note（47歳男性/−8% 等）・点線の subtotal（特約合計）・subtract行が −¥1,768 のグリフ＋控除トーン（符号は色でなくグリフ＋sr-only「控除」）・強調した total＋数式キャプション。謝絶ケース（合計¥0・negative トーン）まで処理。加算 も 減算 も 小計 も 数式 も 注記も——全項目クリア。これが標準装備の主役。
そして索引も：
/docs/by-use-case索引が秀逸で、これが無ければ倍かかった。 画面を説明したら ほぼ完璧なコンポーネント一覧が返った——保険料は AmountBreakdown・KPI は StatGroup・承認は ApprovalWorkflow＋CoSign（CoSign は名前から存在を推測できなかった）。一番見つけにくい2つ——保険料内訳と承認/2名フロー——を名指しで当てた。
これが「法則が閉じた」瞬間
人物の階層（PersonCell→RelationshipRow→StatGroup）で「作る→翌画面で別業界の予備知識ゼロの AI が自力発掘」を法則化した。今回はそれが AmountBreakdown で1ラウンドで再現した：
- #103：損保の支払担当 AI が金額の導出を3回目の手組み → その場で
AmountBreakdownを作り＋逆引き索引をそこへ向けた。 - #104：生保の引受査定の AI（別人・別領域）が、索引から
AmountBreakdownを自力発見し、保険料計算に 摩擦ゼロ で適用——加算/減算/小計/数式/謝絶まで全部嵌めた。
コンポーネント（#103 で作った）と 索引（#103 で向け直した）が、次の回で同時に効いた。 発見可能性への投資と機能への投資が、同じ1ラウンドで裏付いた。
直さなかったこと（観測のみ）
- 🟢
Timelineが入れ子で組む API（<Timeline><TimelineItem><TimelineTime/>…）で、データを prop で渡す形（DataTable/StatGroup/AmountBreakdown はitems/lines）と違う——「最初の書き方を壊した唯一の点。ソースを読むまで分からない」。索引にも型名にも『入れ子で組む か データ prop か』が出ない。→ #349（Timeline にデータ prop の別形 or 索引に「API の形」タグ）。今回も核は発見可能性——機能は在る、形（入れ子 vs データ）が見えないだけ。 - そのほか
ReferenceValue（BMI/血圧を基準値で H/HH 判定）・CoSign・SignedRecordが生保の引受査定にそのまま嵌まった＝医療の基準値判定と署名ロックが保険の引受にも効く。
今回 src の新規コンポーネントなし（4.5/5・AmountBreakdown の別業界での自力発見が成果）。
学び — 「作る」と「見つけさせる」は同じ1ラウンドで裏付く
#100 で「コンポーネントは揃った、次は見つけさせる」と逆引き索引を作り、#101 で効いた。#103 で AmountBreakdown を作り索引を向け直し、#104 でコンポーネントも索引も同時に効いた。機能・発見可能性は別物でなく、両方とも『作れば次の採用者に効く』同じ性質。 残る唯一の欠落は「入れ子で組む か データ prop か、形が見えない」——それも索引のタグ1つで閉じる。
次回予告（やってみた #105）
- 保険5枚目で締める（団体保険/共済 or 募集人ポータル）か、次業界（運輸/建設/エネルギー）へ移る。
試す
- gunjo.jp ／ 金額内訳 AmountBreakdown ／ 逆引き索引 /docs/by-use-case ／ npm
@gunjo/ui／ GitHub ／ 前回まで #1〜#103 - GunjoUI by UIXHERO
昨日作ったコンポーネントを、別のAIが翌日もう見つけて使った。保険4枚目、法則がまた閉じた。
この連載は、作者が AI（Claude と Codex）と協働で制作しています。実験・検証の設計、判断、公開前の事実確認は人間が行い、実作業と下書き執筆は AI が担っています。
使用した @gunjo/ui コンポーネント
この画面のソースが直接 import しているコンポーネントです。
cold AI が組み上げた実コード
ファイル名をクリックでソースを展開できます。