「コードを読むだけ」のAIレビューを超えて——Greptileが実行層を組み込んだ「TREX」の設計思想

6月17日、AIコードレビューサービスを提供するGreptileが「Building TREX: Code Execution and Artifact Generation for AI Code Review」と題した記事を公開した。コードレビューのパイプラインに実行層を組み込んだシステム「TREX」の設計と実装について、その背景にある問題意識から具体的なアーキテクチャの判断まで詳しく解説されている。

GitHubのPRに対してAIがコメントを付けるツールは、ここ数年で急速に普及した。CodeRabbitやGitHub Copilotをはじめ、多くのサービスがLLMを使ってdiffを読み、潜在的な問題を指摘する。Greptile自身もその一つだ。しかしこうしたツールには共通の限界がある——コードを「読む」だけで、「動かす」ことはしない。特定の状態遷移を経て初めて発現するロジックエラー、ページロード後にだけ起きるUI崩れ、実際のリクエストがないと再現しない競合状態——こうした問題はdiffをどれだけ丁寧に読んでも見逃す。

TREX（Test, Run, Executeの略）は、その限界への回答として設計された。Greptileのソフトウェアエンジニアであるshlok氏が主導して構築したもので、AIレビューエージェントが実際にコードを実行し、その結果をスクリーンショットやログといった「証拠」とともに提示する仕組みだ。現在はGreptileのサービスに統合されており、PRレビューの一環として動作する。

構築で最も難しかったのは、エージェントをどう組み合わせるかという問題だった。当初TREXはGreptileとは独立した単体エージェントとして開発された。テストを生成・実行することでバグが浮かび上がると期待していたが、機能しなかった。テスト生成とバグ発見は別の活動であり、独立したエージェントが書いたテストはユーザーの意図とずれた。また、2つのエージェントがコードベースの同じ箇所を別々に探索するという無駄も発生した。

「では1つに統合すれば」と試みたが、今度は逆の問題が起きた。サービスの起動、スクリーンショットの取得、テストの実行——これらを1つのエージェントに担わせると、コンテキストウィンドウが溢れた。最終的な解決策はオーケストレーター＋サブエージェント構成だ。メインのGreptileレビューエージェントがdiffを読み、調査すべき問題を特定する。問題ごとに専用のTREXサブエージェントを起動して並列実行し、各サブエージェントはオーケストレーターが既に発見した知識を引き継ぐため、ゼロから探索し直さない。認証ゲートの裏にあるUIフィーチャーのテストを例にとると、サブエージェントが環境のセットアップ、認証、フィーチャーフラグの状態設定を自律的に処理し、レンダリング結果のスクリーンショットを返してくる。

初期バージョンでは、TREXの出力は箇条書きのテキストだった。「チェックアウトフローをテストし、失敗を発見」——これでは役に立たない。失敗したのはセットアップか、アサーションか、環境の問題か、判断できない。さらに初期のエージェントはハルシネーションを起こし、実際にはやっていないことをやったと主張することがあった。この問題への回答がマルチモーダルなアーティファクトセットだ。各TREXの発見に対して、スクリーンショット、ログ、APIトレース、実行スクリプトが添付される。特にインパクトが大きかったのが動画アーティファクトで、アニメーションの変更をプッシュするとTREXがその再生動画をキャプチャする。開発者はローカル環境を立ち上げることなく、アニメーションの実際の動作を確認できる。記事ではこの役割を「教師が生徒に途中式を求める理由」に例えている。エージェントも同様で、結論に至るまでの各ステップが記録されていれば、どのステップで問題が起きたかを特定できる。アーティファクトはレビューコメントの信頼性を担保する仕組みでもある。

TREXのレビューはすべて使い捨てのサンドボックス環境で実行される。レビューごとに独立した計算インスタンスが起動し、実行後に破棄される。モックに対するユニットテストではなく、実際の依存関係を持つ本物のサービスを動かす設計だ。多くのバグはエンドツーエンドでしか現れないからだ。毎回ゼロから環境構築すると遅すぎるため、再利用可能なベースイメージとリポジトリ単位のスナップショットを活用する。ただし各レビューでPRの正確なコミットを取得し、実行前にクレデンシャルをローテートする。キャッシュが少なすぎると遅く、多すぎると古い状態が混入する——その均衡を記事では「温かく、かつ信頼できる」と表現している。

モデルの選択についてはモデル非依存のハーネスを採用し、フロンティアモデル間をホットスワップできる設計にした。メインエージェントとサブエージェントで異なるプロバイダーを使うことも可能だ。評価指標としてリコール（実際のバグをどれだけ検出できるか）と精度（同一PRを2回レビューしたときに同じ問題を検出できるか）を測定しており、レイテンシは意図的に優先度を下げている——開発者は少し待ってでも正確な結果を求めるという判断だ。TREXの差別化要因はモデルそのものではなく、コードベースインデックス、オーケストレーション、アーティファクト生成、評価フレームワークといった周辺インフラにある。モデルの性能は継続的に向上する。Greptileはそれを動かすハーネスを構築することに注力している——記事はそう締めくくっている。

詳細はBuilding TREX: Code Execution and Artifact Generation for AI Code Reviewを参照していただきたい。