「デザインツールはFigma一択」——ここ数年、そう言い切れる時期が続いていました。しかし、デザインデータをSaaSに預けきりにしていて本当に大丈夫なのか、デザイナーが作ったものがなぜ毎回コードに手作業で翻訳されるのか、という不満を抱えるチームは少なくありません。Penpot（ペンポット）は、まさにこの不満に正面から答える、オープンソースのデザイン・プロトタイピング基盤です。公式は自らを「the open-source design platform for teams that build digital products at scale」——大規模にデジタルプロダクトを作るチームのためのオープンソースなデザイン基盤——と位置づけています。GitHubで約54,800スター（2026年7月時点）を集め、Figma代替の本命として存在感を強めています。

この記事を読むと、①Penpotで結局何ができるのか（ブラウザでも自己ホストでも動くデザイン・プロトタイピング環境を持てる）、②どんな課題を解決するのか（デザイン基盤の完全所有と、デザインとコードの断絶の解消）、③何を代替できるのか（データ所有とコード連携を重視するなら、FigmaのようなSaaSデザインツールの代わりになりうる）が分かります。デザインの「値」をチーム全体でどう一元管理するかで悩んでいる方は、まずデザインシステム構築ガイドを合わせて読むと、Penpotのデザイントークンが担う”単一の情報源”という位置づけが掴みやすくなります。

Penpot：オープンソースのデザイン基盤。ブラウザまたは自己ホストで動き、デザイントークンとSVG/CSSのWeb標準でデザインとコードを橋渡しする
Penpotはデザインとコードを同じWeb標準（SVG/CSS）の上で扱い、デザイントークンを"単一の情報源"として両者を橋渡しする。
この記事のポイント
  • ・Penpotはブラウザでも自己ホストでも動くオープンソースのデザイン・プロトタイピング基盤で、Figma代替として注目されている。
  • ・最大の特徴はSVG/CSSなどWeb標準をネイティブに扱い、デザイントークンを"デザインとコードの単一の情報源"にできること。
  • ・Inspectモードで実際に使えるSVG/CSS/HTMLを出力し、Open APIとMCPサーバーでdesign-to-codeのワークフローを自動化できる。
  • ・自己ホストによりデザイン基盤を完全所有でき、コンプライアンスやガバナンスの要件に応えやすい。
  • ・ライセンスはMPL-2.0。自己ホスト運用には相応の運用負担があり、Figmaとの機能同等性は過度に期待しない前提で検証したい。

1. Penpotとは：オープンソースの「デザイン・プロトタイピング基盤」

Penpotはデザイン→プロトタイプ→Dev/Inspect→コードを地続きにする自己ホスト可能なOSSデザイン基盤。Figma（SaaS）に対しデータ所有・Web標準準拠・API/MCP自動化で対抗する
Penpotはデザインからコードまでを地続きにする自己ホスト可能なOSSデザイン基盤。データ所有・Web標準準拠・API/MCP連携が「Figma代替の本命」と呼ばれる理由。

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標準ネイティブ」という独自の解を持ち込んでいます。

デザインからコードへの流れを図にすると、デザイントークンを中心に据えたときの「単一の情報源」の役割がよく見えます。

flowchart LR D["デザイン
Penpot上の画面"] --> T["デザイントークン
単一の情報源"] T --> I["Inspectモード
SVG CSS HTML 出力"] I --> C["コード
実装リポジトリ"] T --> C C -->|"MCPで双方向"| D

この図の肝は、デザイントークンが真ん中に居座っていることです。色や余白の値は一度トークンとして定義され、デザインも実装もそのトークンを参照します。値そのものを両側に散らばせないので、片方を直せば両方に効きます。

3. Penpotの主な機能：コラボ・トークン・Inspect・API・MCP

Penpotの主要機能：リアルタイムコラボ・デザイントークン・Inspectモード・REST API・Penpot MCP・Flex/Gridレイアウト
Penpotの主な機能。作る（コラボ・レイアウト）→共有（トークン）→実装（Inspect・API・MCP）までを1つの基盤でつなぐ。

Penpotの機能は「デザインを作り、共有し、実装につなぐ」という一連の流れを、Web標準の上でひととおり満たすように設計されています。主要機能を整理します。

リアルタイム・コラボレーション：複数のメンバーが同じファイルを同時に編集できます。大規模なチームでも、デザインの現在地を全員で共有しながら進められます。

コンポーネントとバリアント：再利用可能なコンポーネントと、その状態違い（バリアント）を管理できます。ボタンやカードのような部品を一元管理し、デザインシステムの土台を作れます。

レスポンシブ・デザイン（CSS Grid ＋ Flexレイアウト）：開発者が実際に使うCSSのGridとFlexboxと同じ概念でレイアウトを組めます。画面幅に応じた変化も、実装と同じ発想で設計できます。

ネイティブなデザイントークン：色・余白・タイポグラフィなどをトークンとして定義し、「デザインとコードのあいだの単一の情報源」にできます。後付けのプラグインではなく、標準機能として組み込まれている点が重要です。

Inspectモード：デザインを選ぶと、そのまま使えるSVG・CSS・HTMLのコードを取り出せます。開発者が値を目視で写し取る必要がありません。

Open APIとプラグインシステム：外部からデザインデータを読み書きするAPIと、機能を拡張するプラグインの仕組みを持ちます。

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-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本体を改変する場合は該当ファイルのソース公開義務が生じうるため、再配布・改変を伴う利用では条項を確認する。
  • ・小さく検証するならクラウド版から始め、要件が固まってから自己ホストへ移すのが現実的。

自己ホストとクラウドの構成の違いを図にすると、データがどこに置かれるかの差がはっきりします。

flowchart TD subgraph Cloud["クラウド版"] U1["ブラウザ
チームメンバー"] --> P1["Penpot 提供のサーバー"] P1 --> DB1["Penpot 管理のデータ"] end subgraph Self["自己ホスト版"] U2["ブラウザ
チームメンバー"] --> P2["自社サーバー
docker compose"] P2 --> DB2["自社管理のデータ
DB ストレージ"] end

図の左右で違うのは、最終的にデータが誰の管理下に置かれるかです。クラウド版はPenpot側、自己ホスト版は自社側。この一点が、コンプライアンスやガバナンスを重視する組織にとっての決定的な分かれ目になります。「試すのはクラウド、所有するなら自己ホスト」という二段構えで導入できるのがPenpotの現実的な使い方です。

5. デザイントークンとInspectモード：デザイン⇄コードを埋める中核

デザイン→デザイントークン（色・余白・タイポを命名し共有）→Inspectモード（SVG/CSS/HTML出力）→コードへ、値を二重管理せず流す
デザイントークンで定義した値がInspectの出力にそのまま流れ、デザインとコードの断絶を埋める。

Penpotの思想がもっとも具体的に現れるのが、デザイントークンとInspectモードです。この2つが、デザインとコードの断絶を埋める中核になります。

デザイントークンは、色・余白・タイポグラフィといった値に名前を付けて、デザインと実装で共有する仕組みです。たとえば「プライマリカラー」という名前に具体的な色コードを結びつけておけば、デザイン側でも実装側でも、その名前を通じて同じ値を参照できます。以下はあくまで説明のためのデザイントークンの例（実際のエクスポート形式は公式ドキュメントを参照）です。

// 例（説明用のデザイントークンのイメージ。実際の形式は penpot.app のドキュメント参照）
{
  "color": {
    "primary":   { "value": "#4A5CFF", "type": "color" },
    "surface":   { "value": "#0F1220", "type": "color" }
  },
  "spacing": {
    "sm": { "value": "8px",  "type": "spacing" },
    "md": { "value": "16px", "type": "spacing" }
  },
  "typography": {
    "heading": { "value": "600 24px/1.4 'Inter'", "type": "typography" }
  }
}

ポイントは、この値が一箇所にしか書かれていないことです。デザイン側で「プライマリカラー」を少し明るくすれば、その名前を参照している実装側にも同じ変更が伝わります。色コードをデザインファイルとCSSに二重で書き、片方だけ直して食い違う——という典型的な事故を、構造的に防げます。

もう一つがInspectモードです。デザイン上の要素を選ぶと、そのまま使えるSVG・CSS・HTMLが取り出せます。以下はInspectモードが返しうるCSSのイメージ（実際の出力は要素やバージョンで変わります）です。

/* 例（Inspectモードが返すCSSのイメージ。実際の出力は要素により異なる） */
.card {
  display: flex;
  flex-direction: column;
  gap: 16px;             /* spacing.md */
  padding: 16px;         /* spacing.md */
  background: #0F1220;   /* color.surface */
  border-radius: 8px;
}
.card__title {
  font: 600 24px/1.4 'Inter';  /* typography.heading */
  color: #4A5CFF;              /* color.primary */
}

このCSSが効くのは、開発者が値を目視で写し取る作業から解放されるからです。しかも出力に現れる16pxや#0F1220は、先ほどのデザイントークンに紐づいた値です。つまり「トークンで定義した値が、Inspectで出力されるコードにそのまま流れてくる」という一貫性が保たれます。

SVGについても同様に、ベクター図形はそのままSVGとして取り出せます。PenpotがもともとWeb標準の上に立っているからこそ、この出力が”変換された近似”ではなく、実装で使う形に近くなる——ここがFigmaのようなSaaSツールに対するPenpotの構造的な差別化です。デザインが最初からコードの言葉（SVG/CSS）で作られているから、ハンドオフが翻訳ではなく受け渡しになるのです。

とはいえ、Inspectモードやトークンの出力の正確な形式やエクスポート手順は更新が入りやすいため、実装に組み込む際は必ずPenpotのドキュメントで最新の仕様を確認してください。ここで示したコードは、あくまで考え方を掴むためのイメージです。

6. Figmaとの比較とMCPによるdesign-to-code

では、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がデザインを参照してコードを生成し、必要ならコード側の文脈をデザインに戻す」という双方向の流れを可能にします。

flowchart TD A["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が向いている人と、自己ホストの運用コストなど慎重に判断すべき注意点の比較
Penpotの導入判断。データ所有やコード連携を重視するなら有力だが、自己ホストの運用コストは事前に見積もりたい。

最後に、導入すべきかの判断材料を整理します。

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の公式ドキュメント。