自作のデザインシステム
@gunjo/ui（群青／gunjo.jp（gunjo.jp を新しいタブで開く）） を、群青を一度も見たことのない 予備知識ゼロのAI に170画面組ませてきた連載のまとめ第4弾。普通は「AIがUIを作る」なのに、なぜ私は「AIに検査させる」側に立ったのか——その方法論を書きます。
「AIに任せる」の逆パターン
AIとUIの話で私たちがよく聞くのは「AIにコンポーネントを生成させる」「AIにプロトタイプを組ませる」——AIに手伝ってもらう方向の話です。
私は逆をやりました。「予備知識ゼロのAIに、群青のドキュメントとnpmパッケージだけを渡して、実業種の画面を組ませる」を170回繰り返してきました。目的はAIにUIを作らせることではなく、AIが「何ができなかったか」を測ることでした。
これは「AIにUIを作らせる」でも「AIがUIを作れるか試す」でもありません。AIを「忖度しない検査役」として使う、という第三の方法論です。
人間の「気がする」は、思ったより弱い
デザインシステム設計者として、こういう言葉に何度も遭遇します。
- 「このコンポーネント、なんとなく足りない気がする」
- 「使う人は多分こう使いたいはず」
- 「ここは拡張しておいた方がいい気がする」
全部、大切な直感です。でも直感の中身をほぐしてみると、たいていこう混じっています。
- 過去に別のライブラリで見た UI（無意識の借用）
- 昔、使う人に言われた 要望の記憶
- 自分が使いたいから 欲しい機能
- 未来こう使われるはず の予測（希望的観測）
これらは全部正当ですが、今の使う人が本当に詰まっているかどうかは、直感からは読めません。「気がする」で作ったコンポーネントは、5つ目の画面で誰も使わない、をよく生みます。
予備知識ゼロのAIの「無い」は、なぜ強いのか
同じ「無い」を、予備知識ゼロのAIに書いてもらうと、意味が変わります。
予備知識ゼロのAIにとって、群青は「公開docsとnpmパッケージの中身」だけが世界のすべてです。過去の経験も、昔の要望の記憶も、「うちの流儀」もない。このAIが「このコンポーネントは無い」と書くとき、それは:
- 見えるものと見えないものを、機械的に分けた結果
- 希望的観測で埋められていない
- 経験による補完がない
だからこそ「本当に無い」の強い証拠になります。予備知識ゼロのAIは「なんとなく足りない気がする」を書きません。書いてあることか、書いていないかを、そのまま報告します。
例えば #171 HR書類ダウンロードのAIはこう書きました。
DocumentRowにあたるコンポーネントが無い。なぜListCardを使わないかというと、ListCard.onSelectはカード全体を1つの<button>にするから。でも書類の行には、独立した3つの操作対象（選択チェックボックス／プレビューのタップ面／ダウンロードボタン）が要る。ダウンロードボタンをListCardのボタンに入れ子にすると、不正なHTMLになり、フォーカス順も壊れる。だからListCardは構造的にこの行を持てない。
タップして拡大表示クリックして拡大表示
これは人間が書ける言葉ですが、「なんとなく気がする」からは出てきません。予備知識ゼロのAIは「docsにこう書いてあり、npmパッケージにimportできる名前を全部見て、この行の3つの操作対象を並べる方法が無かった」を、具体的に書いています。
手組みの跡は、足りないコンポーネントの正確な地図
もう1つ大事なことは、AIが「これは組めなかったので手組みしました」と書いてくれた手組みの内容そのものが、次に作るべきコンポーネントの初期仕様になることです。
例えば #90ケアプランでAIは「利用者↔担当ケアマネの関係が組めなかった」と書き、独自のJSXで、アバター2つ＋中央にラベルを並べました。この手組みの構造が、そのまま RelationshipRow の実装仕様になっています——from / to に PersonCellProps、中央に relationshipLabel。
手組みは、使う人が何を欲しかったかの直接の証拠です。
- 何を隣に置いたか（並び順）
- 何を色で示したか（色の意味）
- 何を独立した操作対象にしたか（アクセシビリティ）
- どの動きを組み立てたか（操作）
これらが次に作るべきコンポーネントの骨格を、そのまま教えてくれます。手組みは、どのコンポーネントが足りないかを示す正確な地図なのです。
地図で切り分ける：「群青の問題」か「AIの理解不足」か
AIの報告を読むときに大事なのは、「これは @gunjo/ui 側の問題か、AIの理解が不足しているだけか」を切り分けることです。
同じ「無い」報告でも、中身が違えば切り分けが変わります。
| 報告の中身 | 切り分け | 対応 |
|---|---|---|
「ListCard.onSelect で独立ダウンロードボタンを入れると、ボタンの中にボタンになる」 | 群青の問題 | 作る（DocumentRow） |
「時間帯を選ぶコンポーネントが無い（TimePicker は正確な時刻用）」 | 対応表の問題 | 対応表を是正 |
「Tabs の使い方が分からない」 | AIの理解不足 | docsを明確化 |
「Meter を使ったが、direction="higher-is-better" があるのに気づかなかった」 | docsの見つけやすさ | JSDocに用途を追加 |
この切り分けを 1回のコールドテストだけで決めないのが、群青の運用ルールです。「3つの別々の画面で独立に同じ手組みが出る」までは判断を保留します。1回だけの「無い」は、単なるAIの理解不足かもしれません。3回同じ形が出るなら、それは「本当に無い」の強い証拠です。
AIの「正直さ」は、環境で作る
AIが正直に「無い」を書くには、環境の設計が要ります。迎合を避け、使う人の視点を保つ工夫が必要です。
① 文脈を渡さない：群青のソースは見せない。「公開docsとnpmパッケージだけ」を厳守します。既存の実装を見ると、「うちの流儀」を推測してしまうからです。
② 質問形式で誘導しない：「このコンポーネントは使いましたか？」と聞くと、AIは迎合して「はい」と答えがちです。「あなたが手組みした部分と、その理由を報告してください」と、使う人が現場で書くはずの振り返りを求めます。
③ 別プロセスで隔離する：予備知識ゼロのAIは独立したプロセスで走らせ、メインの文脈を汚さない。同じセッション内で「あの回で作ったコンポーネントは……」という記憶が滲むと、予備知識ゼロでなくなります。
④「組めなかった」を弱点として扱わない：AIが「これは組めなかった」と書くとき、それを失敗ではなく貴重な報告として扱います。組めなかった箇所こそが、群青の次に作る候補だからです。
AIは「頼る道具」より「忖度しない検査役」として最も強い
170画面を回してきて、私は予備知識ゼロのAIの使い方を「作らせる」ではなく「測らせる」に定めました。
- 作らせる（AIにUIを組ませる）→ AIが善意で手組みして埋めてしまうので、「本当は無いコンポーネント」がどれか見えなくなる
- 測らせる（AIに「何ができなかったか」を書かせる）→ 足りないコンポーネントの場所が正確に浮かぶ
AIの「本当に見えないものを、見えないと書ける力」は、実は人間には難しい力です。人間は経験や希望的観測で埋めてしまう。AIは「書いてある」か「書いてない」かをそのまま報告できる。だから AIは「頼る道具」より「忖度しない検査役」として最も強い、と私は思っています。
これはUIの話に限らないはずです。API設計の検証、docsの読みやすさ、CLIの見つけやすさ——「予備知識ゼロのAIに、公開情報だけ渡して、詰まった箇所を報告してもらう」は、多くの分野で機能する方法論のはずです。170画面のコールドテストで見えた、群青の一番普遍的な学びです。
まとめ
- 人間の「気がする」は、経験・偏見・記憶の混合で弱い
- 予備知識ゼロのAIの「無い」は、書いてあるか / 書いてないかを機械的に分けた強い証拠
- 手組みの跡は、次に作るべきコンポーネントの初期仕様
- 「群青の問題 / 対応表の問題 / AIの理解不足」を 3回確認で切り分ける
- AIの「正直さ」は環境設計で作る（文脈を渡さない / 質問形式で誘導しない / 別プロセスで隔離 / 「組めなかった」を貴重扱い）
- AIは「作らせる」より「測らせる」側で最も強い
「予備知識ゼロのAIは、優秀な正直者だった」——170画面かけて、この1行を証明した連載でした。手組みされた跡は、どのコンポーネントが足りないかを示す正確な地図。その地図をたどって、群青はここまで来ました。
関連
- /cold-tests/why（考え方のページ）（gunjo.jp のコールドテストの記録を新しいタブで開く） — 3回確認の方法論
- 『ユースケース別の対応表』の落とし穴
- 「作るべき理由」には強さの段階がある
- 作ってから再発見までの距離が縮む
- 総集編（Zenn）（Zenn を新しいタブで開く）
この記事のもとになった記録は、本にまとめました
『あなたがAIにUIを作らせると、何が起きるか』
予備知識ゼロのAIに、実在する業種の業務UIを175枚作らせ続けた記録です。何が組めて、何が組めなかったか。全175回の採点と、生まれた26コンポーネントの年表を載せています。
- Zenn版（Zenn を新しいタブで開く）（序章と第7章は無料で読めます）
- Amazon Kindle版
この連載は、作者がAI（Claude）と協働で制作しています。実験・検証の設計、判断、公開前の事実確認は人間が行い、実作業と下書き執筆はAIが担っています。
