デザインシステムを、織り直す。

組織としてデザインシステムを運用する仕組みを整え、チームがレビューするエージェントとともに運用を続けます。プロダクトの見た目は変えずに、チームが頼れる道具にします。

見える化する実際に何があるかを知る。8 つの領域を監査し、すべての指摘に根拠を示します。稼働中
Story Atelier：適用前 59、適用後 83（Loom 側のコピーを Loom の公開基準で採点。記録は創業者の承認前）。
整える説明書ではなく、道具にする。型付きトークンと、コンポーネントごとに一つのコントラクト（機械可読なコンポーネント仕様）。見た目は変わりません。一部稼働コンポーネントの生成は、まだ三つのコンポーネントにとどまります。
ロールトークン → プリミティブ → 値。58 のロールトークンが 54 のプリミティブを参照し、描画結果は一つも変わっていません。
守る一度だけ、正しいレベルで決める。オーナー、ルール、例外を、自社のリポジトリの中に残します。稼働中
ガバナンスの効いた変更（サンプル）
1. 提案
2. レビュー
3. 承認
4. リリース
リリース：プルリクエストでトークンを追加。マージするのは自社のエンジニアで、Loom はマージしません。
運用する定型作業はエージェントに任せる。自社のチームが決めたルールのもとで、レビューできる変更として届きます。稼働中
ドラフトのプルリクエスト：生の値 2 件をトークンに置き換え（コードモッド）。マージするのは自社のエンジニアです。

デザインシステムを動かすのは、道具ではなく人です。

デザインシステムが長く続くのは、組織がその運用の仕方を知っているときです。 ドキュメントツール、Figma ライブラリ、コードのチェックは良い道具であり、デザインチームは使うべきです。しかし道具は、誰がルールを持つのか、誰が変更をレビューするのか、締め切りと基準がぶつかったときにどうするのかを決めてはくれません。5 人のデザイナーが合意した進め方なしに一つのライブラリを共有すると、システムはすぐに形骸化します。

これが UX Ops（UXオペレーション）であり、私たちが最初に取り組む仕事です。チームがシステムを運用するために必要な役割、レビューキュー、定例の進め方、コミュニケーションを整え、それらを自社のリポジトリの中の記録として残します。道具は、組織が決めたことを実行するためにあります。

すべての領域にオーナー。
システムオーナー、領域ごとのオーナー、デザイン・エンジニアリング・コンテンツ・アクセシビリティをまたぐ小さなギルドを、リポジトリに記録します。稼働中
サービスレベル付きのレビューキュー。
すべての依頼にオーナー、期日、残りの営業日があります。担当者のいない依頼はありません。稼働中
準備された定例。
Loom はキューとヘルス指標から、週次トリアージの議題を下書きします。Slack や Teams への投稿は計画中です。一部稼働コンセプト
終わりのある例外。
すべての例外に、ルール、理由、承認者、期限を記録します。期限が来ると、課題は戻ってきます。稼働中

私たちの運用の進め方（英語）

問題はシステムではありません。守り方です。

デザインシステムがばらばらになる仕組み

イラスト

12 か月目：システムは残っていますが、もう一つのものとして使う人はいません。

仕組みを示すイラストで、計測データではありません。四角が一つのシステム、線の一本一本がその糸（コンポーネント、トークン、ルール）です。

デザイン、コード、AI エージェントが、デザインシステムを三つの方向へ同時に引っ張ります。 デザイナーは Figma ライブラリを変え、エンジニアはコンポーネントを変えます。AI コーディングエージェントは毎日インターフェースを書き、見つけたものをそのまま真似します。一つ一つの変更はもっともでも、合わさるとシステムはばらばらになります。

16%のデザインシステムは一人で運用されています。
23%のチームだけが、人員は十分だと答えています。
56%が人員を最大の課題に挙げています。

zeroheight Design Systems Report 2026（実務者 147 名への調査）、zeroheight のローンチウェビナーで公表された数値。 https://report.zeroheight.com

小さなチームでもシステムを説明することはできます。しかし、すべての画面、すべてのライブラリ変更、エージェントが書くすべての行を確かめることはできません。こうして良いシステムも取り残されていきます。私たちが引き受けるのは、その仕事です。

私たちは自分たちの数字と、その確かめ方を公開します。

お客様のシステムに使うのと同じ基準を、私たち自身にも当てはめます。

同じシステムで、59 点から 83 点へ。
Seamline（私たちのチームのプロダクト）のデザインシステム Story Atelier は、Loom の作業前は 59 点（Loose threads）でした。Loom のサービスを適用した後は 83 点（Holding together）で、8 領域中 5 領域が Tightly woven です。採点基準の重みやルールは一切変えていません。稼働中作業は Loom 側のコピーで行い、Loom 自身の公開基準で採点しています。記録はまだ創業者の承認前です。利用状況とブランドは、プロダクトのコードとブランド素材がないため低いままです。稼働中
50 件のパリティテストすべてに合格。
Loom は Button、Switch、Dialog をそれぞれ一つのコントラクトから React と React Native 向けに書き、両プラットフォームを同じ振る舞いに対してテストしました。ネイティブのテストはシミュレーション環境で実行しており、実機ではまだ行っていません。一部稼働
エージェント向けの 11 のツール。
Loom の MCP サーバーを使うと、どのエージェントもシステムを検索し、コントラクトとトークンを読み、構成をチェックし、コードを監査し、変更を提案し、見つからなかったものを記録できます。稼働中
二つのパイロット、課題はその日のうちに修正。
2026 年 10 月 25 日、実在する非公開アプリでの二つの匿名パイロットで、標準的な構造を持たないアプリの読み取りに課題が見つかりました。私たちはその日のうちに、テスト付きでエンジンを修正しました。稼働中

Story Atelier

59→83/ 100 · Holding together

基盤とトークン63 91
Tightly woven. 63 から 91 へ。非公開のシステムのため、指摘の本文は公開していません。
コンポーネント56 98
Tightly woven. 56 から 98 へ。非公開のシステムのため、指摘の本文は公開していません。
パターンとページ100
Tightly woven. 非公開のシステムのため、指摘の本文は公開していません。
利用状況58 59
Loose threads. 58 から 59 へ。非公開のシステムのため、指摘の本文は公開していません。
ガバナンス49 100
Tightly woven. 49 から 100 へ。非公開のシステムのため、指摘の本文は公開していません。
ブランドとマイクロコピー24 31
Loose threads. 24 から 31 へ。非公開のシステムのため、指摘の本文は公開していません。
ツールと同期43 84
Holding together. 43 から 84 へ。非公開のシステムのため、指摘の本文は公開していません。
AI 対応77 90
Tightly woven. 77 から 90 へ。非公開のシステムのため、指摘の本文は公開していません。

同じシステムの、Loom のサービス適用前と後の実際の監査結果（2026年10月25日）。作業は Loom 側のコピーで行い、Loom 自身の公開基準で採点しています。記録はまだ創業者の承認前です。利用状況とブランドは、プロダクトのコードとブランド素材がないため低いままです。細い線が適用前のスコアです。

ミニ監査を試す CSS やトークンを貼り付けると、すぐに最初の結果が出ます。データはブラウザの外に出ません。（英語）一部稼働監査エクスプローラーを見る二つの実際の監査を領域ごとに。Story Atelier とオープンソースのメモアプリ。（英語）稼働中

すべてのデモ（英語）

小さく始め、次の段階は成果で判断していただきます。

ご支援の範囲は、毎回チームと一緒に決めます。どの段階も、次に進むかどうかにかかわらず、手元に残るものがあります。

クイック監査。
2 週間、€5,000〜€8,000（税別）。スコアと根拠のレポート、ロードマップ、進捗を測る基準値が残ります。
ディスカバリー。
2〜4 週間、€15,000〜€25,000（税別）。オーナー、ルール、レビューキュー、定例といった運用モデルが、リポジトリの記録として残ります。
変換。
範囲はご相談のうえ決めます。見た目はそのままに、ガバナンスの効いた AI 対応のシステムが残ります。
運用。
プロダクトごとの月額契約で、プラットフォームを含みます。費用はご相談のうえ決めます。

ご支援の進め方（英語）

役割ごとに、専用のページがあります。

デザインシステムはチーム全体のためのもので、役割ごとに関わり方が違います（各ページは英語です）。

チームの働き方の基本を守ります。

UX Ops は、本来の仕事を取り巻く事務作業ではありません。本来の仕事を効果的に進めるための基盤です。

Loom 創業者 Xavier Sorribas、Why Organisations Need UX Ops More Than Ever（2026 年 8 月、英語）より。

Loom は、デザインシステムと UX Ops を率いてきた Xavier Sorribas が立ち上げました。デザインシステムの専門家のチームがつくっています。デザインシステムがうまくいかない理由は、道具が足りないことではほとんどありません。運用する体制がないことです。

Loom について（英語）

まずは、自社のデザインシステムについてお聞かせください。

私たちはまず話を聞きます。それからシステムを読み、見つけたことをお見せし、何から直すかをチームと一緒に決めます。

相談する無料で診断する（約3分）

Loom は、デザインチームが 5 名以上の組織を対象にしています。