このWebサイトをClaude Codeで作った記録|AI前提の開発で、人は何を決めたのか

「AIでWebサイトを作ると、人は何をすることになるのか」が気になっている方に向けた記事です。結論から言うと、当社のこのWebサイトでは、コードはすべてClaude Codeが書き、人は載せる内容、公開してよいかの判断、社外に影響が出る決定を担いました。この記事では、何を作ったのか、人とAIがどう分担したのか、人が判断しなければならなかったこと、そしてサイトの仕組みとデザインの組み立て方を記録します。

何を、どのくらいの期間で作ったのか

リポジトリを作った2026年11月4日から6日までの3日間で、次のものを作りました。ただし、ページの構成を決めたワイヤーフレーム(11ページ分)と、色や文字の基になった会社紹介資料のデザインは、その前から用意していました。

項目	数
出力したページ	96ページ
本番に出した変更(マージしたPR)	23件
旧サイト(WordPress)から移した記事	61本
旧サイトから同じURLのまま移した固定ページ	11ページ
旧URLから新URLへの転送ルール	309件

数字は、2026年11月6日時点のリポジトリから数えています。

作った機能は、ページそのもののほかに、次のとおりです。

• お問い合わせフォーム(ロボットによる送信の防止、自動返信メール)
• 変更ごとのプレビューサイトと、本番への自動デプロイ
• 旧サイトの記事と画像の書き出し、新サイト用の原稿への変換、旧URLからの転送
• お客様向けWindowsアプリの更新ファイルの配信(旧サイトと同じURLのまま)
• アクセス解析の計測タグ、検索エンジンとAI検索向けの構造化データ

人とAIは、どう分担したのか

人は「何を、どう載せるか」と「出してよいか」を決め、AIはその決定を実装し、確かめるところまでを担いました。

工程	人が担ったこと	Claude Codeが担ったこと
方針	載せる情報と載せない情報を決める(単価を出さない、メンバーは名字のみ、など)	決めた方針をページの構成とデータに落とす
原稿	ページの文章案を確かめ、直す	文章案をページに反映する。記事の下書きを作る
実装	実装の方針を確かめる	コードを書く。旧サイトの移行スクリプトを書く
確認	プレビューサイトで画面を見て、直す点を伝える	型のチェックとビルドを通す。スクリーンショットで見た目を確かめる
公開	本番に出すか(マージするか)を決める	マージ後のデプロイ、タグとリリースの作成を自動で行う

コードを人が手で書いた箇所はありません。サイトの画像の一部は、別のAIであるCodexで作っています。

どのように進めたのか

1つの変更ごとに、次の流れを繰り返しました。

1. 人が頼む:「旧サイトの記事を移したい」「この住所が正しい」のように、やりたいことや決めたことを伝える
2. Claude Codeが変更を作る:作業用のブランチでコードを書き、ビルドが通ることを確かめて、PR(変更の提案)を出す
3. プレビューサイトで確かめる:PRごとに、本番と同じ構成の確認用URLが自動で作られる
4. 人がマージを決める:マージすると、本番へのデプロイと、日付と連番のタグ付けが自動で行われる

この流れのおかげで、人は「変更の中身」と「出してよいか」だけを見れば済みました。

人が判断しなければならなかったことは何か

社外の人や仕組みに影響が出ることは、AIが作業を進めていても、人が決める必要がありました。この3日間にあった例です。

• URLを変えないこと:旧サイトの記事のURLは、検索結果や外部のリンクに残っています。お客様向けアプリの更新ファイルの配信URLは、インストール済みのアプリが持っています。どちらも、旧URLのまま使えるようにすると決めました
• 会社の住所の表記:作業の途中で、会社概要とプライバシーポリシーで住所が違っていることが見つかりました。どちらが正しいかは、人にしか分かりません
• プライバシーポリシーへの追記:アクセス解析を入れるにあたり、Cookieと解析ツールの利用について追記しました。プライバシーマークの規程との整合を確かめるのは人の役割です
• 計測の範囲:アクセス解析のタグは、本番のサイトでだけ読み込むようにしました。プレビューサイトでの確認が、計測に混ざらないようにするためです

どれも、コードとしては数行の変更です。ただ、間違えたときに困る人がいる決定でした。

このサイトは、どんな仕組みで動いているのか

Markdownで書いた原稿をAstroが静的なHTMLにし、GitHub ActionsがCloudflare Workersへ自動で出しています。サーバー側でプログラムが動くのは、お問い合わせの受付と、アプリの更新ファイルの配信だけです。

図をクリックすると、原寸で開きます。

• 原稿(Markdown、Astroの部品):記事と実績は、Markdownのファイル1つが1ページになる。会社の数字や社名は1つのファイルにまとめる
• ビルド(Astro):原稿から、全ページのHTMLとサイトマップを作る
• 自動化(GitHub Actions):PRを出すと確認用URLを作り、マージすると本番に出してタグを付ける
• 配信(Cloudflare Workers):HTML・CSS・画像をそのまま返し、決まったパスだけWorkerのプログラムで処理する
• 周辺(Cloudflare R2、Turnstile、Resend):アプリの更新ファイルの置き場、フォームのロボット対策、メールの送信

ページを表示するたびに動くサーバーやデータベースはありません。そのため、壊れる場所が少なく、表示も速くなります。

公開前の変更は、どうやって確かめたのか

PRを出すたびに、そのPR専用の確認用URLが自動で作られます。人はそのURLを開き、本番と同じ見た目と動きで確かめてから、マージするかを決めました。

1. PRを出す、または更新する:GitHub Actionsが型チェックとビルドを行い、Cloudflare Workersに「プレビュー版」として配置する。本番のサイトには影響しない
2. PRにURLが書き込まれる:pr-<PRの番号> で始まる確認用URLが、PRのコメントに自動で載る。PRを更新すると、同じURLの中身が新しくなる
3. 人が確かめる:パソコンでもスマートフォンでも、URLを開くだけで確かめられる。文章の確認だけをする人も、開発の環境を用意する必要がない
4. PRを閉じると片付く:PRを閉じる(マージを含む)と、確認用URLの中身が「このプレビューは終了しました」というページに差し替わる

確認用URLは、本番と同じCloudflare Workersの上で動きます。お問い合わせの送信やWorkerの処理も含めて、本番に近い状態で確かめられるのが利点です。最初の土台を入れたあと、本番に出した変更はすべてこの流れを通しています。

Astroでは何を工夫したのか

原稿の書き間違いを機械で見つけられることと、同じことを1か所に書くことを重視しました。

• 原稿の項目を型で決める:記事や実績のMarkdownの先頭に書く項目(タイトル、カテゴリ、柱テーマ、よくある質問など)を、Astroのコンテンツコレクションで型として定義しています。書き間違いは npm run check で見つかり、PRを出したときの自動チェックでも失敗として表示されます
• 会社の情報は1か所に書く:社名、所在地、社員数、プライバシーマークの登録番号などは、1つのファイルにまとめ、全ページがそこを参照します。作業の途中で住所の表記の違いが見つかったときも、直す場所は1か所でした
• 旧サイトの固定ページを同じURLで出す:アプリのプライバシーポリシーなど、外部から同じURLで参照されているページは、HTMLのまま取り込み、元と同じURLで表示しています
• 画像は自動で最適化する:写真は、表示する幅に合わせて複数の大きさのWebP形式に自動で変換し、画面に合ったものが読み込まれるようにしています
• JavaScriptは必要な所だけ:Astroは標準でJavaScriptを送らない作りです。使っているのは、メニューの開閉、一覧の絞り込み、お問い合わせフォーム、計測タグなどに限られます
• 検索とAI検索向けの情報を自動で出す:サイトマップと、会社・記事・よくある質問の構造化データを、ビルドのたびに自動で作っています

デザインは、どう組み立てたのか

会社紹介資料のデザインを起点に、色・文字・余白を「デザイントークン」として1つのCSSファイルにまとめ、すべての部品がそれだけを参照する作りにしました。

• 起点は会社紹介資料:生成りの地、紺、琥珀の3色と、見出しの明朝体(Shippori Mincho)を、資料からそのまま引き継いでいます
• 決まりごともトークンに書く:強調の琥珀色は1画面に1か所まで、補足の文字は背景とのコントラストを6:1以上、余白は4pxの倍数、といった決まりを、定義のすぐ横に書いています
• 部品を組み合わせてページを作る:冒頭、見出し付きの区切り、カード、手順、よくある質問、表、問い合わせへの誘導など、18個の部品を作り、各ページはその組み合わせでできています。CSSのフレームワークは使わず、部品ごとに閉じたCSSを書いています
• 日本語の見出しを文節で改行する:見出しが語の途中で改行されないよう、文節単位で改行し、行の長さをそろえる指定を入れています
• 画像も同じ決まりで作る:SNS用の画像、記事のアイキャッチ、この記事の構成図も、同じ色と文字で、プログラムから書き出しています

色や余白の決まりが1か所に文書としてあると、AIも毎回同じ見た目でページを作れます。人の頭の中にある「なんとなくの統一感」は、AIには守れません。決まりを先に文書にしておくことは、デザインでも、コードの規約やテストの方針と同じ役割を果たしました。

実際にやってみて、どうだったか

AIに任せて特に速く進んだのは、量が多く、手順が決まっている作業でした。旧サイトの記事61本の移行と309件の転送ルールは、書き出しと変換のスクリプトを書き、何度実行しても同じ結果になる形で作っています。

一方で、作業の速さが上がるほど、「何を決めればよいか」を人が先に持っている必要がありました。決まっていないことは、AIは尋ねるか、仮に置いて先に進みます。仮に置かれたものを見つけて決め直すのも、人の仕事です。

当社がお客様の案件で行っているAI前提の開発も、同じ分担です。進め方はAI開発のページで、開発チームへの入れ方は「開発チームにAIを入れる手順」で説明しています。

まとめ

• このサイトは、コードをすべてClaude Codeが書き、リポジトリを作ってから3日間で96ページまで作った
• 人は、載せる内容、出してよいかの判断、社外に影響が出る決定を担った
• 作業が速くなるほど、何を決めればよいかを人が先に持っていることが大切になる

自社の開発チームでも同じ進め方を試したい方は、お問い合わせからご相談ください。