「動いた」をどこまで信じるか——AIで作ったLINE予約のテスト設計

AIに実装を任せると、LINE予約ボットは驚くほど早く形になる。イベントを選ばせ、人数と名前を聞き、最後に「予約を受け付けました」と返すところまでが、まず最初にできあがる。

自社で運営しているうどんカフェのLINE予約でも、そうだった。そして、そこからが本題だった。

早く「動く」ものができるほど、危なくなる言葉がある。「動いた」だ。

「動いた」は1回ではなく5回ある

このLINE予約で「動いた」と言えそうな瞬間を数えたら、5つあった。

• LINEの会話が最後まで進んだ
• 予約APIが応答を返した
• 予約台帳（スプレッドシート）に行が追加された
• 満席・残席不足のときに、ちゃんと止まった
• 公開後、予約失敗や台帳漏れが起きていない

全部まとめて「動いた」と呼ぶと、最初の1つが確認できた時点で、残りの4つも済んだ気になる。実際には、会話が最後まで進むことと、予約が本当に台帳に入ることは、まったく別の保証である。

一番避けたいのは、お客さんが「予約できた」と思っているのに、台帳には何も残っていない状態だ。動かない機能は直せばいいが、動いたように見える機能は、事故が起きるまで気づけない。

テストを4層に分けて、それぞれの保証範囲を言葉にする

そこで、テストをひとまとめにせず、4層に分けて記録した。

分けて言葉にした理由はひとつで、偽物のAPIで通った結果を、本番の保証だと誤解しないためだ。

部品テストでは偽物の予約APIを使っていい。会話の順番を確認するのが目的だからだ。ただしその合格が保証するのは「会話が壊れていない」ことだけで、本物のスプレッドシート連携は1ミリも保証しない。ここを分けずにおくと、「ローカルでは動いた」がいつの間にか「本番でも予約できる」にすり替わる。

AIで実装が速くなるほど、この誤解も速く起きる。作る速度はAIが上げてくれるが、どの層のテストが何を保証するかを言葉にするのは、人の仕事として残った。

「完了」の確定だけは、AIの会話に渡さない

4層の中でいちばん硬く決めたのは、確定の条件だ。

台帳への書き込みが成功した後だけ、「予約完了」と返す。

スプレッドシートが落ちている。権限が切れている。APIが失敗した。残席が足りない。台帳の状態が確認できない。——このどれかに当たったら、会話がどれだけ自然に進んでいても、内部の扱いはすべて「予約未完了」にする。お客さんへの文面はやさしくていいが、完了か未完了かの判定を会話の雰囲気に任せない。

AIは会話を進めるのがうまい。うまいからこそ、確定の判定まで会話側に持たせると、「予約できましたと言ってしまったが、実は書けていなかった」が起きる。会話の進行はAIに任せ、完了の確定は台帳の書き込み結果だけで決める。ここが今回引いた、いちばん太い線だった。

止める場所は、最後の1箇所に頼らない

残席の扱いも同じ考え方で設計した。残り1席のイベントに2名で申し込まれたとき、最後の確定時に止めるだけでも事故は防げる。ただ、お客さんは途中まで進んでから断られることになる。

だから残席チェックは1箇所ではなく3箇所に置いた。満席のイベントは候補に出さない。人数入力の時点で残席を超えたら止める。確定時にも最新の残席でもう一度確認する。実際のテストでは、残席2名の公演に4名で進んだケースで、完了にせず理由を返して受付中の候補を出し直すところまで確認した。

守りの判定は、最後のゲート1つに集めるより、早く止められる場所に分散させたほうが、体験も安全も両方よくなる。

今回の線引き

この現場のお店向けの記録は、mise の記事『「予約したつもりが、できてなかった」を避けるLINE予約テスト』として別に残している。設計側として持ち帰ったのは次の3つだ。

• 「動いた」を層で分け、各層が何を保証するかを言葉にする
• 偽物のAPIの合格を、本物の連携の保証と誤解しない
• 「完了」の確定はAIの会話に渡さず、台帳の書き込み結果だけで決める