「受託開発、1週間で納品って言ったけど...本当にいけるのか？」
エンジニアなら一度は感じたことがある、あの納期前夜の冷や汗。仕様は固まった、技術スタックも決まった。でも手が足りない。
私たちplayparkは2人チームの小さな会社です。でも最近、もう1人（？）チームに加わりました。Claude Codeです。今回は、Claude Codeをフル活用して採用管理システムの受託開発を1週間で完了させた、開発プロセスの裏側をお話しします。
この記事で話すこと・話さないこと
先に断っておきます。システムの機能紹介やGemini APIの活用については、別の記事で詳しく書いています。今回は 「どうやって1週間で作ったのか」、つまり開発プロセスと生産性の話に絞ります。
Claude Codeを「なんとなく便利そう」で終わらせず、受託開発の現場でどう使い倒したか。泥臭い話も含めてお届けします。
開発タイムライン：5日間で48PR
まず、実際のGit履歴から振り返ります。
| 日付 | 主な作業 | PR数 |
|---|---|---|
| 3/28-29 | 仕様策定・初期構成（Next.js + Prisma + Neon） | 4 |
| 3/31 | MVPダッシュボード（候補者CRUD・AI選考・面接記録） | 3 |
| 4/1 | テスト補完・パフォーマンス改善第1弾 | 10 |
| 4/2 | パフォーマンス改善第2弾・招待制認証・UX修正 | 12 |
5日間で48PR、80以上のコミット。しかもこれ、1人の人間が書いたコードです（Claude Codeのアシスト込みですが、レッドブル代は自腹です）。
「いや、数が多いだけでは？」と思いますよね。中身を見てみましょう。
Claude Codeの活用法：4つの使い方
1. 並列タスク分解と実装
このプロジェクトで一番効いたのが、Issue → 並列タスク分解 → worktree並列実装 → マージ のワークフローです。
たとえばパフォーマンス改善のIssue。「動きがもっさりする」というクライアントフィードバックから、Claude Codeにプロファイリング結果を渡して分析させると、4つの独立したボトルネックを特定しました。
- task1: DBインデックス追加・N+1クエリ修正・認証セッション重複排除
- task2: 検索デバウンス・react-markdownのdynamic import化
- task3: SWR基盤構築・楽観的更新の導入
- task4: Server Component化・ページネーション実装
それぞれファイルの依存関係が独立していたので、Git worktreeで4つの作業ディレクトリを作って並列に実装。Claude Codeが各worktreeでコードを生成し、最後にマージブランチで統合しました。
feature/issue-29-task1 ← DBインデックス + N+1修正
feature/issue-29-task2 ← デバウンス + dynamic import
feature/issue-29-task3 ← SWR + 楽観更新
feature/issue-29-task4 ← SC化 + ページネーション
↓
feature/issue-29-merge ← 4ブランチを統合
この「分解 → 並列 → 統合」パターンを繰り返した結果、1つのIssueに対して設計仕様書の作成から実装・テスト・PRレビューまで約2時間で完了できました。人間が全部手で書いていたら、1日仕事です（しかも脳が溶ける）。
2. コードレビューの壁打ち相手
受託開発で地味に時間を食うのが、セルフレビュー。2人チームだと「もう1人の目」が常にあるわけじゃない。
Claude Codeに PR のdiffを渡してレビューさせると、こんな指摘が返ってきます。
- 「
FIELD_LABELSが2ファイルで重複定義されてます。共通化しませんか？」 - 「このキャッシュキー、typoしてません？」
- 「import順序がBiomeのルールに違反してます」
実際のコミット履歴を見ると、fix: address review feedback や fix: レビュー指摘対応 というコミットが複数あります。これ、全部Claude Codeのレビュー指摘を反映したもの。人間がレビューするのと同じフィードバックサイクルが、待ち時間ゼロで回ります。
もちろん、Claude Codeのレビューを鵜呑みにはしません。「その指摘、この文脈では当てはまらないよ」と却下することもあります。でも 「見落としを拾ってくれる第三の目」 としては、かなり頼りになる。
3. テスト生成の自動化
テストって、書かなきゃいけないのはわかってる。でも納期が迫ると「後で書く」が「永遠に書かない」に変わる、あの現象...心当たりありませんか？
このプロジェクトでは、Claude Codeにテストギャップの分析と補完を任せました。
- 認証・バリデーション・API・AI連携のテストを一括生成
- TypeScript型エラーの検出と修正まで自動対応
- テスト用のモックヘルパー（
mock-auth.ts,mock-prisma.ts）も生成
結果として、tests/integration/ に6ファイル、src/ 配下にユニットテスト14ファイルが揃いました。納期に追われながらもテストカバレッジを妥協しなかったのは、Claude Codeの生産性のおかげです（「後で書く」が本当に「後で書けた」の、人生初かもしれない）。
4. パフォーマンス最適化の設計から実装まで
「動きがもっさりする」——クライアントからのこの一言、開発者にとっては一番ドキッとするフィードバックですよね。
Claude Codeの真価が発揮されたのは、このパフォーマンス改善フェーズでした。
- ボトルネック分析: コードベースを読み込ませて、パフォーマンス上の問題点を体系的に列挙
- 設計仕様書の自動生成: 改善方針と実装計画をMarkdownで出力
- 段階的な改善実装: バンドルサイズ削減（googleapis → @googleapis/drive で190MB削減）、セッション応答改善（383ms → 100ms以下）、SWR導入による楽観的更新
設計仕様書から実装コードまで一貫してClaude Codeが支援してくれるので、「設計は決まったけど実装する時間がない」という受託開発あるあるから解放されました。
Claude Codeを受託開発で使う際の勘所
半年ほどClaude Codeを実案件で使ってきて、見えてきたことがあります。
うまくいくパターン
- Issueを明確に書いて渡す: 「もっさりしてる」ではなく、プロファイリング結果やエラーログを一緒に渡す。Claude Codeは材料が多いほど精度が上がる
- ファイル単位で独立したタスクに分解する: 依存関係が少ないほど並列化しやすく、マージコンフリクトも起きにくい
- レビュー → 修正のサイクルを回す: 一発で完璧なコードは出てこない。PRレビュー形式でフィードバックして、2-3回のイテレーションで仕上げるのが現実的
注意が必要なポイント
- ビジネスロジックの判断は人間がやる: 「招待制にするかオープン登録にするか」はClaude Codeに聞いても答えは出ない。要件定義とアーキテクチャ判断は人間の仕事
- 生成コードの盲信は禁物: 特にセキュリティ周り。認証・権限チェックのコードは必ず人間がレビューする
- コンテキストの管理が重要: プロジェクトが大きくなると、Claude Codeに渡すコンテキストの質が生産性を左右する。CLAUDE.mdの整備は投資対効果が高い
数字で振り返る開発生産性
| 指標 | 値 |
|---|---|
| 開発期間 | 5日間（実稼働） |
| PR数 | 48 |
| コミット数 | 80+ |
| テストファイル | 20ファイル（unit + integration） |
| パフォーマンス改善Issue | 4件（すべて解決） |
| 並列worktree最大数 | 5（1Issueあたり） |
1人のエンジニアが5日間で出せる量としては、かなり異常値だと思います（褒めてるんです、Claude Codeを）。
でも大事なのは量じゃない。PRレビューのサイクルを回しながら、テストも書きながら、パフォーマンス最適化もやりながら、1週間で納品できたこと。質と速度を両立できたのが、Claude Codeの本当の価値です。
まとめ
Claude Codeは「コードを書いてくれるAI」ではなく、「開発プロセス全体を加速するペアプロ相手」 だと感じています。
タスク分解、並列実装、コードレビュー、テスト生成、パフォーマンス分析。受託開発で必要なあらゆるフェーズでClaude Codeが機能しました。ただし、要件定義や最終判断は人間の仕事。AIに任せていい部分と、人間がグリップすべき部分の線引きが、うまく使いこなすカギだと実感しています。
「受託開発、もう少し効率よくならないかな」と感じている開発者の方。まずは1つのIssueを並列タスクに分解して、Claude Codeに投げてみるところから始めてみませんか？
