Mirai Guide：欲しいものから逆算して一日を組む

グッズイベントで一番難しい問いは「何が欲しいか」ではありません。

「何時に起きればいいか」です。

Mirai Guideは、最も売り切れやすい品を起点にして、一日を逆算することでこれに答えます。

逆算のタイムライン

各段階を右から左へ導くので、鎖の終点が起床時刻になります。

品ごとの目標入場時刻は、そのリスク曲線と本人のリスク許容度ダイヤルの関数です。
入場の目標時刻は、カート内すべての目標入場時刻のうち、最も早いものです。
会場到着時刻は、その到着オフセットで見込まれる入場列の待ち時間を引いたものです。
家を出る時刻は、移動時間と駅からの徒歩を引いたものです。
起床時刻は、個人の準備バッファを引いたものです。

これを誠実に保つ規則が2つあります。

出力は常に信頼区間つきの幅で表示し、単一の分は示しません。そしてUIは、この計画があくまで目安だとはっきり書きます。こちらのモデルが自信ありげに見えたせいで、誰かが電車を逃すのは避けたいです。

もう1つ、移動時間はアプリ内で計算しません。時刻表データはライセンスの対象なので、来場者が乗換サービスへのプリフィル済みリンクで所要時間を確認し、その数値は端末内にだけ保存されます。

較正する歴史コーパス

モデルが学ぶのは、アプリがたまたま観測したものではなく、著述された歴史コーパスです。リポジトリ内で構築し、バージョンを付け、管理画面からアップロードします。データベースへ直接シードすることはありません。

バンドルは2種類のレコードを持ちます。完売イベントは事実表で、公式の当日完売告知です。観測はそれ以外のすべてを縦持ちの整然形で保持します。1測定1行で、観測種別（待ち時間、処理能力、伸び、ブースや商品の人気度、文脈定数、較正済みモデルパラメータ）、任意のスコープ、主体、単位と任意の上下限を伴う指標、任意の時点、そして来歴を持ちます。

スキーマ自体より重要な性質が2つあります。

新しい共変量は自由形式のfeaturesオブジェクトに入り、マイグレーションにはなりません。 将来の精密モデルは、スキーマを追いかけずにこの表を直接読めます。
ビルドは決定的です。 同じ著述元から同一バイトのバンドルが生成されるので、差分がきれいで、ハッシュも安定します。適用は内容由来のIDによる追記のみなので、同じバンドルの再適用は何もしません。1行だけ書き直して再ビルドし、再アップロードすれば、その1行だけが入ります。

各行は出典とレビュー状態を持ちます。時刻が判読不能な行は診断として提示して飛ばします。黙って事実になることはありません。

来歴は設計上の制約

歴史的な完売データは、一次資料である公式告知から再導出します。コミュニティの集計記事は、データが存在することを示すものとして読み取り専用の相互確認に使い、複製はしません。公開前に著者へ謝意を伝えるべき相手として扱います。

この制約が、取り込み経路の形そのものを決めました。コーパスは各行の出所と確信度を記録します。

来歴を示せない予測を、これから目覚ましを何時にするか決めようとしている人の前に置きたくはありません。