GitHub Copilot の各プラン：階層別の機能と管理を徹底解説

GitHub Copilot の各プランの概要

GitHub はエコシステム向けに複数の明確な階層を提供しています。特筆すべきは、2026 年 6 月に従量課金の展開が完了し、従来の「Premium Request Unit（PRU）」枠が GitHub AI Credits に置き換わる点です。

新制度では、基本的なコード補完と「Next Edit」提案は引き続き無制限で、クレジットを消費しません。

一方で、マルチファイルのチャット、エージェント的なワークフロー、長時間のコーディングセッション、深いコードレビューなどの高度な操作は、各モデルの公開 API レートに基づくトークン消費（入力、出力、キャッシュトークン）に応じて AI Credits を消費します。

ベースの月額サブスクリプション価格自体は据え置きですが、この変更によって、管理者は超過分の予算計画や実利用の監視方法を見直す必要があります。

個人プラン：Free、Student、Pro、Pro+

個人向けの各階層は、モデルアクセスの範囲、使用上限、実験的機能で違いがあります。たとえば Free は基礎的な探索に向きますが、Pro+ は AI 支援アプリ開発向けに調整された環境である GitHub Spark にアクセスできます。

現在、Pro、Pro+、Student などの GitHub 個人有料アカウントの新規登録は一時停止中です。既存アカウントは Pro から Pro+ にアップグレードできますが、GitHub が新しい従量制の AI Credits 課金へ完全移行を終えるまで、新規アカウントの申し込みはできません。

Business と Enterprise

Business と Enterprise の領域は、GitHub Copilot を IDE 拡張から、完全に監査可能なエンタープライズインフラ資産へと位置づけ直します。

GitHub Copilot Business には、管理に不可欠な機能が導入されています：

• 席の一元的な割り当てと取り消し
• 組織全体のポリシーベースライン
• 体系的な監査ログとコンプライアンスイベントの追跡
• コンテンツおよびリポジトリのファイル除外
• 商用の知的財産（IP）保障

GitHub Copilot Enterprise では、さらに制御と機能が拡張されます：

• Copilot Spaces：社内ドキュメント、Wiki、体系的なコーディング標準をもとに Copilot にプロンプトできるナレッジハブ機能
• GitHub.com Chat の強化統合
• 子組織にわたる階層的なポリシー継承

GitHub Copilot Enterprise の利用には、GitHub Enterprise Cloud の有効なサブスクリプションが必要です。GitHub Enterprise Cloud はユーザーあたり月額 $21、Copilot Enterprise ライセンスはユーザーあたり月額 $39 のため、Enterprise の実質的な最低コストはユーザーあたり月額 $60 です。 これは GitHub Copilot Business には当てはまらず、GitHub Free や GitHub Team プランの組織でも単独で購入できます。

Enterprise レベルのポリシー継承などは利用できませんが、IP 保障、監査、ファイル除外、組織ポリシー管理は享受できるため、中規模のエンジニアリングチームには有力な選択肢です。

Enterprise の導入を検討している場合は、GitHub Copilot Enterprise ガイドで、Copilot Spaces や新しい Usage Metrics API などの使い方を確認してください。

個人プランと Business プランの違い

データの取り扱い、IP 保障、課金が、個人とビジネスの大きな分岐点です。ユーザー向けの追加機能も重要ですが、個人の Pro ライセンスを束ねて管理するのか、Business を契約するのかを決める際には、これらの違いを正しく理解することが不可欠です。

データ取り扱いと学習の既定

独自のシステムを扱うチームにとっては、データプライバシーが、個人プランと Business の分水嶺になることが多いです。

2026 年 4 月、GitHub は個人向け Copilot プランにおけるインタラクションデータ収集の扱いを変更しました。Free、Pro、Pro+ のユーザーでは、ユーザーが明示的にオプトアウトしない限り、インタラクションデータがモデル学習に利用されるのが既定になりました。

AI 学習に使用されるものを正しく把握するため、「保存されているコード」と「インタラクションデータ」の違いを確認しておきましょう。

• 保存されているコード：プライベートリポジトリに保存されている生のコードは、公開の学習データセットに読み込まれたり取り込まれたりしません。
• インタラクションデータ：プロンプト、チャットクエリ、カーソルのコンテキスト、IDE API を通じて送信される編集中の周辺コードブロック、提案の受け入れ指標、フィードバックログなどを含みます。

Business と Enterprise の契約では、インタラクションデータがいかなる状況でも学習に使用されないことが厳格に保証されています。ユーザーによる手動操作は不要です。

データの活用方法や Copilot の問題解決について詳しく知りたい場合は、GitHub Copilot のプライバシーとトラブルシューティングガイドをおすすめします。

IP 保障（インデムニティ）

GitHub Copilot Business と Enterprise には、生成コードに対する知的財産（IP）保障が含まれます。個人プランには含まれません。

実務的には、保障とは、生成コードが知的財産上の紛争を引き起こした場合に、特定の条件下で GitHub が法的保護を契約上提供することを意味します。すべての法的リスクがなくなるわけではありませんが、商用ソフトウェアチームにとって責任分担の議論は大きく変わります。

クライアント向けにコードを納品するフリーランサーは、この点に注意を払うべきです。「個人の生産性ツール」と「組織に支えられた開発プラットフォーム」の違いは、契約や商用納品が絡むと非常に現実的な問題になります。

課金、席（シート）、AI Credits への移行

個人向けの課金はセルフサーブ方式で、個々の個人アカウントに直接ひも付きます。Business では管理者が席を付与して請求も一元化します。さらに、個々のユーザーが独立したクレジットバケットを扱うのではなく、組織はユーザー数に応じて毎月の AI Credits をプールします。

Enterprise ではさらに細かい制御が可能で、厳密な予算上限、コストセンターのグルーピング、部門単位の割当などにより、ある開発チームの重いエージェントワークフローが、企業全体のクレジットを使い果たすことを防げます。

SKU とプライバシーの考慮事項

データプライバシー保護および SKU の違いを理解することは重要です。各階層におけるデータフローのアーキテクチャ境界、法的保護、追跡について、以下に要約します。

2026 年 4 月の学習ポリシー変更

個人プランでオプトインからオプトアウトへ移行したことは、コンプライアンス漏えいの主因になり得ます。アクティブな IDE セッション中に自動収集されるインタラクションデータには次が含まれます。

• 詳細なチャット履歴とプロンプトのコンテキスト
• 複数行のコード提案とローカルでの受け入れ率
• エディターのアクティブなカーソルのコンテキスト（隣接するファイルの文脈、import 文、開いているタブの変数定義を取り込むことが多い）

たとえば、開発者が企業のリポジトリ内で個人の Copilot Pro アカウントを使って作業している場合、学習が有効のままだと、その作業セッションに結びついたインタラクションデータが GitHub の学習エコシステムに入る可能性があります。これが組織が Business を採用する一般的な理由です。

プライバシー要件に合った SKU の選び方

業務レベルに応じて、必要な SKU は異なります。

• ソロ開発者／副業プロジェクト：Free または Pro が柔軟です。独自コードを扱う場合は、個人のプライバシー設定でオプトアウトしてください。
• フリーランサー／受託開発：Business は防御的なバリアを提供します。クライアント契約では外部 LLM へのデータ送信を明示的に禁じることが多く、専用の組織席は契約を保護します。
• コンプライアンス要件のある企業チーム：Business は標準的な前提となり、データパイプラインの分離と管理ガバナンスを確保します。
• 規制業界（金融、ヘルスケア）：Enterprise が一般的に必須で、特化したセキュリティ構成、厳密なデータレジデンシー要件、ローカライズされたファインチューニング層との統合が可能です。

Copilot から特定ファイルを除外する

GitHub Copilot のファイル除外ルールセットを実装することは、環境を防御的に保護する最も効果的な方法のひとつです。コンテンツ除外により、ローカルの IDE エージェントが特定ファイルの内容を処理できなくなり、インライン補完、チャット、バックグラウンドのエージェント処理から完全に不可視になります。

なお、GitHub Copilot CLI、Copilot のクラウドエージェント、および IDE の Copilot Chat における Agent モードは、コンテンツ除外をサポートしていません。

除外ルールの設定

管理チームは、組織設定（Organization Settings）の全体パネル、または個別のリポジトリ設定のいずれかで除外設定を適用できます。右上のSettings ボタンから対象のリポジトリや組織の設定に進んでください。

サイドバーの Copilot 設定で「Code and automation」を選択します。次に「Paths to exclude in this repository」ボックスに、以下のように除外を記入します。

# Ignore the /src/some-dir/kernel.rs file in this repository.
- "/src/some-dir/kernel.rs"

# Ignore files called secrets.json anywhere in this repository.
- "secrets.json"

# Ignore all files whose names begin with secret anywhere in this repository.
- "secret*"

# Ignore files whose names end with .cfg anywhere in this repository.
- "*.cfg"

# Ignore all files in or below the /scripts directory of this repository.
- "/scripts/**"

組織レベルでのリポジトリ指定も同様ですが、設定項目は「Repositories and Paths to exclude」の下にあり、次の形式を使います。

REPOSITORY-REFERENCE:
  - "/PATH/TO/DIRECTORY/OR/FILE"
  - "/PATH/TO/DIRECTORY/OR/FILE"
  - …

設定の一部として REPOSITORY-REFERENCE を保持することが重要です。共通の設定ベースラインとしては、ハードコードされた認証情報、本番オーケストレーションのプロファイル、機微な独自アルゴリズムのモジュール、または厳格に規制されたコンプライアンスフォルダーを優先してください。

Copilot 機能全体での除外適用方法

除外に一致した場合、データの分離は Copilot のすべてのサブシステムで完全に適用されます。

• インライン補完：当該ファイル内でのコンテキスト生成や、隣接ファイルへのコンテキスト提供がブロックされます。
• Copilot のチャット／エージェント：組織ポリシー制限によりファイルをレビューできない旨の通知が返されます。

標準的なローカル IDE エンジンの動作は同じです。テキスト解析、シンタックスハイライト、ローカルの IntelliSense などの利便性機能は通常どおり動作します。除外レイヤーは Copilot への外部テレメトリストリームに明示的に適用されるためです。

管理者はステージング用のリポジトリでパスパターンを徹底検証してください。ワイルドカードの誤りはオープンなまま失敗し、隔離したいデータが露出するおそれがあります。

組織全体のポリシー管理

GitHub Copilot の組織ポリシー管理を適用することで、企業のセキュリティが個々の開発者の好みではなく、管理チームによって決定されるようになります。

利用可能なポリシー設定

組織は開発者に対して以下を制御できます。

• 機能トグル：開発環境内の Copilot Chat、コマンドラインインターフェース（Copilot CLI 経由）、高度なエージェント型コードレビューシステムを全社的に有効化／抑止。
• 公開コードフィルター：GitHub 上のオープンソースリポジトリに近似するコード提案の返却をブロックし、オープンソースライセンス準拠リスクを低減する法的コントロール。
• モデル選択の制限：開発者が選択できるモデル（例：特定の GPT や Claude のバリアント）を制限し、レイテンシ、クレジット消費、性能を管理。GitHub プラットフォームで利用可能なモデルの詳細は、実践ガイドGitHub Modelsを参照してください。
• カスタム組織インストラクション：Markdown 形式の標準ポリシー文書を注入し、企業のコーディングパターン、セキュリティフレームワーク、アーキテクチャ指針を開発者のすべてのプロンプトに付加します。

GitHub の組織や権限モデルに不慣れなチームは、Intermediate GitHub Concepts コースが参考になります。コマンドラインツールを拡充するエンジニアリンググループは、GitHub Copilot CLI チュートリアルもご覧ください。

Enterprise レベルのポリシー継承

大規模な企業環境では、ポリシーエンジンは厳格な階層継承に従います： Enterprise ポリシー > Organization ポリシー > ユーザー設定

Enterprise 管理者は、チームなど小規模な事業単位にわたりポリシーを全面ロックしたり、組織ごとの一部上書きを許可したり、完全に委譲したりできます。例えば、エンタープライズ全体で特定のモデル利用を制限するグローバル設定を持たせることができます。

一方でチームレベルでは、金融サービス部門には厳格な公開コードフィルターを課し、社内のソフトウェア R&D 部門にはより柔軟な実験を許可するといった運用も可能です。

監査ログ

コンプライアンス監査でソフトウェアサプライチェーンの検証が必要な場合や、セキュリティチームがデータ漏えいを追跡する場合、GitHub Copilot はプラットフォーム変更の記録を監査します。

監査ログにおける Copilot イベント

システムは管理操作の網羅的な台帳を記録し、次をログに残します。

• 明示的な席の割り当て、取り消し、請求グループの変更
• 公開コード重複フィルターの変更
• ファイル／ディレクトリの除外パターンの変更
• 機能の有効化状態（例：エージェント型コードレビューの有効化）

粒度はサブスクリプションに依存します。Business は組織スコープのアクションイベントが中心で、Enterprise は組織横断のフォレンジックテレメトリを解放します。

検索、フィルタ、エクスポート

監査ログは組織設定パネルからネイティブにアクセスできます。管理者は以下のようなアクションクオリファイアでインターフェースをクエリできます。

# Filter logs to identify who adjusted Copilot access privileges
action:copilot.cfb_seat_assignment_created

# Identify changes made to systemic exclusions within a date window
action:copilot.content_exclusion_updated created:2026-05-01..2026-05-31

Enterprise アカウントは、これらの監査イベントを外部のセキュリティ情報イベント管理（SIEM）システム（Splunk や Datadog など）へ直接ストリーミングし、自動アラートや改ざん不能な集中保管を実現できます。

REST API で Copilot の席を管理する

UI ダッシュボードからの手動プロビジョニングは小規模チームには十分ですが、大量の企業オンボーディングではすぐに破綻します。Github Copilot REST API の seats エンドポイントを使えば、ID とアクセス管理を完全にコードとして扱えます。

これは Copilot 管理で特に好ましい点で、ライセンス管理をエンジニアリングチームがきれいに自動化できるようになります。

主要な API エンドポイント

一般的な API ワークフローは以下のとおりです。

• 席の割り当て一覧の取得
• 席の割り当て
• 席の削除
• 使用状況メトリクスの取得
• 組織の Copilot 設定の読み取り

認証には一般的に以下が必要です：

• きめ細かな個人用アクセストークン
• GitHub App の権限
• 組織管理者の権限

これらの管理経路にアクセスするには、拡張された admin:org スコープを持つ Personal Access Token（PAT）で統合スクリプトを認証するか、組織レベルの Copilot 管理権限を明示的に付与した GitHub App を通じて実行する必要があります。

プログラマティックなプラットフォーム統合を詳しく学ぶには、GitHub Foundations スキルトラックの受講をおすすめします。

一般的な自動化パターン

実践的なパターンには以下があります。

• 自動アイデンティティオンボーディング：人事情報システム（Workday や Okta など）を Webhook 経由で GitHub に直接接続。エンジニアが指定チームに加入すると、スクリプトが POST を発行して Copilot ワークスペースを自動プロビジョニングします。

• 非アクティブ席の回収：スケジュールされた Cron スクリプトが API 経由で席の利用状況を照会。30 日以上 Copilot を利用していないユーザーがいれば、DELETE でライセンスを回収し、企業のクレジットプールを保全します。

• 財務ダッシュボード：日次の割当と消費テレメトリを取得して、Tableau などの社内 BI プラットフォームに連携し、部門ごとのコストセンター按分を明確化します。

例：Python で Copilot の席を割り当てる

以下のスクリプトは、Python を使って特定の開発者に組織の席をプログラム的に割り当てる方法を示します。

	import requests
	# Identity Configuration
TOKEN = "YOUR_ORGANIZATION_ADMIN_PAT"
ORG = "your-corporate-org"
USERNAME = "target-developer-user"

url = f"https://api.github.com/orgs/{ORG}/copilot/billing/selected_users"

headers = {
    "Authorization": f"Bearer {TOKEN}",
    "Accept": "application/vnd.github+json",
    "X-GitHub-Api-Version": "2022-11-28"
}

payload = {
    "selected_usernames": [USERNAME]
}

response = requests.post(url, json=payload, headers=headers)

if response.status_code == 201:
    print(f"Successfully allocated Copilot seat to {USERNAME}.")
else:
    print(f"Failed allocation. Status: {response.status_code}")
    print(response.json())

まとめ

GitHub Copilot のプラン構成は、価格表だけを見ると単純に見えます。しかしチーム運用を始めると、その差はかなり本質的になります。

プライバシーの境界、学習ポリシー、監査可能性、ガバナンスは、単なるモデルアクセス以上に重要になることが多い要素です。だからこそ、GitHub Copilot の Business と Enterprise の議論は、純粋なエンジニアリングではなく、セキュリティやオペレーションの話題になりがちです。

もし今チームに助言するなら、まずガバナンス要件から整理します。

• 契約上のプライバシー保証が必要か？
• 監査ログが必要か？
• ポリシーを集中管理する必要があるか？

そのうえで、使用量と機能アクセスの最適化に取り組みます。

チームの技術力を高め、公式認定に備えるには、次の上級学習パスを探索してください。

• Software Development with GitHub Copilot コース
• AI for Software Engineering スキルトラック
• データ専門家のための GitHub 認定ガイド