「Claude Code に任せて良かったか」が、毎晩の振り返りテーマだった
個人開発を始めて 12 年が経ちますが、Claude Code を導入して最初の数ヶ月は、毎晩寝る前に「今日の判断は本当に最適だったか」を振り返ることが日課になっていました。
判断のたびに分岐が発生するのです。「このタスクはサブエージェントに分解すべきか、それとも自分でやった方が早いか」「Plan モードで止まるべきか、自走させて結果だけ見るべきか」「テストを先に書かせるか、実装の後で書かせるか」。どれも一見すると好みの問題に見えますが、判断を間違えると深夜にバグの原因を追いかける羽目になります。
ここでは私が個人開発の現場で 1 年運用してきて、ようやく自分なりに「ここはこう判断する」と言語化できるようになった 7 つの分岐点を共有します。教科書的な答えではなく、失敗と回り道の末に辿り着いた実践的な基準として読んでいただければ嬉しいです。
分岐 1 — サブエージェントに分解すべきか、メインで考え抜くべきか
Claude Code のサブエージェント機能は強力ですが、何でも分解すれば良いわけではありません。むしろ過剰に分解すると、メインのコンテキストでは見えていた全体像が、サブエージェントには伝わらず、ちぐはぐな実装が返ってくることがあります。
私が今使っている判断基準は次の通りです。
サブエージェントに任せるのは、入力と出力の境界がはっきり定義できるタスクです。「この関数のテストケースを 5 つ書いてほしい」「このディレクトリのファイル一覧から該当しそうな実装を探してほしい」のように、依頼内容と期待する成果物が独立して評価できるものは、サブエージェントが得意としています。
逆に、設計判断や全体最適が絡むタスクはメインのコンテキストで考え抜きます。「このリファクタリングの方針を決めたい」「この機能はどのレイヤーに置くべきか」といった問いは、コードベース全体の文脈と、過去の判断履歴を理解しているメインエージェントの方が良い答えを出してくれます。
実際に失敗した例を 1 つ挙げると、ある日 API の認証層を全面的に書き直す作業で、調査・設計・実装・テストを 4 つのサブエージェントに分解しました。結果として、調査エージェントは「JWT を使うのが標準」と返してきたものの、設計エージェントは「セッション Cookie の方がこのアプリには合う」と判断し、実装エージェントは両方を中途半端に混ぜたコードを書いてしまいました。コンテキストの分断が品質を下げた典型例です。
分岐 2 — Plan モードで止めるか、自走させるか
Plan モードは Claude Code の中でも特に好きな機能ですが、毎回これで止まると開発のリズムが崩れます。私の運用では、次の条件のいずれかに当てはまる時だけ Plan モードを使っています。
- 影響範囲が 3 ファイル以上に及ぶ変更
- データベーススキーマや API 契約の変更を含む
- 過去にも似たタスクで判断ミスがあったドメイン
- 失敗した時のリカバリーコストが高い領域（決済、認証、永続データ）
これ以外の作業、たとえばスタイル調整やテキスト修正、新規ファイルの追加程度であれば Plan モードを挟まずに自走させます。Plan を毎回確認していると、細かな修正のたびに思考のコンテキストスイッチが起きて、生産性が落ちることに気付いたためです。
代わりに、自走させた場合は コミット粒度を細かくして、後から差分で確認できる体制を整えます。これは「事前に見るか、事後に見るか」のトレードオフで、用途に応じて使い分けるのが現実的だと思っています。
分岐 3 — テスト駆動で進めるか、実装後にテストを足すか
理論上は TDD が美しいのですが、個人開発の現実では必ずしも TDD が最適ではないと感じています。
私が TDD で進めるのは、仕様が確定していて、入出力の対応が論理的に決められる領域です。バリデーション関数、データ変換、ビジネスルールの実装などは、テストを先に書いた方が速く、かつ堅牢になります。
逆に、UI コンポーネント、API のハンドラ、外部サービス連携のコードは、実装してみないと適切なインターフェイスが見えてこないことが多いので、まず動くものを作り、後からテストで仕様を固めます。
Claude Code に依頼する時の言い回しも変えています。前者は「この仕様のテストを書いてください。その後、テストを通る最小実装をお願いします」、後者は「まず動く最小実装を書いてください。動作確認の後、回帰防止用のテストを追加します」と明示します。曖昧に「テストも書いてください」と言うと、実装とテストが密結合になり、後で仕様変更が辛くなります。
分岐 4 — AI コードレビューをどこまで信用するか
これは個人開発者にとって特に悩ましい問題です。同僚がいないので、AI のレビューに頼りたくなる気持ちは分かります。私自身、Claude Code に「このコードをレビューしてください」と頼むことは多いです。
ただし、自動的に修正させる範囲と 自分で判断する範囲は明確に分けています。
自動修正させて良いのは、コーディングスタイル、未使用変数の削除、明らかなロジックバグ（オフバイワン、null チェック忘れ）など、判断の余地が小さいものです。これらは AI が見つけて直してくれるだけで時間が節約できます。
逆に、設計判断、命名、エラーハンドリング戦略、パフォーマンスのトレードオフは、必ず自分で見て判断します。AI のレビューは「こういう観点もあるよ」というヒント集として扱い、最終決定は自分で下すというスタンスです。
これを守らないと、半年後に自分のコードベースを見た時に「このコードはなぜこう書かれているのか」が説明できなくなります。長期的にメンテナンスする責任は自分にあるという前提を忘れないようにしています。
分岐 5 — リファクタリングを依頼するか、機能追加と一緒にするか
Claude Code に「ついでにリファクタリングもお願いします」と頼むと、機能追加とリファクタリングが混ざったコミットが生まれてしまい、後から差分を追うのが大変になります。これは何度か痛い目を見て学んだ教訓です。
今は次のルールで運用しています。
機能追加の前に、対象コードに対して先にリファクタリング専用のコミットを作ります。「この関数を機能追加しやすい形に整える」と Claude Code に明確に依頼し、振る舞いを変えないリファクタリングだけを行います。テストが既にあれば、リファクタリング前後でテストが通ることだけを確認します。
その後、別のコミットとして機能追加を行います。こうすることで、もし後で機能を取り消す必要が出た時も、リファクタリング部分は残せますし、もしリファクタリングが過剰だったと気付いた時も、機能追加には影響しません。
少し手間に感じますが、個人開発で長くメンテするコードには、この分離が効きます。
分岐 6 — どこまでコメントを書かせるか
Claude Code は、放っておくと丁寧すぎるコメントを書きます。「// この変数を 1 増やす」のような自明なコメントが量産されると、コードが読みにくくなります。
私が今使っているプロンプトは「コメントは『なぜ』を書き、『何を』は書かないでください」という指示です。コードを読めば分かることはコメントしない、コードからは読み取れない意図や背景だけを残す、という方針です。
加えて、こういうコメントを残してもらうように頼むと、後から自分が読み返した時に助かります。
- このコードを書いた当時のトレードオフ判断
- なぜこの選択肢を採らなかったかの理由
- 将来変更する時に注意すべき副作用
- 関連する別のコードへのリンクや参照
逆に、JSDoc や docstring のような構造化されたコメントは、生成してもらった方が良いと感じています。後で型情報や引数の意味を確認する時に、エディタのホバー表示で読めるからです。
分岐 7 — エラー対応を任せるか、自分で読むか
エラーが出た時、Claude Code に「このエラーを直してください」と頼みたくなりますが、ここも分岐があります。
任せて良いエラーは、メッセージが具体的で、原因が局所的なものです。「Property 'foo' does not exist on type 'Bar'」のような型エラーや、「Cannot find module 'baz'」のような依存関係のエラーは、Claude Code に投げるだけで解決します。
自分で読むべきエラーは、メッセージが抽象的だったり、複数のシステムが絡んでいたりするものです。「Internal Server Error」「The operation could not be completed」のような抽象的なメッセージは、AI に投げても見当違いの修正が返ってくることが多いです。
特に怖いのが、症状を消す修正を AI が提案してくるケースです。例えば、null チェックを追加してエラーを握りつぶす、try-catch で例外を黙らせる、テストを skip にする、などです。これらは表面的にはエラーが消えますが、根本原因は残ったままです。
私はエラー対応の時、必ず「このエラーの根本原因を 3 つの可能性として説明してください。修正は私が判断します」とまず聞いてから、自分で原因を特定するようにしています。修正の方針が決まってから、実装を Claude Code に任せます。
個人開発者にとって、Claude Code は「相棒」であって「代行者」ではない
ここまで 7 つの分岐を紹介してきましたが、共通する考え方は 1 つです。Claude Code は私の代わりに考えてくれるツールではなく、私の思考を加速してくれる相棒だという認識です。
任せるべきところは思い切って任せ、判断するべきところは自分で判断します。この線引きが甘くなると、コードベースの一貫性が失われ、半年後に自分でメンテナンスできなくなります。逆に、線引きを意識して使えば、1 人で複数のプロジェクトを並行運用できる生産性が手に入ります。
私自身、まだ毎日この分岐に直面しながら、判断基準を更新しています。今回紹介した 7 つも、3 ヶ月後にはもっと洗練されているかもしれません。それでも、こうやって言語化しておくことで、未来の自分や、似た立場の個人開発者の役に立てればと思って書きました。
明日の開発で、どこか 1 つでも「これは前の判断と違うな」と気付けたら、それが個人開発者として成長している証だと思っています。