TL;DR — Claude Design は6/17のアップデート後、Claude Codeとの統合がより深まった。これはつまり、プロンプトだけで画面を生成するツールではなくなり、
design-syncを通じてサイトの実際のデザインシステムを読み込み、以降の生成物をブランドに自動的に一致させられるようになったということだ。今回、私は paulkuo.tw のブランド tokens を Claude Design に接続した。10ファイルの同期、validate exit 0、ゼロforceでの完結。しかし本当に書き留めておきたいのは、プロセスの中で人間の判断が求められた各瞬間だ——権限を許可していいか、AIが読み込んでいるファイルは正しいか、自分の記憶はもう古くなっていないか、最後にもう一組の目で検証する必要があるか。
ツールが強力になるほど、人間の判断力はより価値を持つ。
Claude Design のアップデート後、私が最初に試したかったのは、より美しい画面を生成できるかどうかではなく、自分のサイトに本当に接続できるかどうかだった。
そこで design-sync を使って paulkuo.tw のデザインシステムを読み込ませた。フローが途中まで進んだとき、私はターミナルの権限確認ダイアログを見つめ、Enterキーの上で指を止めた。要求されているアクセス範囲が、目の前の作業より一回り大きかった。色とフォントをいくつか同期するだけのつもりが、まったく関係のないサブディレクトリへのアクセスを求めてきたのだ。
その一瞬、習慣的に Yes を押していれば、フローはおそらく前に進んでいた。しかし何を変えようとしているのか、実際にはわからないままだった。だから私は手を止め、一歩戻って何をしようとしているのかを読み返した。後で判明したのは、その一時停止が正しかったということだ。
この一時停止を手がかりに、Claude Design 今回のアップデートの背後にある、より重要な問いを分解したい。AIツールがデザインシステムをコードベースに接続し、一連のワークフローを代わりに実行するほど強力になったとき、人間が絶対に外注できないものは何か。私の答えは「管理（把関）」だ。そして管理は、コマンドを打つことよりずっと難しい。
design ↔ code が繋がった。コードベースを持つ人にとって何を意味するか
以前、AIで設計をすると、見た目は十分に美しいが、本当の問題は「誰でも使えるような美しさ」になることだった。Claude Design はもともとモックやコンポーネントを生成できたが、あなたのサイトを知らず、実際に使っている色・フォント・間隔・コンポーネントのロジックを知らないため、生成物はいつも「汎用AIデザイン感」を帯びていた——悪くはないが、あなたではない。今回のアップデートで真に興味深いのはここだ。Claude Design が Claude Code を通じてコードベースに接続し、あなたのデザインの現場を読み込めるようになった。
6/17のアップデートが私にとって重要なのは、単に機能が増えたからではなく、Claude Design と Claude Code の境界が薄くなり始めたからだ。最も重要な変化はデザインシステムのインポートが刷新されたことだ。Claude Design はブランドの説明を聞くだけでなく、GitHub repo・デザインファイル・ソースデータを読み込み、実際のデザインシステムを生成の根拠として使い、生成物を自ら照合して、不一致があれば修正する。
自分のコードベースを持つ人間にとって、これは分水嶺だ。これまで私のサイトがどんな見た目で、どんな色やフォントを使っているかと、AIが生成する設計は基本的に別世界だった。今は、一つのコマンドでその二つの世界を繋げられる。
上の画像が現在の Claude Design の様子だ。左上にはまだ Beta のラベルがあるが、必要な入口はすべて揃っている——ファイルから開始、プレゼン作成、プロダクトプロトタイプ、ワイヤーフレーム。下には積み上げてきたデザインプロジェクトが並ぶ。今回私がやりたかったのは、このリストに入るものを最初から paulkuo.tw らしく仕上げることだ。
補足として、使用量は独立して計測される。毎週独自の枠があり、チャットや Claude Code の枠とは別プールで計算されるため、デザインでの使用量がさかのぼって会話や Code の枠を食いつぶすことはない。私は Max プランを使っており、今回の同期では枠に詰まることはなかった。
今回の同期の規模は小さいが、一つのことを証明している。AIはもはやプロンプトだけで私のサイトのスタイルを推測するのではなく、実際のデザイン仕様を読み込み始めたということだ。
📊 今回の同期の数字
- 同期ファイル数：10
- 内容範囲：ブランド tokens（色・フォント・間隔）
- 検証結果：validate exit 0（エラーゼロ）
- バージョン管理の完結：commit + push 三ミラー、fast-forward、ゼロforce
- 今後のコスト：
.design-sync/設定ファイルを一度作れば、以降の re-sync は一つのコマンドで完了
まず整理する：デスクトップアプリはドア、Claude Code はエンジン、Claude Design は作業場だ
一度話を脇道に外れさせたい。「Claude Design がデスクトップアプリと統合された」という話を聞くと、それが一言で済む話だと思う人が多いが、この連携には二つの層がある。分けて理解しないと混乱する。
第一層は入口の連携だ。デスクトップの Claude アプリのサイドバーに Claude Design へのショートカットが追加され、クリック一つでワークスペースに直接アクセスできる。ブラウザを別途開く必要はない。この層は単に「入れる」ということだ。アプリが Claude Design を取り込み、直接アクセスできる場所にした。
第二層こそが本題だ——能力の連携。既存のコードベースを読み込み、設計が終わったら開発に戻すという双方向の接続を駆動するエンジンは Claude Code であり、デスクトップアプリそのものではない。デスクトップアプリには Chat・Code・Cowork の三つのモードがある。Chat はこの同期フローを駆動できない。Cowork は知的作業における第二の視点に近く、独立した検証に適している——実際、この後私がそう使う場面が出てくる。デザインシステムをコードベースに読み込ませ、開発フローに戻すことができるのは Claude Code だ。
| 役割 | 担当する内容 |
|---|---|
| デスクトップ Claude アプリ | Claude Design への入口。ワークスペースへ直接アクセスさせる |
| Claude Code | 「コードベースを読み込む ↔ 開発に戻す」を駆動する実際のエンジン |
| Claude Design | 設計を生成し、プロトタイプを作る作業場 |
一言でまとめる。デスクトップアプリはドア、Claude Code はエンジン、Claude Design は作業場だ。したがってこれから出てくる同期は、すべて Code がバックエンドで行っている。Chat でも Cowork でもない。
フロー全体像：五つのフェーズと二つの重要な判断
今回歩んだ道筋を一枚の図にまとめた。大事なのはステップの美しさではなく、各ステップの背後に判断が潜んでいることだ。
フロー全体はこうだ。新しい Claude Code セッションを開き、/update で最新のコマンドを取得し、repo のルートディレクトリで /design-sync を起動し、権限を一つずつ判断し、独立した視点で検証し、最後にきれいに完結させる。ルーティン作業のように聞こえるが、本当に脳力を使うのは二つの判断だ。第一に、どこまで同期するか。第二に、どの権限を許可するか。
なぜ tokens だけ同期したのか？ツールがまだ Astro コンポーネントを消化できないからだ
design-sync を起動すると、何を同期するかを問われる。私は tokens-only を選んだ。つまりブランドの基層仕様だけを移し、完全なコンポーネントは移さない。シンプルに言えば、まず AIに私の色・フォント・間隔を認識させ、Astro コンポーネント全体を理解させることを急がないということだ。
これは保守的な判断ではなく、ツールの境界を見極めた判断だ。Claude Design のデザインシステムインポートは コードベースとデザインファイル を読み込むところから出発しているが、paulkuo.tw のような Astro プロジェクトで実際に試すと、.astro コンポーネントは現時点ではまだ読み込めない。無理やりコンポーネントを同期させようとすれば、半分正しく半分間違った結果が出るだけだ。それならば、最もクリーンでエラーの出にくい層——色・フォント・間隔——だけを移す方がいい。これらはブランドの基色だ。移行後、AIが設計をするとき、少なくとも配色とフォントは正しくなる。
第二の判断は目的地だ。tokens をどこに同期するか。デフォルトでは既存の design system 母体に流し込もうとするが、私は「新しいプロジェクトを作成」を選んだ。理由はシンプルだ。今回の paulkuo.tw 専用の tokens を、今後再利用する可能性のある共通デザインシステムに混入させたくなかったからだ。一つの操作が今後も使い続けるものを汚染しないか——そういう判断はツールがしてくれない。自分で考えるしかない。
AIが Yes を押させようとするとき、まず何を変えようとしているのかを問え
冒頭の権限ダイアログに戻ろう。AIエージェントと協働していると、権限の確認は繰り返し現れる。多くの人はやがて感覚が麻痺し、ダイアログを見るたびに反射的に Yes を押すようになる。これが最も危険な習慣だ。私の方法は、各確認を小さなテストとして扱い、二つのことを問い直すことだ——何を変えようとしているか、許可する範囲はどれくらいか。
シェルコマンドには基本的な文法がある。プログラムが書けなくてもいい。最低限区別できることがある——「データを読む」だけか、「ファイルを変える」準備をしているか。grep や sed は通常、読み取りやテキスト処理に寄っているが、> というリダイレクト記号が見えたら、結果をどこかのファイルに書き込もうとしているかもしれないと知っておくだけでいい。「見る」と「変える」を区別できれば、多くの不要なリスクを避けられる。ツール自身のサンドボックス内の操作は概ね安心して許可できるが、実際のソースコードディレクトリに触れようとする、あるいは「今後は確認しない」という選択肢が現れたら、神経を引き戻すべき時だ。
私を立ち止まらせたあのダイアログが最良の例だ。何度も現れ、worker サブディレクトリへの権限を要求してきたが、そのディレクトリはトークン同期とは何の関係もなかった。後でわかったのは、そのとき作業ディレクトリがたまたまそのサブディレクトリの下にあったため、そのパスがデフォルトの範囲として提示されたのだということだ。許可の範囲が目の前の操作と噛み合わないとき——それがブレーキを踏むべきサインだ。 AIの悪意ではなく、AIのデフォルトロジックが必ずしもあなたの意図に沿っているとは限らないということだ。そのときは人間が修正しなければならない。
記憶を信じるな、現場で読んだファイルを信じろ
途中で小さな出来事があり、私はそれが気に入っている。design-sync が私のブランド tokens の実際の定義場所を探しに行くとき、私はソースコードがすべて src/ にあるのだから当然そこにあると確信していた。ところが、ツールが自分で照合を行い、本当の源泉を public/styles/ に見つけた。私の記憶が間違っていたのだ。
これは逆に面白いことだ。AIに対するステレオタイプな印象——でたらめを作り上げる、あなたに同調する——とは正反対に、少なくともこの一回は、私の確信に満ちた口ぶりに引きずられることなく、ファイルそのものに立ち返って照合した。
しかしこれは同時に別のことを教えてくれる。AIが照合するからといって、常に正しいわけではない。AIも人間も、頭の中に「記憶の中の古いバージョン」を持っている。重要な事柄は現場でファイルを読んで確かめるべきであり、どちらかの記憶に頼ってはならない。今回、私は自分の記憶に一度騙された。幸い、フローに照合というステップがあった。
記憶が人を欺く例はもう一つある。同期が終わり収束に向かうとき、私は git push がオンラインの自動ビルドをトリガーすると思い込んでいた——多くの CI/CD がそうであるように。しかし現場で repo の CLAUDE.md を読んで初めて、その自動ビルド機能はとっくに無効化されており、デプロイは別のルートを通っていることがわかった。またしても、現場のファイルが頭の中の古いバージョンを上書きした。こうして訂正される瞬間に抵抗してはならない。喜んで受け入れるべきだ。「現場を基準にする」という原則が、一つのミスを防いでくれたのだから。
AIに自分で自分を検証させるな：独立した第二の目を持ち込め
同期完了後、validate は exit 0 を返し、10ファイルもすべて揃っていた。成功したように見えた。しかし「ツールが成功と言っている」と「本当に正しい」は別の話だ。
私は同期を実行した Claude Code 自身に検証させるのではなく、別途 Cowork を開いた。前のフローに一切関与していない第二の目として、元の tokens の源泉と同期後の生成物を項目ごとに照合した——色の値に誤りはないか、漏れはないか。問題ないと確認してから、commit し、三つのミラーに push した。整合、fast-forward、ゼロforce。
この操作こそ、今回の全行程で最も記憶に値する規律だ。実行者が自分で自分を検証するのは、検証していないに等しい。プログラム・設計・文章を問わず、外に出すものは送り出す前に、制作に参加していない役割の者がもう一度見直すべきだ。
これが私が長年マルチモデル認知協作を主張してきた理由でもある。重点は複数のウィンドウを開いて賑やかしにすることではなく、異なる役割が互いに疑い合い、互いに校正し合うことにある。人間はその中央に立ち、基準の定義・リスクの判断・最終結果の確認を担う。
途中、小さなハプニングもあった。画面が突然固まり、接続が切れたかと思った。しかし後でわかったのは、誤って Ctrl+Z を押してツールをバックグラウンドに一時停止させてしまっただけで、fg と打てばフロー全体が戻ってきた。これもまた思い知らされる——多くのパニックは、底で何が起きているかを知らないことから来る。
ツールが強力になるほど、判断力は価値を持つ
今回の全行程を一言に凝縮するなら、こうなる。AIを使って仕事をするとき、本当の技量はコマンドを打てるかどうかではなく、何を変えようとしているかを見抜けるか、現場でその場で確かめる意志があるか、誰かに管理を任せる知恵があるか、にある。
design-sync は確かに強力だ。一つのコマンドで私のサイトのブランドを AIに接続し、以降の設計は自動的にブランドに沿うようになる。しかしこれを「完了した」だけでなく「正しくできた」ものにしたのは、最初から最後まで、コマンドには書かれていない判断の数々だった。これは私がずっと語り続けているセンスと判断力と同じことだ——実行コストがほぼゼロに近づいたとき、残る差異はすべて意思決定の質にある。
Claude Design の今回のアップデートは、始まりに過ぎない。これからは、内容を生成するだけでなく、作業の現場に直接接続し、ファイルを読み、フローを変えるAIツールがさらに増えてくる。ワンクリックで完了できることは増え続ける。だからこそ、押す前に半秒立ち止まり、一歩退いて読み返す意志を持つ人間が、ますます重要になる。
次に確認ダイアログが現れたとき、急いで Yes を押さないでほしい。まず一つ問え——あなたは一体、何を変えようとしているのか、と。
💬 コメント
読み込み中...