スクリーンショットでAIにUI修正を伝える：見た目と操作を分けて書く

「見た目」と「操作」を混在させると何が起きるか

UIの問題を一文で表現しようとすると、「ボタンが分かりにくい」のような言葉に落ち着きがちだ。しかしこの一文には、少なくとも二種類の異なる問題が含まれうる。ひとつは視覚的な問題——色のコントラストが低い、文字が小さすぎる、余白のバランスが崩れている、といった「見ればわかる」ものだ。もうひとつは操作上の問題——タップ領域が狭すぎる、押した感触（フィードバック）がない、意図しない要素が反応する、といった「使ってみて初めてわかる」ものだ。

この二つを混ぜたまま「ボタンを改善して」とAIに依頼すると、回答は曖昧な方向を向きやすい。「色を変えてみては」「もう少し大きくしては」という一般的なアドバイスにとどまり、実際に何をどう直せばよいかが伝わらない。スクリーンショットは、この分類を助ける最初の道具になる。

使えるスクリーンショットの条件を整理する

AIに画像を渡して修正の相談をする場合、まず「その画像を誰でも見せられるか」を確認しておく必要がある。自分が制作したゲームの画面であれば、制作者本人が権利を持っているので問題は生じにくい。問題が起きやすいのは、参考にしたい他社のゲームやアプリの画面を使う場合だ。AIとの会話であっても、他者が権利を持つ画像を含めることは著作権上の注意が必要になる。この記事が扱うのは、自分が作っているゲームのUIスクリーンショットを使う場面に限る。

また、修正依頼を後から見返せるよう、画像とテキスト記述のセットを記録として残しておくと便利だ。「変更前」と「変更後」の画像を並べて管理すると、AIとの会話の文脈を保ちやすく、同じ問題が再発したときに参照できる。

対象端末の種類とブラウザ（例：iPhone Safari、Windows Chrome）をファイル名やメモに添えておくと、後述する操作上の問題を記述するときに役立つ。同じデザインでも端末によって表示が変わる場合があるため、どの環境で撮影したかを残しておく。

見た目の問題を記述するテンプレート

視覚的な問題は「画面のどこに」「何が」「どう見えるか」を順番に書くと伝わりやすい。AIは画像内の位置を参照できるが、「左上のボタン」「中央のテキスト」のように言葉でも位置を補足すると精度が上がる。

テンプレート（見た目）

• 場所：画面のどこか（例：タイトル画面の右下、ゲームオーバー時のリトライボタン）
• 問題：何がどう見えるか（例：ボタンの背景色がページ背景と似すぎていて、ボタンと認識しにくい）
• 期待する状態：どうなってほしいか（例：ボタンであることが一目でわかる。青背景に白テキストの組み合わせは維持したい）
• 制約：変えたくない要素（例：フォントはそのまま、ロゴのサイズは変えない）

実際に使う場合の記述例を示す。「添付のスクリーンショット（タイトル画面）の右下にある「はじめる」ボタンについて相談したい。背景が薄いグレーで、ボタンの枠線も薄いグレーのため、画面を初めて見たプレイヤーにはボタンと認識されにくいかもしれない。フォントと文言は変えずに、視覚的な区別をつける方法を提案してほしい。」このように「場所・問題・期待・制約」を分けて書くと、AIは全体のデザインを一度に変えるような提案ではなく、特定の要素への修正提案を返しやすくなる。

操作の問題を記述するテンプレート

操作上の問題は画像だけでは伝わらない。「どの操作で」「何が起きたか」「何を期待していたか」を文章で補う必要がある。スクリーンショットはあくまで文脈を示す補助として使い、本体は文章による記述だ。

テンプレート（操作）

• 環境：端末・ブラウザ（例：Android Chrome 126、iPhone Safari 17）
• 操作手順：何をしたか（例：タイトル画面で「はじめる」ボタンをタップした）
• 実際の結果：何が起きたか（例：反応がなく、約1秒後に画面が切り替わった。切り替わる前に視覚的な変化がなかった）
• 期待した結果：何が起きてほしかったか（例：タップした瞬間に色の変化など、押されたことがわかるフィードバックがほしい）
• 参考画像：問題が起きた状態、または期待する状態のスクリーンショット（添付）

実際の記述例を示す。「iPhone Safari（iOS 17）で確認した。タイトル画面の「はじめる」ボタンをタップしたが、押した直後に見た目の変化がなく、約1秒間反応がないように感じた。添付の画面はタップ前の状態だが、タップ後も同じ見た目のままだった。押されたと認識できる即時のフィードバック（色が変わる、ボタンが少し凹む表現など）をCSSで追加する方法を教えてほしい。」

このように書くと、AIはCSSの:active 疑似クラスや transitionなど、操作フィードバックに関連する具体的な実装例を返しやすくなる。「ボタンが重たい感じ」という曖昧な表現よりも、修正の方向が絞り込まれる。

「見た目」と「操作」を分けてAIに送る実際の流れ

ひとつのUIに複数の問題がある場合は、一度の会話にまとめず、問題ごとに分けて依頼するほうが整理しやすい。見た目の修正と操作の修正を混ぜて依頼すると、双方が中途半端な提案にまとめられることがある。

1. 修正したいUIのスクリーンショットを撮る。端末・ブラウザを記録する。
2. 問題を「見た目」と「操作」に仕分けする。ひとつの問題がどちらのカテゴリに属するかを先に決める。
3. 見た目の問題があれば、画像と「場所・問題・期待・制約」のテンプレートでAIに依頼する。
4. 操作の問題があれば、別の依頼として「環境・操作手順・実際の結果・期待した結果・参考画像」の形式で送る。
5. 受け取ったコードや提案を実装し、同じ環境でスクリーンショットを撮り直す。「変更前」と「変更後」を並べて差分を確認する。
6. まだ問題が残っていれば、変更後の画像と「この点が改善した、この点はまだ残っている」を追加して会話を続ける。

AIが返したコードは参考として示されるものであり、動作を保証するものではない。実装後は必ず実機またはブラウザで確認し、意図しない表示崩れがないかを目視で確かめる。

よくある詰まりどころと、この方法の限界

「どちらか分からない問題」は意外と多い。たとえば「ボタンの位置がなんか変」という感覚は、見た目のバランスの問題（余白・配置）なのか、操作動線の問題（次に押すべき場所として自然かどうか）なのか、どちらとも取れる。こういう場合は「見た目として変か、操作として変か、自分でも特定できていない」とAIに率直に伝えてよい。画像を添えた上で「この画面で違和感を感じている。視覚的な問題か操作上の問題かを切り分ける質問をしてほしい」と依頼すると、AIが整理の入口を作ってくれる場合がある。

この方法の限界もある。スクリーンショットは静止画なので、アニメーション・音・連続した操作の流れは伝えられない。スクロール中のずれや、複数のタップを続けたときの挙動のような時間軸が関係する問題は、言葉による詳細な記述がより重要になる。また、AIが画像から読み取れる情報には限界がある。ごく小さな文字や細い線は正確に認識されないことがあるので、そうした要素に関しては文章で補足する。

複数のUIを一度に直そうとして、一回の会話に画像を何枚も貼り付けると、回答がどの問題を指しているか曖昧になりやすい。問題が多い場合でも、一回の会話では一つの問題を扱うことをおすすめする。修正の粒度を小さく保つことが、UIを少しずつ確実に整えていく近道になる。

ゲームのUIは遊んでいるプレイヤーの操作に直結する。画面の第一印象と、実際に触れたときの感触が揃って初めて「使いやすいUI」と感じてもらえる。言葉にしにくい違和感を、スクリーンショットと分類という補助線を使って整理することで、AIとのやりとりはより具体的な修正につながりやすくなる。