9月10日｜まず、AIの予定ではなく要件を聞く。

みんなで集まりたい。でも、返事はチャットのあちこちに。「土曜は○」「日曜は夕方なら△」。このままでは、予定を決める前に読解力が試されそうです。そこで、最初に頼んだのはアプリではなく要件定義書でした。

わたし：みんなでスケジュール調整をしたいときに、みんながアクセスできて、予定の日時をいれたスケジュール表に、みんなが各自で予定をいれて、空いている日時を簡単に決められるWebサイトを作りたい。そのための要件定義書を作って。

AI：参加者が候補日時に回答し、幹事が集計結果から日程を決められるサイトとして、要件定義書をまとめます。未指定の点は初期案として明記し、そのまま開発の相談に使える形にします。

会員登録なし、日本時間、候補50件、回答者100人。こうした具体的な数字はAIの初期案から。こちらの「みんなで使いたい」が、保存方法や入力ルールを持った計画になっていきます。

「心配な点は？」と聞いたら、ちゃんと出てきた。

わたし：要件定義書で心配な点はないですか？

AIが挙げたのは、招待した全員が回答したか分からないこと、候補の変更に気づきにくいこと、管理URLをなくすと復旧できないことなど。「心配ありません！」で終わらないあたり、なかなか現実的な相談相手です。

では、提案された改善を全部盛りにするのか。ここでの返事はこうでした。

わたし：この要件定義書のままでWebアプリを作成して

AI：会員登録なしで使える『作成 → URL共有 → ○△×で回答 → 日程確定』の流れを組み立てています。前回挙げた改善案は追加せず、元の要件どおりに実装します。

心配を知ったうえで、まずは決めた範囲を作る。アプリの候補機能まで、延々と日程調整するわけにはいきません。

○を並べるだけの表に、意外と仕事がある。

たとえば土曜日に付けた○。幹事が候補を日曜日に変えたとき、その○まで引っ越してしまったら困ります。日時が変わった候補は未回答へ戻す。変更していない候補の回答は残す。そんなルールも実装しました。

同時に何人かが保存しても、ほかの人の回答を上書きしないこと。自分の回答を直せても、他人の回答や幹事の設定は変えられないこと。表の表面はシンプルでも、裏側の仕事はなかなか几帳面です。

「全員参加可能」という言葉にもひと呼吸。分かるのは、回答した人たちの都合まで。まだ返事をしていない人の予定を、AIが気合いで埋める機能は付けていません。

公開の前に、まず道具の準備でひと騒動。

制作記録には、開発環境にnpmがなく、公式配布物を用意して進めた経緯が残っています。さらにアプリ本体の検証後も、公開先への転送でひとつまずき。

AI：アプリ本体と保存機能の検証は完了しています。公開先への転送で環境上の問題が出たため、接続を整えて公開作業を続けます。

みんなが集まる日の前に、必要な道具と接続をそろえる時間がありました。その後、転送は成功。動くことと、みんなに触ってもらえること。その間にも作業があるのだと分かります。

9月22日｜「いつ」の次は、やっぱり「どこ」。

ここからは会話の再現ではなく、変更履歴に残る話です。「場所・お店の投票」が加わり、幹事が最大20件の候補を出せるようになりました。日程に回答した人は、複数のお店に投票できます。

候補のお店の内容を変えたら、その候補への票は取り消す。日程の○と同じ考え方です。最初のお店に賛成した人を、知らないうちに別のお店の推薦人にしないための仕組みでした。

日時入力にも小さな改善。開始を入れたら終了も同じ日時にそろえる。でも、元の保存ルールは「終了は開始より後」。画面だけ気を利かせると、保存する側に断られてしまいます。そこで同時刻も受け付けるように、裏側とテストも一緒に直しました。

同日｜あわせる、occam.jpへ引っ越す。

今回は画面と操作を引き継ぎ、保存部分をXServerで動くPHP・SQLiteに移植しました。旧公開先のデータは移さず、occam.jpでは新しい予定からスタート。アプリの引っ越しと、参加者の予定の引っ越しは別にしました。

公開先では、3人の同時回答、古い編集の拒否、候補変更、場所投票、確定と取消などを確認。画面からの作成・回答とスマートフォン幅の表示も確かめています。テスト用の架空の集まりは、確認が済んだら片づけました。

最初は、みんなの○△×を並べたかっただけ。触ってみると「場所も決めたい」「終了日時もそろえたい」が出てきます。AIに頼んで、実際に使う場面を考えて、また直す。少しずつ、幹事のやることを減らしていく制作になりました。

9月22日・夜｜予定表にも、片づけ当番が必要でした。

日程が決まって、集まりも終わった。そのあと、予定表はどうなるのでしょう。作るときは「いつ会う？」で頭がいっぱいですが、保存する側には「いつまで残す？」という仕事もあります。

これまでも、作成から180日を過ぎた予定は開けなくしていました。ただし、データを実際に消すのは、誰かがアプリを更新操作したとき。アクセスが途絶えると、片づけのきっかけも来ません。店じまいはしているのに、机の上の紙はそのまま。そんな状態を残さないための更新です。

そこで、毎日午前3時15分、日本時間で片づけ当番が動く設定を追加しました。人がサイトを開かなくても、保存期限を過ぎた予定と、その中の名前・コメント・回答・場所の投票をまとめて削除します。期限内の予定は、そのまま。まだ集まる相談をしている人たちまで、お開きにはしません。

確かめたのは、期限の直前・ちょうど・直後で対象が分かれること、試行だけなら消さないこと、繰り返しても期限内の予定が残ること。途中で処理が失敗したら、半端な削除を取り消せることも、テスト用のデータで確認しました。「消せました」だけでなく、「残すものを残せました」までがセットです。

最初の手動実行では、期限切れの予定は0件。いきなり大掃除、とはなりませんでしたが、動作結果を記録できるところまで確認しました。初回の時刻表を待たずに試運転しておくのも、公開後の地味な仕事です。

今回は画面のボタンは増えていません。AIと作るアプリの更新には、目立たないけれど必要な「後片づけ」もある。集まる日の調整から始まって、データを片づける時間まで決めることになりました。

この追記は実装・テスト・サーバー設定の記録に基づきます。新しい会話の台詞は補っていません。定期実行の登録と初回手動実行を確認済みです。自動バックアップ・障害通知は別の課題として残っています。