Claude Codeで190個のWebツールを一人で作った話 — AIコーディング実戦記録
66日間・527コミット・14万行。AIコーディングツールだけを頼りに、一人で190個のブラウザツールサイトを構築した全記録。何がうまくいき、何が失敗したか。
#Claude Code#AIコーディング#一人開発#Cursor#Webツール#開発効率#AI実戦#ブラウザツール
66日間・527コミット・14万行。AIコーディングツールだけを頼りに、一人で190個のブラウザツールサイトを構築した全記録。何がうまくいき、何が失敗したか。
これが ainew.jp の現時点でのスペックだ。
PDF結合、画像圧縮、動画変換、為替計算、JSON整形、QRコード生成… ジャンルの異なる190個のツールが、すべてブラウザ内で動く。ファイルはサーバーに一切アップロードされない。
この規模のプロダクトを、一人で、66日で作れたのはなぜか。答えは単純だ。AIコーディングツールがなければ、絶対に不可能だった。
この記事は「Claude Codeの使い方ガイド」ではない。AIコーディングツールを実際のプロダクト開発に毎日使い続けた人間の、生の記録だ。うまくいったことも、失敗したことも、全部書く。
正直に見積もると：
| 項目 | AI無し（1人） | AI有り（実績） |
|---|---|---|
| ツール1個の平均開発時間 | 4〜8時間 | 30分〜2時間 |
| 190個の総開発時間 | 760〜1520時間 | 約200時間 |
| 必要期間（週40h） | 5〜10ヶ月 | 66日 |
| 必要チーム規模 | 3〜5人 | 1人 |
AIなしで同じものを作ろうとしたら、3人チームで半年。一人なら1年以上かかる。
最も時間が圧縮されたのは「似たパターンの繰り返し」だ。画像系ツールは基本構造が同じで、処理ロジックだけ異なる。AIはこのパターン認識が異常に速い。1個目を丁寧に作れば、2個目以降は「これと同じ構造で、処理だけ変えて」で動くものが出てくる。
逆に、圧縮されなかったのは「設計判断」と「デバッグ」だ。これは後で詳しく書く。
教科書的なスタック紹介はしない。「なぜこれを選んだか」だけ書く。
Vercelにしなかった理由は単純で、190ページの静的生成＋API＋Cron＋D1データベースを月額0円で動かしたかったから。Cloudflare Workersの無料枠は驚くほど太い。カスタムWorkerでAPIルートを書き、OpenNextでSSRを動かし、D1（SQLite）でニュースとユーザーデータを管理している。
ビルドパイプライン:
opennextjs-cloudflare build → custom-worker.ts → /api/* は worker-api.ts、それ以外は OpenNext SSR
UIライブラリ（shadcn、MUI等）を使わなかった理由。190個のツールページで微妙にレイアウトが違う。UIライブラリのコンポーネントに収まらないケースが多すぎて、結局上書きCSSだらけになる。Tailwindならユーティリティクラスの組み合わせで済む。
ダークモードはCSS変数オーバーライド方式を採用した。@theme inlineで--color-neutral-*をマッピングすると、text-neutral-900が自動でダークモード対応する。dark:バリアントをほぼ書かなくて済んだのは大きかった。
5つのツールでTransformers.js（WebGPU加速）を使っている。画像のAI処理、テキスト書き換え、翻訳など。
正直に言うと、ブラウザ内AIの体験はまだ荒い。モデルのダウンロードに時間がかかる（初回数百MB）、WebGPU非対応ブラウザでフォールバックが必要、メモリ管理が難しい。でも「ファイルをサーバーに送らずにAI処理できる」という価値は本物だ。
12個のツールで使用。動画圧縮、トリミング、フォーマット変換、音声抽出など。COOP/COEPヘッダーの設定が地味に面倒だった（next.config.tsで設定）。
開発時間の80%以上はClaude Codeと過ごした。
最も強い場面：
page.tsx（メタデータ＋SEO＋FAQ）とtool.tsx（実装ロジック）の2ファイルが出てくる。ToolPageLayout、UnifiedFileUploader、Buttonコンポーネントの使い方も既存コードから学習してくれる。bg-whiteとbg-gray-*をCSS変数に置き換えてくれた。手動でやっていたら1週間。最も弱い場面：
Claude Codeがプロジェクト全体を見ながらの大きな作業に向いているのに対して、Cursorは「このファイルのこの関数だけ直したい」という局所的な作業に使った。
使い分けの基準は単純：
compound-interest（複利計算ツール）を例にとる。
09:00 Claude Codeに指示:
「金融カテゴリで複利計算ツールを作って。
元本・年利率・期間のスライダー入力、
グラフ表示、結果テーブルをつけて」
09:15 page.tsx + tool.tsx が生成される
→ FAQ、メタデータ、ToolPageLayout は既存パターンから自動生成
09:20 tool.tsx のロジックを確認
→ 計算ロジックは正確。UIは基本的に動く
09:30 微調整開始（ここからが手動作業）
→ スライダーのステップ値を調整
→ グラフの色をサイト全体のテーマに合わせる
→ モバイルでの表示崩れを修正
10:00 完了。tools.tsに定義を追加してlint通過
合計: 約1時間（AIが作った部分: 15分、人間の調整: 45分）
この「AI 15分 + 人間 45分」のバランスは、ほとんどのツールで共通だった。AIは70%を15分で作る。残りの30%に人間の45分がかかる。
最もよくあるパターン：APIの引数順序を間違える。特にPDF.jsやFFmpeg.wasmのような複雑なライブラリで、引数の型は合っているが順序が逆、というバグを何度も仕込まれた。
コンパイルは通る。型チェックも通る。でも実行時に結果がおかしい。
教訓： AIが生成した外部ライブラリの呼び出しコードは、必ず公式ドキュメントと突き合わせる。TypeScriptの型チェックだけでは引数順序の間違いは検出できない。
AIが書いたコードのバグを、AIに直させようとすると、元の意図がわからないまま場当たり的に修正することがある。自分で書いたコードなら「ああ、ここの状態管理がおかしいな」と直感でわかるが、AIが書いた200行のuseEffect群を追いかけるのは、他人のコードをデバッグするのと同じ難しさがある。
結局、AIが書いたコードでも自分が理解してからmergeするのが一番効率がいい。理解せずに進むと、後でバグが出たとき倍の時間がかかる。
190個のツールを作る過程で、AIは既存ツールをベースに新しいツールを生成する。これ自体は効率的だが、コピー元の問題がそのまま伝播する。
例えば、初期に作ったツールでuseStateを8個以上使う癖があった。AIはそのパターンを「正しいやり方」として学習し、以降のツールでも同じパターンを踏襲した。結果として、状態管理が複雑すぎるツールが大量にできた。
教訓： 早い段階で「標準パターン」を確立して、AIにはそれを参照させる。最初のツールの品質がすべてのツールの品質を決める。
AIに「かっこいいデザインにして」と言っても、出てくるのは「正しいけど退屈なUI」だ。余白の取り方、色のバランス、タイポグラフィの選択… こうした「正解がない判断」は人間がやるしかない。
実際、開発時間の30%以上をUI調整に使った。コードが動くようになった後の「見た目を良くする」作業が、一番AIに頼れない部分だった。
| アプリ | コード行数 | 用途 |
|---|---|---|
| tools | 131,429行 | 190個のWebツール（メインプロダクト） |
| news | 10,102行 | AIニュース自動収集・分析 |
| blog | 1,604行 | ブログ（この記事が載っている場所） |
| shared | 2,367行 | 共有コンポーネント・型定義 |
| main | 258行 | トップページ |
| カテゴリ | ツール数 | 例 |
|---|---|---|
| テキスト・開発 | 60 | JSON整形、Base64エンコード、正規表現テスター |
| 画像 | 57 | 圧縮、リサイズ、フォーマット変換、フィルター |
| 26 | 結合、分割、圧縮、暗号化、透かし | |
| 金融 | 21 | 複利計算、FIRE計算、NISA・iDeCoシミュレーター |
| ユーティリティ | 19 | QRコード生成、単位変換、パスワード生成 |
| 動画・音声 | 11 | 動画圧縮、トリミング、MP3変換 |
| 月 | コミット数 | 主な作業 |
|---|---|---|
| 2026年1月 | 28 | プロジェクト立ち上げ、基盤構築 |
| 2026年2月 | 302 | ツール大量生産、ニュースシステム構築 |
| 2026年3月 | 128 | UI改善、ダークモード、認証・課金 |
| 2026年4月 | 69 | モノレポ分割、デザインリニューアル |
2月の302コミットは異常値に見えるが、これは「1ツール作るたびにcommit」を愚直に繰り返した結果だ。AIコーディングでは小さなコミットを頻繁に打つのが正しい戦略。大きな変更を一度にcommitすると、問題が起きたときにどこで壊れたかわからなくなる。
AI開発効率が高いカテゴリ:
AI開発効��が低いカテゴリ:
AIがいても、一人開発には明確な限界がある。
自分一人で作っていると、「これで十分」の基準が甘くなる。他の人に見せて初めて「このボタンの位置おかしくない？」と気づくことが多い。AIはコードレビューはできるが、ユーザー目線のデザインレビューは弱い。
一人だとテストを書くモチベーションが湧きにくい。「動いてるから大丈夫」で進みがち。実際、190個中のいくつかのツールには、エッジケースのバグが眠っているはずだ。
190個のツールがあっても、誰も知らなければ意味がない。コードを書く時間をマーケティングに使うべきだったのでは？…という疑問は常にある。
変えたこと:
変えなかったこと:
この記事は「全体像」を伝える最初の一本だ。今後、もっと具体的なテーマで掘り下げていく予定：
質問や「こういうことを知りたい」があれば、ぜひコメントで教えてほしい。
この記事の執筆にもClaude Codeを使用しました。データ収集のgitコマンド実行、記事構成の壁打ち、日本語の推敲はAIが支援し、体験談・判断・反省はすべて筆者自身のものです。