こんにちは！プロダクト開発部の村松です！
突然ですが皆さん、こんな悩みはないでしょうか？
「AIが実装している間、ローカル環境を自由に触れない」
「定期的にコマンド実行の承認待ちになり、他の作業に集中できない」
Claude Codeが登場して以降、git worktreeを使った並列開発が流行り、AIの待ち時間は大幅に短縮されました。しかし、依然としてローカル環境が占有され、時折承認待ちになる問題は残ります。
この問題を解消するため、私のチームではGitHub Copilot cloud agentを使い、GitHubのクラウド上で並列開発を行っています。 (※ 以後、copilotと表記します)
今回はどのようにしてcopilotを使い、並列で開発を行っているのか具体例を交えて紹介します。
具体例とする作業の説明
私のいるテーブル解体チームでは、1つのテーブルを2つに分割するようなDBのリファクタリングを行っています。
(分割している背景に関しては、下記の記事をご参照ください。)
それに伴い、まず様々な処理に散在してしまっているSQLを1つに集約するリファクタリング作業を行っています。 今回はこの具体例を交えて、どの様に並列開発を行っているのか紹介します。
Step1: テストを作成する
散在したSQLの処理を集約する前に、対象のAPIに対してテストを作成します。
コドモンでは簡単にAPIテストを作成できるテスト基盤が存在しており、使い方を .claude/skills に記載しています。
このSkillsに関してはClaude Codeはもちろん、copilotでもSkillsとして認識されます。(参考)
作成手順としては下記の流れで作成しています。
対象となるAPIを調査
まずは修正対象のAPIをClaude Codeと調査し、1つのissueに列挙していきます。
同時にテストがすでに存在するか、存在する場合はどこのディレクトリに存在するかも記載します。
sub-issueを作成する
先ほど作成したissueの情報を元に、テストを作成するためのsub-issueを作成して紐づけます。
Claude CodeのPlanモードで修正方針を決定し、テストを行うAPIの数だけsub-issueを作成します。
sub-issueには下記を記載します。
- 対象のAPI
- テスト観点
- 作成するテストのディレクトリパス
- すでにテストがある場合はどこのディレクトリにあるか
- どの画面から呼ばれているAPIか
改めて作成されたsub-issueの内容をレビューし、問題なければcopilotをアサインします。
copilotはアサインされるとsub-issueの内容を元に、PRを作成します。
簡単に流れを図にすると下記のとおりです。
作成されたPRを確認し、修正が必要な場合はPR上から @copilot メンションで追加の指示を行います。
Step2: SQLの処理を集約する
集約先のクラスを作成し、各APIごとSQLの処理を集約します。
このStepではcopilotを使わず、Claude Codeと相談しながらインターフェースを考え、集約していきます。
なぜcopilotを使った並列開発を行わないのかは、後ほど触れます。
これでStep1, 2を通して、SQLの処理を集約することができました🙌
copilotでの並列開発のメリット・デメリット
次にgit worktreeと比べたメリット・デメリットを紹介します。
copilotで並列開発を行うメリットは下記のとおりです。
プロンプトがissueとして残る
AIが作るPRがイマイチな場合、様々な要因が考えられます。
- プロンプトの指示が曖昧
- skillsの情報が足りない
- ニッチなライブラリでドキュメントが充実していない
仮にプロンプトが残っている場合、原因の目星がつきやすく改善しやすくなります。
PR作成中はローカル環境は占有されない
copilotで並列開発を行う場合、クラウド上で行われます。
そのためローカル環境のリソースに依存せず、並列数を上げることができます。
並列開発を行っている間、PCが重くなることもありません。
コマンド実行等の承認待ちにならない
ユーザーの承認待ちで開発が止まることはありません。
私のローカル環境で並列開発を行う場合、承認待ちで開発が止まることが頻繁にあります。
クラウド環境で開発することで、安全にこの問題を解決できます。
一方、デメリットは下記のとおりです。
クラウド上での環境構築の設定が必要
修正後の動作確認など、コードの修正だけでなく環境構築が必要な作業が発生する場合、クラウド上での環境構築の設定が必要です。(参考)
設定しなくてもPRは作成できますが、環境構築されたローカルに比べるとコードの質は落ちると思われます。
並列開発するうえで注意すべき点
今回紹介した並列開発を効率的に行う上で、注意すべき点がいくつかあります。
ここでは私がcopilotを使った並列開発で失敗した経験を元に、意識すべき点を紹介します。
issueのレビューは手厚くする
issueのレビューを怠ると意図していないPRが大量に作られてしまうため、かえって非効率になります。
「意図した通りの内容か？」、「具体的に記載されているか？」を意識して手厚くissueのレビューを行うことで、作成されたPRを修正する手間が大幅に削減されます。
完成形が見えていないものは並列開発しない
今回、紹介した具体例でいうとStep2にあたります。
SQLの処理を集約する際、どのようなインターフェイスに集約すべきか想像するのは困難です。
完成形が見えていないものはcopilotに指示できないため、Claude Codeと相談しながら実装します。
一方、Step1は完成形がある程度明確なため並列でテストを作成できます。
テスト観点は既存コードや仕様から判別でき、動作の確からしさはテストの実行で確認できます。
CI環境を安定させる
並列開発を行うとPRが大量に作成されるため、ボトルネックがレビューに移ります。
「正しく動作しているか」はテストで、「最低限のコードの品質」は静的解析等でCIでチェックできるとレビューコストを下げることができます。
仮にフレイキーテストが存在するとレビューコストを下げることができないため、PRが溜まりやすくなります。
安定的に動作するCI環境を維持しましょう。
おわりに
今回、copilotを活用することでAI待ち時間を短縮する事ができました。
個人的にはgit worktreeでローカルで並列で開発すると別のタスクになかなか集中できなく、「承認待ちになっていないか」が気になり時折確認してしまっていました。
copilotに依頼するようになってからはあまり意識せず、別タスクに集中できるようになったのが嬉しいポイントです。
AIの待ち時間で悩んだ際は、今回紹介したようなアプローチが取れそうかぜひ検討してみてはいかかでしょうか。
