Figma, Claude, OpenAI, Pencil比較：生成コードとワークフローの決定的な差

Last updated at 2026-06-22Posted at 2026-06-22

最近の生成AI、デザインからプロトタイプまで一気に仕上げてくれて本当に凄いですよね。

でも、Figma Make、Claude Design、OpenAI Product Design、Pencil.devと選択肢が増えてくると、「結局、自分の現場にはどれを導入すればいいの？」と迷う方も多いのではないでしょうか。

結論から言うと、「これが最強」というツールは存在しません。なぜなら、こちらの出したい要件を形にする『実装能力（カバレッジ）』だけで見れば、どれもほぼ互角だからです。

じゃあどこで差がつくのか？それを確かめるために、今回は「サポートチケット起票フォーム」と「会議室予約ウィジェット」という実務的な2つの課題を各ツールに丸投げしてみました。
「緊急時だけ担当者を必須にする条件分岐」や「60分枠の連続マス予約ロジック」、後から加えた無茶振り修正への対応など、生成されたコードを実際に1行ずつ検証しています。

見えてきた本当の差は、機能の有無ではなく、「吐き出される素のコードが綺麗か」「ビルドなしですぐメンバーに共有できるか」「上流の仕様をもみほぐすのに向いているか」「いつものIDE内で完結するか」といった、開発ワークフローへの馴染み具合と出力品質にありました。

その検証をレポートとしてまとめてみました。

ちなみに私の個人的なおすすめはPencilです。その記事はこちら

検証対象

ツール	提供形態	成熟度
Figma Make（FM）	Figma内のMake機能	安定提供
Claude Design（CD）	claude.ai/design	リサーチプレビュー（Opus基盤）
OpenAI Product Design（OAI）	ChatGPT内のProduct Designプラグイン	2026年6月出荷直後
Pencil（PC）	VS Code/Cursor拡張 + Claude Code	アーリーアクセス

目的

事前調査・ツール調査。

検証した課題

お題①：サポートチケット起票フォーム
- 件名・カテゴリ・優先度・詳細説明・添付・担当者の入力
- 一覧表示（番号/件名/優先度バッジ/状態/更新日時）
- 条件分岐：「緊急のときだけ担当者を必須にする」異常系
- 後出し修正：エスカレーション赤ボタンを非破壊で追加
お題②：会議室予約ウィジェット
- カレンダー・時間枠（30分刻み、9:00～18:00）
- 予約者名＋利用目的の入力
- 状態ロジック：「60分予約時は連続2枠が両方空きでないと不可」
- 後出し修正：30分/60分トグル追加、確定ボタン緑化

どちらも「初稿の正常系」→「複雑な異常系・状態ロジック」→「後出し修正」のフローで、AIツールの実装能力と編集ワークフローを追跡しました。

作成日:2026年6月15日時点

前提：本検証はすべてデザインシステム未接続（DSなし）の条件で実施しました。CDのフロントエンド接続やPencilのTailwind自動連携など、DS接続時の効果は別検証が必要です。

本レポートについて：個人による調査・検証をもとに、AIを用いて作成しています。各ツールは更新が速く、記載内容には誤りや、実際の挙動・最新の仕様と異なる箇所が含まれる可能性があります（AI作成物にありがちな誤りを含みます）。重要な判断の際は、公式情報および実際の挙動でご確認ください。

1. エグゼクティブサマリ

生成コードを実査した結果、 コードが存在する範囲では、どのツールも指定した要求項目を実装していた。指定したフォーム要素・一覧・優先度バッジ・必須バリデーション・「緊急時のみ担当者必須」という条件分岐・予約の「連続2枠」状態ロジック・後出し修正（エスカレーションボタン追加／30・60分トグル／確定ボタン緑化）まで、いずれもコードに実装が確認できた。

具体的には、お題①（チケット）は全4ツール、お題②（予約）は CD・PC・OAI で全項目をコードで確認。 「何が作れるか」での優劣はほとんどない。

差が出るのは 「どう作るか」——そのまま出力させた生成コードの素の品質、手で直せる編集面の有無、ビルドなしで動くか、ワークフローと民主化度である。素のコード品質は、スタイルをCSS別ファイルに分ける OAIが最もすっきり、次いで PC（スタイルは別記述だが固定データはベタ書き）、FM・CD はスタイルがベタ書きで、PC・FM・CDは要調整（ツール別の詳細は5. ツール別の要点）。

手で直せる編集面はPC（キャンバス→コード反映）・CD（Editメニュー）にあり、上流のUXフロー監査はOAIに固有。用途とチーム前提での選び分けが現実解となる。

2. ツール概要

各ツールの提供形態・入出力・特徴・強み/留意点をまとめる（コード実査の根拠は4-2. 集計）。

Figma Make（FM）

提供形態/動作環境：Figma内のMake機能（クラウド実行）。AIクレジット制（プラン/シート依存）。成熟度＝安定提供。デザインのコピーや公開には有料版が必要
入出力：入力＝プロンプト＋画像/Figmaデザイン添付。出力＝動くWebプロトタイプ＋React/TSX、GitHub push、Figma Sites公開
Figmaとの相互編集（双方向）：Make→Figmaはプレビューをデザインレイヤーとしてコピーし継続編集、Figma→Makeは「ポイントして編集」で初回出力の汎用コンポーネントを自社UIへ差し替え。コメント記入も可
強み/留意点：Figmaワークフロー直結で往復編集が強い。一方、既定Reactで他フレームワーク変換に手間・クレジット消費が大きい・スタイルはベタ書き・自由なベクター手作業に弱い

Claude Design（CD）

提供形態/動作環境：claude.ai/design（クラウド実行）。Claude Opus系基盤のリサーチプレビュー。Pro/Max/Team/Enterprise向け（Enterpriseは管理者有効化）。週次トークン上限あり
入出力：入力＝会社概要＋クイズ形式ヒアリング、コードベース（React/Vue/Next.jsのフロントサブフォルダ）・Figma/Sketch・PPTX/PDF・PNG/JPG/SVG・カラー定義(テキスト/JSON)。出力＝デザイン案/プロトタイプ/スライド（複数案）。書き出しはZIP(HTML/CSS)・PDF・PPTX・Canva・スタンドアロンHTML・Claude Codeハンドオフ。共有はURL＋4権限（閲覧/コメント/編集/閲覧不可）
特徴機能：デザインシステム自動抽出（カラー/タイポグラフィ/コンポーネント/レイアウト）、Tweaks（"Describe a tweak…" と文章で指示する微調整）、選択部分への個別チャット、インラインコメント、背景画像の差し替え。DS設定は Default／登録済みDS／None を選択
強み/留意点：初稿の初速・複数案探索・Claude Code連携が強い。一方、会話主体でキャンバス直接操作は弱い・Figmaエクスポート無・週次トークン上限・既定出力(HTML＋JS)のスタイルがベタ書き。DS接続の有無で準拠度の差が大きい（未接続はきれいでも自社条件から外れやすい）
参照：Claude Designを始める、管理者ガイド、Claude Design 完全ガイド、【Claude Design】見せてもらおうか Claude Designの性能とやらを、Claude Designとは？できること・機能・使い方・料金をわかりやすく解説

OpenAI Product Design（OAI）

提供形態/動作環境：Codex内のProduct Designプラグイン（クラウド実行、ChatGPT/Codex系契約）。2026-06出荷直後・実績薄。タブは Prototype（UI設計）／Slide Deck（資料）／Other（白紙）／From Template
入出力：入力＝ブリーフ/素材、スクショ・参考URL・Figma(URL/画像/テキスト仕様)・既存コード・画像。出力＝レビュー可能なインタラクティブプロトタイプ＋実コード（既定React/Vite、指示でVue）。Figmaネイティブ(.fig)書き出しは不可、SVG／PNG＋レイアウト仕様での受け渡しは可。保存先フォルダは事前指定が可能
目玉＝UX/UIレビュー（監査）：画面・フローを「使いにくさ・情報設計・視認性・アクセシビリティ」の観点で監査し、優先度付き改善案まで出力（実例は付録A）。曖昧なアイデアから3案のビジュアル探索→試作までの往復が短い
強み/留意点：UXフロー監査・URL/スクショ起点の生成・スタイルがCSS別ファイルで最もすっきり。一方、出荷直後で情報少・承認/CLIの摩擦・アプリ内に手動編集面なし（Figma/Canvaへ）。
参照：OpenAI「Codex」の新プラグイン Product Design とは？

Pencil（PC, pencil.dev）

提供形態/動作環境：VS Code/Cursor拡張 or macOSアプリ＋Claude Code。MCPサーバーはローカル動作（生成モデル利用にはクラウド接続が必要）。ブラウザ版・自動保存なし。Pencil本体は無料・アーリーアクセス（別途Claude Code側のコスト）
入出力：入力＝AIプロンプト、Figmaインポート（コピペ可だが画像は不完全）、コードベースからのコンポーネント再現。出力＝ベクターキャンバス＋React/HTML/CSS（.penをGit管理）
特徴：MCP経由で座標・トークン値を渡しピクセル精度でコード化。手動編集をHTML/CSS/Reactへ即同期（トークン消費なしで微調整）。Tailwind config／UIキット／CSS変数を連携
強み/留意点：VS Code/Cursor内でデザイン〜コード生成を完結でき、.penと生成コードをGitでバージョン管理できるのが最大の強み（開発フローにそのまま乗る）。座標精度の高いコード化・手動編集の自由度も高い。一方、開発者向けで学習コスト・協業弱め・固定データがベタ書き
参照：pencil.dev

補足：CDのトークン消費は1回の修正で約6%という実感値（週次上限に効くため、微修正を手動GUIへ寄せられるPC/CDが運用上有利）。

3. マスター比較表（12機能 × 4ツール）

順序は「はじめ方→出力→編集→取り込み→DS連携→ハンドオフ→コスト」。◎=得意／○=できる／△=弱い・限定的／×=不可。本検証で確認したセルには注を付した。

機能	FM	CD	OAI	PC
はじめ方/入力	Makeファイル新規→チャット（画像/Figma添付可）	claude.ai/design→会社概要→クイズ形式で詳細確認→生成	Product Designプラグインにブリーフ/素材	VS Code/Cursor拡張 or macOSアプリ→Claude Code→`.pen`作成→Cmd+K
主な出力	動くWebプロトタイプ＋コード（既定でReact、スタイルはベタ書き）	プロト/スライド（複数案）＋コード（既定でHTML＋JS、スタイルはベタ書き）＋Claude Codeハンドオフ	3案提示→コード（既定でReact、スタイルはCSS別ファイル）	ベクターキャンバス＋コード（既定でHTML＋JS、スタイルは別記述・固定データはベタ書き、`.pen`はGit内）
プロンプト修正	◎ 逐次	◎ 会話で逐次・1指示から複数案	○ 会話で（承認フローを挟む）	◎ 可・複数エージェント並列も
手動GUI編集	△ 「ポイントして編集」中心。自由な手作業は苦手（別キャンバスへ書出し要望あり）	○ Editで選択→左メニューで色/数値（検証で確認）	× アプリ内に編集面なし。Figma/Canvaへ書出して編集	◎ キャンバスで選択→右メニュー、手動編集をコードへ反映
コード編集	◎ コード直編集→プレビュー反映（双方向）	○ HTMLを直接出力（実装の本格化はClaude Code）	○ 実コード生成（既定React、スタイルはCSS別ファイル。生成コードあり）	◎ 生成コードを直接使用・双方向同期
既存資産の取り込み	Figma/画像/スクショをコピペ添付	コードベース（フロントのサブフォルダ）接続・参考画像	ライブURL/スクショからプロト化（強力）	Figmaインポート・コードベースからコンポーネント再現
デザインシステム連携	DSファイルからコンポーネントを貼り「差し替えて」	`src/components/`/`src/styles/` 接続で自動抽出・準拠（最強機能）	参照デザインを指定（情報少）	Tailwind config/UIキット/CSS変数を取込み、MCPで正確なトークンを渡す
コードのハンドオフ	コード書き出し/GitHub push/Figma Sites公開	Claude Codeでコード化 / ZIP・PDF・PPTX・Canva書出し	Figma/Canvaで継続（実コードはCodex側）	コードがそのまま成果物（Git管理）
UXレビュー/分析	△ 薄い	△ 薄い	◎ ユーザーフロー監査・使いにくい箇所の指摘（目玉）	× 機能なし
動作環境	クラウド（ブラウザ/デスクトップ）	クラウド（Pro/Max/Team/Enterprise、Opus基盤）	クラウド（ChatGPT/Codex系契約）	ローカル（別途IDE等でAIでチャットが行える環境）、ブラウザ版なし
コスト/制限	AIクレジット制（上限あり）	週次トークン上限・Figmaエクスポート無し	出荷直後で実績薄・承認フロー要	Pencil本体は現在無料＋AI利用課金が別途・自動保存なし・協業弱い
向いている人	デザイナー中心・Figma運用チーム	非デザイナー（創業者/PdM/マーケ）＋エンジニア連携	PdM/ディレクター（上流・仕様）	開発者/デザインエンジニア

4. 検証結果：要求項目のコード実査

ほぼ同一プロンプトを各ツールへ投入し、生成コードを実査して要求項目の実装有無を確認した。判定は二値。

✓ ＝コードに実装を確認（確認内容は 4-2. 集計末尾）
— ＝コードが無く未確認（判定不能）

このフォルダにコードが存在するのは、お題①が全4ツール、お題②が CD・PC・OAI。FMの予約ウィジェットはコードが無く（PNG画像のみ）、コードでは未確認。これはReact出力をVueへ変換する過程でクレジット上限に達し、コード取得を断念したため。

4-1. 要求項目チェックリスト（コード実査）

お題① サポートチケット起票フォーム

#	要求項目（観点）	FM	CD	PC	OAI
1	件名（必須）（意図）	✓	✓	✓	✓
2	カテゴリ4種（意図）	✓	✓	✓	✓
3	優先度4種（意図）	✓	✓	✓	✓
4	詳細説明（必須）（意図）	✓	✓	✓	✓
5	添付（任意・複数）（意図）	✓	✓	✓	✓
6	担当者（任意）（意図）	✓	✓	✓	✓
7	送信・キャンセル（意図）	✓	✓	✓	✓
8	一覧（番号/件名/バッジ/状態/更新日時）（意図）	✓	✓	✓	✓
9	日本語UI（意図）	✓	✓	✓	✓
10	必須未入力でインラインエラー（異常系）	✓	✓	✓	✓
11	緊急のときだけ担当者必須（異常系）	✓	✓	✓	✓
12	エスカレーション赤ボタン追加（修正）	✓	✓	✓	✓
13	既存レイアウト非破壊（修正）	✓	✓	✓	✓

OAIの一覧は「番号」列と「更新日時」列をコードで確認。
雛形の「重複警告モーダル」「送信中ローディング」は本検証フローで投入されず、いずれのコードにも実装がないため対象外。

図：各ツールが生成したお題①（サポートチケット起票フォーム）の画面。

お題② 会議室予約ウィジェット

#	要求項目（観点）	FM	CD	PC	OAI
1	日付選択カレンダー（意図）	—	✓	✓	✓
2	30分刻み・9:00〜18:00（意図）	—	✓	✓	✓
3	空き/予約済みの区別（意図）	—	✓	✓	✓
4	予約者名（必須）＋利用目的（意図）	—	✓	✓	✓
5	予約確定ボタン（意図）	—	✓	✓	✓
6	予約済み一覧（時間/予約者/目的）（意図）	—	✓	✓	✓
7	時間枠ホバーでハイライト（意図・動的）	—	✓	✓	✓
8	予約済み枠は選択不可（異常系・競合）	—	✓	✓	✓
9	60分時は連続2枠が空きでないと不可（異常系・状態）	—	✓	✓	✓
10	30分/60分トグル追加（修正）	—	✓	✓	✓
11	確定ボタン緑化（修正）	—	✓	✓	✓
12	既存グリッド非破壊（修正）	—	✓	✓	✓

OAIのホバーハイライトをコードで確認。

図：各ツールが生成したお題②（会議室予約ウィジェット）の画面。

4-2. 集計

お題①（チケットフォーム）：コードが存在する全4ツールとも、13項目すべての実装をコードで確認した
お題②（予約ウィジェット）：CD・PC・OAI はコードが存在し、12項目すべての実装をコードで確認した

コード実査で確認した主な実装

CD：チケット＝カテゴリ/優先度4種・緊急時のみ担当者必須・エスカレ赤ボタン。予約＝連続2枠ロジック・空き枠ホバー・確定ボタン緑化
PC：チケット＝緊急時必須バリデーション・エスカレ赤ボタン。予約＝連続2枠判定・ホバー・緑化
OAI：チケット＝一覧の番号/更新日時列・緊急時必須・エスカレ赤ボタン。予約＝連続2枠判定・ホバー・確定ボタン緑
FM：チケット＝緊急時必須・エスカレ赤ボタン。予約＝コード無し

5. ツール別の要点（コード品質と運用）

機能が横並びである以上、実務差はそのまま出力させた生成コードの素の品質とワークフローに出る。実際に各ツールでコードを出力して確認した要点は次のとおり。

ツール	既定の出力形式	素のコード品質	手動編集面	ビルド要否	民主化度
FM	React	スタイルがベタ書き（要調整）	弱い（コード変換経由）	要	高
CD	HTML＋JS	スタイルがベタ書き（要調整）	有（Edit→左メニュー）	不要（即開ける）	高
PC	HTML＋JS	スタイルは別記述だが固定データがベタ書き（要調整）	有（キャンバス→コード反映）	不要（即開ける）	低（IDE前提）
OAI	React	スタイルをCSS別ファイルで管理。4ツール中もっともすっきり	無し（Figma/Canvaへ）	要	中（承認/CLI寄り）

素のコードのすっきり度は OAI ＞ PC ＞ FM・CD（PC・FM・CDは要調整）。FMはReactが既定のため他フレームワークへの変換に手間がかかり、クレジット消費も大きい。(個人の感想)

6. 使い分けの見取り図／実務レコメンド

目的・場面	おすすめ	理由
仕様整理・UXのダメ出し（上流）	OAI	フロー監査・URLからのプロトタイプ化
プロトタイプの高速作成	FM / CD	Figma運用ならFM、非デザイナー起点ならCDのヒアリング型。CDはHTMLで即動・共有も速い
既存デザインの改修・バリエーション出し	CD	複数案・Tweaksで方向性を振れる
IDE内で設計〜実装を完結・Git管理	PC	VS Code/Cursorで完結し、コードがそのまま成果物・`.pen`をGit管理
そのまま使いやすい初稿コード	OAI	スタイルがCSS別ファイルですっきり。HTMLで即開いて確認するならCD / PC
正本保存	Figma	—

※ 複雑な状態遷移の設計に明確な得意ツールはない。本検証で扱った範囲の状態ロジック（緊急時のみ担当者必須・予約済み枠の選択不可・60分の連続2枠）は各ツールとも実装できたが、それ以上に複雑な状態遷移の設計品質は本検証の範囲外。

総括：機能では4ツールに優劣はほぼない。選定軸は「そのまま出力させたコードの素の品質（OAIが最もすっきり、PC・FM・CDは要調整）」「ビルドなしで速く確認・共有したいか（CD・PC）」「上流の仕様・フロー検討か（OAI）」「Figma運用に乗せるか（FM）」「IDE内で完結しGit管理に乗せたいか（PC）」というワークフロー適合。役割分担での併用が現実解。

継続観測すべき変数：① プロンプト修正のトークン/クレジット消費（CDの週次上限・約6%/回に対し、手動編集の面を持つPC・CDで往復をどれだけ減らせるか）。② 成熟度の変化（OAI＝出荷直後、CD＝リサーチプレビュー、PC＝アーリーアクセスは機能追加で評価が動くため四半期ごと再検証）。

7. 参考：設計→実装→検証を定型化して保守性を平準化する運用

5. ツール別の要点（コード品質と運用）のとおり素のコード品質にはツール差があるが、これは各ツールの「素の出力の癖」であり、設計の前提固定・出力規約・検証を定型化すれば、どのツールを主軸にしても保守性をある程度そろえて育てられる。その一例として、検証用に作成したテストリポジトリ（未公開）の運用構成を紹介する。

運用の考え方

規約をプロンプト／スキルに落とす：「inline styleを避けCSS変数（デザイントークン）で書く」「コンポーネント分割」「DRY」などのコーディング規約を、毎回手で指示せず prompt／skill として定型化し、初稿から保守的なコードへ寄せる
段階を固定する（仕様駆動）：単発プロンプトに頼らず「要求の定型化 → 画面遷移をMermaidで確定 → 仕様確定 → 実装前チェック → 実装 → 検証 → 承認済みを記録」という工程を固定。各段階の入力・出力と「次へ進む条件」を決め、AIが前提を推測で補完して出力がぶれるのを防ぐ
.pen を設計の一次情報にする：見た目だけで終わらせず、Page Spec／Data・Interaction Contract／State Matrix（loading・empty・error・no permission を含む）／受け入れ条件まで .pen に残す。これがないとAIは「見た目が作れた」で止まりやすい
不足時は止める：必要な契約が .pen に無ければ実装へ進まない／データ契約が曖昧ならモック前提で止める／新規フレームを乱立させず既存更新を優先する——という「止まり方」を先に決め、推測での前進を防ぐ
スタックを固定する：実装は既存の React / Vue＋TypeScript＋Tailwind CSS、パッケージは pnpm に固定し、新規ライブラリは既存で足りない場合のみ最小限。技術選択のぶれを抑える
役割を分離する：設計・実装・検証を別エージェントに分け、読んでよいファイルや使ってよいツール（設計＝read/search中心、実装＝edit/execute、検証＝browser）を役割ごとに制限する

ツール構成（組み合わせ）

デザイン：Pencil.dev。.pen を設計の正本として Git 管理
実装環境：VS Code ＋ GitHub Copilot
実装スタック：React / Vue ＋ TypeScript ＋ Tailwind CSS、パッケージマネージャは pnpm
常時ルール（custom instructions）：
- 日本語で返す
- .pen を一次情報にする
- 配置・命名・分割・禁止事項を固定（React・Vue 別に用意）
prompt（スラッシュコマンドで明示実行）：(各 React 版あり)
- /design-governance（前提固定）
- /make-design-system（デザインシステム部品）
- /make-design（画面設計）
- /design-guide（コンポーネントガイド）
- /error-design-before-code（エラー3分類設計）
- /pre-implementation-check（実装前チェック）
- /initcode（実装）
- /post-implementation-validate（実装後検証）
skill（自然文の依頼を拾う）：
- screen-transition-before-design（画面遷移図を先に確定）
- design-screen-from-brief（粗い要求→画面設計）
- design-to-code-workflow（hidden。「これ作って」を段階管理へ寄せる）
- create-ui-part（部品切り出し）
custom agent（役割分離）：
- pencil-designer（設計・契約整理）
- error-architect（エラー契約）
- pencil-implementer（実装）
- pencil-verifier（契約検証）
- pencil-playwright-verifier（browser/Playwright 検証）
検証：型検査・lint に加え、Playwright／browser で .pen 契約と実装UIの差分・主要導線を確認
ディレクトリと運用：
- design/＝設計の正本
- docs/requests/＝依頼・実行ログ
- frontend/＝実装コードの正本
  pre-commit チェックあり
設計思想：
- DRY（同一ロジックを2箇所に書かない）
- AIが書いたコードも自分の言葉で説明できる状態にする
  その他、自身のルールを入れておくとある程度いい形で作成してくれる。ルールの考え方はこちらの記事を参考に。

Pencil.dev を設計の一次情報、VS Code / GitHub Copilot を実装・検証の実行基盤とし、prompt・skill・agent で工程と出力規約を固定する構成。これにより、どのツールを主軸にしても一定の保守性を確保しやすくなる。

正直な現状（完全自動化にはまだ不足）

prompt・skill・agent の「入口」と「実装規約」は揃っているが、AIだけで安定して回すには次の4点がまだ弱い。これらを作り込み、仕様駆動で段階を固定して初めて品質が安定する。逆にここが弱いと、AIは不足情報を推測で補完し、同じ依頼でも出力がぶれる。

依頼の型：対象ユーザー・画面／部品名・目的・必須データ・主要アクション・対象範囲・どこまで自動で進めてよいか、を毎回固定する入力テンプレート
設計契約：.pen に Page Spec／Data・Interaction Contract／State Matrix（loading・empty・error・no permission）／受け入れ条件まで残す。特に受け入れ条件が無いと「見た目が作れた」で止まる
検証ゲート：型検査・lint に加え、画面レンダリングや状態差分の自動確認（Playwright・Storybook 相当）。現状はTypeScript検査止まりで見た目崩れ・状態取りこぼしを拾いにくい
状態管理：要求受付／設計中／設計承認済み／実装中／検証待ち／完了を記録する場所。これが無いとセッションをまたいで未承認仕様のまま実装が進む

現時点では「Kiro のような専用ツール」が必須なのではなく、Kiro 的に“段階を固定する運用”が要る段階であり、この4点は本検証時点では作り込み途上である。

留意：本検証はデザインシステム未接続（DSなし）で実施しており、CDのフロントエンド接続やPencilのTailwind/トークン取込みなど実DS接続時の効果は未確認。CDの既定出力（HTML＋JS）は多ファイルのコンポーネント群にはなりにくく、本実装はClaude Codeへ渡す前提が活きる。規約を厚くするほど生成トークン消費が増える点はトレードオフ。

付録A：OpenAI Product Design のUX監査（実例）

OAIの目玉であるUX監査を、会議室予約ウィジェットのデザイン2案に実施した例。画面・フローを4観点で評価し、優先度付きの改善案まで出力させた。

観点	案1	案2
使いにくさ	時間選択・入力フォーム・予約一覧が分散し視線移動が多い。予約完了まで遠回り	日付→時間枠→予約情報の流れが明確で迷いにくい。選択中の枠がやや分かりにくい
情報設計	4要素は揃うが主導線が曖昧。右の一覧が中央の予約済み枠と役割重複	手順の優先順位が明確。見出し番号が効き初見でも進めやすい
視認性	全体は整うがフォームが控えめで、次の入力位置としての強さが弱い	並びが素直で読みやすい。カレンダー/説明文がやや淡い
アクセシビリティ	状態判別が色依存。選択中状態の表示が弱い	構造は明快。改善余地は選択中の強調・60分不可時の理由表示・フォーカス表示

主な改善提案（P1）：案1＝予約導線の一本化・選択中枠の強調／案2＝選択中枠の明示・60分予約不可の理由提示
結論：案1は一覧性、案2は操作の流れに優れ、定型業務では案2 を推奨

コード生成だけでなく「既存／試作画面のUX評価と改善提案」を出力できる点が、他3ツールにないOAIの特徴。