保険UIのコールドテスト — 損保査定・契約・支払・生保引受・営業ポータル
自動車保険の保険金請求・査定、損保契約と代理店ダッシュボード、保険金支払と精算、生命保険の引受査定、生保営業のライフプランナー活動ポータル。AmountBreakdown が 3回確認に到達し、実装翌回で別 cold AI に自力発見された5枚です。
保険 の cold test、10 画面のまとめ。
なぜ保険UIは難しいのか
保険は「金額を構造で説明する」場面が常時並びます。査定の認定額・過失相殺・免責・既払・支払額の連鎖、保険料の構成、引受審査の BMI / 血圧 / 既往の ReferenceValue、高額案件の2人確認 CoSign、確定の SignedRecord、契約者と募集人の関係を見る代理店ビュー。同時に、後半の営業ポータルでは消費者寄りの作法（パイプライン Kanban、目標 Meter、要対応 Alert）も同居します。観測の核は明確で、「金額導出ブロックが3回目の手組みになれば、その場で実装する」でした。
動く見本：架空の保険会社の業務アプリ
この業界で実際に何が組めるのかを、読むだけでなく触って確かめられるように、架空の保険会社の業務アプリを1本用意しました。契約管理、保険金請求・査定、保険金支払・精算の3画面がこのサイトの上でそのまま動きます。UIコンポーネントはすべて @gunjo/ui のものだけを使っています。
ここで群青に加わったコンポーネント
保険5枚で 3回確認を満たして実装に到達した、または実装翌回で自力発見されたコンポーネントです。
- AmountBreakdown#103
支払明細＝認定額−過失相殺−免責−既払＝支払額。求人#102 を経て #103 で 3回確認到達実装。翌回 #104 の保険料計算で別 cold AI が自力発見。
- CoSign (high-value)#101
医療の2人確認が、高額査定・支払・引受承認に 組み合わせ。
- ReferenceValue (underwriting)#104
医療で正式なコンポーネントになった「基準値付き数値」が、生保引受の BMI・血圧・既往判定にそのまま効いた。
- Floor 組み合わせ (round 5)#105
営業ポータルで、人物階層・金額内訳・パイプライン Kanban・関係行・要対応・ブック表が「全部 組み合わせで組める」状態に到達。
AmountBreakdown は実装翌回（#104 生保引受査定）で、保険料計算という新作法の場面で別 cold AI に自力発見されました。金融の「数の説明」がどれだけ業界を越えるかを最も強く証明した連鎖です。
この業界で要るもの
各回の記事から抜き出した項目です。状態は記事の時点ではなく、コンポーネント側のいまの実測です。
- 査定額の大きい案件は、担当者がひとり承認しても止まったままになります。もうひとりが承認し、確定が署名として残って、はじめて次の工程に進みます。
高額案件の承認（自動車保険 保険金請求・査定管理）自分の画面で確かめる 高額の1件を開いて、ひとりの承認だけで支払の工程まで進めてしまわないか確かめてください。
状態 対応済み - 1件の請求が、受付・損害調査・査定・承認・支払のどこまで来ているかが一目で分かり、途中で差し戻すこともできます。
査定ワークフロー（自動車保険 保険金請求・査定管理）自分の画面で確かめる 差し戻した1件を開いて、いま止まっている工程が画面のどこかに出ているか確かめてください。
状態 対応済み - どの募集人（保険を売る営業担当者）がどの契約を担当しているかが、1行のまとまりとして読めます。
募集人と担当契約の関係（損保の契約管理 / 代理店ダッシュボード）自分の画面で確かめる 担当者と契約を並べた行を見て、担当する側とされる側の向きが行だけで読めるか確かめてください。
状態 対応済み - 今回いくら払うのかが、認定損害額から過失相殺と免責と既払金を引いた道筋ごと読めます。
支払明細（自動車保険 保険金支払・精算管理）自分の画面で確かめる 支払明細を開いて、合計だけでなく、そこに至る引き算の一段ずつが出ているか確かめてください。
状態 対応済み - 控除の行が、マイナスの記号でも、画面を読み上げるソフト向けの言葉でも、控除だと分かります。色が見えない状態でも取り違えません。
支払明細の控除行（自動車保険 保険金支払・精算管理）自分の画面で確かめる 画面を白黒にして、控除の行が控除だと分かるか確かめてください。
状態 対応済み - BMIや血圧などの数値が、基準の範囲からどのくらい外れているかまで込みで出ます。
告知・リスク評価（生命保険の引受査定（アンダーライティング））自分の画面で確かめる 検査値を並べた画面で、値そのものと基準からの外れ方の両方が読めるか確かめてください。
状態 対応済み - 主契約と特約と特別条件を積み、割引を引いて保険料を出します。引受をしない判定のときは、合計が0円として出ます。
保険料算定（生命保険の引受査定（アンダーライティング））自分の画面で確かめる 引受をしない判定に切り替えて、合計が0円のまま崩れずに出るか確かめてください。
状態 対応済み - 見込みから成約までの段階が、カードを並べた列として出ます。列の並びはボードの枠の内側だけで横にスクロールするので、スマートフォンでもページ全体は横にずれません。
見込みパイプライン（生保営業（ライフプランナー）の活動ポータル）自分の画面で確かめる 375pxの幅で開いて、パイプラインを横に送ってもページ自体が横にずれないか確かめてください。
状態 対応済み - 今月の手数料の見込みが、募集手数料とインセンティブを足し、取消や戻入（あとから差し引かれる分）を引いた形で出ます。
手数料内訳（生保営業（ライフプランナー）の活動ポータル）自分の画面で確かめる 取消や戻入がある月を開いて、引かれた分が控除だと分かる形で出ているか確かめてください。
状態 対応済み
連載が先につまずいたところ
複数の回で出たものは1つにまとめ、根拠になった回を全部並べています。
- 同じ承認の画面なのに、ボタンは「次へ進める」「差戻し」と日本語で、状態だけ Pending や In progress と英語で出ました。
査定ワークフローの状態表示（自動車保険 保険金請求・査定管理）原因 ApprovalSteps の状態ラベルの既定値が英語のままで、同じ仲間のコンポーネントのボタンだけが日本語だったためです。自分の画面で確かめる 承認の画面を開いて、状態の文字とボタンの文字が同じ言語で出ているか見てください。
状態 対応済み - 請求額から過失相殺と免責を引いて査定額を出すところだけ、明細と合計行を手で書くことになりました。
査定額の内訳（自動車保険 保険金請求・査定管理）原因 ラベル付きの明細、マイナス記号つきで引き算を見せる行、強調した合計、数式の4つをまとめて見せるコンポーネントが当時はまだ無かったためです。自分の画面で確かめる 金額を引き算して出す画面を開いて、合計行と数式を自分で書いていないか確かめてください。
状態 対応済み - やりたいことからコンポーネントを引く対応表で保険料の内訳を探すと、編集用の入力グリッドに案内されました。読むだけの明細に、編集用の作りは合いません。
ユースケース別の対応表（損保の契約管理 / 代理店ダッシュボード）原因 対応表が、読むための金額導出と、入力するための編集グリッドを分けていなかったためです。自分の画面で確かめる 対応表で「金額の導出」を引いて、読むための明細と入力用のグリッドが別々に出てくるか確かめてください。
状態 対応済み - 隣り合うフィルタで、値の変化の受け取り方が違いました。Select はブラウザ標準の onChange、検索欄は値だけを渡す onValueChange です。
保有契約一覧のフィルタ行（損保の契約管理 / 代理店ダッシュボード）原因 Select はブラウザ標準の select 要素の書き方をそのまま通し、SearchInput は値だけを渡す書き方にしているためです。自分の画面で確かめる フィルタ行に入力を2つ並べて、変化の受け取り方が同じ書き方で済むか確かめてください。
状態 未修正・直し方記録済み - 横から出すパネルで、外枠（Root）と中身（Content）の2箇所に同じ向きを指定することになりました。既定の幅も、契約の詳細を見るには狭いままです。
契約を掘り下げる詳細パネル（損保の契約管理 / 代理店ダッシュボード）原因 同じ向きを外枠と中身の2箇所に書かないと見た目と動きが揃わない作りで、既定の幅も 320px と狭いままだったためです。自分の画面で確かめる 横から出すパネルを開いて、向きの指定が1箇所で済むか、幅が詳細に足りるか確かめてください。
状態 未修正・直し方記録済み - DataTable や StatGroup はデータを渡せば描けるのに、Timeline だけ中身を入れ子で書きます。最初に書いた形が通らず、ソースを読むまで気づけませんでした。
時系列の表示（生命保険の引受査定（アンダーライティング））原因 同じライブラリの中にデータを渡す作法と入れ子で組む作法が混ざっていて、当時はその違いが型名にも、やりたいことからコンポーネントを引く対応表にも出ていなかったためです。自分の画面で確かめる 時系列の表示を、他の一覧と同じようにデータを渡す書き方で組めるか確かめてください。
状態 対応済み - 失効防止や更新や満期や誕生日といった、いま対応が要る項目を深刻度の順に並べるところを、手で書くことになりました。
要対応アラート（生保営業（ライフプランナー）の活動ポータル）原因 深刻度で並んだ対応待ちの一覧を出すコンポーネントが当時は無く、深刻度と見た目の対応づけを毎回自分で書く必要があったためです。自分の画面で確かめる 朝いちばんに見る画面で、対応が要る項目が深刻度の順に並んでいるか確かめてください。
状態 対応済み
保険 の全ラウンド
保険 カテゴリの 10 画面を、ラウンド順に並べています。各カードから cold AI が組んだソース、解説記事、デスクトップ／モバイルのプレビューに飛べます。
/insurance-claims14業界目は損保。観測の核は明確——**#100 で作った[用途別の逆引き索引](https://gunjo.jp/docs/by-use-case)が、次の予備知識ゼロの AI の役に立つか。**
/insurance-policies#101査定とは別の契約/営業系。観測の核——**#101 で課題に記録した CalculationLedger（金額の導出ブロック）が、保険料内訳でまた手組みされるか。**
/insurance-payments#101 査定・#102 契約に続く保険3枚目。観測の核は最初から決まっていた——**金額の導出ブロックが3回目の手組みになれば、その場で `AmountBreakdown` を作る。**
/insurance-underwriting#101〜103 は損保（査定/契約/支払）。#104 は生保の引受査定——別作法。観測の核は1つ——**前回作ったばかりの `AmountBreakdown` を、別の予備知識ゼロの AI が保険料計算で自力発見できるか。**
/insurance-agent-portal#101〜104 は社内の事務方（査定/契約/支払/引受）。#105 は**現場の募集人側**＝別のペルソナで保険を締める。観測：人物の階層・金額内訳・パイプライン・関係——**ここまで作ったコンポーネントが、営業の朝の画面でも全部、組み立てで済むか。**
/policy-portal予備知識ゼロの AI に、公開されている npm パッケージと gunjo.jp の docs だけを渡して組ませました。`tsc` は緑、実行してもエラーはありません。
/claim-filing前の #192（入居者マイページ）で、**写真を添える部品がキーボードから一切操作できない**という重い不具合を見つけました。そのときの AI は実装を読んで気づき、**採用を見送っています**。
/premium-quote予備知識ゼロの AI に、公開されている npm パッケージと gunjo.jp の docs だけを渡して組ませました。`tsc` は緑、実行してもエラーはありません。それでも、いちばん大きい発見は不具合でした。
/health-disclosure告知は、連載202枚のフォームとは性格が逆です。
/policy-renewal予備知識ゼロの AI に、公開されている npm パッケージと gunjo.jp の docs だけを渡して組ませました。`tsc` は緑、実行してもエラーはありません。
この業界が gunjo に残したもの
保険は、「金額導出ブロック」を群青のキャンバスとして完成させ、ApprovalWorkflow・CoSign・SignedRecord・ReferenceValue といった「責任の重い操作」のキャンバスが損保／生保／代理店の全層で 組み合わせで組めることを証明しました。最後の営業ポータル（#105）では、ここまで作ったコンポーネントが「全部 組み合わせで組める」状態に到達し、docs のコンポーネント検索も全部名指しで正解──保険5枚で作り切ったと記録されています。