Codexにデザインカンプを丸投げ。JPG画像からHTMLコーディングできるか試してみた

結論から言うと、ChatGPT CodexにPhotoshopやIllustratorのデザインデータをそのまま丸投げして実務品質のコーディングを完了させるのは、現時点ではまだ難しいというのが実務者としての見立てです。
ただし「叩き台としての骨組みコーディング」までなら十分に任せられる場面があります。

デザインデータをそのまま渡しても、Codexが解釈できるのはあくまで画像として見える情報や、書き出したテキスト・レイヤー構造の範囲までです。
フォントの微妙なトラッキング、余白のルール、レスポンシブ時の崩れ方といった暗黙の実装ルールまでは読み取れません。つまり「完成品を丸ごと作ってもらう」のではなく「初稿を高速に作らせて、人が仕上げる」という前提で使うのが現実的な運用になります。

この記事では、デザインデータを渡す際に何が起きやすいのか、どこまでのクオリティを期待していいのか、そして丸投げが向くケースと向かないケースを整理しました。実際に依頼する前のチェックリストとしても使える内容にしています。

この記事で分かること

• ChatGPT CodexにPSD/AIデータを渡したときの一般的な処理の流れ
• 丸投げで期待できるクオリティの水準と、届かない部分
• コーディングの精度を上げるための素材の渡し方
• 実務で丸投げに向くケース・向かないケースの判断基準
• 納品前に必ず人の目で確認すべきチェック項目

ChatGPT CodexがPhotoshop・Illustratorのデータをどう解釈するか

ChatGPT Codexは、画像やコードを理解して開発作業を支援するAIエージェントとして設計されています。
PSDやAIファイルそのものを直接開いて内部構造を完全に読み込む、というよりは、書き出された画像やテキスト情報をもとにレイアウトを推測し、HTML・CSSを生成する仕組みだと理解しておくのが実務的です。

具体的には、次のような情報の渡し方によって結果が大きく変わります。

• PNG・JPEGで書き出したデザインカンプ:見た目の配置は読み取れるが、余白の正確な数値やフォントサイズは推測ベースになる
• SVGやテキスト情報を含む書き出しデータ:文字情報やパスの座標が読み取りやすく、精度が上がりやすい
• レイヤー名やアートボード名の情報:命名が整理されていると、セクション構造の推測に役立つ

重要なのは、Codexが「見えている範囲」でしか判断できないという点です。
デザイナーが頭の中で決めている余白のルールやグリッドシステムは、画像だけでは伝わりません。

JPGファイルでテストしてみた

ここでは、デザインデータを直接扱えないケースを前提にしつつ、コンテキストは当方の環境に合わせて調整し、以下のようなシンプルなプロンプトでデザインを作成。

誌面で使用するような、HTMLではやや実装しづらいデザインのWEBページ案を、A4サイズ・1ページ程度で仮制作してください
テーマは「京都観光」です。

こちらを以下のような思いつきの箇条書きの形でcodexに投げてみます。

これをHTMLコーディングしてください。
・HEROの背景、写真のデザインはそれぞれ分けて京都らしいアニメーションで表示してください。
・全体的にテキストコーディング
・明朝体はしっぽり明朝
・01～05の部分もアニメーションをつけたい

このシンプルな依頼で出来たサイトがこちらです。
デモサイトはこちら

デザイン通りのコーディングは、まだ難しい。ただし使い道は十分ある

完成したHTMLを見ると、最初に感じるのは「思った以上にちゃんとWebサイトになっている」ということです。
今回Codexに渡した指示は、細かな数値指定や実装方法まで書き込んだものではありません。
それでも、レイアウトを組み、画像やテキストを配置し、アニメーションやレスポンシブ対応まで含めて、ひと通り閲覧できるWebページとして完成させてくれました。

一方で、元となったデザインデータと比較すると、レイアウトや写真の見せ方、装飾など、大きく異なる部分もかなりあります。
「デザインデータを渡せば、そのまま忠実にHTML化してくれる」という段階には、まだ達していない印象です。

良かったところ

• 少ない指示でも、ここまでWebサイトとして形にしてくれる
  元デザインとは異なる部分があるものの、簡単な指示だけでページ全体を構成し、実際に閲覧できるところまで作ってくれるのはかなり便利です。
• アニメーションの完成度が高い
  要素の表示やスクロール時の動きなども自然で、単純にフェードインさせるだけではなく、サイト全体の雰囲気に合わせた演出になっています。
• レスポンシブ対応まで自動で考えてくれる
  PC版だけを作って終わりではなく、スマートフォンで見た場合のレイアウトまで考慮されています。
  デザインデータ側に細かなスマホ版の指示がなくても、ある程度自然な形に再構成してくれるのは大きなメリットです。
• Webサイトとして必要な要素を補完してくれる
  元デザインには存在しない見出しやコンテンツ、CTA、フッターなども追加され、単なるデザインの再現ではなく「Webサイトとして成立させる」方向に補完されています。
• HTMLの文章構造もある程度考えられている
  大見出し・中見出し・各コンテンツの見出しなどがHTML上でも分けられており、単純にすべてをdivで組んだだけのページにはなっていません。
• 画像内の文字を画像のまま使わず、HTMLテキストとして再構築できる
  SEOやアクセシビリティ、スマートフォン表示を考えると、この点は大きなメリットです。
• 画像にも内容に応じた代替テキストが付けられている
  「清水寺」「伏見稲荷」「宇治抹茶」といった画像について、内容を表すテキストが設定されているため、SEOやアクセシビリティ面でも最低限の配慮があります。
• こちらが細かなCSSやJavaScriptを書かなくても、ひとまず動くところまで持っていける
  ゼロからコーディングする場合と比べると、初期工程をかなり短縮できます。

気になったところ

• 元デザインと大きく異なる部分が多い
  最大の問題はここです。
  元デザインでは、写真同士の重なりや余白、サイドカラム、紙面のような構成などがデザインの大きな特徴になっています。
  HTML版ではそれらが独自に再解釈されており、「同じデザインをWeb化した」というより、「元デザインを参考に別のWebデザインを作った」に近い部分があります。
• 細かなあしらいがかなり省略される
  細い罫線、背景の質感、筆のような装飾、写真の微妙な重なり、スタンプ、アイコン、余白の取り方など、誌面デザインらしさを作っている細部は省略・簡略化されやすいです。
• 写真のサイズやトリミング、配置が元デザインと一致しない
  特にメインビジュアルは、写真の重なり方そのものがデザインの重要な要素ですが、その位置関係まで忠実に再現するのはまだ難しい印象です。
• 「実装しやすいWebデザイン」へ勝手に最適化される傾向がある
  今回のように、あえてHTMLでは組みにくい誌面的なデザインを渡しても、Codex側でグリッドやカード型など、Webで扱いやすい構造へ整理されることがあります。
  普通のWeb制作ではメリットでもありますが、デザイン再現を目的とした場合にはデメリットになります。
• 元デザインにない要素を追加することがある
  見出しやCTA、フッターなどを補完してくれる反面、「デザインに存在しないものまで作らないでほしい」という案件では修正対象になります。
• デザイン上の意図までは完全には読み取れない
  「なぜここだけ写真が少し傾いているのか」「なぜこの余白が大きいのか」「なぜここだけ縦書きなのか」といった、デザイナーが意図して作った細かなニュアンスまでは正確に汲み取れないことがあります。
• レスポンシブは成立していても、デザイナーが考えたSPデザインとは別物になりやすい
  崩れないようにはしてくれますが、それが必ずしも「デザインとして最適なスマホ版」であるとは限りません。
• SEOは土台を作ってくれるが、そのまま公開して完璧というわけではない
  見出し構造やテキスト化、画像のaltなどはある程度対応できますが、タイトル・description・構造化データ・内部リンク・表示速度・Core Web Vitalsなどは、公開前に人間が確認した方が安心です。
• JavaScriptの演出も、後から調整したくなる部分は残る
  動きそのものは綺麗でも、開始タイミング、速度、スクロール量、スマートフォンでの動作など、実案件では細かなチューニングが必要になります。
• 最終的な品質確認はまだ人間側に必要
  PC・スマートフォン・各ブラウザでの確認、リンク切れ、アクセシビリティ、SEO、表示速度など、納品前のチェックまで完全に任せきるのはまだ難しいと感じます。

では、実際のWeb制作で使えるのか？

今回試した限りでは、完成したデザインが存在し、それをピクセル単位で忠実に再現することが求められるコーディング案件に、そのまま使うのはまだ難しいと感じました。
特に今回のような、誌面的なレイアウトや写真の重なり、細かな装飾までデザインの一部になっているものほど、その差は大きくなります。

ただし、
「まずベースをCodexに作らせて、そこから人間がデザインに合わせて調整する」
という使い方なら、十分アリです。

ゼロからHTML、CSS、JavaScriptを書き始める必要がなくなるため、案件によってはかなりの時間短縮になると思います。

さらに、
まだデザイン自体が決まっておらず、初回提案からAIを使う
という方法なら、むしろ相性は良さそうです。
AIが作ったHTMLをそのまま一つのデザイン案として捉え、そこからデザイナーがブラッシュアップしていくのであれば、「元デザインと違う」という問題自体がなくなります。

そしてもう一つ。
個人サイトや自分で運営するメディアなら、これは全然アリです。
多少デザインが変わっても自分で判断できますし、気になるところだけ後から直せばいい。

完璧なデザイン再現を求めず、
「まず形にする」「早く公開する」「あとから育てる」
という目的なら、現時点でもかなり実用的です。

「デザイナーやコーダーが不要になる」というところまではまだ来ていません。

ただ、
デザイナーやコーダーが、ゼロから全部作る必要はなくなりつつある。
一番感じたのはそこでした。

まとめ

もちろん、より細かなプロンプトを用意し、具体的な指示を重ねていけば、完成度はさらに高められます。
また、ページ全体を一度に作らせるのではなく、パーツごとに分けて制作させることで、より精度の高い再現が期待できるのも事実です。

現時点では、「0から1を生み出す力」にはまだ伸びしろがあるように感じます。
一方で、すでにある「1」をベースに、改善や調整を重ねながら「10」に近づけていく力には注目すべきなのかもしれません。

一昔前であれば、仕事で通用するレベルのWEB制作知識を身につけるには、少なくとも2年程度は必要だったように思います。
しかし今では、AIをうまく活用すれば、もしかすると1ヶ月ほどでも、実務の現場で一線のプレイヤーと肩を並べられるレベルまで到達できる可能性があります。

もちろん、知識や経験そのものが不要になるわけではありません。
それでも、学習や実装に必要な時間が大幅に短縮されつつあることは、間違いなさそうです。

よくある質問

PSDファイルをそのままCodexにアップロードすれば自動でコーディングしてくれますか。

アップロード自体は可能な場合がありますが、内部のレイヤー構造や余白ルールまで正確に読み取れるとは限りません。書き出した画像やテキスト情報を補助的に渡すほうが、実務では安定した結果を得やすいという見立てです。

Illustratorのデータの方がPhotoshopより向いていますか。

Illustratorはパスや座標情報が明確なぶん、テキストやアイコンの位置情報を伝えやすい傾向があります。ただし最終的な精度は書き出し方法やレイヤー整理の丁寧さに左右されるため、どちらが優れているとは一概に言えません。

丸投げしたコードはそのまま納品しても問題ないですか。

レスポンシブ対応やアクセシビリティ、実際のブラウザ表示確認は人の目でのチェックが欠かせません。初稿として活用し、必ず実装者が仕上げる工程を挟むことをおすすめします。