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回そろったので、⁠トーンは部品の守備範囲か⁠という論点として記録しました（#795）。

足りなかったもの：複数の入力を1つの問いにまとめる部品

構造の側でも大きな不足が出ました。⁠いくつかの入力欄やボタンを「1つの問い」としてまとめる部品⁠がありません。

フォームの項目を作る部品は⁠単一の入力欄を前提⁠にしています。ところが「はい／いいえ」も「いまの状態（完治・通院中・経過観察・分からない）」も、中身は選択のまとまりなので、ラベルの結び方が効きません。「年＋月」のように2つの入力を1つの問いにする部品もない。81行の手組みでした。

この形の不足は⁠5例目⁠です（#183 のラジオ、#193 の選択入力、#195 の選択カード、#191/#202 のつまみと数値入力、そして今回）。⚠️ ⁠個別に塞ぐより、群のための項目部品を1つ足すほうが早い⁠かもしれません（#794）。

⁠エラーの一覧⁠も3回目に達しました（#183・#193・今回）。3つの別々の画面で必要になったら作る運用なので、これは作ります（#793）。

今回の AI の見立てです。⁠「この2つが条件表示の部品と同じ解像度で入っていたら、この画面は250行短く、アクセシビリティももっと一貫していた」⁠。

スクリーンリーダーへの伝え方が良かったので記録します

「はい」で項目が増えることを、⁠3層⁠で伝えていました。

⁠答える前⁠：質問の説明に「『はい』を選ぶと、病名・時期・いまの状態をおうかがいする欄が開きます」を入れる。スクリーンリーダーでは、はい／いいえと一緒にこの説明も読まれます。⁠答えると何が増えるか⁠が、選ぶ前に耳に入る形です。答えたあとに気づく形にしない。

⁠開いた瞬間⁠：条件表示の部品が領域の名前と通知を付けてくれる。

⁠目で見る側⁠：「これは答えるべき？」の開閉を、はい／いいえの⁠上⁠に置く。選ぶ前に手間が読めるように。

もう1つ、判断として良かった点。⁠送信ボタンを押せなくしていません⁠。未了のまま押すと同じエラー一覧が出ます。理由の書かれた説明とセットで、⁠「理由の無い押せないボタンは、この画面がいちばん壊れる形」⁠と書かれていました。

今回 直したものは無い：課題に記録だけにした

この回でも新しく作ったコンポーネントはありません。トーンの論点（#795）と、問いをまとめる部品（#794）は、課題に記録するだけにしました。エラーの一覧（#793）は3回目に達したので作る対象ですが、この回の時点ではまだ作っていません。

学び：構造は部品が持てる。トーンは、まだ書き手に残る

条件で開く、確認を求める、注記でやわらかく言う。⁠構造⁠はここまで部品が持っていました。けれど「急がせない」「分からないと答えてよい」には、部品の側に居場所がありません。この画面のトーンをいちばん決めていたのが手書きのチェックボックス5個だったことが、そのまま証拠になっています。

これが直すべき不足なのか、それとも⁠部品の守備範囲の外⁠なのかは、まだ決めていません。#178（施主ポータル）・#192（入居者マイページ）に続いて3回目なので、論点として立てたところです。

コンポーネント化スコアボード（作成済 27個）

直近で加わったのは #180 の CommentThread（27個目）です。ただし取り込みの手続きが止まっていて、⁠この回の AI に渡した版（@gunjo/ui 0.1.0-beta.2）には入っていません⁠。#181 からこの回まで、新しく作ったものはありません。

3回目待ち：エラーの一覧（#793）が #183・#193 に続いて3回目に到達（作る対象）。トーンの論点（#795）も #178・#192 に続いて3回目。問いをまとめる部品（#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⁠

構造は部品が持てる。トーンは、まだ書き手に残ります。