AI時代、多数のツールが市場に生まれ、UIやクリエイティブをつくるのはデザイナーだけの仕事ではなくなりつつあります。

ログラスのデザイン部ではこの流れに乗りながら、デザイナーがやるべきことに集中できる環境をつくるために「AI駆動の新しいデザインワークフロー構築」に大きく注力しています。

AI時代にログラスのデザイン部は「AI駆動の新しいデザインワークフローの構築」に取り組んでいる

今回は、その一環として、AI駆動なデザインシステム運用ワークフローを構築したので紹介します。この導入によって、これまでデザイナーの中で暗黙知的に運用されており、更新の負荷が高かったデザインルールをまとめたドキュメントを、ほぼコストゼロで作成・運用できるようになっています。

また、このワークフローの構築を進めると、いずれUI設計の業務をデザイナーから手離れすることもできるのではないかと思っています。

AI駆動なデザインシステム運用ワークフローを構築中。今は「デザインルールをまとめたドキュメントの更新が、ほぼコストゼロで運用可能」になっている

現在もワークフローを更新中で、ツールや仕組みはアップデートするかもしれないですが、根本的なワークフローの設計思想については変わらないと思うので、ここまでの取り組みを事例としてまとめてみます。

ログラスとしてのAI時代への向き合い方やスタンスをぜひ参考にしていただけると嬉しいです。

ログラスのデザイン部では、全社としてのAI駆動なワークフロー構築の一貫として、AI (LLM) によるUIの自動生成にチャレンジしてきています。

ログラスのデザイン部がチャレンジしているAI活用項目の一つ「LLMによるUIの自動生成」

例えば、デザイナーもMCPサーバーを活用して、既存のコンポーネントライブラリと繋ぎこみ、UIを生成するような取り組みは早々に実験しています。

また、デザイナーだけでなく、新規事業のプロトタイプをPdMがv0で生成して、お客さまにぶつけて検証するようなことも社内で頻繁に起こっており、もはやUIをつくる活動はデザイナーだけのものではなくなってきています。

ただ、このように生成されたUIは、実務レベルに耐え得るのか?という疑問がずっと残っていました。

実証実験の中で結論として辿り着いているのは、コンポーネントライブラリを読み込んでLLMでUIを生成する方法では、実務レベルには至らないということです。

一見綺麗なUIが生成されるものの、単に同じボタンやフォームを使っているだけで、そこに一貫したルールがない場合が多くなります。これは、新規プロダクトの初期プロトタイピングなどのシーンでは問題ないかもしれませんが、新規事業の本公開のタイミングや、既存事業の運用フェーズにおいては、ページごとのUIのルールが違うことは体験として致命的です。

なぜコンポーネントを読み込むだけでは適切なUIが生成できないのか?

その答えは、コンポーネントをどう扱えば良いか、つまり、デザインルールをLLMが理解していないためです。

コンポーネントをどのようなルールで扱うのかを細かく場合分けしてまとめたドキュメントも一緒に読み込むことで、場面ごとに適切なUIを一貫したルールで生成できるようになるはず。このドキュメントを用意する必要があると気付きました。

デザインルールを拡充していくことが、LLMによるUIの生成を実務レベルに近づける鍵ではないか

ただ、このようなデザインルールをまとめたドキュメントを細かく用意していこうとすると、無数のパターンが必要となり、人の手でつくるには限界があります。

実際、当時のログラスでは、デザインルールの定義が必要になった時にデザイナーがよしなにドキュメントをまとめる運用となっていて、いくつかドキュメントはあるものの十分な網羅性がなかったり、内容の記述方法もバラバラになってしまっていました。

これまでのデザインルールは属人的にまとめられており、網羅的ではなかった

そこで生まれたアイデアが「デザインルールをまとめたドキュメントを、AIにつくってもらえないか?」という仮説です。

デザインルールをまとめたドキュメントを人が管理/作成するのではなく、AI駆動で管理/作成できるようにできないか

ここまでにまとめた背景をもとにつくっているのが、AI駆動のデザインシステム運用ワークフローです。

このワークフローは、いくつかのプロセスで区切られています。

  1. デザインルールをまとめたドキュメントの半自動更新

  2. デザインルールをすぐに確認できるチャットボット

  3. MCPサーバーを活用してUIを自動生成

AI駆動のデザインシステム運用ワークフロー

現在は、1つ目の「デザインルールをまとめたドキュメントの半自動更新」と2つ目の「デザインルールをすぐに確認できるチャットボット」の仕組みの構築が完了していて、3つ目の「MCPサーバーを活用してUIを自動生成」は開発を終えて社内検証に入っている状況です。

現時点での仕組みについて、詳しくまとめていきます。

まず一つ目のステップが、デザインルールをまとめたドキュメントの半自動更新です。

これまでは、プロジェクトを進める中でデザインルールの定義が必要になった時に、プロジェクトを担当しているデザイナーが自分でデザイン原則をドキュメントにまとめる属人的な運用がされていました。

新たなワークフローでは、DesignOpsのメンバーがAIを用いて、必要なデザインルールを網羅的に用意していく運用へと変化しています。

デザインルールをまとめたドキュメントを、AIを用いて網羅的に用意できるように

現在の仕組みでは、以下のようにGithub上でつくりたいデザインルールのイシューを立てると、すぐにClaude Code Actionが反応して、必要なデザインルールの要件を確認してくれます。

質問に答えると、すぐに以下のようなデザインルールをまとめたドキュメントがすぐさま生成されます。

Github上で、生成したいデザインルールのイシューを立てると、Claude Code Actionが反応して必要なデザインルールの要件を確認してくれる
質問に答えると、すぐにデザインルールをまとめたドキュメントが生成される
裏側で、Claudeには基礎的なデザインの理論をインプットしており、この考え方をもとにデザインルールを考えてくれるようにしている

この生成されたデザインルールに対して、さらにチャットを重ねてレビューを行い、最終的にmasterデータとしてコミットされます。(現状では、大体2〜3回のやり取りでmasterにコミットできています。)

Githubのイシューに返信する形でレビューを行い、FIXしたらmasterデータにコミットされるような流れ

現在は、このワークフローを用いて、DesignOpsのメンバーがデザインルールをまとめたドキュメントを網羅的に整備しています。

また、もしまだデザインルールが用意されていない場合にも、プロジェクトを進めるデザイナーが業務の中で「このルールどうなってる?」と迷った時に、ワークフローを使ってほぼ手を動かさずすぐにルールを定義することも行えています。(ex. 「ボタンコンポーネントの扱いは?」「フォーム内の余白の持ち方は?」)

DesignOpsのメンバーが中心となって、ワークフローを使って網羅的にデザインルールを整備している
デザインルールは、デザインデータの考え方だけでなく、実装面やシステムアーキテクチャーなども言及されるようになっており、デザイナーが属人的につくるよりも詳しい定義にできている

UIの自動生成の仕組みが構築できるまでは、特に、調整をしっかりかける必要がある既存事業のデザインデータについては、まだデザイナーが手を動かして整備する必要があります。

この時に、デザインルールを確認したい場面ですぐに必要なドキュメントを呼び出せるように、AIチャットボットを開発しました。

生成されたデザインルールをまとめたドキュメントを呼び出し、質問に合わせて必要なデザインルールを答えてくれるようにしています。また、デザインルールが更新された時には、それをSlackで教えてくれます。

デザインルールをすぐに確認できるAIチャットボットを開発

AIによって網羅的につくられたデザインルールをまとめたドキュメントは膨大で、覚えたり、一つ一つ見にいくような行動は現実的ではありません。なので、チャット形式ですぐにデザインルールを呼び出せる仕組みを用意しました。

網羅的につくられたデザインルールをまとめたドキュメントを、人の頭で覚えるのではなく、簡単に呼び出せるようにする

実際、AIチャットボットを導入してから、デザイナーがUIをつくる際にSlackで「このデザインルール教えて」「ここってデザインルール定義されてる?」という呼びかけが日常的に起こるようになっています。

現在、すでに開発は終えて運用フェーズに入っているのですが、この後のステップとして、すでに存在しているコンポーネントライブラリと、今回のデザインルールをまとめたドキュメントをナレッジベースとしたMCPサーバーをつくり、UIの自動生成を行えるようにすることにチャレンジしています。

3つ目のステップ「MCPサーバーを活用してUIを自動生成」も改めてチャレンジしているところ

実務レベルのUIをつくるには「プロジェクトの目的を正しく押さえていること」と「サービス全体で一貫したUIになっていること」の2点が踏まえられている必要があります。

なので、仕組みとしては、エージェンティックな機能をMCPサーバーにもたせ、クライアント側からの要求に対して背景や意図などのコンテキスト情報を収集したうえで最適なルールを返すような構造にしています。

このAI駆動のデザインシステム運用ワークフローを導入してから、ログラスのデザインプロセスにはすでに大きく変化が起こっています。

一つ目の変化は、デザイナーがデザインルールをまとめる負荷が大幅に削減できているということです。

前述の通り、プロジェクトを担当しているデザイナーが自分でデザインルールをまとめるのは、時間も取りづらく、負荷が大きくかかっていました。これが、プロンプトを打ち込むだけで、2〜3ラリーでデザインルールをまとめられるようになったので、実際の時間だけでなく心理的にも大きく負荷が減っています。

1つ目の変化:デザインルールをまとめる負荷が大幅に削減されている

また、デザインルールをまとめたドキュメントが細かく分けられ、量が増えていくことで、AIチャットボットの精度も高まり、デザイナーがより素早くルールを確認できるようになっています。

2つ目の変化:デザインルールが網羅的にまとめられてきたことで、これまでよりもデザイナーが素早くデザインルールを確認できるようになっている

これからワークフローを進化させていくと、デザイナーのUI設計業務にかかる時間が大きく減少、デザイナー以外の職種がつくるUIの品質向上、などの効果もどんどん起こっていくだろうと考えています。

最後に、UIデザインを誰でもできるようにした先に、私たちデザイナーは何をやろうとしているのかについてまとめておきます。

今回紹介したAI駆動のデザインシステム運用ワークフローはまだ構築途中ですが、これが成立していくにつれて、少しずつデザイナーの役割はUIデザインから移行していくでしょう。

AI駆動なワークフローによって、デザイナーの役割は「UIデザイン」から移行していく

私たちは、その先には、未検証なデザイン領域の検証を進めていける未来があると考えています。

ログラスでは、もともと単にUIをつくるということではなく、理想の社会を描き、そのための最適なソリューションをつくる活動こそが、デザイナーの役割だと定義してきました。そして、その役割から考えると、まだまだ検証できていないけどやるべきデザイン領域がたくさんあります。

例えば、ディスカバリー、ユーザビリティテスト、新規事業の立ち上げ、UIの大幅アップデートなど。

AIを活用してこれまでのコストが大きく削減されるワークフローをつくることができれば、そのような未検証のデザイン領域にさらに注力していくことができるはずです。そのためにも、実務レベルのUIを誰でも生成できる状態を早くつくりたいと考えています。

ログラスのデザイナーが注力していきたいのは「未検証なデザイン領域の検証を進めていくこと」

そして私たちは、LLMによってUIデザインを自動で行えるようになるためのラストワンマイルは「デザインの意志込め」だと考えています。

意志のないUIでは、ユーザーは動いてくれません。プロジェクトの目的や、サービス全体の体験と齟齬がないUIをつくることができるのは、まだデザイナーの特殊技能となっています。

今回まとめたワークフローの構築を進めていくことで、このような「意志」をLLMに学習させることができれば、ようやく私たちはUI設計の業務から手離れして、さらに別のデザイン領域に全力でコミットしていくことができるはずです。

LLMに「意志」を学習させることで、デザイナーがUI設計業務から手離れし、さらに多くの検証を進められるように

AIによる変化は、何もしなくてもツールの進歩によって必ずいずれやってきます。ログラスのデザイン組織は、ツールの成熟を待たず先行して新しいワークフロー構築にチャレンジすることで、より早く未検証のデザイン領域にチャレンジすることができ、それがいずれ強い優位性になっていくと考えています。

AIは、ログラスが目指す「良い景気をつくる」というビジョンに向けて、もっと多くのデザイン領域を検証できるようになるための、絶好の道具だと思います。

各社、デザイン視点でのAI活用を試行錯誤をしているところだと思います。これからもログラスでの検証内容や、その狙いについて積極的に公開していこうと思うので、ぜひ一緒に実験を進め、デザイナーからできることを増やしていきましょう。

このデザイン組織をもっと知る