AIにデザイン画像だけ渡しても再現できない｜Web実装を正確に依頼する仕様の伝え方

生成AIへデザインカンプの画像を渡し、「この通りにコーディングしてください」と依頼すれば、短時間でHTMLやCSSを作成できます。

しかし、完成したページを見ると、余白が微妙に違う、スマートフォンで崩れる、ボタンの動作が想定と異なるといった問題が起こりがちです。

これは、AIの性能だけが原因ではありません。

一枚の画像から分かるのは、その画面幅における完成状態だけです。レスポンシブ表示、クリック後の動作、再利用する部品、WordPressとの連携など、画像に写っていない仕様は判断できません。

今回は、AIへWeb実装を依頼するときに伝えるべき情報と、修正を効率よく進める方法を初心者向けに解説します。

デザイン画像だけでは分からないことが多い

人がデザインカンプを見ると、過去の経験から見えない部分をある程度推測できます。

たとえば、横並びのカードはスマートフォンで縦並びになる、メニューボタンを押すとナビゲーションが開く、といった判断です。

しかし、それはデザイン画像に書かれている事実ではなく、制作者による推測です。

AIも同じように、不足している情報を一般的なパターンから補います。

その結果、見た目は近くても、制作者の意図とは違う実装になることがあります。

画像だけでは判断できない代表的な項目は次のとおりです。

スマートフォンでの並び方

コンテンツの最大幅

余白が固定か可変か

画像を切り抜く範囲

ボタンを押したあとの動作

メニューやアコーディオンの開閉方法

アニメーションの種類

WordPressで更新できる範囲

同じ部品を使い回す場所

入力内容が増えた場合の表示

エラー時や読み込み中の状態

AIに正確な実装を求めるなら、画像に写らない仕様も文章で伝える必要があります。

最初に実行環境を伝える

同じ画面を作る場合でも、使用する環境によって実装方法は変わります。

静的なHTMLサイトなのか、WordPressテーマなのか、ReactやNext.jsを使うのかを最初に明確にします。

伝えたい情報は次のようなものです。

使用する言語や仕組み

WordPressを使用するか

オリジナルテーマか既存テーマか

CSSの管理方法

Javascriptの使用方針

すでに導入しているライブラリ

対応するブラウザ

既存ファイルを修正するのか新規作成か

納品後に誰が更新するのか

環境を伝えないと、AIが新しいライブラリを追加したり、既存サイトとは異なる書き方を選んだりすることがあります。

動けばよいのではなく、現在の制作環境で管理できる形にすることが重要です。

ページ全体の役割を説明する

デザイン画像だけでは、そのページが何を目的としているのか分かりません。

同じ見た目でも、会社案内ページと広告用のランディングページでは、必要な設計が異なります。

ページの目的として、次の内容を伝えます。

誰が見るページなのか

最も伝えたい内容は何か

最終的にどの行動をしてほしいか

お問い合わせへ誘導したいのか

商品を購入してほしいのか

別ページへ移動してほしいのか

検索からの流入を想定しているか

更新頻度はどのくらいか

目的が分かれば、AIはHTMLの構造やボタンの役割を判断しやすくなります。

見た目の再現だけでなく、ページが果たすべき役割まで共有することが大切です。

セクションごとの構成を文章にする

デザインカンプを渡すときは、ページ上部から順番にセクション名を書き出します。

たとえば、次のように整理します。

ヘッダー

メインビジュアル

サービス紹介

選ばれる理由

制作実績

ご利用の流れ

料金

よくある質問

お問い合わせ

フッター

さらに、各セクションについて、見出し、文章、画像、ボタンなどの要素を説明します。

この作業によって、AIが背景の装飾をコンテンツと誤解したり、複数の要素を一つの画像として扱ったりする問題を減らせます。

人が見れば分かるデザインでも、文章として構造を整理すると、実装時の認識違いを見つけやすくなります。

レスポンシブ表示は別の仕様として伝える

パソコン版のデザインだけを渡し、スマートフォン表示をAIへ任せると、一般的な形へ自動的に変更されます。

しかし、一般的な表示が、そのサイトにとって最適とは限りません。

レスポンシブ表示では、次の項目を指定します。

何列から何列へ変えるか

画像と文章の順番を入れ替えるか

メニューをどの形に変えるか

非表示にする装飾があるか

ボタンを画面幅いっぱいにするか

表や料金プランをどう見せるか

横スクロールを使用するか

文字サイズをどの程度変えるか

セクション間の余白を縮めるか

固定ボタンを表示するか

スマートフォン版のデザインがある場合は、パソコン版とセットで渡します。

デザインがない場合も、「スマートフォンではカードを一列にする」といった最低限のルールを決めておきます。

画像の表示方法を明確にする

画像は、同じファイルを使用しても表示方法によって見え方が変わります。

枠いっぱいに切り抜くのか、画像全体を見せるのか、背景として配置するのかを伝える必要があります。

特に人物写真では、パソコンで顔が見えていても、スマートフォンで横幅が狭くなると見切れることがあります。

画像については、次の点を指定します。

写真全体を表示するか

枠に合わせて切り抜くか

どの位置を中心にするか

パソコンとスマートフォンで画像を分けるか

背景画像として使用するか

文字を画像の上へ重ねるか

暗い重ね色を付けるか

画像の高さを固定するか

縦横比を保つか

代替テキストが必要か

画像の見切れは、完成後に気付きやすい問題です。

最初から端末ごとの見せ方を決めておくと、修正回数を減らせます。

動きは開始条件と終了状態まで伝える

「ふわっと表示する」「文字を流す」といった説明だけでは、AIが選ぶ動きに幅があります。

アニメーションを依頼するときは、動き方だけでなく、いつ始まり、どの状態で終わるのかを説明します。

確認したい項目は次のとおりです。

ページを開いたときに動くか

画面内へ入ったときに動くか

一度だけ動くか

スクロールするたびに動くか

どの方向から表示するか

何秒程度で完了するか

要素ごとに時間をずらすか

動きが苦手な利用者への配慮を行うか

Javascriptが動かなくても内容を表示するか

装飾的なアニメーションによって、文章が読めなくなったり、ボタンを押せなくなったりしてはいけません。

まず通常の状態で利用できるページを作り、その上へ動きを追加する考え方が重要です。

操作できる要素は状態まで設計する

ボタン、リンク、入力欄などには、通常時以外の状態があります。

デザイン画像には通常時しか描かれていないことが多いため、AIへ任せると状態ごとの見た目が統一されない場合があります。

主に確認したい状態は次のとおりです。

マウスを重ねた状態

キーボードで選択した状態

押している状態

利用できない状態

入力エラーの状態

送信中の状態

送信に成功した状態

メニューを開いた状態

アコーディオンを開いた状態

現在のページを示す状態

通常時だけではなく、操作中の見た目や動作も仕様の一部です。

特にフォームでは、入力に失敗した理由や次に何をすればよいかが分かる表示を用意します。

WordPressで更新する場所を指定する

WordPressサイトでは、完成後に管理画面から変更する内容を先に決めておきます。

この情報がないと、AIが文章や画像をテーマファイルへ直接書き込み、クライアントが更新できない構造にする可能性があります。

管理画面から変更したい項目には、次のようなものがあります。

メインビジュアルの文章

サービス内容

料金

施工実績

お知らせ

よくある質問

スタッフ情報

お客様の声

アクセス情報

お問い合わせ先

すべてを自由に編集できるようにすればよいわけではありません。

変更されるとレイアウトが崩れる装飾や、サイト全体で共通して使う部品は、テーマ側で管理した方が安全な場合もあります。

誰が、どの項目を、どのくらいの頻度で更新するのかを考えて設計します。

部品として共通化する範囲を伝える

複数の場所に同じ見た目のボタンやカードがある場合、それぞれを別々に実装すると、後から修正しにくくなります。

AIには、共通部品として扱う範囲を伝えます。

たとえば、次のような部品です。

メインのボタン

サブのボタン

セクション見出し

記事カード

施工事例カード

料金表

お問い合わせへの誘導

パンくずリスト

ページ上部へ戻るボタン

ヘッダーとフッター

共通化すれば、一か所の修正を複数ページへ反映しやすくなります。

ただし、見た目が少し似ているだけの要素まで無理に共通化すると、例外設定が増えて管理しにくくなります。

同じ役割と構造を持つものを共通部品にすることが基本です。

既存ルールを先に共有する

既存サイトへページを追加する場合、AIが新しい命名方法やデザインルールを持ち込むと、コードが統一されません。

実装前に、現在のサイトで使用しているルールを伝えます。

クラス名の付け方

ファイルの保存場所

色や余白の基準

文字サイズのルール

画像ファイルの命名方法

Javascriptの管理方法

共通部品の呼び出し方

コメントの書き方

使用してよいライブラリ

使用してはいけない方法

必要であれば、既存ページや関連ファイルを一緒に確認させます。

新しいページだけが別の作り方にならないように、サイト全体のルールへ合わせることが重要です。

一度にページ全体を作らせない

長いページを一度に実装させると、途中の認識違いが最後まで引き継がれることがあります。

修正するときも影響範囲が広くなり、どこを変更したのか確認しにくくなります。

次のように段階を分けると進めやすくなります。

ページ構造を整理する

使用する部品を決める

ヘッダーとメインビジュアルを作る

一つ目のセクションでルールを確認する

スマートフォン表示を確認する

残りのセクションを追加する

動きや操作を追加する

WordPressの更新機能と連携する

ページ全体をテストする

最初の段階で余白、文字、画像の扱いをそろえておけば、その後のセクションも統一しやすくなります。

修正指示は感覚ではなく差分で伝える

完成した画面に対して、「なんとなく違う」「もう少しおしゃれに」と伝えても、AIはどこを変えるべきか正確に判断できません。

修正内容は、現在の状態と目的の状態を分けて伝えます。

たとえば、次のような情報です。

見出しと本文の間隔を狭くする

画像の中心を人物の顔へ移動する

ボタンの幅を文字に合わせる

スマートフォンでは画像を文章の上へ移動する

セクション全体ではなく背景装飾だけを非表示にする

アニメーションの速度を遅くする

料金カード三つの高さをそろえる

変更してほしくない部分も伝えると、別の場所まで修正されるのを防ぎやすくなります。

一回の指示では、一つの目的に関係する修正へ絞ることも大切です。

AIが作ったコードは必ず人が確認する

見た目がデザインに近くても、内部の実装に問題が残っている可能性があります。

最終的には、制作者が次の項目を確認します。

HTMLの構造が適切か

見出しの順番が自然か

リンクとボタンを使い分けているか

キーボードで操作できるか

画像の代替情報が適切か

不要なコードが重複していないか

既存サイトのルールに合っているか

スマートフォンで横にはみ出していないか

Javascriptエラーが発生していないか

フォームを正常に送信できるか

表示速度を大きく低下させていないか

機密情報が書き込まれていないか

AIは実装を速めるための手段であり、公開の安全性を保証する担当者ではありません。

公開してよい状態かを判断するのは、最終的に制作者です。

まとめ

AIへデザイン画像を渡すだけでは、画像に写っていないレスポンシブ表示、操作、更新方法、部品の共通化までは正確に伝わりません。

AIは不足した情報を一般的なパターンで補うため、見た目は近くても意図とは違う実装になることがあります。

実行環境、ページの目的、セクション構成、端末ごとの表示、画像の扱い、操作時の状態、WordPressで更新する範囲を文章で伝えることが重要です。

また、ページ全体を一度に作らせず、小さな単位で実装と確認を繰り返すと、認識違いを早い段階で修正できます。

AIを使えばコーディング時間は短縮できますが、仕様を決める作業まで自動的になくなるわけではありません。

何を作るか、どのように動かすか、誰が更新するかを人が整理し、AIへ明確に伝える。

この進め方を身につけることで、修正の往復を減らし、実務で管理しやすいWebサイトを効率よく制作できるようになります。