Claude CodeでWebサイトを丸ごと作って運用してわかったこと（このブログの話）

このブログ（clvr.lol）は、ほぼ全部Claude Codeで作っている。Astro 5のサイト本体、文字数カウントやcron式ジェネレータなどのブラウザツール7本、スネークや2048などのブラウザゲーム4本、シンセウェイブ調のデザインまで含めて、エディタで自分がコードを書いた量より、ターミナルでClaude Codeに指示を出した量の方が圧倒的に多い。

だからこの記事は「Claude Codeでこういうことができます」の紹介ではなくて、実際にサイトを1つ作って運用し続けた中で「効いたこと」と「期待どおりにいかなかったこと」の記録だ。

一番効いたのはCLAUDE.md。ただし最初からは書けない

Claude CodeはプロジェクトルートのCLAUDE.mdを毎回読み込む。ここに規約を書いておくと、セッションをまたいでも同じルールでコードを出してくれる。これが一番効いた。

ただ、正直に言うと最初から良いCLAUDE.mdが書けたわけではない。うちのCLAUDE.mdは「失敗の記録」に近い。たとえば記事のfrontmatterにはcategoryのenum制約があって、これを外れるとビルドが落ちる。Claude Codeが規約外のcategoryで記事を作ってビルドが壊れたことが実際にあって、それ以来CLAUDE.mdに「categoryはこの6種のみ。違反するとビルドが落ちる」と書いた。以降は同じ事故が起きていない。

つまり運用は「事故る → 原因の規約をCLAUDE.mdに1行足す → 二度と起きない」の繰り返しだ。最初に完璧な規約集を書こうとするより、壊れた場所から書く方が、実際に効く1行になる。

# 例: うちのCLAUDE.mdにある実際の類いの記述
- frontmatterのcategoryはenum内のみ（違反するとビルドが落ちる）
- 秘密情報(.env, APIキー)は絶対コミットしない
- デプロイはnpm run deploy（.envをsourceしてwrangler pages deploy）

さらに一歩進めて、frontmatterの検証はhooksで機械化した。Claude Codeが記事ファイルを書いた直後にスキーマ検証スクリプトが走る設定にしてある。「CLAUDE.mdに書いてもたまに守られない」系のルールは、文章で念押しするより検証を自動で走らせる方が確実だった。

まとめて指示すると、デザインの一貫性が勝手に保たれる

ツールページを増やしていったときに気づいたのがこれ。1本ずつ「文字数カウントを作って」「次はJSON整形を作って」とやると、微妙に配色やレイアウトの解釈がずれる。逆に「既存のツールページと同じ構成・同じデザイントークンで、この機能のページを作って」と既存ファイルを参照させると、CSSの書き方からコンポーネント構成まで揃った状態で出てくる。

要するに、Claude Codeにとって「お手本ファイルの存在」はプロンプトの長文説明より強い。新しいページを作るときは、ゼロから仕様を語るより「このファイルを踏襲して」の一言の方が仕上がりが安定する。ゲームを4本作ったときも、2本目以降はスコア保存やタッチ操作の実装を1本目から流用してくれたので、後から作ったものほど手戻りが少なかった。

スクリーンショットを貼るのが、レイアウト修正の最短ルート

モバイル表示の崩れ（ヘッダーがはみ出す、カードが横スクロールを生む、の類い）は、文章で説明するよりスクリーンショットを撮って貼る方が早い。Claude Codeは画像を直接読めるので、「この画像の状態になっている。原因を特定して直して」で該当コンポーネントの特定から修正までやってくれる。

このサイトでも、ツールページのフォームがスマホでビューポートからはみ出したとき、DevToolsのスクショを貼っただけで原因のCSSにたどり着いた。「どのファイルが原因か自分で探してから指示する」工程を丸ごと省けるのが、プロジェクト全体を横断検索できるCLIツールならではの利点だと思う。

期待どおりにいかなかったこと

良い話ばかりだとフェアじゃないので、うまくいかなかった方も書く。

デザインの微調整は往復が必要。 「シンセウェイブ風のデザインにして」で出てくる初稿は、方向性は合っているが、そのまま公開できる水準ではなかった。グラデーションの色味、グローの強さ、余白のバランスあたりは結局「ここをもう少しこう」を何往復もした。骨組みは速いが、最後の2割は人間の目が要る。

生成させた文章はAIっぽくなる。 コードは良くても、記事やLPのコピーを丸ごと書かせると、網羅的で当たり障りのない文章が出てくる。実はこの記事自体、初版はClaude Codeの自動生成で、「テクニック5選」型の教科書的な記事だった。読み返してあまりにAIっぽかったので、実体験ベースで全面的に書き直したのが今の版だ。文章は「素材を出させて人間が直す」か、文体の規約を相当作り込むかのどちらかになる。

一発で完成することはない。 どの作業も「動くものは一発で出る。完成には往復が要る」が実感に近い。この前提でいると精神的に楽だし、往復コストを減らす投資（CLAUDE.md、hooks、お手本ファイル）に意味が出てくる。

2026年現在の環境について

自分が使い始めた頃はCLIだけだったが、今はVS Code / JetBrains拡張、デスクトップアプリ、Web版まである。モデルもClaude 5ファミリー（Fable 5）が最新で、Opus 4.8やSonnet 5、軽量なHaiku 4.5と使い分けられる。自分は普段の実装は既定モデルのまま、コミット前のレビューだけ上位モデルに投げる運用に落ち着いた。全部を最上位モデルでやる必要は感じていない。

他のAIコーディングツールとの比較はGitHub Copilot vs Claude Codeのレビューに書いたが、個人的な結論はシンプルで、「補完が欲しいならCopilot、ファイル操作とコマンド実行まで任せたいならClaude Code」だ。サイトを丸ごと1つ作って運用するような使い方は後者でしか成立しなかった。

Claude Codeは魔法ではない。放っておけばサイトが完成するツールではなく、「規約と検証を整えた分だけ、任せられる範囲が広がるツール」だ。このブログのツールもゲームも、その積み上げの上で回っている。