デザインハーネスとは｜AIにデザインを任せても崩れない仕組み
-
Etsuko Mera - 30 Sep, 2026
はじめに
こんにちは、広報・制作担当のmeraです。
AIにバナーや図版を頼むと、1枚目はいい感じに仕上がる。ところが2枚目、3枚目と頼むうちに、色が少しずつずれ、文字の大きさが変わり、気づけば別のブランドのような見た目になっている。そんな経験はありませんか。
私はこれを、プロンプトの書き方が悪いせいだと思っていました。でも最近、そうではないと考えるようになりました。問題はAIの腕ではなく、AIの周りに何を用意しているかのほうにある。その考え方に名前を付けたのが「デザインハーネス」です。
この記事でわかること
- デザインハーネスとは何か、どこから来た言葉なのか
- デザインハーネスを形づくる4つの層
- ブログのTOPページをFigmaデザインに作り替えたときに、実際に効いたこと
- 明日から小さく始めるための3つの手順
デザインハーネスとは、AIを迷わせないための「周りの仕組み」のこと
先に結論を書きます。デザインハーネスとは、AIにデザインを任せるときに、ルール・前提知識・チェックの仕組みをAIの外側に用意しておく考え方です。AIそのものを賢くするのではなく、AIが働く環境を整えることで、仕上がりを安定させます。
もとはエンジニアリングの言葉「ハーネスエンジニアリング」
「ハーネス」という言葉は、2026年に入ってからAIエージェントの開発現場で広く使われるようになりました。2月にはOpenAIが、人間がコードを1行も手で書かずにAIエージェントに製品を作らせた社内実験を「Harness engineering」という記事にまとめています。5か月でおよそ100万行。そこで人間が担ったのは、コードを書くことではなく、環境を設計し、意図を伝え、フィードバックの仕組みを作ることでした。
ソフトウェア開発の論考で知られるMartin Fowler氏のサイトでも、Thoughtworksのビルギッタ・ベッケラー氏がこの考え方を整理しています。その中では、ハーネスという言葉が「AIエージェントのうち、モデル以外のすべて」を指す略語として広まってきた、と説明されています。
つまり、AIエージェント＝モデル（頭脳）＋ハーネス（それ以外の全部） という見方です。同じモデルを使っていても、ハーネスの出来によって結果が大きく変わります。
そのデザイン版を提唱したのが、こぎそさん
このハーネスの考え方をデザインの領域に持ち込んだのが、デザイナーのこぎそさん（株式会社Lumilinks）です。2026年5月にnoteで「デザインハーネスとは何か」を公開し、9月5日にはProduct Engineering Conference 2026で「デザインハーネス 〜AIが生成する”デザイン”の妥当性を、誰がどう担保するのか〜」と題して講演しています。
解説サイト design-harness.com では、デザインハーネスを次のように説明しています。
AIエージェントの力を人の判断で御しながら、デザインプロセスを前に進めるための考え方
ポイントは「人の判断で御しながら」という部分です。AIに丸投げするのでも、AIを使わないのでもない。AIの速さは活かしつつ、最後の判断は人が持つ。その中間を仕組みで支えるのがデザインハーネスです。
ハーネスの語源は「馬具」
英語の harness は、もともと馬に付ける馬具や、高所作業の安全帯を指す言葉です。
馬具は、馬を縛りつけるための道具ではありません。馬の力を、行きたい方向へ無駄なく伝えるための道具です。AIも同じで、力が強いぶん、向きを与えないとあちこちへ走り出してしまいます。デザインハーネスは、AIの自由を奪うものではなく、AIの力を正しい方向へ通すためのものだと考えると分かりやすいと思います。
デザインハーネスは「制約・文脈・検証・評価」の4つの層でできている
こぎそさんの整理では、デザインハーネスは4つの層で構成されます。
| 層 | 役割 | 具体例 |
|---|---|---|
| 制約 | やっていいこと・いけないことを決める | 色やフォントの指定（デザイントークン）、使ってよい部品、禁止事項 |
| 文脈 | 判断の材料を渡す | デザイン原則、過去の決定の記録、想定読者、既存の画面 |
| 検証 | できたものをチェックする | 色がルール通りか、読みやすいか、文字があふれていないか |
| 評価 | 結果をルールに戻す | レビューで出た指摘や失敗パターンを、ルール集に書き足す |
制約は、AIに「ここからはみ出さないで」と伝える柵です。色をカラーコードで、文字サイズを数値で決めておくと、AIは迷わずその値を使います。
文脈は、AIに「なぜそうするのか」を伝える材料です。同じ色の指定でも、「このブログは専門的な内容を、やさしく伝えたい」と分かっていれば、AIの判断はそちらに寄っていきます。
検証は、できあがったものを確かめる工程です。人の目で見ることもあれば、スクリーンショットを並べて比べたり、ツールで自動チェックしたりすることもあります。
そして一番大事なのが評価です。崩れたところを直して終わりにせず、「なぜ崩れたか」をルールに書き足す。こぎそさんは、このルール集を DESIGN.md というファイルにまとめる方法を紹介しています。こうすると、同じ失敗は二度と起きにくくなります。4つの層は一方通行ではなく、評価から制約へ戻るループになっているのです。
プロンプトを工夫するだけでは、なぜ足りないのか
「だったら、プロンプトを丁寧に書けばいいのでは」と思うかもしれません。私も最初はそう考えていました。
でも、プロンプトとハーネスには決定的な違いがあります。
| プロンプトの工夫 | デザインハーネス | |
|---|---|---|
| ルールが残る場所 | その会話の中だけ | ファイルとして環境に残る |
| 次の依頼では | また一から伝え直す | 自動で読み込まれる |
| 失敗したとき | その場で直してもらう | ルールに書き足して、次から防ぐ |
| 担当者が変わると | 書き方の差がそのまま出る | 同じルールで動く |
プロンプトは、その場かぎりのお願いです。どれだけ上手に書いても、会話が終われば消えてしまいます。一方ハーネスは、環境そのものに残るルールです。だから、何度頼んでも同じ前提から始められます。
毎回うまく頼む技術より、毎回同じ前提で始められる環境のほうが強い。これがデザインハーネスの核心だと私は理解しています。
【実例】ブログTOPページのFigma化で、デザインハーネスが効いた
ここからは私自身の話です。
このブログのTOPページを、Figmaで作ったデザインに作り替えました。ヒーローエリア、「注目の記事」、記事カード、右カラムのバナーや筆者一覧、ページ送り。ヘッダーとフッターも含めて、見た目をほぼ入れ替える作業です。実装はClaudeと一緒に進めました。
振り返ってみると、4つの層がそれぞれちゃんと働いていました。
制約：色とフォントは設定ファイルにあった。ただし穴もあった
このブログには、テーマカラーやフォントを数値で定義した設定ファイルがあります。メインカラーはカラーコードで1つに決まっていて、フォントも1書体です。ナビのホバー下線や記事カードのアクセントは、この値から作られています。
ただ、あとから見直すと穴も見つかりました。文字や背景に使うグレーは、設定ファイルに定義がありませんでした。そのため新しいパーツでは、Figmaから読み取ったグレーの値が、それぞれのファイルに直接書き込まれています。いまの見た目に問題はありませんが、次に色を調整するときは何か所も直すことになります。
制約に書いていないことは、AIもその場の判断で埋めるしかありません。次にやることは、このグレーを設定ファイルに足すこと。後で出てくる「評価」から「制約」へ戻るループの出番です。
文脈：Figmaのデザインと、CLAUDE.md
見本になるFigmaのデザインがあったことは、何より大きかったです。言葉で「おしゃれな感じに」と伝えるより、完成形を見せたほうが早く、ずれもありません。
もう一つは CLAUDE.md です。これはAIに向けた「このリポジトリの取扱説明書」のようなファイルで、記事の命名ルールや下書きの扱いが書いてあります。以前、奮闘記 #6 で「CLAUDE.mdを育てる」という話を書きましたが、あのとき育てたファイルが、今回もそのまま前提として働いてくれました。
検証：PCとスマホのキャプチャを並べて見る
作ったページは、PC幅とスマホ幅でキャプチャを撮り、Figmaのデザインと見比べながら直していきました。特にメニューはスマホ表示で崩れやすいので、並べて比べる確認を何度か繰り返しています。
コードは読めなくても、画像を並べれば違いは分かります。ノンエンジニアの私にとって、この「目で見て検証できる」形にしてもらったことが一番助かりました。
評価：決めたことは、ファイルに書いて残す
作業の途中では、いくつも判断が必要になりました。たとえば「注目の記事」は自動で選ぶのか、手で選ぶのか。私は記事ごとに手動で指定する方式を選びました。
こうした決定は、会話の中だけで終わらせず、設定ファイルに残しています。右カラムのバナーや「よく読まれている記事」の設定ファイルには、冒頭に「このファイルは何のためのものか」「画像の推奨サイズ」「どの順に並べるか」といった説明が書き込まれています。次にAIがこのファイルを触るときも、私が触るときも、同じルールで迷わず動けます。
気づいたら、ほかにもハーネスがあった
TOPページに限らず、このブログの制作には、いつのまにか小さなルールがたまっていました。
- 図版のトンマナは、ネイビーとオレンジの2色に固定したプリセットを使う
- 文章では、AIっぽさが出るダッシュ記号を使わない。タイトルの区切りは「｜」
- 記事の画像はJPEGで、横幅は最大1600px（サーバーの転送量を抑えるため）
- 記事は、構成案を承認してから本文を書いてもらう
どのルールも、最初から計画して作ったものではありません。一度崩れたり困ったりしたから、書き足したものです。こぎそさんの4つの層でいえば、「評価」が私の知らないうちにハーネスを育てていた、ということになります。
明日から始めるなら、この3つだけでいい
デザインハーネスと聞くと大がかりに感じますが、最初は小さくて大丈夫です。
1. 色とフォントを、数値で書き出す 「落ち着いた青」ではなく、カラーコードで書きます。フォント名とサイズも同じです。これだけで、AIの出力のブレはかなり減ります。
2. やってはいけないことを、1枚にまとめる 「この色は使わない」「この言い回しは避ける」など、禁止事項を短いメモにします。AIに依頼するときは、毎回そのメモを読み込ませます。Claudeなら、CLAUDE.md に書いたことは毎回自動で読み込まれます。スキルに書いておけば、関係する依頼のときに読み込まれます。
3. 崩れたら、直すだけで終わらせない 崩れたところを直してもらったら、「次から同じことが起きないように、何をルールに足せばいいか」を一緒に考えます。この1行の追加を続けることが、ハーネスを育てることそのものです。
まとめ
- デザインハーネスとは、AIにデザインを任せるときに、ルール・前提知識・チェックの仕組みをAIの外側に用意しておく考え方。
- 構成は「制約・文脈・検証・評価」の4層で、評価から制約へ戻るループが肝になる。
- 完璧なハーネスを最初から作る必要はない。崩れるたびにルールを1行足していけば、自然に育っていく。
次に読むのがおすすめの記事
参考文献・出典
- こぎそ「デザインハーネスとは何か」（2026年5月8日） ／ note
- こぎそ「デザインハーネス 〜AIが生成する”デザイン”の妥当性を、誰がどう担保するのか〜」Product Engineering Conference 2026（2026年9月5日） ／ Speaker Deck
- デザインハーネス 解説サイト ／ design-harness.com
- OpenAI「Harness engineering: leveraging Codex in an agent-first world」（2026年2月11日） ／ openai.com
- Birgitta Böckeler「Harness engineering for coding agent users」（2026年4月2日） ／ martinfowler.com
アイキャッチ・図版は、特記のない限りAIで生成した画像を画像編集ソフトで加工して制作しています。人物・イベントの写真は実際に撮影したものです。