課金、ライセンス、従量制料金のサービスを管理する
Enterprise アカウントは、GitHub Enterprise Cloud (GHEC) でのすべての課金とライセンスを、Enterprise に属するすべての Organization を含めて一元的に管理します。Enterprise アカウントを設定するときの最初のステップの 1 つとして課金構成をレビューすることは重要です。支払方法を設定し、費用の上限を確認すると、GitHub Actions や Codespaces のような従量制料金のサービスを、予算やポリシーに沿って使用開始する準備が整います。また、Enterprise アカウントのライセンス使用に関するレポートのしくみに慣れておく必要もあります。これによって、GitHub Enterprise のライセンスやその他の別途ライセンスされたサービスがどのように使用されて提示されるかを理解できます。
このガイドの学習内容
GHEC が課金対象としてユーザー ライセンスを決定する方法
GitHub Actions、Packages、Codespaces などの従量課金制サービスに対するアクセス権と支出限度額の設定方法
GitHub Copilot や GitHub Advanced Security など、ライセンスを個別に割り当てるサービスのポリシーとライセンスの管理方法
ユーザー ライセンス
GHEC では、ユニークユーザー ライセンシング モデルを採用しています。このモデルでは、Enterprise の複数の Organization に所属しているユーザー アカウントや、Organization が所有する複数のリポジトリにアクセスできるユーザー アカウントであっても、GitHub では各メンバーや外部コラボレーターを課金対象として一度だけカウントします。GHEC のユーザー ライセンスは、購入と同時に Enterprise に追加されます。追加ユーザーの招待やプロビジョニングを続けるには、Enterprise に十分なユーザー ライセンスが必要です。
具体的には、以下の各シナリオのアカウントは、請求可能なユニーク ユーザーとしてカウントされます。
Enterprise の少なくとも 1 つの Organization のメンバーまたは所有者である Enterprise オーナー
オーナーを含む Organization メンバー
フォークを除く、Organization が所有するプライベート リポジトリまたは内部リポジトリの外部コラボレーター (公開リポジトリのみにアクセスできるコラボレーターはライセンスを消費しません)
Organization のオーナーまたはメンバーになるための招待を保留している人 (Enterprise Managed Users (EMU) を使用していない Enterprise のみ)
フォークを除く、Organization が所有するプライベート リポジトリまたは内部リポジトリに対する外部コラボレーターになるための招待を保留している人 (EMU を使用していない Enterprise のみ)
それに対して、以下の各利用タイプのアカウントは、請求可能なユニーク ユーザーとしてカウントされません。
Enterprise の少なくとも 1 つの Organization のメンバーまたは所有者でない Enterprise オーナーまたは支払いマネージャー
個々の Organization の支払いマネージャーで、他の使用状況がない人
支払いマネージャーになるための招待を保留している人 (EMU を使用していない Enterprise のみ)
Organization が所有するパブリック リポジトリの外部コラボレーターになるための招待を保留している人 (EMU を使用していない Enterprise のみ)
停止されている管理ユーザー アカウント (EMU を使用している Enterprise のみ)
従量課金制サービス
GitHub ホステッド Actions ランナー、GitHub Actions および Packages の共有ストレージ、Codespaces などの従量課金制サービスの利用は、消費単位ごとに課金されます。Enterprise 内の全 Organization での利用分は、Enterprise レベルで 1 つの請求書に集約されます。
GitHub ホステッド Actions ランナーの分単位の使用量と Actions と Packages の共有ストレージについては、GHEC プランには月あたりの一律のストレージ容量と使用量 (エンタイトルメント) が含まれています。エンタイトルメントを超える利用やエンタイトルメントを含まないサービスについては、課金のための支払い方法を設定する必要があります。また、各機能の支出限度額を設定して支出をコントロールしたり、無制限の支出限度額を設定してサービスの継続性を確保したりすることもできます。
Organization の料金は単一の Enterprise 請求書に集約されますが、全ての従量課金制サービスのレポートが詳細に記載されたものを利用できます。
従量課金制サービスに含まれるエンタイトルメント
GHEC プランには、GitHub ホステッド Actions ランナーの使用時間と、共有の Actions および Packages ストレージのためのエンタイトルメントが含まれています。全ての GHEC Enterprise アカウントには、企業の規模、Organization の数、ユーザー数に関係なく、共有されるエンタイトルメントのデフォルト数が与えられます。これらのサービスは、簡単なワークフロー オートメーション、パイロット アクティビティのサポート、セキュリティ スキャンのテスト、その他ビジネスクリティカルでない利用など、GitHub Actions および Packages を企業が利用し始められるようになることを目的としています。本番環境での DevSecOps パイプラインの一部として GitHub Actions や Packages を利用する場合は、毎月の支払い限度額と支出限度額を設定し、含まれるエンタイトルメントを超えてこれらのサービスを継続的に利用できるようにする必要があります。
従量課金制サービスの支払いを設定する
Enterprise アカウントに Azure プラン ID を接続することで、GitHub の従量課金制サービスを利用する際に、Enterprise アカウントに含まれるエンタイトルメント以上の料金を支払うことができます。このオプションは、Azure プランをお持ちの方であればどなたでもご利用いただけるようになっており、毎月の請求書よりも望ましい課金方法です。
Azure プランをお持ちのお客様であればどなたでも、Azure プラン ID を Enterprise アカウントに接続して、Azure 請求書経由で全ての料金を管理できます。Azure プランは、課金目的のみに使用されます。Azure プラン自体にリソースが作成されたり、使用されたりすることはありません。
Azure プランを接続するには、Azure プランのオーナー権限を持っていることと、GitHub の Enterprise オーナーであることが必要です。
従量課金制サービスの支出限度額を設定する
従量課金制サービスの支払いを設定したら、各サービスの支出限度額の設定も検討しましょう。支出限度額を設定すると利用コストを管理できます。支出限度額を 0 ドルに設定すると、そのサービスに対する追加料金は発生しませんが、含まれるエンタイトルメントを使い切るまでそのサービスを利用できます。また、支出限度額を無制限に設定することも可能で、その場合は利用金額にかかわらずサービスを利用し続けることができます。請求書が発行される顧客に対するデフォルトの支出限度額は無制限に設定されているため、特定の支出限度額を設定したい場合は必ず更新してください。
Actions、Packages、Codespaces では、サービスごとに個別の支出限度額を設定できます。
従量課金制サービスの課金 / 使用状況に関するレポート
従量課金制サービスの課金に関する情報は、各 Organization レベルおよび合計 Enterprise レベルの両方で提供されます。ユーザー インターフェイスで毎月の使用量を表示したり、CSV 形式で詳細な使用状況レポートをダウンロードしたりできます。これらのレポートは、さらなる分析、チャージバック、その他のより詳細なレポートや分析の出発点になることを目的としています。
支出限度額と同様に、Actions、Packages、Codespaces の個別の使用状況を確認できます。
GitHub Actions のポリシー
Enterprise 内の Organization の全てや一部を対象に、またはいずれも対象とせずに、ポリシーによって Actions を有効または無効にできます。Actions が有効な場合、管理者はワークフローで利用できる特定のアクションを定義できます。以下の 3 つのオプションを利用できます。
全てのアクションと再利用可能なワークフローを許可する: ユーザーは、GitHub Marketplace にあるアクションやパブリック リポジトリに定義されているアクションを含むワークフローを実行できます。このオプションは制限がそれほど厳しくないため、ほとんどの企業には適していません。公開されているアクションを使うのに確認や承認は必要ありません。
Enterprise アクションと再利用可能なワークフローを許可する: この設定は、上記の設定に比べると非常に制限的ですが、使用される全てのアクションが Enterprise 内に存在する必要があるため、ほとんどの Enterprise には適していません。これはつまり、開発者は GitHub Marketplace から直接アクションを使うことができないということです。また、必要なアクションを全て Enterprise 内にクローンし、それらの内部アクションを参照するようにチームをトレーニングし、定期的にアップデートをチェックして取り込むプロセスを定義する必要があります。
Enterprise アクション、一部の非 Enterprise アクション、再利用可能なワークフローを許可する: このオプションは、ほとんどの Enterprise にとって賢明で管理しやすい選択です。このオプションでは、管理者が GitHub で作成したアクション、GitHub が認証済みのクリエイターが作成したアクション、特定のサードパーティ製アクションや再利用可能なワークフローを個別に承認するための「許可」リストが表示されます。
3 番目のオプションを選択した Enterprise は、Actions へのアクセスをリクエストするための独自のプロセスを作成して管理する必要があります。管理者は、承認されたアクションを以下の 4 つの方法で参照できます。
アクションのソース コードへの簡単なオーナー / リポジトリ パス
アクションの特定のブランチ。次として参照される:
owner/repo@branchアクションの特定のタグ / リリース。次として参照される:
owner/repo@tagアクションの特定のコミット SHA。次として参照される:
owner/repo@SHA
サードパーティのアクションを独自にセキュリティ レビューする企業は、承認されたアクションのバージョンに固有の owner/repo@SHA 構文を使用する必要があります。この理由は、ブランチ名とタグで参照されるコードが変更される可能性がある一方で、コミット SHA は不変であるためです。
また、GitHub ホステッド ランナーではなく、セルフホステッド ランナーでアクションを実行することもできます。お客様によっては、セキュリティ上の理由から、リポジトリ レベルでのホステッド ランナーの使用を防止したいと考える場合もあります。この理由は、GitHub ホステッド ランナーとは異なり、GHEC 用のセルフホステッド ランナーは一時的かつクリーンな仮想マシン上でホストされるという保証がないためです。その結果、ワークフロー内の信頼できないコードによって危険にさらされる可能性があります。このようなセキュリティ上の問題が発生する可能性があるため、リポジトリ レベルのセルフホステッド ランナーの使用を防止するポリシーを設定できます。Enterprise Managed Users (EMU) モデルを使用している Enterprise では、Organization ではなく EMU アカウントが所有するリポジトリに対してランナーの作成を制限するポリシーを設定することもできます。
Codespaces のポリシー
GitHub Codespaces はクラウドベースの即時開発環境で、開発者に開発用の一般的な言語、ツール、ユーティリティを提供します。その結果、作業を始めるために開発者は多くのツールや依存関係をローカルにインストールする必要がなく、プロジェクトを迅速に開始できます。Codespaces を Organization 全体に徐々に展開したい場合でも、GHEC ではそのためのコントロールを利用できます。全ての Organization で Codespaces を有効にしたり、特定の Organization で有効にしたり、全ての Organization で無効にしたりできます。
あるいは、Enterprise 内のプライベート コードの管理を強化する必要があるセキュリティ規制に準拠しなければならない場合は、Enterprise 内の全ての Organization で Codespaces を無効にすることもできます。Enterprise ポリシーを設定して、Enterprise 内の Organization 全体で Codespaces を有効または無効にできます。
ライセンスを個別に割り当てるサービス
GitHub Copilot
このセクションのポリシーは、GitHub の AI ペア プログラマーである GitHub Copilot の使用を管理するものです。GitHub Copilot は GHEC とは別にライセンスが割り当てられます。GitHub Copilot を使用している Enterprise の場合、この設定を使用して、どの Organization のユーザーが GitHub Copilot を使用できるかを管理したり、パブリック コードに一致する GitHub Copilot からの提案を許可または禁止したりできます。
コードのセキュリティと分析 (GitHub Advanced Security)
GitHub Advanced Security は、プライベート リポジトリのシークレット スキャンやコード スキャンなど、アプリケーション セキュリティの追加機能を提供します。このサービスは、この機能を使用するリポジトリへのアクティブなコミッターごとにライセンスが割り当てられます。コミッターは、そのコミットがいつ作成されたかにかかわらず、過去 90 日以内にリポジトリにプッシュされたことがある場合にアクティブと見なされます。
Enterprise ポリシータブの [コードのセキュリティと分析] セクションには、Dependabot のコントロールも含まれています。Dependabot は GHEC に含まれる機能で、オープン ソースの依存関係をコードで安全に使用するのに役立ちます。Dependabot は使用している依存関係の脆弱性を通知し、セキュリティ修正が利用可能になるとプル リクエストを開きます。さらに、新しいバージョンがリリースされると、依存関係を更新するように自動的にリマインドして、問題に先手を打つことができます。
セキュリティ機能のライセンス、有効化、ポリシーの設定、GitHub Advanced Security についての詳細は、セキュリティに関するラーニング パスを参照してください。
次の項目: リポジトリの可視性、ルール、設定を管理する
ここまで、いくつかの中核となる設定について説明し、課金に関するガードレールを設定しました。次は、Organization の下にある構造的な要素であるリポジトリをどのように設定し、可視性とプル リクエストのマージ機能に関してよりきめ細かなコントロールを提供するかを探ります。