GitHub Copilotの従量課金移行が2026年6月1日に始まると、席種の判断は『一律でBusinessかEnterpriseか』ではなくなります。いま必要なのは、誰がAI creditsを多く消費し、誰に高い上限と新機能を持たせると投資回収しやすいかを、役割と利用パターンで切り分けることです。
先に結論を言うと、Enterprise席を優先すべきなのは、Copilot cloud agentやcode reviewを日常的に回す開発リード、複数リポジトリをまたぐ大規模改修を任せる中核開発者、そして部門横断で標準化や監査の責任を持つ管理者です。多くの一般利用者はBusiness席のままでも足りるため、全員昇格よりも選抜配分のほうが失敗しにくいです。
結論: Enterprise席は全員ではなく3タイプに絞る
GitHub公式は、Copilot Enterpriseの価値を『より多いAI credits』と『新機能や新モデルへの早期アクセス』で説明しています。特にbacklog消化、PR高速化、技術的負債の削減のように、エージェント的な使い方で成果を出したい組織では、Enterprise席の恩恵が出やすい構造です。
逆に、コード補完や軽いチャットが中心の利用者まで全員をEnterpriseへ上げる必要はありません。コード補完とnext edit suggestionsは有料プランで無制限のままなので、日常の小さな補助が主目的ならBusiness席で十分なケースが多いです。
BusinessとEnterpriseの差分は料金より配分ロジックで見る
2026年5月30日時点のGitHub Docsでは、Copilot Businessは1ユーザー月額19ドルで1,900 AI credits、Copilot Enterpriseは1ユーザー月額39ドルで3,900 AI creditsです。既存顧客には2026年6月1日から9月1日までの移行期間があり、Business 3,000、Enterprise 7,000のプロモーション枠が案内されています。
重要なのは、これらのAI creditsがユーザー個別ではなく企業単位でプールされる点です。重い利用者は軽い利用者の未使用分を使える一方、追加利用を許可しているとプール超過後は従量課金へ進みます。つまり席種配分は『個人の快適さ』より『誰にプールを優先配分するか』という予算設計の問題です。
Enterprise席へ昇格させる判断基準
実務では、まずAI usage dashboardか利用レポートで上位消費者を洗い出します。その上で、1. cloud agentやagent modeを継続利用しているか、2. code reviewや大規模リファクタのように高コンテキスト作業が多いか、3. その人の作業が他メンバーの待ち時間やレビュー詰まりを解消しているか、の3条件で見ます。
移行期の目安としてGitHubは『Copilot Businessで月800件超のpremium requestsを使う人はEnterpriseのほうが割安になりやすい』と案内しています。ただし6月1日以降はAI credits基準へ移るため、800件という数字を固定ルールにせず、実際のcredits消費と成果の両方で再判定する運用が安全です。
席種配分の実務パターン
GitHub Enterprise Cloudでは、enterprise ownerが組織ごとにCopilot BusinessかCopilot Enterpriseを選べます。したがって、全社で一括昇格するより、AI駆動開発を強く進める組織だけEnterpriseへ切り替え、他組織はBusinessを維持する二層構成が作りやすいです。
一方で、enterprise直下でユーザーやteamへ直接割り当てられるのは現時点ではCopilot Businessだけです。Enterprise席を特定ユーザーへ配りたい場合は、そのユーザー群を新しい組織へ集約してEnterpriseを有効化する運用がGitHub公式の案内です。同一enterprise内で同じユーザーが複数組織から席を受けても請求は1回で、BusinessとEnterpriseが重なった場合はEnterprise側が優先されます。
承認フローは予算より先にガードレールを決める
席の昇格申請を通す前に、予算担当と情シスで3つ決めておくべきです。第一に、universal user-level budgetを席単価より上に置くことです。GitHubはBusinessなら19ドル、Enterpriseなら39ドルより上に設定しないと、プールの融通が効かず、重い利用者を早めに止めてしまうと説明しています。
第二に、enterprise budgetかcost center budgetへ『Stop usage when budget limit is reached』を必ず付けます。通知だけで止めない設定だと超過課金が走ります。第三に、予算を使い切っても安いモデルへ自動フォールバックはされないので、止まって困るユーザーを誰にするかを先に決める必要があります。購買承認は席単価の差額ではなく、停止時の業務影響まで含めて出すほうが通りやすいです。
導入前に確認したい運用チェックリスト
チェックは5点です。利用レポートで上位消費者を確認したか。Enterprise候補者が本当にagent利用者か。候補者を集約する組織を用意したか。user-level budgetとenterprise budgetの関係を計算したか。組織別にBusiness運用を残すユーザーの承認権限を誰が持つか明確にしたか。ここが曖昧だと、Enterpriseへ上げても翌月に配分が崩れます。
Copilot Enterpriseの席種設計や予算ルールを社内標準へ落とし込みたい場合は、 AI・Claude研修のご相談はこちら 。
よくある質問
Q. Enterprise席は高いので、まず全員Businessで始めるべきですか。A. 小規模導入なら妥当ですが、cloud agentやPR reviewを多用する中核人材までBusinessに固定すると、プール不足か追加課金が先に問題になります。まず上位利用者だけEnterpriseへ寄せるほうが判断しやすいです。
Q. 追加課金を避けたいなら、Enterprise席を増やすより予算をゼロにすべきですか。A. 予算ゼロは最も強い制御ですが、利用停止がそのまま開発停止になります。月次でブロックされる利用者が偏るなら、席の昇格、個別上限、cost center分離の順で調整したほうが現場は安定します。
