アンソロピック「脱Git」の真意とは？ AI開発を加速する基盤刷新と見極めるべき条件

1日3万件超の変更、開発基盤の前提が変わる

　米アンソロピックは10月13日、社内のソースコード管理システムをGitから自社開発のScionへ移行した経緯を公表した。複数の開発プロジェクトを1つの保管庫で管理するモノレポで、コード変更の統合件数は5月の1日約2500件から、9月には3万件超へ増えたという。移行は5カ月で完了した。

　この数字を読む際に押さえたいのは、統合した変更の数と、利用者へ届けた価値は同じではないという点だ。変更には機能追加だけでなく、修正や実験も含まれうる。3万件という値だけから、開発者の生産性や売上への貢献が何倍になったかを計算することはできない。

　一方、変更が集中する基盤の負荷を考える材料にはなる。コードを取得し、動作を検証し、ほかの変更と組み合わせる工程は、書いたコードの後ろに続く。生成にかかる時間を縮めても、そこで長く待てば、利用者に届くまでの時間は縮まらない。AIを活用する企業にとって、開発支援ツールと基盤の整備を一緒に考える理由である。

　今回のニュースは、Gitを一律に置き換えるべきだということではない。アンソロピック自身、自社の負荷は特殊であり、多くのリポジトリにはGitの設計が適していると説明する。であれば、まず知りたいのは、同社と自社では何が共通し、何が違うのかということだろう。

　そこで本稿では、発表内容とGitの公式文書、開発の成果を測るDORAの指標を手がかりに、改善の順番を整理する。焦点は、新しい管理システムの名前ではなく、どの待ち時間を、どの方法で減らすか。刷新に進む条件と、既存環境を育てる条件を切り分けてみよう。

Scionの設計を自社に当てはめる条件

　Scionの前提は、主な利用者であるAIエージェントや自動処理が常時オンラインであることだ。履歴の照会や変更の統合などをサーバ側へ寄せ、端末は必要なデータを取得する。この構成を検討するなら、まず自社でネットワークに接続できない作業がどれだけあるかを洗い出したい。開発者の人数よりも、作業の場所と接続条件が判断材料になる。

　次に、巨大な保管庫のどの部分を実際に使っているのか。たとえば1つの機能を検証するたびに、無関係なディレクトリまで取得しているなら、取得範囲の見直しから始められる。Gitのsparse-checkoutは、作業用のファイルを指定した一部に絞る機能だ。保管庫全体を手元に展開しなくても作業できる余地がある。

　ただし、作業用ファイルを減らすことと、通信で取得するデータを減らすことは別である。Gitのpartial cloneでは、たとえばファイル内容を必要になるまで取得しない設定が可能だ。前者を有効にしただけで、履歴や通信量も同じ割合で減るとは限らない。両者を区別して測定する必要がある。



　最後は運用体制である。社内専用の仕組みを持つなら、障害対応や権限管理、将来の改修まで担当する主体を決めなければならない。以下の判断手順は企業向けに整理した本稿の提案であり、アンソロピックが公表した移行基準ではない。自社の取得範囲、接続条件、保守体制をそろえてから、候補を比較したい。

【次ページ】コード生成の後、どこで待つかを測る