Claude Code だけで本番Webサービスを作った話 — 36時間・2.6億トークンの全記録
TL;DR（要約）
- Claude Code（Anthropic の CLI ツール）を使い、自然言語の会話だけで本番稼働するWebサービスを構築した
- 開発期間17日間、実作業時間36時間、39セッション、消費トークン約2.6億
- React SPA + FastAPI + PostgreSQL + データ収集パイプライン + SEO + デプロイシステムまで一気通貫
- 成果物: CS Book Radar — 技術書籍の客観的ランキングサイト（https://rankcraft.jp/cs-books ）
- ソースコード: https://github.com/yu-hanabusa/csbookradar
何を作ったのか
CS Book Radar は、Qiita・Zenn・Dev.to・Stack Overflow・GitHub の5つの技術コミュニティから「どの技術書が実際に言及・引用されているか」を毎日自動収集し、客観的なスコアで書籍をランキングするサービスです。
「おすすめ本」の記事はたくさんありますが、どれも個人の主観です。CS Book Radar はコミュニティ全体の集合知をデータとして集め、Evidence-first（エビデンス重視）のスコアリングで順位を決めています。
技術スタック
[ブラウザ] → [Nginx (443)] → [FastAPI (8000)] → [PostgreSQL]
↓
[static/index.html] ← React SPA (Babel in-browser変換)
| レイヤー | 技術 | 特徴 |
|---|---|---|
| フロントエンド | React 19 + Babel | HTMLファイル1つに完結（ビルドステップなし） |
| API | Python FastAPI | main.pyファイル1つに完結 |
| DB | PostgreSQL 16 | 書籍・記事・プロジェクト・PV・クリック追跡 |
| データ収集 | Python | 5プラットフォーム、1日1回自動実行 |
| SEO | Python (Pillow) | sitemap.xml、JSON-LD、書籍別OGP画像 |
| デプロイ | Python | MD5チェックサムで差分転送 |
| インフラ | Ubuntu VPS + Nginx | SSL + systemd + cron |
なぜ Claude Code を使ったのか
正直に言うと、自分で全部書けるスキルはあるが、「本業の片手間で実用的なサービスを高速に立ち上げたかった」というのが本音です。
Claude Code の強みは「会話するだけでコードが出てくる」ことではなく、設計判断を一緒に考えてくれる対話型の開発パートナーであることです。
例えば:
- 「スコアリングどうしよう」→ Evidence-first 方式を提案してくれた
- 「SEOの現状分析して」→ 20項目以上の監査レポートが返ってきた
- 「この設計おかしくない？」→ ナビゲーション構造の問題を指摘してくれた
開発の全記録
統計データ
| 指標 | 値 |
|---|---|
| 開発期間 | 17日間（2026/2/25 〜 3/13） |
| 稼働日数 | 10日 |
| Claude Code セッション数 | 39回 |
| 実作業時間 | 約36時間 |
| ユーザーメッセージ数 | 2,388 |
| ツール使用回数 | 2,066 |
| 消費トークン | 約2.6億（出力: 93万、キャッシュ読取: 2.5億） |
| API換算コスト | 約＄656（Max サブスクで月額＄100〜＄200） |
| 使用モデル | Claude Opus 4.6（90%）+ Sonnet 4.6 |
| コミット数 | 12 |
| コアコード行数 | 約6,100行 |
日別の開発フロー
| 日付 | セッション | 主な作業 |
|---|---|---|
| 2/25-26 | 9 | プロジェクト設計、DB設計、初期コミット |
| 2/28 | 11 | 最大稼働日: データ収集パイプライン、SPA化、SVGロゴ、5コミット |
| 3/1 | 6 | スコアリング調整、マッチング精度改善 |
| 3/7 | 1 | GitHub を第5収集プラットフォームとして追加（11時間の長セッション） |
| 3/8-9 | 5 | SEO強化（日本語URL化、リンク抽出パターン拡張） |
| 3/11 | 3 | SEO総合監査 → 回遊動線改善、OGP画像生成、構造化データ |
| 3/13 | 2 | GitHub公開準備（セキュリティ監査、機密情報除去） |
実際の開発で学んだこと
1. 「全部任せる」より「一緒に考える」が正解
最初は「データ収集パイプライン作って」のように丸投げしていましたが、途中から設計の意思決定は自分が行い、実装をClaudeに任せるスタイルに切り替えました。
# 良くないプロンプト
「書籍ランキングサイトを作って」
# 効果的だったプロンプト
「Qiita の記事本文から Amazon リンクの ASIN を抽出したい。
正規表現で /dp/B0XXXXX パターンと ISBN-13 を両方拾いたい。
既存の collect.py の extract_books() に追加する形で」
具体的なファイル名・関数名・やりたいことを明示すると、Claudeの出力精度が劇的に上がります。
2. セッション管理が重要
Claude Code はセッションごとにコンテキストがリセットされます。長いセッションで複雑な機能を実装すると、途中でコンテキストが圧縮されて「さっき話したこと」を忘れることがあります。
対策として:
- CLAUDE.md にプロジェクトのルールを書く → 毎セッション自動的に読み込まれる
- 1機能1セッションを意識する → コンテキストの無駄遣いを防ぐ
- Skills（スラッシュコマンド）を定義する → 繰り返し作業を標準化
# CLAUDE.md の例（抜粋）
## 開発ルール
- フロントエンドは index.html 1ファイル完結（React + Babel in-browser）
- APIは main.py 1ファイル（FastAPI）
- DB操作は必ずパラメータ化クエリ（$1, $2...）
3. コードレビューは自分でやる
Claude Code が書いたコードはそのまま使える品質であることが多いですが、以下は自分の目で確認すべきです:
- セキュリティ: SQLインジェクション、XSS、認証の穴
- API利用規約: レート制限の遵守、利用許可の確認
- ビジネスロジック: スコアリングの重みが意図通りか
実際、GitHub公開前のセキュリティ監査では Claude 自身に「全ファイルのIPアドレスとトークンを探して」と依頼し、20以上のファイルからハードコードされたVPS IPアドレスを発見・修正しました。AIに書かせたコードをAIに監査させるのは有効なアプローチです。
4. 「単一ファイル設計」はトレードオフがある
index.html（2,000行超）や api/main.py を1ファイルに集約する設計を採用しました。Claude が1ファイルで全体を把握できるため初速は出ますが、1,000行を超えると Edit ツールの文字列マッチ失敗が増え、開発効率が落ちます。
Claude Code はファイル横断の検索・編集も十分にこなせるので、AIの都合でアーキテクチャを歪める必要はありません。
5. バイブコーディングのコスト感
17日間の開発で消費したトークンは約2.6億、API換算で約＄656相当です。ただし、Claude Code Max サブスクリプション（月額＄100）を使っているため、実際の支払いはサブスク料金のみです。
＄200/月で「設計もできるシニアエンジニアがペアプロしてくれる」 と考えると、個人開発においてはかなりコスパが良いと感じました。
つまずいたポイント
スコアリングの試行錯誤
最初は「いいね数 × 重み」でスコアを計算していましたが、人気記事で1回だけ触れられた本がトップに来る問題がありました。最終的にAmazon/ISBNリンクを含む記事の数を最重要シグナルにする Evidence-first 方式に落ち着きました。
evidence = link_article_count × 10.0 # リンク記事数（最重要）
+ project_count × 5.0 # GitHubプロジェクト数
「リンクを貼る = 読者に推薦している」という仮説が、実際のランキング結果を見ても妥当でした。
SEO の奥深さ
Claude に SEO 監査を依頼したところ、20項目以上の改善点が出てきました。特に大きかったのは:
- 空のページが低品質と判定されるリスク → レベル別ページを削除
- 書籍別OGP画像がない → Pillow で1200x630pxの画像を自動生成
- 構造化データの不備 → Book スキーマに datePublished と offers を追加
SEO は「やれば終わり」ではなく、継続的な改善が必要だと実感しました。
今後のリファクタリング計画
前述の通り、単一ファイル設計は初速の開発には有効でしたが、運用フェーズでは限界が見えてきました。今後は以下の方針で段階的にリファクタリングしていきます。
フロントエンド: index.html → コンポーネント分割 + Vite
現在2,000行超の index.html を、Reactコンポーネント単位の .jsx ファイルに分割し、Vite でバンドルする構成に移行します。
# Before
static/index.html (2,000行、全コンポーネント + CSS + ルーティング)
# After
src/
App.jsx
pages/
HomePage.jsx
GenreTopPage.jsx
CategoryPage.jsx
BookDetailPage.jsx
components/
BookCard.jsx
CategoryCard.jsx
...
これにより、コンポーネント単位での修正・テストが容易になり、Claude Code の Edit ツールが「該当箇所が見つからない」で失敗する問題も解消されます。
API: main.py → FastAPI Router 分割
api/main.py も機能ごとに Router モジュールに分割します。
# Before
api/main.py (全エンドポイント)
# After
api/
main.py (アプリ初期化 + ミドルウェア)
routers/
rankings.py (GET /api/rankings, /api/books/*)
tracking.py (POST /api/track/*)
admin.py (GET /api/stats, /api/system)
いずれもClaude Code で実行するリファクタリングを想定しています。分割作業自体はAIが得意とする領域です。
まとめ
Claude Code を使った17日間の開発で、実際に本番稼働するWebサービスを1人で構築できました。
Claude Code が得意なこと
- 定型的なCRUDやAPI実装
- CSS/UIの調整
- 既存コードのリファクタリング
- SEO監査や技術的な分析
- セキュリティ監査
人間がやるべきこと
- プロダクトの方向性・何を作るかの判断
- スコアリングロジックなどのビジネスルール設計
- API利用規約の確認と倫理的判断
- 最終的なコードレビューとセキュリティ確認
- デプロイ後の運用判断
バイブコーディングは「コードを書かなくていい」のではなく、「より高いレベルの意思決定に集中できる」 手法だと思います。
興味があればぜひコードを覗いてみてください:
この記事は Claude Code (Claude Opus 4.6) との会話を基に、著者が執筆・編集しました。