MENU

問い合わせ


    GitHub Copilotを社内導入するときの設定とルール 従量課金の上限設定まで発注者向けに解説

    「エンジニアがGitHub Copilotを使いたいと言っている」「開発会社から、うちの案件でもCopilotを使っていいかと聞かれた」。AIのコーディング支援ツールが当たり前になり、情シス兼任の担当者や経営者が、GitHub Copilotの社内導入の設定やルールを決める場面が増えています。

    「GitHub Copilotを社内導入したいけど、どの設定をして、どんなルールを決めればいいのか分からない。従量課金だと聞いたけど、費用が読めないし、上限を決めないと止まるの?」

    先に結論をお伝えします。

    • 会社で使うなら、個人プランではなく組織向けプラン(Copilot Business など)で契約し、会社が席(利用権)を配るのが基本です
    • 設定で押さえるのは「誰に配るか」「使えるAIモデル」「自律的に作業するエージェント機能」「外部ツール連携(MCP)」「読ませないファイル」の5つです
    • 費用は、席の料金に含まれる「AIクレジット」を超えた分が従量課金です。初期状態では、超えても止まらず課金が続く設定になっているため、上限を決めたい場合は管理者が明示的に止める設定をします

    この記事では、執筆時点(2026年9月)のGitHub公式ドキュメントに基づき、設定の順番と「なぜその設定をするのか」、社内ルールのひな形、開発会社がCopilotを使う場合に確認したいことを解説します。

    目次

    GitHub Copilotの社内導入で最初に決める「プラン」

    GitHub Copilotは、プログラムを書く画面の中で続きのコードを提案したり、チャットで質問に答えたり、指示を受けて修正案を作ったりするAIの支援ツールです。まずは「どのプランで契約するか」を決めます。

    📰 出典:GitHub Docs「Plans for GitHub Copilot」

    プラン料金(執筆時点)1人あたりのAIクレジット/月向いている使い方
    Copilot Business1席 月19ドル1,900組織で席を配り、ポリシー(利用ルール)を一元管理したい会社
    Copilot Enterprise1席 月39ドル3,900GitHub Enterprise Cloud を使っていて、より多くのAI利用枠が必要な会社
    Free/Pro/Pro+/Max無料〜月100ドルプランによる個人での利用

    Copilot Businessは、GitHub Enterprise Cloud を契約していなくても、GitHub Free または GitHub Team の組織(Organization=会社単位のアカウント)の所有者が購入できます。小さな会社なら、まずBusinessで検討するのが現実的です。

    📰 出典:GitHub Docs「Setting up GitHub Copilot for your organization」

    個人プランを業務で使わせない方がよい理由

    プラン選びで特に注意したいのが、データの扱いです。GitHubは、2026年4月24日から、Copilot Free・Pro・Pro+ の利用者のやり取りのデータ(入力したコードの断片、カーソル周辺のコード、受け入れた提案など)を、オプトアウト(=設定で拒否すること)しない限りAIモデルの改善に利用する方針に変更しました。一方で、Copilot Business・Copilot Enterprise のデータや、有料の組織に所属するユーザーのデータは対象外とされています。

    📰 出典:GitHubブログ「GitHub Copilot のインタラクションデータ利用ポリシーの更新について」

    つまり、社員が自分の個人プランで会社のコードを扱うと、設定次第では会社のコードの一部が学習に使われる可能性があります。「業務では会社が配った席だけを使う」ことを、ルールの最初の1行にしておくと安心です。社内情報をAIに入力する際の考え方は、ChatGPTに社内情報を入力しても大丈夫?でも解説しています。

    Copilot Businessの設定手順5ステップ

    GitHubの公式ドキュメントでは、組織での導入を「有効化 → ポリシー設定 → ネットワーク設定 → メンバーへの付与 → 定着の推進」の順で案内しています。発注者・管理者の目線で、何をなぜ設定するのかを整理します。設定画面は、組織の「Settings」→「Code, planning, and automation」→「Copilot」にまとまっています。

    📰 出典:GitHub Docs「Managing policies and features for GitHub Copilot in your organization」

    ステップ1:会社の組織(Organization)でCopilotを有効にする

    会社のGitHub組織の所有者(オーナー)がCopilot Businessを申し込みます。まだ組織が無く、開発者が個人アカウントでコードを管理している場合は、先に会社の組織を作り、コードの置き場所を会社の管理下に移しておくのが順番です。

    ステップ2:ポリシー(使ってよい機能)を決める

    ここが社内ルールの中心です。主な設定項目と、決めるときの考え方は次のとおりです。

    設定項目何を決めるか考え方の例
    Models(モデル)基本モデル以外のAIモデルを使わせるか追加費用がかかる場合があるため、最初は必要なものに絞る
    Cloud agent(クラウドエージェント)Issue(課題票)を任せると自律的に作業し、修正案を作るエージェント機能を使うか試験導入するリポジトリ(=コードの保管場所)を限定する
    MCP servers in CopilotMCP(=AIと外部のツールやデータをつなぐ仕組み)を使わせるかつなぐ先と権限を決めてから有効にする
    Suggestions matching public code公開されているコードと一致する提案を許可するか開発チームと相談して方針を決める

    Business・Enterpriseでは、クラウドエージェントは初期状態で無効になっており、管理者が有効にしないと使えません。また、組織の所有者は、特定のリポジトリでエージェントを使えないようにすることもできます。エージェントは下書きのプルリクエスト(=変更の提案)を作る仕組みなので、最終的に取り込むかどうかは人が確認して判断する運用にしておきましょう。

    📰 出典:GitHub Docs「Managing access to GitHub Copilot cloud agent」

    ステップ3:AIに読ませないファイルを指定する(コンテンツ除外)

    BusinessとEnterpriseには、指定したファイルをCopilotに使わせない「コンテンツ除外」という機能があります。設定ファイルや顧客データを含むファイルなどを指定しておくと、そのファイルでは提案が出なくなり、他の提案の材料にも使われなくなります。

    ただし公式ドキュメントでは、VS Code などのエディタにおけるCopilot Chatの Edit モード・Agent モードでは、コンテンツ除外に現在対応していないと明記されています。「除外したから絶対に読まれない」とは考えず、そもそも秘密情報をコードの保管場所に置かないことと組み合わせるのが前提です。

    📰 出典:GitHub Docs「Content exclusion for GitHub Copilot」

    ステップ4:ネットワークを確認し、席を配る

    社内にプロキシやファイアウォールがある場合は、Copilotの通信が通るかを確認します。そのうえで、「Access」の画面から全員または選んだメンバー・チームに席を割り当てます。費用は、席を割り当てた時点から発生し、使ったかどうかは関係ありません。「使う人から順に配る」「退職・異動時に外す」を運用ルールに入れておきましょう。

    📰 出典:GitHub Docs「Granting access to GitHub Copilot for members of your organization」

    ステップ5:チームのルールを「カスタム指示」としてAIに渡す

    Copilotには、AIに守ってほしいルールを文章で渡す「カスタム指示」という仕組みがあります。リポジトリに「.github/copilot-instructions.md」や「AGENTS.md」といったファイルを置くと、そのリポジトリでの依頼に適用されます。Business・Enterpriseでは、組織の所有者が組織全体のカスタム指示も設定できます(GitHub.com上のチャット・コードレビュー・クラウドエージェントが対象)。

    📰 出典:GitHub Docs「About customizing GitHub Copilot responses」

    書く内容は「テストを必ず書く」「社内の命名ルール」「使ってよいライブラリ」など、人間の新メンバーに渡す開発ルールと同じで構いません。優先順位は個人の指示が最も高く、次にリポジトリ、組織の指示は最後とされているため、必ず守らせたいことは人のレビューでも確認します。

    従量課金(AIクレジット)の仕組みと上限の決め方

    2026年6月1日から、Copilotの全プランは「GitHub AI Credits(AIクレジット)」の消費量に基づく課金になりました。プランごとに月の利用枠が含まれ、それを超えた分が追加の費用になります。

    📰 出典:GitHub Changelog「Updates to GitHub Copilot billing and plans」(2026年6月1日)

    何にクレジットを使い、何は無料か

    公式ドキュメントでは、次のように整理されています(執筆時点・2026年9月)。

    • クレジットを消費するもの:Copilot Chat、Copilot CLI、クラウドエージェント、サードパーティのコーディングエージェントなど
    • 消費しないもの:コード補完(入力中に続きを提案する機能)と次の編集の提案。有料プランでは無制限
    • 利用枠は組織全体で共有:Businessなら1人あたり1,900クレジットが組織の共有プールに入ります(100人なら19万クレジット)。毎月1日(UTC)にリセットされます

    📰 出典:GitHub Docs「Usage-based billing for organizations and enterprises」

    GitHubの発表では、Businessの席料金19ドルには19ドル分のクレジットが含まれるとされています。補完中心の使い方なら追加費用は出にくく、エージェントに大きな作業を任せるほどクレジットを多く消費する、と理解しておくと見通しが立てやすくなります。

    📰 出典:GitHubブログ「GitHub Copilot is moving to usage-based billing」(2026年4月27日)

    上限を決めないと止まる? 答えは「初期状態では止まらない」

    多くの方が気にする「上限に達したら止まるのか」について、公式ドキュメントの記述を整理します。

    • 共有プールを使い切った後の追加利用は、「AI credits paid usage(AIクレジットの有料利用)」ポリシーで決まります。初期状態では追加利用が許可されており、公表単価で課金が続きます
    • このポリシーを管理者が無効にすると、プールを使い切った時点で翌月のリセットまで利用が止まります
    • 組織などの予算(バジェット)を設定しても、「Stop usage when budget limit is reached(上限到達で利用を停止)」は初期状態でオフです。オフのままだと通知が来るだけで、課金は続きます
    • ユーザー単位の予算は、上限に達すると必ず止まる設定です(使い過ぎる1人に全体の枠を使われないようにできます)
    • 止まった場合でも、コード補完と次の編集の提案は引き続き使えます

    📰 出典:GitHub Docs「Budgets for usage-based billing」

    おすすめの考え方は、導入直後の1〜2か月は「有料利用を止める」か「予算に停止設定を付ける」で様子を見て、実際の消費量を見てから上限を広げることです。止めた場合に開発が止まる機能(チャットやエージェント)があることを、事前に開発チームと共有しておきましょう。なお、コードレビュー機能はAIクレジットに加えて GitHub Actions の実行時間も消費すると発表されています。AI利用費の見直し全般は、生成AIのAPI値下げと運用費の見直し方もあわせてご覧ください。

    そのまま使える社内利用ルールのひな形

    設定と合わせて、利用者向けのルールを短く文書にしておきます。A4用紙1枚に収まる程度で十分です。

    • 使ってよいアカウント:業務では会社が割り当てたCopilotの席のみを使う。個人プランでの業務利用は禁止
    • 入力してはいけない情報:パスワード・APIキー(=システム同士の接続に使う秘密の鍵)、個人情報、顧客から預かったデータ
    • 使ってよい機能:コード補完・チャットは可。エージェント・MCPは管理者が許可したリポジトリのみ
    • レビュー:AIが書いたコードも、人が書いたコードと同じレビューとテストを通してから取り込む
    • 費用:月の予算と、超えたときの連絡先(管理者)を明記する
    • 席の管理:入社・退職・異動の手続きに、席の付与・削除を組み込む
    • 見直し:プランや規約は変わりやすいため、半年に1回はルールと設定を見直す

    開発会社がCopilotを使う場合に確認すること

    自社で導入しなくても、開発会社が案件でCopilotを使うケースは多くあります。その場合は、開発会社側の組織で上のような設定・ルールがあるかを確認するのが発注者の役割です。特に確認したいのは、どのプランで使っているか(学習に使われない契約か)、自社のコードや資料をどの範囲でAIに渡すか、エージェントの成果物を誰がレビューするか、の3点です。AIの利用は開発会社にとって品質や効率を上げる手段でもあるため、禁止するのではなく、条件を合意して使ってもらう姿勢がおすすめです。

    発注者がやることチェックリスト

    • ☐ 業務で使うのは組織向けプラン(Business/Enterprise)の席に限ると決めた
    • ☐ 会社のGitHub組織があり、コードが会社の管理下にあることを確認した
    • ☐ モデル・クラウドエージェント・MCPを、どの範囲で許可するか決めた
    • ☐ 読ませたくないファイルをコンテンツ除外に設定し、秘密情報をリポジトリに置かない方針にした
    • ☐ 席を配る対象と、退職・異動時に外す手順を決めた
    • ☐ 「AIクレジットの有料利用」ポリシーと予算の停止設定を、意図どおりに設定した
    • ☐ 社内利用ルール(1枚)を作り、開発チームに共有した

    開発会社への質問例

    • 「当社の案件でGitHub Copilotを使う場合、どのプランで、データが学習に使われない設定になっていますか?」
    • 「当社のコードや資料のうち、AIに読ませない範囲はどのように設定・管理していますか?」
    • 「エージェント機能で作られた変更は、誰がどのようにレビュー・テストしていますか?」
    • 「AIツールの利用料は見積もりのどこに含まれていますか? 当社側で契約が必要なものはありますか?」
    • 「当社で社内導入する場合、最初に許可すべき機能と、止めておくべき機能はどれだと考えますか?」

    まとめ:GitHub Copilotの社内導入は「プラン・設定・ルール・予算」をセットで

    • 業務では、学習利用の対象外とされる組織向けプラン(Business/Enterprise)で、会社が席を配る
    • ポリシーでモデル・クラウドエージェント・MCPの範囲を決め、読ませたくないファイルは除外しつつ、秘密情報は置かない
    • カスタム指示やAGENTS.mdで開発ルールをAIに渡し、最終確認は人が行う
    • AIクレジットは初期状態では超過しても止まらないため、有料利用ポリシーや予算の停止設定で上限を決める

    料金やプラン、機能の仕様は変わりやすいため、導入前には必ずGitHubの公式ドキュメントで最新情報を確認してください。設定やルールづくりに不安がある場合は、開発会社に相談しながら小さく始めるのがおすすめです。

    あわせて読みたい関連記事

    システム制作・運用・保守のお問い合わせはこちら


      よかったらシェアしてね!
      • URLをコピーしました!
      • URLをコピーしました!

      この記事を書いた人

      株式会社THIRD HERO代表取締役 朝野貴朗
      Webシステム開発を中心に、toC向けサービスサイトの運営、ツール開発などを行ってまいりました。

      コメント

      コメント一覧 (1件)

      コメントする

      目次