Anthropicにおけるソース管理の再設計

2026年10月14日原文(anthropic.com)

概要

Anthropic はAIによる自律的なコーディングで、従来の開発インフラがボトルネックに
Scion という独自のバージョン管理システムを開発し、gitから全面移行
分散型から常時オンライン前提の設計 へ転換し、スケーラビリティと効率性を追求
Derived Data による柔軟なデータ構造とAPI中心の運用
未来のAI時代 に適したソース管理の新たな標準を提案

AnthropicにおけるAIコーディングと開発インフラの限界

Claude による自律的な研究・開発ループの自動化
コードマージ数の爆発的増加 （2026年5月：2,500件/日→9月：30,000件/日超）
既存の開発インフラ （git・CI/CD等）がAIスケールに対応不能
ボトルネックの本質 ：人間規模を前提とした従来ツールの限界

Scionの開発と移行

Scion ：Anthropicが独自開発した新バージョン管理システム
5か月でgitから全面移行、同時期にレビューUI（Antique）、コード検索、IAMなども構築
Google Piper、Meta Sapling など大規模モノレポ運用の知見を活用
AIによるコード生成能力 が新システム構築の原動力

モノレポ成長とgitの課題

メインブランチの履歴が100GB超、圧縮ワーキングコピー25GB超
1日2,500万回以上のチェックアウト がCI等で発生
gitの分散・オフライン設計 が大規模化で逆に障害に
内部ミラーやスナップショット運用 も限界、運用コスト増大

Scion設計の基本原則

常時オンライン前提のクライアント設計
- クライアントは必要な時だけサーバからデータ取得
クライアント・サーバ非対称性
- サーバが履歴管理・マージ等を担当、クライアントは最小限のローカルキャッシュのみ
API中心のソース管理
- すべての操作・クエリをAPI経由で実現、ローカルリポジトリ不要
水平スケーラビリティ
- データは分散管理、どのサーバもキャッシュ可能、パックファイル不要
コミットは高速・インクリメンタル・ロックフリー
- 変更単位でのみコスト発生、グローバルな参照管理は最小限
ワーキングコピーは任意・スパース設計
- 必要なディレクトリだけ取得、API経由で差分・履歴クエリ可能

Scionのデータ構造と運用

変更単位（changeset） ：WAL（Write-Ahead Log）形式で管理
- 各changesetは親との差分ファイルと圧縮内容のポインタを持つ
Derived Data ：履歴・blame・検索用インデックス等を再帰的に生成
- 新しいデータ構造の追加や最適化が容易
- クライアントは内部構造を意識せず利用可能
サーバ群によるAPI提供
- すべての操作（diff・マージ・blame等）をAPIで実行
- データは不変・キャッシュ可能、サーバ間の協調最小化

Scionクライアント・チェックアウトの特徴

scnクライアント ：gitとは異なるfetchプロトコル
- クライアントは欲しいツリー・blobのみリクエスト
- オブジェクト単位で取得、キャッシュ層構造で効率化
スパース・仮想化チェックアウト
- 必要なファイル・ディレクトリのみオンデマンドで取得
- 巨大なパックファイル不要、効率的なリジュームが可能

Scionのスケーラビリティと運用面での利点

CI・ツール側でローカルリポジトリ不要
- ソース管理クエリのAPI化で運用負担を大幅軽減
サーバキャッシュによる高速化
- どのサーバもオブジェクト単位でキャッシュ、協調不要
運用コスト・複雑性の削減
- 大規模モノレポでも安定運用が容易

まとめ：AI時代の新しいソース管理像

AIによる自律的な開発・研究 が常態化する時代の新標準
従来の分散・オフライン前提設計からの脱却
API駆動・スパース設計・水平スケーラビリティ による持続可能な拡張性
Scion は今後のAI時代のソース管理のベストプラクティスとなる可能性

Hackerたちの意見

今年の初めに、私たちはgit-to-Scionの取り込みパイプラインの最初のバージョンをプロトタイプとしてほぼ手書きで作成しました。良いものだと思っていたんですが、Claude Mythos Previewの初期の内部スナップショットを手に入れてから考えが変わりました。全体を書き直すように頼んだら、特に指示をしなくても、メモリ消費が20倍少なく、速度が4倍速いバージョンを作り出しました。取り込みの順序やデータ構造に関する暗黙の不変条件も全て保たれています。こういうモデルを社内に持つことの利点は計り知れないと思います。劣ったモデルにアクセスしかできない企業は、一般的な開発において置いていかれるでしょうね。

└

一度きりのインポートパイプラインだから、実際問題どうでもいいんじゃない？

└

これはかなり洞察に富んでるね。たぶん、最高のソフトウェアエンジニアですら、これらのモデルにさえ緩やかに追いつけないんだ。脅威を感じるんじゃなくて、その優れた能力を素直に受け入れることを思い出させてくれるね。

時々、Claudeのコードリリースノートを見て、その製品の変更の数を把握するのが好きです。量を測ろうとするなら、箇条書きを数えるしかないですが、時間の経過とともにその数がこの記事のグラフとどう比較されるかは興味深いです。https://imgur.com/a/M30pFLc

Anthropicのエンジニアリングの仕事を軽視するつもりはないけど、AIがコードを書くのをかなり安くしているから、もっと多くの再発明が小さなスタートアップでも見られると思います。カスタムなものを作ることと既存のソリューションを適応させることのトレードオフが変わってきています。すべてのカスタムソフトウェアを維持するのが同じくらい安くなるかはまた別の話です。

└

一日にそんなに多くのコミットがあるのは、エンジニアリングとは呼べないな。基本的に力任せって感じ。

└

記事の内容は、オープンソースや実際のScionソフトウェアスタックを共有することに対する抵抗感について、あなたに同意する傾向があると思う。各組織や個人の環境がツールに組み込まれることで、複雑さや微妙さがあるから、今の段階でこれらのツールが一般化することを期待するのは、もはや時代遅れな考えかもしれない。自分の個人的なスタックで使っているツールにもそういうのが見られる。多くのプロジェクトは共有の候補だけど、特にハードウェアに関する具体性が強いから、共有可能で一般化できるプロジェクトを作るのは、メンテナンスの面で負担が増えるだけなんだよね。

└

LLMの生産性がどこに行っているのか疑問に思う人が多いけど、これがその一部だと思う。LLMを使うことでコード生成は間違いなくみんながずっと生産的になっているけど、実際にはそういうことに多くの生産性が使われているんだよね。Grafanaの制限にいつも悩まされてる？自分に合ったダッシュボードソリューションを作れるよ。遅くてウザいデプロイチームがいる？自分のデプロイエンジンを作れる。kubectlが一度に一つのk8sクラスターしか管理できないのが嫌だった？AIにfleetctlを生成させればいい。DynamoDBから始めて、mysqlに書き換え、次にpostgres、最後にduckdbにする。Pythonから始めて、Golangに切り替え、さらにRustに移行。AWSでデプロイして、Azureに移動、ハイブリッドオプションにして、コロケーションも混ぜる。ソース管理が気に入らない？新しいのを作ればいい。Jsonが制限されすぎてる？ハイブリッドのJSON/HCL言語を発明すればいい。ブラウザのサンドボックスが制限されてる？デスクトップアプリを作ったり、言語を作ったり、OSを作ったり、カーネルを作ったりすればいい。

└

最初は、また同じことを繰り返すのかと思ったけど、ソフトウェア開発の「形」が変わってきて、ツールが新しい柔軟性をサポートする必要があることに気づいた。ソフトウェア開発は、以前のように構築前のリスクを減らすことが中心じゃなくなってきた。今は、チームが素晴らしいものをたくさん作れるけど、間違ったものを作ってることが多い。ほとんどのことが問題の「形」を理解することになってる。問題の形を理解するのは、LLMがいつも早い段階でスリムにできるわけじゃない。ワードジェネレーターは生成しなきゃいけないからね。

正直な質問だけど、今の時点でAnthropicではみんな何をしてるの？Claudeは自分自身でループしていて、毎日何百万行ものコード変更を押し出しているみたい。人間もコミットを打つのが追いつかないんじゃない？この人たち、もうすぐ解雇されるの？

└

https://news.ycombinator.com/item?id=50075832

└

推論の最適化だけじゃなくて、トレーニング側でもかなりの非自明なコードが作業されると思うよ。彼らが運営しているスケールだと、普段は簡単なこともそうじゃなくなることが多いんじゃないかな。

Hacker Newsで議論の続きを見る

ハクソク