GitHub Copilot Appsを使ってみた。非エンジニアでもPR作成からデプロイまでできた話
はじめに
最近、GitHub Copilot Appsを使う機会がありました。
最初は正直、
- GitHubが苦手
- ブランチって何？
- PR（Pull Request）って何？
- Create PRを押したら終わりだと思っていた
という状態でした。
そんな私でも、GitHub Copilot Appsと一緒に開発を進めることで、
- ソースコード調査
- 改善案作成
- 実装
- Build確認
- Git操作
- PR作成
- デプロイ確認
まで進めることができました。
この記事は使い方の説明ではなく、
実際に私がどう使ったのか
をできるだけわかりやすくまとめた体験談です。
GitHub Copilot Appsって何？
最初は
コードを補完してくれるもの
だと思っていました。
でも実際には違いました。
私が使ってみた感覚では、
コード補完ツール
というより
AI開発メンバー
でした。
例えば、
- プロジェクト全体の調査
- ソースコード解析
- 実装箇所特定
- コード修正
- Build確認
- Git操作
- PR作成
まで手伝ってくれます。
最初にやったこと
多くの人は
この機能を作って
と言いたくなると思います。
でも私は違いました。
まず最初に
現在のプロジェクトを分析してください
と依頼しました。
なぜ分析から始めたのか
理由は簡単です。
自分では
ちゃんとできている
と思っていても、
実際は
改善ポイントがある
ことが多いからです。
まずは現状を知りたかったのです。
分析で分かったこと
GitHub Copilot Appsは
- 現在の機能
- データの流れ
- 強み
- 弱み
を整理してくれました。
そして、
私が気付いていなかった問題を指摘してくれました。
次にやったこと
分析結果を見て、
今度は
その機能はどこで実装されていますか？
どこでこのデータを使っていますか？
と調査を依頼しました。
GitHub Copilot Appsが得意だったこと
特に便利だったのはこれです。
探して
です。
例えば、
この処理はどこにありますか？
このデータはどこから来ていますか？
この機能はどの画面で使われていますか？
など。
人間が探すと大変なことを短時間で調べてくれました。
次に改善方針を決める
ここはAI任せにしませんでした。
最終的に決めるのは自分です。
私は
新しい機能を増やす
ではなく
今ある機能をもっと伝わりやすくする
ことを選びました。
GitHub Copilot Appsへの指示
ここで重要なのが指示です。
私はいきなり
実装してください
とは言いませんでした。
まず
変更対象ファイルを提示してください
と依頼しました。
これが本当におすすめ
いきなり編集されると怖いです。
でも
どこを変更するのか
が先に分かると安心できます。
私は毎回この方法にしています。
実装
変更箇所を確認した後、
初めて
実装してください
と指示しました。
GitHub Copilot Appsは
- データ修正
- UI修正
- 画面遷移修正
などを実装してくれました。
Build確認もお願いする
実はここが大事でした。
私は最初、
実装完了
↓
終わり
だと思っていました。
でも実際は違います。
Buildまでがセット
私は毎回こう依頼します。
実装後は
1. TypeScript確認
2. Build確認
3. エラー修正
まで実施してください
実際にエラーも出た
実装後、
TypeScriptのエラーが発生しました。
でもGitHub Copilot Appsは
- エラー解析
- 原因特定
- 修正
- 再Build
まで行ってくれました。
結果としてBuild成功です。
Git操作もやってくれた
その後、
GitHub Copilot Appsは
- コミット
- Push
まで進めてくれました。
そして次に
PR作成用のURLを提示してくれました。
ここで大きな勘違い
私は
Create PR
を押したら終わりだと思っていました。
違いました。
GitHub初心者がハマったポイント
実際は
Create PR
↓
Pull Request作成
↓
Merge Pull Request
↓
Confirm Merge
↓
mainへ反映
↓
デプロイ
です。
私は
Create PR
↓
終わった！
と思っていました。
実際には終わっていなかった
期待していた変更が本番に反映されませんでした。
そこで再びGitHub Copilot Appsと一緒に調査。
原因調査
一緒に確認した結果、
コードは正しい。
Buildも成功。
Pushも成功。
でも反映されていない。
真犯人
原因はこれでした。
PRを作っただけ
でした。
マージしていなかったのです。
解決方法
GitHubで
Merge Pull Request
を押して
Confirm Merge
を実行。
その後デプロイが開始されました。
今回GitHub Copilot Appsがやってくれたこと
✅ プロジェクト分析
✅ 現状調査
✅ ソースコード探索
✅ 改善案作成
✅ 実装
✅ Build実行
✅ エラー修正
✅ コミット
✅ Push
✅ PR作成
✅ 原因調査
自分がやったこと
一方で、
全部をAIに任せたわけではありません。
私がやったことは
- 課題を決める
- 優先順位を決める
- 方向性を決める
- 最終確認する
- PRをマージする
です。
私が思う一番おすすめの使い方
実はこれが一番重要です。
GitHub Copilot Appsに
どうしよう？
何を作ろう？
どっちがいい？
を延々と聞くと利用量を消費します。
そこで私は、
まず別のAIと壁打ちをします。
私の使い方
まず別のAIで
課題整理
改善案検討
優先順位決定
指示文作成
を行います。
そしてGitHub Copilot Appsには
調査してください
変更対象ファイルを提示してください
実装してください
Build確認してください
という具体的な指示だけを渡します。
この方法のメリット
GitHub Copilot Appsは
考えるAI
ではなく
開発するAI
として使います。
そうすると
- 利用量を抑えやすい
- 指示が明確になる
- 精度が上がる
- 無駄なやり取りが減る
というメリットがありました。
私のおすすめ手順
①分析
このプロジェクトを分析してください
②調査
この機能はどこにありますか？
③改善案
改善案を整理してください
④変更対象確認
変更対象ファイル一覧を提示してください
⑤実装
実装してください
⑥Build
Build確認してください
⑦PR作成
PRを作成してください
⑧Merge
GitHubでマージ
まとめ
GitHub Copilot Appsは、
私にとって
コード補完ツールではありませんでした。
実際には
- 調査担当
- 実装担当
- Build担当
- Git担当
を兼ねた
AI開発メンバー
でした。
そして一番効果的だったのは、
別のAIで課題や方向性を整理し、
GitHub Copilot Appsには実装に集中してもらうことでした。
GitHubが苦手だった私でも、
分析からPR作成まで進められたので、
これから使う方の参考になればうれしいです。