Screenshot to Codeは画面の見た目を実装の出発点へ変える
スクリーンショットをドロップして、クリーンなコード (HTML/Tailwind/React/Vue) に変換します。
ひと目でわかる
- これは何？
- abi/screenshot-to-codeの対応スタック、モデル鍵、ローカル構成、プレビュー機能と生成物の確認責任をREADMEから読む。
- 誰に向いている？
- Screenshot to Codeは、既存画面をコード化する初稿作りや、デザイン検証用のプロトタイプを短時間で用意したい人に向きます。生成結果をそのまま本番へ出す道具ではなく、APIキーの管理、画像やロゴの権利、レスポンシブ挙動、アクセシビリティ、実ブラウザでの表示を人が確認する工程が必要です。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 6 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
入力はスクリーンショットだけではない
abi/screenshot-to-codeは、スクリーンショット、モックアップ、Figmaデザイン、画面録画を入力にして、機能するコードやプロトタイプを生成するAIツールです。READMEが示す対応スタックはHTMLとTailwind、HTMLとCSS、ReactとTailwind、VueとTailwind、Bootstrap、IonicとTailwindです。静止画の見た目を写す作業と、操作中のWebサイトを画面録画から組み立てる作業が同じ入口に置かれています。
出力形式が複数あるため、最初に既存プロジェクトの技術方針を決めておくべきです。Reactを採用したいのにHTMLの例で評価すると、生成精度と保守性の比較を誤ります。READMEの対応表は機能の入口を示すもので、複雑な状態管理、サーバー連携、実データ、既存デザインシステムまで再現するという約束ではありません。
モデルとAPIキーの役割を分ける
既定モデルとしてREADMEにはGemini 3 Flash Preview、Gemini 3.1 Pro Preview、GPT-5.5、GPT-5.4 Mini、Claude Opus 4.6、Claude Opus 4.8が挙げられています。画像生成にはReplicate経由のz-image-turboが記載されます。ローカル実行ではOpenAI、Anthropic、Geminiのいずれか一つのモデルプロバイダー鍵が必要で、GeminiとReplicateは品質や画像処理のために強く推奨されています。
Geminiはスクリーンショットから実際のロゴや画像を抽出するアセット処理を担当し、Replicateは画像生成、背景除去、画像編集に使われます。Replicate鍵がない場合は`edit_images`と`remove_backgrounds`が使えず、動画モードにはGemini鍵が必要です。鍵を増やせば常に目的に合う結果になるわけではなく、プロバイダーへの送信範囲、費用、生成物の確認方法を先に決める必要があります。
ローカル版はReactとFastAPIの二層構成
READMEはローカル実行の構成をReactとViteのフロントエンド、FastAPIのバックエンドとして説明しています。バックエンド側ではPoetryで依存を入れ、Playwrightでスクリーンショットプレビュー用のChromiumをインストールし、Uvicornを7001番ポートで起動します。フロントエンドはpnpmを使って開発サーバーを5173番ポートで起動する流れです。
環境変数はバックエンドの`.env`に置く鍵と、フロントエンドの`VITE_WS_BACKEND_URL`に分かれます。実行者が誤った場所へ鍵を保存すると、鍵の漏えいと接続不良が同時に起きます。READMEのコマンドを実行する前に、開発用の秘密情報をリポジトリへ追跡させないこと、フロントエンドへ秘密鍵を埋め込まないこと、ポートとWebSocketの向きを確認することが必要です。
画像プレビューが担う確認範囲
スクリーンショットプレビューは、エージェントが生成したページをヘッドレスブラウザで描画し、見た目を確認する任意機能です。Chromiumがインストールされると自動的に有効になり、設定画面からバックエンドで利用可能かを確認できます。これは生成後の目視確認を支える機能であり、完成品の品質を自動で保証する検査ではありません。
確認対象は、画面画像との近さだけに限定しません。異なる画面幅での折り返し、キーボード操作、フォームのラベル、画像の代替テキスト、リンク先、動的状態、読み込み失敗時の挙動を別途見ます。プレビュー機能が無効でもコード自体は生成できますが、その場合は人がブラウザで検証する工程の比重が上がります。
Poetry、pnpm、Dockerの使い分け
ローカル開発では、Poetryでバックエンドを準備し、`poetry run playwright install chromium`でブラウザを入れ、フロントエンドは`pnpm install`と`pnpm dev`で動かします。Dockerを使う場合はルートで`.env`を作り、`docker-compose up -d --build`を実行する例がREADMEにあります。どちらもアプリを5173番ポートで開く入口ですが、Docker構成ではファイル変更が再ビルドを起こさないため開発には向かないと注意されています。
ホスト型アプリはローカル設定なしで試せる最短経路として案内されています。比較検証では、ホスト型へ入力を送る場合とローカルでモデルAPIを呼ぶ場合を同じ扱いにしないことが大切です。画像、画面録画、生成コード、秘密情報の保管場所と削除条件をそれぞれ記録し、試作の便利さとデータ管理の条件を切り離して判断します。
生成コードを採用候補へ変える工程
Screenshot to Codeの出力は、見た目と画面構造を作るための候補です。実際の製品コードにするには、コンポーネントの責務を分け、重複したCSSや画像を整理し、ルーティング、状態、API接続、エラー表示を設計し直します。画面録画から得たプロトタイプも、録画された操作の範囲しか事実を持たないため、未収録の状態を生成結果から推測してはいけません。
Geminiによるアセット抽出は、元画像にあるロゴや画像を再利用できる可能性を示しますが、第三者素材の利用許諾まで解決しません。生成画像、元画面のコピー、ブランド要素の権利を確認し、公開前に置き換える素材を決めます。アクセシビリティやセキュリティのレビューも、生成ツールの外側に残る人の責任です。
MITライセンスとREADMEが残す不明点
リポジトリはMITライセンスです。コードの利用、改変、再配布を検討する法的な出発点になりますが、生成された画面に含まれる第三者の画像やロゴの権利、各モデルプロバイダーの利用条件、入力データの取り扱いを一つにまとめて許可するものではありません。鍵を使う外部サービスの契約は別に確認します。
素材メタデータでは、mainブランチ、約7万5千スター、約9千フォーク、131件のオープンイシューが確認できます。注目度は利用者の広がりを考える材料にはなりますが、生成物の正確さ、保守負荷、サポート水準の証明ではありません。まず一枚の画面を対象に入力、モデル、費用、修正時間、実ブラウザでの差分を記録し、チームの基準を作ってから範囲を広げるのが妥当です。
編集部の結論
Screenshot to Codeは、既存画面をコード化する初稿作りや、デザイン検証用のプロトタイプを短時間で用意したい人に向きます。生成結果をそのまま本番へ出す道具ではなく、APIキーの管理、画像やロゴの権利、レスポンシブ挙動、アクセシビリティ、実ブラウザでの表示を人が確認する工程が必要です。ローカル版とホスト版の扱いを分けて、まず一つの画面で再現度を測ってください。
コミュニティノート