AI に保険金査定の画面を作らせてみた — #100で作った「用途から引く索引」が、次の回でもう効いた（やってみた #101）
/insurance-claims375px のビューポートで撮影。縦長のページはフレーム内をスクロールします。
この回の発見
この下の記事から抜き出した、この回で分かったことです。状態は記事の時点ではなく、コンポーネント側のいまの実測です。
この回で要ると分かったもの
- 査定額の大きい案件は、担当者がひとり承認しても止まったままになります。もうひとりが承認し、確定が署名として残って、はじめて次の工程に進みます。
高額案件の承認（自動車保険 保険金請求・査定管理）自分の画面で確かめる 高額の1件を開いて、ひとりの承認だけで支払の工程まで進めてしまわないか確かめてください。
状態 対応済み - 1件の請求が、受付・損害調査・査定・承認・支払のどこまで来ているかが一目で分かり、途中で差し戻すこともできます。
査定ワークフロー（自動車保険 保険金請求・査定管理）自分の画面で確かめる 差し戻した1件を開いて、いま止まっている工程が画面のどこかに出ているか確かめてください。
状態 対応済み
この回でつまずいたところ
- 同じ承認の画面なのに、ボタンは「次へ進める」「差戻し」と日本語で、状態だけ Pending や In progress と英語で出ました。
査定ワークフローの状態表示（自動車保険 保険金請求・査定管理）原因 ApprovalSteps の状態ラベルの既定値が英語のままで、同じ仲間のコンポーネントのボタンだけが日本語だったためです。自分の画面で確かめる 承認の画面を開いて、状態の文字とボタンの文字が同じ言語で出ているか見てください。
状態 対応済み - 請求額から過失相殺と免責を引いて査定額を出すところだけ、明細と合計行を手で書くことになりました。
査定額の内訳（自動車保険 保険金請求・査定管理）原因 ラベル付きの明細、マイナス記号つきで引き算を見せる行、強調した合計、数式の4つをまとめて見せるコンポーネントが当時はまだ無かったためです。自分の画面で確かめる 金額を引き算して出す画面を開いて、合計行と数式を自分で書いていないか確かめてください。
状態 対応済み
解説記事
AI に保険金査定の画面を作らせてみた — #100で作った「用途から引く索引」が、次の回でもう効いた（やってみた #101）
やってみたシリーズ: 自作のデザインシステム
@gunjo/ui（群青）を、群青のことを一度も見たことのない AI に、実際の画面で組ませていく連載。新業界 保険 1枚目——自動車保険 保険金請求・査定管理（受付→損害調査→査定→承認→支払）。#100 の総括で、用途からコンポーネントを引ける索引（逆引き索引）を公開した、その次の回。
14業界目は損保。観測の核は明確——#100 で作った用途別の逆引き索引が、次の予備知識ゼロの AI の役に立つか。
結果 — 4.5/5・~90%が組み立て
tsc/build 緑・375px 横溢れゼロ・0 console error。KPI・請求一覧・査定ワークフロー・高額2名承認・査定額内訳・査定確定。
観測の主役 — 逆引き索引が「再発明と組み立ての分かれ目」に
予備知識ゼロの AI（群青を一度も触っていない設定）のレポートから:
/docs/by-use-case索引が秀逸で、実際に時間を節約した——「請求/承認・テーブル・人物セル・KPI・承認サイン・お金」で引いたら、ApprovalWorkflow/DataTable/PersonCell/StatGroup/SignedRecord+CoSign/formatCurrency/Badge/Sheetという正確なコンポーネントが返ってきた。予備知識ゼロの採用者にとって、これは組み立てと再発明の差だ。
CoSignが最も見落としやすい——索引が無ければ2人目承認フォームを手組みしていた。Inputs に分類されていて「承認」を探す場所には無いから。
#100 で「コンポーネントは揃った、次は見つけさせる」と書き、逆引き索引を作った。その次の #101 で、新業界の予備知識ゼロの AI がそれを使って CoSign を発掘した。 コンポーネントの「作る→翌画面で発掘」と同じことが、docs にも起きた——発見可能性への投資が1ラウンドで裏付いた。
ApprovalWorkflow(査定WF)・CoSign(高額2名承認・「金融の二重承認」)・SignedRecord(査定確定)・StatGroup(KPI)・PersonCell(契約者+査定者)・DataTable(renderCard でモバイルカード)・formatCurrency(JPY既定) が全部、組み立てで。「~90% が組み立て、~10% がつなぎのコード」。
直した2つ（src の修正）
- 🔴
ApprovalStepsの既定の状態ラベルが英語（Pending/In progress/Approved）——なのにApprovalWorkflowのボタンは日本語（次へ進める/差戻し/却下）。同じコンポーネント族で状態は英語・ボタンは日本語＝日本語ファーストのライブラリで目に見える不整合。→ 既定を 未着手/対応中/完了/却下/スキップ に（PR#346・利用者は stateLabels で上書き可）。 - 🟢
StatGroupの cols が6で頭打ち——保険の KPI は7枚。→ 列数を8まで拡張（同じ PR・#94 で作った自分のコンポーネントの小改善）。
課題に記録 — CalculationLedger（金額の導出ブロック）
査定額の計算だけ手組み＝請求額 − 過失相殺 − 免責 = 査定額 を
MetadataList+DistributionBar+手書きの合計行で。「ラベル付き明細→符号付きの減算→強調された導出合計＋数式キャプション のコンポーネントが無い。MetadataList で80%だが、合計行と数式は毎回手書き」。
→ #347 を課題に記録。これは見積/請求/査定/控除/精算の全画面に出る——請求書#37・給与#40・年末調整#41・税申告#78・査定#101 と手組みされてきた。「KPI 行＝StatGroup」の金融版。作る候補（金融でもう1回出れば固まる）。
今回 src で作ったもの = ApprovalSteps の日本語化＋StatGroup の列数拡張（既存コンポーネントの小さな修正）。
学び — 発見可能性への投資も「翌画面で裏付く」
コンポーネントの「3回ルール→作る→翌画面で別業界が発掘」を法則化したが、#101 は同じ法則が docs にも効くことを示した——#100 で作った逆引き索引が、次の回の新業界の予備知識ゼロの AI に使われ、CoSign の手組みを消した。機能だけでなく『見つけさせる仕組み』も、作れば次の採用者に効く。 そして次に固めるべきは、金融を横断して手組みされ続けた CalculationLedger かもしれない。
次回予告（やってみた #102）
- 保険2枚目（契約管理/代理店 or 引受査定 など）。逆引き索引の再利用＋CalculationLedger 再出現の観測。
試す
- gunjo.jp ／ 逆引き索引 /docs/by-use-case ／ npm
@gunjo/ui／ GitHub ／ 前回まで #1〜#100 - GunjoUI by UIXHERO
まだ alpha。だが「見つけさせる仕組み」を作った次の回で、それがもう効いた——14業界目の1枚目。
この連載は、作者が AI（Claude と Codex）と協働で制作しています。実験・検証の設計、判断、公開前の事実確認は人間が行い、実作業と下書き執筆は AI が担っています。
使用した @gunjo/ui コンポーネント
この画面のソースが直接 import しているコンポーネントです。
cold AI が組み上げた実コード
ファイル名をクリックでソースを展開できます。