Independent Proposal · Requirements Reform 2026
プロダクトの速さを決めるのは「コーディング時間」ではない。「翻訳コスト」という見えない構造的負債を、要件定義工程ごと再設計する。
Figma の「絵（ピクセル）」と本番環境の「コード」が乖離する 二重の真実（Dual Truth） 問題。デザイナーの意図をエンジニアが再解釈する 翻訳コスト が、終わらないレビュー修正ループを生んでいる。
本提案は、Markdown 仕様書 DESIGN.md を SSOT とし、OSS デザインエンジン open-design で「動作する UI コード」を即座に生成する Code-as-Design パラダイムへの移行を提言する。要件定義 → 初回検証 → 合意のサイクルは、数日 → 15 分以内 へ短縮される。
Section 01 · 構造的負債
プロダクトのデリバリー速度を決めるのはコーディング時間ではない。「何をどう作るか」の合意形成と、仕様を実装へ移し替える「翻訳」の時間だ。Figma を起点としたプロセスは、もはや単なるボトルネックではなく、組織的な構造的負債である。
デザイナーは 3 日 かけて Figma を作り込む。エンジニアは 2 日 かけて、その「絵」をコードで再現する。レビューでは「余白がズレている」「ホバーの反応がおかしい」と指摘が飛ぶ。— これはエンジニアの技能の問題ではない。「絵」と「コード」という二つの真実が並立していること自体が引き起こす、構造的欠陥なのだ。
静止画としてのデザインファイルは、原理的に以下の要素を担保できない。実装後に初めて発覚するため、リリース直前の致命的な手戻りを常態化させる。
ホバー時の影、フォーカスリング、トランジション — 静止画では「気持ちよさ」を伝えられない。実装後に「思ってたのと違う」が必ず起きる。
3 ブレークポイントの絵では、その間の連続的なレイアウト崩れを表現できない。アダプティブ挙動は実装してみないと判断不能だ。
アクセシビリティは、Figma のフレーム上で観測できない。「動かないもの」で合意した設計は、後工程で必ず再交渉を迫られる。
レビューで指摘される 「余白のズレ」「ホバーの違和感」 は、エンジニアの技能の問題ではない。
「絵」と「コード」が並立すること自体 が引き起こす、構造的欠陥である。
Section 02 · 設計契約
DESIGN.md — AI への 9 セクション設計契約Figma の代わりに、AI エージェントへの厳格な「設計契約（Design Contract）」を Markdown で書く。9 セクションの構造化スキーマが、汎用的な UI（AI Slop）ではなく、ブランド独自の規律に基づいた決定論的なコードを生成させる。
DESIGN.md は人間と AI が共に理解できる 唯一の真実（SSOT）。Markdown だから Git で管理され、PR とレビューがそのまま走る。「絵」を経由しないから、ステークホルダーは「動くもの」を見て判断でき、合意形成の精度が劇的に向上する。
ブランド哲学・トーン・視覚的密度
プライマリ・サーフェス・テキストの役割定義
フォントスタック・階層・ウェイトの厳格指定
角丸・シャドウ・境界線の規律
グリッド・最大幅・余白スケール
Z 軸の重なりとレイヤー構造
「グラデーション禁止」等の Slop 抑制
ブレークポイント毎の挙動変化
推論時の重み付け指示
Markdown は人間と AI が共に理解可能な 最大公約数。Git で管理でき、PR レビュー・履歴・ブランチ・マージがそのまま走る。「実装の真実」を構造化データ資産に変える第一歩はここから始まる。
Section 03 · 自律型エンジン
open-design — 既存エージェントを オーケストレーション する OSSopen-design は Claude Code / Cursor などの既存コーディングエージェントを束ね、DESIGN.md に沿った決定論的コードを並列生成する OSS デザインエンジン。31 種類以上の専門スキルと 5 次元自己批評アルゴリズムが、AI Slop を構造で防ぐ。
「保守的」「実験的」「ミニマル」「リッチ」など — 1 つの指示から最大 5 つのバリアントを 15 分以内に並列生成する。「描く」コストがゼロになることで、同等の時間で 10 倍以上の実験が可能になる。
用途に応じて最適化された専門スキルを選ぶ。代表的なスキル例：
pm-spec仕様書（PRD）生成
saas-landingSaaS LP 生成
dashboard管理画面生成
web-prototypeWeb プロト
mobile-appモバイル UI
pricing-page価格ページ
… 全 31 種類以上。すべて DESIGN.md を参照し、ブランド規律に従って生成される。
AI 特有の低品質出力（Slop）を防ぐため、生成物は 5 軸で 1〜5 点採点される。スコアが 3 点未満 の指標が 1 つでもあれば、AI は自己批判に基づき Auto-Refine（自動修正）を自律的に実行。人間がコードを見る前に、ブランドの設計契約に準拠した品質まで底上げされる。
If score < 3 → Auto-Refine. この決定論的なリトライプロセスが、凡庸な UI を構造で排除する。
Section 04 · 新ワークフロー
数週間かかっていたサイクルを、1 日以内に再編するための実装ガイド。発見フォーム → 並列生成 → サンドボックス検証 → Symphony 承認、の 4 ステップで決定履歴を構造化資産に変える。
9 セクションスキーマに基づき設計言語を固定する。組織の SSOT を Markdown として確立。
Surface / Audience / Tone / Brand Context / Scale / Constraints の 6 項目で AI の意図をロックインする。
open-design generate --skill saas-landing --parallel 3 を実行。Warp ADE が localhost:3001~3003 で複数案を即座に並列起動。
OpenAI Symphony を「制御平面」として運用。決定履歴を構造化資産として残し、承認案をプロダクションへ Promote する。
このフローの最大の効果は、組織内の 役割の再定義である。可視化を依頼する側だった PdM が、自ら仮説を即座に可視化し、価値を判断するクリエイターに変わる。言語化能力こそがプロダクトの品質を決定する時代へと移行する。
Figma 操作スキルがなく、デザイナーへの依頼で初期検討に数日。抽象要件を「動く UI」へ変換する手段を持たない。
言葉で書く DESIGN.md と発見フォームから、自ら 3〜5 案を 15 分で生成。動くプロトタイプで合意形成までを主導する。
Section 05 · コスト構造
移行は経済的な「主権（Sovereignty）」の奪還でもある。固定費型のライセンス・特定 SaaS への依存を脱却し、データ管理を自社リポジトリへ取り戻す。
| 項目 | 従来のデザインプロセス (Figma) | Code-as-Design (open-design) |
|---|---|---|
| ライセンス費 | $15-50 / 人 (Dev Mode 含) | $0（OSS + BYOK） |
| 翻訳コスト | 膨大（絵をコードで再現） | ZERO（コードを直接生成） |
| 探索コスト | 1 案につき数時間 | 3〜5 案を 15 分で並列生成 |
| データ管理 | 商用 SaaS に依存 | Local-First / 自社リポジトリ |
Figma を 廃止するのではない。構想フェーズの 「ホワイトボード」へと 降格させる。実装フェーズではコード（DESIGN.md）が唯一の真実となる。
Section 06 · 2026 年の開発標準へ
この変革は AI 時代のプロダクト開発における不可逆な進化だ。「仕様を書き、エージェントに生成させ、コードで議論する」プロセスへの転換は、組織を「二重の真実」という呪縛から解放する。
既存システムを解析し DESIGN.md として設計言語を固定。SSOT の基礎を築く。
新規 LP や小機能で open-design による 並列生成 を試験導入。実物で品質と速度を実証する。
OpenAI Symphony を「制御平面」として導入し、決定履歴を構造化データ資産として蓄積。組織の「ソフトウェア・ファクトリー」化を進める。
実装フェーズにおける Figma 依存を脱却。すべての 「実装の真実」をコードへ集約。
デザインの主権を「絵」から「コード」へ戻す決断は、単なる効率化を超える。2026 年以降の「ソフトウェア・ファクトリー」において、永続的な競争優位をもたらすものだ。
「仕様を書き、エージェントに生成させ、コードで議論する」 — この一連の動詞こそが、これからの開発標準である。Figma は「ホワイトボード」となり、DESIGN.md と open-design が「真実」を担う。今、コード主権を取り戻すことが、未来のデリバリー速度を決定づける。
「絵」を経由しない設計により、終わらないレビュー修正ループから組織を解放する。
「描く」コストがゼロになり、同時間で 10 倍以上の探索量。意思決定の質が構造的に上がる。
SaaS ロックインから Local-First へ。決定履歴を構造化データ資産として、組織内に蓄積し続ける。
