GitHub は 2026 年 4 月 20 日、Copilot Individual プランの変更 を発表しました。Free / Pro / Pro+ の 3 階建てが整理され、それぞれの機能差と業務利用の可否が明確化されています。
受託開発の現場では「個人契約のまま業務に使う」運用が暗黙化しているチームが多く、今回の変更でライセンス整理が遅れている案件は監査リスクを抱えやすい状況です。本記事では変更点と、受託開発チームが取るべき選定基準を整理します。
変更点のサマリー
GitHub の発表によれば、今回の変更は次の 3 軸で行われています。
| 軸 | 旧 | 新 |
|---|---|---|
| プラン構成 | Individual / Business / Enterprise | Free / Pro / Pro+ / Business / Enterprise |
| Pro+ の位置付け | 不明確 | 個人開発者向けの「全機能盛り」プラン |
| 業務利用 | 個人プランでも事実上可 | Business 以上が推奨 |
特に「業務で使うなら Business を契約してね」というメッセージが従来より明確になっており、個人プランの業務流用が問題視されやすくなりました。これは Copilot AI 学習オプトアウト変更 と同じ流れで、プライバシーとライセンスのガバナンスを強化する方針の延長線上にあります。
受託開発で何が問題になるか
受託開発のチームでよくある運用が次の 3 パターンです。それぞれが今回の変更で再点検対象になります。
| 運用パターン | 問題 | 推奨対応 |
|---|---|---|
| エンジニア各自が個人 Pro を契約、領収書精算 | クライアントコードに個人プランで触る → ライセンス違反の懸念 | Business に切り替え |
| 受託会社が Business を契約、メンバーに付与 | 契約上は OK だがクライアント環境で使うと別問題 | NDA・契約書を確認 |
| クライアント側が Enterprise を契約、外注に付与 | 一見クリーンだが、退任時の権限剥奪が漏れがち | オフボーディング手順を整備 |
3 つ目の Enterprise アカウント貸与は、外注メンバーの離任時にアカウントを止め忘れるとセキュリティ事故になります。受託側からも「離任時の権限剥奪を契約書に明記する」提案を入れておくのが安全です。
選定フロー：自社チームに合うプランを選ぶ
受託で開発チームを構成するときの選定フローは次のとおりです。
1. 業務利用するか？ → No: Free / Pro でよい
→ Yes: 2 へ
2. クライアントコードに触れるか？ → No: 個人 Pro+ でも可
→ Yes: 3 へ
3. クライアントが Enterprise / Business を持っているか？
→ Yes: クライアントから付与してもらう
→ No: 受託会社で Business 契約 → 4 へ
4. データ取り扱いの NDA はあるか？ → 必ず締結この順序で判定すると、受託会社として最低限 Business を 1 契約は持つのが現実的になります。Pro+ は個人開発・OSS 用途に振った位置付けで、業務での主軸プランとしては推奨されません。
Business プランの実装上の注意点
Business プランで業務運用するときは、次の 3 つを設定で明示しておきます。
# .github/copilot.yml の例
content_exclusions:
- "**/*.env"
- "/secrets/"
- "credentials.json"
policies:
block_public_code_matches: true
ai_training_opt_out: true
audit_logging: true| 設定項目 | 用途 |
|---|---|
content_exclusions | 機密ファイルを Copilot のコンテキストから除外 |
block_public_code_matches | OSS と一致する出力を抑制（ライセンス汚染防止） |
ai_training_opt_out | 学習データ提供をオフ |
audit_logging | 利用ログを残し、監査対応に使う |
これらの設定がない状態で Business を導入すると、クライアントから「設定で守られている前提で受け入れたのに、設定が空だった」という事故が起きます。受託側が初期設定まで含めて納品するのが望ましい運用です。
クライアント案件での Copilot 利用契約書テンプレ
受託案件でクライアント環境にエンジニアを送り込むとき、契約書に次の条項を入れておくと事故が減ります。
- 使用する AI コーディング支援ツールの明示：Copilot / Cursor / Claude Code など
- 学習データ提供のオプトアウト方針：原則オフ
- 生成コードの著作権の扱い：成果物全体の著作権はクライアントへ譲渡
- 生成コードのライセンス汚染リスクの責任範囲：Block public code matches を有効にする義務
- 離任時のアカウント剥奪プロセス：72 時間以内に剥奪
Web 制作会社の選び方 でも触れたように、受託側からこの種の契約書ドラフトを先出しできると、契約交渉の主導権をこちらに引き寄せる効果もあります。
移行プロジェクトの組み方
すでに個人プラン運用が常態化しているチームを Business に切り替える場合、3 〜 4 週間のスポット案件として組めます。
| フェーズ | 期間 | 内容 |
|---|---|---|
| 棚卸し | 1 週 | 利用者・契約形態・利用範囲を一覧化 |
| 契約締結 | 1 週 | Business / Enterprise 契約・SSO 連携 |
| 設定整備 | 1〜2 週 | content_exclusions・ポリシー・監査ログ |
| 移行 | 1 週 | 個人プラン解約・Business アカウント付与 |
このスコープなら 50〜120 万円程度で受託に組み込めます。「Copilot 入れたいが社内ライセンス整理が追いつかない」という相談は意外と多く、受託の入り口案件として使いやすいテーマです。
まとめ ─ 「個人プランで業務」は終わりに
GitHub Copilot Individual プランの変更は、ツール側というよりはガバナンス側の整理です。受託開発の現場では、この機にライセンス整理を片付けてしまうのが合理的で、契約書テンプレ・初期設定・監査ログまで一式で納品できれば付加価値の高い案件になります。
弊社では Copilot を含む AI コーディング支援ツールの導入支援、契約書ドラフト、設定整備、移行プロジェクトを受託で提供しています。Copilot と Claude Code のワークフロー を併用するチーム構築も可能ですので、「ライセンスを整理したい」「クライアントから問われて困っている」というご相談は お問い合わせフォーム からお気軽にどうぞ。
