【ITニュース解説】Don't let the LLM do the maths: grading writing with AI but scoring in code

AI、特に大規模言語モデル（LLM）の進化は目覚ましく、文章の採点やフィードバック生成など、これまで人間が時間をかけて行っていた作業を自動化する可能性を秘めている。しかし、これらのAIモデルをシステムに組み込む際には、その特性を理解し、得意なことと苦手なことを見極めて適切に役割分担することが、信頼性の高いシステムを構築する上で非常に重要になる。

あるドイツ語試験対策プラットフォーム「ExamReady」の開発者は、学習者が書いた文章をAIで採点するシステムを構築する過程で、このAIの特性と向き合った。彼が直面したのは、LLMに採点基準の解釈、単語数のカウント、点数の計算、さらには特定のルール（例：規定単語数の50%未満なら0点）の適用まで一任すると、AIは自信満々に答えを出すものの、時としてその答えが誤っているという問題だった。そして厄介なことに、その誤りが見た目にはもっともらしく見え、間違いに気づきにくいという点にあった。

LLMは「言語の理解」や「言語的な判断」において非常に優れた能力を発揮する。例えば、学習者の書いた文章が課題の内容に適切に応えているか、表現の丁寧さや専門性が場面に合っているか、文法に大きな誤りはないか、といった、まさに言語能力を評価するような判断は、LLMの得意分野だ。これらの判断は、人間であれば経験や専門知識が必要とされる高度な作業であり、LLMがその一部を担えることは大きなメリットと言える。

しかし、LLMが苦手とすることも明確に存在する。それは「数える」ことや「計算する」といった、厳密な論理に基づいた作業だ。具体的には、文章中の単語数を正確にカウントしたり、特定の数値を比較して条件を判定したり、複数の点数を正確に合計したりといった、いわゆる算術的な処理は、LLMにとって実は苦手な分野だ。LLMにこれらの作業をさせると、多くの場合で正しい結果を出すが、たまに間違いが生じ、しかもその間違いの原因を特定したり、同じ間違いを再現させたりすることが難しいという特性がある。これは、LLMが統計的なパターン認識に基づいて動作するため、厳密な計算ルールを常に完璧に適用できるわけではないからだ。

そこでExamReadyの開発者が採用したのは、AIと通常のプログラムコードで役割を明確に分離する方法だった。このアプローチでは、AI、具体的にはLLM（彼の場合はGeminiを使用）には、あくまで「言語的な判断」に集中させる。LLMは、受験者の書いたテキストと課題の内容を受け取り、公式な採点基準に基づいて各項目ごとの評価点数や具体的なフィードバック、さらに文章の修正提案を生成する。この際、LLMは最終的な合計点を計算したり、テキストの長さに関するルール（例えば「短すぎる文章は0点」）を適用したりはしない。

これらの「数える」や「計算する」といった厳密な処理は、システムエンジニアが記述する通常のプログラムコードの役割となる。コードはまず、学習者のテキストから単語数を正確にカウントする。次に、このカウントした単語数に基づいて、規定単語数の50%未満であれば0点とするなどの公式ルールを適用する。さらに、LLMが各採点項目について出した点数を組み合わせて、最終的な合計点を算出するのだ。

この役割分担には、いくつかの重要なメリットがある。一つ目は「再現性」だ。プログラムコードで単語数を数えたり、ルールを適用したりすれば、同じテキストに対しては常に寸分違わず同じ結果が得られる。一方、LLMの判断部分は、完全に同じ入力でもわずかに異なる結果を出すことがある。システムにおいて、特に採点のような結果が重要な場面では、常に同じ入力に対して同じ結果が出る「再現性」は極めて重要だ。

二つ目は「テスト可能性」だ。プログラムコードで記述されたルールは、ユニットテストと呼ばれる自動テストでその正確性を検証できる。例えば、特定の単語数のテキストを入力した場合に、正しく単語数がカウントされるか、ルールが適用されるか、といったことを細かく確認できる。しかし、LLMへのプロンプト（指示文）の中に埋め込まれたルールが正しく機能しているかを厳密にテストすることは非常に困難だ。

三つ目は「デバッグ可能性」だ。もし採点結果が期待と異なっていた場合、役割が分離されていれば、問題の原因が「LLMの言語的な判断」にあるのか、「コードによる計算やルール適用」にあるのかを切り分けて特定しやすい。これにより、問題解決の効率が格段に向上する。

四つ目は「ルール変更への対応の容易さ」だ。もし採点基準や単語数のルールが変更された場合、コードに記述されたルールであれば、その部分の関数を変更するだけで対応できる。しかし、プロンプトの中にルールが散りばめられていると、プロンプト全体の構造を見直したり、再検証したりする必要があり、変更作業が複雑になる傾向がある。

また、LLMが生成する「修正提案」についても、同様の検証が必要となる。LLMは学習者の文章の特定の箇所を指摘し、より良い表現を提案することがある。しかし、ここでもLLMが元の文章に書かれていないフレーズを引用してしまったり、元の文章を微妙に書き換えてから「修正」を提示したりする失敗が起こり得る。このような誤った修正提案は、学習者にとって混乱の元となる。そこでExamReadyでは、LLMが提案した修正の「元の文章」部分が、実際に学習者の提出したテキスト内に存在するかをコードで確認している。もし一致しない場合は、その修正提案は表示しない。誤ったフィードバックを与えるよりも、フィードバックがない方が学習者にとっては良いという考え方だ。

これらの取り組みは、AIが万能ではないことを理解し、それぞれの技術の強みを最大限に活かしつつ、弱点を補い合うという、現代のシステム開発における重要な原則を示している。LLMには言語的な判断を任せ、プログラムコードには厳密な計算や条件判定、ルール適用を任せる。そして、LLMの出力は「そのまま信用するのではなく、常に検証が必要な入力」として扱う。この考え方は、システムエンジニアを目指す上で、AIを単なる魔法のツールとしてではなく、賢く使いこなすための基礎となるだろう。要するに、AIに何でもかんでもやらせるのではなく、それぞれのタスクに適した道具を選ぶという、シンプルだが非常に効果的なアプローチだと言える。