Sketch Cloud Librariesのコンフリクトを「技術」で制圧する――分散設計環境のアーキテクチャ再考
多くのUIチームが「SketchのCloud Libraryで競合が起きた。誰の変更を優先すべきか？」という不毛な議論に時間を浪費している。だが、断言しよう。コンフリクトは「個人の作業ミス」ではなく「システムの設計欠陥」である。
SketchのCloud Libraryは便利な同期機能だが、Gitのような厳密なマージアルゴリズムを内蔵しているわけではない。大規模開発において、GUIポチポチの運用で整合性を保とうとするのは、手動でバイナリをパッチするのと同義だ。
本稿では、Sketchを「単なるデザインツール」から「設計資産のソースコード」へと昇華させ、コンフリクトを物理的に排除する、あるいは自動解決するための深層アプローチを解説する。
—
1. コンフリクトの真因：なぜ同期は崩壊するのか
Sketchの`.sketch`ファイルは、実質的にはJSONとアセットの集合体である。Cloud Library上での競合は、単なる「同じレイヤーを触った」という事象ではない。「Sketchの内部ID（UUID）の衝突と、メタデータの非同期更新」に起因する。
複数人が同時にLibraryを編集すると、Sketchはバックグラウンドで「Document State」の同期を試みるが、UIスレッドの優先度やネットワークのレイテンシにより、競合解決のシグナルが失われる。結果として、ローカルの変更がサーバー側の最新状態を上書きし、破壊的な変更（破壊的コミット）が発生する。
—
2. 実践的防衛策：ワークフローの「コード化」
まず、最も重要なのは「Design Tokenの外部化」だ。色やタイポグラフィ、スペーシングといった「Atomicな要素」をSketchのUI内で編集させてはならない。
独自CLIによるトークン管理（Design Tokens Pipeline）
SketchのLibraryに依存する前に、JSON形式のトークン定義をGitで管理し、それをSketchへ注入するパイプラインを組むべきである。
Design TokenからSketchファイルへ自動生成するプラグインのCLI例
sketch-tool (Sketch公式CLI) を活用した自動化スクリプト
npm run build:tokens — –output ./libraries/SystemUI.sketch
内部的に sketch-tool を叩き、JSONの差分をSketchデータ構造にマッピングする
コンフリクトが起きた場合、Git側のトークンJSONを正とし、Sketchを再生成する
このように、「Sketchファイルは常にJSONから生成される（生成物である）」という思想へシフトすれば、ライブラリの競合問題は「再ビルド」というコマンド一発で解決できる。
—
3. コンフリクト発生時の緊急オペレーション（低レイヤからの復旧）
もしCLIを導入していない環境で競合が発生した場合、SketchのUIで「どちらを残すか」と悩むのは時間の無駄だ。即座に「バージョン履歴（Version History）」の内部構造へ介入する。
内部ファイル構造の分解と復旧
Sketchファイルは`unzip`可能だ。競合が発生した際、以下の手法で「汚染されたメタデータ」を除去する。
1. ファイルの解凍: `.sketch` を `.zip` にリネームして解凍する。
2. `document.json` の解析: 競合している `pages` フォルダ内のJSONを `jq` コマンドで整形し、JSON Schemaの観点から欠損しているUUIDを特定する。
3. メタデータ・クリーンアップ: 競合で発生した冗長な `meta.json` を削除し、再圧縮してSketchで開き直す。
競合により破損したドキュメントを救出する簡易スクリプト
unzip library.sketch -d ./temp_design
cd ./temp_design
競合の痕跡である冗長なIDリストをクリーンアップ
jq ‘del(.pages[] | select(.do_objectID == null))’ document.json > document.clean.json
zip -r ../fixed_library.sketch .
—
4. チーム運用における「絶対ルール」
自動化を極めても、運用がズボラでは意味がない。以下のプロトコルをチームの憲法とせよ。
- 「Atomic Committer」制度: Libraryの更新権限を持つ人間を、スプリントごとに1名に限定する。その際、Slackと連携させたWebHookを叩き、「今からLibraryを触る」というロックをCI/CD環境に通知する。
- シンボルの分割: `UI-Core.sketch` と `UI-Components.sketch` を分離し、依存関係を階層化する。単一の巨大ファイルは、コンフリクトの確率を幾何級数的に増加させる。
- 「破壊的変更」の事前検知: CI上で `sketchtool list slices` や `sketchtool dump` を定期実行し、前回コミットとの差分をGitHub Actionsで監視する。差分が異常に大きい場合、自動的にPull Requestをブロックする。
—
結論：ツールに振り回されるな
SketchのCloud Libraryは、今のところ「小規模チームには最適だが、大規模には外科手術が必要」なツールだ。真のシニアエンジニア・デザイナーは、GUIの制限を嘆くのではなく、その制限を突破するための「メタレイヤ（自動化スクリプトやパイプライン）」を構築する。
Sketchのコンフリクトは、貴方のワークフローが「人間依存」であることの証明だ。今すぐそのプロセスをコード化せよ。設計資産が「管理されるべきソースコード」に変わったその瞬間、コンフリクトという概念は貴方の辞書から消え去るだろう。
次回の記事では、`sketch-data-format` を直接操作し、FigmaのAPIと同期させる「デザイン・トランスパイラ」の構築手法について解説する。期待していてほしい。