homula2026年10月13日、Anthropic はエンジニアリングブログで、社内のバージョン管理を git から自前のシステム「Scion」へ全面移行したことを公開しました（Anthropic Engineering・2026年10月13日（10月15日更新））。きっかけは単純で、冒頭にこうあります——「ソースコントロールが、我々の開発における最大のボトルネックになった」。
注目すべきは、ボトルネックが「モデルの賢さ」でも「エンジニアの数」でもなかった点です。Claude がコードを書く量が機械スケールで膨れ上がった結果、人間の働き方を前提に作られた土台（git・CI・レビュー）が先に悲鳴を上げた。これは、AIコーディングを本格導入しようとするすべての企業に効く警告です。
homula はエンタープライズ向けの AIエージェント・インテグレーターとして、日本企業の「PoC から本番・全社へ」を日々支援しています。本稿では、Scion の技術的な面白さを追うだけでなく、AIにコードを書かせる量が増えたとき、企業の現場で本当に作り変わるのは何かを、日本企業の実装・運用の視点で整理します。
何が起きたのか——1日2,500件が、3万件を超えた
まず、Anthropic が示した数字を押さえます（出典はいずれも公式ブログ）。
- 統合（マージ）件数：2026年5月に 1日あたり約2,500件 だったものが、9月には1日3万件超 へ。約4カ月で10倍以上に増えた。
- リポジトリの規模：モノレポの本流（main）の履歴は ほぼ100GB。
- チェックアウト量：CI だけで 1日あたり約2,500万回 のコード取得が走る（開発環境・エージェントのサンドボックス・研究ジョブは別勘定）。
- 移行：わずか 7人のチーム が、新VCS Scion と専用のコードレビューツール Antique を構築し、5カ月でモノレポを git から完全移行した。
- 効果：従来の git ミラー群に比べ CPU・メモリを約200分の1 に。CI と研究ジョブのチェックアウトは 数分から数秒 に短縮され、CI の計算容量に25%の余裕が生まれた。
この急増の主因は、Anthropic 自身がはっきり書いています。「Anthropic では、システムを作ることも研究することも、もはやコーディングがボトルネックではない」。つまり、人間のタイピング速度という上限が外れた結果として、変更の流量がインフラの設計限界を突き破った、ということです。
ここで「マージ3万件/日」という数字を、自社の現状と比べて「桁が違う」と片付けないでください。重要なのは絶対数ではなく変化の形です。AIエージェントがコードを書き始めると、変更は「人が1日に出せる本数」ではなく「計算資源が許す本数」に支配されます。流量の上限が人からマシンに移った瞬間、人間向けに設計されたすべての工程——取り込み・テスト・レビュー・配送——が順番にボトルネック化します。
なぜ git だったのか——「常時オフライン前提」とのズレ
Anthropic の分析の核心は、git の設計思想そのものにあります。git は、ネットワークが不安定な環境でも各開発者が手元に完全な履歴を持ち、オフラインで作業できる分散型として設計されました。これは人間の分散開発には理想的ですが、Anthropic の利用実態——ほぼ常時オンラインのエージェントやジョブが、巨大なモノレポに高頻度でアクセスする——とは噛み合いません。約100GBの履歴を何百ものミラーへ複製し続ける構成は、マージ流量が上がるほど運用が難しくなっていきました。
Scion は、この前提を逆転させています。公開された設計原則を要約すると、次のようになります。
- クライアントは常時オンライン前提：重い処理はサーバー側が担う。履歴・blame・コミット・マージはサーバーが処理し、クライアント（
scn）は軽量に保つ。 - ソースコントロールを API として露出：操作をコマンドではなく API 経由で提供し、エージェントやツールから直接扱えるようにする。
- 水平スケール前提：キャッシュ階層を重ね、各階層で99%超のキャッシュヒット率を維持する。
- 作業コピーは任意・疎（sparse）：全履歴を手元に複製しない。必要な部分だけを取り出す。
- コミットは安価でロックフリー：全体ロックに頼る従来のマージキューを廃し、マージ後テストとデプロイ前テストに置き換えた。
なお Anthropic は、これを「git の汎用的な置き換え」として売り出すわけではないと明言しています。Google の Piper や Meta の Sapling（サーバー実装 Mononoke）という先行事例に学びつつ、自社の極端な利用形態に最適化した内製システムだと位置づけ、得られた知見は git プラットフォームや OSS コミュニティと共有したい、としています。つまり、ここで真似すべきは「Scion を導入すること」ではなく、設計の問い直し方です。
本当の論点は、ツールよりも「人間の役割」
技術的な話以上に、日本企業の経営・開発現場に効くのは、Anthropic が率直に書いた働き方の変化です。
「このシステムを作ったエンジニアは全員、いまや Claude の方が自分よりコードを書くのが上手いと評価するだろう」
その上で、エンジニアの仕事がどう変わったかをこう述べています。「エンジニアの価値が下がったわけではない。仕事の中身が変わったのだ」。具体的には、
- 多くの場面で、エンジニアの役割は Claude に『ノー』と言うことだった。AIが出してくる過剰に作り込まれた設計を押し戻し、制約条件を定める側に回る。
- レビューの重心が、1行ずつコードを読むことから、変更の「意図（intent）」を検めることへ移った。
- 7人という少人数で大規模移行を完遂できたのは、AIの支援を前提に設計の意思決定とレビューに人を集中させたから。
ここに落とし穴があります。AIがコードを書く量が増えるほど、人間のレビュー能力が新しいボトルネックになります。生成量は機械スケールなのに、承認・監査・説明責任は依然として人間のスケールのまま——この非対称を放置すると、「誰も中身を把握していないコードが本番に流れ込む」か「レビュー待ちで何も進まない」かの、どちらかに振れます。Anthropic が VCS と同時に**専用のレビューツール（Antique）**を作ったのは偶然ではありません。
「人間前提」から「エージェント前提」へ——作り変わる4つの層
今回の事例を一般化すると、AIコーディングを本格導入したときに作り変わるのは、次の4つの層だと整理できます。
| 層 | 人間前提の設計（これまで） | エージェント前提で問い直す点 |
|---|---|---|
| 配送（VCS/CI） | オフライン分散・手元に全履歴・全体ロックのマージキュー | 常時オンライン・疎なチェックアウト・ロックフリー／流量に耐えるスケール設計 |
| レビュー | 1行ずつ人が読む・1変更1人レビュー | 意図ベースの検証・自動チェックと人の承認の役割分担 |
| 統制（権限/監査） | 人のアカウントで操作・事後の棚卸し | 変更が誰（どのエージェント）の意図かを証跡に残す・機械スケールの監査 |
| 人の役割 | 書く・読む | 制約を定める・『ノー』を言う・意図を検める |
重要なのは、この4層は順番にボトルネック化するということです。Anthropic の場合はたまたま「配送（git）」が最初に壊れましたが、多くの日本企業ではおそらくレビューと統制が先に詰まります。生成は速くなったのに、承認フローと監査が人手のまま残っているからです。
日本企業にとっての意味——「賢いモデル」の次に来る宿題
この事例から、日本企業が引き出すべき示唆は3つあります。
- AIコーディング導入の勝負どころは、モデル選定の後ろにある。どのコーディングエージェント（Claude Code か Codex か、等）を選ぶかは入口にすぎません。生成量が増えたときに配送・レビュー・統制の土台が流量に耐えるかが、本番・全社展開の分岐点になります。私たち自身、AIコーディングで自社サイトを作り直した記録でも、ボトルネックが「書く速度」からその周辺工程へ移ることを実感しました。
- レビューと監査を機械スケールへ設計し直す。人が1行ずつ読む前提のレビュー運用は、生成量が10倍になれば必ず破綻します。何を自動チェックに委ね、何を人が「意図」として承認するか——その役割分担を先に決めることが要になります。これは検証可能な実行証拠を統制の層にするという発想と地続きです。
- 「人の役割」を再定義する。エンジニアを減らす話ではなく、書く人から、制約を定め・意図を検め・『ノー』を言う人へという配置転換です。ここを言語化しないまま生成量だけ増やすと、現場は「AIの出力を追認するだけ」の受け身な運用に陥ります。
いきなり全社の開発基盤を作り変える必要はありません。まず1チーム・1リポジトリで、AIにコードを書かせる量を意図的に増やし、「どの工程が最初に詰まるか」を観測することを薦めます。多くの場合、それは配送（CI）ではなく、レビュー待ちと承認・監査です。詰まる場所が分かれば、投資すべき土台の順番が決まります。
homula の観点——実行基盤とレビュー設計を、内製化の射程に入れる
今回の事例が示すのは、**AIにコードを書かせる量が増えたとき、企業が本当に作り変えるのは「モデル」ではなく「配送・レビュー・統制の土台」**だという現実です。これは homula が一貫して主張してきた「実装の勝負どころは実行基盤にある」という立場と、正面から重なります。
homula は、この土台づくりを一気通貫で支援します。MCP を活用したエンタープライズ向け統合プラットフォーム Agens は、200以上のツールと構築ゼロで接続し、開発・業務のエージェントを既存基盤に組み込みやすくします。そのうえで Agens Control が、承認フロー・DLP・5年分の監査ログ・RBAC を提供し、生成量が機械スケールになっても「誰の意図でこの変更が入ったか」を証跡に残せる状態を作ります。レビューと監査を人間スケールのまま放置しない——それが本番・全社展開での安全弁になります。
進め方としては、(1) 1チームでAIコーディングの生成量を意図的に増やし、最初に詰まる工程を特定する → (2) レビュー・承認・監査の役割分担を設計し直す（何を自動化し、何を人が意図として承認するか）→ (3) 実行基盤と統制の土台を敷く → (4) 横展開と内製化、という順序を推奨します。AIエージェント・ブートキャンプ（業務棚卸し・プロトタイプ構築・ROI試算を3〜5日で完結）は、この最初の観測と設計を素早く回すための入口として使えます。
まとめ
Anthropic の Scion 移行が示したのは、エンタープライズAIの焦点が 「どれだけ賢くコードを書けるか」から「機械スケールの出力を、どう配送し・レビューし・統べるか」へ 移ったという事実です。要点は3つです。
- 最初に壊れるのは土台：コーディングがボトルネックでなくなると、人間向けに作られた配送（git/CI）・レビュー・統制が順番に悲鳴を上げる。1日2,500件が3万件超になったとき、Anthropic が作り変えたのはモデルではなくバージョン管理だった。
- レビューと監査が次のボトルネック：生成は機械スケール、承認・監査は人間スケール——この非対称を設計で埋めないと、無統制な本番流入か、レビュー渋滞のどちらかに振れる。
- 人の役割は『書く』から『検める』へ：制約を定め、意図をレビューし、AIに『ノー』を言う。この配置転換を言語化することが、AIコーディングを追認作業にしないための鍵。
「どのコーディングエージェントを入れるか」の議論を、「増えた出力を安全にさばく土台があるか」へ一段引き上げること。それが、AIコーディングを PoC から本番・全社へ、そして説明責任を伴う運用へと運ぶための次の一歩です。
AIにコードを書かせる量が増えたとき、最初に詰まるのは配送でもレビューでも統制でもありえます。どの工程から作り変えるべきか——その見極めと土台づくりを、homula は実装から内製化まで一気通貫で支援します。