AIがコードを書ける時代に、プログラミングをどう教えるか

プログラミング教育において、これまで学生のコードは思考プロセスを覗く窓でした。エラー、コード構造、不格好な解決策はすべて、学生がどのように推論し、どこで行き詰まったかを示していました。しかし、この窓は決して完璧ではありませんでした。学生は常にコピーし、詰め込み、借用し、時には完全には理解していない作品を提出していました。それでもコードは手がかりを残していました。生成AIはこれを変えました。完成したプログラムは今や、学生のアイデアよりもプロンプトを反映しています。さらに厄介なのは、コードが見栄えよく見えるほど、学生が実際に学んだことについて言えることが少なくなることです。

これは大きな疑問を提起します：AIがコードを書けるなら、プログラミングを教えるべきでしょうか？答えはイエスだと私は信じます。少なくとも一部の学生や状況では。しかしそれは別のトピックです。ここでは次のステップに焦点を当てます：AI時代にプログラミング教育を続けるなら、学生が本当に学んでいるかをどうやって知ることができるでしょうか？

一部の学校は学生を捕まえようとしています。AI検出器、監視ツール、ロックされたブラウザ、より厳格なルール、明確な栄誉規定を使用しています。これにより疑念が増大しています。これらの対応の一部は理にかなっています。教師は学習を保護したい、学校は公平を保ちたいと願っています。しかし、検出を主要な評価方法として使用するのは脆弱です。スタンフォード大学の研究者は、人気のAI検出器が非ネイティブ英語話者の文章を誤って識別することが多く、ある研究ではTOEFLエッセイの61.22%がAI生成とマークされたことを発見しました。OpenAIは2023年に自社のAIテキスト分類器を廃止しました。精度が不十分だったからです。ツールを作った会社がAIを確実に検出できないなら、それに基づいて栄誉規定を設けるのは良い考えとは言えません。

しかし、検出が本当の問題ではありません。完璧な検出器があったとしても、私たちは間違った質問をしていることになります。「どうやって学生がAIを使うのを止めるか？」ではなく、「AI時代にプログラミングをどう教え、その利点を活用しつつ、学生が学んでいるかどうかを確認できるようにするか？」を問うべきです。

スタジオから借りた方法

テキサス大学オースティン校の芸術・エンターテイメント技術学科（AET）で、この課題に直面しています。私の通常の所属はコンピュータサイエンスですが、AETは美術学部に属しており、スタジオワーク、批評、リハーサル、改訂、パフォーマンスなど、学習と評価の多くの方法を提供しています。芸術の世界では、最終作品がすべてではありません。絵画はその背後にある選択を説明しません。パフォーマンスはリハーサルを明らかにしません。デザインボードは破棄されたバージョンを示しません。作曲は学生がどこで苦労したか、最終的に何を学んだかを教えてくれません。

芸術教育は、目に見える進歩に焦点を当てた実践を発展させてきました。学生はスケッチやドラフトを持ち寄り、影響、改訂、失敗について議論し、進行中の作品をリハーサルし、パフォーマンスし、批評します。AETでは、クリエイティブコーディングを教えています。これは、アート、デザイン、ゲーム、体験を創造するためのプログラミングです。詩人のためのコーディングではありません。私たちの学生は、ゲームデザイナー、ウェブ開発者、プログラマーであり、Processingやp5.jsなどのツールで高度な概念を学びます。クリエイティブコーディングの伝統では、プログラムはしばしば「スケッチ」と呼ばれ、芸術の世界から用語を借りています。それは一時的で、探索的で、変更可能なもの——あなたが作り、テストし、修正し、共有するものです。

したがって、クリエイティブコーディングではすでに、スケッチ、実験、反復、批評というスタジオモデルに傾いていました。今、AI時代のコーディング教育を再考するにあたり、それをさらに推し進めています。以下は、すでに使用している、または積極的に開発している3つの方法です。

作業を公開する

私たちはクラスをスタジオのように運営しています。自宅で作業が行われないわけではありませんが、最も重要な作業は教室で見られる必要があります。学生はコードを、誤った開始点や改訂、行った選択とその理由を含めて示します。課題はもはや単に提出するものではなく、公共の場で開発するプロジェクトになります。AIは教室から禁止されていません。代わりに、学ぶための助手的な存在として扱われます。学生はプロンプトやテクニックを共有します。AI、Google、Stack Overflow、クラスメート、その他のリソースを使用できます。

しかし、自分の作業に対して責任を負う必要があります。提出または発表する場合、コードが何をするか、なぜその選択をしたか、どのように機能するかを説明しなければなりません。あなたのコードを理解するためにAIに尋ねる必要があるなら、何かが間違っています。助けを求めるのは結構ですが、その助けの後ろに隠れるのはダメです。部屋全体が見ているものをAIに外注することはできません。

本当のスタジオは、学生が毎日一緒に声を出して話すことを必要とします。これは、AIとは関係のない別の問題にも役立ちます。多くの人が、今日の学生は過去よりも静かだと言います。これは主に逸話に基づいていますが、これらの逸話は一般的で一貫しています。あらゆる種類のキャンパスの教員が、沈黙した教室と、特に2020年以降、発言をためらう学生について話します。理由はともあれ、この沈黙は変えられます。解決策はAIの課題と同じです：学生の参加を促すこと。コミュニケーションはどんなキャリアにおいても最も重要なスキルの一つであり、アイデアを説明し、選択を守り、リアルタイムで他者を説得することを含みます。学生はAI主導の作業をオンラインで提出するだけではこれらのスキルを身につけられません。作業を公開して共有することで、AIの悪用を防ぐだけでなく、最も必要なスキルを構築する手助けにもなります。

役割を逆転する：AIを教師兼評価者に

私たちは通常のパターンを知っています：学生が質問し、AIが答え、学生がコピーします。これを逆転させようと試みました。新しいアプローチでは、AIが学生と一緒にトピックセットに取り組み、学生がナビゲートしなければならない会話をし、最終的に理解度を評価して成績を出します。このアイデアにはChatGPT以前からの研究背景があります。Betty's Brainのような教えられるエージェントシステムは、説明すること（ソフトウェアエージェントに対してさえ）が、学生に知識を整理させ、つながりを明確にさせ、ギャップを見つけさせることを示しました。私たちのモデルはこの洞察を異なる方法で使用します。学生はボットを教えているのではありません。代わりに、学生はボットと会話し、学び、議論し、討論し、理解していることを示します。

どのようにしたか？かなりシンプルなプロンプトエンジニアリングで、Vera Molnár（1924–2023）のアバターチャットボットを作成しました。彼女はアルゴリズムアートの先駆者です。ボットはMolnárの役割を担い、学生をランダム性、計算、生成アート、創造的選択についての会話に引き込みます。彼女の実践は、クリエイティブコーディングの学生が考える必要がある場所——ルールとバリエーション、システムと選択、計算と視覚的判断の間に正確に位置しています。システムプロンプトはトピックと質問のタイプを設定します。ボットはこれらを学生と一緒に進め、不明瞭な回答には詳細を求め、理解の証拠があるまでフォローアップを続けます。最後に、ルーブリックに照らして会話をレビューし、学生がどのアイデアをカバーしたか、どこで苦労したか、どの程度改善したかの明確な記録を提供します。

評価はしばしば正確ですが、その記録は別の種類の証拠となり、典型的な課題が隠すかもしれないものを示します。学生は何に気づいたか？何を誤解したか？概念をコードに結びつけられたか？自分の選択を守れたか？挑戦されたときに説明を修正できたか？役割を切り替えると、驚くべきものが現れます：完成した提出物が決して示すことのできないもの——学生が声に出して考えていること。

理解をパフォーマンスにする：学生にパフォーマンスさせる

プログラミングにはこれまでパフォーマンスの伝統がありませんでした。ミュージシャンにはあり、画家にはあり、ダンサーにはあります。ライブコーディングがそれを変え始めています。毎学期、AETでは異なる分野の学生が一緒にアルゴラヴ（アルゴリズミックレイブの略）を開催します。オーディオセット、プロジェクション作品、ゲームデモ、レーザー、ドローン、体験デザイン。クリエイティブコーディングクラスは、ライブコーディングの伝統にライブビジュアルをもたらします：コードはリアルタイムで書かれ修正され、スクリーンが投影され、観客はエディタが変化するのを見て、ビジュアルが他の学生が演奏する音楽に反応します。プレレンダリングなし。仕組みを隠さない。

2004年にTOPLAPが書いたライブコーディングマニフェストには、AI時代の評価の会話にぴったりな一行があります：「難解さは危険だ。画面を見せろ。」これはパフォーマンスの倫理であるだけでなく、評価戦略でもあります。学生がステージに上がります。投影されたスクリーンは彼らのエディタです。部屋はそれを読めます。音楽が始まります。そして、画面上にコードの行を構築します。これはリアルタイムでビジュアルを生成するJavaScriptです。FFT、チェーン関数、高次操作。ステージ上でそのようにコードを操作しているなら、自分が何をしているかよくわかっている必要があります。

AIは準備を手伝えます。良いでしょう。そうさせてください。しかしステージに上がれば、質問は「コードをコピー＆ペーストできますか？」から「それを制御できますか？」に変わります。コードをファイルに貼り付けることはできても、プロジェクション全体がベージュ色の長方形になりながら、3分間の公開デバッグを貼り付けることはできません。ライブビルドでは、理解は隠れる場所がありません。コードを読めますか？意図的に変更できますか？予期しないことが起こったときに回復できますか？それが流暢さです：システムが実行中に次に何をすべきかを知っていること。パニックを盗用するのは非常に困難です。

評価に関する注記

これまでの結果は私たち自身の観察に基づいています。対照研究を実施したり、異なるグループを比較したりしていないため、観察されたことは初期の変動に過ぎず、広く適用できるパターンではないかもしれません。現時点では、これらの取り組みは実験であり、最終的な答えではありません。スタジオやライブパフォーマンス設定での評価は常に主観的で、人に焦点を当てています。学生の進捗を監視し、フィードバックを提供し、課題にどう取り組むかを観察することに依存しています。この中核アプローチを変更する予定はありません。

Molnárの会話課題では、学生がAIシステムを使ってMolnárについて議論しました。AIは各学生の理解の要約と分析を作成しました。ティーチングアシスタントはこの分析を検討し、自身の評価を行い、成績を付けました。私たちの小さな実験では、ルーブリックを使用したAIの評価は、ティーチングアシスタント自身の評価と密接に一致しました。また、期末コーディング課題の採点にもAIを使用しました。このプロジェクトでは、学生がヒューリスティック、探索アルゴリズム、学習行動などの戦略を追加してオブジェクト指向のゲームを改良しました。ティーチングアシスタントはオブジェクト指向プログラミングの経験が限られていたため、詳細なルーブリックを作成し、AIモデルにそれを使用して各提出物を評価させました。AIの分析はティーチングアシスタントへのサポートとして提供されました。各プロジェクトの構造を理解し、重要なOOPデザインの選択を見つけ、ルーブリックをより自信を持って使用するのに役立ちました。ティーチングアシスタントは依然として自身の採点判断を行いました。私がOOP専門家として、彼らが答えられない質問に対応しました。観察されたところでは、これによりティーチングアシスタントは学生のOOPデザイン作業を大幅に理解し、採点できるようになりました。より広く言えば、これらのアプローチは、そうでなければ困難な規模で実質的なフィードバックを可能にするようです。