要点：Anthropic Scion（サイオン）は、コーディングエージェントの台頭によってモノレポへのマージ数が2026年5月の1日あたり約2,500件から9月には30,000件超へと急増したことを受けて、Anthropicが自社開発した社内向けバージョン管理システムです。Scionではコミット、マージ、リベースがすべてサーバー上で実行されます。社内専用システムであり、AnthropicはGitの汎用的な代替品ではないと説明しています。
AnthropicがScionを開発した理由とその取り組み
2026年10月13日、Anthropicのエンジニアリングチームは公式ブログ記事「Redesigning source control at Anthropic（Anthropicにおけるソース管理の再設計）」を公開しました。その冒頭の主張は率直です。「システムの構築や研究の推進において、コーディングはもはやボトルネックではない」。真のボトルネックは、「人間規模を前提に作られた開発者インフラ全体、すなわちソース管理、ビルド、そしてCIである」と彼らは記しています。
数字を見ればその理由は明白です。2026年5月時点での同社の1日あたりのコードマージ数は約2,500件でした。それが9月には30,000件を超えました。わずか4か月で12倍に急増した計算であり、Anthropicはこの要因をAIエージェントによるコーディングの自動化によるものだとしています。
人間の開発規模であればGitでも問題ありませんでした。しかし、エージェント規模になると破綻をきたしました。Anthropicによると、CIのチェックアウト回数は1日約2,500万回に達し、mainブランチの履歴サイズは100GB近くに膨らみ、ピーク時には社内に数百台ものGitミラーサーバーが稼働していたといいます。単純なフェッチ戦略をとった場合、Gitトラフィックは1日あたり600PBを超えてしまう計算でした。
そこで7人のチームが立ち上がり、Scionをはじめ、Antiqueと呼ばれるコードレビューツール、コード検索機能、ディレクトリ単位のアクセス制御システムを構築しました。彼らはわずか5か月でモノレポのGitからの移行を完了させました。さらに、GitからScionへの取り込みパイプラインの書き直しにはClaude Mythos Previewを活用し、メモリ使用量を20分の1に削減し、実行速度を4倍に向上させました。
チーム内でClaude CodeやCodexなどのコーディングエージェントを運用しているなら、この記事で語られている内容はまさに次に直面するボトルネックの予告と言えます。Sharklyはこの課題を解決するために作られました。エージェントの作業、成果物、レビューを散在するターミナルではなく共有のTask上に集約して管理できます。
ScionとGitの違い
Gitは、すべてのクローンが履歴全体を完全に保持し、オフラインでも自律して動作することを前提としています。一方、Scionはその逆を前提としています。クライアントは常時オンラインであり、ローカル側ではほとんど処理を行いません。
| Git | Anthropic Scion | |
|---|---|---|
| Where commits, merges and rebases run | ローカル（開発者のPC上） | サーバー上 |
| Local data | 完全な履歴 | 容量制限付きオブジェクトキャッシュ、疎（スパース）または仮想化チェックアウト |
| Unit of work | ツリーを指すコミット | 先行書き込みログ（WAL）内の変更セット（変更ファイル一覧） |
| Branches and refs | 作成コストが低く推奨される | mainおよびリリースブランチを除き非推奨 |
| Fetch | パックファイル | オブジェクト単位（ツリー、次いでBlob）、リポジトリのメンテナンス不要 |
| Offline work | 可能 | 不可 |
| Main clients | 人間 | エージェント、CI、研究ジョブ |
アーキテクチャは3層構造になっています。各ノードで動作するscion-daemon、リージョンごとのscion-cache、そしてオーソリタティブ（マスター）なscion-serverです。クライアントCLIはscnと呼ばれます。各層のキャッシュヒット率は99%を超えています。
その成果は絶大でした。CPUとメモリのフットプリントは従来のGitミラー構成と比べて200分の1に縮小しました。CIや研究環境でのチェックアウトにかかる時間は数分から数秒へと短縮され、CIのCPUキャパシティは25%向上しました。
サーバーサイドコミットによって何を犠牲にしたのか
サーバーサイドでコミットを行うことは、Gitがデファクトスタンダードとなった最大の利点、すなわち「飛行機の中でも作業できるローカルの完全な履歴」を捨てることを意味します。Anthropic自身もこの点を率直に認めています。Scionは「一般的な用途においてGitの適切な代替とは到底言えない」とし、他組織が利用できる形で提供するのは困難であると述べています。外部への公開はされておらず、記事内でもオープンソースとは言及されていません。
並行処理の仕組みも、通常想定されるものとは異なります。Anthropicではグローバルロックを用いてすべてのマージを直列化（シリアライズ）しているわけではありません。並行する変更同士が競合する可能性は残されており、同チームはマージ後およびデプロイ前のテストによってそれを検出しています。
AIエージェント時代のGit：Scionを持たないチームへの教訓
一般的なチームがScionを導入することはできませんし、そもそも導入する必要もありません。リポジトリサイズは100GBにも達していませんし、1日に2,500万回ものチェックアウトを行っているわけでもないからです。この記事から学ぶべき真の価値は、リポジトリの規模にかかわらず現れる「課題の本質的な構造」にあります。
エージェントがコードを書くようになると、ボトルネックは開発プロセスの下流へと移動します。まずマージに、次いでコードレビューへと移るのです。DevOps.comの報道やTechSpotの記事でも、Scionはエージェントのアウトプット量にインフラが追いつくための取り組みとして位置づけられています。10体のエージェントを動かす5人の小規模チームであっても、規模こそ違えどまったく同じ壁に突き当たることになります。
次のような兆候に心当たりはないでしょうか。
- 同じ日の午後に2体のエージェントが同じファイルを編集し、手動でのコンフリクト解消を余儀なくされる。
- 誰も読み切れないスピードでプルリクエストが積み上がっていく。
- エージェントは高速に動作し続ける一方で、CIのキューの待ち時間が毎週のように延びていく。
- どのエージェントが、何を、なぜ変更したのかを誰も把握できなくなる。
- 火曜日に切ったブランチを金曜日にリベースしたら、収拾がつかないほどのコンフリクトが発生する。
Anthropicは新たなインフラを開発することで1と3の課題に対処しました。しかし、すでに手元にあるプロセスとGitの標準機能を活用すれば、これら5つの課題すべてに対応することができます。
コーディングエージェントによるマージコンフリクト：なぜ急増するのか
マージコンフリクトの発生頻度は、人数ではなく「作業の重複度合い」に比例します。1つの大まかな目標に向かって10体のエージェントが作業すると、常に同じファイルを変更し合ってしまいます。一方で、明確にスコープが絞られた10個のタスクに10体のエージェントが取り組めば、衝突することはめったにありません。エージェントの数よりも、個々のタスクの大きさが重要なのです。
長寿命のブランチは事態をさらに悪化させます。ブランチが開かれたまま放置される時間が長くなるほど、背後でmainブランチはどんどん進んでいきます。人間がブランチをマージ（クローズ）する速度をはるかに上回るペースでエージェントが次々とブランチを作成するため、この問題はより顕著になります。人間1人あたりの稼働日でどれだけの量のエージェントの作業をレビューできるかについては、過去の記事「how many agent workdays one human workday can review（人間の1営業日でレビュー可能なエージェントの稼働日数）」で具体的な数値を検証しています。
Scionがなくても今日からできる5つの実践策
通常の開発チームが必要とする対策の大部分は、以下の5つのプラクティスでカバーできます。いずれも新たなバージョン管理システムを導入する必要はありません。
タスクごとに専用のworktreeを割り当てる
Git worktreeは、同一のリポジトリに紐づく別のワーキングディレクトリを作成できる機能です。タスクごとに1つのworktreeを割り当てれば、2体のエージェントが同じディレクトリに同時に書き込む事態を防げます。
git worktree add ../tasks/COIN-212 -b agent/COIN-212 origin/main
cd ../tasks/COIN-212
# run the agent here, commit, push, open a PR
git worktree remove ../tasks/COIN-212
具体的な環境構築手順は「AIコーディングエージェントのためのGit worktree活用法」で、後片付けの手間を省く方法については「クリーンアップの煩わしさを解消するworktree管理術」で解説しています。
タスクを小さく保ち、スコープを明確にする
タスクを指示する際は、変更対象となるファイルやモジュールを明示し、完了を証明するための検証内容を含めるようにします。1回のレビューで確認できる適切な差分（diff）に収まるタスクであればスムーズにマージできますが、「認証周りをリファクタリングする」といった曖昧で巨大なタスクではうまくいきません。
mainブランチの手前にマージキューを導入する
マージキュー（Merge Queue）は、最新のmainブランチにそれ以前にキューに入ったすべての変更を適用した状態で各プルリクエストをテストし、順番にマージしていく仕組みです。GitHubのマージキュー機能を使えば、保護されたブランチに対してこの処理を実行できます。これはAnthropicがマージ後テストで行っているアプローチの小規模チーム版と言え、破損した変更の組み合わせがmainにマージされた後になって初めて発覚する、という事態を防ぐことができます。
レビューをタスクおよび検証エビデンスと紐づける
コードの差分（diff）だけを見ても、レビュアーにはエージェントが何を指示され、何を検証したのかが分かりません。指示内容、実行ログ、テスト結果、そして差分が一箇所に集約されていれば、レビューは格段にスピードアップします。詳細は「タスク単位のエビデンスを活用したAI生成コードのレビュー方法」や「なぜ人間のレビューがボトルネックになるのか：並行開発のためのレビュー設計」をご覧ください。
エージェントに人間の承認を待たせる
調査、コードの記述、テスト、レポート作成はエージェントに任せましょう。その一方で、方針の決定、リスクを伴うステップの承認、最終成果物の受け入れは人間が担います。エージェントがマージ前に一旦停止して人間の確認を待つことで生じるロスはせいぜい数分ですが、未レビューのコードがmainにマージされた場合の後始末には丸一日かかります。「コーディングエージェントのための承認ゲート：どこで停止させるべきか」では、どの段階にチェックポイントを設けるべきかを詳しく解説しています。
Sharklyが果たす役割
SharklyはGitを置き換えるものではありませんし、マージコンフリクトを自動解決するツールでもありません。エージェントはこれまで通り、既存のGitホスティングサービスを経由してリポジトリにコミットします。Sharklyが整理・管理するのは、それらのコミットを取り巻く「作業そのもの」です。
エージェントが行う個々の作業は、担当者（Assignee）、ステータス、実行ログを備えた「Task」として管理されます。エージェントは自身が契約しているClaude CodeやCodexなどのランタイムを使用し、自前のComputer上で動作します。Temporaryモードでは、タスクごとに独立したディレクトリが割り当てられ、リポジトリと連携した実行時には個別のworktreeを用意できるため、並行して走るTask同士が1つの共有フォルダに同時に書き込む心配はありません。
エージェントが作業を終えると、Taskを人間のレビュー待ちステータスに移行できます。その通知はInboxに届き、担当者はTaskを開いて作業文脈を踏まえた上で結果を確認し、承認、再試行、再割り当てのいずれかを判断できます。タスクの実行結果とその後のやり取りはすべてTaskのタイムラインに集約されるため、カンバンボードがそのままレビューキューとして機能します。
前述したGitの運用プラクティスに、指示、実行、エビデンス、判断を一箇所にまとめるワークスペースを組み合わせることで最大の効果を発揮します。ツールの比較検討を行いたい方は、「並行AIコーディングエージェント管理ツールの徹底比較」をご覧ください。
今すぐ対策を始めるべき人とは
日常的に3体以上のエージェントを稼働させているチーム：マージの限界点（マージの壁）は目前に迫っています。今週中にworktreeの運用とマージキューの導入を検討してください。
複数のエージェントを並行稼働させている個人開発者：ボトルネックはマージではなくレビューにあります。1つの差分を10分以内に読み終えられるサイズになるまで、タスクを細分化してください。
プラットフォームおよびインフラ責任者：CIのキュー待ち時間とプルリクエストの滞留期間を注視してください。Anthropicの記事が示しているように、何よりも先に破綻するのはソース管理とCIです。あなたの組織でも同じ順序で問題が発生すると考えるべきでしょう。「分離されたworktreeによるエージェントの並行稼働環境」を整えることで、本格的な破綻を迎える前の貴重な猶予を確保できます。
まとめ
Anthropic Scionは開発の未来を告げるシグナルであり、一般の開発者がそのまま導入できるプロダクトではありません。Anthropicではマージ量が4か月で12倍に急増し、Gitの「オフラインファースト」な設計がフィットしなくなったため、7人のチームが「クライアントの大半がエージェントである世界」に向けてソース管理システムを一から再構築しました。大半の開発チームにおいて、ここまでのシステムが必要になることはまずありません。
しかし、コーディングエージェントを導入するすべてのチームが、本質的に同じパラダイムシフトに直面することになります。コードを書くコストが劇的に下がる一方で、それをマージし、レビューするコストは跳ね上がります。タスクを隔離し、サイズを小さく保ち、マージをキューイングし、エビデンスに基づいてレビューを行いましょう。
レビュープロセスを一元化したい場合は、まずは1台のComputerをSharklyに接続し、エージェントを1体作成して、小さく低リスクなTaskを割り当ててみてください。その実行結果がどのように集約されるかを確認した上で、本格導入を検討してみてはいかがでしょうか。
よくある質問（FAQ）
Anthropic Scionとは何ですか？
ScionはAnthropicが社内向けに開発したバージョン管理システムです。2026年に同社のモノレポにおいてGitから置き換えられました。コミット、マージ、リベースをすべてサーバー側で実行し、クライアント側には容量制限のあるローカルキャッシュのみを保持します。
なぜAnthropicはGitを置き換えたのですか？
コーディングエージェントの活用により、1日あたりのマージ数が2026年5月の約2,500件から9月には30,000件超へと激増したためです。従来のGitミラーリング、チェックアウト、CIインフラがその負荷に耐えきれなくなり、ソース管理が開発全体の最大のボトルネックとなったことが理由です。
Scionはオープンソースとして公開されていますか？利用可能ですか？
一般公開はされていません。Anthropicは、Scionは一般的なGitの代替として適したものではなく、他組織向けに提供することも困難であると述べています。同社がその設計思想を公開したのは、他の開発チームがそのアイデアを既存のGit環境に応用できるようにするためです。
コーディングエージェント間のマージコンフリクトを減らすにはどうすればよいですか？
タスクごとに独立したworktreeを割り当て、1回のレビューで把握できる差分サイズにタスクのスコープを限定し、頻繁にマージを行い、mainブランチの手前にマージキューを配置することです。コンフリクトはエージェントの数ではなく変更ファイルの重複によって発生するため、スコープの適切な絞り込みが何よりも重要になります。
小規模チームにも新しいバージョン管理システムが必要ですか？
ほぼすべてのチームにおいて不要です。Anthropicが直面した問題は、100GBに及ぶ履歴サイズと1日2,500万回というチェックアウト規模に起因するものです。通常の規模であれば、worktree、マージキュー、そしてタスク単位のレビュー体制を整えるだけで十分に負荷を処理できます。
