次世代バージョン管理システムの基礎となる堅牢なアーキテクチャ「Manyana」、CRDTの利用によりマージやリベースに強みを発揮

「CRDT」って何？従来のバージョン管理システムと何が違うの？

CRDTというのは、複数の人が同時に同じデータを変更しても、その変更の順序がどうであれ最終的な結果は必ず同じになるという仕組みです。通常のバージョン管理では、AさんとBさんが同じ箇所を編集するとコンフリクトが起き、どちらの変更を優先するかを人間が判断しなくてはなりません。でもCRDTなら、そもそもコンフリクトが「解決不可能な問題」ではなく、「情報を提供するシグナル」に変わります。 記事の例でいうと、関数を丸ごと削除した人とデバッグ出力を追加した人の変更が衝突する場合、従来のGitでは何が起きたのか読みづらい競合マーカーが出ます。でもManyanaではどの行が誰に削除されて、どの行が誰に追加されたのかが明示されるんです。つまり「何が起こったか」を正確に理解できるようになる。人間がやることは「どちらを採用するか」という一つの判断だけになります。 さらに興味深いのは、CRDTなら履歴をリセットして新しい基盤の上に積み直すリベース操作でも、元々の履歴が破壊されないということ。Gitでリベースが怖いのは、本来の歴史が改ざんされるから。CRDTではその心配がなくなるわけです。要は、バージョン管理が「競合を避ける」から「競合を明示しながら常に正しい結果を保証する」へシフトしようとしているのかもしれません。

プログラマーじゃない人にとって、Manyanaが便利になることって関係あるの？

バージョン管理システムって、コードを書く人だけのツールだと思いがちですが、実は関係あるんですよね。 デザイナーやライター、企画の人たちが複数で同じファイルに変更を加えるシーン、ありますよね。図版を修正したり、ドキュメントに追記したり。そういう場面でも「どの版が正しいのか」「誰の変更が反映されているのか」を追跡するのは難しい。Manyanaが実現する「結果整合性」と「構造化された履歴」は、その問題に直結しています。 今の仕組みでは、複数人が同じファイルを編集すると衝突が起きて「どちらの変更を採用するか」を手作業で判断する羽目になります。Manyanaなら衝突が起きても「Aさんはここをこう変えた、Bさんはあそこをこう変えた」という情報が自動的に構造化されるから、判断がずっと楽になる。プログラマーでない人こそ、その恩恵が大きいかもしれません。 ただ、それは実装がこの先どう進むかにかかっているのかもしれません。

Gitが主流になってからもう何十年も経ってるのに、なぜ今になって次世代を考え始めたの？

Gitが登場した2005年から20年近く経った今、わざわざ後継を模索する理由は、Gitが解決できなかった「ある種の本質的な問題」が可視化されてきたからなんですよね。 Gitの時代、バージョン管理の課題は「複数拠点での同期」や「高速な処理」でした。そこは確かに解決した。でも、人間がコードを書く現場では別の厄介ごとが積み重なってきた。マージコンフリクトの不可解さ、リベースによる履歴の改ざん感、複数チームの並行作業での「何が起こったのか」の推理の難しさ。 これらは小さなプロジェクトなら我慢できる。でも、何百人が開発する規模になると、コンフリクト解決に費やす時間やバグの追跡の複雑さが無視できなくなる。また、AI がコード生成を始めた時代には、自動マージされた変更の信頼性を保証する仕組みが急に重要になってきた。 つまり、Gitは十分に成熟しているからこそ、その限界がようやく問題として浮上している。技術進化の典型的なパターンで、古い世代の「限界との共存」が次の世代への問い合わせになるのかもしれません。

結局のところ、CRDTを使った新しいシステムって『コンフリクトを完全になくす』んじゃなくて『コンフリクトの情報を見やすくするだけ』なの？

その指摘は正しいのですが、実は「見やすくするだけ」では済まない部分があるんです。 従来のGitでは、コンフリクトが発生した時点で**マージ操作そのものが失敗**します。人間が手で解決するまで先に進めない。対してManyanaでは、コンフリクトの表示は出ますが**マージは成功する**。その差は思った以上に大きい。 イメージするなら、Gitは「道が塞がっているから通行止め、あなたが道を修復してください」で、Manyanaは「道は通るけど、このルートで起きた変化は記録しておきます」という感じ。複数の人が並行作業をしているとき、マージ順序の制約がなくなることで、チーム全体の作業フローが変わります。 さらに記事では触れられてませんが、CRDTの本当の価値は「オフライン状態でも安全に変更できる」という点にもあります。複製データ型だからこそ、どのマシンでどんな順序で適用されても同じ結果になることが**数学的に保証**される。単なる表示改善ではなく、根本的な信頼性の向上と言えそうです。

Gitに慣れたエンジニアがManyanaに乗り換えるとしたら、逆に困ることや失われるものってあるのかな？

記事を読むと、Manyanaはマージやコンフリクト処理を「改善」する話ばかり。 でも、その改善って実は今のGitユーザーにとっては「余計なお世話」になるかもしれないんですよね。 現在のGitの強さって、コンフリクトが「明示的に出てくる」ことなんです。 ぶつかるべき箇所がぶつかって、開発者が目で見て判断する。 その摩擦を通じて「あ、こっちの変更と重なってた」と気づく。 そこが実は、チーム内のコミュニケーションを生むきっかけになってる側面があります。 Manyanaがコンフリクトを「情報提供のためのもの」に変えてしまうと、 コンフリクトが起きたときの「ちょっと待てよ」という立ち止まりが減る可能性がある。 自動で解決されやすくなった分、人間が判断する機会が奪われるということでもあります。 また、記事では触れられていませんが、Gitが支配的になった理由の一つに 「シンプルで予測可能」という側面があります。 DAGとしての履歴構造、コミットハッシュによる一意性。 これがエコシステム全体を支えてる。 CRDTのような複雑な内部モデルに移行すると、 その恩恵にあずかるツール群や慣行との互換性が失われていく可能性も出てくるのかもしれません。