目次
AIに実装を任せると、コードを書く時間は短くなっても、変更を取り込み、テストし、公開するまでの時間が同じ割合で短くなるとは限りません。むしろ、並行する作業が増えて、チェックアウトやCIの待ち時間が目立つようになります。開発基盤を改善するときは、モデルの出力速度とは別の物差しが必要です。
Anthropicは2026年10月13日に、AIエージェントの利用拡大に合わせて社内のソース管理基盤を再設計した事例を公開しました。資料は10月15日に更新されています。本記事は10月21日に確認したAnthropic「Redesigning source control for AI agents」とGitの公式資料に基づく解説であり、Scionという製品が一般提供されたというニュースではありません。
スポンサーリンク
Scionの事例はGitを捨てる勧めではない
Anthropicは、同社で実装以外のソース管理・ビルド・CIがボトルネックになり、社内向けのScionへ移行したと説明しています。オンライン接続を前提にサーバー側へ処理を寄せ、作業によってはリポジトリ全体のチェックアウトを不要にする設計です。これは提供元による自社の特殊な開発環境の報告であり、一般のWeb制作現場で同じ改善率が得られるという実測ではありません。
同資料は、Scionが汎用的なGit代替ではなく、大半のリポジトリにはGitの設計が適しているとも明記しています。読み取るべき変化は「新しい管理ツールに乗り換えよう」ではなく、「AIが増やす変更量に対して、毎回コピーするデータと実行する処理を見直そう」という点です。以下の実施手順は、この考え方を通常のWeb開発へ適用する本サイトの提案です。
まずコードを書く時間と待つ時間を分けて測る
最初に確認したいのは、変更開始から本番反映までの時間の内訳です。AIの応答が速くても、CI実行枠の空き待ちが長ければ、モデルを変更しても問題は解消しません。チェックアウトの後に依存パッケージの導入が長く続くなら、ソース管理とは別の改善が必要です。
代表的な変更を数件選び、実行枠の待ち、ソース取得、依存関係の復元、ビルド、テスト、レビュー、デプロイに分けて記録します。小さな修正と横断的な改修、キャッシュがある実行と初回実行は混ぜずに比較してください。合計時間だけでは、たまたま空いていた実行環境の効果を設定変更の成果と誤認します。
費用も一回のCI料金だけで評価しません。失敗後の再実行や、古い変更に対して走り続けた処理を含め、取り込めた変更一件あたりの実行時間を見ます。測定期間と対象の変更を残しておくと、後で利用モデルやエージェント数を変えた際にも比較できます。本記事では、これらの処理を実行した性能測定は行っていません。
スポンサーリンク
浅い取得と部分取得と作業ファイルの削減は別物
Gitの取得を軽くする方法には複数の軸があります。Git公式のgit cloneドキュメントとGit公式のgit sparse-checkoutドキュメントでは、履歴の深さ、取得するオブジェクト、作業ツリーへ展開するファイルを、それぞれ別の機能として説明しています。「一部だけ取得する」という言葉でまとめると、期待した通信量や処理時間にならない原因になります。
| 方法 | 主に減らす対象 | 先に確かめること |
|---|---|---|
| shallow clone | 取得する履歴の深さ | 差分の基準やタグが必要か |
| partial clone | 最初に取得するオブジェクト | 遅延取得とサーバーの対応 |
| sparse checkout | 作業ツリーに展開するファイル | 必要な共有ファイルが含まれるか |
例えば履歴を浅くすれば、過去との比較やバージョン算出に必要な情報が不足する場合があります。partial cloneのblob:noneはファイル内容の取得を必要になるまで遅らせる方式ですが、結局すべてのファイルを読む処理なら、後続の取得が増えます。sparse checkoutは作業ファイルを絞る機能であり、それだけで通信量まで同じ割合で減るとは限りません。
使い分けはジョブごとに決めます。特定ディレクトリだけを整形する処理と、履歴からリリース番号を決める処理を同じ取得設定にする必要はありません。後者に必要な履歴を省略して速くなっても、出力が誤っていれば改善ではありません。公式資料の説明と、利用中のGit・ホスティング・CIの組み合わせを照らして確認します。
Webのモノレポでは共有設定を取りこぼさない
ここからは説明用の仮想例です。公開サイトをapps/site、管理画面をapps/admin、共通UIをpackages/uiに置くリポジトリを考えます。公開サイトの文言修正だけなら管理画面のファイルが不要に見えますが、実際のビルドにはルートのロックファイル、ワークスペース設定、共通UI、型定義、生成処理が関わるかもしれません。
作業対象を絞る前に、ビルドの入力を一覧にします。直接編集するファイルだけでなく、設定を継承する先、コード生成の元データ、テスト用のフィクスチャも対象です。エージェントへ一部分だけ見せる場合も、取得されていないファイルを「存在しない」と判断させないよう、作業範囲と追加取得の方法を伝えます。
最初は完全なチェックアウトを使う既存ジョブを残し、限定取得のジョブを比較用に走らせる方法が現実的です。生成物やテスト結果が一致するかを見てから置き換えます。共有パッケージを変更したケースを検証に含めないと、単純な文言修正で成功しただけの設定を横断改修にも適用してしまいます。
スポンサーリンク
CIには最初から取得が限定されている場合もある
GitHub公式のactions/checkoutは、通常は指定された参照やイベントに応じた単一コミットを取得し、fetch-depth: 0では全履歴を取得する設定を案内しています。つまり、CIが重いからといって、現状を見ずに「履歴を浅くしよう」と提案しても、すでにその状態かもしれません。まずワークフローの設定とログを確認します。
逆に、理由が分からないまま全履歴を取得しているなら、その必要性をジョブ単位で確認します。履歴に依存する処理を残し、ファイルの検査だけをする処理は分ける余地があります。ただし、差分対象やマージの基準、タグによるバージョン計算を使っていないかを先に調べます。設定値だけを機械的に変更するのは避けてください。
部分取得の設定を組み合わせる際も、Git自体の機能とCIアクションの入力仕様を混同しないことが重要です。同じような名前の項目でも、指定の優先関係はツールにより異なります。採用中のアクションの版に対応する公式説明を読み、取得ログと生成された作業ツリーで意図した結果になったか確かめます。
変更数が増えるとテストの鮮度も課題になる
AIが並列に修正案を作る運用では、同じブランチへの更新で古いCIが何本も残ることがあります。この場合はチェックアウトの数秒より、不要になったビルド全体を止める方が有効かもしれません。同じ変更系列で置き換え可能なジョブと、途中で止めると問題がある公開処理を分け、前者に限って実行の集約や中止を検討します。
また、あるコミットで成功したテストが、取り込む時点の別のコミットまで保証するわけではありません。どの変更の組み合わせを検証したのかを追跡し、並行変更が共有部分へ触れた場合の再検証条件を決めます。エージェントが作る変更の量だけを増やすと、レビュー待ちや競合解消が新しい詰まりどころになります。
Anthropicのような特殊な大規模環境の設計を、そのまま自分のチームへ移す必要はありません。待ち時間を削るために既存の取り込み前テストを外すのではなく、不要な重複実行、処理対象、依存関係の取得を先に見直します。品質を保ったまま終わる変更が増えたか、という指標で改善を判断します。
すべての処理にローカルコピーが必要かを問う
Scionの設計が示すもう一つの視点は、目的とチェックアウトを切り離すことです。例えば変更されたファイル名の一覧や、特定コミットの差分を読むだけの処理なら、ホスティング側のAPIで必要な情報を取得する設計も候補になります。これはScionを導入する提案ではなく、通常の開発基盤でも検討できる作業分解です。
ただし、APIにすれば常に安く速くなるとは限りません。呼び出し回数の制限、ページ送り、応答の欠落や打ち切り、障害時の扱いが新たな運用項目になります。ビルドのように多くのファイルを読む処理では、毎回個別に取得する方が不利な場合もあります。必要なデータ量とアクセス回数で比較してください。
ネットワークへ処理を寄せるほど、通信できないときに何が止まるかも重要です。ローカルで完結する作業まで遠隔サービスへ依存させる必要はありません。既存のGit運用を維持しつつ、情報照会だけの小さなジョブを切り出す方が、全面移行より問題の切り分けと復旧が容易です。
導入判断は小さな比較から始める
実施順序としては、まず待ち時間の内訳を取り、次に一つの遅いジョブを選び、取得する履歴・ファイル・処理の必要性を確認します。その後、出力の一致、キャッシュなしの初回、共有部分の変更、再実行を含めて比較します。改善しなければ戻せるよう、設定変更は独立した小さな単位にしてください。
AIモデルの選び方と開発基盤の選び方は別ですが、無関係でもありません。小さな変更を大量に並行させる運用と、広い範囲を一度に改修する運用では必要な取得範囲も検証も異なります。エージェントの並列数を増やす前に、CIやレビューが受け止められる量を測ることが、実際の開発速度を上げる近道です。
Scionから学べるのは特定ツールへの乗り換えではなく、作業の目的に合わせてデータと処理を減らす考え方です。まずはGitと既存CIでできる範囲を検証し、正しい成果物を届けるまでの時間が短くなったと確認できる改善から採用しましょう。
スポンサーリンク
参考資料
Anthropic「Redesigning source control for AI agents」（2026年10月13日公開・10月15日更新）
Git公式のgit cloneドキュメント
Git公式のgit sparse-checkoutドキュメント
GitHub公式のactions/checkout
資料確認日：2026年10月21日。Scionの報告は提供元の事例として扱い、本文の導入手順と仮想例は本サイトの提案として区別しています。
