ホーム › ブログ › 法人導入
法人導入 2026年9月9日公開

GitHub Copilotの料金｜Business・Enterpriseの違いと、非エンジニアに要るか

GitHub Copilotの料金｜Business・Enterpriseの違いと、非エンジニアに要るか

法人でGitHub Copilotを導入しようとすると、最初に料金ページを確認し、席ごとの月額へ従業員数を掛けて予算を作りたくなります。しかし、この計算から着手すると、本来は不要な利用者の分まで申請に含めやすくなります。

そうなる背景は大きく二つです。まず、BusinessとEnterpriseは単価だけで選び分けるプランだと思われがちですが、Enterpriseには利用の土台となる契約条件があります。金額の比較だけでは選べません。さらに、Copilotを全従業員向けの生成AIと捉えてしまう問題があります。これは開発作業の流れで活用する製品なので、開発工程のない部門では活用場面そのものが生まれにくいのです。

そこで本記事では、料金比較の前に確認すべきこの二つの論点を中心に解説します。価格と提供条件は公式情報に限定し、参照した日付も明記します。さらに、導入支援を通じて当社が繰り返しお伝えしている「非エンジニア部門には、ひとまず配布しない」という結論についても理由を示します。販売の後押しにはなりにくい話ですが、利用されない席を契約し、後から取りやめる例を見てきたからこそ、先に共有しておきたい判断です。

価格およびサービス内容は、GitHub Docs「Plans for GitHub Copilot」とGitHub「Copilot plans」を参照しています。情報を確認したのは2026年9月8日です。為替変動による陳腐化を避けるため、価格は円へ換算せず米ドルのまま示します。課税方法、請求のまとまり、利用枠の内容は、選択する契約形態で変わります。名称や金額、利用可能な機能が今後更新される場合もあるため、契約手続きの直前には公式サイトで最新情報を必ず確かめてください。価格は他社の記事から引用していません。また、運用面の説明には当社と支援先で得た実務上の知見を用いていますが、会社を識別できる名称、個別契約の金額、個人を特定し得る情報は記載していません。

この記事で押さえられるポイント

  1. 単価から検討すると失敗しやすい背景
  2. 一般的な比較記事で抜けやすい三つの視点
  3. 確認日を明記した公式価格の整理
  4. 月額計算に影響するクレジットの仕組み
  5. BusinessとEnterpriseを分ける本当の条件
  6. 非技術部門への付与をどう判断するか
  7. 開発作業のない職場でたどる経過
  8. 利用者を増やす前に確認したい条件
  9. 非エンジニア向けツールの選択肢
  10. 必要席を三つの段階で見極める方法
  11. 決裁資料で示す費用の考え方
  12. 情シスが事前に整理すべき管理事項
  13. 申し込み前に使える確認項目
  14. 導入現場で起こりやすい五つのつまずき
  15. よくある質問をまとめて確認

料金表から先に見ると、判断を誤る

執筆にあたり「GitHub Copilot 料金 法人」で検索し、検索結果の上位にある解説を読み比べました。各プランの価格や機能が見やすくまとめられ、概要の把握には有用です。一方で、記事中の価格と提供元が現在示している金額が一致しない例も見つかりました。料金改定があれば、掲載時には正確だった記事でも、閲覧時には古い情報になり得ます。

当社では、価格に関する数値は第三者の記事を出典にしません。提供元のページを直接確認し、その確認日と一緒に記載します。為替相場で値が変わる円換算も避けています。換算すると、社内審査で採用したレートの根拠まで説明する必要が生じるためです。本稿も同じ基準で情報をまとめました。

ただし、公式の料金ページを正確に読むだけでも、検討の出発点としては十分ではありません。料金表から分かるのは席ごとの価格であり、自社に必要な席数は別途判断する必要があります。先に決めるべきなのは後者です。人数を精査せず単価だけを見ると、全従業員分の総額を基準に話が進み、その支出に理由を付ける検討へと逆転してしまいます。

適切な席数を出すには、社内で日常的に行われている開発作業を把握しなければなりません。Copilotの主な活躍場所は、コードを記述する作業環境です。そうした環境を利用しない部門へ付与しても、使うきっかけがありません。全従業員の数ではなく、普段からコードを記述する人の数を起点にしてください。

既存の解説に無かった三つの論点

複数の上位記事を確認すると、実際の法人契約で欠かせないにもかかわらず、十分に説明されていない観点が三つありました。

第一に、上位プランを利用するには、その基盤となる契約形態が求められます。公式情報でEnterpriseは、GitHub Enterprise Cloudを使う企業を対象に設計されたプランとされています。したがって、価格と機能を見て自由に上位版を選択できるわけではありません。まず利用条件を満たす土台が必要です。この前提を確認せず機能表だけで決めると、決裁手続きの途中で計画を組み直すことになります。

第二に、費用を考えるうえではクレジットの仕組みを外せません。公式の比較表では、各席の月額に加えて、毎月割り当てられる利用量も示されています。つまり、席数に単価を掛けるだけでは、請求の全体像を十分に見通せません。超過時の運用を曖昧にしたまま承認を得ると、利用開始後に予算を上回る可能性があります。

第三に、そもそも非エンジニアへ付与する必要があるのかという検討が不足しています。多くの比較記事が答えるのはプランの選択であり、導入の要否そのものではありません。どの社員を対象にするかという、それ以前の選別が抜け落ちています。導入支援の実務では、この切り分けが費用に最も大きく影響します。

ここからは、この三つの観点を一つずつ詳しく見ていきます。

公式に記載されている料金（確認日つき）

組織向けの二つのプランについて、席あたりの月額と月あたりのクレジット、前提となる契約形態を対比した図
公式サイトを2026年9月8日に参照して整理した情報。提供条件や料金は更新され得るため、契約前には公式の最新表示を改めて確認してほしい。

公式ページで2026年9月8日に確認できたプラン内容を、以下に整理します。為替換算はせず、価格表示には米ドルを使用します。

法人・組織で利用できる選択肢は、次の二つです。

個人利用のプランは、以下の四種類です。法人プランと見比べるための参考情報として掲載します。

個人向けのクレジット表記には注意が必要です。公式であっても、ページによって説明の細かさがそろっていません。基本分と追加分を区別する案内がある一方、月ごとの金額相当として示す案内もあります。そのため本稿では、参照した両ページで同じ値を確認できた組織向けの数字だけを確定情報として載せました。個人プランの利用可能量は、公式の最新ページを直接参照してください。

税金の取り扱い、請求単位、年間契約を選べるかどうかは、契約の条件次第です。社内申請に記載する費用は、自社に適用される条件で正式な見積もりを取得して確定させてください。

席数×月額では読めない、「クレジット」という数え方

公式表で月額と一緒に掲載されているクレジット数は、単なる機能説明ではなく、支出の計算に関わる情報です。仕組みを把握せず承認手続きを終えると、運用後の請求が想定を超える恐れがあります。

月額料金の中に、一定の利用可能量が含まれていると考えると理解しやすいでしょう。割り当てられた範囲内なら、基本費用は席数と月額の積で把握できます。問題になるのは、付与分を消費し終えた後です。上限到達時に利用を止めるのか、追加利用を認めるのかによって、次回の請求額が変わります。

少なくとも、社内申請を出す前に以下の三項目を確定させましょう。

支援先で特に欠けやすいのは、利用状況を確認する担当者の設定です。契約前は丁寧に議論していても、サービスが動き始めた途端に監視する人がいなくなることがあります。月ごとの使用量チェックは、既存の月次締め業務へ組み込むのが確実です。単独の予定にすると、多忙な時期に後回しになりやすいためです。

利用量と上限を管理する基本的な考え方は、上限と消費量を確認する方法にもまとめています。対象製品は異なっても、重い処理を行う人の選定や部門別の配布設計には共通点があります。

BusinessとEnterpriseの差は、席の値段ではない

席の単価で比べる見方と、前提となる契約形態から判断する見方を左右に対比した図
価格表だけなら自由に選択できるように映るが、上位版には契約上の利用条件がある。確認の順番を取り違えると、決裁中に計画の前提が成り立たなくなる。

公式説明に沿って捉えるなら、両プランは単純な上下関係ではなく、利用できる前提条件が異なる選択肢です。

Businessは、組織の利用者を一元的に管理し、利用ポリシーを統制する機能を持つプランです。公式FAQでは、統合開発環境やコマンドライン、モバイルアプリなど、主としてコードを扱う環境で使うものと説明されています。

Enterpriseは、GitHub Enterprise Cloudを契約する企業のために設計されたものです。Businessで使える機能をすべて含み、クレジット枠の拡大や企業用途の追加機能が用意されています。公式FAQに示されている代表例は、組織に合わせたカスタマイズとGitHub.com上の統合です。

この公式情報を選定に落とし込むと、確認事項は次のようになります。

したがって稟議では、最初に基盤となる契約の有無を確かめる必要があります。GitHub Enterprise CloudがないのにEnterpriseの利用料金だけを申請すると、決裁後に条件を満たしていないことが分かります。導入を支援する際、当社も最初にこの契約状況を確認します。

非エンジニア部署に、配るべきか

ここが、法人での導入範囲を決めるうえで最も重要な部分です。先に答えを示すなら、開発作業が日常業務にない部署には、当初は付与しなくて構いません。

これはCopilotの性能を低く評価しているわけではありません。この製品は、コードを作る環境に入り込んで開発を助ける道具です。公式でも、統合開発環境、コマンドライン、モバイルアプリなど、開発者が普段使う場所が主な利用先とされています。そもそも開発環境を開かない社員には、使い始める場面がありません。

それでも全社への一括配布が候補になるのは、なぜでしょうか。支援の現場で実際に耳にする事情は、主に三種類です。

一つは、全社でAIを導入済みだと示したいという目的です。経営層への報告や社外向けの発信を見据え、分かりやすい導入実績を求める判断です。その狙いは理解できるものの、利用実績のない契約が残れば、翌年度の予算確認で厳しい説明を求められます。

もう一つは、生成AI製品ごとの役割が整理されていないことです。文章作成を支援するサービスもプログラミングを支えるサービスも、同じ生成AIとして一括りにされるため、一つ導入すれば全部門の仕事を改善できるという期待が生じます。これは技術に詳しくない経営者だけでなく、情報システムの担当部署でも起こり得る誤認です。

最後は、製品名が広く知られていることです。知名度が高いと承認を得やすいため、各部署の仕事内容との適合を確かめるより先に、契約の方針が固まることがあります。

当社の研修は12職種を対象としていますが、日常業務としてコードを書く職種はその一部にとどまります。営業や経理、人事、総務、顧客対応の担当者が、毎日の仕事で統合開発環境を立ち上げることは通常ありません。そうした社員に割り当てた席は、利用されず費用だけが残ります。

開発工程が無い部署に配ると、何が起きるか

開発を行わない社員へ実際に席を付与した後、どのような経過をたどるのでしょうか。以下は、当社が複数の導入支援で目にしてきた典型的な流れです。

開始から一週間ほどは、配布された手順に従ってセットアップが進みます。しかし、この時点ですでに作業を完了できない人が現れます。開発者向け環境の準備が導入手順に含まれているからです。普段触れない環境を用意するだけでも、非エンジニアには大きな負担になります。

二週目になると、設定を終えた社員が試用を始めます。ところが、担当業務には作成すべきコードがありません。その結果、具体的にどの仕事へ使うのかという問い合わせが情シスへ集中します。該当する作業がない以上、問い合わせを受けた側も有効な用途を示せません。

導入から一か月もすると、ほとんど起動されない状態になります。利用は止まっていても席の割り当ては維持され、料金の発生だけが続きます。さらに難しいのは、すぐには契約解除に至らないことです。社内には導入実績だけが記録され、未利用の実態が表面化しにくくなります。

利用されていない事実が見つかるのは、半年後の棚卸しということもあります。その頃には、現場が生成AI全般に良くない印象を持っています。金額以上に深刻なのが、この心理的な損失です。本当に業務へ合うサービスを次に提案しても、以前の未活用経験が導入への反対材料になってしまいます。

余分に支払った費用は止められますが、失われた期待や信頼の回復には長い時間を要します。当社が対象者を限定するよう強く勧めるのは、コスト削減だけでなく、この悪循環を防ぐためです。導入時の代表的な失敗パターンは、企業導入がうまくいかない典型例でも紹介しています。

配る前に見落とされがちな前提

決裁前に確認されにくい条件が、もう一つあります。組織用プランでは、組織の管理下にいる利用者へ席を割り当てます。言い換えれば、付与対象者はその組織の枠組みに加わっていなければなりません。

開発チームのメンバーであれば、すでに組織へ登録されているのが一般的です。一方、配布先を別部門へ広げる場合、対象となる社員を新しく組織へ参加させる手続きが必要になります。アカウントを追加するだけではなく、それぞれが閲覧できる領域も同時に設計しなければなりません。

特に忘れられやすいのが、参照権限の範囲を決める作業です。組織へ加わることで、その社員から見える情報が増えます。設定によっては、自社のソースコードや内部の設定情報にアクセスできる状態にもなり得ます。非開発部門を全員参加させることは、情報への入口をその人数分広げることでもあります。

当社が関わった案件でも、この確認をしないまま配布計画が進んだ例は一つではありません。ライセンスを追加するだけの想定だったものが、途中で権限設計の見直しを要し、導入時期が数か月後ろ倒しになりました。必要席を計算する前に、情報システム部門と閲覧可能な範囲を合意してください。

退職者が出た際の対応も、あらかじめ手順へ含める必要があります。ライセンスを戻す処理に加えて、組織から対象者を外すところまでを退職手続きに組み込みましょう。具体的な回収対象は、退職時のアカウント・権限回収に整理しています。

では、非エンジニアには何を配るか

文章を扱う土台、職種ごとの道具、ファイルを直接扱う道具という三つの選択肢を並べた図
開発を日常業務に含まない部門には、ここに示した三系統から選ぶ。いずれもコード作成用の環境を利用条件としない。

技術職ではない社員へ導入する場合は、三つの方向から候補を考えます。どの選択肢も、プログラミング環境を日常的に使うことを求めません。

最初の候補は、文書や言葉を扱う共通基盤です。文章の作成、要点の整理、情報収集、翻訳は、多くの職種で繰り返し発生します。全社共通で用意するなら、この領域が適しています。実際の選定では、現在利用しているグループウェアとの連携や親和性が大きな判断材料になります。サービス別の費用は、法人契約における価格の考え方とWorkspaceと組み合わせる場合の整理で解説しています。

二番目は、各職種に固有の業務を助ける専用ツールです。会議内容の記録、経費データの照合、採用候補者への連絡など、特定の担当者に集中する作業を対象にします。利用者は数人から数十人の範囲に収まりやすいため、全社の席数よりも業務との適合度を優先して判断できます。

三番目は、手元のファイルを直接操作できるツールです。プログラミングを前提にせず、表計算や文書を更新したり、決まった処理を反復したりする用途に向きます。同じ作業を何度も行う担当者なら、非技術部門でも効果を得やすい選択肢です。もっとも、導入前にはツールが読み書きできる情報の範囲を設計する必要があります。詳しくは非エンジニア向け業務で選ぶ際の比較をご参照ください。

三つのどれを採用する場合にも、満たすべき共通条件があります。対象部署の一日の仕事を思い浮かべ、どの作業を改善するのか一文で説明できることです。用途を一文にできない段階では、製品を選定するには早すぎます。サービスを決めた後で無理に活用先を探すことが、定着しない導入の大きな原因になります。

席数の決め方は、三段階

ここで、開発部門に導入する場合の話へ戻りましょう。必要なライセンス数は全従業員数から出さず、次の三段階で絞り込みます。

第一段階では、普段からコードを書く社員を数えます。兼任しているだけの人や、ごくまれに開発環境を触る人は最初の対象から外します。開発環境を週に数回以上立ち上げる社員に限定して集計しましょう。そこで得た人数が初期導入の最小規模です。

第二段階では、二か月ほど実際に使い、利用実績を点検します。付与した席のうち、継続的に活用されている割合を確認してください。当社の導入支援では、利用者数が当初の予測を一割から二割ほど下回る例が多いと感じています。未使用と分かった席は、このタイミングで回収します。

第三段階で、初回の対象外とした社員から追加希望を受け付けます。周囲で実際に活用する様子を確認した後なら、希望者は必要性を具体的に感じている人へ自然と絞られます。最初に限定して後から増やす方が、全員へ渡した席を取り上げるよりも社内の反発を抑えられます。

この手順には、定着を促す効果もあります。自ら利用を希望した社員は、必要な操作方法を主体的に調べる傾向があります。一律に与えられた社員には、その動機が生まれにくいものです。契約席が同数でも、使い続ける人の割合に差が出ます。

稟議に載せる、費用の組み立て方

社内の決裁資料に記す費用は、以下の順番で組み立てると説明しやすくなります。価格の根拠には、必ず公式サイトで確認した値を使ってください。

最初に示す基本料金は、必要席数に席単位の月額を乗じた金額です。計算自体は簡単ですが、申請に必要な費用説明はこれで終わりではありません。

続いて、付与分を使い切った場合の運用方針を記載します。超過時には利用を停止するのか、追加を認めるなら限度額をどこに置くのかを明文化します。この項目がなければ、承認者から費用上限を確認されることになります。

さらに、導入しなかった場合との比較材料を一つ加えます。対象作業に現在どれほどの時間を費やしているかを示すのです。必要時間は、対象人数と作業時間の掛け算で求めます。推計値でも問題ありませんが、推計であることを資料上ではっきりさせましょう。確定値のように示すと、実績との差が出た際に資料全体の信頼性を損ねます。

締めくくりとして、契約を再評価する時期も明記します。三か月後に利用データを点検して席数を調整すると書き添えてください。見直し予定が示されていると、決裁者は承認しやすくなります。懸念されやすいのは支出額そのものだけではなく、不要になった際に縮小できるかどうかだからです。

決裁資料を作る具体的な構成については、起案に必要な六項目と質問への備えで説明しています。成果を時間で評価する方法は、削減時間を計測する考え方をご覧ください。

情報システム部門が、必ず聞かれること

ポリシー管理、利用者の管理、使用状況の確認、監査ログ、ファイルの除外という五つの管理機能を並べた図
公式案内では、組織用プランの所有者が扱える管理項目として示されている機能。申し込みの前に、社内基準を満たすか一つずつ照合する。

公式ドキュメントには、組織向けプランの所有者が利用できる管理機能として、以下の項目が挙げられています。自社のセキュリティや運用要件と契約前に照合しましょう。

実際の運用相談で質問が最も多いのは、ファイルを除外する機能です。社内情報のうち、ツールの対象に含めたくないデータをどのように切り離すかは、導入支援のたびに論点になります。ただし、設定を保存しただけでは対策が完了したとはいえず、適用後の挙動確認まで必要です。除外できたと思い込み、実際には反映されていない状態が最も危険です。

現場では、次の手順で検証を進めるのがよいでしょう。

監査ログは、保存される情報だけでなく、記録の対象外となる情報も調べる必要があります。取得できる項目は公開されていても、取得できない項目が網羅的に示されるとは限りません。審査担当者や監査人へ説明する可能性があるなら、ログの空白も把握しておきましょう。確認の視点は、監査記録に含まれるものと含まれないもので詳しく整理しています。

契約前のチェックリスト

これまでの説明を、申し込み前に点検できる一覧へまとめました。

現場で繰り返される五つの失敗

第一の失敗は、従業員の総数をそのまま必要席数とすることです。把握すべきなのは、日頃から開発環境を利用する社員の人数です。この数え違いが、予算を最も大きく膨らませます。

第二は、他社メディアに掲載された価格を申請資料へ転用することです。料金は将来変わり得ます。今回の調査でも、検索上位の記事と公式の現行表示が異なる例がありました。提供元の情報を直接参照し、いつ確かめた数字なのかも記録しましょう。

第三は、上位版を席単位の価格だけで選ぼうとすることです。必要となる基盤契約を最初に調べなければ、承認を得てから利用条件の不足に気づくことになります。

第四は、誰が何を閲覧できるかという設計を後回しにすることです。単なる席の追加と思って進めると、権限の見直しで導入が数か月延びる場合があります。情シスとの権限協議は、ライセンス数を確定するより前に実施してください。

第五は、利用実績のない席を契約したままにすることです。導入済みという事実だけが注目されると、実際には使われていない状況を発見しにくくなります。契約開始時に、三か月単位で利用席を棚卸しする予定も登録しましょう。

よくある質問

技術職でなくてもGitHub Copilotを利用できますか。
操作すること自体は可能ですが、仕事の中で活用する場面は限られます。公式案内でも、統合開発環境やコマンドラインなど、コードを作る環境が主要な利用場所です。そうした環境を普段使わない部門では、製品を立ち上げる必要すら生じません。非エンジニアには、文章業務の共通基盤や各職種に特化した製品を検討しましょう。

BusinessとEnterpriseの選択基準を教えてください。
まず自社がGitHub Enterprise Cloudを利用中かどうかを調べます。公式によると、Enterpriseは同サービスを使う企業に向けて設計されています。未契約なら、価格や機能を比較する前に候補から外れます。契約済みの場合は、GitHub.comとの統合要件と、必要なクレジット量をもとに選んでください。

費用は月額単価に席数を掛けるだけで算出できますか。
その計算だけでは十分ではありません。公式のプラン表には月額だけでなく、毎月利用できるクレジット枠も掲載されています。枠を消費し切った後の方針がなければ、運用後に予想していなかった支払いが生じる恐れがあります。超過時に停止するか、追加利用を認めるか、さらにその限度額を申請時に定めてください。

小規模な試験導入から始められますか。
初回は対象を限定し、必要に応じて広げる方法がおすすめです。日常的にプログラムを書く社員へ先に付与し、二か月の実績を見て調整しましょう。全員への配布後に回収する方法よりも、社内で生じる反発を小さくできます。希望して参加した人は、自ら操作を学びやすいという利点もあります。

すでに導入している生成AIと役割が重なりませんか。
用途が異なるため、通常はそのまま重複するわけではありません。文書作成を支援する基盤と、プログラミング環境で働く製品では、登場する業務場面が違います。ただし開発チーム内では、複数製品の機能が重なる場合があります。その際は、開発工程ごとに使う製品を決めましょう。使い分けの実例は、二つのサービスを併用する企業の運用で説明しています。

契約後に利用が進まない場合、何から見直せばよいですか。
対象者の日常業務にコード作成が含まれるか、最初に確認します。開発工程を持たない社員なら、操作研修を増やしても根本的な解決にはなりません。席をいったん戻し、その職種の仕事に合う製品へ切り替える方が近道です。開発する人が使っていない場合は、導入のどの手順で止まったかを個別に聞き取りましょう。

利用料金を小さくするには、何が効果的ですか。
最も直接的なのは、不要な席をなくすことです。下位プランへの変更を考える前に、継続利用されているライセンスを数えてください。当社の経験では、当初見込んだ人数より一割から二割ほど利用者が少なくなるケースがよくあります。三か月ごとの棚卸しを通常業務として定着させましょう。

社内ルールにはどのように記載すればよいでしょうか。
サービスごとに新しい規程を用意する必要はありません。入力可能な情報、禁止事項、問題発生時の報告先などを定めた既存規程に対し、利用対象ツールの一つとして製品名を加える運用が現実的です。ファイル除外機能を設定している場合は、除外対象の一覧も付属文書として保管してください。

まとめ

法人導入を考え始めたら、料金表を眺める前に、社内で普段からコードを書いている社員の人数を確認してください。この対象者を特定するだけでも、決裁申請に必要な金額を現実的な規模まで絞り込めます。最初の作業は、開発者数の把握です。

各部門で生成AIを適用する業務の選定から始めたい場合は、職種ごとに学べるAI実務研修もご確認ください。営業・経理・人事をはじめ、それぞれの職種が実際の仕事で困りやすい場面を出発点に研修内容を設計しています。

当社では、エンジニア以外の社員も生成AIを日々の仕事で安全に使えるよう、計画づくりから社内定着までを支援しています。AIへ任せる作業の切り分け、アクセス権と情報範囲の設計、更新履歴の記録、異常を検知する通知、社内ルールと利用者向け手順書の作成、四半期単位の再評価を、企業ごとの規程や業務フローに合わせて構成します。最初のご相談に費用はかかりません。


非技術部門でも安全にAIを活用するためのオンライン・対面研修


業務の切り分けやアクセス権の設計段階からご相談ください
初回相談とお見積もりには料金が発生しません

無料相談について確認する →

← 前の記事
AI導入の補助金と研修の助成金は何が違うか｜ツール代と人の育成で使い分ける

AIの活用について、
個別に相談する

「何から始めればいいか分からない」という段階で構いません。現状をお聞かせいただければ、貴社に合った進め方をご提案します。ご相談・お見積もりは無料です。

無料で相談する → 他の記事を見る