agensby homula
資料請求無料相談

Engineering · アーキテクチャ

AIエージェントが1日3万件のコードをマージする世界の開発基盤 — Anthropic Scion から読み解く設計の5原則

エージェントが大量のコードを生成する時代、開発インフラの前提が変わります。Anthropicは2026年10月13日、1日30,000件超のマージ量急増に対応するためGitから自社製Scionへ移行した事例を公開。「クライアントは常時オンライン・サーバー中心・スパース取得」という設計への転換が、エージェントスケールへの鍵です（Anthropic Engineering、2026-10-13）。

要点

  • ✓Anthropicは2026年5月の1日2,500件から9月の30,000件超へのマージ急増に対応するため、Gitから自社製Scionへ移行（Anthropic Engineering、2026-10-13）。
  • ✓Scionの設計前提は「クライアントは常時オンライン・サーバー中心」。Gitのオフライン型分散モデルから根本的に転換した。
  • ✓CIのチェックアウト時間は分単位から秒単位へ（約100倍高速）、CI CPU容量が25%改善、キャッシュヒット率99%超（Anthropic Engineering、2026-10-13）。
  • ✓7名のチームが5ヶ月でモノレポ全体をScionへ移行。同期間にマージ量は2,500件→30,000件超（12倍超）に増加（Anthropic Engineering、2026-10-13）。
  • ✓エンジニアの役割は「コードを書く」から「設計判断・架橋・ClaudeにNoと言う」へ変化しつつある（Anthropic Engineering、2026-10-13）。

AIエージェントがコード生成量を急増させると、開発インフラが壊れる

AIエージェントの活用が組織に広がるにつれ、ソフトウェア開発の現場にこれまでになかった問題が起きています。人間の開発者が書いていた時代のペースを前提に設計された開発インフラが、エージェントの生産性についていけなくなるのです。

Anthropicは2026年10月13日、自社のバージョン管理システムをGitから自社製Scionに移行した事例を公開しました（Anthropic Engineering「Redesigning source control at Anthropic」2026-10-13）。その背景にあったのは、AIエージェント（Claude）の活用拡大によるコード生成量の急増です。

マージ件数は2026年5月の1日約2,500件から、9月には30,000件超へと急増しました（Anthropic Engineering、2026-10-13）。同期間に12倍超のスケール増です。CIの1日あたりのチェックアウト回数も約2,500万回にのぼり、素朴にGit fetchで対応した場合は1日当たり600 PB超の転送量になるとAnthropicは試算しています（同）。

この事例は「Anthropic特有の問題」ではありません。エージェントがコードを書き、レビューし、テストを走らせる規模になると、あらゆる組織の開発基盤は同じ壁に直面します。エージェントを組み込んだ開発インフラの設計原則を、Scionから読み解きます。

マージ量が急増すると何が起きるか（Git の限界）

Git の前提（人間開発者向け）全クライアントが完全コピーオフライン前提・分散型マージ急増でミラー数百台ピーク時（Anthropic 2026-10）CIチェックアウト: 分単位1日2,500万回（Anthropic 同左）5月: 2,500件/日 → 9月: 30,000件+/日エージェントが12倍超のコードを生成するとインフラの前提が崩れるエージェントネイティブ設計（Scion）サーバー中心・常時オンラインクライアントは API 経由で取得のみスパース取得・必要分だけCIチェックアウト: 分→秒（約100倍）水平スケール・ロックなしデータ分散・参照数を最小化7名・5ヶ月で移行完了CI CPU 容量 25% 改善・ヒット率 99% 超12倍超スケールに対応出典：Anthropic Engineering「Redesigning source control at Anthropic」2026-10-13
左：Git（人間開発者向けの分散型設計）が抱える課題——全クライアントの完全コピー・数百台ミラー・CIチェックアウトが分単位。右：Scion（エージェントネイティブ）の設計——サーバー中心・スパース取得・水平スケール。マージ量2,500件→30,000件+/日に5ヶ月で対応（Anthropic Engineering、2026-10-13）。

(B) なぜ Git はエージェントスケールに向かないのか

Gitの設計思想は「分散型・オフライン前提」です。各開発者がリポジトリの完全なコピーを手元に持ち、オフラインでも作業できる。これは人間の開発者がラップトップで作業することを前提にした設計で、長年にわたってうまく機能してきました。

ところが、エージェントとCIが主要クライアントになるとこの前提が崩れます。Anthropicが直面した問題点は次の通りです（Anthropic Engineering、2026-10-13）。

  • マージ急増への対応として、ピーク時に数百台の内部Gitミラーを運用していた。
  • モノレポのmainブランチ履歴は100 GB弱、圧縮済みの作業コピーは25 GB超。
  • 1日あたりのCIチェックアウト回数は約2,500万回。素朴にfetchすると600 PB超の転送量となる試算（Anthropic Engineering、2026-10-13）。
  • CI・研究ジョブのチェックアウトに分単位の時間がかかっていた。

「ほとんどのクライアントがエージェントとジョブになった」——この前提の変化がGitを限界に追い込む根本的な原因です。エージェントは人間のように「ブランチを切っておく」「後でプッシュする」という使い方をしません。常時オンラインで、必要な部分だけを素早く取得し、変更をすぐにコミットします。

Scion の3層構造 — サーバー中心・スパース・スケール

Scion の3層アーキテクチャscion-server正規データ（Spanner 管理）scion-cacheリージョン単位・障害を隔離scion-daemonノード単位・ローカルキャッシュエージェント / CI / ツールAPI 経由で必要分だけ取得正規データ・Spannerリージョンキャッシュノードデーモンクライアント層API で汎用利用（CI も agent も）スパース取得・packfile なしロックなし・低コストコミットワーキングコピーは不要・任意Scion 設計：Anthropic Engineering「Redesigning source control at Anthropic」2026-10-13
Scionの3層アーキテクチャ（Anthropic Engineering、2026-10-13）。scion-server（正規データ・Spanner管理）→ scion-cache（リージョン単位）→ scion-daemon（ノード単位）→ クライアント（エージェント・CI・ツール）。左の各層の役割・右の設計原則はAnthropicの報告に基づく。

(B) エージェントネイティブ基盤の設計原則5つ

Scionの設計からAnthropicが示した原則は、エージェントネイティブな開発インフラ全般に応用できる考え方です（Anthropic Engineering、2026-10-13）。

  • ①クライアントは常時オンライン前提：Gitのオフライン型分散モデルを捨て、必要なときにデータをサーバーから取得する。これによりクライアント側の負荷を大幅に削減できる。
  • ②サーバー・クライアント非対称：履歴・blame・コミット作成・マージはサーバー側で処理。クライアントは限定的なローカルキャッシュのみを持つ。
  • ③APIによる汎用利用：CI・ツール・エージェントが、ローカルリポジトリなしにAPIで直接履歴を問い合わせられる設計にする。
  • ④水平スケール：データを分散配置し、完全なコピーをどこにも持たない。参照数を最小限に抑えてグローバルな状態を減らす。
  • ⑤スパース・部分取得：必要なディレクトリ・ファイルだけを取得する設計。巨大なpackfileを使わず、中断・再開が可能な取得方式を採用する。

Scionではこれらの設計により、CIのチェックアウト時間が分単位から秒単位（約100倍）に短縮され、キャッシュヒット率99%超、CI CPU容量25%改善を実現しました（Anthropic Engineering、2026-10-13）。また、7名のチームが5ヶ月でモノレポ全体を移行。移行中も1日あたりのマージ量は12倍超に増え続け、その状態で安定稼働しました（同）。

エンジニアの役割変化 — コードを書くから「Noと言う」へ

Scion移行事例が示した最も示唆深い観察は、エンジニアの役割変化についてです。Anthropicは「エンジニアの役割が、コードを書くことよりも、設計判断を下すこと・架橋をすること・ClaudeにNoと言うことに移っている」と述べています（Anthropic Engineering、2026-10-13）。

具体的には、チームメンバーは全変更リクエストのすべての行を読むのではなく、「変更の意図・目的」を理解することにフォーカスが移っていると報告されています（同）。コードを生成する役割をエージェントが担い、人間はアーキテクチャの制約を守らせる役割を担うという分業の形です。

同事例では、「superfan」と呼ばれる監視エージェントが各コンポーネントの健全性を継続的に確認する仕組みも採用されています（同）。エージェントが生成するシステムを、別のエージェントが監視するという構造です。

（B）この役割変化はAnthropicに固有ではなく、エージェントが開発の主要な担い手になる組織全般に起きることが予想されます。「コードを書ける人」より「何を作るべきかを判断できる人・エージェントに適切に指示できる人」の価値が高まる転換点です。

(A) agens の設計 / (C) 今後の方向性

(A) agensはタスクごとのサンドボックス隔離・RBAC・SSO/SAML/OIDC/SCIM・監査ログ・操作の巻き戻しを実装しています。これらはエージェントが実行環境で行った操作を追跡・制御する基盤です。エージェントネイティブ開発基盤においても、エージェントが変更を加えたコードの追跡可能性・承認フロー・異常検知は、同じ統制原則に基づきます。(C) エージェントが生成するコードの品質評価・承認ゲート・自動ロールバックを開発ワークフロー内に組み込む設計は今後の方向性の一つです。

🛡 一次資料と注記

本記事の事実はすべて一次資料に基づきます：Anthropic Engineering「Redesigning source control at Anthropic」2026-10-13（https://www.anthropic.com/engineering/redesigning-source-control）。マージ件数（2,500件→30,000件+）・チェックアウト数（2,500万回/日）・移行チーム規模（7名・5ヶ月）・CI CPU改善（25%）・ヒット率（99%超）・チェックアウト高速化（約100倍）・600 PB試算・superfan監視エージェント・エンジニア役割変化の記述は同記事の内容に基づきます。agens実績値は含みません。「600 PB」は素朴にfetchした場合のAnthropicの試算値であり実際の転送量ではありません。Scionは現時点でAnthropicの内部専用システムであり、一般公開の予定は公表されていません（Anthropic Engineering、2026-10-13）。

関連

概念を学ぶ（homula.jp）AIエージェントのアーキテクチャパターン →製品で見る（homula.ai）agens エンタープライズ（大規模導入・統制） →

よくある質問

AnthropicがGitをやめた理由は何ですか？
エージェント（Claude）によるコード生成量の急増で1日あたりのマージ件数が5月の2,500件から9月の30,000件超に増加し、Gitベースのインフラが追いつかなくなったためです。CIのチェックアウトが分単位かかり、ピーク時に数百台のGitミラーが必要になっていました（Anthropic Engineering、2026-10-13）。
Scionは誰でも使えますか？
現時点ではAnthropicの内部専用システムです。Anthropicは「Scionは非常に大規模なモノレポ向けの設計であり、一般的なGitの代替ではない」と明言しています（Anthropic Engineering、2026-10-13）。
私たちの開発環境にも同じ問題が起きますか？
エージェントがコードを大量に生成・テストする規模になると、同様の問題が起きる可能性があります。Scionは非常に大規模なモノレポ向けの設計であり、一般的なGitの代替ではないとAnthropicは明言しています（Anthropic Engineering、2026-10-13）。
エージェントネイティブ設計の核心は何ですか？
「クライアントは常時オンライン・サーバー中心・スパース取得・API汎用利用・水平スケール」の5原則です。特に「全クライアントが完全コピーを持つ」というGitの前提を捨て、サーバー側で処理してクライアントは必要分だけ取得する設計への転換が核心です（Anthropic Engineering、2026-10-13）。
agensとの関係は何ですか？
(A) agensはエージェントを企業で安全に使うための実行環境です。エージェントが開発ワークフロー内でコードを生成・テスト・コミットする場面では、agensのサンドボックス隔離・RBAC・監査ログ・操作の巻き戻しが、生成されたコードの追跡可能性と統制を担います。

最終更新: 2026-11-02

agens を実際に動かしてみませんか?

デモ・お問い合わせagens を詳しく見る他の技術解説を見る