GitHub Copilot ユーザーの管理とプロビジョニング

GitHub Copilot の概念実証を開始する場合であっても、全社的なデプロイを展開する場合であっても、アクセス権を取得するユーザーを管理して、適切なユーザーが恩恵を受けられるようにする戦略が必要です。

GitHub Copilot のアクセスはシート ベースです。アクセス権を付与したユーザーごとに、サブスクリプションに別のシートが追加されます。毎月、使用しているシートの数に対して請求されます。シートの追加や削除はいつでもでき、前もって決まった数を購入する必要はありません。

このガイドの学習内容

• GitHub Copilot のシートを管理するさまざまな方法

• 効率的なシート割り当てに使用できる自動化戦略

また、ASOS の Lead Principal Engineer である Dylan Morley 氏から、同社が構築したカスタム シート プロビジョニング システムについて話を聞きます。

GitHub Copilot のシートのプロビジョニングと無効化

GitHub Copilot のシートのプロビジョニングと無効化にはいくつかのアプローチがあり、優先順位を考慮して決める必要があります。 

煩雑さを軽減して、できるだけ多くの開発者が GitHub Copilot を使えるようにしたい場合もあれば、コストを抑えて効率的にシートを割り当てたい場合もあります。 

煩雑さを軽減したいのであれば、組織全体または ID プロバイダー (IdP) グループにシートを割り当てるのが最適かもしれません。ただし効率を優先するのであれば、よりきめ細かいアプローチが必要な可能性があります。GitHub Copilot のシートは組織の設定で割り当てることができます。さらに、GitHub Copilot Business API を使用すれば、組織の優先順位を適切なバランスに調整したカスタム ソリューションを作成できます。

GitHub Copilot のシートを管理する一般的な方法

手動: GitHub 組織の設定で、GitHub Copilot のシートを開発者 1 人ずつに割り当てます。これは基本的な方法の 1 つであり、数人の開発者だけで小規模な概念実証を行う場合に有効でしょう。

組織ベース: GitHub 組織全体のメンバーにアクセス権を付与します。これもシンプルな方法ですが、GitHub Copilot を使用しないメンバーが組織に多い場合は効率的ではない場合があります。

ID プロバイダー プロビジョニング: Microsoft Entra ID (旧 Azure Active Directory) や Okta などのシングルサインオン用の IdP と連携している組織であれば、チーム同期やクロスドメイン ID 管理システム (SCIM) を使用して、GitHub Copilot へのアクセスをチーム レベルで管理できます。このアプローチを採用すれば、GitHub Copilot のシートを組織内の専用チームに割り当てたり、GitHub Copilot のシートが全メンバーに完全に割り当てられている組織に割り当てたりして、これらのチームや組織へのメンバーシップを外部 IdP からプロビジョニングできます。 

API の自動化: GitHub Copilot Business API を使用すると、カスタムの GitHub Actions ワークフローや自動化スクリプトを使用して、シートを追加したり削除したりできます。たとえば GitHub Actions を使用して、開発者が特定のリポジトリで問題を開いてアクセスを要求したときにワークフローを開始することができます。これは、ASOS のように高度にカスタマイズされた管理システムを作るための良い方法です。

GitHub Copilot Business API による自動化

アカウントのプロビジョニングや無効化だけでなく、GitHub Copilot Business API では、組織内のユーザーのシート割り当ての詳細など、その他の情報にもアクセスできます。この情報には、割り当て日、最終アクセス日、最後に使用したコード エディタなど、シートが割り当てられた人のアクティビティの詳細が含まれます。たとえば使用状況データを使用して、全てのシートの最終アクティビティ日を個々のシート割り当ての詳細と共に確認することで、使用されていない可能性のあるシートを発見できます。

それでは、ASOS が GitHub Copilot Business API を使ってどのようにシートを管理しているのか、Dylan 氏の話を聞いてみましょう。

当社では、特定のニーズを満たすために、シートの自動プロビジョニングと管理のシステムを構築しました。ASOS の開発者に GitHub Copilot を使用したいと思う者がいれば、可能な限り摩擦なく使えるようにしたかったのです。しかし、リソースの無駄遣いになるため、Organization レベルで全員に GitHub Copilot をオンにするのは避けました。そこで構築したのが独自のセルフサービス システムです。

社内には Web サイトがあり、従業員全員がプロフィールを持っています。GitHub Copilot のシートを受け取るには、自分のプロフィールのボタンをワンクリックするだけです。背後では、開発者の Azure トークンを検証する Microsoft Azure Functions プロセスが起動し、GitHub Copilot Business API を呼び出してシートのプロビジョニングを行います。必要であれば、開発者がコマンド ラインからこの処理を行うこともできます。

同時に、シートの使用状況データを取得して、アクティブでないアカウントを毎晩チェックする Azure 関数も用意しています。シートが 30 日間使用されていない場合、次の課金期間が始まる前に削除対象に設定されます。削除する前にもう一度アクティビティがチェックされ、シートが取り消される開発者全員にメールが送信されます。再びシートが必要な場合は、そのメールにあるボタンをクリックするだけで、プロセスを再開できます。

Dylan Morley // Lead Principal Engineer // ASOS

上記のように、GitHub Copilot のユーザー シート管理には万能のアプローチはありません。組織の優先順位を考慮し、独自の計画を立てる必要があります。最初はシンプルなアプローチを選択し、導入データを収集するにつれて、よりカスタム化されたソリューションに移行するのがよいでしょう。その後、ユースケースが複雑になってきたら、GitHub Copilot Business API と IdP インテグレーションを使用して、ニーズに合わせてカスタマイズしたソリューションを構築します。

これで、組織で GitHub Copilot のシートをどのようにプロビジョニングするべきかを理解できました。ここからは請求の仕組みを見てみましょう。