GitHub Copilotの個人プラン変更で最初に確認すべき結論は、「これからPro／Pro+／Studentに新規加入する人」「ProでOpusモデルを使っていた人」「エージェントやCLIで高負荷に使っている人」ほど影響が大きい、という点です。2026年4月20日の発表では、個人向け有料・学生プランの新規サインアップ一時停止、利用制限の強化、Copilot ProからのOpusモデル除外が示されました。既存ユーザーはすぐに契約が消えるわけではありませんが、更新前・アップグレード前・組織シートへの切り替え前に、利用上限、使えるモデル、請求タイミングを必ず確認する必要があります。(The GitHub Blog)
GitHub Copilot 個人プラン変更で何が変わったのか
今回のGitHub Copilot individual plan changesは、単なる料金表の更新ではありません。開発者の使い方、特にエージェント型の長時間タスクや並列実行が増えたことで、GitHub側がサービス品質と計算資源のバランスを取り直した変更です。
GitHubは、個人向けプランについて次の3点を明確に発表しています。Pro、Pro+、Studentプランの新規サインアップを一時停止すること。個人プランの利用制限を厳しくすること。そして、Copilot ProからOpusモデルを外すことです。(The GitHub Blog)
| 変更点 | 影響を受けやすい人 | 実務上の確認ポイント |
|---|---|---|
| Pro／Pro+／Studentの新規サインアップ一時停止 | これから有料プランやStudentプランを使い始めたい人 | Copilot Freeで始めるか、既存アカウントでアップグレード可能かを確認する |
| 個人プランの利用制限強化 | Agent mode、Copilot CLI、長時間のコード生成を多用する人 | VS CodeやCopilot CLIの上限警告、週次上限、モデル倍率を確認する |
| Copilot ProからOpusモデル除外 | ProでOpus系モデルを使っていた個人開発者 | Pro+への移行、別モデルへの切り替え、ワークフロー変更を検討する |
| 返金オプションの案内 | 変更後の条件が合わないPro／Pro+利用者 | May 20までに請求設定からキャンセル・返金手続きを確認する |
新規加入停止の対象はPro、Pro+、Student
最初に影響を受けるのは、まだGitHub CopilotのPro、Pro+、Studentプランに入っていないユーザーです。GitHubは、既存の有料顧客向けのサービス品質を優先するため、Pro、Pro+、Studentの新規サインアップを一時停止すると説明しています。一方で、Copilot Freeは新規サインアップ可能で、既存ユーザーはプラン間のアップグレードや変更が可能とされています。(The GitHub Blog)
ここで誤解しやすいのは、「有料プランが廃止された」と読むことです。発表内容は、少なくとも2026年4月20日時点では、新規サインアップの一時停止と既存ユーザー向け条件の変更です。既にProやPro+を使っている人は、まず自分の現在のプラン、次回更新日、使えるモデルを確認してください。
特に学生ユーザーは注意が必要です。新たにStudentプランへ申し込もうとしている場合、従来と同じ流れで使い始められない可能性があります。学習用途でCopilotを検討しているなら、Copilot Freeで足りるか、学校・企業・OSS活動を通じた別の提供形態があるかを確認するのが現実的です。
利用制限は「リクエスト数」だけでなくトークン消費でも見る必要がある
今回の変更で重要なのは、GitHub Copilotの上限が「月に何回使えるか」だけでは判断できなくなっている点です。GitHubの説明では、Copilotにはセッション上限と週次、つまり7日単位の上限があり、週次上限はトークン消費量を基準にします。上限に近づくとVS CodeとCopilot CLIで警告が表示されるとされています。(GitHub)
たとえば、短い補完や簡単な質問だけなら影響が小さくても、次のような使い方では上限に早く近づく可能性があります。
| 使い方 | 上限に近づきやすい理由 | 対策 |
|---|---|---|
| 大規模リポジトリの調査をエージェントに任せる | 読み取るファイル量と推論ステップが増える | 対象ディレクトリや目的を絞って依頼する |
| 複数のAgent modeやCLIタスクを並列実行する | 同時にトークンを消費しやすい | 優先度の高いタスクから順に実行する |
| 高性能モデルを軽い作業にも使う | モデル倍率が大きいほど上限に早く到達する | 簡単な説明や小修正は軽量モデルやAutoに任せる |
| 長い会話で要件定義から実装まで続ける | コンテキストが肥大化し、入出力トークンが増える | 作業単位を分け、要約してから次のタスクへ進む |
GitHubは、上限に近づいた場合の対策として、より小さい倍率のモデルを使う、plan modeを使う、並列ワークフローを減らす、必要に応じてPro+へアップグレードする、といった方法を案内しています。週次上限に達してもプレミアムリクエストが残っている場合、Auto model selectionで継続利用できるケースがありますが、任意のモデル選択は週次期間のリセットまで再有効化されないと説明されています。(GitHub Docs)
Copilot ProではOpusモデルが使えなくなった
モデル面で最も大きな変更は、Copilot ProからOpusモデルが外れたことです。GitHubは、OpusモデルはCopilot Proでは利用できなくなり、Opus 4.7はPro+で引き続き利用可能と説明しています。また、Opus 4.5と4.6についてもPro+から削除予定であることに触れています。(The GitHub Blog)
実務上、これは「Proで高度な長時間推論や複雑なエージェント作業を任せていた開発者」に直接響きます。たとえば、複数ファイルにまたがるリファクタリング、既存コードベースの仕様調査、失敗したテストの根本原因分析、CLI経由の長い実装タスクなどでOpus系モデルを指定していた場合、同じプロンプトでも出力品質や安定性、作業時間が変わる可能性があります。
ただし、すべての開発者がPro+へ移行すべきという意味ではありません。日常的な補完、短い質問、PR説明文の作成、単体テストのたたき台作成が中心なら、ProやFree、またはAuto model selectionで十分な場合もあります。判断基準は「最高性能モデルが必要か」ではなく、「自分の開発フローで上限やモデル制限が作業停止につながるか」です。
誰が最初に影響を受けるのか
影響の大きさは、契約状態と使い方で分かれます。今回のGitHub Copilot個人プラン変更で、特に早めに確認すべきユーザーは次の層です。
| ユーザー | 影響度 | 具体的に起こりやすいこと |
|---|---|---|
| これからPro／Pro+へ新規加入したい人 | 高 | 新規サインアップが一時停止され、Freeから始める必要が出る |
| 新たにStudentプランを使いたい学生 | 高 | Studentプランの新規サインアップ停止の影響を受ける |
| Copilot ProでOpusモデルを使っていた個人開発者 | 高 | 指定していたモデルが使えず、別モデルやPro+検討が必要になる |
| Agent modeやCopilot CLIを長時間使う人 | 高 | セッション上限や週次上限に当たりやすくなる |
| 既存のPro+利用者 | 中〜高 | Proより高い上限はあるが、モデル整理や上限警告の確認が必要 |
| Copilot Free中心のライトユーザー | 低〜中 | 新規サインアップ停止の直接影響は小さいが、有料移行の選択肢が変わる |
| 組織のCopilot Business／Enterprise管理者 | 中 | 個人プラン利用者を組織シートへ移す場合、個人契約の自動キャンセルやポリシー変更を確認する必要がある |
エンジニアリングリードは、個人ユーザー本人よりも別の観点で注意が必要です。個人契約でCopilot ProやPro+を使っていたメンバーに、組織のCopilot BusinessまたはEnterpriseシートを割り当てると、個人プランは自動キャンセルされ、残り期間分の按分返金が発生し、そのユーザーは組織ポリシーの下でCopilotを使うことになります。(GitHub Docs)
更新前に確認すべきチェックリスト
更新前に見るべき項目は、料金だけではありません。Copilotを「補完ツール」として使うのか、「実装を任せるエージェント」として使うのかで、最適なプランは変わります。
| 確認項目 | 見る場所・確認方法 | 判断基準 |
|---|---|---|
| 現在のプラン | GitHubのSettings → Billing & licensing → LicensingまたはPlans and usage | Free、Pro、Pro+、組織シートのどれで使っているか |
| 次回更新日 | Billing設定 | 返金・キャンセル・ダウングレード判断の期限を把握する |
| 上限警告 | VS Code、Copilot CLI | 週の途中で75%前後の警告が出るなら使い方の見直しが必要 |
| 使っているモデル | IDEやgithub.comのモデルピッカー | Opus依存があるならPro+や代替モデルを検討する |
| 作業内容 | 直近1〜2週間の利用実態 | 補完中心か、エージェントによる長時間タスク中心か |
| 組織シートの有無 | GitHub組織設定、管理者への確認 | 個人契約が不要になる可能性がある |
| キャンセル・返金可否 | Billing設定のManage subscription | 特別な返金案内の期限と通常の請求ルールを分けて確認する |
GitHubのアカウント設定では、現在のCopilotプランの確認、アップグレード、ダウングレード、キャンセルができます。ただし、組織からCopilotアクセスを付与されている場合、個人側でプランを変更できないケースがあります。(GitHub Docs)
シート変更前に確認すべきこと
チームや企業でGitHub Copilotを導入している場合、「個人プランから組織シートへ移す」作業は便利ですが、請求とアクセスの切り替わりを理解しておく必要があります。
Copilotのシートは、Copilot BusinessまたはCopilot Enterpriseプランで特定のユーザーアカウントに割り当てるライセンスです。組織オーナーは、GitHubの組織設定またはREST APIでシートを管理できます。(GitHub Docs)
| 操作 | 請求への影響 | アクセスへの影響 |
|---|---|---|
| 組織シートを追加 | 現在の請求サイクルの残り期間分が按分課金される | 割り当て後すぐに利用可能 |
| 組織シートを削除 | 請求はサイクル終了時まで続き、削減は次サイクルから反映 | シートの扱いにより、サイクル末まで使える場合と即時失効の場合がある |
| 個人Pro／Pro+利用者へ組織シートを割り当て | 個人プランは自動キャンセルされ、残期間分が按分返金される | 組織ポリシーの下でCopilotを利用する |
| 組織レベルでCopilotを無効化 | 対象ユーザーの請求停止はサイクル終了時 | 対象ユーザーは即時アクセスを失う |
GitHubの請求ドキュメントでは、シート追加は按分課金、削除は次の請求サイクルから反映されると説明されています。また、請求サイクルのタイムゾーンにはUTCが使われるため、日本時間で月末に作業しても、GitHub上では次の請求サイクル扱いになる可能性があります。(GitHub Docs)
シート変更で失敗しやすいのは、退職者や異動者のシートを「外したつもり」でも請求サイクル上は次回まで残るケースです。月末・四半期末に棚卸しするのではなく、スプリント終了や人員変更が確定したタイミングで、早めにシート管理を更新する運用にすると無駄な請求を避けやすくなります。
Proのままか、Pro+へ上げるか、Freeへ戻すかの判断基準
プラン判断は、月額料金だけでなく「作業停止リスク」で考えるのが実務的です。上限に当たって数時間作業が止まる、重要なモデルが使えない、組織ポリシーと個人契約が重複する、といった状況では、安いプランを選んでも開発効率が落ちます。
| 選択肢 | 向いているケース | 向いていないケース |
|---|---|---|
| Copilot Freeを使う | まず試したい、補完や短い相談が中心 | 毎日業務で使う、CLIやエージェントを多用する |
| Copilot Proを継続 | 補完、チャット、軽〜中程度の開発支援が中心 | Opusモデル前提、週次上限に頻繁に近づく |
| Copilot Pro+へ移行 | 高度なモデル、エージェント作業、長時間タスクを重視 | 利用頻度が低い、軽い補完だけで十分 |
| 組織シートへ移行 | チーム標準化、管理ポリシー、請求一本化が必要 | 個人で自由にモデルや設定を管理したい |
| キャンセル・返金を検討 | 変更後の条件が業務に合わない | 代替手段を準備せず、急に解約すると作業が止まる |
GitHubは、変更が合わないProまたはPro+ユーザーに対して、現在のサブスクリプション残期間分の返金を受けるキャンセル手順を案内しています。この返金オプションはMay 20まで利用可能とされ、発表ページでは2026年4月21日に返金ポリシー表現と手順が更新されたことも記載されています。(The GitHub Blog)
通常のキャンセルでは、現在の機能へのアクセスは請求サイクル終了まで続き、サイクル終了後にCopilot Freeへ移行すると説明されています。特別な返金案内と通常のキャンセルルールを混同しないようにしてください。(GitHub Docs)
開発者が今日やるべき具体的な確認手順
まず、GitHubのSettingsからBilling & licensingを開き、現在のCopilotプランと次回更新日を確認します。組織から付与されたCopilotを使っている場合は、個人設定だけでなく、組織管理者にシートの種類とポリシーを確認してください。
次に、普段どおりの作業を1週間単位で見直します。VS CodeやCopilot CLIで上限警告が出ていないか、特定のモデルを選べなくなっていないか、Auto model selectionに切り替えると品質が許容範囲かを確認します。GitHubは、上限に近づいたときの対策として、小さい倍率のモデル、plan mode、並列ワークフローの削減を挙げています。(GitHub Docs)
最後に、次の3つに分けて判断します。
| 判断 | 取るべき行動 |
|---|---|
| 今のプランで問題ない | 更新日と上限警告だけを定期確認する |
| 上限やモデル制限で作業が止まりそう | Pro+、組織シート、ワークフロー変更を比較する |
| 変更後の条件が合わない | May 20までの返金オプションと通常キャンセル条件を確認する |
失敗しやすいポイント
GitHub Copilotのプラン変更で最も多い失敗は、「プレミアムリクエストが残っているから大丈夫」と考えることです。GitHubは、プレミアムリクエストと利用制限は別物だと説明しています。プレミアムリクエストが残っていても、トークンベースの週次上限に達する可能性があります。(GitHub)
もう一つの失敗は、モデル依存を棚卸ししないことです。たとえば、チーム内の一部メンバーだけがOpus系モデルを前提にプロンプトや手順を作っていた場合、同じ手順を他のメンバーが実行しても同じ結果にならないことがあります。プロンプトテンプレートや開発標準に「使用モデル」を書いているなら、今回の変更を反映して更新してください。
シート管理でも注意が必要です。個人Pro／Pro+を持つメンバーに組織シートを付与すると個人プランが自動キャンセルされるため、本人が個人契約で使っていた設定やモデル選択が、組織ポリシーにより変わる可能性があります。移行前に、コード参照フィルター、利用可能モデル、データ利用ポリシー、社内ルールを確認しておくと混乱を防げます。
まとめ：更新前に「契約」「上限」「モデル」「シート」を確認する
2026年4月20日のGitHub Copilot個人プラン変更では、Pro／Pro+／Studentの新規サインアップ一時停止、個人プランの利用制限強化、Copilot ProからのOpusモデル除外が大きなポイントです。最初に影響を受けるのは、新規加入予定者、Opusモデルを使っていたProユーザー、エージェントやCLIを高負荷で使う開発者です。
次に取るべき行動はシンプルです。GitHubの請求設定で現在のプランと更新日を確認し、VS CodeやCopilot CLIで上限警告の有無を見て、普段使っているモデルが変更後も使えるか確認してください。チーム利用の場合は、個人契約と組織シートの重複、請求サイクル、UTC基準の締め日まで含めてチェックすることが重要です。
GitHub Copilotは、補完ツールからエージェント型の開発支援へ役割が広がっています。だからこそ、プラン選びも「料金が安いか」だけでなく、「自分やチームの開発フローを止めないか」で判断するのが、更新前の最も実用的な見直し方です。
コメント