営業時間の変更を利用者がすぐ直しても、承認待ちの間は別の訪問者が古い時間を読む。公開前に誤りを確認する手続きが、正しい更新も遅らせるのである。12月には許可された編集を先に反映し、履歴で後から確認する方式を選んだ。Deltaでは領域別保存と変更履歴、必要に応じた公開申請でこれを具体化した。

編集申請と承認待ち

従来は運営者が申請を読み、実際のデータを変更していた。公開前に誤りを除ける利点はあるが、正しい修正も同じ順序を待つ。店舗と参加者が増えるほど、現地を知る人の修正時点より、運営者がメールや申請を読む時間が更新速度を決めるようになる。

すべてを一度に開くのではなく、問題があれば追跡して戻せる領域から始めた。営業時間のような日常的な値は履歴とともに保存し、後から確認する。公開判断や確認が必要な基本情報は申請に残す。確認を続けながら正しい修正の待ち時間を減らす選択だった。

移行は段階的だった。2025年12月には営業時間を即時反映したが、公開済み基本情報の変更は申請のままとした。2026年3月には公開文書の基本情報も直接反映へ広げた。12月の方針決定と、すべての保存経路の変更時点は一致しない。

flowchart TD
    accTitle: 変更の性質によって反映時点を分ける
    accDescr: 許可された日常編集は履歴とともに反映し、公開判断が必要な変更は別の確認を待つ。
    U[ログイン済み利用者の編集] --> D{変更の性質}
    D -->|即時編集が可能| A[変更と履歴を保存]
    D -->|公開判断が必要| Q[別の確認リクエスト]
    A --> R[事後確認]
    Q --> O[運営者の判断後に反映]

作成者の確認と新店舗の公開要件

事後に編集を確かめるには、まず作成者が必要だ。サーバーはログイン中のアカウントから作成者を取得して履歴に残す。ブラウザーが送る任意名を使うと、誰が編集したか確認できないためである。ただし識別できることと、すべての公開判断を任せることは別に検討する。

新店舗は検索に出ない非公開下書きから始まる。下書き保存と公開には異なる手順が必要だった。当初は作成者と現在の公開および閉店状態を確認し、公開申請をarcade_ticket_requestに残して審査した。

3月末には、公開もサーバーが要件を検査して直接反映する方式へ変えた。申請者が作成者か、公開済みまたは閉店済みではないかを確認する。ゲームと連絡先、または営業時間と写真など必要資料も調べる。個別承認を減らしても、新店舗に必要な情報がそろっているかの確認は続ける。

領域別バージョンと現在参照の更新

変更を戻すには以前の値を残す必要がある。営業時間は上書きせず新しいarcade_hourレコードを作り、文書のhourが現在のものを参照する。基本情報、連絡手段、施設、ゲームも領域別レコードと現在参照を持ち、一つの領域を独立して修正できる。

参照を変える共通処理は以前の値を読み、新しい値を適用しながらarcade_changelogへ保存する。changedが領域、fromとtoが前後の状態、byが作成者である。現在参照と履歴を同じDBトランザクションで更新し、新しい内容だけ公開され履歴がない状態を防ぐ。

営業時間の新レコードは、この共通トランザクションより前に作る。参照更新が失敗すれば新レコードの削除を試みる。したがって作成からすべてが一つのトランザクションなのではなく、利用者が読む現在参照とその変更履歴が一緒に確定する。

sequenceDiagram
    accTitle: 現在の参照と履歴を一緒に確定する
    accDescr: 新しい営業時間レコードを作った後、現在の参照と変更者を含む履歴を同じデータベーストランザクションで保存する。
    participant U as 編集者
    participant S as サーバー
    participant D as データベース
    U->>S: 認証情報と営業時間の変更
    S->>D: 新しい営業時間レコードを作成
    S->>D: 参照の更新とfrom・to・byの保存
    D-->>S: 一緒に確定または取り消し
    S-->>U: 保存結果

反映後の確認に使う比較資料

事後確認は、誰がどの店舗のどの領域を変えたか探すところから始まる。その後fromとtoを比べる。例えば料金一項目の修正と営業時間の全削除では、確認する内容が違う。時刻だけの活動一覧では実際の値を見た判断を代替できない。

履歴があっても、内容が現地と一致するとは限らない。履歴は以前の状態と比較資料を提供する。確認申請も運営者へ対象を知らせる手段であり、受理だけで文書修正やアカウント制裁が終わるわけではない。内容と必要な対応は引き続き確認する。

以前の状態への復元とアカウント対応

誤りが分かれば対象領域の以前の状態を選び、現在参照を戻す。同じ店舗の同じ領域かも検査が必要だ。他文書のIDをつなぐと、復元ではなく関係を壊す変更になるためである。

復元しても元の変更は残す。戻した操作を新しい履歴として追加し、編集と復元を両方見られるようにする。文書を戻しただけで作成者の権限を自動制限しない。内容の訂正とアカウント対応は、それぞれ確認する必要がある。

flowchart TD
    accTitle: 復元と運営判断の境界
    accDescr: 実際の変更を比較し、同じ店舗と項目の以前の状態を選んで復元する。復元は新しい履歴に残り、アカウントへの処置は別に判断する。
    S[現在の状態と変更履歴] --> A[変更前後を比較]
    A -->|問題を確認| C[同じ店舗と項目の以前の状態を選択]
    C --> R[現在の参照を復元して履歴を追加]
    A -->|運営判断が必要| O[別の確認と処置]

反映速度と継続的な確認

許可された編集は、運営者が申請を開くまで待たずに済む。一方、誤情報が確認前に見える可能性もある。履歴、確認申請、復元を備えたうえで実際に記録を読み対応する運用が必要だ。更新を速める効果は、この後続作業を継続できてこそ維持される。

関連記録：Musecatの開発記録。