デザインハーネスとは

デザインシステムは、静かに壊れる

見覚えがあるはずだ。エージェントが color.primary トークンを使わず、#3b82f6 を直接書き込む。レビューで気づいて直し、次へ進む。翌週、同じ値が別のファイルで戻ってくる。誰も雑なわけではない。それぞれのエージェントが、直前の判断を知らないまま、単独で「良さそうなもの」を作っているだけだ。そのゆっくりとした乖離には名前がある——デザイントークン・ドリフトだ。

そして積み重なる。3つのセッションがそれぞれボタンを発明し、同じボタンが3種類できる。スペーシングが2ピクセルずれる。diffはGitに残るが、その背後にあった理由は残らない。6週間後に「なぜこのpaddingは14pxなの?」と聞かれ、正直な答えは「誰も分からない」になる。

これはAIの失敗ではない。文脈が欠けているという失敗だ。モデルは、このプロジェクトで「一貫している」とは何を意味するのかを、作業中に実際に読める形で一度も渡されていない。私たちはその欠けている成果物を デザインハーネス と呼ぶ。ここから先は、それが何であり、なぜ地味な部分が効くのか、という話だ。

デザインハーネスとは何か

デザインハーネスとは、トークン・コンポーネント仕様・品質ゲートを、AIエージェントと人間の双方が読める単一のソースにまとめたものだ。

これが必要なのは、AIエージェントが人間のレビュー速度を超える速さと規模でUIを書くようになり、人の記憶や散文ドキュメントにしか存在しない設計意図では、その速度に耐えられないからだ。従来のデザインシステムが人間向けのドキュメントであるのに対し、ハーネスは同じ意図を、人間もエージェントもその中で実装し、そこからの逸脱（ドリフト）を自動で捉えられる形で表現したものだ。

この言葉は馬具から借りている。ハーネスは馬を遅くするためのものではない。乗り手が、大きな力と争わずにその向きを定めるための仕組みだ。手綱は檻ではない。AI駆動開発では、力も速さも本物だ。欠けていたのは、その力と、あなたの意図とを結ぶ、軽くて意識的な接点だった。ハーネスはその接点である——口うるさい規則集ではなく、エージェントがUIを一行書く前に参照する、共有された契約だ。一度書けば全員が読む。コンポーネントを生成するエージェントも、PRをレビューする同僚も、ドリフトを指摘する検査も、同じ一つのソースを読む。単一ソース・複数の読み手。

3つの構成要素と、地味なディテールがなぜ効くか

ハーネスには3つの可動部がある。

1. トークン——語彙。色・スペーシング・角丸・書体を、リテラルではなく名前付きの値で表す。#0a0a0a ではなく color.accent。その参照が壊れると、トークン・ドリフトになる。
2. コンポーネント仕様——文法。Buttonとは何か、そのバリアントと状態、使ってよいトークン、破ってはいけない規則。書き留めれば、それがコンポーネント契約だ。
3. 品質ゲート——校正者。生のhex禁止、スケール外のスペーシング禁止といった機械判定可能な規則。人間向けドキュメントと同じ定義から生成されるので、読む規則と走る規則が食い違うことがない。

重さを支える2つの判断

静かな仕事の大半は、2つの設計判断が担っている。1つ目は 安定ID。すべてのトークン・コンポーネント・ゲートは、名前が変わっても変わらない識別子を持つ。color.brand を color.accent に改名しても、あらゆる参照・記録された判断・過去のドリフトが紐付いたまま残る。名前で紐付ける仕組みは名前が動いた瞬間に壊れる。IDで紐付ける仕組みは覚えている。

2つ目は 二層記録 だ。「何が・どのファイルで変わったか」という事実を、「なぜ変えたか・他に何を検討したか」という文脈とは別に保つ。事実層は決定論的で、モデルが説明を覚えているかに依存しない。文脈層は、理由があるときにそれを添える。分けておけば、説明が欠けても変更の記録は失われない。一緒にすれば、雑なコミット一つで両方が消える。

Figmaでいいのでは?

多くのチームはFigmaでデザインを管理していて、ハーネスはその競合ではない。だが、Figmaファイルは人間が眺めるために描かれたものであって、エージェントが深夜2時に button.tsx を編集しながら読むために構造化されてはいない。エージェントが必要とする情報——正確なトークン、破ってはいけない規則、過去の判断がそう決まった理由——は、キャンバスが運ぶようにはできていない。

だからハーネスはゼロから、テキストで、あなたのリポジトリの中で始める。npx harnd scan が、エージェントが既に作ったアプリを読んでトークンとコンポーネントを抽出する——デザインツールを前提とせず、アカウントも要らず——そしてエージェントがコンポーネントに触れる前に、必要な仕様だけを数百トークンで引ける成果物を生む。Figmaを使っているなら、それでいい。ハーネスは機械可読な契約として隣に共存する。使っていなくても、失うものはない。ハーネスは最初からそれを必要としていない。

私たちはHarnd自身のハーネスの下でHarndを作っている

ここにあるものはすべてドッグフーディングだ。HarndはHarnd自身のハーネスの下で作られている。この記事の色は私たち自身のソースの中のトークンであり、コンポーネントは仕様化され、私たちが出荷しているのと同じゲートが私たち自身のPRに対して走る。上の考え方が抽象的に聞こえたなら、そうではない——それは、このページそのものが書かれた際の規則だ。

もし、このページ冒頭の問題が少しでも他人事に思えなかったなら、それがこの記事の狙いだ。まず最初に壊れる2つの部分から始めてほしい——デザイントークン・ドリフトとコンポーネント契約——あるいは早期アクセスに登録して、エージェントが既に作ったアプリにHarndを向けてほしい。