最近はClaude Codeでしかコードを書いていない。1月に対して2月は自分が関わったプルリクエストの量は3倍になったらしい。
コードを出力するスピードが上がっているのであれば、コードレビューがネックになるでしょう！と思って、Claude Code ActionによるAIレビューを導入してみたのだがあまりしっくりきていない。
考えてみると、コードレビューの何をAIに期待しているのかを自分の中で整理できておらず、期待しすぎてるかもと思ったので整理してみる。
コードレビューの目的と役割分担
コードレビューの目的はかなり多いし、人や組織やプロダクトによっても異なりそう。例えば、検査の観点でいえばバグ発見、コードの質、テストの質などがあるし、チームメンバーと話して疑問をはっきりさせたり、共通認識にしたりする場でもあるみたいな話もあるだろう。
Coding Agent登場以前は、これらすべてを人間がやっていたのかでいえばそうではなくLinterに頼ってもいた。Linterは、答えが明確になっているルールに沿って警告やエラーを出す。
人間とAIは同じ入力に対して異なる結果を返す可能性があるが、LinterやTestは同じ入力に対して常に同じ結果を返す。それを踏まえると以下のような役割分担になるのではないか。
- 答えが明確でルール化できる → 主にLinter / Test
- まだ答えがないので人間の判断が必要 → 主にAI
- 判断・確定 → 主に人間
Linterによるレビュー
スタイル・フォーマット・命名規則みたいなのは当然として、依存方向の違反や禁止されたimportのようなアーキテクチャルールも明文化できるならLinterに寄せられる。
言語イディオムレベルの冗長なコードもLinterが得意。Dartは、関数参照（tear-off）で書けるのにラムダ式を使っている箇所を検出するルール のunnecessary_lambdas とかそういうのがある。コードの質でいえばDart Code Metricsとかもある。
テストの質も頑張ればいける気がする。ミューテーションテストは、ソースコードを自動的に壊して（a > b → a < b など）テストを実行し、壊したのにテストが通ったらアサーションが甘いのでテストの質が低いねというのがわかる。*1
ルールとして明文化できるなら、まずLinterに寄せるのがよさそう。
AIによるレビュー
AIが扱うのは、Linterではルール化できないが人間に「確認してほしい」箇所。例えば
- 既存のコードと異なるパターンで書かれているがLinterは指摘していない
- テストが書かれていないが書かなくていいのか判断つかない
一方で、AIはAIが持つわずかなコンテキストを元に「このコードは怪しい」という確度を出しているだけなので、AIはバグや間違いっぽいものを検出するが「ここが間違いです」とは断定できない。加えて、人間の方がいろんな情報にアクセス出来るため、コンテキストを多く持っていて「あえてそうやっている」とか「別にそこまでやる必要ない」とかすでに判断していることが多い気がする。
AIがアクセス出来る場所にコード以外のコンテキストも含めていくのが必要で、難しければAIには暗黙知っぽいところを指摘してもらうくらいしか出来ないのではなかろうか。
人間によるレビュー
AIによるレビューで書いたことは、人間によるレビューにも言えるが、人間にしか出来ないことは、以下のようなものがある。
- 設計の妥当性の判断
- ビジネスロジックの正しさの判断
- AIの指摘に対する判断
- 知識共有の会話
判断するのは人間で決定したことをLinterで気付けるようにしていくみたいなのをAIに指示するのも人間ですね。
まとめ
Claude Code Actionでのコードレビューは、Linterでやるべきことも指摘しようとしていたからしっくりこなかったんだとおもう。
今まであんまりやりきれてなかったLinterカスタムルールなどを色々整備していくことが今後重要になっていくだろうし、Coding Agentによってそれがしやすい環境になってきた。加えて、AIは答えが不確定で、チューニングや期待値の調整が必要なため効果が読みにくい。Linterで地盤を固めたりリポジトリ内にコンテキストを持てるようになった上でAIによるレビューを導入するか、さくっと使えるGithub Copilotでレビューしたりするほうがよさそうではある。
いま悩ましいのは、custom_lintを使わずにカスタムルールを書くにはanalyzerのアップデートが必要で、そのためにはRiverpodのアップデートやcustom_lintからの移行を真面目に考える必要があるということ！やるしかねえ
