用語解説

デザインハーネスとは? AIの出力精度を高め、自社らしいデザインを作る4つの仕組みと始め方を解説

生成AIの進化により、デザインを「作る」コストは大きく下がり、AIに「いい感じのUIを作ってほしい」と伝えれば、それらしい画面が数十秒で出力されるようになりました。

一方で、制作にかかる時間が短縮された分、ボトルネックは生成物の良し悪しを判断することへと移り変わっています。

この課題に対して、AI活用の現場で注目を集めているのが「ハーネスエンジニアリング」です。そして、その考え方をデザイン領域に応用したのが「デザインハーネス」と呼ばれています。

本記事では、デザインハーネスが何を指す言葉なのか、何によって構成されるのか、そして自社で取り組むとしたら何から着手すればよいのかを解説していきます。

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

デザインハーネスとは、企業独自のデザイン判断基準をAIが参照・検証できる形式に整え、誰が制作しても、AIの出力を一定の品質へ収束させるための環境設計です。

前提として押さえておきたいのは、AIの出力は「確率的」であるということです。
つまり、同じ指示を出しても、毎回まったく同じものが返ってくるわけではありません。そのため、指示の精度を高めるだけでは品質を担保するのは困難です。

デザインハーネスは、こうしたAIの性質を踏まえ、AIの外側に管理の仕組みを構築するというアプローチを取ります。具体的には、「制約・情報・評価・修正」という4つの要素でAIエージェントを囲い込むことで、出力を意図した品質へと安定させます。

「ハーネス(harness)」とは、本来、馬の力を目的の方向へ導くための馬具を指します。エンジニアリングの文脈においても同様に、LLMの持つ能力を安全かつ意図通りに引き出すための仕組みをハーネスと呼びます。

代表例としては、ソフトウェア開発における「テストハーネス」が挙げられます。これはモジュール間の複雑な依存関係をコントロールしながら、動作確認を効率化するための環境を構築する存在です。この話を出力が安定しない(確率的な)生成AIに置き換えると、ハーネスの価値は、AIの力を正しく使えるようにするための構造を設計することにあることだと言えます。

デザインハーネスは、この考え方を企業のデザイン領域へ応用したものです。ブランドのトーン&マナー、UI/UXの評価基準、制作上のルールなど、従来は個人やチーム内に限定されていた知見をAIが読める形式へ変換し、生成と改善のサイクルへと組み込んでいくことでハーネスを構築していきます。

なぜ、生成AIにはハーネスが必要なのか

AIの生成物に確信が持てる人はごくわずか

UserTesting社が2026年に公表した調査「Defensible Design in the Age of AI」は、現在のデザイン現場が直面している状況を顕著に示しています。

同調査によると、生成AIの導入により業務速度が向上したと回答した人が91%に達する一方で、成果物の品質に「高い自信がある」と答えた人はわずか15%にとどまりました。さらに、AIの生成物に対して「もっともらしく見えるが検証しにくい」と感じている人が47%存在することも報告されています。

このように、AIによって作業速度が大幅に向上した一方で、「品質に対する確信を持てない」という点が、多くのデザイン組織における共通の課題となっています。

さらに、生成スピードの加速に対してレビュー担当者の数は変わらないため、確認業務が追いつかず、プロセスの停滞という新たなボトルネックも浮き彫りになりました。特にデザイナーリソースが限られた組織においては、この停滞がより顕著かつ深刻なボトルネックとして表面化しています。

プロンプト、コンテキスト、そしてハーネスエンジニアリング

このような状況から、「正しく導くための構造を設計する仕組み」としてのハーネスが重視されるようになりましたが、そのニーズは、AI活用の進化に合わせて変わってきました。

生成AIが普及し始めたころは、AIが単発の質問に応答するケースがほとんどで、「指示の工夫」で十分な効果が得られました。これが「プロンプトエンジニアリング」と呼ばれる技術やスキルです。

その後、AIが高度なタスクを扱うようになるにつれ、プロンプトによる単発の指示文だけで意図した通りの品質や再現性を担保することが難しくなり、どの情報を参照させ、いかなる前提条件を与えるべきかという「コンテキストエンジニアリング」の視点が重要になったのです。

さらに、AIを長時間にわたり自律的に稼働させられるようになった現在においては、指示や情報だけでなく、品質を担保するための仕組みが不可欠となりました。処理の途中で判断の誤りが生じても気付きにくく、気付いた時点では大量の不適切な成果物が生成されている懸念があるためです。

このリスクに対応するために、AIが動作する環境全体の設計、つまりハーネスというアプローチが注目されるようになりました。

環境を変えると結果が変わる

ハーネスの考え方に対し、「出力される生成物の品質の問題は、AIモデル自体の精度に依存するところが大きく、より高性能なモデルが登場すれば解決するのではないか」という指摘もあります。しかし、モデル自体の性能向上を待つだけでなく、モデルを取り巻く環境設計(ハーネス)の改善によっても品質や成果が大きく変化することが、近年のAI開発領域で実証されてきています。

例えばLangChain社は、ベンチマークテストでAIモデルに一切手を加えず、ハーネスの改善だけを繰り返した結果、コーディングエージェントの性能を52.8%から66.5%へと引き上げ、13.7ポイントの改善を発表しました。

注目すべきは、この検証過程でAIモデル自体は一切変更されていない点です。改修を加えたのはシステムプロンプト、ツール群、およびミドルウェアのみ。モデル外部の環境設計を見直すことだけで、この差が生まれたことで、AIを用いた業務効率化の主戦場が「どのモデルを使うか?」ではなく、「AIをどんな環境で用いるか?=ハーネス設計」に移ってきているとも言える結果です。

このアプローチが「ハーネスエンジニアリング」であり、2026年に入ってから開発者のあいだで急速に広まりました。

その中核を成す思想は、エージェントが失敗した際に、同様の失敗が再発しないよう環境側を永続的に改修するという点にあり、AIの成果がモデル自体の性能だけでなく環境設計の品質によって左右されることを明示しました。デザインハーネスは、この環境設計をデザイン領域に適用した概念と言えます。

▼デザインハーネスの一例

デザインハーネスを構成する4つの要素

記事冒頭で触れたように、デザインハーネスは「制約」「情報」「評価」「修正」という4つの要素で構成されます。ここからは、それぞれの要素がデザインハーネスにおいてどのように機能するかを見ていきましょう。


1. 制約:できることを限定する

「制約」は、AIが使ってよいものと使ってはいけないものをあらかじめ決めて、生成の範囲を限定する要素です。自社のデザインにおける「ルール」を定義する層、と言い換えることもでき、制約は「使ってよいものの指定」と「使ってはいけないものの定義」の2つに大きく整理できます。

使ってよいものの指定

例えば、生成に使うコンポーネントやカラー、デザイントークンを、自社のデザインシステムに定義されているものだけに限定することが該当します。余白やフォントサイズも、「余白を広めに」といったあいまいな指示ではなく具体的な値で渡します。解釈の余地がなくなるため、意図しないパーツや独自のスタイルが紛れ込むのを防げます。

ルールの対象は見た目だけではありません。「こういう場面ではこのような言い回しを使う」といった言葉づかいも制約として定義することが可能です。

使ってはいけないものの定義

AIの生成物は、過度なグラデーションや不要な装飾など、要素を「足す」方向に寄る傾向があります。こうした使ってはいけないデザインパターンや非推奨の仕様を明文化して制約に組み込み、足し算を防ぐことが重要です。

これら2つの制約を作る材料として最も確実なのは、既存のデザインシステムと実装コードです。これに加えて、トーン・オブ・ボイスのガイドラインなど、社内で明文化されている自社固有のルールも材料になります。

2. 情報:何をすべきかを知らせる

「情報」は、そのデザインが誰の、何のためのものかという前提(コンテキスト)をAIに知らせる要素です。

人間のデザイナーは、画面をつくる前に「このサービスのユーザーは誰か」「どんな悩みを抱えているか」「この画面で何を達成してほしいか」を踏まえています。こうした前提がAIに渡せていなければ、制約のルールは守れていても、目的からずれた画面が生成されてしまいます。

AIに渡す情報には、次のようなものがあります。

  • ペルソナ(ターゲットと、その悩み)
  • ユーザーストーリーと、提供価値・体験の変化
  • サービスとして追っているKPI
  • 既存画面や画面の型(パターン)の意図
  • 過去の意思決定ログ(その画面をなぜその構成にしたか)

これらの情報は、段階を踏んで集めていきます。まずは、すでに明文化されているドキュメントを整理します。次に、ベテランデザイナーをはじめとする現場メンバーにヒアリングし、普段の思考プロセスや業務フローを言語化し、それでも言葉にしきれない判断は、実際にハーネスを使いながら集めます。生成されたものを見て「ここが違う」と教えていくことで、少しずつ蓄積されていきます。

なお、集めた情報をすべて常に読ませる必要はありません。AIが起動時に必ず読む入り口と、必要なときだけ参照する詳細情報を分けておくと、重要な指示がほかの情報に埋もれるのを防ぐことができます。

3. 評価:正しくできたかを確認する

「評価」は、生成されたものが「制約」「情報」で定義したルールを守れているかを確認する要素です。

評価の仕組みは、かけるタイミングによって2種類あります。1つは、生成時にルールを効かせて、そもそも外れたものを作らせない仕組みです。もう1つは、生成後に成果物を検証し、ルール外の値やパーツが使われていないかを確かめる仕組みです。

また、デザインにはプログラムと違って、機械的に判定できる項目と、判定に解釈を伴う項目が混在しています。そこで、検証する項目を次の3つの機構に振り分けます。

  • 機械処理:指定外のカラーやコンポーネントの使用など、CIやリントで機械的に判定できる項目
  • AI処理:トーンや型の意図に沿っているかなど、AIがルールを参照して判定する項目
  • 人間処理:まだルールとして言語化できておらず、人の目で確認する項目

ここで大事なのは、評価の対象はあくまで「定義済みのルールが守られているか」だという点です。言語化できていない判断をAIに採点させるわけではありません。

ルールになっていない判断は人間処理に残し、言語化できたものから順にAI処理・機械処理へ移していきます。そうすることで、使うほどに人間が直接確認すべき範囲が狭まっていきます。

公開前の品質を何をもって「OK」とするかが言語化されていなければ、良し悪しを判定できるのは今の担当者だけのままです。評価の設計は、この「OKの基準」を組織の言葉にしていく作業でもあります。

4. 修正:フィードバックし、自己修正する

「修正」は、評価で見つかったズレを直し、その理由を記録して次の生成に活かす要素です。修正は、時間軸の異なる2つのループで動きます。

その場で直す:AIによる自己修正

評価でNGが出たら、AIが評価結果を読んで自ら修正し、再生成します。再生成の手順をあらかじめ組んでおけば、ルールから外れたものが人間のレビューに届く前に直します。

次に生かす:記録とルールへの昇格

AIが修正した内容と、人間がフィードバックした内容を、それぞれ理由とセットで記録に残します。記録が貯まると、組織の中で何度も同じフィードバックが繰り返されている箇所が見えてきます。そうした内容を「制約」や「情報」に追記したり、「評価」のチェック項目に加えたりすることで、個別の指摘が組織のルールへと昇格していきます。

修正層をつくる作業の中心は、この記録を残す場所と、ルールに昇格させるまでのフローをあらかじめ決めておくことです。記録の見直しは月に1回など定期的な運用にしておくと続けやすくなります。

ここまで見てきた4つの要素は、それぞれ独立して機能するものではありません。「制約」と「情報」を与えて生成し、「評価」でズレを見つけ、「修正」で直して記録し、環境そのものを更新していく。このループを何周も回しながら、ルールや渡す情報を磨き続けることが、デザインハーネスの本質と言えます。

デザインシステムとデザインハーネスの関連性

デザインハーネスの4要素に基づいて整理すると、ブランドガイドラインやデザインシステムといった既存アセットとの相違点や関係性が明確になります。

前提として、一般的なデザインシステムは「制約」に該当するアセットを既に保持しています。「情報」についても、デザイン原則やコンポーネントの使い方の意図など、一部はデザインシステムに含まれています。

デザインシステムは、デザイン原則やUIコンポーネントを標準化することで組織内の共通理解を形成し、一貫性のあるデザイン構築を支える重要な役割を果たしてきた一方で、「評価」や「修正」の仕組みといった、ルールの準拠確認や外れたケースの再フィードバックは、人間の目視確認や手作業に依存していました。

このように、従来のガイドラインやデザインシステムは「ルールの規定・維持」に長けている一方で、AIが自律的に稼働する環境において「判断の背景となる評価や検証のプロセス」を学習し、資産として自動蓄積していく循環構造は持っていません。

デザインハーネスは、プロダクトの前提をAIに渡すことと評価・修正を通じたノウハウの蓄積を補完する役割を果たし、AI時代に対応した次世代のデザイン業務基盤へと進化させることができます。

デザインハーネス構築の始め方

デザインハーネスの構築は、まず自社の現状を確かめるところから始まります。着手する前に、4つの要素それぞれについて次の問いを確認してみてください。

  1. 制約:対象サービスの色やフォント、余白、守らせたいルールは言語化されているか
  2. 情報:普段、何を前提にデザインをつくっているか(ターゲット、その悩み、提供価値、体験の変化など)。それは言語化されているか
  3. 評価:公開前の品質を、何をもって「OK」としているか。それは言語化されているか
  4. 修正:普段、人やAIに伝えているフィードバックは、どこかに蓄積されているか

これらの問いに即答できないところが、デザインハーネスを始める第一歩になります。たとえばルールが定まっていなければ評価の仕組みはつくれず、記録が残っていなければ、何をルールに昇格させるべきかも判断できません。

初期段階から完ぺきを求める必要はありません。4つの要素を少しずつつくって貯めながら、何周も回してルールや渡す情報を磨いていくうちに、評価・修正が機能し始めます。

注意すべき点としては、ハーネスはあくまで環境設計のフレームワークのため、何を制御し、どのように評価するかという設計原則がないままツールを導入しても、本質的な成果には結びつかないということです。

あわせて確認しておきたいのが、デザインシステムやデザイン資産の整備状況です。既存のアセットがどの程度整っているかによって、必要な作業が変わります。例えばUIデザインの場合は、次の通りです。

グッドパッチが取り組んだ事例

ここからは、グッドパッチが支援・実践してきた取り組みの中から、生成AIをデザイン業務フローへ組み込んだ事例を紹介します。

対象となる領域はUI開発、ブランド表現、デザインシステムとさまざまですが、いずれも「判断基準をAIに渡し、出力を確かめ、見つかった問題を仕組みに書き戻す」という構造を実現した事例です。

事例 概要
エス・エム・エス「カイポケコネクト」 デザインシステムを土台に、UIデザイナーが生成AIで画面の実装まで担う開発体制を構築
コクヨ「TEAMUS」 ブランドガイドラインを生成AIツールに組み込み、誰が書いても「TEAMUSらしい」表現に整う仕組みを構築

UI開発の事例:エス・エム・エス「カイポケコネクト」

Figmaを使わずClaude Codeを使ってデザインと開発を一緒に進めたファイルアップロード画面

出典:UIデザイナーがいかにして「開発」まで越境したか? 「カイポケ」開発メンバーに聞く、生成AI時代の画面開発の新常識

「カイポケコネクト」のリニューアルでは、フロントエンドエンジニアのリソース不足をきっかけに、グッドパッチのUIデザイナーがClaude Codeで画面の実装まで担う体制に切り替えました。

デザインシステムのコンポーネントを使ってAIがコードを生成し、デザインレビュー用のスキルとビジュアルリグレッションテストで確認することで、実装時のUI崩れやスプリントレビューでのデザインに関する指摘を、ほとんどなくすことに成功しました。

現在はその土台を生かし、グッドパッチと共にデザインハーネスの構築が進行中です。実際にハーネスを活用した画面づくりも始まり、今後はデザインハーネスを通じて誰もが自社らしいデザインを安定して出力できる環境を整え、デザインシステムを「組織全員のもの」として活用するフェーズへ進んでいます。

\デザインシステムを土台にしたAI駆動の開発体制が分かる/

ブランド表現の事例:コクヨ「TEAMUS」

コクヨ株式会社(ブランディング支援)メインビジュアル

出典:コクヨ株式会社|ファンを生む「TEAMUS」のブランドづくり〜マーケティング伴走支援

コクヨの「TEAMUS」では、整備したブランドガイドラインが日常業務で参照されず、資料の表現にばらつきが残っていました。そこでグッドパッチは、ブランドのルール(Tone of Voice)を生成AIアシスタント「Gemini」のGem機能に組み込み、資料や文章の表現を確認できるツールを制作しました。

ブランドの判断基準を情報として渡し出力を評価する仕組みを、ライティングの領域で実装した例です。ツールは営業やマーケティングなど部署を問わず活用され、目線合わせにかかる時間も大幅に減りました。

\ブランドガイドラインをAIで実務に定着させた事例が分かる/

AI前提のUI/UXデザイン業務基盤の作り方を、実物のデモで解説【セミナーアーカイブ公開中】

自社らしさを満たしたデザインをAIで生成するための業務基盤とはどういうものか、具体的な手順まで紹介しています。ぜひご覧ください!

AI×UIデザイン ─ 組織全員の”スピードと再現性”が変わる AI前提のUI/UXデザイン業務基盤のつくり方

デザインハーネスの構築を相談する

グッドパッチでは、デザインハーネスの構築・運用支援ソリューションを提供しています。貴社におけるAIデザイン環境状況を診断した上で、最適なご提案をいたします。

詳細なサービス内容をまとめた資料をご用意しておりますので、ぜひご活用ください。