UIXHERO
テスト・評価

AIが作った画面で、実際に起きた29の失敗

自分たちがAIに作らせた業務画面175枚を検品し、実際に起きた失敗を29個並べました。すべて画面の番号つきです。動く画面が出てくることと、出してよいことは別です。各項目に、手元の画面で確かめるための目安を1行添えています。

2026年8月16日
更新: 2026年8月27日
約27分
by Dengen Yosho（DGYS）
#AI生成UI
#UI検品
#デザインレビュー
#デザインシステム
#アクセシビリティ

AIは、画面を作れます。作れた画面を出していいかどうかは、そのあとで別に確かめる必要があります。

この文書は、AIに作らせた業務画面を実際に検品して見つかった失敗を、29個並べたものです。読むだけでも使えます。手元の画面で確かめたい人のために、各項目の末尾に確認の目安を1行だけ添えてあります。

同じ失敗を一度知っておくと、次にAIが出してきた画面を見たときに、同じ箇所が自然と目に留まります。

この29件はどこから出てきたか

出どころは2つです。どちらも公開しています。

1. コールドテスト（175画面）

ボタン・表・入力欄のような、画面を組み立てる単位のことを、コンポーネントと呼びます（以下、コンポーネント）。そのコンポーネントと、使い方の決まりごとを一式にまとめたものが、デザインシステムです。私たちは「群青」という名前で作って公開しています。

その群青を一度も見たことのないAIに、公開している説明書と、コンポーネント一式（そのまま組み込んで使える状態のもの）だけを渡します。それで、現場で実際に使われるような業務画面を1枚ゼロから作らせるのがコールドテストです。医療、建設、物流、公共など20を超える業種で175画面を作らせ、1画面につき1件ずつ記録を公開しています。記録は gunjo.jp/cold-tests（gunjo.jp のコールドテストの記録を新しいタブで開く） にあります。

作らせた画面には、その場で5点満点の採点を付けています。測っているのは「用意したコンポーネントだけでどこまで組めたか」で、画面としての出来ではありません。

以下、この175画面それぞれに付いている通し番号を「#12」のように書きます。

2. 検品（そのうちの2画面）

コールドテストで作った画面のうち2枚を、公開している検品の基準で測り直したものです。2枚とも建設現場の画面で、#174 が工事の工程表、#175 が現場写真の台帳です。

基準は6つの観点に分かれた質問票です。明瞭さ、導線、行動、信頼、、実装性の6つで、この文書もその順に並べてあります。全項目は design-qa.com/framework（design-qa.com を新しいタブで開く） に出しています。

12体のレビュアーが、互いの回答を見ない状態でそれぞれ画面を検分し、画面からの引用を添えて指摘を出します。レビュアーはAIのこともあれば人間のこともあります。AIと人間を区別せず、1つの視点を1体として同じように数えるので、以下の「12体」には人間のレビュアーも含みます。総合判定は「出してよし」「要修正」「要再構築」（部分的な直しでは足りず、作り直したほうが安い状態）の3段階です。12体とは別に、人間の審査担当が1名いて、最後にこの3段階のどれかを決め、報告書に自分の名前を署名として記します。

レビュアーが見たのは画面の静止画です。別に、AIが提出したものを実際に動かした記録もあり、それは29番で扱います。

この2枚は、コールドテストの採点では5点満点の4点でした。検品の判定は2枚とも「要再構築」でした。作れたかと、実際の業務で使い始めてよいかは、別の物差しです。

「コールドテスト175画面」の箱から矢印が伸びて「#174 施工スケジュール」「#175 施工写真台帳」の2画面の箱につながり、その2画面から2本の線が右へ別々に分かれている。片方は「コールドテストの採点＝5点満点で4点（測るのは、作れたか）」、もう片方は「検品の判定＝要再構築（測るのは、出してよいか）」で、同じ2枚に別の物差しが2つかかっているタップして拡大表示

数字の読み方

「12/12」は、12体のレビュアーのうち何体が同じ箇所を指摘したかです。12/12は全員一致を意味します。

スマートフォンのような狭い画面についての指摘は、「2体中2体」のように、その画面を見たレビュアーの人数を分母にして書きます。

証拠のない項目について

29件すべてに、実際に起きた画面の番号が付いています。 数を揃えるために、証拠の無いものを混ぜることはしていません。

29の失敗（一覧）

気になった行から本文へ飛べます。確認するならは、手元の画面で確かめたい人のための目安です。

明瞭さ（Clarity）— この画面が何をする場所か伝わるか

#AIがやった失敗確認するなら
1見出しは具体的なのに、中身が見出しと合っていない見出しやラベルが「何ができる場所か」を具体語で言っていて、その下の中身が実際にそのとおりか
2必要な要素は全部あるのに、どれが主役かが決まっていない初めて見た人が「何をする画面か」を3秒で言えるか。全体の集計と、いま操作した結果の数字が、見た目で区別できるか
3主役が、画面の下へ押し出される一番重要な情報や数字が、スクロールなしで見えるか
40件のとき、次に何をすればいいか書かれていないデータが0件のとき、次にすべきことが画面に出るか
5画面の言葉が、作り手の語彙のまま置かれる画面の言葉が利用者の語彙になっているか。実装の用語や、別の業界の習慣が漏れていないか

導線（Flow）— 次にどこへ行けるか

#AIがやった失敗確認するなら
6戻る、閉じる、取り消しの導線が無い「戻る」「キャンセル」の行き先が予測どおりか
7段階は表示されるのに、その段階を進める操作が無い複数ステップの操作で、現在地と残りが見えるか
8警告は出るのに、そこから次の一手へ行けないタスク完了画面や警告に「次の一歩」があるか
9選んだものが、開いた先で同じ名前・同じ印で確認できない同じ概念が、どの画面でも同じ場所・同じ見た目にあるか

行動（Action）— 迷わず実行できるか

#AIがやった失敗確認するなら
10押した先で何が起きるかが、押す前に分からない作り手が一番押してほしいボタンが1つに絞られていて、名前が動詞になっているか。押した先で何が起きるかが読めるか
11エラーが画面の上にまとめて出るだけで、直し方が書かれていない入力エラーが「その場所の近く」で「直し方まで」言うか
12取り消す道が無い後戻りできない操作に確認があり、そのうえで取り消せるか
13必須と任意の区別も、入力の形式も示されない必須と任意が明示され、入力形式の例が欄の外に添えてあるか
14押したあと、保存されたのかどうかが分からない送信中・処理中の状態が見え、二度押しできないようになっているか

信頼（Trust）— 根拠が伝わるか

#AIがやった失敗確認するなら
15数字はあるのに、いつ時点のものか書かれていない数字や集計結果に、それがいつ時点のものかが添えてあるか
16個人情報や決済を、用途を告げずに求める個人情報や決済を求める前に「何に使うか」を伝えているか
17エラーのときに「エラーが発生しました」しか言わないエラー時に「何が起き、どうすればよいか」を正直に言うか
18同じ事実を指す数字が、1つの画面の中で食い違う日付・金額・単位・件数の表記が正確で、画面全体で一貫しているか
19困ったときに、誰に聞けばいいのかが画面から分からない運営者や問い合わせ先に、1〜2回の操作でたどり着けるか

摩擦（Friction）— 余計に詰まらせていないか

#AIがやった失敗確認するなら
20同じ情報を二度入力させる同じ情報を二度入力させていないか
21選べないものが、選べる顔のまま並ぶ選べないものが、選べる見た目のまま並んでいないか。選択肢が多い場所に、検索や既定値や推奨があるか
22指で押す画面なのに、押す場所が既定の大きさのまま押し間違えやすい距離・大きさになっていないか
23待ち時間に、どれくらい待つのかが出ない待ち時間に進捗や目安が表示されるか
24途中でやめると、入力が全部消える途中でやめても入力が保存され、再開できるか

実装性（Feasibility）— 作ったとおりに、壊れず動くか

#AIがやった失敗確認するなら
25AI自身が入れた見本のデータの時点で、すでに文字が切れている極端なデータ（長い名前・0件・1万件）で崩れないか
26画面が狭いと読めなくなり、そのことを知らせる合図も無い画面幅が変わってもレイアウトが破綻しないか
27見た目が合うコンポーネントを選んで、HTMLの入れ子の規則を破る見た目で選んだコンポーネントが、構造としても正しい入れ子になっているか。実際に動かして落ちないか。押せる見た目のものが本当に押せる要素として作られていて、キーボードだけで操作でき、いまどこを選んでいるか（フォーカスの位置）が見えるか
28状態の違いが、色だけに乗る色だけに意味を持たせていないか。文字との明暗差は足りるか
29うまくいく場合だけが作られている読み込み中・エラー・空・成功の4状態が全部作られているか

明瞭さ（Clarity）— この画面が何をする場所か伝わるか

1. 見出しは具体的なのに、中身が見出しと合っていない

「根切り底 掘削」「基礎配筋 D19@200」という工事写真のラベルの下に、都市の風景、ヤシの木、チューリップ、夕暮れの海が並んでいました。ラベルの書きぶりは正確で、業務の語彙で書かれています。合っていないのは中身のほうです。

施工写真台帳の写真一覧の一部。「床付け完了」「基礎配筋 D19@200」「スラブ上端筋 結束」「柱型枠 建込み」という工事の語彙で書かれたラベルが4枚横に並び、囲みを付けた1枚目の写真はヤシの木の生えた砂浜、囲みを付けた4枚目は桟橋のある夕暮れの海になっている。ラベルは正確なまま、中身だけが工事と関係のない風景写真になっているタップして拡大表示

ラベルが名乗っている内容と、その下の中身が食い違うと、その画面の他の表示すべてが疑わしくなります。読み手は数字も日付も確かめ直すことになります。

2. 必要な要素は全部あるのに、どれが主役かが決まっていない

工程を管理する画面は、現場監督が「今日どこに手を打つか」を決めるためのものでした。その画面について、審査担当はこう書いています。「工程表、の一覧、作業の行、人数といったブロックを並べているだけで、その判断を支える構造になっていない」。必要な要素は全部そろっていました。足りないのは、どれを先に見せるかの決定です。並べることと、どれを先に見せるか決めることは、別の作業です。AIは前者を確実にこなし、後者を飛ばします。

写真を扱う画面では、それが数字の並びに出ました。画面上部に数字を並べた枠があり、「総枚数 8」「本日の撮影 2」「要是正 1」「台帳 選択中 0」が同じ列に同じ見た目で並んでいます。前の3つは全体の集計で、最後の1つは今あなたが選んでいる件数です。性質がまったく違うのに、見た目からは区別できません。

3. 主役が、画面の下へ押し出される

絞り込みの操作が画面の上半分を占め、この画面の主役である写真の一覧が下へ押し下げられていました。12体全員が指摘しています。

狭い画面（スマートフォンのように横幅の狭い画面）では、もっとはっきり出ます。別の画面では、数字の枠が縦に1つずつ積まれ、1画面に1つしか入らない状態でした。本題の一覧にたどり着くまで、何度もスクロールが要ります。狭い画面を見た2体が、2体とも指摘しています。

4. 0件のとき、次に何をすればいいか書かれていない

一覧が空のときに、空の枠だけが出ます。データが無いのか、絞り込みの条件が合っていないのか、まだ読み込み中なのかが読み手には分かりません。

工程表（作業の期間を横棒で表す図）では、これが別の現れ方をしました。期間の棒が1本も引かれていない行があり、まだ着手していないのか、表示している期間の外なのか、そもそも表示できていないのかが区別できませんでした。11体が指摘しています。

5. 画面の言葉が、作り手の語彙のまま置かれる

「出来高」「pt」「KY活動」が説明なしで並んでいました。12体全員が指摘しています。出来高は工事がどこまで進んだかを表す割合、pt はその割合の差を表す単位、KY活動は作業前に危険を予知して共有する現場の活動のことです。業務の中にいる人には通じますが、初めてその画面に来た人には通じません。

反対に、業務には無い言葉を持ち込む事故もあります。工事写真の一覧に、5段階の評価バッジとハートのアイコンが乗っていました。工事写真に点数を付ける業務はありません。ハートも、押せるボタンなのか、すでに付いている印なのかが見た目から分かりません。AIは、よく見かける画面の語彙を、業務の語彙だと思って持ち込みます。

導線（Flow）— 次にどこへ行けるか

6. 戻る、閉じる、取り消しの導線が無い

12体全員が指摘しました。詳細を開くことはできるのに、それを閉じて元へ戻るボタンが画面のどこにも見当たらない状態です。

作る側から見ると、進む道は仕様に書いてあり、戻る道は書いてありません。AIは書いてあるものを作ります。

コールドテスト全体でも同じ形が出ています。段階を追う画面（いま何段目かを並べて見せる作り）のうち4画面で、段階は表示されているのに、前の段階へ戻る手段がどこにもありません。新幹線の予約、駅ナカの提案、生産工程の管理、施主向けの窓口です。進む先が見えているぶん、戻れないことに気づくのが遅れます。

7. 段階は表示されるのに、その段階を進める操作が無い

審査や承認のように、受付から交付まで段階を踏む画面です。段階の並びは正しく表示されました。ただし、それを進める・差し戻すためのコンポーネントは群青にありません。そこでAIは、その処理を自分で書き足していました。入居審査で1回、自治体の窓口業務でもう1回、同じことが起きています。

画面の上では動いて見えます。しかし群青が配っているコンポーネントが、表示崩れや動作の確認を済ませたものであるのに対し、AIが自分で書き足した分は、その確認を通っていません。画面を見ただけでは、どちらがどちらか分かりません。

8. 警告は出るのに、そこから次の一手へ行けない

「確認してください」と書かれた警告が出ているのに、確認する場所への行き方が画面に無い状態です。11体が指摘しました。

完了画面でも同じことが起きます。「送信しました」で終わり、次に何ができるかが書かれていません。

9. 選んだものが、開いた先で同じ名前・同じ印で確認できない

一覧で1件を選ぶと右側に詳細が出るのに、それがどの行を選んだ結果なのかが画面から読めませんでした。工程表では12体全員、写真台帳では10体が指摘しています。

選んだ行に印が残らない、詳細の側に同じ名前が出ない、という小さな欠落の集まりです。1つずつは小さいのに、合わさると読み手は一覧に戻ってもう一度選び直すことになります。

行動（Action）— 迷わず実行できるか

10. 押した先で何が起きるかが、押す前に分からない

「台帳を作成」というボタンがありました。動詞で書かれていて、名前としての不備はありません。それでも、押したら何が起きるのかが押す前に分かりません。下書きができるのか、確定するのか、印刷に回るのか。12体全員が指摘しました。

AIはボタンのラベルを上手に書きます。押した後の説明を書きません。

11. エラーが画面の上にまとめて出るだけで、直し方が書かれていない

入力の誤りが赤い文字で上部にまとめて出るだけで、どの欄のことなのか、どう直せばいいのかが書かれていません。

コールドテストの175画面のうち7画面で、同じことが起きていました。物流と倉庫の作業画面（入荷・ピッキング・格納・出荷・積み込み）に集中していました。手を動かしながら使う画面ほど、誤りをその場で直せる必要があるのに、逆になっています。

12. 取り消す道が無い

6番（戻る、閉じる、取り消しの導線が無い）で取り上げたのと同じ指摘の、別の面です。12体全員が「戻る・閉じる・取り消しの導線が無い」と指摘しました。取り消せない画面では、利用者は操作の手前で止まります。止まらなかった場合は、間違いがそのまま記録に残ります。

削除のような後戻りできない操作に確認を挟むこと自体は、AIも書くことがあります。書かないのは、確認を通した後の取り消しです。

13. 必須と任意の区別も、入力の形式も示されない

入力欄は並んでいるのに、どれが必須でどれが任意なのか、日付をどう書けばいいのかが示されていませんでした。11体が指摘しています。

入力欄の中に薄い灰色で書き方の例を入れて、説明の代わりにするのも同じです。この文字は、利用者が打ち始めた瞬間に消えてしまいます。

14. 押したあと、保存されたのかどうかが分からない

チェックを入れて作業の実施状況を更新する画面で、更新できたという反応が何も出ませんでした。誰がいつ更新したのかも残りません。10体が指摘しています。

押したあとの反応が無い画面では、利用者はもう一度押します。それで二重に登録されるかどうかは、画面の裏で動くシステム側の作りしだいです。画面だけを見ても分かりません。

信頼（Trust）— 根拠が伝わるか

15. 数字はあるのに、いつ時点のものか書かれていない

「最新に更新」というボタンがある画面で、いま出ている数字がいつ時点のものかが書かれていませんでした。12体全員が指摘しています。別の画面には「本日の撮影　2件」という表示がありましたが、その「本日」がいつを指すのかが読めず、9体が指摘しました。

業務の記録として後から見返すとき、この1行があるかどうかで使えるかが決まります。数字が正しいかどうか以前に、いつの数字か分からないものは報告に使えません。

16. 個人情報や決済を、用途を告げずに求める

最初の画面でいきなり全項目を要求し、何に使うのかを書きません。

コールドテストでは3画面で出ました。賃貸の申込、行政の申請受付、転居の届出です。マイナンバー、健康保険証、氏名、生年月日を並べて求めておいて、何に使うのかがどこにも書かれていません。 求める側にとっては手続きに必要な項目でも、入力する人にとっては、渡した先で何が起きるか分からないまま渡すことになります。

17. エラーのときに「エラーが発生しました」しか言わない

何が起きたのか、どうすれば進めるのかを書きません。

コールドテストでは1画面で出ました（#21（gunjo.jp のコールドテストの記録を新しいタブで開く） の「投稿の読み込みに失敗しました」）。ただし詳しく調べた2枚では、むしろ逆でした。工程を管理する画面に出た警告には、原因と、今後の見通しと、次に確認することまで書かれていて、10体が「良い点」として挙げています。AIは説明の文章を書けることがあります。書けないのは、その説明どおりに直すための操作を始める場所（ボタンや入力欄）です。8番の「警告は出るのに、そこから次の一手へ行けない」がそれです。

  • 確認するなら：エラー時に「何が起き、どうすればよいか」を正直に言うか
  • 詳しく：エラーを防ぐ設計

18. 同じ事実を指す数字が、1つの画面の中で食い違う

これが、私たちが見つけた中で最も重い1件です。同じ日の同じ現場の人数が、1枚の画面の中で噛み合っていませんでした。12体全員が指摘しています。

人数の出どころは、画面の中に3つ別々にありました。

  1. 画面上部の数字。現場全体で「本日稼働予定 26名」
  2. 当日の作業予定の行。3行に6名・10名・4名と書かれていて、足すと20名
  3. 作業の種類ごとの詳細カード。「基礎工事」のカードに「本日稼働 8名」

施工スケジュールの画面上部にある指標カードの1枚。囲みを付けたこのカードが「本日稼働予定 26名」「4社・協力会社含む」と出していて、現場全体の人数がここでは26名とされているタップして拡大表示

同じ画面の「本日の状況 — 7/17（金）」にある当日の作業予定。囲みを付けた3行が「基礎 立上り型枠 解体 6名」「2F 配筋（壁・柱）10名」「資材揚重・搬入 4名」で、足すと20名にしかならない。囲みの外にある4行目「場内清掃・KY活動」には人数がなく「管理」とだけ書かれているタップして拡大表示

同じ画面の「基礎工事」の詳細カード。出来高は実績88%・予定96%で「遅延」の印が付いている。囲みを付けた行は「本日稼働 8名」で、当日の作業予定が同じ基礎工事を6名としているのと合わないタップして拡大表示

26名と20名は、どちらも現場全体の人数のはずなのに合いません。さらに3の8名は、同じ基礎工事について2の1行目が6名としているのと合いません。差の理由は、画面のどこにも書かれていません。

つまり「数字が1つ間違っている」問題ではありません。同じ事実についての集計が、画面の中に3つ別々に置かれていることが問題です。表示だけを揃えても、次のデータでまた食い違います。

言葉のほうも揺れます。同じ画面の中で「本日稼働予定」と「本日稼働」が混在し、予定なのか実績なのかを読み手が判断できませんでした。これも12体全員です。

19. 困ったときに、誰に聞けばいいのかが画面から分からない

問い合わせ先もヘルプへの入口も置かれていません。うまくいっているあいだは目に入らないので、無くても画面は完成して見えます。手が止まったときに初めて、行き先が無いことに気づきます。

コールドテストの175画面のうち、問い合わせ先やヘルプを持っている画面は35枚でした。残る140枚のうち、手続きを進めさせて何かを入力させる画面が25枚あります。銀行の振込（口座番号を入れて実行する）、住宅ローンの仮審査（年収と生年月日を入れて申し込む）、フライトの予約（搭乗者の氏名を入れて確定する）、返品の受付（返金が絡む）。どれも、途中で分からなくなったときに人へ聞きたくなる画面です。

摩擦（Friction）— 余計に詰まらせていないか

20. 同じ情報を二度入力させる

郵便番号を入れているのに住所を全部手で打たせます。

コールドテストでは2画面で出ました。どちらも郵便番号の欄と住所の欄が並んでいて、郵便番号から住所を埋める仕掛けがありません。

21. 選べないものが、選べる顔のまま並ぶ

写真を分類するタブが並んでいて、そのうちの1つに「設備 0」と件数0が出ていました。それでも押せる見た目のまま並んでいます。押すと空の一覧が出ます。10体が指摘しています。

選択肢の数そのものは、この画面では問題ありませんでした。12体全員が「無理なく選べる範囲に収まっている」と評価しています。問題は数ではなく、選べないものの見せ方です。

22. 指で押す画面なのに、押す場所が既定の大きさのまま

搭乗手続き、運航状況の案内、マイレージと、指で操作する前提の画面が、コールドテストで3回続けて出題されました。3回とも、押す場所が既定の大きさのまま作られています。群青の側には指で押しやすい大きさを選ぶ設定が用意されていたのに、AIがそれを見つけられなかった、という記録です。

AIは、指定しなければ既定値を使います。既定値はたいてい、机の上でマウスを使う場合の大きさです。

23. 待ち時間に、どれくらい待つのかが出ない

くるくる回るマーク（読み込み中の表示）だけが出て、あと何秒なのか、いま何件目なのかが読めません。

コールドテストでは8画面で出ました。回るマークだけが置かれていて、あと何秒なのか、何件目を処理しているのかが分かりません。振込、レジ締め、返品の受付など、待っているあいだ手を離せない場面に集中しています。

24. 途中でやめると、入力が全部消える

長い入力の途中で別のことをすると、戻ってきたときに空になっています。

コールドテストでは5画面で出ました。いずれも入力欄が8個以上あるのに、下書きを保存する仕掛けがありません。航空券の予約は入力欄が11個あります。

実装性（Feasibility）— 作ったとおりに、壊れず動くか

25. AI自身が入れた見本のデータの時点で、すでに文字が切れている

工種名（工事の種類の名前）という、その表でどの行が何なのかを決める一番大事な列が、AIが自分で入れた見本のデータの時点で、すでに省略記号で切れていました。12体全員が指摘しています。長い文字を入れると崩れる、ではありません。最初から崩れていました。

施工スケジュールの工程表の左半分。左端が工種名の列で、囲みを付けた「土工事（掘削・山…」と「設備工事（電気・…」の2つが省略記号で切れている。囲みの外の「基礎工事」「躯体工事（RC）」「鉄骨建方（PH階）」は切れていない。右へ22・23・24・6/25と日付の列が続き、工期の棒が引かれているタップして拡大表示

同じ画面について、「列の幅に余裕がない」と12体全員が、「長い文字を入れると崩れる」と11体が答えています。写真台帳のほうでも、カードの中の長い文字で崩れると11体が指摘しました。

26. 画面が狭いと読めなくなり、そのことを知らせる合図も無い

狭い画面で工程表を開くと、工事の種類の名前も日付も読めず、横へスクロールできることを示す合図もありませんでした。狭い画面を見た2体が、2体とも指摘していますが、これは狭い画面を担当したレビュアーがそもそも少ないためです。指摘した数の少なさは、問題の軽さを意味しません。

27. 見た目が合うコンポーネントを選んで、HTMLの入れ子の規則を破る

AIが、履歴の説明文を表示するコンポーネントの中にボタンを並べたところ、その画面は動かしたときに落ちました。説明文のコンポーネントは文章を入れる場所として作られていて、その中にボタンの塊を入れることは、画面の書式（HTML）の規則で許されていません。

動かす前に自動で書式を確かめる検査（型チェック）は通ります。この検査は書き方の辻褄を見るもので、動かしたときに何が起きるかは見ないからです。

大見出しの次に中見出しを飛ばして小見出しが来る、ボタンの中にボタンが入る、といった事故も同じ系統です。AIは見た目が合うコンポーネントを選び、それが構造として何であるかまでは確かめません。

28. 状態の違いが、色だけに乗る

工程表の棒が、いまどの状態なのかを色だけで区別していて、凡例も色の丸印が並ぶだけでした。12体全員が指摘しています。

施工スケジュールの工程表。6行の工種に対して工期の棒が3本引かれていて、状態の違いは棒の塗りの色だけで表されている。囲みを付けた下部の凡例は「予定どおり」「要注意」「遅延」「完了」の4つが色の丸印で並ぶだけで、形や記号の違いは付いていないタップして拡大表示

同じ画面で、重要な数字の色が薄くて読み取りにくいという指摘が9体、凡例の色と実際の棒の色が対応していないという指摘が3体ありました。色を使うこと自体が問題ではありません。色以外の手がかりが1つも無いことが問題です。

29. うまくいく場合だけが作られている

これが最後です。エラーも警告も出ないまま通り過ぎるので、いちばん気づきにくい失敗です。

写真台帳の画面を、AIが提出したそのままの状態で動かしたところ、画面が表示されませんでした。サーバー側の処理で止まり、ブラウザにはエラーを示す応答（HTTP 500）が返っていました。下に載せた画面は、同じ原因を開発中に動かしたときの表示です。本番の利用者にはこの文言ではなく、エラーの応答だけが返ります。同じ状態で、28番に出てきた書式の検査（型チェック）はエラー0です。ブラウザに付いている開発者用のログ表示（コンソール）にも、出力は1件もありません。このログだけを見て確認を終える手順では、この状態は通過します。

同じ提出物にかけた3つの確認を、左から右へ並べた図。左は「型チェック」でエラー0。書き方の辻褄だけを見て、動かした結果は見ない。中央は「コンソールの出力」で0件。警告も、止まった理由も出ない。この2つはどちらも素通りと書かれている。右は橙色の枠の「実際に起動」で、画面が出ない。ここで初めて見えた、とある。左の2つの下には「この2つで確認を終える手順では、通過する」と書かれているタップして拡大表示

原因はAIの不注意ではありませんでした。使われていたのは配色を切り替えるコンポーネントです。このコンポーネントは、配色の設定を配る別のコンポーネントで画面全体を囲っておかないと動きません。囲いが無かったため、コンポーネントが配色を受け取れずに止まりました。

動かしたときに出た実行時エラーの表示。「Runtime Error」の下に、囲みを付けた1行で「useTheme must be used within a ThemeProvider」と出ている。配色を読み取る仕組みは、配色を配るコンポーネントの内側で使わなければならない、という意味の英文。下のコードでは、囲いの無いまま置かれた ThemeToggle の行に印が付いている。内部のファイル名は灰色で塗って隠してあるタップして拡大表示

ところが、この前提は公開している説明書のどこにも書かれていませんでした。説明書だけを渡されたAIには、到達しようがなかったというのが調べた結果です。それでも、出てきた画面は表示されませんでした。

読み込み中、エラー、空、成功の4つの状態のうち、AIが確実に作るのは成功だけです。

最後に

29件すべてに、コールドテストの番号が付いています。すべて、私たち自身がAIに作らせた画面です。他社の画面ではありません。だから、どこが悪いかを全部出せます。

検品した2枚は、コールドテストの採点ではどちらも5点満点の4点でした。それでも総合判定は、2枚とも「要再構築」です。丁寧に作られていなかったわけではありません。工程を管理する画面では、12体全員が「良い」と判定した箇所が5つありました。それでも総合判定は「要再構築」でした。

作れたかと、出せるかは、別の物差しです。

ここまで読んで、手元の画面が気になった方へ。

更新のお知らせ

サイトに載せていない実例や、新しい記事のお知らせはこちらで出しています。

読んだ内容を、自分の画面に当てるとき

UIXHEROは、記事を書くほかに、画面の検品・判定、デザインシステムの構築、実装と改善の伴走を受けています。何を頼めばいいか決まっていない段階の相談も、同じ窓口で受けます。

UIXHEROに頼めることを見る

※ 記事の内容についての質問や、書いてほしいテーマの要望も同じ窓口で受けています

記事をシェア

メールでお知らせを受け取る

最終更新: 2026年8月27日

この記事を書いた人

Dengen Yosho（DGYS）

Dengen Yosho（DGYS）

UI/UXデザイナー兼デザインエンジニア デザイン歴25年以上 情報設計〜UIデザイン〜React/TypeScriptによる実装までを一気通貫で担当 大手企業のDXプロジェクトや決済アプリ領域で、デザインリードとして改善と構築を経験 現在はフリーランスとして、プロダクトのUI/UX改善とデザインシステム構築を支援 長年の実務の中で感じてきたのは、 「良いUI」はセンスではなく、再現可能な判断の積み重ねであるということ UIXHEROは、 心理学や行動科学の知見を、現場で使える設計言語に翻訳するための場所 関心領域は「ユーザーの行動が変わるUI」 人の認知・注意・意思決定の構造を理解し、 “なぜそのUIが機能するのか”を言語化することを目指している

XGitHub

あわせて読みたい

この記事に関連する記事をご紹介します

AIを「忖度しない検査役」にする方法論 — 手組みの跡は、足りないコンポーネントの地図

AIにUIを作らせるのではなく、AIに「何が作れなかったか」を書かせる方法論です。予備知識ゼロのAIの「無い」が強い証拠になる理由、手組みの跡を次に作るコンポーネントの仕様として読む手順、AIが正直に書ける環境の作り方をまとめます。

#デザインシステム
#AI生成UI
#UI検品
+1
2026年8月18日
約10分

UI検品の観点「Feasibility（実装性）」とは — 型が通っても画面が出ないことを確かめる3つの手順

Feasibilityは、UI検品で使う6つの観点のうちの6つめです。文字量が増えても崩れないか、狭い画面でも成立するか、運用しても一貫性が保てるかを見ます。静止画では判定しきれないため点を付けません。AIが作った1画面では、型チェックが緑でコンソールも静かなのに画面が出ませんでした。

#UI検品
#デザインレビュー
#実装性
+2
2026年8月12日
約10分

AIが作った画面は、出していいのか｜文脈ゼロのAIに175画面つくらせて分かったこと

生成AIにUIを作らせると、動く画面はかなりの確率で出てきます。では出していいかどうかは何で判断するのか。文脈ゼロのAIにデザインシステムだけで175画面を組ませた記録から、満点の回と最低点の回で何が違ったのかを、実際の画面を並べて確かめます。

#AI生成UI
#UI検品
#デザインレビュー
+2
2026年8月11日
約10分

もっと深く知りたいですか？

ここに掲載されていないトピックについても、リクエストがあれば解説記事を追加します。 わかりにくい点や、具体的な事例について知りたいことがあれば教えてください。

リクエストを送る

その画面、AIに作らせたあと「出していいか」誰が判断していますか？

UIXHERO の知識を、実際の画面の判断に。AIが作ったUIの課題・改善優先度・判断根拠を、 6観点で整理する軽量 Design QA です。

Design QA を見る
記事一覧に戻る