screenshot-to-code でスクショを HTML 化する方法

既存の画面と同じ見た目をゼロから実装し直す作業は、技術的な難易度こそ高くないものの、確実に時間を消費します。余白の数値を目視で拾い、フォントサイズを合わせ、レスポンシブの折り返しを調整する。この工程が積み上がると、本来考えたかった設計や状態管理の議論に使える時間が削られていきます。

そこで期待されているのが、スクリーンショットやデザインカンプから直接コードを生成するアプローチです。ただ、いざ導入を検討し始めると別の壁にぶつかります。この領域には商用 SaaS からオープンソースまで多数の選択肢があり、それぞれ入力の起点（既存画面のスクショなのか、手描きスケッチなのか、自然言語なのか）も出力できるスタックも異なります。スター数の多さだけでは比較になりません。

そうした選択肢のなかで、GitHub 上で最大規模のスターを集めているのが abi/screenshot-to-code です。スクリーンショット・モックアップ・Figma デザイン、さらには画面録画までを入力として受け取り、HTML + Tailwind から React、Vue、Bootstrap、Ionic までのコードを生成します。MIT ライセンスのオープンソースであり、自分のインフラ上で動かしてモデルを選べる点が、SaaS 型のサービスとの明確な違いです。

一方で、採用を判断するうえで確認すべき点も複数あります。ソフトウェア本体は無償でも、コード生成に使う LLM の API 費用は利用者負担です。しかも既定で複数案を並列生成する設計のため、1 回の生成でその分の API 呼び出しが発生します。セットアップにも Python と Node.js の両方の環境が必要です。

本記事では、公開されている README・リポジトリ内の設計ドキュメント・公式サイトをもとに、screenshot-to-code の対応範囲、導入手順、コードを生成する内部の仕組み、類似 OSS との棲み分け、そして導入前に押さえておきたい制約を整理します。なお本記事は動作検証を伴わないドキュメントベースの整理です。掲載しているコマンドはすべて公式 README からの引用であり、最新の仕様は各出典リンク先でご確認ください。

screenshot-to-codeとは｜スクショをコードに変換するOSS

screenshot-to-code は、リポジトリの説明文どおり「スクリーンショットを放り込むとクリーンなコード（HTML/Tailwind/React/Vue）に変換する」ことを目的としたオープンソースプロジェクトです。README では対象の入力としてスクリーンショットのほかにモックアップ、Figma デザイン、画面録画が挙げられています（abi/screenshot-to-code）。

構成は、React / Vite のフロントエンドと FastAPI（Python）のバックエンドという二層です。生成処理そのものは各社の LLM API に委ねており、利用者は自分で用意した API キーを設定して動かします。

リポジトリの基本情報は次のとおりです（gh api /repos/abi/screenshot-to-code による 2026 年 9 月 2 日時点の取得値）。

2023 年 11 月の公開から 2026 年 8 月まで継続して更新されており、開発が止まったプロジェクトではありません。ライセンスも MIT で明示されているため、商用利用や改変のハードルは低い部類に入ります。

導入判断で最初に押さえておきたいのが、このプロジェクトが二層構造になっている点です。README の冒頭では、公式のホスト版である screenshottocode.com が「最も手軽に試す方法」として案内されています。つまり、環境構築なしで挙動を確かめたいだけならホスト版があり、OSS 版はカスタマイズ・セルフホスト・コントリビュートをしたい人向けという位置づけです。README の「Getting Started」でも、この 2 つの経路が明示的に並記されています。

なお、GitHub には emilwallner/Screenshot-to-code という同名の別プロジェクトが存在します。こちらはデザインモックを静的サイトに変換するニューラルネットワークの研究・教材寄りのリポジトリで、2024 年 8 月を最後に更新が止まっています。日本語で検索すると両者が混在して出てくるため、参照する際はリポジトリの owner まで確認することをおすすめします。

screenshot-to-codeが対応するスタックと入力モード

自分の技術スタックで使えるかどうかは、最短で判定したい項目です。README に記載されている対応スタックは以下の 6 種類です。

「HTML 化」という言い方をすると静的ページ専用に聞こえますが、コンポーネントフレームワーク向けの出力にも対応しています。既存プロジェクトのスタックに合わせて出力形式を選べる点は、生成結果を取り込む際の手戻りを減らす方向に働きます。

入力側は、静止画のスクリーンショットに加えて、モックアップ画像や Figma デザインを受け付けます。さらに README には、動いている Web サイトの画面録画を撮り、それを機能するプロトタイプに変換する機能があることも記載されています。静止画からは読み取れないインタラクション（開閉やタブ切り替えなど）を含めて再現させたい場合の選択肢になります。

使用するモデルについては注意が必要です。README には既定の AI モデル一覧が記載されている一方、API キーの説明テーブルに書かれているモデル名とは一部が一致していません。モデルの世代交代が速い領域であり、本記事の掲載時点の名称を書き写しても短期間で陳腐化します。現行のモデル構成は README で確認してください。本記事では「利用者が設定したキーに応じてモデルが自動的に選ばれる」という仕組みのほうを、のちほど詳しく扱います。

スクショをHTML化する手順｜ローカル実行とDocker

ここからは README に記載されているセルフホストの手順を確認します。以下のコマンドはすべて公式 README からの引用であり、本記事側での改変は加えていません。

必要なAPIキーと役割

screenshot-to-code は、モデルプロバイダのキーを 最低 1 つ 必要とします。README の API キー表を整理すると、役割は次のように分かれています。

出典: abi/screenshot-to-code の README

ここが導入判断に効いてくるポイントです。「1 つキーがあれば動く」のは事実ですが、機能の一部は特定のプロバイダに紐づいています。とくに、元のスクリーンショットからロゴや画像を抜き出して再利用するアセット抽出は Gemini が担っており、画面録画からの生成には Gemini キーが必須と README に明記されています。また、キーを増やすほどバリアントごとに強いモデルの組み合わせが自動で選ばれ、単一キーの場合はそのプロバイダのモデルのみが使われます。

なお、Ollama などのローカル OSS モデルでの実行については、README で「結果の品質が低いため推奨しない」と明記されたうえで、参考として Issue のコメントが案内されています。API 費用をゼロにする目的でローカルモデルに置き換える構成は、公式の想定外と考えたほうがよさそうです。

バックエンドとフロントエンドを起動する

バックエンドは Poetry でパッケージ管理を行います。README では以下のコマンドが提示されています。

cd backend
echo "OPENAI_API_KEY=sk-your-key" > .env
echo "ANTHROPIC_API_KEY=your-key" >> .env
echo "GEMINI_API_KEY=your-key" >> .env
echo "REPLICATE_API_KEY=r8_your-key" >> .env
poetry install
# Install the Chromium browser used by the screenshot preview tool.
# On Linux, use `poetry run playwright install --with-deps chromium` to also
# install the required system libraries (needs sudo/apt).
poetry run playwright install chromium
poetry env activate
# run the printed command, e.g. source /path/to/venv/bin/activate
poetry run uvicorn main:app --reload --port 7001

出典: abi/screenshot-to-code の README

playwright install chromium が含まれているのは、後述するスクリーンショットプレビュー機能でヘッドレスブラウザを使うためです。この手順を省略した場合でも本体は動作し、該当機能だけがスキップされる設計になっています。

フロントエンドは pnpm で起動します。

cd frontend
pnpm install
pnpm dev

出典: abi/screenshot-to-code の README

README によれば、起動後は http://localhost:5173 でアプリケーションを開きます。バックエンドのポートを変更する場合は frontend/.env.local の VITE_WS_BACKEND_URL を更新するよう案内されています。

OpenAI・Anthropic・Gemini のキーについては、.env ではなくフロントエンドの設定ダイアログ（歯車アイコン）からも設定できます。ただし Replicate のキーだけは backend/.env に REPLICATE_API_KEY として設定する必要があると README に記載されています。設定ダイアログでは、スクリーンショットプレビューが利用可能かどうかも確認できます。

セットアップでつまずいた場合の導線も用意されています。API キーの取得方法やバックエンドのセットアップエラーについては、公式の Troubleshooting.md が案内されています。国や環境の制約で OpenAI API に直接アクセスできない場合に OPENAI_BASE_URL でプロキシを設定する方法も、README の FAQ に記載があります。

Dockerで動かす場合の注意

Docker が使える環境であれば、リポジトリのルートで以下を実行する方法も README に記載されています。

echo "OPENAI_API_KEY=sk-your-key" > .env
docker-compose up -d --build

出典: abi/screenshot-to-code の README

こちらも http://localhost:5173 でアプリケーションが起動します。ただし README には、この構成ではファイルの変更がリビルドをトリガーしないため、アプリケーションの開発には使えないという注記があります。挙動をひととおり確認したい場合や、社内の共有環境に立てて試用したい場合には Docker 構成、コードに手を入れる前提ならローカル構成、という使い分けになります。

変換精度を支える仕組み｜エージェントのツール呼び出しとバリアント並列生成

「結局のところ、画像を投げてプロンプトで整形しているだけではないか」という疑問は、この種のツールを検討するときに必ず出てきます。screenshot-to-code はリポジトリ内に設計ドキュメントを同梱しており、内部構造を読んだうえで判断できます。ここは採用可否とコスト構造の両方に直結する部分なので、少し詳しく見ていきます。

ツール呼び出しループの流れ

コード生成の中心にあるのは、単発のプロンプト応答ではなくツール呼び出しを伴うエージェントのループです。公式の design-docs/agent-tool-calling-flow.md によると、処理は backend/routes/generate_code.py の AgenticGenerationStage._run_variant からバリアントごとに Agent(...).run(model, prompt_messages) を呼び出す形で始まります。Agent は backend/agent/engine.py の AgentEngine の薄いラッパーです。

中心のループは AgentEngine._run_with_session(...) にあり、同ドキュメントでは次の流れが説明されています。

1. ターンごとのストリーミング状態を初期化する
2. session.stream_turn(on_event) でプロバイダの 1 ターンをストリーム受信し、アシスタント出力・思考・ツール呼び出しの差分を WebSocket に転送する
3. ツール呼び出しがなければ確定して終了し、あれば各ツールを実行する
4. session.append_tool_results(...) で結果を会話履歴に追加し、次のターンへ進む
5. ガードレールとして、ツール実行のターンは最大 20 回まで（超過時は例外を送出）

同ドキュメントに記載されている対応ツールは create_file / edit_file / generate_images / remove_backgrounds / edit_images / extract_assets / screenshot_preview / save_assets / retrieve_option の 9 種類です。create_file については、引数がまだ到着している途中の段階でもコードのチャンクをプレビュー配信し、ツールが updated_content を返した時点で setCode を送出する、という細かい制御まで説明されています。

つまり、モデルが 1 回の応答で完成品を吐き出す構造ではなく、ファイルを作り、必要なら画像を扱い、結果を見てから修正するという反復を前提とした設計です。ガードレールとして 20 ターンの上限が置かれているのも、この反復が前提であることの裏返しといえます。

アセット抽出とスクリーンショットプレビュー

対応ツールのうち、変換精度に直接効くものを 2 つ取り上げます。

1 つは extract_assets です。README の API キー表にあるとおり、これは元のスクリーンショットからロゴや画像そのものを取り出して再利用するためのもので、Gemini のキーが必要になります。画像部分をプレースホルダや生成画像で埋めるのではなく、元の素材をそのまま使えるかどうかは、既存画面の再現度に大きく影響します。

もう 1 つは screenshot_preview です。README では任意機能として説明されており、エージェントが自分で生成したページをヘッドレスブラウザでレンダリングし、視覚的に自己確認する仕組みです。前述の playwright install chromium を実行済みであれば自動的に有効になり（Docker イメージでは自動で導入されます）、Chromium がない場合はツールがスキップされます。有効かどうかは設定ダイアログで確認できます。

生成物を自分で見て確認するループが組み込まれている点は、単純なワンショット生成との差分としてわかりやすい部分です。

複数案を並列生成して比較する仕組み

もう 1 つの特徴が、複数の実装案（バリアント）を並列生成してユーザーに比較させる設計です。公式の design-docs/variant-system.md によると、既定値は backend/config.py の NUM_VARIANTS = 3 で、この値を変えるとシステム全体が自動的にスケールする作りになっています。

モデルの割り当ては、利用可能な API キーに応じて配列を循環させる方式です。同ドキュメントでは「モデルが [A, B] で NUM_VARIANTS が 5 なら [A, B, A, B, A] になる」と説明されています。前述の「キーを増やすほど強いモデルの組み合わせが選ばれる」という README の記述は、この循環割当の仕組みに対応しています。

フロントエンド側はバックエンドから variantCount を受け取り、バリアント数に応じて 2 列・2×2・3 列・4 列とグリッドレイアウトを動的に切り替えます。Option/Alt + 1, 2, 3... のキーボードショートカットでバリアントを切り替えられることも記載されています。

なお、この設計ドキュメント内に登場する具体的なモデル名は README の記載より古い世代のものです。ここでは設計思想（並列バリアントとキーに応じた循環割当）のみを参照し、最新のモデル構成は README 側を確認してください。

導入判断の観点で重要なのは、この並列生成が API 呼び出し回数に直結する点です。既定の 3 バリアントであれば、1 回の生成指示に対して 3 系統の生成が走ります。品質の高い案を選べる代わりに、単純計算でコストは 3 倍側に寄ります。コストを抑えたい場合は NUM_VARIANTS を下げる、品質重視なら上げる、というトレードオフを設定値で調整できる構造になっています。

同梱の評価セットでモデルとプロンプトを比べる

「どのモデルが自社の対象画面に合うか」を印象で決めずに済むよう、リポジトリには評価用の仕組みが同梱されています。公式の Evaluation.md には、16 枚のスクリーンショットからなる評価データセットと、それを一括実行する Python スクリプト、出力を採点する UI が含まれることが記載されています。

同ドキュメントによる運用の流れは次のとおりです。入力のスクリーンショットは backend/evals_data/inputs に置き、出力は backend/evals_data/outputs に生成されます（変更したい場合は backend/evals/config.py の EVALS_DIR を修正します）。backend/run_evals.py の STACK と MODEL を設定してスクリプトを実行すると、データセットに対する生成が並列で走ります。結果はフロントエンドの /evals で確認でき、各出力を 1〜4 の 4 段階で採点したうえで、ページを PDF として出力してチームに共有できます。

作者は同ドキュメントで、モデル／プロンプトとスタックの組み合わせごとに 3 回テストを実行し、その平均スコアで評価する運用をとっていると述べています。LLM の出力にはばらつきがあるため、1 回の結果で優劣を決めない前提が明示されている点は参考になります。

この評価の仕組みは、飾りとして置かれているものではありません。リポジトリの直近コミットには、判定済みの評価結果に基づいてモデル構成を更新する内容（Refresh image-create model mix from judged evals など、2026 年 7 月）が並んでいます。プロンプトを集めただけのリポジトリではなく、評価駆動でモデル選択を見直す運用が回っていることが履歴から読み取れます。

同じ仕組みを利用者側でも使えるため、自社が扱う対象画面のスクリーンショットを入力に差し替えれば、「自分たちのデザインに対してどのモデルが妥当か」を手元で検証できます。採用判断を試用の印象だけに委ねなくて済む点は、選定材料として押さえておく価値があります。

類似OSSとの違い｜OpenUI・draw-a-ui・make-realと比べる

この領域には近接するオープンソースが複数あります。以下は gh api で取得した 2026 年 9 月 2 日時点の実データです。

差分は 3 つの軸で整理できます。

入力の起点が違います。 screenshot-to-code は「すでに存在する画面」を起点にします。既存サイトのリニューアルや、他社事例を参考にした社内ツールの叩き台づくりのように、再現したい対象が目の前にあるケースに向きます。一方 OpenUI は自然言語で「こういう UI が欲しい」と記述する方式で、まだ存在しない画面をゼロから起こす用途です。draw-a-ui と make-real は手描きスケッチやホワイトボードの作図を起点とし、アイデア段階のスケッチを即座に動く形にすることを狙っています。同じ「AI で UI を作る」でも、想定している作業フェーズが異なります。

出力スタックの幅が違います。 screenshot-to-code は前述の 6 スタックを明示的にサポートします。draw-a-ui は HTML 中心、OpenUI は HTML から React / Svelte / Web Components への変換を掲げています。既存プロジェクトのフレームワークに合わせて出力させたい場合、選択肢の幅は判断材料になります。

保守状況に差があります。 screenshot-to-code は 2026 年 8 月、OpenUI は 2026 年 8 月にそれぞれ push されており、どちらも動いているプロジェクトです。これに対し make-real はすでにアーカイブ済みで、新規採用の対象にはなりません。draw-a-ui は 2025 年 7 月で更新が鈍化しています。前述のとおり emilwallner 版は同名の別プロジェクトで、2024 年 8 月以降は更新がありません。名前だけで選ぶと意図しないリポジトリを掴む可能性がある点は、この領域の特有の注意点です。

商用サービスとの棲み分けも整理しておきます。同じ design-to-code のカテゴリには、v0（Vercel）、Bolt、Lovable、Builder.io Visual Copilot、Anima といった商用ツールが並んでいます（AIMultiple の design-to-code 比較）。これらは環境構築が不要で完成度も高い一方、SaaS であるためセルフホストはできず、使用するモデルを差し替えることもできません。逆に言えば、OSS 版を選ぶ動機は「入力する画面のデータを外部サービスに預けたくない」「使用するモデルを自分で選びたい」「生成のロジックに手を入れたい」のいずれかに集約されます。この動機がない場合は、ホスト版や商用サービスのほうが合理的な選択になります。

導入前に押さえたい制約とコスト

ここまでの内容を、採用判断で確認すべき制約としてまとめます。

API 費用は利用者負担です。 ソフトウェア本体は MIT ライセンスで無償ですが、コード生成に使う LLM の呼び出し費用は自分で支払います。しかも既定では 3 バリアントを並列生成するため、1 回の生成指示あたりの呼び出し回数はその分増えます。試用の段階から想定コストを見積もっておくことをおすすめします。

キー構成によって使える機能が変わります。 最低 1 つのモデルプロバイダキーがあれば起動しますが、Gemini がないとスクリーンショットからのアセット抽出が使えず、画面録画モードも利用できません。Replicate がないと画像編集と背景除去が使えません。「動くこと」と「README が想定する品質で動くこと」の間に差がある点は、事前に把握しておくべきです。

ローカル OSS モデルへの置き換えは公式に推奨されていません。 API 費用を抑える目的で Ollama 等に差し替える構成は、README で品質面から非推奨と明記されています。

生成コードはそのまま本番に投入する前提で考えないことです。 この点は screenshot-to-code に限った話ではなく、design-to-code カテゴリ全体に共通します。前掲の AIMultiple の比較記事でも、この種のツールが生成するコードは強固な出発点にはなるものの、本番利用には開発者によるレビューと調整が必要になるのが通例だと整理されています（AIMultiple）。実装の初期案を高速に用意する道具として位置づけるのが妥当です。

リリースタグ運用がありません。 2026 年 9 月 2 日時点で GitHub のリリースは作成されておらず、バージョンタグによる管理が行われていません。したがって導入時は main ブランチに追随する形になり、特定バージョンへの固定を前提とする運用とは相性がよくない点に注意が必要です。オープン Issue は 139 件で、活発なプロジェクト相応の規模といえます。

セルフホストの動機を先に固めることです。 公式のホスト版が並存している以上、OSS 版を選ぶ理由は「データを外に出したくない」「モデルを選びたい」「改造したい」のいずれかであるはずです。この動機が明確でない場合、Python と Node.js の両環境を用意し、複数プロバイダの API キーを管理し、main ブランチの変更に追随する運用コストに見合わない可能性があります。

まとめ｜screenshot-to-codeが向くケース・向かないケース

ここまでの整理を、採用判断のチェックリストとしてまとめます。

向いているケース

• 既存画面のリニューアルで、現行 UI を起点に実装の初期案を素早く用意したい
• 社内ツールの UI について、デザイナーを介さずに叩き台を作りたい
• 入力する画面のスクリーンショットを外部 SaaS に送信したくない事情がある
• 複数のモデルを自社の対象画面で比較検証したい（同梱の評価セットが使えます）
• React / Vue / Bootstrap / Ionic など、出力スタックを既存プロジェクトに合わせたい
• Python と Node.js の環境構築、および複数プロバイダの API キー管理を自チームで担える

向いていないケース

• セットアップ工数をかけられない（この場合は公式ホスト版のほうが目的に合います）
• LLM API の従量課金を負担できない、またはコストを事前に固定したい
• 生成されたコードをレビューなしでそのまま納品・本番投入したい
• 特定バージョンに固定して長期運用したい（リリースタグ運用がありません）
• まだ存在しない画面をゼロから起こしたい（自然言語入力の OpenUI などのほうが起点として適します）

screenshot-to-code は、スクリーンショットという「すでにあるもの」を起点にコードの初期案を高速に用意するための道具です。エージェントのツール呼び出しループ、アセット抽出、自己確認のためのスクリーンショットプレビュー、複数案の並列生成といった構造が公開されており、内部を読んだうえで採用可否を判断できる点は、この規模の OSS としては扱いやすい部類に入ります。一方で、API コストと環境構築の負担、そして生成物にレビューが必要である前提は動きません。まずは公式ホスト版で出力の傾向を掴み、セルフホストする動機が明確になった段階で OSS 版の導入を検討する、という順序が現実的です。

関連情報

AI を活用したフロントエンド開発の効率化や、社内ツールの内製化をご検討中の方は、お問い合わせフォームからご相談ください。要件の整理段階からご相談いただけます。