AKIの予約を、実フォームから通知まで通した。

2026年8月22日、AKI SERVICE v0.8からv0.9で、予約システムの実動テストを行った。

作ったのは予約画面の見本だけではない。

利用者がフォームへ入力し、その内容が実際のデータベースへ保存され、通知キューへ渡り、予約確認の通知が作られるところまで接続した。

予約サイトは、フォームが送れれば完成に見える。

しかし現場では、その後に確認、確定、変更、キャンセルが続く。

誰の予約なのか。

いつの枠なのか。

いまは受付済みなのか、確定なのか。

変更した時に古い予定が残らないか。

画面の外側にある処理をつながなければ、結局は人がLINEやカレンダーへ写し直すことになる。

今回のテストでは、実フォームから実DB、通知キューまでを通し、予約確認通知を実装した。

次の課題として、AKI HOMEとの連携、予約確定時の処理、キャンセル時にカレンダー上の予定を確実に消すことを残した。

ここを曖昧にしたまま一般利用へ進めると、二重予約や消し忘れが起きるため、テストと実予約を区別して止めた。

同じ日は、福岡第一高校陸上部の同窓会の日でもあった。

受付、会費、写真共有、無事帰宅までを幹事一人に背負わせない「また会おう。」の発想も、予約システムと同じ問題から生まれている。

人が覚え、転記し、確認している仕事を、一つの流れへ移すことだ。

この日の具体的な成果は、予約画面ではなく、入力された情報が次の処理へ渡ったことだった。

動く仕組みを作るとは、見えるページを作ることだけではない。

その裏で、データと通知と人の判断が正しい順番につながる状態を作ることだ。