LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

Penpotとは？OSSのデザインコラボ・プロトタイピングツール

Penpotとは、UIデザインとプロトタイピングをブラウザ上で行えるオープンソースのデザインプラットフォームです。公式サイトは「Penpot is the open-source design platform for teams that build digital products at scale」と説明しており、複数人が同時に編集できるコラボレーション機能を備えています^*2。GitHub公式リポジトリは2026年7月時点で57.1kのスターを獲得しており、Mozilla Public License 2.0（MPL-2.0）のもとで開発が続けられています^*7。

デザインツールの多くはSaaS型で提供されており、デザインファイルはベンダーのクラウド上に置かれる仕組みが一般的です。Penpotはこの前提を変え、SVG・CSS・HTML・JSONといったオープン標準の上に構築されたツールで^*2、自社が管理するサーバー上でインスタンスを丸ごと運用できます。公式サイトは、セルフホストによって「full ownership of your design infrastructure」を実現できると述べており^*1、デザインデータの保管場所を自社の管理下に置きたい企業にとって選択肢になり得るでしょう。

機能面では、デザイントークン・コンポーネント・バリアントを備え、デザインシステムの単一の情報源（single source of truth）として使う設計になっています^*2。複数人での同時編集や、デザインからコードへの橋渡しを意識した機能も用意されており^*2、Figmaで行ってきた作業をブラウザ上でそのまま代替できる範囲は広いと言えます。ただし、セルフホスト運用にはインフラの構築・維持という別の負担が発生する点は見落とせません。

デザイン資産を自社サーバーで管理する必要性

受託開発やSI案件では、発注元企業のNDA（秘密保持契約）や社内セキュリティ基準により、UIデザインデータを外部のSaaSサーバーへ置けないという制約が課される場合があります。金融・官公庁関連の案件や、開発中の新規サービスの意匠情報を扱う現場では、こうした制約が特に厳格になりやすい傾向があるでしょう。

Penpotをセルフホストで構築すれば、デザインファイル・コメント・バージョン履歴といったデータは、自社が用意したサーバーの中だけで完結します。前述のとおり公式サイトも自社インフラでの所有を運用上の利点として挙げており^*1、情報システム部門やデザイン部門が、外部ベンダーのクラウド仕様に依存せずにアクセス権限やネットワーク経路を自社ポリシーで統制できる点が実務上の意味を持ちます。一方で、この統制を実現するにはDocker運用・認証設計・バックアップ体制の整備が前提となり、構築と運用を誰が担うかという判断が新たな論点になるでしょう。

Docker Composeで構築する標準的な導入手順

公式ドキュメントは、Dockerを使ったセルフホストについて「Docker and Docker Compose, basic DNS management, and proxy configuration」の知識が必要になると案内しています^*3。導入手順自体はシンプルで、まず公式リポジトリからdocker-compose.yamlを取得します^*4。

wget https://raw.githubusercontent.com/penpot/penpot/main/docker/images/docker-compose.yaml
docker compose -p penpot -f docker-compose.yaml up -d

このコマンドを実行すると、公式ドキュメントの表現では「At the end it will start listening on http://localhost:9001」の状態になり^*4、ブラウザからアクセスできるようになります。バージョンを固定したい場合は、起動前にPENPOT_VERSION環境変数を指定する運用も案内されています^*4。

クラウド版とセルフホスト版の機能差については、公式ドキュメントが「The experience stays the same, whether you use Penpot in the cloud or self-hosted」と明記しており^*3、操作感自体はどちらを選んでも大きくは変わらない設計です。ただし、DNS設定やリバースプロキシ、HTTPS化は自社で担う工程になるため、社内にDocker運用の経験者がいるかどうかが最初の分かれ目になります。

フロントエンド・バックエンド・エクスポーターの構成サービス

公式のdocker-compose.yamlは、7つのサービスで構成されています^*6。penpot-frontendはポート9001番でブラウザ向けの画面を提供し、penpot-backendが認証・データ処理などの業務ロジックを担当します^*6。penpot-exporterはPDF・PNGなどへの書き出し処理を受け持ち、penpot-mcpはAI駆動のワークフローや自動化と連携するためのMCPサーバーです^*2*6。

データベースにはpenpot-postgresが使われ、公式ドキュメントは「Penpot only supports PostgreSQL and we highly recommend >=13 version」と明記しています^*5。キャッシュ・セッション管理にはRedis互換のpenpot-valkeyが割り当てられ、開発・検証用にメールを画面上で確認できるpenpot-mailcatch（ポート1080番）も同梱されています^*6。実運用では、このmailcatchを本番のSMTP設定に置き換える判断が必要になります。

公開URL・認証・SMTPなど主要な環境変数設定

社外のユーザーにPenpotを公開する場合、公式ドキュメントはPENPOT_PUBLIC_URI環境変数の設定が必要と案内しています^*5。この値はフロントエンド・バックエンド・エクスポーターの全サービスで揃える必要があり^*5、設定を誤るとアセットの参照先がずれるといった不具合につながりかねません。

セッションや招待リンクの元になるマスターキーはPENPOT_SECRET_KEYで指定し、公式ドキュメントは「python3 -c “import secrets; print(secrets.token_urlsafe(64))”」による生成を例示しています^*5。メール送信は既定でsmtpフラグが無効になっており、有効化しない限りメール本文はコンソールに出力されるだけの状態です^*5。招待メールを使ってメンバーを追加する運用を想定する場合は、PENPOT_FLAGSにenable-smtpを加えたうえで、SMTPホスト・ポート・認証情報を設定する工程が欠かせません^*5。

認証方式は、既定のメール・パスワード認証に加え、Google・GitHub・GitLab等のOAuthプロバイダー、汎用のOpenID Connect（OIDC）、LDAPに対応します^*5。社内のSSO基盤と連携させたい情報システム部門にとっては、これらの選択肢があること自体が構成の柔軟性につながります。HTTPS化していない検証環境ではdisable-secure-session-cookiesフラグでCookie保護を緩められますが、公式ドキュメントは「This is a configuration NOT recommended for production environments」と注意を促しています^*5。本番環境ではHTTPS化を前提とした構成にする必要があります。

Dockerボリュームによるバックアップ運用

公式ドキュメントは、標準のdocker-compose構成で使われるボリュームについて「there are two volumes used: one for the Postgres database and another one for the assets uploaded by your users (images and svg clips)」と説明しています^*4。デザインデータの実体は、この2つのボリュームに保持される仕組みです。

ボリューム内のデータフォルダを直接コピーする方法は推奨されておらず、公式ドキュメントは「Docker provides you a volume backup procedure, that uses a temporary container to mount one or more volumes, and copy their data to an archive file」という、一時コンテナ経由でアーカイブ化する手順を案内しています^*4。Docker Desktopを使う環境では、この作業を補助する拡張機能も用意されています^*4。

アップグレード時は、docker compose pullで新しいイメージを取得したうえでdocker compose upにより再起動する流れになります^*4。旧バージョンからのマイグレーションは自動で実行されますが、公式ドキュメントはデータ量が多い場合に数分を要すると案内しており^*4、業務データを扱う以上、更新前のボリュームバックアップを運用ルールとして固定しておくことが望ましいでしょう。

セルフホスト内製と外注委託のコスト構造比較

セルフホストによる内製構築と、外部パートナーへの委託では、費用構造・必要スキル・リスク対応の重心が異なります。以下の表に主な違いを整理しました。

内製構築に必要なスキルと外注との違い

Docker運用・認証設計・バックアップ運用に求められる専門知識

Penpotを内製で構築・運用する場合、求められる専門知識は複数分野にまたがります。Dockerコンテナの運用とネットワーク・DNS管理、PENPOT_PUBLIC_URIやPENPOT_SECRET_KEYといった環境変数の設計、OIDC・LDAPを使う場合の認証連携、Dockerボリュームを使ったバックアップ運用がその内容です。自社の情報システム部門だけでこれらを完結させるには、複数の担当者が連携する体制を整える必要があるでしょう。

判断を先延ばしにしたまま自己流で構築を進めると、HTTPS化が後回しになったままdisable-secure-session-cookiesを本番環境で使い続けるといった問題に、後から気づくケースが生じます。バージョン間のマイグレーション挙動を把握しないまま運用を続けると、いざアップグレードが必要な場面で対応に時間がかかる失敗にもつながりかねません^*4。

専門パートナーに委託した場合の違い

専門パートナーに依頼すると、Docker環境の構築からリバースプロキシ・HTTPS化、SMTP・OIDC等の認証設定、バックアップ設計、バージョンアップ時の動作検証まで一連の工程を任せられます。自社では構成検討や動作検証だけで時間がかかる場面でも、複数のセルフホスト型ツールを扱ってきた知見を活用すれば、稼働までの期間を圧縮しやすくなります。内製と外注のどちらを選ぶ場合でも、まずは自社のセキュリティ要件と運用体制の整理が出発点と言えるでしょう。

まとめ：Penpotセルフホスト活用の3つの判断軸

本稿ではPenpotの機能とセルフホスト構築の要点を、公式ドキュメントとGitHubリポジトリの情報に基づいて整理しました。要点は次の3つに集約されるでしょう。第一に、UIデザインとプロトタイピングをブラウザ上で行えるPenpotはMPL-2.0のOSSであり、Docker Composeを使えばワンコマンドで環境を起動できます^*4*7。第二に、受託開発や機密案件でデザイン資産を外部SaaSに置けない企業にとって、セルフホストは自社サーバー内でのデータ保有を実現する選択肢になり得ます^*1。第三に、PENPOT_PUBLIC_URIやPENPOT_SECRET_KEYといった環境変数設計、認証連携、バックアップ運用には専門知識が必要であり、構築・運用の判断と実行は外部委託によってリスクを抑えやすくなります^*5。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Penpot公式サイト「Self-Host Penpot: Deploy it anywhere」（https://penpot.app/self-host）
2. *2　出典：Penpot公式GitHubリポジトリ「README」（https://github.com/penpot/penpot）
3. *3　出典：Penpot公式ドキュメント「1. Self-hosting Guide」（https://help.penpot.app/technical-guide/getting-started/）
4. *4　出典：Penpot公式ドキュメント「1.3 Install with Docker」（https://help.penpot.app/technical-guide/getting-started/docker/）
5. *5　出典：Penpot公式ドキュメント「Configuration」（https://help.penpot.app/technical-guide/configuration/）
6. *6　出典：Penpot公式GitHubリポジトリ「docker-compose.yaml」（https://raw.githubusercontent.com/penpot/penpot/main/docker/images/docker-compose.yaml）
7. *7　出典：Penpot公式GitHubリポジトリ「LICENSE」（https://github.com/penpot/penpot/blob/main/LICENSE）

Tweet