- AI を使ってスクリーンショット、モックアップ、Figmaデザイン、画面録画を整った動作するコードに変換するツール
- 対応スタックは HTML + Tailwind、HTML + CSS、React + Tailwind、Vue + Tailwind、Bootstrap、Ionic + Tailwind
- ウェブサイトの動作を収めた 画面録画 を受け取り、動作するプロトタイプへ変換する機能にも対応
- デフォルトのAIモデルは 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 を使用
- ローカル実行には API キーとバックエンド・フロントエンド構成が必要で、アプリ構成は React/Vite フロントエンド と FastAPI バックエンド
- OpenAI、Anthropic、Gemini のうち少なくとも1つのモデルプロバイダーのキーが必要
- Gemini は実際のロゴと画像をスクリーンショットから抽出し、動画モードに必要
- Replicate は画像編集、背景除去、Replicate ベースの画像生成を有効化
- キーを多く追加すると、variant ごとにより強力なモデルの組み合わせを自動選択し、単一キーしかない場合はそのプロバイダーのモデルのみを使用
- オプション機能の screenshot preview は、Chromium インストール後に生成されたページをヘッドレスブラウザーでレンダリングして視覚的に確認し、Chromium がない場合はそのツールをスキップ
- 実行方法はローカル開発、ホスティングアプリ利用、Docker 実行に対応し、Docker 実行時はアプリが
http://localhost:5173で起動
1件のコメント
Hacker News の意見
これは本当に魔法のように見えて、計算がどう機能するかについての自分の頭の中のモデルのどこに位置づければいいのか分からない。
ニューラルネットワークが普遍関数近似器であるというのは、入力を特定ドメインの出力へ写像する関数群をモデル化するという意味だと理解していて、MNIST のような例は概念的に納得できる。
しかしここでは、GPT の一般的な学習がピクセル強度から HTML+Tailwind のテキストトークンへの値の写像を実現し、ブラウザがそのトークンを解釈・レンダリングした結果が入力画像を近似する、ということなのか気になる。
そうだとすると、GPT はピクセル→HTML/CSS 変換だけでなく、ブラウザが HTML/CSS をレンダリングする方法までモデル化していることになる。そうした写像が存在することは受け入れられるとしても、GPT が無数の別テーマの文章も書きながらそれを導き出したというのが驚きだ。
もっと実用的には、こうしたツールをダイアグラムコンパイラのように見なせるのか、将来的に Sketch/Figma のような成果物を受け取って HTML/CSS/JS を出力するビルドパイプラインの一部になり得るのかも気になる。
潜在空間とは、アイデアや概念が互いに似ているほど近くに配置される n 次元空間で、この配置は学習中に学習データから作られるため、学習プロセスとはすなわち潜在空間を作るプロセスでもある。
2 次元グリッド上で「house」と「mansion」は近くにあり、「growling」はまったく別の隅に置かれると想像すればよい。GPT-4 のような潜在空間はこれに似ているが、数百〜数千次元で、その規模の違いが膨大な知識を有用な形で整列させている。
画像の読み取りに戻ると、学習データには Web ページ画像と対応するコードがあり、そのコードがコード・画像ペアをどこに置くべきかを学習過程に教えた。ラベルやキャプションも、テキストと同じように画像を潜在空間へ配置させる。
そのため GPT-4 に新しい Web サイトの画像を与えて対応する HTML を求めると、その画像を潜在空間に配置し、近くにある対応 HTML を取り出せる。
しかし学習可能性や必要な構造については何も述べておらず、必要な構造が非現実的に大きい可能性もある。
使われている学習アルゴリズムである確率的勾配降下法による誤差逆伝播は普遍学習器ではなく、グローバル最小値を見つける保証もない。
Sketch/Figma の段階を飛ばして、直接実行可能なプロトタイプへ進む方向に見える。
「任意の関数をフィットできる」という見方は正しいが、有限のリソースで実際にそれができるかは教えてくれないので、それ自体はあまり有用ではないと思う。
今驚くべきなのは、昔からある普遍近似器ではなく、抽象概念をこれほどよく近似するという点で、答えはデータの規模にある。
圧縮こそ知能だという見方があり、これらのモデルは優れた圧縮器だと見なせる。学習中、重みは固定サイズで、合わせようとしているデータよりはるかに小さく、目標が原文の復元、つまり次トークン予測であるなら、データを非常にうまく圧縮する以外に方法はない。
賢ければ賢いほど、よりよく予測・圧縮する。圧縮を強制されると、事実上、知能を獲得するよう強制されることになる。試験前に答えを暗記することもできるが、問題が何千問もあって暗記できないなら、科目を学んで試験中に答えを導くのが最善であるのに似ている。
この圧縮/知能の二重性は、LLM の汎化能力を否定する側からは論争的だが、現時点での私のメンタルモデルであり、まだ反証できていない。
この見方を受け入れると、マルチモーダル能力は工学上の問題に近い。GPT-4V の内部は正確には分からないが、公開されているマルチモーダル研究から推測できる。
画像とその画像を説明するテキストのペアがあれば、テキストのように画像をトークン化/埋め込みする。ViT（Visual Transformer）のように、画像をパッチごとの視覚特徴に変換して長いシーケンスにできる。
この埋め込みを事前学習済み LLM に与え、画像説明テキストを予測するよう強制すれば、画像埋め込みを見て一般的な画像理解を得る以外に方法はない。
与えられた画像の情報を理解し、自然言語で表現できるようになった後は、その理解を使うように指示チューニングすればよい。
Stable Diffusion のような画像生成モデルも同様に、CLIP のような対照モデルを学習させ、同じ概念の画像埋め込みとテキスト埋め込みを近づけ、その二重の情報を生成方向の制御に使う。
驚くべきなのは、この規模の能力をすでに備えていて、計算量を増やすだけでさらに多くの能力を得られるという点だ。現在の GPT-4 の最終損失が 1 だとすれば、何らかの形で 0.1 まで下げられたとき、はるかに有能になる可能性が高い。
2 つ目の質問については、その方向に見えるし、おそらく今でも可能だろう。
核心はここにあります: https://github.com/abi/screenshot-to-code/blob/main/backend/...
プロンプトは、ユーザーのためのTailwind専門家として、スクリーンショットを見てTailwind、HTML、JSでシングルページアプリを作るよう指示しています
背景色、文字色、フォントサイズ、パディング、マージン、ボーダーなどを正確に合わせ、スクリーンショット内のテキストをそのまま使い、「コード全体を書け」、繰り返し要素の数を合わせろ、コメントで省略するな、placehold.coの画像を使いaltに詳細な説明を入れろ、といった指示が含まれています
Tailwindは
https://cdn.tailwindcss.com、Google Fonts、Font Awesomeを使うことができ、コード全体をタグ内だけで返し、Markdownのコードフェンスは使うな、となっています個人的には防御的プロンプティングが今後の道だとは思いませんが、これが動くというのは本当にすごいことです。10代の頃に夢見ていたことが、今では比較的少ない労力で可能になった感覚です
命令に不安定に従い、バグを作り、機械に怒鳴って直す方式です
「これは複雑な課題です」をもう一度見たら本当にうんざりしそうです。性能が60%しかなくても、より「怠けない」モデルのほうが良い場合があります。残り40%の能力を使わせるには追加のプロンプトエンジニアリングが必要で、技術的限界というより意図的に弱められているように感じます
それでも競合にとっては依然として難しい要求なので、今のところOpenAIの勝ちです
もちろん今でもものすごく素晴らしく有用なので、不満ばかり言うのではなく、実際にやり遂げる競争が出てくれば、今後数年は面白くなりそうです
「これをきちんとやることは私のキャリアにとって非常に重要だ」を追加してみるとよさそうです
今は見つけられませんが、あるYouTubeの研究動画によると、複数のタスクで出力品質が目に見えて良くなったそうです
研究によれば、感情的な言葉を含むプロンプトは、「文をフォーマルな言葉に変える」「与えられたオブジェクト群の共通特徴を見つける」といったタスクで、全体として8%の性能向上をもたらしたそうです
もう何を作るべきか、どう考えるべきか分からなくなってきました
このプロジェクトをけなすつもりはまったくなく、ソース公開にも感謝していますが、今ではかなり簡単に解けそうに見える問題群がまるごと生まれていて、「わざわざなぜやるのか？」という感じがします
何を解く価値があるのか、どう解くべきなのかの両面で、問題設定を再調整する必要がありそうです
こうしたツールが、少し手直しするだけで済む「十分に良いコード」を出せるなら、大きな時間節約になります
ただめちゃくちゃなコードを出すだけなら、あまり役に立ちません
技術者は使うツールそのものに過度に没頭しがちです。Framework AとToolkit Bを無理やりくっつけたという理由だけで、ごく平凡で空っぽな「hello world」プロジェクトが展示されるのをどれだけ見てきたか分かりませんし、本当に退屈です
LLMベースの技術がこの文脈で挑戦的なのは、可能性そのものを考え直さなければならないからです。ツールが汎用的なら、単なるショーケースを作ることにはあまり意味がありません
驚くべき点はもちろん、これが汎用モデルでできることですが、この作業のための教師あり学習データを生成するのはかなり簡単そうです
HTML生成 → レンダリングしてスクリーンショット撮影 → そのデータを逆向きに学習に使えばよいのです
GitHubページにはPico経由でホスト版を提供する予定だと書かれていますが、なぜPicoを選んだのか気になります
たった今そのページでPicoを知ったのですが、Picoは売上の30%だけを支払うように見えます。一般的なアプリストアの60%取り分の半分で、私の読み方では、無料ユーザーがアプリを試した後に登録した場合にだけ支払われ、すでにプラットフォーム上にいたユーザーが使う分は支払われないようです
従来のプラットフォームより条件もずっと悪く、ユーザーベースも小さそうに見えるので、選んだ理由が気になります
それとPicoは一般的なWebアプリ制作プラットフォームです。売上30%の部分はアフィリエイトにのみ該当し、アプリ内決済には該当しません。Picoはまだアプリ内決済に対応していません
要点がよく分かりません。既存のWebサイトをコピーしたいのなら、なぜHttrackを使わないのか分かりません
元のWebサイトのほうが常により似ているはずですし、GPT APIの費用も節約できます。この手法が輝くのは、スケッチからWebサイトへ持っていく場合です
生成されたWebサイトのデモを、
srcdoc付きのiframeとして、生成中にすぐ見せる方式が本当に良かったですシンプルでエレガントです
「AI」の実装の詳細を無視すれば、これはラスター画像を拡大するとひどく見え、レンダラーに不要な線を描かせたり塗りつぶさせたりするSVGに変換するのと似た意味で、HTMLを生成しているということです。
つまり、出力結果はWeb開発者に渡すのに十分きれいには見えません。開発者はそもそも高度なツールを必要とせず、テキストエディタのスニペットプラグインのほうがうまくやれる、ごく明白な上位構造以外は、ほとんどすべて書き直すことになりそうです。
Web開発の多くの部分は目に見えもしません。アクセシビリティはスクリーンショットから得られないメタデータですし、レスポンシブCSSには、すべての挙動やアニメーションなどを漏れなく収めた動画が必要になるでしょう。
JavaScriptは、どれだけ画像認識を使っても判断するのはほぼ不可能に見えます。
それなら開発者ツールから実際のHTMLを直接コピーしたほうがよいのでは？
フィッシングサイトを作る速度がずっと速くなりそうです。