[Codex実録] デザイン修正は、ルールを書くより画像を渡すほうが速かった
はじめに
数年、あるいは数ヶ月前に作ったWebサイト。そのサイトのスナップショットをポートフォリオに並べいたのですが、技術スタックも作成時期もバラバラで、デザインに統一感がない……。
統一させるのもいいかなぁと思い立ち、AIを使ってデザイン改修を試みたときの話になります。
デザインルールによる統一の限界
まず試したのは、AIに対して「デザインルール」を定義して渡すという、従来のアプローチでした。
- カラーパレット(プライマリ・セカンダリカラー)
- フォントサイズ、余白の規定
- 共通のコンポーネント設計
この時はAIエディターの Kiro を使い、これらの指示書を「既存のサイトに適用して」とお願いしてみました。結果は「そこそこ」といったところ。
サイトの構造(HTML/CSSの構成)が近いものであれば綺麗に当たりますが、技術スタックも時期もバラバラなサイトたちを相手にすると、細かな調整が必要になり、結局かなりの手間がかかってしまいました。
「事前にルールを作ったほどの恩恵」は、正直それほど感じられませんでした。
それでも、CSSをちまちま修正すりよりも凄い事なんですが...AIに慣れてしまって感動が薄くなってます(笑)
デザインルール
webdesign-rules
+- design-rule.md
+- design-rule-common.md
+- design-rule-validation-dashboard.md
# FN:design-rule.md
# Design Rules
- 共通ルール: ./design-rule-common.md
- 検証用ダッシュボード / ツール系Webアプリ: ./design-rule-validation-dashboard.md
# FN:design-rule-common.md
# Design Rules - Common Preferences
このファイルは、検証用ダッシュボード・実運用Webアプリ・演出系Webアプリのすべてに共通して適用する個人ルールです。個別のデザインルールよりも上位の方針として扱います。
## Core Preferences
- 余白はやや広めに取る
- 角丸は小さすぎず、6pxから12px程度を基本にする
- 原色は使わない
- 影は弱めにし、主にパネルの分離にだけ使う
<<省略:以降、具体的なルール書きすぎて実行時に破綻したのかも>>
# Design Rules - Tool Web App / Validation Dashboard
This rule extends ./design-rule-common.md.
If there is a conflict, follow this validation dashboard rule only when the reason is explicit.
## Scope
このルールは、検証用ダッシュボードに限らず、個人運用のツール系Webアプリ全般に適用できます。
適用対象の例:
- Supabaseへのデータ登録・確認ツール(Beacon Data Registration Check)
- API疎通確認ツール
- データ変換・整形ツール
- ログビューア、簡易モニタリング画面
- 個人用の管理・運用ダッシュボード
<<省略:以降、具体的なルール書きすぎて実行時に破綻したのかも>>
画像プロンプトがもたらした一発回答
次にアプローチを変えてみました。言葉でルールを説明するのをやめ、AIに 「理想のトップページ案」 の画像で出力してもらったのです。
その画像をそのままAIに投げ、「このイメージ通りに作り直して」と指示しました。
この作業には Codexデスクトップ版 を使用したのですが、驚くほど一発で「いい感じ」のサイトが出来上がりました。
以前、Figmaで作成し、その画像をコピペで渡した際も、UIパーツが正確に出力(コード化)されて便利だと感じていましたが、今回は「一枚の画像」から、サイトのイメージをガラッと作り変えてしまったのです。適当に作った静的なサイトが、画像の雰囲気を纏って再構成される様子は、まさに圧巻でした。
補足:ツールによる特性と検証の余地
ここで一つ触れておきたいのは、手法によってツールを使い分けてしまった点です。
- デザインルールによる修正: Kiroを使用
- 画像指示による刷新: Codexデスクトップ版を使用
Codexは画像生成がかなりいい感じなので、以下の流れで作業してしまいました。
- ChatGPT(ブラウザ)でTOP画面の画像を作成
- Codexデスクトップ版でその画僧を使ってサイトのデザイン変更
一方で、「もしCodexにデザインルールを渡して指示していたら、もっと良い結果が出ていたのではないか?」という疑問も残ります。
今回は手法を切り替えるタイミングでツールも変えてしまったため、これが純粋に「指示方法(言葉 vs 画像)」の差なのか、あるいは「ツールの性能差」によるものなのか、完全な切り分けはできていません。
スピードが「構造のきれいさ」より効いてくる場面もある?
生成されたコードの中身を見てみると、必ずしも自分がきれいだと感じる設計ではありませんでした。ヘッダーやフッター、コンテンツ部分の切り分けが曖昧だったり、構造的に「まあまあ」な部分は確かにあります。
しかし、この圧倒的な開発スピードを目の当たりにすると、一つの疑問が湧いてきます。
「修正したくなったら、またAIに作り直してもらえる。だとしたら、最初からコード構造のきれいさにどこまでこだわるのがよいのか?」
もちろん極論かもしれませんが...どうせこの後も修正にも人間介在しないし...。AIがこれほど高速に「見た目」を具現化してくれる時代において、開発の優先順位が確実に変わりつつあることを実感しました。
まとめ ─ 「百聞は一見にしかず」のAI時代
最初はデザインルール充実させてそれを適用すればうまくいくのかなと思ってたんですけど、結局AIにとっては 一枚の画像が最高の指示書 だったみたいです。
AIで作成したサイトのTOP画面のイメージです。

デザイン修正前

デザイン修正後

最近は何を見ても驚かなくなって(AIに慣れて)しまっていましたが、今回の「画像から一気にイメージを再現する」体験には、久しぶりに驚かされました。
一からWebページを生成するのは得意だと思うのですが、既存のサイトを指定した画像こ沿って綺麗に修正できるとは...正直期待してなかった分(デザインルールで失敗していたので)の驚きました。
「百聞は一見にしかず」 (言葉よりも目で見た方が早い)
古くからあるこの言葉が、AIエージェント時代において新たな意味を持って迫ってきている。
自分でやってみて改めてそう感じました。
以下、セッションログになります。
🧑💻 ユーザー
[画像添付]
サイトのデザインこんな感じに作り直すことできますか
🤖 AI
はい、できます。まず今のサイト構成と使っている技術を確認して、既存の作り方に合わせてこの静かなポートフォリオ風デザインへ寄せていきます。
(省略: コマンド実行件数表示)
今の状態はクリーンで、静的HTML/CSS/JSのサイトですね。トップページ中心に作り替えつつ、共通CSSを壊しすぎない範囲で全体の雰囲気も整えます。
(省略: コマンド実行件数表示)
トップページはスクリーンショットの構成にかなり近づけます。白いナビ、余白のある自己紹介、横長のプロジェクトカード、短いノート欄、控えめなフッターという形で、既存の実ファイルと画像を使って組み直します。
これから編集に入ります。トップページのHTMLをスクリーンショット寄りの情報設計に差し替えて、CSSは既存ページにも効く基本トーンを残しながらホーム専用の仕上げを追加します。
(省略: ファイル作成・編集・コマンド実行件数表示)
見たところ、既存の script.js に文字化け由来の構文エラーもありました。デザイン変更と一緒に、画像モーダルやメールリンクが普通に動くように小さく修正します。
(省略: ファイル作成・編集・コマンド実行件数表示)
構文チェックは通りました。リンク先の主要アンカーも確認できたので、次に実画面で崩れや読み込みエラーがないか見ます。
file:// はブラウザ側の安全ポリシーで開けなかったので、ローカルの静的サーバーで確認します。サイト本体は静的HTMLなので、確認用に小さく配信するだけです。
(省略: コマンド実行件数表示)
ローカルURLもブラウザ拡張側でブロックされました。表示確認は別の手段に切り替えて、HTML/JSの実行とスクリーンショット取得ができるか試します。
(省略: コマンド実行件数表示)
デスクトップ表示は大きな崩れなしです。カードや余白は意図通り出ているので、続けてスマホ幅でナビやカードが詰まらないか確認します。
(省略: コマンド実行件数表示)
できます、ということでトップページをスクリーンショット寄りの静かなポートフォリオデザインに作り直しました。
変更した主なファイルは index.html、style.css、script.js です。白いヘッダー、余白のあるヒーロー、プロフィール枠、横長プロジェクトカード、ノート欄、控えめなフッターに組み替えています。ついでに script.js の文字化けで壊れていたテーマ/モーダル周りの構文も直しました。
確認済み:
-
node --check script.jsOK - Chrome headlessでPC幅/スマホ幅を表示確認
- 横スクロールなし、JSエラーなし
- プレビュー:
http://127.0.0.1:4174/index.html
Browserプラグインの通常表示はローカルURLがブロックされたので、代わりにPlaywright + Chromeで確認しています。
(省略: UIボタン・システムメッセージなど会話に関係ない表示を省略)
🧑💻 ユーザー
このデザインに合わせてほかのページも修正してもらえませんか
🤖 AI
もちろんです。トップページで作った静かな白ベースの方向に合わせて、Windows / Android / Tools / Web / Profile の共通ヘッダー、ページ見出し、詳細カードまわりを揃えていきます。まず各ページの構造差分を確認します。
(省略: コマンド実行件数表示)
各ページは中身のプロダクト説明はそのまま活かせそうです。今回は大きく壊さず、共通ナビをトップと同じものに差し替え、下層ページ用の余白・カード・フッターのCSSを追加する方針で進めます。
(省略: コマンド実行件数表示)
これから機械的な共通化をします。本文の各プロダクト説明は残し、body、ヘッダー、フッターだけをページごとのアクティブ状態つきで差し替えます。
(省略: コマンド実行件数表示)
差し替え自体は入っていますが、PowerShell経由の文字コードでナビの日本語ラベルが一部 ??? になりました。ここはすぐ直してから、見た目のCSSを当てます。
(省略: ファイル編集・コマンド実行件数表示)
下層ページ側の差し替えとCSS調整が入りました。文字化けも解消済みです。次は実際に主要ページをレンダリングして、横はみ出しやJSエラーがないか確認します。
PC幅では全ページが横にはみ出さず、アクティブナビも正しく出ています。Profileだけページ見出しがなかったので、他ページと揃えるために見出しブロックを追加します。
(省略: ファイル編集・コマンド実行件数表示)
スクリーンショットを見ると、Shields.ioの外部バッジが確認環境では読み込めず、代替テキストがそのまま見えて少し荒れていました。ネットワークが通らない環境でも整って見えるよう、読み込み失敗時は小さなテキストバッジへ自動置換します。
(省略: ファイル編集・コマンド実行件数表示)
はい、ほかのページもトップページのデザインに合わせて整えました。
Windows / Android / Tools / Web / Profile の各ページで、ヘッダー・ナビ・フッターをトップと同じ白ベースの構成に統一し、ページ見出し、プロダクト詳細カード、画像枠、ボタン、開閉セクションのトーンも揃えています。Profileには他ページと同じ見出しブロックも追加しました。
あわせて、外部バッジ画像が読み込めない環境でも崩れないように、バッジをテキスト表示へ自動置換する処理も script.js に入れています。
確認済み:
-
node --check script.jsOK - PC幅 / スマホ幅で windows.html, android.html, tools.html, web.html, profile.html をレンダリング確認
- 横スクロールなし
- JSエラーなし
- アクティブナビ表示 OK
- プレビューは引き続きこちらです:
http://127.0.0.1:4174/windows.html
Discussion