--- title: "AIは学びを奪わない支援者になれるか" url: "https://blog.101ta28.com/posts/can-ai-support-learning-without-taking-it-away/" language: "ja" description: "新人研修でAIコードレビューを使うとき、判断する経験を新人に残すための支援設計について" --- # AIは学びを奪わない支援者になれるか > 新人研修でAIコードレビューを使うとき、判断する経験を新人に残すための支援設計について 学生から、既存プロジェクトのチーム開発研修にAIコードレビューを活用したい、という相談を受けた。 Gemini Code AssistやCodeRabbitのようなツールを使えば、人間が見落とした問題を見つけたり、レビューの負担を減らしたりできるかもしれない。 新人にとっても、自分だけでは気づけない問題を知る機会になるだろう。 ただ、AIの指摘どおりにコマンドを実行し、修正を反映するだけで研修になるのだろうか。 AIレビューによってコードは良くなる。では、そのコードを書いた人も成長するのか。 ## AIを使わなくても学ばないことはある 新人がAIを使うには、事前知識が必要ではないか。最初はそう考えた。 知識がなければ、AIの指摘が正しいか判断できない。 理由を理解しないまま修正しても、次に似た問題が起きたとき、自分で気づけるとは限らない。 一方で、この問題はAIが登場する前からあった。 先輩から「このコマンドを実行して」「ここをこう直して」と指示され、そのとおりに作業する。 コードは直っても、なぜ直したのかは分からない。 AIを使わなければ、自動的に知識が身につくわけではない。 AIを使う人と使わない人の差ではなく、指示を処理して終わる人と、理由を理解しようとする人の差なのだと思う。 AIはその差を生み出すというより、広げる可能性がある。 すぐに具体的な修正案を返してくれるため、理解しなくても作業を先へ進められるからだ。 ## 調べれば分かることと、対話しなければ分からないこと 新人に、すべての文法やフレームワークを覚えてからAIを使ってほしいわけではない。 文法、API、フレームワークの仕様には、公式ドキュメントやAIを使って調べた方がよいものも多い。 バージョンアップによって、以前の知識がそのまま使えないこともある。 覚えていることより、現在の情報を調べ、確かめられることの方が重要な場面もある。 しかし、Gitの運用、プルリクエストの作り方、チーム規約は少し異なる。 一般的な方法は調べられる。 操作手順も見つかる。 それでも、なぜこのチームがその運用を選び、何を守ろうとしているのかは、外部の情報だけでは分からない。 たとえば、コミットを分けるという規約があるとする。 「コミットは小さくする」とだけ覚えれば、不便な決まりに見えるかもしれない。 だが、その目的はコミット数を増やすことではない。 誰が読んでも、後から見返しても、短時間で変更の意図を理解できる状態を目指している。 規約を適用するだけならAIにもできる。 規約によって、誰とのどのような協働を守ろうとしているのかは、人間同士で共有する必要がある。 ## 巨大な一コミットに残る説明の負債 新人が一つの機能を実装し、最後にすべての変更をまとめてコミットしたとする。 新人から見れば、これは自然な流れだ。 実装が終わった。動作も確認した。だから、すべてコミットする。 しかし、そのコミットに機能追加、変数名の整理、フォーマット変更、別のバグ修正が混ざっていたら、レビュアーは変更の意図を分解し直さなければならない。 最終的なコードが動いていても、どの差分が機能追加に必要なのか分からない。 問題が起きたとき、どの変更を戻せばよいのかも判断しにくい。 実装者が整理しなかった思考を、レビュアーや未来の担当者が復元することになる。 これは、説明の負債と言えるかもしれない。 読みにくいコードが理解の負担を未来へ残すように、巨大な一コミットも変更を読み解く負担を未来へ残す。 ブランチやコミットは、作業を保存するためだけのものではない。 ブランチは、何を目的とした変更なのかを区切る。 コミットは、なぜこの変更をひとまとまりにしたのかを伝える。 プルリクエストは、変更の意図をチームへ説明する。 コードだけでなく、変更履歴も読みやすくする必要がある。 ## AIが読めることと、人間が読みやすいことは違う AIコードレビューは、大きな差分からも個別の問題を見つけられるかもしれない。 それ自体は便利なことだ。 一方で、AIが巨大な差分を読み解いてくれるほど、新人は変更を説明可能な単位へ分けなくても作業を進められる。 AIが解析できるから、このコミットの分け方で問題ない。 そのように考えてしまえば、人間が読みやすい変更を作る経験は減っていく。 AIにコミットを分割してもらえば解決する、という話でもない。 AIが分けた結果をそのまま採用するだけなら、どの変更が同じ意図に属するのかを新人自身は判断していない。 AIがコードを読めることと、人間が短い時間で変更の意図を理解できることは別の問題だ。 チーム開発の研修で身につけてほしいのは、AIが処理できる差分を作る力ではない。 自分の変更を、他者が理解できる形に編集する力だと思う。 ## 答えを出す前に、説明を求める 研修でAIレビューを使うなら、最初から答えを見せるのではなく、新人が一度判断した後に使うのがよいのではないか。 たとえば、次の順序が考えられる。 1. 新人が自分で変更を見返す 2. ブランチの目的と、各コミットを分けた理由を書く 3. AIでレビューする 4. 自分の判断とAIの指摘を比較する 5. 指摘を採用するか決め、その理由を説明する 6. 人間がコードと判断過程をレビューする AIの役割は、修正を完成させることだけではない。 - 「このコミットには別の目的が混ざっていないか」 - 「フォーマット変更は、機能追加と同じコミットである必要があるか」 - 「このブランチの目的を一文で説明できるか」 このように問い返すこともできる。 新人が自分で考え、AIが説明の足りない部分を問い、人間がプロジェクト固有の意図を伝える。 AIを人間の代わりとなるレビュアーではなく、対話を始めるための相手として置く。 AIレビューの導入だけでは、レビュー教育にはならない。 いつ使うのか、何を説明させるのか、誰が最後に判断するのかまで決める必要がある。 ## 判断する経験を新人に残す 以前、[学びを奪わない支援の設計]({{< ref "posts/designing-support-that-does-not-steal-learning" >}})で、支援は親切であればあるほどよいとは限らないと書いた。 入口が分からなければ挑戦できない。 しかし、すべての手順と答えを渡せば、自分で調べ、仮説を立て、失敗する経験を奪ってしまう。 AIコードレビューにも、同じことが言える。 AIは、知らないことを学ぶ入口になれる。 人間が見落とした問題を示し、別の考え方を知る機会も作れる。 ただし、AIの指摘を反映して終わる研修では、コードが直っても、レビューを判断する力は残らない。 AIが学びを奪うのではない。 考える前に答えを示し、判断までAIへ委ねる支援の設計が、学びを奪うのだと思う。 巨大な一コミットを見たとき、AIに分割してもらうだけで終わらせない。 なぜ分けるのか、誰が後から読むのかを新人自身に考えてもらう。 AIを使っても、変更の意図を説明し、最後に判断するのは新人である。 その経験を残せるなら、AIは学びを奪わない支援者になれるはずだ。 ## 関連記事 - [分からなかったらググれと言われ困る人へ]({{< ref "posts/struggling-with-just-google-it-advice" >}})：答えそのものではなく、調べ方の入口を渡すことについて。 - [情報の引継ぎに必要と思うこと]({{< ref "posts/information-transfer-essentials" >}})：後から必要になる情報を、組織の中でどう残し、受け渡すかについて。