GitHub Copilot appのAI更新「The GitHub Copilot desktop app becomes available on every Copilot plan」で変わったのは、デスクトップアプリを利用できるプランの範囲です。Copilot FreeとGitHub Educationを含むすべてのCopilotプランで利用できるようになり、Copilot契約がなくても、自分で用意したAPIキーを使うBYOKでエージェントセッションを実行できます。
一方、既存のCopilot Pro、Business、Enterprise利用者に、リポジトリの移行や開発環境の作り直しが求められたわけではありません。注意すべきなのは、全プランでアプリを起動できることと、モデル、利用枠、エージェント機能、管理ポリシーが同一であることは別だという点です。特にCopilot BusinessとEnterpriseでは、管理者によるCopilot CLIポリシーの有効化が必要です。(The GitHub Blog)
なお、GitHub公式Changelogの表記日は2026年7月7日です。本稿では、指定された2026年7月8日を基準日として、変更内容と対応要否を整理します。(The GitHub Blog)
「The GitHub Copilot desktop app becomes available on every Copilot plan」で何が変わったのか
GitHub Copilot appは、AIエージェントに開発作業を依頼し、変更内容の確認、テスト、プルリクエスト、CI結果の確認までをデスクトップ上で管理するアプリです。
IDE内のコード補完だけを目的としたものではなく、複数の作業を別々のブランチとワークツリーで並行実行し、人間が計画や差分を確認しながら作業を進めることを想定しています。(GitHub Docs)
今回の変更点を整理すると、次のとおりです。
| 観点 | 変更前の状況 | 2026年7月7日の変更後 | 実務への影響 |
|---|---|---|---|
| 利用できるプラン | 2026年6月2日時点では、既存のPro、Pro+、Business、Enterprise利用者が主な対象 | Copilot FreeとGitHub Educationを含む全Copilotプラン | 無料・教育向け利用者もデスクトップアプリを試せる |
| Copilot契約なしでの利用 | 2026年6月23日にBYOK対応が追加済み | BYOKによる利用を継続 | GitHubアカウントとモデル提供元の認証情報があれば利用可能 |
| 対応OS | Windows、macOS、Linux | 変更なし | OS移行は不要 |
| Business・Enterprise | Copilot CLIポリシーの有効化が必要 | 変更なし | 管理者が無効化している環境では利用できない |
| 既存リポジトリとの連携 | GitHubリポジトリ、ブランチ、CIとの連携に対応 | 変更なし | リポジトリ形式の変換や専用プロジェクトへの移行は不要 |
2026年6月2日の技術プレビュー拡大時点では、Copilot Freeへの提供は「近日中」とされていました。7月7日の告知で、その対象が全プランへ正式に広がった形です。BYOKは6月23日に追加されており、今回新しく登場した機能ではなく、全プラン対応後も維持される利用経路です。(The GitHub Blog)
つまり、今回の中心的な変更はアプリ本体の動作方式ではなく、利用資格の拡大です。
全プラン対応でも機能や利用枠は同一ではない
「every Copilot plan」という表現から、無料プランでも有料プランと同じ機能を無制限に使えると考えるのは適切ではありません。
今回共通化されたのは、GitHub Copilot appを利用できるという入口です。モデル選択、AIクレジット、クラウドエージェント、Automationsなどの条件は、引き続きプランや管理ポリシーによって異なります。
| 項目 | 全プランで共通か | 確認すべき点 |
|---|---|---|
| アプリのインストール | 共通 | 対応OSとCPUアーキテクチャ |
| GitHubアカウントでのサインイン | 共通 | 個人用と業務用アカウントの取り違え |
| 利用できるモデル | 共通ではない | プラン制限、管理者のモデルポリシー |
| モデルの手動選択 | 共通ではない | Free・StudentではAutoのみとなる場合がある |
| AIクレジット | 共通ではない | プランごとの月間利用枠、追加予算 |
| Automations | 共通ではない | 対象プランとクラウドエージェントポリシー |
| Business・Enterpriseでのアプリ利用 | 条件付き | Copilot CLIポリシーの有効化 |
| BYOK | 利用可能 | 外部モデルの料金、上限、データ処理条件 |
2026年6月24日の公式情報では、Copilot FreeとStudentプランのモデル選択はAutoが既定かつ唯一の選択方式とされています。また、2026年6月1日からは全CopilotプランでAIクレジットを基準とした利用量管理が導入され、各プランに含まれる利用枠や追加予算の扱いが異なります。(The GitHub Blog)
Automationsについても、少なくとも2026年6月2日の提供時点では、既存のPro、Pro+、Max、Business、Enterprise利用者が対象であり、BusinessとEnterpriseではクラウドエージェントポリシーの有効化が必要でした。アプリが全プラン対応になったからといって、付随するすべてのエージェント機能まで同条件になったわけではありません。(The GitHub Blog)
実務では、次の3点を分けて確認する必要があります。
- アプリをインストールして起動できるか
- 必要なモデルやエージェント機能を利用できるか
- 想定する利用量をプラン内のAIクレジットで賄えるか
既存のGitHub Copilot環境との互換性
リポジトリやCIの移行は基本的に不要
GitHubは、GitHub Copilot appがCopilot CLIを基盤とし、GitHubとネイティブに連携するため、既存のリポジトリ、ブランチ、CIパイプラインをそのまま利用できると説明しています。今回の告知にも、リポジトリ構造の変更や設定ファイルの移行を求める記載はありません。(GitHub Docs)
そのため、既存利用者が今回の更新だけを理由に、次のような作業を行う必要はありません。
- リポジトリを作り直す
- GitHub Actionsを再構築する
- IDEのGitHub Copilot拡張機能を削除する
- Copilot CLIをアンインストールする
- ブランチ運用をGitHub Copilot app専用に変更する
ただし、GitHub Copilot appはIDE拡張機能と同じ操作画面を提供するものではありません。既存ツールを置き換えるというより、用途に応じて併用する位置付けで考えると分かりやすくなります。
| 既存ツール・仕組み | 主な用途 | GitHub Copilot appとの関係 |
|---|---|---|
| VS CodeやJetBrainsのCopilot拡張 | 編集中のコード補完、チャット、IDE内作業 | 継続利用可能。アプリは複数エージェントの作業管理に向く |
| GitHub Copilot CLI | ターミナルからのエージェント操作 | アプリの基盤となる仕組み。企業では同じCLIポリシーが関係する |
| GitHub Actions | ビルド、テスト、デプロイ | エージェントが作成したPRを既存CIで検証できる |
| ブランチ保護ルール | レビューや必須チェックの強制 | AIが作った変更にも従来どおり適用すべき |
| GitHub Desktop | Git操作と変更履歴のGUI管理 | 目的が異なるため、必要に応じて併用する |
最大の確認ポイントはワークツリー
GitHub Copilot appでは、複数のローカルエージェントセッションを並行実行できます。各セッションには専用のGitワークツリーとブランチが割り当てられ、ファイルやブランチの衝突を避ける設計です。(GitHub Docs)
この仕組みは並列作業に有効ですが、既存の開発環境が「常に同じフォルダーで実行される」ことを前提としていると、問題が起きる場合があります。
特に確認すべきなのは、次のような環境です。
- リポジトリの絶対パスをスクリプト内に記述している
- メインの作業フォルダーにだけ
.envやローカル設定ファイルを置いている - 依存パッケージやビルド成果物を作業フォルダー内に保存する
- 複数セッションが同じポート番号を使用する
- ローカルデータベースやコンテナ名を固定している
- Git hooks、Git LFS、サブモジュールを利用している
- テストが共有ファイルや共有キャッシュを書き換える
例えば、メインの作業フォルダーには.env.localが存在するものの、エージェント用ワークツリーには存在しない場合、アプリ自体は正常でもビルドやテストだけが失敗する可能性があります。
反対に、複数セッションで同じ開発サーバーを起動すると、どちらか一方がポート競合で停止することもあります。全社展開前に、実際のプロジェクトでワークツリーを使ったビルドとテストを確認することが重要です。
Quick chatが成功しても互換性テストは完了していない
Quick chatは、ブランチやワークツリーを作らずに質問や設計相談を行う機能です。一方、実際にコードを変更するフルセッションでは、エージェントがブランチを作成し、コード変更やテストを行います。(GitHub Docs)
そのため、Quick chatでリポジトリを読み取れただけでは、次の項目を検証できません。
- エージェント用ワークツリーでの依存関係構築
- コード変更権限
- テストコマンドの実行
- ローカルサービスへの接続
- ブランチのプッシュ
- プルリクエストの作成
- CIと必須チェックの実行
評価時は、Quick chatに続いて、低リスクな修正を使ったフルセッションまで実施してください。
対応が必要な利用者と不要な利用者
今回の更新に対する対応要否は、現在の契約と利用目的によって異なります。
| 対象 | 対応要否 | 推奨する対応 |
|---|---|---|
| すでにアプリを利用している個人向け有料プラン利用者 | 緊急対応は不要 | 通常のアプリ更新を行い、既存プロジェクトで動作確認する |
| Copilot Free利用者 | 利用したい場合は対応 | アプリをインストールし、利用枠とモデル制限を確認する |
| GitHub Education利用者 | 利用したい場合は対応 | 教育用アカウントでサインインし、利用可能な機能を確認する |
| Business・Enterprise利用者 | 管理者確認が必要 | Copilot CLIポリシーが有効か確認する |
| Business・Enterprise管理者 | 導入判断が必要 | 対象ユーザー、ポリシー、予算、利用ルールを決めてから有効化する |
| Copilot契約がなく外部モデルを利用する人 | BYOK設定が必要 | APIキー、エンドポイント、料金、データ処理条件を確認する |
| 機密性の高いコードを扱う組織 | 段階導入を推奨 | 公開コード、ログ、外部モデル、コマンド実行を重点的に検証する |
既存の有料プラン利用者については、今回のChangelogに破壊的変更や必須移行は示されていません。そのため、すぐに構成変更を行う必要はありません。
反対に、企業管理者は「利用可能になった」という理由だけで一括有効化するのではなく、デスクトップ上でエージェントがコード変更やコマンド実行を行う開発ツールとして評価する必要があります。
GitHub Copilot appの導入条件
GitHub公式ドキュメントで示されている主な前提条件は、次のとおりです。
| 条件 | 必須度 | 確認内容 |
|---|---|---|
| 対応OS | 必須 | Windows、macOS、Linux |
| Git | 必須 | ローカルPCにGitがインストールされていること |
| GitHubアカウント | 必須 | CopilotプランやBYOKの有無にかかわらず必要 |
| Copilotプラン | いずれか必須 | Copilot Freeを含む任意のCopilotプラン |
| BYOK用認証情報 | プランがない場合に必須 | APIキー、エンドポイント、モデル提供元の設定 |
| Copilot CLIポリシー | Business・Enterpriseで必須 | 組織またはEnterprise管理者が有効化 |
| リポジトリへのアクセス権 | コード作業時に必須 | 読み取り、ブランチ作成、プッシュ、PR作成など |
| ネットワーク接続 | 実質的に必要 | GitHubや利用するモデル提供元へ接続できること |
配布ページでは、Windowsのx64・ARM、MacのApple Silicon・Intel、Linux向けビルドが案内されています。最低OSバージョンなどは更新によって変わる可能性があるため、導入時点の配布ページとリリース情報を確認してください。(GitHub Docs)
推奨する初期設定手順
- 利用経路を決める
GitHubが提供するCopilotモデルを使うのか、BYOKで外部モデルを使うのかを決めます。 - 企業ポリシーを確認する
BusinessまたはEnterpriseの場合は、インストール前に管理者へCopilot CLIポリシーの状態を確認します。 - Gitとアプリをインストールする
OSとCPUアーキテクチャに合ったビルドを選択します。 - 正しいGitHubアカウントでサインインする
業務用と個人用のアカウントを使い分けている場合は、特に注意が必要です。GitHub Enterprise Serverでは「Use GitHub Enterprise」を選び、サーバーアドレスを入力できます。 - テスト用リポジトリを追加する
ローカルフォルダー、GitHub上のリポジトリ、任意のGit URLから追加できます。 - Quick chatで読み取りを確認する
リポジトリの概要、主要ディレクトリ、テスト方法などを質問します。 - Planモードで小さな修正を依頼する
最初から自律性の高いAutopilotを使わず、計画を確認できるPlanモードから始めると安全です。 - 差分、テスト、PR、CIを確認する
AIの回答だけでなく、実際の変更内容とテスト結果を人が確認します。
GitHub Copilot appは、ローカルフォルダー、GitHubリポジトリ、任意のGit URLを接続元として利用できます。セッションではPlan、Interactive、Autopilotなどのモードを選択でき、エージェントによる変更を段階的に確認できます。(GitHub Docs)
BYOKで利用する場合の注意点
BYOKを利用すると、Copilotプランを契約していなくても、自分で用意したモデル提供元をGitHub Copilot appに接続できます。ただし、GitHubアカウントでのサインインは必要です。
公式ドキュメントでは、次のモデル提供元が案内されています。
- OpenAI
- Azure OpenAI
- Microsoft Foundry
- Anthropic
- Ollama
- Foundry Local
- LM Studio
- OpenAI互換HTTPエンドポイント
Copilotプランを持っている場合は、GitHubがホストするモデルとBYOKモデルを同じアプリ内で使い分けることもできます。APIキーなどの認証情報はOSの資格情報ストアに保存され、画面上には再表示されない設計です。(GitHub Docs)
ただし、BYOK対応はパブリックプレビューです。仕様や対応プロバイダーが変更される可能性があるため、本番業務の唯一の実行経路にする前に、障害時の代替手段を用意してください。(GitHub Docs)
企業でBYOKを認める場合は、少なくとも次の項目を決めておく必要があります。
- 利用を許可するモデル提供元
- APIキーの発行者と保管方法
- 個人契約のAPIキーを業務で使ってよいか
- モデル提供元に送信できるコードの範囲
- 利用リージョンとデータ保持条件
- 月額上限とレート制限
- APIキー漏えい時の失効手順
- ローカルモデル利用時のPC要件
BYOKはCopilot料金を不要にする仕組みではありますが、外部モデルのAPI料金やローカルモデルを実行するための計算資源は別途必要です。
導入テストで確認すべき項目
GitHub Copilot appの評価では、回答精度だけを見ると不十分です。認証、ワークツリー、コマンド実行、CI、費用、情報管理までを一連の流れとして確認します。
| テスト項目 | 実施内容 | 合格と判断する基準 |
|---|---|---|
| アカウント認証 | 業務用アカウントでサインイン | 意図した組織・リポジトリだけが表示される |
| プラン・ポリシー | アプリ起動とセッション開始 | Business・EnterpriseでCLIポリシーエラーが出ない |
| 非公開リポジトリ | テスト用のPrivateリポジトリを追加 | 必要な範囲だけ読み書きできる |
| Quick chat | リポジトリ概要を質問 | ブランチを作らず回答できる |
| フルセッション | 小規模なテスト追加を依頼 | 専用ブランチとワークツリーに変更が作成される |
| ビルド・テスト | lint、単体テスト、ビルドを実行 | ローカルとCIの両方で成功する |
| 並列セッション | 同じリポジトリで2つの作業を実行 | ポート、DB、キャッシュ、ファイルが衝突しない |
| PR作成 | エージェントの変更からPRを作成 | レビューと必須チェックを経由できる |
| AIクレジット | 同じ規模のタスクを複数回実行 | 想定コストと利用量の範囲に収まる |
| BYOK | APIキーとエンドポイントを設定 | 認証失敗、上限超過、接続断を適切に検知できる |
| セキュリティ | シークレット検査と依存関係検査 | 秘密情報や不審な依存関係が含まれない |
| 障害報告 | デバッグログを取得 | 機密情報を除去してから共有できる |
最初のテストに向くタスク
初回評価では、次のような影響範囲が限定された作業が適しています。
- 既存関数への単体テスト追加
- READMEの誤字修正
- lintエラーの修正
- 入力値チェックの追加
- 小規模なリファクタリング
- 失敗しているテストの原因調査
- Issueの内容から実装計画だけを作成
データベーススキーマの変更、認証方式の変更、インフラ構成の変更、本番デプロイなどは、初回テストには向きません。
失敗しやすいポイント
Copilotのライセンスはあるがアプリを利用できない
BusinessまたはEnterpriseでは、ライセンスが割り当てられていても、Copilot CLIポリシーが無効ならアプリを利用できません。
利用者側で再インストールを繰り返す前に、管理者へポリシーを確認してください。(The GitHub Blog)
Quick chatだけで導入可否を判断する
Quick chatではワークツリーを作らないため、ビルド、テスト、ブランチ操作、PR作成の問題を見つけられません。
必ずフルセッションまで実施します。
複数セッションで同じローカル資源を使う
ワークツリーが分離されていても、ポート番号、Dockerコンテナ、データベース、クラウド上の検証環境までは自動的に分離されるとは限りません。
セッションごとにポートやリソース名を変えられる設計にすると、並列実行しやすくなります。
無料プランでもモデルを自由に選べると考える
Copilot FreeとStudentでは、Autoが唯一のモデル選択方式となる場合があります。モデルを固定した検証や、モデル間の比較を行う場合は、対象プランの条件を先に確認してください。(The GitHub Blog)
「公開コードとの一致をブロック」で完全に防げると考える
GitHubの公式ドキュメントには、GitHub Copilot appでは「Suggestions matching public code」がBlockに設定されていても、公開コードと一致または近似するコードを生成する可能性があると記載されています。(GitHub Docs)
そのため、企業利用ではポリシー設定だけに依存せず、次の対策を組み合わせる必要があります。
- 人による差分レビュー
- ライセンスやコード由来の確認
- コードスキャン
- 依存関係の検査
- PRテンプレートでのAI利用申告
- 重要コードに対する承認者の追加
デバッグログをそのまま外部へ送る
不具合報告では、アプリのバージョン、OS、再現手順、期待結果、実際の結果、スクリーンショット、デバッグログの提出が案内されています。
ただし、/collect-debug-logsで取得するログには機密情報が含まれる可能性があります。社外へ送信する前に、リポジトリ名、ユーザー名、パス、プロンプト、コード断片、トークンなどが含まれていないか確認してください。(GitHub)
Business・Enterprise管理者が実施すべき管理策
Copilot CLIポリシーを確認する
GitHub Copilot appの利用可否は、BusinessとEnterpriseではCopilot CLIポリシーに連動します。
Organization管理者は、OrganizationのSettingsからCopilot、Policiesへ進み、機能ポリシーを確認できます。Enterprise管理者は、EnterpriseのAI controlsからCopilot関連ポリシーを管理します。Enterprise側で強制されたポリシーは、Organization側で変更できない場合があります。(GitHub Docs)
利用できないユーザーが出た場合は、次の順番で確認すると原因を切り分けやすくなります。
- ユーザーにCopilotライセンスが割り当てられているか
- EnterpriseレベルでCopilot CLIが許可されているか
- OrganizationレベルでCopilot CLIが許可されているか
- ユーザーが正しいGitHubアカウントでサインインしているか
- 対象リポジトリへの権限があるか
一括展開ではなく段階展開にする
推奨される展開順序は次のとおりです。
- 管理者と少人数の開発者だけでテストする
- Quick chatとPlanモードに限定して評価する
- テスト用リポジトリでコード変更を許可する
- PRとCIを必須にした状態で実プロジェクトへ広げる
- 利用量、品質、手戻り、セキュリティ問題を確認する
- 問題がなければ対象チームを拡大する
最初からAutopilotやAutomationsを広く許可すると、問題が発生したときに、アプリ、モデル、プロンプト、権限、リポジトリ設定のどこに原因があるのか判断しにくくなります。
AIクレジットの予算を設定する
GitHub Copilotは全プランでAIクレジットを基準とした利用量管理になっています。各プランには月間の利用枠があり、追加利用には予算設定が関係します。OrganizationとEnterpriseでは、ユーザー単位の予算管理も提供されています。(The GitHub Blog)
導入時は、単に月額料金だけを見るのではなく、次の指標を確認してください。
- 1セッション当たりのAIクレジット
- タスクの完了率
- 人が修正したコードの割合
- 再実行ややり直しの回数
- PR作成までに必要なセッション数
- 利用モデルごとの消費量
- 開発時間の削減量
- CI失敗率
- AIが生成した変更の却下率
高性能モデルを使えば必ず費用対効果が高くなるわけではありません。単純なドキュメント修正やテスト追加では軽量なモデルを使い、設計判断や複雑なデバッグだけ高性能モデルを使う運用が現実的です。
実行権限と秘密情報を制限する
GitHub Copilot appは、単にコードを表示するだけではありません。セッション内でブランチを作成し、コードを書き換え、コマンドやテストを実行できます。(GitHub Docs)
そのため、テスト端末や開発環境には、必要以上の権限を与えないことが重要です。
- 本番環境の認証情報を開発PCへ保存しない
- クラウドの管理者権限を常時付与しない
- 本番データベースへ接続できないようにする
- デプロイには人の承認を必須にする
- mainブランチへの直接プッシュを禁止する
- PRレビューとCIを必須にする
- シークレットスキャンを有効にする
- MCPサーバーや外部ツールの接続先を管理する
従来のコード補完機能よりも操作範囲が広いため、エージェントが誤った判断をしても、本番環境へ直接影響しない構成にする必要があります。
よくある疑問
Copilot FreeでもGitHub Copilot appを利用できるのか
利用できます。2026年7月7日の変更により、Copilot FreeとGitHub Educationを含む全Copilotプランが対象になりました。(The GitHub Blog)
ただし、有料プランと同じ利用枠やモデル選択が保証されるわけではありません。
有料のCopilot契約は必須なのか
必須ではありません。GitHubアカウントでサインインし、BYOKで自分のモデル提供元を設定すれば、Copilotプランなしでも利用できます。(GitHub Docs)
ただし、外部モデルのAPI料金や利用条件は、そのモデル提供元との契約に従います。
既存ユーザーは再インストールや設定移行が必要か
今回の公式告知には、既存ユーザーへ再インストールや設定移行を求める記載はありません。変更の中心は利用対象プランの拡大です。
ただし、古いビルドを使い続けるのではなく、通常のアプリ更新を行ったうえで、既存セッション、リポジトリ接続、BYOK設定などを確認するのが安全です。
Business・Enterpriseでアプリが表示されない場合はどうするか
最初にCopilot CLIポリシーを確認します。ライセンスがあっても、このポリシーが無効ならGitHub Copilot appを利用できません。(The GitHub Blog)
GitHub Enterprise Serverでも利用できるのか
初回サインイン時に「Use GitHub Enterprise」を選び、GitHub Enterprise Serverのアドレスを入力する手順が公式ドキュメントに記載されています。(GitHub Docs)
実際の利用可否は、サーバー構成、認証方式、ネットワーク、Copilot契約、管理ポリシーも含めて検証してください。
対応判断のまとめ
今回のGitHub Copilot app更新は、既存環境を壊す仕様変更ではなく、無料・教育向け利用者を含めてデスクトップアプリの入口を広げる変更です。
個人利用者は、Copilot Freeでも試せるようになったため、まずQuick chatでリポジトリの理解度を確認し、その後、テスト追加などの低リスクなタスクをPlanモードで実行するとよいでしょう。
既存の有料プラン利用者には緊急の移行作業はありません。現在のIDE拡張機能やCopilot CLIを維持しつつ、複数エージェントの並列作業やPR管理が必要な場合にGitHub Copilot appを追加する判断で問題ありません。
Business・Enterprise管理者は、次の順番で対応してください。
- Copilot CLIポリシーの状態を確認する
- 少人数のテスト対象者と低リスクなリポジトリを選ぶ
- ワークツリー、CI、権限、秘密情報、公開コードの扱いを検証する
- AIクレジットとBYOKの利用ルールを決める
- PRレビューと必須チェックを維持したまま段階展開する
「全プラン対応」を単なるインストール対象の拡大として見るだけでなく、これまで有料ユーザー中心だったエージェント型開発が、無料ユーザーや教育利用者にも広がった変更として捉えることが重要です。
コメント