Atsushi Nakatsugawa
July 17, 2025
1 min read
Share
Cut code review time & bugs by 50%
Most installed AI app on GitHub and GitLab
Free 14-day trial
Good code review advice doesn't come from threads with 🚀 in themの意訳です。
かつてコードレビューは静かで品のある儀式のようなものでした。非同期でじっくり（あるいはパッシブアグレッシブに）フィードバックを送り、ときどき「nit: この変数名を変えてみては？」とコメントして自己満足する、そんな時間でした。しかし、ソーシャルメディアが登場してから状況は一変しました。今や開発者たちはホットな意見をSNSで発信し、その多くは「他人と一緒に働いた経験がないのでは？」と思わせる内容ばかりです。
一方には「とりあえずマージして後で直せばいい」と主張するX（Twitter）インフルエンサーがいます。イテレーション（とダウンタイム）が命だそうです。もう一方には「本物の開発者はコードレビューなんて不要、チームを信頼すべき」と語るLinkedInのグラインド系がいます。
そして、トラウマが伝統にすり替わったようなアドバイスも。「うちのチームは毎週金曜にライブでお互いのコードを酷評します。これで人間力が鍛えられます」とか「対面でしかコードレビューしません。誠実さが保たれます」など。要するに、コメント欄を公開処刑の場に変えただけです。なかなか大胆な戦略ですね。
インフルエンサーが開発サイクルに与える影響をコミカルに描いたのが、私たちが作成したコミック『バスローブインフルエンサーの戦い』です。今タイムラインに溢れる様々なコードレビュー論争と、それを本当にチームが全部真に受けて実践したらどうなるかを、ユーモラスに表現しています。このコミックの制作でインフルエンサーは傷つけていません…たぶん。
CodeRabbitは、良いコードレビューのマナー論争が大好きですが、同時にコードを出荷することや、同僚のメンタルを守ることも大切にしています。そこで、タイムラインでよく見かける「イマイチなコードレビュー論」と、その代わりに実践したい方法をまとめました。これを読めば、チームメンバーがあなたのリポジトリ追放を密かに画策する心配も減るはずです。
「WIP – とりあえず今はマージします」と書かれたプルリクエストを見たことがあれば、「とりあえずマージ」派の開発者ということでしょう。彼らは「とにかく早く出して、全部壊して、後で直せばいい」という流派の信者です。品質がどうであれ、とにかく出荷するのが強みで、後で直すのがアジャイルだと信じています。
しかし、実際に「後で直す」ために悪いコードをマージすると、たいてい直されません。誰も直しません。そのまま本番環境に行き、壊れます。そして、あなたの同僚が日曜の夜に謎のバグをデバッグしながら、あなたの名前を呪文のようにささやく羽目になります。
もし開発をスピードアップしたいなら、「とりあえずマージ」よりも良い方法があります。それは、自分のコードを他人にレビューしてもらう前に一度自分で見直すことです。新鮮な目で読み返し、意味不明なロジックや不要なコードを整理しましょう。そして、CodeRabbitのようなAIレビューアをIDEで使うことで、うっかり恥ずかしいミス（使っていないライブラリをimportするなど）も防げます。
もう一つよくあるのが、「スタッフエンジニア Lv.4」になったらコードレビューは不要、という考え方です。自分はもはや人間には理解できないレベルに達したので、誰にもレビューされる必要がないと信じています。
このマインドセットは、シニア開発者を「レビュー不可能な魔法使い」に変えてしまいます。彼らはアーキテクチャのサイドクエストに消え、数週間後に2,000行のPRと「大丈夫、テスト済みです」という言葉と共に戻ってきます。
実際は、シニアであればあるほどコードレビューは重要です。なぜなら、あなたの仕事はより影響力が大きく、複雑で、今後の基盤になるからです。そのコードに問題があれば、将来の開発者が苦しむことになります。
また、コードレビューは双方向です。シニアエンジニアは建設的なフィードバックの仕方を示したり、アーキテクチャの背景を共有したり、丁寧なコメントで後輩を指導できます。逆に、ジュニアが素朴な疑問を投げかけたり、独特な変数名に気付いたりして、シニアが学ぶこともあります。どのレベルでもレビューを当たり前にしましょう。
最近、「コードレビューで細かい指摘をするのはマイクロ・アグレッション（重箱の隅をつつく攻撃）だ」という意見が増えています。変数名の変更や30行の関数を分割する提案をすると、創造性を妨げたり、無駄に開発を遅らせていると受け取られることもあります。確かに、空白や「utils」か「helpers」かなど、どうでもいい指摘が14件も来たら嫌になります。しかし、すべての細かい指摘が無意味なわけではありません。
実際、「小さなこと」とされる多くは本当は小さくありません。可読性の小さな傷が積み重なり、コードベースは内側から腐っていきます。分かりにくい名前や一貫性のない構造、場当たり的な例外処理が積み重なると、デバッグは「心理的ホラー」と化します。
とはいえ、細かい指摘が攻撃のように感じられてはいけません。目的はスタイルガイドの知識をひけらかすことではなく、次の人（さらにその次の人）が理解しやすいコードにするためです。パッシブアグレッシブなLinterのような口調にならないようにしましょう。
まずは、基本的な指摘は本物のLinterに任せましょう。たとえばCodeRabbitには30種類以上のLinterが内蔵されているので、インデントやセミコロンなどの指摘に脳のリソースを使わずに済みます。その分、ロジックや可読性、アーキテクチャなど、人間にしかできない部分に集中できます。
プルリクエストの良いところは、夜10時にスウェット姿で、スナックをかじりながら、ひとり静かにレビューできる点です。逆に最悪なのは、突然Zoomに呼び出されて「みんなであなたのコードを見てみましょう」と画面共有されることです。
ライブコードレビューは、コラボレーションや「文脈共有」として導入されがちですが、実際は尋問とパフォーマンスアートの中間のようなものです。自分の関数がオークションのようにスクロールされ、他の開発者が「自分もそこ気になってました」と追い打ちをかけてきます。
特にジュニアや内向的な人、公開コード解剖が苦手な人にはつらい時間です。正直なフィードバックがしづらくなり（CTOの前で「ここ分かりにくい」とは言いにくい）、みんなのカレンダーも圧迫されます。3つの非同期コメントで済む話が、45分の会議と存在意義の危機に変わります。
ライブレビューにも適切な場面はありますが、「毎スプリント必ず」ではありません。オンボーディングや大規模なアーキテクチャ変更、ポストモーテムなど、意図的に使いましょう。実施する場合は、事前に予告するのがマナーです。
開発現場が混沌とする中、AIがカフェイン漬けのインターンのように登場しました。AIコーディングツールは強力ですが、同時にカオスです。動くコードを出してくれる一方で、架空の関数を混ぜてくることもあります。
実際、5,000行のPRにfoo7という変数や、謎のタイムアウト、税金をメタファーだけで説明したようなロジックが混じっているのを見たことがあります。たまにコンパイルも通りますが、AIアシスタントがロジックバグや重複コード、AIにしか理解できない関数を紛れ込ませていないとは限りません。
AIツールは助けになりますが、批判的思考を手放してはいけません。「プロンプトを投げて、コミットして、ランチに行く」だけのワークフローなら、あなたも問題の一部です。AIが書いたコードは必ず見直し、リファクタし、正気かどうか確認しましょう。そして、マージ前にローカルでAIレビューを走らせてください。
CodeRabbitのIDE内AIレビューアなら、多くの問題をチームメイトが気付く前にキャッチできます。会議前にロボットが「チャック開いてるよ」と教えてくれるようなもので、上司に指摘されるよりずっと気楽です。
ここまで読んで「自分はどれにも当てはまらない」と思った方、おめでとうございます。では次のステップです。どうすれば「フィードバックをもらって嬉しい」と思われるレビュワーになれるのでしょうか。
まずは人間らしく。なぜそう思うのか、理由も添えて丁寧にコメントしましょう。
分かりにくい部分は、悪意や無能を疑うのではなく、素直に質問しましょう。
本当に巧みだったり美しい実装には、素直に「ナイス！」と伝えましょう。PRで「いい仕事ですね」と一言あるだけで、他のコメントが全部宿題の赤ペンでも救われます。
機械のエラー出力のような口調は避けましょう。フレンドリーなトーンで。絵文字も適度ならOKです（👀や🎉は効果的です）。
チームメイトがマージコンフリクトで泣いているときでも、ちょっとしたユーモアを添えるのもアリです。むしろ、笑わせてあげたいときこそ。
コードレビューの黄金律はシンプルです。「自分が受け取りたいフィードバックを相手にも送る」。そして、すべてのコメントにNotionドキュメントで変数名の哲学を反論しないこと。人生は短いのですから。
「悪いアドバイスをしないAIレビューアが欲しいですか？ IDEやGitプラットフォームでCodeRabbitを試してみてください
