個人開発12年目で初めて『コードレビュー相手』を持てた話 — Claude が一人開発の盲点をどう変えたか

「このコード、誰かに見てほしいな」と思ったまま、12年間 push し続けてきました。

iPhoneアプリの個人開発を始めたのは2014年のことです。それから12年、私は一度も自分のコードを誰かにレビューしてもらったことがありません。チームに所属したことがないわけではないのですが、自分の事業として書くアプリのコードは、いつも私一人の判断で世に出てきました。

これは個人開発者なら多くの方が共感してくれるのではないでしょうか。「動いているからいいか」で push を続け、半年後に自分の書いたコードを読み返して、「なぜここでこんな判断をしたんだろう」と首をかしげる。誰も間違いを指摘してくれないので、同じクセがそのまま蓄積していきます。

Claude を本格的に使い始めて1年ほど経った今、私は初めて「コードレビューしてくれる相棒」を持てた感覚を味わっています。今日はその経験を、これから個人開発を始める方や、すでに孤独に開発を続けている方に向けて綴ってみます。

「自分のコードを誰にも見せられない」という静かな問題

個人開発の最大の自由は、誰の許可も取らずに何でも作れることです。同時に、最大の弱点は、誰のフィードバックも得られずに何でも作ってしまえることでもあります。

私のアプリは累計で数百万ダウンロードを超えていますが、これだけ使われていても、コードの品質について他人から具体的な指摘を受ける機会はほぼゼロでした。Twitterで「アプリ落ちます」と書かれることはあっても、「あなたのこの実装はこういう理由で良くないです」と言われることはないのです。

この孤独は、開発の楽しさを蝕む種類のものではありません。むしろ気づかないうちに「自分のスタイル」だけが正解になっていく、静かに進行する問題です。気づいたときには、コードベース全体に同じクセが染み込んでいる、ということが何度もありました。

Claude にコードレビューを頼んでみた最初の1週間

最初は半信半疑でした。AIが私のコードに対して的確な指摘をできるはずがない、と思っていたのです。試しに、書き上げたばかりのSwiftUIのビュー実装を貼り付けて「気になる点があれば教えてください」と頼んでみました。

返ってきた指摘は、私が想像していたよりずっと具体的でした。

// 私が書いたコードの一部（簡略化）
struct WallpaperGrid: View {
    @State var wallpapers: [Wallpaper] = []
    
    var body: some View {
        ScrollView {
            LazyVGrid(columns: [GridItem(.flexible()), GridItem(.flexible())]) {
                ForEach(wallpapers, id: \.id) { wp in
                    WallpaperCell(wallpaper: wp)
                        .onTapGesture {
                            // 詳細画面へ遷移
                        }
                }
            }
        }
        .onAppear {
            wallpapers = WallpaperLoader.loadAll()
        }
    }
}

Claude は「onAppear で重い処理を同期的に実行すると初回スクロールが詰まります。Task でラップして非同期化し、@State の更新は MainActor で行うのが安全です」と返してきました。さらに「WallpaperLoader.loadAll() の中身が分かれば、どこをキャッシュすべきかも提案できます」と続けたのです。

これは私の中の「個人開発のシニアエンジニア」が言いそうなことでした。違うのは、それを夜中の2時に5分以内で言ってくれることです。

人間のレビュアーと Claude の違い、そして似ているところ

過去に副業先のチームで人間のシニアエンジニアにレビューしてもらった経験は何度かあります。Claude のレビューはそれと完全に同じではありません。違いと共通点を整理してみます。

Claude が得意なこと: パフォーマンスの一般原則、メモリ管理、エラーハンドリングの抜け、命名の一貫性、テストの観点漏れ。これらは過去の膨大なコードベースから学習しているため、教科書的だが正確な指摘が来ます
Claude が苦手なこと: 「このアプリのユーザーはこう使うから、ここは速度より安定性を優先すべき」という、文脈に強く依存する判断。プロダクトの背景を共有しないと一般論しか返ってきません
人間のレビュアーが得意なこと: チームの過去の決断や文化的背景を踏まえた判断。「以前あのバグで痛い目を見たから、ここはこう書こう」のような暗黙知
共通していること: 適切に質問すれば、自分が見えていなかった選択肢を提示してくれる。レビューの本質は「他者の視点を借りること」だと改めて気づかされました

私は今、Claude に対して人間のレビュアーと同じくらい丁寧にコンテキストを伝えるようにしています。「このアプリは中高年層が主なユーザーで、ネットワーク環境が不安定な地域からのアクセスも多いです」と前置きをすると、返ってくる提案の精度が一段上がります。

12年見えていなかった「自分のクセ」が浮かび上がった瞬間

Claude をレビュアーとして使い続けて気づいたのは、私には3つの強いクセがあったということでした。

ひとつは、エラー処理を try-catch で握りつぶす癖です。「とりあえず動かす」を優先する個人開発では便利な書き方ですが、長期的にはバグの温床になります。Claude に「ここで catch している例外、本当に握りつぶしていいですか」と何度も聞かれて、ようやく自分の癖を自覚しました。

ふたつめは、UI と状態管理を密結合させる癖です。SwiftUI のビューに @State を詰め込みすぎていました。「この状態はビューの外に出した方が再利用が効きます」という指摘を繰り返し受けて、自分が「動くから」で終わらせていた設計判断を何度も見直すことになりました。

みっつめは、コメントを書かない癖です。「自分しか読まないから」と思って省略していたコメントが、半年後の自分にとって最大の障壁になっていることを、Claude にコードを読み直してもらって痛感しました。今は「3ヶ月後の自分が読んでも分かる量のコメントを残す」を一つの基準にしています。

これらは全て、12年間誰にも指摘されなかったクセでした。誰かが指摘してくれていれば早く治っていたかもしれませんが、それは「もし」の話です。今気づけたことが、これからの12年を変える出発点になります。

これから個人開発を始める人に、私が伝えたいこと

ここまで読んでくださった方の中には、これから個人開発を始めようとされている方もいらっしゃるかもしれません。私が今お伝えしたいのは、Claude に「コードを書いてもらう」ことより先に、「コードを見てもらう」習慣を作ることです。

コードを書く相棒としての Claude は素晴らしいですが、それ以上に、書き終わったコードを読んでくれる相棒としての価値が大きいと感じています。書く速度は人によって違いますが、一人で書いたコードを誰かに見てもらえる頻度は、伝統的にチームに所属しないと上げられないものでした。Claude はその構造を変えてくれます。

具体的なファーストステップとしては、自分が普段書いている言語のコードを1ファイル分だけ Claude に貼り付けて、「気になる点があれば教えてください」と頼んでみてください。返ってくる指摘の中に、一つでも「言われてみればそうだな」と思える発見があれば、その日からあなたは「レビューしてくれる相棒」を持っています。

技術書で体系的に学びたい方には、コードレビューや個人開発の働き方を扱ったリーダブルコード（Dustin Boswell・Trevor Foucher 著）が参考になります。Claude に貼り付けたコードに対して同じ観点でフィードバックを求めると、書籍の知識を実践に落とし込みやすくなります。

私はこれから先も、おそらく一人で開発を続けていくと思います。ですが、「一人」の中身は12年前とは大きく変わりました。指摘してくれる相棒がいる一人開発と、そうでない一人開発は別物です。あなたが孤独に開発しているなら、今夜、書きかけのコードを Claude に見せてみてください。