本記事は、CodeRabbitのお届けするポッドキャストTHE MERGEより、Just because AI can build it. Should you ship it? | CodeRabbit & TRM Labsの日本語解説記事です。
TL;DR
CodeRabbitのCEOであるHarjot GillとTRM Labsの創業者Rahul Raina氏が、AIによってコード生成が加速した後の開発を議論します。両社が直面しているのは、生成したコードの検証、増え続けるプルリクエストの優先順位付け、そして何を製品に組み込むかという課題です。
対談の中では検証への投資、企画から社内共有までをつなぐ開発プロセス、用途に特化したエージェントの実行基盤、コンテキスト管理の工夫を紹介しています。AIが機能を実装できるようになっても、その機能を提供するべきか、品質をどう確認するかは引き続き人が判断する必要があります。
事業をはじめるのに大事なのは、長く取り組める課題と仲間（1:23〜）
Rahul Raina氏は、尊敬できる仲間と意義のある問題に取り組みたいという思いから起業しました。市場については、現時点の規模だけでなく、速く成長することを重視していると言います。また、大きな目標を掲げることで優秀な人を集めやすくなり、困難な時期にも自分の意欲を保ちやすいと話します。
Harjotも難しいシステムを作ることや、ほかの人に機会を生み出すことに魅力を感じて起業しました。CodeRabbitはもともと、Harjotが2社目のスタートアップで開発していた社内ツールです。そのツールが成長し、開発者向けの製品を扱う現在の事業につながりました。
共同創業者選びにおいては相互の尊敬や謙虚さに加え、互いを補うスキル、リスクを取れる度合い、生活上の事情も話題になります。対談では、最初から綿密な計画を立てていたというより、実際に一緒に働いた経験や関係を通じて事業を始めた経緯を語っています。
AIで拡大する攻撃に対し、検証と防御をどうするか（18:20〜）
TRM Labsは、犯罪捜査を支援するデータやエージェントを開発しています。Rahul Raina氏は、AIによって攻撃者が活動を拡大しやすくなったと説明します。たとえば、以前の詐欺サイトは見た目が粗く、変更の特徴を追いやすいものでした。現在はAIで、完成度の高いサイトを短時間に作れます。人員を増やすだけでは追いつけないため、防御側にもAIを活用する必要があると述べています。
ソフトウェア開発でも、エージェントが長時間動いて大規模な変更を作るほど、人がコードを理解することは難しくなります。CodeRabbitでは別のAIを使って出力を検証し、人がより高い抽象度で変更を把握する必要があると話します。具体的な問題として、想定外の実行経路やユーザーフローの変更、個人情報の漏えい、セキュリティの低下といった点が挙げられます。
両者は、人による承認と自動検証を組み合わせています。TRM Labsは現在、研究開発の約40％を検証に充てており、顧客向け製品では人がPRとデプロイを承認しています。捜査支援の製品でも、人が判断できるように出典や監査ログを用意し、分析結果を確認しやすくする設計を重視しています。
実装が速くなるほど、何を作るかの判断が重要に（32:13〜）
CodeRabbitでは、バックグラウンドエージェントや自動化を導入した結果、オープンなプルリクエストが約1,000件に増えました。エージェントはサポートチケットや監視アラートを調べ、必要に応じて修正を作成します。しかし、変更を生成できても、人が承認する作業や優先順位の判断が追いつきません。対談では、PRを作る前に計画を確認する仕組みが十分に整っていないことを課題として挙げています。
TRM Labsは、開発プロセスを担当者ごとの工程から、果たすべき仕事を中心とする構成へ見直しました。顧客の声などを集める「signal」、試作して方向性を固める「shape」、実装と検証を組み合わせる「make-validate」に加え、保守や学習、社内への共有も扱います。文書とプロトタイプをリポジトリに保存し、営業やマーケティング向けの資料生成までつなげています。
同社はプロダクトマネージャーが戦略上の優先事項を与え、エージェントがそれに関係する情報を探す運用も進めています。顧客の要望を解決する機能を作れても、画面にボタンを追加する方法が適切かどうかは分けて判断します。実装が容易になったからこそ、目的や設計を事前に詰めることが重要になっているのです。
特化した実行基盤と評価で製品の品質を高める（53:43〜）
Harjotは、基盤モデルの進歩が速いために、コードレビュー用途では独自のファインチューニングよりも、モデルをどう動かすかに注力していると説明します。複数モデルを組み合わせて、処理の振り分けやコードの意味解析、推論前に必要なコンテキストを集める仕組みなどを調整しています。これは、用途に特化した実行基盤を構築することによって、精度と費用の両方を改善する方針に則っています。
こうした調整は、評価をもとに進めています。CodeRabbitは公開されたコードなどのデータを、実行基盤やコンテキスト構成の改善に使っています。TRM Labs側も評価と実行基盤の重要性に同意しており、用途によっては99％と99.9％の精度の差が大きな意味を持つと述べています。これは製品の実測値を示す話ではなく、自動化を任せられる水準まで品質を高める難しさを意味します。
両社は利用者の業務に合った体験も重視しています。開発者がプルリクエスト上で求める操作や、捜査担当者が必要とする監査性は、それぞれ異なります。試作品を作ることに加え、継続して品質を維持し、費用や業務上の要件を満たすことにも開発の労力がかかります。
人はエージェントの文脈を整理し顧客の課題に向き合う（1:21:34〜）
Harjotは、モノレポでは関連するサービスをエージェントが参照しやすく、複数リポジトリにまたがる変更も扱いやすいと話します。一方で、変数名が不明確だと検索や推論を誤りやすく、ファイルが小さすぎると文脈をつなぐ手間が増え、大きすぎても扱いにくくなると説明します。人にとって読みやすい構成と、エージェントが効率よく扱える構成の間には違いがあると議論しています。
情報取得においては、CodeRabbitは当初からサンドボックス内のコマンドやコード検索を利用していました。その後に追加したRAGでは、コードの変化によって取得情報が古くなることが問題になりました。現在は、実行時に定義や参照を解析してコードの関係を把握する方法などを使っています。TRM Labsも、取得結果をすべてコンテキストに詰め込む方法から、ファイルに保存し、必要なときにエージェントが読み直す方法へ移したことで性能が改善したと話します。
対談の最後では、製品がまだモデルの能力を十分に活用しきれていないという見方を共有しています。他の創業者に対しては、変化に注意を払って想像力を持ち、良い製品を見極める感覚を育てるように勧めています。そのうえで、顧客を深く理解し、製品をどう届けるかを考えることが引き続き重要だと述べています。
まとめ
AIによって実装が速くなると、チームは検証・承認・優先順位付け・社内共有により多くの労力を使うようになります。CodeRabbitとTRM Labsは、自動検証への投資や開発プロセスの再設計を進めながら、人が責任を持って変更を判断できる仕組みを整えています。生成したコードをレビュー担当者に渡す前に、作成者自身が品質を確認する姿勢も求めています。
製品を作るうえでは、用途に合った実行基盤や評価、最新のコンテキスト、利用者の業務に合う体験を組み合わせています。両社が重視しているのは、作れる機能を増やすことに加え、顧客の課題を理解した上で何を提供するかを判断することです。AIの能力を製品の価値につなげるために、実装の前後を含めた開発全体を見直しています。