個人開発でいちばん腰が重いのは、ゼロから画面を起こす最初の一歩かもしれません。やりたいことはあるのに、配色やレイアウトを決めて、コンポーネントを並べて、と考えるだけで先延ばしにしてしまう。私自身、Dolice Labs という4つのブログを運営しながら、その手前で何度も足踏みしてきました。
最近この詰まりが軽くなったきっかけが、Claude Design と Claude Code を行き来する作り方です。デザインの発散を Claude Design に任せ、実装の収束を Claude Code で詰める。役割をはっきり分けると、最初の一歩が驚くほど軽くなりました。ここでは、その往復の流れを一望できる形でまとめます。
まず「発散」と「収束」を別の道具に割り当てる
この作り方の肝は、性質の違う2つの作業を別々の道具に預けることです。デザインの方向を広げる発散と、実装を一つに固める収束は、求められる頭の使い方がまるで違います。
- Claude Design（発散） — 配色・レイアウト・コンポーネントの方向を、動くプロトタイプとして複数案で出す
- Claude Code（収束） — プロトタイプを実データで動く本番へ。内部実装の整理、データ設計、CI、実機での微調整
発散の段階で実装の細部を気にすると手が止まり、収束の段階でデザインを迷い続けると終わりません。道具を分けるだけで、その混線が自然に解けます。私の体感では、この分担がいちばん効きました。
Claude Design は「作る前に質問してくる」
Claude Design に面白いのは、いきなり作り始めず、先に選択式の質問を返してくることです。誰に見せるのか、どれくらいインタラクティブにするか、案を何個並べるか。ポチポチ答えるだけのフォーム形式で、前提が一気にそろいます。
これは仕様書を書くより速く、しかも自分でも言語化できていなかった要件がその場で固まる、という体験でした。「とりあえず作って」だと相手が前提を勝手に埋めてしまいますが、先に問い返してくれると、認識がそろった状態でプロトタイプに入れます。最初の質問に丁寧に答えることが、後半のやり直しを減らす近道です。
複数案を並べて、触りながら決める
Claude Design は方向を1つに絞らず、複数案を動くプロトタイプとして並べてくれます。実物を見比べられるので、「これは情報密度が高すぎる」「これは余白が気持ちいいがスクロールが長い」といった判断が、文字の仕様書を読むよりずっと速くなります。
さらに、デザインの初稿で終わりではなく、触りながら何度も直せるのがプロトタイプの強みです。ある要素をクリックしたら表示を切り替えたい、といったインタラクションまで、この段階で詰められます。「触ってみて違ったら戻す」というループを高速で回せるので、方向決めと初期の作り込みが地続きになります。
Claude Code に持ち込んで本番化する
方向が決まったら、Claude Code に持ち込んで細部を詰めます。実データを流し、CI で自動更新し、スマホでも崩れないようにして、ようやく毎日使える道具になります。
ここで効くのが、派手な新機能を足す前に「今あるものを正しく動かす」ことから始める姿勢です。プロトタイプの分岐を畳んで本筋に絞る、画面の中間幅でテキストがはみ出すのを直す。こうした地味な一手から本番化を始めると、土台が崩れません。私もブログまわりのツールを作るときは、まずこの取りこぼしの掃除から入るようにしています。
Link Local code と Send to で往復をつなぐ
2つの道具を行き来する以上、ファイルの受け渡しが面倒だと続きません。当初はインポートと ZIP 書き出しの手作業で、「どっちが最新か」を気にするのが地味な負担でした。
ここを楽にするのが2つの仕組みです。手元のリポジトリを Claude Design に読み込ませる側は「Link Local code」でローカルのディレクトリを直接指定でき、GitHub を介さず最新ファイルを読めます。逆に、キャンバスでの編集をリポジトリへ戻す書き戻しは「Send to...」から手元のコーディングエージェントを宛先に選ぶと、取り込み用のプロンプトが用意されます。実際の反映は Claude Code 側のプルなので、取り込みのたびに差分を確認してから確定でき、いつもの開発ループにそのまま乗ります。なお、変更を ZIP で受け渡しする場面が残ると、macOS の Finder で解凍したときに .github や .claude のようなドットで始まる名前が原因でエラーになることがあります。こうした受け渡しまわりの泥臭い部分は、ディレクトリ接続に寄せて手作業を減らすほど安定しました。
「色は意味にだけ使う」羅針盤を先に作る
往復をぶれずに回すために、私が早い段階で固めておくと良いと感じたのが、デザインの方針を一文で言える形にしておくことです。たとえば「色は意味づけ（区分の識別や、増減の向き）にだけ使い、飾りのための色は足さない」と決めておくと、後から要素を追加するたびに「これは意味のある色か」と問い直せます。
この羅針盤を Claude Design の段階で言葉にしておくと、Claude Code で何度も細部をいじっても判断の軸がぶれません。発散で決めた方針を、収束の現場が参照する正として持ち込む。たったこれだけで、画面が育っても一貫性が保たれます。装飾を増やすより、意味のない色や数字を足さない方向で密度を上げる、という構えが結果的に読みやすさにつながりました。
どこから試すか
この往復をいきなり大規模なプロジェクトで試すと、勝手がつかめないまま疲れてしまいます。おすすめは、機能を絞った小さなテーマを1つ選び、Claude Design で方向を決めて、Claude Code で本番化するところまでを一周してみることです。
一周すると、発散と収束を別の道具に預ける感覚が体に入ります。私自身、最初は小さなダッシュボードのような題材で往復の呼吸をつかみ、そこから少しずつ扱う規模を広げました。後編では、この往復をさらに安定させるための単一ソース化や、CI による自動更新、SNS 共有画像の自動生成といった本番運用の作り込みを、実装を交えて掘り下げます。まずは小さな一周から始めてみてください。