「ここ、なんでこう書いたの?」
レビューで昔からよく聞いてきた質問だ。答えられない部下がいる。動くコードは書けている。でも、なぜその設計にしたのか、その場で説明できない。
「わかるまで考えて来い」と返す。これを何年もやってきた。
そして今、AIの登場で、この問題が一段と悪化している。
AI時代に「説明できない提出」が増えた
以前は、自分で書いたコードなら、たどたどしくても本人なりの理由があった。「とりあえずこう書いた」でも、考えた痕跡はある。
AIが書くようになって、そこが変わった。AIの出力をそのまま提出してくるケースが増えた。動く。テストも通る。でも「なぜこの実装か」を聞くと、答えられない。本人が書いていないから当然だ。
これが厄介なのは、表面上は問題なく見えることだ。コードは綺麗だし、動く。レビューで初めて「あ、これ本人わかってないな」と気づく。
何が問題か
説明できない提出には、2つの実害がある。
バグの温床になる
理解せずにマージされたコードは、後で誰も原因を追えない。何かあったとき「ここ、どういう意図で書いたんだっけ?」が誰にも答えられない。AIが書き、人が理解していないコードは、ブラックボックスのまま本番に積み上がっていく。
部下が成長しない
もっと根本的なのはこれだ。AIに丸投げしていると、考える力が育たない。「設計を判断する」「トレードオフを選ぶ」という、エンジニアの core の部分が鍛えられないまま、表面的なアウトプットだけが出続ける。
便利な道具を持った結果、成長が止まる。これは本人にとっても組織にとっても損失だ。
lint では捕れない
ここで困るのは、「理解しているか」は機械的に検出できないことだ。
型エラーは lint で捕れる。規約違反も静的解析で弾ける。でも「本人がこのコードを理解しているか」は、コードを見ただけではわからない。理解していようがいまいが、出てくるコードは同じだから。
長らく、これは「レビューで人が口頭で確認するしかない」と思っていた。自分がボトルネックになりながら、一人ひとりに「なんでこうした?」と聞いて回るしかない、と。
発想の転換：AIに説明させず、質問させる
仕組み化のヒントは、自分が口頭でやっていたこと——「意図を聞く」——そのものにあった。
普通にAIを使うと、「このコードを説明して」とお願いする。でもそれだと、AIが流暢な説明を生成してしまい、本人が理解しているかは相変わらずわからない。むしろ「AIが書いた説明をそのまま読む」という二重の丸投げになる。
逆だ。AIにコードを説明させるのではなく、質問だけを生成させる。
「この変更について、レビュアーが聞くであろう『なぜ』を10個生成しろ。コードの解説は一切するな。質問だけ出せ」
こうすると、提出者は自分の差分に対する鋭い問いのリストを受け取る。そして答えられない質問＝理解できていない箇所が、自分自身で可視化される。
これを提出前のセルフゲートにする。答えられないなら、提出するな。
/explain-check ── 質問だけ生成するコマンド
Claude Code のカスタムコマンドで実装するなら、こうなる。
---
description: 自分のPRにレビュアーが聞く「なぜ」を生成。答えられなければ提出するな
allowed-tools: Read, Grep, Glob, Bash
---
現在の git diff を読み、この変更の「なぜ」を問う質問を10個生成せよ。
ルール：
- コードの解説・要約は一切するな。質問だけを出力する。
- 配分：設計選択の理由×3 / 代替案と却下理由×2 /
境界条件・失敗時の挙動×2 / 壊しうる箇所・副作用×2 / テストの保証内容×1
- 各質問は具体的に（ファイル:行 や関数名を指す）。一般論は禁止。
末尾に1行：「自分の言葉で即答できないものは、まだ理解できていない箇所」ポイントは「コードの解説をするな、質問だけ出せ」という制約だ。これがないと、AIは親切に解説してしまい、ゲートとして機能しなくなる。質問に徹させることで、提出者の理解度を炙り出す道具になる。
PRテンプレートと組み合わせる
セルフゲートを「やったかどうか」も仕組みに組み込む。プルリクエストのテンプレートに、申告欄を作る。
## 何を・なぜ（自分の言葉で。AI生成文のままは不可）
- 解決する課題 / なぜこの方針か（検討した代替案と却下理由）
## AI支援の申告
- [ ] AI支援を使った（使った場合、全行を理解し自分の言葉で説明できる）
- [ ] /explain-check を実行し全質問に即答できることを確認した「自分の言葉で」「AI生成文のままは不可」と明記する。チェックボックスで、本人に確認の意思表示をさせる。
狙いは「取り締まり」ではない
ここが一番大事なところだ。
この仕組みは、AI利用を禁止・監視するものではない。もし「AIを使うな」と取り締まれば、人はAIを隠して使う。バレないように使い、結果としてもっと質が落ちる。最悪のパターンだ。
狙いは逆。「AIは使え。ただし、分かった上で出せ」を仕組みで担保すること。
AIは強力な道具だ。使うべきだ。禁止するのは時代に逆行している。でも、理解せずに出力を垂れ流すのは別問題。「使う」と「理解する」を両立させる。その境界線を、人の善意や根性ではなく、仕組みで引く。
/explain-check は、その境界線を引く装置だ。AIを使ったかどうかは問わない。「説明できるか」だけを問う。
口頭でやっていたことを、仕組みに昇格させる
振り返ると、自分がずっと口頭でやってきた「なんでこうした?」「答えられないなら考えて来い」を、提出前に本人が自分でやれる形にしただけだ。
違いは、自分がボトルネックでなくなること。一人ひとりに聞いて回らなくても、提出者が自分でゲートを通る。自分は本当に必要な設計判断のレビューに集中できる。
「目標は私が暇になること」とずっと言ってきた。理解度の確認すら仕組みに渡せるなら、また一つ、自分の手を離せる。
これはまだ設計段階だ。実際にチームへ展開するのはこれから。でも、AIをそのまま出す問題に対して、「禁止」でも「諦め」でもない第三の道が見えた気がしている。AIに説明させるのではなく、質問させる。答えは、本人の中にしかない。
関連記事: