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は、重要な管理機能を提供します。

• シートの一元的な割り当てと回収
• 組織全体のポリシーベースライン
• 構造化された監査ログとコンプライアイベントの追跡
• コンテンツおよびリポジトリファイルの除外
• 商用における知的財産の補償

GitHub Copilot Enterpriseは、さらにコントロールと機能を拡張します。

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

GitHub Copilot Enterpriseには、GitHub Enterprise Cloudの有効なサブスクリプションが必要です。GitHub Enterprise Cloudはユーザー1人あたり月21ドル、Copilot Enterpriseライセンスは月39ドルのため、実質的な最小コストはユーザー1人あたり月60ドルとなります。 これはGitHub Copilot Businessには当てはまらず、GitHub FreeまたはGitHub Teamプラン上の組織でもネイティブに購入できます。

組織はエンタープライズレベルのポリシー継承などの恩恵は受けられませんが、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セッション中に自動収集されるインタラクションデータのペイロードには、以下が含まれます。

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

開発者が個人の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パネル、または個別のRepository設定のいずれかで除外設定を適用できます。画面右上の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経由）、高度なエージェント型コードレビューシステムの有効／無効をグローバルに切り替え。
• Public code filter：公開OSSリポジトリと近似するコード提案をCopilotが返さないようにする法的コントロールで、OSSライセンス順守リスクを低減。
• モデル選択の制限：開発者が選択できるモデル（例：特定のGPTやClaudeのバリアント）を制限し、レイテンシ、クレジット消費、性能を管理。GitHubのプラットフォームで利用可能なモデルの詳細は、実践ガイドGitHub Modelsを参照。
• カスタム組織インストラクション：標準的なMarkdownのポリシーファイルを注入し、企業のコーディングパターン、セキュリティフレームワーク、アーキテクチャの考え方を、開発者が送信するすべてのプロンプトに付与。

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

エンタープライズレベルのポリシー継承

大規模な企業環境では、ポリシーエンジンは厳密な階層継承のカスケードに従います。Enterprise Policy > Organization Policy > User Preferences

エンタープライズ管理者は、チームなどの小規模事業単位全体にポリシーをグローバルに固定する、特定の組織単位に上書きを許可する、あるいは完全に委譲する、といった選択が可能です。たとえば、エンタープライズ全体で特定モデルの利用設定をロックすることが考えられます。

チームレベルでは、金融サービス部門には厳格なPublic code filterを適用し、社内のソフトウェアR&D部門には柔軟な実験を許容するといった運用が可能です。

監査ログ

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

監査ログに記録されるCopilotイベント

システムは管理操作の包括的な台帳を記録します。具体的には次のとおりです。

• 明示的なシートの割り当て、回収、課金グループの変更
• Public code duplication filterの変更
• ファイル／ディレクトリの除外パターンの変更
• 機能の有効化状態（例：エージェント型コードレビューの有効化）

詳細度はサブスクリプションに依存します。Businessは組織スコープのアクションイベントに焦点があり、Enterpriseでは組織横断のフォレンジックテレメトリが解放されます。

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

監査ログのストリームはOrganization Settingsパネルからネイティブにアクセスできます。管理者は特定のアクション修飾子を使ってインターフェースをクエリできます。

# 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（シート関連エンドポイント）を使えば、アイデンティティとアクセス管理を完全にコードとして扱えます。

これはCopilot管理の中でも特に気に入っている点で、ライセンス管理をエンジニアリングチームがきれいに自動化できるようになるからです。

主要なAPIエンドポイント

一般的なAPIワークフローには以下が含まれます。

• シート割り当ての一覧取得
• シートの割り当て
• シートの削除
• 利用メトリクスの取得
• 組織のCopilot設定の読み取り

認証には通常、以下が必要です。

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

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

プログラムによるプラットフォーム統合を深掘りするには、gGitHub Foundationsスキルトラックの受講をおすすめします。 

一般的な自動化パターン

実践的なパターンとしては、以下が挙げられます。

• 自動アイデンティティ・オンボーディング：人事情報システム（WorkdayやOktaなど）をWebhooksで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認定ガイド