【ITニュース解説】Should an AI Tutor Just Give You the Answer? I Tested It

このニュース記事は、AIチューターが学習者に対してどのように「手助け」を提供すべきかという重要な問いについて、具体的な実験と考察を通して解説している。システムエンジニアを目指す初心者にとって、ユーザーインターフェースや学習システムの設計、そして実験による効果検証の重要性を理解する良い事例となるだろう。

筆者は、SQLの学習を支援するAIチューターを開発し、学習者が問題を解決できない場合に、すぐに答えを教えるべきか、それともまずは自分で考えることを促しヒントを与えるべきか、という設計上の疑問に取り組んだ。現在広く使われているChatGPTやGitHub CopilotのようなAIツールは、困ったときに直接的な答えを提供することが多い。しかし、過去の大規模な研究では、AIがすぐに答えを与える環境で数学を学んだ学生は、AIを使わなかった学生よりも、後に行われた試験で成績が悪くなることが示されていた。これは、AIに頼りすぎると、AIがない状況ではかえって学習効果が低下する可能性を示唆している。

この背景から、筆者は「チューターがまず試行を促し、答えの前にヒントを与えた場合、チューターがいなくなった後でも、学習者はより多くのことを自分でできるのか」という、より具体的な問いを設定し、実験を行った。

実験のために開発されたのは、ウェブページ上でSQLの質問を読み、SQLクエリを書いて実行し、正誤判定を受けられるSQLチューターである。このチューターには、学習者が「ヘルプ」ボタンを押したときの動作が異なる2つのバージョン（「アーム」と呼ぶ）が存在した。

一つ目の「アームA」（試行優先型）は、学習者が何も試していない状態で「ヘルプ」を押すと、「まず一度試行してください」と助けを拒否する。一度試行した後であれば、AIが生成したヒントが提供され、さらに2回試行した後に答えが表示される仕組みだった。 もう一つの「アームB」（即答型）は、現在の多くのAIツールのように、学習者が「ヘルプ」を押せばすぐに答えを提示する。アームBは、比較のための基準として設定された。

練習問題は16問、両アームで同じウェブページと問題、採点システムが使われた。実験には6人の開発者仲間が参加し、それぞれ3人ずつがアームAとアームBに振り分けられた。参加者のSQLスキルレベルが均等になるように調整された上で、まずはチューターを使った練習セッションが行われた。その後、5〜7日間待機し、最終テストとして、チューターなしで新しい12問のSQL問題に挑戦してもらった。筆者が最も重視したのは、チューターがいない状況で学習者がどれだけ自分で問題を解けるか、という点だった。

実験結果は非常に興味深いものだった。最終テストで、アームAのグループは12問中36問すべて（3人×12問）に正解したのに対し、アームBのグループは36問中25問の正解にとどまった。この結果だけを見ると、アームAの「試行優先型」のチューターが明らかに優れていたように見える。

しかし、筆者はこの結果を自身のチューターの完全な勝利とは受け止めなかった。詳細な分析では、最初の試行で正しく回答できた問題数は、両グループともに17問と同じだったことが明らかになった。これは、チューターが、学習者が最初から正しいクエリを書く能力を直接向上させたわけではないことを示している。

このギャップは、学習者が間違った回答をした後の行動に起因していた。アームAのグループは、すべての質問を解き、間違った最初の試行19問すべてを修正して正解に導いた。一方、アームBのグループは、一部の質問（7問）を解かずに残し、間違った最初の試行12問のうち8問しか修正できなかった。つまり、アームAは学習者の「間違いを修正する粘り強さ」や「問題解決への意欲」を変えた可能性が高いという発見があった。

筆者が結果を過信しなかった理由にはいくつかの要因があった。まず、実験前に設定した検証基準のうち2つが満たされなかった。一つは、アームAとアームBの学習者の行動が予想ほど異ならなかったこと。アームBの参加者も、ヘルプボタンを押す前に平均で0.83回は自力で試行していたため、「試行を促す」というアームAの意図が完全に機能したとは言い難かった。もう一つは、最終テストがアームAのグループにとって簡単すぎたこと。100%の正答率を達成してしまうと、実際にはどれほど能力が向上したのか正確に測ることができない。

さらに、結果を歪めた可能性のある予期せぬ要因も判明した。テスト問題の順序が簡単なものから難しいものへと並んでいたため、途中で解答をやめた参加者は、より難しい問題を解けなかった。また、アームAの参加者の中には、練習中に一度もヘルプ機能を使わなかった人がおり、その人も最終テストで満点を取った。この参加者はチューターの「試行優先」の仕組みを経験していないため、結果に影響を与えた可能性がある。これらの要因を考慮すると、グループ間の差は11問から3問にまで縮まる可能性があった。

これらの分析を経て、筆者が主張できたのは「学習者にまず試行を促すことは、彼らが間違った回答をした後の行動を変えるようだ。しかし、最初の試行で正解する能力を変えるわけではない」という、より限定的な結論だった。

デモデイで審査員から「練習とテストは監視下で行われたか？」という質問があったことも重要だった。実際には、参加者は各自の都合の良い時間に実施しており、筆者は監視していなかった。この状況は結果の解釈に大きな影響を与える。なぜなら、監視されていない環境では、参加者が外部ツール（例えばChatGPT）を自由に利用できた可能性があるからだ。

特に、アームAの参加者は、チューターが試行を促している間に、外部ツールに質問を貼り付けて答えを得る誘惑に駆られやすかっただろう。もしそうした行動があったとすれば、アームAが意図した「苦労する過程」をスキップしてしまったことになり、アームAの効果が実際よりも弱く、グループ間の差が小さく見えた可能性があった。つまり、この非監視環境は、アームAの効果を過小評価する方向に作用した可能性が高いと筆者は考察している。このことから、実験の詳細な実施方法が結果の解釈にどれほど重要であるか、そしてそれを明確に伝える必要性を学んだと述べている。

最後に、筆者は今後の実験で改善すべき点も挙げている。質問の順序をシャッフルすること、より難しいテスト問題を用意すること、最初の試行での正答数を主要な評価指標とすること、ヘルプ機能の実際の利用状況を追跡すること、そして可能であれば監視下でテストを行うか、タブの切り替えやコピー＆ペーストのログを記録することなどである。

この一連の検証から得られた主な学びは、予測していなかった部分から大きな結果の差が生まれる可能性があること、結果を見る前に検証基準を明確に設定しておくことの重要性、そして最初の予測が変わったとしてもそれは失敗ではなく、むしろプロジェクトから得られる最も有用な知見であること、そして実験の実施方法に関する詳細を正確に伝えることの重要性、である。この研究は、AIを教育に応用する際に、単に答えを効率的に提供するだけでなく、学習者の思考プロセスや学習行動をどのように支援・誘導すべきかを深く考えるきっかけとなるだろう。