解こうとしたこと
ライブのセットリストは、ファンの間で共有されてはいるものの、記録の置き場所がばらばらです。あの曲はいつ披露されたか、この公演では誰が歌ったか、といった問いに答えられる形にはなっていません。
必要なのは記録アプリではなく、横断して辿れるデータベースだと考えました。
保存先を、データの性質で分ける
このアプリで一番効いた判断は、データを 1 箇所に集めなかったことです。扱うものを 2 系統に分け、それぞれ別の場所を唯一の正としています。
ライブ・楽曲・アイドル・セットリストといったマスタは CloudKit に置いています。理由は運用コストで、アプリを更新しなくても新しいライブを即座に配信でき、しかも保存できる量は利用者が増えるほど自動的に増えます。個人が長く続けるうえで、ここが従量課金だと詰みます。
一方、お気に入りや投票、ランキングといった集計系は Cloudflare Workers 側の D1 に置いています。数を確実に増やす、サーバ側で集計する、連投を制限する、同じ端末からの重複を弾く。この手の処理は CloudKit が苦手とするところで、無理に寄せると壊れます。
端末側では、CloudKit から差分だけを取ってきてローカルのデータベースに落とし、検索や絞り込みは全部そこで行います。オフラインでも動き、通信のたびに待たされることもありません。
権利に触れないように作る
非公式のファンメイドである以上、権利まわりの線引きは機能より先に決めるべきものでした。キャラクターの画像・歌詞・公式ロゴは一切収録していません。ジャケット画像も自前では持たず、Apple の API 経由で表示する経路だけを通しています。
この制約を後から足すことはできません。データの持ち方そのものが変わるためです。何を保存しないかを最初に決めて、その上に画面を載せました。
ユーザーの声を受けて、ソースを公開した
使ってくれているコミュニティから声をもらい、ソースコードを公開しました。ファンが集めたデータの上に成り立っているアプリで、中身が見えないまま個人が抱えている状態は、長い目で見て健全ではないと判断したためです。
ライセンスは商用利用を認めないものを選びました。誰でも読めて、非商用なら改変も再配布もできる。ただし営利目的では使えない。非公式ファンプロジェクトとしての立ち位置を、コードの側でも明示しています。
データの修正は 2 つの経路で受け付けています。ひとつはアプリの中から誰でも出せる編集の申請、もうひとつは JSON を置いて出すプルリクエストです。後者は送る前に手元で検証を回せるようにしてあり、そのために鍵や権限は要りません。外部の人が「これで通るか」を自分で確かめられない状態だと、結局オーナーに聞くしかなくなって参加の敷居が上がります。
版権まわりの制約は、参加規約として明文化しました。公開する以上、自分だけが守っていても意味がありません。
iOS と Android を 1 対 1 で揃える
Android 版も出しています。ここで決めたのは、両者のファイル構成とコンポーネントの割り方を意図的に同じにする、という運用でした。片方に入れた変更を、もう片方へそのまま横に写せる状態を保つためです。
プラットフォームごとに最適な設計を追うと、機能が増えるほど差が開いて、いずれ片方が置き去りになります。ひとりで両方を持つなら、それぞれの最適解より、写せることの方が価値が高い。
そのうえで Android 版は閲覧まわりに絞った部分移植としています。全部を追いかけるより、できていない範囲を正直に示す方が扱いやすいためです。
コミュニティ追記を受け入れる
コーレスや参考動画といった情報は、公式に存在するものではなく、現場にいたファンの中にしかありません。これを集めるには編集を開くしかない一方、開けば荒れます。
追記できる範囲は構造化されたものに限り、削除は履歴を残す形にしています。消えたように見えても実体は残るので、間違って消された情報を戻せます。
問い合わせを運用に載せる
紹介ページの問い合わせフォームは、送信内容をそのまま GitHub の issue として起票します。バグ報告・データの誤り・機能要望が、届いた時点で管理対象になる形です。
公開フォームなので、honeypot・送信までの経過時間・Cloudflare Turnstile の三段でスパムを落とし、通過したものだけを issue にしています。メンション記法と生 HTML は無害化してから本文に埋めているので、issue 経由で無関係な人に通知が飛ぶこともありません。