Penpotを「ただの描画ツール」にするな：大規模組織におけるデザインインフラとしての極限運用術
多くのチームがPenpotを「Figmaの代替品」として導入し、その直後に運用という名の泥沼に沈む。なぜか？ 「コンポーネントの管理」をデザインチームの作業領域だと勘違いしているからだ。
Penpotは、ブラウザベースのオープンソース・プラットフォームであるという点で、他のプロプライエタリなツールとは一線を画す。我々エンジニアにとって、それは「Gitのリポジトリ管理」や「CI/CDパイプライン」と同じレイヤーで語るべきインフラストラクチャであることを意味する。
本稿では、Penpotを大規模組織のスケールに耐えうる「デザイン・バックエンド」として定義し、その統治（ガバナンス）と最適化の極致を解説する。
—
1. 階層構造の再定義：Workspaceは「プロジェクト」ではなく「デリバリー単位」で切れ
Penpotの階層構造を漫然と作ると、権限管理は必ず破綻する。大規模チームにおける鉄則は、「Workspace = 権限境界」かつ「Team = 責務分離」とすることだ。
- Workspace (L1): 組織の事業単位（例: `Core-Platform`, `Consumer-App`, `Internal-Tools`）
- Team (L2): 役割ベース（例: `Design-System-Core`, `UI-Component-Library`, `External-Contractors`）
- Project (L3): 機能またはリリースサイクル（例: `Sprint-24-Q3`, `Auth-Refactor`）
権限管理の極意
外部委託メンバー（コントラクター）を入れる際、Workspace全体を見せるのは愚策だ。`External-Contractors` という独立したTeamを作成し、`Viewer` 権限で必要なProjectのみを共有する。「最小権限の原則」をUIデザインのレベルで強制せよ。
—
2. APIによる「デザイン・インフラ」の自動構成
Penpotの最大の強みは、API経由で「ファイル構造をコードとして制御できる」点にある。手動でプロジェクトを作る時代は終わった。GitHub ActionsやGitLab CIからAPIを叩き、新しいプロジェクトが立ち上がった瞬間に、CI経由でテンプレートファイルを流し込むのだ。
独自CLIによるプロジェクト初期化（Python概念コード）
import requests
import os
Penpot APIを叩くためのセキュアなラッパー
class PenpotInfraManager:
def __init__(self, token, api_url):
self.headers = {“Authorization”: f”Token {token}”}
self.base_url = api_url
def create_project(self, workspace_id, name):
# プロジェクト作成後のIDを取得し、後続のCI/CDで利用
endpoint = f”{self.base_url}/api/v1/workspaces/{workspace_id}/projects”
payload = {“name”: name}
response = requests.post(endpoint, json=payload, headers=self.headers)
return response.json()[‘id’]
運用フロー:
新規スプリント開始時にCIがトリガーされ、テンプレートが自動生成される
manager = PenpotInfraManager(os.environ[‘PENPOT_TOKEN’], “https://your-penpot-instance.com”)
project_id = manager.create_project(“workspace-uuid-123”, “Sprint-2024-Q4″)
print(f”Provisioned design environment for project: {project_id}”)
—
3. パフォーマンスとメモリ消費の最適化ハック
Penpotを重いと感じるなら、それはデータ設計が悪い。ブラウザのメモリを食い潰す最大の要因は「巨大な1ファイル」への依存だ。
- コンポーネントの疎結合化: Design Systemのメインライブラリを巨大な1ファイルで管理してはならない。原子単位（Atomic）またはコンポーネントカテゴリ単位でファイルを分割せよ。
- Libraryの参照分離: 大規模チームでは、`Core.penpot` (tokens), `Components.penpot` (atoms/molecules), `Pages.penpot` (templates) と明確にファイルを分け、Libraryとしてリンクさせる。これにより、レンダリング負荷が分散され、ブラウザのメモリ消費が抑えられる。
- WebAssemblyの恩恵を受ける: Penpotはブラウザのマルチスレッド処理を最大限活用する。DOMに依存しすぎない「非表示レイヤーの削除」を定期的に行うスクリプトを走らせることで、プロジェクト全体のパフォーマンスを維持できる。
—
4. デザインシステムとコードの同期：究極の自動化
デザイナーが作った「色」や「影」の定義が、CSS変数やTailwindの設定と乖離する瞬間、デザインシステムは死ぬ。
PenpotのAPIからエクスポートされるJSONデータを解析し、自動的にトークンを生成するパイプラインを構築せよ。
1. Penpot API: `GET /api/v1/files/{file-id}/content` で全データを吸い出す。
2. Parser: Penpotの内部構造から「Color/Typography」情報を抽出し、JSONに変換。
3. Style Dictionary: AWSやAdobeのOSS「Style Dictionary」に流し込み、CSS/SCSS/TSの定数ファイルを自動生成する。
このループを完成させれば、「デザイナーがPenpotで色を変えたら、数分後にはGitHub上でCSS変数が更新され、フロントエンドのビルドが走る」という、エンジニアが夢見る自動化環境が手に入る。
—
結論：ツールを「ハック」せよ
Penpotは単なる描画ソフトではない。それは、デザインデータという「バイナリに近い何か」を、APIとコードで制御可能な「インフラ」に変えるためのツールだ。
もしあなたが大規模組織のエンジニアなら、UIデザイナーに「ツールを使ってください」とお願いするのは今日でやめろ。彼らが作業する場所を、あなたが設計・構築し、自動化されたパイプラインの上で彼らに自由に表現させるのだ。
それが、現代のUI/UXエンジニアが到達すべき「プロダクトの真髄」である。