Claude Codeスクリーンショット実装 — モックアップからUIを作る手順
Claude Codeに画像を渡してUIを実装する手順をまとめます。モックアップからのCSS・HTML生成、実装結果をスクリーンショットで検証するフィードバックループ、画像サイズの上限まで扱います。
Claude Codeは画像を会話に渡すだけで、デザインモックアップからCSSやHTMLを生成させたり、UIのスクリーンショットを見せてバグの原因を探らせたりできます。テキストで細部を説明するより、画像を1枚渡すほうが速く正確に意図が伝わる場面は多くあります。本記事では画像の渡し方から、モックアップを実装に落とす手順、実装結果を画像で検証するフィードバックループまでを扱います。
Claude Codeに画像を渡すとできること
画像を使ったUI実装とは、テキストの説明だけでなく視覚的な情報そのものを入力に使う作業です。Claude Codeは渡された画像を解析し、次の3つの用途に使えます。
- UIの分析: スクリーンショットに写ったUI要素や崩れを説明させる
- エラー診断: エラー画面のスクリーンショットから原因を推測させる
- コード生成: デザインモックアップからCSSやHTML構造を組み立てさせる
テキストの説明があいまいになりがちな見た目の情報を扱うときほど、画像を渡す効果が大きくなります。
画像をセッションに追加する3つの方法
画像を会話に加える方法は3つあります。
1. ドラッグ&ドロップ
画像ファイルをClaude Codeのウィンドウにドラッグ&ドロップします。
2. クリップボードから貼り付け
画像をコピーして Ctrl+V で貼り付けます。macOSのiTerm2では Cmd+V も使えます。
3. パスを直接指定する
ファイルパスをそのままプロンプトに書きます。
Analyze this image: /path/to/mockup.pngいずれの方法でも、1回の会話で複数の画像を扱えます。エラー画面と正常時の画面を2枚並べて渡し、違いを比較させるような使い方もできます。
モックアップからCSS・HTMLを生成させる
デザインモックアップの画像を渡し、実装コードを生成させます。
Generate CSS to match this design mockupWhat HTML structure would recreate this component?生成の精度を上げるコツは、依頼を具体的にすることです。「このデザイン通りに作って」だけでは、余白や配色の解釈がClaude Code任せになります。「ヘッダーの高さは64px、背景色はモックアップの薄いグレーに合わせて」のように、数値化できる要素は言葉でも補うと再現度が安定します。
複数の画像を1つの依頼で渡すときは、それぞれに「1枚目はデスクトップ表示、2枚目はモバイル表示」のようなラベルを添えると、どの画像がどの意図かをClaude Codeが取り違えません。既存の実装スクリーンショットとモックアップを並べて「この2つの差分を埋めて」と頼む使い方も、変更点を絞り込みたいときに有効です。
複雑な画面を一度にまるごと実装させようとすると、部分ごとの精度がばらつきやすくなります。ヘッダー、カード一覧、フッターのように画面をブロック単位で区切り、「まずヘッダー部分だけ実装して」と1ブロックずつ依頼すると、各パーツの再現度を確認しながら進められます。既存のデザインシステムやコンポーネントライブラリを使っているプロジェクトでは、「既存のButtonコンポーネントを再利用して」のように、ゼロから書かせるのではなく既存コードとの統合を明示すると、プロジェクトのコードベースと乖離した実装になりにくくなります。
画像を使う場面・使わない場面の判断
画像を渡す方法が常に最速とは限りません。テキストによる指示のほうが速く正確に伝わる場面もあります。
| 場面 | 画像の有効度 | 理由 |
|---|---|---|
| 複雑なレイアウト・余白の再現 | 画像の有効度◎ | 理由言葉での説明より画像1枚のほうが誤解が少ない |
| 既存UIのバグ・崩れの診断 | 画像の有効度◎ | 理由スクリーンショットがあれば状況説明が不要になる |
| 配色・フォントの細かい調整 | 画像の有効度○ | 理由画像は有効だが、正確な色コードは別途言葉で補うと安定する |
| 単純なテキスト変更・文言修正 | 画像の有効度△ | 理由画像を使わずテキストで直接指示したほうが速い |
| デザイントークンをそのまま実装へ反映したい | 画像の有効度△ | 理由Figma MCPサーバーなど構造化データを扱う経路のほうが正確 |
実装結果を画像で検証するフィードバックループ
モックアップから一度で完全に一致するコードが出ることは多くありません。実装したUIを実際にレンダリングし、その見た目を画像としてClaude Codeへ渡し直す一往復を挟むと、仕上がりの精度が上がります。
Claude CodeはChromeブラウザ拡張機能と連携させることで、この検証工程自体を1つの会話の中で完結できます。拡張機能を接続した状態であれば、実装したUIをブラウザで実際に開かせ、モックアップと見比べさせる使い方が公式のワークフロー例としても挙げられています。ブラウザでスクリーンショットを撮って保存させる依頼も可能です。
Take a screenshot of the checkout page and save it to disk保存した画像を「このスクリーンショットと元のモックアップを比較して、差分を教えて」と渡し直せば、余白のズレやフォントサイズの違いなど、コードだけでは気づきにくい見た目のギャップを指摘させられます。この一往復を繰り返すことで、テキストの説明だけに頼るより早く実装をモックアップへ寄せていけます。
レスポンシブ対応やダークモードのように状態が複数あるUIでは、状態ごとにこのループを分けて回すと精度が安定します。デスクトップ表示を仕上げてからモバイル幅のスクリーンショットを撮らせて比較し、続けてダークモードに切り替えたスクリーンショットで同じ手順を繰り返す、という進め方です。1回のやり取りで全パターンをまとめて検証させようとすると、指摘が混ざって見落としが増えるため、状態を1つずつ区切るほうが手戻りが少なくなります。
デザインファイル側にトークンや変数といった構造化データがあり、それをそのまま実装へ反映したい場合は、画像ベースの実装よりFigma MCPサーバーを使う経路のほうが正確です。画像を渡す方法は、Figmaのアクセス権がない・スクリーンショットしか手元にない、といった場面での代替手段として位置付けると使い分けやすくなります。
画像サイズの上限とエラーが出たときの対処
Claude Codeが扱える画像には上限があります。
| 上限の種類 | 値 |
|---|---|
| 単一画像の長辺 | 値8,000ピクセルまで |
| 複数画像を同時にコンテキストに含める場合の長辺 | 値2,000ピクセルまで |
| 会話全体のリクエストサイズ(画像・添付ファイル合計) | 値32MBまで |
大きすぎる画像を渡すと Image was too large というエラーになることがあります。対処の詳細はImage was too largeエラーの対処法にまとめています。
画像の形式が読み取れない、または縮小処理自体が失敗する場合は Unable to resize image というエラーになります。こちらの対処はUnable to resize imageエラーの対処法を参照してください。
スクリーンショットツールで撮った直後の画像は、Retinaディスプレイなどの環境では実寸よりかなり大きなピクセル数になっていることがあります。あらかじめ長辺を2,000ピクセル前後にリサイズしてから渡しておくと、エラーで再試行が挟まる回数を減らせます。
よくあるつまずき
- 依頼が抽象的すぎる: 「いい感じに実装して」では余白やフォントの解釈がぶれます。数値や色コードなど具体的な情報を言葉でも添えます
- 画像を渡さずに口頭で説明する: 複雑なレイアウトほど、テキストでの説明より画像1枚のほうが正確に伝わります
- 検証を1回で終わらせる: 最初の生成結果をそのまま採用せず、実装結果をスクリーンショットで見比べる一往復を挟むと精度が上がります
- 画像サイズを気にせず添付する: 高解像度の画像をそのまま渡すと自動縮小がかかり、細かい文字が潰れることがあります。あらかじめ長辺2,000ピクセル前後に収めておくと安定します
- 複数画像の意図を区別せずに渡す: どの画像が何を表すかラベルを付けないと、比較の意図が伝わらないことがあります
よくある質問
生成されたCSSの配色がモックアップと微妙に違う場合はどうすればいいですか
「ヘッダーの背景色をモックアップの左上、正確には#1a1a2eに合わせて」のように、目視で読み取った色コードを言葉で補うと修正が的確になります。画像だけでは正確な色の数値まで読み取れないことがあるため、重要な配色は数値で指定するのが確実です。
画像はどのファイル形式に対応していますか
PNG・JPEG・GIF・WebPに対応しています。対応外の形式や、寸法を読み取れない画像では Unable to resize image エラーになるため、事前に対応形式へ変換します。
動画やGIFのアニメーションは解析できますか
扱えるのは静止画で、動画ファイルは渡せません。アニメーションGIFはファイルとしては受け付けますが、動きそのものを追って解析する用途には向きません。
モバイル表示とデスクトップ表示を同時に実装させられますか
できます。デスクトップ用とモバイル用のモックアップをそれぞれラベル付きで渡し、「1枚目はデスクトップ、2枚目はモバイルのレイアウトとして実装して」のように指定します。
手書きのワイヤーフレームでも読み取れますか
画像として渡せる形式であれば、手書きのワイヤーフレームを撮った写真も入力に使えます。色や細かい数値までは手書きから読み取りきれないことがあるため、精度が必要な部分は写真とあわせて言葉でも補うと安定します。
Chrome拡張機能を接続していないと画像でのUI実装は使えませんか
画像を渡してコードを生成させるだけなら拡張機能は不要です。拡張機能が必要になるのは、実装結果をブラウザで開いて自動でスクリーンショットを撮らせる検証ループを回すときです。ブラウザでの確認を手動で行い、そのスクリーンショットを自分で貼り付ける分には拡張機能なしでも同じ流れを再現できます。
まとめ
Claude Codeへの画像入力は、モックアップからのコード生成だけでなく、実装結果を撮り直して見比べる一往復を挟むことで精度が安定します。Chrome拡張機能と組み合わせれば、実装からブラウザでの検証までを1つの会話で完結できます。構造化されたデザインデータがあるならFigma MCPサーバー、スクリーンショットしかないなら画像を直接渡す方法、と使い分けるのが実務的な線引きです。