ども!HTML図解の自動生成シリーズを書いている龍ちゃんです。
AIコーディングでデザインの修正依頼を出すとき、「なんか違う」を言葉にするのに苦労していませんか? 僕もずっとそうでした。出来上がった図解を自分のイメージ通りに仕上げたいんだけど、テキストだけだと伝わらない。
画像を一緒に渡すだけで、これが解決しました。マルチモーダルな入力で言語化できなかった感覚がそのままAIに伝わって、総当たりの修正ループがディスカッションに変わります。
今回の内容です。
- レビューは人間の感覚が起点。でも言葉にするとあいまいになる
- 画像を加えると自分のイメージがそのまま伝わる実例
- イメージが共有されるとAIがディスカッション相手になる
順番に見ていきます。
前提:HTMLで図解を作っている
まず前提として、僕はブログ用の図解をHTML + Tailwind CSSで作っています。AIに指示を出すとHTMLコードが生成されて、それをブラウザでレンダリングしてPNGに変換するという流れですね。作り方の詳細はこのシリーズで紹介しています。
ここで厄介なのが、ソースがコードなので、見た目がどうなっているか書いた時点ではわからないということです。gap-6 や text-sm といったクラス名を見ても、実際にレンダリングしたときのバランスや印象はコードからは読み取れないんですよね。
だからPNGに変換して初めて「あ、なんか違うな」と気づくし、その修正をAIに伝えるときにも同じギャップが生まれる。AIもコードは読めるけど、レンダリング結果の「見た目の印象」まではコードだけじゃ判断できないんです。
これがこの記事の出発点です。
レビューの起点は人間の感覚。でも言葉はあいまい
図解を生成した後、デザインを自分のイメージに近づける作業が必ず発生しますよね。その出発点は「なんか詰まってる」「バランス悪い」という視覚的な違和感です。この感覚は正しくて、人間の目が最終的な品質の判断基準なんですよね。
でも、その感覚を言葉にした瞬間に問題が起きます。解釈の幅が生まれてしまう。
- 「スカスカ」→ 余白の話?情報量の話?文字サイズの話?
- 「詰まりすぎ」→ 行間?padding?要素数?
人間同士でも言葉のズレは起きるのに、AIにはなおさら伝わりにくいんですよね。
試しに、テキストだけでこういう修正依頼を出してみました。
右側が詰まりすぎて左側がスカスカに見える。バランスを整えてほしいAIの応答はこうでした。「スカスカ」を余白の問題と解釈して、幅・行間・gap の3箇所を同時に変更してきたんです。
でも僕が感じていたのは「のっぺりして見える」という感覚だったんですよね。言葉に変換した時点で、別の問題として伝わってしまった。

感覚が言語化を経由する瞬間に、AIの解釈が複数の方向に分岐してしまうんです。これがテキストだけでデザインレビューを進めるときの根本的な難しさですね。
画像を加えると自分のイメージがそのまま伝わる
同じ図解に、同じ修正依頼をした。でも今度は画像も一緒に渡しました。
するとAIの応答がガラッと変わったんですよね。
テキストだけのときは「スカスカ」という言葉から総当たりで修正してきたのに、画像ありのときはこう返してきました。
「右カラムが全部 text-sm(14px) で、のっぺりした灰色テキストの塊に見えます。レイアウトはそのまま、文字サイズの比率だけ調整するのはどうでしょう?」
これです。僕が感じていた「のっぺりして見える」という感覚の本質を、AIが画像から直接読み取ってくれたんですよね。言語化を経由していないから、あいまいさが入り込まなかった。修正箇所も1箇所に絞られました。
実際にこの記事用の図解でも、まさに同じことが起きています。さっきセクション1で見せた「言葉のあいまいさ」の図、あれは修正後なんですよね。修正前はこうでした。

「左寄り」「右に囲みがない」「下半分が空白」という問題があるんですが、僕は「左側に全体寄っているかな」「枠線がないのが気になる」くらいの感覚だったんです。AIは画像を見て、こう返してきました。
- 左のカードが左端に寄っていて、右側に大きな余白がある。
justify-centerがない - 左と中央はカードで囲まれているのに、右は3枚のカードが浮いている。グループ感がない
- 情報の広がり(1→1→3分岐)に対して高さが対応していない
僕が言語化しきれなかった「下半分が空白」という問題まで、AIが画像から補完してくれたんですよね。
なぜこんなに違いが出るのか、整理するとこうなります。
| 観点 | コード+言葉 | コード+言葉+画像 |
|---|---|---|
| 自分のイメージの伝わり方 | 言葉に変換 → あいまいになる | 画像で直接共有 → そのまま伝わる |
| AIの問題特定 | あいまいな言葉から推測 → 総当たり | 画像から視覚的に特定 → 的を絞れる |
| 修正の方向性 | 複数箇所を同時に微調整 | 原因を絞って1箇所を修正 |
画像は言語化を経由しないから、あいまいさが入り込む余地がないんですよね。「自分が見ているこれ」をそのままAIと共有できる。
イメージが共有されるとディスカッションになる
ここが一番面白い変化で。自分のイメージがAIに伝わっている状態になると、やり取りの性質が変わります。
テキストだけのとき:
人間が「右が詰まりすぎ」と指示 → AIが推測で3箇所修正 → 「なんか違う」→ 再指示 → …という一方通行のループになりがちです。
画像ありのとき:
AIが画像から問題を特定 → 「ここがこうなってるからこう直す」と提案 → 人間が判断する、という双方向のやり取りになります。

実際にこういうやり取りがありました。上の図(テキストのみ vs 画像あり)を作ったときの話です。修正前は線が薄くて見えないし、文字は小さいしで、全体的にぼんやりした印象でした。
その修正前の画像を見せながら「全体的に色味が薄いのと、テキストサイズをもう少し上げたほうが読みやすいと思う。他に問題点があれば画像から教えて」と伝えたところ、AIはこう返してきました。
- 左パネルのボーダー(slate-200)がほぼ見えない。右もblue-300で弱い
- カード内のテキストが text-sm(14px)で、PNGとして見ると読みづらい
- 上部のラベルと最初のカードの間のスペースがありすぎる
- アイコンが text-2xl(24px)で誰が誰か識別しづらい
- 左(NG)側がもっとネガティブに見えていい。右と構造が似すぎている
- 左のラベルが地味で、右の青ラベルと比べて存在感が薄い
僕は「全体的に色が薄い」という感覚しか持っていなかったのに、AIが画像から6つの具体的な問題を特定してくれたんですよね。人間は「そう、それ!」と判断するだけでいい状態になっていました。
修正内容はこうなりました。
| 対象 | 修正前 | 修正後 |
|---|---|---|
| ボーダー色 | slate-200, blue-300 | slate-400, blue-400 |
| ラベル | 薄い背景色ピル | 白抜き文字の濃色ピル(slate-600, blue-600) |
| テキストサイズ | text-sm(14px) | text-base(16px) |
| アイコンサイズ | text-2xl(24px) | text-3xl(30px) |
| 左の末尾カード | 通常ボーダー | 破線ボーダー(「まだ続く」感) |
| AIの提案カード(右) | bg-white | bg-blue-100(強調) |
| ループ/ディスカッション表示 | テキストのみ | 背景色付きピル(red-100, blue-200) |
イメージが共有されているから、修正後のPNGを再生成してまた渡せば、次のサイクルでもズレない。理想に向かって改善が積み上がっていくんですよね。AIが「指示待ちの修正マシン」から「一緒にデザインを詰めるディスカッション相手」に変わった感覚がありました。
Claude Code・Codex CLI・Gemini CLIでの画像の渡し方
ソースから見た目が生成されるものなら、どのツールにも使えます。HTMLに限らず、SVG、CSSだけのスタイル調整、Reactコンポーネントなんかも同じ考え方で動きます。
手順はシンプルです。
- ソース(HTML / CSSなど)を作る
- PNGに変換する(幅800px以上推奨。それ以下だとAIが細かい文字を読み取れないことがある)
- ソース+修正の言葉+画像をまとめてAIに渡す
僕が使っているのは Claude Code で、チャット入力欄に画像をドラッグ&ドロップするか、画像パスを貼り付けるだけです。Codex CLI や Gemini CLI もマルチモーダル入力に対応しているので、同じ考え方で使えるはずです。渡し方の詳細は各ツールの公式ドキュメントを確認してみてください。
一点だけ注意があって、「どの画像のどこが問題か」を言葉で明示しておくと精度が上がります。「右カラムの文字が読みづらい」くらい絞り込んでおくのがコツですね。
あと補足なんですが、この記事では「なんか違う」という感覚ベースのレビューを中心に紹介しました。でも、感覚をさらっと伝えるだけが正解ってわけじゃないんですよね。「左カラムのpadding-xを16pxから24pxに広げて、右カラムのtext-smをtext-baseに変えてほしい」みたいに、詳細にプロンプトを書くのも当然効果があります。画像+感覚ベースの指示と、画像+詳細な指示、どっちも使えるのがマルチモーダルの強みです。自分の中で問題が明確なら詳細に書けばいいし、「なんか違うけど何が違うか分からない」ときは感覚のまま画像と一緒に投げればいい。場面によって使い分けてみてください。
まとめ
デザインが成果物のとき、レビューの判断基準は人間の感覚です。でもその感覚を言葉にすると、どうしてもあいまいさが入り込む。
画像なら「自分が見ているもの」をそのままAIと共有できて、言語化のロスがなくなります。AIが問題を自分で特定して提案してくれる状態になると、やり取りが一方通行の指示ループから双方向のディスカッションに変わるんですよね。
次回はMarp CLIでスライドをPNG化して、専門AIレビューを適用する方法を紹介します。
ほなまた〜
関連ブログ
今回の記事はHTML図解シリーズの一部です。図解の作り方から気になる方はこちらからどうぞ。
- Claude Code SkillでHTML図解を自動生成する
— シリーズの出発点。Skillを使ってHTML + Tailwind CSSの図解をコマンド一発で作る仕組みを紹介しています - 図解作成、AIに丸投げしたら「たまに自分より上手い」件
— 実際に丸投げで作った図解の実例集。AIに任せたほうがいいケースと、人間が手を入れるべきケースの見極め方も書いています - MermaidをTailwindで設計書品質に仕上げる
— Mermaidのフロー図やシーケンス図を、Tailwindで見た目を整えて設計書にそのまま使えるレベルにする方法です - PlantUMLをTailwindで設計書品質に仕上げる
— PlantUML版。クラス図やアクティビティ図をTailwindで仕上げるパターンを紹介しています


