AI に給付金の請求画面を作らせてみた：前の回が見つけた不具合を、今回の AI は素通りした（やってみた #201）
/claim-filing375px のビューポートで撮影。縦長のページはフレーム内をスクロールします。
解説記事
AI に給付金の請求画面を作らせてみた：前の回が見つけた不具合を、今回の AI は素通りした（やってみた #201）
やってみたシリーズ: 自作のデザインシステム
@gunjo/ui（群青）を、群青を一度も見たことのない AI に、実際の画面で組ませていく連載。保険の7枚目です。お題は入院した契約者が給付金を請求する画面。請求の入力から、書類の提出、出したあとの進み具合、不備の差し戻しまでを1枚で見せます。
この回で確かめたかったこと
前の #192（入居者マイページ）で、写真を添える部品がキーボードから一切操作できないという重い不具合を見つけました。そのときの AI は実装を読んで気づき、採用を見送っています。
今回も写真の提出がある画面です。別の AI が同じ判断をするかを見れば、この欠陥がどれくらい気づかれやすいかが分かります。
結果：4/5。そして、気づかれなかった
予備知識ゼロの AI に、公開されている npm パッケージと gunjo.jp の docs だけを渡して組ませました。tsc は緑、実行してもエラーはありません。発注の条件はスマホ幅（375px）だけで、パソコン幅は要求していません。パソコン幅で開くと、この画面はスマホ幅のまま中央に置かれます。
今回の AI は、その部品を採用しました。中身は別の不足で自作していますが（下の「足りなかったもの」）、キーボードの問題には、最後まで触れていません。
これは重要な結果です。この欠陥は実装を読まないと気づけない。目で見る分には動くので、普通の採用の流れなら本番に出ます。優先度を上げる根拠になりました（#764）。
なお今回の AI は、自分で作った隠しファイル入力に画面読み上げソフト（スクリーンリーダー）から隠す指定とタブ順から外す指定を付け、名前は見えているボタンに持たせています。皮肉なことに、これが本体が採るべき形でした。
今回の主役：進み具合には、配送追跡の部品が効いた
進み具合（受付・書類の確認・査定・支払い）に最終的に使われたのは、配送を追跡するための部品でした。名前も説明も、保険の画面からいちばん遠く見えます。
それでも選ばれた理由がはっきりしています。段階ごとの日付を持ち、状態の言葉を丸ごと差し替えられ、いまどの段階かをスクリーンリーダーに伝えられるのが、これだけだったから。「これから・完了・要対応」「いまここ」と言葉を入れ替えて使っています。
同じことが #192（修繕の進み具合）でも起きていました。「日付が要る段階表示」の唯一解なのに、名前と説明が隠しているというのが、これで2回目です。
この画面で使われた部品は37種類。手で組んだのは、下に書く写真まわりの119行と、フォームの24行のラッパーでした。
足りなかったものと、説明文が招いた3つの危なさ
自作に回った不足が1つ、説明文や既定のせいで意味が変わってしまうものが3つ出ました。
足りなかったもの：カメラの口と、写真のサムネイル
写真を添える部品は採用されましたが、中身は自作でした。不足が2つあったからです。カメラを起動する口が無いこと（診断書を撮って出す画面なのに）と、写真のサムネイルが出ないこと（内蔵の一覧はファイル名の文字だけで、「診断書がちゃんと写っているか」を確かめられない）。約119行の手組みでした。
危なかったこと：契約者が自分の請求を承認できる画面
もう1つ、ひやりとする発見がありました。
査定の進み具合を出すのに、承認フローの部品を見に行っています。説明に「給付・申請の審査」と書いてあるので、保険金請求の査定そのものに読めるからです。
ところが実体は査定する側が押す操作パネルでした。進める・差し戻す・却下するボタンと、操作した人の記録。これを契約者の画面に置くと、契約者が自分の請求を承認できてしまいます。
今回の AI は型定義を読んで気づき、撤退しました。説明文に業務名を書くことの危うさが、いちばん分かりやすい形で出た例です（#763）。
フォームの説明書が、また役割を逆に書いていた
#193（売却査定）で「説明書に従うと、スクリーンリーダーへの配線が全部消える」という問題を報告しました。今回、独立に同じ罠を踏んでいます。
今回の AI の記録で、役割の分かれ方がはっきりしました。スクリーンリーダーへの配線を持つのは片方、幅を揃える指定を持つのはもう片方。どちらか一方では成立しません。今回は両方を重ねる24行のラッパーを自作して解決しています。
本人の言葉です。「これは利用側が毎回発見する類の話ではないと思います」（#771）。
同じフォームの中で配線の経路が3通りに割れることも見つかりました。ふつうの入力欄は自動で配線され、日付の入力欄だけは外から渡せず、選択の入力欄は明示的に受け取れる。「日付欄だけエラー表示の仕組みが違う」という妥協が残っています。
選択カードの「良い知らせ」枠
小さいけれど、意味が反転する発見がありました。選択カードには強調用の枠がありますが、色が緑で固定です。
今回の AI は「別の口座を指定する」カードに「本人確認書類の提出が必要になります」を入れたところ、不利な条件が良い知らせに見えたので説明文に移しました（#791）。
今回 直したものは無い：課題に記録だけにした
この回でも新しく作ったコンポーネントはありません。写真を添える部品のキーボード操作（#764）は優先度を上げる根拠が増えただけで、用途別の対応表が誤った部品を名指しする件（#763）、フォームの説明書（#771）、選択カードの強調枠（#791）も、いずれも課題に記録するだけにしました。
学び：気づかれなかったことにも、記録の価値がある
同じ不具合を、1体目は実装を読んで見つけ、2体目は素通りしました。この差そのものが結果です。 1体だけなら「たまたま気づいた」で終わりますが、2体目が気づかなかったことで、この欠陥がどれくらい隠れているかまで分かりました。
使わずに引き返した理由を書かせるのと同じくらい、気づかなかったことにも記録の価値がある。連載のやり方に、材料が1つ増えた回です。
コンポーネント化スコアボード（作成済 27個）
直近で加わったのは #180 の CommentThread（27個目）です。ただし取り込みの手続きが止まっていて、この回の AI に渡した版（@gunjo/ui 0.1.0-beta.2）には入っていません。#181 からこの回まで、新しく作ったものはありません。
3回目待ち：選択カードの強調枠（#791）1回目。フォームの説明書（#771）は #193 に続いて2回目です。
保険の進捗：契約者向けの2枚目
- 事業者向け：#101 保険金の査定、#102 契約の管理、#103 保険金の支払、#104 引受の査定、#105 代理店ポータル
- 契約者向け：#200 契約者マイページ、#201 給付金の請求（いまここ）、#202 保険料の試算、#203 告知、#204 更新
次回予告（やってみた #202）
保険の8枚目。医療保険の保険料を試算する画面です。年齢や入院日額を動かすと月額が変わります。#191（住宅ローンの試算）で見つかった「つまみでも直接入力でもできる部品が無い」という不足が、別の画面でも再現するかを見ます。
試す
- gunjo.jp ／ 配送の段階 RouteStops ／ ファイルの取り込み FileUploader ／ 選択カード RadioCard ／ npm
@gunjo/ui／ GitHub ／ 前回まで #1〜#200 - GunjoUI by UIXHERO
1体目が気づき、2体目が素通りした。気づかれなかったことにも、記録の価値があります。
この連載は、作者が AI（Claude と Codex）と協働で制作しています。実験・検証の設計、判断、公開前の事実確認は人間が行い、実作業と下書き執筆は AI が担っています。
使用した @gunjo/ui コンポーネント
この画面のソースが直接 import しているコンポーネントです。
cold AI が組み上げた実コード
ファイル名をクリックでソースを展開できます。