Commenting with Copilot: A Taxonomy and Multi-Year Analysis of Student Code-Generation Specifications
本論文は、AIによるコード生成の仕様として用いられる学生のコメントに関する三次元的な分類法を導入するために、学部生のプログラミング提出物の4年間にわたる分析を提示するものであり、学生は主に「何（What）」に関するコメントを記述し、手続き的なタスクに対しては「どのように（How）」に関するコメントへと移行すること、そして仕様を繰り返し書き換えることよりも生成されたコードの検証を優先することを明らかにしている。
原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。 免責事項の全文を読む
あなたはシェフだと想像してください。ただし、野菜を切ったり鍋をかき混ぜたりするのではなく、超高速で超クリエイティブなロボット・スーシェフ（副料理長）の「指揮官」としての役割です。あなたの仕事は、自分で料理を作ることではなく、ロボットがプログラムを構築できるように、レシピの指示を平易な英語で書くことです。これは、ある大学のコンピューター・クラスで、1,161人の大学生が4年間にわたって行ってきたことです。彼らはコードを一行ずつ書いたのではありません。AIツールであるGitHub Copilotにプログラムを構築させるための「コメント（小さなメモ）」を書いたのです。
ここに、研究者たちが、この「学生指揮官」たちがどのようにしてロボットの助手と対話していたかについて発見した内容をまとめます。
主な発見：「何を（What）」対「どのように（How）」
最大の驚きは何だったでしょうか？ ほとんどの学生はプログラマーのような話し方をしていませんでした。彼らは目標を説明する人間のように話していました。
- 「何を（What）」派 (77%): 学生が書いたメモの大部分は、「何」という結果を望んでいるのかについての記述でした。例えば、「このリストをループして数字をチェックする」と言う代わりに、「もし数字が負なら、falseを返す」と書いていました。彼らは目的地を記述しており、運転の指示を出していたわけではありません。
- 「どのように（How）」へのシフト: しかし、タスクが複雑になったとき（例えば、ステップを何度も繰り返す必要がある場合や、複雑な一連の動作が必要な場合）、学生たちはギアを切り替えました。彼らは「どのように（How）」のコメントを書き始め、ステップ・バイ・ステップの行軍命令を出し始めたのです。それは、友人に「サンドイッチを作って」と言う（「何を」）けれど、もし特定の複雑なクラブサンドイッチが必要になったら、突然「まずパンをトーストして、次にターキーを重ねて、それからピクルスを挟んで……」と言わなければならなくなるのと似ています（「どのように」）。
「レシピをいじるな」というルール
ロボットが間違いを犯した場合、学生が熱心に何度も指示を書き直すだろうと思うかもしれません。論文はその考えに反論しています。
データによれば、学生がコメントを書き直すことは滅多にありませんでした。実際、一度コメントを書くと、彼らはそれをほとんどそのままにしておきました。
- 現実: 100個のコメントにつき、約48個は全く手を加えられず、別の41個は新しいものでした。大幅に書き直されたり、完全に破棄されたりしたものは、ごくわずかな部分（約4%）だけでした。
- 本当の仕事: では、彼らはメモを書き直していなかったとしたら、何をしていたのでしょうか？ 彼らは厳格な品質検査官として行動していました。学生たちは、自分の指示を絶えず変更することよりも、ロボットが作成した成果物をチェックし、テストを実行し、コードを修正することにエネルギーを注いでいました。論文は、難しいのはプロンプトを書くことではなく、出力を検証することであったと示唆しています。
学生たちの言葉（リフレクション）
タスクの後、学生たちはリフレクション（振り返り）を記述しました。研究者は13の主要なテーマを見出しました。その中でも大きなものは以下の通りです。
- スピードこそ命: 学生たちは、このツールが速いという理由で気に入っていました。それは、退屈な詳細事項で行き詰まることなく、素早く作業を開始させてくれる「足場（スキャフォールド）」のように感じられました。
- 「慣れ」の罠: ロボットは単純で反復的なタスク（定型的なコードなど）には優れていましたが、タスクが奇妙だったり、非常に特殊だったり、あるいはユニークな解決策を必要としたりする場合には苦戦しました。
- 信頼の問題: ロボットは速かったものの、学生たちは盲目的に信頼することはできないと分かっていました。彼らは重い「検証の負担」を感じていました。ロボットは、正しく見えるけれども実際には間違っている答えを出すことがあったため、彼らはすべてをダブルチェックしなければなりませんでした。
- 学習か、それとも「杖」か: 一部の学生は、ロボットに頼りすぎると、自分自身で料理を作る方法を学べなくなるのではないかと懸念していました。彼らは、このツールを「杖（補助具）」として使うことが、将来的に問題を解決する自分自身の能力を損なう可能性があると感じていました。
この論文が否定していること
この研究が発見しなかったことも知っておくことが重要です。
- それは「魔法のボタン」ではない: 論文は、学生が単にAIに完全な解決策を求めて、そのまま立ち去ったわけではないことを明確に否定しています。それではうまくいきませんでした。成功したのは、AIをガイドし、チェックすべきパートナーとして扱った学生たちでした。
- それは「完璧な」コードについてではない: 研究は、AIが常に完璧なコードを生成するという結果は見出していません。実際、学生たちは、AIが不要なコードを追加したり、細かな技術的詳細を見落としたりすることがあると指摘していました。
- それは「解決済み」の問題ではない: 論文は、AIへのプロンプトの出し方を教えることが簡単であるとか、誰もが今やエキスパートであるとは主張していません。これは、いつ詳細に指示を出し、いつ作業をチェックすべきかを知るための練習を必要とする、新しいスキルセットであることを示唆しています。
どの程度確実なのか？
研究者たちは、膨大なデータセットを見ているため、これらの数字に非常に自信を持っています：4年間のクラスからの10,257件の提出試行。彼らは自動化ツールを使用して、136,000件以上のコメントをカウントし、学生のリフレクションを高精度で分析しました。
- 彼らは、**99.3%**の学生が最終的にコードをテストに合格させたことを突き止めました。
- 彼らは数学的な精密さをもってコメントの「微調整」を測定し、大幅な書き換えは稀であることを明らかにしました。
- しかし、論文はいくつかの限界も認めています：これはJavaを用いた一つの大学のコースに過ぎません。これと同じパターンが、異なる言語や異なる種類のクラスでも起こるかどうかは分かりません。また、この研究は学生が提出したコメントのみを見ており、作業の途中で入力して削除した可能性のあるコメントについては見ていません。
まとめ
論文は、AIの時代において最も重要なスキルは、単にコードをタイピングすることではなく、「何を（specifying）」欲しいかを指定し、「得られたもの（verifying）」を検証することであると示唆しています。学生たちは、明確な「何を（What）」を書くことが第一歩であるが、真のマジックは、ボスとして振る舞い、ロボットの仕事をチェックし、ロボットが行き詰まった時にのみ「どのように（How）」の指示を出すときに起こるのだと学びました。それは、AIに思考を任せることではありません。AIがあなたと共に思考してくれるように、どう対話するかを学ぶことなのです。
自分の分野の論文に埋もれていませんか？
研究キーワードに一致する最新の論文のダイジェストを毎日受け取りましょう——技術要約付き、あなたの言語で。