Anthropicが2026年10月13日、社内のモノレポをGitから自社開発のバージョン管理システム「Scion(サイオン)」へ全面移行したことを、公式エンジニアリングブログ「Redesigning source control at Anthropic」で公表しました。国内ではまとめ記事や報道経由で紹介されることが多いため、本記事ではAnthropic公式記事の本文と図を直接読み、何が書かれていて何が書かれていないかを整理します。そのうえで、受託開発とAIエージェント事業を手がける立場から、開発会社やSIerの経営判断にどう関わるかを私の見解として述べます。
この記事でわかること
- Scionとは何か、なぜAnthropicはGitをやめたのか(公式記事の記述ベース)
- 「25倍」「207倍」などの高速化の数字は何を測った値か
- 7人・5か月で移行できた体制と、エンジニアの役割の変化
- Gitを使い続ける一般企業が、今から準備しておくべきこと
要点:Anthropic公式記事に書かれている事実
- 2026年5月は1日平均約2,500件だったマージ数が、9月には1日3万件を超えた。Anthropicは「マージしたいコードの潜在需要は事実上無限」と書いている
- mainブランチの履歴だけで約100GB、圧縮した作業コピーで25GB超。CI用のチェックアウトは1日約2,500万回で、素朴にフェッチすれば1日600PBを超えるGitトラフィックになる計算
- これに対し、自社開発のScionへ5か月で全面移行した。同じ期間に、コードレビュー基盤「Antique」、コード検索、ソース管理用のIAM(権限管理)なども作っている
- 開発したのは7人のチーム。コードはClaudeに書かせ、エンジニアは設計判断とClaudeに「やめろ」と言う役割を担った
- Anthropic自身は「ScionはGitの一般的な代替にはまったくならない」と明言し、外部提供もしない。ただし同種の問題は今後6〜12か月で多くの企業に広がると見ている
Scionとは:常時オンラインのエージェントを前提に作り直したバージョン管理
Gitは分散型のシステムです。どのクローンも完全なリポジトリで、オフラインでも差分・履歴・blameを計算できます。公式記事も、ほとんどのリポジトリにとってこれは正しい設計であり、Gitが標準になった大きな理由だと認めています。
問題は、Anthropicのクライアントのほとんどが常にオンラインのエージェントとジョブになったことです。記事は「多くの企業と同じく、私たちもGitを、正本が1つしかない中央集権的なシステムとして使っていた」と書いています。オフラインで分散して作業するためのGitの性質が、リポジトリの肥大化とともに、むしろスケールの邪魔になっていたということです。ピーク時には数百台の社内Gitミラーと、blob storageに置いたリポジトリのスナップショット(seed)で凌いでいましたが、マージの頻度が上がるにつれて運用が追いつかなくなりました。
そこでAnthropicは「エージェントが常にオンラインである前提で、最初からソース管理を設計したらどうなるか」と問い直し、次の6原則を置いています。
| 原則 | Gitとの違い |
|---|---|
| クライアントは常時オンライン | Gitはオフラインで完全なコピーを持つ前提。Scionは必要なときに必要なデータだけ取りに行く |
| クライアントとサーバの非対称 | 履歴・blame・コミット・マージ・リベースはサーバ側が担う。クライアントは上限付きのキャッシュと作業ファイルの展開だけ |
| ソース管理をAPIで提供する | 「誰がこの行を変えたか」などをAPIで問い合わせられるため、多くのジョブはローカルにリポジトリを持たなくてよい |
| すべてを水平スケールさせる | リポジトリ全体の完全なコピーはサーバにも存在しない。packfileが無いのでリポジトリのメンテナンスも要らない |
| コミットは安く・差分単位で・ロック無し | コミットにかかるコストは、リポジトリ全体ではなく変更の大きさに比例させる。mainとリリース以外のブランチ(ref)は使わない方針 |
| 作業コピーは任意で、部分取得が基本 | 必要なディレクトリだけのsparse checkoutと、読んだファイルだけ取り出す仮想化チェックアウトが前提 |
中身:changesetと3層キャッシュ
Scionの作業単位は「changeset」で、write-ahead log(先行書き込みログ)の1エントリです。Gitのコミットがツリー全体へのポインタを持つのに対し、changesetは最初の親から変わったファイルの一覧と、blob storage上の圧縮済みファイルへの内容アドレス(ハッシュ)だけを持ちます。メタデータは分散データベースのSpannerに置かれ、ブランチの付け替えはSpannerの1行に対するcompare-and-swapで済みます。blameやファイル履歴のような重い問い合わせには、changesetから派生データを再帰的に計算して索引を作ります。
配信は、ノードごとのscion-daemon、地域ごとのscion-cache、正本を持つscion-serverの3層構成です。3層とも同じRPCに応答するので、クライアントはキャッシュの構成を意識しません。各層のキャッシュヒット率は99%超で、旧Gitミラー基盤と比べてCPUとメモリの使用量は200分の1になり、CIでは25%のCPUが空いたと書かれています。
設計の下敷きとして、GoogleのPiperと、MetaのSapling(特にサーバ側のMononokeとそのBonsaiデータモデル)を挙げています。10月15日の更新で、この先行事例への言及が追記されました。まったくの新発明というより、超巨大モノレポで先行企業が積み上げてきた知見を、エージェント前提で組み直したものと読むのが正確です。
高速化の数字は何を測ったものか
国内記事でよく引用される「Pull latestが25倍」「Statusが207倍」「New worktreeが84倍」は、本文ではなく、公式記事の図「Everyday source control commands on the monorepo」に載っている値です。図はAnthropicのモノレポ上での中央値で、主な値は次のとおりです。
| 環境 | 操作 | Git | Scion | 倍率 |
|---|---|---|---|---|
| 開発者環境 | Pull latest | 87秒 | 3.5秒 | ×25 |
| 開発者環境 | Status | 3.9秒 | 19ミリ秒 | ×207 |
| 開発者環境 | Commit | 1.4秒 | 1.1秒 | ×1.3 |
| エージェント環境 | New worktree | 7.1分 | 5.1秒 | ×84 |
| エージェント環境 | Commit | 18秒 | 761ミリ秒 | ×24 |
| エージェント環境 | 変更1件あたりのソース管理時間の合計 | 34分 | 3.7分 | ×9.2(1日約1.1万エージェント時間) |
| CI | CIジョブでのチェックアウト | 31秒 | 3.5秒 | ×8.8(1日約19.5万マシン時間) |
研究出身の私が気にするのは、倍率そのものより測定条件です。これは100GB級の履歴を持つAnthropic自身のモノレポでの中央値で、ふつうの規模のリポジトリにそのまま当てはめられる数字ではありません。また、開発者環境のCommitはわずか1.3倍です。速くなったのは「書く」操作ではなく、状態を確かめる・最新を取る・作業場所を作るといった待ち時間のほうでした。
私が一番重要だと考えるのは、変更1件あたりのソース管理時間が34分から3.7分になったという行です。個々のコマンドの速さではなく、エージェントが変更1件を出すたびに払っていた待ち時間の合計を測っています。AIに大量の変更を出させるようになると、ボトルネックはコードを書く速さから、その周辺の待ち時間に移ります。この図はそれを数字で示しています。
7人・5か月で移行できた理由と、変わったエンジニアの役割
公式記事によれば、7人のチームがScionとAntique、さらに関連システム6つほどを作り、5か月で移行を終えました。その間もマージ数は10倍に増えています。「以前なら、何年もかけて多くのエンジニアで段階的に移行していたはずだ」とも書かれています。
印象的なのは、年初に手書きした「GitからScionへの取り込みパイプライン」の試作を、社内向けのClaude Mythos Previewに書き直させた話です。追加の指示なしで、メモリ使用量は20分の1、速度は4倍になり、取り込み順序やデータ構造に関する暗黙の約束事もすべて保たれていたそうです。
一方で、エンジニアの役割については次のように書かれています。
- 関わったエンジニア全員が、コードを書く能力ではClaudeのほうが上だと評価している
- それでも、システム間の関係や設計上のトレードオフの判断はエンジニアが担った。役割の多くは、Claudeに「やめろ(no)」と言うことだった
- エージェントは、本来許してはいけないパターンに合わせるために、システムの根本的な制約を破ることがある(例:コードレビュー基盤に問い合わせればよいところを、コミットログを先頭から総当たりで読む実装)
- 敵対的レビュー(AI同士のレビュー)は有効だが視野が狭くなることがあり、仮定の懸念に応えて過剰な検証を足す方向へ走るのを、人が止める必要があった
- 変更はいまも全件を人がレビューしているが、見ているのは1行ずつのコードではなく変更の意図
運用面では、Slackに常駐させたClaude(Claude Tag)に、scion-daemonやマージキューなど1つの部品の健全性だけを見張らせています。Anthropicはこれを「superfan(熱狂的なファン)」と呼び、従来のアラートでは拾えない、細かく新しい異常を見つけると書いています。マージキューについても、テスト実行中に何百件もマージされる規模では、リポジトリ全体をロックする業界標準のやり方は成り立たないとしています。代わりにマージ後・デプロイ前の自動テストに投資し、変更同士の衝突はClaudeが直す運用にしたそうです。
徐 聖博の見解:Gitの話ではなく「待ち時間の再設計」の話として読む
「Gitは終わった」とは読まない
まず、この記事を「Gitの時代が終わった」と読むのは誤りです。Anthropic自身が、Scionは数万人規模のエンジニアか、大量のエージェントがコードを書き続ける超巨大モノレポでしか意味を持たないと書いています。社内でここまでトークンを使える会社は他に無い、とも認めています。私はふだんから「技術が事業のボトルネックになった瞬間が、技術投資のタイミングである」と考えていますが、AnthropicがScionを作ったのはまさにそれが起きたからです。ソース管理がボトルネックになっていない会社が、同じ投資をする理由はありません。
日本の開発会社・SIerに先に来るのは、VCSより前の詰まり
一方で、「当社には関係ない」と片付けるのも危ういと私は見ています。数十人規模の開発会社でVCSの性能が限界に達することは、当面ないでしょう。ただ、AIエージェントにPRを出させ始めると、Scionの図で問題になっていたのと同じ種類の待ち時間が、もっと手前で表に出てきます。
当社はGit Flow(developブランチを介す運用)を採用していて、レビューは人とClaudeの併用です。Anthropicがmainとリリース以外のブランチを使わない方針を取り、全件ロックのマージキューを捨てたことを読むと、人間のレビューの速さを前提に組んだブランチ戦略とレビュー手順が、最初の詰まりになると考えています。エージェントがPRを1日に何十本も出すようになると、先に足りなくなるのはVCSの性能ではなく、人がレビューに使える時間です。
公式記事のなかで、私が受託開発の事業判断として一番重いと思うのは「1行ずつではなく変更の意図をレビューする」と「コメントだけの変更と、重要なロジックの変更とで承認条件を分ける」の2点です。受託開発の見積もりの中身は、これまでかなりの部分がレビューと確認の工数でした。レビューの対象が「行」から「意図」に移れば、人月で何を売るのかを考え直す必要が出てきます。これは生成AIで勘定系の開発期間を30%短縮したソニー銀行の事例や、全変更を人が承認する体制でAccess/VBA移行の純コストを37%削減したOdyssey Logisticsの事例を読んだときと同じ論点です。
今から準備しておくこと
Anthropicは、同種の問題が今後6〜12か月で広がると見ています。Scionのように自社でVCSを作る必要はまったくありませんが、次の3つは今のうちに測っておく価値があると考えます。
- 変更1件あたりの待ち時間を測る。 チェックアウト、CI、レビュー待ち、マージ待ちに分けて記録する。Anthropicが図の最後に「変更1件あたりの合計時間」を置いたのは、ここに効果が出るからです
- 人が見るべき変更と、見なくてよい変更を分ける。 権限、課金、データの整合性、本番設定のような壊してはいけない部分は人が承認する。それ以外は自動テストで止める。分け方は承認ルールとして明文化する
- ブランチ戦略を見直す。 長く生きるブランチが多いほど、エージェントが出す変更どうしが衝突しやすくなります。マージ後・デプロイ前のテストと、すぐ戻せる仕組み(ロールバック)をセットで整えたうえで、trunk-based開発への移行を検討する
AIがコードを書く時代ほど、テストとセキュリティ、認証・認可、本番環境の保守が重要になる、というのが私の考えです。Scionの記事は、エンジニアの仕事が「書くこと」から「何をやらせないかを決めること」に移った様子を、実際の運用として描いています。開発組織の役割分担を見直す材料として、原文を一度読むことをおすすめします。
よくある誤解
Q. ScionはGitの代わりとして一般に使えますか? A. 使えません。Anthropicは公式記事で「ScionはGitの一般的な代替にはまったくならない」と明言しており、外部に提供する予定もないとしています。レビュー・コード検索・CIまで含めて開発の仕組み全体を移す必要があるためです。似た名前のプロジェクトが出てきても、Anthropicの公式なものではない点に注意してください。
Q. AnthropicはGitHubやGitLabと対立しているのですか? A. 公式記事を読む限り、そうではありません。Gitコミュニティの約20年の取り組みに敬意を示したうえで、GitHub・GitLab・OSSコミュニティと協力し、Gitのサーバ側の構成や通信プロトコルを改善する方向を提案しています。
Q. 「207倍速い」はどんなリポジトリにも当てはまりますか?
A. 当てはまりません。これはAnthropicの巨大モノレポで、開発者環境のstatusコマンドを測った中央値(3.9秒→19ミリ秒)です。Commitは1.3倍にとどまっており、効果は操作の種類とリポジトリの規模によって大きく変わります。
Q. 中小規模の開発会社でも、今すぐ何かすべきですか? A. VCSを替える必要はありません。ただ、AIエージェントにPRを出させるなら、変更1件あたりの待ち時間とレビュー体制を測り直しておくべきだと私は考えます。モノレポの運用そのものについては、Block社が450のJVMリポジトリをモノレポに統合した事例も参考になります。
まとめ
- Scionは、エージェントが常時オンラインでいることを前提に、Gitの分散型の設計を中央集権・API中心・差分単位に組み直した、Anthropic社内専用のバージョン管理システム
- 高速化の数字は、Anthropic自身のモノレポで測った中央値。最も大きな効果は、変更1件あたりの待ち時間(34分→3.7分)に表れている
- 7人・5か月での移行は、Claudeがコードを書き、エンジニアが制約と意図を管理する分担で実現した
- 一般企業にとっての教訓は「Gitを捨てる」ことではなく、AIが変更を量産したときに詰まる、レビュー・ブランチ・テストの待ち時間を先に設計し直すこと
関連して読むなら、AIを開発の上流やレビューに組み込む動きはPRDレビューから始まるAIガバナンス層の記事、マージ後・デプロイ前にテストする前提はステージング環境が必要な理由にまとめています。
参考文献・出典
出典: Redesigning source control at Anthropic(Anthropic Engineering, 2026年10月13日公開・15日更新)
- Piper (source control system) - Wikipedia (公式記事内で先行事例として参照)
- Sapling SCM / Mononoke README(GitHub) (同上)
- Introducing Claude Tag(Anthropic) (superfan運用に使われた製品)
