古い記事に「いいね！」を押したあと、バックオフィスの記事一覧を開いた。すると、その記事が一覧の一番上に近い位置へ移動していた。
古い記事が突然、一番上に上がってきた
「え？」
最初は見間違いかと思った。記事一覧は更新日時の降順で並ぶ仕様だったので、古い記事が突然上に来る理由が思い当たらなかったからだ。調べてみると、原因は単純だった。ユーザーが「いいね！」を押したタイミングで、記事レコードそのものが更新され、updated_atまで更新されていたのである。
機能は動いている。でも、業務では困る
一見すると、この実装は間違っていないようにも見える。いいね数は増えている。画面表示も正しい。データベースにも正しく保存されている。だから、プログラムとしては正常に動いている。
でも、業務として見ると話は変わる。
記事を書き直したわけではない。タイトルを変更したわけでもない。本文を修正したわけでもない。公開設定を変えたわけでもない。ただ、ユーザーが「いいね！」を押しただけだ。
それなのに、記事が更新された扱いになってしまうと、管理画面では「最近編集された記事」のように見えてしまう。運営側からすると、かなり紛らわしい。この瞬間、「データが更新された」と「記事が更新された」は、同じではないのだと改めて感じた。
AIなら、この実装を選んでも不思議ではない
この事例を見ていて思ったのは、「AIが悪い」という話ではない。むしろ、AIならこの実装を選ぶのは自然だと思った。
データが変わる。だからレコードを更新する。レコードを更新するなら、updated_atも更新する。実装だけを見れば、非常に筋が通っている。実際、人間がコードレビューだけをしていても、違和感なく通ってしまうかもしれない。
問題は、業務上の意味まで仕様として伝わっていなかったことだった。
人間なら空気で補えることが、AIには伝わらない
人間同士の開発なら、「いや、それ記事を更新したわけじゃないよね」という会話が自然に出る。「更新日時は変えないほうがいいですよね」と、設計を修正することも珍しくない。
でも、AIは空気を読まない。正確に言えば、空気ではなく、書かれた仕様を読む。仕様書に書いていない以上、「データが変わるなら更新する」という判断をしても不思議ではない。
私はこの不具合を見たとき、「AIが仕様を理解していない」のではなく、「こちらが業務上の前提を書いていなかっただけなんだ」と感じた。
テストケースにも書かなければ見逃す
この不具合は、テストケースにも表れやすい。
例えば、「いいね！を押すと、いいね数が1増えること」。これは誰でも書ける。でも、本当に確認すべきだったのは、その先だった。
「いいね！を押しても記事の更新日時は変わらないこと」
「お問い合わせを送信しても記事一覧の並び順は変わらないこと」
「閲覧数が増えても管理画面で編集済みの記事にならないこと」
この観点を書けるかどうかで、品質は大きく変わる。カウントが増えたかどうかだけを確認していたら、この不具合はそのままリリースされていたと思う。
AI開発では「更新しないもの」を仕様に書く
生成AIのおかげで、実装スピードは驚くほど速くなった。その一方で、人間同士なら言葉にしなくても伝わっていた前提が、少しずつ通用しなくなってきているとも感じる。
「何を更新するか」は仕様に書く。でも、それだけでは足りない。これからは、「何を更新してはいけないか」まで仕様として明文化することが、AI開発では当たり前になっていくのかもしれない。
今回の不具合は、派手にシステムが壊れたわけではない。それでも、現場では確実に困る。そして、こういう“意味のズレ”は、正常に動いているように見えるからこそ見逃されやすい。
AI時代のQAは、機能が動くかどうかだけを見る仕事ではない。その動きが、業務上も本当に正しいのか。そこまで考えることが、これからますます大切になるのだと思った。