AI時代のコードレビューは「クラス図」のレビューに回帰する
はい、どうもこんにちは佐藤です！
最近、AI にコードを書かせていて、しみじみ思うことがあるんですよね。
変数名の付け方とか、ループの回し方とか、早期 return がどうとか。かつてのコードレビューで散々指摘してきた、ああいう細かい話。
もう、どうでもよくなってきたんだわ。
AI が「距離の近い」クラスの中身を完璧に書いてくれる時代、私たちが本当に見るべきものは別のところにある。それは結局、昔ながらの「クラス図」のレビューに回帰していくんですよね。
なぜそう言えるのか。そして、その先に待っている厄介な問題について書いていきますね！
AI時代のレビューは「クラス図」のレビューになる
まず、何が起きているのか整理しましょう。
AI は、ひとつのクラスやひとつの関数の「中身」を書かせると、もはや人間より上手いです。エッジケースの処理、ガード節、命名。こうした「距離の近いロジック」については、レビューで指摘することがほとんどなくなりました。
では、レビューする意味がなくなったのでしょうか。違いますよね。
主戦場が移っただけです。
AI がローカルなロジックを保証してくれるなら、人間が担保すべきは、その外側――システムの「結合」と「契約」になります。このクラスとあのクラスは、どういう責務で、どんなインターフェースを通じて会話するのか。どこからどこまでがひとつの塊なのか。
これって、まさにクラス図が表現してきた世界そのものなんですよね。コードの行を追うレビューから、構造を俯瞰するレビューへ。AI 時代のレビューは、クラス図のレビューになるのです。
「プログラムの距離」が契約の厳密さを決める
ここで鍵になるのが、私が「プログラムの距離」と呼んでいる概念です。
プログラム同士には、距離があります。距離が遠いほど、その間で交わす「契約」は厳密でなければなりません。
たとえば、フロントエンドとバックエンド。両者は別プロセスで動き、ネットワークを越えて会話しますよね。距離はかなり遠い。だから API という契約は、型もエラーも含めて、徹底的にカチッと固める必要があります。
一方で、同じクラスの中のメソッド同士。これは距離がほぼゼロです。ここの契約をいちいち厳密に定義しても、過剰なだけですよね。
クリーンアーキテクチャを思い浮かべてください。進行役であるアプリケーションサービスと、ビジネスルールを宿すドメインサービス。この 2 つの間には、明確な境界線が引かれています。あるいは DDD でいう「境界づけられたコンテキスト」を、システムのどこに引くのか。
これらはすべて、「距離に応じて、どこに契約の壁を立てるか」という設計判断なのです。
そして面白いことに、AI はこの判断が苦手です。与えられた枠の中でコードを書くのは天才的。でも、その枠＝境界線そのものを引く作業は、依然として人間の領域なんですよね。どこに線を引くべきかは、業務の本質をどう捉えるかに依存します。コードの外側にある問題だからです。
クラス図は「AIへのプロンプト」として復権する
さて、「クラス図のレビューに回帰する」と言うと、嫌な顔をする人がいます。
わかります。かつて SIer の現場で描かれていた、あの Excel 方眼紙に詰め込まれた重厚長大な UML。更新されないまま腐っていく、形骸化したドキュメントの山。あの時代に戻りたいわけじゃない。
戻りません。これからのクラス図は、役割がまるで違うのです。
かつてのクラス図は、人間が人間に読ませるための「仕様書」でした。これからのクラス図は、**人間が AI に食わせるための「プロンプト」**になります。
Copilot や Cursor に、コンテキストとして制約を与える。「このドメインモデルの構造を守って実装して」と。Mermaid や PlantUML で記述された軽量なドメインモデルこそが、人間と AI が共通言語としてやり取りする、現代の「設計図」なのです。
テキストで書けるから、差分も取れる。コードと一緒にリポジトリで管理できる。腐ったら気づける。重厚長大な UML とは、似て非なるものですよね。設計の意図を AI に伝える制約として、クラス図は復権するのです。
良い設計を引く力は「阿頼耶識」から生まれる
ここまでは、わりと明るい話でした。
問題はここからです。じゃあ、その良いクラス図を、誰がどうやって引けるようになるのか。
正直に言いましょう。良い境界線を引く力は、知識として教わって身につくものではありません。あれは、過去の痛みを伴う失敗の蓄積から生まれます。
密結合なコードを書いてしまって、仕様変更のたびに地獄を見た。あちこちに影響が飛び火して、徹夜でスパゲティを解きほぐした。「二度とこんな設計をするものか」と骨の髄まで刻まれた。
そういう無数の失敗が、無意識の判断力として沈殿していく。私はこれを、仏教用語を借りて 「阿頼耶識（あらやしき）」 と呼んでいます。言葉にできないけれど、図を見た瞬間に「これは危ういぞ」と肌で感じる、あの感覚です。
ベテランがサッと引く境界線の裏側には、この阿頼耶識があるんですよね。
「高速な失敗」という幻想――AIは若手を甘やかす
では、若手にどうやって設計を教えるか。
ここで、ひとつ妙案が浮かびます。「わざと AI に悪いクラス図を渡して、仕様変更でシステムが破綻するのを、高速で疑似体験させればいいのでは？」と。失敗から学ぶのが大事なら、その失敗を AI で爆速に回せばいい。一見、賢いアイデアですよね。
でも、これは機能しません。理由は単純で、痛みがなさすぎるからです。
考えてみてください。密結合な設計のせいでコンテキストが肥大化し、トークン消費が跳ね上がったとします。でも、その請求書を払うのは会社です。若手エンジニアの懐は、一円も痛みません。
修正でスパゲティコードが生まれても、「このバグ直して」と AI に投げれば終わりです。AI は文句ひとつ言わず、なんとか動くように直してくれる。かつて私たちが、自分の手で、徹夜で、呪いの言葉を吐きながら解きほぐした、あの physical な痛みがどこにもないのです。
痛くない失敗は、阿頼耶識に沈殿しません。AI は、コードという泥臭いレイヤーの痛みを、すべて肩代わりしてしまう。良かれと思って、若手を甘やかしてしまうんですよね。
最後に残る壁は「仕様の理解」に遡る
AI がコード修正の痛みをすべて吸収する時代。それでも、設計の破綻が唯一、人間に牙を剥く瞬間があります。
それは、「そもそもドメインの捉え方が間違っていた」と気づくときです。
クライアントの真の要求と、AI が生成したシステムとの間に、どうしようもないズレが生じる。ここに至ると、コードの表面的な修正では、もうどうにもなりません。境界づけられたコンテキストを引き直し、概念モデルから作り直すしかない。「ドメインの深い理解」が、最後の最後で要求されるのです。
ところが、ここで詰むんですよね。
コードレベルの小さな失敗――距離の近い痛み――を一度も経験せずに育った若手が、いきなりこの抽象度の高い「仕様理解の壁」を越えられるでしょうか。
階段を一段ずつ上ってきた人間なら、登れます。でも AI 時代の若手は、その下の階段を AI にスキップさせられている。土台となる阿頼耶識がないまま、いきなり最上階の難問に放り込まれるのです。これは、かなり酷な話ですよね。
まとめ
というわけで、AI 時代のレビューはクラス図のレビューに回帰していくよ！って話でした。
あ。正確には、コードの中身は AI に任せて、人間は境界と契約を見る って感じですねっ。
そこまでは、まあ間違いないと思っています。問題はその先です。クラス図を引くための「阿頼耶識」を、どうやって次世代にインストールするのか。
かつて私たちは、バグと仕様変更の嵐に揉まれ、コードという泥臭いレイヤーで失敗を繰り返しながら、無意識のうちに設計の感覚を育ててきました。でも AI がコードを書き、AI がコードを直す時代。私たちは「実装」という下積みをスキップさせて、いきなり「設計」と「仕様のモデリング」を若手に要求することになります。
しかも、AI なしでコードを書かせる予算も時間も、もう現場には残されていません。経営は効率を求めます。「あえて失敗から学ばせる」なんて贅沢は、許してくれないのです。
正直、この問いの答えは、私もまだ見つけられていません。やっぱり、この問題はとても難しい。みなさんは、どう継承していきますか。