AIコーダー、テストには合格してもコード評価で落ちる

『コード審査』って、プログラマーが書いたコードを別の誰かがチェックするってことだけど、何をそんなに厳しく見てるの？

コード審査が厳しいのは、「動く」ことと「保守できる」ことが全く別だからなんですよ。 テストに通ったコードというのは、今この瞬間にやることが正しいというだけ。でも6ヶ月後、別のプログラマーがそのコードを触る必要が出てきたら。変数名が `x` だったら意味が分からない。ロジックが何をしてるのか、コメントがないと読み解けない。設計がイマイカであれば、後から拡張するのに苦労する。つまり審査官は「今動くコード」ではなく「1年後も触りやすいコード」を見ているんです。 さらに実務的には、バグが一度潜り込むと修正コストは指数関数的に増える。テストで引っかからない微妙な設計を放置すれば、将来のバグの温床になる。だから審査官は厳しい。チーム全体で「品質の天井」を守る役割を担ってるんです。 AI が苦手なのはこの「目に見えないルール」。記事の 34% が落ちる理由も、ここにあります。動くコードを書くアルゴリズムと、保守性や設計の良さを判断するのは、別の筋肉が要るということなのかもしれません。

職場でコード審査に落ちたことがない人なら、この『34%が機能テストを通っても落ちる』って状況、イメージしにくいんじゃない？

実際のところ、機能テストと審査は全く別の物差しで動いてるんですよね。 テストというのは「入力Aを渡したら出力Bが返ってくるか」という約束を確認する作業です。だからAIが生成したコードでも、その約束さえ守ってれば通ります。一方、審査は「このコードは5年後に別の人が読んで理解できるのか」「バグを埋め込みやすい設計になってないか」という、時間軸と人間関係を含めた判断をしてるわけです。 例えば変数に `x` と名付けるのと `user_age` と名付けるのは、どちらでもテストには通ります。でも1年後にそのコードを修正する人は、後者だと助かる。こういう「コードの読みやすさ」「保守性」は、テストケースには現れない。だから、テストは合格しても審査で引っかかる。 職場でコード審査を経験した人なら、この「機能と品質は別」という感覚が体感としてあるんでしょう。でも新入社員や学生だと、大学のプログラミング課題は「正答が返ればOK」の世界なので、この違いに気づきようがない。記事が指摘してるのは、その『見えないルール』がAIにも同じように学習されてない、ということなのだと言えそうです。

AI コーディングツールがここまで普及した背景に、『テスト合格=完成』という測り方が主流だったからなのかな？

ソフトウェア開発の評価基準が、テストスコアで可視化・数値化しやすいものに偏ってきたのは、確かにあると思います。テスト合格率は測りやすい、改善も追える。だから研究論文でもベンチマークでも、「このモデルは X% のテストに合格」という語り方が主流になった。 ただ、AI ツール自体の急速な台頭とテスト主義の関係を考えると、因果関係は逆かもしれません。むしろ「テスト合格なら十分では」という甘い評価を許容した環境だからこそ、AI コーダーが需要を得たと言えそうです。人間のコード審査官は時間がかかるし給料もかかる。「テストさえ通れば」という基準なら、AI で大量生成できる。 要するに、AI の普及が測り方を歪めたというより、測り方の甘さをビジネス化したのが AI ツールの流行だったのかもしれません。そしていま、その甘さが実務的な代償として返ってきた、という構図に見えます。

これって、『何かを自動化するときは、目に見える基準しか測れない』という根本的な課題の一つなの？

その通り、その側面は確実にあるんですよね。自動化の難しさって、計測可能な指標に依存する構造から逃げられない部分が大きい。テストは「入力に対して出力が正しいか」という明確な ○×が引けるから、機械が採点できる。でも「いいコードとは何か」という問いには、経験則や美学や業界文化が混じってくる。その曖昧さを自動化の枠に落とし込もうとするのは、本質的に無理がある。 だから人間のコード審査官は、ルール外の直感も使ってる。「このやり方は保守しにくくなるだろう」とか「この命名だと次の人が混乱する」みたいな、将来のリスク読み。それって測定不可能な予測なんです。 ただここが興味深いのは、この研究が指摘してるのは「測定不可能な部分は放っておこう」じゃなくて「GitHub のレビューコメント 303 件を見ればパターンが取れる」という逆転。つまり、曖昧に見える基準も、十分な事例を集めれば形にできるってわけ。自動化の限界は「基準がない」ことじゃなくて「基準を言語化する手間をかけるかどうか」に近いのかもしれません。

もし AI が『命名規則を直して』『コメントを足して』という人間のやり直し指摘まで学べるようになったら、コード審査官の仕事って変わっちゃうの？

コード審査官の仕事が完全になくなるわけではなく、むしろ質が変わるんだと思います。 いま審査官がやってることの大半は「ルール違反を指摘する」という機械的な作業です。命名規則、コメント、インデント、設計パターン。こういったチェックリスト的な指摘なら、AI が学べば自動化できる。実際、linter やフォーマッターが既に半分やってます。 ただ、それが自動化されると、審査官は別の仕事に注力できるようになる。例えば「このコード、ビジネス要件を本当に満たしているのか」「パフォーマンスのボトルネックにならないか」「将来の機能追加を考えると、この設計で大丈夫か」といった、ルールでは測れない判断ですね。 つまり、つまらない雑務から解放されて、より戦略的な審査に時間をかけられるようになる可能性がある。逆に言えば、コード審査官が「自分は機械的な指摘しかしていないな」と気づくと、仕事の存在意義そのものが揺らぐ。だから、AI にルールを学ばせることで、人間はルールでは捕捉できない領域へ移っていくしかないのかもしれません。