Pencil.dev × Claude Codeで実用レベルの開発効率とコード品質は両立できるか｜第2弾：Pencil.dev × Claude Codeで作ったコードは、実務で使えるか？【株式会社ライトコード】

Pencil.dev × Claude Codeで実用レベルの開発効率とコード品質は両立できるか｜第2弾：Pencil.dev × Claude Codeで作ったコードは、実務で使えるか？

前回の第1弾では、Pencil.devで作ったデザインが実務で通用するか？を検証しました！
まだ読んでいない方は、こちらからどうぞ！

前回に引き続き、デザイナーとPM（エンジニア）の3名で検証していきます。

第2弾は、「デザイン→コード変換の実用性」にフォーカスし、シリーズ完結編としてお届けします！
早く本題を知りたいという方は「第2弾：Pencil.dev × Claude Codeで作ったコードは、実務で使えるか？」からお読みください。

はじめに

Pencil.dev ✕ Claude Code（第2弾）で確かめたいこと

第1弾で作成した .penファイルを使って、Claude Codeでコード生成を行います。
今回確かめたいのは以下の3点です。

生成されたコードの品質は、開発に乗せられるレベルか？
開発効率は、実際にどれくらい変わるのか？
デザイン → フロントエンド開発までを、本当にシームレスにつなげられるか？

検証の進め方（再掲）

第1弾で提示した評価軸のうち、今回は「デザイン→コード変換の実用性」にフォーカスします。

題材は引き続き「架空の食器小売店サイト」です。
第1弾で生成した .penファイルを使用し、コード生成を行っていきます！

第2弾：Pencil.dev × Claude Codeで作ったコードは、実務で使えるか？

結論：Pencil.dev × Claude Codeでのコード生成は実務で通用する。

ただし、 .penファイルをそのままClaude Codeに渡しても、デザイン通りのコードは生成されない。

コード生成にも、AIに正しく作らせるための"前準備"が必要だった
— これが今回の最大の発見です。

この記事では、私たちが失敗から学んだ「 .penファイル → コード変換を成功させるためのコツ」を紹介します。

失敗談：.penファイルをそのまま渡したら、デザインと違うものが生成された

最初は、シンプルなフローで進めていました。

.pen からデザイン変数（ design-tokens.json ）を生成
— design-tokens.json とは？
.pen のデザイン変数（カラー・フォント・余白・角丸など）を読み取り、JSON形式のファイルに書き出したものです。
.pen のみでは、デザイン変数の値が不明確なため、そのままコード側で参照できる形に変換する必要があります。
　
アプリ仕様書（ app-spec.md ）を作成
— app-spec.md とは？
これから作るアプリの仕様をMarkdownでまとめたドキュメントです。
画面構成・データ構造・機能要件などを記載し、AIが実装するときの「何を作るか」の根拠になります。
　
実装計画書を作成
— app-spec.md と design-tokens.json をもとに、AIに実装手順を分解した計画書を生成。
「どのファイルに、どんなコードを書くか」「コンポーネントの構造はどうするか」まで含んだ、いわば実装の設計図です。
　
実装
— 実装計画書に沿って、Claude Codeにコードを生成させます。

つまり、「.penファイル（デザイン）」から「コード」までを、AIが読みやすい中間ファイル（design-tokens.json / app-spec.md / 実装計画書）でつないでいくフローです。

しかし、いざ実装してみると、デザインとはかけ離れたUIが出てきました。
フォントサイズが想定より小さい、本来ないはずの謎テキスト（"tetto"のような文字列）が混入する、レイアウトが崩れる…。

なぜ失敗したのか

原因を追っていく中で、いくつかの問題が見えてきました。

根本原因：AIが .penファイルを「要約」して読んでいた

これが一番大きな問題でした。
.pen はJSONベースのデータですが、Claude Codeは効率化のために内容を要約して扱おうとします。
さらに、.penファイル内に参考用に残していた別フレームの情報まで混ざり込み、本来生成したいデザインとは違うデザインを"再構成"してしまっていたのです。

その他に見えてきた課題

実装計画書のレビュー段階でも、以下のような問題が見つかりました。

実装計画書が1600行超
— エンジニアがレビューするには分量が大きすぎる。これだけシンプルなサイトでこれだけの分量になるので、より複雑なページだと膨れ上がる。
　
DB前提が抜けてハードコード
— 商品データが products.ts に直書きされ、実プロダクトでは使えない構成に
　
ファイル階層の重複
— app/src/app/ のような不自然な構成
　
font-sizeがデザイントークンに反映されない
— @theme に定義されず、text-[48px] のような任意値で書かれていた
　
h1タグがブランド名ではなくFVキャッチコピーに
— SEO観点でNGな判断をAIが勝手に下していた
カテゴリーなどのデータがハードコード