Anthropicは2026年10月13日、同社で1日にマージされるコード変更が、5月の平均約2,500件から9月には3万件を超えたと報告しました。コードを書く作業が速くなるにつれ、次に時間を取るのはソース管理、ビルド、CI（コード変更を自動で検査する工程）だというのが同社の説明です。そこで同社は、巨大な社内リポジトリ向けに独自のバージョン管理システム「Scion」を作りました。Anthropicの公式エンジニアリング記事
この数値は「AIを使えばどの会社でも開発が12倍になる」という意味ではありません。Anthropicの社内環境で測った変更件数であり、顧客に届いた機能数や不具合率、社員一人あたりの生産性を測った数字ではないからです。小規模チームが参考にできるのはScionそのものより、AI導入後にレビューやテストが新しい待ち時間になっていないかを測る考え方です。
この記事では、発表された数値の範囲、Scionを一般企業がそのまま使えない理由、AIコーディングの効果を自社で試す方法を整理します。日本はClaude Codeの対応地域に含まれますが、Scionの提供を意味するものではありません。まず自社の作業を一件選び、AIあり・なしで「修正から確認済みのマージまで」を比べるのが実務的な出発点です。
Anthropicは5月から9月にコード変更が10倍超へ増えたと報告
公式記事によると、Anthropicでマージされたコード変更は2026年5月に平均約2,500件/日、9月時点で3万件超/日でした。Anthropicはこれを「10倍超」と説明しています。単純に数字を割れば約12倍以上ですが、どちらも概数なので、精密な生産性倍率として扱うべきではありません。発表日は10月13日で、比較対象は5月と9月の社内開発です。
同社は、Claudeが研究上の作業を繰り返したり、大きなコードを書いたりできるようになったことが、既存の開発基盤を人間中心の規模から押し上げたと説明します。変更を受け取り、履歴を処理し、ビルドして検査する仕組みが追いつかなくなったため、同社は自社のモノレポをGitからScionへ5か月かけて移行しました。モノレポとは、複数の製品やサービスのコードを一つの大きなリポジトリにまとめる方式です。チェックアウトは、作業や検査に必要なコードをリポジトリから作業環境へ取り出す処理を指します。
ここでの発表は、Claudeの性能評価や一般ユーザー向けの機能提供ではありません。Anthropicの社内運用と、そこで必要になったインフラの設計を紹介する記事です。読者がまず持ち帰るべき問いは「AIが何行書いたか」だけではなく、「作られた変更を、誰が、どれだけの時間で、どの品質確認を通して次へ進めるのか」です。
「変更件数が10倍超」は「開発の生産性が10倍」と同じではない
変更件数は工程の一部分を表します。コードがマージされても、ユーザーが使える状態で公開されたとは限りません。変更の難しさ、レビューにかかった時間、テストの失敗、リリース後の修正、顧客が得た価値は、この件数だけでは分かりません。
| Anthropicが公表した指標 | 記事から確認できる範囲 | この数字だけでは分からないこと |
|---|---|---|
| マージされたコード変更 | 5月平均約2,500件/日、9月3万件超/日 | 変更一件ごとの規模、担当者数、顧客へ届いた割合、不具合率 |
| リポジトリの規模 | メイン履歴は約100GB、圧縮した作業コピーは25GB超 | 一般的な中小企業のリポジトリで同じ問題が起きるか |
| コードのチェックアウト | CIや研究ジョブ等で1日あたり約2,500万回 | 通常の開発チームで必要なサーバー構成や投資額 |
| チェックアウト時間・計算資源 | 同社は秒単位への短縮、CIのCPU容量25%改善などを報告 | 別組織で同じ割合を再現できるか、他の品質指標も改善したか |
表の数値はいずれもAnthropicの社内発表に基づきます。たとえば「CPU容量25%改善」は、同社の新しいチェックアウト方式を同社の以前の構成と比べた報告であり、他社のGit環境を同じ割合で速くする保証ではありません。記事には、独立した第三者による再計測や、AI導入前後の欠陥率を同じ条件で比較した結果は示されていません。
そのため、経営上は変更数の伸びを売上や納期短縮に読み替えず、後段の指標と並べて見ます。たとえば「依頼からレビュー完了までの日数」「人がレビューに使った分数」「テスト後に差し戻された回数」「リリース後に戻した変更の数」を一緒に測れば、コードを書く工程だけが速くなって他が詰まっていないか判断できます。
Scionは巨大な社内モノレポ用で、一般向けGit代替ではない
ScionはAnthropicが社内で作ったバージョン管理システムです。Anthropicの記事は、作業クライアントが常にサーバーへ接続できる前提にし、必要なデータだけを取得する設計や、ソース管理の操作をAPIから呼び出す考え方を説明しています。これは同社の巨大なコード基盤を大量のCIジョブやエージェントが扱うための設計です。
Anthropic自身も、Scionを一般的な用途でGitの代わりにするのは適さないと述べています。同社の説明では、こうした方式は極めて大きなモノレポや非常に多くのエンジニア・エージェントが動く環境を想定しており、他社が採用するにはリポジトリだけでなく、コードレビュー、コード検索、CIなど周辺の開発工程も移行しなければなりません。Scionを中小企業向けに販売開始したという発表でもありません。
したがって「AnthropicがGitを捨てたから、自社も独自VCSを作るべきだ」という結論にはなりません。多くの小規模チームでは、既存のGitやホスティングサービスを保ちながら、待ち時間が発生している場所を探す方が先です。レビュー担当が一人に集中しているのか、テストが遅いのか、受け入れ条件が曖昧なのかを区別しなければ、インフラ変更に費用をかけても原因は残ります。
Gitの全面変更ではなく、まず「書く時間」と「待つ時間」を分ける
Anthropicの設計変更が必要になった背景は、一般的な小規模リポジトリとは大きく異なります。同社の記事では、メインブランチの履歴が約100GB、圧縮した作業コピーが25GB超で、CIや研究ジョブなどが1日あたり約2,500万回コードをチェックアウトすると説明されています。さらに、ピーク時には数百の社内Gitミラーを運用していたものの、変更量が増えるにつれて維持が難しくなったとしています。この規模だからこそ、サーバーから必要なデータだけを取る独自方式を選びました。AnthropicのScion設計説明
少人数の会社で同じ問題が起きているかを見分けるときは、単に「AIが書く量」を数えず、一つの依頼が流れる経路を分けます。受付条件をそろえる作業、実装、レビュー待ち、レビュー、CI待ち、検査後の修正、リリース確認です。実際に手を動かす時間と、次の担当者や検査を待つ時間は別に記録します。AIで実装時間が縮んでも、レビューの列やテストの待ち行列が伸びれば、依頼が完了するまでの時間は変わらないことがあります。これはAnthropicの数字から小規模チームに機械的に当てはめられる結果ではなく、工程を比較するための見方です。
Anthropicは、Scionの仕組みを広く公開して誰でも導入できる汎用品として出すのは難しいと説明し、社内で使うトークン量も一般企業が通常望む額をはるかに上回ると認めています。したがって、発表された変更量や開発速度には、専用システム、専門チーム、非常に大きなAI利用量という条件が含まれます。自社で測るときは、同じ件数を目標にするより、既存のGitやCIを保ったままどの待ち時間が実際に減るかを判断してください。
AIが書く量が増えても、設計判断と確認は人に残る
Anthropicの記事では、関連システムの変更依頼をすべて人がレビューしていると説明されています。レビュー担当者はコードの一行一行を読むだけでなく、変更の意図を理解して判断するようになったとしています。一方で、同社はClaudeが重要な設計上の制約を破る実装を提案したり、仮定上のリスクに過剰反応して複雑な検証を足したりした例も紹介しています。
これはレビューを省いてよいという話ではありません。むしろ、生成量が増えたときに、守るべき仕様と人が承認する箇所を先に決めておく必要があることを示しています。中小チームが試行するなら、AIの出力を直接本番へ反映せず、変更範囲を限定したブランチで作業し、既存テストと担当者の確認を通してからマージします。テストが存在しない領域では、AIが「テストも追加した」と報告しても、そのテストが本当に重要な失敗を検出できるかを人が確認します。
Anthropicは大規模環境向けに、マージ後やデプロイ前の自動テストにも投資したと記しています。小さなチームで同じ方式を導入する必要はありませんが、変更後の検査をどこで行い、失敗したとき誰が止めるかは決めておきます。変更を速く作るほど、見落としを検出する仕組みを後付けする負担も大きくなるからです。
小規模チームでは、同じ種類の仕事をAIあり・なしで比べる
AIコーディングの試行では、モデルがどれだけ賢く見えたかより、日常業務のどの工程が変わったかを測ります。作業の開始は「担当者が受け入れ条件のそろった依頼に着手できる状態」、終了は「レビューと必要な自動検査を通ってマージされた時点」のように固定します。開始点や終了点が人によって違うと、導入前後の比較ができません。
ここでいう全体のリードタイムは、担当者が作業を始めてから、レビューと必要な自動検査を通った変更がマージされるまでの経過時間です。実際にコードを書いた分数とは分けて記録します。作業時間が減っても、レビュー待ちやCI待ちが残れば、依頼者が受け取るまでの時間は短くならないためです。
次の2例は、実際の導入や検証の結果ではなく、評価の組み立て方を示す想定例です。
想定例1：ECサイトのフォームに入力検証を一つ追加
担当者は、注文フォームで特定の入力が欠けたときにエラー表示を出す小さな修正を選びます。作業前に、必須項目、正常な送信、空欄や形式違いのときの表示、既存の画面幅で崩れないことを受け入れ条件に書きます。AIには限定したブランチ上で変更案とテスト案を作らせ、担当者は差分、既存の自動テスト、実際の画面表示を確認します。
記録するのは、依頼からマージまでの時間、レビューに使った時間、追加・修正されたテスト、差し戻し回数です。コード作成だけが短縮し、画面確認やレビューで同じ時間が増えたなら、全体の納期は改善していません。受け入れ条件をAIが満たしていない場合は、その回を成功扱いにせず、どの条件の伝達または確認が足りなかったかを記録します。
想定例2：月次CSV集計の不具合を修正
バックオフィスの担当者と実装者が、集計対象から同一伝票が二重に数えられるなど、再現条件を説明できる不具合を選びます。実データの代わりに、個人情報や取引先情報を含まない固定サンプルを用意し、期待する合計、空欄行、重複行、月末の境界を先に決めます。AIにコード修正と回帰テストの案を作らせても、経理担当者が既知の正解値と突き合わせて確認する工程は残します。
この例では、実装時間に加えて、正解値との不一致、見逃された境界条件、レビュー後の修正数、実行に使った利用料を記録します。テスト用サンプルでは合っても、実データ特有の例外を扱えていない可能性があります。小さなサンプルで安全性と再現性を確認した後、担当者が承認した範囲でのみ次の検証に進めます。最初から顧客データや本番ファイルをエージェントへ渡す必要はありません。
試行では時間、品質、待ち時間、費用を分けて記録する
一つの作業を数回試しただけで、汎用的な効率を結論づけることはできません。同じ種類の低リスクな依頼を数件集め、AIなしの過去記録または同時期の通常作業と比べます。タスク数が少なければ「初期観察」として扱い、導入効果が確定したとは書かないでください。可能なら、難易度や担当者が大きく違う作業を同じ表に混ぜず、種類別に比較します。
| 見るもの | 記録方法 | 分かること |
|---|---|---|
| 全体のリードタイム | 依頼が実装可能になった時点から、検査済みでマージされるまで | コード生成の速さが、納品までの速さにつながったか |
| 人の確認時間 | 仕様確認、差分レビュー、テスト結果の確認に使った分数 | 実装で減った時間がレビュー負荷へ移っていないか |
| 手戻りと品質 | 受け入れ条件の未達、追加修正、テスト失敗、リリース後の差し戻し | 速さと引き換えに修正や不具合が増えていないか |
| 待ち時間 | レビュー待ち、CI待ち、他作業との競合を別々に記録 | 次に改善すべき工程が人かシステムか |
| 総費用 | 契約に応じたAI利用料と、レビュー・修正にかかった人件時間 | 削減できた作業の価値が追加費用を上回るか |
試行前に「この作業なら何分短縮すれば有用か」「品質を落とさずに許容できる手戻りはどこまでか」を担当者と決めます。万人に共通する合格率や削減率を置く必要はありません。反対に、結果を見てから都合のよい指標だけ選ぶと、効果を過大評価しやすくなります。AIの実行時間だけを測り、人が修正した時間を記録しない方法も避けます。
小さく試す手順
- 作業の種類を一つに絞る。フォームの表示修正、既存の集計処理の不具合など、受け入れ条件と正解を事前に書ける仕事から選びます。認証、決済、権限、個人情報の扱いなど、誤りの影響が大きい変更は初回の試行対象から外します。
- 比較する前提をそろえる。同じ種類の作業について、直近のAIなしの記録か、同じ期間に通常の手順で行う作業を基準にします。担当者、レビュー担当、テスト、作業の完了条件を可能な範囲でそろえ、難易度が違う依頼を単純に合算しません。
- 安全に戻せる作業環境を用意する。別ブランチや検証用コピーを使い、本番環境への反映権限や実データを最初から渡さないようにします。固定のサンプル、既存の回帰テスト、期待する画面や集計結果を準備し、AIが変更してよい範囲と人が承認する範囲を決めます。
- 作業中の条件も記録する。利用したツールとモデル、依頼文、担当者、AIの実行時間、人が追加で書いた指示を残します。モデルやテスト条件が途中で変わった場合は印を付け、前後の結果を同条件のように扱わないようにします。
- 品質確認を通常どおり通す。差分、受け入れ条件、自動テスト、必要な画面確認を人が確認してからマージします。テスト失敗をAIに修正させた場合も、最終結果とテスト自体の妥当性を見ます。AIが「完了」と述べたことは、検査を通った証拠にはなりません。
- 結果を工程ごとに振り返る。リードタイム、レビュー時間、CI待ち、手戻り、不具合、利用費用を分け、どこが変化したかを記録します。少数の試行なら「初期観察」として、他の作業へ一般化できるかは保留します。
試行の規模は、まず同種の作業を数件から始め、安定して記録できるなら5〜10件程度まで増やす方法が現実的です。これは統計的な効果を保証する最低数ではなく、依頼一件の偶然に判断を左右されにくくするための目安です。同種の作業が月に一度しかないなら、無理に期間を短縮して数を揃えるより、試行結果を限定的な観察として扱います。
結果の読み方も先に決めます。実装時間は減ったがレビュー時間が増えたなら、差分の範囲や受け入れ条件を見直します。レビュー時間は変わらずCI待ちだけが長いなら、モデルを上位に変えるよりテスト構成や実行待ちを調べます。全体時間が変わらず、確認負担や利用費用が増えた場合は、対象の作業を変えるか、試行を拡大せず止める判断も候補です。
導入を急がない条件を決め、まず一つの工程を測る
自社の変更が少なく、レビューやCIにほとんど待ち時間がない場合、Anthropicの事例から大規模な投資を正当化することはできません。受け入れ条件を書けない、テスト用データを安全に用意できない、差分を確認する担当者がいない、本番環境の秘密情報を分離できないといった状態なら、先に開発手順を整えるか、AIを使わない判断も妥当です。
Claude Codeについては、Anthropicの対応地域ポリシー（2026年5月12日発効）が対象サービスにClaude Codeを挙げ、日本を対応地域に含めています。ただし、この地域一覧は社内システムScionの販売や利用資格を意味しません。試す場合は、現在のアカウント、プラン、課金方法、組織のデータ取り扱い条件を契約前に公式画面で確認してください。料金は本記事では固定値を示しません。Anthropicの対応地域ポリシー
次の行動は、AIツールを増やすことではなく、最近の一件を使って「依頼受付、実装、レビュー、CI、リリース」のどこで待ったかを記録することです。そのうえで、繰り返し発生し、失敗しても戻せる作業を一つだけ選び、既知の正解やテストを用意します。AIあり・なしの全体時間と品質を同じ基準で比べ、実装の負荷がレビューや検査へ移っただけなら、利用範囲を広げる前に詰まりの工程を改善します。