エンジニアにデザインハーネスを 〜デザインプロセスを規定するためのハーネス〜 / Design harness from an engineer's perspective

Transcript

1. 2026年7月9日 Asterminds株式会社 r.kagaya デザインハーネス 〜デザインにおけるハーネスエンジニアリング〜 エンジニアにデザインハーネスを 〜デザインプロセスを規定するためのハーネス〜

2. 2022年に株式会社ログラスに入社 経営管理SaaSの開発、開発生産性向上に取り組んだのち、 生成AI/LLMチームを立ち上げ、新規AIプロダクトの立ち 上げに従事、その後、25年8月に独立・現職 翻訳を担当したAIエンジニアリングが オライリージャパンより出版 Asterminds（アスターマインズ）株式会社 共同創業者・CTO r.kagaya(@ry0_kaga) 自己紹介

3. 26年3月にシードラウンド調達を公開

4. 昨今のシードスタートアップの悲哀

5. プロダクトデザイナー不在のスタートアップ

6. プロダクトビルダーという言葉の実質エンジニア

7. エンジニアがコーディングエージェントで 一定レベルのUIを作るには？

8. AIコーディングエージェントとのデザインの課題 デザイナーが担っていた部分を、エンジニア with コーディングエージェントが引 き受けると何が起きるか 基準を見極める眼 人ガチャ・AIガチャ それっぽい画面は作れる か、そこ止まり 妥当性や見極めの判断は

   つかない どこまでなら妥協していい か、どこからは絶対に守る べきラインか 最低基準を引く基準を持 たない 理解や意識もばらつきが 大きい コーディングエージェント や使い方によってもばら つく それっぽさの限界

9. 同じDESIGN.mdを見ているのに、選ぶコンポーネントがズレる 地味に大きいのが人やエージェントによる属人性 例) Claude CodeとCodexで、違うUIコンポーネントを選びがち

10. 同じデザインシステムを見ているのに、選ぶコンポーネントがズレる （例）GPT系の方が指示追従性が高く、Claudeの方がハックを試行しがち

11. AIに委ねることには、2つの分岐がある offloading＝何を作るかの判断は自分が持ち、作り方だけをAIに渡す surrender＝AIの出力がそのまま自分の出力になる デザインハーネスで実現したいのはoffloadingの世界

12. "Done" is a claim, not proof エージェントの「完了しました」は、証拠ではない 観察・判定・検証のループを設計するのもハーネス 弱いループ 手順を規定

    エージェントの「直しまし た」「テスト通りました」は 自己申告であり、証拠では ない 検証を自己申告に任せた 瞬間、ループは弱まる ハーネスは成果物を後か ら採点するのではなく、そ こに至る前の手順を規定 する 自己申告

13. デザインハーネスで実現したいこと 最高のUIではなく、一定クオリティ・範囲のデザインに収斂する仕組み • AIエージェントにプロダクトデザインをoffloadingできる • エージェントが変わっても、人が変わっても、一定クオリティのUIに収斂する

14. ハーネスとループの基本 デザインハーネスはユーザーハーネスの一種 ループは、その足場をいつ・どう回し続けるかを決める運行原理 • 出力の良し悪しを機械的に判定できるか • 追加トークンで速く／良くなるか • 状態は途中から再生できるか •

    不変条件と終了条件は書けるか • 予算上限と人間への戻し方は決まっているか 流行りのループも本質は変わらない 検証可能性やガードレールで誘導する ハーネスは成果物ではなく、そこに至るまで のプロセスを制約する

15. 弊社のデザインハーネスの登場人物 何が必須かを機械可読に定義する（rules.json, patterns.json） どう書けばいいかを例で見せる（recipes、patterns）

16. ハーネスの4象限 ユーザーハーネスは導くか、検知するか。推論的か計算的かで整理できる

17. デザインハーネスの4象限 デザインハーネスも同様のマトリクスで役割を整理

18. デザインハーネスの計算的センサー デザインの契約違反を型エラーやlintにより先にブロックする AIが自律的に検知することで改善を回す

19. デザインシステムを組み込んだループ デザインシステムをベースに、スキルに組み込むことで、 コーディングエージェント非依存で（ある程度)同じLoopを辿れる

20. デザインシステムを組み込んだループ DevinへのSlack一言の依頼で、契約違反のパターンを拾えるように ガイドをベースに、PRレビュー/ブラウザQA自動化の中でデザインレビューも

21. （再掲）AIコーディングエージェントとのデザインの課題 デザイナーが担っていた部分を、エンジニア with コーディングエージェントが引 き受けると何が起きるか 基準を見極める眼 人ガチャ・AIガチャ それっぽい画面は作れる か、そこ止まり 妥当性や見極めの判断は

    つかない どこまでなら妥協していい か、どこからは絶対に守る べきラインか 最低基準を引く基準を持 たない 理解や意識もばらつきが 大きい コーディングエージェント や使い方によってもばら つく それっぽさの限界

22. （再掲）AIコーディングエージェントとのデザインの課題 デザイナーが担っていた部分を、エンジニア with コーディングエージェントが引 き受けると何が起きるか 基準を見極める眼 人ガチャ・AIガチャ それっぽい画面は作れる か、そこ止まり 妥当性や見極めの判断は

    つかない どこまでなら妥協していい か、どこからは絶対に守る べきラインか 最低基準を引く基準を持 たない 理解や意識もばらつきが 大きい コーディングエージェント や使い方によってもばら つく それっぽさの限界 UI関連の制約（e.g. Xの場合はYしたい）を追加し、 その後から各種エージェントが参照

23. （再掲）AIコーディングエージェントとのデザインの課題 デザイナーが担っていた部分を、エンジニア with コーディングエージェントが引 き受けると何が起きるか 基準を見極める眼 人ガチャ・AIガチャ それっぽい画面は作れる か、そこ止まり 妥当性や見極めの判断は

    つかない どこまでなら妥協していい か、どこからは絶対に守る べきラインか 最低基準を引く基準を持 たない 理解や意識もばらつきが 大きい コーディングエージェント や使い方によってもばら つく それっぽさの限界 デザイナーが監修したガイドラインを踏まえた制約

24. まとめ

25. To be continued メインプロダクトには組み込み済 CC / Codex / Devinからもデザインシステムを参照している状態 今後は

    • セカンドプロダクトからの参照 ◦ デザインや体験のプロダクト間の統一性担保ができるか？ • 陳腐化/改善のためのサイクル・ループ ◦ ルールファイルと同じ継続的 and 半自動的な改善は回せるか？ • ハーネスの評価

26. まとめ ハーネスは、AIへの委任をoffloadingとして成立させる デザインハーネスで、UI/デザインプロセスを制約するそこに至る前でのプロセスを制 約するそこに至る前でのプロセを制約

27. おわり