これまでAIでWebサイトを作るとき、多くの人が重視してきたのはPromptでした。レイアウト、雰囲気、機能、トーンをどう言葉にすれば、より良い出力になるのか。けれどAIが画面生成、スクリーンショット理解、フロントエンド修正、Coding Agentによる反復までこなすようになると、ボトルネックは別の場所へ移ります。
Promptは要件を伝えられても、感覚までは伝えきれない
「モダンで、プロフェッショナルで、プレミアムなAIサイトを作って」と指示しても、タイポグラフィ、情報密度、画像の扱い、余白、モーション、カード比率、モバイル時の再構成など、多くの判断が未指定のまま残ります。
その空白が大きいほど、AIはよく見かける安全な平均解へ戻りやすくなります。似たサイトが量産される原因は、AIの能力不足だけではなく、設計判断をAIに委ねすぎていることにもあります。
Prompt EngineeringからContext、そして視覚リファレンスへ
これらは競合するものではなく、補完関係にあります。ブランドが「理性的だが実験的」「上質だが自然」と分かっていても、その言葉が具体的にどのようなレイアウトや写真、動きになるのかまでは決まりません。そこで、視覚リファレンスが曖昧さを減らす役割を持ちます。
参照はコピーではない。まず分解してから使う
スクリーンショットを1枚渡して「これと同じように」と指示するだけでは、複数の設計判断が一緒に混ざってしまいます。より実践的なのは、参照したい要素を分解することです。
- 構図：Heroの比率、非対称性、情報階層。
- タイポグラフィ：見出しサイズ、太さの差、行長、密度。
- モーション：スクロールのリズム、遷移、速度感。
- インタラクション：ナビゲーション、Hover、Cursor、状態変化。
- 素材感：写真、Texture、3D、Shader、画像処理。
- 情報密度：余白、セクション間隔、ページ全体の呼吸感。
- レスポンシブ：デスクトップを単に縦積みするのではなく、モバイルでどう再構成するか。
最終サイトは1つの参照元に似せる必要はありません。Aは構図、BはTypography、CはMotionというように役割を分け、自分たちのブランドとUX Contextで再統合できます。
Codrops Creative HubをReference Libraryとして使う
Codrops Creative HubのようなCreative Webの資料は、AI Coding時代には単なる「面白い表現集」以上の価値を持ちます。Three.js、WebGL、WebGPU、GSAP、Shader、スクロール表現などから、使いたいインタラクションの方向を先に選び、Coding Agentに自分の技術構成へ合わせて再実装させることができます。
重要なのは、効果そのものをコピーすることではなく、「どの部分が自分のブランドに役立つのか」「どこまで取り入れるのか」「どの制約の中で再構築するのか」を決めることです。
リファレンスエンジニアリングの5ステップ
選択
なぜその参照が必要なのかを決めます。構図、文字、動き、素材、モバイル設計など、役割を明確にします。
分解
サイト全体をひとつの「スタイル」として扱わず、個別の設計シグナルへ分解します。
制約
取り入れない要素も明示します。非対称レイアウトだけを参考にし、色やブランド素材は使わない、といった指定です。
統合
ブランド、コンテンツ、UX Context、視覚リファレンス、技術制約をひとつの新しい方向へまとめます。
検証
意図した特徴が保たれているか、モバイル、実コンテンツ、各種状態でも成立するかを確認します。
Negative Referenceも重要になる
良いReference Briefは「何を取り入れるか」だけでなく、「何を持ち込まないか」も書きます。たとえば「このトランジション原理は使うが、ネオン色は使わない」「このEditorialな密度は参考にするが、Brutalistな見た目にはしない」といった指定です。
これによりAIが参照元をそのままTemplateとして解釈する可能性を下げられます。
ライセンス、パフォーマンス、参照過多
参照することと、外部のコード、画像、フォント、ブランド表現を無制限に再利用することは別です。外部素材やDemoを実際に利用する場合は、元のライセンスや利用条件を確認する必要があります。
また、WebGL、WebGPU、Physics、Shader、重いPost-processingは魅力的でも、本番サイトに適するとは限りません。アクセシビリティ、端末性能、読み込み時間まで含めて評価する必要があります。
参照は多ければ良いわけでもありません。互いに矛盾する参照を大量に渡すと、曖昧さが増えることもあります。
インスピレーション集からAI-ready Design Reference Systemへ
将来の参照ライブラリは、URLとスクリーンショットだけではなく、Reference Type、取り入れる要素、避ける要素、Typography、色、Motion、技術、適用場面、パフォーマンス注意点まで記録するものになるかもしれません。
そのとき、単なるインスピレーション集は、AIが理解・組み合わせ・検証できるDesign Reference Systemへ変わります。
よくある質問
Reference Engineeringは正式なAI業界用語ですか？
本記事で使う意味では、統一された正式用語として扱っていません。マルチモーダルAIやCoding Agentが視覚参照を扱う時代に有用な、実践的な方法論の枠組みとして使用しています。
Screenshot-to-Codeと同じですか？
同じではありません。Screenshot-to-Codeは画面の再構築に重点がありますが、リファレンスエンジニアリングは、なぜその参照を選ぶのか、どの要素を使うのか、複数の参照をどう組み合わせるのか、何をコピーしないのかまで扱います。
複数のReferenceを同時に使えますか？
はい。AはLayout、BはTypography、CはMotionのように役割を分けると、1つのサイトだけに依存するより柔軟です。
Referenceは多いほど良いですか？
いいえ。矛盾する参照や優先順位のない参照は曖昧さを増やします。量よりも、選択・分解・制約・優先順位が重要です。
他のWebサイトを参考にすると著作権の問題がありますか？
設計原理を研究することと、コード、画像、ブランド素材、完成した表現をコピーすることは別です。外部素材やコード、フォント、Demoを使う場合は、元のライセンスを確認してください。