AIドリブンデザイン開発の全体像 — 要件定義からユーザビリティテストまで、プロセスはどう変わるか

はじめに — プロセス全体が変わろうとしている

AIプロトタイピングツールの登場で「UIを作る速度」は劇的に向上した。v0にプロンプトを書けばReactコンポーネントが数秒で生成され、Claude Codeに指示すればローカルで動くアプリケーションが数分で立ち上がる。

しかし、プロダクト開発は「UIを作ること」だけではない。要件を理解し、情報構造を設計し、プロトタイプを作り、ユーザーに当てて検証し、改善する——この一連のプロセスの中で、AIは各フェーズにどう介入し、何を変え、何を変えないのか。

前回の記事「AIが即座にUIを作れる時代、デザイナーに求められる「3つの判断力」」では、主に「生成」と「評価」の局面に焦点を当てた。本記事ではスコープを広げ、要件定義からユーザビリティテストまで、デザイン開発プロセスの全体像を包括的に整理する。

---

全体マップ — AIドリブンデザイン開発の5フェーズ

まず全体像を示す。従来のデザイン開発プロセスをベースに、AIがどの局面に介入するかをマッピングした。

フェーズ	従来のアプローチ	AIドリブンのアプローチ	変化の度合い
1. 要件理解	ヒアリング → ドキュメント整理	ヒアリング → AIによる構造化・変換	中
2. 情報設計	ペルソナ → IA → ワイヤーフレーム	オブジェクトモデル → AIへのインプット設計	高
3. プロトタイプ生成	Figmaで手作業 → エンジニアが実装	AI生成 → コードエクスポート → 即座に動く	革命的
4. 評価・テスト	ユーザビリティテスト（人間のみ）	AIエージェントテスト + 人間テスト	高
5. 改善・反復	フィードバック → 手動修正	フィードバック → AI修正 → 即再テスト	高

以下、各フェーズを文献と実務知見で深掘りする。

---

フェーズ1: 要件理解 — AIが変えるもの、変えないもの

変わること：構造化の速度

顧客からのインプット——パワーポイント、議事録、RFP——は多くの場合、整理されていない。従来はこれを人間が読み込み、利用者・提供価値・ユースケースに分解していた。

AIはこの「変換」作業を劇的に加速する。パワポをアップロードして「利用者ごとのユースケースに分解して」と指示すれば、数分で構造化されたアウトプットが出てくる。

変わらないこと：ユースケースの「洗い出し」

ただし、AIが構造化できるのはすでに言語化された情報だけだ。ドキュメントに書かれていないユースケース——現場の暗黙知、従業員が日常的にやっている非公式な運用——はAIからは出てこない。

ここは依然として人間がドメインに入り込んで観察し、言語化する必要がある。要件定義の本質的な仕事は変わっていない。

実務上の勘所

サービスブループリントの重要性が増している。 複数システムが関わる統合案件では、As-Is（現行の体験）とTo-Be（目指す体験）の両方をサービスブループリントとして可視化し、そのワンシーンごとに「誰が何をどこまでするか」をリストアップすることが、AIへの最良のインプットになる。

Forresterのサービスデザイン調査が示すように、サービスブループリントは「フロントステージ（顧客が見える部分）」と「バックステージ（見えない部分）」を接続する唯一のツールであり、AIが統合システムのプロトタイプを生成する際の「設計意図」として機能する。

ポイント: AIに渡すべきは「画面仕様」ではなく「サービスブループリント＋ユースケース一覧」。これがあれば、AIは画面を自動生成できる。なければ、表面的なUIしか出てこない。

---

フェーズ2: 情報設計 — 「画面の前にオブジェクトを設計する」がより重要に

OOUXがAI時代にこそ必要な理由

前回の記事でも紹介したSophia Praterの**OOUX（Object-Oriented UX）**とそのORCAプロセスは、AIドリブン開発においてさらに重要性を増している。

📄 Sophia Prater「OOUX: A Foundation for Interaction Design」A List Apart https://alistapart.com/article/ooux-a-foundation-for-interaction-design/

理由はシンプルだ。AIは「1画面」を作るのは得意だが、画面間の整合性——データモデルの一貫性、ナビゲーションの論理性、状態遷移の網羅性——を自力で保つことが難しい。オブジェクトモデルを先に設計しておけば、AIはそれを「制約」として参照しながら、各画面を整合的に生成できる。

Intent Prototypingとの接続

📄 Yegor Gilyov「Intent Prototyping: A Practical Guide to Building with Clarity」Smashing Magazine（2025年10月） https://www.smashingmagazine.com/2025/10/intent-prototyping-practical-guide-building-clarity/

Gilyovが提唱するIntent Prototypingの3点セット——スケッチ、コンセプチュアルモデル、フロー図——のうち、「コンセプチュアルモデル」がOOUXのオブジェクトモデルと直結する。

この2つのフレームワークを統合すると、AIへのインプットとして以下の3層構造が見えてくる：

Layer 1: オブジェクトモデル（OOUI/ORCA）
  → システムの「骨格」。何がどう関係しているか。

Layer 2: ユースケース × サービスブループリント
  → 各シーンで誰が何をするか。

Layer 3: UIの設計意図（スケッチ・フロー図）
  → 画面レベルの方向性。

この3層がAIへのインプットとして揃っていれば、生成されるプロトタイプの構造的品質は格段に上がる。逆に、Layer 3（UIの見た目）だけを渡すと、NN/gの言う「Good from Afar, But Far from Good」——遠くから見るときれいだが、近づくと構造が破綻しているプロトタイプが量産される。

---

フェーズ3: プロトタイプ生成 — 実践パイプラインの現在地

ツールチェーンの進化

2025年後半〜2026年にかけて、プロトタイプ生成のツールチェーンは急速に成熟した。以下は現時点で実用的なパイプラインだ。

パイプラインA：v0起点（高速探索向き）

v0（プロンプト → Reactコンポーネント生成）
  ↓ インタラクション・アニメーション込みで生成
  ↓ コードエクスポート（React/HTML/JS）
  ↓
Claude Code / Codex（ローカルで起動・調整）
  ↓ 数秒でブラウザ操作可能な状態に
  ↓
公開 or テスト

v0の特筆すべき点は、内部的にReact実装を生成していることだ。単なるモックアップではなく、エクスポートすればそのまま動くコードが手に入る。これをClaude CodeやCodexなどのコーディングエージェントに渡せば、細かい調整や追加機能の実装が即座にできる。

パイプラインB：Figma起点（既存デザインシステム連携向き）

📄 Figma Blog「From Claude Code to Figma: Turning Production Code into Editable Figma Designs」（2026年2月） https://www.figma.com/blog/introducing-claude-code-to-figma/

📄 UX Collective「Building AI-driven workflows powered by Claude Code and other tools」（2025年10月） https://uxdesign.cc/designing-with-claude-code-and-codex-cli-building-ai-driven-workflows-powered-by-code-connect-ui-f10c136ec11f

2026年2月、FigmaはClaude Codeとの双方向連携「Code to Canvas」を発表した。これにより：

• Code → Figma: Claude Codeで生成した動くUIを、Figmaの編集可能なフレームに変換
• Figma → Code: Figma MCPとCode Connect UIを使い、デザイントークンやコンポーネントマッピングを維持したままコード生成

デザインシステムが整備されたチームでは、このパイプラインが強力だ。デザイントークン（色、タイポグラフィ、スペーシング）がコードに直接反映されるため、「デザインと実装の乖離」という慢性的な問題が構造的に解消される。

パイプラインC：コーディングエージェント起点（エンジニア主導）

Claude Code / Cursor / Codex CLI
  ↓ 自然言語指示 → 実装
  ↓ ローカルで即起動
  ↓
Figma（Code to Canvas で逆変換・デザインレビュー）
  ↓
調整 → 再実装

エンジニアがプロトタイピングを主導する場合、コーディングエージェントから始めてFigmaに逆変換するワークフローも現実的になった。Dylan Field（Figma CEO）が「The Future of Design Is Code and Canvas」で述べた通り、コードとキャンバスは対立するものではなく、双方向に行き来するものになりつつある。

プロトタイプの二重目的を意識する

📄 Cao et al.「Vibe Coding for Product Design」arXiv（2025年9月） https://arxiv.org/html/2509.10652v1

どのパイプラインを使うにせよ、重要なのはプロトタイプの目的を意識することだ。Cao et al.の研究が指摘する「二重の緊張」は、実務でも頻繁に現れる：

目的	プロンプトの特性	適したツール
探索用 — ユースケースの解像度を上げる	曖昧・方向性のみ	v0、ChatGPT Canvas
検証用 — 構造の妥当性を確認する	詳細・制約付き	Claude Code + OOUI仕様

探索用プロトタイプは「作って見せて、反応を引き出す」ためのもの。完成度よりもバリエーションが重要で、AIの「速さ」が最大限に活きる。

検証用プロトタイプは「この情報設計で破綻しないか」を確認するためのもの。オブジェクトモデルとサービスブループリントをインプットにし、構造的な整合性を重視する。

落とし穴: 探索用のつもりで作ったプロトタイプが、見た目のきれいさゆえに「もうこれでいいんじゃないか」と検証をスキップさせてしまう。前回記事で紹介した審美的ユーザビリティ効果（Tractinsky et al., 2000）がここで働く。

---

フェーズ4: 評価・テスト — AIエージェントと人間の役割分担

プロトタイプができたら、次は評価だ。ここでもAIは大きな変化を起こしている。

AIエージェントによるユーザビリティテストのシミュレーション

📄 Lu et al.「UXAgent: A System for Simulating Usability Testing of Web Design with LLM Agents」arXiv（2025年4月）/ CHI 2025 https://arxiv.org/abs/2504.09407

UXAgentは、LLMエージェントに「ペルソナ」を与え、実際のWebページをブラウザ経由で操作させてユーザビリティテストをシミュレーションするシステムだ。

仕組み:

1. UXリサーチャーがデモグラフィック分布を定義
2. ペルソナジェネレータが数千のペルソナを自動生成
3. 各LLMエージェントがブラウザ（Chrome）経由でWebページを操作
4. 定性データ（エージェントへのインタビュー）、定量データ（操作回数・時間）、動画記録を収集

CHI 2025での発表では、5人のUXリサーチャーによるヒューリスティック評価で「革新的」と評価された一方、「リアルなユーザーテストの代替にはならない」という見解も示された。

AIテストの実用的な位置づけ

📄 Liu et al.「AI in Automated and Remote UX Evaluation: A Systematic Review (2014–2024)」Wiley（2025年9月） https://onlinelibrary.wiley.com/doi/10.1155/ahci/7442179

Liu et al.のシステマティックレビューは、AI活用のUX評価を包括的にマッピングしている。現時点での実用的な結論は以下の通り：

評価タイプ	AIの有効性	人間の必要性
フロー整合性チェック	◎ — 画面遷移の抜け、デッドエンドの検出	低
ヒューリスティック評価	○ — 基本的な問題は検出可能	中（エキスパートレビューが補完）
感情・満足度の評価	△ — 予測は可能だが精度に限界	高
文脈依存の課題発見	× — ドメイン固有の暗黙知は検出困難	必須

二層テスト戦略

現実的なアプローチは、AIと人間のテストを二層構造で組み合わせることだ。

第1層: AIエージェントテスト（自動・大量・低コスト）
  ├─ フロー整合性: 全画面遷移を自動走査
  ├─ ヒューリスティック: Nielsen's 10原則ベースの自動チェック
  ├─ ペルソナシミュレーション: 複数属性のエージェントで網羅
  └─ 出力: 問題リスト + 重要度スコア

第2層: 人間によるテスト（少数・高品質・高コスト）
  ├─ コンテキスト依存の課題: 実際の利用環境で検証
  ├─ 暗黙知の引き出し: ドメイン専門家との共同セッション
  ├─ 感情・直感の評価: 「なんとなく使いにくい」の言語化
  └─ 出力: 構造的改善提案 + 優先順位

第1層で機械的に検出できる問題を潰してから、第2層の人間テストに進む。これにより、人間のテスト時間を本当に人間にしか見つけられない問題に集中させることができる。

📄 Purdue大学「AI-in-the-Loop UCD」arXiv（2025年7月） https://arxiv.org/html/2507.21012v1

Purdue大学のケーススタディが示したように、AIで並列プロトタイピング（複数バリエーションの同時生成）を行い、それをドメイン専門家とのリアルタイム共同セッションで評価するワークフローは、暗黙知の引き出しに特に有効だった。

---

フェーズ5: 改善・反復 — フィードバックループの圧縮

従来のボトルネック

従来のデザイン開発では、フィードバックから改善までのサイクルに大きなボトルネックがあった：

従来: テスト結果 → デザイン修正（Figma） → 仕様伝達 → 実装（数日〜数週間） → 再テスト

デザインと実装の間にハンドオフが発生し、そのたびに情報が劣化する。「デザインではこう意図していたが、実装では違う解釈がされた」という問題が頻発していた。

AIドリブンの反復サイクル

AIドリブン: テスト結果 → AI修正（分単位） → 即座に再テスト

AIコーディングエージェントがプロトタイプの修正を直接行い、Figmaへの逆変換（Code to Canvas）でデザインレビューも可能になった今、フィードバックループは数日から数分に圧縮されている。

この速度変化は、プロセスの質的な変化をもたらす。1回のテストにかけるコストが下がるため、テスト回数を増やせる。「3回のテストで完璧にする」から「10回のテストで漸進的に磨く」へ——反復の哲学そのものが変わる。

ただし「何を直すか」の判断は人間

フィードバックループが速くなっても、「このフィードバックのうち、どれを優先して対応するか」の判断は人間の仕事だ。すべてのフィードバックに機械的に対応すると、全体の整合性が崩れる。

ここで再びフェーズ2のオブジェクトモデルが効いてくる。個別の修正がオブジェクトモデルの制約に反しないかをチェックすることで、反復のたびに構造が劣化するリスクを防げる。

---

統合フレームワーク — AIドリブンデザイン開発の7原則

5つのフェーズを横断して見えてくる原則をまとめる。

原則1: AIへのインプット設計が品質の9割を決める

NN/gの実証研究（2025）が明確に示したように、AIの出力品質はインプットの解像度に比例する。「とりあえず作って」では使えないものが出てくる。オブジェクトモデル＋ユースケース＋UIの設計意図を揃えることが最優先。

原則2: 画面より先にオブジェクトを設計する

OOUX/ORCAプロセスでシステムの骨格を定義してからAIに渡す。これがなければ、画面が増えるたびに整合性が崩壊する。AIが画面を即生成できる今こそ、「画面の前にモデルを作る」の規律が求められる。

原則3: プロトタイプの目的を明示する

「探索用」か「検証用」か。目的によって、プロンプトの解像度もツール選択も変わる。目的が曖昧なプロトタイプは、見た目はきれいだが判断材料にならない。

原則4: 美しさに惑わされない評価の仕組みを持つ

審美的ユーザビリティ効果（Tractinsky et al., 2000）を意識し、「何を評価するか」を事前に決めてからプロトタイプを見る。lo-fi版との並行評価も有効。

原則5: AIテストと人間テストを二層で組み合わせる

AIエージェントで機械的に検出できる問題を先に潰し、人間のテスト時間を「人間にしか見つけられない問題」に集中させる。UXAgentのような研究がこのアプローチを裏付けている。

原則6: フィードバックループを圧縮し、反復回数を増やす

v0→Claude Code→テスト→修正のサイクルを分単位で回す。1回の精度を上げるより、反復回数を増やす方が最終品質は上がる。

原則7: 「何を変えるか」の判断は人間が持ち続ける

AIは生成も修正も高速だが、トレードオフの判断——「ここは分かりやすさを優先してデータ密度を下げる」「この機能はMVPから外す」——は人間の設計判断だ。この判断力こそが、AIドリブン時代のデザイナー・PMの核心的なスキルになる。

---

今日から試せる3つのアクション

1. 次のプロジェクトで「ORCA → AI生成」の順序を試す

OOUXのORCAプロセス（Objects → Relationships → CTAs → Attributes）をExcalidrawやFigJamで30分だけやってみる。そのアウトプットをv0やClaude Codeに渡して生成結果を比較する。モデルなしの生成との品質差を体感できるはず。

2. AIエージェントで自分のプロダクトをテストする

Playwright MCPやVercel AI Agent Browserを使い、自分のプロダクトに対してユーザーシナリオを自動実行してみる。「受付画面からフード注文までの導線に破綻はないか？」のような具体的なシナリオを指定すれば、フロー整合性の問題が見つかる可能性が高い。

3. v0 → エクスポート → Claude Codeのパイプラインを1回やってみる

v0でプロトタイプを作り、コードをエクスポートし、Claude Codeで「これをローカルで起動して」と指示する。この一連の流れを一度体験すると、「動くプロトタイプが数分でできる」という感覚が実感として掴める。

---

引用文献一覧

#	文献	発表	主な知見
1	NN/g「Good from Afar, But Far from Good」	2025年10月	プロンプトの詳細度が出力品質を決定する
2	Gilyov「Intent Prototyping」Smashing Magazine	2025年10月	AI生成前の意図明示が品質を担保する
3	Prater「OOUX」A List Apart / ooux.com	—	画面の前にオブジェクトモデルを設計する
4	Cao et al.「Vibe Coding for Product Design」arXiv	2025年9月	探索用と検証用プロトタイプの二重目的
5	Purdue大学「AI-in-the-Loop UCD」arXiv	2025年7月	ドメイン専門家との共同セッションの有効性
6	Tractinsky et al.「What is beautiful is usable」	2000年	見た目の美しさがユーザビリティ判断を歪める
7	Lu et al.「UXAgent」arXiv / CHI 2025	2025年4月	LLMエージェントによるユーザビリティテスト自動化
8	Liu et al.「AI in Automated and Remote UX Evaluation」Wiley	2025年9月	AI活用UX評価のシステマティックレビュー
9	Figma Blog「From Claude Code to Figma」	2026年2月	コードとキャンバスの双方向連携

---