デザインは「データ」である：Penpot GraphQL APIで構築するデザインOpsの極致
デザインツールを単なる「絵を描く場所」と認識しているなら、君のチームはまだ20世紀にいる。
Penpotの真の価値は、そのオープンソース・アーキテクチャと、背後に潜む堅牢なGraphQL APIにある。Figmaのプラグインエコシステムという「檻」の中ではなく、APIを通じてデザインデータを直接「抽出・加工・分析」できることこそ、エンジニアリング組織が渇望していた真のデザインOpsの姿だ。
今日は、Penpotのデザインデータを引きずり出し、カスタムレポートを自動生成する。これは単なる可視化ではない。デザインの「非決定性」を「データ駆動型の事実」へと変換する、DevOpsの最前線だ。
—
1. 核心：Penpot GraphQLの内部構造を掌握せよ
Penpotのバックエンドは、PostgreSQLを堅牢に包み込み、GraphQLをインターフェースとして公開している。まずは、エンドポイントの構造を解析しよう。
ブラウザのDevToolsで `/api/graphql` を覗けば、何が行われているかは一目瞭然だ。ここでのポイントは、認証（JWT）と、GraphiQL環境での探索だ。
認証スキームのハック
PenpotのAPIはトークンベースの認証を行う。まず、以下のヘッダーを注入する。
`Authorization: Token
探索すべきRoot Query
デザインのメタデータを得るには、`files` や `projects` のスキーマを叩く。特に重要なのは、JSON形式で保存された `data` フィールドだ。ここをパースすることで、コンポーネントの数、レイヤー構造、プロパティの変更履歴まで全て追跡できる。
—
2. 実装：デザインメトリクスを自動集計する「Design-Crawler」
デザインの進捗やコンポーネントの枯渇を、手作業で数えるのは無能の極みだ。Node.jsを用いて、デザインシステムの状態をリアルタイム集計するスクリプトを実装する。
// design-crawler.js
const { GraphQLClient, gql } = require(‘graphql-request’);
const client = new GraphQLClient(‘https://your-penpot-instance.com/api/graphql’, {
headers: { authorization: `Token ${process.env.PENPOT_TOKEN}` }
});
// コンポーネント数と使用頻度を抽出するクエリ
const GET_PROJECT_METRICS = gql`
query GetDesignMetrics($projectId: ID!) {
project(id: $projectId) {
files {
name
data # ここに設計図がJSONとして埋まっている
}
}
}
`;
async function analyzeDesignSystem() {
const data = await client.request(GET_PROJECT_METRICS, { projectId: ‘…’ });
// パフォーマンスの観点から、大規模なJSONはストリーム処理でパースする
const components = data.project.files.flatMap(file =>
JSON.parse(file.data).components || []
);
return {
totalComponents: components.length,
uniqueVariants: new Set(components.map(c => c.id)).size,
timestamp: new Date().toISOString()
};
}
エンジニアリングの極意:
ここで重要なのは「JSONの肥大化」だ。数千のレイヤーを持つファイルをそのままメモリに載せると、Node.jsのヒープメモリを圧迫する。大規模なファイル解析時は、`stream-json` 等のライブラリを用いて、必要なプロパティのみをオンメモリでフィルタリングせよ。
—
3. 可視化：社内ダッシュボードへのリアルタイム・パイプライン
抽出したデータをPrometheusやGrafanaに流し込むことで、デザインの健全性を「監視対象」にする。
推奨パイプライン構成
1. GitHub Actions / Cron Job: 定期的に `design-crawler` を実行。
2. Pushgateway: 集計結果をPrometheusへプッシュ。
3. Grafana: 「デザインシステムのコンポーネント網羅率」や「デッドデザイン（使用されていないマスター）」を可視化。
なぜここまでやるのか？
「デザイナーが頑張っているか」を定性的に語るのは時間の浪費だ。
- 「デザインシステムのコンポーネント使用数」が減っていれば、負債が溜まっている証拠。
- 「特定ページの更新頻度」が異常に高ければ、UI/UXの設計が迷走している予兆。
これらを数値化することで、プロダクトマネージャーやエンジニアは「勘」ではなく「データ」でデザインの意思決定を支援できる。
—
最後に：デザインを「コードの隣人」にせよ
デザインデータがクローズドなツールの中に閉じ込められている現状は、技術的負債以外の何物でもない。PenpotのGraphQLを活用するということは、デザインを「コードベースの一部」として扱い、CI/CDのパイプラインの中に組み込むことを意味する。
「デザインシステムは、書かれたコードよりも先に、データとして完結しているべきだ」
このレシピをベースに、君たちの組織独自のメトリクスを構築してほしい。それができるエンジニアこそが、次世代のUI/UXアーキテクトだ。
現場からは以上だ。コードを書き、データを支配しろ。