「動く」と「解ける」は別物。AIエージェントに150問解かせて見つけた本当のバグたち

「自動テストがすべてパスしているのに、ユーザーは問題を解けない」という逆説的な状態が実はよく起きている。ネットワーク設定の練習シミュレーターRouteLabで150問すべてをAIエージェントに解かせたとき、こうした現実のギャップが次々と見つかった。自動テストは「エンジンが正しく動くか」という機械的な正しさだけを見ていて、「ユーザーが問題文を読んで本当に解けるか」という実用的な正しさは検証していなかったのだ。採点条件が特定の数値を要求しているのに、その数値が問題文のどこにも書かれていない、あるいはコマンド出力から導き出せない。こんな問題は自動テストなら正解コマンド列を叩けばクリアするが、初見のユーザーはその数値をどこから拾えばいいのか分からずに詰まる。この機械的な正しさと人間にとっての解きやすさのギャップを埋めるために、AIエージェントに実際に問題を解かせる検証の仕組みを作り、トラブルシューティング系150問を完走させた。

AIの鬼が面白いと感じるのは、ここで何が見つかったのかではなく「何が見つからなかったのか」だ。ヒント表示ロジックが本番には存在しないのに検証では見えていた、show系コマンドの実装がごっそり抜けていたのに誰も気づかなかった、複数の正解があるのに採点は一つだけ認めている。こうしたバグは、UIを手で触って一通りテストするだけでは絶対に見つからない。たまたま誰もそのコマンドを打たなかった、たまたまそのモードを試さなかった、それだけで何ヶ月も静かに壊れたままになり得るのだ。AIに大量の問題を機械的に解かせるという「人間にはできない量と速度」を活用することで、初めて「あ、この機能ほんとは未実装だ」という報告が上がってくる。この発見の方法そのものが、これからのテストの在り方を示唆している。設計時のジレンマも興味深い。複数の正解がある問題で採点ロジックを緩めるか、それとも問題文を明確にするか。著者は後者を選んだ—機械的な利便性より、ユーザーが理解すべき本質を守ることを優先したのだ。

中小製造業が自社の業務管理システムを導入するときも同じ話が起きる。ベンダーの納入検査は「仕様通りに動くか」を見ている。だが、実務で誰かが使うときに「本当に仕事が進むか」「使い方が分かるか」は別の検証が必要だ。特に、業務の例外ケースや月末処理のような低頻度だが重要な場面こそ、誰も試していないまま本番を迎えることが多い。導入後に「ここ対応してくれ」という修正依頼の半分は、実はシステムのバグではなく、使う側が想定していなかった仕様との乖離だ。だから導入時は「テストがパスしたから大丈夫」と安心せず、実務で数週間試す時間を取り、「実際に解けるか、進むか」を人間の目で確認してから切り替える。それがシステム導入の失敗を減らす、最も地味で最も確実な方法だ。