企業で新しいCopilot機能またはモデルをパイロットする

このチュートリアルでは、予算の設定、限定されたグループに対する機能の有効化、結果の監視、そして得られた根拠に基づく実施可否の判断と報告を含めて、パイロット運用を最初から最後まで実施する方法を順を追って説明します。

パイロットを開始する前に

何かを有効にする前に、機能またはモデルを評価し、それがコンプライアンス要件を満たしていることを確認してください。「新機能とモデルの準備」を参照してください。

機能またはモデルを有効にしても問題ない場合は、パイロットを開始する前に、会社のセキュリティチームとコンプライアンスチームに確認してください。

始める前に「実行」の基準を明確に決めておくことで、事後ではなく計画に基づいてパイロットを評価できるようになります。導入 (アクティブユーザーの最小シェアなど)、コスト (設定した上限内に留まる)、定性的フィードバック (たとえば、ほとんどの参加者がこの機能をお勧めします) をカバーするいくつかの具体的な成功基準を書き留めます。実施/中止を決定するで、パイロットの実際の結果をこれらの基準に照らして確認します。

また、パイロット導入をどのくらいの期間実施するかも計画します。予算と AI credits の共有プールは課金サイクルごとにリセットされるため、パイロットは少なくとも1回の課金サイクル全体（通常は4～6週間）にわたるように計画してください。実施期間が短すぎると、信頼できる結論を導くにはコストや利用状況に関するデータが不十分になる可能性があります。

パイロットグループに含めるユーザーを選択する

機能とモデルは組織レベルで有効化されるため、その組織を通じて Copilot ライセンスを付与されたユーザーは、特定の一部のユーザーだけでなく利用できるようになります。ただし、その組織のメンバー全員が必ず利用できるとは限りません。したがって、個人を選定する代わりに、ライセンス対象の母集団が以下の基準をすでに満たしている組織を探します。

実際の意味のある作業を行う開発者。 パイロット参加者は、使い捨てプロジェクトではなく、組織にとって重要な言語、フレームワーク、リポジトリでこの機能を使用する必要があります。使用状況とコストのシグナルは、本物の作業から得た場合にのみ信頼できます。
スキルレベルと年功序列レベルの組み合わせ。 経験豊富なエンジニアと、コードベースや Copilotに新しい人の両方を含めます。さまざまなレベルのエクスペリエンスでは、機能の使用方法が異なり、さまざまな価値や異なる問題が明らかになります。
さまざまなチームとワークフロー。 あるチームのワークフローを支援する機能は、別のチームのワークフローを支援しない可能性があります。複数のチームにまたがると、機能によって価値が高まる場所とそうでない場所をより確実に把握できます。
フィードバックを提供するユーザー。 パイロットの価値の多くは、メトリックだけでなく、定性的なフィードバックから得られます。参加する参加者を選択し、何が機能し、何が機能しないかを報告し、入力を求められたら応答します。

たとえば、適切なユーザーの組み合わせが複数の組織に分散している場合や、組織が大規模すぎて包含パイロットとして機能できない場合は、専用の組織を作成し、選択したユーザーのみを追加できます。これにより、含めるユーザーを正確に制御できますが、それらのユーザーのリポジトリアクセスを移行または複製することを意味し、深いリポジトリレベルのコンテキストに依存する Copilot クラウドエージェントなどの機能ではうまく機能しない可能性があります。このチュートリアルでは、既存の組織を使用していることを前提としています。専用の組織ルートに移動する場合は、パイロットグループの機能を有効にする前に、その設定とメンバーの追加を追加の手順として扱います。

コストを見積もり、予算の上限を設定する

パイロットする機能とモデルの多くは使用量によって課金されるため、割り当てるライセンスの数によって支出が固定されることはありません。

フロンティアモデルまたはエージェント機能を使用するアクティブな開発者の一部は、予想以上に多くを消費する可能性があります。パイロットのコストの大まかな見積もりを確認し、機能を有効にする前に使用する上限を決定します。

まず、機能またはモデルの課金方法を理解します。使用量ベースの機能は GitHub AI Creditsを消費し、各相互作用のコストは、モデルと使用されるトークンの数によって異なります。使用量にカウントされる機能、含まれるクレジットが企業全体でプールされる方法、超過分の課金方法を理解するには、組織と企業の使用量ベースの課金を参照してください。

見積もりを生成するには、次の 3 つの数値を結合します。

前のセクションで定義したパイロットグループ内のユーザーの数。
この機能の使用を期待する頻度。 これは、ユーザーが実際に使用するまでわからないため、正確に予測するのではなく、意図的にハイエンドの見積もりを選択してください。同等の機能またはモデルを既にロールアウトしている場合は、実際の使用状況を参照ポイントとして使用します。そうでない場合は、エージェント機能とフロンティアモデルは、クイックチャットの質問よりも対話あたりのコストが高いため、開発者ごとに頻繁に大量の使用を想定してください。集中的な作業を行う小規模なグループでは、この機能を使用する大規模なグループよりもコストが高くなることがあります。
含まれている利用可能な許容量。 割り当てられた各ライセンスには、エンタープライズレベルでプールされる毎月一定量のAI creditsが含まれているため、超過料金が請求される前に、パイロットの使用量の一部がそれで充当される場合があります。

これらを使用して上限を設定します。一時停止して再評価する前にパイロットに費やす準備ができている最大値です。パイロットにおいて、有意義な利用データを収集できる余地を残しつつ、従量課金の消費量が予想を上回った場合でもリスクを最小限に抑えられるような数値を設定してください。パイロットグループのサイズを後で調整する場合は、この見積もりを見直してください。

たとえば、20 人の開発者が Copilot 事業でエージェント機能をパイロットするとします。各ライセンスには毎月 1,900AI credits が含まれているため、パイロットグループは、従量制課金が開始される前に、含まれる 1,900 の 20 × AI credits 分の共有プールを利用します。その月の開発者あたり約 3,000 AI credits の使用が予想される場合は、合計使用量を 20 × 3,000 と見積もる必要があります。含まれているプールを減算して従量制課金使用量を見積もり、 $0.01 USD を掛けて超過コストを見積もり、その少し上に上限を設定します。この機能を有効にした後に、この上限を適用する予算を作成します。 [予算の設定] でパイロットのコストを上限にします。

パイロットグループの機能を有効にする

コストを見積もり、対象ユーザーを選定したら、限定的な形でこの機能を有効化できます。目標は、パイロットグループに、企業の残りの部分を影響を受けないようにしながら、正しく管理された実際のエクスペリエンスを提供することです。

これを行うには、次の 4 つの手順を実行します。

組織のメンバーシップとライセンスの割り当てを確認します。
機能を管理するポリシーを構成します。
その組織に対してのみ機能を有効にします。
パイロットのコストを上限とするように予算を設定します。

組織のメンバーシップとライセンスの割り当てを確認する

メンバーシップだけでは不十分です。ほとんどの Copilot ポリシーは、所属する組織だけでなく、ユーザーの Copilot ライセンスを割り当てる組織に基づいて適用されます。他のユーザーが複数の組織に属している場合は、パイロット組織を通じてライセンスが割り当てられているかどうかを確認します。別のポリシーを使用して割り当てられている場合、パイロット組織のポリシーはアクセスを管理せず、このチュートリアルの機能の有効化は適用されません。

パイロットユーザーがまだメンバーではない場合、またはメンバーであっても、他の場所でライセンスを受け取っている場合は、パイロット組織に追加し、それを通じて Copilot ライセンスを割り当ててから続行します。

この機能を有効にする前にポリシーを構成する

Copilot ポリシーは、ユーザーがアクセスできる機能とモデル、およびユーザーのデータの処理方法を制御します。機能をオンにする前にパイロット組織に対してこれらのポリシーを構成して、パイロットユーザーが、意図したガードレールなしで機能を利用できる短いウィンドウではなく、最初の操作から正しく管理されたエクスペリエンスを得るようにします。

パイロットが許可する必要がある機能とモデルを決定し、変更がパイロット組織にのみ影響するように組織レベルでポリシーを設定します。エンタープライズレベルで設定されたポリシーは、企業内のすべての組織に適用されます。エンタープライズポリシーで組織が独自の値を設定できない場合は、続行する前に、エンタープライズ所有者はこれを変更する必要があります。ポリシーが企業から組織にどのように連鎖し、各レベルで設定をオーバーライドできるかを理解するには、企業と組織のGitHub Copilotポリシーを参照してください。

1 つの組織で機能を有効にする

組織の所有者は、組織の Copilot ポリシー設定から、パイロット組織の特定の機能またはモデルのみを有効にします。完全な手順については、組織内のGitHub Copilotのポリシーと機能の管理を参照してください。設定を保存する前に、設定がパイロット組織に適用され、企業全体には適用されないことを確認します。

パイロットのコストを上限に予算を設定する

前に、パイロットの支出上限を決定しました。次に、それを適用する予算を作成します。

まず、組織の予算の内容を理解します。 従量制課金のみを上限とし、AI creditsの共有プールが使い果たされた後にのみアクティブになります。総支出は上限ではないため、パイロットの総コストではなく、含まれている許容量を超えて支払う超過分の量に制限を設定します。重要なのは、 予算は既定ではハードストップではありません。予算の作成時に [予算の上限に 達したときに使用量を停止 する] を有効にしない限り、料金は引き続き上限を超えて発生します。

組織の所有者または課金マネージャーとして、パイロット組織を対象とする予算を作成し、その制限を選択した超過分の上限に設定し、 予算制限に達したときに使用を停止できるようにします。

1 人のパイロットユーザーが消費を実行しないようにする場合は、ユニバーサルユーザーレベルの予算も設定します。これは、常にハードストップとなる唯一の制御であり、共有プールと従量制使用量の両方からのユーザーの消費量を、同じ上限に算入します。参加者が実際に作業できる一方で、1人のユーザーが試験運用の予算の過大な割合を使い切ってしまわないよう、控えめな額に設定します。

ユーザー、組織、エンタープライズレベルでの予算の使用状況の測定とブロック方法については、使用量ベースの課金の予算を参照してください。

パイロットを監視する

パイロット全体を通じて、導入を追跡し、開発者のフィードバックを収集し、開始時に定義した成功基準に対するコストとエージェントのアクティビティを監視します。これらのシグナルを組み合わせることで、機能を拡張するかどうかを決定するのに役立ちます。

Copilotメトリックを使用して導入と使用状況を追跡する

Copilot使用状況メトリックを使用して、アクティブなパイロットユーザーの数、機能を使用する頻度、パイロット期間中の数値の傾向を確認します。安定または成長を保持する導入は強いシグナルです。使用が急増してフェードする場合は、この機能が開発者の実際のワークフローに適合していないことを意味する可能性があります。

メトリックの内容とその解釈方法については、 GitHub Copilot 使用状況メトリクスを参照してください。
組織または企業のダッシュボードを表示するには、 Copilot 使用状況メトリックダッシュボードの表示を参照してください。

パイロットグループから開発者フィードバックを収集する

メトリックは、ユーザーが機能を使用 しているかどうか は示しますが、その理由や機能は示しません。定性的フィードバックを収集して、そのギャップを埋めます。短いアンケートを実行したり、定期的なチェックインを保持したり、パイロットユーザーが何が機能していて、何が機能していないかを報告できる専用チャネルを設定したりします。

ここで、フィードバックを提供する意欲を持って選択した参加者は報われます。具体的な質問をします。機能によって時間が節約された場所、結果が悪かった場所、機能がどのように動作を変更したかなどです。このフィードバックは、多くの場合、数字だけでは明らかにされない問題や機会を明らかにし、後でリーダーシップと共有するための具体的な例を示します。

予算と監査ログ内のコストとエージェントのアクティビティを確認する

最後だけでなく、パイロット期間中を通して、作成した予算に対する支出状況を注視してください。使用量が予想よりも早く上限に近づく場合、これは、より広範なロールアウトのコストに関する早期の証拠として役立ちます。予算に対して費やした内容を監視する手順については、 GitHub AI Creditsの使用状況の監視を参照してください。時間の経過に伴う支出の追跡については、 AUTOTITLE を参照してください。

コストと共に、機能が安全に使用されているかどうかを確認します。これはリーダーシップが尋ねる3番目の質問であり、パイロットは保証ではなく証拠でそれを答えるチャンスです。エージェント機能については、エージェントセッションを確認して、開発者に代わって機能が実際に何を行っているかを理解し、予期しない動作や望ましくない動作をキャッチします。監査ログは、機能が有効または無効になっているときに記録されますが、その詳細レベルはキャプチャされません。設定したポリシーと予算が意図したとおりに動作していることを確認し、より大規模なガードレールを必要とするものに注意してください。「企業での主体的活動の監視」を参照してください。

実行するか見送るかを判断する

パイロットの最後に、前もって定義した成功条件に照らして結果を確認し、機能を拡張するか、さらにデータを保持して収集するか、ロールバックするかを決定します。意図的に決定し、その背後にある証拠を文書化します。

決定するのに十分な証拠があることを確認する

決定する前に、パイロットが計画した期間にわたって実施され、妥当な結論を裏付けるにあたって十分なデータが得られたかどうかを確認してください。

パイロット期間中の使用量は、従量課金が開始される前に、追加料金なしでまず共有プールから充当されるため、パイロット初期に費用が 0 ドルとなるのは想定内であり、実施期間が短いとコストデータが誤解を招く可能性があります。

次の項目がそろえば、判断する準備はできています。

1 つの早期バーストではなく安定したパターンを示す導入メトリック。
見積もりと比較できる、少なくとも 1 つの請求サイクルにまたがる実際のコストデータ。
パイロットユーザーの代表的な範囲からのフィードバック。

これらのいずれかが不十分な場合、たとえば利用状況がまだ増加している場合や参加者がまだ少ない場合は、不十分な証拠に基づいて判断を下すのではなく、パイロット期間を延長することを検討してください。データを元に戻すことができる決定は、リーダーシップを守る方がはるかに簡単であり、逆転が必要になる可能性ははるかに低くなります。

リーダーシップへの報告

意思決定を正当化し、より広範なロールアウトのためのケースを構築するには、パイロットの結果をリーダーシップに報告します。

パイロット中に収集した信号をまとめる:

導入メトリック。 アクティブなパイロットユーザーの数と、時間の経過に伴う使用状況の傾向を示します。
予算に対する実際のコスト。パイロットが設定した上限と元の見積もりを比較します。
フィードバックのテーマ。参加者が価値を見つけた場所と、問題が発生した場所を要約します。
監査ログから、またはポリシーと予算がどのように動作したかから学習した内容を含む、安全性とガバナンスの観察。

企業で新しいCopilot機能またはモデルをパイロットする

この機能を使用できるユーザーについて

Adopting new features

この記事で