✏️

Claude Code / Cursor と組み合わせるデザインツール「Pencil」は何者か

に公開

この記事は、Pencil を「実際に導入検討する前提」で整理したものです。
機能紹介だけでなく、弱点やコスト、向いている人まで含めて判断材料になるように書きます。

本記事は 2026-02-23 時点の公開情報をもとにしています。

先に結論

1. どういうものか

Pencil は、デザイン用キャンバスとコード生成を、IDE中心の開発フローへ接続するツールです。
公開情報では、Cursor / VSCode / Claude Code / OpenAI Codex との組み合わせが案内されています。

特にユニークなのは、デザインファイルを .pen というテキストベース(JSON)の形式で持ち、Git差分で扱える点です。
「デザインを画像成果物ではなく、コード同様の変更対象として扱う」思想がかなり明確です。

2. 特徴

主な特徴は次です。

  • Infinite canvas 上でAIにプロンプト指示してUI案を作成・編集できる
  • ベクター編集からコード(HTML/CSS/React)への変換導線がある
  • Brand kits / design kit を使って、ある程度トーンを揃えやすい
  • Figmaのフレームをコピー&ペーストで取り込める(画像は別対応が必要)
  • MCPサーバーをローカルで動かし、AIが .pen を読み書きできる
  • .pen がGitフレンドリーで、branch/merge/commit運用に乗せやすい

UIKit / Storyboard / SwiftUI / Flutter から .pen は作れるか

「既存コードから .pen を作る」ワークフロー自体は公式に案内されています
Design to Code ドキュメントには Code → Design が明記されており、AIに「既存コンポーネントを .pen に再構成して」と指示する流れです。

一方で、現時点の公式例は tsx などWeb実装中心です。
そのため、UIKit / Storyboard / SwiftUI / Flutter widget については、次の整理が実務的です。

  • 直接コンバーターがある、と公式に明言されているわけではない
  • ただしAIが参照できるコードとして渡せれば、.pen へ再構成できる可能性はある
  • 再現性はコード記法より「レイアウト情報の明確さ」に依存しやすい

自分なら、モバイルUIを取り込むときは次をセットで渡します。

  1. 該当コード(SwiftUI View / Widget / UIView / .storyboard
  2. 実機やシミュレータのスクリーンショット
  3. レイアウト意図(余白・優先順位・状態変化)

こうすると、AIが .pen を再構成するときのブレを減らしやすいです。
つまり「完全な自動変換」より「コード+視覚情報からの半自動再構成」と考えるのが安全です。

Pencilの見た目をGUIでどう確認できるか

「実際の画面がどんなUIか」を確認する方法は、実務では次の3つが早いです。

  1. 公式サイトの1分デモを見る
    pencil.dev のトップにある Watch 1 min demo が最短です。全体の雰囲気を一気に掴めます。

  2. ドキュメントの Pencil Interface を見る
    キャンバス、レイヤーパネル、選択状態、ショートカットなど、UI要素の構成を文字ベースで確認できます。

  3. 実際に起動して Welcome File を開く
    Desktop App か VSCode/Cursor拡張を入れて .pen を開き、キャンバス上で右クリックして Open Welcome File を実行します。
    サンプルコンポーネントとレイアウトが入っているので、「どこまで作り込めるか」を最も正確に把握できます。

事前把握は 1 + 2、導入判断は 3 で行う のが最短です。

状態分岐が多いアプリの見た目差分をPencilでどう表現するか

ログイン状態、権限、空データ、エラー、ローディングなど、状態が多い画面は
「1画面1完成形」で管理するとすぐ破綻します
Pencilでは、次の分割で管理すると崩れにくいです。

  1. 共通部品は reusable component 化する
    ボタンやカードなどの共通要素はコンポーネント化し、状態ごとの差は instance 側でオーバーライドします。

  2. 状態ごとのUIは frame を分けて並べる
    例: Profile/Loaded, Profile/Empty, Profile/Error, Profile/Loading のように、同一キャンバス上で比較可能な形にします。

  3. テーマ差分は variables で持つ
    light/dark やブランド色差分は個別オブジェクトの直書きではなく、variables経由にして一括更新可能にします。

  4. AIでバリエーションをまとめて生成し、スクリーンショットで検証する
    AI Integrationの例にあるように「5 variations」を作らせ、get_screenshot で見比べる運用が有効です。

実装レベルで見ると、.pen は component instance のオーバーライド(ref + descendants)を持てるので、
「同じ骨格に対して、状態で文言・色・一部要素だけ差し替える」表現と相性が良いです。

注意点として、現時点では「状態行列を専用UIで一括管理する仕組み」が強く前面に出ているわけではありません。
そのため、命名規則とframe配置、Git差分運用で状態爆発を制御するのが実務的です。

3. これまでの類似品との違い

ここは公式文言だけではなく、公開仕様からの実務的な解釈も含みます(推定を含みます)。

Pencil の違いは「どこを起点にUIを作るか」です。

  • Figma中心の従来フロー: デザインツール側が主、実装は後段
  • prompt-to-code系SaaS: まずコードを出す、デザイン編集は補助
  • Pencil: デザイン面を持ちながら、最初からIDE・Git・MCP前提で運用する

つまり、Pencil は「デザインツール」でもありつつ、実態は「AI時代の設計データ層」に近いです。
この立ち位置が、単なる生成UIツールとの違いだと思います。

4. 欠点

現時点で公開されている注意点が、はっきりしています。

要するに、現段階は「高い可能性はあるが、プロダクト成熟度はこれから」です。

5. コスト

公式Pricingには、現時点で Pencil is currently free と明記されています。
ただし、実運用の総コストは次で決まります。

  • Cursor 側のプラン(機能や利用上限)
  • Claude Code / APIモデル利用料
  • チーム運用時のレビュー・調整工数

Pencil本体が無料でも、AI実行コストは別に見積もる必要があります。

6. 今後への期待

個人的に期待するのは次です。

  • auto-save / undo/redo の強化(まず作業の安全性)
  • エクスポート再現性の改善(デザインと実装の差分縮小)
  • CLIのheadless強化(CIやバッチ処理への組み込み)
  • 共同編集体験の改善(Git運用の摩擦低減)
  • ドキュメント整合性の継続改善

「AIで作れる」段階から「チームで壊れず回る」段階へ進めるかが分岐点です。

7. どういう人に向くのか

向いている人:

  • デザインと実装の往復を減らしたいアプリ/フロントエンド開発者
  • Figma一本化より、Git中心で変更管理したいチーム
  • Cursor / Claude Code を日常的に使っていて、UI試作速度を上げたい人

向きにくい人:

  • 完成度の高いリアルタイム共同編集を最優先する組織
  • 既存Figma運用(プラグイン資産含む)を崩したくない大規模チーム

8. 自分ならどう使うか

自分なら、次の順で使います。

  1. まず Pencil 上で画面構成を粗く作り、ブランド変数を先に固定する
  2. Claude CodeCursor からMCP経由で複数案を一気に作らせる
  3. スクリーンショット取得ツールで比較し、採用案だけを .pen とコードでコミットする
  4. 生成コードはあくまで土台と割り切り、アクセシビリティと状態管理は手で仕上げる
  5. 以後は「デザイン変更=PRで差分確認」の運用に寄せる

ポイントは、Pencil を「最終成果物を一発で出す魔法ツール」としてではなく、
「設計と実装のラリー回数を減らす中間レイヤー」として使うことです。

まとめ

Pencil は、Claude Code/Cursor時代に噛み合う「Design as Code」志向のツールです。
強みは明確ですが、現時点では欠点も明確です。
だからこそ、まずは小さく試し、無料のうちに運用適性を見極める のが最も合理的だと思います。

参考リンク(一次情報)

Discussion