Sketchを「単なる描画ツール」から「真のSSoT」へ昇華させる：デザイントークン連携の極致
デザインツールとコードベースの間に横たわる「仕様の乖離」は、プロダクト開発における最大の負債だ。Sketchの「Shared Styles」を単なる整理術として使うのは、フェラーリを近所のコンビニの買い物に使うようなものだ。
我々が目指すべきは、Sketchをデザイントークンの「GUIフロントエンド」として定義し、その裏側に強固なCI/CDパイプラインを構築することである。本稿では、マルチプラットフォーム（iOS/Android/Web）展開を極限まで自動化するための、アーキテクチャの核心を説く。
—
1. Shared Stylesを「トークンのスキーマ」として再定義する
SketchのShared Stylesは、そのままでは単なる「プリセット」に過ぎない。これをデザイントークンのスキーマとして機能させるには、命名規則に「抽象化レイヤー」を導入する必要がある。
- ハードコーディングを排除する: `Blue/500` のような具体的な値ではなく、`color/action/primary/default` といったセマンティックな命名を徹底する。
- 階層化の徹底:
- Level 1 (Global): カラーパレット、ベースフォントサイズ（例: `color/blue/500`）
- Level 2 (Semantic): 文脈に応じた定義（例: `color/bg/primary`）
- Level 3 (Component): 特定コンポーネント用（例: `button/primary/bg`）
この階層構造をSketch上でShared Stylesとして管理することで、デザイントークンの構造そのものをデザインファイル内に埋め込むことが可能になる。
—
2. SketchからJSONへ：内部構造をハックする
Sketchのファイルは実際には`.sketch`という拡張子のついたZIPアーカイブだ。この中にある `document.json` を直接解析することで、Shared Stylesのデータをコードベースへと抽出できる。
以下は、Sketchファイルを解析し、トークンを抽出するためのNode.jsスクリプトの断片である。
/
- Sketch document.json から Shared Styles を抽出し、
- Style Dictionary が読み込める形式に変換するスクリプトの核心部
/
const fs = require(‘fs’);
const AdmZip = require(‘adm-zip’);
function extractTokensFromSketch(filePath) {
const zip = new AdmZip(filePath);
const doc = JSON.parse(zip.readAsText(‘document.json’));
// Shared Styles は ‘layerStyles’ オブジェクトに格納されている
const sharedStyles = doc.layerStyles.objects;
return sharedStyles.map(style => ({
name: style.name, // ここに “color/action/primary” と命名規則が反映されている
value: style.value.fills[0].color // RGBA値をCSS/Swift/Kotlin形式に変換するロジックへ
}));
}
—
3. Style Dictionary を用いたマルチプラットフォーム同期
抽出したJSONを、Style Dictionaryに流し込む。ここで重要なのは、「プラットフォームごとの差異」をデザイン側ではなく、ビルドパイプライン側で吸収することだ。
// style-dictionary/config.json
{
“platforms”: {
“web”: {
“transformGroup”: “web”,
“buildPath”: “dist/web/”,
“files”: [{ “destination”: “tokens.css”, “format”: “css/variables” }]
},
“ios”: {
“transformGroup”: “ios-swift”,
“buildPath”: “dist/ios/”,
“files”: [{ “destination”: “StyleTokens.swift”, “format”: “ios-swift/class.swift” }]
}
}
}
このパイプラインを構築すれば、デザイナーがSketchでスタイルを更新し、Gitにプッシュ（またはCLI経由でのエクスポート）するだけで、全プラットフォームのコードが自動的にアップデートされる。
—
4. パフォーマンスとスケーラビリティの最適化ハック
大規模なデザインシステムにおいて、Sketchのメモリ消費とパフォーマンスは無視できないボトルネックとなる。
1. シンボルとスタイルの分離: 複雑なレイヤー構造を一つのファイルに詰め込むとレンダリングが重くなる。`Foundation.sketch`（トークン用）と `Components.sketch`（コンポーネント用）をライブラリとして分離し、デザインファイルはそれらを参照する形にせよ。
2. CLIオートメーション: `sketchtool`（Sketch公式のCLI）を駆使し、手動での書き出しを完全に排除せよ。CIサーバー上で毎晩実行し、コードベースとの差分があればPull Requestを自動生成させるのが、真のDevOpsだ。
3. トークンのバリデーション: `document.json` をパースする際、命名規則から外れたShared Stylesが存在する場合にビルドを失敗させる「スキーマバリデーター」をCIに組み込むこと。これにより「名前だけ変えてシステムが壊れる」という悲劇を未然に防げる。
—
結論：デザイナーとエンジニアの「言語」を統一せよ
優れたUI/UXとは、画面上のピクセルだけを指すのではない。そのデザインがいかにして信頼できるデータソース（SSoT）から生成され、いかにしてコードへと変換されたかという「プロセスの美しさ」こそが、プロダクトの品質を決定づける。
Sketchを「絵を描くツール」として使う段階は終わった。今こそ、デザイントークンという言語を介して、デザインとコードを不可分なものとして統合するのだ。このパイプラインが完成した時、あなたのチームから「修正の同期漏れ」という言葉は永久に消滅するだろう。
さあ、コマンドラインを開け。設計の真髄は、エディタの中にある。