Pencil.dev ✕ Claude Codeで実用レベルの開発効率とコード品質は両立できるか｜第1弾：Pencil.devで作ったデザインは実務で通用するか？

みなさんは、Pencil.devというAIデザインツールをご存知ですか？
エンジニア界隈では話題になっているものの、デザイナーやPMの視点から検証した記事はまだほとんどありません。
今回は、デザイナーとPMの3名でPencil.dev ✕ Claude Codeを検証していきます。

この記事は、第1弾をお届けします。
早く本題を知りたいという方は「第1弾：Pencil.devで作ったデザインは実務で通用するか？」からお読みください。

はじめに

Pencil.dev ✕ Claude Codeで確かめたいこと

もし、デザインカンプの作成からコードの生成までをAIがやってくれるとしたら
— それは本当に開発で使えるクオリティなのでしょうか？

この連載では、Pencil.devとClaude Codeを掛け合わせ、その実用性を検証していきます。

• AIデザインツール「Pencil.dev」で作ったデザインは、実務で通用するか？
• そのデザインから「Claude Code」で生成したコードは、開発にそのままのせられるか？
• デザインと実装の間にある溝を、AIによってどれだけ埋められるか？

Pencil.dev とは？

• AIでデザインカンプを丸ごと生成できるデザインツール
• Claude Code等のAIツールと直接連携できる（MCP対応）
• UIはFigmaに近く、手動での調整も可能
• デザインデータはJSONベース（.pen形式）で、Gitで差分管理できる

→ 公式サイト: https://pencil.dev

Claude Code とは？

• Anthropicが提供する、ターミナルで動くAIコーディングエージェント
• コードの生成からファイル操作、Git操作までを会話形式で実行できる
• MCP対応により、Pencil.devなどの外部ツールと直接連携できる

→ 公式サイト: https://claude.ai/code

なぜ今、検証するのか — AI時代の開発と向き合う

AIツールが日進月歩で進化し、開発の在り方そのものが変わりつつあります。
弊社は、デザイン専業でも開発専業でもなく、プロダクトをトータルで作り上げる会社です。
デザインから実装までのスピードを上げることは、そのまま競争力に直結します。

加えて、AIツールの普及により、デザイナーの役割も大きく変わりつつあります。
「デザインして終わり」ではなく、動くプロダクトまでを視野に入れた
— いわゆる"バイブデザイン"的なスキルが求められる過渡期にあります。

PMとしても、デザイナーやエンジニアがどこに注力し、どこをAIに任せるかを見極めることが、これからのチーム設計に欠かせないと感じています。

そこで、Pencil.dev ✕ Claude Codeがその武器になるのかを、実務に近い形で検証することに意義があると考えました。

検証の進め方

開発効率とコード品質を検証するために、実務に沿って「デザインカンプ生成 → コード生成」のフローを実際に行い、事前に選定した評価軸に基づいて評価していきます。

評価軸

デザインと開発面から重要な項目を策定し、以下の軸で5段階評価を行います。

題材

「架空の食器小売店サイト」を題材に、以下の3ページを作成します。題材の選定理由は以下の通りです。

• レイアウトの不規則性と規則性のバランスが、デザイン&コード検証に適している
• AI生成画像のクオリティも含めて評価できる

第1弾：Pencil.devで作ったデザインは実務で通用するか？

結論：Pencil.devで作ったデザインは実務で通用する。

ただし、ここで言う「通用する」とは見た目だけの話ではありません。
コードに落としやすく、チームで運用できるデザインかどうかも含めての評価です。

この記事では、私たちが試行錯誤の中で見つけた「実務で通用するデザインを生成するコツ」を紹介します。

ただし、闇雲に使っても通用しない

まずは、Pencil.devの実力を把握するために、最小限のプロンプトでデザインを生成してみました。
やったことはシンプルで、Pencil.devに「架空の食器小売店サイトのトップページを作って」と指示しただけです。

ここで注目したいのは、一見それなりのデザインが出てくるということです。
PM目線で「見た目」だけみると「そこそこ使えそうだな」という印象を持ちました。

しかし、デザイナーの目線で分析すると、以下の問題が見えてきました。

デザイン品質の問題

• ユーザー設計の意図がない
  — 誰に向けたデザインなのか、導線の根拠が不明なまま見た目だけが生成される
  　
• トーンや文言が定まらない
  — 誰に向けた言葉なのか、専門用語が混在しても気づけない
  　
• デザインルールが不明
  — 色・フォント・余白がどんな根拠で決められたのかブラックボックス
  　
• 値の一貫性がない
  — カラーやフォントサイズがページごとにばらつき、統一感が出ない

運用・保守性の問題

• セッションが変わると1から伝え直し
  — 前回の指示や調整内容が引き継がれず、毎回ゼロからAIに説明が必要
  　
• バリアブル（デザイン変数）が設定されない
  — 色や余白が変数化されず、後から一括変更ができない
  　
• 再利用可能なコンポーネントが生成されない
  — 同じパーツが毎回別々に作られ、修正が全箇所に及ぶ

つまり、「1回きりのデザイン」は作れても、運用できるデザインにはならないということです。

実務で通用するデザインにするために私たちが考えたこと

これらの問題を踏まえ、私たちはデザイン生成のフローそのものを設計し直しました。

1. ドキュメント設計
   — AIが従うべきデザインの品質と運用性のルールを人間が設計し、ルール文書（.md）を作成
   　
2. デザイン生成
   — ルール文書（.md）をPencil.devに連携しているAIに読み込ませてデザインカンプを生成
   　
3. ルールに基づく調整
   — 生成されたデザインを部分調整
   　

以下、各ステップを詳しく紹介します。

ステップ1. ドキュメント設計

デザインの品質と運用性を担保するために、以下のルール文書を作成しました。

POINT：デザイン基準書と基準プレビューの役割

AIはプロンプトだけでは「なんとなくいい感じ」のデザインを作りますが、色・フォント・余白などの具体的な値までは保証してくれません。
デザイン基準書（design-style-guide.md）は、デザイナーが決めたルールを数値レベルで明文化したもので、AIにとっての「唯一の正解」になります。
ただし、テキストだけでは人間側がルールの妥当性を視覚的に確認しづらいという問題があります。

基準プレビュー（design-style-demo.html）を用意し、定義した色やフォントをブラウザ上で確認できるようにしました。
これにより、デザイナー・PM間の認識のズレを防ぎつつ、ルールの調整もスムーズに行えます。

▼デザイン基準書（design-style-guide.md)

▼基準プレビュー（design-style-demo.html）

POINT：CLAUDE.mdによるルール自動読み込み

Claude CodeにはCLAUDE.mdというファイルがあり、セッション開始時に自動で読み込まれます。
CLAUDE.mdに作成した各ルール文書（.md）を読み込ませる記載をしておくことで、セッションが変わっても毎回ゼロから説明し直す必要がなくなりました。

ここで重要なのはCLAUDE.mdという仕組み自体ではなく、「AIにルールを毎回自動で読み込ませる」という考え方です。
お使いのAIエージェントに応じた方法で、同じアプローチを取り入れてみてください。

記入例:

1# CLAUDE.md
2- 作業開始前に `design-brief.md` を必ず読み、内容を省略・要約せずそのまま理解すること
3- デザイン作成時は `design-style-guide.md` のルールに厳密に従うこと。値のハードコードは禁止
4- 画面構成は `screen-spec.md` を参照し、記載のないページは作成しないこと

※ 検証の中でClaude Codeがルール文書を要約・省略して読み飛ばすことがあったため、強めの指示を記載しています。

ステップ2. デザイン生成

ステップ1でルール文書を整備したことで、デザイン生成時のプロンプトは非常に簡潔なもので済むようになりました。
ルールが適用されているか不安な方は、チャットの始まりに「ルールを理解していますか？」と聞いてみてください。AIが理解している内容を要約して返してくれます。

ルールを整備した効果として、運用できるデザインが生成されるようになりました。

デザイン品質の改善

• 企画書のターゲット・トーンに沿ったデザインが生成され、ユーザー設計の意図が反映された
• トーンや文言も企画書に基づいて統一され、プロジェクトのイメージに沿った表現になった
• デザイナー作成のデザインルールに基づいた色・フォント・余白で生成され、根拠が明確になった
• バリアブル（デザイン変数）が定義された状態で出力され、値の一貫性が保たれた

運用・保守性の改善

• CLAUDE.mdによりセッションが変わってもルールが引き継がれ、ページの追加や拡張時にも品質がブレなくなった
• バリアブルが設定された状態で出力され、後から一括変更が可能になった
• コンポーネントがメイン/インスタンスの構成で生成され、再利用可能な状態になった

▼今回生成された「シックでモードな、キリッとした雰囲気」をコンセプトに、黒背景の洗練されたデザイン

▼コンポーネント

ステップ3. ルールに基づく調整

Pencil.devの一番の強みだと感じたポイントは、一から生成し直すのではなく、部分的に調整することができることです。
気になる点を直接触ることができ、UIもFigmaとほぼ同様なので学習コストもかかりません。
プロンプトによる修正だけではないのが、他の生成AIとの大きな違いだと感じました。

また、AIを駆使した修正もPencil.devの特徴です。

■AIによる部分修正
Pencil.dev上で要素を選択すると、AIがその範囲を認知してくれます。「ここだけ変えたい」という修正がピンポイントで可能で、全体を壊す心配がありません。

▼例：選択範囲をつくり、「文字が小さくて読みずらい」とAIエージェントに伝える。

▼修正前（フォント:Cormorant Garamond、見出し:24px、小見出し:12px）

▼修正後（フォント：Noto Sans JP、見出し:28px、小見出し：14px）

■手動 + AI修正
AIで大きく直して、細かいところは手で仕上げる。こういった使い分けができるのも、Pencil.devの特徴です。

▼例：ボタンの矢印SVGのデザインが崩れていたため、手動 + AIで修正。

プロセス① SVGの差し替え(AI修正)
問題のあるボタン内SVGと2つ同時選択した状態でAIに「SVGを入れ替えて整えて」と指示。
元のデザインに近づいたものの、まだ崩れが残っている状態。

プロセス② SVGのサイズ変更(AI修正)
AIに原因を尋ねると、まずSVGのサイズが大きすぎると判明。
ボタンのサイズに合わせてスケールダウンしましたが、見た目は変わらず。

プロセス③ パスの記法を絶対座標に変更(AI修正)
さらにAIとやりとりを続けるうちに、パスの記法が問題だとわかりました。
-15.588-7.327 のようにマイナス符号が区切り文字を兼ねる書き方を、Pencil.devのレンダラーが正しくパースできていませんでした。
絶対座標（大文字 L）に書き換えることで解決。

1NG（相対座標・連結）
2M0 7.327l48 0-15.588-7.327 0 12

1OK（絶対座標）
2M0 7.327L48 7.327L32.412 0L32.412 12

プロセス④ stroke thickness を 1 に設定(手動修正)
データ上の数値が仕様と合っていても、見え方を基準に修正したいことがあります。今回の場合は、stroke thicknessが 2 だとイメージより太かったため、手動で修正しました。

▼修正前

▼修正後

まとめ - 検証から見えたこと｜第1弾：Pencil.devで作ったデザインは実務で通用するか？

AI時代におけるデザイナーの役割変化

Pencil.devなどのAIが作業を担う分、デザイナーにはより本質的な判断力が求められるようになると感じました。
中でもデザイナーの判断が欠かせないと感じたのは以下の3つです。

• ルールの策定
  — 「なんとなく」ではなく、プロダクトに沿った意図と根拠のあるデザイン基準を決める
  　
• UX/UIの設計判断
  — AIが出してきたレイアウトや配色を検討し、ユーザー体験が担保されているかを判断・修正する
  　
• 品質の見極め
  — AIが出したものを鵜呑みにせず、デザイナー自身の経験と審美眼をもって「これでいいのか」を問い続ける
  　

デザイナーが不要になるのではなく、AIが作業を担うからこそ、こうした判断力がより一層重要になる。これがPencil.devの検証を通して見えた、デザイナーの役割の変化です。

Pencil.devのメリット

デザイナー視点
圧倒的なメリットは、「デザインデータを作成する」という手作業の効率化です。
作業時間が短縮された結果、UX設計やブランドの方向性の検討といった上流工程により多くの時間を割けるようになります。

• 初期デザインの立ち上げが圧倒的に速い
  — 1ページまるごと生成でき、ラフやワイヤーの画像からも生成可能。ゼロから作る工数が大幅に減る
  　
• 組み込みデザインシステムが用意されている
  — Shadcn UI等のプリビルトコンポーネントがあり、ゼロからスタイルガイドを作らなくても品質を担保できる
  　
• 構造が整った状態で出力される
  — セクション構造の自動判別・適切なレイヤー名付けにより、後から探しやすく整理の手間が省ける
  　
• デザイン変数・コンポーネントが同時に生成される
  — カラー・タイポグラフィ等の変数や再利用可能なコンポーネントが最初から作られるので、運用に耐える構造が初手で手に入る
  　
• AIで一括操作できる
  — Claude Codeのターミナルからデザイン変数を一気に書き換えられるなど、手作業では手間のかかる操作を効率的に行える
  　

PM視点
マネジメントの観点から見たとき、一番のメリットはGitでデザインが管理できると言うことです。

• デザインデータとコードをGitで一元管理できる
  — 従来はどのデザインデータが最新か常にデザイナーが把握しておく必要があったが、Gitで管理することでその負担が減る
  　
• 意思決定の根拠とデザインを一緒にPR管理できる
  — 意思決定のドキュメント（.md）とデザイン（.pen）をセットでGit管理・PRレビューができる
  　
• AIエージェント連携で、手作業起因のミスが減る
  — デザイン変数の一括変更などをAIが行うため、変更漏れや値のばらつきといった人為的ミスのリスクが下がる
  　

Pencil.devの課題や制約事項

ポテンシャルを感じた一方で、実務導入を検討するうえで把握しておくべき課題も見えてきました。

フロントで話題のPencil.dev、実は「デザイナーが一番使いこなせるツール」では？

フロントエンド界隈で話題になっているPencil.devですが、検証を通じて、実は「デザイナーが一番使いこなせるツール」では？と感じました。

エンジニアにとって生成AIツールは、目新しいものではありません。
v0などのツールが既にあり、コンポーネント生成やUI作成はある程度できていました。

一方、デザイナーにとってはどうだったでしょう？
従来のプロンプトでやり取りしコードを書き出す生成AIツールとは、デザイナーの仕事の本質と相性があまりにも悪かったんです。

Pencil.devが他の生成AIツールと大きく違うのは、手動で調整できること、ドキュメントに従って生成してくれることです。

手動で調整できるということは、単に「細かい修正ができる」というだけではありません。
デザイナーはこれまで、注目させたい箇所をあえてルールから外れた違和感を残したり、余白をほんの少しずらしてユーザーの視線を誘導したりしてきました。
「整合性を崩す」ー これはデザインにおいてとても重要で、デザイナーの経験と判断が問われる箇所でした。

従来の生成AIツールは、デザインの原則に沿ったきれいなデザインは生成してくれるけど、「整合性を崩す」にはコード自体を触るしかありませんでした。

また、デザインルールを文書化さえすれば、Pencil.devがそのルールに基づいて生成してくれます。
色・フォント・余白などのデザインルールを決め「一貫性を守り続ける」ー これは、デザイナーが今までずっとやってきたことです。
その「ルールを言語化する力」は、エンジニアよりデザイナーの方がはるかに経験を積んでいます。

つまり、Pencil.devを使いこなすために必要なスキルは、デザイナーがすでに持っているものばかりだということです。

次回予告

さて、ここまでお読みいただきありがとうございました。

皆さんはPencil.devを試してみたくなりましたか？
Pencil.devはまだまだ発展途上ですが、「デザインの民主化」ではなく「デザイナーの武器化」に向かうツールだと、この検証を通じて感じました。

次回は、第1弾で作成したデザインカンプ（.pen）をもとに、Pencil.dev × Claude Codeを使ったコード生成の検証を行います。

• 生成されたコードの品質や開発効率への影響は？
• デザインからフロントエンド開発までをシームレスにつなげられるか！？

などコード周りを中心にお届けする予定です。お楽しみに！