GitHub Mobileでプルリクエストのマージコンフリクトを確認した際、PCを開かずにCopilot cloud agentへ解消作業を依頼できるようになりました。2026年7月8日付のGitHub公式Changelogで公開された機能で、iOS・Androidの最新プロダクション版から利用できます。(The GitHub Blog)
結論から言えば、今回の更新は新しいマージ方式への移行ではなく、既存のCopilot cloud agentをGitHub Mobileのマージボックスから起動しやすくする変更です。従来の@copilotコメントも引き続き利用できるため、既存のプルリクエスト運用を大きく変更する必要はありません。
ただし、Copilotがコンフリクトを解消しても、自動的に安全な状態でマージされるわけではありません。Copilotはプルリクエストのブランチへ変更を追加するため、差分レビュー、GitHub Actions、ブランチ保護、権限管理を含めた運用設計が必要です。
GitHub Mobileの「Fix with Copilot」で何が変わったのか
マージコンフリクトが発生しているプルリクエストをGitHub Mobileで開くと、マージボックスから「Fix with Copilot」を選択できるようになりました。
ボタンをタップすると、Copilotへコンフリクト解消を依頼するコメントが自動入力されます。そのコメントを送信するとCopilot cloud agentのセッションが開始され、成功または失敗の結果がアプリ上に表示されます。(The GitHub Blog)
今回の主な変更点は次のとおりです。
| 比較項目 | 従来のGitHub Mobile | 更新後 |
|---|---|---|
| コンフリクトの確認 | プルリクエスト内で状況を確認 | マージコンフリクトの警告を分かりやすく表示 |
| Copilotの起動 | コメント欄から@copilotへ依頼 | マージボックスの「Fix with Copilot」から起動 |
| プロンプト入力 | 依頼内容を手動で入力 | コンフリクト解消用コメントを自動入力 |
| 実行結果の確認 | コメントやタイムラインを確認 | 成功・エラーのフィードバックを表示 |
| 従来方式との互換性 | @copilotコメントを使用 | @copilotコメントも引き続き使用可能 |
GitHub.comでは、マージボックスの「Fix with Copilot」と、プルリクエストコメントで@copilotへ依頼する2つの方法が案内されています。今回の更新は、その専用導線をGitHub Mobileへ広げたものと考えると分かりやすいでしょう。(GitHub Docs)
スマートフォン上でコンフリクトを直接編集する機能ではない
「Fix with Copilot」は、スマートフォン内のGitクライアントで競合箇所を編集する機能ではありません。
GitHub Mobileから依頼を送ると、Copilot cloud agentがGitHub Actionsベースの一時的な開発環境でリポジトリを調査し、競合を解消してブランチへ変更をプッシュします。処理の本体はクラウド側で動くため、端末に開発環境や依存パッケージを用意する必要はありません。(GitHub Docs)
GitHub Mobileからマージコンフリクトを解消する流れ
基本的な利用手順は次のとおりです。
- GitHub Mobileを最新のプロダクション版へ更新する
- マージコンフリクトが発生しているプルリクエストを開く
- マージボックスに表示された「Fix with Copilot」をタップする
- 自動入力されたコメントを確認する
- 必要に応じて、優先すべき仕様や実行するテストを追記する
- コメントを送信してCopilot cloud agentを起動する
- Copilotが追加したコミットとセッションログを確認する
- GitHub Actionsを実行し、差分をレビューしてからマージする
Copilotは競合する変更を分析し、コンフリクトを解消したうえで、実行可能なビルド、テスト、リンターによる確認を試みます。作業後は人間へレビューを要求するため、Copilotだけでマージまで完了する仕組みではありません。(GitHub Docs)
自動入力されたコメントには条件を追記する
コンフリクトの解消方針が明確な場合は、初期コメントをそのまま送らず、判断基準を追記した方が意図しない変更を減らせます。
例えば、次のような条件です。
このプルリクエストのマージコンフリクトを解消してください。
- 認証処理はbaseブランチ側の実装を優先する
- このPRで追加した入力チェックは残す
- 公開APIのシグネチャは変更しない
- .github/workflows配下は変更しない
- npm testとnpm run lintを実行する
- 判断が必要だった箇所を作業結果に記載する「コンフリクトを解消して」だけでは、両ブランチのどちらを優先すべきかCopilotが推測することになります。機能要件や変更禁止範囲を指定することが、実用上の重要なポイントです。
既存のCopilot運用との互換性
今回のGitHub Mobile更新によって、既存の@copilotコメントやプルリクエスト運用が廃止されるわけではありません。
プルリクエストのコメントで@copilotにメンションし、コンフリクト解消、レビュー指摘への対応、テスト追加、GitHub Actionsの失敗修正などを依頼する方法は引き続き利用できます。Copilotが既存プルリクエストのコメントから起動された場合、原則としてそのプルリクエストのブランチへコミットを追加します。起動できるのは、リポジトリへの書き込み権限を持つユーザーです。(GitHub Docs)
基本利用にリポジトリの移行作業は不要
2026年7月8日の公式発表は、GitHub Mobileの表示と起動導線の追加を中心としたものです。新しいGitブランチ形式、API、コンフリクト記法への移行は案内されていません。
そのため、すでにCopilot cloud agentを利用している組織では、基本的に次の対応で利用を開始できます。
- GitHub Mobileアプリを更新する
- Copilot cloud agentのポリシーを確認する
- 対象リポジトリが利用許可されているか確認する
- 利用者に書き込み権限があるか確認する
一方、ブランチ保護やルールセットが厳しいリポジトリでは、Copilotのコミットが拒否される可能性があります。
ブランチ保護やルールセットへの影響
Copilot cloud agentも、人間の開発者と同様にブランチ保護、ルールセット、必須チェックの対象です。
例えば、コミット作成者を特定のユーザーだけに制限している場合、Copilotがプルリクエストのブランチを更新できないことがあります。ルールセットを使用している場合は、必要に応じてCopilotをバイパスアクターとして設定できますが、安易に広いバイパス権限を与えるべきではありません。(GitHub Docs)
確認すべき主な互換性項目は次のとおりです。
| 対象 | 動作・制約 | 推奨対応 |
|---|---|---|
| ブランチ保護 | Copilotにも適用される | 検証用PRでコミット可能か確認する |
| 必須ステータスチェック | 原則として維持される | チェック完了前のマージを許可しない |
| コミット作成者の制限 | Copilotの更新をブロックする可能性がある | ルールセットを個別に検証する |
| 既存のPRブランチ | Copilotが直接コミットを追加する | 実行前にブランチ所有者へ周知する |
| 複数リポジトリにまたがる変更 | 1回のセッションでは対応できない | リポジトリごとに作業を分割する |
| 長時間の処理 | セッションの上限は59分 | 大規模な競合は小さく分割する |
Copilot cloud agentは1回のタスクで1つのリポジトリ、1つのブランチを扱い、セッションの最大実行時間は59分です。巨大なモノレポや大量の生成ファイルを含むコンフリクトでは、途中でタイムアウトする可能性も考慮してください。(GitHub Docs)
利用に必要な条件
GitHub Mobileで「Fix with Copilot」を使うには、アプリを更新するだけでは不十分です。プラン、ポリシー、リポジトリ、権限の条件をすべて満たす必要があります。
| 条件 | 確認内容 |
|---|---|
| GitHub Mobile | iOSまたはAndroidの最新プロダクション版 |
| Copilotプラン | Copilotの有料プランを利用している |
| ユーザー権限 | 対象リポジトリへの書き込み権限がある |
| 組織ポリシー | Copilot cloud agentが有効になっている |
| リポジトリアクセス | 対象リポジトリが除外されていない |
| ホスティング環境 | GitHub上でホストされたリポジトリである |
| プルリクエスト | オープン状態で、実際にコンフリクトが発生している |
Copilot cloud agentはすべての有料Copilotプランで提供されています。Copilot Pro、Pro+、Maxでは標準で有効ですが、Copilot BusinessとCopilot Enterpriseでは初期状態で無効となり、管理者による有効化が必要です。(GitHub Docs)
また、GitHub Enterprise ServerではCopilotが提供されていないため、本機能も利用対象外です。Enterprise Managed Userが所有する個人リポジトリも、GitHub-hosted runnerを利用できないことから対象外となります。(GitHub Docs)
利用量とコストも確認する
Copilot cloud agentの実行では、GitHub Actionsの利用時間とGitHub AI Creditsが消費されます。AI Creditsの消費量は、使用モデルやセッションで処理するトークン量によって変わります。(GitHub Docs)
マージコンフリクトが頻発するリポジトリで無制限に利用させると、想定より利用量が増える可能性があります。組織導入時は、成功率だけでなく次の数値も確認すると判断しやすくなります。
- 1件あたりのセッション時間
- 再実行率
- Copilotが追加したコミット数
- 人間による修正が必要だった割合
- GitHub Actionsの追加消費時間
- AI Creditsの消費量
組織・Enterpriseで実施したい管理策
最初から全リポジトリへ有効化しない
Copilot BusinessまたはCopilot Enterpriseを利用している場合は、検証対象のリポジトリだけを選択して段階的に有効化するのが安全です。
Organizationでは、設定画面の「Copilot」から「Cloud agent」を開き、Repository accessで許可するリポジトリを指定できます。Enterpriseでは「AI controls」から「Agents」「Copilot Cloud Agent」へ進み、対象Organizationを制御できます。(GitHub Docs)
初期検証に向いているのは、次のようなリポジトリです。
- 自動テストが整備されている
- ロールバックが容易
- 本番シークレットへのアクセスが不要
- 変更範囲が比較的小さい
- コードオーナーがレビューできる
- マージコンフリクトの発生パターンを再現しやすい
Content exclusionをアクセス制御として使わない
特に注意したいのが、CopilotのContent exclusionとの関係です。
GitHub公式ドキュメントでは、Copilot cloud agentはContent exclusionを考慮せず、除外対象として設定されたファイルも参照・更新できると説明されています。通常のCopilot機能で除外設定を行っていても、cloud agentに対する非表示制御にはなりません。(GitHub Docs)
cloud agentへ見せたくないコードがある場合は、Content exclusionに依存せず、次の対策を検討してください。
- 対象リポジトリ自体をcloud agentの利用対象から外す
- 機密性の異なるコードを別リポジトリへ分離する
- リポジトリへのユーザー権限を見直す
- 重要な設定ファイルをCODEOWNERSで保護する
- 監査ログとセッションログを定期的に確認する
GitHub Actionsの自動実行は慎重に許可する
Copilotがプルリクエストへ変更をプッシュした場合、GitHub Actionsワークフローは初期設定では自動実行されません。書き込み権限を持つユーザーが、マージボックスの「Approve and run workflows」を選択して実行します。(GitHub Docs)
自動実行を許可する設定もありますが、未レビューのコードがActionsのシークレットや書き込み権限へアクセスする可能性があります。特に.github/workflows配下をCopilotが変更している場合は、ワークフローを承認する前に必ず差分を確認してください。
初期導入では、次の設定が現実的です。
- Copilotの組み込み検証ツールは有効のままにする
- Actionsワークフローは手動承認を維持する
.github/workflows/**の変更にはコードオーナーの承認を求める- デフォルトブランチへ直接プッシュできない状態を維持する
- 必須レビューと必須チェックを解除しない
テスト時に見落としやすいポイント
コンフリクトマーカーが消えただけで合格にしない
マージコンフリクトの解消には、2つの異なる意味があります。
<<<<<<<などのコンフリクトマーカーが消えている- 両ブランチの意図を保った正しい実装になっている
Copilotが前者を満たしても、後者を満たしているとは限りません。
例えば、一方のブランチで入力チェックを追加し、もう一方で関数の戻り値を変更していた場合、コードがコンパイルできても、入力チェックが失われている可能性があります。レビューでは「競合が消えたか」ではなく、「両変更の目的が残っているか」を確認してください。
Agent内のテストとPR上のCIを区別する
Copilot cloud agentは、一時的なGitHub Actions環境でビルド、テスト、リンターを実行できます。一方、Copilotがコミットをプッシュした後の通常のGitHub Actionsは、初期設定では自動実行されません。(GitHub Docs)
したがって、「Copilotがテストに成功した」と表示されても、次の確認が必要です。
- プルリクエスト上の必須チェックが実行されたか
- 本番と同じOS・ランタイムで検証されたか
- 結合テストやE2Eテストが含まれているか
- プライベートパッケージへアクセスできたか
- 外部サービスを使用するテストが省略されていないか
開発環境の差を減らす
Copilot cloud agentの標準環境はUbuntu Linuxです。Windows固有のビルド、専用SDK、ネイティブライブラリが必要なプロジェクトでは、Agent内の検証が失敗したり、重要なテストが実行されなかったりする可能性があります。
必要なツールや依存関係は、.github/workflows/copilot-setup-steps.ymlで準備できます。このファイルはデフォルトブランチへ配置する必要があり、Windows環境やセルフホストランナーを指定することも可能です。(GitHub Docs)
リポジトリ固有のビルド方法やテスト手順は、.github/copilot-instructions.mdにも記載できます。最低限、次の情報を含めておくと効果的です。
- 使用言語とランタイムのバージョン
- 依存関係のインストール手順
- ビルドコマンド
- 単体テストと結合テストのコマンド
- リンターとフォーマッターの実行方法
- 変更してはいけないディレクトリ
- 互換性を維持すべき公開API
- マイグレーションや生成ファイルの扱い
GitHub公式も、ビルド、テスト、実行、lintの手順や前提条件をカスタム指示へ記載することを推奨しています。(GitHub Docs)
シークレットとネットワークの違いを確認する
Copilot cloud agentは、通常のGitHub Actions用シークレットを自動的には利用しません。プライベートパッケージレジストリなどへアクセスさせる場合は、専用のAgents secretsまたはvariablesを設定します。(GitHub Docs)
また、cloud agentのインターネットアクセスはファイアウォールで制限されています。依存パッケージのダウンロード先や社内サービスがブロックされる場合は、セッションログを確認し、必要な接続先だけを許可してください。ファイアウォール全体を無効化すると、コードや機密情報の外部送信リスクが高まります。(GitHub Docs)
導入テストで確認するチェックリスト
| 検証観点 | 確認内容 | 合格基準 |
|---|---|---|
| Mobileの表示 | コンフリクト警告と「Fix with Copilot」が表示される | 対象ユーザーがボタンを利用できる |
| 権限 | 書き込み権限のあるユーザーだけが起動できる | 権限外ユーザーから起動できない |
| コンフリクト解消 | 競合箇所が正しく統合されている | 両ブランチの機能要件が維持される |
| ブランチ保護 | 必須レビューとチェックが維持される | Copilotだけでマージできない |
| CI | 必須テスト、lint、セキュリティチェックが動く | 全必須チェックが成功する |
| ワークフロー安全性 | Actions定義の変更を確認する | 未承認の権限拡大がない |
| 監査 | コミットとセッションログを追跡できる | 起動者、変更内容、結果を確認できる |
| 利用量 | ActionsとAI Creditsを確認する | 想定した予算内に収まる |
Copilotが作成したコミットには署名が付与され、依頼した開発者は共同作成者として記録されます。セッションログや監査ログも確認できるため、検証時は「結果」だけでなく「どのような判断で変更したか」まで確認すると、組織での利用可否を判断しやすくなります。(GitHub Docs)
「Fix with Copilot」が表示されない場合の確認項目
ボタンが見つからない場合は、次の順番で確認してください。
- GitHub Mobileを最新版へ更新する
- プルリクエストがオープン状態か確認する
- GitHub上で実際にマージコンフリクトが検出されているか確認する
- 有料Copilotプランが割り当てられているか確認する
- Copilot cloud agentの組織・Enterpriseポリシーを確認する
- 対象リポジトリが利用対象から除外されていないか確認する
- 自分に書き込み権限があるか確認する
- ルールセットがCopilotのコミットを拒否していないか確認する
専用ボタンが利用できない場合でも、条件を満たしていればプルリクエストコメントから次のように依頼できます。
@copilot resolve the merge conflicts on this PR.書き込み権限があるにもかかわらず反応しない場合は、コメントへの目の絵文字リアクションや「Copilot started work」のタイムラインイベントを確認します。これらが表示されない場合は、ポリシー、権限、プルリクエストの状態を再確認してください。(GitHub Docs)
自社で対応すべきかを判断する基準
GitHub Mobileからのコンフリクト解消を積極的に試す価値があるのは、次のようなチームです。
- 外出中や障害対応中にプルリクエストを確認することが多い
- コンフリクト待ちでレビューやリリースが止まりやすい
- 自動テストとブランチ保護が整っている
- すでにCopilot cloud agentを利用している
- 担当者がCopilotの差分をレビューできる
反対に、次の環境では、すぐに全社展開せず管理設計を先に進めるべきです。
- Content exclusionを機密コードの保護に使っている
- Actionsワークフローが強い書き込み権限を持つ
- テストがローカル環境でしか動かない
- コミット作成者を厳格に制限している
- 自動生成ファイルやマイグレーション競合が多い
- AIによるコード変更を承認するルールが未整備
- GitHub Enterprise Serverを使用している
個人利用や小規模チームでは、アプリを更新し、低リスクなプルリクエストで動作を試せば十分です。Business・Enterprise環境では、選択したリポジトリだけでパイロットを行い、Actionsの手動承認、必須レビュー、セッションログ確認を維持した状態で評価するのが適切です。
まとめ
GitHub Mobileの「Fix with Copilot」により、マージコンフリクトを見つけてからCopilot cloud agentへ依頼するまでの操作が大幅に短縮されました。既存の@copilotコメント方式も残るため、従来運用との互換性は高く、基本利用のためにリポジトリを移行する必要もありません。
一方で、変更されるのはあくまで「依頼のしやすさ」です。Copilotが解消した結果の正しさ、GitHub Actionsの実行、ブランチ保護、機密ファイルへのアクセス管理は、引き続き人間と管理者の責任で確認する必要があります。
まずは次の順序で対応してください。
- GitHub Mobileを最新版へ更新する
- Copilot cloud agentのプラン、ポリシー、リポジトリアクセスを確認する
- 自動テストが整った低リスクなリポジトリで試す
- Actionsの手動承認を維持したまま差分とセッションログを確認する
- 成功率、修正率、利用量を測定して展開範囲を判断する
コメント