Claude Design誕生秘話──1人・1週末から10週間で本番投入するAnthropicのプロダクト哲学

anthropic/claude-design

🧠 Claude Code claude-design anthropic-labs agent-sdk claude-code ui

2026.05.22 1分

Claude Design誕生秘話──1人・1週末から10週間で本番投入するAnthropicのプロダクト哲学 - AIツール日本語解説 | AI Heartland

2026年5月、AnthropicがCode w/ Claudeイベントで公開した28分間の講演には、Claude Design誕生から本番投入までの全工程と、AIネイティブプロダクトを高速に市場投入するための哲学が詰まっていた。日本語でまとめた情報源がなく、エンジニアとPMにとって実践的価値が高い。

2026年5月、AnthropicはCode w/ Claudeイベントで28分間の講演を公開した。テーマは「Designing with Claude: From prompt to production」──Claude Designというデザインツールが、1人のエンジニアの週末プロジェクトから、数万人が使う本番プロダクトへと進化するまでの物語だ。

この動画には、AIネイティブプロダクトを超高速でゼロから本番投入するための開発哲学と実践手法が詰まっている。字幕なし・28分間・英語のみの講演を、12のポイントで日本語解説する。

AIデザインツールとしてのClaude Designの機能・料金・比較についてはClaude Designの使い方｜AIデザインツールでプロトタイプ・3D・スライドを完全解説を参照してほしい。本記事はプロダクト開発の哲学と構造に焦点を当てる。

Code w/ Claudeイベント登壇者 — 「Code w/ Claude」イベントでClaude Designの開発哲学を語る登壇者。28分間の講演に開発の全工程が詰まっている

Anthropic Labsとは何か──Claude Designが生まれた場所

Claude Designを作ったのは、Anthropic内の「Labs」チームだ。Labsはリサーチとプロダクトの中間に位置する組織で、新しいClaudeの機能をゼロから小規模なプロダクトとして実験・検証する役割を担う。

Labsが掲げる運営原則は4つだ。

How Labs worksスライド — Anthropic Labsの4原則。Code w/ Claudeのイベント会場で発表されたスライド

How Labs works ── 4原則

Talk to users every day：毎日ユーザーと話す
Ship to users every day or two：1〜2日ごとにリリースする
Fix reported issues in 24 hours：報告された問題を24時間以内に修正する
Don't predict the future, run experiments：未来を予測せず、実験を走らせる

この4原則は、従来のSaaS開発とは根本的に異なる。2週間のスプリント・PRD（製品要件書）・ロードマップ会議──これらは一切登場しない。代わりにあるのは「毎日ユーザーと話す」「毎日シップする」という圧倒的なイテレーション速度だ。

特に重要なのは4番目の原則「未来を予測せず実験を走らせる」だ。AIモデルは数ヶ月単位で能力が飛躍的に変わる。今日のモデルでは不可能なことが、次のモデルリリースで突然可能になる。この環境では長期ロードマップより「今日何を試せるか」のほうがはるかに価値が高い。

Claude Designの誕生──1人・1週末・1本の画面録画

Claude Designの最初のプロトタイプは、驚くほど小さなスタートだった。

How Claude Design startedスライド — 「1 person / 1 weekend / 1 screen recording」──Claude Designの誕生を示すスライド

最初のプロトタイプ構成

人数：1人
期間：1週末
コア素材：1本の画面録画
技術構成：Agent SDK + 薄いIDEラッパー + 既存のデザインスキル

そのプロトタイプには欠点も並走していた。同じスレッドに「何が問題か」も書き込んだのだ。

alignment issues：レイアウトのズレ問題
good visd/average ux：ビジュアルは良いがUXが平均的
screenshot recreation didn’t work：スクリーンショットの再現が機能しなかった

そしてこの欠点リストがそのままロードマップになった。

「作ったものの問題点を並べただけで、次の開発計画ができた」──これはLabs流の製品管理の核心を示している。ロードマップをトップダウンで作るのではなく、実際に動くものを作り、ユーザーが何に引っかかるかを観察し、それを解消していく。

Agent SDKで最初のプロトタイプを作る方法

Claude Designの第一世代が使ったAgent SDKは、複数のClaude呼び出しをオーケストレーションし、ツール呼び出しを組み合わせて複雑なタスクを実行するための仕組みだ。最小構成でデザインスキルを持つエージェントを作る場合、以下のような構造になる。

import anthropic

client = anthropic.Anthropic()

# デザインスキルをツールとして定義
tools = [
    {
        "name": "generate_design",
        "description": "テキストプロンプトからデザインを生成する",
        "input_schema": {
            "type": "object",
            "properties": {
                "prompt": {"type": "string", "description": "デザイン指示"},
                "brand_context": {"type": "string", "description": "ブランドガイドライン"},
                "format": {"type": "string", "enum": ["prototype", "slide", "lp"]}
            },
            "required": ["prompt", "format"]
        }
    },
    {
        "name": "export_to_claude_code",
        "description": "デザインをClaude Codeにハンドオフする",
        "input_schema": {
            "type": "object",
            "properties": {
                "design_artifact": {"type": "string"},
                "handoff_bundle": {"type": "object"}
            },
            "required": ["design_artifact"]
        }
    }
]

# エージェントループ
response = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=4096,
    tools=tools,
    messages=[{
        "role": "user",
        "content": "スタートアップのランディングページを作ってください"
    }]
)

このコードはClaude Designの「薄いIDEラッパー＋既存スキル」という構成を再現したものだ。完全なプロダクトではなく、週末に1人で作れる最小の検証ユニットとして機能する。

小チームで役割を融合させる──1→3→5の法則

Claude Designのチーム構造は、一般的なスタートアップとは異なる。

Small teams where the roles mergeスライド — 「Small teams where the roles merge」スライド。1→3→5人の段階的拡張が示されている

Labsのチームビルディングには明確な公式がある。

1 → 3 → 5 の段階的拡張

1 person：魔法を見つける（1人でプロトタイプ）
3 people：ローンチまで持っていく
5 people：スケールで運用する

そして重要な原則がある。「全員がユーザーと話し、機能を設計し、コードを書き、フィードバックを読む（Everyone talks to users, designs features, ships code, reads feedback.）」。

エンジニア・デザイナー・PMという役割分担は最小化される。5人のチームメンバー全員がユーザーインタビューを行い、全員がコードを書き、全員がデザインの意思決定に参加する。これが「役割が融合する小チーム（small teams where the roles merge）」の意味だ。

この構造には明確なメリットがある。情報のサイロ化が起きない。エンジニアが「デザイナーからの仕様を待つ」という待機時間が消える。ユーザーの声がリアルタイムで開発に反映される。

必要なツールは自分で作る──Claude CodeへのハンドオフがClaude Designを変えた

Labsチームが直面した課題の一つが「機能を高速にシップすること」だった。このボトルネックを解消するために、彼らは内製ツールを作った。

Build the tools you needスライド — 「Build the tools you need」スライド。Claude Codeへのハンドオフ機能がどのように生まれたかが示されている

問題の特定から解決ツールへ

課題：機能を高速にシップできない（Ship features faster）
解決策：Claude Codeへのハンドオフ機能を自社開発
結果：ExportメニューにHandoff to Claude Code...が追加された

この「ハンドオフ機能」は、後にClaude Designの正式機能として一般ユーザーにも公開された。Labsチームが自分たちの開発スピードを上げるために内製したツールが、プロダクト自体の重要な差別化機能になったのだ。

「ツールを待つのではなく、必要なものは自分で作る」──これはLabsが持つエンジニアリング文化の核心だ。チームが開発フローで感じた摩擦は、そのままプロダクトのニーズと一致する。開発者自身がユーザーでもあるため、フィードバックループが極めて短い。

Claude CodeへのハンドオフAPIの使い方

Claude Designからコードに移行する際のハンドオフは、以下のような構造で実装できる。

// Claude Design → Claude Code ハンドオフの基本構造
interface DesignHandoffBundle {
  designTokens: {
    colors: Record<string, string>;
    typography: Record<string, FontSpec>;
    spacing: number[];
  };
  components: ComponentSpec[];
  layoutTree: LayoutNode;
  brandGuidelines: string;
}

async function handoffToClaudeCode(
  designArtifact: string,
  bundle: DesignHandoffBundle
): Promise<string> {
  const prompt = `
以下のデザインアーティファクトをReactコンポーネントとして実装してください。
デザイントークンはそのまま使用し、ブランドガイドラインに従ってください。

デザイントークン:
${JSON.stringify(bundle.designTokens, null, 2)}

コンポーネント仕様:
${bundle.components.map(c => c.description).join('\n')}

アーティファクト:
${designArtifact}
  `;
  
  // Claude Code CLIへの転送
  return prompt;
}

このハンドオフ構造により、デザインシステムのトークン（色・タイポグラフィ・スペーシング）がそのままコードに引き継がれる。デザイナーとエンジニアの「翻訳コスト」がゼロになる。

失敗から学ぶ──「1%未満が気に入った」機能の教訓

One thing we got wrongスライド — 「One thing we got wrong」スライド。高度なデザインコントロール機能の失敗と教訓が示されている

Labsでも失敗はある。講演者が「最大の失敗」として挙げたのが「高度なデザインコントロール」機能だ。

「One thing we got wrong」の経緯

高度なデザインコントロール機能の構築に1週間投入した
1%未満のユーザーしか好まなかった
それ以外のユーザーは誰も触れなかった
機能は削除された（Advanced design controls → 取り消し線）

スライドの結論は明確だ。

You will build the wrong thing occasionally. What matters is how fast you notice and how willing you are to course correct. （たまに間違ったものを作ることはある。重要なのは、どれだけ早く気づき、どれだけ積極的に軌道修正できるかだ。）

この失敗には構造的な教訓が含まれている。「高度なコントロール」を求めたのは、既存のデザインツール（Figmaなど）からの流入ユーザーだ。彼らは細かなパラメータ制御に慣れている。しかし、Claude Designのコアバリューは「テキストで指示するだけで高品質なデザインが出来上がる」こと──つまり、コントロールをAIに委譲することだ。

ユーザーの声に全て従うのではなく、プロダクトの本質的なバリューに沿うフィードバックを選別する能力が、LabsのPMに求められる。

v1から10週間後──週末プロトタイプの進化

v1 vs todayスライド — 「v1 vs today」比較スライド。左が週末プロトタイプ、右が10週間後の本番プロダクト

Claude Designの「週末プロトタイプ」と「10週間後」の比較は、AIネイティブ開発の速度を端的に示している。

週末プロトタイプ（Weekend prototype）：

Claude Code上で動くDesign Skill App
会話形式のUI
ワイヤーフレームレベルのデザイン出力
複数バージョンを同時生成する仕組み

10週間後（Ten weeks later）：

完全に独立したWebアプリケーション
インタラクティブなキャンバスUI
商用品質のビジュアル生成
地球儀・ランディングページ等の高度なデザイン対応
Canva・PPTX・HTMLへのエクスポート機能
Claude Codeハンドオフ機能

10週間で「プロトタイプ」から「本番プロダクト」への変化がこれほど大きいのは、AIモデル自体の能力と、5人のフルタイムチームによる集中開発の両方が効いているからだ。

Labsの開発フローを比較する

従来型SaaS開発とLabs流開発の違いを整理する。

比較軸	従来型SaaS開発	Anthropic Labs流
計画	PRD → 設計 → 開発	プロトタイプ → 欠点リスト = ロードマップ
チーム	エンジニア/デザイナー/PM分離	全員がユーザー対話・設計・実装を担う
リリース頻度	2週間スプリント	1〜2日ごと
ユーザー接触	スプリント開始時・終了時	毎日
機能削除の判断	四半期レビュー	使われない機能は即削除
未来予測	ロードマップで1年先を計画	実験で検証
失敗対応	ポストモーテム	「どれだけ早く気づくか」で評価
ツール調達	既存ツールを購入・採用	必要なものは内製

この表が示すように、Labsの開発哲学は「スピード」よりも「フィードバックループの短縮」に最適化されている。毎日ユーザーと話し、毎日シップするのは、速度のためではなく「何が本当に必要か」を最速で知るためだ。

「動作の端で構築する」──モデル進化を見越した開発戦略

Build on the edge of workingスライド — 「Build on the edge of working」スライド。プロトタイプを捨てずに保存しておく戦略が語られた

Labsが実践する最も独自性の高い戦略が「Build on the edge of working（動作の端で構築する）」だ。

スライドのメッセージは明確だ。

Prototype things that almost work on today’s model （今日のモデルで「あと少しで動く」ものをプロトタイプとして作る）

Keep them around （捨てずに保存しておく）

When the next model ships, they often just start working （次のモデルがリリースされたとき、それらはしばしば突然動き始める）

これは従来のソフトウェア開発では考えられない戦略だ。通常、「動かない機能」は削除されるか放棄される。しかし、AIモデルが進化する環境では「今日動かない機能」は「まだ動かない機能」に過ぎない。

Claude Designで具体的に当てはまるのは、スクリーンショットからのデザイン再現機能だ。初期プロトタイプでは「screenshot recreation didn’t work（スクリーンショットの再現が機能しなかった）」として欠点リストに記載されていた。しかし、Claudeのビジョン能力が改善されるにつれ、この機能は徐々に動作するようになった。

フィーチャーフラグを使った段階的公開

「動作の端」機能を管理するために、フィーチャーフラグによる段階的公開が有効だ。

from anthropic import Anthropic

client = Anthropic()

# フィーチャーフラグ管理の例
FEATURE_FLAGS = {
    "screenshot_recreation": {
        "enabled": False,  # 今日のモデルでは未完成
        "rollout_percentage": 0,
        "min_model": "claude-opus-4-7"  # 次世代モデルで有効化
    },
    "brand_extraction_from_url": {
        "enabled": True,
        "rollout_percentage": 100,
        "min_model": "claude-sonnet-4-6"
    }
}

def call_design_feature(feature_name: str, prompt: str, model: str = "claude-opus-4-7"):
    flag = FEATURE_FLAGS.get(feature_name, {})
    
    if not flag.get("enabled", False):
        return {"status": "unavailable", "reason": "feature_not_ready"}
    
    response = client.messages.create(
        model=model,
        max_tokens=2048,
        messages=[{"role": "user", "content": prompt}]
    )
    return {"status": "success", "content": response.content[0].text}

# 使用例：スクリーンショット再現は次モデルまで保留
result = call_design_feature("screenshot_recreation", "このUIを再現してください")

フィーチャーフラグを活用することで、「動作の端」にある機能を安全に保持しつつ、モデルアップグレード時に即座に公開できる体制を整えられる。

次にやること──Anthropicが視聴者に提示した3つのアクション

What to do nextスライド — 「What to do next」スライド。PRDをスキップしてミーティング議事録からプロトタイプを作ることが勧められた

講演の終盤、登壇者は視聴者に3つの具体的なアクションを提示した。

What to do nextスライドと聴衆が手を挙げる様子 — 「What to do next」で質問すると、多くの聴衆が手を挙げた。会場の反応がこのメッセージへの共感を示している

What to do next ── 今すぐ始める3つのアクション

Skip a PRD, use your meeting transcript to seed a prototype
PRDを書くのをやめ、ミーティングの議事録からプロトタイプを作れ
Pick one internal tool you've been waiting on and build it this week
「欲しかった社内ツール」を1つ選んで今週中に作れ
Set a 24-hour fix target for one user-reported issue
ユーザーが報告した問題を1つ選び、24時間以内の修正を目標に設定しろ

この3つのアクションに共通するのは「今週中に始められる」こと、そして「小さく始める」ことだ。PRDを書く代わりにミーティング議事録を使うのは、「完璧な計画より動くプロトタイプ」というLabsの哲学の直接的な実践だ。

会場で手を挙げた人数の多さ（スライド28で確認できる）は、この提案が現場のエンジニアとPMに直接刺さったことを示している。

Claude Designから読み解くAIネイティブ開発の構造

Claude Designの誕生と進化を整理すると、AIネイティブプロダクト開発の標準的なパターンが見えてくる。

graph TD A[1人が週末に魔法を見つける] --> B[プロトタイプと欠点リスト] B --> C[欠点リストがロードマップに変換] C --> D[3人チームでローンチ] D --> E[毎日ユーザーと話す] E --> F[毎日シップする] F --> G[動かなかった機能を保存] G --> H[次モデルリリースで機能が動き始める] H --> I[5人チームでスケール運用] E --> J[間違った機能を作る] J --> K[素早く気づいて削除] K --> F

このフローで特徴的なのは、失敗が「ループの外」に弾き出されるのではなく、「素早く気づいて削除」というステップでメインループに組み込まれている点だ。失敗はコストではなく、フィードバックループを短縮するための必要なサイクルとして設計されている。

また、「動かなかった機能を保存」→「次モデルで機能が動く」というサイクルは、AIモデルの継続的改善を前提とした開発戦略だ。これは従来型ソフトウェア開発には存在しない概念で、Labsの最も独自性の高い知見だ。