SE歴20年・Claude Max 5x契約の筆者が、リリース翌日に2件のプロトタイプを実測しました。BtoB比較サイトのLP改善案と、モバイルWebアプリのマッチング画面です。URL参照の挙動・Tweaks機能・Export形式・クォータ消費量まで一次体験で記録したレポートをまとめます。

ムラサキ

最初は画像生成AIかと思ったら違いました。Claude Designの正体と、触ってわかった向き・不向きを一次情報で整理します。

Claude Designは画像生成AIではない

「Design」という名前から画像生成ツールを想像しがちですが、Claude Designが作るのはプロトタイプ・スライド・LPなどのHTMLベースの成果物です。Anthropicの公式Xアナウンスでも「prototypes, slides, and one-pagers」と位置づけられており、Figma・Canvaに近い立ち位置になります。

2026年4月17日リリースの研究プレビュー

Claude DesignはAnthropic Labs（同社の実験的プロダクト部門）から公開された研究プレビュー機能です。Pro・Max・Team・Enterpriseの有料プランで段階的に利用可能となり、Web版のclaude.ai/designからアクセスできます。

前日の4月16日にはClaude Opus 4.7が一般公開されており、Claude DesignはこのOpus 4.7の視覚理解能力を前提に設計されています。Opus 4.7は最大解像度が従来の1568pxから2576pxへ大幅に拡張され、デザイン用途のスクリーンショット解析が現実的になったモデルです。Opus 4.7自体の位置づけとコスト感はOpus 4.7と副業開発への影響を整理した記事で詳しく扱っています。

作れるもの・作れないもの

Claude Designで作れるのはWebページ・アプリのプロトタイプ、スライドデッキ、ワンページャー、マーケティング資料などです。いずれもHTMLベースで生成され、ExportメニューからZIP・PDF・PPTX・standalone HTMLで書き出せます。

一方で作れないものもはっきりしています。MidjourneyやStable Diffusionのような写真風画像生成、動画・アニメーションの生成、実データと連携した動的ダッシュボードなどは範囲外です。

モデル選択はOpus 4.7がデフォルト、切替も可能

Claude Designの入力欄左下の歯車アイコン（Change model）からモデルを切り替えられます。選択肢はClaude Haiku 4.5・Opus 4.7（デフォルト）・Sonnet 4.6・Opus 3・Opus 4.6・Sonnet 4.5の6種類。筆者の3件の検証はすべてデフォルトのOpus 4.7で実施しました。軽めの編集指示ならHaiku 4.5やSonnet 4.6に落とすことでクォータ節約が可能な設計になっています。

検証1｜BtoB比較サイトのLP改善

1件目は「SaaSツールを比較する情報サイトのLP」を題材にしました。現状サイトのURLを参考情報として渡し、コンバージョン重視のリデザイン案を依頼する形です。

投げたプロンプトと事前準備

Claude Designの新規プロジェクト作成は、Prototype（プロトタイプ）／Slide deck（スライド）／From template（テンプレート）／Otherの4タブから選びます。Prototypeの下にはWireframe（ラフ）とHigh fidelity（高精度モックアップ）の2モードがあり、今回はHigh fidelityを選択しました。

Createボタンを押すと、左ペインにチャット入力欄、右ペインにキャンバスが表示される作業画面に遷移します。コンテキスト追加ボタンとしてDesign System／Add screenshot／Attach codebase／Drag in a Figma fileの4種が用意されており、ブランド資産やコードベースを事前に紐付けられる設計です。

今回は事前アセットは渡さず、プロンプト本文内にURLだけを含めて投げました。実際に使ったプロンプトの骨格は次の通りです。サイト情報・現状課題・ターゲット・依頼内容・バリエーション数を明示しています。

https://example.com を参考にして、このLPを改善してほしい。

【サイトの目的】
SaaSツールを探している人向けの比較・レビューサイト

【現状の課題】
- ファーストビューで何のサイトか伝わりにくい
- CTA（資料請求・比較ボタン）の導線が弱い

【ターゲット】
情報収集段階の中小企業のIT担当・個人事業主

【依頼】
- コンバージョンを意識したLPトップページのデザイン案
- クリーンで信頼感のあるテック系（BtoB寄り）
- バリエーションは2案まで（トークン節約のため）

Fetching挙動｜URLを渡すと実際にサイトを読みに行く

プロンプト送信後、Claude Designは逆質問をせず即座に生成フェーズに入りました。左ペインには「依頼内容がかなり具体的（方向性・必須要素・バリエーション数まで指定済み）なので、前提をまとめて即着手します」という宣言が表示され、続いてデザイン方針（アプローチ・タイポグラフィ・カラー・構造）を明示したうえでProgress 0/4のタスクリストを展開します。

進行中のアクション表示には「Fetching page ×2, Copying starter」の文言が出ました。URLを渡すとClaude Designがweb capture toolでサイトを実際に取得しに行くことが、この表示で確認できます。ただし丸ごとコピーはせず、「著作権に配慮し、コピーではなく『BtoB向けSaaS比較サイト』として一般的なパターンで新規設計します」と宣言したうえで、参考サイトの雰囲気だけを汲む挙動でした。

数分で完成したLPファーストビュー

プロンプト送信から完成まで数分。筆者が別で実測した軽量LP案件では約6分で完走しました。右ペインにindex.htmlとして1ファイルのLPが出力され、ファーストビューのコピーは「『使うべきSaaS』が、30秒で見つかる。」。ターゲット文言（中小企業のIT担当・個人事業主）はプロンプトから引用され、CTA2種（無料で比較をはじめる／比較シートをダウンロード）・信頼数値（320+ 掲載SaaS／18 カテゴリ／月間 42k 意思決定者）・比較表サンプル・カテゴリ導線・代表ツールの横スクロールまで、依頼した必須要素がすべて1ページに収まっています。

注意点として、比較表に記載されたツール名（Notion・Confluence・Coda等）は実在するサービスですが、料金・スコア数値はダミーです。Claude Designは実データ連携を持たないため、具体的な数値を使う最終版には必ず自力で差し替えが必要になります。

Tweaks機能｜配色とコピー文言まで変わる

右上の「Tweaks」トグルをONにすると、生成された2バリエーション（案A / Navy・案B / Ink）を即時切替できます。面白いのは配色だけでなくコピー文言まで変わる点で、案Aの「『使うべきSaaS』が、30秒で見つかる。」に対して案Bは「SaaS選びの、最短ルート。」と別のメッセージが自動生成されていました。

単なるテーマ切替ではなく、各案が独立した別デザインとして成立するように設計されている点が特徴です。プロンプトで「王道BtoB」「モダン・差別化志向」という2方向を事前に指示できれば、2案を並べて社内議論のたたき台にする使い方が現実的になります。

検証2｜モバイルWebアプリのマッチング画面

2件目はポケモンGOの個体交換マッチングサービスを想定し、マッチング結果一覧画面（/matches）を言語説明だけで起こしました。URL参照ではなく、複雑な業務仕様をテキストで指示したときにどこまで再現できるかの検証です。

言語だけでの指示プロンプト

プロンプトには、サービス概要（何を何とマッチングさせるか）、画面構成（上部タブフィルター・セクション見出し）、マッチカードの2カラム構造、バッジ・状態表現のルール、アクションボタンの表示条件、モバイルファースト（375px想定）などを詳細に記述しました。ドメイン固有の用語（双方向マッチ／片方向マッチ／フレンドレベル不足／ほしのすな消費量）がどこまで伝わるかもチェックポイントです。

375px固定のiOSフレーム付きUIで完成

送信から完成までは数分。Progressタスクは0/7まで分解され（iOSフレーム取り込み・マッチデータ設計・カード実装・タブフィルター実装・リクエストモーダル実装・状態遷移管理・仕上げ検証）、生成ファイルはapp.jsx・modal.jsx・card.jsx・components.jsx・data.jsx・ios-frame.jsxの6つのReactコンポーネントに分割されていました。

完成画面はiPhoneフレームに9:41の時刻表示とノッチが再現され、内部のUIは375px固定幅で収まっています。タブフィルター（すべて8／アクション可能2／交渉中2）の件数バッジ、双方向マッチセクション（4件）の緑バッジ、マッチカード2枚の左右2カラム表示（自分のリスティング／相手のリスティング）、トレーナー名＋取引実績バッジ、ほしのすな消費量、スケジュール重複時間、黄色の「リクエストする」CTAボタン、下部タブバーのチャットアイコンに付く通知バッジまで、指示した仕様がほぼそのまま反映されています。

著作権配慮のガードレール｜固有名詞は許容、公式UIは回避

興味深かったのは、ポケモン名（ラルトス・ヨーギラス・ヒトカゲ・ゼニガメ）と図鑑番号はサンプルデータとして採用しつつ、「ポケモンGO自体の画面やロゴは使わず、オリジナルの『個体交換マッチングサービス』としてデザインします」と宣言したうえで公式UIの模倣を回避した点です。実際、マッチカード内のポケモン画像はオリジナルのモンスターボール風プレースホルダ（タイプ色で塗り分け）に置き換えられていました。

固有キャラ名の例示は許容、公式UIやロゴの模倣は回避というガードレールの粒度が、検証1（BtoBサイトの丸コピー回避）と合わせて見えてきます。商用利用前の最終確認は必要ですが、著作権リスクへの一定の配慮が組み込まれている設計です。

日本語フォント選定の文化的配慮

フォント選定は検証1と検証2で明確に違いました。BtoB LP（検証1）ではPlus Jakarta Sans＋IBM Plex Monoという英文ベース、モバイル・カジュアル・日本ユーザー想定の検証2ではZen Maru Gothic＋M PLUS Rounded 1cという丸ゴシック系日本語フォントが選ばれています。プロンプトに「日本語フォント」とは書いていないにもかかわらず、文脈から自動で使い分ける挙動です。

追加検証で見えた、アフィリLPとTweaksの多軸性

上記2件とは別に、アフィリエイト記事向けのVPN比較LPを3件目として検証しました。この検証はトピックが重複するので本記事には含めませんが、2点の新発見があったので補足します。1件あたりのClaude Design枠消費は+15%、生成時間は実測で約6分でした。

景表法・PR表記を自発的に挿入

アフィリエイト目的のLP生成では、プロンプトで明示していないにもかかわらず「PR・景表法表示：本ランキングはアフィリエイト広告を含みます。評価は編集部の独自基準によるもので、広告料によって順位は変動しません」というステマ規制対応の注記がファーストビュー直下に自動挿入されていました。依頼内容から「アフィリエイト収益化視点」というキーワードを汲み、景表法・ステマ規制への配慮を自発的に入れる挙動です。

Tweaksはコンテンツに応じて多軸化する

検証1のTweaksは「案A/案B」の2バリエーション切替でしたが、VPNランキングLPでは「デザイン方向（A・ネイビー/B・ダークグリーン）」「見出し言語（日本語/日+英併記）」「ランキング密度（詳細(Pros/Cons)/コンパクト）」の3軸同時カスタマイズに変化していました。固定のUIパターンではなく、生成物の性質に応じてカスタマイズ軸が動的に組み立てられている挙動です。ランキングLPなら密度軸、2方向のデザイン比較なら方向軸、といった最適化が入っていると見られます。

できること・できないことの整理

3件の検証から見えた範囲を整理します。2026年4月時点の研究プレビュー版での筆者検証範囲内での結果です。

できること

できないこと・注意点

エンジニアの現実的な使い道3パターン

副業SEや週末起業家の視点で、実務に組み込める使い方を3つ整理しました。

クォータ設計の実測ガイド

研究プレビュー期間中のClaude Designで最も重要なのがクォータ設計です。Claude Designには通常のClaude利用枠とは別のトークン枠が設定されており、消費ペースが想像以上に速いことが報告されています。

Claude Design枠は通常枠と別カウント

Claudeの設定画面の使用量タブを開くと、「すべてのモデル」「Sonnetのみ」に加えて「Claude Design」の独立した枠が確認できます。リセット時刻も通常のモデル枠（筆者環境では金曜7:00）と異なり、Claude Designは土曜21:00と別設定。Designをヘビーに使っても通常のチャット枠は残る、逆にチャット枠を使い切ってもDesignは動く、という住み分けです。

Max 5x実測：検証1本あたり約9〜15%消費

Claude Max 5xプランでの実測値を3件並べると、検証1（LP 2バリエーション＋URL fetch）で13%消費、検証2（モバイル画面1案）で9%消費、追加検証のVPNランキングLP（3軸Tweaks付き）で15%消費でした。合計37%で3本のプロトタイプを完走しています。単純換算で、Max 5xなら週次で6〜10本程度の本格プロトタイプが作れる計算になります。

一方Proプランの実測については、PCWorldのBen Patterson氏の検証記録が参考になります。同氏は3バリエーションのプロトタイプ生成を25分で完走したものの、その時点でProの週次Claude Design枠の80%を消費。誤操作のundoで全作業が消えた後5分間の再生成で残り枠もゼロになったとレポートしています。本格的にプロトタイプを作り続けるならMax以上、たまに1本試すだけならPro、という目安になりそうです。

トークンを節約するプロンプト設計

消費を抑える最大のコツは、最初のプロンプトで情報を出し切ることです。Claude Designは具体的な指示が足りないと逆質問を繰り返すので、その往復だけでトークンが消えます。筆者の検証では事前に方向性・必須要素・バリエーション数を明記したため、Claude側から「依頼内容がかなり具体的なので即着手します」と宣言されて逆質問ラッシュをスキップできました。

よくある質問

まとめ

3件の検証でわかったことを3点に整理します。

• Claude Designは「数分で初稿が出る」プロトタイピングツールで、画像生成AIでもFigma代替でもない独自の立ち位置にある
• URL参照・多軸Tweaks・景表法表記の自発的挿入・日本語フォント自動選定・著作権ガードレールなど、実用レベルの機能が研究プレビュー時点で揃っている
• PNG直接出力なし・実データ連携なし・Pro枠はタイトなど制約もあり、完成品ツールではなく「議論と実装のたたき台生成器」として捉えるのが現実的

副業エンジニアの視点では、LP草案・UIプロトタイプ・スライド初稿といった「議論を前に進めるための素材」を数分で揃えられる価値が大きいツールです。最終成果物ツールではなく、思考を可視化する道具として使うと効きます。記事制作ワークフロー全体にAIをどう組み込むかはClaude記事制作ワークフローの全記録にまとめています。

外部情報としては、Anthropic公式のClaude Design発表記事、Opus 4.7の詳細を扱ったAnthropic APIドキュメント、Proプランでのクォータ消費実測を含むPCWorldの検証レポートが参考になります。

ムラサキ

Handoff to Claude Codeで実装まで通すフローはClaude Design→Code｜handoffで既存プロジェクトに統合にまとめました。既存Reactプロジェクトへの統合記録です。

SE歴20年・Claude Max 5x契約の筆者が、Handoff to Claude Codeを使って既存リポジトリに統合した一次体験です。結論から言うと、Design→Codeの受け渡しはURL経由のfetch方式で、Design枠は消費せずCode枠+3%のみ、実装完了まで約1時間、437テスト全パス・Viteビルド成功までたどり着きました。

ムラサキ

Design単体の検証は昨日済ませたので、今回は「本番寄りの既存プロジェクトに統合する」実運用フェーズの記録です。

Handoff to Claude Codeの正体

Claude DesignのExportメニューにある「Handoff to Claude Code」は、Design側で生成したUIモックをClaude Codeに引き渡すための公式機能です。どういう仕組みで動いているのかを実測しました。

「Send to local coding agent」ダイアログの中身

Designプロジェクト画面の右上「Export」→「Handoff to Claude Code…」を選ぶと、「Send to local coding agent」というダイアログが開きます。ダイアログの中身は次の3要素です。

• Claude Code用の指示コマンド（コード風の枠に表示される）
• Copy commandボタン（指示文をクリップボードにコピー）
• Give the agent more detailの自由記述欄（追加指示を書ける）

オプションとして「Download zip instead」のチェックボックスもありました。URLが何らかの理由で使えない場合に、ローカルzipダウンロードに切り替えてClaude Codeのチャットに手動で投入する代替手段です。

APIエンドポイント経由のURLフェッチ方式

表示される指示コマンドは次のような形です。

Fetch this design file, read its readme, and implement the relevant
aspects of the design.
https://api.anthropic.com/v1/design/h/<project-id>?open_file=Matches+Screen.html
Implement: Matches Screen.html

Anthropic側のAPIエンドポイントにDesignの成果物がホストされ、Claude Code側がそのURLをfetchして読み込む設計です。Claude Codeのログを見ると、実際にはfetch後にgzip圧縮ファイルが保存され、それを解凍して読み込む流れになっていました。

この方式の利点は、Design側がCode側のファイルシステムを直接操作しないこと。受け渡しは読み取り専用の配信で、ローカルに何を書くかはすべてClaude Code側の判断に委ねられます。

追加指示欄で統合方針を伝えられる

デフォルトの指示コマンドだけでは「このデザインを実装して」という漠然とした依頼にしかなりません。今回は自由記述欄に以下の統合方針を入力しました。

• 対象プロジェクト（既存のReact + Vite + Tailwind）と置換対象ファイルの明示
• 作業ブランチ名
• 既存自前コンポーネントを優先使用する方針
• モックデータは破棄して既存のAPI関数に接続する方針
• 作業フロー（CLAUDE.md/BUGS.mdを読む→既存機能を把握→計画提示→承認後に実装）

この欄に既存資産の情報を詰め込むと、後述の通りClaude Codeが計画段階で既存コードと整合性を取るための下調べをしてくれます。

ターミナルで受け取る（CLI経由の実行）

Handoffの受け取り方はいくつか選べますが、今回はClaude Code CLI経由で実行しました。

Copy commandで取得してClaude Codeに貼り付ける

流れはシンプルです。

1. ダイアログのCopy commandボタンをクリック
2. ターミナルでプロジェクトディレクトリに移動
3. claude でClaude Code CLIを起動
4. クリップボードの指示コマンドを貼り付けてEnter

これだけで、Claude CodeがURLをfetchして実装準備に入ります。Mac版Claude Code、VSCode拡張、JetBrainsプラグインなど他のインターフェースでも同じコマンドを貼り付ければ動くはずです。

Design枠は消費しない（Code枠のみ課金）

今回の作業前後でClaude Designの週次枠を実測した結果、Handoff後もDesign枠の消費はゼロでした。Claude Codeが fetch する先は静的配信のURLなので、Design側の生成処理は走っていないと理解できます。

代わりにClaude Code側の5時間セッション枠が25%から28%へ3ポイント増加。Max 5xプラン実測で、1本の本格的な統合作業がCode枠の+3%で済む計算になります。Claude CodeのOpus 4.7・Sonnet 4.6・Haiku 4.5のコスト感を踏まえると、個人開発レベルなら十分現実的な消費ペースです。

Claude Codeが自発的にやったこと

指示を投げたあとのClaude Codeの挙動が想像以上に賢く、Handoffの価値の大半はここにあると感じました。

Design成果物fetchと既存コード探索を並行実行

実行開始直後、Claude Codeは「デザインファイル取得と既存コードの探索を並行実施」と宣言し、実際に両方を同時に走らせました。

• 「デザインファイルを取得する」→「gzip圧縮ファイルが保存された。解凍して読む」→「デザインファイル完全に取得できた」
• その間に既存プロジェクトのCLAUDE.md・BUGS.md・既存ページ・関連コンポーネントを探索

統合型の実装では、新規資産（Design出力）と既存資産（プロジェクトのコード）の両方を把握しないと計画が立てられません。Claude Codeはこの並行実行を自動で判断していました。

テーマ衝突を検出して逆質問

取得完了後、Claude Codeは「設計に入る前に重要な決定を確認」として、AskUserQuestionツールで逆質問を投げてきました。

デザインはウォームクリーム（#FAF7EF）の明るいテーマですが、既存プロジェクトはネイビー（#0a1628）のダークテーマです。対象ページをどちらに合わせますか？

選択肢として「デザイン通り（明るいクリーム）」「ダークテーマに合わせる」「他の内容を入力」の3択が提示されます。さらに各選択肢には、右カラムに「背景: #FAF7EF（ウォームクリーム）カード: #FFFFFF + 薄影 テキスト: #2B2B2B アクセント: #E5A621（ゴールド）→ デザイン通りの見た目になる → 他ページはダークテーマのまま」という帰結説明が付いていました。

指示されていない判断ポイントを自発的に発見して、帰結まで提示して確認を取る挙動です。Design→Code統合の実運用では、この「既存環境との衝突検出」が一番重要なステップだと実感しました。

計画書に既存技術的癖の回避策まで含めてきた

テーマ判断（今回は「デザイン通り」を選択）のあと、Claude Codeは詳細な計画書を提示してきました。

計画書の構成は次の通りです。

• Context（作業の前提）
• 対象ファイル（4ファイルを明示）
• カラーパレット（Design出力から抽出した7色）
• 重要テクニック
• メインコンポーネントの新構造（ASCIIアートで描画）
• ページ側の変更点
• 実装手順
• 再利用する既存資産
• 検証方法

特に「重要テクニック」の項目が秀逸で、次のように書かれていました。

Tailwindのbg-white等はindex.cssの!importantでダーク上書きされる

インラインスタイル（style={{ background: '#FAF7EF' }}）を使えば!importantの影響を受けない

既存ロジック（API関数・カスタムフック・フィルター関数）はすべて維持

プロジェクトの既存CSSが持つ「!importantでTailwindを上書きする」という技術的癖を読み取り、それを回避する具体的な戦略まで計画段階で組み込んでいます。追加指示に含めていなかった内容を、既存コードを読んで自律的に発見した挙動です。

実装結果の実測

計画を承認してから実装完了までは、逆質問の往復を含めて約1時間弱でした。

変更ファイル4つ・437テスト全パス・ビルド成功

最終的な変更内容は次の通りです。

• メインコンポーネント：デザイン通りに全面再設計（トレーナー情報帯・2カラム中央揃え本体・フッター帯・ゴールドグラデーションのリクエストボタン）
• ページ側：ページ背景#FAF7EFをインラインスタイルで設定してダークテーマ上書きを回避、countバッジ付きタブフィルター、アイコンボックス付きセクションヘッダー
• index.html：Zen Maru Gothic / M PLUS Rounded 1cフォントを追加
• テストファイル：クラス名ベースassertionを削除・更新

• npm run test:runの結果：437 passed / 0 failed
• Viteプロダクションビルド：成功
• コミットまで自動で完了

Tailwindクラス名に依存した既存テストをClaude Codeが自律的に書き換えた点が重要です。デザイン変更でTailwindクラスが変わるとテストが壊れやすい問題を先回りして対処しています。

クォータ消費はCode枠+3%のみ

Design→Codeの受け渡しは静的ファイルのfetchなので、Design側の生成処理は走りません。Code側の実装作業だけが課金対象になる構造です。大規模なリファクタや新機能開発ではなく既存画面の置き換えだったため、Code枠の消費も軽く済みました。

見た目の再現度と既存機能の両立

実装後の対象画面と、他ページの画面を並べると、テーマの封じ込めが機能していることが確認できます。

対象ページ側はDesign出力通りのクリーム色背景とカード、ゴールド系アクセント、丸ゴシック系フォント。既存ロジック（方向フィルター、表示用バッジ、情報帯など）も維持されています。Design出力には無かった既存機能も、既存コードから読み取って再実装してくれた形です。

一方の他ページ側は元のダークネイビーテーマをそのまま維持。インラインスタイルでダークテーマ上書きを封じ込めた戦略が、他ページに一切漏れていません。追加指示に「他ページには影響させるな」と書いていなかったにもかかわらず、Claude Codeが計画段階でこの分離を設計していたことになります。

Design→Codeフローで見えた注意点

3件のDesign検証に続けて今回の統合作業を実行して、実運用で押さえておきたいポイントが見えてきました。

テーマ衝突は必ず起きる想定で計画する

Design側は配色・フォント・余白を独立に設計するため、既存プロジェクトと100%一致するケースはほぼありません。AskUserQuestionで逆質問が来るパターンを想定し、判断材料（既存テーマの色コード・フォント・CSS設計思想）を事前に整理しておくとスムーズです。今回は「index.cssで!important上書き」という癖が事前に整理されていたからこそ、Claude Codeが回避策を提示できた側面もあります。

既存自前コンポーネントの扱いは追加指示で明示する

追加指示欄で「既存自前コンポーネントを再利用する」「Design出力に同等コンポーネントが含まれていても既存版を優先」と明示したことで、Claude Codeは計画段階で再利用リストを作り、Design出力の一部をそのまま活かしつつ既存コンポーネントを維持する判断をしました。明示がなければDesign出力をそっくりそのまま置き換える形になっていた可能性があります。

言語・型設定は追加指示で回避する

Design出力はJavaScriptで来ましたが、プロジェクトによってはTypeScript化を自動で試みる挙動もありうるため、追加指示欄に「JavaScript (.jsx)を維持。TypeScript化しない。」と明記しておくのが安全です。今回はこの一文があったため、Claude Codeは一切TS化を試みず既存のJS構成を尊重しました。

mainブランチには直接適用しない（必ずフィーチャーブランチ）

Handoffの挙動は予測不能な部分があり、最初の1手で既存のmainが壊れるリスクがあります。今回はフィーチャーブランチで作業し、mainへのマージは後日の追加検証フェーズに持ち越しました。Claude Codeを使った個人開発の運用ノウハウはClaude Codeで個人サービスを作った正直な話にまとめてあります。

よくある質問

まとめ

3点に集約します。

• Handoff to Claude CodeはAPI経由のURLフェッチ方式で、DesignとCodeのファイルシステムを直接繋がない安全な設計
• Design枠は消費せず、Code枠のみ+3%で本格的な既存プロジェクト統合が完了した実測値
• テーマ衝突・既存コード癖・テスト更新などの「実運用で必要な判断」を、Claude Codeが計画段階で自発的に拾ってくれる

Design単体の検証は前回の記事で完結しましたが、本当の価値はDesign→Code handoffによる「初稿生成→実装まで一本化される体験」にあると実感しました。次はClaude Code v2.1.114時代の他の新機能も/powerup入門あたりと繋げて試していく予定です。

外部情報としては、Anthropic公式のClaude Design発表記事{target=”_blank” rel=”noopener noreferrer”}、Opus 4.7の仕様を整理したAnthropic APIドキュメント{target=”_blank” rel=”noopener noreferrer”}、Claude Code公式ドキュメント{target=”_blank” rel=”noopener noreferrer”}が参考になります。

ムラサキ

main/masterへのマージは追加検証フェーズに回します。Claude Codeで自作サービスをどこまで自動化できるかは、別記事でまた検証予定です。