Open Designでデザイン品質を上げる：Penpot契約運用とDESIGN.mdの続編
前作では、Penpot と React を「同期する」のではなく 同じ契約に従わせる 運用を書きました。続くガイドでは、その契約への入口を DESIGN.md に集約しました。
ここまでで「判断の順番」は固定できます。ただ、ツール選定の話が残っています。
特定ツールの優劣ではなく、デザインデータが開いているかどうかで選ぶと、なぜデザイン品質に効くのか。この記事はそこだけを扱います。
TL;DR
- デザイン品質とは「綺麗さ」ではなく、再現性・一貫性・レビュー可能性のこと。前2記事の契約と入口はここに効く
- Open Design（オープンフォーマット）が品質に効く理由は4つ：SVG が差分で読める／token が往復できる／AI が読める／レビューがフォーマット非依存になる
- ただし「ツールを Open Design に替えれば品質が上がる」は誤り。契約（前作）と入口（ガイド）が無いと、ツールの開放性は品質に変換されない
1. ここでの「デザイン品質」を定義する
品質を上げたい、と言うとき、まず何を品質と呼ぶかを揃えないと議論が滑ります。
この記事では、デザイン品質を見た目の美しさではなく、次の3つで定義します。
| 品質の軸 | 意味 | 崩れたときの症状 |
|---|---|---|
| 再現性 | 同じ意図から同じ実装が出る | 画面ごとに余白・角丸・密度が揺れる |
| 一貫性 | 部品の責務と名前が揃っている | 似た見た目の別コンポーネントが増殖する |
| レビュー可能性 | 何を基準に良し悪しを言えるか共有されている | レビューが人によって論点ずれする |
前作の「契約」も、ガイドの「DESIGN.md 入口」も、狙っていたのはこの3軸でした。Open Design は、この3軸を ツールの構造で支える ために選んでいます。
2. Open Design とは何を指すか
ここでいう Open Design は、特定プロダクトの宣伝ではありません。次の性質を持つデザイン基盤を指します。
- ファイル/データがオープンフォーマットで読める（例: SVG・W3C 標準 token 形式など、公開された仕様で出力できる）
- ツール外からデータへアクセスできる（例: 公開 API・CLI エクスポートがあり、画面操作なしに token / SVG を取り出せる）
- セルフホストやクラウドを運用負荷で選べる（例: ホスティング形態がベンダーに固定されない）
Growth Lab では Penpot Cloud を採用しました。共同編集ができ、SVG ベースで AI と相性がよく、運用オーバーヘッドが低かったためです。重要なのは製品名ではなく、デザインデータが閉じていないという性質のほうです。
なお、考え方自体は Penpot 専用ではありません。フォーマットとアクセスが開いていれば、別ツールでも同じ議論が成立します。
3. Open Design が品質に効く4つの理由
開放性そのものは機能ではありません。それが前2記事の契約とつながって初めて品質に変換されます。順に見ます。
3-1. SVG が「差分で読める」
要点: レビューが「印象」ではなく「変更点」になり、再現性軸（1章）が構造で担保される。
クローズドなバイナリ形式だと、デザイン変更はスクリーンショット比較になりがちです。SVG ベースなら、変更がテキスト差分として読めます。
差分で読めるということは、レビューが「印象」ではなく「変更点」になるということです。前作の「変更単位ごとに確認順を固定する」が、ツール側でも成立しやすくなります。
3-2. token が往復できる
要点: 正本（JSON）とツールが双方向に同期でき、一貫性軸（1章）がロックインなしで保てる。
tokens/*.json を正本にする運用（前作）は、token がツールへ取り込め、ツールから戻せて初めて閉じます。
Open Design は標準 token 形式（W3C / Design Tokens Community Group 形式）を入出力できるため、pnpm penpot:push / pnpm penpot:sync のような往復運用が、ツールロックインなしで組めます（これらは token JSON とツールを同期する自作コマンド。具体は前作・ガイドで定義）。正本は JSON 側、ツールは作業の場、という前作の役割分担が崩れません。
3-3. AI が読める
要点: AI に画像を察させるのではなく構造を渡せる。前作の「契約に照らす」AI 指示が成立する。
AI に UI 実装を任せる前提だと、デザインデータが AI から参照可能かどうかが品質に直結します。
SVG とオープン token は、AI にとって構造化された読めるデータです。「画像を見て察してもらう」ではなく「構造を渡して契約に照らす」（前作の AI 指示方針）が、ツール側のデータ性質として成立します。
3-4. レビューがフォーマット非依存になる
要点: 専用ツールを開かず差分で見られる。レビュー可能性軸（1章）が善意でなく構造で担保される。
クローズド形式は、レビューにそのツールのアカウントとライセンスを要求します。Open Design は、フォーマットが開いているぶん、レビューの入口を DESIGN.md（ガイド）に寄せられます。
つまり「デザインを見るには専用ツールを開く」ではなく「契約ファイルと差分を見る」にレビューを移せます。レビュー可能性（1章の3軸目）が、人の善意ではなく構造で担保されます。
4. 前2記事とどう接続するか
この続編単体では品質は上がりません。3つが揃って初めて効きます。
Open Design（本記事） … データが開いている＝差分・往復・AI可読・レビュー非依存
↑ これを品質に変換するのが
契約（前作） … token JSON / component-map を正本にする
入口（ガイド） … DESIGN.md で参照順と検証を固定する
続編単体で読む人向けに、前2記事の要点を1行ずつ補足します。
-
契約（前作）:
token JSONとcomponent-mapを正本に置き、ツールではなくファイルを「正しさの基準」にする運用 -
入口（ガイド）:
DESIGN.mdに「どの順で何を参照し、どう検証するか」を集約した薄い索引
この契約と入口が無いままツールだけ開いても、開いたデータを「何を正本に、どの順で、どう検証するか」へ接続する層が無く、品質には変換されません。ツール選定は最後の1ピースであって、最初の解ではない、というのがこの記事の主張です。
5. 実際に何が変わったか（正直な範囲で）
定量効果はまだ十分に蓄積していません。ここは誇張せず、観測できた定性変化に絞ります。
観測できた定性変化
- デザイン差分が「スクショ突き合わせ」から「変更点の確認」に寄った
- token 変更が JSON 正本 → ツールの一方向で追えるようになり、どちらが正かで迷う場面が減った
- AI へのデザイン指示で、画像説明より構造参照を渡せるようになった
- レビューの入口が
DESIGN.mdに集約され、「どこを見るか」の合意が取りやすくなった
逆に、改善しなかった/しにくかったことも置きます。
- 「ツールを替えたから見た目が美しくなる」ことは起きない。見た目の美しさは契約と判断の問題
- 開放性は drift を自動では止めない。
pnpm penpot:verifyのような検証導線が別途必要 - オープンフォーマットでもチームの命名が揺れれば一貫性は崩れる
品質向上の主因は Open Design 単体ではなく、開いたデータを契約と入口に接続できたことだ、と整理しています。
6. 最小で始めるなら
前2記事と同じく、最初から全部を揃える必要はありません。
- デザインデータが開いているツールを選ぶ（フォーマットとアクセスが閉じていないこと）
-
tokens/*.jsonを正本にし、ツールとの往復を一方向（正本→ツール）に固定する -
DESIGN.mdにレビューの入口を寄せ、ツールを開かなくても差分で見られる状態にする -
pnpm penpot:verify相当の整合チェックを置き、開放性を「善意依存」にしない
この4つだけでも、デザイン品質を「印象の議論」から「再現性・一貫性・レビュー可能性の議論」に移せます。
まとめ
Open Design の価値は、見た目の美しいツールに替えることではありません。
価値は、デザインデータが差分で読め、往復でき、AIが読め、フォーマット非依存でレビューできることです。そしてそれは、前作の契約と、ガイドの入口に接続して初めて品質になります。
- デザイン品質＝再現性・一貫性・レビュー可能性
- Open Design はその3軸をツールの構造で支える
- ただしツール選定は最後の1ピース。契約（前作）と入口（ガイド）が前提
- 品質向上の主因は Open Design 単体ではなく、開いたデータを契約と入口に接続できたこと（効果は5章のとおり現時点では定性中心）
デザインツールを開くかどうかは、見た目の好みではなく、品質をどの構造で担保するかの選択です。前2記事の契約と入口があるなら、Open Design はその効きを素直に増幅します。
Open Designでデザイン品質を上げるFAQ
Q. Penpot ではなく Figma のままでも、この記事のメリットは得られますか？
A. 部分的に得られます。Figmaは token の入出力（Tokens Studio経由）と API アクセスは可能なので「往復」「AI可読」は成立します。一方、SVG の差分レビューやセルフホスト選択肢は弱いため、本記事で挙げた4つの理由のうち3-1（差分レビュー）と運用負荷の自由度は妥協する形になります。
Q. 契約と入口が無い段階で先に Penpot に移行するのは無駄ですか？
A. 無駄ではありませんが、品質向上は後ろ倒しになります。先にツールだけ替えても、開いたデータを「どの順で何を見るか」へ接続する層が無いため、レビューや AI 指示は以前と同じ揺れ方をします。並行で tokens/*.json を正本にする運用と DESIGN.md の入口整備を進めるのが最短です。
Q. SVG ベースの差分レビューと言っても、実際にPRで見ると変更が膨大で読みにくいのでは？
A. その通りで、生 SVG の diff を眺めるのは現実的ではありません。実運用では「token JSON の差分」「component-map の差分」を主に見て、SVG はスクショ生成のソースとして使います。重要なのは「差分として取得可能なフォーマットである」ことで、レビュー時に毎回テキスト差分を読むことではありません。
Q. Open Design 採用の最低条件は何ですか？セルフホストは必須？
A. セルフホストは不要です。最低条件は「データ形式が公開仕様（SVG / W3C token 等）であること」と「画面操作なしにデータを取り出せる API か CLI があること」の2点です。Growth Lab は Penpot Cloud を採用していますが、フォーマットとアクセスが開いていれば運用負荷の少ない SaaS で十分です。
Discussion