カナリーでは現在、「PRDの作成」から「デザインシステムに沿ったUIの生成」まで、一通りのプロセスをClaude Codeを使ったワークフローで自動で行えるようにプロセスを組むことができています。
目下、多くのプロダクト組織でAIワークフローを当たり前にチームで運用している状態をつくろうとしていると思いますが、カナリーの場合はどのように仕組みを構築しているのかを事例として公開してみようと思い、現在地をまとめてみました。
AIを取り入れたUIデザイン業務改善の例として、もしも自組織で参考になる部分があれば取り入れてもらえると嬉しいです。
まず、カナリーにおける現在のUI生成フローについて全体像を解説します。
対応しているワークフローとしては、「PRDの生成・要求の読み取り」「データモデル設計 / 情報設計」「UIパターンの発散」「デザインシステムを考慮したUI調整」「デザインレビューとデザインシステム更新」の5ステップです。要はほとんどのデザインステップをカバー可能になっています。
裏側も含めてまとめると、以下のような仕組みで構成されています。
生成を行うためのエージェント、レビューを行うエージェントは切り離し、両者に共通するデザインシステム「NestUI」は共通のリファレンスとして読み込めるようにしています。
実際に生成されるアウトプットのイメージは以下のようなものができています。
カナリーのプロダクトにそのまま乗せても問題ないクオリティのUIが生成されており、リードデザイナーの最終クオリティチェックは挟んでいつつ、ほとんどコストをかけずに実用的なデザインがつくれるようになっています。
今回は、この仕組みのそれぞれの具体的な裏側を解説していきますが、先に大元となっている考え方を共有しておきます。
カナリーにおいては「リードデザイナーの思考をLLMに100%反映させる」ということを、AIワークフロー構築の際に強く意識しています。
逆にいうと、リードデザイナーの思考プロセスとズレていて、設計意図を説明できないアウトプットは受け入れない、ということでもあります。
LLMを使えば、簡単な指示でもそれらしいUIがアウトプットされます。ただ、それは企業で実用可能なUIとは言えないのではないかと思っています。
事業においては再現性が何より大事です。常に同じ思考で同じクオリティのアウトプットが出せるのか。ここがブレていると、いずれ「誰も意図を説明できないアウトプット」が溢れてきて、何を改善すればいいのかが分からない状況になってしまいます。
このようなディレクションが効いていない状況を避けるためにも、あえてLLMの考え方を矯正して、リードデザイナーがやっていることと同じことをやれる、というゴールに向けて仕組みを育てていくのがカナリーのUI生成ワークフローづくりの肝です。
AIを、「自分たち以上の思考をする魔法の道具」と捉えると扱いが難しくなりますが、「人間の思考を拡張してくれる相棒的な存在」だと捉えると、途端に扱いやすいものに見えてくるのではないかと思っています。新しく入社したフレッシュな思考をしてくれるデザイナーのようなイメージで接しています。
ここからは具体的な仕組みの裏側をいくつかまとめていきます。
まずは「要求の解釈」と「データモデル / 情報設計」のステップについて。この工程は、複数画面の生成において活用し、単一の画面を生成する場合では網羅的なPRDのみ用意してスキップをします。
まず、簡易なテキスト単位でも良いので、今回つくりたい機能の内容を読み込ませます。
この時、要件定義として必要な情報を網羅的に揃えるために、「要件定義そのものの定義」をまとめたリファレンスをもとに、出力するフォーマットを指定して情報を整理してもらいます。
生成の精度を高めるための条件は、インプットを安定させることと、出力のフォーマットをあらかじめ絞ることです。これにより、AIが自由に考える余地を下げ、情報をパズルのように組み合わせていく思考をしてもらえるので、結果として精度が安定します。
また、複数の画面を設計するために「画面をまたいだ関係性の整理」も行ってもらいます。
具体的には、画面遷移図、共通で使うコンポーネントの定義、バッチ設計判断の3つと、合わせてそれぞれの機能における簡易な設計書を出力しています。
ここでアウトプットされた情報を目視で確認し、ズレがないかを確かめてから一括生成を行います。
このプロセスを挟んでいるのは、複数の画面を生成するときに、各画面単位では成り立っているように見えて、実は画面ごとに情報が足りなかったり設計に差分が出ていることに気付いたためです。
そこで、画面横断での関係性や、ユーザーがソフトウェアとやり取りしてどういう結果が返ってくるのかという情報をシーケンス図などをまとめてインプットしてみたところ、大量の画面をつくるに当たってもブレが減ることが分かってきたのでこのフローを採用しています。
画面遷移、共通シェル層、バッチ設計判断などの共通で持つと良い情報は、エンジニアが設計において欲しい情報とは何か？という観点で考えています。
LLMが設計しやすいということは、エンジニアが考える時のように実装観点で必要になる情報が網羅されているということなので、そこから考えて情報を揃えるようにしました。
先述したように、単一の機能設計においてはこのプロセスは省略しても生成の精度は下がらないように感じています。あくまで複数画面を同時に生成する時に必要なフローとして、特に新規プロダクトの設計などで活用しています。
次に、「UIパターンの生成」について。ここは前にまとめた仕様設計のエージェントのサブエージェントとして、複数画面を同時に生成するときにも並列で動かすようにしています。
このエージェントには前回の事例でもまとめたように、「デザイナー人格」というskillを複数インプットしておき、意図的にありがちなUIとは外れたひと工夫があるUIを生成できるようにしています。
具体的には、以下のようないくつかの「デザイナー人格」をリードデザイナーの思考から抽出した上でskillに落とし込み、そのskillをもとにUIパターンの発散をさせるような仕組みをとっています。
アウトプットとしては、以下のように、「デザイナー人格」を介することで、機能が満たされているだけではなく、合理的な要件に加えたデザインの一工夫が生まれるようになっています。
このプロセスについては、詳細に仕組みを切り取った事例をまとめているのでこちらも合わせて参照ください。
UIパターンを生成したあとは、「デザインシステムを考慮したUI調整」のステップを挟んでいます。
カナリーでは、LLMでのデザインを前提としたAgentic Design System「NestUI」を用意し、生成・レビュー両方のリファレンスとして読み込めるように設定しています。
LLMにはどこに何があるのかを階層として理解してもらうことで、精度が向上します。そのため、このタイミングでカナリーのデザインシステムもLLMファーストでつくり変えました。
初めはコンポーネントをマークダウンにしたり、デザイントークンをファイル単位でClaude Code上に置いておくDESIGN.mdで運用していたのですが、これだけだとLLMが生成のたびに各コンポーネントの扱い方を都度判断するため、精度にブレが出ることが分かります。
例えば、操作の目的は変わらないとしても、ある画面では「ドロップダウン」を使っているのに、別の画面では「ラジオボタン」を使うなど別のコンポーネントを使うようなことが起こっていました。
ここで、人間であれば非言語的に読み取っているコンポーネントそれぞれの適切な扱いを、LLMに対しては正確に定義しておかなければいけないということを学びます。
なのでコンポーネントを置いておくだけでなく、その一つ上の階層で、コンポーネントの種類一覧とindex (扱い方) をまとめたリファレンスを用意しました。
この設計は、Adobeのデザインシステムでもcomponent-decision-tree.mdというファイルで同じような考え方がされており、一つのベストプラクティスだと考えています。
同じように、レイアウトパターンについても一つひとつのレイアウトをどのような場合に使うべきかを定義して用意しています。
パターンが網羅されていることと、定義が明確に示されていることで、LLMはこのパターンの中から仕様に合う適切なパターンを選ぶだけの思考をすることができます。
LLMによる生成の精度を上げるために、このレイアウトパターンや、コンポーネントの定義など新たにデザインシステムに追加した部分でした。
実際の生成の場面では、LLMが前のステップで発散されたUIに対して、「デザインシステムと外れていないか」という観点でチェックしていきます。
まず、レイアウトの扱い方が定義されたindexファイルを読みにいき、どのレイアウトのパターンを使うかを選びます。そのあと、ユースケースや要件に合うようにコンポーネントのindexを見て適切なものを選びます。ここまで来れば、あとは最適な配置をしていくだけとなります。
ここで、各画面の余白や配置などもずれないように、数字単位で細かく指定しておくのもポイントです。
当初はもう少しざっくり余白や配置についてまとめていたのですが、px単位でブレがないように指定をしておく方が生成の精度は上がることが分かったので、このような情報も明記するようにしています。
結果として、冒頭で見せたようなカナリーのデザインシステムに沿ったアウトプットがされるようになっています。
こちらのデザインシステム「NestUI」の一部は、GitHubで誰でも見れる形で外部公開をしています。事業の形が変わっても構造が参考になるところがあると思うので、ぜひ参照いただければと思います。
UIを実装に進める前に、「デザインレビュー」のステップを挟んで最終チェックを行います。
この工程では、ここまでの生成のためのエージェントと、レビューのためのエージェントを別に組むようにしています。なぜかというと、レビューの方が実はやるべきことはルール的に整理しやすく、分けた方が精度が高まりやすいからです。
入力受付
以下の観点で指摘と評価のループを回す
アクセシビリティ
コンポーネント
レイアウト
情報設計
UXライティング
一定以上の点数を満たすまで、指摘と改善のサイクルを自動でループさせる
評価が終わったら、UIレビューレポートを出力
同時に、デザインガイドラインもアップデートされ、レビュー観点に反映
というような一連の流れで、レビュー部分のエージェントは設計しています。
これはAnthropic公式のワークフローを組み合わせて更新しており、オーケストレーター型で親エージェントが各サブエージェントを明示的に並列起動させて実行、さらに各サブエージェントは評価システムと組み合わせられていてAIによる自己採点・改善も可能になっています。 (詳細は別途事例にまとめます。)
UIレビュー・レポートの出力イメージは以下のような形です。このレポートを目視でも確認して、本当にリードデザイナーがレビューする時と同じように考えられているのかを確かめ、エージェント自体の改善を行うことも裏側で行って精度を高めていました。
また、このタイミングで「デザインシステムの自動更新」のステップも走らせることも大切です。
AIによるUI生成が各所で走るようになると、基準としてのデザインシステムのアップデートを人が行うことは困難になります。
なので、この生成・レビューのサイクルの中に、デザインシステムのアップデートの仕組みも挟み込むことで、自然と人がやっていた時と同じように、デザインシステムの更新がされるようにできます。
このワークフローが生まれたことでカナリーは、深いドメイン理解があれば、デザインスキルの有無によらず、誰でも事業の検証を進められる状態になりつつあります。
例えば、カナリーで動かしている一つの新規事業では、POがデザインシステムを活用してデザイナー不在で事業開発を進めています。
また、新しく入社した不動産業界出身のデザイナーは、デザイン・プロダクト開発のバックグラウンドはなかった方です。それでも、元不動産業界のドメイン理解を活かし、LLMを活用してデザイン業務を進められています。
デザイナー自身も、UIの設計に使っていた時間が減り、これまで取り組めていなかったコーポレートのブランド設計や、キャラクター設計、社内へのユーザー理解の浸透など仕事の幅を広げることができています。
このような体制が取れるのは、誰が生成をしても精度の高いUI生成を再現できると言い切れるほどLLMを育てられたからです。アウトプットや設計プロセスの再現性を確認できて、はじめてワークフローを実用段階に移行することができます。
最後に、なぜカナリーのデザイナーがAIワークフロー設計に力を入れるのかをまとめます。
僕たちは、もともとデザイナーが潤沢にいる組織ではありませんでした。事業の成長に合わせてデザイナーの採用にも取り組んできましたが、市場にもデザイン組織が増えていく中で、採用が追いつかなくなっていたのが実態です。
そんな中で可能性を見出したのがAI活用でした。リードデザイナーのやっていることを、LLMで再現可能になれば、デザイナー採用の課題を解決できるかもしれない。その考えのもと、当時業務委託で関わり始めていた平場さんに、「AIワークフロー構築を推し進めてもらいたい」とオーダーしたのが最初でした。
それからの検証の流れについては、また別途事例で公開しますが、私たちの目線はずっと変わらず「LLMをリードデザイナーの1人として扱う」というところにあります。
今のワークフローは、自分がこれまでカナリーでやってきていたプロダクトデザインのプロセスを違和感なく落とし込めたものになっており、自分は事業にとって新しいデザイン活用領域に時間を使えるようになってきています。
おそらく、これからのデザイナーの役割の一つは、このような「今リード層がやれている動きを、AIを使って仕組み化していく」という、ワークフローのビルダーのようなところに伸びていくのではないかと考えています。
カナリーのデザイン組織は、「つくる」ことは当たり前にできる上で、「つくる仕組みをつくる」ことにフォーカスしていきます。ワークフローのつくり手としてデザイナーが全社に機能している状態に向けて、ここからもUI生成の仕組みにとどまらず、仕組み化を進めていきます。