AIにUIを作らせると、既存のコンポーネントが作り直される

この記事の要点

• AIに画面を作らせると、すでにあるコンポーネントや設定項目を見つけてもらえないことがあります。自分たちのコンポーネントを一度も見たことのないAIに175画面を組ませた記録に、在るのに見つからなかった、または見つけるのに手こずった回が6件残っています
• 連続する2回で、逆の結果が出ました。片方は型定義まで開いて見つけ、片方は公開ドキュメントだけを見て見落としています。渡した材料は同じでした
• 見つからなかったコンポーネントの説明文を書き直したところ、次の3回は続けて自力で見つかりました（うち2回は、書き足した用途からAIが自分で広げて当てています）。増えた28語のうち27語は、使う場面の記述です。仕組みの説明は1語しか増えていません

「無い」と報告されたコンポーネントが、前日に作ったものでした

AIに画面を作らせていると、こういうことが起きます。手元にあるはずのものを使わずに、同じものをその場で書き直してくる。指示が悪かったのかと思ってプロンプトを直し、また同じことが起きる。

その瞬間を記録に残せた回があります。

UIXHERO（この記事を書いているチームです）では、コールドテストという検証を続けています。毎回、何も知らない冷えた状態から始めるので、この名前です。使うのは、自分たちで作っているデザインシステム 群青（GUNJO）（gunjo.jp を新しいタブで開く）です。デザインシステムとは、画面を組むためのコンポーネント一式と、その使い方の決めごとをまとめたものを指します。群青を一度も見たことのないAIに、教育・小売・介護といった実在の業務の画面を1枚組ませます。以下、このAIを「予備知識ゼロのAI」と呼びます。記録は1画面につき1件、gunjo.jp/cold-tests（gunjo.jp のコールドテストの記録を新しいタブで開く） に公開しています。この記事で「#71」と書くのは、その通し番号です。

デザインシステムを持っていなくても、話は同じです。社内の共通コンポーネントも、utils に置いた関数も、去年だれかが書いたものも、AIから見れば「説明が付いているか、いないか」でしか区別できません。この記事の「公開ドキュメント」を「README とコードのコメント」に読み替えれば、そのまま当てはまります。

画面を組ませたあと、AIが群青のコンポーネントを使わずにその場で自分で書いた箇所（以下「手組み」）を報告してもらいます。同じものが3つの別の画面で組み直されたら、そこで初めて私たちがコンポーネントとして群青に足します。コンポーネントを作るのはAIではなく、私たちの側です。

教育の業種で、5枚を続けて作らせていたときのことです。#70『時間割』で、行と列が交差するマスにボタンや色を置ける表（ScheduleGrid）を、この決まりに沿って新しく足しました。翌 #71『成績管理』は、生徒と教科を縦横に並べて点数を入れる画面です。縦横に並べる同じ表が要ります。

予備知識ゼロのAIは、こう報告してきました。

固定ヘッダ・固定した先頭列・任意のセル描画を備えた本物の「DataGrid / マトリクス」こそ、最も価値ある欠けているコンポーネントだ。

AIが言う「DataGrid」は、前日に足した ScheduleGrid と同じものです。前日に作ったものそのものです。 足りない機能は1つもありませんでした。上端の見出し行を固定することも、左端の列を固定することも、セルの中身を自由に作れることも、全部入っています。それでも見つかりませんでした。このまま進めば、同じものがもう1つ生まれるところでした。

AIに渡したものは、2つだけです

なぜ見つからなかったのかを話す前に、この検証でAIに何を渡しているかを決めておきます。ここが曖昧だと、この先の話が「AIの出来不出来」に見えてしまいます。

渡すのは2つだけです。公開ドキュメント（gunjo.jp のページ）と、npmパッケージの中身。群青のリポジトリ（開発中のソースの置き場所）は見せません。読めるのは、この2つに入っているものだけです。そして、その中に「AIが説明を読める場所」が6つあります。

渡したもの	AIが読める場所	そこに何が書いてあるか
公開ドキュメント	コンポーネントのページ	作例と、渡せる設定項目の表
公開ドキュメント	用途から引く一覧	「こういう画面にはこれ」を並べたページ
npmパッケージ	呼び出しの入口（index.ts の一覧）	パッケージを開いたとき最初に見える、使える名前の一覧。フォルダ分けされず全部が1枚に並んでいて、用途は書かれていません
npmパッケージ	説明文（コードに書くコメント。JavaScript なら JSDoc）	コードのすぐ横に書いてある短い解説。公開ドキュメントとは別物で、パッケージの中を開かないと見えません
npmパッケージ	種類ごとのフォルダ	表示系・入力系のように、種類でまとめた置き場所。名前の一覧には現れません
npmパッケージ	型定義	そのコンポーネントに何を渡せるかを、機械が読めるように書いた一覧

この6つは、渡した2つの中に最初から入っています。あとに出てくる差は、渡したかどうかの差ではなく、どこまで読んだかの差です。

能力の差ではありません。読んだ場所が違いました

冒頭の例はコンポーネントまるごとの話でしたが、同じことは設定項目1つでも起きます。

小売の画面で、カードの見出しの段を指定する項目が問題になりました。カードとは、見出しつきの枠のことです。見出しの段とは、大見出しの下に中見出し、その下に小見出し、という深さのことで、これが飛ぶと、読み上げソフトを使う人が構造をたどれなくなります。

この項目はすでに実装されていました。書いてあったのは型定義だけです。公開ドキュメントのページには載っておらず、作例は全部、指定なしの書き方でした。

タップして拡大表示クリックして拡大表示

連続する2回で、逆の結果が出ています。

回	どこまで読んだか	結果
#44『レジ締め』	公開ドキュメントを読み、型定義まで開いたと報告	項目を見つけ、見出しの段を正しく整えた
#45『返品処理』	公開ドキュメントだけを見たと報告	見落とし、大見出しの次に中見出しを飛ばして小見出しが来た

渡した材料は、2回とも同じです。違ったのは、そのうちどこまで読んだかでした。どこまで読んだかは、どちらもAI自身の報告によります。

この件で直したのも、コンポーネントではありません。公開ドキュメントの設定項目の表に、1行足しただけです。翌 #46『入荷検品』の予備知識ゼロのAIは、その項目を見つけて使い、段の飛びを作りませんでした。

表に1行足しただけで、翌回の結果が変わった記録です。1回ぶんですが、コンポーネントには触れていません。

「無い」という報告は、無いことの証拠になりません

同じ現象は、誤報としても出ます。#74『面談予約』では、自由記述欄と入力欄に、何を入れる欄かを機械に伝える指定（ラベル）が「無い」と報告されました。実際には #57『看護記録』と #58『手術記録』の時点で実装されていました。#74 のAIがそれを見つけられず、手作業で組み直しただけです。

「欠けている」と「無い」は、報告の言い方が違うだけです。実体はどちらも同じ見落としでした。

175画面のうち、在るものが見つからなかった、または見つけるのに手こずった記録を並べます。

回	見つけにくかったもの	何が起きたか	どう手当てしたか
#45『返品処理』	カードの見出しの段を指定する項目	指定なしのまま使い、段が飛んだ	公開ドキュメントの設定項目の表に1行追加
#71『成績管理』	行と列のグリッド（ScheduleGrid）	前日に作ったものを「欠けている」と報告した	説明文の用途を書き直した
#74『面談予約』	自由記述欄と入力欄のラベルの指定	「無い」と報告して手組み	課題として記録
#83『採用パイプライン』	凡例（ChartLegend）	説明文が図の中での使い方しか書いておらず、図の外では使えないものに見えた。選考の段階ごとの色と意味の対応を手組み	課題として記録
#84『従業員名簿と組織図』	階層の表示（TreeView）	名前の一覧で見つけて組織図に採用。ただし挙げてある用途に組織図が無く、直前まで手組みするつもりでいた	課題として記録
#159『トラック配車』	一括操作つきの表（ActionDataTable）	用途から引く一覧が、一括操作の付いていない表（DataTable）へ誘導した。選んで割り当てる操作を手組み	その一覧に行を追加

この6件は、いずれも実際には在ったものです。うち #45 と #74 はコンポーネントではなく設定項目で、#84 は最終的に見つかっています。

#84 の記録に、いちばん短い診断が残っています。「入口が救い、ドキュメントは救わなかった」。名前の一覧に並んでいたので見つかりましたが、公開ドキュメントには組織図や階層の作例も枠も無く、説明文が挙げている用途にも組織図は入っていなかった、という意味です。

説明文を書き直したら、次の3回で結果が変わりました

ここからは、冒頭の ScheduleGrid の続きです。手を入れたのはコンポーネントではなく、説明文でした。

直す前の、用途を挙げている部分です（説明文全体は70語で、以下はその末尾の12語）。

For timetables, shift rosters, room/resource booking grids and any periods×days matrix.

（時間割、シフト表、部屋や設備の予約グリッド、および時限×曜日のあらゆるマトリクスに）

直したあとです（全体は98語で、以下はその末尾の39語）。

For any rows×columns matrix of rich navigable/editable cells — timetables (periods×days), gradebooks (students×subjects), shift rosters, comparison/cohort matrices, availability and room/resource booking grids. (Not for sortable list data — that is DataTable; not for value-by-color heatmaps — that is HeatmapChart.)

（操作・編集できるセルを並べた、行×列のあらゆるマトリクスに。時間割（時限×曜日）、成績表（生徒×教科）、シフト表、比較のマトリクス、同じ時期に始めた集団（コホート）のマトリクス、空き枠および部屋や設備の予約グリッド。並べ替えできる一覧データには使いません。それは DataTable です。値を色で表す図には使いません。それは HeatmapChart です。）

変わったのは3つです。

1. 用途を挙げている部分の頭から、「時間割の」という限定を外した
2. 使われる場面を3つ足した。「成績表（生徒×教科）」「比較や、同じ時期に始めた集団（コホート）のマトリクス」「空き枠のグリッド」の3つです。名指しした場面は3つから6つになりました
3. 使わない場合を書いた。どういうときに別のコンポーネントへ行けばよいかを、名指しで2つ

挙動も、渡せる設定項目も、1文字も変えていません。

結果は次の3回で出ました。#72『出欠管理』、#73『学習進捗ダッシュボード』（画面内の課題提出の部分）、#74『面談予約』。3回とも、予備知識ゼロのAIが自力で見つけて使いました。#72 の報告に、この記事の主題がそのまま出ています。

「出欠」という語そのものは無いが、「生徒×日付、操作と編集ができるリッチなセル、セルごとの色」がほぼそのまま書いてある。名前の由来になった分野の外でも再利用されるように、コンポーネントをどう説明すべきかの手本だ。

3回のうち、書き直しの効果がはっきり見えるのは #72 と #73 です。引用にある「セルごとの色」などは仕組みを説明した部分にもとからあったもので、「出欠」も「課題の提出」も、直す前にも直した後にも用途として名指ししていません。AIは、書き足した「成績表（生徒×教科）」から自分で広げて当てています。#74 の「予約グリッド」は、直す前から名指しされていた場面なので、見つかったのは当然とも言えます。

なお #74 は、上の表にも別件で載っています。グリッドは見つけたのに、入力欄にラベルを結び付ける書き方は見落とした回です。同じ1回の中で、見つかった側と見つからなかった側が両方出ました。

翌回の結果まで追えた2つの手当てと、その前後の回をまとめると、こうなります。

タップして拡大表示クリックして拡大表示

増えた28語のうち、仕組みは1語だけです

説明文の語数を前と後で比べられるのは、この1件だけです。説明文を「仕組みを説明している部分」と「用途を挙げている部分」に分けて数え直しました。文面は2026年9月8日に、群青の、説明文が書かれているファイルとその変更履歴から取得しています。語数は英語の原文で数えました。

ScheduleGrid の説明文	仕組みの部分	用途の部分	合計
直す前（見つからず）	58語	12語	70語
直した後（3回続けて自力発見）	59語	39語	98語

全体で28語増えていますが、そのうち27語は用途の部分です。仕組みの説明は1語増えただけでした。ここまでは言えます——ただ長くしたのではなく、増えたぶんはほぼ全部が用途だった。

同じように、用途として何が挙がっているかだけを見ると、上の表のうち説明文をまだ直していない3つはこうなります。

ChartLegend（9語） Legend rows for chart series, values, and token-driven markers. （図の系列・値・印を並べる凡例の行）

TreeView（10語） Hierarchical tree with expand/collapse for file explorers and navigation. （開閉できる階層のツリー。ファイルの一覧やナビゲーション向け）

ActionDataTable（12語） Selectable data table composition with bulk actions, row actions, and disabled-action feedback. （選択できるデータ表の組み合わせ。一括操作、行ごとの操作、操作できないときの表示に対応）

どれも仕組みは正確に書いてあります。違うのは、用途がどれだけ挙がっているかです。TreeView が挙げている場面は「ファイルの一覧」と「ナビゲーション」の2つだけで、#84 が探していた組織図は入っていません。ChartLegend が書いている「図の系列」はコンポーネントの部位であって、画面や業務の名前ではありません。ActionDataTable にいたっては、場面が1つも挙がっていません。#159 の画面でAIがやりたかったのは「未割当の案件をいくつか選んで、車両に割り当てる」ことでしたが、ActionDataTable の説明文には、その言葉がどこにも入っていません。

これは、書き直した1件と、直していない3件を並べただけの観察であって、統計ではありません。名前の付け方も、一覧のどこに載っているかも同時に効いています。言えるのは、説明文を直して結果が反転した1件があり、そこで書き足したのが用途だった、というところまでです。

名前と説明文は、別々の手がかりです

説明文だけが効いているわけではありません。同じ記録に、名前で見つかった回と説明文で見つかった回が別々に残っています。

PersonCell は、1人ぶんの表示のかたまり（顔写真か頭文字、名前、肩書を横に並べたもの）です。#85 で作り、次の #86『勤怠管理』で、予備知識ゼロのAIがこう書いています。

人物のセルと承認の流れを手組みしかけて、表示系のコンポーネントをまとめたフォルダを見て見つけた。呼び出し名の付け方に救われた。

手組みしかけた、という報告です。ここで効いたのは名前で、説明文ではありません。なお、このAIが見ていた「フォルダ」は、上の表の呼び出しの入口（名前を1枚に並べた一覧）ではなく、種類ごとのフォルダです。名前の一覧で埋もれたものが、置き場所の分類で見つかることもある、ということです。

一方、PersonCell を作ってから4回目にあたる #89『訪問介護の管理画面』では、AIが挙げた理由が変わります。

説明文が「名簿、テーブル行、担当者ピッカー、承認者行、詳細パネル」を列挙している。この分野でライブラリの最重要の単一コンポーネント。

こちらは説明文です。PersonCell を作ったのは #85 で、人材の業種の画面でした。#89 は介護なので、別の分野です。説明文に挙げてあった「名簿」「担当者の選択」が、別の業種の画面で引っかかりました。

名前も説明文も、どちらか片方で足りるものではないようです。#91『介護記録』では、予備知識ゼロのAI自身が、このライブラリへのいちばん大きな要望を書いています。

1か所にまとめて並べてある約210個の名前がアルファベット順に並んでいて、必要なものが埋もれる。説明文が助けてくれるが、それはパッケージの中身を開かないと見えない。

この「約210」は、名前で呼び出せるものを数えた値です。コンポーネント本体だけでなく、カードの見出しのように単体では使わない部分や、金額を整形する関数のような補助も含みます。コンポーネントが210種類ある、という意味ではありません。

名前が並んでいることと、見つかることは別です。そして説明文は、名前の一覧を眺めているだけでは目に入りません。

自分のコードベースで確かめる4つの手順

ここまでの記録から、そのまま持ち帰れる手順です。デザインシステムを持っていなくても使えます。AIが読むのは、コンポーネントの説明文でも、関数のコメントでも、READMEでも同じだからです。

1. AIが「無い」と言ったら、その働きを表す語で1回検索する。 無いという報告は、無いことの証拠になりません。上の表の6件は、いずれも実際には在りました。AIが言う名前と、自分が付けた名前は違います。#71 でAIが求めたのは「DataGrid」でしたが、在ったのは ScheduleGrid です。名前の丸ごと一致ではなく、「grid」のような部分一致で引いてください。とくに #71 のように、直前の回で作ったばかりのものほど危ない、という点に注意してください。作った本人は在ることを知っているので、疑いません。

2. 説明を、AIが読める場所に2か所以上置く。 1か所にしか無いと、そこを読まなかったAIは落ちます。#44 と #45 の差はそこでした。あなたの環境で候補になるのは、コードのコメント、型定義、README、そして「こういう画面を作るときはこれ」と用途から逆引きできる索引（無ければ作る）です。この検証では、AIの自己申告のほかに、実際にどこを読んだかを追っていません。確実に分かるのは、自分がどこに書いたかだけです。だから、読む順を当てにせず置く数を増やします。

3. 直すのは説明。場面を、その分野の言葉で複数書く。 この記録の中では、AIは作り手が想定した用途の言葉では探しませんでした。その画面の業務の言葉で探しています。「時間割用のグリッド」ではなく「時間割、成績表、シフト表、予約グリッド」です。使わない場合も書いてください。別のコンポーネントへ名指しで送れば、探している人が正しい方へ着きます。

4. 直したかどうかは、次の1回で測る。 次に画面を作らせるとき、前と同じ見落としが起きるかを見ます。指示は同じでなくてかまいません。前に見落とされたものが使われれば、直っています。予備知識ゼロの状態は、前のやりとりを引き継がない新しいセッションで始めるだけで作れます。この記録では2回とも、翌回で見落としが消えました。#45 の見落とし（段の飛び）は #46 で消え、#71 の見落とし（作り直しかけた件）は #72 から #74 まで3回続けて消えています。コンポーネントの中身も、渡せる設定項目も変えずに試せて、次の1回で結果が出ます。

放置したときに出る症状は、不便ではありません

見つけやすさを放置しても、しばらくは動きます。AIは毎回、手元で同じものを組み直すからです。画面は出てきますし、動きます。

出る症状は「不便」ではなく、同じものが2つできることです。

同じことを2か所に書かない、という開発の原則があります（DRY原則）。DRY は Don't Repeat Yourself の頭文字で、繰り返すな、という意味です。これが言っているのはコードの重複で、説明を複数の場所に置くことは当たりません（そちらは手順2で勧めているとおりです）。AIが書くと、この二重化が人間より速く起きるというだけの話です。

機能への投資と、見つけやすさへの投資は、効く範囲が違います。機能を1つ足すと、そのコンポーネントを使う場面に効きます。説明文を1回書き直すと、それ以降にそれを探す全員に効きます。そして書き直しの手間は、説明文1つぶんです。

この検証で見つけやすさの良し悪しがそのまま返ってきたのは、予備知識ゼロの相手に作らせているからです。人間のチームなら、隣の席の人に「あれ、無いんだっけ」と聞けます。ドキュメントが狭くても、口伝えで補えます。予備知識ゼロの相手は聞けません。説明の良し悪しが、見つかったか・手こずったか・見つからなかったか、としてそのまま返ってきます。

AIが、あなたのコードベースにある関数やコンポーネントを二重に作りはじめたら、それは指示の失敗とは限りません。説明が、AIの読める場所に無いという信号かもしれません。確かめるのに要るのは、働きを表す語での検索1回です。

この記事の数字について

• 画面の数と回の番号は、コールドテストの公開記録によります。1回ぶんの画面と、予備知識ゼロのAIの報告は https://www.gunjo.jp/cold-tests/番号 で読めます
• 説明文の文面と語数は、2026年9月8日に、群青の、説明文が書かれているファイルから取得しました。ScheduleGrid の説明文が最後に書き換わったのは2026年6月24日です
• 直す前の ScheduleGrid の説明文は、そのファイルの変更履歴から取り出しました
• 語数は英語の原文で数えています。空白で区切って数え、斜線で並んでいるもの（room/resource など）は2語、ハイフンでつないだもの（value-by-color など）と、×でつないだもの（periods×days など）は1語としました。前後に空白のある記号（× +）は1語に数え、文をつなぐダッシュ（—）は数えていません
• 「名指しした場面」の数え方は、語数とは別です。用途として挙げられている分野を数えたもので、comparison/cohort matrices のように1つのまとまりを指すものは1つと数えました。「あらゆるマトリクス」のように分野を名指ししていない書き方は数に入れていません。直す前の3つは、時間割・シフト表・部屋や設備の予約グリッド。直した後の6つは、これに成績表・比較や同じ時期に始めた集団のマトリクス・空き枠のグリッドの3つを足したものです

関連

• AIが作った画面は、出していいのか — 動いたことと、出してよいことは別だという話。同じ175画面の記録から、点が分かれた理由を見ています
• AIが作った画面で、実際に起きた29の失敗 — 出来上がった画面の側で何が起きていたかの一覧
• 作ってから再発見までの距離が縮む — 見つかるまでの間隔を、デザインシステムが育ったかどうかのものさしにする話。この記事が「見つからなかった側」を見ているのに対して、あちらは「縮んでいく側」を測っています
• デザインシステムの考え方
• DRY原則

この連載は、作者が AI（Claude と Codex）と協働で制作しています。実験・検証の設計、判断、公開前の事実確認は人間が行い、実作業と下書き執筆は AI が担っています。