Gitを置き換えるか？EpicがOSS化した次世代VCS Lore

Epic Games が MIT ライセンスで次世代バージョン管理システム Lore を公開した 出典。

Rust 実装で、ゲームのような巨大バイナリとコードを同一リポジトリで扱う前提に最適化されている。

Git の代替を唱えるプロダクトは過去にもあったが、Unreal を抱える Epic が本気で OSS 化した点に意味がある。

巨大アセットが VCS を壊す問題

従来の Git はテキストコードには強いが、ゲームアセットのような大容量バイナリでは LFS や Perforce 併用が一般的だった 出典。

Lore はコンテンツアドレスストレージとチャンク分割、オンデマンドのハイドレーションで「全部落としてから作業」を避ける設計を採る。

Epic が OSS 化した理由

Epic はオープンエコシステムを業界全体で育てる必要があると説明し、Lore を完全オープンソースで公開した 出典。

一社だけが握る VCS では、他スタジオやツールベンダーが乗りにくい。

将来の業界標準を狙う布石と読める。

まだ「未来の VCS」

公式 FAQ でも本番運用レディではないと明記されている 出典。

アーキテクチャ文書、CLI、複数言語 SDK は揃いつつあるが、Git からの移行は文化ごと変える挑戦だ。

早期採用は実験的なチームに限られるだろう。

日本のゲーム業界への示唆

国内スタジオも Perforce + Git のハイブリッドに悩む例は多い。

Lore が成熟すれば「アセット中心の VCS」という第三の選択肢になりうる。

今はウォッチリストに載せる段階と言える。

ゲームや映像制作のような巨大バイナリを扱うチームに、Git では足りないスケールとワークフローを提供する次世代 VCS として位置づけられる 出典。

Epic Games が MIT でオープンソース公開した点は、一社専用ツールではなく業界標準を狙う意図を示す。

ただし公式 FAQ でも本番運用レディではないと明記されており、PMF は「将来の可能性」段階だ 出典。

早期採用は実験的チームに限られる。

ゲーム業界向けの大規模バイナリ最適化と、Epic 内プロジェクトでの実績が積み上がれば強い堀になる 出典。

汎用 Git では再現しにくいドメイン特化の設計が武器だ。

ただし現時点では OSS として公開されたばかりで、実績の蓄積はこれからだ。

チーム全員が同一 VCS 上にいるほど価値は上がるが、現時点では普及前で効果は限定的だ。

Git の圧倒的なシェアがネットワーク効果の障壁になっている。

業界標準として採用が進めば強まるが、鶏と卵の問題がある。

ゲーム開発者、アーティスト、大容量アセットを扱うエンタメ制作チームが主ターゲットだ。

テキストコード中心の Web 開発チームには過剰スペックだ。

Perforce に不満を持つスタジオや、Git LFS の限界に直面しているチームが初期採用候補になる。

Epic Games のブランドと Unreal エコシステム内での実利用が最大の信頼材料だ 出典。

バイナリファースト設計、コンテンツアドレス、Merkle 木による整合性は、ゲーム業界の実課題に直結する。

MIT ライセンスでの完全 OSS 公開は、他スタジオやツールベンダーの参入障壁を下げ、エコシステム拡大の起点になりうる。

Git からの移行コストは文化ごと変える挑戦で、エコシステムは未成熟だ 出典。

Perforce や Git LFS の既存慣行が強く、短期間での置き換えは現実的でない。

本番運用未対応のため、ミッションクリティカルなプロジェクトへの採用はリスクが高い。

OSS コミュニティ、Discord、Epic 内プロジェクトからの実利用拡大が主軸だ 出典。

マーケティングより、実プロジェクトでの成功事例の蓄積が普及の鍵になる。

ゲーム・映像業界のカンファレンスや技術ブログでの啓蒙も想定される。

インフラ級プロダクトはコード公開だけでは普及しない。

実プロジェクトでの実績が物語になる。

Epic のように自社で痛みを持つ企業が OSS 化する動きは、業界標準を狙う布石として参考になる。

Git との共存期間を前提に、段階的移行パスを設計することが普及の鍵だと言える。

日本のゲームスタジオはバイナリ資産が大きく、Perforce + Git のハイブリッドに悩む例は多い。

日本語ドキュメントと Perforce からの移行ガイドがあれば関心は高い。

国内スタジオとのパイロット導入事例ができれば、ゲーム業界内での口コミ獲得につながりうる。