Xのトイレ議論から、初めてのシミュレーターを公開するまで

きっかけは、Xで見かけた男子トイレと女子トイレの便器数を扱う投稿だった。

便器の数が違えば、同じ人数が同じ時間に押し寄せたとき、待ち時間はどのように変わるのか。数字だけを並べるより、実際に列が伸び、設備が埋まり、時間切れになる様子を見られたほうが考えやすい。

そこで、トイレの待ち時間を比較するWebシミュレーターを作ることにした。

私は、それまでシミュレーションを作ったことがなかった。

平均時間を掛けるだけではなかった

最初の題材は、学校の休み時間に一つのトイレへ利用者が集中する場面にした。

男子小便器、男子個室、女子個室を別々の設備として扱い、人数、男女比、利用可能時間、設備数を変更できるようにした。後から、イベント施設の幕間に来場者が集中するシナリオも追加した。

作り始めてすぐ、単純な割り算では足りないことが分かった。

「平均利用時間は本当に計算へ入っているのか」「全員が終わったように見えるのに完了率が98％で止まるのはなぜか」「中央値を使うだけでなく、利用時間を人ごとにばらつかせられないか」。画面を動かすたびに、見た目の問題からlogicの問題が見つかった。

現在のmodelでは、全員を同じ利用時間にせず、一定範囲の確率分布から一人ずつ占有時間を生成している。同じ条件と乱数seedなら同じ試行を再現できる。画面には仮定値も表示し、animation一回の印象と、modelが置いた前提を混同しにくくした。

もちろん、これは現実のすべてを再現するmodelではない。手洗い時間など、まだ含めていない要素も明記している。特定の結論を証明するためではなく、条件を変えたとき何が起きるかを観察する道具である。

チュッパチャップスから設備表示まで

logicと同じくらい時間がかかったのが、何をどう見せるかだった。

待機中の人を簡単な記号で表示したら、棒の上に丸が載った「チュッパチャップス」のように見えた。小便器のiconは便座に見え、個室の扉も意図と違った。使用中の薄い赤色は、説明されなければ気づけなかった。

そこで、人は球体へ簡略化し、待機列は無理に動かさず増減だけを見せた。設備は一列から始め、数が増えたら二段目へ送る。使用中は一目で分かる強い表示へ変えた。

全体designも何度も変わった。最初はWebサービスの紹介pageやペット向けサービスのように見えた。研究対象として考える画面へ寄せるため、色、余白、font、focus時の画面遷移を調整した。

背景には大きな数式が角度を変えながら現れ、縮小して消えるanimationを入れた。ただし、ここに流れる数式はsimulationで使っている式ではない。あえて過剰な研究室感を加える、非計算的な演出である。動きが苦手な人のために停止buttonも置いた。

合理性だけで作るなら不要な演出かもしれない。しかし、「トイレのsimulationなのに、なぜここまで壮大なのか」という少しの可笑しさは、このsiteらしさになった。

メールアドレスのない「受信箱」を作る

公開後に必要になるのが、修正依頼を受け取る窓口だった。

メールアドレスをsiteへ載せる方法もある。しかし今回は、利用者がformへ書いた内容を、そのまま自分のAOS Dashboardへ届ける仕組みにした。返信が必要な場合だけ、Xで連絡してもらう。

流れは、公開form、Cloudflare Turnstile、投稿専用Worker、D1、管理専用Worker、AOS Dashboardである。

Turnstileは「私はロボットではありません」と確認するCloudflareのbot対策だが、それだけで安全になるわけではない。受け取る項目と文字数を固定し、本文sizeを制限し、短時間の連続投稿を抑え、SQLへ値を埋め込むときはprepared statementを使う。管理用のsecretはbrowserへ渡さず、投稿本文はHTMLとして実行せずtextとして表示する。file添付は最初から扱わないことにした。

これはメール機能ではない。それでも、メールアドレスを公開せず、複数のsiteから一つの受信箱へ改善案を集めるという意味では、私が欲しかった「メールのような窓口」になった。

そして、この窓口は公開直後から役に立った。

Turnstileの成功表示が出ても送信buttonが灰色のまま、という状態が起きた。原因は本文が10文字未満だったことだ。機能上は正しくても、利用者には理由が分からない。そこでbuttonへ「内容を10文字以上入力」「セキュリティ確認を完了」と、その時点で不足している条件を表示するようにした。

安全に受け取る仕組みを作った直後、その仕組みの使いにくさを直すことになった。feedback loopとしては、むしろ理想的な最初の一件だった。

Sitesで、その日のうちに公開する

完成したsiteはOpenAIのSitesを使って公開した。

ローカルで画面を作り、logicと表示を検証し、同じsourceを公開版として保存する。Cloudflare側の投稿基盤とは分離しながら、公開siteから安全に接続した。

公開版はこちらから触れる。

Restroom Flow Lab — トイレ待ち時間シミュレーター

Xの一投稿から始まったのは、便器数の比較だけではなかった。

初めてのsimulation modelを作り、見た目の違和感を何度も直し、無駄に壮大な背景を加え、公開し、さらに利用者の声を受け取る入口まで作った。

agentと作る速度は確かに速い。しかし、最初から正解が出たわけではない。数字がおかしい、iconが違う、動きが鬱陶しい、文字が小さい、目的地が分からない。そうした人間側の違和感を遠慮なく返し、次の版をすぐ見る。その往復が、初めて作る種類の道具を一日で公開まで運んだ。

今回の開発で一番面白かったのは、simulationを作れたことだけではない。問いを動く形にし、その問いへ他の人が反応できる入口まで、一続きのsystemとして作れたことだった。