Claude Codeで自分のサイトを作った話。AIとの共同開発のリアル
このサイト、実はほぼClaude Codeで作っている。デザインの方向性を伝えて、コンポーネントを生成して、修正を繰り返して完成させた。1週間くらいの制作過程を振り返る。
きっかけ
ゲーム配信のポートフォリオサイトが欲しかった。YouTubeのチャンネルページだけだと情報が散らばるし、ブログも書きたかった。
ただ、フロントエンドは本業じゃない。インフラエンジニアなので、サーバーの設定やデプロイはできるけど、CSSを書くのは苦手。そこでClaude Codeに頼ることにした。
技術スタックを決めるまで
最初に考えたのは技術選定。候補はいくつかあった。
- Astro: 静的サイト向けで軽量。ブログには最適
- Hugo: ビルドが爆速。Go製で情報も多い
- Next.js: Reactベース。機能は豊富だけど個人サイトにはオーバースペック気味
結局Next.js（App Router）を選んだ。理由は「学びの最大化」。仕事でReactを触る機会があるから、個人サイトでApp RouterとReact Server Componentsを試しておきたかった。シンプルさだけならAstroの方が良かったと思う。でも、技術的な実験場としてはNext.jsが一番面白い。
デプロイ先はCloudflare Workers。Vercelの方がNext.jsとの相性は良いけど、エッジコンピューティングを触りたかったのと、仕事でCloudflareを使う機会が増えてきたから。詳細は別の記事に書いた。
技術選定の時点でもClaude Codeに壁打ちしている。「個人サイトでNext.js + Cloudflare Workersの構成ってどう？」みたいな感じで聞くと、メリット・デメリットを整理してくれるから判断しやすかった。
プロトタイプは一瞬でできた
最初に伝えたのは「ダークテーマで、ネオンっぽい雰囲気のポートフォリオサイト」。Next.jsを指定して、Cloudflare Workersにデプロイする前提。
正直驚いた。最初の出力でもう8割形になっていた。ヒーローセクション、About、YouTube埋め込み、お問い合わせフォームまで一気に出てくる。「ゲーム配信者のポートフォリオ」と言っただけで、YouTube埋め込みやSNSリンクが自然に含まれていた。技術仕様よりも「誰の、何のサイトか」を伝える方がよっぽど大事だった。
ファイル構成もApp Routerの規約に沿って app/ 配下にページ、app/components/ にUIコンポーネントという形で生成してくれた。手動で移動する手間がなくて助かった。
ここまでは順調だった。問題はこの後。
一番時間を食ったのはビジュアルの調整
開発の大半はこのループだった。自分が言葉で伝える、Claude Codeがコードを生成する、ブラウザで確認して「ここが違う」と言う、修正される、また確認する。
で、このループが一番回ったのがヒーローセクションのアニメーション。10回以上やり直している。「もう少しゆっくり」「光の軌道を変えて」「ネオンの光をもう少し控えめに」みたいな抽象的なフィードバックを何度も投げた。
これが意外と難しかった。「なんか違う」を具体的な言葉にしないといけない。自分の頭の中にある「こういう感じ」を言語化する能力が問われる。AIは曖昧な指示にもそれなりに対応してくれるけど、具体的に言った方が圧倒的に結果が良い。
途中で気づいたのは、デザイン用語を知っていると一気に効率が上がること。「グラスモーフィズム」と一言伝えれば、自分が5回くらいかけて説明していた質感が一発で出る。専門用語の語彙力がそのまま開発速度に直結する。これは想定外だった。
それからCSSのピクセル単位の微調整もきつかった。レイアウトの大枠は問題ないけど、「あと2px左に」みたいな指示は、自分でDevToolsを開いて直した方が早い。AIに伝えるより手を動かした方が速い場面は確実にある。
AdSense対応が本当に大変だった
サイトの基本構造なんかよりも、AdSense審査対応の方がずっと手間がかかった。これは正直想定していなかった。
プライバシーポリシー、利用規約、Cookie同意バナー、Consent Mode v2、構造化データ、OGP設定、セキュリティヘッダー。やることが山盛りだし、Googleの要件がとにかくわかりにくい。
特にConsent Mode v2の実装が厄介だった。Googleタグマネージャーとの連携、Cookie同意バナーの表示タイミング、同意状態の永続化。仕様書を読んでも何が正解なのかはっきりしない。Claude Codeと何往復もやり取りして、やっと動く実装にたどり着いた。
ここで痛感したのは、AIが「これで大丈夫です」と言っても、実際に審査に通るかは別の話だということ。AIは仕様を解釈してコードを書いてくれるけど、Googleの審査基準は外からは見えない。最終的には自分で判断するしかなかった。
コンテキストが切れると手戻りが起きる
もう一つ地味にストレスだったのが、セッションが長くなるとAIが前半の設計意図を忘れること。
「さっき決めたデザイントーンと違う」みたいな手戻りが何度かあった。新しいコンポーネントを生成すると既存のスタイルと衝突するし、CSS変数の命名が途中で変わったりもした。
対策として、プロジェクトのルートに設計方針をまとめたファイルを置いて毎回読み込ませるようにした。これでだいぶマシになったけど、完全には解消できていない。長いセッションでの文脈維持は、今のAI共同開発の明確な弱点だと思う。
楽だった部分
苦労した話ばかり書いたけど、逆にAIに任せて本当に楽だった部分もある。
JSON-LDの構造化データ、OGPタグ、robots.txt、sitemap.xml。この手の「仕様が決まっていて、書くのが面倒」な作業はAIの独壇場。正確だし速い。自分で書いたらたぶん半日かかる。
レスポンシブ対応も「モバイルでも見やすくして」の一言で済んだ。ブレイクポイントの設定もTailwindの md: lg: の使い方も的確。
お問い合わせフォームのバリデーション、404ページ、エラーバウンダリ。自分だと後回しにしがちな部分を最初から組み込んでくれたのもありがたかった。
ブログ機能の設計
ブログはMarkdownファイルをリポジトリに置くだけで記事が生成される仕組みにした。
具体的には、content/blog/ にMarkdownを置いて、ビルドスクリプトが gray-matter でフロントマターを解析、marked でHTMLに変換する。生成されたJSONを app/blog/[slug]/page.tsx が読み取って表示する流れ。Cloudflare Workersのランタイムでは fs モジュールが使えないから、ビルド時に全部変換しておく必要がある。
この「ビルド時にJSONを生成する」設計はClaude Codeが提案してくれた。ランタイムの制約を伝えたら自然にこの方式を出してきた。制約条件を先に共有すると、AIは妥当な設計を選んでくれる。最初はCMSを使う案も出たけど、「デプロイのたびに記事が反映される方がシンプル」という判断で今の形に落ち着いた。
丸投げしなかった理由
AIに全部任せることもできたと思う。でもそうしなかった。
自分のサイトだから、自分の意思が入っていないと意味がない。Aboutの文章、ブログの内容、デザインの方向性。これは自分で決めたかった。AIはあくまで実装の手を速くする道具。
あと、コードの中身を理解していないと運用できない。バグが出た時に「AIが書いたから知りません」は通らない。だから生成されたコードは毎回読んで、何をしているか把握した上でマージしている。時間はかかるけど、この手間を省くと後で確実に痛い目を見る。
振り返り
制作期間は実質1週間くらい。仕事の合間に少しずつ進めた。フロントエンド未経験でこのクオリティのサイトが作れたのは、間違いなくAIのおかげ。
ただ、「AIが作ったサイト」ではなく「AIと作ったサイト」だと思っている。設計判断も文章も、最終的には全部自分で確認して決めた。AIは優秀なペアプログラマーであって、発注先ではない。
振り返って一番感じるのは、自分が何を作りたいかがぼんやりしていると、出てくるものもぼんやりするということ。逆に「こう動いてほしい」が頭の中にあれば、AIはそれを形にしてくれる。結局、作る人間の解像度がそのまま成果物の解像度になる。
関連記事
他の記事
ブラウザ横スクロールアクションゲーム開発記｜TypeScript×Canvasで作るネオンランナー
HTML5 CanvasとTypeScriptで横スクロールアクションゲーム「ネオンランナー」を自作した。物理エンジン、衝突判定、操作性の工夫を解説する。
ブラウザで遊べるテトリス風パズルをTypeScriptで作った話
HTML5 CanvasとTypeScriptでテトリス風ブロックパズルを実装した。エンジンとUIを分離するSnapshotパターンや、ネオン演出のこだわりを解説する。
ゲーム実況のサムネイル作りで学んだデザインの基本
非デザイナーがゲーム配信のサムネイルを自作し続けて気づいた、視認性・配色・構図の基本ルール。試行錯誤の記録。
配信のコメント欄が動いた瞬間の話。ゼロからイチの体験
ゲーム配信でコメントがゼロの日々を超えて、初めてリアルタイムでコメントが来た瞬間の話。ゼロからイチの体験がモチベーションを変えた。