Seat Timeへの改名と、ゲームに届かなかったマージ
私たちがAIコーディングエージェントのチームと作るブラウザー運転ゲームは、Racing Simという名前に収まらなくなっていました。2026年10月の第2週には、仕事、財布、ライセンス、小さな街が加わっていました。レース以外も含められる名前が欲しくなったのです。その成長の裏で、「Merged」と表示された変更の一部が、ゲームに届いていませんでした。
改名自体は順調でした。古いリンクはゲームにつながり、保存済みの進行状況も残りました。難しかったのは、統合済みのはずの車が選択画面にいないことです。プルリクエストは、コードをレビューして統合するための変更提案です。その安心できそうな完了表示だけでは、足りませんでした。
レースゲームに財布と街が加わりました
運転の周りに、暮らしの要素が増えていました。開発記録には、ライセンス制度、チューニングショップ、アルバイト、走行距離、財布が並んでいます。有料プランやMiniature Rioの街での仕事も加わりました。分割前には、初期状態で無効のクレジット台帳、販売店、レンタル、ミッションもありました。
Racing Simという名前では、その周辺の活動が伝わりません。トロフィーやチューニング、運転の上達に費やす時間も含めたかったのです。そこで、ハンドルを握る時間を指すレース用語からSeat Timeを選びました。すべてをレースと呼ばずに、運転を中心に置ける名前でした。
ただし、名前だけでは範囲の問題は解決しません。レースをしに来る人と、仕事やお金の循環を楽しむ人では、同じゲームを開く理由が違います。改名で看板は変わりました。その先に何を置くかは、まだ決める必要がありました。
進行状況を残したまま改名しました
10月11日、ゲームをSeat Timeに改名しました。ファイルの移動は、移動だけを記録したコミットに分けました。コミットは変更の記録で、このときは1,412ファイルを移動しています。機械的な移動を独立させ、翻訳メッセージの接頭辞や古いアドレスも変更しました。
古い/games/racing-simのリンクは、新しい場所へリダイレクトします。言語とクエリーパラメーターも保持します。使ったのは、RFC 9110で定義された恒久的リダイレクトのHTTP 308です。規格が定義するのはステータスの意味です。言語やパラメーターの保持は、私たちの実装に含まれる処理でした。
保存データのキー、スキーマの識別名、データベースのテーブル名は、意図的に残しました。これらは、ブラウザーやデータベースにある進行状況とゲームを結ぶ名前です。内部まで新しい看板にそろえると、改名にデータ移行まで加わります。公開済みコンテンツのアーカイブも、当時の名前を維持しました。
内部に古い名前が残る境界は、見た目には不ぞろいです。それでも、公開名と保存データの識別子を分ける判断には意味がありました。守りたかったのは、ゲーム内でのプレイヤーの進行状況です。検索と置換を徹底することではありませんでした。
3日後、レースと生活を分けました
10月14日、範囲をSeat TimeとSeat Lifeに分割しました。Seat Timeはレース版です。チームガレージとワンメイクの進行ルートがあり、24台のレーシングカーを対象に27イベントを用意しました。Seat Lifeはレーサーの生活を扱う経済の拠点です。両方で1つのエンジンと1つのセーブプロフィールを共有しました。
進行状況を別々にせず、各版の目的を明確にできました。レースにはレースの入口を、仕事や経済の循環には別の入口を用意します。エンジンを共有したのは、関連する運転システムへの入口を分けたからです。シミュレーションを二重に作り直す判断ではありませんでした。
台数とイベント数は、分割当時の値です。そして、紙の上で範囲が整理されても、受け入れた変更が共有コードに届いたかどうかは分かりませんでした。
エージェントの作業コピーがディスクを埋めました
並行作業には、まずディスク容量という代償がありました。10月12〜13日ごろ、エージェントの作業コピーは413 GBに達し、空きは4 GBでした。個々のタスクは小さく見えても、コピーを合わせると開発に必要な容量を使い切ってしまいます。
私たちは、スパースチェックアウトを使うワークツリーへ移行しました。Gitのworktreeは、同じリポジトリにつながる別の作業ディレクトリです。sparse checkoutは、そこに展開する管理対象ファイルを一部に絞ります。組み合わせると、エージェントに必要な範囲だけを渡せます。毎回、完全な作業コピーを置く必要がなくなります。
自動チェックでも、完全なチェックアウト中に容量不足が起きました。10月13日にはリポジトリの履歴を書き換え、生成物を約1.1 GB取り除きました。これは履歴に保存されたデータへの対処です。各エージェントの作業場所に何を展開するかとは、別の問題でした。
履歴の書き換えは、記録の読み方にも影響しました。最初の150件のプルリクエストは、書き換え後のmainの履歴に属さなくなりました。初期の作業を確かめる主な記録は、保持された提案ページです。以後は、履歴につながらないという理由だけで、その変更が失われたとは判断できません。
統合済みの車が選択画面にいませんでした
Formula Club 1500 Aeroの欠落で、問題が具体的になりました。復旧記録には、新規ゲストの画面に24台が並び、Aeroがなかったとあります。提案はマージ済みでした。ただし、統合先のブランチは、すでにmainへのマージを終えていました。復旧では、元の履歴をmainに取り込みました。
ブランチは独立した開発の流れで、マージは選んだ先へ変更を統合する操作です。mainは私たちの共有統合先です。説明だけなら単純ですが、統合先を間違えると意味が変わります。「Merged」が示すのは提案の宛先への統合です。mainやプレイヤーが開くビルドへの到達を意味しません。
完了した提案とゲストの車一覧が食い違っていました。
親の統合が終わっても、子の宛先は残りました
落とし穴は、依存する提案を積み重ねる運用にありました。変更Aの上に変更Bを作り、Bの宛先をAのブランチにしたとします。Aが先にmainへ入ります。その後BをAのブランチへ入れると、新しい変更は、mainへの統合をすでに終えた場所に着きます。後のマージが、前の統合を自動で繰り返すことはありません。
積み重ね自体が誤りの証拠ではありません。11月3日の集計では、マージ済み516件のうち106件がmain以外を宛先にしていました。そこには、意図的にまとめて作業するブランチも含まれます。問題は、親の統合後も、その宛先を安全だと思い込むことでした。
同じ集計で、親の提案がmainへ入った後に、そのブランチへマージされた提案が13件見つかりました。時間差は1秒から約54分です。これは時系列のパターンに一致した件数で、13件の恒久的な損失を証明する数字ではありません。復旧したものや別経路で届いたものもあり、集計だけでは区別できません。
マージ時に必要な問いが変わりました。「準備できたか」だけでは不十分です。「今、どこへ入るのか」も確認する必要があります。提案を開いたときには正しかった宛先が、受け入れる時点では間違っていることがありました。
後日の例：10月24日の20秒
後日の事例では、秒単位で順序が分かります。10月24日、親の変更は15:36:20 UTCにmainへ入りました。軽自動車の物理変更は、15:36:40 UTCに親のブランチへ入りました。差は20秒です。mainは物理バージョン7を受け取らず、バージョン6のままでした。
その物理変更は、後からmainに取り込みました。欠落をどう発見したかは記録にありません。一方、マージの順序によってmainに古い物理が残ったことは分かります。これは、10月17日に到達確認を追加した後の出来事でした。
この事例で重要なのは、間隔の短さです。ブランチを何日も放置しなくても起きます。親が完了し、子がすぐ続いても、mainに届かないことがあります。正しい宛先を選ぶことも、作業完了の一部でした。
復旧では、ラベルではなく変更を取り戻しました
復旧が必要だったのは、車だけではありません。デプロイの公開処理を一本化する変更は、親のマージから14秒後に入り、別途取り込み直しました。受け入れ済みのアカウント、練習、ネイティブアプリの利用フローも対象でした。独立したChallenge Labも同様です。各事例で、実際の変更を見つけてmainへ届ける必要がありました。
もう1つの後日談は、10月31日の復旧です。学習済みドライバーのWatchデモは、親のブランチへ10秒遅れてマージされていました。復旧には、元の履歴を残す通常のマージを使いました。これにより、到達確認は元の変更をmainの祖先として認識できました。
すべてに復旧の結末があるわけではありません。Hall of Fameのデモ評価は、最後に確認した11月3日にも未到達と記録されていました。10月17日の監査で挙がっていた項目です。
ルールを決め、止められるチェックを加えました
ルールは、積み重ねた提案の宛先をmainに変えてからマージすることです。すでに統合済みのブランチへはマージしません。GitHubのベースブランチ変更の説明には、宛先の変更方法があります。表示されるコミットやレビューコメントが変わる可能性も警告しています。宛先の変更後も確認は必要です。
10月17日に追加した到達確認は、対象となる各提案の最終コミットがmainの祖先かを調べます。祖先とは、mainの記録された履歴をたどって到達できる変更です。見つからなければチェックは失敗します。例外は、同等の変更が届いたか、未到達と認めたかをレビュー済みの記録に残した場合です。
「同等」は別の経路で変更が届いたという意味です。「未到達」は既知の欠落を一覧に残します。どちらも、元の履歴がmainへ入った証明ではありません。書き換えた初期履歴も別扱いが必要です。最初の150件を誤警報にしてはいけません。
まとめて開発している途中では、このチェックが正しく失敗する場合もあります。受け入れた変更が共有の統合ブランチに残っているからです。必要なのは統合を終えることで、不便な警告を無視させることではありません。私たちのGitHub Actionsは課金上の理由で停止していたため、この確認はローカルの自動チェックで動かしていました。
新しいルールがあっても、後に物理変更の欠落が起きました。変わったのは、何をもって完了とするかです。マージ済みという表示には、宛先と到達の証拠が必要になりました。エージェントは実装と復旧を担当しました。私たちは作業を指示し、マージの判断に責任を持っていました。
次は、プレイヤーに何が届くかです
改名では、古いリンクと保存済みの進行状況を守れました。分割では、レースと経済の置き場所を明確にしました。しかし、どちらもマージ済みの提案を到達の証拠には変えません。完了と呼んだ変更も含め、mainまで追う必要がありました。
「マージ済み」が「mainにある」を意味しないなら、「mainにある」は「公開中」を意味するのでしょうか。
前回：雨と、停止中に動く車。次回：すべてのマージがリリースになる。
注記と出典
記録に基づく事実・設計上の判断 — 開発記録には、10月11日の改名、1,412ファイルの移動、保存用識別子の維持、リダイレクトが残っています。10月14日の分割、27イベント、24台のレーシングカー、共有エンジンとセーブプロフィールも同じ記録に基づきます。機能拡大の説明は変更タイトルに基づくもので、今回の機能監査ではありません。本記事の日付はすべて2026年です。
測定値 — 開発記録では、10月12〜13日ごろの作業コピーが413 GB、空き容量が4 GBでした。10月13日の履歴書き換えで、生成物を約1.1 GB取り除きました。11月3日の集計は、提案の宛先、元ブランチ、マージ時刻を照合しています。マージ済み516件中106件がmain以外を宛先とし、13件が遅いマージのパターンに一致しました。時間差は1秒から約54分です。恒久的に欠けた機能の件数ではありません。
記録に基づく事実 — 復旧記録は、Aeroの欠落、10月24日の物理変更の順序、公開処理と利用フローの復旧、10月31日のWatch復旧を裏づけます。Aeroの欠落と復旧の日付は不明です。10月17日の監査と到達確認の記録には、安全策とHall of Fameの未解決項目が残っています。最終確認日は11月3日です。この記録のための新しい実機走行や、現在公開中のビルドの評価は行っていません。
公開資料 — RFC 9110の308 Permanent Redirect、Git worktree、Git sparse checkout、GitHubのプルリクエストのベースブランチ変更は、仕組みの説明です。私たちの開発履歴を独立して検証する資料ではありません。
私たちの解釈 — 「Merged」は提案の状態であり、製品の中身を示すものではありません。この記事の執筆と翻訳にはAIを使用しました。過去の事実は、保存された私たちの開発記録に基づきます。