こんにちは!
広告事業本部でユニットマネージャーをしている建人です!
最近はAIを活用した開発が当たり前になりつつありますが、「とりあえずAIを導入してみたけど、そこからどう進めればいいの?」と悩んでいるチームも多いのではないでしょうか。
この記事では、実際に自分のチームでAIを活用した開発を円滑に進めるために取り組んだ環境整備についてお話しします。
AI活用のはじまりと課題の発見
GitHub Copilot の自動レビューを導入
元々チームではGitHub Copilot(以下、Copilot)を開発で利用していましたが、レビューでの活用はしていませんでした。
開発の効率化だけではなく、レビューの負荷を軽減するためにAIの導入を検討しました。
Copilotにプルリクエスト(以下、PR)を自動でレビューさせる設定は簡単なのでとりあえずリポジトリへの設定を組み込みました。
▶ 設定方法(クリックで展開)
- 対象リポジトリの「Setting」を開く
- 「Rules」の「Rulesets」から「New branch ruleset」を選択
- 「Target branches」に「Default」を設定する
- 「Automatically request Copilot code review」にチェックを入れる
この設定だけで、特定のリポジトリに対するPRに対して自動でCopilotのレビューがアサインされるようになります。
ただ、この設定だけではレビューとしてはあまり役に立ちませんでした。 LinterやFormatterを無視した指摘や変更差分しか見ていない的外れな指摘ばかりが返ってくる状態でした。
.github/copilot-instructions.md を作成するとレビューへの指示を記載できるので、最低限の設定をしています。
▶ 設定例(クリックで展開)
## 共通設定 - 日本語で回答してください - 簡潔で分かりやすい説明を心がけてください - ベストプラクティスの具体例を提示してください - スケーラビリティとパフォーマンスを重点的にチェックしてください ## コードレビュー専用指示 ### レビューの基本方針 以下のプレフィックスを使用してレビューコメントを分類してください: - [Must] - 必須修正項目(セキュリティ、バグ、重大な設計問題) - [Should] - 推奨修正項目(パフォーマンス、可読性の大幅改善) - [Nits] - 軽微な指摘(コードスタイル、タイポ等) - [Good] - 良い点の指摘(ベストプラクティス、優れた設計) ### 重点チェック項目 1. **セキュリティ**: SQLインジェクション、XSS、認証・認可の不備 2. **パフォーマンス**: N+1問題、不要なループ、メモリリーク 3. **可読性**: 変数名、関数名、コメントの適切性 4. **保守性**: DRY原則、SOLID原則の遵守 5. **テスト**: テストケースの網羅性、エッジケースの考慮 6. **言語固有のベストプラクティス**: 各言語の推奨パターンに準拠しているか、非推奨・廃止予定のAPIや構文を使用していないかチェック
指示書を入れることでレビューの方向性をある程度コントロールできるようになりましたが、まだ改善の余地があるので設定を充実させていきたいです。
開発主体がAIへ
当初の目的は「開発主体はあくまで人間」で、「AIはサポート」といった面がかなり大きかったです。
しかし、AIが進化していくにつれて「開発の主体はAI」で、「人間はサポート」になり始めました。
Copilot や Claude Code を利用して実装してもらい、人間がレビューと手直しをするといった開発に移り始めたのです。
AIの進化に全然ついていけていないのでは?という危機感からメンバーが各々でAI活用を進めており、チーム内での知見共有がされていませんでした。
そのため、AI活用の共有会を開催し、画面共有しながら開発して「こういう使い方をすると便利だった」「これはうまくいかなかった」といった知見を共有しています。
質疑応答の時間も設けて、メンバーそれぞれのAI活用レベルを底上げしていきました。
そこからAIを活用していく上での問題点を洗い出して環境整備を進めていきました。
JiraからGitHub Projectsへの移行
移行の動機
Jiraを使っていた頃は、AIに実装を依頼する場合タスクの内容を都度コピペする手間がかかっていました。
開発中にAIへタスクの内容を渡したい場面は頻繁にあるので、この手間は地味なストレスになります。
MCP(Model Context Protocol)を利用すればその限りではないですが、チーム内で特に反対の声はなく、Jiraにこだわる理由もなかったので移行を選択しました。
移行してよかった点
GitHub Projectsに移行したことで、AIが gh コマンドを使ってIssueの内容をそのまま読み込めるようになりました。
Issue番号さえ渡せば実装まで行ってくれますし、タスクの整理や作成もAIに相談しながら進めることができます。
開発体験をかなり上げることができたと思います。
また、DevinやCopilot、Claude Code など、どのAIツールを使用したとしても変わらない体験で利用できるのがいいポイントです。
Jiraと比べて課題に感じている点
正直に言うと、GitHub Projectsに不満がないわけではありません。
チャート機能などの機能不足感
Jiraが標準で持っているような分析機能(バーンダウンチャートなど)が充実していないため他の方法を考える必要があります。
UIの整備
GitHub Projectsにはカスタマイズ性はあるものの、Jiraは最初から使いやすいUIが揃っています。
運用方法さえ確立できればそこまで問題ではありませんが、最初は痒いところに手が届かないといった感じがありました。
とはいえ、AIとの相性でだいぶアドバンテージがあるので、総合的にはGitHub Projectsに移行して良かったと感じています。
ドキュメント整備の問題点と解決方法
コーディングルールの管理方法と問題点
コーディングルールなどの開発に直結するドキュメントは開発リポジトリの中に入れて管理をしています。
これによって開発時に参照しやすくしています。
しかし、それらのコーディングルールは放っておくとすぐに古くなり、参照しても古いやり方が広まるだけになってしまいます。
月イチでルール見直し会を開いていますが、全てを更新できるわけではなく管理が行き届いていない状態になってしまいます。
また、コーディングルールには記載されていない暗黙の了解のようなルールも存在しています。これらを管理する必要がありますが、移り変わりも早いのでなかなかできていないのが現状です。
ドキュメント化よりも参照先を用意
上記の理由もありますが、ドキュメント化するにあたって「どこまでドキュメント化するべきなのか?」「AIも人間も読みやすいドキュメントとはどういうものなのか?」など考えるべきことはたくさんあります。
そこで、考えたのが 「常に最新の参照用ディレクトリを用意する」 です。
「お手本」を用意することで、AIも人間もそこさえ参照すれば一定のルールに沿った実装を行えるようになります。
参照用にはフロントエンドの1ページとそこで利用するバックエンドのコードを用意しています。
参照用のディレクトリ自体も実際に公開しているコードなのでリファクタリングが必要な箇所を修正するだけで管理できます。
将来的にはドキュメント化も必要ですし、AIがサンプルを無視して実装しやすい箇所は明確化する必要はありますが、実装の正確さはかなり上がるのでアプローチとしてはよかったと思います。
今後の取り組み
整備自体は現在も継続中で、直近では以下のようなことに取り組んでいます。
ディレクトリ構成の見直し
AIがどこかを参照して実装する際に、やりやすい形のディレクトリ構成があるのでは?と考えています。
フロントエンドのディレクトリ構成では元々コロケーション(関連するファイルを近くに配置する考え方)の意識はありました。
しかし、一部のできていなかったテスト用のモックデータや関連する細かい設定ファイルを近くに置くようにしました。
これによりAIはプロジェクト全体から特定のファイルを探すのではなく、近くのファイルを参照すれば良くなり効率が上がると考えています。
どこまで効果があるのかはまだ不明ですが、ディレクトリ構成も綺麗になるのでとりあえずやってみています。
コーディングルール以外のドキュメント整備
コーディングルールに関しては上の項目で記載した通り、開発リポジトリの中で管理していますが、それ以外のドキュメントに関しては Confluence を利用しています。
Confluenceに関してもMCPを利用すればAIに読み込ませたり活用できると思います。
しかし、プレーンテキスト(Markdownなど)で管理した方がAIに読み込ませたり、書かせたりがより楽に行えるようになるのでは?と考えています。
GitHubで管理するなど移行先は現在検討中です。
レビューでのAI活用の推進
AIの活用によりPR数が多くなりレビュー負荷が上がっています。
PRを出す前にローカルでAIによるレビューを必須で行うようにチームルールとして決めました。
しかし、それだけでは全てを解決できないためPRで行っている Copilot レビューの精度を上げる必要があると考えています。
レビューで使用している指示書を充実するか、Copilot以外の使用を検討していきたいと考えています。
まとめ
AI開発が進むにつれて様々な問題に直面すると思います。
それらに対してどのようにアプローチするのか方法は沢山ありますが、最初から完璧な環境が整うことはないと思います。
「とりあえずやってみる」が大切だと考えているため、一旦やり方を見直して試行錯誤してみましょう。
ダメだった場合はやり方を戻すのも選択肢として持っておくと良いと思います。
ただ、AIツールの変化は激しいので特定のツールに依存する形になり、ベンダーロックインがかからないように気をつけたいですね。
AIの成長とともに環境もアップデートしていきましょう!
では、また!!