はじめに
はじめましての人ははじめまして、こんにちは！フロントエンドエンジニアのがっちゃん（ @gatchan0807 ）です！
今回は、GitHub Copilot Chatを使った開発の中で実際に試してみたことと、そこから得られた気づきについて共有していきたいと思います。 （この作業を実施したのが2025年1月中頃の話なので、GitHub Copilot Agentモードが出る前の話である点だけご了承ください。2025年4月の今ならAgentモードでサクサク作らせていたと思いますし、直近はAgentモードで作ってPRを出したりしています🙏）
やってみたこと
今回やってみたことはシンプルで、
- MarkdownでAPI仕様書をリポジトリ内に置いてみた
- Mock API実装をGitHub Copilot Chatに依頼してみた
- レイヤー分割を意識したGitHub Copilot Chatによるコーディングを実施してみた
という3つになります！
シンプル && ステップ分割できる作業においてはGitHub Copilot Chatを使うことで、一定の開発効率向上できてるな！というのを感じたので今回紹介しようと思った次第です🙋
もし今回の記事を読んでいただき、参考にできそうなポイントがあればぜひ真似してみてください！また、こういう使い方をするとよりよく使えるよ！というポイントなどあれば X（旧Twitter）などで教えていただけると嬉しいです！
では、具体的にどんなことをやってみたのか見ていってください！
1. MarkdownでAPI仕様書をリポジトリ内に置いてみた
今回は自分が担当しているPAY.JP YELL BANK関連の新機能の開発時に使ってみました。
PAY.JP YELL BANK自体は、PAY.JPの加盟店に向けて提供している将来債権ファクタリングというスキームの資金調達サービスです。
今回はこれに関連する金融サービスの追加機能のお話で、複数人での開発であったため、認識揃えのためにAPI仕様書を書きつつ開発していました。
APIの仕様（スキーマ）は適宜メンバー間で相談し、以下のような形でFigJamとNotion上にAPI Design Documentとしてまとめていました。
（チームではADRというものを活用しています！めっちゃいいんです！！）
もう少しだけ今回の作業の背景を紹介すると、私が所属しているBASE BANKチーム（YELL BANKやPAY.JP YELL BANKなどのサービスを担当しているチーム）では、以前よりADR（Architecture Decision Records）という形で仕様整理も含めた設計時の意思決定をドキュメントに起こす文化があります。
このADRをまとめる際に設計の抜け漏れの確認とメンバー間での認識揃えができるだけでなく、あとから当時の意思決定の理由や「検討したが選択しなかったこと」や「仕様変更がある前の前提知識」などを知ることができるので現在のシステムに対する解像度が一段上がりやすくなります。
ADRを書くことによるメリットや背景などは本題ではないので今回は省きますが、こちらのページ（ https://adr.github.io/ ）が端的でわかりやすいので、合わせて参照いただけるとよりイメージしていただけるかと思いますのでよければご覧ください。
そして、今回はこのAPI Design DocumentをNotionから出力してリポジトリ内に置く。という作業を行いました。
ちょっとした工夫として、Markdownファイルは リポジトリ内に tools/.copilot/ という名前で「開発に使えるAI Copilot（副操縦士）用のファイル置き場」ぐらいの粒度の専用ディレクトリを作成して、 .gitignore でGitの管理下からは外す ようにしています。
これは、2025年1月当時の状況として 「 .cursorrules などが話題にはなり出してはいるけど、何がどこまで覇権を握るかもわからないし、PJ全体として管理する前にそもそも個人ごとに使い分けが起こるだろうし、一旦気軽な場所が必要だ…」と思っていたので抽象化して場所を作っておいたという流れがあったりします。
このディレクトリがあるおかげで、VSCode経由のGitHub Copilot Chatであれば必要に応じてファイル指定を行うこともできるし、プロンプトに「このディレクトリ内から検索して…」などの追加指示を行えるので、一定の精度向上が見られました。（あくまで個人の感覚値）
今後は、README.mdのような人間向けに作りつつもAI Agent側の参考にもなるリポジトリ内ドキュメントを整えつつ、 .cursorrules などのようなAI Copilot / AI Agentに最適化されたルール定義ファイルも駆使していければなと考えています🙋
2. Mock API実装をGitHub Copilot Chatに依頼してみた
今回の開発では、PAY.JP側のエンジニアと協力してAPIスキーマを決めていきました。
APIスキーマは両者の責任分界点となるため、開発環境で先行してMock APIとして実装することで、PAY.JP側での動作確認とAPI利用に関するフィードバックを受けやすくする狙いがありました。
この実装にあたり、「Mock APIなら生成AIで効率的に作れるかも…！」と考え、GitHub Copilot Chatを活用して開発を進めることにしました。
具体的な流れとしてはこんな感じです。
tools/.copilot/ai-docsというディレクトリにAPI Design DocumentをMarkdownで配置する- そのファイルと、その中の特定の見出しを指して「このAPIを作りたいので、まずはMock処理としてHandler層でレスポンスするようにして」のように指定して、Mock APIの実装を依頼する ⇒ （レスポンスとしては良いが、他の既存のAPIの書き方とかなり異なっていて、必要なプライベートメソッドが実装されていなかったりしてコンパイルも通らないレベルで失敗）
- 同じ層の別のAPIのファイルを指定して「このHandlerを参考に書いて」と指示を出す ⇒ （微妙に書き方が違うものの、コンパイルは通るようになったので一旦許容）
- 3で作ったAPIのHandler層を指定してテストコードの作成を依頼する ⇒ (これもコンパイルが通らないレベルで失敗)
- 同じ層の別のテストファイルも合わせて指定して「このテストを参考に書いて」と指示を出す ⇒（無事テストが通り、Handler層のテストが実行できるようになる）
- Handler層のコード・ドキュメント・既存のテストを同時に指定し、テストケースを増やす必要があるか検討し、追加してもらう
- 3, 5の実装をそれぞれ同じ層の既存ファイルを複数同時に指定し、「これらのファイルと書き方が違っていない？もし違うなら合わせて欲しい」と指示する ⇒ （素直にリファクタリングを実行してくれる）
- HTTP Clientファイルを作ってAPIの動作が意図通りか確認する
- テストとコンパイルと動作確認ができたので、最後に人間の目で見て全体のコードに違和感がないか確認し、適宜修正を依頼する
PAY.JP YELL BANKのコードはクリーンアーキテクチャを参考にしたレイヤードアーキテクチャで構成されています。 なので各処理レイヤーのインプット / アウトプットと責務を意識して実装依頼を行うことで、成果物の品質を高めることができました。これに関しては、次の項で詳しく紹介します。
補足）キャプチャ込みでやり取りを紹介
各ステップでどのような指示とやり取りをしていたか、実際のキャプチャも含めて軽くご紹介します。
2のステップでは、以下のようにざっくばらんな指示を出してみました。
すると、コンパイルエラーになる形で作成をしてきたので、3のステップでは同じレイヤーのコードと比較しつつ、参考にしながら書いてもらう指示を行いました。
4のステップでは、テストコードの作成を依頼していて、この時に初回の指示のようにAPI Design Documentのファイルと見出しを指定してテストコードを書いてもらいました（が、いまいちコンパイル通らない形での実装をしてきたので、ステップ3と同じように同レイヤーのテストコードと比較しながら修正してもらいました）
また、APIレスポンスのモックファイルの一括作成も同時に依頼して、パターンの洗い出しとJSONファイルの作成を代行してもらいました。
その後は、以下の画像のように細かいリファクタリングを指示しながら作業を進めていきました
3. レイヤー分割を意識したGitHub Copilot Chatによるコーディングを実施してみた
前の項でも軽く触れましたが、PAY.JP YELL BANKのAPI処理の実装はレイヤードアーキテクチャの構成になっています。 そのため、Usecase層、Handler層、Model層、データアクセス層など、それぞれの層に分けていて層ごとにテストを書いています。
このレイヤー分割を意識して、GitHub Copilot Chatに実装依頼を行うことで、以下のようなメリットがありました。
- GitHub Copilot Chatへの指示・提供するファイルのサイズが小さくなるため、必要なコンテキストウィンドウが小さくなり、指示を忘れることが少なくなる
- 取り扱うファイル数やコードの量が増えると指示を忘れて意図しないコードを出力してくることがよく発生してしまっていたのでGood 🙌
- GitHub Copilot が出力したテストコードを見るだけで人間側が意図を理解しやすくなる
- 最終的には人間のレビューが必要なので、まず In / Out を確認するだけで処理の振る舞いが理解できるテストコードは重要です 👀
- エンドポイントの指定 × レイヤーの指定という形で組み合わせるので、小さい単位で切れ目を作れてコミットサイズ・PRサイズを小さく管理しやすい
- 細かい単位でコミット・PRを作ることで他のメンバーのレビューを受ける際にもレビューしやすくなるので、GitHub Copilot Chatを使う場合でも意識しておくと良さそうだなと思いました🙋（AIに書いてもらうとかんたんに作れてしまう分、長大なPRになりがち）
学んだこと
実際にこのような流れで開発をしてみて、GitHub Copilot Chatをはじめとした、生成AIコーディングツールを使う上での気づきやコツみたいなものを掴むことができました。
これらをまとめてご紹介し、この記事を読んでくださった皆さまに何か得るものがあれば嬉しいなと思います🙋
1. リポジトリ内に開発に必要な情報をできる限り置く・置けるようにする
コードには開発情報や仕様が含まれてはいますが、実際の開発時に必要な情報はドキュメント、デザイン、API仕様書など様々な場所に分散しているのではないでしょうか？
今回の作業を行なっている中で、GitHub Copilot Chatを使う場合にもそれらの情報に人間が開発する時と同じようにアクセスできるようにしておくことで精度の向上が見込めそうだ…👀 というのを肌身に感じました。
VSCodeのGitHub Copilot Chatでは、ファイル検索や参照が容易なため、開発に必要な情報はリポジトリ内にファイルとして置いておく方が良いなと思っています。
この流れは、GitHub Copilot Chatに限らず、CursorやClineをはじめとしたAI Agentを使う場合でも同じような流れですし、 .cursorrules のようなファイルを作るのが推奨されているのとかは特に顕著ですね。
また、このようなプロジェクト全体で共通化しておくファイルを置くのとは別に、今回実施した tools/.copilot/ のようなGit管理しない個人用のファイル置き場を作っておくのも、自分用に適宜カスタマイズしてAIエディタの開発支援を行えて効率的な開発につながるなと思いました。
2. 人間・AIともに認知負荷を下げる
AIの性能面では、タスクの精度を高めるために共通ルールなどのコンテキストを小さくする方が望ましく、認知負荷を下げることで精度が向上します。
また、生成AIのコードは人間がレビューして説明責任を持つ必要があるため、認知負荷を下げることでレビュー効率が向上します。
直近はVibe Coding（バイブコーディング）というものが話題になっているものの、チームで開発を行う場合は生成AIで書いたコードに対して、人間側が説明責任を持てることが求められます。
そのため、AIの成果物をレビューする際は人間の認知負荷を下げることが重要です。これは自分とチームメンバー双方のために意識的に工夫すべき点です。
ここに関しては X（旧Twitter）でも日々言われている「人間がボトルネックだ…」という話を今回の作業をしている中でひしひし感じていたので、今後より良い方法を模索しつつ、より良いツールやワークフローが生まれてくることに期待したいなと思いました🙋
3. テストコードや動作確認ツールを活用する
テストコードとHTTP Clientの活用で、AIが生成したコードの動作確認を効率的に行えます。これは生成AI特有の話ではなく、一般的な開発プラクティスですが、特に重要です。
これまでの開発者の努力によって市場として成熟している各種テストツールを活用することで、エラーや意図しない挙動の検出と修正が容易になります。この自動化された高速なフィードバックループが、プログラミングと生成AIの相性の良さを支えていると私は考えています。
これがない場合、お手々でのビルドと実行、エラー時のAIへの再確認という遅いサイクルを繰り返すことになってしまいますからね…🤔
このように、今回の検証によって、迅速なテストとフィードバックループは生成AI活用の重要な要素だと感じました。 そのため、動作確認ツールとテストコード環境の整備が、Webアプリ開発における生成AI活用を推進する第一歩となるのかなと感じています🙋
おわりに
以上が、GitHub Copilot Chatを使った開発の中で実際に試してみたことと、そこから得られた気づきについてのまとめでした！
GitHub Copilot以外にも、CursorやClineなどのAIエディタやAIエージェントが出てきている中で、これらを使うことで開発効率が上がるのか？という点については、今後も引き続き検証していきたいなと思っていますし、これを調査してうまく使えるようになることがこれからのエンジニアキャリアを作る上でも重要な要素になってくるのかなぁと思っているので引き続き頑張っていきたいと思います！
もし、こちらの記事を読んでAIを使った開発に興味が出てきた方がいらっしゃればぜひお声がけください！ざっくばらんにお話ししましょう🙋
カジュアル面談プラットフォームのPittaやX（旧Twitter）などでお話しできる機会があれば嬉しいです！
また、PAY.JP YELL BANKを開発しているBASE BANKチームではエンジニアを募集していますので、興味がある方はぜひこちらもご覧ください！ 🙌
最後まで読んでいただき、ありがとうございました！
