「このスクショ通りに作って」と頼まれて、Antigravity に画像を渡してみたら、雰囲気は近いのに余白とフォントウェイトと角丸が全部わずかにズレている — そんな経験、私も何度もしました。マルチモーダルが進化してもスクリーンショットからの UI 再現は、最初の一発で完璧になることはまずありません。
ここでは私自身がアプリの UI 実装で実際に使っている、画像の渡し方とプロンプトの組み立て方、そして「微妙にズレている」を「これでいい」に近づけるための差分修正の進め方を、SwiftUI / Tailwind / Flutter の具体例を交えてまとめます。Antigravity のマルチモーダル能力を引き出して、スクリーンショット駆動の実装を実用レベルに乗せるための作法集です。
なぜスクショからの UI 再現は最初の一発で決まらないのか
Antigravity に貼り付けた画像から AI が読み取れる情報は、人間が無意識に補完している多くの要素を欠落させています。たとえば「角丸 12px のカード」と私たちが見たものは、AI からするとピクセル単位のグラデーション境界でしかありません。具体的にズレやすいのは次の領域です。
- フォントの太さ（regular / medium / semibold の見分け）
- 余白の単位（4px グリッドか 8px グリッドか）
- 微妙なシャドウ（elevation 1 と 2 の違い）
- カラートークン（
#EEEと#F2F2F2の判別） - アイコンの線の太さ（1.5px と 2px）
ここで重要なのは、AI が「分からない」のではなく「画像のピクセルから推定した結果が、デザインシステムの離散値と一致するとは限らない」という性質を持っていることです。だからこそ、画像と一緒に「正解の選択肢」を渡すと精度が一気に上がります。
スクショを渡す前に決めておく 3 つの前提
Antigravity に画像を貼り付ける前に、私はいつも以下の 3 つだけメモしてからプロンプトに含めるようにしています。これだけで再現精度は体感で 3 〜 4 割上がります。
- 使うフレームワーク・スタイルシステム: Tailwind v4 / SwiftUI / Flutter Material 3 など
- デザイントークンの離散値: 余白は 4 / 8 / 12 / 16、角丸は 4 / 8 / 12 / 16、テキストサイズは 12 / 14 / 16 / 18 / 24 のように選択肢を絞る
- コンポーネントの粒度: ボタン単体なのか、カード全体なのか、画面全体なのかを明示する
このスクショの「中央のカード」だけを実装してほしい。
- フレームワーク: SwiftUI（iOS 26 / Xcode 26）
- 余白の選択肢: 8 / 12 / 16 / 24（pt）
- 角丸の選択肢: 8 / 12 / 16
- テキスト: .footnote / .body / .headline / .title3
- カラーは Asset Catalog の `Tint/Primary`、`Surface/Card`、`Text/Secondary` を優先して使うこのように「離散値リスト」を渡すと、AI は連続値（12.7px のような中途半端な数字）を出さなくなり、実装後にコードレビューで指摘される箇所がほぼゼロになります。
解像度と注釈の付け方で精度が変わる
スクショそのものを工夫すると、画像から読み取れる情報量が増えます。私が普段やっているのは次の 3 つです。
最も効くのが 2x で書き出す こと。1x の Retina 画像をそのまま渡すと、文字の輪郭が AI から見るとぼやけて、フォントウェイトの推定が外れがちです。Figma なら Export 時に 2x、Sketch なら @2x 書き出しを使うだけで、テキストやアイコンの判別が安定します。
次に効くのが、画像に 赤線で寸法を書き込む こと。Preview.app の「マークアップ」機能で、カード間の余白に「16」と書き込んで保存し直すだけです。私は実際にこれをやってから、AI が間違った余白を出してくる頻度が大幅に減りました。
最後に 対象領域だけクロップする こと。画面全体のスクショを丸ごと渡すと、Antigravity は「画面構造をどう作るか」に意識が分散して、目的のコンポーネントの細部が雑になります。「ボタン 1 つだけ」「ヘッダーだけ」のように切り出した画像を渡したほうが、結果的に総合の品質は上がります。
実装プロンプトの基本フォーマット
Antigravity に画像を渡してコードを書いてもらうとき、私は以下の構造でプロンプトを組み立てています。
[画像を貼り付け]
このスクショ「右下の Floating Action Button」を SwiftUI で実装してください。
要件:
- フレームワーク: SwiftUI（iOS 17+ / @available 不要）
- サイズと余白の選択肢: 4 / 8 / 12 / 16 / 24 / 32（pt）
- 影の選択肢: なし / 軽（radius 4 y 2）/ 中（radius 8 y 4）/ 強（radius 16 y 8）
- カラー: `Color("Primary")`、`Color.white`
- アイコン: SF Symbols から最も近いものを選び、コメントで候補を 2 つ示す
- アクセシビリティラベルを必ず付ける
出力フォーマット:
- 1) `FloatingActionButton.swift` のコード全文
- 2) 推定した値の根拠（余白・影・サイズ）の箇条書き
- 3) スクショから読み取れなかった項目（タップ領域・押下時の見た目など）のリストアップ
注意:
- スクショから連続値（13.5pt 等）を出さないでください
- 既存の `Theme.swift` の値を使えそうな場合は import で参照してくださいポイントは 出力フォーマットを 3 つに分ける ことです。コードだけを返してもらうと、AI がどこで判断に迷ったかが見えません。「読み取れなかった項目」を最初から書き出させておくと、こちらが追加で答えるべき質問が明確になり、二往復目で精度が大きく上がります。
ケーススタディ: Tailwind カードを Pixel Perfect に近づける
実際に「Dribbble で見つけたカードのスクショ」から Tailwind v4 で実装するときの流れを、私が普段やっている順番で書き出します。
一往復目: 構造とトークンを引き出す
最初のメッセージでは、画像とともに「ピクセル測定はせず、Tailwind のクラスだけで近似してほしい」と依頼します。
[画像を貼り付け]
このカードを Tailwind v4 で実装してください。
ピクセル単位の測定はせず、Tailwind の標準スペーシング（p-2 / p-3 / p-4 / p-6 など）と
角丸（rounded-md / rounded-lg / rounded-xl）の組み合わせで近似してください。
色は `slate-*` と `zinc-*` のシェードから選び、ブランドカラーは `--color-brand` という CSS 変数を仮置きしてください。AI からは大体以下のような JSX が返ってきます。
// Card.tsx — 一往復目の出力（仮）
export function ProductCard() {
return (
<article className="bg-white rounded-xl shadow-md p-6 max-w-sm">
<h3 className="text-lg font-semibold text-slate-900">商品名</h3>
<p className="mt-2 text-sm text-slate-600">短い説明文がここに入ります。</p>
<div className="mt-4 flex items-center justify-between">
<span className="text-xl font-bold" style={{ color: "var(--color-brand)" }}>
¥1,200
</span>
<button className="rounded-lg bg-slate-900 px-4 py-2 text-sm text-white">
購入する
</button>
</div>
</article>
);
}期待する見た目: スクショとほぼ同じ構造のカードが描画されるが、影が強すぎる・価格の色が濃すぎる、といった微妙なズレが残る状態です。
二往復目: 差分だけを伝える
ここで「全部書き直して」と言うと AI は別解を出してきて、せっかく合っていた構造まで変わってしまいます。私は 差分だけ を箇条書きで渡します。
さっきのコードを下記の通り「最小限の差分で」修正してください。
構造とクラス名は他は触らないでください。
- 影: shadow-md → shadow-sm（スクショではかなり浅く見える）
- 価格の色: var(--color-brand) のまま太さを font-bold → font-semibold に
- カードの padding: p-6 → p-5（スクショの上下はもう少し詰まっている）
- ボタンの角丸: rounded-lg → rounded-md「最小限の差分で」という指示が重要です。これがないと、AI は「もっと良いコード」を提案してくる癖があり、こちらが望んでいない構造変更が混入します。
三往復目以降: 細部の往復
実装の最後の数 % は、目視と差分の往復でしか埋まりません。私は Antigravity の Diff ビューで「変える前の DOM スクショ」と「変えた後のスクショ」を並べて、まだ違う部分だけを伝えています。Diff ビューの活用については Antigravity の Diff ビュー徹底活用ガイド で詳しく書きました。
SwiftUI と Flutter での注意点
SwiftUI でスクショから実装する場合、.padding() を素直に使うと iOS 標準の余白（16pt）が暗黙に乗ってしまい、スクショより微妙に広くなります。私は最初のプロンプトで「.padding(.all, X) の X は明示してください、.padding() 単体は使わないでください」と書くようにしています。
Flutter の場合は逆に、Padding ウィジェットがネストして余白が二重に効くケースが多発します。「Padding の入れ子は禁止、すべて EdgeInsets.all か EdgeInsets.symmetric で表現してください」という制約を最初に渡すと、後から余白を調整するのが楽になります。
マルチモーダルの精度を最大化する細かい技
Figma がある場合は、スクショではなく Figma MCP 連携 を使ったほうが正確です。MCP 経由なら AI は実際のスタイルプロパティ（fillColor、cornerRadius、autoLayout の gap 値など）にアクセスできるため、推定する必要がありません。
スクショしか手元にない場面では、複数枚の画像を一度に渡すのも効きます。たとえば「全体スクショ + そのコンポーネントのアップ + 同系統の別コンポーネント」の 3 枚を貼ると、Antigravity は共通する余白・角丸を発見しやすくなります。これは実装してみると分かりますが、1 枚だけのときより明らかにブレが減ります。
UI バグの修正シーンであれば、Antigravity でスクリーンショットを貼り付けて UI バグを直す のアプローチもセットで覚えておくと、新規実装と修正のどちらにも対応できます。
私が個人アプリ開発で使ってきたプロンプトの引き出しは、自分で書き溜めるのが一番ですが、入門の参考としては プロンプトエンジニアリング実践ガイド も役に立つはずです。スクショベースの実装は、結局のところ「画像から推定した値を、自分のデザインシステムの離散値に丸める」作業の繰り返しなので、その丸め方のパターンを言語化してテンプレ化しておくと、毎回ゼロから書かずに済みます。
スクショから推定された複数案のうち、どれを残すかを自分で言語化できるようになるのが目的です。
今日からできる最初の一歩
最後に、今日この記事を読んで実際に試すなら、まずは 手元のアプリの 1 画面を 2x で書き出して、Antigravity に渡してみる ところから始めてみてください。最初のプロンプトに「離散値リスト」と「出力フォーマット 3 段構成」を含めるだけで、出力の質が体感で変わるはずです。完璧に再現できなくても、二往復目の差分修正を 2、3 回繰り返せば実用レベルに乗ります。Pixel Perfect は一発の魔法ではなく、丁寧な往復で近づけていく作業 — そう割り切って取り組むと、Antigravity のマルチモーダル機能はかなり頼もしい相棒になります。