個人開発で Claude Code を使い始めて 1〜2 週間が経った。
気づいたら PR が 86 本、コミットが 211 件になっていた。作ったツールは 41 個。ひとりで本業の傍らでやっている副業なので、これは正直「え、そんなに？」という感覚がある。
ただ、良いことばかりではなくて、ちゃんと苦労もある。特にトークン消費がひどい。開発が 4 日間止まった。苦悩している。
この記事では、Claude Code をどう使って ぱんだツールズ を開発したか、うまくいったこと・苦労したこと、そしてトークン代との戦いを書いていく。
2週間でPRが86本できた
ぱんだツールズ は、PDF・画像・CSV・テキスト処理をブラウザ内で完結できる無料の Web ツール集だ。iLovePDF みたいなやつを個人で作っている。
開発を始めたのは 2026 年 3 月末。副業プランを Claude Code に読み込ませてそのまま「Phase 1 から開始してください」とやったのが最初だった。
1 週間足らずで基盤 + 40 ツールが一気にできた。2 週目には SEO・OGP・パンくずリストなどのインフラ作業が一通り終わり、Google Search Console への登録、AdSense 審査申請まで進んだ。
これだけの量を自分の手だけでやろうとしたら、週末をかなり削っても 3 ヶ月はかかったと思う。
どうやって使ったか。CLAUDE.mdとスキルで Claude を飼いならす
Claude Code を単なる「コードを書いてもらうツール」として使うと、すぐに限界が来る。毎回「このプロジェクトはこういう設計で…」「ブランチは develop から切って…」と説明し直す羽目になる。
そこで重視したのが CLAUDE.md だ。
CLAUDE.mdに書いたこと
# Webツールポータル — Claude Code ガイド
## プロジェクト概要
全処理をブラウザ内（クライアントサイド）で完結。ファイルはサーバーに送信しない。
## 技術スタック
- Next.js 15 (App Router) + TypeScript
- Cloudflare Pages 無料枠
- pdf-lib + PDF.js（PDF処理）
- SheetJS + encoding-japanese（CSV処理）
## ブランチ戦略
- main: 本番ブランチ。直接push禁止
- develop: 開発ブランチ
- feature/xxx: 機能単位。develop → developへPR
⚠️ Claudeを含む自動化ツールはmainに直接コミット・pushしない。
こういう「コンテキスト」を CLAUDE.md に全部書いておくと、新しい会話を始めても Claude がプロジェクトの文脈を理解した状態でスタートできる。
コーディング規約（any を使わない、Props には named interface を使う、等）、SEO ルール（title タグのフォーマット、FAQ + JSON-LD 必須）、テスト規約（Vitest、src/lib/__tests__/ に置く）も全部ここに書いた。
「設計は CLAUDE.md に書く、Claude は読む」という分業ができると、会話を始めるたびに設計を説明するコストがゼロになる。
カスタムスキルで繰り返し作業を型化する
ツールを追加するたびに「ページを作って → lib 関数を書いて → テストを書いて → SEO メタを追加して → PR を作ってマージして」という手順が毎回発生する。
これをスキル（Claude Code のカスタムプロンプト）として定義した。/add-tool スキルを呼ぶと、既存ツールのパターンに沿って一通り実装してくれる。/manage-pr スキルは、ブランチ削除・PR 方向・既存 PR の更新などのルールを含む PR 操作専用のスキルだ。
スキルにより「このツールを追加してください」の一言でかなりのところまで進む。
並列開発にはworktreeを使う
複数の機能を同時に開発したいとき、同じリポジトリで複数のエージェントを走らせるとファイル競合が起きる。これを解決するのが isolation: worktree だ。
sakutto-tools/
main/ ← メイン作業場所
worktrees/
feature-tool-a/ ← Agent 1（機能開発）
feature-tool-b/ ← Agent 2（機能開発）
docs-update/ ← Agent 3（ドキュメント更新）
各エージェントが独立したワークツリーで作業するので、ファイルが競合しない。並列で走らせて、それぞれ終わったら feature → develop への PR を作る流れだ。
ただし、後述するトークン消費の問題から、ツール実装の並列化は今ではほぼやらなくなった。現在は コードレビューに限って並列 Agent を使う という使い方に落ち着いている。実装は直列、レビューで品質を担保する、という分担だ。
うまくいったこと。人間がやる気ゼロの作業が全部消えた
Claude Code が最も力を発揮したのは、「正しい手順は分かるけど自分でやりたくない」系の作業だ。
たとえば、全 41 ツールに OGP メタタグを追加する作業。og:title, og:description, og:url, og:image を全ページに統一フォーマットで設定する。正確さが必要で、量が多くて、でも技術的に面白くは全くない。
これを PR #75 で Claude が一括でやった。ファイル数は 37。人間がやったら確実に途中で飽きてどこかでミスる。
他にも、
- 全ページのタイトルタグを統一フォーマットに変換（37 ページ）
-
パンくずリスト +
BreadcrumbListJSON-LD を全ツールに実装（PR #78） - カテゴリページ 5 つ新規作成 + サイトマップへの追加（PR #77, #80）
- SEO 説明文セクションを優先ツールから順に追加（PR #76）
どれも「手順は明確、でも量が多い」タイプだ。こういう作業を任せることで、週末 3 時間の副業時間を「設計と意思決定」だけに集中できた。
苦労したこと。監視しちゃう問題
ただ、良いことだけではない。開発中に気づいた問題を dev-notes に残しているが、最初の教訓がこれだった。
Claude Code による自動実装・ファイル生成などの処理を待っている状況。
処理が走っている間、ユーザーは何もしなくていいはずが、つい画面を確認してしまっていた。
結果として、手作業より忙しさを感じる逆転現象が起きた。
Claude が自動で動いてくれる「待ち時間」は空き時間のはずなのに、処理の進捗が気になってチラチラ見てしまい、別の作業に集中できない。
「AI が代わりにやってくれているのに、なぜか疲れている」という奇妙な感覚だった。
今は「AI への委任は、完全に手を離すか、完全に自分でやるかの二択で考える」という結論に落ち着いている。中途半端に監視する状態が最もコストが高い。
長めのタスクは run_in_background で投げて通知を待つ、Claude 実行中は意図的に別のことをするルーティンを作る、タスクの粒度を小さくして待ち時間そのものを短くする、という方向で対処している。
トークン消費が激しすぎる問題
これが今一番の悩みだ。
開発が4日間止まった
Claude Code の Max プランには週次の使用量上限がある。1 週間あたりの制限を 100% とすると、開発 3 日目に 40 ツールを一気に作り終えた時点で、その週の使用量の 90% を消費していた。
残り 10% で残りの 4 日間をやりくりするしかない。実質、その週の開発はそこで止まった。リセットされるまでの 4 日間、ほぼ何もできなかった。
「爆速で作れる」の裏側に「そのぶん上限も爆速で溶ける」があった。
1ツールで週次上限の20%が飛ぶ
Claude Code の使用量は時間ベースで管理されていて、1 回の会話セッションに使える枠も有限だ。
実感として、ツールを 1 個追加する作業（実装 + テスト + SEO + PR 作成）で、1 セッション枠の 20% 前後を消費する。
つまり 1 セッションで 5 ツールが限界の計算だ。これが週次上限とも絡んでくるため、「並列でまとめて作ったほうが速い」という判断が実はコスト的に最悪になる。並列化すると消費量がそのまま掛け算になるからだ。
今では、ツール実装は直列でひとつずつ が基本になった。
並列化をやめた。でもレビューだけは残した
並列エージェントをやめた理由はコストだが、「完成度を下げたくない」という気持ちもある。
コードを Claude に書かせたとき、品質のばらつきがある。バグ・XSS・メモリリーク・設計の一貫性など、ひとつの作業 Agent が見落とすポイントは必ず出る。これをカバーするのが並列でのコードレビューだ。
実装を担当した Agent とは別の Agent に、完成したコードをレビューさせる。実装した Agent 自身にレビューさせると「自分の実装を自分で褒める」になりがちで、指摘の精度が落ちる。別の Agent に任せると、ちゃんと問題を拾ってくれる。
PR #66 では「バグ・アーキテクチャ修正（XSS対策・メモリリーク・PapaParse・parseRanges分離）」というコミットが入っている。これはレビュー Agent が見つけたものだ。自分では気づかなかったし、実装 Agent も見落としていた。
- 実装（直列・コスト抑制）
- レビュー（並列・品質担保）
この使い分けが今のバランスだ。
今やっているコスト抑制の他の工夫
会話を短く切る: 1 会話に複数の作業を詰め込まない。「このツールを追加して、あとついでに SEO も直して」は分ける。コンテキストが長くなるほど 1 トークンの価値が薄くなる感覚がある。
コンテキストを絞る: 「関係ないファイルを読まないでください」と明示的に伝えることもある。Claude は丁寧にあちこちのファイルを読みに行くので、タスクに無関係なファイルまで参照されると無駄が増える。
CLAUDE.md を整理する: CLAUDE.md が肥大化するとコンテキストコストが上がる。不要になったルールは消す、具体的すぎる実装例はリンクに差し替える、といったメンテナンスが地味に重要だとわかってきた。
それでも消費量は多い。「Claude Code は高い道具だが、それを使って生み出せる量を考えると割に合う…と思いたい」という葛藤が正直なところだ。
まとめ。Claude Codeと個人開発の現在地
Claude Code で個人開発をやった率直な感想は「スピードは本物だが、コストも本物」だ。
PR 86 本・41 ツールを 2 週間で作れたのは、本業並行・週数時間の副業時間では普通は出ない数字だと思う。特に「正しいけど量が多くてやりたくない」系の作業を完全に委任できるのは強い。CLAUDE.md とスキルで Claude を「プロジェクトを知っている開発者」として機能させると、毎回の説明コストが消えて会話の密度が上がる。
一方で、監視問題とトークンコストは本物の課題だ。3 日でその週の使用量の 90% を使い切って 4 日間止まった経験は、「使い方を考えないと詰む」という実感として残っている。今は「実装は直列・レビューは並列」という使い分けで、コストと品質のバランスをとっている。
個人開発でどこまで AI に課金するかのバランスは、まだ正解を出せていない。ただ、この規模のものを一人でここまで動かせたのは事実なので、しばらくはこのスタイルを続けながら最適化していくつもりだ。
ぱんだツールズ はまだ育て中で、SEO 流入はこれから。Claude Code と一緒にどこまでいけるか、しばらく実験が続く。
この記事は Zenn にも同じ内容を投稿しています。