Claude Codeの主任デザイナーがAIでビルドする方法 [YouTube]

• 実際のプロダクト開発でClaude Codeをどう使うか、Excalidrawにautocomplete機能を直接追加しながら 実践的なワークフロー を実演
• デザイナーの発表だが内容はほぼ開発者向けワークフローに近く、worktreeで複数のClaudeセッションを並列実行し、機能プロトタイプを作り、ブラウザで検証し、PRを上げるまでの過程をCLI中心に扱う
• 核心はAIを単にコードを代わりに書くツールとして使うのではなく、アイデア探索 → 実装案比較 → 自己検証 → PR作成 → レビュー反映 → マージ補助 まで続くプロダクト開発パイプラインに組み込む方法であること
• デザイナーにとって有用な点は、Claudeがまだデザイン判断を得意としていないという限界を認めつつも、複数の実装案を素早く作り、スクリーンショット・GIF入りのPRでレビューさせることで、デザイン意思決定の速度と品質管理 を同時に高める方法を示している点
• 開発者にとって有用な点は、/prototype、loop、自動権限モード、Chromeベースのセルフテスト、コード整理・レビュー・PRマージ自動化のように、Claude Codeを実際のリポジトリと協業フローの中につなぐ具体的なパターンを見られる点
• 特に「誰もが作れるからといって、すべてがデプロイされるべきではない」という観点が重要で、AI時代にはより多くの人がコードを作れるようになる分、検証、レビュー、デザイン関与、デプロイ基準 を自動化されたシステムへ拡張する必要がある
• 結局この動画は、デザイナーがAIでコーディングする方法というより、デザイナーと開発者がAIを間に置きながら プロダクト品質を維持しつつ、より速く実験する方法 を示す事例

---

発表の文脈と登壇者

• Claude CodeのリードデザイナーであるMeaghan Choi
• AI導入以前から CLIプロダクトを設計 しており、Claude CLIの設計に参加し、自らを「CLI信奉者（CLI die-hard）」と表現
• Anthropicのメンバーはツールに常時アクセスし、一日中使っているため、より最適な作業方法 を絶えず探している雰囲気だと説明
• デスクトップアプリのほうがアクセスしやすく、デモのすべての作業は desktop appでも同様に可能 だと明言
  • CLIは登壇者個人の好みであり、視聴者が必ず従うべき方式ではない

並列・高速作業環境の設定

• worktree

  • ローカルリポジトリで複数のClaudeを同時に動かすと、互いの作業を上書きして 衝突 が起こりうる
  • worktree はリポジトリの分離されたコピーを作り、複数の作業を並列に進められるようにする
    • エンジニアがClaudeを4〜5個開いている場合、repo1・repo2のようにリポジトリを複製しているか、worktreeを使っているということ
    • claude --worktree を実行すると自動で新しいブランチをチェックアウトするため、管理しやすく推奨

• Opus 1M · fast mode

  • 登壇者は常に Opus 100万コンテキスト と fast mode を使用しているが、組織によってはアクセスが制限される場合がある
  • 15分のデモを素早く進めるための設定で、若干の速度差があると説明

• auto mode

  • Anthropicのメンバーは常に auto mode を使用しており、低権限モードの代替になっている
  • 分類器（classifier） が危険な動作かどうかを検知するため、「Yes, accept」を繰り返し承認する必要がなく、作業が大幅に速くなる

• Loop

  • Loop は「すべて終わるまで続ける」を意味する標準プロンプトで、完了するまで作業を繰り返させる

プロンプトとprototype skill

• デザイン仕様なしに「autocompleteを追加したい」という シンプルなプロンプト だけで、Excalidrawへの機能追加を指示

• prototype skill

  • Claudeに依頼して自作した slash prototype skill で、1つの機能について基本5個（n個）の実装案を生成し、HTMLファイルでプレビューして繰り返す
    • スキルは手書きではなくプロンプトで作ることを強調し、「最近スキルを手で書く人はいない」と表現
  • Claudeにまず 1つの案を自分で選び、その理由を説明 させるよう求め、登壇者は結果を見るのが楽しいと述べる
  • 「オンラインリサーチを許可」を追加し、本番コードベースなら Slack・Google Docs・議論記録・BigQuery などあらゆるソースを参照させただろうと説明
  • 最良案の実装・検証・スタイル一致の後、スクリーンショット入りのPR を生成するよう指示
    • 以後は文字起こしではなく、実装された機能の録画が入った PRをレビュー する方式へ切り替える
  • デモではClaudeが提示した複数のタブ補完（autocomplete）案の中から、観客の意見を反映して2番を選択

作業の3つの原則

• Claudeを含むほとんどのLLMはまだデザインに弱い ため、craftと意思決定には人間が引き続き関与すべき
  • 永続的な限界ではないが、現在のワークフローは「人がプロダクトに入るものを決める」という前提の上に成り立っている
• コーディングは自動化しても、非コーディング業務もClaudeに委任 すべきであり、そうでなければ最も自動化された使い方にはならない
• 誰でもshipできるからといって、すべてをshipすべきではない。誰もが本番環境へpushできるようになるほど、スケーラブルなシステムが必要になる

非コーディング業務の自動化

• Claude in the web (cloud)

  • アプリで見つけた 数百件の細かなpolish修正 を、別セッションなしで常時処理する用途
  • 修正が多すぎるというエンジニアの不満があるときは、1つのPRにsquash するよう依頼
    • 些細なCSS変更はレビューなしで自動承認されることもあり、プロダクトの完成度維持に有効

• PRマージ自動化

  • ほぼすべてのメンバーがClaudeを常時動かして PRマージ を支援させており、登壇者はもはやCIやマージ直前の段階に直接関与していない
  • simplify・code review はリポジトリ内部向けで、コードベースを整理（prune） するためのもの。AIを使うエンジニアリングチームなら類似ツールがあるはず
  • commit push PR は内部チェックを一括実行するコマンド
  • 開いているPRを確認し、完了段階まで押し進める コマンドはスキルに組み込まれている
    • Slackと連携し、コードレビュアーやon-call担当へ自動でDMを送り、ツール群の統合が重要

• Claude in Chrome

  • Claudeが直接Chromeを開いて動作をテストし、フロントエンド変更の自己検証 に最も適した方法として推奨
  • 一連の GIF としてスクリーンショットを記録して投稿し、その後PRを開く流れ

• スケジュールルーチン（Claude code work）

  • 定期実行ジョブ（routine）として、全リポジトリの フロントエンド変更 をスクレイプ
  • Slack・Google Meetの文字起こし・Google Docs などを見て、デザイナーが関与したかどうかを確認し、不参加ならフラグを立てる
  • 不参加の場合はデザインをレビューし、対抗視点のデザイン（adversarial design）PR をドラフト作成し、該当エンジニアにDMしたうえでデザイナーとの協業を依頼
    • Claudeはデザインに弱いためDM機能は無効にしてあり、これは1つ目の原則（LLMはまだデザインに弱い）とつながる
  • 最初の段階だけでなく、次の段階のさらに次の段階 まで自動化を押し進め、次期モデルのリリース時にすぐ適用できるよう事前に書いておく戦略

デザイナー・開発者にとって有用な理由

• 発表の目的そのものが Claude Codeユーザーの作業レベル向上（up level） であり、実際にAnthropic内部で人気のある作業スタイルをそのまま公開している
• 開発者の観点では、worktreeによる並列作業、auto modeで承認の反復を排除、PRマージ・CI自動化 など、日々の作業速度を直接高める具体的なコマンドと動作を示している
  • 発表で使われた simplify・code review のようなツールは、AIを使うエンジニアリングチームであれば社内に同等のものがあるはずなので、エンジニアリングパートナーに聞いて活用するよう案内
• デザイナーの観点では、LLMはまだデザインに弱い ことを前提に、人間がcraftと意思決定の主体であり続け、自動化は補助に置くという立場を明確にしている
  • デザイナー参加なしでshipされたフロントエンド変更を検知・フラグする スケジュールルーチン のように、デザイン品質をシステムで守るアプローチを提示