著者｜鄭佳美
|| 編集 | 岑 峰
Gitは20年以上にわたりソフトウェア開発を支えてきましたが、Anthropicはそれを置き換えることにしました。Claudeが継続的に生成するコードが開発プロセスにスムーズに入るように、7人のエンジニアが5ヶ月かけてScionの出版システムを開発し、核心コードリポジトリをそこに移行しました。今年の5月には、Anthropicは毎日平均で約2500件のコード変更をマージしていましたが、9月には3万件を超え、CIシステムは毎日約2500万回のコードダウンロードを行うことになりました。 コードを書く速度が上がったものの、リポジトリの準備、オブジェクトの同期、履歴の検索はますます機械を消耗させる。ほぼ同じ時期に、GitHubは微調整されたModernBERTをキースキャンの一般的なLLMに置き換えた。コロンビア大学やGoogle DeepMindなどの機関はBTTFを通じて、チップのシミュレーション波形をSQLiteに変換し、AgentがSQLを使って異常を調査できるようにした。Scionはデフォルトでオンラインであり、BTTFは波形をクエリインターフェースに変換し、GitHubは高頻度の判断を分類器に委ねている。 人類の開発ペースに沿って設計されたシステムが、エージェントによる別の負荷を受け始めている。
01
Gitのオフライン機能がなぜ負担になるのか
Gitの分散型設計により、エンジニアがリポジトリをクローンした後、ネットワークが切断されてもコミット、マージ、履歴の確認が可能になる。しかしAnthropicで大量のコードを読み込む作業は、常にネットワークに接続されたCI作業やAgentサボンであり、数分間実行されるだけで破棄される。おそらく数つのファイル、diff一つ、または二つのコミットの祖先関係を確認するだけである。これらの操作のためにローカルリポジトリを用意することで、再現コストが高くなる。Anthropicのメインレベルの履歴は約100GBに達し、圧縮されたワークコピーは25GBを超える。 毎日2500万回の検出が行われ、完全なコピーが得られると仮定すると、理論上のトラフィックは600PBを超えることになる。会社は浅いクローン、希薄な検出、スナップショット、そして数百台のGitイメージを使用しているが、イメージは依然として同期が必要であり、スナップショットは期限切れとなり、歴史クエリでは対象オブジェクトを補完する必要がある。倉庫が活発になるほど、メンテナンスコストは高くなる。Scionはクライアントを軽量なエントリーに縮小する。コミット作成、マージ、変更基準、歴史クエリは中心サービスに移し、ローカルではファイルの変化のみを監視し、少量のキャッシュを維持し、作業ディレクトリが必要な場合にのみ展開する。 CI もし diff のみを計算したい場合は、APIを直接呼び出すことで、完全なコミットを行う必要はありません。これによりオフラインでの自律性が損なわれますが、再初期化の回数が減少します。コミットの形式も変わりました。Git commit はリポジトリの状態を表すディレクトリツリーを指し、Scionのchangesetは事前に書かれたログエントリを通じて、相対的な最初の親コミットで変更されたファイルを記録し、内容アドレスポインタを使ってデータを参照します。 Changesetを作成するにはGit packfileを生成する必要はなく、共有ブランチを即座に移動する必要もありません。mainなどの引用が更新されるときのみ、システムがSpanner内の単行記録に対してcompare-and-swapを行います。Agentは並行して変更を生成でき、競合はブランチの引用移動時に集中します。しかし、履歴クエリには依然として問題があります：增量記録では、どの行が誰によって変更されたのか、ファイルに何が起こったのかを直接答えることはできません。Scionはblame、パス履歴、コミット図跳表のメンテナンスのための派生データを提供し、親コミット関係に基づいて事前計算するか、クエリが発生した後に生成します。 書き込みと歴史分析は独立して拡張可能です。雷峰網が検出される際、scnクライアントは目標のディレクトリツリーから始まり、欠落しているツリーとblobのみを要求します。要求は順にノード上のscion-daemon、エリアscion-cacheを経由し、次にscion-serverからSpannerまたはオブジェクトストレージにリソースを取り戻します。オブジェクトの書き込み後は変更不可能であり、キャッシュはタスク間で再利用可能で、協調、圧縮、繰り返しの転送を減らします。Anthropicによると、キャッシュのヒット率は99％を超え、障害時のリソース取り戻しトラフィックを制限しています。 移行後、Scionは旧のGitイメージシステムと比べてCPUとメモリの必要量が約200倍減少し、コミット検出は分秒単位から秒単位に下がり、CIは約25%のCPU容量を解放した。200倍というのはインフラ資源の占有量の減少を指し、Git操作全体の速度向上とは関係ない。Anthropicはまた、Antiqueのコードレビュー、ソースコード検索、IAM、バッチマージツールも同時に構築し、新しいプロトコルに適応している。オンラインサービスのメンテナンスも新たなコストとなった。02
データベースで波形を読み込ませて、エージェントが障害を調査できるようにする
チップ検証には別の障害が立ちはだかる。RTLシミュレーションによって生成されるVCD、FSDB波形記録には、時間とともに変化する多数の信号の状態が含まれ、複雑な設計のダンプは数十GB、あるいはTBレベルに達することがある。雷峰網（公式アカウント：雷峰網）のエンジニアは波形閲覧器で時間軸に沿って異常を探すことができる。Agentが元の波形をテキストに変換すると、コンテキストはすぐにタイムスタンプ、信号名、繰り返しのジャンプで埋め尽くされる。他の信号を追跡することも可能で、ファイルの再読み込みが行われる場合がある。 また、人間は図表の中で目で探すのが常ですが、Agentには数十GBもの物理ファイルを収容するためのコンテキストがありません。したがって、これらの「死文件」をSQLで正確に呼び出せる「活接口」に変換することは、AIにデータを与える最適な方法です。BTTFはデータアクセスをSQLiteに委ねています。signal_metadataは信号の名前、種類、階層などの静的情報を保存し、signal_changesは信号ID、タイムスタンプ、変化後の値を記録します。これら2つのテーブルはIDを通じて関連付けられています。 指定された時間点における信号の状態を照会し、SQLはその時間点以前の最も最近の変化記録を見つけ、一定期間内の反転をチェックするため、時間窓でフィルタリングし集計する。2回の跳変の間に状態が変わらない場合、新しい記録がないことを未知と誤解してはならない。モデルは問題を処理し、少数の返されるイベントのみを扱う。例えば、あるセグメントのハンドシェイクプロトコルがタイムアウトした場合、エージェントはリクエストと応答信号の変化を先に検索し、異常な範囲に絞り込んで、時序関係をチェックする。データベースが検索を行い、モデルが次に何を調べるかを決定する。 シグナルID、時間単位、RTLバージョンを一致させる必要があります。しかし、波形をデータベースに格納しても、圧力が自動的に解消されるわけではありません。高周波のクロックによって密集した記録が生成され、行ごとにINSERTを行うことでトランザクションコストがかかります。BTTFでは、取得時に波形識別子をデータベースIDへのマッピングを構築し、信号のジャンプを統計することができ、クロックフィルタリング、ジャンプのない信号のカットアウト、バッチINSERTを組み合わせます。カットアウトされていないデータベースは1420 MBを占め、クエリには約410.5ミリ秒かかりましたが、クロックとジャンプのない信号をフィルタリングした後、サイズは395 MBに減少し、時間は94.8ミリ秒になりました。 もし変動率が平均以下の信号を続けて削除し続けると、データベースは185 MBに縮小するが、活動カバレッジは64.23%しか残らない。稀な障害は、ほとんど反転しない制御信号で発生する可能性がある。データはインポート段階で削除されるため、その後のエージェントでは証拠を復元できない。カットアウトは断言とデバッグの要求に従う必要がある。 SQLインターフェースがあることで、BTTFは異なるエージェントに分担を割り当てる：Orchestrationエージェントがタスクを分解し、Analysisエージェントがクエリを生成し、Verificationエージェントがアプリケーションの断言をチェックしRTLソースと関連付け、Evaluationエージェントが時間範囲、フィールド関係、結果の完全性を確認する。例えばASSERT_KNOWNが信号にX/Zの未知状態が発生したことを発見すると、システムは違反時刻をロックし、関連操作数の状態を前に進めて調べ、可能なモジュールを段階的に特定する。SQLエラーが発生しても修正した後、作業を続行できる。 研究チームは、4.2 GBの波形、18450個の信号、150件の専門家による注釈のクエリを扱う実験で、95.33%の実行正確率を達成した。Multi-Agentの品質評価が単一Agentより17.3%向上し、平均遅延も約1.96倍に増加した。静的SVA検査の正確率は84.62%であった。この方案は後続のシミュレーション分析をサポートするが、継続的なデータ取得と複雑な原因の特定についてはまだ検証が必要である。03
なぜキースキャンが分類器に変わったのか
高エントロピー文字列は、実際の証拠であることもあれば、テストデータ、プレースホルダ、またはハッシュ値であることもある。正規表現は怪しいフォーマットを迅速に特定できるが、コードの文脈を判断するのは苦手である。汎用LLMが区分を助けることができるが、候補が多いほど推論コストと遅延が積み重なる。コードの提出が受け入れられる前に結果を出す必要があるPush Protectionにおいて、この待ち時間は開発体験に直接影響する。GitHubは正規表現を候補エントリとして保持し、後続の判断は微調整されたModernBERTに委ねている。 それは候補文字列、キータイプ、変数名、ファイルパス、および近傍のコードを読み取り、リスク分類スコアを出力する。そして、閾値に基づいて警告を発するかどうかを決定する。エンコーダは前向計算によってカテゴリーを返すことができ、生成型LLMのように一つ一つのトークンに至る説明を出す必要はなく、同種のリクエストを大量処理するのに適している。難点はハードネガティブである：文字列がキーに似ているが、無害な例である。 GitHubは、製品フィードバックと人間によるラベル付け、実際の倉庫内の高再現率の候補データ、特別に合成された困難な負のサンプルを組み合わせ、倉庫、候補値、関連性といった要素に基づいて訓練データと評価データを分けることで、類似したデータがもたらす評価の偏りを減らします。そうでないと、モデルはファイル名を覚えてしまい、見知らぬプロジェクト内の証拠を認識することが難しくなります。デプロイ時には、モデルをONNX形式に変換し、8ビット量化を行うことで推論に必要なリソースの消費を低減します。 閾値は、Precision、Recall、およびオンライントラフィックの校正と組み合わせる必要があります。過度に緩いと誤報が発生し、過度に厳格すぎると実際のキーが見逃される可能性があります。新しいキー形式が出現した場合は、トレーニングセットとルールを更新する必要があります。旧のLLMパイプラインと比べて、新しい方案ではオフラインのPrecisionが13％向上し、Recallが19％向上しました。オンラインのA/B実験によると、Post-pushスキャンの実行時間の中央値が86％減少し、モデルサービスのコストが98％以上減少し、倉庫所有者に基づくアラーム受容指標が11.5％向上しました。 ここでの98％はモデルサービスにかかる費用であり、全セキュリティシステムの総コストではありません。分類器も正規表現で見つかった候補を判断するだけで、前置規則のカバー範囲は漏れが生じることを制限しています。規則が手がかりを発見し、分類器が判断を完了した場合、開放型分析は依然として汎用LLMに任せることができ、毎回固定判断で生成式推論のコストを負担することを避けることができます。04
次にCIの順番になるかもしれない
GitHubはセキュリティスキャンのフィードバック時間を短縮したが、コードは今後もビルド、テスト、デプロイを経なければならない。Anthropicはソースコードの取得問題を解決した後、新たな問題に直面した：一連のテストがまだ終わっていないため、メインブランチには数百、あるいは数千件の変更が追加される可能性がある。グローバルロックに依存し続けると変更が積み重なる一方、並行処理を許可すると新たなリスクが生じる。あるテストが通過したとしても、そのコードの状態がデプロイ準備版と異なる可能性がある。つまりCIが次に処理しなければならないのは、頻繁な変更の中で結果が有効であるかを確認することである。ビルドキャッシュにはソースコードと依存関係の変化を認識する必要があり、テスト記録は具体的なコミットとビルド産物と関連付けられなければならず、システムはどの結果が再利用可能か、どの変更が以前の検証を無効にするかを判断する。依存関係が複雑なMonorepoでは、テスト機器を増やすだけでは、並行変更によるバージョン一貫性の問題は解決しにくい。Anthropicは、マージ後のテストとデプロイ前の検証を強化し始めている。一般的なチームにとっては、依存関係分析、增量テスト、ビルドキャッシュを整備する方が、直接バージョン管理システムを再構築するより現実的である。Agentがコード生成を続けるにつれて、ソフトウェア工学のボトルネックはデリバリーチェーン後方へ移動していく。コードがメインブランチに入る速度は速まるかもしれないが、ビルド、テスト、デプロイの間には信頼できる検証関係を維持する必要がある。将来的には、AIによるコード作成の急速な進展が、最終的にソフトウェア工学の全ラインを「もう一度作り直す」ことに追い込む例が増えるだろう。工学インフラの価値は、変化の速いコードが持続的に信頼できるデリバリー根拠を得られるかどうかに表れる。参照リンク：https://www.anthropic.com/engineering/redesigning-source-control乗り込んで、世界のAIカンファレンスの魅力をご覧しましょう
独占的に観覧できる：
専門家講演PPT
大会報告全文
人気論文解説
学問の新星へのインタビュー
上のQRコードをスキャンする
または「原文を読む」をクリックして専門セクションをフォローしてください。
雷峰網のオリジナル記事は、許可なく転載することを禁じられています。詳細は転載に関する注意事項をご覧ください。