AIは、画面を作れます。作れた画面を出していいかどうかは、別に確かめる必要があります。
UI裁判は、AIが生成したUIを、公開された物差しで1画面ずつ測る連載です。測るのは制作物で、使う物差しと、判定が出るまでの筋道を毎回そのまま公開します。
第1回の題材は、UIXHERO自身の画面です。だから、どこが悪いかを全部出せます。
1. 検品したもの
対象は、デザインシステム @gunjo/ui（群青（gunjo.jp を新しいタブで開く））のコールドテスト#175「施工写真台帳」です。
コールドテストは、群青を一度も見たことのないAIに、公開されているドキュメントとnpmパッケージだけを渡して、実在の業務画面を1枚組ませる実験です。#175のお題は建設・建築。現場監督が使う施工写真台帳で、撮影日・工種・撮影場所でひもづけた写真の一覧、絞り込み、拡大表示、検査の是正記録、報告書用の選択までを1画面にまとめたものです。ルートは /construction-photos。
このラウンドのコールドテスト採点は 4/5でした。既存のコンポーネントだけで大半が組め、tsc --noEmit はエラー0、デスクトップとモバイルの両対応です。
⚠️ 4/5は「組めたか」の採点で、これから行う検品は「出せるか」の判定です。物差しが違うので、この2つの数字は同じ画面の上で共存します。 この記事は、その2つがどこまでずれるかの記録です。
検品の物差しは6観点です。Clarity（明瞭さ）・Flow（導線）・Action（行動）・Trust（信頼）・Friction（摩擦）・Feasibility（実装性）。12体のレビュアー（AIもしくは人間）がそれぞれ独立に画面を検分し、引用つきの指摘を出し、スコアは各指摘の重要度から機械的に決まります。総合判定——出してよし／要修正／要再構築の3段階——は、審査担当が判断して署名します。
採点と判定の実物は design-qa.com（design-qa.com を新しいタブで開く） で公開しています。以下の数字はそこに載っているものと同じです。
2. 静止画で測る — 5観点
まず、動かさずに画面そのものを測ります。
タップして拡大表示クリックして拡大表示
出荷されている #175 の全画面。原寸は gunjo.jp/cold-tests/175（gunjo.jp のコールドテストの記録を新しいタブで開く） で見られます
| 観点 | スコア | |
|---|---|---|
| Clarity（明瞭さ） | 2/5 | 要対応 |
| Flow（導線） | 3/5 | 許容 |
| Action（行動） | 3/5 | 許容 |
| Trust（信頼） | 3/5 | 許容 |
| Friction（摩擦） | 3/5 | 許容 |
括弧内の数字は、その指摘に声を寄せたレビュアーの数です。
Clarity — 2/5
写真の中身がラベルと不一致（8枚全てがストックフォト・12/12）。全12体がCriticalを立てた
「根切り底 掘削状況」「基礎配筋 D19@200」というラベルの下に、都市の風景、ヤシの木、チューリップ、夕暮れの海が並んでいます。検査記録を扱う画面に、中身と無関係な写真が入っている状態です。
実験の素材としては問題ありません。ここで測っているのは、出せるかどうかです。12体全員が、この1点にCriticalを立てました。 画面が名乗っている内容と実際の中身が食い違うと、その画面の他の表示すべての確度が疑われます（認知負荷・一貫性）。
Flow — 3/5
戻る・閉じる・取り消しの導線が無く（12/12）、右パネルがどの選択の結果か分からない（10/12）
右のパネルに写真と入力欄が出ていますが、何を選択した結果それが出ているのかが画面から読めません。同じ状態が上部の指標カードにも出ていて、「台帳 選択中 0」が「総枚数 8」「本日の撮影 2」と同じ列に、同じ見た目で並んでいます。総数の報告と、いま自分が選んでいる件数は、性質のまったく違う情報です（ヤコブの法則）。
Action — 3/5
「台帳を作成」を押した後に何が起きるか書かれていない（12/12）。必須／任意・入力形式の表示も無い（11/12）
この画面の主な仕事は「絞り込む → 選ぶ → 台帳を作る」です。右上に「台帳を作成」があり、機能としては通っています。しかし、押した先で何が起きるのかが、押す前に分かりません（アフォーダンス）。
審査担当はここに1点を足しています。サムネイルに乗っている ★4.0 / ★5.0 の評価バッジと ♡ のアイコンです。工事写真に点数を付ける業務はありません。♡ も、押せるボタンなのか、すでに付いている状態の表示なのかが見た目から判別できない。「重要」「要確認」のようなラベルであれば、業務の語彙として読めます（シグニファイア）。
Trust — 3/5
「本日の撮影 2」の基準日が分からない（9/12）
数字は出ているのに、いつ時点のものかが書かれていません。現場の記録では、この1行が後から効きます（フィードバック）。
Friction — 3/5
絞り込みが主役の一覧を押し下げ（12/12）、0件の「設備 0」も押せてしまう（10/12）
絞り込みが画面の上半分を占め、この画面の主役である写真の一覧が下に押し出されています。0件と表示されているタブが押せてしまう点も、同じ系統です（段階的開示）。
静止画で測れるのは、ここまでです。ただし6観点のうち1つは、この方法では採点できません。
3. 静止画では測れない観点 — 実装性
Feasibility（実装性）は、静止画では判定しきれないため所見のみ・非採点という扱いです。文字が増えても崩れないか、実際に動くのか——止まった絵からは決まりません。#175の静止画からの所見は「カード内の長い文字列でレイアウトが崩れる（11/12）」でした。
この回は自前の画面なので、そこから先まで踏み込めます。dev サーバを立て、該当ルートを開きました。
AIが提出した状態のまま開いたところ、画面が描画されませんでした。
⨯ Error: useTheme must be used within a ThemeProvider
at ignore-listed frames { digest: '198647918' }
GET /<route> 500 in 719ms
タップして拡大表示クリックして拡大表示
3つの状態を測っています。
| 状態 | HTTP | tsc --noEmit |
|---|---|---|
<ThemeToggle /> をヘッダに置く（AIが提出した元の状態） | 500 | エラー0 |
同じものを <ThemeProvider> で包む | 200 | エラー0 |
ThemeToggle を除去（実際に出荷された #175） | 200 | エラー0 |
環境は @gunjo/ui 0.1.0-beta.1（当時のbaseline）／Next.js 16.2.9 (Turbopack)／React 19.2.4。
型検査は3つの状態すべてで緑です。それでも、1つだけ画面が出ない。さらに、ブラウザのコンソールにはエラーが1件も出ません。サーバ側のレンダリングで落ちるためです。コンソールだけを見て確認を終える手順では、この状態は通過します。
⚠️ いま公開されている #175 の画面を開いても落ちません。 ThemeToggle は検品の時点で除去済みです。落ちたのは、検品前のAIの提出物です。第2章で測ったのは、除去して出荷したあとの画面です。
4. 判定
6観点が出揃ったので、導出ルールに通します。判定はスコアから機械的に決まり、人の判断が入る箇所は1つだけです。
Critical が1件以上ある（Clarity・12体全員）
↓
分岐は「修正コスト」の1点のみ
↓
直す工数 vs 作り直す工数 → 作り直す方が安い
↓
判定 = 要再構築
唯一の判断点は、Criticalの重さ——直す工数と、作り直す工数のどちらが安いかです。ここだけが審査担当の判断で、あとはスコアを入れれば決まります。
判定: 要再構築
根拠: Clarity / Critical（12/12）
写真の中身がラベルと不一致。8枚すべてがストックフォト。
Flow / Action / Trust / Friction はいずれも 3/5。
実装性は静止画では非採点。ただし提出物は実行時に HTTP 500 で描画されず、
`tsc --noEmit` はエラー0、ブラウザのコンソールにも出力なし。
意味: 画面が名乗る内容と中身が食い違うと、他の表示の確度も疑われる。
型検査を通り、コンソールが静かでも、画面は出ないことがある。
出るかどうかは、動かさなければ分からない。
次の一手: 部品の差し替えではなく、この画面が何を選ばせる画面なのかを決め直すところから。
テーマ切り替えの部品は、外すか、テーマの提供元で包む。どちらでも解消する。
「次の一手」は方向だけを書きます。具体的な修正手順と実装案は、有料の診断の範囲です。
5. 原因は、AIの不注意ではない
500の原因を追うと、AI側の問題ではありませんでした。
ThemeToggle は内部で useTheme() を呼び、context が無ければ throw します。コンポーネント側の設計としては妥当です。前提が満たされていない状態を黙って動かすより、明示的に落ちる方が正しい。
問題は知識源の側でした。群青の公開ドキュメントには、theme 関連のページが1枚もありません。docs/theming のページも4つのAPIに触れておらず、唯一の記述である docs/adoption.md にも、Provider が必須だとは書かれていません。
コールドテストの条件は「公開ドキュメントとnpmパッケージの中身だけ」です。その条件下では、この前提条件に到達する経路が存在しません。デザインシステム側の欠陥です。issue #711 として起票済みです。
所感
ぱっと見よくできている風で、よくよく見ると破綻している。コールドテスト——AIが作ったレベル——では4/5でも、人間が目で見ると全然ダメ。
これが、この画面に対する審査担当の総評です。
何も知らないAIが、公開ドキュメントだけで群青を使ってここまで組んだこと自体は、良い結果です。コンポーネントは効いていて、tsc は緑で、モバイルにも対応している。そのうえで、UIとしては出せない。「作れた」と「出せる」が別だということの、実例です。
AI生成UIに検品が要る理由は、AIの出力が雑だからではありません。作れる速さと、出していいかを判断する物差しが、まだ釣り合っていないからです。
第2回は、この画面を骨格から作り直します。 要再構築という判定に対して、実際に何をどう変えたのか。作り直したあとに同じ物差しでもう一度測り、判定がどこまで動くかまで公開します。
有料の診断では、ここまで出します → 鑑定書の見本（#174 施工スケジュール・全21ページ）（design-qa.com を新しいタブで開く）
あなたの画面でやります → design-qa.com/ui-trial（design-qa.com を新しいタブで開く）
関連リンク
- 今回の題材（コールドテスト #175 の記録）：gunjo.jp/cold-tests/175（gunjo.jp のコールドテストの記録を新しいタブで開く）
- 6観点の採点基準と、判定済み3画面の実データ：design-qa.com（design-qa.com を新しいタブで開く）
- デザインシステム
@gunjo/ui（MIT）：gunjo.jp（gunjo.jp を新しいタブで開く） ／ GitHub - UX用語の出典：UXリファレンス
この記事は、UIXHEROがAI（Claude）と協働で制作しています。検品の設計・判断・公開前の事実確認は人間が行い、実作業と下書き執筆はAIが担っています。
GunjoUI by UIXHERO
