Gautam Korlam、Sonar のプリンシパルエンジニア – インタビューシリーズ

Gautam Korlam、Sonar のプリンシパルエンジニアで、開発者向けインフラストラクチャ、コード品質、オートメーション、AI支援ソフトウェア開発にキャリアを注いできたベテランソフトウェアエンジニア兼テクノロジーリーダーです。Sonar に入社する前は Gitar を共同設立し CTO を務め、コードレビューの自動化、継続的インテグレーション（CI）失敗の診断、根本原因の特定、修正生成を目的とした AI ネイティブプラットフォームを構築しました。Sonar は 2026 年 5 月に Gitar を買収し、Korlam と Gitar チームは同社に加わり、Sonar のより広範なコード検証プラットフォームの一部として技術開発を継続しています。Gitar 以前は、Korlam は Uber でほぼ10年にわたり、モバイルプラットフォームチームの創業エンジニアからプリンシパルエンジニアへと昇進しました。在職中、Uber の集中型開発者インフラの構築とスケール、モノレポおよびビルドシステムの大規模イニシアチブのリード、リモート開発環境と CI/CD ツールの開発、そして StarCoder、OctoCoder、Code Llama といったオープンソース大規模言語モデルを用いた実験を通じて、Uber のコードベースにおける AI 支援コーディングの向上に取り組みました。以前の経験としては Lookout でのエンジニアリング職、UC サンタバーバラでの研究、Microsoft と Oracle でのインターンシップがあります。

Sonar はコード検証、コードレビュー自動化、コード品質、アプリケーションセキュリティに注力するソフトウェア企業です。主力製品の SonarQube プラットフォームは、開発者が書いたコードや AI が生成したコードを解析し、バグ、脆弱性、保守性の問題、その他の品質課題を本番環境に到達する前に特定します。提供形態はクラウド、セルフマネージド、統合開発環境（IDE）ワークフローにわたります。Sonar によると、同社の技術は 700 万人以上の開発者と 22,000 社の顧客に利用され、1 日あたり 7500 億行以上のコードを解析しています。Gitar の買収により、このアプローチは AI ネイティブなコードレビューとリメディエーションへと拡大し、SonarQube の検証エンジンと、コードレビュー、CI 失敗の調査、修正の提案や適用が可能なエージェントツールを組み合わせ、ソフトウェア開発がますます AI 主導になることに対応しています。

あなたのキャリアは、Uber のモバイルおよび開発者インフラの構築から、コードベース上でオープンソースの大規模言語モデルをトレーニングし、Gitar を共同設立して Sonar に加入するまでに至ります。これらの経験は、コード生成は課題の一部に過ぎず、信頼性のある検証がより難しい問題であるという信念をどのように形作ったのでしょうか？

Uber では、誰がリリースできるかを決定するシステム、つまりモノレポ、ビルド、CI キュー、テストスイートの部分に取り組んでいました。変更を容易に生産できるようにすると、すべての負荷がその機構に集中します。予測できない形で相互作用するサービスが増え、エンジニアは自分の変更がマージしても安全かどうかを確認する必要が出てきます。

その後、社内コードベースでモデルをトレーニングする仕事に取り組みました。ここで非対称性が顕在化しました。モデルは迅速に妥当な実装を生成できますが、その実装が実稼働システムに適合し、チームが実際に使用している慣習に従い、二つのサービス間で何かを壊さないことを確認するにははるかに時間がかかり、その大部分が人間の作業となります。Gitar はこの課題から生まれ、Sonar が 17 年以上にわたって分析側で行ってきたことと合致しています。

AI コードレビューは決定論的分析を置き換えるのではなく補完すべきだと主張されていますが、繰り返し可能なルールベースの分析で最も適切に特定できる問題はどのようなものか、また従来の手法では対応できない AI の提供できる能力はどこにあるのでしょうか？

ルールベースの分析は、コード自体から決定できる性質の問題に適したツールです。汚染された入力がシンクに到達すること、誰かが見落としたパスでの null 参照、ハードコードされた認証情報、既知の CVE を持つ依存関係、層を越えてインポートすることなどが該当します。各実行で同じ結果が得られ、なぜ検出されたかを指摘できるため、強制はこの層で行われるべきです。

ルールがカバーできないのは意図です。パーサーだけでは、ユーザー向け文字列が翻訳者にとって曖昧になることや、変更がチケットを閉じると主張しながらチケットの要求の半分しか実装していないこと、あるいは新しいリトライループがサービス全体のバックプレッシャー処理と衝突することなどを判断できません。差分とリンクされた課題、コードベース全体のコンテキストを読み取るモデルはそれらを指摘し、人が最終的に確認するべき所見として提示すべきです。

AI システムはビジネスロジック、開発者の意図、アーキテクチャ上のトレードオフを評価できますが、その結論は確率的です。開発チームはこのコンテキスト推論を活用しつつ、AI レビュアーの出力を本質的に正しいと扱わないようにするにはどうすればよいでしょうか？

AI レビューは、従来のチェックが見落とす問題—論理エラー、意図と合致しない振る舞い、単体では問題なさそうでも特定システムでは誤りとなる変更—に対して価値を発揮します。これらの結論は確率的であるため、決定そのものではなく、意思決定への入力として扱われるべきです。チームはマージ前に決定的なコントロールを保持し、具体的には自動テスト、CI 検証、セキュリティスキャン、ポリシーチェック、そして変更を所有する人間です。AI は修正案を提示したり、チームが設定したガードレール内で実装したりできますが、これらの変更は人が書いたものと同様の検証を通過し、機械生成だからという特権は与えられません。

我々は自社実装でも同様の境界を設けています。モデルは所見を提案し、レビューの判定はそれらの所見の状態からコード上で計算されます。解決も同様の流れです。所見に対応するコードが差分から消えている場合、それはパースされた差分に対する決定的チェックとなり、モデルは既に差分で修正されたものを再度未解決にすることは許されません。

一般的な考え方として、間違いが回復可能な領域に確率的層を任せ、状態機械は決定的に保ち、責任はチームに残すという形です。信頼を得るためには、誰もが検査でき、すべての実行で同じ挙動を示す証拠が必要です。

Sonar はコンテキスト対応のプルリクエストレビューと決定論的分析、品質ゲートを組み合わせています。効果的な多層検証プロセスはどのような姿か、また各層は作業の重複や開発者への所見過多を招かずにどのように連携すべきでしょうか？

決定論的分析と品質ゲートは交渉の余地がない項目を扱い、マージがブロックされる基準となります。コンテキストレビューは、変更が主張通りに機能するか、コードベースに適合するか、リスクが人の注意を要するかといった判断を行います。

大量の所見は、全く所見がない場合と同程度に無視されます。レビューア間で重複除去を行い、検証できない候補を除外し、シグナルの高い所見に注力します。ルール側では、モデルが実行される前に現在の差分にルールが適用可能か述語で判定するため、ほとんどの変更に対してルールはコストをかけません。すべては開発者がすでに開いているプルリクエスト上に表示されます。

コード生成エージェントがより多くのコードとプルリクエストを生み出す中で、ソフトウェアレビューと検証が新たなボトルネックになる可能性はありますか？レビュー工程のどの部分を自動化すべきか、どの判断を経験豊富なエンジニアに残すべきか教えてください。

レビューと検証はすでにボトルネックとなっています。実際、我々の 2026 State of Code Developer Survey によると、チームは作業週の約 4 分の 1 を AI の出力の確認と修正に費やしていると報告しています。この結果から、開発者の 48% しか AI 生成コードをコミット前に必ずチェックしておらず、しかし大多数（96%）は機能的に正しいと完全には信頼していないことは驚きではありません。

自動化に値する作業は機械的で不快な作業です—たとえば、CI 失敗を根本原因まで絞り込み、誰も 4,000 行のログを読む必要がないようにすること、リベース後に所見がまだ有効か判断すること、失敗を再現すること、明白な修正を書くことです。エンジニアは意図、設計、そして特定の変更に対してどれだけの証拠が十分かという判断を保持すべきです。シニアエンジニアが 9 件の失敗のうちどれが重要かを夜間にログを読んで判断するのは、判断というよりトリアージであり、まさに我々が彼らから取り除くべき作業です。

AI コードレビューシステムは問題を特定し、修正を提案し、継続的インテグレーションパイプラインに対してその変更を検証できます。自律的なリメディエーションシステムがリグレッションを引き起こしたり、ソフトウェア全体の品質よりもビルド成功にだけ最適化することを防ぐにはどうすればよいでしょうか？

最も重要なのは、ビルドが緑（成功）であることを受け入れ基準としないことです。緑のビルドは、存在するテストが失敗しなかったことを示すだけです。

我々が自社のリメディエーションに課す制約の大半はスコープに関するものです。Gitar は壊れた CI を修正し、プッシュ前のコミットが緑であることを確認してから初めて責任を負います。2 回のフォローアップコミットの後に止まり、赤いビルドに対してずっと作業し続けることはありません。失敗が変更に関係なく、フレークテストやインフラの一時的な問題である場合は、修正パスではなくリトライパスへと進みます。なぜなら「テストの失敗を止める」ことは、能力のあるエージェントに最もさせたくない目的だからです。

その後、変更は Gitar が管理しない層を通過しなければなりません。SonarQube は独自の基準で結果を評価し、品質ゲートがマージの条件となり、チームがそのポリシーを所有します。また、変更が実装すると主張する課題と照らし合わせてチェックし、要件抽出を完了判定とは別に保持することで、チケットから静かに抜け落ちた要件が実装済みとして戻ってくることを防ぎます。

効果的な AI コードレビューは、リポジトリの慣習、依存関係、アーキテクチャ、提案された変更の目的を理解することに依存します。AI レビュアーが有用な判断を下すために必要なコンテキストは何か、また組織はシステムが進化する中でそのコンテキストを正確に保つにはどうすればよいでしょうか？

AI レビュアーは、単に差分を読むだけでなく、経験豊富なレビュアーのように推論できるだけの十分なコンテキストが必要です。具体的には、変更の目的、関連するコードパスや型情報、依存関係、テストの振る舞い、リポジトリの慣習、そしてチームが期待するアーキテクチャ上の境界です。

コンテキストはコードと共に存在し続けなければなりません。ルールやレビューガイダンスをリポジトリ内でバージョン管理し、サービスや慣習が変わったときに更新し、アーキテクチャやポリシーの所有者を明確にします。さもなければ、AI レビュアーは個別に妥当な提案を行っても、実際のシステム全体の動作と矛盾する可能性があります。

決定論的分析は一貫した監査可能な結果を生み出す一方で、大規模言語モデルベースのレビューは実行ごとに変動する可能性があります。規制が厳しいまたはセキュリティが重要な環境において、企業は AI 生成所見をどのように文書化、再現、管理すべきでしょうか？

監査トレイルには、レビュー対象の変更、AI が提示した所見、取られた決定、そして結果を検証するために使用された独立した証拠が示されるべきです。企業は AI を活用してレビューとリメディエーションを加速させつつ、強制や承認の判断は定義されたポリシーと人間の責任に基づいて行うことが重要です。

エンジニアリングリーダーは、AI コードレビューが実際にソフトウェア開発を改善しているかどうかを判断するために、どの指標を使用すべきでしょうか？レビュー時間、漏れた欠陥、誤検知率、継続的インテグレーション失敗、技術的負債、開発者の信頼、あるいは他の指標を優先すべきでしょうか？

まずは結果に焦点を当て、AI システムが生成するコメント数ではなく、プルリクエストからマージまでの時間、CI 失敗の診断に費やす時間、最初の検証で修正が通過する率、そして問題が後工程や本番に持ち越される頻度を測ります。

次に、誤検知率や除外率、再オープンされた課題、最近マージされた変更に起因するリグレッション、そして所見が実用的かどうかに関する開発者のフィードバックといった品質指標を観察します。適切な指標の組み合わせはチームによって異なりますが、重要なのは一貫した問いです：再作業やレビュー待ち時間を削減しつつ、安全で信頼性の高いソフトウェアの基準を下げていないか？

将来的に、ソフトウェア開発はエージェントがコードを生成、レビュー、テスト、修正し、決定的なガードレールの下で循環する継続的なループになると予想しますか？その環境下で、人間のソフトウェアエンジニアの責任や必要なスキルはどのように変化すると考えますか？

そのループはすでに存在しており、チームは固定された順序で採用する傾向があります—まず検出、次にリメディエーション、そして条件を書き下した上での承認、最後にマージです。誰も最後のステップに直接飛びつくことはなく、進む証拠はベンチマークではなく自社のコードベースです。マージは最も興味深いステップで、コミットスループットが上がるにつれて衝突頻度が増加し、スループットはすべてを加速させます。

価値が高まるスキルはループの外側に位置します。エージェントが文字通りあなたの説明を受け取るため、問題とその制約を正確に定義することが重要になります。また、変更を通過させるのに十分な証拠を決定することも必要で、これはかつては人の頭の中にあった習慣であり、今は自動化が適用できるポリシーとして文書化しなければなりません。残りはシステム設計です—自動化作業が触れる範囲を限定し、エージェントが制御できない何かが結果をチェックし、問題が起きたときに責任を追えるようにします。エンジニアは実装を作る時間を減らし、何が存在すべきか、そしてそれが機能する証拠は何かを決める時間を増やすでしょう。

素晴らしいインタビューをありがとうございました。詳しく知りたい読者は Sonar をご覧ください。