週末しか手を動かせないSEとして、このブログのページはClaude Designで組んできた。デザインの当たりを出すのが速いから。

その Claude Design に6月、大型アップデートが入った。目玉は「Claude Codeとコードを往復できる」/design-sync。デザインをいじったらコードに反映、コードを直したらデザインに戻る——という双方向同期。これは自分の運用に効くかもしれない、と週末に実機で試した。

結論から書く。自分のブログでは”お断り”された。 ただし、これは失敗談で終わらない。非Reactの個人が同じおいしさを別ルートで取る方法まで分かったので、そこまで含めて残す。

4月版から6月版で何が変わったのか

そもそもClaude Designは2026年4月リリースの実験的ツール。1週間で100万人が触ったらしい。6月17日のアップデートで、ここが変わった（出典は公式ブログ）。

変わった点中身
コード双方向連携/design-syncでデザインシステムを同期・/designでターミナルから作成まで
インポート刷新GitHub・デザインファイル・raw画像から取り込むエンジンを再構築
オンキャンバス編集要素をドラッグ・リサイズ・整列できるレイアウト操作
出力先の拡大PDF/PPTX/HTMLに加えCanva・Vercel・Wix・Adobe等へ書き出し
利用枠の統一チャット・Code・Coworkと枠を共有・1ターンの消費も削減
管理者ロック標準デザインを承認・固定（※これは企業チーム向け）

個人的に一番うれしかったのは最後から2番目、利用枠の統一。前のClaude Designは「トークンがよく溶ける」と言われていて、自分も枠を気にしながら使っていた。そこが是正された。

そして本命が/design-syncの往復連携。これを試したかった。

自分のブログで /design-sync を叩いてみた

手順はこう。

  1. ターミナルでClaude Codeにログイン（サブスクのアカウントを選択。Claude DesignはPro/Max等に追加料金なしで含まれる）
  2. brew upgrade claude-code でアップデート（/design-syncは新しめのバージョンに同梱されていた）
  3. ブログのディレクトリで/design-syncを実行
  4. 「このAstroプロジェクトのデザインシステムを同期したい」と指定

ここまでは順調。スキルが起動して、既存の設定ファイルを探しにいった。初回インポート、と表示が出る。いける、と思った。

結果：Astroは”対象外”だった

ところが、スキルがプロジェクトを読んだ瞬間にこう返ってきた。

Scope: React design systems. （Reactでないデザインシステムには、Claude Design側が組み立てる材料が無い）

/design-syncが前提にしているのは、こういうプロジェクトだった。

求められる要件うちのブログの状態
Reactコンポーネント.astroファイルのみ（Reactではない）
dist/ のライブラリビルド無し（あるのはサイトのビルド出力）
TypeScriptのProps型定義無し
Storybook等のカタログ無し

なぜ弾かれるのか。ここはReactとAstroの性格の違いが効いている。

ざっくり言うと、Reactは「再利用できる部品（コンポーネント）を組み立てる仕組み」。ボタンやカードを部品として作り、画面のあちこちで使い回す。動きのあるアプリ寄りの作りに強い。一方Astroは「完成したページを軽い静的HTMLとして書き出す」フレームワーク。表示が速く、記事中心のブログに向く。うちのブログがAstroなのも、まさにこの軽さが理由。

/design-syncが欲しがるのは、前者の**「React製の部品カタログ」**。ビルド済みで型まで付いた部品の一覧を読み込んで、Claude Design側がプレビューを組み立てる仕組みになっている。ところがAstroは”完成したページ”をポンと書き出すだけで、“使い回せるReact部品の一覧”を差し出さない。だから同期しようにも、Claude Design側が掴むものが無い——これが「お断り」の正体。

「React＝動きのあるアプリ向け、Astro＝静的なコンテンツ向け」という理解でだいたい合っている。もう少し正確に言えば、/design-syncは”React製の部品ライブラリ”を前提にした道具で、記事中心のAstroとは、そもそも土俵が違った、ということ。

つまりこの往復連携の本当の客は、Reactでデザインシステムを回しているフロントエンドのチーム。週末に1〜2枚のページを直すような使い方は、最初から想定の外だった。ここは割り切るところ。

非Reactの個人は、同じ恩恵をどう取るか

ここで終わると損なので、代わりを調べた。結論、「往復同期」は諦めても「デザインを作って実装する」部分は今までどおり取れる。 むしろ一人で回すなら、こっちのほうが軽い。

ルート①：claude.ai/design単体で作って、HTMLで書き出す ポイントは、弾かれたのは/design-syncという”往復同期の機能”だけ、ということ。Claude DesignのWebアプリ本体は、フレームワークに依存しない。 デザインを作ってスタンドアロンHTML（CSS同梱）や.zipで書き出せるし、そのままClaude Codeへ受け渡せる（公式ヘルプに出力形式の記載あり）。

実際の流れはこう。

  1. claude.ai/designで見た目を作る
  2. HTMLで書き出す、またはClaude Codeへハンドオフ
  3. Claude Codeに「これを.astroに直して、色は既存のデザイン規則に合わせて」と頼む

これは双方向の同期ではない。デザイン→コードの一方通行。でも逆に言えば、双方向じゃなくてもこの一方通行は普通に成立する。「デザインを速く出す → コードに落とす」という、自分がClaude Designに求めていた中身は、これで足りる。/design-syncが無くても困らない。

ルート②：ブランドの色は CSS変数で一元管理する /design-syncがうたうもう一つの売り「デザインシステムでブランド色を統一」も、個人なら大げさな仕組みは要らない。:rootにCSS変数で色を定義して、全ページから参照するだけ。

:root {
  --lp-primary: #2563EB;
  --lp-success: #16A34A;
  --lp-danger:  #DC2626;
}

うちはもともとレイアウトの共通ファイルでこれをやっていて、色の出どころは設計メモ1枚に集約している。Style Dictionaryのような本格的なトークン管理ツールもあるけれど、ページが数枚の段階では過剰。CSS変数1ファイルで十分回る。

やってみて分かった3つの結論

1. お金はかからない。 サブスク（Pro/Max等）でログインする限り、Claude Designは月額の範囲内。検証で追加請求は出ない。API課金のアカウントを選ぶと従量で取られるので、ログイン時はサブスク側を選ぶ。

2. /design-syncの往復連携は、個人のAstro/HTML運用には現状刺さらない。 あれはReactでデザインシステムを回すチームの道具。週末SEの自分には対象外だった。新機能の名前に飛びつく前に、自分の足元のスタックに合うか確認するのが先。

3. 個人が取るべきは「claude.ai/designで作る → HTMLで書き出す → Claude Codeで貼る」＋「色はCSS変数で一元管理」。 これで往復連携のおいしいところは、だいたい手元に来る。

新機能は派手なほど「自分にも効く」と錯覚しやすい。今回は実機で叩いて「効かない」とハッキリ分かったのが収穫だった。道具を増やすより、手持ちの運用に合うかを試した週末。