AI に保険の契約管理を作らせてみた — 金額内訳がまた手組み、次に作るべきものが見えた（やってみた #102）
/insurance-policies375px のビューポートで撮影。縦長のページはフレーム内をスクロールします。
この回の発見
この下の記事から抜き出した、この回で分かったことです。状態は記事の時点ではなく、コンポーネント側のいまの実測です。
この回で要ると分かったもの
- どの募集人（保険を売る営業担当者）がどの契約を担当しているかが、1行のまとまりとして読めます。
募集人と担当契約の関係（損保の契約管理 / 代理店ダッシュボード）自分の画面で確かめる 担当者と契約を並べた行を見て、担当する側とされる側の向きが行だけで読めるか確かめてください。
状態 対応済み - 代理店ごとの業績が、数字の羅列ではなく、長さで見比べられるメーターで出ます。
代理店業績（損保の契約管理 / 代理店ダッシュボード）自分の画面で確かめる 代理店の一覧を開いて、業績が数字を読み込まなくても見比べられるか確かめてください。
根拠Meter状態 対応済み
この回でつまずいたところ
- 基本保険料に特約を足し、各種の割引を引いて年間保険料を出すところを、また手で書くことになりました。
保険料の内訳（損保の契約管理 / 代理店ダッシュボード）原因 読むための「明細と、足し引きの符号が見える調整と、合計」を出すコンポーネントが当時は無く、前の回とこの回とで、別々のAIがどちらも同じ種類の箇所を手で書くことになったためです。自分の画面で確かめる 金額を積み上げて出す画面を開いて、小計と合計を自分で書いていないか確かめてください。
状態 対応済み - やりたいことからコンポーネントを引く対応表で保険料の内訳を探すと、編集用の入力グリッドに案内されました。読むだけの明細に、編集用の作りは合いません。
ユースケース別の対応表（損保の契約管理 / 代理店ダッシュボード）原因 対応表が、読むための金額導出と、入力するための編集グリッドを分けていなかったためです。自分の画面で確かめる 対応表で「金額の導出」を引いて、読むための明細と入力用のグリッドが別々に出てくるか確かめてください。
状態 対応済み - 隣り合うフィルタで、値の変化の受け取り方が違いました。Select はブラウザ標準の onChange、検索欄は値だけを渡す onValueChange です。
保有契約一覧のフィルタ行（損保の契約管理 / 代理店ダッシュボード）原因 Select はブラウザ標準の select 要素の書き方をそのまま通し、SearchInput は値だけを渡す書き方にしているためです。自分の画面で確かめる フィルタ行に入力を2つ並べて、変化の受け取り方が同じ書き方で済むか確かめてください。
状態 未修正・直し方記録済み - 横から出すパネルで、外枠（Root）と中身（Content）の2箇所に同じ向きを指定することになりました。既定の幅も、契約の詳細を見るには狭いままです。
契約を掘り下げる詳細パネル（損保の契約管理 / 代理店ダッシュボード）原因 同じ向きを外枠と中身の2箇所に書かないと見た目と動きが揃わない作りで、既定の幅も 320px と狭いままだったためです。自分の画面で確かめる 横から出すパネルを開いて、向きの指定が1箇所で済むか、幅が詳細に足りるか確かめてください。
状態 未修正・直し方記録済み
解説記事
AI に保険の契約管理を作らせてみた — 金額内訳がまた手組み、次に作るべきものが見えた（やってみた #102）
やってみたシリーズ: 自作のデザインシステム
@gunjo/ui（群青）を、群青のことを一度も見たことのない AI に、実際の画面で組ませていく連載。保険 2枚目——損保の契約管理 / 代理店ダッシュボード（保有契約・更新失効リスク・代理店業績・保険料内訳）。
#101査定とは別の契約/営業系。観測の核——#101 で課題に記録した CalculationLedger（金額の導出ブロック）が、保険料内訳でまた手組みされるか。
結果 — 4/5・~85%が組み立て
tsc/build 緑・375px・0 console error。KPI・保有契約一覧・更新失効リスク・代理店業績・保険料内訳・契約を掘り下げる詳細。
観測 — コンポーネントは揃い、逆引き索引も効く。だが金額内訳だけは…
予備知識ゼロの AI（群青を一度も触っていない設定）のレポートから:
StatGroup（KPI）・PersonCell（契約者/募集人）・RelationshipRow（募集人↔担当契約・「手こずらなかった」）・DataTable（renderCard でモバイルカード）・Meter（業績）・formatCurrency（JPY既定） が全部、組み立て。/docs/by-use-case索引が秀逸で、その役割を果たした——「何を作りたいか」で引いて RelationshipRow（名前は 募集人↔契約 を主張しない）に辿り着けた。唯一の本当の欠落＝保険料内訳を手組み（基本保険料 ＋ 特約 − 各割引 = 年間保険料）。「読み取り専用の『ラベル付き明細＋符号付き調整＋合計』を表示するコンポーネントが無い。索引は
EditableDataTableに誘導したが、あれはエディタグリッド＝読み取り専用の保険料明細には作法が違う。Delta（符号付きの行の最小コンポーネント・割引/加算の読み上げラベル付き）で組んだ」。
CalculationLedger の手組みは2回連続（#101 査定額＋#102 保険料内訳・別々の予備知識ゼロの AI が独立に）＝3回ルール 2/3。しかも予備知識ゼロの AI が最小コンポーネント（Delta）と作法まで設計してくれた——「CostBreakdown は Delta＋Separator＋formatCurrency の組み合わせ：グループ別のラベル付き明細 → 符号付き調整 → 小計 → 総計＋数式キャプション」。あと1回 金融/保険で出れば作る。
課題記録（追記）
- 🟠 CalculationLedger 2回目（#347・逆引き索引が EditableDataTable に誤って誘導＝編集明細 vs 読み取り専用の金額内訳を区別すべき・Delta が行の最小コンポーネント）。
- 🟢 Drawer の side が Root と Content の2箇所にある＋既定幅 w-80 が狭い（#335）・Select(onChange) vs SearchInput(onValueChange) の API が不一致・TimelineItem は status でなく variant（#330）。
今回 src の新規コンポーネントなし（4/5・RelationshipRow 含む再利用が成果・CalculationLedger は 2/3 で次回に作る候補）。
学び — 索引は効く、が「合成コンポーネント」には更新が要る
#101 で逆引き索引が CoSign を救い、#102 でも RelationshipRow を救った——索引は効く。だが #102 は索引の限界も見せた：金額内訳を「EditableDataTable（エディタ）」に誤って誘導した。索引は『完成したコンポーネント』には強いが、『最小コンポーネントを組んで作るべきもの（CostBreakdown=Delta の合成）』には、まだコンポーネントが無い欠落を指せない。 だから次の一手は明確——金融を横断して2回手組みされた CalculationLedger/CostBreakdown をコンポーネント化し、索引をそこへ向ける。コンポーネントが欠落を埋め、索引がそれを指す、の両輪。
次回予告（やってみた #103）
- 保険3枚目（引受査定/申込審査 など）。CalculationLedger 3回目＝作る合図（保険料計算で再出現の可能性大）。
試す
この連載は、作者が AI（Claude と Codex）と協働で制作しています。実験・検証の設計、判断、公開前の事実確認は人間が行い、実作業と下書き執筆は AI が担っています。
使用した @gunjo/ui コンポーネント
この画面のソースが直接 import しているコンポーネントです。
cold AI が組み上げた実コード
ファイル名をクリックでソースを展開できます。