GitHub CopilotをPRでメンションして、スマホからそのままコードを修正して、外出中でも快適開発ライフを送る
スマホでのPRレビュー、もう他のプルリクを開かなくていい
以前プルリクエストをCopilotにレビューしてもらったら、いくつか指摘をもらいました。
提案をそのまま適用するボタンが出現しなかったため、Copilotにメンションをかけて問題箇所を修正してもらうようにしました。
ところが、作業が完了して見てみると依頼したプルリクエストではなく、新しいプルリクエストが作成されていてそれをマージしないと適用できないようでした。
本当にちょっとした動作ですが、確認用のプルリクエストを開いて内容を見て、さらにマージする一手間が毎回挟まるのは地味に重く感じていました。
つい最近、そうした流れをかなり省けるCopilotのアップデートが入っていることに気づきました。
この記事では、GitHub Mobile上のPRコメントでCopilotをメンションし、外出中でも軽微なレビュー修正を返せるようになった実践例を紹介します。
まず前提：この方法が使いやすい条件
このやり方は、外出中に軽微なレビュー修正を返したいときに特に向いています。
- GitHub MobileでPRのコメントを書けること
-
@copilotを使えるリポジトリであること - 変更が軽微で、その場でローカル専用の確認をしなくてよいこと
なお、リポジトリやアカウント側でGitHub Copilotが利用できる状態になっている必要があります。コメント欄で@copilotが候補に出ない場合は、Copilotの利用可否やリポジトリ側の設定を確認しておくと良いです。
アプリ、プルリク間の行ったり来たりに消耗していた日々
以前はCopilotに指摘されたら、CodexのアプリやVS Codeを立ち上げて修正してコミット、プッシュして修正していました。
先ほども触れた通り、Copilotにメンションして直してもらうことも可能でしたが、マージ作業が面倒で結局VS Codeなどで修正していることも多かったです。
ただ、この方法だとPCが必要だったり、CodexをChatGPTのiOSアプリから動かすためにiPhoneが必要だったりと、不便な面もいろいろありました。
解決策：PR上でGitHub Copilotを直接メンションする
最近、私が個人開発しているアプリのリポジトリでCopilotの進化を発見しました。
仕事帰りの電車内で何気なくChatGPTのチャットでどこまでコードレビューができるか試してみると、すぐに直した方が良い箇所が2か所指摘されました。
すぐにCodexに切り替えて修正しようかと思いましたが、当時手に持っていたのが、Androidスマホ。ChatGPTのAndroidアプリからはCodexは使えません。
肝心のiPhoneは、カバンの中にあり、狭い電車内で取り出すのが面倒な状態。
そうしたこともあって、久しぶりにCopilotへメンションして直してもらおうと思い、修正指示を送りました。
すると、Copilotは新しくプルリクエストを作ることなくその場でコードを修正してコミットまで完了。コメントするだけで開発が進みました。
どうやら、2026/3/24のアップデートからデフォルトでは直接修正するようになったらしいです。
以前は
- 修正用の別プルリクエストが作られる
- 内容確認とマージが追加で必要
今は
- 依頼した既存PRに直接コミットされる
- PRの切り替えなしで差分確認まで進められる
今回便利だと感じた一番大きなポイントはここです。
今回使ったのは、GitHub Mobileで開いたPRのコメント欄です。実際の修正依頼はGitHub Mobile上で@copilotを付けて投稿しました。コード編集アプリ自体は開かず、修正後の差分確認も同じPR上で行っています。
実際にやった流れは3ステップ
- PRのレビュー指摘を確認する
- GitHub Mobileのコメント欄で
@copilotに修正指示を書く - 返ってきたコミットと差分を確認し、帰宅後にPCでビルド確認する
この時点でスマホ上で確認するのは、コミット先ブランチと差分の妥当性までで、最終的なビルド確認や動作確認は帰宅後にPCで行います。
モバイルから依頼するときの書き方
モバイルから依頼するときは、1コメントで「どこが問題か」と「どう直したいか」を短く書く方が通りやすいです。原因と期待する修正を1文にまとめておくと、やり取りが増えにくくなります。
たとえば、こんな形です。
@copilot
この条件分岐で iOS fallback lens の扱いがずれているので、resolved lens を使うよう修正してください
この型が向いているのは、原因と期待する修正を1コメントで言い切れる軽微な変更です。
通りやすい例は、上のように「どこがずれているか」と「どう直したいか」が1文で分かる依頼です。
一方で、次のような依頼はスマホからだと粒度が粗く、差分も広がりやすくなります。
@copilot
カメラ周りを全体的に見直して良い感じに直してください
【実践】カメラ権限整理のPRをスマホから直してみた
今回Copilotメンションを試したプルリクは、以下の内容です。
カメラ権限・プレビュー・エラー処理を shared ViewModel 中心に整理し直して、許可後の復帰や iOS 側の Compose 統合まで通したPR。
今回伝えたいのは、モバイルからでも根本原因を含む具体的な修正依頼が通り、差分確認まで進められたことです。
Copilotには以下のコメントを送りました。
@copilot
iOS fallback lens 時の onPlatformPreviewError() に渡す lens が requested lens のままで、error が握りつぶされうる
プロンプトの画像
修正が完了して帰ってきたコメントはコミット番号と根本原因、修正内容がしっかり入っている質の良いものでした。
要点だけ抜くと、「resolved lens ではなく requested lens を使っていたためエラーが握りつぶされていた」「resolved lens を渡すように修正した」「修正はそのままコミットされた」の3点です。
1件目の修正コメント詳細（日本語訳あり）
**根本原因:**
IOSCameraSessionManager.startPreview がコールバックとして (Result<CameraLensFacing>) -> Unit を使用していました。これにより、失敗時に CameraLensFacing へアクセスできなくなり、CameraPreviewHost は元々リクエストされていた lensFacing を onPlatformPreviewError に渡すようにフォールバックしていました。フォールバック先のレンズが決定（解決）された際、リポジトリ内の pendingLensFacing はそのフォールバック先のレンズを保持していたため、pendingLensFacing == lensFacing というガード条件を満たさず、エラーが静かに握りつぶされていました。
**修正内容:**
コールバックのシグネチャを (resolvedLens: CameraLensFacing, error: Throwable?) -> Unit に変更しました。これにより、セッションマネージャーは常に「解決されたレンズ（resolved lens）」を呼び出し元に提供するようになります（「利用できるカメラが全くない」場合の早期終了パスにのみ requestedLensFacing を使用します）。CameraPreviewHost は onPlatformPreviewError を呼び出す際に resolvedLens を使うようになり、これで pendingLensFacing と正しく一致するようになりました。
念のためコミットを確認してみると、依頼したブランチのまま修正が入っていました。
修正コミットの画像
続けて、レビューで Should Fix とされていた問題も修正してみました。
@copilot
CameraViewModel が repository の具体的 error を PreviewInitializationFailed で上書きしてしまう
プロンプトの画像
修正コメントはこちらです。
こちらも要点は、「repository の具体的な error を保持する例外を用意した」「ViewModel 側でその error を取り出すようにした」「修正コミットまで完了した」です。
2件目の修正コメント詳細（日本語訳あり）
> CameraViewModel が repository の具体的 error を PreviewInitializationFailed で上書きしてしまう
**コミット `3caec7d` で修正されました。**
共有定義に `CameraRepositoryException(val error: CameraError) : Exception(error.name)` を追加しました。
これにより、Android / iOS 両方の repository にある `Result.failure(IllegalStateException(...))` の呼び出しは、すべて適切な `CameraError` を持つ `CameraRepositoryException` を使うようになりました。
たとえば、レンズが存在しない場合の失敗には `CameraUnavailable`、レンズ切り替え失敗には `LensSwitchFailed` を使います。
また、`CameraViewModel` には `Throwable?.toCameraError(fallback: CameraError)` という拡張関数を追加しました。
これは、`CameraRepositoryException` から `CameraError` を取り出し、取り出せない場合は fallback を返すものです。
3か所ある `onFailure`（`startCameraPreview()` が2か所、`onRetryPreview()` が1か所）は、これまでのように `PreviewInitializationFailed` を固定で使うのではなく、この仕組みを使うように変更しました。
こちらもコミットされ修正が完了していました。
修正コミットの画像
家に帰ってPCでビルドして動作確認してみると、きちんと修正されていました。
ツール切り替えが大幅に減ることで得られる快適さ
ツール切り替えが減るだけで、レビュー修正に取りかかるまでの負荷はかなり下がります。コメントを書く、修正コミットを見る、差分を確認する、という流れがPR上で完結するので、コピペや別PRのマージ確認に意識を取られにくくなりました。PR上で説明と差分確認まで完結する点が大きいです。
GitHub MobileでのPR修正という軸で見た使い分け
GitHub Mobile上のCopilotメンションだけで、実装からレビュー修正まで全て済ませるべきかというと、そうではありません。あくまでも、PCが使えなくてちょっとした修正をするための補助ツールとして使った方が良さそうです。
私が実践している開発フローは、CodexやVS Codeなどで大まかな実装をして、レビューと修正をCopilotにやってもらうようにしています。
本実装は専用のコーディングツールを使った方が、PlanモードやAgent Skillなどの便利機能がフルで使えて効率が良いです。
モバイルから依頼しやすいのは、次のような修正です。
- 既存コードの数行から数十行程度の修正
- レビューコメントへの追従
- メソッド名や例外処理の軽微な修正
- 指摘内容を1コメントで言い切れるもの
今回のように「ここで渡す値が違う」「具体的なエラーを握りつぶしている」のように、指摘内容を1コメントで言い切れるものは相性が良いです。
逆に、次のような修正はPC側で進めた方が安全です。
- 複数ファイルをまたぐ大きな設計変更
- 実機・シミュレーターでの確認が前提になる修正
- 影響範囲をローカルで追いながら確認したい修正
骨格ができている状態での軽い変更であれば、GitHub Mobileから変更してもそこまで大きな支障はありません。軽い変更を外出先でも進められるようになった点は、かなり効率的です。
モバイルで修正を依頼する前には、以下を確認しています。
- 指摘内容が1コメントで言い切れるか
- 影響範囲が広すぎないか
修正後は、以下をPCで見直します。
- コミット先ブランチが意図したPRのものか
- 差分が指摘箇所に閉じているか
- 最終的なビルド確認や動作確認が必要か
もし差分が指摘箇所から広がったり、意図しないファイルまで触り始めたら、その時点でモバイル運用をやめてPCに切り替えるのが安全です。
ただし、プルリクエストを出している以上は動作確認することは必須です。私のようにモバイル開発をしている場合は、ビルド実行がPCでないとできないため最後は家で仕上げをしましょう。
シームレスな開発体験で、レビューのハードルを下げる
以前よりもCopilotに修正依頼を出しやすくなり、移動中でも軽微なレビュー指摘をその場で返しやすくなりました。
GitHub MobileはiOS/Androidでそのまま使えるので、この導線自体は試しやすいです。
移動中の電車やカフェでも、PRを開いてコメントし、返ってきた差分を確認するところまではスマホで完結できます。大きな実装はPC、軽微な修正はモバイルと切り分けるだけでも、レビュー対応はかなり進めやすくなりました。
Copilot関連記事
Copilotを業務でどう使い始めて、どこで役立ったかを整理した記事です。
同じ指摘を減らすために、Agent SkillsをCopilotが読み込めるように作成した手順をまとめた記事です。
全社向けのガイドをCopilotを使用して、公開したときに使用したプロンプトなどをまとめた記事です。
Discussion