こんにちは。開発チームでエンジニアをしている森本です。
皆さんは日々の開発でコードレビューをしていますか？
kickflowでは、開発フローにコードレビューのステップを組み込んでおり、ほとんどすべてのコードでレビューが実施されます。しかし、このコードレビューは多くの企業で共通の課題となっているように、非常に負荷の高い作業です。複数の観点から品質に対する責任を伴うため、有識者が中心となって行うことが多く、開発のボトルネックになりやすい傾向があります。一方で、コードレビューを怠るとプロダクトの品質を担保できず、不具合や仕様齟齬が発生するリスクが高まります。
本記事では、弊社でのコードレビューへの取り組みについて、レビュアーの視点からご紹介します。この記事は2025年6月現在の情報です。
kickflowでのコードレビューへの取り組み
kickflowでは、コードレビューの負荷を軽減し、開発者体験とプロダクト品質を両立させるために、さまざまなツールや仕組みを導入しています。今回はその中から4つの取り組みをご紹介します。
1. Linterによる静的解析
まずはオーソドックスなところからですが、Linterの活用はコードレビューの基本だと考えています。
kickflowでは、サーバーサイド（Ruby on Rails）ではRuboCop、フロントエンド（TypeScript）ではESLintを導入しています。一部、プロジェクト独自のルールを追加していますが、基本的にはコミュニティで広く使われているルールセットをベースにしています。
これにより、コーディングスタイルや規約に関する細かな指摘を、人間がレビュー時に行う必要がなくなります。これらのチェックはGitHub Actionsで自動化されており、Pull Requestを作成した時点でレビュイーもレビュアーも機械的な問題を把握できる仕組みです。
2. GitHub Copilotによるレビュー
GitHub Copilotにも、コードレビューを支援する機能があります。Pull RequestのReviewersにcopilotを追加するだけで、AIがレビューコメントを付けてくれます。
現状では、プロジェクト固有のコーディング規約や設計思想を細かく設定できないため、その効果は限定的です。しかし、一般的なバグや改善点の指摘には役立つ場面もあります。kickflowのリポジトリでは、より高度なカスタマイズ機能が有効化され次第、本格的な活用を検討していきたいと考えています。
3. CodeRabbitによるAIレビュー
次に紹介するのが、AI Code ReviewツールであるCodeRabbitです。
CodeRabbitを導入すると、Pull Requestが作成された際にAIがコードを分析し、行単位で具体的な改善提案をコメントしてくれます。
このツールの優れた点は、.coderabbit.yamlという設定ファイルに自然言語でレビュー基準を記述できることです。これにより、プロジェクト固有のルールをAIに学習させ、一貫性のあるレビューを実現できます。
以下は、kickflowで利用している.coderabbit.yamlのサンプルです。
path_instructions:
- path: "**/*.rb"
instructions: |
一般的なコードレビューの観点に加えて、Rubyのファイルは以下のようにレビューしてください。
# Rubyのコーディングについて
- 原則すべてのコードに対して、RSpecで単体テストが書かれているか確認してください。
- 例外を投げるときは、適切な例外クラスを投げてください。
...
- path: "**/*.ts"
instructions: |
一般的なコードレビューの観点に加えて、TypeScriptのファイルは以下のようにレビューしてください。
# TypeScriptのコーディングについて
- APIを呼び出すときに、適切な例外処理が実装されているか確認してください。
- interfaceではなくtypeを推奨します。interfaceは拡張できるため、意図しない型の変更が発生する可能性があります。
- URLのクエリパラメータを組み立てるときには、`URLSearchParams` を使用してください。文字列の連結やテンプレートリテラルでの組み立ては避けてください。
...
実は、CodeRabbitの導入は1年ほど前でしたが、当初は期待したほどの成果は得られませんでした。社内のエンジニアにアンケートを取ったところ、評価が分かれていたのが実情です。シーケンス図を自動生成してくれる機能は便利な一方で内容が不正確なこともあり、また、局所的な指摘が多く、プロジェクト全体の整合性を考慮したレビューは難しいと感じていました。
しかし、この1年でAIモデルが大きく進化したのか、最近では非常に的確で有用なコメントが増えてきました。レビュアーとしても、まずCodeRabbitの指摘内容を確認することで、レビューの観点を整理してから本題に入れるため、大変助かっています。
4. Claude Code GitHub Actionsによるレビュー
直近で導入した仕組みとして、Claude Code GitHub Actionsがあります。これは、Pull Requestのコメントから手動で実行できるレビューアクションで、個人的に非常に期待しているツールです。
このアクションは、Pull Requestのコメント欄でメンションすることで起動し、比較的短時間で精度の高いレビュー結果を返してくれます。具体的な活用イメージは、次のセクションで詳しくご紹介します。
AIによるレビューの具体例
ここでは、実際にAIがどのようにコードをレビューしてくれるのか、具体例を見ていきましょう。 今回はレビューのために、AIにコードレビューで指摘されるような「隙がある」コードを生成してもらいました。 このコードには、典型的なSQLインジェクションの脆弱性が含まれています。怖いですね。
レビュー対象のコード
class Api::V1::SampleController < Api::V1::BaseController
def index
query = params[:q]
@samples = Sample.where("title LIKE '%#{query}%' OR content LIKE '%#{query}%'")
render json: @samples
end
end
Claude Code GitHub Actionsのレビュー結果
このコードに対してClaude Code GitHub Actionsを実行した結果、以下のようなレビューコメントが生成されました（一部を抜粋・要約しています）。
ここまでのPull Requestがレビューに上がってくることはないですが、セキュリティの脆弱性からパフォーマンス、さらには独自に定めたルール（rbs-inline）まで、的確に問題を指摘してくれているのがわかります。私自身も、この結果をざっと確認してからレビューを始めることで、観点の抜け漏れを防いでいます。
CodeRabbitのレビュー結果
次に、CodeRabbitのレビュー結果です。CodeRabbitは、コードの該当箇所に直接コメントを付けます。
CodeRabbitも同様にSQLインジェクションの脆弱性を指摘しています。このように、特定の行に対してインラインでコメントが付くため、どの部分に関する指摘かが一目で分かりやすいのが特徴です。
まとめ
コードレビューは、プロダクトの品質を維持するために不可欠なプロセスですが、時間と専門知識を要するコストの高い作業でもあります。コードレビューを完全になくすことはできませんし、するべきではないと考えています。なぜなら、プロダクトの設計思想やビジネスロジックの妥当性など、最終的な判断と責任は人間が担うべきだからです。 しかし、今回ご紹介したように、レビュープロセスの一部、特に定型的・機械的にチェックできる部分をAIに任せることで、人間はより本質的で生産的な活動に時間を使えるようになります。 kickflowでは今後も、コードレビューに限らずAIを積極的に活用し、開発者一人ひとりがより創造的で生産性の高い仕事に集中できる環境を追求していきます。
最後に
kickflowでは、私たちと一緒にプロダクト開発を推進してくれる仲間を募集しています。 このような技術的な取り組みや、より良い開発プロセスを追求することに興味がある方は、ぜひ採用サイトをご覧ください。
