/designは、これまでClaude Codeにスクリーンショットを貼り付けてインターフェースを修正してもらうやり方と、何が違うのか?
従来のやり方(ターミナルにスクリーンショットを貼り付け、何を変更したいかを口頭で説明する)は、本質的にはスクリーンショットを「参考画像」として扱うものだった。Claudeは画像の内容を読み取り、直接コードを生成または修正する。その間に、独立した編集可能なデザインファイルは存在しない——目に見える成果は、実際に動いているコードそのものだ。/designが異なるのは、その出力が本物のデザインファイル(Claude Designに保存されるキャンバス)であり、直接書き込まれたコードではない点だ。つまり、コードが一切存在しない段階で、デザインファイル上で調整・比較を行い、Team/Enterpriseプランでは他の人と共同編集することさえでき、バージョンが確定してから初めてClaudeにそのデザインをコードへ変換してもらえる。
簡単に言えば、従来のやり方は「画像が入って、コードが出る」だったのに対し、/designは「アイデアやスクリーンショットが入って、編集可能なデザインファイルが出て、そのデザインファイルがコードになる」というものだ——間に独立した、繰り返し修正可能な中間成果物が加わった。
なぜAnthropicは専用の「デザイン」スキルを構築したのか、Claude Codeが直接コードを生成する能力を強化し続けるのではなく?
最も直接的な理由は、デザインと実装がそもそも性質の異なる意思決定だからだ——デザイン段階が気にするのは「この画面はどんな見た目であるべきか、情報はどう配置されるべきか」であり、実装段階が気にするのは「その画面をどうコードで作るか」だ。もし画面を調整するたびにコードを修正する必要があるなら、本来低コストであるべき問題(いくつかのレイアウト案を比較すること)を、より高コストな方法(コードを修正し、再コンパイルし、結果を再確認する)で解決していることになる。
デザインを独立した編集可能なファイルにすることには、もう一つの意味もある。デザインファイルは共有・共同編集できるが、コードの変更権限やレビュープロセスは通常より厳格だ。エンジニアリングの背景を持たない人(プロダクトマネージャーやデザイナーなど)がコードに一切触れることなくClaude Design内で直接画面を調整できるようにすることは、ある意味で「画面をどう見せるかという決定」と「コードでの実装」という2つの権限境界を引き直すことでもある。
実際に使う場合、入力からコードを手に入れるまでの一連の流れはどうなっているのか?
第一段階は入力で、3つの形式のいずれかを取れる。欲しい画面をテキストで説明する(「サブスクリプションプランの比較表、3列で、中央の列を強調表示」など)、既存インターフェースのスクリーンショット、あるいは既に手元にあるデザイン案だ。第二段階として、/designはその入力に基づいて編集可能なキャンバスを返し、Claude Designに保存する——この段階では、最初の結果をそのまま受け入れるのではなく、複数のバージョンを生成して並べて比較することをお勧めする。
第三段階は調整と確認で、キャンバス上で色、間隔、テキストといった細部を直接修正でき、TeamまたはEnterpriseプランであれば他の人を招待して共同編集し、新しいバージョンを公開することもできる。画面が確定したら、第四段階として初めてClaudeにそのデザインファイルを実際のコードへ変換してもらう。最初の3段階はコードを一切書かないため、修正のコストは比較的低く、実際にコードを書く段階に入る頃には、実装対象は多くの場合まだ推測段階の草案ではなく、確定済みのデザインになっている。
今すぐ/designを試してみたいが、何に注意すべきか?この機能はどんな利用シーンに向いているのか?
まず知っておくべきは、これが現在リサーチプレビュー段階にあるということだ。つまり操作の細部、出力の品質、機能の範囲は今後も変わり続ける可能性がある。既に安定・成熟した正式機能として、特に重要で外部に公開される製品デザインにおいて依存するのはお勧めできない。より適した位置づけは「社内向け機能の初期ドラフト段階」だ——例えば社内ツールのインターフェース案を素早く作る、あるいはプロダクトマネージャーが会議前にエンジニアリングチームへいくつかの画面案を見せたい場合など、こうした場面では「デザイナーが先に作るのを待たなくてよい」という効率向上を直接実感できる。
もしチームが既に確立されたデザインシステムやブランドガイドラインを持っているなら、実際の利用時には/designが生成する初版が通常、既存の基準に照らして調整が必要になる点に注意が必要だ——自動的に自社のビジュアルガイドラインが適用されるわけではない。より現実的な使い方は、「いくつかの方向性のドラフトを素早く生成するもの」として扱うことであり、「一発で完成する最終稿」としてではない。現時点でこの機能はClaude CodeのCLIとデスクトップアプリにのみ存在し、他のインターフェースにはまだ展開されていない。
2026年8月17日、AnthropicはClaude Codeに新しいスキル/designをリサーチプレビューとして公開した。アイデア、スクリーンショット、あるいは既存のデザイン案を渡せば、編集可能なClaude Designのキャンバスが返ってくる——これにより、これまで「モックアップは別のツールにあり、コードはClaude Codeにある」という往復が、ターミナルを離れることなく同じ場所で完結できるようになった。
/designはartifactsの上に構築されており、CLIとデスクトップアプリの両方で使える。入力は3つの形式を取れる。欲しい画面の説明、既存インターフェースのスクリーンショット、あるいは既にある設計案だ。どの入力であっても、出力は画像ではなく、Claude Designに保存される本物のデザインファイルだ。単なる画像ではなく本物のデザインファイルであるため、共有や共同編集が可能になる——TeamおよびEnterpriseプランでは、あなたが編集者に設定した誰でもそれを変更し、新しいバージョンを公開できる。
従来の一般的なワークフローは、まずデザイナーが別のツールで画面を作り、その後開発者がそれをコードへと翻訳し直すというもので、その間には待ち時間とやり取りのギャップがしばしば生じていた。/designがまさに解決しようとしているのはこのギャップだ——同じループの中で、画面を説明し、いくつかの選択肢を受け取り、一つを選んで調整し、そのままClaudeに選んだバージョンをコードとして実装してもらえる。プロセス全体が同じツールチェーンの中で完結するため、デザインと実装はもはや「渡して、戻ってくるのを待つ」という関係ではなくなる。
コードを書き終えてからインターフェースが望んでいたものと違うと気づくのではなく、より効率的な使い方は、コードを一行も書く前に/designで同じ画面の異なるバージョンをいくつか生成させ、実際に比較したうえで一つに絞り込み、それからClaudeに実装させることだ。これは従来の「まず書いて、気に入らなければ直す」という順序を逆転させ、意思決定を最もコストの低い段階に移すものだ。
/designは現在もリサーチプレビュー段階にあり、機能自体や操作の細部が今後も変わる可能性があることを意味する。これはAnthropicが2026年8月に配信したClaude Codeのアップデートまとめニュースレターの中で、Concise出力スタイルや利用上限到達後の自動継続といった他のアップデートと並んで発表されたものだ——この一連のアップデートに共通するテーマは、Claude Codeが「ターミナル内のコーディングアシスタント」から、より完成度の高いワークスペースへと徐々に拡張しつつあるということだ。