この記事の要点
- Feasibility（実装性）は、UI検品で使う6つの観点のうちの6つめです。文字量やデータ量が変わっても壊れないかを見ます
- この観点だけ、点を付けません。 崩れるか、動くかは、止まった絵からは決まらないためです
- AIが作った1画面は、型チェックがエラー0、ブラウザのコンソールも静かなのに、開くと画面が出ませんでした
Feasibility（実装性）とは何を見る観点か
UI検品では、1つの画面を6つの観点に分けて見ます。Clarity（明瞭さ）、Flow（導線）、Action（行動）、Trust（信頼）、Friction（摩擦）、Feasibility（実装性）の6つです。
このうち Feasibility が見るのは、実装と運用の上で壊れにくい作りかです。確かめるのは3つ。
- 文字量・データ量が増減しても、崩れない構造か
- 狭い画面・文字の拡大・多言語でも、成立し続けるか
- 運用（更新・追加）で、一貫性を保ち続けられる作りか
3つに共通しているのは、いま見えている状態ではなく、これから変わる状態を見ていることです。今日きれいに見える画面が、来週データが増えたときにも同じように見えるか。そこを問います。
この観点だけ、点を付けない
6つのうち、Feasibility だけスコアを作りません。 検品では所見だけを書きます。
理由は単純で、止まった絵からは決まらないからです。文字が3倍になったときに崩れるかどうかは、崩れるまで分かりません。実際に動くかどうかも、動かさなければ分かりません。
判定を空欄にしているのではなく、静止画で分かる範囲と分からない範囲を分けている、ということです。分からないものに点を付けると、その点数が独り歩きします。
自分の画面のFeasibilityは、自分では判定できない
ここでの壁は、いちばんはっきりしています。自分が入れたデータで動かしているからです。
作りながら使うデータは、たいてい短くてきれいです。「根切り底 掘削状況」のように、ちょうどよく収まる長さ。件数も、手で作った数枚。その条件でだけ、画面は完成して見えます。
本番のデータは違います。建物名が40文字あり、備考欄に改行が5つ入り、写真が800枚ある。 その状態を見ていないので、崩れることに気づけません。
もう1つ、自分の環境で動いていることも判定になりません。 これは実例で見ます。
実例：AIが作った施工写真台帳のFeasibility
材料は前回までと同じ、デザインシステム 群青（GUNJO） で作られた画面です。群青を一度も見たことのないAIに、公開ドキュメントとnpmで配っている中身だけを渡して組ませた、建設業の施工写真台帳です。
| 観点 | スコア |
|---|---|
| Clarity（明瞭さ） | 2/5 |
| Flow（導線） | 3/5 |
| Action（行動） | 3/5 |
| Trust（信頼） | 3/5 |
| Friction（摩擦） | 3/5 |
| Feasibility（実装性） | 静止画では非採点 |
静止画からの所見は「カード内の長い文字列でレイアウトが崩れる」で、12体中11体が指摘しました。
この回は自前の画面なので、そこから先まで踏み込めます。dev サーバを立てて、実際に開きました。
型は緑、コンソールも静か、それでも画面が出ない
AIが提出した状態のまま開いたところ、画面が描画されませんでした。
タップして拡大表示クリックして拡大表示
提出された状態のまま開いたところ。画面ではなくエラーが出ました
3つの状態を測っています。
| 状態 | HTTP | tsc --noEmit |
|---|---|---|
| テーマ切り替えをヘッダに置く（AIが提出した元の状態） | 500 | エラー0 |
| 同じものをテーマの提供元で包む | 200 | エラー0 |
| テーマ切り替えを除去（実際に出荷された画面） | 200 | エラー0 |
型検査は3つの状態すべてで緑です。 それでも、1つだけ画面が出ません。
さらに、ブラウザのコンソールにはエラーが1件も出ません。 サーバー側のレンダリングで落ちるためです。コンソールだけを見て確認を終える手順では、この状態は通過します。
原因は、AIの不注意ではなかった
落ちた原因を追うと、AI側の問題ではありませんでした。
テーマ切り替えの部品は、内部でテーマの提供元を参照します。提供元が無ければ、黙って動くより明示的に落ちるほうが正しい。部品の設計としては妥当です。
問題は知識源の側でした。群青の公開ドキュメントには、テーマ関連のページが1枚もありません。 唯一の記述にも、提供元が必須だとは書かれていませんでした。
コールドテストの条件は「公開ドキュメントとnpmパッケージの中身だけ」です。その条件では、この前提条件に到達する経路が存在しません。 デザインシステム側の欠陥として起票しています。
自分の画面で確かめる3つの手順
最初に挙げた Feasibility の3つを、自分の画面で確かめます。手順はその3つに1つずつ対応しています。
| 手順 | 確かめること |
|---|---|
| 手順1 | 文字量・データ量が変わっても崩れないか |
| 手順2 | 狭い画面・文字の拡大でも成立するか |
| 手順3 | 実際に動くか |
前の5つと違い、この3つだけは画面を動かす必要があります。 そのぶん、見つかるものが確実です。
手順1 いちばん長い文字を貼って、いちばん多い件数を入れる
その画面に入るデータのうち、実際にありうるいちばん長いものを用意します。
- 各項目に、業務で実際に使われている長い名前を入れる（架空の長い文字列ではなく、本物に近いもの）
- 一覧なら、本番で想定される件数を入れる。多いほうと、0件のほうの両方
- その状態で画面を開き、はみ出し、重なり、横スクロール、途中で切れた文字を探す
施工写真台帳で11体が指摘したのは、この1つめです。カードの中に長い文字列が入ると崩れる形でした。
直し方は、文字を短くするのではなく、長くても収まる作りにすることです（デザインと実装の耐久性）。省略するなら、省略した全文をどこで読めるかも決めます。
手順2 幅を狭め、文字を大きくして、もう一度開く
同じ画面を、条件を変えて開きます。
- 幅375px（いちばん狭いスマートフォンの目安）
- ブラウザの文字サイズを200%にする
- 使うなら、英語など文字数が変わる言語に切り替える
崩れるのは、たいてい横に並べたものです。指標のカード、チップの列、テーブル。縦に積み直せるかを見ます（多言語対応のUI）。
文字の拡大は見落とされがちですが、利用者が実際に設定しているものです。文字だけ大きくして枠が追従しないと、その時点で読めなくなります（コントラストとアクセシビリティ）。
手順3 型チェックとコンソールで終わりにせず、実際に開く
最後は、動かすことそのものです。
- ビルドして、実際にその画面を開く
- HTTPのステータスを見る（200かどうか）
- サーバー側のログも見る。ブラウザのコンソールだけでは足りない
上の実例がそのまま理由です。型チェックが緑で、コンソールが静かでも、画面は出ないことがあります。
新しく入れた部品には、前提条件があるかもしれません。 提供元で包む必要がある、初期化が要る、といったものです。ドキュメントに書かれていないこともあるので、入れたら開くを1回挟みます。
3つ通っても、Feasibilityの入口です
ここまでは、自分の環境で確かめられる範囲です。実際の検品では、運用で一貫性を保てる作りかまで見ます。部品を足していったときに揃い続けるか、といった話です。
採点基準は全項目を公開しています。 6観点62項目のうち、Feasibility は所見として書く項目にあたります。
Review Framework（6観点62項目）を見る — design-qa.com/framework（design-qa.com を新しいタブで開く）
6つ見終えて — 「作れた」と「出せる」は別
これで6観点が揃いました。最後に、この画面がどうなったかを書きます。
施工写真台帳は、組み立ての採点では 4/5 でした。既存のコンポーネントだけで大半が組めていて、型チェックはエラー0、狭い画面でも崩れていません。AIが公開ドキュメントだけでここまで組んだこと自体は、良い結果です。
そのうえで、6観点での総合判定は「要再構築」でした。Clarity に立った重い指摘1件が効いています。
「組めたか」で4点の画面が、「出せるか」で要再構築になる。 これが、6観点を分けて見る理由です。
そして Feasibility は、その中でも特別な位置にあります。他の5つは、静止画1枚あれば見られます。 この観点だけは、動かさないと分かりません。動かして初めて、型もコンソールも当てにならない場面があると分かります。
AI生成UIに検品が要るのは、AIの出力が雑だからではありません。作れる速さと、出していいかを判断する物差しが、まだ釣り合っていないからです。
実物を見る
判定の材料と、実際の画面はどちらも公開しています。
- 画面の原寸、AIに渡した条件、コールドテストの採点：gunjo.jp/cold-tests/175（gunjo.jp のコールドテストの記録を新しいタブで開く）
- 6観点すべての指摘と、判定に至る筋道の全文：AIが作った施工写真台帳を、出す前に検品した
6観点シリーズはこれで全部です。
この記事は、UIXHEROがAI（Claude）と協働で制作しています。検品の設計・判断・公開前の事実確認は人間が行い、実作業と下書き執筆はAIが担っています。
GunjoUI by UIXHERO
