デザインハーネスの試行錯誤。鍵は小さく始めることだった【デザインハーネス The Beginning 〜これから始めるデザインハーネス〜 登壇レポート】

こんにちは、上條 @mk-0A0 です。

2026年10月29日に Gaji-Labo・CrossRelさん・noteさんの3社で共催したイベント「デザインハーネス The Beginning 〜これから始めるデザインハーネス〜」に、デザイナーの伊藤と一緒に登壇しました！

セッションタイトルは「歴史あるプロダクトで小さくはじめるデザインハーネス」です。私たちが参画している長く運用されてきた大規模プロダクトにて、制約がある中でどのようにデザインハーネスに近づいていったのか、その試行錯誤の中身をお話ししました。

イベントのテーマである「デザインハーネス」とは、AI と人間が協業して一貫した UI を生み出すための手綱（ハーネス）となる仕組みとして定義されたものです。
※. 今回の登壇内容はこの定義より手前の、AI が適切にデザインを扱えるよう仕組みを整え始めた話です。

デザインハーネスとは、ハーネスエンジニアリングの「デザイン版」です。デザインシステム・設計知識・検証・ワークフローへの組み込みまでを束ね、プロダクトやサービスのデザインをAIエージェントと共に推進するための仕組み全体を指します。
引用元：https://design-harness.com/#practice

今回のセッションでは、デザイナーとエンジニアそれぞれの視点で前後半に分けて発表しました。本記事ではセッションでお話しした内容に加え、時間の都合でお話ししきれなかった背景や実際どう変わったのかという結果の現在地までをレポートします！

デザイナーパート：小さな検証からはじめたデザインハーネス

まずはデザイナーの伊藤パートから振り返ります。前提として、最初からデザインハーネスを整えようとしていたわけではありませんでした。

プロジェクトの状況と制約

私たちが関わっているのは、エンタープライズ向けの大小5つのプロダクトからなるサービスで、約50人規模のチームで開発・運用を行っています。私たち Gaji-Labo は主に UI デザインとフロントエンド実装を担当しています。

このプロジェクトには以下のような特有の制約と難しさがありました。

• 事業に直結する重要プロダクト：顧客企業の業務基盤であるため、機能品質を落とした雑な改善は避けたい
• AI 駆動開発へのシフト：開発全体が AI を前提となり、デリバリー速度が高速化する中で、Figma を使った今のデザインプロセスがデリバリーのボトルネックになってしまう
• 機能要件の優先：デリバリーのスピードを高速に保つため、UI の整合性は一旦後回しとしてリリースを優先する場面が増えてきた

スピードは保ちたいが、AI が生成する UI の精度を少しでも高めてデザインとしての価値や品質を担保したいという葛藤がありました。

最初にやったこと：デザインルールを DESIGN.md に仮置きする

とりあえず動くためにまず試みたのが、各所に散らばっていたデザインルールをひとつの場所に集約することでした。仮置き場所をDESIGN.mdに定めて、Figmaと実装等を突き合わせてトークンやコンポーネントの利用ルールを抽出し、 Google が提唱する仕様に沿って記載しました。整理しきってから置き場所を決めるのではなく、まず一か所に溜めて機能するかを確かめ、そのあとで必要な場所へ再配置していく進め方です。

これまでは AI はデザインルールを参照できていなかったので、DESIGN.md に集約しただけでも、色や余白・タイポグラフィといった基本的なルールが生成結果に反映されるようになりました。

一方で、ルールを書き足していくうちに限界も見えてきました。DESIGN.md にどれだけ書いても、AI が既存のコンポーネントを使わずに、独自 UI を作ってしまう問題は解消しませんでした。どのコンポーネントを使うか、要求されるコンポーネントが存在するかの判断は、文章のルールだけでは伝えきれなかったのです。また、ファイルが厚くなっていくことで、AI が必要な記述にたどり着きにくくなるという懸念もありました。

適切な配置と SSOT（Single Source of Truth）の定義

DESIGN.md への集約で基本的なルールは AI に届くようになりましたが、すべてのルールをドキュメントに丁寧に書き起こすのは現実的ではありません。AI に適切な選択をさせるためには、情報の置き場所を整理して SSOT（Single Source of Truth：信頼できる唯一の情報源） を定める必要がありました。DESIGN.md は、ルールを集めて効き目を試す場としては機能しましたが、既存コンポーネントからの選択まで任せられる SSOT には向いていなかったということです。

そこでいくつかの検証を行った結果、Storybook を SSOT として据えることが最も即効性と確度が高そうだという結論に至りました。

アプローチとして、アプリケーションのコードをそのまま読ませるよりも UI カタログとして整理された Storybook からコンポーネントを適切に選択し、モックアップを生成させるという流れが期待していた生成精度に一番近かったのです。（このプロセスを前に進めるにあたっては、後述する Ayana Yamazaki さんの多大なご支援がありました）

検証と情報整備のサイクルを回す

SSOT の基盤が整ったことで、AI によるモックアップ生成が形になってきました。ここからは地道に改善サイクルを回すフェーズに入ります。

生成した画面を人間がデザインルールとのズレを確認し、足りない情報やルールを DESIGN.md や Story の記述にフィードバックしていく作業を繰り返しました。

改善サイクルを安定させるために工夫したのが、生成時に「何を根拠にしたか（引用リスト）」と「どう推測したか（推測リスト）」を必ず出力させることでした。AI の判断ロジックが可視化されたことで、指示が足りないのか、あるいは SSOT 側にコンポーネントの記述が不足しているのか、といった原因特定がスムーズになりました。

「これってデザインハーネスなのでは？」

地道にこのループを回していたところで「デザインハーネス」という概念を知り、自分たちが今手探りでやっていたことと近しく感じました。

取り組みがデザインハーネスという名前で整理されたことで、ベストプラクティスとされている観点から自分たちに必要なことが見え始めました。

書籍『ちいさくはじめるデザインシステム』でも語られている通り、整備は後からできるのでまずは小さくはじめることが、デザインハーネスでも重要だと実感しています。最初から網羅性のある基盤を作るのではなく、今必要とされている部分に絞って整備したからこそ比較的スムーズに改善サイクルを回す段階までたどり着けました。

エンジニアパート：Storybook を SSOT と定義したプロセスと工夫

後半のエンジニアパートでは私上條にバトンタッチし、エンジニア視点で「どのように Storybook を SSOT 化したか」をお話ししました。

なぜ Storybook を SSOT にしたのか

AI 時代より以前から、歴史あるプロダクトゆえに仕様やコンポーネント定義が各所に散らばっているという課題がありました。AI 駆動開発へシフトしている今が SSOT を明確に定義する良きタイミングだと感じました。

Storybook を選んだ理由は検証結果として効果が高かったこと、そして既存の Storybook を整備すれば活用できることです。大規模プロダクトにおいて1から新しく作り直す時間はないため、制約の中で現実的にできることから小さくはじめる手段を選びました。

Storybook SSOT 化のステップ

Storybook を信頼できるものにするためのステップをざっくり4段階で紹介しました。

1. Storybook 整備：AI がコンポーネントを選べる状態にする
2. トークン整備：カラー、タイポグラフィ、スペーシングなどのデザイントークンを整理
3. ルールの言語化：デザイナーが言語化したルールや意図を AI が汲み取れるようにする
4. 組み合わせの例示：実際のページを Storybook 上で例示し、AI が実装サンプルとして参照できるようにする

ゼロから整備する場合、ルールの言語化とトークンの整備をしてから Storybook 整備に着手といった、抽象から具体へ落とし込む方法もあると思います。しかし、私たちの場合は既に動いている Storybook があったため、一番生成結果への影響が大きかった Storybook の整備から着手しました。

SSOT を参照したモックアップ作成の流れ

この SSOT をもとに AI が画面のモックアップを生成するフローを構築しました。

コンポーネントを自由に作らせるのではなく、Storybook に定義された既存のコンポーネントから選択させるという制約を与えるのがポイントです。

モック画面はコードとして生成され、そのまま Storybook 上でプレビュー・動作確認ができます。ブラッシュアップを重ねればそのままプロダクションで使えるコードとして流用できるため、デザインを実装に起こすフローがシームレスになるという大きなメリットがあります。

進めるうえで特に大事にしていること

エンジニアパートのまとめとして、以下の2点を強調しました。

• 小さくても確実に成果を出す手段を選ぶ：一気にすべての画面・全コンポーネントを網羅しようとせず、今必要なことを選んで小さく取り組む
• デザインルールと実装都合のすり合わせ：デザイナーが言語化したルールをエンジニアが既存実装に即しているかという観点でレビューし、両者の視点でルールを磨く

もちろん、既存コードの肥大化によるブロッカーの解消など、まだまだ現場での苦戦や泥臭い課題は山積みですが、職能を超えて同じ SSOT を育てていく手応えを日々感じています。

結果としてどう変わったか？

セッション内では取り組みの全体像がメインだったため、実際プロジェクトではどのような変化が見られるかという具体的な成果をここで簡単にまとめます。

生成精度のブレが劇的に減少

ある程度信頼できる SSOT が定まったことで、画面仕様に対する AI の出力が一定の品質で安定しました。ブレが減ったことで人間側の手戻り確認コストも下がり、実用できる場面が徐々に増えています。

非デザイナーへ画面設計を手渡せる

未定義の複雑な独自の UI をゼロから自動で生成するのはこれからの取り組みですが、コンポーネントやトークンを正しく組み合わせた標準的な画面設計や機能設計であれば、非デザイナーにも手渡せる目処が立っています。

実際のフェーズ

社内アプリのような小規模なプロジェクトであれば、すでに実用できる水準に達しています。一方で、今回の主題である大規模なエンタープライズ向けサービスにおいては、チーム全体の開発ワークフローとして定着するまでにまだ多くの課題を感じています。部分的に使うための足がかりができたので、これをチームに浸透させるのが次の取り組むべきフェーズです。

会場の反応

懇親会では似た悩みを抱えている方から共感の声をたくさんいただきました。既に動いているプロダクトはデリバリー速度を保ちたいので整備に手が回らない、そもそもデザインシステムが機能してないなどなど、プロダクトの数だけ悩みは尽きませんね。

また、デザイナーとエンジニアが2人で登壇した形式も好評をいただきました（ありがとうございます！）。職能で壁を作るのではなくチームとして課題に向き合う姿勢は Gaji-Labo がずっと強みにしてきた文化でもあるので、その空気感が参加された方に伝わっていれば幸いです。

セッションに盛り込めなかった内容もあるので、後日公開予定の伊藤の記事もぜひご覧ください！

小さな取り組みから自分たちのデザインハーネスを育てていこう

「デザインハーネス」というワードを聞くと「なんだか凄そう」「大掛かり」とハードルの高さを感じるかもしれませんが、今回のセッションでお伝えしたかったのは プロジェクトの状況に合わせて小さくはじめ、後からでも段階的にデザインハーネスの4層に近づけていける ということです。まず情報を1つのファイルに集める、Storybook をAIの参照元にするなど、チームでできるところから模索する試行錯誤のプロセスが重要だと考えています。
私たちの取り組みもまだまだ道半ばです。他の登壇者の方々から得た知見も取り入れながら、チームと一緒に育てていきたいと思います。

弊社では「ボトルネックをどう解消したら良いか分からない」「自社の場合はどこから始められるか」といったプロダクト固有の課題から、デザインハーネス / Agentic Design Systems に関する情報交換・壁打ちを行っています。ぜひお気軽にお声がけください！登壇者にもっと詳しく話を聞きたいといったご要望も大歓迎です。
下記の AI 駆動開発支援サービスのページからぜひご連絡ください。（無料です！！）

• AI駆動開発について相談する https://www.gaji.jp/services/aidd

参考記事

セッション内では時間の都合上割愛させていただきましたが、今回の一連のデザインハーネス検証プロセスは Ayana Yamazaki さんにご協力・ご支援をいただきました。特に以下の記事には多大な知見をいただいております。この場を借りて心より御礼申し上げます。

• デザイナーの暗黙知をStorybookへ。AIがComponentを正しく使い分けられるMDXを作る
• Figmaでは見えない仕様の穴をStorybookで潰す——デザイナーが Claude Codeで131件の課題を実装前に解決した話 | CADDi Tech Blog – CADDi Tech Blog