運用する：定型作業はエージェントに、判断は人に

どのエージェントも、システムを読めます

LoomのMCPサーバーは、AIコーディングエージェントに、推測ではなく実際のシステムを渡します。MCPに対応したエージェントであれば、どのAIモデルのものでも使えます。

サーバーには36のツールがあります。読んでチェックするツールが32、ドラフトを書くツールが4です。書くツールは、自社で有効にするまでオフになっています。

読んでチェックするツール：

• search_system：コンポーネント、トークン、パターンを検索します。確度と、合うものがないときの「強い一致なし」という正直な結果を返します。
• get_entity：コンポーネントのコントラクト（機械可読なコンポーネント仕様）全体を、正確なインポート文とともに読みます。
• get_tokens：トークンの値と役割を読みます。
• get_guidelines：ガイダンスを読みます。ない場合は、ないことがわかります。
• get_rules：すべてのルールと、それを誰がチェックするか、その例外を一覧にします。
• get_design_md：同じ記録から生成した、システム全体をまとめたDESIGN.mdファイルを取得します。
• check_composition：書く前に、ドラフトをチェックします。
• audit_code：既存のファイルの乖離を見つけます。
• intake_need：ニーズが、再利用、拡張、新規のどれにあたるかを判断します。
• list_unmet_needs：エージェントが求めて見つけられなかったものを確認します。
• get_health_history：監査の実行ごとのスコア、領域ごとの推移、前回から何がずれたかを確認します。
• get_flow：オンボーディングや決済などのガバナンスの効いたフローを、ロックされたステップや承認済みかどうかとあわせて読みます。
• search_illustrationsとget_illustration：承認済みのイラストやアイコンを、代替テキストの指針とともに探します。
• search_contentとget_content：ラベルやメッセージの承認済みの文言を、トーン、長さ、複数形とともに探します。
• get_localisation：どの言語が必要か、どの文言がまだレビューされていないかを確認します。
• get_accessibility_passport：コンポーネントのアクセシビリティの記録を読みます。実行したチェック、実行していないもの、最後に確認した日です。
• find_conflicts：互いに、またはすでに下した判断と食い違う提案を、解決案とともに確認します。
• get_version_plan：各パッケージの次のバージョンと、リリースを妨げているものを確認します。
• get_campaigns：組織がいま廃止または導入を進めているものをチームごとに確認し、廃止予定のものをエージェントが新たに使わないようにします。
• get_design_debt：判明しているデザイン負債を、オーナー、規模、経過期間とともに読みます。
• simulate_migration：破壊的変更を承認する前に、その変更がいくつのファイル、呼び出し箇所、プロダクトに及ぶか、どれだけをコードモッドで書き換えられるかを確認します。
• plan_migration：移行を、パッチとプルリクエストの本文、手作業の手順のチェックリストとして受け取ります。何も書き込みません。

ドラフトを書くツール（許可した場合）：

• propose_change：根拠と影響する項目を添えて、ドラフトの提案を作成します。AIが生成したものと明示され、レビューキューに入ります。
• request_exception：理由と終了日を添えて、ルールへの期限つきの例外を申請します。申請は、承認できる人に届きます。
• report_need：システムのオーナーに、足りないものを伝えます。未充足ニーズ・レーダーの集計に加わります。
• draft_branch：変更をドラフトのブランチに置き、ドラフトのプルリクエストを作成します。

書き込みにはすべて、エージェントとモデルの名前が記録され、書き込みログに残り、サイズと頻度に上限があり、エージェントが再試行しても一度しか書かれません。これらのツールが、承認、許可、マージ、リリースを行うことはできません。決めるのは、適切な役割を持つ人です。

ほかに、4つのリソース（システムの概要、すべてのトークン、DESIGN.mdファイル、コンポーネントごとのコントラクト）と、システムの上での組み立てをエージェントに順に案内するプロンプトを一つ提供します。

エージェントの再生（リプレイ）では、スクリプトで動くエージェントが、Loom Base（Loom自身のデザインシステム）でMCPサーバーを使うセッションの記録を、一つずつ順に見られます。各結果は、実際にかかった時間どおりに表示されます。データはサーバーの実際の出力です。

エージェントの再生を見る（英語）

何を直せばよいかを、エージェントに正確に伝えるチェック

check_compositionは、ハードコードされた色や余白、作り直されたコンポーネント、ラベルのないフォームの入力欄、一つの領域に2つある主要なアクション、システムのコンポーネントへのスタイルの上書き、パターンのルール違反を検出し、代わりに何を使えばよいかを伝えます。

2026年10月25日のライブテストでは、新しい請求ページの9件の問題のうち、6件をサーバーが検出しました。見逃した3件はその日のうちに修正し、テストを追加しました。

1import { Card, Button, Heading, Text } from "@loom/base/native";2import { Modal } from "@mui/material";3 4export function DangerZone() {5  return (6    <Card>7      <Heading level={2}>Danger zone</Heading>8      <Text style={{ color: "#1e1a16", marginBottom: 16 }}>Deleting removes every journey in this workspace.</Text>9      <Button tone="primary">Export first</Button>10      <Button variant="danger" tone="primary" onClick={() => setOpen(true)}>Delete workspace</Button>11      <Modal open={open}>Are you sure?</Modal>12    </Card>13  );14}

1import { Card, Button, Text, Stack, ConfirmAction } from "@loom/base/native";2 3export function DangerZone() {4  return (5    <Card title="Danger zone" headingLevel={2}>6      <Stack gap="md">7        <Text>Deleting removes every journey in this workspace.</Text>8        <Button tone="secondary">Export first</Button>9        <ConfirmAction title="Delete the workspace?" confirmLabel="Delete the workspace"10          cancelLabel="Keep the workspace" onConfirm={remove} />11      </Stack>12    </Card>13  );14}

1import { Modal } from "@mui/material";2import { Button } from "@loom/base/native";3 4export function Billing() {5  return (6    <div style={{ padding: "18px", color: "#333" }}>7      <h1>Billing</h1>8      <Button variant="primary">Save card</Button>9      <Button variant="primary">Cancel</Button>10      <Modal open>Card declined. Try again</Modal>11      <input placeholder="Card number" />12    </div>13  );14}

1import { Card, Heading, TextField, Button, Stack, Alert } from "@loom/base/native";2 3export function Billing() {4  return (5    <Card>6      <Stack gap="md">7        <Heading level={1}>Billing</Heading>8        <Alert tone="danger">Card declined. Try another card.</Alert>9        <TextField label="Card number" />10        <Button tone="primary">Save card</Button>11        <Button tone="quiet">Cancel</Button>12      </Stack>13    </Card>14  );15}

1import { Card, Button } from "@loom/base/native";2 3export function NoInvoices() {4  return (5    <Card>6      <img src="/empty-invoices.svg" />7      <h2 style={{ color: "#6b6b6b", marginTop: 24 }}>Nothing here</h2>8      <p>You have not created any invoices yet.</p>9      <Button tone="primary">Create invoice</Button>10      <Button tone="primary">Import invoices</Button>11    </Card>12  );13}

1import { EmptyState } from "@loom/base/native";2 3export function NoInvoices() {4  return (5    <EmptyState title="No invoices yet" description="Invoices you create or import appear here."6      actionLabel="Create an invoice" />7  );8}

自律レベルは、領域ごとにオーナーが決めます

各領域のオーナーは、エージェントにどこまで任せるかを選びます。観察だけから、すべてのチェックに合格した定型的な変更のマージまでです。モードは、観察、提案、ガードレール付き自動、完全自動の4つです。

設計では、どのモードでも、すべての変更はプルリクエストになり、必須のチェックに合格する必要があります。禁止リスト（人だけが行える操作）があり、すべての変更は元に戻せて記録され、組織全体の上限も適用されます。変更が2つの領域にまたがる場合は、より厳しいモードが適用されます。

自律レベルのデモ（今後の予定、サンプルデータ）では、「余白のトークン」という一つの領域を4つのモードに切り替え、変更を流してみることができます。各ステップで、誰が動くか（Loom、人、または誰も動かない）が表示されます。完全自動は、オーナーがリスクの説明を了承するまで有効になりません。

現在、領域ごとのモードは記録として残り、より厳しいモードを適用するルールも機能しています。エージェントが作成したプルリクエストやコメントは、使ったモード、レビューする人、元に戻す方法とともに記録されます。すべての変更は人を待ちます。パイロットでは完全自動は使いません。

自律レベルのデモを見る（英語）

デザイン、コード、コントラクトの間の乖離を見張るセンサー

現在動いているセンサーは1つです。定期的なスキャン（npm run sense、またはCIの週次のスチュワードのジョブ）がシステムを監査し、結果をリポジトリの履歴に保存し、前回から何がずれたかを報告します。段階の低下、コンポーネントの独自の複製の増加、ハードコードされた値の増加などです。しきい値を超えたニーズはドラフトになります。違いはシグナルかドラフトになり、黙って書き換えることはありません。

**対応済み：**必要なときに実行する乖離チェックです。監査、audit_code、ルールのコマンドを使います。ルールのコマンドはエラーが残っているとエラーコードで終了するため、CIで実行できます。すぐに使えるGitHub Actionが、プルリクエストごとにチェックを実行し、エージェントが書いたコードを自社のコントラクトに照らしてチェックします。許可されたコンポーネント、トークン、文書化されたプロパティ、アクセシビリティを、変更された行に限って確認します。

変更は、プルリクエストとして届きます

Loomには、GitHub、GitLab、Azure DevOpsで変更を出すための一つの方法があります。出どころを記したドラフトのプルリクエストを、ラベルつきで作成します。

移行も同じ方法で届きます。npm run migrate -- apply --write --pr suggestで、コードモッドの変更と手作業の手順のチェックリストを含むドラフトのプルリクエストが作成されます。

エージェントの操作は、すべて明示され、記録されます

エージェントが書いたドラフトには、機械可読なラベルがつきます。AIが生成したこと、報告がある場合はAIモデルとプロバイダー、時刻、そしてまだ人がレビューしていないことです。Loomが作成するプルリクエストにはloom:agent-generatedラベルと開示文がつき、ラベルがなければ実行は失敗します。コーディングエージェントが書いたプルリクエストにはai-generatedラベルがつき、レビューにその理由が示されます。

Loomのツールの呼び出しは、すべて実行ログに記録されます。どのツールか、かかった時間、トークン数、費用の見積もりです。呼び出し回数、トークン数、費用の見積もりで実行に上限を設けられ、上限に達するとLoomはそれ以上の呼び出しを拒否します。

FigmaとStorybookにも、同じ情報源から反映します

あるFigma Professionalのファイルで、Loomはトークンをバリアブルとして反映し（現時点ではモードは一つ）、コンポーネントライブラリの一部を生成し、ファイルを読み戻してコードと比べました。Storybookのストーリーはコントラクトから生成します。ただし、お客様自身のシステム向けのストーリーにはまだ対応していません。

誰でも、ふだんの言葉でシステムに質問できるように

デザイナー、ライター、プロダクトマネージャーがふだんの言葉で質問し、システム自身のルールから、それぞれの出典つきで答えを得られるようにする構想です。初期のバージョンはルールを検索して引用しますが、まだ答えを文章にはしません。

コンポーネントごとのアクセシビリティの記録

各コンポーネントには、自社のシステムのテストとコントラクトからつくるアクセシビリティ・パスポートがあります。実行したチェック、キーボードとスクリーンリーダーについてのメモ、カラーモードごとのコントラスト、判明している課題、最後に確認した日です。ライブラリの各コンポーネントのページに置かれ、JSON、Markdown、CSVで書き出せるため、欧州アクセシビリティ法に対応する作業の根拠になります。パスポートはレビューのための根拠であり、適合を宣言するものではありません。

定型作業はエージェントが担います。何を定型とするかは、人が決めます。

今後の予定

• 管理スペースでのエージェントのドラフト。 管理スペースにエージェントのドラフトが表示されるようになります。現在は、レビューキューのファイルとプルリクエストで確認します。
• お客様のリポジトリでのプルリクエスト。 ドラフトのプルリクエスト、ドラフトのブランチ、そのラベルを、GitHub、GitLab、Azure DevOpsのお客様のリポジトリで使います。これまではシミュレーションのGitホストでテストしています。
• お客様のリポジトリでのGitHub Action。 Actionとエージェントのコントラクトテストがお客様のリポジトリで動くようになります。これまでは使い捨てのリポジトリとシミュレーションのGitHubで動かしています。
• センサーの追加。 Figmaの監視とエージェントの利用状況の計測が定期スキャンに加わり、定期的なジョブがお客様のCIで動くようになります。
• 移行のプルリクエストにスクリーンショット。 移行のプルリクエストに変更前後のスクリーンショットが添付され、お客様のリポジトリで動くようになります。
• モードのもとで動くエージェント。 エージェントが、領域のモードの範囲内で自らマージや差し戻しを行うようになります。
• エージェントのプロバイダー設定。 Anthropic Claude、OpenAI、OpenAI互換のゲートウェイ向けに、Loomが動かすエージェントのプロバイダー設定を用意します。
• 手作業でのスクリーンリーダーの確認。 パスポートに、手作業でのスクリーンリーダーの確認が記録されるようになります。

よくある質問