Projects / 実践記録

Claude DesignとClaude Codeは何が違う？/design-syncでつまずいた話

本ページはアフィリエイトプログラムを利用しています

Claude Designを触っていて、最初に引っかかった。

Claude Desktopには、Chat、Cowork、Codeがある。
さらにClaude Designも出てきた。

名前だけ見ると、なんとなく分かる。
でも、実際に使おうとすると境界が分かりづらい。

Claude CodeでもUIは作れる。
Claude Designでもプロトタイプは作れる。
では、何が違うのか。

さらに、自分はClaude DesktopのCodeタブから/design-syncを使えば、Claude DesignとClaude Codeをそのままつなげると思っていた。

でも、できなかった。

2026年6月21日時点の自分の環境では、Claude DesktopのCodeタブから/design-syncを進めようとすると、Design側の認可で止まった。
/design-loginも使えなかった。

一方で、Claude Designそのものは使える。
ブラウザのclaude.ai/designからは普通に触れるし、standaloneのClaude Code CLIなら回避できる可能性が高い。

この記事は、Claude Designの公式紹介ではない。

実際に触って、つまずいて、調べて、現時点ではこう扱うのがよさそうだと整理した記録です。

なお、Claude Designはresearch preview / betaとして提供されている。
この記事の内容は、2026年6月21日時点の観測です。
仕様、コマンド、使用量の扱いは今後変わる可能性があります。

最初に結論。DesktopのCodeタブからは無理だった

先に結論を書いておく。

自分の検証では、Claude DesktopのCodeタブから/design-syncを使ってClaude Designへつなぐことはできなかった。

理由は、Claude Proではないからでも、Claude Designが使えないからでもない。
Claude DesktopのCodeタブという環境の制約だった。

この環境では、DesignSyncに必要な認可が足りず、さらに/design-loginのようなターミナル前提のコマンドも使えなかった。

公式のClaude Code Desktop docsにも、DesktopのCodeタブでは一部のterminal-dialog commandが使えず、isn't available in this environmentと返ることがある、と説明されている。
今回の挙動は、その系統に近い。

なので、現時点の整理はこうなる。

やりたいこと	現時点の扱い
Claude Designをブラウザで使う	できる
Claude DesktopのサイドバーからClaude Designを開く	できる
DesktopのCodeタブから`/design-sync`する	自分の環境では不可
standalone CLIから`/design-login`する	回避策として現実的
すぐ試すためにブラウザ操作する	当面のしのぎとしてあり

ここを誤解すると、かなり時間を使う。

「Claude Designが使えない」のではない。
「Claude DesktopのCodeタブから、いま自分が期待した形ではつながらない」という話。

Claude DesignとClaude Codeは、目的が違う

Claude DesignとClaude Codeの違いは、モデルの能力だけで見ると分かりづらい。

Claude CodeでもWebページは作れる。
CSSも書ける。
スクリーンショットを見せれば、かなり直せる。

だから最初は、こう思いやすい。

Codeでできるなら、Designはいらないのでは？

でも、実際に触ると違った。

Claude Designは、見た目の探索に寄っている。
画面、プロトタイプ、スライド、ワンページ資料、マーケティング用のビジュアルを、会話しながら組み立てる場所。

Claude Codeは、動くコードに寄っている。
リポジトリを読み、ファイルを編集し、テストを回し、差分を作る場所。

かなり乱暴に言えば、こう。

観点	Claude Design	Claude Code
主な目的	見た目、プロトタイプ、資料を作る	実装、修正、検証を進める
得意なこと	方向性を出す、見た目を比較する、画面を触りながら直す	リポジトリに入れる、既存コードに合わせる、テストする
人間の確認点	これで見た目や体験がよいか	これで壊れず動くか
成果物の置き場	Designのプロジェクト、HTML/PDF/PPTXなど	ローカルのコード、PR、commit
向いている段階	設計前、画面案、比較検討	実装、修正、公開前検証

ここを分けると、だいぶ見えやすくなる。

Claude Designは、最初の画面案を作る場所。
Claude Codeは、その案をコードベースに入れていく場所。

もちろん、重なる部分はある。
でも、中心が違う。

CodeでできるからDesignはいらない、とは言い切れない

ここが少し面白いところ。

Claude Codeでも、うまく指示すればUIを作れる。
ローカルでdev serverを立てて、スクリーンショットを見て、DOMを読んで、修正していくこともできる。

自分もCodexやClaude Codeで、何度もそのやり方をしている。

ただ、そこには人間側の手間がある。

Claude Codeに見た目を作らせる場合、こちらが確認ループを組まないといけない。
レンダリングする。
スクショを撮る。
見た目の違和感を伝える。
CSSを直す。
また見る。

コードの品質確認としては自然。
でも、デザイン探索としては少し重い。

Claude Designは、最初から見た目を作って、そこにコメントし、直接編集し、別案を出す前提になっている。
公式ヘルプでも、チャット、インラインコメント、直接編集を使い分けてデザインを詰める流れが説明されている。

つまり、Claude Designは「コードも書けるAI」ではなく、「見た目を会話で詰める作業台」として見る方がしっくりくる。

Codeでもできる。
でも、Designの方が迷いにくい場面がある。

/design-syncでつまずいた

Claude Designで作ったものをClaude Codeへ渡せるなら、かなり使いやすい。

Anthropicの公式発表でも、Designが準備できたらClaude Codeへhandoffできる、と説明されている。
Claude Designのヘルプにも、Exportの選択肢としてClaude Codeへのhandoffが載っている。

そこで、自分はClaude DesktopのCodeタブから/design-syncを試した。

期待していたのは、こういう流れ。

Claude Designで画面や部品を作る
Claude Codeで/design-syncする
Design側の成果物やdesign systemがCode側に入る
実装へ進む

ただ、実際には認可で止まった。

DesignSyncにはDesign側のauthorizationが必要。
でも、DesktopのCodeタブでは、その場で/design-loginを実行できなかった。

この時点で、かなりややこしい。

Claude DesktopからClaudeにログインしている。
Claude Designも使える。
Claude Codeも使える。

なのに、DesktopのCodeタブからDesignSyncしようとするとつながらない。

ここが今回いちばん分かりづらかった。

原因は、Claude DesktopのCodeタブという環境だった

調べていくと、問題はPro契約の有無ではなさそうだった。

Claude Designは、2026年6月21日時点でPro、Max、Team、Enterprise向けのbetaとして案内されている。
自分の環境でも、Claude Design自体は開ける。

一方で、Claude DesktopのCodeタブは、terminal-based CLIとは完全に同じではない。

公式のDesktop docsでは、DesktopとCLIの違いが整理されている。
Desktopは並行セッション、ペイン配置、視覚的な差分確認には向いている。
一方で、CLI向けのflagや一部commandにはDesktopで使えないものがある。

特に、interactive panelを開くタイプのterminal-dialog commandは、Codeタブでは使えず、standalone CLIから実行する必要があるとされている。

/design-loginも、自分の検証ではこの制約に引っかかった。

つまり、DesktopのCodeタブは使いやすいけど、Claude Code CLIそのものではない。
ここを混ぜて考えると迷う。

回避策はstandalone CLI

恒久的にDesignとCodeをつなぎたいなら、現時点ではstandalone CLIを使うのがよさそうだ。

最短ルートは、この形。

npm install -g @anthropic-ai/claude-code
claude
/login
/design-login

自分の検証では、globalに入れたclaudeでは/design-loginへ進めた。
macOSでは認証情報がKeychainに保存され、平文の認証ファイルを直接見る必要はなかった。

ここは大事。

Claudeまわりの認証で詰まると、設定ファイルや認証値を見たくなる。
でも、記事化や作業ログでは、機密値やアカウント固有情報を絶対に出さない。

必要なのは、認証できたかどうか。
値そのものではない。

すぐ触るなら、ブラウザでClaude Designを開く

一方で、今すぐClaude Designを試したいだけなら、CLI連携にこだわらなくてもいい。

claude.ai/designをブラウザで開けば、Designそのものは使える。
実際に自分も、ブラウザ側でClaude Designにトップページ案を作らせてみた。

ここは結構インパクトがあった。

Designは、ただHTMLを書くだけではなかった。
生成した画面を見て、表示崩れの原因になりそうな実装を自分で疑い、DOMや描画状態を確認して直そうとしていた。

もちろん、完璧ではない。

途中で接続が不安定になった。
ブラウザ操作だとスクショ取得やタブ操作も安定しないことがある。
成果物はまずClaude Designの中に残るので、実際のリポジトリへ入れるにはexportやhandoffが必要になる。

それでも、画面の方向性を見たい段階では十分使える。

自分の中では、当面こう分ける。

画面案を広げたい: Claude Design
既存コードへ入れたい: Claude Code
Desktopで完結させたい: まだ期待しすぎない
ちゃんと連携したい: standalone CLIで/design-login

使用量は、Design専用枠ではなく共有枠で見る

もうひとつ、かなり注意したいのが使用量。

Claude Designは、以前は別枠のように説明されていた。
実際、公式の「Claude Design subscription usage and pricing」には、2026年6月21日時点でも、DesignはchatやClaude Codeとは別にmeterされる、という趣旨の記述が残っている。

でも、別の公式ヘルプでは説明が変わっている。

「Get started with Claude Design」には、Claude DesignはClaudeの他の利用と同じ使用制限にカウントされ、chat、Claude Code、Coworkと共有するpoolから消費される、と書かれている。
さらに、以前は別のweekly allowanceがあったが、今はshared limitsにカウントされる、という注記もある。

実際、自分のClaude Desktopの使用量画面でも、Design専用のメーターは見えなかった。

表示されていたのは、Proのプラン使用制限。
現在のセッション。
週間制限。
すべてのモデル。
利用クレジット。

Designだけの別枠ではなく、Claude全体の使用量として見る画面だった。

Claude Proの使用量画面。週間制限がすべてのモデルで9%使用と表示されている様子

ここは、記事公開時点でも少しややこしい。

公式ドキュメント内で、共有枠と別枠の説明が並んでいる。
ただ、実画面と最新の入門docを見る限り、少なくとも自分の環境では共有枠として扱うのが安全。

Claude Designは、見た目を作るぶん、試行回数が増えやすい。
「ちょっと別案を3つ出して」だけでも、それなりに使う可能性がある。

ProでClaude Codeも普段から使っているなら、Designを気軽に回しすぎると、あとでCode側の作業に響くかもしれない。

ここは、使う前に見ておいた方がいい。

自分なら、こう使い分ける

現時点では、Claude Designを万能のUI制作ツールとしては見ない。

使うなら、画面の方向性を探る場所。

たとえば、新しいWebアプリのトップページ。
管理画面のダッシュボード。
入力フォームの見た目。
LPのファーストビュー。
スライドやワンページ資料。

こういう「まず見たい」ものには向いている。

一方で、実装に入るならClaude Code。

既存のコンポーネントに合わせる。
ルーティングに入れる。
フォーム送信をつなぐ。
テストする。
commitする。

これはCode側の仕事。

Designで見た目を決め、Codeで実装する。
この受け渡しを自然にするために/design-syncがある。

ただし、2026年6月21日時点では、Claude DesktopのCodeタブから直接いけると決めつけない。
standalone CLIを使う。
または、ブラウザのClaude Designで作って、いったんexportやhandoffで扱う。

このくらいの期待値がちょうどいい。

小さく試すなら、この順番

初めて触るなら、いきなり本番案件に入れない方がいい。

自分なら、こう試す。

claude.ai/designで小さな画面案を作る
2〜3案を出して、Claude Designの得意不得意を見る
使用量画面を確認する
exportできる形式を見る
standalone CLIで/design-loginできるか確認する
/design-syncを小さなサンプルで試す
本番リポジトリでは、Design案をそのまま入れず、人間が方針を決めてからCodeへ渡す

ポイントは、最初から全部つなげようとしないこと。

Claude Designは、まだbeta。
公式docも移行途中に見える。

見た目の探索に使う。
実装はCodeで受ける。
使用量は共有枠として見る。

この3つだけでも、だいぶ迷いにくくなる。

FAQ

Claude DesignはProでも使える？

2026年6月21日時点の公式案内では、Claude DesignはPro、Max、Team、Enterprise向けのbetaとして提供されている。
Enterpriseでは管理者側の有効化が必要な場合がある。

Claude DesktopのCodeタブから/design-syncできる？

自分の環境ではできなかった。
Claude DesktopのCodeタブでは、一部のCLI向けcommandが使えない。
DesignSyncを試すなら、standalone CLIで/login、/design-loginを通す方が現実的。

Claude Designを使うと、Claude Codeの使用量も減る？

現時点では、共有枠として見るのが安全。
Claude Designの入門docでは、chat、Claude Code、Coworkと同じshared poolから消費されると説明されている。
ただし、別の公式docには古い説明が残っているため、画面上の使用量と最新docを確認した方がいい。

Claude Designでキャラクターイラストも作れる？

そこは期待しすぎない方がいい。
Claude Designは画像生成モデルではなく、デザインやプロトタイプの作業台として見る方が自然。
キャラクターやビジュアル素材は、Firefly、Midjourney、Gemini系などの画像生成ツールで作り、Claudeには構成、方向性、プロンプト、UIへの落とし込みを任せる方が扱いやすい。

まとめ。Designは見た目、Codeは実装

Claude Designは、思っていたより面白い。

ただ、分かりづらい。

Claude CodeでもUIは作れる。
Claude Designでもコードっぽいプロトタイプは出る。
DesktopにもCodeタブがあり、ブラウザにもDesignがあり、CLIにはまた別の入口がある。

だから、最初に役割を分けておく。

Claude Designは、見た目を探索する場所。
Claude Codeは、実装して検証する場所。
/design-syncは、その間をつなぐための仕組み。

ただし、DesktopのCodeタブから直接つながるとは限らない。
2026年6月21日時点では、standalone CLIを使う方がよさそうだった。

そして、使用量は共有枠として見る。
Designで遊びすぎると、Codeやchatの作業時間にも響く可能性がある。

新しい機能ほど、触る前の期待値で迷う。

Claude Designは、いきなり全部を任せるより、小さな画面案から試す。
そこからCodeへ渡す流れを作る。

今のところ、自分はそのくらいの距離感で使うのがよさそうだと思っている。

参考・出典

続けて読む

次に読むなら、これ。

同じテーマの実践記録や、taupeの読み方へ進めます。

同じテーマAI活用近い実践記録をカテゴリから続けて読めます。サイトの読み方FAQ運用方針や、よくある質問を確認できます。taupeについてこのサイトについてどんな視点で作り、使い、運用しているかをまとめています。

イシカワヒデカズの実践記録

Web制作、開発、AI活用、メディア運営の相談先は公式サイトにまとめています。