自作のデザイン用手順書「design-forge」を、情報量の多い架空サイトで最初から最後まで使ってみた。機械検証が実際にバグや丸写しを捕まえる場面を3つ確認できた。
なぜやったか
手順書やチェックツールは何度も手直ししてきたが、実際の制作で機械検証がどこまで効いているのかを一度も通しで確かめていなかった。複雑な題材で試すことにした。
やったこと
- 題材に架空の「離島航路の総合運航ポータル」を選んだ。時刻表・運賃・欠航情報・気象・島案内と情報の種類が多く、密度の検証に向くと考えた
- 手順書の全工程（方向性決定→デザイン文書の生成と検証→実装→自己点検→採点）を通しで実行した
- スタイルの方向性は3候補を比較し、「欠航情報は生活インフラなので、色だけに頼らない状態表示が最優先」という理由で1つを選んだ
- 完成後、採点役の別AIに100点満点で採点させた
つまずいた点
配色数の上限が高密度なUIには厳しく、危険を示す系統の色だけで「欠航」「条件付き」「判定前」の3状態を賄おうとすると枠線と背景の役割が重なりがちだった。
わかったこと
- 機械検証が実際に効いた場面が3つあった。配色数の上限が、参照元の特徴的な配色をそのまま使うのを構造的に防いだこと。デザイン文書と実装コードの突き合わせが、目視では気づかない場当たり的な色を検出したこと。採点役の別AIが、航路ごとの閾値の線が実データと矛盾しているという、自分では見落としていた本物のバグを指摘したこと
- 一方で採点だけで約10万トークンかかった。「軽く作ってみる」規模の題材では、採点のほうが本体の実装より重くなるというコスト構造の課題が見えた
- デザイン文書の生成から検証、実装、突き合わせ、独立採点までの一本道の流れは、途中で破綻せず完走できた
次にやること
配色数の上限に「セマンティック色として2色まで例外を許す」といった逃げ道を用意し、高密度UIでも無理なく運用できるようにする。