CursorやClaude Code、FigmaのAI機能を使って、UIのコードや画面を一気に作る場面が本当に増えましたよね。
ただ、実際に現場で使っていると、「AIが作った画面、うちのデザインシステムと微妙にズレてない？」と確認に追われること、ありませんか？
画面を何十枚も一瞬で作れるようになっても、デザイナーが1枚ずつ手作業で目視確認していては、結局そこで作業が止まってしまいます。
そんな「AIが作るUIの品質やルールを、どうやってチームで守っていくか？」という悩みを解く仕組みとして、いまデザイン界隈で注目されているのが「デザインハーネス（Design Harness）」という考え方です。
1. デザインハーネスとは？「AI生成は並列、レビューは直列」の停滞を解く仕組み
AIエージェントが生成するデザインの「妥当性」と「品質」を組織的に担保するための制御・運用基盤です。AIの自由すぎる出力を防ぐ「制約」、意図を伝える「文脈」、機械的にチェックする「検証」、人間がフィードバックする「評価」の4層構造で、高速な並列生成とレビューのボトルネックを解消します。
デザインハーネスは、プロダクトデザイナーのこぎそ（@kgsi）氏が提唱した設計思想です。
AIエージェントにデザイン作業を任せるときに、その出力がチームのルールやブランドのトンマナから外れないよう、あらかじめ外枠で支えてあげる仕組みのことを言います。
2026年に入ってからはグッドパッチ社が支援ソリューションをスタートするなど、現場への導入が一気に現実味を帯びてきました。
この考え方が生まれた背景には、AIツールを導入したチームがほぼ確実にぶつかる「生成は並列、レビューは直列」というリアルな問題があります。
AIに指示を出すと、数十画面のUIやバリエーションがあっという間に並列で作られますよね。
でも、その画面の余白が合っているか、変な色が混ざっていないかをチェックするデザイナーの目は、画面の数だけ増えるわけではありません。
結局、デザイナーが1画面ずつ手作業で確認することになり、AIが速くなればなるほどレビュー待ちのタスクが山積みになってしまいます。
しかも「チームとして何をもってOKとするか」の基準が曖昧なままだと、レビューする人の好みで判断がブレてしまいがちです。
もともと「ハーネス（馬具）」というのは、力強い馬を人間がコントロールして、安全に目的地へ走らせるための道具です。
エンジニア界隈の「テストハーネス（テストを自動で回すための実行環境）」と同じで、パワフルなAIの出力を一定の枠組みで支える仕組みをイメージするとわかりやすいと思います。
AIに「適当にいい感じの画面を作って」と丸投げするのではなく、あらかじめ決めたルールと検証のレールを通すことで、おかしなデザインが出ないように先回りします。
自分自身も現場でAIツールを使うときは、自由気ままに作らせるより、カチッとした制約を渡した方が手戻りが圧倒的に少ないなと実感しています。
2. デザインハーネスを支える「4層構造モデル」
デザインハーネスは、何か特定の有料ツールを指すわけではありません。
AIの出力をうまくコントロールして、日々のデザイン運用に落とし込むための「4層の設計フレームワーク」として整理されています。
「AIにどんな情報を渡して、どうチェックして、どう改善していくか」という一連の流れを4つの階層に分けたものです。
それぞれのレイヤーが担う役割と具体的な要素をまとめると、以下のようになります。
| 構成要素 | 主な役割 | 実務における具体例 |
|---|---|---|
| 1. 制約（Constraints） | AIの自由な出力を制限し、ルールの逸脱を防ぐ | デザイントークン、4px/8pxグリッド、DESIGN.md |
| 2. 文脈（Context） | 画面の目的やユーザー体験の前提を正しく伝える | ユースケース定義、画面遷移フロー、ペルソナ情報 |
| 3. 検証（Verification） | 生成されたUIがルールを満たしているか機械判定する | Figma Linter、CSSバリデーター、アクセシビリティテスト |
| 4. 評価（Evaluation） | 人間の目で体験価値を判定し、改善サイクルを回す | デザイナーによるUXレビュー、ルールへのフィードバック |
まず土台となる第1層の「制約」は、AIが使っていい色やフォント、余白のサイズを最初から絞り込んでおく枠組みです。
デザインシステムに定義されていない謎のカラーコード（いわゆる野良カラー）が勝手に作られるのを、入口の段階でシャットアウトします。
続く第2層の「文脈」は、「この画面は誰がどんな状況で使うものか」という背景情報をAIに共有するレイヤーです。
ただ見た目のパーツを並べるだけでなく、前後の画面遷移やユーザーの目的をしっかり渡すことで、的外れなレイアウトが出てくるのを防ぎます。
そして第3層の「検証」では、AIが書き出したコードやFigmaデータに対して、自動テストや静的解析（lint）を走らせます。
「フォントサイズが基準値と合っているか」「コントラスト比が足りているか」といった機械的に白黒つけられる部分は、すべてここで自動判定します。
こうして機械的なチェックをパスした画面だけを、最後の第4層「評価」で人間のデザイナーが確認します。
「操作していて違和感がないか」「体験として気持ちいいか」という定性的な判断に集中し、気づいた改善点はまた第1層や第2層の指示にフィードバックしていきます。
3. Figmaとデザインシステムを「機械可読なハーネス」にする手順
「考え方はわかったけれど、実際の現場では何から手をつければいいの？」と思いますよね。
一番手軽でおすすめなのが、いまあるデザインシステムを「AIが読めるデータ形式」に整えることです。
人間向けに作った分厚いスタイルガイドを、AIエージェントがそのまま解釈できる形へ落とし込んでいきます。
現場ですぐに取り入れやすい3つのステップを見ていきましょう。
1. Figma Variablesでトークンをかっちり決める
最初の一歩は、Figma上のカラーや余白を「デザイントークン」として整理することです。
カラーコードを生でベタ打ちするのではなく、PrimaryやSurfaceといった役割ベースの変数名で管理します。
変数のルールが綺麗に整っていれば、AIに対しても「ボタンの色は --color-button-primary だけを使ってね」とシンプルに指示を出せます。
これだけで、AIが勝手なカラーコードをでっち上げるミスを一気に減らせます。
2. ルールファイル（DESIGN.md）をプロジェクトに置く
CursorやClaude Codeを使ってUIを組むときは、プロジェクトのルートフォルダに DESIGN.md というルールファイルを1枚置いておくのがおすすめです。
フォントサイズのスケールや余白の基本ルール（4px/8pxグリッドなど）を、簡潔なMarkdownでメモ書きしておきます。
AIエージェントはコードを書くときにこのファイルを自動で読み込んでくれるので、毎回プロンプトに細かな指示を書く手間が省けます。
指示文が短くて済む分、入力トークン数の節約になって生成スピードが上がるのも嬉しいポイントです。
配置場所に迷ったら、まずはプロジェクトのルート直下（./DESIGN.md）に置くのが基本ルールです。AIツールが作業開始時に一番認識しやすい場所だからです。
フロントエンドとバックエンドが分かれているリポジトリなら、フロントエンド側（apps/web/DESIGN.md や frontend/DESIGN.md）、またはコンポーネント管理フォルダ（packages/ui/DESIGN.md）に配置するのが実務上の定石です。
さらに、Claude Codeの CLAUDE.md や Cursorの .cursorrules の中に「UIの実装時は DESIGN.md のルールを参照すること」と1行メモを添えておくと、AIが確実にルールを優先して読み込んでくれます。
3. プラグインやテストで機械的に自動チェックする
画面が出来上がってきたら、Figmaプラグイン（Figma Linterなど）を使ってワンクリックでスタイル違反をスキャンします。
未登録のフォントや勝手な余白が使われていれば、その場ですぐにアラートを出して修正できます。
「1pxズレていないか」「スタイルが合っているか」を目を凝らして探す作業は、ツールに任せてしまえばいいんですよね。
機械でできるチェックを自動化するほど、デザイナーは「本当に使いやすいUIになっているか」という本質的な体験設計に時間を使えるようになります。
デザイントークンを破綻させずに運用するVariablesの設計ルールについては、こちらの記事で具体的な命名のコツをまとめています。
4. デザイナーの役割の変化：パーツの配置者から「ハーネス設計者」へ
デザインハーネスが浸透してくると、現場のデザイナーに求められる動き方も少しずつ変わっていきます。
これまで時間をかけていた「ボタンやテキストを1px単位で並べる作業」は、AIエージェントにどんどん任せられるようになっていきます。
その代わり、デザイナーの大事な役割になっていくのが、「AIが迷わずにクオリティの高いUIを作り続けられるよう、ハーネス（ルールシステム）を整えてあげること」です。
部屋の壁紙を自分で1枚ずつ貼る作業から、建物全体の設計図を引いて安全基準を決める建築家のような立ち位置にシフトしていく感覚に近いかもしれません。
実務では、特に次のような領域が大切になってくると感じています。
- トークンと変数のルール設計: 画面数が増えても破綻しない、すっきりとした変数構造を組み立てる。
- 品質の合格ラインの言語化: どんな状態ならチームとしてリリースOKなのか、判断ロジックを整理する。
- フィードバックによるルールの更新: AIが間違えた箇所を分析して、DESIGN.mdや指示文を微調整していく。
デザインエンジニアの台頭と、溶け合うデザインとコード
こうした流れの中で、国内外の現場でいま急速に数が増えているのが「デザインエンジニア（Design Engineer）」という職種です。
これまでは「Figmaで画面を作るデザイナー」と「それをコードに落とし込むエンジニア」で分業するのが当たり前でした。
しかし、AIツールがFigmaデータから直接コードを書き、コードからUI画面を一瞬で生成する時代になったことで、デザインと実装の境界線が一気に溶け合っています。
Figma Variablesなどのデザイントークンを理解しつつ、それをDESIGN.mdやコード側のLint・テスト（ハーネス）として落とし込める人材の需要が急増しているんですよね。
自分自身も現場で作業していて、「画面を作る作業そのもの」よりも「Figmaとコードの間でルールが破綻しないよう仕組みを整える役割」がどんどん重要になっているのを強く実感しています。
最初から完璧な仕組みを作る必要はないので、まずは普段よく使う余白やカラーのルール化から気軽に試してみるのがおすすめです。
まとめ：適切な制約が、AIとの共創をスケールさせる
デザインハーネスは、AIの自由を奪って窮屈にするためのルールではありません。
しっかりとした安全帯（制約）があるからこそ、AIは迷わずに素早く画面を作れますし、人間も安心してその出力をレビューできます。
「生成は一瞬、でも確認に追われて疲弊する」という悪循環を抜ける鍵は、レビューを人間の根性で乗り切るのではなく、仕組みで軽くしていくことです。
制約、文脈、検証、評価という4つの層を意識しながら、日々のデザインシステムをAI時代に合わせて少しずつ育てていきましょう。
まずはプロジェクトに小さな DESIGN.md を1枚置いてみる。そんな身近な一歩から、AIとの気持ちいいチームプレイを始めてみてくださいね。
次のステップ：あわせて深掘りしたい知見
デザインハーネスの土台となる「崩れないUI構造」や「OS標準のガイドライン」を把握しておくと、ルール作りの解像度がさらに上がります。
現場の実務ですぐに役立つ記事をピックアップしましたので、ぜひあわせてチェックしてみてください。
オートレイアウトを使った崩れないフレーム設計の手順は、こちらの記事でステップ順に詳しく解説しています。
Appleが定めるOS標準のタップ領域や文字基準については、以下の実務ガイドで数値を整理しています。
