AI に保険の更新画面を作らせてみた：前と後を並べる部品が、7回目の手組みになった（やってみた #204）
/policy-renewal375px のビューポートで撮影。縦長のページはフレーム内をスクロールします。
解説記事
AI に保険の更新画面を作らせてみた：前と後を並べる部品が、7回目の手組みになった（やってみた #204）
やってみたシリーズ: 自作のデザインシステム
@gunjo/ui（群青）を、群青を一度も見たことのない AI に、実際の画面で組ませていく連載。保険の10枚目、この業種の締めです。お題は定期保険の満期が近づいた契約者が、更新するかどうかを決める画面。同じ保障でも年齢が上がるぶん保険料が上がるので、続けるか、見直すか、やめるかを決めます。
結果：4/5。画面の中心が、また無かった
予備知識ゼロの AI に、公開されている npm パッケージと gunjo.jp の docs だけを渡して組ませました。tsc は緑、実行してもエラーはありません。幅の条件はスマホ（375px）だけを渡しています。パソコン幅で開くと、スマホ幅の画面がそのまま中央に置かれます。
この画面の中心は「いまの契約と、更新後の条件を並べて比べる」ことです。保険金額・保険期間・毎月の保険料・満了年齢を項目ごとに並べ、どこが変わるかを示す。
その部品がありませんでした。 表の素材から76行の手組みです。
比較表の不足は #14・#25・#186・#190・#191・#202 に続いて7回目。3つの別々の画面で必要になったら作る運用なので、とっくに作るべきものでした。
ただし今回は形が違います。#190（3件の物件）や #186（3つのプラン）は「N件を並べる」形でしたが、こちらは2列で、片方が基準です。今回の AI は API の案まで出していました。「行×2列 ＋ 変化したかの印 ＋ 増減のスロット」（#132）。
今回の主役：比較表を除けば、既にあるもので組み上がった
この画面で使われた部品は31種類です。手で組んだ箇所は下に3つ書きますが、それ以外、つまり契約の中身、更新後の選択肢、満了の日付、これまでの経過、確認のダイアログは、既にあるもので入りました。
助けられた記録もあります。表のセルに数値の増減を入れようとして最初は別の部品を選び、失敗したところで「カード型のあれと違って表のセルに収まる」と説明文に書いてあるのを見つけて解決しています。
部品の当たり外れが出たところ
良かった記録が2つ、足りなかった部品が1つ、不具合が1つ、遠回りが1つです。
スクリーンリーダーへの読ませ方が、これまででいちばん良かった
比較表を画面読み上げソフト（スクリーンリーダー）にどう読ませるかが秀逸だったので、記録します。
本物の表にして、列と行の両方に見出しを付ける。ここまでは定石です。今回の AI が加えたのは、表の直前に要約文を置いたことでした。
変わるのは 毎月の保険料 と 満了年齢 と 保障が続くのは の3つです。保険金額と保険期間は変わりません。
しかもこれをスクリーンリーダー専用にせず、全員に見せています。 理由が書かれていました。「晴眼者にとっても一番役に立つ情報なので、隠す理由がなく、隠さないことで二重読み上げも起きない」。
変化の有無も色に載せていません。バッジで「変わります」「変わりません」と文字にし、増減も「増えます」「のびます」と言葉にする。保険料の増加が既定では緑（良いこと）になってしまうので、色の意味も反転させていました。
部品が無かったもの、もう1つ：見出しと本文
小さいようで効いた不足がありました。見出しと本文の部品がありません。
カードの見出しと画面の上部バー以外は、文字の大きさ・太さ・色を毎回クラスで手書きすることになります。今回の AI は20箇所以上に書き、こう評していました。「デザインシステムとしては一番ずれやすい箇所」（#789）。
「落ち着いた説明ブロック」も無く、2つ手組みしています。警告の部品は声が大きすぎ、カードの入れ子は重く、注記の部品は文書向けの見た目。静かに何かを説明する枠が空いていました。
あえて使わなかった部品
今回いちばん考えさせられた記録です。
「更新しないと保障がなくなります」という注意に、確認を求める警告バナーが一番効きそうでした。ところがあえて使っていません。理由が書かれています。
設計思想が「アレルギー・禁忌・パニック値」向けの割り込む警告で、今回の「脅さない」という要件と正面から衝突するため
そして、「名前と機能に引かれて選ぶと、トーンを間違える型の部品だと思います」。
#203（告知）では同じ部品が「軽く流させない」の正しい抽象として評価されました。同じ部品が、片方では正解で、片方では不正解。トーンという観点が、部品選びに効いてくることの例です。
見つかった不具合
副産物として、実装の不備が1つ報告されました。金額の内訳を出す部品が、行の中でラベル側に役割を付けていません。スクリーンリーダーから見ると表の行構造が壊れており、項目名が落ちる可能性があります。
この部品は #37 以来8業種で使われている最頻出のものです。目で見る分には正しく出るので、実装を読んだ AI が初めて気づいた形でした（#786）。
名前で迷ったところ
比較表を探して、時間割の部品で長く止まっています。説明文に「比較・コホートの行列」と書いてあるからです。実体は操作できるグリッドで、読むだけの比較には重すぎました。「一番時間を使った遠回り」と記録されています。
これは #202（保険料試算）でも独立に起きました。説明文の用途列挙が、2体を同じ場所で止めた形です（#763）。
今回 直したものは無い：課題に記録だけにした
保険の10枚を通して、新しく作ったコンポーネントは1つもありません。2列の比較表（#132）、見出しと本文（#789）、金額の内訳がスクリーンリーダーで壊れる件（#786）は、いずれも課題に記録するだけにしました。
学び：同じ部品が、片方では正解で、片方では不正解になる
前の #203（告知）では、確認を求める警告バナーが「軽く流させない」の正しい抽象として評価されました。今回の AI は同じ部品を、あえて使っていません。「脅さない」という要件と正面から衝突するからです。
つまり部品の当たり外れは、機能だけでは決まりません。トーンという観点が、部品選びに効いてくる。 名前と機能に引かれて選ぶと、この型の部品はトーンを間違えます。
比較表の側にも似た形がありました。7回目の手組みですが、今回のものは #190（3件の物件）や #186（3つのプラン）の「N件を並べる」とは違い、2列で、片方が基準です。回数だけ数えていると、作るものを1つに丸めてしまいます。
コンポーネント化スコアボード（作成済 27個）
直近で加わったのは #180 の CommentThread（27個目）です。ただし取り込みの手続きが止まっていて、この5枚で AI に渡した版（@gunjo/ui 0.1.0-beta.2）には入っていません。#181 からこの回まで、新しく作ったものはありません。
3回目待ち：2列の比較表（#132）が7回目、見出しと本文（#789）が1回目です。
保険の進捗：10枚で、事業者側と契約者側がそろった
- 事業者向け：#101 保険金の査定、#102 契約の管理、#103 保険金の支払、#104 引受の査定、#105 代理店ポータル
- 契約者向け：#200 契約者マイページ、#201 給付金の請求、#202 保険料の試算、#203 告知、#204 更新（この回で締め）
既にあった5枚はすべて事業者側でした。今回の5枚で契約者側が加わり、事業者向けの画面と加入者向けの画面がそろいました。契約者向けがゼロだった業種が対称になったのは、この連載で初めてです。
手で組んだ割合は10〜25%で、業務側の既存5枚より高くなりました。理由は前の3組と同じで、業務画面の部品が業種を越えて育っている一方、消費者向けの層はまだこれからだからです。
この5枚の収穫。3つ目に達したものがエラーの一覧と完了画面の成功状態の2件（どちらも作ります）。新しく記録したものが読み取り専用の階層、年単位の期間、複数の入力を1つの問いにまとめる部品、見出しと本文の4件。実際の不具合が5件です。
中でも #201 で「前の回が見つけた不具合を、今回の AI は素通りした」ことは、この連載のやり方そのものの検証になりました。1体では「たまたま気づいた」で終わる。2体目が気づかなかったことで、その不具合がどれくらい隠れているかまで分かります。
次回予告（やってみた #205）
介護・福祉へ移ります。この業種の6枚目で、施設の連絡帳を家族が見る画面です。
試す
- gunjo.jp ／ 素の表 Table ／ 増減 Delta ／ 期限バッジ ExpiryBadge ／ npm
@gunjo/ui／ GitHub ／ 前回まで #1〜#203 - GunjoUI by UIXHERO
同じ部品が、片方では正解で、片方では不正解になる。トーンという観点が、部品選びに効いてきます。
この連載は、作者が AI（Claude と Codex）と協働で制作しています。実験・検証の設計、判断、公開前の事実確認は人間が行い、実作業と下書き執筆は AI が担っています。
使用した @gunjo/ui コンポーネント
この画面のソースが直接 import しているコンポーネントです。
cold AI が組み上げた実コード
ファイル名をクリックでソースを展開できます。