EN日本語
相談する
メニュー

このページの日本語は、ネイティブスピーカーによる確認前の翻訳です。

見える化する：何かを変える前に、いまあるものを正しく知る

多くのチームは、自社のデザインシステムに課題があることを知っています。しかし、それがどこにあり、どれほど大きく、どれが重要なのかを正確に言えるチームはわずかです。 「見える化する」では、その全体像を、すべての指摘事項の根拠とともに示します。最初の一歩は、コードへのアクセスを必要としないヘルスチェックです。

自社のスタイルシートは、システムがどこからほつれ始めているかを知っています

CSS、SCSS、またはDTCG形式のトークンファイルを貼り付けてください。ページに組み込まれたLoom自身の監査コードが、見つけたことから先に示します。ハードコードされた色、ほぼ同じ色、コントラストを満たしていない組み合わせです。そのうえで、スタイルシートからわかる2つの領域を採点します。どこにも送信しません。データは貼り付けた内容だけです。

残りの6つの領域にはリポジトリが必要なため、ページ上では採点しません。

自社のスタイルシートを読む（英語）

最初の診断に、コードへのアクセスは必要ありません

ヘルスチェックは、ブラウザで行う自己診断です。公開している評価基準（ルーブリック）の8つの領域について、16問の基本の質問に答えます。さらに詳しく答えられる任意のセクションもあります。領域ごとのスコアは、その場で表示されます。「わからない」も有効な回答です。わからない項目は「未確認の点」として別に示します。誰も把握していないこと自体が、一つの指摘事項だからです。

回答はブラウザの中だけで処理されます。詳細レポートを希望された場合に限り、連絡先、プロフィール（役割、チームの人数、組織の規模）、領域ごとのスコアが私たちに届きます。個々の回答と自由記述は、ブラウザの外に出ることはありません。

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

監査は、システムの説明ではなく、システムそのものを読みます

リポジトリへのアクセスをいただければ、監査はすべてのトークン、コンポーネント、画面を読みます。コードを実行することはありません。ヘルスチェックと同じ8つの領域を採点するので、2つの結果を比べられます。また、すべてのチェック項目について根拠を示します。

8つの領域は次のとおりです。

  1. 基盤とトークン
  2. コンポーネント
  3. パターンとページ
  4. 利用状況
  5. ガバナンス
  6. ブランド、イラスト、マイクロコピー、ローカライズ
  7. ツールと同期
  8. AI対応

すべての指摘事項には、その根拠と次の一手が示されます。以下は、デザインシステムを持たないオープンソースのメモアプリ「takenote」（MITライセンス、コミットe0eddbb）を監査した実際の出力です。監査エンジンの出力は英語です。

Usage · 17/100
HIGH · 17 hand-rolled <button>s across 10 files, no shared Button
  src/client/components/AppSidebar/ActionButton.tsx:24
  src/client/components/AppSidebar/AddCategoryButton.tsx:18
  src/client/components/AppSidebar/CollapseCategoryButton.tsx:20
  src/client/components/AppSidebar/FolderOption.tsx:66
  → Extract one Button contract (variants, states, a11y) and migrate
    call sites; this is the highest-leverage first component.

指摘事項は、プロダクトの見た目についての意見ではありません。システムがどう組み立てられているかについての事実であり、コード上の場所と最初の修正方法が示されています。

監査は、人にしか下せない判断も一覧にします。たとえば、あるコンポーネントを使うべきでないのはどんなときか、といったコードからは読み取れない点です。

スコアは4つの段階に分かれます。しっかり織り上がっている（90以上）、まとまっている（75〜89）、形になりつつある（60〜74）、ほつれが多い（60未満）です。基準は意図的に厳しくしています。良いシステムが簡単に合格すべきではないからです。

  1. 16takenoteデザインシステムのないオープンソースのメモアプリほつれが多い
  2. 75Loom Base私たちのオープンソースのデザインシステム（MIT）まとまっている
  3. 22Loom のコントロールエリア基準ができる前に私たちが作った画面ほつれが多い
実際の監査結果です。Loom 自身の公開基準で採点し、低いスコアも含めて公開しています。各数字から、その根拠となるすべてのチェックを確認できます。

私たちは、自分たちの仕事にも同じ基準を当てはめます。私たちの管理画面は22点、Loom Baseは75点です。どれを開いても、各チェック、その重み、スコアを出したコマンドを確認できます。

私たちのスコアの根拠をすべて見る（英語）

完成しているように見えても、システムが迂回されていることがある

利用状況のスキャンはプロダクトのコードを読みます。1回の実行で1つまたは複数のプロダクトのフォルダを読み、件数はフォルダごとに保持します。そして、トークンを迂回しているハードコードされた色やピクセル値、システムのコンポーネントを独自に複製したもの、コントラクト（機械可読なコンポーネント仕様）やルールのないUI要素を報告します。複製かどうかはコードそのもので確かめます。システムのコンポーネントを包むコンポーネントや、どこにも適用されていないクラスは、複製として数えません。静的なスキャンのため、定着の数値は下限値です。

Usage scan · takenote (real audit output, 7,184 lines of product code)
System bypasses per 1,000 lines    20.8
  raw colour literals               91   (44 distinct, e.g. #333333 ×5)
  raw pixel values                 117   (counted at half weight)
  token references                 209
Distinct UI elements with no contract or rule   13 of 30

監査の結果は、実行ごとにスコアと件数の小さなファイルとして自社のリポジトリに保存できます。2回目の実行からは、領域ごとの推移、段階の変化、前回から何がずれたかを、管理画面、監査レポート、ターミナル、そしてエージェントに示します。

Figmaも、コードと同じ評価基準で読みます

LoomはFigmaライブラリをコードと同じ評価基準で監査し、コードと比べて食い違っている箇所を示せます。

Figmaのバリアブルを読めるのはEnterpriseプランだけです。それ以外のプランでは、該当するチェックは「評価できません」と表示されます。

エージェントが見つけられなかったものは、ニーズの一覧になります

エージェントがシステムを検索して合うものが見つからなかったとき、Loomはエージェントにコンポーネントを勝手につくらせず、そのニーズを記録します。ニーズはまとめて数えられ、オーナーが決めたしきい値と照らし合わされます。記録はデプロイメントごとに保持され、依頼者はエージェントが報告する名前で数えます。その名前は検証されていません。

search_system("date range picker for booking")
  No component matches "date range picker".
  Closest partial matches: Meter and ProgressBar (covers "range", not "date picker")
list_unmet_needs()
  1 unmet need from 1 request; 0 over the threshold
  (3 requests from 2+ requesters in 30 days). "date range picker" x1.

以下は、LoomのMCPサーバーをLoom Base（Loom自身のデザインシステム）に対して実行した出力で、エージェントの再生（リプレイ）のデモに記録されているものです。

しきい値を超えたニーズは、週次のレーダーのジョブがドラフトの提案に変え、受信トレイの項目とともに、所有の記録にもとづいて振り分けを担う人に回します。すでに提案の流れにあるニーズを二重に挙げることはありません。マージされるものはありません。

システムの一部は、外からも見えます

最初のご相談の前に、コンサルタントは公開されているWebサイトを訪問者と同じように読み、そこから読み取れるデザインシステムを測れます。色、文字、余白、繰り返し使われるコンポーネント、アクセシビリティ、マイクロコピーです。採点するのは外から見える領域だけで、それぞれに確度を示します。それ以外の領域は0点ではなく「アクセスが必要」と表示します。

ログインが必要なページと実際のアプリの画面を読むには、ディスカバリーでのアクセスが必要です。

チーム間の見方の違いも、指摘事項です

有料のディスカバリー（現状調査）では、それぞれの職種が、ヘルスチェックと同じ質問にチームアンケートで答えます。回答は回答者のブラウザの中で、コンサルタントの鍵に向けて暗号化され、5人未満のグループの結果を単独で表示することはありません。デザインとエンジニアリングで、システムの見え方がどこで違うかがわかります。

今後の予定

  • お客様のファイルでのFigmaの監査。 実際のお客様のライブラリで動かします。これまでは合成したライブラリでテストしています。
  • お客様のCIでのレーダー。 レーダーがお客様のCIで動くようになります。これまではローカルとシミュレーションのGitホストで動かしています。
  • 実際のチームでのアンケート。 実際のチームから回答を集めるようになります。これまでは合成した回答で動かしており、回収は手作業です。

よくある質問

ヘルスチェックに、コードへのアクセスは必要ですか？

いいえ。ヘルスチェックにはアカウントもアクセスも必要ありません。監査にはリポジトリの読み取り権限が必要で、それもご支援の期間中だけです。

監査で何かが変更されることはありますか？

いいえ。監査は読んで報告するだけです。コードを実行することも、リポジトリに書き込むこともありません。

優れたシステムでも、最初は低いスコアになるのはなぜですか？

評価基準が2026年の水準を求めているからです。記録として残るガバナンス、AI対応、チェックできるブランドとコンテンツのルールなどです。スコアが示すのはやるべき仕事であり、失敗ではありません。Loom自身の管理画面も22点で、私たちはそれを公開しています。

評価基準は公開されていますか？

はい。評価基準は公開しており、ヘルスチェック、監査、管理画面のすべてが同じ8つの領域を使います。

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

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

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

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