はじめに
現在freeeでAIフィジビリティ検証基盤のPdMをしています。Jです。もともとはフロントエンドエンジニア、デザインエンジニア、プロダクトデザイナーとキャリアを渡り歩いてきました。
どの職種にいても感じていたのは、要求が画面になり体験になるまでの変換のたびにロスが発生する、という問題です。デザイナーがFigmaで描いた画面をエンジニアが実装すると、見た目のズレで差し戻しが入る。デザインシステムのコンポーネントが標準化されても、画面全体の組み立て方（どのパターンを使い、要素をどう配置し、状態遷移をどう設計するか）は各チームの解釈に委ねられていた。コンポーネントが揃っていても、組み合わせ方の解釈が食い違えば「意図と違う」は起き続けます。
2023年頃には、この断絶の橋渡し役として「デザインエンジニア」が業界で注目されましたが、橋渡しを人に求める限りスケールしません。この変換を、人ではなく仕組みで担保する必要がありました。しかし当時、その仕組みは存在しなかった。AIコーディングエージェントの登場が、このパラダイムを変えることになります。
この記事では、freeeのデザインシステムの変遷と、この変換の検証をAIが担うに至るまでの過程を整理します。
要求、UI設計、実装、体験
要求が画面になり、ユーザーの体験になるまでには、3つの変換を経て4つの層を通ります。
- 要求: 機能要求やユースケース。何を実現するか、誰がどう使うか。
- UI設計: 要求を画面構成に落とし込む。どの画面パターンを使い、どの要素をどう配置するか。
- 実装（この記事ではフロントエンド実装に焦点を当てる）: 状態管理や異常系を考慮し、UI設計をコードに具現化する。
- 体験: 実装されたUIを通してユーザーに届くもの。操作感、情報の見通し、業務の流れやすさ。
デザインシステムはUI設計と実装に使われる制約を定義します。freeeでは、その制約を通して届けたい体験を「デザインプリンシプル」として定義しています。
デザインプリンシプルとは、プロダクトの見た目や使い勝手を設計する際の「判断基準」となる基本方針（原則）のことです。プロダクト全体の体験に一貫性を持たせつつ、素早く質の高いデザイン判断を行うための土台として機能します。
プリンシプルは、UI設計の判断基準であると同時に、実装されたUIを通して届く体験の質を測る基準でもあります。
フィジビリティ検証とは、今の要求をデザインシステムの制約を通してUI設計・実装したとき、どのような体験になるかを確認すること。制約の中で設計・実装できるかだけでなく、その結果がプリンシプルの目指す体験に到達できるかまでを含みます。
ここまでの前段：freeeのデザインシステムが辿ってきた2つの試行
freeeのデザインシステムがどのような試行を経てきたかを整理します。
第1の試行：UIの部品を標準化する（vibes）
freeeでは2018年からデザインシステム「vibes」を開発・運用してきました。ボタン、テキストフィールド、テーブルといったAtomsやMoleculesレベルのコンポーネントを共通化し、アクセシビリティを含む品質を標準化しました。
vibesの導入で、部品レベルの見た目と品質は統一されました。しかし、規模が拡大し開発チームが増えていく中で、制約の粒度が足りないことが見えてきました。個々のコンポーネントは揃っていても、要求からUI設計への変換は各チームの裁量に委ねられていました。同じような要求に対しても、アプリケーションによってUI設計が異なり、実装もバラバラになり、ユーザーに届く体験が一貫しなくなっていました。
部品の制約だけでは、要求→UI設計→実装→体験の一貫性は保てませんでした。
第2の試行：プリンシプルを画面パターンに翻訳する（標準UI）
個々の部品ではなく、要求をUI設計に変換するパターンそのものを標準化する。これが第2の試行の答えでした。
freeeではまず、UIを通して届けるべき体験を「デザインプリンシプル」として策定しました。そしてこのプリンシプルを体現する画面パターンとして、高機能UIライブラリ「標準UI」の開発を進めました。この取り組みについては「デザインシステムを拡張し、プロダクト開発の共通基盤を目指す」で詳しく紹介しています。
標準UIは、vibesのコンポーネントを内部的に使用しつつ、業務システムで基本となる3つのパターン（一覧・詳細・作成/編集）を、少数のコンポーネントを組み合わせるだけで作成できるようにしました。UI設計だけでなく、状態管理やAPI連携、エラーハンドリングといった実装ロジックも標準化の対象とし、プリンシプルが目指す体験をUI設計と実装の両面から担保できる状態を目指しました。
この試行の本質は、プリンシプル（目指す体験）を、画面パターン（UI設計と実装の制約）に翻訳したことです。
制約は成熟した。使いこなすためのハードルが残った
第2の試行で制約は成熟し、今も成長を続けています。標準UIの画面パターンのおかげで、要求→UI設計→実装の変換における組み合わせ方のばらつきは大幅に減りました。しかし、2つのハードルが残っていました。
制約を作るハードル
画面パターンレベルの制約を作るには、具象から抽象を描き出せるシニアデザイナーの知識と、エンジニアリングとデザインの両方を持つUIエンジニアの力が必要です。
制約を使いこなすハードル
制約を利用する側にも、コンポーネント仕様の理解、インターフェースの把握、画面パターンの使い分け判断という学習コストが伴いました。そして最も大きな問題は、「この要求を、この制約でUI設計・実装したとき、プリンシプルが目指す体験に到達できるか」の判断が専門家にしかできなかったことです。Figmaでは制約の外でも何でも描けるからこそ、この検証が後回しになっていました。
これらのハードルは、標準UIの成果を否定するものではありません。標準UIがなければ、組み合わせ方の標準化自体が存在しなかった。しかし、標準化された制約を使いこなし、要求から体験までの変換を検証する仕組みは、まだありませんでした。
cutterの構築：制約をAIに渡すだけでは解決しない
では、制約をAIに渡せば解決するのか。答えはNoでした。
freeeではこの問題を解決するために、デザインシステムの制約をAIのコンテキストとして活用する検証パイプライン「cutter」を構築しました（noteの「AIで速く作るほど遅くなる──手戻りを生む「変換コスト」を潰す、基盤化の話」で紹介しています）。このcutterの画面設計エージェントが1枚の画面を設計するとき、実際に参照しているものを並べてみると、コンポーネント仕様だけでは足りない理由がわかります。
- コンポーネントの仕様: UIの部品として何が存在し、どんなインターフェースを持つか
- 画面パターン別の設計ガイドライン: 一覧・詳細・ウィザードそれぞれの構成ルール
- UIの要素別ガイドライン: ボタン配置、フォームバリデーション、モーダルの原則、ライティングルール、誤操作防止など
- デザインプリンシプル: 「業務フロー動線に沿った画面分割」「反復操作の効率」「情報の一覧性」など13のプリンシプル
- 実現可否の判定基準: 機能・レイアウト・視覚表現・インタラクションの4観点での評価
- 階層構造のルール: Container → Area → Segment → Block → ElementというUIの入れ子の文法
これらが整備されていない状態でAIにUIを作らせると、何が起きるか。これは人のチーム開発で起きていた問題と同じ構造です。1人の熟練者なら暗黙知でカバーできても、複数人で開発すると解釈がずれる。AIエージェントも同じで、明示的なルールがなければ各画面で判断がばらつき、スロップ（意図しないばらつき・劣化）を生みます。
設計ガイドラインがなければ、一覧画面と詳細画面の構成ルールの違いを知らず、すべて同じ構造で組み立てる。要素別ガイドラインがなければ、削除ボタンを確認なしで配置したり、バリデーションメッセージの表示位置が画面ごとに異なったりする。プリンシプルがなければ、「動くが使いにくい」UIが生成される。実現可否の判定基準がなければ、制約を無視して自由に組み立ててしまう。階層構造のルールがなければ、レイアウトが破綻する。
人のチーム開発では、これをレビューやペアプログラミングで防いできました。AIの場合は、これらのルールをコンテキストとして渡すことで防ぎます。解決の手段は違いますが、問題の構造は同じです。
つまり、コンポーネント仕様は6つの要素のひとつにすぎません。要求をUI設計に変換する判断基準（ガイドライン）、UIを通して届ける体験の基準（プリンシプル）、変換の実現可否を判定する仕組み。これらすべてをAIのコンテキストとして整備し、さらにFigmaを介さずコードベースで要求からUI設計・実装・体験の検証までを一気通貫で行う。これがcutterの発想です。
cutterを支える4つの要素とAIオーケストレーション
デザインシステムの制約をAIがフィジビリティ検証に使えるようにするために、4つの要素を整備しました。
体験の判断基準をテキスト化する: プリンシプルやコンポーネントの使い分けルールを、AIがスキルとして参照できるMarkdownに変換する。Claude Codeのskillsのように、AIエージェントが設計判断の場面で必要なナレッジを呼び出せる形式にします。
制約の範囲をAIリーダブルにする: 各コンポーネントの仕様をAIリーダブルなドキュメントに整理する。人向けのStorybookやデザインファイルではなく、AIエージェントが機械的に参照・判定できるテキスト形式にすることがポイントです。
変換プロセスを標準化する: PRDのフォーマットと画面設計の記法（UFML、slideの「図じゃなく言語で描く - Common Ground for Design AI Operations」で紹介しています）を定義し、AIエージェントのワークフローに組み込みます。UFMLはユースケースの完遂に必要な画面要素・遷移・アクションを宣言的に記述する中間言語です。
品質評価の仕組みを組み込む: 各ユースケースが必要な要素を満たしているか、複数のユースケースが干渉し合わないか、仕様に曖昧さが残っていないか。こうした品質チェックをパイプラインに組み込み、変換精度を構造的に担保します。
11のエージェントによるオーケストレーション
これらの要素は、渡すだけでは機能しません。要求→UI設計→実装→体験の変換は一度に行えるほど単純ではなく、デザイナーやエンジニアが日常的に行っている設計・実装・検証のオペレーションを丁寧に分解し、各工程を専門のAIエージェントに委ね、中間成果物を次の工程に受け渡していく。このオーケストレーションが品質の鍵です。
cutterでは、中央のオーケストレーターが11の専門エージェントを協調させて検証を実行します。
- プロジェクトセットアップ: プロジェクトの検出・構造作成、ユーザー入力の保存
- プランニング: 要求分析とPRD生成。曖昧な点があれば質問を自動生成
- プロトタイプ準備: PRDからUFMLを生成し、画面構成を決定。共有型定義、ルーティング、スタブページまでを一括生成
- 画面間連携の構築: API連携に必要なモックとデータ取得の仕組みを自動生成
- UI設計: PRD・UFML・プリンシプル・ガイドラインを参照し、画面ごとにコンポーネントの選定と階層構造を決定
- カスタム要素構築: 標準UIにない要素が必要な場合、その設計と実装を並列で実行
- 画面実装: 設計ファイルに基づくコードの生成
- 画面エラー解決: 画面単位の型チェック・lint・ランタイムエラーの修正
- レイアウト検証: スクリーンショットベースで設計仕様との照合。ずれを検出・修正
- UIレビュー: 15カテゴリのデザインレビュー
- 全体エラー解決: プロジェクト全体の型チェック・lint・ランタイムエラーの修正
5〜10は画面ごとに独立したオーケストレーターが起動し、設計→実装→エラー解決→レイアウト検証→レビューのパイプラインを並列で完走します。
各エージェントは自分の工程に必要なコンテキストだけを受け取り、成果物を次のエージェントに渡します。UI設計エージェントが出力した設計ファイルを実装エージェントが読み、生成されたコードをエラー解決エージェントが検証し、レイアウト検証エージェントがスクリーンショットで最終確認する。この中間成果物の受け渡しが、オペレーション全体の品質を担保しています。
画面ごとに並列実行することで、画面数が増えてもコンテキストウィンドウを圧迫せず、画面間の干渉もありません。
検証結果として、PRD、UFML、画面設計書、TSXコード、レビュー結果がセットで生成されます。コードはPreview環境にデプロイされ、ブラウザで操作可能なReactアプリとして確認できます。
プロトタイプは検証の副産物です。本質的な価値は、「今の要求をデザインシステムの制約でUI設計・実装すると、このような体験になる」が企画段階で可視化されること。
何が変わったか
| 観点 | cutter以前 | cutter以後 |
|---|---|---|
| 要求→UI設計 | 専門家が経験則で判断。実装段階で「作れない」が発覚 | AIが制約を参照して自動変換。企画段階で検証 |
| UI設計→実装 | 設計と実装の間に解釈のずれが発生。標準UIで改善されたが完全ではなかった | 設計ファイルからTSXコードが直接生成。解釈のずれが構造的に排除される |
| 実装→体験の確認 | 実装してから初めて体験を確認 | プロトタイプで企画段階から体験を確認できる |
| PRDの品質 | フォーマット・要求密度にばらつき | 構造化され、曖昧な点は評価で指摘される |
| 手戻り | デザイン完成後〜実装中に発生 | 企画段階で検出 |
| チーム構成 | UIエンジニア・デザイナーのアサインが前提 | PdM+エンジニア1-2名で早期リリース実績 |
| コラボレーション | Figmaライセンスや専用ツールの権限が必要。共有範囲が限定されがち | プロトタイプはブラウザで動作し、職種や権限を問わず誰でも触って確認できる |
人の役割はどう変わったか
cutterが手作業で行っていた要求→UI設計→実装の変換を担うようになったことで、人は3つの役割に集中できるようになりました。
制約を磨く: ガイドラインの更新、コンポーネントの追加・インターフェース改善。具象から抽象を描けるシニアデザイナーの知識と、エンジニアリングとデザインの両方を持つUIエンジニアの力が引き続き必要です。
ユーザーと向き合う: 要求分析、ユーザーテスト、そしてユーザーの目の前で業務フローを可視化・言語化するアナリストとしての役割。
AIオペレーションを設計する: 上流から正しいオペレーションを設計し、オーケストレーションの追加や改善、コンテキストの調整、適切なリンター設定などを行う。AIが正しく変換できる仕組み自体を進化させる仕事です。
そしてこれらの役割に共通する判断があります。出来上がったUIが「自社らしいか」「プリンシプルが目指す体験に到達しているか」の評価です。
UIレベルのレビュー（ボタン配置、階層構造、バリデーション位置など）はルールが具体的で、AIで自動化できています。しかしプリンシプルの評価は性質が異なります。プリンシプルは方向性を示すものであり、同じプリンシプルでも業務文脈によって正しい体現の仕方が変わる。さらにプリンシプル同士がトレードオフになることがあり、どちらを優先するかはその業務における体験の優先度に依存します。「ルール違反かどうか」ではなく「この文脈でのバランスが適切か」という判断であり、今のAIには難しい。
ただし、これは永遠に自動化できないという意味ではありません。後述するイテレーションの中で、レビューのたびに判断基準が言語化されガイドラインに昇華されていく。この循環が暗黙知を徐々にAIリーダブルにしていくプロセスでもあります。
フィジビリティ検証には2つの層があり、人の3つの役割はそれぞれの層に関わっています。
- 要求→UI設計→実装の変換: 制約の中で要求を設計・実装できるか → AIで自動化できている。「制約を磨く」と「AIオペレーションを設計する」がこの層の精度を継続的に上げる
- 体験の評価: 実装されたUIがプリンシプルの目指す体験に到達しているか → 人の判断が必要。「ユーザーと向き合う」と「制約を磨く」がこの層を担う
検証が回すイテレーション
重要なのは、人の判断が一方通行で終わらないことです。
ミドル・シニアデザイナーがプロトタイプを操作して「目指す体験に到達できていない」と判断したとき、その判断基準を言語化してガイドラインに昇華する。昇華されたガイドラインはcutterのコンテキストに追加され、次回以降の変換精度に反映されます。
cutterが繰り返し同じコンポーネントで生成に失敗する場合、それはコンポーネント仕様の可読性が低いことを意味します。この情報をもとにドキュメントやインターフェースの設計を改善する。AIの変換精度を上げることが、人にとっても理解しやすい制約定義につながります。
要求→UI設計→実装の変換をAIが担い、体験の評価を人が担う。そして人の評価が制約の改善にフィードバックされ、次回のAIの変換精度が上がる。この循環によって、UIを通して届く体験の質が継続的に向上していきます。
デザインシステムを運用しているプロダクト開発組織へ
freeeの事例を書きましたが、要求から体験への変換にロスが生じる問題は、デザインシステムを運用しているプロダクト開発組織に共通するものだと考えています。
freeeでは3つの試行を重ねてきました。
- 第1の試行（vibes）: UIの部品に制約を定義し、見た目とアクセシビリティを統一した
- 第2の試行（標準UI）: プリンシプルを画面パターンに翻訳し、UI設計と実装の変換パターンを標準化した
- 第3の試行（cutter）: 要求→UI設計→実装→体験の変換をAIが実行・検証し、その結果が制約の改善にフィードバックされる
各組織の文脈によって、試行の形は異なると思います。しかし出発点は共通しているはずです。自社のプリンシプルとそれを体現する制約をAIリーダブルにすること。そして、人の設計・実装・検証のオペレーションを丁寧に分解し、各工程を専門のAIエージェントに委ねるオーケストレーションを構築すること。
コンテキストのAIリーダブル化とオーケストレーションの構築。この両輪が揃うことで、「今の要求をデザインシステムの制約でUI設計・実装すると、どのような体験になるか」をAIが検証できるようになります。
