git-ai 2日で1000スター：AnthropicのScionをオープンソースで再現

10月13日、Anthropicはエンジニアブログを公開し、内部で使用しているバージョン管理システムScionについて初めて公開説明しました。Scionは、数百のコーディングエージェントが同時に読み書きし、コードを同期するために設計されたサーバー中心型システムであり、オープンソースではありません。2日後の10月15日、開発者feder-cr（Federico Elia）はGitHub上にgit-aiのリポジトリを作成しました。READMEの最初の文は「AnthropicがScionを構築した…そこで私はgit-aiを構築した：その設計を実行できるオープンソース版」となっています。10月17日時点で約1,000★（GitHub Search APIによる報告値1057）で、2日間で千星に達しました。MITライセンス、Go言語で開発されています。この記事はいつものように6つのセクションに分けて説明します。

一、それは誰ですか

gitaiの身分は、2つの層に分けて考える必要があります。

ベースはGitLab Gitalyのフォークです。GitalyはGitLabのGit RPCサーバーであり、この証拠チェーンはリポジトリ内で非常に明確です：NOTICEファイルの冒頭には「The following components are included in Gitaly:」と書かれており、cmd/ディレクトリにはgitaly、gitaly-backup、praefectなどのオリジナルのコマンドが含まれています。VERSIONファイルには19.5.0-rc3（Gitalyのバージョン番号）と記載されており、LICENSEには2行の著作権情報があります：「Copyright (c) 2026 Federico Elia and the gitai contributors (modifications and additions). / Copyright (c) 2016-present GitLab Inc.」。READMEには次のように書かれています：Gitalyは下位のGitプランニングを提供し、オーバーウォーターの各Gitaly RPCは引き続き使用可能です。オーバーウォーターのMIT以外のee/ディレクトリはこのリポジトリには含まれていません。

新しいものは「graft」と呼ばれます。地元の統計によると、全ての倉庫には2833個のgit-trackedファイルがあり、Goコードの総行数は約57.6万行です（その大部分はGitalyから受け継がれています）。その中で、internal/graftとcmd/graft*の新しいディレクトリには約7.5万行が含まれており、これが今回のオープンソース化の核心部分です。具体的には、graft CLI、graft-cacheのキャッシュプロセス、graft-verifyの検証ツール、graft-benchのベンチマークツール、そしてサーバー側のland、changeset、derived data、resolver、reviewという一連のサブシステムです。

もう一つ正直に説明しなければならない点があります：倉庫のgit履歴がスクワッシュされており、浅いクローンでは1つのコミットしか見ることができません。7.5万行の新しいコードは明らかに2日間で書かれたものではありませんが、開発にかかった時間は確認できず、「長期にわたって準備した後、一度に公開する」という理解で対処するしかありません。READMEのStatusのセクションには「Version 0.1.0, the first public release」と書かれています。また、倉庫にはAGENTS.mdとCLAUDE.mdというエージェントワークフローファイルが含まれており、プロジェクト自体は「エージェントのために、そしてエージェントが開発に参加する」というスタイルで構成されています。

二、なぜ現在なのか

gitaiが登場した直接的な理由は、Anthropicが発表した「Redesigning source control at Anthropic」という記事（10月13日に公開され、10月15日に一度更新された）です。この記事では、エージェント規模でのソースコード管理の問題点を初めて数値化しました。2026年5月には日平均約2,500回のコミットがあり、9月には1日あたり30,000回以上に増加し、4ヶ月で12倍に増加しました。monorepoのメインストリームの履歴は約100GBあり、圧縮後の作業コピーは25GB以上です。毎日約2,500万回のCIチェックアウトがあり、裸のgitトラフィックは1日あたり600PB+/日で、ピーク時には数百の内部gitミラーが動作します。従来のGitホスティングは「人が一度クローンして数時間作業し、一度プッシュする」という設計でしたが、全量クローン、コミットキュー、クライアントの履歴のトラバースがこの規模でボトルネックになっていました。Scionの解決策は、作業をサーバー上に移すことです。クライアントは常にオンラインであり、必要な時にのみデータを取得します。履歴に関する問題（blame、パス履歴）はサーバー上で計算し、キャッシュされます。並列処理でcompare-and-swapを行い、キューに乗らずに処理します。サーバー上には完全なリポジトリの物理的なコピーがなく、すべてが水平拡張可能です。Anthropicは5ヶ月でこの移行を完了しました。

しかし、Scionは内部用であり、一般の人には手に入らない。そこでオープンソースの復刻が流行った。gitaiは唯一の例ではない（10月13日には既にopenscionが作られていたが、拡散力は低く、HNには7件の「いいね」しかなかった）。しかし、gitaiは最も速く動作するものだった。

この人気のもう一つの原因は、ある論争にあります。10月14日、元Metaのソースコントロールチームメンバーであるsunshowersが投稿しました（HN 425▲）。彼はScionについて、「Mononokeから強く影響を受けている」と指摘しました。派生データやBonsai changesetなどの概念や用語が似ていること、そして「Scion」という名前も「Bonsai」の音節を逆転させてBを取り除いたものだと述べています。一方、Anthropicのブログでは当時、Google PiperとMeta Saplingのみに謝辞が寄せられていました。10月15日には彼は第二の投稿を追加し（HN 251▲）、Scionが「意図的にMononokeを模倣したもの」であり、人員が重複していることを私的に確認したと述べました。これはsunshowers自身の主張であり、独立した検証は行われていません。その後、AnthropicのNick G.がHNで返答し、ブログには所属についての説明が追加され、ページの上部には公式な文言の「Update:」が追加されました。「10月15日に更新され、Scionで使用されている多くの技術を先駆けたプロジェクトについての詳細が記載されています」。主ブログのHNストーリーは889▲で、その週のエンジニアコミュニティのトップトピックでした。

この論争は、分解対象としての意味を変えています。それは、「Scionの設計思想には実際にオープンソースの先例があった（Mononoke）」という事実を公共の話題にし、すべての複製プロジェクトに対する市場教育を行ったことになります。gitaiが的確に狙ったのもまさにこの点です。

三、メカニズムの分解

Graftは、Scionブログで説明されていた設計を一つ一つ実際に動作するものに変換しました。その中で最も重要な4点を説明します。

最初のポイントは、コミットが並行して行われることです。従来のホスティングプラットフォームでは、コミットの処理がシリアルなボトルネックとなっていましたが、graftのUserLandでは、変更を現在のブランチのtipにrebaseし、その後compare-and-swapを用いて参照を更新します。CASが失敗すると、誰かが先にコミットを行ったことを意味し、自動的に再試行されます。デフォルトでは最大20回までです。同じブランチ上での並行なコミットも、一括して単一の参照更新として処理されます。ドキュメントにあるベースラインデータはこの点を明確に示しています：20個のエージェントが同じブランチにコミットを行うと、各変更は平均して約10回試行される必要があり、p99の遅延は26秒です。

二つ目はchangesetのログです。受け入れられた参照更新ごとに、各リポジトリ専用のchangesets.jsonlに記録されます。このデータはflockを使ってシリアルに追加し、fsyncを行います。クラッシュなどで最後の行が切れてしまう場合は、次回の追加時にその部分がカットされます。番号は1から始まり、密接に増加します。agentはこのデータフローを購読して、リポジトリで何が起こっているかをリアルタイムで確認できます。READMEでは、このような監視agentをsuperfansと呼び、重要な情報をSlackに報告することもできます。

第三に、サーバー側で処理される派生データがあります。blame、パス履歴、祖先関係、コード検索などはすべてサーバー上で行われます。内容に基づいたキャッシュが行われ、キーはSHA-256(kind, commit, path)です。書き込みは一時ファイルを使用し、renameによる原子的な置換が行われます。各commitは一度だけ計算されます。そのため、クライアントは完全な履歴を必要としません。graft cloneやgraft sparseは、必要なパスのみを実体化します。

第四つは、衝突解決用のプラグイーブルーなレゾルバです。このプロトコルはバージョン管理されており、ベンダーニュートラルです。ローカルコマンド（stdinからJSONを受け取る）やHTTPエンドポイントを設定でき、パスホワイトリスト/ブラックリスト、アクターホワイトリスト、タイムアウト、ファイル数の上限などを設定できます。AIレゾルバはサーバー外で動作し、サーバー自体はいかなる大規模モデルにも呼び出しを行いません。これはREADMEで何度も強調されているベンダーニュートラルの基本原則です。AIによって解決されたコミットには「Graft-Resolved-By」という注釈が付けられ、後から監査が可能になります。

安全モデルには注目すべき点があります：各エージェントは独自のトークンを持ち、アイデンティティは内部ユーザーIDによって偽装されることはありません。また、e2eテストによってこの点が厳格に確認されています。エージェントが呼び出せるRPCのリストはコード上で定められたallowlistであり、スナップショットからレポジトリを作成するような危険なRPCはエージェントには永遠に禁止されています。

さらに2つの補完メカニズムがあります。1つ目は、実装後に検証を行うことです：graft-verifyはグリーンリファレンスを維持し、実装後にテストが失敗した場合は、原因となる変更を特定し、自動的にリロールし、「Graft-Auto-Revert」のタグを付けます。1時間あたりのリロール制限があり、連鎖的な誤動作を防ぎます。これにより、「先にマージしてからテストする」というスローガンが、リロール保証のあるプロセスへと変わりました。2つ目は、意味論的なレビューロールです：承認の要件は、変更の性質に応じて設定できます。例えば、純粋な注釈変更は論理変更よりも少ない承認が必要です。これは、エージェントが大量のリクエストを送信する場合に必須の機能です。人間のレビュアーの注意は本来希少なものです。キャッシュ層には「graft-cache」というプロセスがあり、リージョン層のキャッシュは不変オブジェクトです。各オブジェクトをアクセスする前にID（タイプ＋長さ＋内容）を再計算し、一致しない場合は拒否します。一連のミスは一度のアップストリーム呼び出しとしてまとめられます。

四、数字と検証

倉庫に付属しているbenchドキュメントによる実測では、100個のエージェントが同時に一つのブランチに実装されました（使用したマシンはIntel Core Ultra 7 255HとWSL2で、ドキュメントにはノイズについて記載があります）。バッチ実装をオフにすると、平均して1変更あたり56.94回の試行が行われ、500回の変更のうち115回のみが成功し、277回が失敗しました。毎分のスループットは126.6回でした。バッチ実装をオンにすると、試行回数が平均1変更あたり1.00回に減少し、392回が実装され、毎分のスループットは257.6回になりました。

さらに難しいのは、単に良い情報だけを提供していない点です。同じ文書には、phase 4aの検収基準が達成されていないと明記されています。50個および100個のエージェント規模で、大量のp99遅延が発生しており、これは大量生産時には起こらないことです。READMEのStatusセクションでは、これがVersion 0.1.0の最初の公開バージョンであり、1.0以前のインターフェースが変更される可能性があると述べられています。エンドツーエンドテストは単体で実施されており、複数ノードでの動作は未検証です。doc/graftのLIMITATIONSセクションには、4つの制限が記載されています。それは、ホスティング製品ではないこと、GitLabの代替品ではないこと、Scionの実装ではないこと、そして本来、セキュリティ上の境界を構成しないことです。

業界の常態と比較してみると、ほとんどのプロジェクトが2日間で数千の星を獲得するものですが、READMEにはビジョン図しかありません。このプロジェクトは、6つの段階的な設計文書、fuzzテストとクラッシュ復旧テストの声明、そして「受け入れられない」と書かれたベンチテストレポートを含むオープンソースとして公開されています。これは、同波複刻の中で最も信頼性が高いプロジェクトです。

五、判断

まず結論を述べると、gitaiは注目に値しますが、現在それが解決しているのは「Anthropicの規模の問題」です。また、Anthropic自身もブログで、ほとんどの組織が近い将来これらの問題に直面するとは期待していないと述べています。

3つの観察点があります。1つ目は、その作品が扱うウィンドウの半分は技術であり、もう半分は物語です。「モノノケ」の帰属に関する論争によって、「この設計には既にオープンソースの先例がある」ということが公共の話題になりました。これは、すべての複製プロジェクトに対する市場教育を提供したことに等しいです。gitaiはこの流れの中で最も速く成長しており、2日間で約1,000星の評価を得ています。これは、10月13日に登場したopenscion（HNには7件のいいねしかありません）よりもはるかに人気があります。この人気の大部分は、Anthropicに関する論争からの影響であり、製品自体の人気だけではありません。

第二に、Gitaly Forkのベース選択は賢明でありながらも重苦しいものです。賢明な点は、Git RPC、リポジトリ管理、バックアップといった面倒な作業を直接継承していること、MITライセンスと声明がクリーンに扱われていることです。しかし重苦しい点は、GitLabエコシステムの複雑さを背負っていること、構築にはMesonやNinjaが必要であり、Gitを組み込むためのコンパイルが必要であること、そして使い始めるハードルが高いため、短期間では一般の人々に受け入れられるツールにはなり得ないという点です。

第三に、本当に学ぶ価値のあるのは、コード自体ではなく、いくつかの設計判断です。例えば、実際の運用ではCASを使用し、バッチ処理を行うのではなくキューを使用する。ログの記録には追加式のJSONLとfsyncを使用する。AI機能はすべてサーバー外で取り外可能なresolverとして構築される。また、エージェントのアイデンティティと権限はプロトコル層で固定される。これら4点は、複数のエージェントが協力する基盤を構築したいチームにとって、すぐに利用できる解決策です。

リスクも明確にしておく：単人で主導されており、開発プロセスが見えない。0.1.0のインターフェースはいつ変更されるかわからない。自分自身の検証も合格していない。『設計上の参考価値は高いが、実際の使用可能性には疑問がある』という基準で評価する方が公平だ。

六、誰が、どのように使うことができるか

複数のエージェントが同時に同じリポジトリにアクセスしている場合、マージの衝突やキューの詰まりが発生してしまいます。これがその最初の対象ユーザーです。Quickstartスクリプトを使えば、一発でサーバー、キャッシュプロセス、2つのエージェントを起動し、一度の作業で主要なプロセスを完了できます。半日程度で主要なプロセスを把握できます。プラットフォームエンジニアチームは、doc/graftに含まれるARCHITECTURE、STORAGE、RESOLVE、LIMITATIONSの4つのドキュメントのみを読み取り、デザイン判断を自分の計画に反映させることができます。コードを導入する必要はありません。通常の単体リポジトリチームは、Gitを使用しても問題ありません。このリポジトリ自体もそう述べています。

手を出したい人は、以下の3点を覚えておいてください：ストレージコアはデフォルトでオフになっていますので、shadowモードからインポートしてから authoritativeモードに切り替えましょう。 resolverにはまず確定的なツールを設定し、AI resolverは最後に追加しましょう。これをセキュリティ境界として扱わないでください。LIMITATIONSを明確に記述してください。

情報源

• 倉庫本体：github.com/feder-cr/git-ai（README、NOTICE、LICENSE、go.mod、VERSION、10月17日のローカルクローン検証；doc/graftのARCHITECTURE/STORAGE/RESOLVE/LIMITATIONS/BENCH/LAND-BATCHING各ドキュメント）
• Anthropic公式ブログ「Redesigning source control at Anthropic」（10月13日公開、10月15日更新、Scionの全数字出典）
• sunshowers.ioの2つのMononokeに関する論争記事（10月14日、10月15日）およびHNの議論（889▲/425▲/251▲/7▲、10月17日朝のスナップショット）
• 星数と作成時間：GitHub検索APIと倉庫ページのcreatedAt（10月17日朝のスナップショット、星数は変動中）