ChatGPTでアプリUIを画像どおりに直せない原因は？一部だけ元デザインが残る理由と改善指示のコツ

ChatGPTを使ってアプリ開発をしていると、改善後のUIイメージ画像はきれいに作れたのに、「この画像のように実装して」と依頼すると、ボタンや背景、余白、ヘッダーなど一部だけ以前のデザインが残ることがあります。これは必ずしもAIが画像を認識できていないからではありません。

大きな理由は、画像は完成イメージを示す参考資料であって、どのファイル・コンポーネント・CSS・状態をどの値へ変更するかまで定義した実装仕様書ではないことです。さらに既存アプリでは、複数のコンポーネントやスタイル、テーマ設定、キャッシュなどが重なって表示を作っているため、一部分だけ変更しても以前の見た目が残ることがあります。

この記事では、ChatGPTを使ったアプリ開発で「画像どおりにしたはずなのに一部だけ元のUIが残る」原因を、AIへの指示方法と実際のコード構造の両面から整理し、再現精度を上げる方法を具体的に解説します。

画像を見せただけでは「どのコードを変更するか」までは一意に決まらない

UI画像からは、色、配置、文字サイズ、角丸、余白など見た目の情報を読み取れます。しかし、その画面が実際にどのようなコードから作られているかは画像だけでは分かりません。

例えば画面上に青いボタンが1つ見えていても、実装では Button.tsx、HomeScreen.tsx、共通CSS、テーマ設定など複数箇所が関係していることがあります。画像から「青を黒へ変更する」と判断できても、「どのファイルのどの定義を直せば全画面へ反映されるか」はコード側の情報が必要です。

画像は「何にしたいか」を伝える資料、ソースコードは「どこをどう直すか」を判断する資料です。UI変更では両方をそろえるほど精度が上がります。

ChatGPTが既存UIをあえて残している場合もある

「画像のように改善して」という指示には、実は複数の解釈があります。「既存機能は全部残しながら見た目だけ似せる」「画像と完全に同じレイアウトへ置き換える」「画像を参考に一部だけ改善する」などです。

明確な指定がなければ、AIは既存コードを壊さないことを優先し、必要そうな部分だけ変更する場合があります。その結果、画像には存在しない旧ボタン、旧カード、古い余白などが残ることがあります。

特に「改善して」「いい感じにして」「画像のようにして」といった表現は人間同士でも解釈の幅があります。AIへ実装を任せる場合には、「既存デザインをできるだけ維持する」のか「画面構成そのものを全面的に置き換える」のかを明示するほうが確実です。

改善画像と実装指示を別々にしたことが原因になる場合

ChatGPTに「UIの改善案を画像にして」と依頼すると、その画像は新しいデザイン案として生成されます。しかし、その画像を作ったときに想定した内部構造と、実際のアプリコードの構造が同じとは限りません。

例えば生成画像ではカードが3枚横並びになっていても、実際のコードでは「上段リスト」と「下段パネル」が別コンポーネントとして実装されている可能性があります。画像生成では見た目として自然でも、実装時には既存コードとの対応付けが必要になります。

そのため、「先ほど作った画像のように」だけではなく、「この画像を完成仕様として扱い、現在の画面との差分を先に列挙してから、該当するすべてのコンポーネントを変更する」と依頼すると抜けを減らせます。

一部だけ元の状態が残る代表的な原因

実際のアプリ側でも、部分的に旧デザインが残る原因はいくつもあります。特に次のようなケースはよくあります。

原因	起きる症状	確認すること
別コンポーネントを変更していない	一部のボタンやカードだけ旧UI	画面を構成する全コンポーネント
共通CSS・テーマが残っている	色やフォントだけ旧状態	global.css、theme、design tokens
CSSの優先順位	新CSSを書いたのに反映されない	specificity、inline style、!important
条件分岐した別UI	特定状態だけ旧UIになる	if、三項演算子、画面状態
レスポンシブ用CSS	PCは新UI、スマホだけ旧UI	media query、breakpoint
同名・類似コンポーネント	直したファイルと別のものが表示される	import先、使用箇所
キャッシュ・古いビルド	コードは正しいのに旧画面	再ビルド、開発サーバー、ブラウザキャッシュ

AIへの指示を変えても改善しない場合は、単なるプロンプトの問題ではなく、このような実装上の原因を疑う必要があります。

まず「画面を作っているファイル」を全部特定する

一部分だけ旧UIが残る場合、最初にやるべきことは修正を繰り返すことではなく、その画面を構成しているコードを確認することです。

例えばReactアプリなら、画面本体が Dashboard.tsx でも、内部で Header、Sidebar、StatCard、BottomNav などを呼び出していることがあります。さらに各コンポーネントが別CSSやTailwindのクラスを持っていることもあります。

そこでChatGPTへは「この画面に関係するコンポーネント、CSS、テーマファイルを先に特定してください。まだコードは変更しないでください」と依頼すると、変更漏れを発見しやすくなります。

「画像との差分を一覧化してから実装」が効果的

いきなり「この画像にしてください」と実装させるより、最初に現状画面と目標画像の差分を整理すると精度が上がります。

例えば次のような差分を先に列挙させます。

• ヘッダーの高さを変更
• 背景色を変更
• カードを2列から1列へ変更
• カードの角丸を変更
• 旧サイドバーを削除
• 新しい下部ナビゲーションを追加
• ボタンの色・高さ・アイコンを変更
• 見出しと本文のフォントサイズを変更

この一覧を確認した後に「この差分をすべて実装し、完了後に各項目が反映されたかチェックしてください」と依頼すれば、一部分だけ修正して終了する可能性を減らせます。

「元のUIを残さない」と明示する

全面的に作り直したい場合は、その意図を明確に伝える必要があります。「画像のようにして」ではなく、「既存UIとの互換性は機能面だけ維持し、見た目については旧デザインを残さない」と指定します。

例えば次のような条件を伝えると実装範囲が明確になります。

この画像を最終的なUI仕様として扱ってください。
既存画面を部分修正するのではなく、画面全体を比較してください。
旧デザインの色、余白、カード、ボタン、ナビゲーションを残さないでください。
ただし現在動作している機能・データ処理は維持してください。
実装前に差分一覧を作り、実装後に全項目を再確認してください。

このように「見た目は全面置換、機能は維持」と役割を分けると、既存コードをどこまで保存すべきか判断しやすくなります。

画像だけでなく寸法や色も数値で指定すると精度が上がる

画像から「だいたい24pxくらい」「少し薄いグレー」と推測することはできますが、正確なデザイン値までは確定できません。そのため重要な部分は数値でも指定すると再現性が高まります。

例えば「カード角丸16px」「左右padding 20px」「見出し24px」「カード間隔12px」「最大幅1200px」のように指定します。色についても #FFFFFF や #111827 のように値を決める方法があります。

特にピクセル単位で高い再現性が必要なら、画像だけでなくFigmaなどのデザインデータから寸法を確認して実装するほうが確実です。

共通コンポーネントが旧デザインを戻している場合

アプリでは同じボタンやカードを何度も書かず、共通コンポーネントとして再利用することがあります。これは正しい設計ですが、UI改修時には注意が必要です。

例えばページ側で新しい色を指定しても、共通の Button コンポーネント内部で旧色が固定されていれば、一部のボタンだけ古い状態に見えることがあります。

同じ見た目が複数箇所に残っている場合は、個々の画面を修正するより、共通コンポーネントやデザイントークンを確認したほうが解決が早いことがあります。

CSSの優先順位で古いスタイルが勝っていることもある

コード上では新しいCSSを書いたのに画面が変わらない場合、古いCSSのほうが優先されている可能性があります。CSSにはspecificityと呼ばれる優先順位の仕組みがあります。

例えば新しく .button を設定しても、既存コードにより具体的なセレクターやインラインスタイル、!important が存在すれば、そちらが適用される場合があります。

この問題ではAIへ何度も「もっと画像に近づけて」と指示するより、ブラウザの開発者ツールで対象要素を調べ、「最終的にどのCSSルールが適用されているか」を確認するほうが早く原因を特定できます。

Tailwind CSSでも古いクラスが残ることがある

Tailwind CSSを利用しているアプリでも同様です。例えば親コンポーネントを新しくしても、子コンポーネントに bg-blue-500 や rounded-md など旧デザインのクラスが残っていれば、その部分だけ以前の見た目になります。

また画面サイズによって md:、lg: など別のクラスが有効になるため、デスクトップだけ旧デザインが現れることもあります。

画像に近づける場合は、通常状態だけでなくモバイル・タブレット・PCの各ブレークポイントを確認する必要があります。

条件分岐の中に旧UIが残っている場合

見た目が常に古いわけではなく、「ログイン後だけ」「データが0件のときだけ」「エラー時だけ」旧UIになる場合は、別のレンダリング処理が残っている可能性があります。

例えば次のようなコードです。

if (loading) {
  return <OldLoadingScreen />;
}

if (items.length === 0) {
  return <OldEmptyState />;
}

return <NewDashboard />;

通常状態の NewDashboard だけ変更しても、読み込み中や0件状態では古いUIが表示されます。UIの全面改修では通常画面だけでなく、loading、empty、error、disabled、hover、modalなど各状態も確認する必要があります。

画面ごとの重複コードが原因になることもある

開発途中のアプリでは、似たUIをコピーして複数ページへ貼り付けていることがあります。その場合、あるページを修正しても別ページには古いコードが残ります。

例えば HomeHeader と ProfileHeader がほぼ同じ見た目なのに別々に実装されている場合、片方だけ修正して「ヘッダーを変更した」と判断してしまう可能性があります。

UI全体を統一したいなら、同じ役割の部品を共通コンポーネントへ整理することも有効です。AIへ「似たUIの重複実装がないか検索し、共通化できるものを一覧化してください」と依頼する方法があります。

キャッシュや開発サーバーが原因で旧画面が見える場合

コード自体は修正済みなのに、ブラウザやアプリ側に古いビルドが残っていて旧UIが表示されることもあります。

Webアプリならブラウザキャッシュ、Service Worker、開発サーバー、ビルド成果物などを確認します。React NativeやFlutterなどでも、ホットリロードだけでは反映されず、再起動や再ビルドが必要になる場合があります。

「ソースを検索すると旧色のコードは存在しないのに、画面にはまだ旧色が出る」という場合は、AIの修正漏れだけでなくキャッシュ・ビルドも候補になります。

画像と実際の画面を同じ条件で比較する

生成したUI画像がiPhoneサイズなのに、実装結果をPCブラウザで比較していると、同じレイアウトにならないことがあります。画面幅、OS、フォント、ステータスバー、セーフエリアなどによって見え方が変わるためです。

例えば画像が幅390pxを想定しているなら、実装側も同程度のビューポートで確認します。レスポンシブUIでは特に重要です。

また、実装で使えるフォントと生成画像に描かれたフォントが異なる場合、文字幅が変わって改行位置やボタンサイズにも差が出ます。完全一致を目指す場合は使用フォントも明示する必要があります。

「画像をそのまま使う」と「画像のUIをコードで再現する」は違う

「この画像を使って同じにして」という表現も曖昧になりやすいポイントです。画像自体を背景や素材として表示したいのか、画像に描かれたUIをHTML・CSS・Reactなどで再構築したいのかは別の作業です。

通常のアプリUIでは、生成された画面画像そのものを1枚の画像として配置するのではなく、ボタン、テキスト、入力欄などを実際のUIコンポーネントとして実装します。そのため画像を解析して各要素へ置き換える工程が必要です。

依頼時には「画像を素材として配置するのではなく、画像をデザイン仕様として扱い、各UI要素をコードで再現してください」と伝えると誤解を減らせます。

ChatGPTに十分なコードが渡っていない可能性もある

AIが修正すべきファイルをすべて確認できていなければ、当然ながら見えていない場所の旧デザインを変更することはできません。

長期的な開発では、関連するコードや指示を同じ作業コンテキストに整理することが重要です。ChatGPTのProjectsでは、関連するチャット、ファイル、指示などを一つのプロジェクトへまとめて利用できます。OpenAI Projectsの説明[参照]

またChatGPTは画像入力にも対応しているため、目標デザインだけでなく「現在実際に表示されている画面」のスクリーンショットも一緒に提示し、「この2枚の差分を確認して」と依頼すると問題箇所を具体化しやすくなります。ChatGPTの画像入力について[参照]

現在のスクリーンショットも渡すと修正漏れを見つけやすい

目標画像だけを渡すより、「現在の実装画面」と「目標デザイン」の2枚を渡すほうが比較しやすくなります。

例えば、「左が現在、右が完成目標です。色だけでなく、要素の有無、位置、余白、サイズ、フォント、角丸、アイコンを比較し、差分を表にしてください」と依頼できます。

その後にコードを修正させれば、「画像にはない旧ボタンが残っている」といった単純な見落としも発見しやすくなります。

一度に全部変更するよりエリア単位で完成させる方法も有効

画面が複雑な場合は、1回の指示で全体を完全に作り替えるより、ヘッダー、メインコンテンツ、カード、フッター・ナビゲーションなどに分けて修正する方法もあります。

例えば最初に「ヘッダーだけ目標画像と一致させる」として完成を確認し、その後カード領域、下部ナビゲーションへ進みます。

ただし最後には画面全体を再比較する必要があります。部分ごとには正しくても、全体で見ると余白やサイズ感がずれる場合があるためです。

AIへ「変更したファイル一覧」を出させる

実装後に何を変更したのか分からないまま画面だけ確認すると、修正漏れの原因を探しにくくなります。そのため、変更後にファイル一覧と変更内容を報告させる方法が有効です。

例えば「実装後、変更したファイル名と各ファイルで変更したUIを一覧化してください。また、画像との差分が残っている可能性がある箇所も報告してください」と指示します。

こうすると、例えば Header.tsx と Home.css しか触っていないのに、画像では BottomNavigation.tsx も変更すべきだった、といった不足を発見できます。

旧デザインの色やクラス名をコード全体から検索する

以前の状態が視覚的に残っているなら、旧デザイン特有の値をコード全体から検索する方法も効果的です。

例えば以前の背景色が #1976d2 なら、そのカラーコードをプロジェクト全体で検索します。旧カードのクラス名が old-card なら、それも検索します。

AIへ「旧UIで使っていたカラーコード、CSSクラス、コンポーネント名をリポジトリ全体で検索し、残存箇所を列挙してください」と依頼すれば、目視だけでは見つけにくい古い実装を探せます。

削除してよい要素を明示することも重要

AIは既存機能を壊さないように、以前の要素を残そうとすることがあります。特に「画像には存在しないが現在のアプリには存在する要素」をどうするのか指定されていない場合です。

例えば旧画面には検索欄があり、新しい画像には検索欄がない場合、「検索欄を削除する」のか「新しい位置へ移動する」のか判断できません。

そこで「目標画像に存在しない旧UI要素は削除。ただし裏側のデータ処理は必要なら残す」といったルールを指定します。デザインと機能を分けて指示することがポイントです。

機能を壊さないために見た目とロジックを分離する

UIを全面変更するときに、既存コードを全部書き直すよう指示すると、今度はログイン、API通信、フォーム送信など正常に動いていた機能まで壊れる恐れがあります。

理想的なのは、データ取得や状態管理などのロジックは必要に応じて維持し、表示部分を新しいUIへ置き換えることです。

AIへは「API通信、状態管理、イベント処理など現在正常に動作するロジックは維持し、表示コンポーネントとスタイルを目標画像に合わせて変更してください」と伝えると安全性が高まります。

完成後にチェックリスト形式で自己検証させる

コードを変更した時点で作業終了にせず、実装結果を検証する工程を入れることも重要です。

例えば、次の項目を確認させます。

• 旧UIの要素が残っていないか
• 目標画像にある要素がすべて存在するか
• 色が一致しているか
• 余白と配置が一致しているか
• スマホ表示が崩れていないか
• PC表示も確認したか
• loading・empty・error状態も更新したか
• 既存機能が維持されているか
• コンソールエラーが発生していないか

単に「できました」と判断させるより、具体的な検査項目を指定したほうが仕上がりを確認しやすくなります。

うまくいかないときに使える指示文の例

目標画像へ全面的に合わせたい場合は、曖昧な一文だけではなく、実装プロセスまで指定すると効果的です。

添付した画像を、この画面の最終UI仕様として扱ってください。

現在の画面と目標画像を比較し、まず差分をすべて列挙してください。
まだコードは変更しないでください。

次に、この画面を構成するコンポーネント、CSS、テーマ、共通部品を確認してください。

実装時は以下を守ってください。
・現在正常に動作している機能とデータ処理は維持する
・見た目は目標画像へ置き換える
・画像に存在しない旧UIは残さない
・通常状態だけでなくloading、empty、error状態も確認する
・モバイルとPCの両方を確認する
・変更後に目標画像との差分が残っていないか再チェックする
・最後に変更したファイル一覧を報告する

このように指示すると、単発のデザイン変更ではなく「調査→差分整理→実装→検証」という開発工程として処理しやすくなります。

さらに精度を上げるならデザイン仕様書を作る

同じアプリを何度も改善する場合、毎回画像だけを基準にするとボタンやカードのデザインが少しずつ変わり、画面ごとに不統一になることがあります。

そこで背景色、文字色、アクセントカラー、フォントサイズ、余白、角丸、ボタン高さなどを簡単なデザインルールとして決めておくと便利です。

項目	仕様例
背景	#F7F8FA
本文文字	#222222
メインカラー	#2563EB
カード角丸	16px
標準余白	16px
ボタン高さ	48px

実際の値はアプリに合わせて決めます。こうしたルールをCSS変数やテーマ、デザイントークンとして共通化すると、AIによる変更でも画面全体の統一感を保ちやすくなります。

ChatGPTだけでなくブラウザの開発者ツールも活用する

AI開発では「もう一度直して」と繰り返すより、自分でも原因を確認できると解決が速くなります。Webアプリならブラウザの開発者ツールで、対象要素のHTMLと適用中CSSを確認できます。

例えば旧背景色が残っている要素を選択すれば、どのCSSファイルの何行目から色が指定されているか分かる場合があります。その情報をChatGPTへ伝えて「このルールが新デザインを上書きしているので整理してください」と依頼できます。

AIを単にコードを生成する道具として使うより、開発者ツール、エラーログ、スクリーンショットなどの実際の情報を渡して原因調査に利用するほうが、複雑なアプリでは効果的です。

何度直しても戻る場合は設計そのものを確認する

同じ箇所を何度変更しても旧デザインへ戻る場合は、単純な修正漏れではなく、スタイルの管理方法そのものに問題がある可能性があります。

例えば各ページに同じ色が直接記述されている、共通ボタンが複数種類存在する、グローバルCSSとコンポーネントCSSが競合している、といった状態です。

この場合は「画像へ合わせる修正」を続けるより、「現在のスタイル構成を調査して、重複・競合・ハードコードされたデザイン値を整理してください」と依頼し、設計を整えてからUI変更を行うほうが再発を防げます。

まとめ｜画像だけでなく「差分・対象コード・変更ルール」を伝える

ChatGPTで作った改善UI画像を元にアプリを修正しても、一部だけ以前の状態が残るのは珍しいことではありません。画像は完成イメージを伝えることには優れていますが、どのコンポーネントやCSSを変更するかまで自動的に一意に決まるわけではないためです。

さらに実際の原因として、変更対象コンポーネントの漏れ、共通スタイル、CSSの優先順位、レスポンシブ設定、条件分岐した別UI、キャッシュ、古いビルドなどが考えられます。

最も効果的なのは「この画像のようにして」と一言で依頼するのではなく、「現状と画像の差分を列挙→関連ファイルを特定→旧UIを残さず実装→完成後に再比較」という手順を指示することです。

目標画像と現在のスクリーンショットを両方渡し、さらに実際のソースコードを確認できる状態にすると精度は上がります。加えて色・余白・サイズなど重要な値を数値で指定し、完成後にチェックリストで検証すれば、「ほとんど新しくなったのに一部だけ昔のUI」という状態を減らしやすくなります。