1日3万件超のマージを支える独自基盤と、Anthropicが公開した「Scion」
2026年10月13日、Anthropic Engineeringは独自ソース管理システム「Scion」の設計と移行の経緯を公開しました（Anthropicによるソース管理再設計の解説記事）。10月15日には先行技術に関する追記もなされています。
同社の自己報告によると、AIモデルによるコード生成が急速に拡大した結果、2026年5月時点で1日あたり約2,500件だったマージ数は、同年9月には1日3万件を超え、CIによるコードのチェックアウトは1日約2,500万回に達していました。従来のGit環境では数百台のミラーサーバーを運用して対応していましたが、リポジトリ全体の履歴や作業コピーの肥大化に伴い、保守負担が限界に近づいていたといいます。
この負荷に対応するため、7人のチームがScion本体に加えてコードレビューツール「Antique」や複数の関連システムを開発し、5か月間でモノレポの全面移行を完了させたと報告されています。ただし同社は、Scionが一般用途におけるGitの代替ではなく、数万人規模のエンジニアや大量のAIエージェントが頻繁にコードを生成する極めて巨大なモノレポという特殊な規模を前提にした設計であると明記しました。
「履歴照会」を先に切り離す、データ取得を分けた移行のステップ
分散型を基本とするGitは、オフラインでも完全な履歴閲覧や差分計算を行えるよう、ローカル環境にリポジトリの完全な複製を保持する設計です。これに対し、利用クライアントのほぼすべてが常時オンラインのジョブやエージェントであるAnthropicの環境では、常時到達可能なサーバーから必要なときに必要な分だけデータを取得する非対称なクライアント・サーバー設計を採用しました。
移行の順序にも特徴があります。同社は独自クライアントや新しいリポジトリ形式、専用プロトコルが完成する前の移行初期段階において、まずコミット履歴や差分といったメタデータ照会をScionで処理できるようにしました。
作業コピーをディスク上に展開したり大容量のファイルを転送したりする処理はデータ転送の負荷が格段に大きいため、別の設計課題として扱われました。Scionでは、CIジョブがコミットとマージベースの差分だけをサーバーAPI経由で照会できるようにしたほか、ファイルが必要な場合も要求されたディレクトリだけを取得するスパースチェックアウトや、必要時に実体を展開する仮想化チェックアウトを中心に構成しています。なお、Scion移行後の社内基盤全体についての自己報告として、CI単体でCPU容量面において25%の改善が見られたと報告されています。
読み出しの軽量化と書き込みの競合、GitHubの参照単位直列化の視点
データ取得や差分照会をAPI化して読み出し処理を軽くしても、並行して走るジョブが同じリポジトリへ書き込む際の待ち時間は別の課題として残ります。
2026年10月21日にGitHubが公開したブログ（エージェント規模のGitインフラに向けたGitHubの解説記事）では、リポジトリ全体をロックして書き込みを直列化していた従来のクォーラム処理を、ブランチなどの参照単位（per-reference）で直列化する設計への見直しが解説されています。
この設計変更により、同じ参照への更新で競合が発生した場合は待機が必要になるものの、異なるブランチへ書き込むジョブ同士は互いを妨げずに並行して処理を進められるようになります。開発自動化における待ち時間を分析する上では、取得や照会といった読み出し側の通信量・CPU負荷と、ブランチ更新やマージといった書き込み側の直列化・競合のどちらがボトルネックになっているかを切り分けて捉えることが重要です。
国内の既存Git環境で活かせる仮定例、「判定」と「ビルド」の分離
Scionのような独自システムの構築は一般的な企業環境には適しません。「スクリプトが実際に必要としている情報と、取得しているデータの差を埋める」という視点は、既存のGit環境でも大いに有効です。
たとえば、国内企業の受注管理システムにおいて、AI支援ツールによるコード修正やテストの実行回数が増加し、CIの待ち時間が長期化しているケースを仮定してみます。
このような環境でパイプラインを調査すると、テスト対象の選定や変更検知のためだけにリポジトリ全体をチェックアウトしているジョブが見つかることがあります。もし変更されたファイルの一覧だけが必要なのであれば、既存のGitホスティングサービスが提供する差分取得APIやコミット比較APIを呼び出すだけで判定を完了できる可能性があります。
実際のファイルが必要なコンパイルや結合テストの段階と、メタデータだけで完結する事前判定の段階を分けることで、不要な大容量クローンや転送の負荷を減らせるか検証する余地が生まれます。
自社のCI・保守処理を整理するための進め方
既存の開発運用を見直す場合、まずはCIログを確認し、リポジトリの取得、差分や変更の判定、実際のビルド・テストの各工程にどれだけの時間を要しているかを測定することから始めます。
次に、自動実行されている各ジョブがどのファイルや履歴を必要としているかを洗い出し、ファイル実体ではなくコミット一覧や変更差分の情報だけで処理できる工程がないかを仕分けます。その上で、現在利用しているGitサービスのAPI仕様、認証条件、取得上限（レートリミット）を確認してください。
いきなり全体のパイプラインを書き換えるのではなく、影響範囲の狭い限定的なテストジョブを1つ選び、従来のチェックアウト方式とAPIによる照会方式で、所要時間や転送量、判定結果の一致を比較・検証していくのが確実な進め方です。
開発・運用の取得処理とAPI連携の検討はデノフへ
AIツールの活用が進むほど、これまでの人間中心の開発手順では意識されなかったCIの転送量やスクリプトの実行待ちが表面化しやすいと考えられます。
株式会社デノフでは、Webサイトや社内業務システムの設計・開発から運用保守までを一貫して提供するとともに、中小企業に向けたAI活用支援として業務の整理やツールの選定、定着支援を行っています（デノフのサービス案内）。
現行のCIパイプラインや保守スクリプトにおいて待ち時間がどこで発生しているかの整理、既存GitサービスのAPIを活用した取得経路の改修案、限定的な環境での検証方法の設計など、運用の継続性を見据えたご相談を受け付けています。日々の開発・保守のボトルネックを見直したいご担当者様は、お気軽にデノフへの相談窓口までお問い合わせください。
