開発時間は40%減った。でも、バグの修正時間は3倍になった。
これが、Claude Codeに開発工程を「全部任せる」運用を1ヶ月続けた私の成績表です。結論から言うと、Claude Codeには「任せていい工程」と「絶対に人間がやるべき工程」が明確に存在します。この記事では、私が手動に戻した3つの工程と、その判断基準となるフレームワークを共有します。
環境・前提条件
- ツール: Claude Code（CLI版）
- プロジェクト規模: Rails API + Next.js フロントエンド（エンジニア3名）
- 期間: 全自動運用1ヶ月 → 一部手動に切り戻して2ヶ月
- 対象読者: Claude CodeやCursorなどAI開発ツールを実務で使っているエンジニア
1. 全自動に酔った1ヶ月間の成果と代償
最初の1ヶ月、私はClaude Codeに可能な限りすべてを任せました。機能設計、DB設計、実装、テスト作成、コードレビュー補助、ドキュメント生成。結果を数字で振り返ります。
成果（ポジティブ面）
| 指標 | Before | After（全自動） | 変化 |
|---|---|---|---|
| 機能実装の初速（PRオープンまで） | 平均4.2時間 | 平均2.5時間 | -40% |
| テストカバレッジ | 62% | 78% | +16pt |
| 1日あたりのPR数 | 1.8件 | 3.1件 | +72% |
数字だけ見れば大成功です。チームの誰もが「もう戻れない」と思いました。
代償（ネガティブ面）
| 指標 | Before | After（全自動） | 変化 |
|---|---|---|---|
| 本番障害のバグ修正時間 | 平均1.2時間 | 平均3.8時間 | +217% |
| マイグレーション起因の障害 | 月0.5件 | 月3件 | +500% |
| 「意図がわからない」レビューコメント | 月2件 | 月14件 | +600% |
速く作れるが、壊れたときに誰も直せない。 コードの「意図」が人間の頭に残っていないからです。
このループに気づいたのは、本番DBのマイグレーションで30分のダウンタイムを出した日でした。
2. 手動に戻した工程①：DBマイグレーション設計
AIが「動くけど危険なスキーマ」を量産した
Claude Codeにテーブル設計を任せると、構文的に正しく、機能的にも動くマイグレーションを高速に生成してくれます。しかし、以下のような「運用で死ぬ」設計が頻発しました。
実際に起きた問題の例：
# Claude Codeが生成したマイグレーション
add_column :orders, :status, :string, default: "pending"
add_index :orders, :status
一見問題なさそうですが、ordersテーブルには1,200万行ありました。
-
add_columnはPostgreSQL 11+ならデフォルト値付きでも高速ですが、add_indexはテーブルロックを伴います - 本番で実行した結果、約30分の書き込みブロックが発生しました
Claude Codeは「テーブルの行数」「本番のトラフィックパターン」「ロック戦略」を知りません。CREATE INDEX CONCURRENTLY を使うべきかどうかの判断は、運用コンテキストを持つ人間にしかできないのです。
今の運用
- スキーマの初案はClaude Codeに出してもらう（速い）
- レビュー・修正は人間が必ず行う（ロック影響、データ量、ロールバック戦略）
- 大規模テーブルへの変更は必ずDBAレビューを通す
3. 手動に戻した工程②：エラーハンドリング設計
例外の粒度は「ビジネス判断」である
Claude Codeにエラーハンドリングを任せると、こういうコードが生まれます。
# Claude Codeが生成したコード
def process_payment(order)
result = PaymentGateway.charge(order.total, order.payment_method)
result
rescue StandardError => e
Rails.logger.error("Payment failed: #{e.message}")
{ success: false, error: "決済に失敗しました" }
end
動きます。テストも通ります。でも本番では地獄です。
問題点を挙げます。
-
StandardErrorの一括キャッチで、カード期限切れもネットワーク障害も不正利用検知も同じ扱いになる - ユーザーには常に「決済に失敗しました」としか伝わらない
- リトライすべきエラーと、リトライしてはいけないエラーの区別がない
あるべき姿：
def process_payment(order)
result = PaymentGateway.charge(order.total, order.payment_method)
result
rescue PaymentGateway::CardExpiredError => e
notify_user_card_update_needed(order.user)
{ success: false, error: "カードの有効期限が切れています", action: :update_card }
rescue PaymentGateway::FraudDetectedError => e
freeze_account(order.user)
notify_security_team(order, e)
{ success: false, error: "セキュリティ上の理由で処理できません", action: :contact_support }
rescue PaymentGateway::NetworkError => e
RetryQueue.enqueue(order, max_retries: 3)
{ success: false, error: "一時的なエラーです。自動で再試行します", action: :wait }
end
例外をどこまで細かく分けるか、各例外でどんなアクションを取るか。これはビジネスロジックそのものであり、プロダクトの信頼性を左右する設計判断です。
今の運用
- 正常系の実装はClaude Codeに任せる
- エラーハンドリングの設計（例外の分類と対応方針）は人間が書く
- 設計方針が決まった後の実装コードはClaude Codeに生成させてもOK
4. 手動に戻した工程③：コードレビュー最終判断
AIレビューを通した後に人間が見る「3つの観点」
Claude Codeにコードレビューをさせると、構文ミス、命名規則違反、パフォーマンス上の明らかな問題はよく拾ってくれます。しかし、以下の3つの観点はAIレビューではほぼ検出できませんでした。
観点1：「なぜやらなかったか」の検証
PRで実装された内容が正しいかはAIでも判断できます。しかし、**「なぜ別のアプローチを選ばなかったか」**の妥当性は、チームの過去の意思決定履歴を知る人間にしか判断できません。
「前にこのパターンで障害が出たから、あえて冗長な実装にしている」
こうした暗黙知はClaude Codeの文脈窓には入りません。
観点2：チーム全体の一貫性
Claude Codeは「そのPR単体で良いコード」を生成する能力は高いですが、リポジトリ全体のアーキテクチャ方針との整合性を見るのは苦手です。
- ServiceオブジェクトとUseCaseクラス、どちらのパターンで統一しているか
- エラーレスポンスのJSON構造は他のエンドポイントと揃っているか
観点3：「この変更の影響を受ける人」への配慮
フロントエンドチームが依存しているAPIのレスポンス構造を変更していないか。モバイルアプリの旧バージョンに影響しないか。これらは組織の構造を理解している人間が判断するしかない領域です。
今の運用
- 1次レビュー: Claude Codeで構文・パフォーマンス・セキュリティをチェック
- 2次レビュー（人間）: 上記3つの観点に絞って確認
- 人間のレビュー時間は減ったが、レビューの質は上がった
5. 「任せる／任せない」の判断フレームワーク
1ヶ月の全自動運用と2ヶ月の調整を経て、私がたどり着いた判断軸は2つです。
- 横軸：失敗時の影響範囲（小さい ← → 大きい）
- 縦軸：必要なコンテキストの深さ（浅い ← → 深い）
このマトリクスの使い方はシンプルです。
| 象限 | 方針 | 例 |
|---|---|---|
| 左下（影響小×コンテキスト浅） | Claude Codeに任せる | テスト生成、ボイラープレート |
| 左上（影響小×コンテキスト深） | 要検証（併用） | ドキュメント生成、リファクタリング提案 |
| 右下（影響大×コンテキスト浅） | AIドラフト＋人間レビュー | API実装の正常系 |
| 右上（影響大×コンテキスト深） | 人間がやる | DB設計、エラー設計、最終レビュー |
新しい工程をClaude Codeに任せるか迷ったら、この2軸で位置づけてみてください。右上に位置する工程ほど、人間の判断が不可欠です。
6. 結論：Claude Codeは「副操縦士」ではなく「高速な仮説生成機」
「副操縦士」というメタファーは、「任せたら安全に飛んでくれる」という錯覚を生みます。しかし実態は違います。Claude Codeが得意なのは、**「ありうる選択肢を人間の10倍の速度で生成すること」**です。
どの選択肢を採用するか、なぜその選択肢が自分たちのプロダクトに最適なのかを決めるのは、常に人間の仕事です。
まとめ
- DBマイグレーション・エラーハンドリング・コードレビュー最終判断の3工程は手動に戻した。 「失敗時の影響が大きく、運用コンテキストが必要な工程」はAIに任せきるとリスクが跳ね上がる
- 判断基準は「失敗時の影響範囲 × 必要なコンテキストの深さ」の2軸。 この2軸マトリクスで工程ごとの自動化適性を可視化すると、チームで合意が取りやすい
- Claude Codeは「高速な仮説生成機」として使い倒すのが最も費用対効果が高い。 生成されたコードを「答え」ではなく「叩き台」として扱う意識が、AI時代の開発品質を左右する