SECTION 01
Claude Codeに画像を渡す3つの方法
Claude Codeで画像を扱うには、大きく分けて3つの入力方法があります。
- 画像のドラッグ&ドロップ：Claude Codeのウィンドウに画像ファイルを直接ドラッグ&ドロップできます
- CLIへの貼り付け：スクリーンショットやクリップボードの画像をそのままCLIに貼り付けられます
- 画像パスの指定：プロンプトの中にローカル画像のファイルパスを書いて渡す方法です
いずれもClaude Code自体が備えている機能で、ターミナルベースの操作に慣れていなくても直感的に使えます。
対応フォーマットと制限も押さえておくと安心です。
- JPEG、PNG、GIF、WebPが対応フォーマット
- ファイルサイズが大きすぎると処理に時間がかかるため、リサイズしてから渡すのが実用的
- 複数画像を同時に渡すことも可能ですが、一度に渡しすぎると指示が曖昧になりやすくなります
自分の経験では、画像は1回の指示につき1〜2枚に絞るのが安定します。全体像を見せたいときと部分を拡大して見せたいときで、渡し方を意識的に切り替えるだけで再現度が変わってきます。
SECTION 02
用途別：スクショ・モック・エラー画面の渡し方と指示の型
画像を渡す目的は大きく3パターンに分かれます。UIのスクリーンショットからコードを生成する、Figmaなどのモック画像を元にコンポーネントを作る、そしてエラー画面を見せてデバッグさせるパターンです。
スクショからHTML/CSSやReactを生成するときは、「この画面を再現して」だけでは精度が出ません。「ヘッダー部分のレイアウトをFlexboxで再現して」のように、どの領域をどの技術で実装するか補足するのがコツです。
Figmaのモック画像を渡す場合は、画面全体を一枚で渡すのではなく、コンポーネント単位で切り出して渡すのが効果的です。カード、ナビゲーション、フォームといった塊ごとに分けることで、Claude Codeが構造を正確に把握しやすくなります。
エラー画面のスクショは、デバッグの文脈で非常に強力です。
- ブラウザのコンソールエラーをスクショで渡すと、テキストで貼るより状況が伝わりやすいです
- レイアウト崩れは期待画面と実際の画面を並べて渡すのが最速です
- スタックトレースが長い場合でも、画像なら一目で全体が見えます
SECTION 03
再現度を上げるプロンプト分解パターン
画像を渡して「これを再現して」と一発で指示するのは、最も失敗しやすいパターンです。複雑な画面ほど、段階的に分解して指示を出す方が圧倒的に精度が上がります。
自分が試行錯誤の中でたどり着いたのは、「レイアウト → 色・フォント → レスポンシブ」の3段階で進めるやり方です。まずHTMLの構造とレイアウトだけを組ませて、次に色やタイポグラフィを調整し、最後にレスポンシブ対応を指示します。
この順番にする理由は明確です。
- レイアウトが崩れた状態で色を調整しても、構造を直すたびにやり直しになります
- フォントやカラーは後から変えやすいですが、HTML構造の変更は影響範囲が広いです
- レスポンシブは最後に入れないと、途中で追加するとレイアウト指示と競合しやすくなります
画像だけでなく、テキストで補足を加えるかどうかで精度が大きく変わる場面があります。たとえば「このカードの角丸は大きめに」「背景はグラデーションではなく単色で」といった補足を一文添えるだけで、出力がぐっと意図に近づきます。
複雑な画面を扱うときは、画面を領域ごとに分割して複数回に分けて渡すのも有効です。ヘッダー、メインコンテンツ、サイドバー、フッターをそれぞれ別の指示として渡し、最後に統合する流れにすると、各部分の再現度を保ったまま全体を組み上げられます。
SECTION 04
崩れたときの修正依頼の出し方
画像からUIを生成すると、一発で完璧に再現されることはまずありません。重要なのは、崩れたときにどう修正を依頼するかです。ここの手際で作業時間が大きく変わってきます。
最も効果的なのは、「期待画面 vs 実際の画面」を並べて見せるパターンです。元のデザイン画像と、生成されたコードのスクリーンショットを両方渡して「この2つの違いを修正して」と指示します。
テキストだけで「余白が大きすぎる」「色が違う」と伝えるより、画像で差分を見せた方が修正精度が高い場面は多いです。特にレイアウトの微妙なズレや、色のニュアンスの違いは言葉にしづらく、画像の方が圧倒的に伝わります。
修正ループを最小回数で終わらせるために意識しているのは、次のポイントです。
- 一度の修正依頼で指摘は3箇所までに絞ります。多すぎると全部中途半端になります
- 修正後は必ずスクショを撮って確認し、残りの差分を次の指示に回します
- 「ここを直して」ではなく「この要素のmargin-topを減らして」のように具体的なCSS指示を添えます
これまでの経験から言えるのは、修正依頼も画像ベースで回す方が収束が速いということです。テキストだけのやり取りだと認識のズレが蓄積しやすく、ループが長引く原因になります。
SECTION 05
スクショ自動取得を仕組みに組み込んで変わったこと
コーディングがAIで速くなると、次のボトルネックは動作確認に移ることに気づきました。コードの生成は一瞬でも、それが正しく動いているかの確認を毎回手動でやっていては、全体のスループットが上がりません。
そこで取り入れたのが、タスク完了時にスクリーンショットを自動で撮らせる仕組みです。AIにコードを書かせたら、セルフレビューと動作確認のスクショ撮影までをワンセットで実行させます。問題があればそのままループして修正に入る流れです。
この仕組みを入れる前は、何度もやり直しが発生する非効率に悩んでいました。
- コードを書かせる → 手動で確認 → 崩れてる → 修正依頼、の繰り返しが地味に時間を食っていました
- 確認を後回しにすると、問題が積み重なって修正コストが膨れます
- スクショが自動で残ることで、レビューの質と速度が同時に上がりました
KING CODINGという複数のAIエージェントを並列管理するツールを作ったときも、タスク完了時にスクリーンショットが添付された状態で一覧に並ぶUIにしました。スマホから確認して、問題なければ完了ボタンを押すだけです。外出先でもカフェでコーヒーを飲みながらレビューできる体験は、開発スタイルそのものを変えてくれました。
SECTION 06
画像タスクでのモデル選定とClaude Codeの得意・不得意
Claude Codeは大規模なリポジトリの把握や機能実装、エラーの自動解決が強いツールです。ただし、画像を渡してのデザイン微調整となると、まだ得意とは言い切れない場面があります。
UIの細かいこだわり部分では、Cursorの方が使いやすいと感じることが今もあります。ファイルを直接開いてプレビューしながら微調整する作業は、IDEベースのツールとの相性が良いためです。自分は今も両方を使い分けるのが最適解だと考えています。
モデルの得意・不得意は画像認識で顕著に出ます。
- Claude Codeはコード生成の文脈で画像を解釈する能力が高く、レイアウト構造の把握に優れています
- 一方で、画像入力に対応していないモデルもあり、その場合は画像タスクには使えません。利用するモデルが画像入力をサポートしているかは事前に確認が必要です
- コスト・速度・再現度のバランスを考えると、画像からの実装はClaude Code、微調整はCursorという分担が現実的です
自分がMax Planに迷わず切り替えたのも、画像を含むタスクを何度もやり取りする使い方ではAPI従量課金がすぐ高くなるからです。料金を気にせず何度でもスクショを渡して修正ループを回せることが、結果的に再現度の向上につながっています。
どのモデルを使うかより、自分のワークフローのどこに画像入力を組み込むかを先に決める方が重要です。ツールの性能は日々変わりますが、使い方の設計は自分でやるしかありません。
SECTION 07
Figmaモック画像からコンポーネントを段階的に再現する手順
MCP連携を使わない場合は、Figmaから画像をエクスポートしてClaude Codeに渡すのが手軽で現実的な方法です。一方、Figma Dev Mode MCP Serverを使えば、Claude CodeからFigmaのデザインやアセットに直接アクセスすることもできます。
ここではエクスポート経由で進める手順を紹介します。
まず最初にやるのは、画面全体のスクショではなく、コンポーネントごとに切り出した画像を用意することです。Figmaで各コンポーネントを選択してPNGにエクスポートし、命名規則をつけて保存しておきます。
切り出したら、以下の順番で進めるのが安定します。
- レイアウト系コンポーネント（ヘッダー、フッター、サイドバー）を先に実装
- 次にコンテンツ系コンポーネント（カード、リスト、フォーム）を個別に生成
- 最後に全体を組み合わせて調整する統合フェーズに入る
コンポーネントごとに渡すメリットは、修正の影響範囲が限定されることです。全体を一発で生成すると、ひとつの修正が他の部分に波及しやすくなります。部品ごとに仕上げてから組み立てる方が、結果的に手戻りが少なくなります。
Figmaのデザイントークン（色やフォントサイズの定義）があるなら、画像と一緒にテキストで渡すのが効果的です。「プライマリカラーは#1A73E8、フォントはNoto Sans JP」のように具体値を添えると、画像の読み取りに頼らず正確な値でコードが生成されます。
SECTION 08
並列タスクとスクショ確認の現実的な運用
Claude Code GitHub Actionsを使うと、issue/PRイベントに応じてClaude Codeを自動実行できます。並列実行の可否や同時実行数の上限は、GitHub Actionsのワークフロー設計やconcurrency設定に依存します。
手元で別の作業を進めながら、バックグラウンドで実装が進む体験は非常に強力です。
ただし並列にすればするほど、確認作業が一気に押し寄せてくるという現実があります。タスクを並列で走らせて、その全部を自分で長文のレポートで読んでいたら、あっという間に疲弊します。これはAI時代特有の「確認疲れ」です。
この問題を解決するのが、スクリーンショットベースの確認フローです。各タスクの完了時にスクショが自動で撮影されていれば、コードを読まなくても視覚的にOK/NGを判断できます。確認にかかる時間が劇的に短くなります。
運用のポイントをまとめます。
- 並列タスクの結果はテキストレポートではなくスクショで確認します
- 明らかにOKなものはスクショだけ見て完了、気になるものだけ詳細を確認します
- 確認のハードルを下げることで、並列数を増やしても運用が破綻しません
SECTION 09
アップデートで画像まわりの仕様が変わったときの確認手順
Claude Codeは頻繁にアップデートされるツールです。画像入力の仕様もバージョンによって変わる可能性があるため、うまくいかないときはまずバージョンを疑うのが鉄則です。
基本的な確認はclaude --versionコマンドで行えます。ターミナルで実行すれば現在のバージョンが表示されるので、他の人の記事や手順書と見比べるときの基準になります。
他人の記事通りにやってもうまくいかないとき、原因の多くはバージョン差分です。特に画像の対応フォーマットや渡し方のUIは変更が入りやすい領域なので、記事の公開日と自分のバージョンを照合する癖をつけておくと、無駄なトラブルシューティングを避けられます。
バージョン差分を効率よく追うためのポイントです。
- リリースノートを定期的にチェックし、画像関連の変更があればメモしておきます
- 画像入力がうまくいかなくなったら、まずアップデートして最新版で試します
- ワークフローに影響する変更があったときは、自分のCLAUDE.mdや手順書を更新しておきます
ツールのアップデートは速いですが、自分のワークフローに影響するかどうかは自分で判断するしかない部分です。全部の変更を追う必要はなく、画像入力・モデル変更・CLI操作に関わる項目だけをウォッチするのが現実的な運用です。
