What Bugs Do Prolog Students Write? An Empirical Taxonomy and Data-Driven Mutation Framework

ロボットに人間の探偵のように考える方法を教えようとしていると想像してみてください。単に「犯人を解決しろ」と伝えるだけでは不十分です。手がかりがどのように組み合わさるかという、独特で癖のある論理のルールを教えなければなりません。これが**論理プログラミング（Logic Programming）**の世界です。これは、手順をステップ・バイ・ステップで記述するのではなく、「何が真実であるか」を記述するコードの書き方です。それは、ターン・バイ・ターンでの運転指示を与える代わりに、都市の地図を与えるようなものです。しかし、ここには落とし穴があります。人間は非常に「不完全」なのです。これらのルールを学ぼうとする際、私たちは非常に具体的で予測可能な間違いを犯します。ルールを忘れたり、2つの手がかりを混同したり、あるいは「停止信号」を間違った場所に置いてしまったりするのです。

私たちのコードを修正してくれる役立つロボットチューターを作るためには、私たちがどのような間違いを犯すのかを正確に知る必要があります。もしロボットが、ランダムに作られたデタラメなエラーだけで練習していたら、本物の学生に出会ったときに混乱してしまうでしょう。それは、タイヤのパンクした車でしか練習しない自動車教習所の指導員が、生徒が実際にシートベルトを付け忘れたときに驚いてしまうようなものです。この論文は、こうした学生のエラーという「不完全な現実」を掘り下げ、より優れたトレーニングの場を構築することについて述べています。

大いなるPrologのバグ狩り

最近の研究で、研究者たちは探偵を演じることにしました。しかし、犯罪者を探すのではなく、コンピュータコードの中にある「バグ」を狩るのです。彼らは、Prologと呼ばれる言語を学んでいる265人の学部生による7,201件のコード提出物を調査しました。Prologは、事実とルールのリストを書き込み、コンピュータが答えを導き出す言語だと考えてください。学生たちは、単純な論理ゲームから、「スター・バトル（Star Battle）」という複雑なボードゲームのソルバーを構築するという最終プロジェクトまで、さまざまなパズルを解いていました。

チームは単にプログラムがどれくらい失敗したかを数えたのではありません。彼らは「なぜ」失敗したのかを知りたかったのです。彼らは、学生が間違いを修正した200件の提出物をピックアップし、それらのエラーを手動で「タクソノミー（分類体系）」、つまり詳細なファイル管理システムへと分類しました。その結果、最も一般的な間違いは、トリッキーな論理エラーではなく、単なる作業の未完了であることがわかりました。約37.5%のケースで、物語の章を飛ばした時のように、パズルのピースの一部を書き忘れていました。次に多かったエラーは、間違った材料の使用（20.5%）、およびルール内のゴール（目的）の混同（13.0%）でした。興味深いことに、学生は他の言語で見られるような「不注意な」タイポ（打ち間違い）をすることは滅多にありませんでした。彼らの間違いは、論理がどのように機能するかについての深い誤解に起因することが多かったのです。

「バグ工場」の構築 (LOGMORPH)

学生がどのような間違いをするかを知ることは素晴らしいことですが、コンピュータにそれらを認識させるにはどうすればよいのでしょうか？研究者たちは、LOGMORPHと呼ばれるツールを構築しました。完璧に動作するコードの断片を、意図的に壊していく工場を想像してみてください。

古い工場は、ボードにダーツを投げるように、ランダムに壊そうとしていました。彼らは、あらゆる種類の故障が等しく起こると想定していました。しかし、LOGMORPHは異なります。これはデータ駆動型の工場です。LOGMORPHは、先ほど研究者が作成した「実在する学生のエラーのファイル管理システム」を参照し、「よし、学生は37.5%の確率でコードの記述を忘れるのだから、その割合に従ってコードを壊そう」と判断します。

このツールは4つのステップで動作します：

1. スキャニング（走査）: 完璧なコードを読み取り、間違いが発生しうるすべての箇所を見つけ出します。
2. サンプリング（抽出）: 壊すべき箇所を選びますが、これは実際の学生の統計に基づいて選択されます。「節（clause）を忘れる」ことが一般的であれば、頻繁にそれを選択します。
3. インジェクティング（注入）: 実際にコードを壊します。2つの数字を入れ替えるような簡単なこともあれば、新しいコードの断片を生成して挿入する必要がある場合もあります。このために、ルールに適合する新しいコードの行を生成するスマートな「シンセサイザー（合成器）」を使用します。
4. テスティング（テスト）: 壊れたコードが実際にテストに失敗するかどうかを確認します。もし「壊れた」はずのコードが完璧に動作してしまう場合は、そのコードを破棄してやり直します。

結果：ほぼ完璧な鏡

チームはこの工場を稼働させ、16,000個の偽のバグを含むプログラムを作成しました。そして、これら偽のプログラムの「バグ・プロファイル」を、実際の学生のデータと比較しました。結果は驚くほど近いものでした。ほとんどのエラーカテゴリにおいて、偽のプログラムは、誤差2%以内で実在の学生のデータと一致しました。それはまるで、鏡を見て、自分の反射が全く同じように動いているのを見ているかのようでした。

しかし、その鏡は完璧ではありませんでした。研究者は2つの主な不具合に気づきました。

• 「カット」の問題: Prologには、コンピュータに他の答えを探すのをやめるよう指示する「カット（! と表記される）」と呼ばれる特別な記号があります。学生はこれをよく間違えます。しかし、偽のプログラムでは、これらの間違いは稀でした。なぜでしょうか？それは、工場の「テスティング」ステップが厳格すぎたからです。もし偽のカットがテスト結果に変化を与えない場合、工場はそれを排除してしまいました。実際の人間の学生は、テストの結果を変えないものの論理を混乱させるようなカットの間違いを犯すことがありますが、工場はそれらをフィルタリングしてしまったのです。
• 「ロボット」のようなコード: 工場が新しいコード（例えばランダムなゴールを追加するなど）を考案しなければならないとき、「シンセサイザー」は技術的には正しいものの、意味不明なものを書くことがありました。例えば、空のリストを数学記号を使って変数と比較するといったことです。人間である学生がそのようなコードを書くことは決してありません。それはまるで、人間のように話そうとしているロボットのようでした。研究者は、もしシンセサイザーを学生の文章で訓練されたより高度なAIに置き換えれば、偽のコードはもっと自然なものになるだろうと考えています。

これが意味すること

この論文は、論理プログラミングのすべての問題を解決したと主張しているわけではありません。その代わりに、学生のエラーをシミュレートするための、より優れた新しい方法を提案しています。エラーに重み付けを行うデータ駆動型のアプローチを用いることで、LOGMORPHは現実的なトレーニングの場を作り出します。研究者たちは、将来的にはこのデータ駆動型のアプローチをよりスマートなAI言語モデルと組み合わせることで、これらのトレーニングツールをさらに生命力のあるものにし、ロボットが単に「学生が間違っている」ことだけでなく、「なぜその特定の人間らしい間違いを犯したのか」を理解できるようにできるだろうと示唆しています。