はじめに
前回は、AIネイティブ開発の概要と、エンジニアに求められる役割の変化について解説しました。第2回となる本稿では、その具体的な実践例として、スケッチ画像からUIを生成する方法をベースとした「Visual-to-Code」という開発スタイルを検証します。
上記の動画は、OpenAIが昨年公開した「Build beautiful frontends with OpenAI Codex」です。この動画の一幕に以下のような流れがあります。
ホワイトボードに、旅行アプリの画面構成をスケッチします。これをスマートフォンで撮影し、OpenAI Codexに入力します。すると、Three.jsによって3Dの地球儀が回転するインタラクティブなUIが生成され、レスポンシブ対応まで完了します。さらにCodexは、自らスクリーンショットを撮影して見た目を確認しながら、コードを修正していきます。
ここで使用されているのは、クラウド上でタスクを実行する環境である「Codex Cloud」です。この環境では、ブラウザの起動からビジュアルチェックまでを自律的に実行できます。ローカルで動作する「Codex CLI」とは別物ですが、「スケッチからUIが生まれる」という体験のインパクトは、十分に伝わりました。
今回は、この「Visual-to-Code」という開発スタイルを実際に検証します。
Visual-to-Codeとは
本稿では、画像やスケッチを入力として、UIのコードを生成する手法を「Visual-to-Code」と呼んでいますが、学術的には「Sketch2Code」や「Design-to-Code」といった用語が使われています。最近では「ScreenCoder」のようなマルチエージェント型のフレームワークも登場しています。
もちろん、AIにUIを作成させる方法はテキストプロンプトでも可能です。
例えば、「ヘッダーは固定でh-16程度。左側にロゴ、右側にハンバーガーメニューを配置。メインコンテンツは3カラムのグリッドとし、スマートフォンでは1カラムにする」といった具合です。
しかし、カードの角丸、影、ホバー時のアニメーションなど、説明すべき要素は無限にあり、テキストの情報だけで正確に伝えるのは、非常に困難な作業です。
こうしたプロンプトを記述している際、言語化能力の限界を痛感します。デザインやレイアウトをテキストで伝えるのはとても難しいです。私もよく「もう少しスタイリッシュな感じで」と指示を出し、期待した結果が得られず苦労しています。
言語化の壁
なぜ、テキスト情報でデザインやレイアウトを伝えるのが難しいのか？
なぜならUIは、「空間の情報」だからです。上下左右、大小、包含関係など、要素同士の位置関係が意味を持ちます。一方、言葉は「線形の情報」です。1つずつ順番に説明するしかありません。
この空間情報から線形情報への変換コストこそが、言語化の難しさの本質であると考えています。
Visual-to-Codeでは、人間同士のコミュニケーションのように、描いた絵を渡すだけでAIが空間情報を直接読み取ってくれます。
Visual-to-Codeが効果的な場面とは
Visual-to-Codeがどのような場面で活用できるか、いくつか挙げてみます。
プロトタイピング
アイデア段階で、ひとまず動くものを見たい時に効果的です。完璧な仕様書を作成する前に、ホワイトボードのスケッチから5分でプロトタイプが作成できます。
デザイナーとの連携
Figmaのスクリーンショットを渡して「この画面を実装して」と指示すれば、デザインの雰囲気（配色、余白、フォントサイズ）を引き継いだコードが生成されます。
既存UIの模倣
「このサイトに近い画面を作りたい」という時、参考サイトのスクリーンショットを渡すだけで、似たテイストのUIが生成されます。
バグの報告と修正
「スマートフォンで見るとレイアウトが崩れている」という時、崩れた画面のスクリーンショットを入力するだけで、AIが原因を特定して修正案を提示してくれます。
