AIエージェント時代の版管理を再設計　AnthropicのScionが示す大規模開発の境界

AIエージェントがコードを大量に変更する開発では、生成速度が上がっても納品全体が速くなるとは限らない。待ち時間は版管理システムのチェックアウト、CIの待ち行列、依存関係の準備、ビルド、テストに分かれるからだ。Anthropicはこの詰まりを大型モノレポの版管理から見直し、内製システム「Scion」を構築した。

Anthropicの公式記事によれば、1日のマージ数は2026年5月の平均約2500件から9月には3万件超へ増えた。同社は5カ月でモノレポをGitからScionへ移し、コードレビュー、検索、権限管理も周辺サービスとして作り直した。これはAIエージェントを使う全チームの標準解ではなく、同社の規模と運用を示す事例である。

まず分けるべきはチェックアウト、CI、ビルド、テスト

「CIが遅い」という一言だけでは、版管理を作り直す理由にならない。ジョブがキューで待っているのか、指定したコミットのファイルを集めているのか、依存パッケージを準備しているのか、ビルドやテストが長いのかで対策は変わる。

Anthropicは、コード変更の増加でソース管理、ビルド、CIが開発基盤のボトルネックになったと説明する。記事に記された同社のモノレポは履歴が約100GB、圧縮した作業コピーが25GB超で、CIによるコード取得は1日約2500万回に達する。こうした負荷なら、毎回完全なコピーを作る方式はネットワークと計算資源の両方を消費する。

一方、一般のチームが同じ規模に達したと決めつけるのは早い。ジョブごとにキュー待ち、チェックアウト、依存関係のインストール、ビルド、テスト、デプロイ前確認の中央値と高位分位を記録し、リポジトリー、ジョブ種別、キャッシュの状態で分ける必要がある。チェックアウトが全体の数％なら、そこだけを秒単位にしても納品時間は大きく変わらない。

Scionの設計──サーバーが履歴、クライアントが必要なファイルを扱う

Gitは各クローンが履歴を持ち、ネットワークから切り離しても閲覧やコミットを続けられる分散型の設計だ。Scionは常時接続を前提に、履歴、差分、マージ、rebaseなどをサーバー側で処理し、クライアントには限定したキャッシュと作業コピーを置く。

必要なディレクトリーだけを取得するスパースな作業コピーや、ファイルが読まれた時点で内容を取得する仮想的なチェックアウトを使えば、短命なCI環境やエージェントの作業環境で大型リポジトリー全体を展開せずに済む。変更セットは直前の版から変わったファイルを記録し、内容アドレス付きの不変オブジェクトを参照する。オブジェクトが変わらなければ、同じ内容をキャッシュから再利用できる。

データの流れは、作業ノードのscion-daemon、地域キャッシュのscion-cache、権威サーバーのscion-serverという層に分かれる。下流のキャッシュにないオブジェクトだけが上流へ進むため、同じ大型ファイルを何度も送る負荷を抑えられる。その代わり、サーバー、ネットワーク、キャッシュの障害が開発作業へ直結し、オフライン開発の利点は小さくなる。

検出が秒になっても、CI全体が秒になるわけではない

Anthropicが公開した数値は、チェックアウトと版管理基盤の改善を示す社内測定である。Scionのキャッシュ命中率は99％超、版管理基盤のCPUとメモリー需要は従来のGitミラー構成の約200分の1になったとされる。CIと研究作業のコード取得は分単位から秒単位へ短縮し、CIは25％のCPU容量を取り戻したという。

CPU容量の回復は、個々のジョブが25％短くなったという意味ではない。チェックアウトで空いた実行器が別のジョブを処理できれば、キュー待ちが減る可能性はある。しかし、コンパイル、テスト、外部サービス、依存パッケージが遅ければ、1件の完了時間は変わらない。平均だけでなく、キャッシュが空の初回、人気ファイルへの集中、ネットワーク断、サーバー障害を同じ条件で測る必要がある。

Anthropic自身もScionを一般用途のGit代替品とは位置づけていない。大規模なモノレポと高頻度の自動作業を持つ組織では検討材料になるが、通常のリポジトリーなら、既存Gitの設定、ミラー、キャッシュ、スパースチェックアウト、部分クローンを先に測る方が回復しやすい。

日本ではどうなる

日本でScionを導入する場合、最初に価格表を探すより、入手経路を確認する必要がある。Anthropicの公式記事はScionを自社の「内製版管理システム」と説明し、構築とモノレポ移行の経緯を公開しているが、日本向けの販売価格、契約プラン、ダウンロード窓口、公開ソースコードは案内していない。本稿の執筆時点で、国内企業が購入して使える製品としてのScionは確認できない。したがって、見積もりを推測してGitHubの料金やクラウド費用に置き換えることもできない。

代替案の価格は、Gitそのものではなく、ホスティング、ストレージ、実行器、キャッシュ、監視、保守の契約で決まる。Git公式の部分クローンは、フィルターで受け取るオブジェクトを絞り、必要になった欠落オブジェクトを後から取得する機能だ。大規模なCIでチェックアウト量を減らす候補にはなるが、サービス料金を示す仕組みではない。日本で比較するなら、同じリポジトリーとジョブを使い、転送量、保存量、実行時間、キャッシュの保持、障害時の復旧を各社の現行料金表で確認することになる。

法規制では、コードに顧客情報や従業員情報が含まれる場合、個人情報保護委員会の個人情報保護法ガイドラインが示す、委託先の選定、契約、取扱状況の把握、再委託の監督を確認する必要がある。海外のサービスへ個人データを預けるなら、保存場所、再委託先、アクセス権、削除と監査の条件を契約で確かめる。個人データを含まない社内コードでも、設計情報や秘密鍵を同じリポジトリーへ置く理由にはならない。

未公開の技術情報を営業秘密として守るには、経済産業省の資料が説明する不正競争防止法上の「有用性」「秘密管理性」「非公知性」を満たす管理が前提になる。Scionのような集中型サービスを採るか、既存Gitを使うかにかかわらず、機密区分、最小権限、監査ログ、退職時の権限削除、バックアップの保管先を決めるのが先だ。日本の開発会社や行政機関がScionを本番運用した公開事例は、本稿の執筆時点で確認できていない。

移行費用は版管理の外側で膨らむ

Scionの設計だけを再現しても、開発者が使う仕組みは完成しない。Anthropicは移行と同じ期間にコードレビュー画面、コード検索、権限管理、変更を着地させる仕組みを作った。一般の組織でも、ブランチとタグ、レビュー、検索インデックス、CI設定、デプロイルール、IDE連携、監査、緊急時の復旧を洗い出す必要がある。

集中サービスでは、ネットワークが切れたときの作業、サーバーが停止したときの読み取り、未同期の変更の保全、バックアップからの復旧を事前に試す。権限はリポジトリー単位だけでなく、ディレクトリーや機械アカウントまで確認し、エージェントには取得、変更、レビュー、公開の権限を分けて与える。これらを含めた人件費と停止リスクが、ライセンスの有無より大きな移行費用になる。

Gitの調整と自建サービスを同じ負荷で比べる

判断の起点は、Scionを採用するかではなく、どの段階が継続的な瓶頸かである。代表的なリポジトリー、変更量、同時実行数、実行器の仕様、キャッシュ状態を固定し、Gitの部分クローンやスパースチェックアウト、内部ミラー、先行キャッシュを順に試す。そこでチェックアウトが主要な待ち時間として残り、局所的な改善が増加するジョブ数に追いつかない場合にだけ、サービスの再設計を比較対象へ入れる。

選択肢	先に測る条件	主な負担
Gitの部分クローン・スパース化	取得範囲や転送量が主な問題	欠落オブジェクト、ローカル複製、互換性の確認
ミラーとキャッシュ	同じ版の検出が何度も発生	更新、容量、障害復旧、整合性の監視
自建の版管理サービス	大型モノレポの取得が長期にわたり主要な瓶頸	開発ツール全体の移行と継続保守

比較では、チェックアウト時間、キュー待ち、ビルド、テスト、障害復旧を分けて記録する。Anthropicの25％というCPU容量の数字を目標値にせず、自社のジョブが空いた計算資源を実際に再利用できたかで判断する。小規模な非重要ワークフローで試し、旧経路へ戻す手段と、性能・可用性・維持費の終了条件を先に決めるのが現実的だ。

よくある質問

Scionは日本企業がすぐ契約できる製品か
Anthropicの公開記事は内製システムとして説明している。日本向けの価格、販売窓口、公開配布版は本稿の執筆時点で確認できない。

チェックアウトが速くなればCIも速くなるか
必ずしもそうならない。キュー待ち、ビルド、テスト、外部サービスを別々に測り、チェックアウト改善が全体へ与えた影響を確認する必要がある。

一般のチームは何から試すべきか
Gitの部分クローン、スパースチェックアウト、ミラー、キャッシュを自社の代表的なジョブで比べる。自建サービスは、これらで主要な瓶頸が残る場合に移行費用とともに検討する。