Anthropicのプロダクトデザイナー、Nate Parrott氏は2026年8月18日、Claude Codeの/designで複数の画面案を扱う早期プレビューを案内した。開発者は実装に入る前に/design a few options for {feature}のように入力し、複数の画面案をアートボードとして受け取る。案を選び、編集した後、そのまま実装へ送る流れだ。アートボードと本番コードは分かれているが、画面を比べて方向を決める作業が、コード変更の直前に入る。
Anthropicはすでに、視覚的な試作をClaude Designで進め、完成した案をClaude Codeへ渡す経路を整備してきた。同社は6月、Claude Codeから/designでデザインプロジェクトを作成、編集、同期できると説明している。コマンド名が8月に初めて登場したわけではない。新たに示されたのは、リポジトリを見ながら複数の選択肢を出し、Claude Design由来の編集とプロンプト操作をClaude Code内で続ける手順だ。生成された画面が本番コードになるわけではない。だからこそ、アートボードがコード変更前の判断材料になる。
アートボードを選んでから、実装を頼む
Parrottが示した/designの手順は、複数案の生成、好みのアートボードの選択、編集、実装という順番で進む。出力は共有可能なモックアップとしてArtifactに作られるという。開発者は、いきなり「この機能を作る」と指示する前に、同じ要求から生まれた画面の違いを見比べられる。
この順序には、実装の前に意図を確かめる場所を置く意味がある。テキストの要求が同じでも、情報の優先順位、入力欄の置き方、一覧と詳細の関係は変わる。少なくとも発表された手順では、アートボードを選んでから実装へ進む。チームで案を共有する場合も、実装後の変更をレビューする前に、どの画面を採るかを話せる。
Parrott氏によれば、Claudeは既存のコードベースを読み、既存UIに合うよう試みる。この「合う」という点は製品側の説明であり、正確さやピクセル単位の再現を保証するものではない。それでも、実装対象の部品やレイアウトを参照して案を作るため、汎用的な静止画から仕様を読み替える工程は短くなる可能性がある。実際にどこまで既存の命名、部品、余白の決め方を取り込めるかは、各リポジトリが持つ情報量に左右される。
6月からあった/designを、8月に深めた
Claude Designは2026年4月17日、Anthropic Labsのリサーチプレビューとして始まった。開始時にはClaude Opus 4.7を使い、ProとMaxの個人向けプランに加え、TeamとEnterpriseの加入者を対象にしていた。プロンプトや取り込んだ素材から案を作り、会話やインラインコメント、直接編集で調整する。その後、共有またはエクスポートしてClaude Codeへ渡す設計だった。初期から、視覚案を使って実装を始めるための受け渡しは用意されていた。
Claude Design本体には、すでに相応の利用基盤がある。Anthropicは6月の更新時点で、最初の1週間に100万人を超える利用者がClaude Designを使ったと公表した。ただし、これは/designコマンドの利用者数ではない。
Anthropicは6月17日、Claude Code側のデザインシステムをClaude Designへ取り込む/design-syncも追加した。同じ更新では、/designを使い、ターミナルを離れずにデザインプロジェクトを作成、編集、同期できるとしていた。デザインをコードベースへ取り込むことや、コードからライブプロトタイプを作ることも説明している。視覚的な探索と実装の間には、すでに往復路があった。
8月の早期プレビューは、既存の経路にアートボード比較と編集操作を明示的に組み込む。Parrott氏は、Claude Designのエディターとプロンプト操作がClaude Codeに入ったと説明した。従来の公開資料にある経路では、Claude CodeからClaude Design MCPサーバーを追加し、/design-loginを実行する方法も案内されている。現行ヘルプページはこの設定を残しており、8月の組み込み型プレビューでMCPやログインの前提が変わるのかまでは説明していない。
リポジトリの文脈が、画面案の差を決める
Claude Designは、コードリポジトリなどからデザインシステムを取り込み、ブランドカラー、タイポグラフィ、コンポーネントを扱えるとしている。インポートした設計情報が十分でなければ、出力もその限界を受ける。/designを実務で使うなら、すでにある部品や配置のパターンにどこまで寄せられるかが価値を左右する。
ここで扱うのは画像生成ではない。Claude Designを作ったプロダクトデザイナーは、HTMLを対話的な視覚媒体として使うと説明し、初期のアイデア出しや協働にはClaude Design、実運用のソフトウェアを出荷する作業にはClaude Codeを充てると区別している。ロゴ作成にも向かないという。その役割分担から見ても、/designのアートボードは完成品の代替ではなく、実装へ渡す前に意図を具体化する成果物と捉えるのが妥当である。
既存の設計システムを自動的に守るかどうかは別の問題だ。ローカルのコンポーネントと、組織側が管理するデザインシステムに差があったとき、どちらを優先するのかは告知に書かれていない。アクセシビリティ、画面幅ごとの振る舞い、状態変化まで実装に反映されるかも、実際の出力を検証しなければ分からない。
早期プレビューで確認すべき境界
案内で明示された利用面はClaude Code DesktopとCLIであり、試すにはclaude updateの後に/designを実行する。だが、対象プラン、アカウントごとの展開、組織や地域、クラウド経由の利用可否、APIでの提供、必要なClaude Codeの版番号は示されていない。Claude Designの現行ヘルプがProからEnterprise向けのベータと記すからといって、同じ条件が/designにも適用されるとは限らない。
データの扱いも、コマンド固有の説明を待つ必要がある。Claude Designの管理者向け文書では、アップロードされた資産は永続的に保存され、データレジデンシー要件には現時点で対応していないとされる。プロジェクトのプレビューは、署名付きトークンでアクセスするAnthropicの別コンテンツドメイン上のサンドボックス化されたiframeで動く。けれども、/designで作ったArtifactが同じ期間で保存され、共有、アクセス、課金にも同じ条件が適用されるかは、今回の告知からは判断できない。
早期プレビューを評価する際は、生成案の見た目だけを比べても足りない。選択したアートボードから何が実装へ渡り、変更後のコードが既存の部品、レスポンシブ対応、アクセシビリティをどこまで維持するかを確認する必要がある。手直しが必要になったとき、どの設計情報をClaude Codeへ戻せるかも実装の使い勝手を左右する。利用資格とArtifactの運用条件が明らかになれば、/designは便利な試作機能なのか、チームの設計レビューを置き換える入口になり得るのかを、ようやく判断できる。
