生成した問題を、学習者に出す前に疑う——検証ゲートの設計
AIドリルキットの心臓部は、問題を生成するプロンプトではない。生成された問題を学習者に出してよいか判定する検証ゲートだ。コード量で言えば、生成より検査のほうが多い。なぜそうなったのか、実際に起きた事故から書く。
事故1: 答えが問題に書いてあった
配信前のレッスンをAI自身に解かせる検証（ドッグフーディング）で、答えが問題面に漏れているケースが12件見つかったことがある。図の中に答えの数値がそのまま描かれている。問題文の括弧に答えの漢字が混入している。すべての自動チェックを通過した後、本番配信の12時間前の発見だった。
教訓: プロンプトの品質が100点でも、生成物の品質が100点とは限らない。 生成側をどれだけ磨いても、出口の検査は別に要る。
事故2: 「正しいデータ」なのに解けない
漢字の並べ替え問題で、選択肢に空文字が混入したことがある。データ構造としては正しいJSONで、形式チェックも型検査も自動テストもすべて通過して本番に出た。発見したのは実際のプレイで、「選択肢が選べない」という形で。
教訓: 「データとして正しい」と「画面で操作できる」は別の命題。 前者をどれだけ検査しても後者は保証されない。
ゲートは4層になった
こうした事故のたびに検査を足していった結果、ゲートは4層になっている。
- 機械検証: JSONの構造、必須項目、値の範囲、採点に必要な項目を機械的に検査する
- 図形視覚検証: 図やスケッチを含む問題をレンダリングし、本文と図の整合性を確認する
- 自己解答ゲート: 配信前のレッスンをAIに解かせる。答えの漏洩や解釈の曖昧さは、解いてみると露見する
- セマンティックレビュー: 最後に意味の通り方、誤解の余地、学習者に出してよい品質かを確認する
検証ルールは運用開始時に完成していたわけではなく、事故が起きるたびに1本ずつ増えた。20本を超えるルールの一本一本に、対応する失敗がある。賢かったから増えたのではなく、痛かったから増えた。
何層あっても漏れる、を前提にする
それでも検証は漏れる。だから設計思想は「漏れない検証を作る」ではなく、**「漏れた事故を必ず新しい検証ルールに変換する」**という運用になっている。事故をゼロにする代わりに、同じ事故を二度と起こさない。
この考え方は、AIを何かに使うすべての場面に持ち出せると思っている。コラム「生成は簡単、信用が難しい」はこの経験の一般化だ。キットを使う人は、この検証ゲートを設計ごと手に入れることになる。