【イベントレポート】人間のレビューなしで"そのまま出せる"デザインは作れるか こぎそさんに聞く デザインハーネスの現在地

AIコーディングエージェントを使えば、画面はいくらでも速く作れるようになりました。では、その画面は人の目を通さずに、そのまま出せるのでしょうか。

モデレーターを務めた株式会社overflow 取締役CTOの大谷も、社内ツールや個人アプリの画面をAIに作らせ、DESIGN.mdを書き、文字と背景のコントラスト検査をCIで回しています。

それでも最後は自分の目で直していて、この1か月ほどで直した箇所は160個ほど。しかも「デザインが足りない」ではなく、「多すぎるから削って」という指摘ばかりだったといいます。

2026年10月15日の #Offers_DeepDive では、「デザインハーネス」という考え方を定義した、株式会社Lumilinks 代表取締役 / デザイナーのこぎそ様をお迎えしました。

LTでデザインハーネスの考え方とデモを紹介いただき、後半は「何ができれば90点なのか」「ルールが増えすぎたらどうするか」といった現場の問いに答えていただきました。

人間のレビューなしで出せるのは「部分的に」

生成は並列、レビューは直列。ボトルネックは実装から判断へ

妥当の定義がない組織では、人を増やしても解けない

デザインの判断基準・文脈・検証を、AIが扱える状態にする

コードのテストハーネスに対応させて考える

制約・コンテキスト・検証・評価の4層モデル

デモ用デザインシステムで見る、ハーネスありとなしの差

判断基準は、レビューコメントにある

指摘を4つに振り分け、ステップごとにフィードバックする

小さく始めて、合格の範囲を広げていく

AIと相性が良い領域、人と相性が良い領域

「90点」の基準は、ハーネスではなく人が持つ

――大谷：ここからはディスカッションです。LTでは「合格」という言葉で、ルールを通過した状態を説明していただきました。

AIが作ったUIを前にして「90点だ、このまま出せる」というのは、ルールに全部合格した状態のことでしょうか。それとも、合格の先にまだ評価基準があるのでしょうか。

こぎそ様：90点とは何でしょうね。

――大谷：ハーネスでは、どんな観点を見ているのでしょう。チャットでは「0.5pxまで見ないと」というコメントもありましたが、そこまで細かくカバーするものですか。

こぎそ様：そこまで細部の仕事をしたいなら、人間がやった方がいいと思っています。デザイナーとしてあるまじきかもしれませんが、細部に神が宿るような仕事に、正直あまり価値を感じていません。これは基本的に、大量生産をするための装置です。

だから90点以上を目指さなくてもいい。僕なら80点や70点、なんなら60点でもいいくらいです。AIがない時代は、デザイナー以外が作ったり、コードが分からないデザイナーが作ったりすると、30点や70点ということも結構ありました。

それが下駄を履いて、点数が高くなってきています。そこはまず、AIの恩恵を大きく受けているところです。

高得点を取りやすいのは、ルールが決まった同じような画面

こぎそ様：90点や80点を取れるのは、ルールがはっきり決まっていて、同じような画面であることが多いものです。デモで見せたテーブルの一覧やモーダルダイアログは、ほぼ80〜90点を出せています。

一方、新しいサービスを生み出すときや、まったく見たことがない画面を作るときは、AIもかなり適当なものを出してくるし、人間側も分からないので、なかなか先に進みません。

そういうところでは、人間がうまく扱える操作体験や画面操作の設計になっているかが評価軸になる気がしています。AIが作ったものは認知負荷が高く、そのまま使えるものは少ない。特に学習していないであろう画面は、人間が評価軸を作って検証すべきでしょう。

――大谷：デザインハーネスは90点を目指すものではなく、デザインの規律をチェックし、制御する仕組みである。90点という判定は、人が言語化してやるべきだということですね。

こぎそ様：そうですね。指示すればAIは10点、20点と点数を出してくれますが、その点数をどう決めているのかという話なんです。長文でいっぱい返ってくると、何が書いてあるのか分からなくなりますよね。

点数は難しいのですが、基準を持つのは人間の側です。会社や組織によるのではないでしょうか。

人が判断を残すのは、見たことのない画面と機能

――大谷：次のテーマは「人間が介在すべき領域はどこか。AIで完全に自動化できる部分と、人間が判断を残すべき境界線の引き方は」です。その線は最初に決めておくのか、レビューの指摘を振り分けながら動かしていくのでしょうか。

こぎそ様：これまで、手数がかかるのに人間がやるべきではない仕事がありましたよね。例えば、色やサイズのトークンをチェックして、コードやFigmaに人間がポチポチ当てはめていく作業です。あれは本当にやるべきではありません。

誰がやっても同じで、それ自体の価値が低い作業もそうです。画面のルールに従ってコンポーネントを構築していくような作業は、人間がやらなくてもいい。

PRを出すときの作業も、今はAIで完全にできてしまいますよね。人間がもうやらなくていい領域になったので、AIにやらせてしまえばいい。現に、ほとんどのエンジニアがそうしていると思います。

デザイナーがどこまでAIを使っているかは会社によって違いますが、Figmaにもエージェントのような機能ができ、画面を一から作ることは減ってきています。楽にできるところは、確実にAIに任せた方が早い。

一方で判断を残すべきなのは、何回言うんだという話ですが、0→1や、まったく見たことのない機能や画面です。気合いを入れて作らなければならない、AIに任せていられないという判断があれば、人間がやればいい。 それぐらいに感じています。

致命的ではない問題は「要確認」に回す

――大谷：デモでは、合格の他に「要確認」が5個ありました。要確認として上がってくるのは、具体的にどんなものでしょうか。

こぎそ様：基準をどう作るかによりますが、例えばボタンをホバーしたときの色が背景色とほぼ同じで、まったく知覚できない場合。あるいは、パディングのルールが部分的に外れていて、微妙におかしい表示になっている場合です。

後者は、見る人が見れば「別にいいじゃん」となりますよね。致命的ではありません。そういう問題は要確認ぐらいでいい、という線引きはできるかなという感じです。

――大谷：その境界線も、LTにあったようにレビューコメントを通して育てていくのでしょうか。

こぎそ様：そうですね。要確認やエラーは、AIがルールを参照してそう判定しています。ただ、ルールの書き方が間違っていたり、表現が少し違っていたりしてエラーになるケースもありますよね。

間違えないようにどう書けばいいのか、どう指示すればいいのかは、基本的に人間が指示する必要があります。

何もないところから始めるなら、絶対に守るものから書く

――大谷：まったく新しいプロジェクトでUIを作る場合、デザインハーネスはどう組み立てていくべきでしょうか。過去のレビュー指摘もまだない状態で、最初の10行はどこから持ってくるべきですか。

こぎそ様：10行はかなりあおった言い方で、実はもう少し入れた方がいい気もします。背景色やブランドカラーのような重要なもの、ブランドガイドで誰が見ても絶対に守らなければいけないものは、最初に記述すべきです。

書いておけば、AIは従ってくれます。なぜかというと、コンテキストが短ければ短いほど、AIはルールを守ってくれる傾向が強いからです。デザインに限らずコードでも同じで、渡せば渡すほど曖昧になり、ルールを守ってくれなくなります。

最近は、shadcn/uiのようなコンポーネントライブラリ自体が、ClaudeやCodexで使うスキルを公式で配布しています。そのスキルを使えば、コンポーネントや画面設計を一定正しく扱える。使える余地があるなら、それを使ってしまうのが一番手っ取り早いです。

ただ、スキルは結局shadcn/uiのお作法でしかありません。各社のブランドガイドや特殊な機能には当然ルールも制約も効かないので、そこは独自に作る必要があります。

デザイナー不在なら、お手本を1つ決めて再現する

――大谷：関連する質問がSlidoに来ています。「デザイナー不在の中で、デザインシステム・ハーネスを構築する際の進め方のコツはありますか。特に、良し悪しの基準をどう決めるべきか。最初に押さえるべき軸があれば知りたいです」。

こぎそ様：広くやらないことでしょうか。それこそ、小さく始めるということです。

僕の知っている会社では、プロダクトではなくコミュニケーションデザインの領域で、同じパターンのバナーグラフィックを毎回作るのが大変なので、AIに任せられないかと取り組んでいます。そこでは一番よく使うものだけを、まずドッグフーディングしていました。

完璧とは言わないまでも、ほぼ問題ないレベルで再現するために、最初は小さくデザインハーネスを組んでいます。構築のコツとしては、小さく始めることがいいのかなという感じです。

良し悪しの基準は、結局答えがないと決められません。ゼロから新しくルールを作ることは、多分できないでしょう。お手本となるバナーやサイトのデザイン、プロダクトの画面という正解があって成立するので、それをどれだけ再現できるかだけだという気がします。

再現できた上で、変則的なルールを適用するのは自然言語の強みです。スペーシングやモバイルレイアウトのように外れないルールを加え、基準に沿っているか、他の画面と比べておかしくないかを判断していく必要があります。

質疑応答

コンポーネントのルール追加は自動化できるか

――大谷：「コンポーネントにルールを1つずつ追加するのは少し面倒だと感じました。ルールへの追加はいくらか自動化されているのでしょうか」という質問です。

こぎそ様：面倒だと思ったら、他社のコンポーネントシステムを参考に、普通にコピーしてしまいます。オープンソースのライブラリや、他社が公開しているデザインシステムがありますよね。お手本として耐えるなら、それを使えばいい。

ただ、全部を自動化して作るのは基本的に無理です。AIもなんとなく作ってはくれますが、それが正しいかは結局人間が判断しなければなりません。生成されたものが良くなかったら、自動化されたところで意味がないので、面倒でもそこはやる必要があります。

AIに自動で書かせることも当然できますが、それが信頼できるのかという問題が残ります。人間の目で確認できるならいいのですが、そうでないなら、信頼に足るデザインシステムやオープンソースのルールを参照し、カスタマイズして使えばいいのではないでしょうか。

テクニカル面で気をつけること

――大谷：「ハーネスを構築する上で、テクニカル面で気をつけることはありますか。例えば、トークンはJSON形式にすべき、など」という質問です。

こぎそ様：トークンをJSON形式にするなど、AIやコードにとって読みやすい形式の方がいいですね。自然言語で書くより可読性を高くできるなら、そちらにした方がいい。

StylelintやESLintのように、これまでコード側で持っていたチェックの仕組みに乗ったフォーマットにできるなら、できるだけそうした方がいいでしょう。

――大谷：LTでは、プリンシパルはいらないという話もありました。自然言語で原則を書くのではないとすると、記載の上で気をつけることはありますか。

こぎそ様：プリンシパルがいらないと言ったのは、渡して何かいいことがないなら入れても意味がない、という話です。みんな入れていますが、外したからといってアウトプットはそれほど劣化しないんです。抽象的すぎるものは、AIを混乱させるだけなのかなと思っています。

具体的な要求定義や仕様なら、入れた方がいい。ただ、各社が用意しているプロダクト原則は、トークンを無駄にしているのではないかと感じるときが多いです。

明らかに絶対入れなければいけないルールは入れて、関係ないかもしれないものは最初から入れなくていい。これが、最近僕が意識していることです。

それなら「あなたは何々です」というなりきりの指示の方が、まだいいのかなと思っています。ただ、モデルが賢くなったので、それもだいぶ減りました。

テクニカル面でいうと、新しいモデルが出るたびに「いらないものを除いて全部削除して」と言ってみる、という手もあります。

ルールが増えてハルシネーションが多発したら

――大谷：「現場でデザインハーネスを構築してみましたが、プロジェクトの規模が大きかったために、どんどんルールが増えてハルシネーションが多発しました。大きいプロジェクトでうまくハーネスを活用する方法はありますか」という質問です。

こぎそ様：これは本当によくあって、ルールは増やされがちなんです。AIが勝手に解析してそれっぽいものを作ってくれるのですが、実行するたびにマークダウンにタスクを記述してくる。ログのような形です。

見ていると結構重複していて、何の意味があるのかというものも書かれています。一度削除して、本当に必要なものしか残さないようにする。まずはそれをやってみてもいいでしょう。

同じプロダクトでもドメインが違うなら、ドメインごとにルールを切り出して参照させないようにする、といった指示の工夫もあっていいと思います。

0→1でもAIは使えるか、Figmaはまだ必要か

――大谷：「0→1になると、まったくAIが使えないということでしょうか。新たな操作体験を作ろうとしたときは、やはりFigmaとにらめっこになってしまうのでしょうか」という質問です。

こぎそ様：一義的には、どういう品質で満足するか、これでいいという判断ができるかではないでしょうか。既存プロダクトにトーンや使いやすさ、品質を完全に合わせたいなら、既存のルール以外のものも作らなければならず、工数がかなりかさみます。

時間がかかって検証が遅れるぐらいなら、僕はそこの品質基準を下げてやってみるのも一手だという気がします。

Figmaについて言うと、最近、僕はFigmaが必要だと思っているんです。

――大谷：それは面白いですね。私も「Figmaはいらない」派閥ではあるのですが。

こぎそ様：Figmaはいらないという意見も、すごく分かります。0→1のスタートアップでお金がなく時間もかけられないなら、Figmaを操作していると時間がかかってしまう。大まかなものは、AIで全然作れます。

ただ、ある程度成熟して画面が増え、品質を気にしなければならないときに、パターンを並べてみたり、細かい差分を出したりするのはどうするのか。誰がどう比較し、コメントをつけ、どう調整するのか。GitHubだと結局、画面キャプチャを貼ってやるしかありません。

共同作業で修正するとき、その場でプロンプトを打って直すことになるのは、結構非効率です。ある程度の規模で、議論が必要な人数になってくると、Figmaが引き続き必要な場面があります。デザインツールの役割が変わっただけで、不要にはならないと考えています。

デザインが得意なモデルはあるか

――大谷：「デザインハーネスを小さく始める場合、制約や文脈に載っていないデザインが発生したときに、筋のいいデザインを提案してくれるモデルを使うことも重要だと思います。現状、デザインが得意なモデルはありますか」という質問です。

こぎそ様：今のフロンティアモデルは、みんな結構得意です。特にOpus 5.5は、かなりデザインが得意だと言われていますね。

この間出たGemini 4も、Google AI StudioのAPIのプランで使ってみましたが、悪くはありません。基本的には、最先端のフロンティアモデルを使っていれば結構いい感じです。

ハーネスを作るタイミング

――大谷：最後の質問です。「ハーネスを構築するタイミングはいつがベストでしょうか。プロジェクトが開始してデザインの方向性が決定し、これから量産していく前にガッと作るのがいいのでしょうか」。

こぎそ様：最初から意識して作っておくといい気がしています。トークンやコンポーネントのようにあまり変わらないもの、規約で制御しやすいものは、最初からルールがあった方がいい。

一方で、画面は作っていく中で結構変わっていきます。特に最初は何を作ればいいかの探索が始まるので、ルールを作りすぎても意味がありません。

ある程度固まって、画面の量産やパターンが見えてきたタイミングで、レビューのスキルや、検証とフィードバックを回すサイクルを作ってもいいかもしれません。

最後にこぎそ様は、「デザインハーネスやハーネスエンジニアリングはいろいろ言われていますが、育てるところには引き続き人間が介在する必要がある」と参加者に語りかけました。そのうえで、「ルールができた後に何が起きるかは分からないので、来年に備えていきましょう」と締めくくりました。