UIのスクリーンショットをQwen 3.7 Plusに渡すと、フロントエンドコードの初期実装を生成できます。画像を読み取りながらコードを生成できるため、デザインモックアップ、競合ページのスクリーンショット、Figmaのエクスポート画像を、ReactコンポーネントやHTMLに変換できます。この記事では、基本的なAPI呼び出し、プロンプトの書き方、視覚的フィードバックループによる改善、生成したUIを実際のアプリに接続する手順を実装ベースで説明します。モデルの背景はQwen 3.7 Plusの概要、リクエスト形式はQwen 3.7 Plus APIガイドを参照してください。この記事では、UIが呼び出すAPIエンドポイントの確認にApidogも使います。
要約
実装の流れはシンプルです。
- UIスクリーンショットを用意する
- Qwen 3.7 Plusに画像と明確なプロンプトを送る
- React、Vue、HTMLなど目的の形式でコードを生成する
- 生成コードをブラウザでレンダリングする
- レンダリング結果のスクリーンショットを撮る
- 元画像との差分をモデルに修正させる
- API接続、フォーム送信、データ取得を実装する
最初の生成だけでも近い構造は得られますが、間隔、色、フォントサイズ、レスポンシブ対応は反復が必要です。Qwen 3.7 Plusは、ビジョン能力、コーディング能力、1Mトークンのコンテキスト、低い呼び出しコストを組み合わせて使えるため、この反復型のスクリーンショットからコード生成に向いています。
このタスクにQwen 3.7 Plusが適している理由
スクリーンショットからUIコードを作るには、次の2つの能力が必要です。
- 画像内のレイアウト、余白、階層、テキスト、色を読み取る
- 読み取った内容を、指定されたフレームワークのコードに落とし込む
Qwen 3.7 PlusはSWE-Bench Proで約60%、Terminal-Benchで70.3%のスコアを記録しており、コーディング能力が高いモデルです。また、高密度なUIレイアウトを扱えるビジョン能力も備えています。
1Mトークンのコンテキストにより、縦長の高解像度デザインも扱いやすく、入力トークン100万あたり0.40ドルという低コストにより、レンダリング結果を見ながら数回修正するワークフローにも向いています。
UIを再構築するのではなく、UIを操作するエージェントについては、コンピュータ利用エージェントガイドを参照してください。
基本的な呼び出し
まずは、スクリーンショット画像をimage_urlとして渡し、テキストプロンプトで出力形式を指定します。
import os
import base64
from openai import OpenAI
client = OpenAI(
api_key=os.environ["DASHSCOPE_API_KEY"],
base_url="https://dashscope-intl.aliyuncs.com/compatible-mode/v1",
)
def screenshot_to_code(png_path, prompt):
with open(png_path, "rb") as f:
b64 = base64.b64encode(f.read()).decode()
resp = client.chat.completions.create(
model="qwen3.7-plus",
messages=[
{
"role": "user",
"content": [
{"type": "text", "text": prompt},
{
"type": "image_url",
"image_url": {
"url": f"data:image/png;base64,{b64}"
},
},
],
}
],
)
return resp.choices[0].message.content
prompt = "Rebuild this UI as a React component."
print(screenshot_to_code("mockup.png", prompt))
出荷前には、Model Studioのドキュメントで現在のモデルIDを確認してください。
この最小コードでも動作しますが、1行だけのプロンプトでは出力も曖昧になります。実用的なコードを得るには、スタック、制約、レスポンシブ要件、アクセシビリティ要件を明示します。
出荷可能なコードを得るプロンプトの書き方
曖昧な指示では、一般的なHTML構造や過剰なdivが生成されがちです。以下のように、実装条件を箇条書きで指定します。
このUIスクリーンショットをTailwind CSSを使用した単一のReactコンポーネントに変換してください。
要件:
- レイアウト、間隔、カラーパレットをできるだけ忠実に合わせてください。
- 375pxのモバイル幅までレスポンシブにしてください。
- 入力、ボタン、ナビゲーションにはセマンティックなHTMLを使用してください。
- フォーム要素にはアクセシブルなlabelまたはaria-labelを付けてください。
- スクリーンショットに動的なコンテンツがある場合は、明確なプレースホルダーデータを使用してください。
- バックエンドAPIは作成しないでください。
- コンポーネントコードのみを返し、説明文は含めないでください。
指定すべき項目は次のとおりです。
- フレームワーク: React、Vue、Svelte、HTMLなど
- スタイリング: Tailwind CSS、CSS Modules、通常のCSSなど
- ブレークポイント: モバイル幅、タブレット幅、デスクトップ幅
- アクセシビリティ:
label、aria-label、セマンティックタグ - データの扱い: プレースホルダーか、propsか、APIレスポンスか
- 出力形式: コードのみ、単一ファイル、コンポーネントのみなど
Tailwindを使う場合は、Tailwind CSSのドキュメントに沿ったユーティリティクラスを生成するように指示すると、レビューしやすいコードになります。
また、スクリーンショットだけでなく、短いデザイン仕様も一緒に渡すと精度が上がります。仕様が結果に与える影響については、design.mdがコーディングエージェントに何をもたらすかで詳しく説明しています。
視覚的フィードバックループでギャップを埋める
最初の生成では、構造は近くても、余白、色、フォントサイズ、影、角丸がずれることがあります。そこで、次のようなループを使います。
- Qwen 3.7 Plusでコードを生成する
- ローカル環境でコンポーネントを表示する
- Playwrightやブラウザのスクリーンショット機能で画像を撮る
- 元画像と現在のレンダリング画像をモデルに渡す
- 差分を説明させ、修正済みコードを返させる
プロンプト例:
これがターゲットデザイン（画像1）と現在のレンダリング（画像2）です。
タスク:
1. 2つの画像の視覚的な違いをリストアップしてください。
2. 余白、色、フォントサイズ、幅、高さ、角丸、影の差分を修正してください。
3. 画像1により近づくように修正済みのReactコンポーネントコードを返してください。
4. 説明文は含めず、コードのみを返してください。
このループを2〜3回実行すると、初回生成よりもかなり近いUIになります。これは、コンピューター利用エージェントで使われる「観察して修正する」考え方を、クリック操作ではなくコード生成に適用したものです。
実際のデザインを扱うときの実装方針
本番のモックアップは大きく、情報量も多いため、スクリーンショットをそのまま1枚で投げるより、生成対象を分割したほうが安定します。
1. 画像サイズを調整する
フルページの高解像度画像はトークンコストが高くなります。次の条件を満たすサイズまで縮小します。
- テキストが読める
- ボタンやフォームの境界が判別できる
- 余白や階層が確認できる
必要以上に大きい画像を送っても、コード品質が必ず上がるわけではありません。
2. セクション単位で切り出す
ダッシュボード全体を一度に生成させるより、以下のように分割します。
- ヘッダー
- サイドバー
- カード一覧
- テーブル
- フォーム
- モーダル
- フッター
例:
このスクリーンショットの左側サイドバー部分のみをReact + Tailwind CSSで実装してください。
ページ全体は実装しないでください。
小さい単位で生成すると、コードの見通しがよくなり、後からコンポーネントとして組み合わせやすくなります。
より良い出力を得るためのプロンプト改善
よくある問題は、プロンプトに1行追加するだけで改善できます。
色がずれる場合
モデルは色を近似するため、正確なHEX値が必要な場合は明示します。
以下の色を必ず使用してください:
- Primary: #2563EB
- Background: #F8FAFC
- Text: #0F172A
- Border: #E2E8F0
アイコンを推測してしまう場合
モデルが存在しないアイコンや曖昧なSVGを作ることがあります。利用するアイコンセットを指定します。
アイコンはlucide-reactからimportして使用してください。
存在しないアイコン名は使わないでください。
または:
アイコンはHeroiconsを使用してください。
スクリーンショットの形状に最も近い既存アイコンを選んでください。
テキストが不自然な場合
UI内の文言を勝手に補完させたくない場合は、プレースホルダーを指定します。
実在する会社名、ユーザー名、メールアドレスは作らないでください。
動的データは「ユーザー名」「メールアドレス」「プロジェクト名」のような明確なプレースホルダーにしてください。
divが多すぎる場合
構造を明示します。
可能な限りsection、header、nav、main、form、label、buttonなどのセマンティックHTMLを使用してください。
不要なラッパーdivを増やさないでください。
APIを勝手に作る場合
フロントエンドだけを生成させたい場合は、境界を明確にします。
バックエンド実装やAPIサーバーは作成しないでください。
データ取得が必要な箇所は、propsまたはモックデータとして表現してください。
UIから動作するアプリへ
スクリーンショットから生成されるコードは、UI実装の出発点です。ただし、実際のアプリとして動かすには、次の作業が必要です。
- APIからデータを取得する
- フォーム送信を実装する
- エラー状態を表示する
- ローディング状態を表示する
- 空データ状態を表示する
- APIレスポンスの型とUI表示を合わせる
ここで重要なのは、UI生成と同時にAPI契約を設計することです。
Apidogを使うと、API契約を定義し、モックし、生成したUIをリアルなレスポンスで即座に確認できます。バックエンドが完成する前でも、フロントエンド側はモックAPIを使って実装を進められます。
スペックファーストで進める流れは、スペックファーストモードガイドで説明されています。この方法は、Cursorで構築されたAPIと同じように、AIで生成したフロントエンドとも相性が良いです。
Qwen 3.7 Plusで生成したUIの背後にあるAPIをモックしてテストするには、Apidogをダウンロードしてください。
よくある質問
Qwen 3.7 Plusはどのフレームワークをターゲットにできますか？
プロンプトで指定したフレームワークをターゲットにできます。React、Vue、Svelte、プレーンなHTML/CSS、Tailwind CSS、コンポーネントライブラリなどを明示してください。指定しない場合は、一般的なマークアップになりやすいです。
最初の生成の精度はどのくらいですか？
構造は近くなりますが、正確な余白、色、フォントサイズはずれることがあります。レンダリング結果を再度スクリーンショットとして渡す視覚的フィードバックループを使うと、精度を上げられます。
Figmaのデザインからでも使えますか？
はい。Figmaのフレームを画像としてエクスポートすれば使えます。モデルはFigmaファイルそのものではなく、レンダリングされた画像を読み取ります。
トークンコストを抑えるにはどうすればいいですか？
画像を判読可能な最小サイズに縮小し、作成したいセクションだけにトリミングしてください。ページ全体を一度に生成するより、ヘッダー、サイドバー、フォーム、テーブルなどに分割するほうが効率的です。
バックエンドも構築できますか？
このワークフローでは、主にフロントエンドコードを生成します。APIは別途設計し、モックし、テストする必要があります。その部分はApidogで扱えます。
結論
Qwen 3.7 Plusを使うと、スクリーンショットからReactやHTMLの初期コードを素早く生成できます。実用的な結果を得るには、明確なプロンプト、セクション単位の分割、レンダリング結果を使った視覚的フィードバックループが重要です。
生成されたUIを本番アプリに近づけるには、API契約、モック、テストも必要です。Qwen 3.7 Plusでフロントエンドを生成し、Apidogでエンドポイントを設計、モック、テストすることで、UIとAPIを一体で実装できます。
Top comments (0)