Claude Codeは、パソコンに入れて文字で指示を打ち込むアプリです。
やりたいことを日本語で伝えると、Claudeがサイトのコードを書いたり、ファイルを直したりします。
そのClaude Codeでのサイト制作の相談が、2026年に入ってから続けて届きます。
詰まっているのは作り方より手前で、何を人が決めて、何をAIに任せるのかを決めずに始めていることです。
私も自社サイトとLP（商品やサービスを1ページで紹介して申し込みにつなげるページ）を公開まで運ぶまでは、同じところで止まっていました。

「1セッションでサイトが完成する」はどこまで本当か

画面ができても、公開と運用の工程が残る

1セッションとは、Claude Codeを開いてから閉じるまでの一続きのやりとりです。
「1セッションでサイトが完成する」と聞いたら、どこまでを完成と呼ぶかを先に確かめてください。
画面が生成されるところまでなのか、公開して誰でも見られる状態までなのかで、残る作業が変わります。
独自ドメインでの公開と、そのあとの運用は、画面の生成とは別工程です。

公開されている所要時間は前提条件つきの実績

公開されている実測を2つ並べます。
Web制作会社のLIGは2026年3月27日の記事で、実装経験ゼロの筆者がデザイナーの作ったカンプ（完成イメージを画像にしたデザイン見本）から約2週間で公開まで到達したと書いています（liginc.co.jp/676810）。
noteの事例は2026年4月13日で、制作時間は約5時間、コードは全行Claude Codeが書いたとあります（note.com/kazu_t/n/n70228e202871）。
2週間の事例はカンプから実装を始めました。
5時間の事例では、デザインシステムを文章でまとめたDESIGN.mdを、note記事の筆者が実装前にClaude Codeへ渡しています。
同じ「Claude Codeで作った」でも前提が違うので、所要時間は一般化できません。

artifactでは先に決めたものが優先される——公式が順序を明記している

artifactではデザインシステムがClaudeの判断より優先される

先に決めろという話は、好みの押しつけに聞こえるかもしれません。
ところが、これは製品側が前提にしている順序です。
Artifactsの公式ドキュメントは、artifactを作るときの説明として、Claudeはあなたのデザインシステムを自身の選択より高い優先度で扱い、あなたのプロンプトを両者より高い優先度で扱うと書いています（code.claude.com/docs/en/artifacts）。
artifactを作るときは、デザインシステムがClaudeの判断より上、プロンプトがその両方より上。
同じドキュメントは、色と書体と余白の置き場所として、CLAUDE.mdか、サイトのファイル一式を置いている場所（リポジトリ）のテーマファイル（色や書体の値をまとめた設定ファイル）を推奨しています。

公式が書いているのは優先順位であって、所要時間ではありません。
自社の2件では、値を先に置くまで、色や余白を変えるたびに、できた画面の枚数ぶん直しが出ていました。
短くなるのは作業そのものではなく、作り直しの回数です。
自社サイトとLPの2件では直した回数を記録していないので、何割短くなったとは言えません。

artifactでは、色と書体と余白の値を先に書かないとClaudeが選んだ色と書体で組まれる

同じドキュメントは、artifactを作るとき、Claudeは追加の指示がなくても組み込みのデザインスキル（手順をまとめてClaudeに持たせる仕組み）を適用し、そのスキルはまずリポジトリの中に自前のデザインシステムがないかを探すと書いています。
見つからなければ、Claudeがその場で選んだ色と書体がそのまま使われます。
公式の優先順位はartifactの話ですが、独自ドメインで公開するサイトでも、値をCLAUDE.mdに書けば毎回言い直さずに済みます。

工程を7段に分けて分担を先に決める

人が決め切る4工程（情報設計・コピー・公開・運用）

人が決め切るのは4つです。

• 情報設計：ページ構成と、各ページのゴール
• コピー：価格と実績、保証やサポート範囲の約束のように、後から言い換えてはいけない文
• 公開：どこへ、どの手順で出すか
• 運用：公開後に誰が更新を入れるか

ここをAIに委ねると、後工程の手戻りが全部この4工程に戻ってきます。
コピーが決まっていないままページを3枚作れば、直しは3枚分になります。

人が決めてAIに渡す2工程（デザインと検証）

デザインは、色と書体と余白の刻み（使ってよい余白の値を数個に絞った一覧）を人が決めてから渡します。
検証は、受け入れ条件（実装を終わりにしてよい条件）を人が決めてから渡します。
条件の実物は、最後の「完成したCLAUDE.mdの実例」の受け入れ条件で、1〜5はClaudeが、6は人が確かめます。

AIが決めてよい1工程（実装の細部）

見た目の指定のまとめ方（クラス設計）、画面を部品に割る分け方（コンポーネント）、どの余白にどの値を当てはめるかは、AIが決めてよい範囲です。
余白の刻みは、人が 4, 8, 16, 24, 40, 64 px（画面の長さの単位）のように数個に絞って渡します。
任せるのはここまでで、その手前のデザインは渡しません。
私の運用ルールは「Claude Code単独でデザインしない」です。

デザインを決める3つのやり方を費用と時間で選ぶ

自分で決めるか、外部デザイナーに頼むか

自分で決めるなら、用意するのは役割ごとの色（自社サイトとLPの2件では4〜6色）と書体、余白の刻みです。
ただし、artifactでは、その場のプロンプトがCLAUDE.mdの値より優先されます（公式の記載はartifactについてです）。
指示文で別の色を書けば、CLAUDE.mdの値ではなくそちらで組まれます。
artifactでも公開サイトでも、実装後に色と書体が決めた値どおりか確認してください。
自分で決めるやり方は、迷い始めると止まるのが弱点です。
カンプをデザイナーに作ってもらう道もあります。
LIGの記事は、社内のデザイナーが作ったカンプからの実装です。
デザインツールのFigmaで作ったカンプなら、Figma MCP server（Figmaとの連携用の仕組み）を使えば、Figmaのデザインの色や書体や余白の値をClaude Codeから読み取れます。
自社では試していません。
利用にはDevまたはFullのシート（Figmaで人に割り当てる有料の利用権の種類）が必要です（figma.com/blog）。

Claude Designに案を出させて選ぶ

Claude Designは、claude.aiをブラウザで開いて使うデザイン作成の機能です。
Claude Codeでは、/design のあとに作りたい画面の説明を続けて打ちます。
Claudeが案を並べたページのリンクを出すので、デスクトップのブラウザで開いて1つ選びます。
公式が週ごとに出す更新のまとめ（週次ダイジェスト）の2026年8月の回は、出てきた案の1つを選択し、調整してから、Claudeに実装させますという順序で書いています（Week 34）。
Claude Designは、2026年10月13日時点でFree、Pro、Max、Teamの各プランでは既定で使えます。
Enterpriseでは、2026年10月15日以降は既定で有効です。
それより前は組織のオーナーの設定が要ります（support.claude.com）。
一方でClaude DesignはFreeでも使えますが、Claude CodeはFreeプランに含まれません。
Proは月払で20米ドル、年払だと月あたり17米ドル換算です（claude.com/pricing）。
/design を使うのに、少なくとも次の3つが要ります。
Enterpriseはこれに加えて1つ要ります。

• 契約：Pro、Max、Team、Enterpriseのどれか
• バージョン：Claude Code v2.1.265以降（2026年10月13日時点のArtifactsのドキュメントに合わせる。8月の週次ダイジェストの記載はv2.1.234以降）
• サインイン：Claude Codeに /login と打ち込み、claude.aiのアカウントで入る
• Enterpriseのみ：組織のオーナーが組織設定のArtifactsで案のひな形（デザインのテンプレート）を有効にする。claude.ai側のClaude Designの既定有効化とは別の設定。Pro、Max、Teamでは案のひな形が既定で有効です。

/design は、Week 34（2026年8月）の時点では、仕様が変わる前提の先行公開（リサーチプレビュー）と書かれていました。
2026年10月13日時点のArtifactsのドキュメントでは、/design が使う案のひな形が試験段階（ベータ）と書かれています。

artifactと独自ドメインの公開サイトは別物

artifactにだけかかる制約

artifactは、claude.ai上のURLをブラウザで開いて見る1ページの成果物です。
作った時点では自分だけが見られます。
他の人へ見せる条件は組織の設定によって変わるため、Artifactsの公式ドキュメント（code.claude.com/docs/en/artifacts）で確認してください。
同じドキュメントによると、データの保存や処理をするサーバ側の仕組み（バックエンド）を持てず、URLの違う複数ページも持てません。
外部に置いた画像は、ブラウザ側で読み込み先を制限する仕組み（CSP）で止められます。
外部から読み込める書体は、Googleが無料で配布しているWebフォント（Google Fonts）だけです。

artifactの制約は、自前で公開するサイトには当てはまらない

相談で一番混ざるのがこの区別です。
「Google Fontsしか使えないと聞いた」という誤解は、外部から読み込める書体がGoogle Fontsに限られるという制約から生まれています。
この制約はartifactだけのもので、自前でデプロイする（作ったファイルを公開用のサーバに置く）サイトにはかかりません。

Claude Code単独に任せて崩れた箇所（自社サイトとLPの実例）

ページをまたぐと一貫性が落ちる

自社サイト（re-rail.co.jp）と自社で運営する講座のLP（re-rail.co.jp/kuroaka/）は、Claude Codeで実装して公開まで運びました。
手を入れ直したのは、ページをまたいだ見た目の揃え方でした。
同じ役割の見出しやボタンが、ページごとに少しずつ違う大きさで出てきます。
色と書体と余白の刻みをCLAUDE.mdに書いていなかった時期に起きたものです。
刻みを先に決めてから依頼する形に変えたあと、同じ直しは減りました。
原因を切り分けて再現を取ったわけではないので、言えるのは私の作業の範囲のことだけです。
結論として、デザインは人が決めてから実装に渡す形に落ち着いています。

言葉にしにくいものはAIに渡らない

文字で渡せたのは、色の値や書体名、余白の刻みのように、そのまま書き出せるものでした。
画面の動き（アニメーション）の速さや止め方は、言葉だけでは決められませんでした。
だから案を見てから選ぶ形に変えています。
LIGの記事も、アニメーションの質感を言葉にするところで苦戦したと書いています。

受け入れ条件を先に決めると検証をAIに渡せる

公式が示すスクリーンショット比較の指示文

公式ベストプラクティスには、UI（画面の見た目と操作する部分）向けの指示例が載っています（公式ベストプラクティス）。
元のデザインのスクリーンショットを貼り、次の指示文を打ちます。
公式の例文を訳したものです。

［ここに元のデザインのスクリーンショットを貼る］
このデザインを実装して。
結果のスクリーンショットを撮って元と比べ、差分を列挙して直して

この指示文で結果のスクリーンショットを撮らせるには、Claude Codeがブラウザを操作できる状態（Chrome連携）が必要です。
必要なChromeの拡張機能とサインインの条件は公式ページで確認してください（code.claude.com/docs/en/chrome）。

受け入れ条件を先に決めておけば、確認そのものはAIに渡せます。

/verifyで最後に確かめる

Claude Codeに最初から入っているスキルの /verify は、サイトを含むアプリを組み立てて動かし、コードの変更が意図どおりかを確かめるものです（公式のスキル一覧）。
公式のベストプラクティスは、Claudeの確認が通ったあとに人が /verify を実行する順で書いています。
自社では、公開前の動作確認を、ブラウザ操作を自動で繰り返すPlaywrightで通しています。
見た目の判断は人が、画面幅を変えて全ページを開き直す確認は自動で、と分けています。

完成したCLAUDE.mdの実例

自社の値に差し替えて使う

ここまでの内容を、そのまま貼れる形にまとめました。
色と書体の値はダミーです。
ご自身の会社の値に置き換えてから使ってください。

# このリポジトリのサイト制作ルール

## デザインシステム（人が決め切る。ここから外れた値を使わない）
- 色（以下5値はダミー。自社の値に差し替える）
  brand=#1F3A5F / accent=#D9822B / text=#1A1A1A / bg=#FFFFFF / muted=#6B7280
- 書体（ダミー。自社の書体に差し替える）: 見出し=Noto Sans JP Bold / 本文=Noto Sans JP Regular
- 余白の刻み: 4, 8, 16, 24, 40, 64 px のみ使う。中間の値を作らない

## 工程ごとの分担
- 情報設計（ページ一覧と各ページのゴール）: 人が決め切る。Claudeは提案までで止める
- コピー（価格、実績、約束の文）: 人が決め切る。渡した文言の言い換えを禁止する
- デザイン: 案を3つ出す。人が1つ選び、調整したあとで実装に入る
- 実装の細部（クラス設計、コンポーネント分割、刻みの当てはめ）: Claudeが決めてよい
- 検証: 下の受け入れ条件1〜5を、Claudeが繰り返し確認する
- 最終確認: Claudeの確認が通ったあと、人が /verify を実行する（受け入れ条件6）
- 公開: 手順書の作成まではClaude、公開の実行は人が行う
- 運用: 更新を入れる人と、戻す先のコミット（Gitに残した戻せる状態）を公開前に決めておく

## 受け入れ条件（実装を終わりにしてよい条件）
1. 選んだデザイン案と実装のスクリーンショットを並べ、差分を列挙してから直す（Chrome連携が前提）
2. 画面幅を変えて全ページを確認し、余白が上の刻みから外れていないことを確認する
3. 色と書体が、上のデザインシステムの値だけでできている
4. 価格、実績、約束の文が、渡した原文と一文字も違わない
5. ページをまたいで、同じ役割の見出しやボタンが同じ見た目になっている
6. 人が /verify で組み立てと実行を通し、変更が意図どおりか確かめる

## やらないこと
- デザインを決めないまま実装を始めない
- artifact の制約（1ページ、外部画像のブロック、外部から読み込む書体は Google Fonts のみ）を、
  独自ドメインで公開するこのサイトの制約と混同しない

受け入れ条件を同じファイルに置く理由

公式がCLAUDE.mdかテーマファイルを置き場所に推奨しているのは、色と書体と余白の値です。
分担と受け入れ条件まで同じファイルに置くのは、自社のやり方です。
そうしておくと、毎回のプロンプトで指定し直す手間が消えます。

よくあるご質問

決める人がいれば、実装は任せられる

最初に決める3つ

公式ドキュメントは、artifactでは先に決めたデザインシステムがClaudeの判断より優先されると明記しています。
逆に言えば、artifactでは、決めずに始めるとClaudeがその場で選んだ色と書体で組まれます。
最初に決めるのは3つです。
ページ構成と各ページのゴール。
価格と実績と約束の文。
役割ごとの色（自社の2件では4〜6色）と書体、余白の刻み。
この3つを決めてから、実装を渡します。
色と書体と余白の刻みは実例のとおりCLAUDE.mdに書き、ページ構成とコピーは7工程の表の1行目と2行目の「AIに渡す形」の欄どおりに渡します。

次にやること

本記事は2026年10月13日時点の内容です。
仕様は週単位で動いているので、読む時点では条件が変わっている前提で、公式ドキュメントを一度開いてください。
工程の切り方だけで止まっているなら、そこだけ一緒に整理することもできます。
私が答えられるのは、自社サイトとLPを公開まで運んだ範囲の話です。
7工程の分担表を自社の工程に当てはめてみて、埋まらない欄が出たら、そこから相談してください。