何が起きたか

AnthropicがClaude Codeに /design コマンドの早期プレビューを追加しました。開発者はターミナルまたはデスクトップアプリから、実装に着手する前にUIのモックアップを作れます。

使い方はシンプルで、/design a few options for {feature} のように指示すると、Claudeが複数のドラフトを「アートボード」として生成します。ユーザーは好みの案を選び、その場で編集し、そこから実装へ進む流れです。生成されたモックアップはArtifactsとして共有可能な形で出力されます。エディタやプロンプト機能はClaude Design由来のもので、それがClaude Codeに直接組み込まれた格好です。利用するには claude update を実行します。

開発者のNate Parrott氏によれば、Claudeは既存のコードベースを読み取り、現行のUIスタイルに合わせたデザインを出すとのことです。

なぜ重要か

ポイントは「デザインツールが増えた」ことではなく、デザインの成果物がコードと同じ場所に置かれたことです。

これまでのAIコーディングは「仕様が決まっている前提」で速くなる技術でした。要件が固まってからの実装は劇的に短縮される一方、その手前の「どんな画面にするか」を決める工程はFigma等の別ツール、別の人、別のレビュー会議に残されたままで、そこがボトルネックになっていました。/design はこの前工程をターミナルに引き込みます。

さらに効くのが「既存コードベースを読んでUIスタイルに合わせる」という挙動です。一般的なデザインツールが出す案は、実装時に自社のデザイントークンやコンポーネントへ翻訳し直す手間が発生します。生成元がコードベースを見ているなら、この翻訳ロスが構造的に小さくなります。デザインと実装の往復で最も時間を食うのは、多くの場合「作ること」ではなく「合っていないものを合わせ直すこと」です。

注意すべき点

早期プレビューであり、完成した仕組みではありません。デザインは実装ステップに引き継がれますが、現時点では手動での保存が必要です。つまり、デザイン案が資産としてリポジトリに自動で蓄積される状態にはなっていません。「案を大量に出す」ことが容易になった分、どれを採用したかを記録する運用は人間側の設計が必要です。

もう一点、複数案が数秒で出ることは、意思決定を自動化しません。むしろ選択肢が増えるぶん、「何を良しとするか」という基準を持つ人の重みが上がります。

💼 事業会社視点：これは自社にどう効くか

日本企業でまず効くのは受託開発とSaaSの初期フェーズです。受託では、要件定義後にワイヤーフレームを起こし、デザイナーがカンプを作り、クライアントレビューを経て実装、という直列の工程が見積の大きな部分を占めてきました。/design で複数案がその場で出るなら、提案フェーズで動くモックを持ち込む競合が現れます。「デザイン工数」を時間で売るモデルは、価格の説明が難しくなります。役員が今すべきは、単価の防衛ではなく、要件の言語化や業務理解といったモックでは代替されない工程へ値付けを移す設計です。

SaaS・EC事業会社では、デザイナー不足で止まっていた管理画面や社内ツールの改善が動き出します。既存コードベースのUIスタイルに合わせて生成される以上、既存プロダクトへの継ぎ足しほど相性が良いはずです。まずは顧客に出ない社内画面で試すのが安全な入口です。

ただし早期プレビューで保存が手動という制約は、そのまま**「誰が最終案を決めたか分からなくなる」リスク**です。案の生成が安くなるほど、デザイン原則とレビュー基準を持つ組織とそうでない組織の差が開きます。デザインシステムの整備を「後回しの投資」から「前提条件」に格上げすべき局面です。