AI に給与明細ダウンロード画面を作らせてみた — DocumentRow が生まれた、ListCard では「構造的に」作れない理由（やってみた #171）

⁠やってみたシリーズ⁠: 自作のデザインシステム @gunjo/ui（群青）を、群青を一度も見たことのない AI に実際の画面で組ませていく連載。今回は⁠残った"足りないコンポーネント"の掘り起こし⁠（書類ダウンロード狙い）——⁠従業員セルフサービスの書類ダウンロード⁠（給与明細・賞与・源泉徴収票・在職証明書・各種申請書）。HR・給与のマイページです。

結果 — 4/5。ダウンロード書類の行が3回目でコンポーネントに

型チェックも通り、モバイル・デスクトップ両対応。群青を一度も触っていない AI の感想：

⁠日本の消費者向け・ポータル画面に、本当に強いライブラリ。⁠ 必要なコンポーネントはほぼ揃っていて、モバイル優先・最初からアクセシブル・説明文がこの画面のために書かれたよう。1点だけ減らしたのは、構造的な"足りないコンポーネント"が1つ＝⁠ダウンロード書類の行が無い⁠こと。

今回の見どころ — DocumentRow が3回目でコンポーネントに（ListCard では「構造的に」作れない）

ダウンロードできる書類の行（ファイルのアイコン＋名前＋PDF・サイズ・発行日＋ダウンロードボタン＋一括選択のチェック）——ListCard を使いたくなります。でも予備知識ゼロの AI は、⁠構造的な理由⁠で却下しました：

AI「ダウンロード書類の行にあたるコンポーネントが無い。なぜ ListCard を使わないか？ ListCard は onSelect を付けると、⁠カード全体が1つのボタンになる⁠。でも書類の行には、⁠独立した3つの操作対象⁠が要る——選択チェックボックス・（プレビュー用の）タップ面・ダウンロードボタン。ダウンロードボタンを ListCard のボタンの中に入れると、⁠ボタンの中にボタン＝不正な HTML⁠ になり、キーボードのフォーカス順も崩れる。だから ListCard は構造上、この行を作れない。追加すべき一番大事なものは DocumentRow＝先頭のコントロール＋ファイル種別のアイコン＋名前＋補足情報＋⁠独立した末尾のボタン⁠で、3つの操作対象それぞれをアクセシブルに扱えるもの。帳票・明細・書類・添付のあらゆる画面が、これを毎回手作りしている。」

⁠ダウンロード書類の行は #168（帳票DL）・#169（月次レポートDL）・#171（HR書類DL）で3回目＝「3回確認」成立。その場で作りました⁠：

• ⁠DocumentRow⁠＝先頭のコントロール（一括選択のチェックボックス）＋ファイル種別のアイコン＋名前＋補足情報（PDF・124KB・発行日）＋⁠独立した末尾のダウンロードボタン⁠。
• ⁠行は1つのボタンではなく <div>⁠＝選択・プレビュー・ダウンロードの⁠3つの操作対象を独立に保てる⁠＝ListCard には構造上できないこと。
• SectionList で年・種別ごとにグループ化（NavRow↔SettingGroup と同じ関係）。
• ⁠docs のコンポーネント検索も修正⁠＝正直に「書類行の専用コンポーネントは無い」と認めていた所を、DocumentRow に向け直しました。
• ブラウザで4行・各行に⁠独立したチェックボックスと独立したダウンロードボタン⁠を確認（PR#429）。⁠群青に加わったコンポーネントは24個目。⁠

学び — 「既存コンポーネントでは構造的に無理」は、一番強い"作るべき根拠"

これまでの「3回確認」の根拠は「コンポーネントが無い（足りない）」「docs のコンポーネント検索が間違った候補に誘導した」でした。#171 は⁠一番強い根拠＝既存コンポーネントでは構造的に無理⁠：

• ListCard は近い（先頭・タイトル・補足・末尾の枠がある）。
• でも onSelect を付けるとカード全体が1つのボタンになるので、独立したダウンロードボタンを入れられない＝⁠HTML の入れ子ルール（ボタンの中にボタンは不正）が物理的に禁じます⁠。

これは「ListCard を拡張すれば済む」話ではありません——⁠ListCard の設計（行全体＝1つの選択ボタン）が、「複数の操作対象」という要件と根本的に両立しない⁠。だから別のコンポーネント（DocumentRow＝行は <div>、中に独立したボタンを複数持つ）が必要でした。⁠「既存コンポーネントでは型やアクセシビリティが合わない」より一段強い「HTML の構造上できない」が、最も反論の余地のない"作るべき根拠"⁠です。予備知識ゼロの AI がこれを言葉にできたから、迷いなく「ListCard の拡張」ではなく「DocumentRow の新設」に進めました。

気づいた点（良かったこと）

• ✅ ⁠docs のコンポーネント検索が正直⁠＝「ダウンロード書類行の専用コンポーネントは無い」とそのまま認めた（無理にでっち上げなかった）＝#162 で見た「自分から認める"足りないコンポーネント"」。
• ✅ SectionList（年グループ）/NavRow（発行申請＝#168 で作ったものの再確認）/FilterChips/BottomActionBar すべてそのまま使えた。
• 🟡 Dialog は組み立て式（すぐ使える簡易版ではない）で、使い方を読まないと取り違えやすい＝簡易版 SimpleDialog を提案。

⁠今回コードで作ったのは DocumentRow⁠（ダウンロード書類行の"足りないコンポーネント"を解消）。4/5・DocumentRow を新設・docs のコンポーネント検索を修正。

これまでに群青へ加わったコンポーネント（24個）

…NavRow / Statistic / OriginDestination / ⁠DocumentRow⁠（このまとまりで11個を作成/拡張） 進行中：MatchCard（1回目）・SimpleDialog（1回目）

進捗

• 運輸5モード完走 ✅／残りの"足りないコンポーネント"の掘り起こし：Statistic・OriginDestination・DocumentRow をコンポーネント化
• 残り：MatchCard 1回目（二者間のペア）

次回予告（やってみた #172）

• 足りないコンポーネントがほぼ出尽くした（残りは MatchCard 1回目のみ）。⁠新しい業種へ⁠（運輸・会計以外＝エネルギー/通信/建設/官公庁/医療 など）か、MatchCard 狙いの深掘り。※次回までに決めます。

試す

• ⁠gunjo.jp⁠ ／ ⁠DocumentRow⁠（新）／ ⁠SectionList⁠ ／ ⁠NavRow⁠ ／ npm @gunjo/ui ／ ⁠GitHub⁠
• ⁠GunjoUI by UIXHERO⁠

DocumentRow が生まれた——「既存コンポーネントでは構造的に無理（ボタンの中にボタンは不正な HTML）」は、型やアクセシビリティの違いより一段強い、最も反論の余地のない"作るべき根拠"でした。