ほとんどの企業は、AI コーディング ツールによってもたらされる生産性の利点を認識しています。 しかし、悪意のあるプロンプトや、レビューなしで AI の提案を受け入れる開発者など、社内での不適切な使用がコードベースの標準を侵害する原因になるという懸念が多く見受けられます。
効果的なガバナンスのためにGitHub 環境と作業文化を設定することで、これらのリスクを軽減できます。 GitHub Copilot の主な利点は、GitHub プラットフォームに組み込まれていることです。このプラットフォームには、エンタープライズ レベルのコード ガバナンス用のさまざまな機能が既に含まれています。
1. プルリクエストとレビューを必要とする
開発者や悪いアクターは、検証されていない AI の提案やエージェントの作業を機密性の高いコードベースに直接一方的に適用することはできません。 ユーザーがコードを運用コードベースやその他の重要なブランチにマージする前に、 承認されたプル要求 を要求する必要があります。
これを行うには、ルールセットを作成します。
-
保護するコードベースを含む組織またはリポジトリを特定し、 カスタム プロパティを適用 します。 これにより、ルール セット内のこれらのリソースを簡単にターゲットにできます。 「Organization 内リポジトリのカスタム プロパティの管理」または「組織のカスタム プロパティの管理」を参照してください。
または、これらの保護されたリソースをルールセットに手動で追加したり、名前付け規則に基づいてターゲットにしたりできます。
-
企業のブランチルールセットを作成します。 「Enterprise でルールセットを使ってコード ガバナンスを適用する」を参照してください。
- マージ前に少なくとも プルリクエストを必須にし 、強制プッシュを禁止する ルールを有効にしてください。 「プルリクエストを要求する」ルールでは、少なくとも1つの承認を必要とすることを確認してください。
- 必要に応じて、他のルールを有効にします。 たとえば、不適切なアクターが pull request をハイジャックすることを心配している場合は、新しいコミットがプッシュされたときに 古い pull request 承認を無視 してください。
-
リポジトリ内の特定のファイルに対して CODEOWNERS ファイルを設定するようリポジトリ管理者に勧めます。 これにより、これらのファイルが変更されると、コード所有者にレビューが自動的に要求されます。
その後、ルール セットに戻り、[ コード所有者からのレビューが必要 ] ルールを有効にすることができます。
-
組織の所有者とリポジトリ管理者は、独自のコードの要件をより認識する可能性が高い、より具体的なルールセットを作成するよう奨励します。
これらのルールセットは、エンタープライズ レベルで定義したベースラインに追加されますが、上書きされることはありません。
2. コードをテストする
DevOps の優れたプラクティスにより、マージとデプロイの前にコードが自動的にテストされ、既定のブランチに入って運用環境で発生するエラーのリスクを最小限に抑えることができます。
- GitHub Actions または別の CI/CD システムを有効にしてください。
- 開発者に対して、すべての機能に対するテストを作成し、そのテストを GitHub Actions ワークフローに統合することを推奨します。
- リポジトリ所有者または組織の所有者に対して、ルールセットを作成し、重要なワークフローをマージ前にワークフローがパスすることを要求するルールに追加することを推奨します。
3. コードをスキャンして脆弱性を検出する
Copilot は、コードベースに脆弱性を導入しないように設計されています。 たとえば、Copilotコーディングエージェント によって作成されたコードは、API キーなどの脆弱なパターンとシークレットを自動的にスキャンします。
ただし、すべてのコードで脆弱性とシークレットを定期的にスキャンし、開発者が最初に脆弱性を導入できないようにすることをお勧めします。
- 開始点として、推奨される GitHub のセキュリティ構成を組織に適用して強制します。 これは、code scanning、secret scanning、シークレットプッシュ保護などのセキュリティ機能の有効化設定のコレクションです。 「カスタム セキュリティ構成を作成する」を参照してください。
- ニーズの詳細については、カスタム構成を作成するか、リポジトリ レベルで詳細な設定を適用します。
- プル要求に code scanning を適用するには、ルール セットに戻り、 Require code scanning 結果 ルールを有効にします。
4. Copilot のガイドラインを作成する
最初に、Copilotの提案の品質を向上させるには、カスタム命令を作成する必要があります。 次の手順では、Copilot に会社のコーディング標準に従うように指示するすべてのプロンプトにコンテキストを追加します。
- 適切なベースラインを確立するには、 組織レベルでカスタム指示を作成します。 これらは、任意のリポジトリに適用される可能性が高い高レベルの標準である可能性があります。 ただし、これらの手順はGitHub Web サイトにのみ適用されることに注意してください。 「GitHub Copilot の組織のカスタム手順を追加する」を参照してください。
- より完全なカバレッジを達成するために、開発者やリポジトリ管理者に特定のリポジトリに関するカスタムの指示を作成するよう勧めます。 これらは組織の指示よりも多くの場所に適用され、各プロジェクトとその要件について詳しく説明できます。 「GitHub Copilot用のリポジトリカスタム命令の追加」を参照してください。
5. ベスト プラクティスを奨励する
強力なガードレールが整っているため、開発者は既にAIを効果的に使用することができるはずです。 ただし、AI ツールに関するトレーニングを提供し、単に適用するのではなく、ベスト プラクティスが推奨される文化を作成することが重要です。
- 開発者がCopilot を使用する際のガバナンス設定と貴社の期待をしっかりと伝達してください。 たとえば、すべてのエージェント作業を十分に確認する必要がある場合は、このプロセスが確立され、伝達されていることを確認します。
- 内部ドキュメントやビデオなどのオンボード リソースを作成します。 開始点として、 GitHub Copilot の使用に関するベスト プラクティス や GitHub Copilot チャットクックブック などの既存のリソースを共有します。
- ワークショップなどの継続的なトレーニングとサポートを提供します。 ロールアウトを成功させるには、Copilot を効果的に使用する方法について他のユーザーをトレーニングできる "チャンピオン" を特定する企業が多数あります。
6. 最悪の事態を計画する
最も厳密なガードレールが配置されていても、開発者が AI ツールを使用しているかどうかに関係なく、脆弱なコードやエラーが発生しやすいコードがマージされる可能性は常にあります。
これらのシナリオに備えて、問題に対処し、この計画を開発者に伝える方法を計画する必要があります。 例えば次が挙げられます。
- 誤ったプル要求を元に戻し、デプロイメントをロールバックします。
- 問題の原因と今後の回避方法を分析するディスカッション投稿を作成します。
- 監査ログで、ルールセットのバイパス、不適切なアクセス許可、ガバナンス設定の変更などを確認します。
7. コードの品質を確認する
ガバナンスモデルに自信を持っていても、Copilot によって時間の経過とともにコードベースの品質が低下することを懸念している場合は、ロールアウトの過程で測定することができます。 有効にした場合、GitHub Code Quality はリポジトリ内のコード健康に関する指標を提供します。 「GitHubのコード品質について」を参照してください。
次のステップ
企業が監査ログを使用して、構成設定とライセンス割り当ての変更を監視する方法について説明します。 「GitHub Copilot Business の監査ログの確認」を参照してください。