Harness、AI エージェントの継続的トラフィック対応へリポジトリ再構築

Harness のフィールド CTO（最高技術責任者）であるマーティン・レイノルズは、エンジニアリングリーダーに対して頻繁に一つの質問を投げかけています。答えは簡単ではありません。

それは、コーディングエージェントが生成するプルリクエストの増加に対応する方法です。あるリーダーは「対応できていない」という 2 語で答えたそうです。レイノルズ氏によれば、そのチームは本番環境へのコード投入基準を下げざるを得なかったといいます。

TNS は、Harness が再構築した Code Repository と新しい AI コードレビュー製品を発表した後数日、そして GitHub が 8 月 17 日に約 8 時間にわたるプラットフォーム障害を起こしてから数週間後にレイノルズ氏に話を聞きました。

会話では、レビューのボトルネックが生じた理由や、なぜエージェントからのトラフィックに対応するために Git リポジトリを再構築したのか、そしてパイプラインのどの部分を決定論的に保つべきかについて議論しました。

プルリクエストで溢れる状況

レイノルズ氏によると、このボトルネックは Harness が GitHub Copilot や Amazon CodeWhisperer の初期試験を行った際に初めて発見されました。

「プルリクエストの数は増えたが、すべてが滞留してしまった」と彼は言います。「テストチームが叫んでいた。これについていけないと。」

—Martin Reynolds, Harness Field CTO.

新コードの投入量が 1.5 倍から 2 倍に増加したことで、テストチームは限界まで追い詰められたそうです。現在は 10 倍になるケースもあり、中には 50 倍という報告もあるといいます。「今のテストチームがどんな気持ちでいるか想像してみてください。」

—Martin Reynolds, Harness Field CTO.

カンファレンスでのエンジニアリングリーダーとの廊下での会話から、Reynolds 氏はプルリクエストの洪水が繰り返されるテーマであることを指摘しています。顧客と話す際に彼が見る状況は主に三つに分類されます：リスク許容度を高めたケース、管理しきれないバックログを抱えているケース、そしてその中間にいるケースです。

「その中間にあるのが最も一般的だと思います」とReynolds 氏は語ります。「私たちはその分野を支援するために何らかの AI ツールを使っていますが、それが必ずしも問題を解決するわけではありません。」

足場ではなく、変更点に焦点を当てる

理想的には、プルリクエストを開いたレビュアーは、まず最も重要な変更点を把握すべきだと Reynolds 氏は考えます。そして、そのコードベースの一部を担当した人物がレビュアーとなるべきで、「プロンプトを作成した人」や「コードを書いた人」ではなく、と彼は提案しています。

「他の部分は依存関係の更新に伴う約 30 ファイルに過ぎません。これらは目を通す重要性という点では低いです」と彼は言います。レビュアーは「その周辺にある足場となる多くのものではなく、実際に変更されている部分をレビューするべきです。」

「モデル単体ではありません」と彼も付け加えます。Harness は過去 12 ヶ月の間に、顧客のパイプライン、デプロイメント、インシデント、ポリシーをマッピングしたソフトウェアデリバリー知識グラフと呼ばれるものを構築するために、「かなりの時間を費やしました」。これにより、レビュアーはコンテキストを「高速で取得でき、トークンを大量に消費することなく済みます。」

同社が自社の事例として挙げたのは、過去のインシデントレビューで未索引の CREATE INDEX ステートメントが生産環境のテーブルを 14 分間ロックしていたことが判明し、移行フラグが立てられたケースです。

同社の集計によると、エンジニアたちは毎月 10,000 時間以上の手動レビュー時間を節約しました。Harness のサービス開始当日から、GitHub の Copilot コードレビューはボットによって作成されたプルリクエスト、同社自身のコーディングエージェントによるものも含めてレビューを開始しています。

エージェントは朝 9 時から午後 5 時まで働くわけではありません

最近、GitHub を利用する Harness の顧客からは「GitHub がダウンしている」というスクリーンショットを真摯に送ってくるケースが頻繁にあったと、Reynolds は語っています。

GitHub が抱える課題の理由は、同社が最終的に「人、あるいは最大で 10〜15 人のチームがコードを変更し、プルリクエストを作成するために設計された」ためだと Reynolds は考えています。作成されたプルリクエストは数時間から最長でも数日間存在するものです。しかし、エージェントは朝 9 時から午後 5 時までしか働かないわけではありません。

Harness は 2023 年、オープンソースの Git プロジェクト上に「Harness Code」を立ち上げて以来、リポジトリサービスを提供してきました。Reynolds によれば、同社はこれを「人間と AI の両方に対応する、AI ファーストのリポジトリとしてゼロから再構築した」とのことです。

これは Kubernetes ベースで、複数のクラウドやリージョンにまたがって稼働しており、1 秒間に数千件のコミットを処理できることがテスト済みです。ベータ版では約 20 のエンタープライズ顧客が利用していましたが、Harness はその詳細を公表していません。

GitHub の CTO、ヴラド・フェドロフ氏は 8 月 17 日の障害に関する事後分析で、「中央米国のデータセンターにある重要なインフラコンポーネントがスケーリングに失敗した」と述べています。これはトラフィックが新たなピークに達した際のことでした。

現在、GitHub では月に 29 億件のコミットを処理しており、平均すると 1 秒間に 1,000 件以上となっています。

もちろん、Harness がこの規模で運営しているわけではありませんが、エンタープライズユーザーにとっては、むしろこれが強みになる可能性があります。

Harness はまた、従来のプロセスの枠組みを超えた新たな方向性も模索し始めています。レイノルズ氏は、自律的なデリバリーライフサイクルを実現する機能はすでに存在すると指摘しつつ、「しかし、組織や企業がその準備ができているだろうか？私はまだ確信が持てない」と述べています。

いずれにせよ、彼は決定論的なツールリングの維持が必要であり、テスト結果も依然としてテストランナーから得られるべきだと強調しています。「それらをすべて撤廃して置き換える必要はありません。むしろ、どこを強化できるかを考えるべきです」

今回の発表において、最も多くのチームが最初に接する部分はレビュー機能です。これはすでに GitHub に存在するプルリクエスト上で動作し、大企業にとってリポジトリの移行は長期間を要するプロジェクトとなります。

レイノルズ氏に「準備できていない」と答えたエンジニアリングリーダーは、新しい Git ホストを導入してその答えを変える必要はありません。彼が必要としているのは、プルリクエスト内のどのファイルがまだ人間のレビューを要し、どの 30 ファイルが依存関係の更新に伴うものなのかを明確に示すツールです。

これは自律的なデリバリーライフサイクルという壮大な約束に比べれば小さな目標ですが、現時点ではむしろ実用的で有益なものとなる可能性が高いでしょう。

「Harness が非停止 AI エージェントトラフィックのために Git リポジトリを再構築した」という記事は、The New Stack に最初に掲載されました。