はじめに
技術選定のPOCの話（tech-selection-poc）でも、フロントエンド品質の話でもない。「見せる」ための動くプロトタイプを数時間で作り、意思決定を加速する話だ。
プロトタイピングにはジレンマがある。Figmaなどの静的モックアップでは「動き」が伝わらず、クライアントやステークホルダーが実際に使えるものを求めてくる。一方で、動くプロトタイプを作るにはエンジニアの数日から数週間が必要で、スプリントの中でそのコストを捻出するのが難しい。
Claude Codeはこのギャップを埋める。「モックアップ → 動くプロトタイプ」への移行コストが、数日から数時間に縮まった。
Figma ⇄ Claude Codeの双方向ループ——設計段階でエッジケースを潰す
従来のワークフローは一方向だった。Figmaでデザインを作り、エンジニアが実装して数日〜1週間後にプロトタイプができる。
2026年に広がっているのは双方向のループだ。Figma MCPとClaude Codeを組み合わせると、ブラウザの実際の表示状態（production・staging・localhost）がFigmaの編集可能なレイヤーに自動変換される。逆にFigmaフレームのリンクをClaude Codeに渡せば、デザイン情報を読み取って実装を開始できる。
Figma ⇄ Claude Code ⇄ ブラウザ確認Anthropicの社内事例として、Product Design teamがFigmaデザインファイルをClaude Codeに投入し、コード生成→テスト→反復の自律ループを設定したとの報告がある（外部一次出典なし）。チームが抽象的な問題を与え、Claude Codeが自律的に作業した後で解決策をレビューし最終調整するという進め方だ。
この双方向ループで得られた意外な効果として、エラーステートやシステムステータスのマッピングが「開発フェーズ」ではなく「設計段階」でできるようになったという報告がある（同じく社内事例として紹介されているもので、外部一次出典はない）。静的なモックでは発見できなかったエッジケースが、動くものを作る段階で早期に浮かび上がってくる。
0・12時間から「動かして判断」する開発へ
デザインスプリントを10年以上運営してきたthoughtbotは、Claude Codeによってクライアントへの提供物が変わったと報告している。従来の「静的なモックアップ」が「実際に操作できるインタラクティブなプロトタイプ」になった。ランディングページがブランドに沿った品質で数時間で完成するようになったという。
より具体的な数字として、$300・12時間で実際のユーザーが使える動くプロダクトを納品した事例がある（Medium）。認証・DBマイグレーション・デザインシステムを含む完全なコードベースが2日でMVPとして動く状態になったケースも報告されている（builtthisweek.com）。
TypeScriptに不慣れなデータサイエンティストが、RLモデルのパフォーマンス可視化のためのReactアプリ全体をワンショットプロンプティングで構築したとのAnthropicの社内報告もある（外部一次出典なし）。コードを理解していなくても完全なTypeScriptビジュアライゼーションが完成した事例として紹介されている。
Jane Streetのエンジニアは「FigmaよりもClaude Codeでデザインすることが増えた」と書いている（janestreet.com）。コードで直接デザインするアプローチへの移行だ。デザイナーがFigmaで静的なレイアウトを作るより、Claude Codeで動くインタラクションを直接作る方が早くなるケースが出てきている。
アイデアが浮かんだらSlack経由でプロトタイプ作成をキックオフし、非同期で開発を始めて結果を見てから投資価値を判断するというフローも実践されている。「議論して決める」から「作って判断する」への転換だ。
EMが管理すべき「速さの罠」——13機能作って使われなかった教訓
速く作れることは諸刃だ。
10日間で13機能のPWAを1人で構築した事例がある（体感10〜20倍の開発速度）。技術的には大きな成果だったが、使ってくれたユーザーは0人だったという。
開発のボトルネックが下がるほど、本来不要な機能まで実装してしまう過剰開発が起きやすい。「作れた」という技術的な達成感が、ユーザー検証を後回しにする心理的バイアスを生む。そして「速く作れる」ことと「届ける力がある」ことは別の話だ。
EMが設計すべきなのは、プロトタイプを作る前に「このプロトタイプで何を検証するか」を明確にする仕組みだ。Claude Codeで速く作れる今だからこそ、「なぜ作るか」の定義がより重要になった。
プロトタイプ品質と本番品質を分離することも必要だ。Claude Codeで速く作れるプロトタイプは、セキュリティ・スケーラビリティ・保守性の考慮が不十分な場合が多い。「プロトタイプをそのまま本番に」という判断は技術的負債の温床になる。
スプリント設計そのものが変わる——EMへの示唆
「エンジニアに1〜2スプリントかかるプロトタイプが1日で作れる」という現実は、スプリント設計の前提を変える。
ステークホルダー管理も変わる。静的資料での説明から「触れるプロトタイプ」でのレビューに変わると、承認速度と合意品質が上がる。「こういうものを作りたい」という抽象的な議論が、「これでいいですか」という具体的な確認に変わる。
PMやデザイナーが自分でプロトタイプを作れるようになる時代が来ると、エンジニアの時間の使い方を再配分する必要がある。Claude Codeがデザインとコードの境界を曖昧にするほど、チーム内のロール分担を明示的に再設計する議論が必要になる。
まとめ
プロトタイピングのコストが下がることで、「とりあえず動かして判断する」という意思決定スタイルが現実的になった。会議室での議論より、動くものを見せる方が議論が速く進む。
ただし、速く作れることが価値になるのは「何を作るか」の定義が正しい場合だけだ。13機能作って誰にも使われなかった事例はそれを教えてくれる。EMとして設計すべきは、Claude Codeの速度を「検証の密度を上げること」に向けることだ。
コメント