【実験ログ】Claude Codeで1日に5サイト立ち上げた全記録 ── 手順・失敗・学びをすべて公開

「1日で5サイト立ち上げた」って聞くと、「ウソでしょ？」って思いますよね。正確には3日間かけた作業なんですが、最終日の3サイトは本当に1日で完成しました。ここでは、その全工程を時系列に沿って正直に書いていきます。

何がうまくいって、何に時間を取られたのか。コスト、失敗、「次にやるならこうする」という反省まで、ぜんぶ公開します。

これは「すごいことをした自慢」じゃないです。むしろ「想定通りにいかなかったことのほうが多い」っていう記録です。だからこそ、同じことをやってみたい人の参考になると思っています。

---

実験の全体像

最初の計画では「1日1サイト、5日間で5サイト」のつもりでした。でもテンプレートの使い回しが思った以上にうまくいって、Day 3では1日で3サイトを立ち上げられました。逆にDay 1はWordPressとの格闘で、想定以上に時間がかかりました。

技術選定、公開先、記事の作り方、画像の用意まで、ぜんぶ一人で判断しながら進めました。ここからはDay 1から順番に、具体的にやったことを書いていきます。

---

Day 1: 最初のサイト ── coffee-explorer.net（WordPress）

所要時間: 約6時間

最初に手をつけたのは、コーヒーに関するメディアサイトでした。この時点ではまだAstroテンプレートっていう発想がなくて、「とりあえずWordPressで始めよう」と安易に考えました。これが後の大きな学びにつながります。

10:00 ── WordPressのセットアップ開始

エックスサーバーにWordPressをインストールして、テーマ選びからスタート。REST API（Webサービスとデータをやり取りする方法の一つ）を使って記事を自動投稿する仕組みを作りたかったので、認証まわりの調べ物に時間がかかりました。

WordPressの管理画面自体は使い慣れてるんですが、REST API経由でプログラムから操作するのは初めて。公式ドキュメントは英語だし、バージョンごとに仕様が微妙に違う。ここで最初の「想定外の時間消費」が発生しました。

12:00 ── REST API認証の壁

WordPress REST APIで記事を投稿するには認証が必要なんですが、Application Passwordsの設定がなかなかうまくいかない。Basic認証のフォーマット（user:application_passwordをBase64エンコード）に辿り着くまで1時間以上かかりました。

具体的に何が問題だったかというと、Application Passwordを生成したときに表示されるパスワード文字列にスペースが入ってるんです。このスペースを消すべきか残すべきかのドキュメントがあいまいで、結局「スペースを含めたまま使う」のが正解でした。

# WordPress REST API認証の正しい形式
curl -X POST https://coffee-explorer.net/wp-json/wp/v2/posts \
  -H "Authorization: Basic $(echo -n 'username:xxxx xxxx xxxx xxxx' | base64)" \
  -H "Content-Type: application/json" \
  -d '{"title":"テスト記事","content":"本文","status":"publish"}'

この認証が通った瞬間のホッとした感じは忘れられないです。でもこの時点ですでに2時間が経過していました。

14:00 ── テーマのCSS格闘

WordPressテーマのCSSカスタマイズに突入。ここで予想以上に時間を食いました。WordPressのテーマは便利なんですが、「ちょっとだけ変えたい」が意外と難しいんです。画像の配置、フォントサイズ、余白の調整…CSS直埋め込みで力技で解決していきました。

特に苦労したのが、テーマがもともと持っているCSSとの衝突です。!importantを連発する羽目になり、メンテナンスしにくい泥沼コードが生まれていく。「これは違うな」と薄々感じていましたが、この日はとにかく完成させることを優先しました。

画像の表示サイズが端末によってバラバラになる問題もありました。レスポンシブ対応（画面サイズに応じてレイアウトが変わること）がテーマ任せだと、意図しない崩れが起きます。max-width: 100%とheight: autoを指定して対処しましたが、こういう細かい対応の積み重ねが時間を奪っていきます。

18:00 ── 記事投入と画像問題

Claude Codeで記事を生成して、REST API経由で投入。ここで画像の問題にぶつかりました。記事に使う画像をどこから持ってくるか。Unsplashは汎用的な写真しかない。Wikimedia Commonsを試したら、ホットリンク（他のサイトの画像URLを直接借りて表示すること。多くのサイトでブロックされる）がブロックされることが判明。

サーバー側でWikimediaの画像をダウンロードしてWordPressのメディアライブラリにアップロードする仕組みも考えましたが、著作権表示の自動付与やライセンスの確認が複雑すぎて断念。結局Unsplashの画像で妥協しました。

Day 1の成果

• coffee-explorer.net 稼働開始
• 記事10本投入
• REST API経由での自動投稿の仕組み構築
• 所要時間: 約6時間（うちCSS格闘2時間、API認証1時間、画像問題1時間）

---

Day 2: Astroとの出会い ── trip-journal.net

所要時間: 約5時間

Day 1のWordPress体験をふまえて、Day 2ではAstroを選びました。Astro（Webサイトを作るための道具。表示が速いのが特徴）は静的サイトジェネレーターなので、Markdownで記事を書いてビルド（サイトのHTMLを生成する処理）するだけでOK。REST APIもCSSテーマも不要。コードの全てを自分でコントロールできます。

正直に言うと、AstroかNext.jsかで30分ほど迷いました。Next.jsのほうが情報量は多いんですが、ブログ・メディア系なら静的生成に特化したAstroのほうがシンプルだと判断。この判断は正解でした。

9:00 ── Astroプロジェクト初期化

npm create astro@latest trip-journal

ここから約1時間かけて、基本的なレイアウト、ヘッダー、フッター、記事一覧ページを作りました。Tailwind CSS（デザインをかんたんに当てられるCSSの道具）v4を導入して、CSS変数でサイトの色を管理する仕組みを作りました。

Astroのcontent collections機能が特に気に入りました。つまり、Markdownファイルをフォルダに置くだけで、記事データとして扱えるということ。WordPressのようにデータベースを経由する必要がないんです。

11:00 ── コンポーネント設計

旅行メディアとして必要なパーツを洗い出しました。この段階で「他のサイトでも使えるように汎用的に作ろう」と意識したのが、後のテンプレート使い回しにつながります。

ここで重要だったのが、site.tsという設計判断です。サイト名、色、ナビゲーション、カテゴリなど、サイトごとに違う情報を1つのファイルにまとめました。かんたんに言うと、「このファイルだけ書き換えれば別のサイトになる」という仕組みです。この設計が、翌日の3サイト爆速構築を可能にしました。

13:00 ── Google Maps Places API統合

旅行サイトには実際のお店の写真が不可欠。Google Maps Places API（Googleマップのお店情報を取得できるサービス）を導入して、ビルド時にお店の名前で検索して写真URLを取得し、HTMLに埋め込む仕組みを作りました。

API（ソフトウェア同士がデータをやり取りする窓口）呼び出しのコードはこんな感じです。ビルド時にだけ実行されるので、サイトを見ている人にAPIキー（サービスを使うための鍵のようなもの）が見えることはありません。

// ビルド時にGoogle Maps Places APIで写真を取得
const response = await fetch(
  `https://places.googleapis.com/v1/places:searchText`,
  {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'X-Goog-Api-Key': API_KEY,
      'X-Goog-FieldMask': 'places.photos,places.displayName',
    },
    body: JSON.stringify({ textQuery: spotName }),
  }
);

この仕組みが後の全サイトに活きる重要な判断になりました。Wikimediaで苦しんだ画像問題が、Google Maps APIで一気に解決したんです。

15:00 ── Cloudflare Pagesデプロイ

GitHub（Gitのデータを保存するクラウドサービス）にpushして、Cloudflare Pagesに接続。ここでWorkersとPagesの画面を間違えるという罠にハマります。Cloudflareのダッシュボードで「Create」を押すとWorkersの画面に飛ぶんですが、Pagesは別のリンクから入る必要があります。

正確には、Workers & Pagesのセクション内で「Pages」タブを選択して、そこから「Connect to Git」を選びます。この導線がわかりにくくて、最初は10分ほど迷いました。

デプロイ（作ったサイトをインターネット上に公開すること）の設定はこれだけです。Astro + Cloudflare Pagesの組み合わせは、びっくりするほどシンプルでした。

Framework preset: Astro
Build command: npm run build
Build output directory: dist
Node.js version: 20

17:00 ── ドメイン設定と記事投入

エックスサーバーで取得したドメインのネームサーバー（「このドメインはどこのサーバーを使ってるか」を教える設定）をCloudflareに変更。DNS（ドメイン名とサーバーの住所を紐づける電話帳のようなもの）の反映を待つ間に記事を書き続けました。

ドメインの取得コストは驚くほど安いです。エックスサーバーのキャンペーンで.netドメインが年間1円〜で取得できました。5ドメインでも数百円程度です。

Day 2の成果

• trip-journal.net 稼働開始
• 記事11本（国内6 + 海外5）
• Google Maps Places API統合
• Astroテンプレートのベース完成（site.tsアーキテクチャ確立）
• 所要時間: 約5時間

---

Day 3: テンプレートの威力 ── 3サイト一気に構築

所要時間: 約7時間（3サイト合計）

ここからが本番です。Day 2で作ったAstroテンプレートをコピーして使い回す作戦に切り替えました。朝8時に始めて、17時には3サイトすべてがCloudflare Pages上で動いていました。

8:00 ── vibe-code-lab.com（バイブコーディング入門）

まずtrip-journalのフォルダをまるごとコピー。site.tsを書き換えて、色をパープル+グリーンに変更。カテゴリを「入門」「ツール紹介」「実践」に作り直しました。

ここで最初の落とし穴：node_modulesをコピーすると壊れる。コピー直後にnpm run devを実行したら、エラーが大量に出ました。つまり、npm（プログラミングのパーツをインストールするための道具）でインストールしたファイルが、元のフォルダの場所を参照したままだったのが原因です。

# コピー後にやること（必須）
rm -rf node_modules
rm -f package-lock.json
npm install

もう一つの落とし穴は.gitフォルダです。Git（ファイルの変更履歴を管理する仕組み）の履歴がそのまま残ってしまいます。新しいサイトとして管理するなら、.gitも削除して最初からやり直す必要があります。

rm -rf .git
git init
git remote add origin https://github.com/ketyaso/new-site.git

トップページを旅行メディアから学習サイトに変更。カードグリッド型からロードマップ型のレイアウトに作り替えました。この部分だけはsite.tsでは対応できず、HTMLを手で書き換えました。記事15本を生成・投入。所要時間: 約2.5時間。

11:00 ── ai-cowork-lab.com（AI業務活用サイト）

2サイト目のコピーはさらに速かったです。テンプレートの切り替え手順が体に染みついてきました。

• カラー: ティール+アンバー
• カテゴリ: 「Claude Code」「業務活用」「実験ログ」
• 記事9本を生成

ここで「テンプレートの威力」を実感しました。site.tsの書き換えに10分、CSS変数の変更に5分、トップページの修正に30分。記事生成を除けば、サイトの骨格は1時間足らずで完成しました。

所要時間: 約2時間。

14:00 ── ceo-tax.com（経営者向け税金サイト）

3サイト目。もう手順は完全にルーティン化されています。

1. フォルダをコピー
2. rm -rf node_modules .git && npm install && git init
3. site.tsのname, colors, nav, categories, footerを書き換え
4. src/styles/global.cssのCSS変数を変更
5. トップページのヒーローセクションを修正
6. 記事を生成・配置
7. GitHubにpush → Cloudflare Pagesに接続

カラーはブルー+レッド。税金・節税・経理の3カテゴリ。記事15本。所要時間: 約2時間。

税金サイトでは、カテゴリの表示パターンを「グリッド」に設定しました。学習サイトのような順序性はなくて、読者が気になるトピックから読む性質のコンテンツだからです。こういった「サイトの性質に応じた表示切り替え」がsite.tsのlayout: "grid" | "steps"でかんたんに実現できるのは、設計が正解だったなと感じました。

17:00 ── 全サイトのCloudflare Pages設定

3サイトのCloudflare Pages設定を一気にやりました。2サイト目以降は手順を覚えているので、1サイトあたり5分程度で完了。

ただし、ネームサーバーの設定には注意が必要でした。Cloudflareはドメインごとに異なるネームサーバーを割り当てます。つまり、同じアカウントでも、ドメインが違えばネームサーバーも違うということです。最初の2ドメインの情報を使い回そうとして失敗しました（詳しくは後述の「失敗の記録」を見てください）。

Day 3の成果

• vibe-code-lab.com 稼働開始（記事15本）
• ai-cowork-lab.com 稼働開始（記事9本）
• ceo-tax.com 稼働開始（記事15本）
• 所要時間: 合計約7時間（3サイト）

---

5サイトの全体像

---

コスト内訳 ── 5サイトで月額$25以下

「5サイトも運用して、いくらかかるの？」という疑問に、正直に答えます。結論から言うと、月額$25程度で5サイトを運用できています。

この低コスト構造が成り立つ理由は3つあります。Cloudflare Pagesの無料枠が強力なこと、AstroのSSG（サイトを事前にHTMLファイルとして作っておく方式。表示が速い）でサーバー不要なこと、そしてClaude Codeが記事生成とコーディングの両方を担えることです。

---

失敗の記録 ── 正直に書く

成功体験だけ書いても参考にならないですよね。ここでは実際にハマったポイントを、原因と対処法とともに正直に書きます。

失敗1: Wikimedia Commonsの画像ブロック（403エラー）

旅行記事でWikimedia Commonsの画像をホットリンクで使おうとしたら、リファラーチェック（どのサイトから画像を見に来たか確認する仕組み）でブロックされました。ブラウザで直接開けば表示されるのに、自分のサイトに埋め込むと403エラー（アクセス拒否）が返ってきます。

調べてみると、Wikimedia側がホットリンクを制限していることがわかりました。画像をダウンロードして自分のサーバーに保存する方法もありますが、ライセンス表記の自動化が面倒です。

対処法としてGoogle Maps Places APIに切り替えましたが、最初の数時間は「なぜ画像が表示されないのか」の原因調査に時間を使ってしまいました。

失敗2: Cloudflareネームサーバーの混乱

Cloudflareのネームサーバーはドメインごとにランダムに割り当てられるんです。最初のドメインではaliza.ns.cloudflare.comとduke.ns.cloudflare.comだったのに、次のドメインではemily.ns.cloudflare.comとuriah.ns.cloudflare.comに。

「同じアカウントなんだから、同じネームサーバーだろう」と思い込んで最初の値を全ドメインにコピペしたら、DNS解決ができない。かんたんに言うと、「住所の登録を間違えたから、手紙が届かない」みたいな状態です。

失敗3: DNS反映待ちの焦り

ネームサーバー変更後、DNSの反映には数分〜数時間かかります。最初は「設定を間違えたのでは」と焦って何度も設定を変更してしまいました。変更するたびにカウントがリセットされて、反映がさらに遅くなるという悪循環。

実際には一度正しく設定したら、触らずに待つだけでよかったんです。反映状況を確認する癖をつけたのは、この失敗以降です。

# DNS反映状況の確認
dig trip-journal.net NS +short

失敗4: node_modulesのコピー問題

Astroテンプレートをフォルダごとコピーした際、node_modulesもそのままコピーしてしまいました。一見動くように見えるんですが、パスの不整合でビルドが不安定になります。

具体的な症状としては、開発サーバーは起動するけど、特定のパーツの読み込みに失敗したり、変更が自動反映されなかったりします。コピー後は必ずnode_modulesを削除してnpm installし直すのが正解です。

失敗5: Google Maps APIキーのウェブサイト制限

Google Cloud Consoleで「ウェブサイト制限」を設定したら、CloudflareのビルドサーバーからのAPI呼び出しがブロックされました。Astroはビルド時にサーバー側からAPIを呼ぶので、ウェブサイト制限（どのサイトからアクセスしたかのチェック）は機能しないんです。

正しくはAPI制限（Places APIのみ許可）にするのが正解。つまり、「誰が呼ぶか」ではなく「何を呼ぶか」で制限をかける、ということです。

---

速さの鍵 ── なぜ後半が爆速だったのか

1号機から2号機で所要時間が半分になっています。テンプレートのコピーだけが理由じゃないです。

加速した5つの理由

1. site.ts設計: サイトごとに違う情報を1ファイルにまとめたことで、「何を変えればいいか」が明確に。迷う時間がゼロになりました
2. パーツの再利用: Callout、Card、CategorySectionなどのパーツがそのまま使える。新しく作るものがゼロ
3. Cloudflare Pages設定の慣れ: 2回目以降は5分で完了。最初は30分かかった作業が6分の1に
4. 記事生成の効率化: Claude Codeにカテゴリとテーマを伝えるだけで、正しいフォーマットの記事が出てくる
5. 失敗経験の蓄積: 「node_modulesは削除する」「ネームサーバーはドメインごとに違う」「.gitは削除する」など、同じ間違いを繰り返さない

特に大きかったのは1と5です。site.tsの設計で「直すべき場所を探す手間」がなくなり、失敗経験で「同じ穴に二度落ちない」状態になりました。3サイト目以降は「考える」というより「流れ作業」に近い感覚でした。

---

6つの学び

学び1: テンプレートは「最初の1つ」に全力を注ぐ

最初のAstroサイト（trip-journal）に時間をかけて作り込んだことが、後の3サイトの爆速構築に直結しました。テンプレートの設計で手を抜くと、コピーのたびに修正が発生して結局遅くなります。

つまり、「今のサイトだけ動けばいい」じゃなくて、「別のサイトにコピーしても動くか？」と常に考えながら作ることが大事ということです。

学び2: site.tsアーキテクチャは正解だった

サイト名、色、ナビゲーション、カテゴリ、フッター情報をsite.ts1ファイルにまとめる設計は、複数サイト運用でものすごく効果がありました。新しいサイトを作るとき、このファイルだけ書き換えれば別サイトになります。

逆に言えば、site.tsに入れ忘れた項目（例：トップページの文言）は手動で書き換える必要がありました。「もれなくsite.tsに入れる」ことの大事さを痛感しました。

学び3: 画像ソースは事前に決めておく

Wikimediaのブロック、食べログの著作権、Unsplashの汎用性問題…画像の調達先の調査に予想以上の時間がかかりました。先に画像をどこから持ってくるか決めてから記事を作るのが正しい順番です。後から変更すると、全記事を直す羽目になります。

学び4: 静的サイトのコスト優位性がすごい

WordPress（月額$9のサーバー代）に対して、Astro + Cloudflare Pagesは完全無料。5サイトが全部Astroなら、ホスティング費用ゼロで運用できます。サーバー管理の手間もゼロ。セキュリティパッチの心配もゼロ。かんたんに言うと、静的サイトは「何もしなくていい」のが最大のメリットです。

学び5: Claude Codeとの分業が確立する

3サイト目あたりから、人間とAIの役割分担パターンが固まりました。人間が「このサイトの目的はこう、カテゴリはこう、色はこう」と方針を決めて、Claude Codeがsite.tsの修正、記事生成、パーツの調整を担当します。

ポイントは「方針決定は人間がやる」こと。AIに「どんなサイトを作るべきか」を聞いても、ふわっとした答えしか返ってきません。「税金サイトを作る。ターゲットは経営者。色はブルー+レッド」という具体的な指示を出すのは、人間の仕事です。

学び6: コピー運用の限界を知っておく

テンプレートのコピーは速いですが、片方で直した修正がもう片方には反映されないのが弱点です。たとえばCallout.astroのバグを直したら、4サイト全部に同じ修正をコピーする必要があります。4サイト程度なら手動でいけますが、10サイトになったらモノレポ化（複数のプロジェクトを1つのフォルダで管理する方法）が必要になります。

今はコピーで十分ですが、限界が見えている。この「限界を知った上で、今はシンプルな方法を選ぶ」という判断が大事だと思っています。

---

最終統計

18時間で5サイト。1サイトあたり平均3.6時間。ただし、テンプレートが固まった3サイト目以降は平均2.2時間です。テンプレート設計への最初の投資が、その後の全てを加速させました。

70本以上の記事は、すべてClaude Codeで生成しました。人間がやったのは、方針決定、品質チェック、そして公開判断です。「AIで記事を量産した」のではなく、「AIと分業して効率的にメディアを構築した」というのが正確な表現だと思っています。

---

次にやるなら

もしこれを読んで「自分もやってみたい」と思った方へ。自分がもう一度ゼロからやるなら、こうします：

1. 最初からAstroを選ぶ（WordPressは使わない。静的サイトで十分なら、WordPressはオーバースペック）
2. site.tsの設計に1時間かける（ここが全サイトの品質を決めます。丁寧に作りましょう）
3. 画像はUnsplash + Google Maps APIの2本立てで決めてから始める（Wikimediaは使わない）
4. Cloudflare Pagesのアカウント設定を先にやる（DNS反映を待つ時間を有効活用できます）
5. 1サイト目を完成させてから2サイト目に着手する（中途半端な状態でコピーすると、バグまでコピーされます）
6. node_modulesと.gitは必ず削除してからコピーする（これを忘れると確実にハマります）

テンプレートが完成すれば、2サイト目以降は本当に2時間で立ち上がります。これは誇張じゃなくて、実際の経験にもとづく数字です。「3日で5サイト」は再現可能な方法だと確信しています。