「デザインツールはFigma一択」——ここ数年、そう言い切れる時期が続いていました。しかし、デザインデータをSaaSに預けきりにしていて本当に大丈夫なのか、デザイナーが作ったものがなぜ毎回コードに手作業で翻訳されるのか、という不満を抱えるチームは少なくありません。Penpot（ペンポット）は、まさにこの不満に正面から答える、オープンソースのデザイン・プロトタイピング基盤です。公式は自らを「the open-source design platform for teams that build digital products at scale」——大規模にデジタルプロダクトを作るチームのためのオープンソースなデザイン基盤——と位置づけています。GitHubで約54,800スター（2026年7月時点）を集め、Figma代替の本命として存在感を強めています。
まずは「Penpotがどんなツールなのか」を掴むために、公式のクイックスタート動画を見てみてください。ブラウザ上でデザインを作り、そのままコード（SVG/CSS/HTML）として扱える様子が、言葉より速く伝わります。
この記事を読むと、①Penpotで結局何ができるのか（ブラウザでも自己ホストでも動くデザイン・プロトタイピング環境を持てる）、②どんな課題を解決するのか（デザイン基盤の完全所有と、デザインとコードの断絶の解消）、③何を代替できるのか（データ所有とコード連携を重視するなら、Figma/SketchのようなSaaSデザインツールの代わりになりうる）が分かります。デザイナーにも開発者にも読めるよう、コードの羅列ではなく「画面と図」で説明します。デザインの「値」をチーム全体でどう一元管理するかで悩んでいる方は、まずデザインシステム構築ガイドを合わせて読むと、Penpotのデザイントークンが担う”単一の情報源”という位置づけが掴みやすくなります。
- ・Penpotはブラウザでも自己ホストでも動くオープンソースのデザイン・プロトタイピング基盤で、Figma/Sketchの代替として注目されている。
- ・最大の特徴はSVG/CSSなどWeb標準をネイティブに扱い、デザイントークンを"デザインとコードの単一の情報源"にできること。
- ・Inspectモードで実際に使えるSVG/CSS/HTMLを出力し、Open APIとMCPサーバーでdesign-to-codeのワークフローを自動化できる。
- ・自己ホストによりデザイン基盤を完全所有でき、コンプライアンスやガバナンスの要件に応えやすい。
- ・ライセンスはMPL-2.0。自己ホスト運用には相応の運用負担があり、Figmaとの機能同等性は過度に期待しない前提で検証したい。
1. Penpotとは：オープンソースの「デザイン・プロトタイピング基盤」
Penpotは、ブラウザの中でも、自社サーバーに自己ホストしても動く、オープンソースのデザインおよびプロトタイピングのプラットフォームです。開発は同名のPenpotチームによって進められ、コードベースの大半はClojure（バックエンドとClojureScriptによるフロントエンド）で書かれています。ひとことで言えば「自分たちで所有できるFigma代替」ですが、それだけに留まりません。
Penpotがユニークなのは、Web標準をそのまま設計言語として使う点です。多くのデザインツールは独自の内部フォーマットで図形を持ち、書き出しの段階で初めてCSSやSVGに”変換”します。Penpotは最初からSVG・CSS・HTML・JSONといったオープンな標準の上に立っているため、デザイナーが画面上で作ったものが、実装で使う形にそのまま近いという性質を持ちます。ここが「デザインとコードの断絶」を埋める思想の根っこにあります。
Penpotが立っている場所を整理すると、次の3つの性質を1つに束ねた点が新しいと言えます。
・オープンソースと自己ホスト：デザイン基盤そのものを自社で所有し、データの主権を握れる
・Web標準ネイティブ：SVG/CSSをそのまま扱うため、デザインが実装に地続きになる
・コードフレンドリーな設計：デザイントークン、Flex/Gridレイアウト、Open API、MCPサーバーで開発ワークフローに寄り添う
名前の”Pen”（ペン）と”pot”（器）が示すとおり、Penpotの発想は「デザインの道具と、その成果物を入れる器を、まるごと自分たちの手元に置く」ことにあります。これまでも、SaaSのデザインツールをプラグインで無理やり拡張したり、書き出したアセットを手作業でコードに落とし込んだりといった工夫はありました。しかしそれらは「便利だがデータは預けきり」「変換はできるが二重管理が残る」といった具合に、必ずどこかで妥協が生じます。Penpotが新しいのは、所有・Web標準・コード連携という要件を、オープンソースの単一の基盤で同時に満たす点です。「デザインツールを借りる」というより「デザイン基盤を持つ」感覚に近いと言えます。
- ・FigmaはSaaSとして"借りる"デザインツール。Penpotはオープンソースとして"持てる"デザイン基盤。
- ・「デザインを最初からWeb標準の上で作る」ことが、デザインとコードの断絶を埋めるPenpotの発明。
2. なぜ必要か：デザイン基盤の「所有」とデザイン⇄コードの断絶
Penpotが解決するのは、大きく2つの根深い問題です。デザイン基盤を他社に預けきる不安と、デザインとコードのあいだで毎回発生する翻訳コストです。
まず所有の問題から見ていきます。デザインデータは、プロダクトの意思決定そのものが詰まった資産です。それを外部のSaaSに預けきると、次のような懸念が現れます。
・データの置き場所を選べないため、業界や地域のコンプライアンス要件に合わせにくい
・価格やプラン変更の影響を一方的に受け、コストのコントロールが効きにくい
・ガバナンス上、社内のデザイン資産を自社管理下に置きたいのに置けない
・サービス側の仕様変更や提供終了のリスクを、自分たちでは回避できない
Penpotは自己ホストによって、この置き場所そのものを自分たちの手に取り戻します。データは自社のインフラに置かれ、アップデートのタイミングも自分たちで決められます。「デザイン基盤を所有する」という選択肢を、初めて現実的なコストで提供した——これがPenpotの一つ目の価値です。
もう一つが、デザインとコードの断絶です。多くの現場では、デザイナーが作った画面を、開発者が改めてコードに”翻訳”します。この翻訳の過程で、色や余白の値がずれたり、レイアウトの意図が失われたりします。
- ・デザイン側とコード側で色や余白の値を二重管理すると、片方の更新がもう片方に伝わらず、ずれが蓄積する。
- ・「デザインどおりに実装したはずなのに微妙に違う」の多くは、この翻訳ロスに起因する。人間が毎回翻訳する限り、この摩擦はゼロにならない。
Penpotは、この断絶を同じWeb標準の上に立つことで縮めます。デザイナーが使うレイアウトの仕組みが、開発者が実際に使うCSSのFlexboxやGridと同じ概念で作られているため、意図が失われにくいのです。さらにデザイントークンを”単一の情報源”として共有すれば、色や余白の値をデザインとコードで二重に持つ必要が減ります。
この問題は、プロダクトの規模が大きくなるほど深刻になります。画面数が増え、関わる人が増えるほど、翻訳のロスと二重管理のずれは指数的に膨らむからです。つまりチームが大きくなるほど、デザインとコードを地続きにする基盤の重要性が上がるという関係にあります。デザインとエンジニアリングの距離をどう縮めるかは、Claude Designと Figma/Canva/v0 比較でも触れられているテーマで、Penpotはそこに「オープンソースかつWeb標準ネイティブ」という独自の解を持ち込んでいます。
デザインからコードへの流れを図にすると、デザイントークンを中心に据えたときの「単一の情報源」の役割がよく見えます。
Penpot上の画面"] --> T["デザイントークン
単一の情報源"] T --> I["Inspectモード
SVG CSS HTML 出力"] I --> C["コード
実装リポジトリ"] T --> C C -->|"MCPで双方向"| D
この図の肝は、デザイントークンが真ん中に居座っていることです。色や余白の値は一度トークンとして定義され、デザインも実装もそのトークンを参照します。値そのものを両側に散らばせないので、片方を直せば両方に効きます。
3. Penpotの主な機能：コラボ・トークン・Inspect・API・MCP
Penpotの機能は「デザインを作り、共有し、実装につなぐ」という一連の流れを、Web標準の上でひととおり満たすように設計されています。上の図の7つの機能を、それぞれが「誰の・どんな困りごとを解決するのか」とセットで整理すると、次の表のようになります。機能名だけを覚えるより、この対応で見たほうが自分のチームに刺さるかどうかを判断しやすくなります。
| 機能 | 何ができる | どんな困りごとを解決するか |
|---|---|---|
| リアルタイム・コラボ | 複数人で同じファイルを同時編集 | 「今どこまで進んでいるか」の共有ロス。大人数でもデザインの現在地を一つに保てる |
| コンポーネント/バリアント | ボタンやカードを部品化し状態違いを管理 | 部品のコピペ増殖と修正漏れ。1か所直せば全画面に反映される |
| CSS Grid＋Flexレイアウト | 開発者と同じ概念でレスポンシブ設計 | 「デザインの意図が実装で崩れる」問題。作り方が実装と揃う |
| ネイティブ・デザイントークン | 色・余白・タイポを命名して共有 | デザインとコードの値の二重管理。単一の情報源にできる |
| Inspectモード | 選んだ要素のSVG/CSS/HTMLを取得 | 開発者が値を目視で写し取る手作業。翻訳がコピーになる |
| Open API＋プラグイン | 外部からデザインを読み書き・機能拡張 | 手作業のハンドオフ。ワークスペースをプログラム可能にする |
| MCPサーバー | AIがデザインを読み取り双方向連携 | 人手のdesign-to-code。AIにデザインを機械可読で渡せる |
表の右列を眺めると、7つの機能がバラバラの機能追加ではなく、すべて「作ったものをロスなく実装へ届ける」という一本の狙いに向いていることが分かります。以下、特に重要な3つを補足します。
ネイティブなデザイントークンは、後付けのプラグインではなく標準機能として組み込まれている点が肝心です。色・余白・タイポグラフィをトークンとして定義しておけば、デザインもコードも同じ名前を参照するので、「デザインとコードのあいだの単一の情報源」になります。
Inspectモードは、デザインを選ぶだけで、そのまま使えるSVG・CSS・HTMLを取り出せる機能です。開発者が定規で測るように値を目視で写し取る作業から解放されます。
MCPサーバーは、AIエージェントや開発ツールがデザインを読み取り、デザインとコードの「多方向のワークフロー」を駆動するための仕組みで、2026年の開発者向け機能として特に注目されています。
これらの機能に共通するのは、「デザイナーの成果物を、いかに実装へロスなく届けるか」という一貫した狙いです。コラボレーションで作った成果を、トークンとInspectモードで実装可能な形に落とし、APIとMCPで自動化まで伸ばす——この一本の線でつながっているのがPenpotの機能設計です。
とりわけ効くのが、Inspectモードで本物のSVG/CSS/HTMLが出てくることです。デザインが独自フォーマットで持たれている場合、書き出したコードはあくまで”近似”になりがちですが、PenpotはもともとWeb標準の上に立っているため、出力されるコードが実装で使う形に近くなります。「デザインが最初からコードに近い」ことの効果は、ハンドオフのたびに効いてくるのです。
- ・デザイントークン＋Flex/Gridで、デザイナーの作り方と開発者の実装の作り方が揃う。
- ・Open APIとMCPサーバーで、design-to-codeの自動化まで同じ基盤の中で伸ばせる。
4. 自己ホストとクラウド：Penpotの導入パターン
Penpotの導入には大きく2つの入口があります。Penpotが提供するクラウド版をそのまま使うか、自社インフラに自己ホストするかです。それぞれ向き不向きがあります。
クラウド版は、アカウントを作ればブラウザからすぐに使い始められます。インフラの準備が不要で、まず触ってみる、小さく試す、という段階に向いています。一方で自己ホストは、デザインデータを自社の管理下に置けるという最大のメリットがあります。コンプライアンスやガバナンスの要件が厳しい組織、データの置き場所を自分で決めたい組織は、こちらを選ぶことになります。
自己ホストはDockerを中心に提供され、公式は Docker のほか Kubernetes・Elestio などでのデプロイにも対応しています（penpot.app/self-host）。正確なdocker-composeファイルは公式サイト・公式ドキュメント（penpot.app / help.penpot.app）に用意されているため、まずはそちらを参照してください（本記事ではファイルの生URLは示しません。バージョンで内容が変わるためです）。公式手順に沿ってcomposeファイルを取得したうえで、標準的な起動は次のコマンドになります。
# 例（自己ホストの標準的な起動）：
# まず penpot.app / help.penpot.app の公式手順に従い
# 公式の docker-compose.yaml を取得・配置してから実行する
docker compose -p penpot up -d
上記はあくまで起動の一例です。実際にはデータベース、ストレージ、認証（メール・OAuth等）の設定を環境変数で与える必要があり、その具体的な値や必須項目は公式ドキュメントに従うのが安全です。自己ホストで気をつけたいのは、起動そのものよりもその後の運用です。
- ・バックアップ、アップデート適用、認証連携、ストレージ管理といった継続的な運用が発生する。「立てて終わり」ではない。
- ・ライセンスはMPL-2.0。Penpot本体を改変する場合は該当ファイルのソース公開義務が生じうるため、再配布・改変を伴う利用では条項を確認する。
- ・小さく検証するならクラウド版から始め、要件が固まってから自己ホストへ移すのが現実的。
自己ホストとクラウドの構成の違いを図にすると、データがどこに置かれるかの差がはっきりします。
チームメンバー"] --> P1["Penpot 提供のサーバー"] P1 --> DB1["Penpot 管理のデータ"] end subgraph Self["自己ホスト版"] U2["ブラウザ
チームメンバー"] --> P2["自社サーバー
docker compose"] P2 --> DB2["自社管理のデータ
DB ストレージ"] end
図の左右で違うのは、最終的にデータが誰の管理下に置かれるかです。クラウド版はPenpot側、自己ホスト版は自社側。この一点が、コンプライアンスやガバナンスを重視する組織にとっての決定的な分かれ目になります。「試すのはクラウド、所有するなら自己ホスト」という二段構えで導入できるのがPenpotの現実的な使い方です。
5. デザイントークンとInspectモード：デザイン⇄コードを埋める中核
Penpotの思想がもっとも具体的に現れるのが、デザイントークンとInspectモードです。この2つが、デザインとコードの断絶を埋める中核になります。
デザイントークンは、色・余白・タイポグラフィといった値に名前を付けて、デザインと実装で共有する仕組みです。たとえば「プライマリカラー」という名前に具体的な色を結びつけておけば、デザイン側でも実装側でも、その名前を通じて同じ値を参照できます。ポイントは、この値が一箇所にしか書かれていないこと。デザイン側で「プライマリカラー」を少し明るくすれば、その名前を参照している実装側にも同じ変更が伝わります。色コードをデザインファイルとCSSに二重で書き、片方だけ直して食い違う——という典型的な事故を、構造的に防げます。
トークンを使う場合と使わない場合で、値の管理がどう変わるかを整理すると次のようになります。
| デザイントークンを使わない | デザイントークンを使う（Penpot） | |
|---|---|---|
| 色や余白の値 | デザインファイルとCSSに別々に書く | 名前を1か所に定義し両方が参照 |
| 値を変えたいとき | 両方を手で直す（片方忘れがち） | 定義を1回直せば両方に反映 |
| ずれの原因 | 二重管理・写し間違い | 参照が同じなので構造的に起きにくい |
| 実装への伝わり方 | 人が目視で写し取る | Inspectの出力にそのまま流れる |
もう一つがInspectモードです。上の図のように、デザイン上の要素を選ぶだけで、そのまま使えるSVG・CSS・HTMLが取り出せます。開発者が定規で測るように値を目視で写し取る作業がなくなり、しかも出力される値は先ほどのデザイントークンに紐づいています。つまり「トークンで定義した値が、Inspectで出力されるコードにそのまま流れてくる」という一貫性が保たれます。
SVGについても同様に、ベクター図形はそのままSVGとして取り出せます。PenpotがもともとWeb標準の上に立っているからこそ、この出力が”変換された近似”ではなく、実装で使う形に近くなる——ここがFigma/SketchのようなSaaSツールに対するPenpotの構造的な差別化です。デザインが最初からコードの言葉（SVG/CSS）で作られているから、ハンドオフが翻訳ではなく受け渡しになるのです。
とはいえ、Inspectモードやトークンの出力の正確な形式やエクスポート手順は更新が入りやすいため、実際に触るときは必ずPenpotのドキュメントで最新の仕様を確認してください。
6. Figmaとの比較とMCPによるdesign-to-code
読者がいちばん知りたいのは「Penpotは結局、何の代わりになるのか」でしょう。答えははっきりしていて、Penpotが置き換えを狙うのはFigmaやSketchのような、UIデザインとプロトタイピングを担うSaaSデザインツールです。とりわけFigmaは事実上の業界標準になっているため、ここでは主にFigmaと比べます。ただし後述のとおり「全部を置き換える」ものではなく、データ所有・Web標準・コード連携という軸で置き換えたいチームに刺さる、という理解が正確です。
では、PenpotはFigmaとどう違うのか。よく比較される観点を表で整理します。フェアに見るため、Figmaが優位な点も併記します。
| 観点 | Penpot | Figma |
|---|---|---|
| ライセンス／提供形態 | オープンソース(MPL-2.0)・自己ホスト可 | プロプライエタリなSaaS |
| データ所有 | 自己ホストで完全所有できる | Figma側のインフラに保管 |
| Web標準 | SVG/CSSをネイティブに扱う | 独自フォーマット中心（書き出しで変換） |
| デザイントークン | ネイティブ機能 | プラグイン等で対応（進化中） |
| レイアウト | CSS Grid＋Flexレイアウト | 独自のオートレイアウト等 |
| コスト | 無料／自己ホストの運用コスト | サブスクリプション |
| プラグイン・コミュニティ資産 | 成長中 | 大規模で成熟（優位） |
| 磨き込み・エコシステム | 発展途上な面もある | 全体に洗練（優位） |
要するに、データ所有とWeb標準・コード連携で選ぶならPenpot、プラグイン資産やエコシステムの成熟で選ぶならFigma、という住み分けです。Penpotはオープンソースであることと、SVG/CSSをネイティブに扱う点で明確な独自性を持ちますが、プラグインコミュニティの規模や細部の磨き込みではFigmaが先行しています。機能の一対一の同等性を過度に期待せず、自分たちの要件で検証するのが健全です。
そしてPenpotがもっとも先進的なのが、MCPサーバーによるdesign-to-codeの自動化です。MCPサーバーは、AIエージェントや開発ツールがPenpotのデザインを読み取り、デザインとコードのあいだで多方向のワークフローを組むための入口です。これは「人間がデザインをコードに翻訳する」だけでなく、「AIがデザインを参照してコードを生成し、必要ならコード側の文脈をデザインに戻す」という双方向の流れを可能にします。
コード生成ツール"] -->|"MCPで読み取り"| M["Penpot MCPサーバー"] M --> D["Penpotのデザイン
SVG CSS トークン"] D -->|"デザイン情報を渡す"| M M -->|"design to code"| A A -->|"生成コード"| R["実装リポジトリ"] R -.->|"変更を文脈に反映"| M
この仕組みが効くのは、たとえば次のようなパターンです。①デザインからのコード生成——AIエージェントがMCP経由でデザインとトークンを読み取り、実装コードの雛形を生成する。②一貫性チェック——実装側の値がデザイントークンとずれていないかを、デザインを参照しながら検証する。③反復ループ——生成したコードのフィードバックをデザイン文脈に戻し、デザインとコードの往復を短くする。いずれも「人間が毎回手作業で翻訳する」代わりに、デザインとコードを機械可読な同じ基盤の上で扱える点が肝です。
PenpotがSVG/CSS/HTML/JSONといったオープン標準の上に立っているからこそ、AIやツールがデザインを”機械が読める形”で扱える、という点も見逃せません。独自フォーマットに閉じたツールでは、この読み取りにいちいち変換の壁が挟まります。「デザインが最初からWeb標準＝機械可読」だから、AI駆動のワークフローに素直に載るのがPenpotの強みです。ただしMCPサーバーは比較的新しい機能であり、正確な対応範囲や設定方法は公式ドキュメントで最新の状態を確認してください。
- ・プラグイン資産やエコシステムの成熟を最優先 → Figmaが無難。
- ・データ所有・Web標準・コード連携を重視 → Penpotが刺さる。
- ・AI駆動のdesign-to-codeを試したい → PenpotのMCPサーバーを検討。
なお、Figma以外のオープンソースなデザイン系ツールと合わせて検討したい場合は、オープンソースのデザインツール open-designも参考になります。所有とコード連携という軸で、選択肢を横並びで見比べておくと判断がぶれません。
7. Penpotの導入判断：向いている人・注意点（MPL-2.0と運用）
最後に、導入すべきかの判断材料を整理します。
Penpotが向いている人
・デザインデータを自己ホストで完全所有したい組織
・コンプライアンスやガバナンスの要件が厳しく、データの置き場所を自分で決めたい
・コードに近いワークフローを好む開発者・プロダクトチーム
・デザイントークンやFlex/Gridでデザインと実装を地続きにしたい
・将来的にMCPによるAI駆動のdesign-to-codeまで視野に入れている
慎重に判断すべきケース
・Figmaのプラグイン資産やコミュニティに強く依存している（移行コストが大きい）
・細部の磨き込みや特定機能の同等性が絶対条件（過度な期待は禁物）
・自己ホストの運用リソースを割けない（この場合はクラウド版から）
特に注意したいのがライセンスと運用です。PenpotのライセンスはMPL-2.0（Mozilla Public License 2.0）で、ファイル単位のコピーレフトです。個人利用や社内利用、自己ホストでの利用では通常問題になりませんが、Penpot本体を改変して再配布するような場合には、改変したファイルのソース公開義務が生じうるため、条項の確認が必要です。MPLはAGPLほど強いコピーレフトではなく、独自コードと組み合わせる自由度は比較的高いライセンスです。
もう一つが自己ホストの運用負担です。Dockerで立てること自体は難しくありませんが、本番運用ではバックアップ・アップデート・認証連携・ストレージ管理といった継続的な作業が発生します。「立てて終わり」ではないことを見込んで、運用体制を用意しておく必要があります。
- ・MPL-2.0の影響範囲を確認する（本体を改変・再配布する場合は特に）。
- ・自己ホストは運用負担を伴う。バックアップ・アップデート・認証・ストレージの体制を用意する。
- ・Figmaとの機能同等性を過度に期待しない。要件を洗い出し、まずクラウド版で検証してから移行する。
補足として、Penpotは約54,800スターと存在感を強めており、最新バージョンは2.16.2（2026年7月時点）と、メジャーバージョン2系で活発に開発が進んでいます。オープンなissueも600件超あり、機能追加や改善のペースが速い一方で、細部の仕様が変わる可能性もあります。とはいえ「デザイン基盤を自社で所有し、デザインとコードを地続きにする」というニーズ自体は今後さらに広がっていくため、この領域のオープンソースの本命を早めに触っておく価値は十分あります。
まとめ
Penpotは、「デザインツールはSaaSで借りるもの」という常識に対して、「デザイン基盤はオープンソースで持てる」という選択肢を突きつける存在です。単なるFigma代替ではなく、Web標準ネイティブとデザイントークンという一点で、デザインとコードの断絶に正面から向き合っています。
- ・Penpotはブラウザでも自己ホストでも動く、オープンソースのデザイン・プロトタイピング基盤。
- ・SVG/CSSをネイティブに扱い、デザイントークンを"デザインとコードの単一の情報源"にできる。
- ・InspectモードでSVG/CSS/HTMLを出力し、Open APIとMCPサーバーでdesign-to-codeを自動化できる。
- ・自己ホストでデザイン基盤を完全所有でき、コンプライアンスやガバナンスに応えやすい。
- ・ライセンスはMPL-2.0。運用負担とFigmaとの機能同等性を見込んだうえで、クラウド版から検証するのが現実的。
デザインデータの所有権や、デザインとコードの毎回の翻訳コストに心当たりがあるなら、まずはクラウド版のPenpotで小さく触り、手応えがあれば公式ドキュメント（penpot.app / help.penpot.app）の手順に沿って docker compose -p penpot up -d で自己ホストを試してみてください。デザインの値をチーム全体でどう一元化するかについてはデザインシステム構築ガイドが、AI時代のデザインツールの立ち位置についてはClaude Designと Figma/Canva/v0 比較が参考になります。
参照ソース
・penpot/penpot (GitHub) — 公式リポジトリ。README・リリース・機能一覧・ライセンス（MPL-2.0）の一次ソース。
・Penpot 公式サイト — 製品概要・機能・自己ホストとクラウドの導入案内の公式情報。
・Penpot ヘルプ・ドキュメント — 自己ホスト手順・デザイントークン・Inspect・API/MCPの公式ドキュメント。
