【ITニュース解説】ひとつのMCPセッションで複数PRを並列レビューする 〜code-review-graphのグラフDBをGit worktreeごとに使い分ける〜

システム開発では、多くのエンジニアがチームで協力して一つのソフトウェアを作り上げる。このプロセスで欠かせないのが、Pull Request（プルリクエスト、通称PR）とそれに伴うレビュー作業である。PRとは、自分が書いたコードの変更を、他の開発者に「これを見てください、問題なければ本流のコードに組み込みましょう」と提案する仕組みだ。提案されたコードは、レビュー担当者によって内容が正当か、バグがないか、既存の機能に悪影響を与えないかなどが細かくチェックされる。このレビューを通じてコードの品質が保たれ、チーム全体の知識共有も進むため、開発において非常に重要な工程と言える。

しかし、エンジニアは複数の開発タスクを同時に抱え、それぞれのPRレビューも並行して進めなければならない場面が頻繁に発生する。この記事では、これをMulti Context Programming (MCP) セッションと呼ぶ。複数のPRを同時に、かつ効率的にレビューすることは、開発の速度と品質を両立させる上で大きな課題となる。

複数のPRをレビューする場合、どのような問題が発生しやすいのだろうか。最も一般的な方法は、レビュー対象のPRを一つずつ確認し、そのレビューが終わってから次のPRに着手することである。この方法では、前のPRのレビューが完了するまで次の作業に進めず、全体の時間が長くかかってしまう。また、別のPRをレビューするために、作業中のブランチ（コードの変更履歴を記録する単位）を切り替えたり、場合によっては開発環境を再構築したりする手間が発生し、これが非常に煩雑だ。複数の開発環境を立ち上げることで、コンピュータのディスク容量やメモリなどのリソースを大量に消費してしまうこともある。

こうした課題を解決するための一つの強力なツールとして、Git worktree（ワークツリー）がある。Gitはソフトウェア開発で広く使われているバージョン管理システムで、worktreeはその便利な機能の一つである。通常、一つのGitリポジトリ（コードの保管場所）には一つの作業ディレクトリ（実際にコードを編集するフォルダ）が対応する。しかし、worktreeを使うと、一つのGitリポジトリから複数の作業ディレクトリを同時に作成できる。これにより、同じリポジトリ内の異なるブランチを、それぞれ独立したフォルダで開いて作業できるようになる。例えば、PR-Aのレビューを一つのworktreeで行いながら、別のworktreeでPR-Bのレビューを進める、といったことが可能になるのだ。複数のリポジトリをクローン（複製）するのと違い、リポジトリの履歴データなどは共有されるため、ディスク容量の節約にもつながる。

このworktreeは非常に便利だが、筆者のチームでは、PRレビューをさらに効率化するために「code-review-graph」という独自のCLI（コマンドラインインターフェース）ツールを使用している。このツールは、GitHub Enterprise Server（企業向けのGitHub）からPRの情報を取得し、PR同士の依存関係（例：このPRはあのPRの変更に依存している、など）をグラフとして視覚的に表示する。これにより、複雑に絡み合うPRの関係性を一目で把握でき、レビューの順番を決めたり、影響範囲を理解したりするのに役立つ。code-review-graphは、取得したPR情報をローカル環境にグラフデータベース（Neo4j Embedded）として保存して管理している。グラフデータベースとは、データを「ノード（点）」と「エッジ（線）」で表現し、データ間の関係性に着目して効率的に処理するデータベースの一種である。

しかし、worktreeとcode-review-graphを組み合わせて使う際に、予期せぬ問題が発生した。code-review-graphは、通常、Gitリポジトリのルートディレクトリにある固定のパスにデータベースファイルを生成する設計になっていた。このため、複数のworktreeを作成しても、それらすべてのworktreeが同じデータベースファイルを共有してしまう事態になったのだ。たとえば、worktree AでPR-100のレビューを終え、その状態をデータベースに記録したとする。しかし、worktree Bで別のPRをレビューしようとすると、BもAと同じデータベースを参照してしまうため、worktree Aで行ったレビューの履歴やステータスがBにも反映されてしまう。これでは、worktreeごとに独立したレビュー作業を進めることができない。せっかくworktreeで独立した作業環境を用意しても、データベースが共有されてしまうために、レビューの管理が混乱してしまうのである。

この問題を解決するため、筆者はcode-review-graphのデータベースパスの指定方法を変更した。具体的には、データベースファイルを格納するディレクトリを、各worktreeのルートディレクトリを基準とした相対パス（例えば、./.code-review-graph/dbのようなパス）に設定するように変更したのだ。これにより、それぞれのworktreeは、自身の作業ディレクトリ内に独立したデータベースを持つことができるようになった。

この変更によって、それぞれのworktree内でcode-review-graph updateコマンドを実行すると、そのworktree専用のグラフデータベースが更新・管理されるようになった。結果として、エンジニアはworktree AでPR-100のレビュー作業を、worktree BでPR-200のレビュー作業を、それぞれ独立したデータベース情報に基づいて、完全に並行して進められるようになったのだ。ブランチの切り替えによる中断や、環境再構築の手間は一切発生しない。また、code-review-graphが提供するPRの依存関係を可視化する機能も、それぞれのworktreeで独立して活用できる。

今回の工夫は、既存の便利なツールであるGit worktreeと、独自のレビュー支援ツールcode-review-graphを組み合わせる際に生じた小さな、しかし実用上大きな課題を、コードの修正によって解決した事例である。システムエンジニアにとって、日々の開発作業をいかに効率化するかは永遠のテーマである。既存のツールをそのまま使うだけでなく、自分の環境やニーズに合わせてカスタマイズしたり、ツール間の連携で生じる課題を解決したりする能力は、非常に重要だ。このような小さな改善の積み重ねが、チーム全体の生産性向上に貢献し、より良いソフトウェア開発へとつながっていくのである。