AI に保険の告知画面を作らせてみた：「構造は正しく出してくれて、温度は全部こちらに残した」（やってみた #203）
/health-disclosure375px のビューポートで撮影。縦長のページはフレーム内をスクロールします。
解説記事
AI に保険の告知画面を作らせてみた：「構造は正しく出してくれて、温度は全部こちらに残した」（やってみた #203）
やってみたシリーズ: 自作のデザインシステム
@gunjo/ui（群青）を、群青を一度も見たことのない AI に、実際の画面で組ませていく連載。保険の9枚目です。お題は生命保険の告知。申し込む人が病歴や通院を申告する画面で、事実と違うことを書くとあとで給付金が受け取れなくなったり、契約が解除されたりすることがあります。
この画面が難しい理由
告知は、連載202枚のフォームとは性格が逆です。
これまでのフォームは全部「早く終わらせたい」ものでした。申込、依頼、注文。ところが告知は急がせてはいけません。しかも聞く内容は病歴・通院・服薬という、答えたくない情報です。そして「はい」と答えると項目が増えるので、正直に答えるほど手間が増える構造になっています。
急がせない・追い詰めない・でも省略もさせない。 このトーンが部品で作れるかを見るのが、この回の狙いでした。
結果：4/5。構造は出せて、温度は残った
予備知識ゼロの AI に、公開されている npm パッケージと gunjo.jp の docs だけを渡して組ませました。tsc は緑、実行してもエラーはありません。
画面の下端には、「5問中 N 問に回答」という進み具合と、確認へ進むボタンの帯が固定で貼りついています。スクリーンショットはページ全体を1枚につないで撮っているので、この帯は縦の途中に写ります。
今回の AI の総括を、そのまま引きます。
群青は構造は正しく出してくれて、温度は全部こちらに残した。
効いた部分：条件で開く節と、確認を求める警告
この画面で使われた部品は37種類。手で組んだのは、下に書く問いをまとめる部品の81行と、トーンを作るチェックボックス5個が中心でした。
条件表示の部品が効きました。「はい」を選んだときだけ詳細が開く、という構造です。素で組むと出現の合図を落としがちで、画面読み上げソフト（スクリーンリーダー）の利用者には黙って画面が伸びます。今回の AI は驚いていました。説明文に「申告のフォーム（配偶者控除）」と業務名が明記されていたからです。この1つで画面の誠実さが変わった、と。
確認を求める警告バナーも評価されています。「軽く流させない」の正しい抽象で、文章ではなく状態なので送信をゲートできる。しかもトーンを一段下げるとスクリーンリーダーの割り込みも弱まる作りでした。今回の AI の言葉です。「4文の説明を割り込みで読み上げるのは怒鳴っているのと同じ。トーンに連動しているのは良い設計」。
注記の部品については、こう書かれていました。「このキットで唯一『人がしゃべっている』音がする部品」。警告の部品は5つのトーンが全部システム通知の声なので、「分からないままで結構です」を言うには強すぎる、と。
部品に居場所が無かったぶんは、こちらで作った
トーン、問いをまとめる部品、増える項目の伝え方。この3つは部品の側に無く、今回の AI が自分で組んでいます。
作れなかった部分
「急がせない」は、部品が逆を向いていました。
用意されているのは進捗バー、段階表示、下部の固定ボタン。全部が推進力の装置です。とくに段階表示は「3ステップ、さあ行こう」に引っぱる。そのモメンタムを文章で買い戻すことになった、と書かれています。
「省略させない」の9割は自前でした。検証、エラーの一覧、項目ごとの表明。部品の形で助けが来たのはチェック一覧だけです。
そして決定的な一文。「この欄は『分からない』と答えてよい」を知っている部品が無い。この画面のトーンをいちばん決めていたのは、手書きのチェックボックス5個でした。
この評価は #178（施主ポータル）の「温かさはコピーとアイコンで作っている」、#192 の「業務システム寄りに硬い」に続く3回目です。3回そろったので、トーンは部品の守備範囲かという論点として記録しました（issue#795）。
足りなかったもの：複数の入力を1つの問いにまとめる部品
構造の側でも大きな不足が出ました。いくつかの入力欄やボタンを「1つの問い」としてまとめる部品がありません。
フォームの項目を作る部品は単一の入力欄を前提にしています。ところが「はい／いいえ」も「いまの状態（完治・通院中・経過観察・分からない）」も、中身は選択のまとまりなので、ラベルの結び方が効きません。「年＋月」のように2つの入力を1つの問いにする部品もない。81行の手組みでした。
この形の不足は5例目です（#183 のラジオ、#193 の選択入力、#195 の選択カード、#191/#202 のつまみと数値入力、そして今回）。⚠️ 個別に塞ぐより、群のための項目部品を1つ足すほうが早いかもしれません（issue#794）。
エラーの一覧も3回目に達しました（#183・#193・今回）。3つの別々の画面で必要になったら作る運用なので、これは作ります（issue#793）。
今回の AI の見立てです。「この2つが条件表示の部品と同じ解像度で入っていたら、この画面は250行短く、アクセシビリティももっと一貫していた」。
スクリーンリーダーへの伝え方が良かったので記録します
「はい」で項目が増えることを、3層で伝えていました。
答える前：質問の説明に「『はい』を選ぶと、病名・時期・いまの状態をおうかがいする欄が開きます」を入れる。スクリーンリーダーでは、はい／いいえと一緒にこの説明も読まれます。答えると何が増えるかが、選ぶ前に耳に入る形です。答えたあとに気づく形にしない。
開いた瞬間：条件表示の部品が領域の名前と通知を付けてくれる。
目で見る側：「これは答えるべき？」の開閉を、はい／いいえの上に置く。選ぶ前に手間が読めるように。
もう1つ、判断として良かった点。送信ボタンを押せなくしていません。未了のまま押すと同じエラー一覧が出ます。理由の書かれた説明とセットで、「理由の無い押せないボタンは、この画面がいちばん壊れる形」と書かれていました。
今回 直したものは無い：課題に記録だけにした
この回でも新しく作ったコンポーネントはありません。トーンの論点（issue#795）と、問いをまとめる部品（issue#794）は、課題に記録するだけにしました。エラーの一覧（issue#793）は3回目に達したので作る対象ですが、この回の時点ではまだ作っていません。
学び：構造は部品が持てる。トーンは、まだ書き手に残る
条件で開く、確認を求める、注記でやわらかく言う。構造はここまで部品が持っていました。けれど「急がせない」「分からないと答えてよい」には、部品の側に居場所がありません。この画面のトーンをいちばん決めていたのが手書きのチェックボックス5個だったことが、そのまま証拠になっています。
これが直すべき不足なのか、それとも部品の守備範囲の外なのかは、まだ決めていません。#178（施主ポータル）・#192（入居者マイページ）に続いて3回目なので、論点として立てたところです。
コンポーネント化スコアボード（作成済 27個）
直近で加わったのは #180 の CommentThread（27個目）です。ただし取り込みの手続きが止まっていて、この回の AI に渡した版（@gunjo/ui 0.1.0-beta.2）には入っていません。#181 からこの回まで、新しく作ったものはありません。
3回目待ち：エラーの一覧（issue#793）が #183・#193 に続いて3回目に到達（作る対象）。トーンの論点（issue#795）も #178・#192 に続いて3回目。問いをまとめる部品（issue#794）は同じ形の不足として5例目です。
保険の進捗：契約者向けの4枚目
- 事業者向け：#101 保険金の査定、#102 契約の管理、#103 保険金の支払、#104 引受の査定、#105 代理店ポータル
- 契約者向け：#200 契約者マイページ、#201 給付金の請求、#202 保険料の試算、#203 告知（いまここ）、#204 更新
次回予告（やってみた #204）
保険の10枚目で、この業種の締めです。定期保険の満期が近づいた契約者が、更新するかどうかを決める画面。同じ保障でも年齢が上がるぶん保険料が上がるので、続けるか、見直すか、やめるかを決めます。
試す
- gunjo.jp ／ 条件で開く節 RevealSection ／ 確認を求める警告 SafetyBanner ／ 注記 DocNote ／ npm
@gunjo/ui／ GitHub ／ 前回まで #1〜#202 - GunjoUI by UIXHERO
構造は部品が持てる。トーンは、まだ書き手に残ります。
この連載は、作者が AI（Claude と Codex）と協働で制作しています。実験・検証の設計、判断、公開前の事実確認は人間が行い、実作業と下書き執筆は AI が担っています。
この回の発見
上の記事から抜き出した、この回で分かったことです。状態は記事の時点ではなく、コンポーネント側のいまの実測です。
この回で要ると分かったもの
- 「はい」と答えたときだけ、病名や時期を書く欄が開きます。欄が増えたことは画面読み上げソフトにも伝わるので、目で見ている人だけが変化に気づく、ということが起きません。
病歴の問い（生命保険の告知）自分の画面で確かめる 答えによって欄が増える画面を読み上げだけで進めて、欄が増えたことが分かるか確かめてください。
状態 対応済み - 事実と違う申告をするとどうなるかを、読み飛ばせないように見せられます。注意書きを読んでくださいと文章で頼むのではなく、読んだという印を付けるまで送信を止められます。
重要事項の確認（生命保険の告知）自分の画面で確かめる 重い注意書きを置いた画面で、読んだという印を付けないまま先へ進めてしまわないか確かめてください。
状態 対応済み
この回でつまずいたところ
- 「はい・いいえ」や「完治・通院中・経過観察・分からない」のように、選択肢のまとまりを1つの問いとしてまとめるコンポーネントがありませんでした。
問いの組み立て（生命保険の告知）原因 フォームの項目のコンポーネントが単一の入力欄を前提にしていて、選択肢のまとまりや、年と月のように2つの入力で1つになる問いに、問い全体の見出しを持たせられないためです。自分の画面で確かめる 選択肢のまとまりを1つの問いとして置いた箇所で、選択肢よりも先に問いの文が読み上げられるか確かめてください。
状態 未修正・直し方記録済み - 入力が済んでいない項目が何件あるかと、それぞれの箇所へ飛べる一覧を出すところを一から書きました。3つの別々の画面で同じものが要ったので、コンポーネントとして作ることに決まりました。
送信時のエラー表示（生命保険の告知）原因 フォームに、エラーの件数と各項目への案内をまとめて出す仕組みが無いためです。自分の画面で確かめる 必須の項目を空のまま送信して、残りが何件でどこにあるかが1か所に出るか確かめてください。
状態 未修正・直し方記録済み - 急がせない、追い詰めない、分からないと答えてよい。この落ち着いた雰囲気を支えていたのは、コンポーネントではなく、病歴の質問に添えた5つの短い説明文の言葉づかいだけでした。
画面全体の調子（生命保険の告知）原因 用意されているのは進み具合のバー、いま何段目かを示す表示、画面の下に貼り付く操作ボタンの列だけで、どれも先へ進ませるための道具なので、急がせたくない画面では文章で落ち着かせるしかないからです。自分の画面で確かめる 答えたくないことを聞く画面を開いて、急がせない雰囲気を支えているのが説明文だけになっていないか確かめてください。
状態 追跡中
使用した @gunjo/ui コンポーネント
この画面のソースが直接 import しているコンポーネントです。
cold AI が組み上げた実コード
ファイル名をクリックでソースを展開できます。