AI に自由に描かせない：パターンカタログで揃えるモック生成

PRD からデザインレビュー用のモック画面を AI に生成させる環境を作りました。同じ要件を渡しても毎回違う画面が出てくる問題は、プロンプトの調整では収まりませんでした。ばらつきを抑えられたのは、AI が選べる骨格・部品・色をあらかじめ固定し、そこから外れたものを機械で落とす形に変えてからです。この記事では、そこに至った経緯と、パターンカタログ・生成パイプライン・機械チェックの中身を順に紹介します。

---

規範ドキュメントだけではモックが揃わなかった

出発点は「PRD から、デザインレビューに出せるモックページを作れるようにしたい」という要望でした。外部のデザイン生成ツールを経由せず、案件のデザインシステムと同じ部品・同じトークンで、自前の環境の中でモックを完結させるのが条件です。

最初に試したのは、AI 向けの規範ドキュメント（デザインスキル）を整備して、それを読ませて画面を生成させる方法でした。結果は同じ要件でも骨格・部品・配色が毎回違うというものです。プロンプトやスキルの文章を何度チューニングしても、このばらつきは抑え込めませんでした。

素朴に AI へ画面を作らせたときに起きたことを並べると、次のようになります。

モックを作らない従来のフローにも、別の課題がありました。手戻りが見つかるのは実装後のレビューで、画面設計は作る人によって骨格が変わり、なぜその構成にしたのかが後から辿れません。生成 AI を使えば速くはなりますが、「速く作れるが毎回違う」状態では業務に使えません。

AI の自由度を絞る 3 つの制約

方針を「規範を厚くする」から「コピー元を用意して、外れたものは機械で落とす」に切り替えました。具体的には、AI が生成してよい範囲を次の 3 つの制約で絞っています。

この 3 つを課すと、AI に残る自由度はダミーデータの中身と文言くらいになります。結果として、1 画面あたり数十分、バリエーションの多いページでも数時間で、レビューに出せる品質のモックが出てくるようになりました。

パターンカタログはコピー元として使う

制約の 1 つ目を支えているのが、91 種の画面パターンを集めたカタログです。カタログは AI が読んで参考にする資料として作っていません。AI がそのままコピーする土台として作っています。

すべてのパターンが動く実装サンプルを持つ

91 種のパターンには、それぞれ React の実装ファイル（.tsx）と Storybook の Story が付いています。Storybook を開けば、どのパターンも実物の画面として目視で確認できます。パターンはこれまでに手がけた案件の画面から抽出し、汎用的な骨格として整理しました。カテゴリ別の内訳は次のとおりです。

文章で書いた規範では守られなかったばらつきが、動く実体ファイルをコピーさせる方式に変えたことで大きく減りました。生成 AI には、渡されたサンプルを忠実に流用する性質があるためです。

見た目ではなく「画面の仕事」で選ばせる

カタログの各パターンには、1 行ずつ「選定シグナル」を書いています。たとえば一覧表のパターンなら「定型の一覧に絞り込みとページネーションが付く画面」です。似たパターンの区別も、状態を監視する対象が単一のリソースか複数のバッチ処理か、のように画面の役割で書き分けています。

見た目の好みで選ばせないことで、どのパターンを選ぶかが安定しました。該当するパターンがなければ、AI は停止して人間に確認します。 独自の骨格を AI が自走で作ることはありません。

人間のゲートを 1 点に絞った生成パイプライン

生成は 6 つのステップで進み、人間が判断するのはパターン選定の 1 点だけです。

合意のゲートを生成後ではなくプランの段階に置いたのは、手戻りのコストが違うからです。生成した後に骨格の指摘が出れば作り直しになりますが、プランの段階なら 1 行書き換えるだけで済みます。手戻りのコストがいちばん大きい判断だけを、前倒しで人間に確認させています。

プランをファイルとして残す

合意したプランは .plan.md としてファイルに残し、Git で管理しています。採用したパターン、その根拠になった要件、Story の一覧、改訂履歴が入ります。Storybook には「Plan」タブを用意し、画面とその構成に至った経緯を同じ場所で確認できるようにしました。

チャットでの合意は、会話が流れると消えてしまいます。プランをファイルにしておけば、修正のときも「プランを先に直し、実装は後から」という順番を機械的に守らせることができます。

書いてあるだけの禁止は守られない

生成したモックは、4 層の機械チェックにかけます。規範に「やってはいけない」と書いておくだけでは AI は守らない、というのが最初の試行錯誤から得た学びです。

アクセシビリティと HTML の検証は、部品のカタログと生成したページの 2 か所で実行しています。見出しレベルの飛びやランドマークの重複のように、部品を組み上げたページでしか出ない違反があるためです。

既存の負債はベースラインのファイルに凍結し、新しく入った違反だけを失敗にしています。基準値はアクセシビリティ違反・HTML 検証エラーとも 0 件で、CI の strict モードで維持しています。CI は push と PR のたびに同じチェックを実行するので、スキルを経由せずに入った変更もここで止まります。

モックにも本実装と同じトークンの規則を課しているのは、モックを「絵」として作ると、本実装へ翻訳する段階でずれが生まれるからです。同じ部品と同じトークンで作られていれば、合意済みのモックの JSX をそのまま本実装の出発点にできます。

4 層の資産と役割を分けたスキル

仕組み全体は、次の 4 層の資産で構成しています。

Claude Code のスキルは、生成・正典の管理・修正・検査・アクセシビリティ修正・パターン登録に分けて用意しています。役割ごとに分けたのは、入力も停止条件も違う作業を 1 つのスキルに混ぜると、AI が文脈によって判断を揺らすからです。たとえば検査の途中で勝手に修正を始めてしまう、といったことが起きます。そこで「検査スキルは可否のレポートを出すところまで。修正はアクセシビリティ修正のスキルに渡す」という越境の禁止を明文化しました。

トークンの値は YAML ファイル 1 枚が正本で、グローバルの CSS はそこから生成しています。ブランドの差し替えは、この YAML 1 枚の差分をレビューするだけで済みます。

コピー元を浄化し、学びをカタログへ戻す

この仕組みは、案件で使うたびに育つように作っています。案件で新しい骨格が生まれたら、パターン登録のスキルでその案件固有のパターンとしてカタログに登録します。他の案件でも使えるとわかれば汎用のパターンに昇格させ、次の生成からは選定の候補になります。

生成のたびに「正典になくて困った箇所」「同じ手組みを 2 回書いた箇所」「機械で検出できたはずの逸脱」を記録し、定期的に棚卸しして正典の改訂や検出ルールの追加につなげています。

サンプル自体に残っていた違反

2026 年 7 月に仕組み全体を総点検したところ、見つかった問題はすべて、規範を注意書きで守らせようとしていたことに原因がありました。象徴的だったのが、正典のサンプル 5 件に負のマージンの違反が残っていたケースです。AI はサンプルを忠実にコピーするので、違反もサンプルごと複製されていました。

対策は 2 つにまとまりました。コピー元のサンプル自体を浄化することと、検出できる違反は機械チェックに回すことです。カタログ・実体ファイル・README の 3 つの整合も検査スクリプトで機械的に照合していて、どれか 1 つだけを更新すると CI が落ちます。91 種あるパターンのメンテナンスが放置されて古くならないよう、仕組みの健全性も人の注意に頼らないようにしています。

運用してわかったこと

本格的に使っている案件はまだ 1 つです。その案件の使用感から問題が出た部分を直しながら、仕組みを育てている段階です。運用の中で見えてきたことや、社内のデザイナーから出た意見をまとめます。

PRD の質がそのまま結果に出る

この仕組みは、PRD を解析して「この要件ならこういう画面になる」という形にするものです。AI が自由にレイアウトを考えないよう縛っているので、PRD にレイアウトを判断する材料が書かれていないと、AI はパターンを選べずに迷います。 よくあるのは、PRD とデザインスキル側の設定が食い違っているケースで、AI が「ここはどうしますか」と確認を返してきます。

社内のデザイナーからも「PRD の大切さが一段と身近になった」という声が出ました。モックの品質を上げたければ、先に PRD を整える必要があります。PRD の書き方は AIDD 要件定義の PRD を Gherkin で書く記事で紹介しています。

中間の成果物を挟まないほど、ずれが小さくなる

PRD から一度別のツールでデザインを起こし、そこからさらにモックを作る流れでは、間に人や AI が挟まるたびに要件とのずれが大きくなります。PRD から直接モックを作れれば、そのずれを最小限にできます。ページ数の多い業務システムの案件ほど、この差は大きくなります。

一方で、LP のようにデザイン性を重視する制作物は、この仕組みが前提としている用途とは違います。案件の性格によって向き不向きがあります。

Figma は取り込み用のスキルで併用を続ける

Figma のデザインを取り込むスキルも別に用意しています。正確に言うと、モック生成の主な経路を Figma に依存しない形にしたということです。

モックは意図的に動かない作りにしています。画面遷移・送信・API 連携は入れず、useState による見た目の切り替えまでに留めています。目的を「見た目の合意」に絞るためです。

全自動にせず、人間の判断点を 1 つに絞る

ばらつきを抑えた仕組みを振り返ると、動く実体ファイルをコピー元にして骨格を発明させないこと、人間の合意をプランの 1 点に前倒しすること、書いてあるだけの禁止を機械チェックに置き換えることの 3 点に集約されます。

全自動で生成させると、必要な要素が足りなかったり、要らないものが入っていたりします。そのため人間のチェックは残し、判断点をいちばん手戻りの大きい 1 点に絞った半自動の形にしています。

今後は次の取り組みを進める予定です。

• PRD からモックを作り、合意を経て見積もりを精緻にする流れを、画面設計レビューの標準フローにする
• 合意済みのモックから本実装へつなぐ手順をスキルにする
• 目視に頼っている検査項目を機械チェックに移す

AI に UI を生成させるときの品質と統一感をどう保つかは、gaipack の AIDD デザインでも取り組んでいるテーマです。デザインシステムを AI に読ませる規範ドキュメントの考え方は、DESIGN.md の解説記事で紹介しています。AI による UI 生成やデザインシステムの整備について、お気軽にご相談ください。