Anthropic（アンスロピック）、自社製のバージョン管理システム「Scion（サイオン）」へ5か月でgitから移行1日のマージが約2,500件から3万件超に

Anthropic（アンスロピック）は、2026年10月9日付のエンジニアリングブログ「Redesigning source control at Anthropic」で、自社のモノレポ（複数のプロジェクトをまとめて1つに入れたコードの置き場）を、自社開発のバージョン管理システム「Scion（サイオン）」へ5か月でgitから完全移行したと公表した。同社によると、Claude（クロード）によるコード生成でマージ（変更の取り込み）が1日あたり2026年5月の約2,500件から9月には3万件超まで増え、バージョン管理が開発の最大の詰まりになったという。

3行まとめ

1. Anthropicは、1日のマージ数が2026年5月の約2,500件から9月に3万件超になったため、自社製の「Scion」へ5か月でgitから完全移行したと発表した（同社ブログ、10月9日付）。
2. 同社の説明では、Scion基盤はCPU・メモリ要件で従来のgitミラー基盤の200分の1、CIや研究ジョブのチェックアウトは2桁速い（分から秒）。CIだけでCPU容量が25%空いた。
3. 同社によると、開発は7人のチームがClaudeを使って進めた。一方で同社は「一般用途のgitの置き換えには向かない」と明記し、他社が使える形で提供するのは難しいとしている。

本記事の内容は、日本時間10月14日0時台に公式ページで確認したものです。

何が起きたのか

Anthropicは同ブログの冒頭で、同社ではコードを書くことがもはやシステム開発や研究の詰まりではなくなったと書いている。Claudeが研究のループを自律的に回し、複雑なプログラムを細かく最適化し、新しいサービスを一から作る速度が、これまでにない水準になったという説明だ。詰まりとして残ったのは、人間の規模を前提に作られた開発基盤（バージョン管理、ビルド、CI）だと同社は書く。

同社が挙げた数字は次のとおり。

同社は、gitにはシャロークローン、スパースチェックアウト、promisor remoteといった「リポジトリの一部だけを扱う」機能や、内部ミラー、スナップショット（seed）という定番の回避策があり、どれも使ったと説明している。これで時間は稼げたが、マージ数が増えるにつれて運用が難しくなり、スナップショットは更新の合間にmainの先端から遅れ、履歴に依存する差分表示やblame（行ごとの最終変更者の表示）を部分クローンで動かし続けるにも手間がかかった、という。

Scionはどういう設計か

同社は、gitを「正本が1つの集中型」として使っているのに、クライアントのほぼすべてがエージェントやジョブで、常にオンラインだという点に注目した。そこで「エージェントが常にオンラインであることを前提に最初から設計したらどうなるか」を問うた、と書いている。ブログが挙げる原則は次の6つ。

1. クライアントは常にオンライン: 必要なデータをその都度取りに行く。
2. クライアントとサーバーは非対称: 履歴・blameの照会、コミットの作成、マージ、リベースはサーバーが行う。クライアントは上限つきのローカルキャッシュを持ち、作業コピーのファイルをディスク上に置き、ファイルシステムの変更を監視する。
3. 照会はすべてAPIで使える: CIのジョブが多くの場合ローカルにリポジトリを持たなくても、差分や変更履歴を聞ける。同社は、自動のbisect（不具合を入れた変更の特定）や取り消しのパイプラインが、この安価なAPIアクセスなしには規模として成り立たないと書く。
4. すべて水平にスケールする: リポジトリ全体を丸ごと持つ場所は、サーバー上にも存在しない。gitのpackfileにあたるものがなく、保守作業が要らない。
5. コミットは安く、増分で、ロックなし: コミット・リベース・マージはすべてサーバー側で起き、pushするものがない。コミットの作成コストは変更の大きさに比例し、リポジトリ全体の大きさには比例しない。mainやリリースブランチ以外のref（ブランチやタグ）は使わない方向に誘導している。
6. 作業コピーは任意で、スパースが前提: できるだけチェックアウトを避け、必要なディレクトリだけのスパースなチェックアウトや、ファイルを必要な時に取り出す仮想化チェックアウトを中心にする。ディスク上にファイルが要る時も、実際に読んだ分だけのコストで済むという。

データ構造とキャッシュ

Scionの作業単位は「changeset」で、先行ログ（write-ahead log）の1項目にあたる。gitのコミットがツリーへのポインタを持つのに対し、changesetは第1親との差でファイルの変更一覧と、blobストレージ上の圧縮済み内容へのポインタ（内容アドレス方式）を持つ。生成はサーバー側で、すぐ全体から使える。blameやパス履歴、コミットグラフのスキップリストなどは、changesetから作る「derived data（派生データ）」として共通の仕組みで計算する。クライアントには内部構造が見えないので、クライアントを変えずに最適化できると同社は説明している。

取得の側は、クライアントが「持っているもの」をサーバーに伝えず、欲しいツリーとblobだけを根から再帰的に要求する方式だ。どの要求も不変のオブジェクトを指すので、どのキャッシュでも答えられる。ノードごとのデーモン（scion-daemon）が、地域ごとのキャッシュサーバー（scion-cache）に問い合わせ、足りなければ正本のscion-serverが、Spannerやクラウドストレージから読む。各層のキャッシュヒット率は99%超で、同社は長期の状態を持たないので増やしやすいと書く。

結果として何が変わったと説明しているか

• Scionの基盤は、従来のgitミラー基盤と比べてCPUとメモリの要件で200分の1。
• CIと研究ジョブのコードのチェックアウトは2桁（二桁）速くなり、分から秒になった。
• CIだけでCPU容量が25%空いた。
• クライアントもキャッシュもリポジトリの保守が要らなくなり、ジョブの運用が単純になった。

いずれも同社自身の数字で、今回の出典の中に第三者による検証や、測定条件の詳細は見当たらなかった。

誰がどう作ったのか

ブログによると、ScionとコードレビューツールのAntique（アンティーク）を作ったのは7人のチームで、関連システム半ダースと合わせ、5か月で完全移行した。その間もマージ量は10倍に増えた。同社は、従来なら何年もの段階的な移行と、もっと多くのエンジニアが要った仕事だと書いている。

Claudeの使い方については、次のような記述がある。

• gitからScionへの取り込みパイプラインの最初の版は、ほぼ手書きのプロトタイプだった。同社が内部で早期のClaude Mythos Preview（ミュトス プレビュー）のスナップショットに全面的な書き直しを頼むと、追加の指示なしで、メモリ消費が20分の1、速度が4倍の版ができた。取り込みの順序やデータ構造にまつわる暗黙の不変条件も保たれていたという。
• 開発に関わったエンジニアは全員、コードを書く力ではClaudeの方が上だと評価する。それでも、システム間の関係や設計上のトレードオフの判断は人が担い、「Claudeに『ダメ』と言う」ことが多かった。例として、マージの時期を調べるのにコードレビューツールへ聞かず、コミットログを端から線形に読むシステムが複数あったことを挙げている。
• 同社はチームのメンバーが変更要求をすべて確認するが、見るのは一行ずつではなく変更の意図だと書く。
• 各コンポーネントの健全性を監視するSlackチャンネルに、「superfan（スーパーファン）」と呼ぶClaudeを置いている。scion-daemon用、scion-cache用、Antiqueのマージキュー用などで、従来のアラートに加えて使い、細かく新しい異常も拾えると説明している。

また、一般的な意味のマージキュー（全体のロックをかけて順に取り込む仕組み）は、同社の規模では再現できなかったという。代わりにマージ後・デプロイ前の自動テストに投資し、同時に入った変更が衝突することはあるが、Claudeはたいてい人間が気づくより速く直せる、と書いている。

これは一般の開発者に関係があるのか

関係はいまのところ限定的、というのが同社自身の整理だ。ブログは「Scionは一般用途のgitの置き換えとしては向かない」と明記し、その概念が意味を持つのは数万人のエンジニアか、コードを大量に書くエージェントの群れがいる巨大なモノレポだけだとしている。社内版のコードレビュー・コード検索・CIは特注で、他社には導入しにくく、万人向けの公開版を作っても役に立たないだろうと書く。

代わりに同社が示したのは、Scionの考え方をgitに応用する案だ。gitのサーバーはクライアントと同じ作りである必要がなく、Scionのような包括的なサーバー側RPCをGit基盤が提供し、場合によってはフォージ（GitHubやGitLabのような基盤）をまたぐ標準にできるのではないか、という。交渉プロトコルの形や、スパース・シャロー機能の組み合わせも見直せる、とも書いている。同社は今後6〜12か月でこの種の問題が一般的になると見ており、GitHub、GitLab、OSSコミュニティと協力したいと述べている。

公式ページを見て気づいたこと

日本時間10月14日0時台にこのページを取得した時点で、ページは HTTP 200 で、公開日は10月9日と表示されていた。私たちのサイトマップ監視がこのページを検知したのは日本時間10月14日0時36分で、表示上の公開日から数日たっている。取得した本文テキストには、図のキャプション（1日あたりのマージ数の推移、Scionのchangesetの形、チェックアウトの構成図、ネイティブScionリポジトリでの性能改善など）は入っていたが、図の中身の数値は文字として取れていない。そのため、本記事の数字はすべて本文の文章に書かれたものだけを使った。グラフの目盛りや「性能改善」の図の値は確かめていない。なお、私たちはScionを使ったことも見たこともない。

発表だけでは分からないこと

• 数字はすべてAnthropic自身の説明で、200分の1の比較相手は「従来のgitミラー基盤」とだけ書かれ、測定方法や期間などの条件は今回確認した範囲では詳しく書かれていない。
• 今回取得した公式ページにはScionのコードやダウンロード先のリンクがなく、一般提供や公開の予定も書かれていない。
• 日本でどう使えるか、という話ではなく社内基盤の紹介のため、日本の利用者向けの案内は該当しない。
• ブログが「Claude Mythos Preview」と「Claude Tag」を社内で使ったと書く点は、同社内の話として紹介されているだけで、利用条件や提供範囲はこのページからは分からない。

出典と確認時刻

• Anthropic, "Redesigning source control at Anthropic"（2026年10月9日付）: https://www.anthropic.com/engineering/redesigning-source-control

公式ページの確認は日本時間2026年10月14日0時台。本記事は続報があり次第更新します。