顧客の声からFigma・実装・検証まで。PDチームのAI駆動デザイン環境を設計する

AIで画面を作り、Figmaに並べ、コードも更新する。ここまで速くなっても、「なぜこの画面に変えたのか」が消えていたら、次のレビューで説明をやり直すことになります。

PD（プロダクトデザイン）チームのAI駆動デザイン環境は、顧客の声、設計原則、部品、改善案、検証結果を共通のIDと版でつなぐところから組み立てられます。AIにはその範囲で案を作らせ、実行の仕組みで検査し、人が採用を判断する。Figmaとコードを往復しても、判断の根拠をたどれる状態を目指します。

今回は「案件一覧から、次に対応する案件を選びにくい」という説明用の仮想例で、設計から検証までを追います。付属のPython例では参照情報の検査を実行しました。Figmaへの取り込み、実ユーザーのA/Bテスト、本番への自動反映は未実施です。製品仕様は2026年9月14日に確認しています。

最初に固定するのは、ブランドの色より「何を勝手に変えないか」

この例のプロダクトが約束する体験を、「担当者が状況を理解し、次の対応を自分で選べること」と置きます。そこから、AIが画面を作る際の具体的な判断を導きます。

ロゴ、色、書体を揃えるだけでは、急かす言葉や、説明のない自動処理まで防げません。ブランドの約束を、コピーや操作の判断にも結び付けます。

AIには、原則を満たす複数の表現を考えさせます。ただし、案の生成と同時に原則そのものを書き換えさせると、都合のよい基準で自分の案を正当化できます。原則に問題がありそうなら、別の変更提案として理由を残します。

デザインシステムは、一つの業務に必要な部品から育てる

今回必要なのは、案件の一覧、状態ラベル、詳細パネル、ボタンです。まず既存の画面とコードを調べ、同じ役割の部品が重複していないかを確認します。AIはその棚卸しや候補の対応付けを補助できます。

Figmaに似た形があるから同じ部品、と決めないことも必要です。「保存」と「送信」は見た目が同じでも、処理中や失敗時の振る舞いが異なります。形と合わせて、役割、状態、利用条件を記録します。

「全部をFigmaの正にする」「全部をコードの正にする」より、対象ごとに更新元と反映先を決めます。実行時の振る舞いはコード、視覚の探索はFigma、と役割を分けても構いません。両方で独立に変更したものを、無条件で相互上書きしない運用が必要です。

FigmaのCode Connectは、デザイン上の部品を実装側の部品へ対応付ける仕組みです。コード全体をFigmaへ変換する機能とは役割が違います。Code Connect公式ドキュメント

Figmaが2026年9月に掲載したCoinbaseの事例では、テクニカルリードのErich Kuerschnerが、同じデザイン・プロンプト・モデルでCode Connectの有無を比較しています。対応付けがない場合、既存のStepperを使わず、プログレスバーなどから組み直す例がありました。ここから今回参考にするのは、ルールの説明に加え、「使うべき部品に到達できる状態」を整えることです。これは同社の限定された評価で、今回の環境の成果を示すものではありません。Figma掲載の検証事例

Voiceから、まだ決めていないことを残して改善案を作る

今回用意した発言は二つです。いずれも説明用に作成したもので、実際の顧客の声ではありません。

この声から「AIが優先順位を自動で決めてほしい」とは言えません。読み取れるのは、次の行動の判断と比較に負担があることまでです。

原因は、一覧に判断材料がないことかもしれません。詳細を見るたびに一覧の位置や比較対象を見失うことかもしれません。そこで二つの仮説を分けます。

• 仮説A：一覧に「次の作業」がないため、必要以上に詳細を開いている。
• 仮説B：詳細へ移ると比較の文脈が失われ、行き来が負担になっている。

AIによる要約には、Voice IDと原文を添えます。原文、解釈、原因仮説、提案を別項目にすれば、どこで推測が入ったかを確認できます。複数の発言を一つにまとめた際も、誰のどの場面の話かを落とさないようにします。

継続的な顧客発見を支援するプロダクトコーチのTeresa Torresは、AI評価について次のように述べています。

“Correctness is context dependent.”

「何が正しいかは、文脈によって変わる。」（HAVU訳）

同氏は、インタビュー要約の評価で、参加者の語りに沿っているか、重要な場面が含まれるか、引用を作っていないかを挙げています。今回も、読みやすい要約であることと、顧客の意味を保持していることを分けて確認します。AI Evals: A Hands-On Guide for Product Teams

【画像挿入：figure-01.png】

図1：説明用の設計フロー。AIの原因仮説は、顧客が述べた事実とは区別する。

A/Bモックは、同じ基準で違う仮説を試す

Aは一覧に「次の作業・担当・期限」を並べる案。Bは一覧を残し、選んだ案件の詳細を横に表示する案です。どちらも同じ3案件、同じ文言、同じデザインシステムの版を使います。

【画像挿入：figure-02.png】

図2：説明用のUI案。Aは一覧での比較、Bは選択した案件の背景確認を重視している。使いやすさの優劣は未検証。

AIには「良さそうな画面を2案」ではなく、今回変える点と固定する点を渡します。色、コピー、並び順、情報量を全部変えると、どの変更が効いたか判断しにくくなります。この比較でも、レイアウトと情報配置を組み合わせて変えているので、個々の要素の因果効果までは分かりません。

生成するモックには、通常状態だけでなく、0件、長い文言、読み込み中、エラー、権限不足の状態も用意します。ブラウザ上の操作確認と、画面の差分確認を別々に実行します。Playwrightではスクリーンショット比較を自動化できますが、画像が基準と一致しても、判断しやすさやキーボード操作の正しさまでは証明できません。Playwrightの画像比較

添付のHTML試作は、固定データから2案を生成した小さな例です。Bでは案件の詳細を切り替えられます。上記の全状態、実データ、実ユーザーによる評価は含んでいません。

Code to DesignでFigmaに戻すのは、レビューする状態を揃えるため

コードで動くA/B案を作ったら、Figmaに取り込み、並べてレビューする工程を置けます。FigmaのCode to canvasは、ブラウザで動くUIを編集可能なFigmaのレイヤーへ取り込む機能です。リモートMCPサーバーと対応クライアントを使います。Code to canvas公式手順

進め方の例は、次の通りです。

1. A/Bを同じ画面幅、同じデータで表示できるようにする。
2. 取り込み先のFigmaファイルを決め、必要なライブラリを追加する。
3. 対応クライアントへ、対象UIをFigmaに取り込むよう依頼する。
4. 通常状態だけでなく、選択後やエラーなど、レビューしたい状態を取り込む。
5. フレームに実験ID、案、データ版、コードの版を記録し、同条件の案を並べる。

公式ドキュメントには、取り込み先でライブラリを利用できる場合、対応するプロパティにVariablesを自動で結び付ける動作も記載されています。ただし、取り込めたことを、チームのコンポーネント構造や操作仕様がすべて復元された証拠にはしません。部品、Variables、レイヤー構造は結果を確認します。

Figma上で採用した変更は、対象フレームへのリンクと変更理由をコード側へ返します。取り込みと再実装を往復させる工程であり、Figmaとコードが常時、無条件に同期している状態ではありません。Figma MCPのツール一覧

今回のような試行では、共有ライブラリを直接変えず、実験用のフレームとコードの作業領域を使います。案が採用された後に、共通部品へ昇格させる変更と、その画面だけに残す変更を分けます。

ハーネスは作業を回し、ガードレールは越えてはいけない範囲を制御する

ここでいうハーネスは、入力の準備、AIの実行、検査、失敗時の扱い、結果の保存をまとめて動かす仕組みです。ガードレールは、その途中で許可する操作や、先へ進む条件を制限する仕組みです。Skillsは作業手順、RulesやCLAUDE.mdなどの指示文は参照すべき基準を伝えます。文章を書くだけで操作が禁止されるわけではありません。役割の違いは、Rules・Skills・ガードレールを分ける記事でも説明しています。

実装では、生成処理に本番公開の資格情報を渡さず、反映を別工程にする設計が考えられます。共有トークンの変更も、画面の修正と分けてレビューします。具体的な制御方法は、使う開発環境とリポジトリの運用に合わせます。

Claude CodeのHooksを使う場合も、実行タイミングを区別します。書き込み前の検査と、書き込み後の指摘は同じではありません。PostToolUseは処理後に動くため、それだけを「書き込みを防ぐ仕組み」と扱わず、実際の禁止操作がどの経路で止まるかを確かめます。Hooks公式仕様

検査に落ちたら、失敗した項目と対象ファイルをAIへ返し、変更範囲を絞って再実行します。例えば修正は2回までとして、それでも直らなければ停止して結果を残す。この回数は運用例です。AIに基準を書き換えさせたり、検査を外させたりして成功にしない設計にします。

【画像挿入：figure-03.png】

図3：提案する実行構成。添付サンプルが実装するのは、最初の参照情報の検査だけ。

フォルダは、判断と試作と結果が混ざらないように分ける

以下は本番環境へ発展させる際の構成案です。フォルダを作っただけでは、自動読み込みや自動実行は起きません。各実行に必要なファイルを、実行スクリプトやAIクライアントの設定から明示的に渡します。

pd-design-loop/
├── product/
│   ├── principles.md
│   └── brand.md
├── design-system/
│   ├── tokens.json
│   └── registry.json
├── evidence/
│   └── voices.json
├── experiments/
│   └── E01/
│       ├── brief.json
│       ├── variants.json
│       └── decision.md
├── app/
│   └── prototypes/
├── figma/
│   └── captures.json
└── checks/
    ├── reference_gate.py
    └── ui.spec.ts

案を受け渡すJSONには、少なくとも次の対応を持たせます。これは添付の案Aから抜き出した実際の値です。FigmaのフレームURLとコードの版は、取り込み・生成後に別の記録へ紐付けます。

{
  "id": "A",
  "experiment_id": "E01",
  "source_ids": ["V01", "V02"],
  "principle_ids": ["P01", "P02"],
  "component_ids": ["CaseTable", "StatusLabel", "Button"],
  "token_version": "demo-1",
  "status": "draft"
}

実行記録には、入力資料、基準、部品、生成環境、出力の版を残します。同じ入力で同じAI出力が必ず再現できるという意味ではなく、何を条件として比較したかを追跡するためです。

小さく動かすなら、案と根拠の対応を検査してみる

添付のpractice-kitは、上の構成案から参照検査だけを切り出した独立した例です。Python 3の標準ライブラリで動きます。元のPDプラグインを変更するものではありません。

python3 gate.py
python3 test_gate.py
python3 render_mocks.py

gate.pyは案のJSONを検査し、違反があれば終了コード1を返します。test_gate.pyは正常例と破損例を実行します。render_mocks.pyは、検査を通った固定データからA/BのHTMLを生成します。この生成スクリプトはAIモデルを呼びません。

2つの正常例と5つの破損例を確認しました。ただし、部品名はJSONの申告を調べているだけで、実装のコードを解析してはいません。引用の文字列が一致しても、その引用が改善案を論理的に支えているかは別です。

追加で、引用などの参照はそのままに、仮説だけを「顧客はAIによる自動優先順位付けを求めている」へ変えて実行すると、エラーは返りませんでした。正確な引用を付けても、この検査では意味の飛躍を判定できません。根拠の追跡を機械で支え、意味の適合は原文を読んで確認する。この役割分担が、この小さな例の範囲です。

読者がAIで試すなら、同梱のvoices.json、brief.json、registry.jsonを渡し、次のように依頼できます。

案件一覧の改善案をA/Bで提案してください。
Aは「判断材料の不足」、Bは「一覧と詳細の往復」を検証する案です。
各案に、原文を変えない引用とVoice ID、原因仮説、
使う設計原則ID、部品ID、弱点を付けてください。
登録済み部品で足りなければ、不足を報告してください。
顧客の希望を補わず、推測を仮説と明記し、どちらもdraftで返してください。

想定出力は、Aが一覧への判断材料の追加、Bが一覧と詳細の併置。どちらもV01・V02とP01・P02に紐付き、それぞれの弱点を示す形です。このAI出力例は外部AIサービスでは未実行です。人は、引用と提案の間に飛躍がないか、既存部品で実際に表現できるかを確認します。

自動化するA/Bの準備と、顧客による評価を分ける

A/Bモックの生成、表示確認、計測イベントの確認、実験結果の集計は、それぞれ自動化の対象になります。ただし、AIが2案を採点した結果を、顧客によるA/Bテストの代わりにはしません。

今回なら、対象ユーザーに「次に対応する案件を選び、その理由を答えてください」と依頼します。所要時間だけでなく、期限や対応状況を読み違えていないかを見ます。速く選べても、判断を誤るなら採用しません。少人数の試作評価では、提示順の影響を避けるよう順序を入れ替え、どこで迷ったかを観察します。

本番で比較するなら、割り当て単位、対象者、主指標、悪化させない指標、必要なデータ量、終了条件を開始前に定めます。案件をチームで共有する製品では、同じチーム内で別UIになる影響も考慮します。必要な標本数は、現在の指標と検出したい差に依存するので、一律の人数は置きません。

計測の設計例は、variant_exposedを割り当てた案が実際に表示されたとき、case_selectedを対象案件が選ばれたとき、task_completedを対応作業が完了したときに記録するものです。実験ID、案、対象版を紐付け、画面を再表示するたびに別の案へ切り替わらないようにします。クリック数だけで業務の完了を代用しないようにします。

結果が出ても、「Bが勝ったので全画面を詳細パネルにする」とは進めません。背景を読む必要があるタスクではBがよく、単純な比較ではAがよい可能性があります。結果と適用条件を部品の利用ルールへ戻します。

チームに残したいのは、次の改善で使える判断

この環境は、一度に全画面を自動化しなくても始められます。一つの業務、一つの部品群、二つの改善案を対象に、原文から判断まで追跡できるかを確かめます。

PDは課題と体験、ブランドの判断を持ち、エンジニアは実装と検査、事業責任者は優先度や導入判断を担う。少人数なら兼務できますが、「検査を通ったので誰も見ずに反映された」という空白は作らないようにします。

次の改善で再利用するのは、完成画面だけではありません。「何を見落としていたか」「どの条件でこの案が合ったか」「何を自動検査でき、何が人の判断だったか」です。その記録があれば、顧客の声が増えるたびにデザインシステムと仕事の進め方を育てられます。

HAVUは、デザインシステム構築、デザインとコードの連携、AIワークフローの設計を支援しています。自社の思想・部品・顧客の声をつないで運用したい場合は、最初に対象とする業務と、現在どこで判断が途切れているかから整理できます。PDチームのAI駆動デザイン環境について相談する