AIエージェントにUIやコピーを書かせると、同じ指示でも返ってくるものが毎回違います。プロンプトを詰めても、翌日には別のものが出てくる。仕組みの側で抑えたいけれど、何をどこまで決めればいいのか分からない。
デザインハーネスは、そこに対する答えとして出てきた言葉です。制約と文脈で出力を方向づけ、検証し、結果を仕組みに戻す。馬具のハーネスは馬の力を止めず、向きだけを決める。そこから来た比喩です。
デザインハーネスとは何か
デザインシステム、設計知識、検証、ワークフローへの組み込みまでを束ねた、デザインをAIエージェントと一緒に進めるための仕組み全体を指します。国内で体系立てて説明したのは Lumilinks inc. 代表のこぎそ（小木曽槙一）で、2026年5月8日に note と X で発表しました。
- 制約するトークン、コンポーネント、パターン、禁止する表現やUI。エージェントが選べる範囲を先に狭めます。 ここに書けるものが無ければ、あとの3層は動きません。
- 文脈を渡す設計原則、意思決定の記録、ユーザー像、既存画面。制約が「してはいけないこと」なら、文脈は「なぜそうなっているか」です。 過去に却下した案とその理由もここに入ります。
- 検証するトークン準拠、アクセシビリティ、文字溢れ、フローの理解しやすさ。出てきたものを、決めた範囲に収まっているかで見ます。 この4つは性質が違うものが混ざっていて、実装で最初に詰まる層です。
- フィードバックするレビューの指摘を、記録の側に戻します。指摘を直して終わりにせず、同じ指摘が二度出ない形に変える。 直す先は制約層か文脈層です。
4 の指摘が 1 と 2 を書き換える。1回作って終わる仕組みではない
中核に置かれるのはデザインシステムです。参照先が1つにまとまっていない組織では、制約層に書ける材料がそもそも揃っていません。デザインシステム自体の定義と、作ったルールが守られなくなる理由はデザインシステムとは何かに書いています。
記事によって層の呼び方が違う
調べていると、同じ4層のはずなのに呼び名が食い違います。骨格は一致しているので、読み替えの表を先に置きます。
| 出典 | 4層の呼び方 |
|---|---|
| こぎそ（2026年5月8日の note） | 制約する / コンテキストを渡す / 検証する / フィードバックする |
| design-harness.com（Lumilinks inc. 運営） | 制約 / 文脈 / 検証 / 評価 |
| Goodpatch（2026年8月4日の発表） | 制約 / 情報 / 評価 / 修正 |
提唱者本人の note と、本人が運営するサイトの間でも4層目の呼び方が変わっています。定義が対立しているのではなく、用語として固まりきっていない段階です。本人も2026年7月14日の記事で「言葉としてはまだ若い」と書いています。
もう1つ、読むときの前提になることがあります。2026年8月時点で法人が出している説明のうち、独立した発信元は Goodpatch です。design-harness.com と、もう1社のサービスページは、こぎそ本人が運営者かパートナーとして関わっています。同じ説明を複数の場所で見かけても、別々に検証された結果とは限りません。
ハーネスエンジニアリングとの関係
デザインハーネスは、ハーネスエンジニアリングをデザインに応用したものだと説明されます。Goodpatch は自社の発表で「国内外で広まったハーネスエンジニアリングの考え方を応用したもの」と明記しています。
ハーネスという語が先に使われていたのはAIエージェント開発の側です。Anthropic は公式のエンジニアリングブログで、2025年11月26日に長時間動くエージェント向けのハーネス設計について書いています。デザイン側は後発で、対象がコードからデザイン成果物に移りました。
検証層は、そのままでは実装できない
図の 3 に並べた4つを、1つずつ見ていきます。同じ「検証」でも、機械で判定できるものとできないものが混ざっています。
- トークン準拠 — 使われている色や余白が定義済みの値かどうか。値の照合なので機械が判定できる
- アクセシビリティ — コントラスト比や代替テキストの有無は機械で判定できる。読み上げたときに意味が通るかは人が見る
- 文字溢れ — 想定文字数を超えたときに崩れるかどうか。画面幅と文字数の組み合わせを回せば機械が出せる
- フローの理解しやすさ — 機械では判定できません。「この導線は分かりにくい」は基準に落ちない
つまり検証層を実装すると、判定が「機械で落とせるもの」と「人が読んで決めるもの」に割れます。そしてハーネスの中身も、機械が読むルールと人が読む文章の2層に分かれます。
Nue はプロダクトの週次レビューをこの形で回しています。UX、UI品質、デザインシステムからの逸脱、アクセシビリティ、コピー、コンバージョンの阻害要因の6観点で見て、機械で判定できる項目は自動化し、UXの妥当性は人が見る。範囲はプロダクト開発支援のページにあります。
この線引きを先にやらないと、判定できない基準まで検査の条件として書かれます。どこまでが自動で落ちて、どこからが人の目なのか。運用する側から見えなくなります。AIに任せたときに速くなる工程と変わらない工程の分け方は、AIコーディングとは何かでも扱っています。
先に止まるのは検証層ではない
検証層は指摘を出し続けます。止まるのは、その指摘を仕組みに戻す層のほうです。提唱者自身が、フィードバックループの仕組みが無ければデザインハーネスとして機能しないと書いています。
兆候は3つあります。
同じ指摘が毎回出るのに、制約層が増えていない。 レビューで「ここの余白が他と違う」「このボタンだけ角丸が違う」が繰り返し出るなら、それは作り手の注意力ではなく、トークンか禁止パターンの側が欠けています。人が毎回口頭で言い続けている状態は、検証層が動いていてもフィードバック層が止まっています。
検証を作った側が自分で採点している。 r.kagaya（Asterminds 共同創業者・CTO）は「"Done" is a claim, not proof（完了は自己申告であって証明ではない）」とし、エージェント自身の検証を自己申告に任せた瞬間にループが弱まると指摘しています。Anthropic も、生成するエージェントとは別に評価専用のエージェントを置く設計を報告しています。エージェントに自分の成果を評価させると、人から見て平凡な出来でも自信をもって称賛する傾向があるためです。
判定は通るのに、見ると違う。 トークン準拠の判定は、参照しているトークン定義が古ければ、古い定義に準拠していることを正しく報告します。検証層が見るのは成果物であって、成果物を作った条件ではありません。判定の記録に「どの定義を、いつ参照したか」を残しておくと、条件が動いたときに後から引き直せます。
作る前に決めておくと、後から効くこと
4層を並べただけでは動きません。運用に入る前に決めておかないと、あとで作り直しになるものが3つあります。
制約層に書ける材料が揃っているか。 トークンとコンポーネントの参照先が1つにまとまっているか。まとまっていなければ、そこが先です。
検証層で機械と人をどこで分けるか。 上の4項目のうち、フローの理解しやすさだけは人に残ります。ここを機械側に書こうとすると、条件に落ちない基準が検査の言葉で書かれます。
指摘を誰がどの頻度で戻すか。 ここは支援を受ける場合も同じです。Goodpatch の発表は「デザインハーネス構築が完了した後も、実業務で新たに生まれたルールや情報をデザインハーネスに反映し、組織に定着するまで継続的に支援します。」と書いています。契約の範囲としては明快ですが、頻度も、誰が見るかも、機械判定と人の判断をどこで分けるかも、公開されている範囲には書かれていません。構築の見積りより先に、この3つを社内で決めておくと後から効きます。
まだ作らない方がいい場合
制約層に書ける対象がまだ無い段階では、検証層は空を打ちます。判定できるルールが1つも無いところに検査を置くと、通ることしか起きません。トークンも共通コンポーネントも決まっていないなら、制約に書けるものを決めるのが先です。
もう1つは、検証の結果を戻す先が決まっていない場合です。指摘を記録の側に戻す担当と頻度が無いなら、検証層は指摘を出し続けるだけになります。デザインシステムを作ったのに使われない状態と、形がよく似ています。
逆に、参照先が1つにまとまっていて、レビューで同じ指摘が繰り返し出ていて、それを誰が記録に戻すかが決められるなら、4層は動きます。順番としては、制約に書けるものを決める、検証で機械と人を分ける、戻す担当と頻度を決める、の3つです。