レビュアーがいない僕が AI と自分レビューの型を作った話

セルフレビューを習慣にする設計

PR を自分でマージするのが当たり前のフリーランス・個人開発者に、コードレビューは贅沢品なのでしょうか。

答えはノーです。

Cursor に代表される AI をレビュアーとして座らせてから、マージ前に自分では気づけなかったバグや型の抜けを発見できるようになりました。

これは、ひとりで品質を守るための AI セルフレビューの型を作るまでの、僕自身の実験記録です。

「なんとなく動く」 でマージし続けていた頃

Approve ボタンを押したのも、Merge ボタンを押したのも、同じ指でした。

フリーランス開発者として独立してから、PR のセルフマージは当たり前の習慣になっていました。
tsurilog（釣果記録アプリ）も flowtask（GTD × PDCA × Freelance の Todo アプリ）も、設計から実装・デプロイまで完全にひとり。
レビューを頼む相手がいないのだから、しかたない——そう自分に言い聞かせていたのです。

でも、心のどこかでずっと引っかかっていました。

「このコード、本当に大丈夫か？」
「後になって後悔するバグが、今この瞬間にもコードの奥に潜んでいるんじゃないか？」

その不安を、「動いているから大丈夫」という言葉で何度も塗りつぶしていました。

その塗りつぶしが崩れたのは、ある案件での出来事でした。

「動けばいい」 の罠にもう一度ハマった

フリーランスになりたての頃に受けた EC サイトの決済機能改修。
スピードを優先するあまりテストを書かず、「後で書けばいい」と言い訳をし続けた結果——リリース後の深夜 2 時に電話が鳴りました。

決済機能のバグ。
数百行のコードの海で、原因を特定するまでに 72 時間かかりました（汗）

会社員時代、医療系システムの開発に携わっていた僕は、一行のコードが持つ重みを身体で知っているはずでした。
それなのに、フリーランスになってスピードという神様に心を奪われた瞬間、その感覚を手放してしまったのです。

この失敗から学んだことはたくさんあります。
その中でも特に根深かったのが、自分が書いたコードを別の視点で見る仕組みを持っていなかったという事実でした。

チームで開発をしていれば、他のメンバーが違う目で見てくれます。
ひとり開発では、それがない。
だから自分で、別の目を作らなければならない——そう気づいたのが、AI セルフレビューへの出発点でした。

書くツールから批評するツールへ

もともと AI はコードを書く道具として使っていました。
Cursor で実装のたたき台を生成し、GitHub Copilot でコード補完を加速する。
Claude に設計の壁打ちをする。

ある日 tsurilog の開発中に気づいてしまいました。

any が増えている（汗）

TypeScript を学びたての頃、Supabase・OpenAI API・Open-Meteo の 3 つの外部 API を組み合わせた設計で型エラーに詰まり続けた僕は、as any という呪文を覚えてしまいました。
コンパイルが通る。画面も動く。

数ヶ月後、自分のコードを読み返すと——手が止まるのです。

「この data、何が入っているんだっけ」

any はコンパイラを黙らせます。
そして同時に、未来の自分も黙らせてしまう。

そのとき、ふと思ったのです。

「AI は書くだけでなく、読む・批評することもできるんじゃないか？」

Cursor のチャット機能に、自分のコードを貼りつけて打ちました。

「このコードの問題点を、正直に教えてください」

AI から返ってきた指摘は、思っていたより的確でした。

型の抜け。
エッジケースで壊れそうな条件分岐。
命名の曖昧さ。

「これ、自分じゃ気づいてなかったな……」

それが、AI セルフレビューの始まりでした。

僕が使っている AI セルフレビューの型

試行錯誤の末に、マージ前に必ず通す 5 つの問いかけの型が定まりました。
Cursor のチャットを開き、レビューしたいコードを貼りつけてから、順番に問いかけていきます。