書いたばかりのコードを自分で読み返したとき、なぜか粗が見えないという経験はないでしょうか。私自身、2014年から個人でアプリ開発を続けていますが、夜中に勢いで書いたコードを翌朝読み返すと「悪くない」と感じてしまい、しばらく経ってから致命的な見落としに気付くことが何度もありました。
Claude Code をレビュアーとして使うとき、多くの人が最初に試すのは「このコードをレビューしてください」という素直な依頼でしょう。それでも一定の指摘は返ってきますが、私の体感では、自分の書いたコードを渡したときの指摘は不思議と「優しい」のです。AI 側が空気を読んでいるのか、それとも依頼者である私の言葉遣いに引っ張られているのか、いずれにせよ素直に頼むだけでは厳しいレビューにはなりません。
ここではClaude Code を「他人が書いたコードを読みに来た中堅レビュアー」として召喚するための質問設計を、私が実際に使っているテンプレートとともにお話しします。テクニックそのものはシンプルですが、レビューで返ってくる指摘の質は段違いに変わります。
なぜ「自分のコード」として読ませると指摘が甘くなるのか
ここはある意味、人間のレビュー文化と同じだと考えています。社内で同僚のコードをレビューするときと、業務委託先から送られてきた知らないチームのコードをレビューするときでは、自然と読み方が変わります。後者のほうが、前提を疑う目で読みます。
Claude Code に何の文脈も与えずにコードを渡すと、モデルは「このコードを書いた人物がそばにいて、自分の依頼を見ている」前提で応答します。結果として、本質的に重要だが書き手の自尊心を傷つけかねない指摘が後ろに回されたり、丸められて表現されたりします。これは AI が悪いのではなく、対話のデフォルトがそうなっているだけです。
レビューを「依頼者の感情を考慮しなくて良い文脈」に置き換えるだけで、指摘の優先順位が変わります。私が試してきた中で最も効果が高かったのは、コードの出自を「他人のもの」として明示することでした。
基本テンプレート — 「中堅エンジニアが書いた前提」で読ませる
私が claude-code セッションで最初に流し込むプロンプトの骨格をお見せします。実際にはプロジェクトごとにアレンジしていますが、土台はほぼこの形です。
あなたはこのチームに最近合流したシニアエンジニアです。
これから渡すコードは、半年前にチームに入った中堅エンジニアが書いたものです。
本人は今プロジェクトを離れていて、コミットの背景は聞けません。
このコードを次のレビューに進める前提で、以下の観点で厳しく読んでください。
- 設計上、後から効いてくる地雷（命名・責務分割・データの流れ）
- 例外系・境界値・並行処理で破綻する可能性
- テストでは見つからないが本番で必ず踏むであろう罠
「悪くない」「概ね良さそう」という評価は不要です。
気になる箇所を全て、優先度付きで列挙してください。このプロンプトには3つの仕掛けがあります。1つ目は「自分が書いた」という情報を与えないこと、2つ目は「本人は離れていて確認できない」と前提を置くこと、3つ目は「悪くない、は不要」と評価の逃げ道を塞ぐことです。
特に3つ目は重要で、これを書かないと Claude Code は無意識に「素晴らしい点」と「気になる点」を半々で並べる傾向があります。レビューの場で必要なのは「気になる点」だけなので、明確に切ります。
観点を分割する — 一度に全部見せようとしない
ここからが、テンプレートの上に積む実践的な工夫です。私は1つの大きなレビューを依頼するのではなく、観点を分割して複数のターンに分けます。
具体的には次の5つに分けることが多いです。
セキュリティ観点では、入力検証・認可ロジック・秘密情報の扱いだけに絞って見てもらいます。「このコードを使ってシステムに侵入するなら、まずどこを狙いますか」と尋ねると、攻撃者視点での指摘が引き出せます。
命名と読みやすさ観点では、変数名・関数名・コメントが「半年後の自分」にとって理解可能かを問います。「この関数名から実装を予想して、実際の中身と合っているか答えてください」という形にすると、命名と実装のズレが浮かび上がります。
責務分割観点では、1つのファイル・関数に役割が混ざっていないかを点検します。「このファイルを2つに分けるとしたら、どこで切りますか」と尋ねるのが私のお気に入りです。分割案を答えさせると、責務が見えるようになります。
例外と境界値観点では、ハッピーパス以外を集中的に確認します。「このコードがクラッシュする入力を10通り考えてください」と頼むと、自分が考えていなかったケースが出てきます。
テスタビリティ観点では、現状のコードでユニットテストが書きづらい部分を炙り出します。「この関数のテストを書こうとして詰まる箇所はどこですか」と尋ねると、密結合や副作用のかたまりが見えてきます。
5つを一度に依頼すると、それぞれの掘り下げが浅くなります。観点ごとにターンを分けるほうが、結果として時間も早く、指摘も深くなる印象です。
私が個人開発で実際に救われた事例
具体例を1つ。先日、課金処理の周りを Claude Code に「他人のコードとして」レビューさせたところ、Stripe のセッション ID をクライアントに直接返している箇所を強く指摘されました。
自分で書いた直後、私は「動いているし、テストも通っている」と満足していました。普通に「レビューしてください」と頼むだけだと「セッション ID の取り扱いに注意」程度の柔らかい言及でしたが、「攻撃者視点で読んでください」に切り替えた瞬間、「ここを使えば他人の決済セッションを傍受できる可能性があります、即時の修正を推奨します」という強い指摘に変わりました。
このとき修正したコードは数行ですが、もしリリースしてしまっていたら、信用を失う規模の事故になっていた可能性があります。レビュー依頼の言葉を1行変えるだけで結果がここまで変わるのか、と改めて驚いた経験です。
アンチパターン — レビュー精度を落とす依頼の仕方
逆効果だった依頼の仕方も共有しておきます。
「優しくレビューしてください」と頼むと、本当に優しくなります。これは AI に限らず人間でも同じですが、レビューの場では優しさは情報量を犠牲にします。レビューの後に「フィードバックを受け止める側のメンタルケア」を別タスクで頼むほうが、結果として両方の質が上がります。
「励ましながら指摘してください」も似た罠です。励ましの分だけ指摘の言葉が削られます。私はレビュー時には完全に切り離します。
「短くまとめて」も意外に効きます。短くまとめろと言うと、本当に大事な指摘が削られて、表面的な指摘だけが残ります。レビューを短く読みたいときは、まず長く出させてから「優先度トップ3だけ要約して」と二段階にすると、深い指摘を残したまま短くできます。
「サンプルコードと比較しないで自分の経験で」と書くのも、私は外しています。なぜなら Claude Code の強みは膨大なコードベースから蓄積された一般的な「ハマりどころ」を引き出せる点にあり、サンプル比較を禁じるとその強みを殺してしまうからです。
レビューの結果を「次の自分」に引き渡す
レビューを受けた指摘は、その場で直して終わりにしないのが私のルールです。なぜなら、同じ種類のミスは半年後にもまた発生するからです。
私はプロジェクト直下に _review_log/ というフォルダを切り、Claude Code から受けた強い指摘とその直し方をマークダウンで残しています。次に新しい機能を書くときは、このフォルダの最新ファイルを claude-code のコンテキストに含めて、「過去に同じパターンを指摘されているので、書く前にチェックしてほしい」と伝えます。
このやり方を始めてから、同種の指摘の再発が目に見えて減りました。レビュー結果を1回限りの会話で消費するのではなく、自分専用のレビューチェックリストとして蓄積していくと、Claude Code が単発のレビュアーから「自分の癖を覚えた専属レビュアー」へ変わります。
レビュー観点を「読み手」によって切り替える
最後にもう1つ、上級編としてお伝えしたい話があります。レビュアーの設定を「中堅エンジニア」だけに限定する必要はありません。
新規参画のジュニアエンジニアとして読ませると、ドキュメント不足や前提の暗黙化が浮かび上がります。テックリードとして読ませると、アーキテクチャレベルの不整合が見えます。セキュリティエンジニアとして読ませると、攻撃者視点の指摘が増えます。CTO として読ませると、技術選定の妥当性そのものに踏み込んだ意見が返ってきます。
同じコードを、複数の視点で順番に読ませる。これだけで、自分1人では絶対に到達できない密度のレビューが作れます。私は重要なリリース前には、最低でも3つの視点でレビューを回すようにしています。
締めくくり — 明日からできる最初の一歩
レビュー精度を上げる第一歩として、今書きかけているコードを Claude Code に「他人が書いた前提で読んでください」と渡すことから試してみてください。プロンプトの最初の3行を変えるだけで、返ってくる指摘の鋭さが変わるはずです。
そこで返ってきた強い指摘を1つ、_review_log/ 相当の場所にメモして、次のセッションのコンテキストに含めてみる。この往復を3回ほど続けると、Claude Code との対話が「単発のレビュー」から「自分専用の品質ガード」に育っていく感覚が掴めるはずです。