Kombaiでデザインをコードに変換する｜v0を上回る再現度と、実プロジェクトで残る手作業【AI活用検証vol.7】

Figmaのデザインをそのままコードに変換できれば、フロントエンド開発の工数は大きく変わります。この領域のツールとして注目したのが Kombai です。VSCodeやCursorの拡張機能として動き、Figmaのデザインを読み込んでコードを出力します。

検証の結果、デザインの再現度は高く、比較したv0を上回りました。ただしそのまま動くコードが出てくるわけではありません。どこまでが「そのまま使える」のか、線引きを共有します。

この検証の概要

本記事は自社での検証記録です。工数削減率などの定量測定は行っていないため、数値は掲載していません。

結論：デザイン再現度は高い。ただし「プロダクトコード」ではない

この検証で最も重要な発見がこれです。

Figma全体のデザイン再現度に関しては、Kombaiのほうがv0より高いと評価しました。見た目をどれだけ忠実に再現できるかという軸では、明確に強いツールです。

一方で、出力されたコードがそのままプロダクトとして成立するわけではありません。サンドボックス環境では優秀に動きますが、実際のプロジェクトに書き出すと話が変わります。

つまずいたこと：実プロジェクトへの書き出し

具体的に発生したのは、Next.jsやTailwindの設定ファイルが不足するケースです。生成されたコードは、それ単体では動く前提で書かれていますが、既存プロジェクトの構成と噛み合わないことがあります。

結果として、出力されたコードを即座に動作させるための準備コストが発生しました。設定ファイルを補い、既存の構成に合わせて整える工程が必要になります。

つまり、デザインの忠実度と、開発環境との整合性は別問題ということです。前者は解決されつつありますが、後者は人間が引き取る必要があります。

現時点での使い方：骨組み生成として割り切る

この制約を踏まえて、次のような切り分けを推奨しています。

「コードを書かなくてよくなるツール」ではなく「デザインからコードへの最初の一歩を飛ばすツール」と捉えると、期待値が合います。ゼロからマークアップを起こす工程が省けるだけでも、効果は十分あります。

v0との比較

同じ領域のツールであるv0と比べると、性格の違いがはっきりしました。

すでにFigmaでデザインが固まっているならKombai、まだ形が決まっていないならv0、という使い分けになりそうです。今回は「既存デザインの再現」という軸での比較であり、用途が違えば結論も変わります。

よくある質問

コードがそのまま使えないなら意味がないのでは？

マークアップをゼロから起こす工程が省けます。デザインの構造をコードに落とす作業は手間がかかるため、そこが自動化されるだけでも効果はあります。ただし「エンジニア不要になる」という期待には応えられません。

どのくらい工数が削減できますか？

この検証では定量測定を行っていないため、削減率はお答えできません。デザイン再現度が高いこと、および実プロジェクト適用には準備コストが発生することを確認した、という定性的な記録です。

なぜ「保留」なのですか？

実用化に向けた環境整備が必要なためです。設定ファイルの不足を毎回手作業で埋めていては、削減した工数が相殺されます。プロジェクト側のテンプレートを整えるなど、受け入れ体制を作ってから本格導入する判断です。

まとめ

• KombaiのFigmaデザイン再現度は高く、v0を上回った
• ただしそのままプロダクトコードとして成立するわけではない。Next.js/Tailwindの設定ファイル不足などで手動調整が必須
• デザインの忠実度と、開発環境との整合性は別問題
• 現時点は「デザインの骨組みを高速生成するツール」として割り切るのが実用的。細部はエンジニアが担当

デザイン→コード変換ツールの評価では、生成物の見た目だけでなく「自分たちのプロジェクトに載るか」まで見る必要があります。サンドボックスでの印象と実プロジェクトでの手触りは、かなり違いました。

株式会社AI棒では、こうしたAIツールの検証を日々行い、企業の開発業務へのAI活用を支援しています。ご相談はお問い合わせフォームから、継続的な伴走支援についてはAI参謀をご覧ください。