守る：ふさわしいレベルで、一度だけ決める

ガバナンスは、リポジトリの記録として残ります

Loomはガバナンスを、リポジトリのloom/フォルダの中のファイルとして管理します。オーナー、ルール、例外、提案、パターン、非推奨、レイヤーのバージョン、定例です。Loomはそれらを読み、作業をそれらに照らしてチェックし、書き込みは、チームがレビューする変更に限ります。Loomの利用をやめても、記録は手元に残ります。

Loom自身のオープンソースのシステムLoom Baseでは、こうした記録が実際にリポジトリに置かれています。

2026年10月に14の公開デザインシステムを読んだ範囲では、ガバナンスを機械可読な記録として公開しているものは一つもありませんでした。どれも、ガバナンスを文章で説明しています。Loomはそれを、人もツールもエージェントも読めるデータにします。

すべてのルールに、オーナーと理由があります

ルールは、バージョン管理された記録です。オーナー、根拠、重大度、適用範囲、チェックの方法を持ちます。ルールの変更も、コードと同じく、提案、レビュー、承認、リリースの流れで進みます。

判断も、その理由とともに記録されます。以下はLoom Baseの実際の記録です。

packages/base/decisions/0003-component-tokens-required.md
Status       Decided by the owner, 25 Oct 2026
Decision     Component tokens are required.
Why          Agents need precise, machine-readable mappings per component.
Consequence  Base generates the component tier from each contract's tokens
             block (about 1,300 tokens). Components read only their own
             component tokens; each aliases a semantic token.

標準では、ハードコードされた色、ハードコードされた余白、作り直されたコンポーネントは警告です。領域のオーナーは、その領域についてルールをエラーに引き上げられます。アクセシビリティのルールは常にエラーです。どんな記録や設定でも、警告に下げることはできません。

例外は、期限が来れば自動で終わります

チームがルールを破らざるを得ないときもあります。例外には、ルール、適用範囲、理由、依頼者、承認者、そして承認から最長90日後の期限を記録します。有効な間、その指摘事項は情報として表示されます。期限が来ると指摘事項は自動で戻り、例外には更新か終了の判断を求める印がつきます。アクセシビリティのルールに対する例外を承認できるのは、アクセシビリティのオーナーだけです。

# loom/exceptions/checkout-banner.yaml (sample record, in the format Loom checks)
rule: no-raw-colour
scope: Checkout banner
reason: Campaign artwork, ends with the campaign
requested_by: Growth team
granted_by: Foundations owner
expires: 2026-11-08   # at most 90 days after it was granted

パターンは、チェックできる形で書きます

パターンは一つの記録です。解決する課題、使うコンポーネント、すべきこととすべきでないことのルール、コンテンツの指針、アクセシビリティの注意点、動く作例をまとめます。エージェントはそれをもとに組み立て、Loomは画面の構成をそれに照らしてチェックします。地域やプロダクトのレイヤーは、ロックの範囲内でパターンを拡張できます。たとえば、基本のサインインのパターンに電話番号でのサインインを加える、といった形です。

コンポーネントが共有レイヤーに上がるのは、3つの条件を満たしたときだけです

一つのプロダクトのためにつくられたコンポーネントは、そのプロダクトのレイヤーに置かれます。共有のレイヤーに移るのは、3つの条件がそろったときです。準備完了の定義を満たしていること、新しいレイヤーでのオーナーが決まっていること、デザイン、エンジニアリング、アクセシビリティの承認を得ていることです。Loomは各条件を、根拠とともに「満たしている」か「足りない」かで示します。

依頼はすべて一つのキューで、期日つきで管理する

判断を待つ項目には、それぞれ期日と残りの営業日が表示されます。標準のサービスレベルは3営業日で、組織ごとに独自に設定できます。営業日の計算では、組織の休日を除きます。オーナーが不在のときや、サービスレベルを守れそうにないときは、オーナーがあらかじめ指名した代理の担当者に項目が回ります。

健全性を測り、測れないものは「未計測」と示す

システムオーナーが最初に見る画面には、4つのグループが表示されます。定着（インターフェースのどれだけがシステムから来ているか）、乖離（コード、Figma、コントラクト（機械可読なコンポーネント仕様）の間の違い）、フロー（提案のリードタイム、守れたサービスレベル、未解決の例外）、品質（アクセシビリティ、準備完了の状況、テストのカバレッジ）です。Loomが測れないものは「未計測」と表示し、推測で埋めることはありません。

破壊的変更は、根拠にもとづいて判断します

Loomはコントラクトの2つのバージョンを比べ、バージョンをどう上げるかを判断します。プロパティの削除や名前の変更、デフォルト値の変更、状態やキーボード操作の削除はメジャーです。追加はマイナーです。主要な画面で0.5%を超える見た目の変化も、破壊的変更とみなします。

Loomはリリースの準備もします。その比較と、承認された提案、非推奨をもとに各パッケージの次のバージョンを算出し、コードモッドか移行のプルリクエストのないメジャーリリースは受け付けず、デザイナー向けと開発者向けのメモを添えた変更履歴をシステムのボイスで書き、リリースのプルリクエストをドラフトとして作成します。マージするのは人で、公開するのは自社のワークフローです。

大きな組織は、システム・オブ・システムズを運用しています

大きな組織では、グローバルブランド、地域、デジタルブランド、プロダクトといった複数のレイヤーが重なっています。各レイヤーには独自のオーナーとバージョンがあり、親のどのバージョンと組み合わせられるかを宣言します。Loomはすべてのレイヤーを親と照らし合わせ、親のリリースによってどのレイヤーが取り残されるかを示します。

すべてのルールは、下のレイヤーでどこまで変えてよいかを定めています。

• **ロック：**下のレイヤーは変更できません。たとえば、アクセシビリティの最低基準や同意の通知です。
• **拡張可：**下のレイヤーは追加できますが、既存のものは変えられません。
• **上書き可：**下のレイヤーは、理由を記録したうえで置き換えられます。
• **デフォルト：**出発点であり、下のレイヤーで調整することを前提としています。

レイヤーのデモ（サンプルデータ）では、いずれかのレイヤーの立場から、各ルールがどこから来ているかを確認し、変更を試せます。ロックされたルールはオーナーへの依頼になり、上書き可のルールでは理由を求められます。

レイヤーのデモを試す（英語）

非推奨は、告知し、日付を決め、移行します

非推奨にした項目は、代わりのものと削除日をあわせて告知します。監査は、残っている利用箇所が0になるまですべて報告し、Loomは利用側のプロダクトごとに、移行をパッチとプルリクエストの説明として書きます。破壊的変更を承認する前には、移行シミュレーターが、その変更がいくつのファイル、呼び出し箇所、プロダクトに及ぶか、そのうちどれだけをコードモッドで書き換えられるかを示します。

デザインとコードが食い違ったら、オーナーが決めます

どちらかが自動的に優先されることはありません。何が存在するかを示すのは、リポジトリとFigmaです。Loomは承認済みのコントラクトとの違いを知らせ、オーナーが変更を受け入れるか、元に戻すかを決めます。Figmaの乖離レポートは、合成したライブラリでは現在動いています。

提案どうしが食い違うこともあります。2つの未決の提案が同じコンポーネントを変える場合や、新しい提案がすでに下した判断と矛盾する場合です。Loomはこうした衝突を見つけ、両方の内容をレビューキューと週次トリアージの議題に示し、解決案を勧めます。決めるのはオーナーです。

管理画面では、システム全体を一か所で確認できます

システムのページでは、健全性、5つの階層、誰が何のガバナンスを担っているか、ルール、例外、レビューキュー、バージョン、利用状況、非推奨、パターンを一か所で確認できます。受信トレイの操作と、ダッシュボードの一部は、サンプルと明示したデータで動いています。

管理スペースでは、適切な役割を持つ人が、重大度の変更、例外の承認、オーナーの割り当て、サービスレベルと自律レベルの設定を行えます。すべての編集はドラフトになります。承認されたドラフトはプルリクエストになり、オーナーがマージします。Loomがマージすることはありません。役割は宣言によるものです。

週次のトリアージなどの定例は、組織ごとの設定の一部です。Loomはキューと健全性の指標から毎回の議題を下書きし、カレンダーの招待と、SlackまたはMicrosoft Teams向けのメッセージを用意します。Slackのボットは構築済みです。出典つきで質問に答え、ニーズを登録し、例外の申請をオーナーに送り、議題の下書きをオーナーの承認に回します。

ガバナンスは、本来の仕事を取り巻く事務作業ではありません。チームが一度決めたら、同じことを決め直さずに済むための仕組みです。

今後の予定

• お客様のリポジトリでのリリース。 リリースの自動化がお客様のリポジトリで、リリースチャネルとともに動くようになります。これまではサンプルのシステムで動かしています。
• ブランドのレイヤーごとのトークン。 ブランドのレイヤーごとにトークンを解決し、それぞれの値の出どころを示すようになります。
• 描画された画面での移行シミュレーター。 呼び出し箇所に加えて描画された画面を数え、お客様のプロダクトで動くようになります。これまではサンプルのプロダクトで動かしています。
• Figmaの乖離の受け入れと差し戻し。 Figmaのライブラリとコードが食い違ったとき、オーナーがLoomの中で変更を受け入れるか元に戻すかを決められるようになります。
• お客様のリポジトリでの管理スペース。 編集をお客様のリポジトリでテストし、役割をサインインで確認するようになります。
• 定例をワークスペースで。 Slackのボットが実際のワークスペースで動き、オーナーが承認した議題を投稿するようになります。Teamsにも順次対応します。

よくある質問