こんにちは！CTO室でエンジニアをやっている別府( @_nuk00_ )です！ 今回の記事では、AIがデザイン案を自動で作成する時代に、なぜ管理コストのかかるデザインシステムを作ったのか。その理由と、デザインシステムの中身を紹介します。 記事は前編と後編の2つに分けています。 前編にあたるこの記事では、土台となる「人とAIが協働するデザインシステムの作り方」を紹介します。 後編では、その土台の上でモック作成やレビューをAIに任せて、業務がどのように変わったのかをお伝えします。 PO・デザイナー・エンジニアが役割を越えてUIを作っているチームの方に、特に読んでもらいたい内容です。 AIで、専門外の人もアイデアを形にできるようになった アイデアを生み出す時間が減ったら、デザインの手直しが増えた デザイナーの判断基準と部品を、AIとチームの共通言語にする 判断基準を言葉にする コードでもFigmaでもなく、Storybookに置く 部品が指すイメージを揃える 「共通言語」を、AIに読ませる ツールは変わる、思想は残る まとめ AIで、専門外の人もアイデアを形にできるようになった 私たちのチームでは、POがデザインを作ったり、エンジニアが企画を考えたりと、役割を越えてプロダクト作りに関わる場面が増えています。AIの支援で、専門外の人でもアイデアを素早く形にできるようになったからです。 この越境の取り組みは、同じチームの山田が登壇資料にまとめています。個人がAIで速くなっても、それだけでは組織の成果にならない。だから役割の壁を越える。そしてその越境を一部の人で終わらせないために、AIを工程に組み込む、という話です。この記事は、その中のデザインという領域で何を作ったかという具体の話になります。 speakerdeck.com アイデアを生み出す時間が減ったら、デザインの手直しが増えた しかし、AIの支援の元で最初の案が早くできても、デザイナーに見せると「ここは変えたい」というやり取りが何度も発生していました。本来デザイナーに見てほしいのは、案の細かい手直しではなく、その機能ならではの体験は何かという、もっと本質的な部分です。このままでは案を作るのが早くなっても、開発のリードタイムは早くなりません。 「仕事は最初から完璧を目指さず、まず6割で出す」とよく言われますが、その6割を毎回ゼロから積み上げるのは、もったいない。もしデザイナーがレビューのたびに口頭で伝えていた判断基準を先に明文化しておいて、案を作る人もAIもそれを踏まえれば、レビューは残りの本質的な4割を詰める時間に割くことができます。 私がデザインシステムに期待した役割は、この最初の6割の部分を完成した状態にすることでした。 デザイナーの判断基準と部品を、AIとチームの共通言語にする 6割を最初から済んだ状態にするために、デザインシステムには2つのものを置きました。「どういう時にどれを使うべきか」という判断基準と、それを形にする部品です。 判断基準を言葉にする 先ず、デザインのレビュー工程を眺めると、何度も往復していたのは部品の見た目ではなく、「ここは目立たせたいのか」「この操作は一度止めて確認させるべきか」といった判断のやりとりでした。 この往復を解消するために用意したのが、ガイドラインとDo/Don'tです。色やスペーシングといったトークンやコンポーネントももちろん揃えていますが、一番大事にしているのはこの2つです。 例えば「primaryのボタンは、その画面で一番してほしい操作にだけ使う」といったルールです。部品の使い分けも同じで、「選択肢が〇〇個までならラジオ、〇〇個までならSelect、それ以上で絞り込ませたいならCombobox」のように、数と操作方法で線を引いています。1つのコンポーネントの使い方だけでなく、どれを選ぶかというコンポーネントをまたいだルールも明記している形です。「見た目を整える」みたいな方針ではなく「この時はこれを使う」と書いておくと、人はその場で判断できますし、AIに渡しても同じ判断をしてくれるようになります。 コードでもFigmaでもなく、Storybookに置く 次に、判断基準をどこに置くかは、割と迷いました。コードのコメントやREADMEに置くと実装とのズレはなくなるのですが、POやデザイナーの目には触れません。一方で、Figmaに置くとデザイナーは読めるのですが、実装との乖離が起きやすくなります。 そこで、ガイドラインとDo/Don'tはコンポーネントと同じリポジトリでStorybookにMDXとして書いて、社内向けにGitHub Pagesで公開することにしました。コンポーネントの隣にあるので実装と一緒に更新されますし、URLを開けばPO・デザイナー・エンジニアの誰でもすぐ見られます。 部品が指すイメージを揃える 判断基準があれば「どの部品を使うか」は決まります。次に揃えたいのは、その部品が具体的に何を指すかです。企画・デザイン・実装で同じ部品を指せれば、そのたびに翻訳し直す必要がなくなります。 そのため、Figma Libraryとコードのコンポーネントは同じデザインシステムから揃えています。Figmaで「ボタン」を置いた時点で、実装で使うコンポーネントもPropsも決まっている状態です。 ただ、Figmaとコードを別々に直していると、すぐにズレが生まれます。そこでコードを正として、コードのコンポーネントをFigmaへ反映するスキルをClaude Code向けに用意しました。新しいコンポーネントを作った時や既存のものを直した時にこのスキルを実行すると、Figma側に用意したテンプレートを参照して、Figma Libraryのコンポーネントが更新されます。コードとFigmaがズレないことを、人の注意ではなく仕組みで担保しています。 「共通言語」を、AIに読ませる 私たちのチームでは、先ほどのFigma同期だけでなく、実装でもClaude CodeなどのAIツールを使っています。そこで、ガイドラインとDo/Don'tをAIにも渡すために用意したのが、これらを読み込むスキルです。 スキルに入っているのは、Storybookに書いたガイドラインのMDXそのものです。リポジトリから都度読みに行かせないのは、使うのがエンジニアだけではないからです。POやデザイナーもClaudeのデスクトップアプリから同じスキルを使えるように、リポジトリにアクセスできなくても動く形にしました。 スキルは用途ごとに分かれていて、実装用と照会用の2つがあります。 実装用のスキルはUIを実装する作業で指示しなくても自動で発火して、AIは作業に入る前にガイドラインを読んだうえで、人と同じ判断基準で案を作ったり、デザインシステムのコンポーネントを使って実装します。 lookupという照会用のスキルは「このコンポーネントの仕様を教えて」のような質問で発火して、一般的なUIライブラリの知識ではなく必ずMDXを根拠にして答えるので、POやデザイナーもガイドラインに沿った答えを得られます。どちらが読んでいるのも人が読むのと同じMDXなので、AI向けの説明を別に書く必要はありません。 例えば、AIにFigmaのデザインとガイドラインを参照させると、こんな提案が返ってきます(一部抜粋・ぼかしています)。 Figmaは上下とも同じ塗りボタン(primary相当)ですが、ガイドラインではprimaryはその画面の主操作にだけ使うことになっていて、そのままだと違反します。 FigmaのデザインとガイドラインをAIが照らし合わせて、ルール違反になる箇所やデザイナーに確認すべきポイントを絞り込んでくれています。部品についても同じで、Figmaのデザインから対応するデザインシステムのコンポーネントとPropsを抽出してくれるので、Figmaで決めた見た目をそのまま実装に持ち込めます。 判断基準と部品の両方をAIが読める状態になると、POがデザイン案を作る段階からルールが反映されて、デザインの完成度は実装に入る前に6割まで出来上がります。人は残りの4割、つまりその機能に固有の体験や難しい判断に集中できるというわけです。 こうして、PO・デザイナー・エンジニアとAIが、同じデザインシステムを見てデザイン案を作ることができるようになりました。 結果として、体感ではありますが、以前は1つのIssueに仕様を詰める1時間のMTGが2〜3回必要だったのが、今は1回のMTGで2〜3個のIssueをさばけるようになってきました。 ツールは変わる、思想は残る ここまで読んで、「デザインシステムを作らなくても、Claude DesignやFigmaのエージェントをチューニングすればできるのでは？」と思った方もいるかもしれません。 確かに可能ですが、私は、ツールとコンテキストは分けて持つべき、と考えます。なぜなら、デザインを作るツールはこの1年でも入れ替わり続けていて、これからも変わっていくからです。一方で「私たちのプロダクトをどのような思想でデザインするのか」は、ツールが変わっても変わりません。 だからデザインのコンテキストはデザインシステム側に置いて、デザインをつくるツールはそれを参照するように仕組み化しています。 例えば、使うAIツールがClaude DesignやFigmaのエージェントでも、Claude CodeでもCodexでもGeminiでも、同じ判断基準で動かせます。変わるのはツール側の読み込み口だけで、思想とルールには手を入れずに済みます。 ツールは変わっても、思想は残る。だから私は、デザインシステムをコンポーネント集ではなく、思想の置き場としてゼロから作りました。 まとめ AI時代にデザインシステムを作ったのは、人とAIが同じ判断基準と部品を使えるようにするためでした。「どういう時にどれを使うか」という判断基準を言葉にして人が読める場所に置いて、同じものをAIにも読ませました。この2つが揃うと、案を作る段階で6割の完成度が済んだ状態から始められて、人は残りの本質的な4割に時間を使えるようになります。 デザインシステムがすでにあるチームなら、判断基準が言葉になっているか、AIがそれを読める形になっているか、一度確認してみると良いかもしれません。ツールがどれだけ賢くなっても、その判断基準を書き、育てていくのは私たちです。 後編では、この土台の上でAIにモック作成からレビューまでを任せて、デザインシステムを使えば使うほど育つ仕組みにした運用を紹介します！ ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

そもそもMCPとは何か？ MCPはAIと外部サービスがやり取りするための共通規格 AIに仕事を依頼する際、その仕事に必要な情報をどのように渡すかは重要です。例えば、Antigravityにプログラムの修正を依頼する場合、修正対象のコードに加えて、GitHubに登録された不具合の報告や、Figmaで作成された画面のデザインも判断材料になります。

はじめに こんにちは！セーフィー株式会社の金原です。 先日（9月5日土曜日）、Agile459（アジャイル四国）と TOKUSHIMA Cyber Security Meetup が主催するイベント「Agile Japan 2025 サテライト 徳島」にお招きいただき、徳島で脅威モデリングワークショップを実施しました。 脅威モデリングは、システムの設計段階でリスクに気づくための強力なアプローチです。また、うまく活用できればセキュリティ文化醸成やセキュリティ組織能力を上げることもできます。一方で、「覚えることが多い」「どこから始めればいいかわからない」「やってみたけどうまくいかなかっ