AIのせいでレビューが壊れてきている
コードは綺麗だ。テストも通っている。でも「なぜこの実装にしたのか」と聞くと、答えられない。
これは最近、開発現場でじわじわ増えている現象だ。AIがコードを書くようになって、「動くけど理解していない提出」が表面化しやすくなった。以前なら、たどたどしくても本人なりの設計の痕跡があった。AIが書いたコードをそのまま出してくる場合、その痕跡がそもそも存在しない。
エンジニアの taka_tech1988 氏がZennに投稿した記事「AIに説明させるな、質問させろ——『分かって出す』を仕組みにする理解度ゲート」は、この問題に対して「禁止でも諦めでもない第三の道」を提示している。記事はまだ「設計段階」と明示されているが、その発想の構造が実務的に面白い。
問題の核心：理解しているかは、機械では検出できない
記事が指摘する実害は2つある。
ひとつはバグの温床になること。理解されないままマージされたコードは、後から誰も原因を追えない。「ここ、どういう意図で書いたんだっけ？」が誰にも答えられない状態で、本番のコードベースに積み上がっていく。
もうひとつはエンジニアが成長しないこと。設計を判断する、トレードオフを選ぶ、という思考の訓練が行われないまま、アウトプットだけが出続ける。これは本人にとっても組織にとっても損失だという指摘は、正直なところかなり同意できる。
問題をより難しくしているのは、「型エラーはlintで捕れる。規約違反も静的解析で弾ける。でも『本人がこのコードを理解しているか』は、コードを見ただけではわからない」という事実だ。理解していようがいまいが、出てくるコードは同じ。だからこそ、長年「レビューで人が口頭で確認するしかない」という属人的な運用が続いてきた。
提案の中身：AIに「説明」ではなく「質問」を生成させる
記事の核心は発想の転換にある。
普通のAI活用は「このコードを説明して」と聞くことだ。だがそれでは、AIが流暢な説明を生成してしまい、本人の理解度は相変わらず不明のまま。しかも「AIが書いたコードを、AIが説明し、それを提出者が読む」という二重の丸投げになる。
ここで提案されているのが逆の使い方だ。AIにコードを説明させるのではなく、質問だけを生成させる。
記事に示されているClaude Codeのカスタムコマンド /explain-check はこう動く。
「現在の git diff を読み、この変更の『なぜ』を問う質問を10個生成せよ。コードの解説・要約は一切するな。質問だけを出力する。」
質問の配分まで指定されている点が細かい。設計選択の理由×3、代替案と却下理由×2、境界条件・失敗時の挙動×2、壊しうる箇所・副作用×2、テストの保証内容×1。さらに各質問は「ファイル名:行番号や関数名を指す具体的なもの」で、一般論は禁止と制約されている。
そして末尾に1行、こう添える。
「自分の言葉で即答できないものは、まだ理解できていない箇所」
これを提出前のセルフゲートにする。答えられないなら、提出するな、という設計だ。
PRテンプレートにも仕掛けがある。「AI支援を使った（使った場合、全行を理解し自分の言葉で説明できる）」「/explain-check を実行し全質問に即答できることを確認した」というチェックボックスを設け、本人に確認の意思表示をさせる。「自分の言葉で。AI生成文のままは不可」と明記することで、説明文をAIに書かせるという逃げ道も塞いでいる。
ここからは見方だが——この発想が持つ構造的な意味
この提案が面白いのは、技術的な目新しさよりも**「仕組みの設計思想」**にある。
AIの利用が広がる中で、現場のマネージャーやリードエンジニアが取りがちな対応は2つだ。「AIを使うな」と禁止するか、「まあ仕方ない」と諦めるか。前者は機能しない。人はAIを隠して使い、バレないように使い、結果として質がさらに落ちる。後者は問題を放置する。
この提案は「AIは使え、ただし分かった上で出せ」を仕組みで担保しようとしている。AIを使ったかどうかは問わない、「説明できるか」だけを問う。これは取り締まりではなく、理解を促す装置として設計されている。
もうひとつ、構造として重要な点がある。記事の著者が言う「口頭でやっていたことを仕組みに昇格させる」という視点だ。レビュアーがボトルネックになって一人ひとりに「なんでこうした？」と聞いて回る、というのは非常に属人的な運用だった。その確認プロセスを、提出前の自己ゲートとして自動化することで、レビュアーは「本当に必要な設計判断のレビューに集中できる」ようになる。
著者が「目標は私が暇になること」と言っているのは冗談ではなく、シニアエンジニアやマネージャーのリソース最適化という実務的な問題意識が背景にある。
実務的な示唆と、残る論点
これをそのまま自分のチームで使えるか、というと、今すぐではない留保がいくつかある。
記事自体が「まだ設計段階、チームへの展開はこれから」と明示している。実際に運用すると、チェックボックスの申告が形骸化するのは時間の問題だ。「確認した」とチェックするだけの儀式になり、実態を伴わなくなる。これはPRテンプレートに何かを追加するときの古典的な失敗パターンでもある。
さらに言えば、「10個の質問に即答できる」という基準は、個人の知識量や経験年数によってかなりブレる。ジュニアエンジニアと、5年目のエンジニアでは「即答できる」のレベルが違う。セルフゲートが「難しすぎる質問ばかりで毎回詰まる」ことで、提出への心理的ハードルが上がりすぎる可能性もある。
次に問題になるのはここだと思っている。仕組みとして設計するなら、「質問の難易度調整」「ジュニアとシニアで異なる基準」「形骸化したときのリセット方法」が実装上の論点になる。ツールを作ることより、運用を継続させることの方が難しいのは、いつもそうだ。
ただ、発想としては使える。Claude Codeに限らず、GitHub CopilotやCursorでも、「説明させず質問させる」プロンプトを自分のワークフローに組み込むことは今日からでもできる。ツールの問題ではなく、問いの設計の問題だからだ。
まとめ：「説明を求める」から「問いを受け取る」へ
AIが生成するコードの品質が上がれば上がるほど、「理解していないコードが綺麗に動く」という問題は深刻になる。これは個人の怠慢の話ではなく、ツールの構造が変わったことによる必然だ。
その問題を「禁止」でも「諦め」でもなく解こうとするとき、「AIに何をさせるか」の設計が問われる。説明を出力させれば理解の代替になる。質問を出力させれば理解の鏡になる。この違いは小さいようで、使い手の成長にとっては大きい。
試してみる価値はある。少なくとも、自分のコードに対して「レビュアーが聞くであろう10の質問」を受け取ってみることで、自分の理解のどこが薄いかは見えてくる。それだけでも、AIとの付き合い方が少し変わる。
