GitHub Copilot Coding Agent の使い方

GitHub Copilot Coding Agent はパブリック プレビュー段階にあり、変更される場合があります。プレビュー期間中、この機能の使用は以下の対象となります GitHub プレリリース ライセンス条項.
Copilot コーディング エージェント は、有効になっているリポジトリの GitHub Copilot Business、GitHub Copilot Pro+ および GitHub Copilot Enterprise プランで使用できます。 Copilot コーディング エージェント は、マネージド ユーザー アカウント によって所有されるリポジトリでは使用できません。 Sign up for Copilot.

Copilot を使用して issue を処理する

GitHub Copilot に issue を割り当て、Copilot が issue を処理する際の進行状況を監視し、pull request レビュー コメントを使用して Copilot に処理を繰り返し実行するように求める方法について説明します。

GitHub.com で Copilot に issue を割り当てる

別のユーザーを割り当てるのとまったく同じ方法で、GitHub.com の Copilot に issue を割り当てることができます。

  1. GitHub で、リポジトリのメイン ページに移動します。

  2. リポジトリ名の下にある [イシュー] をクリックします。

  3. Copilot に割り当てる issue を開きます。

  4. 右側のメニューで [担当者] をクリックします。

  5. 担当者の一覧から [Copilot] をクリックします。

Copilot に issue を割り当てると、issue のタイトル、説明、および現在存在するすべてのコメントが送信されます。 Issue を割り当てた後、Copilot はその issue に追加された以降のコメントを認識せず、したがってそれに応答しません。 さらに詳しい情報がある場合、または元の要件に変更がある場合は、Copilot が作成した pull request にコメントとして追加してください。

GitHub.com のその他の場所から Copilot に issue を割り当てることもできます。

  • リポジトリの [Issues] ページにある issue の一覧から。
  • GitHub プロジェクト で issue を表示しているとき。

Issue に関する Copilot の進行状況を追跡する

Copilot に issue を割り当てた直後に、Copilot は issue に対して 👀 の応答を残します。

数秒後、Copilot は、元の issue にリンクされた下書きの pull request を開きます。 イベントが issue のタイムラインに表示され、pull request にリンクされます。

Copilot が issue を処理するためのエージェント セッションを開始します。 “Copilot started work” イベントが pull request タイムラインに表示され、Copilot が機能すると、通常の状態の更新で pull request 本文が更新され、コミットがブランチにプッシュされます。

Copilot の処理状況を確認する場合は、[View session] をクリックします。 セッション ログ ビューアーが表示され、Copilot による issue の処理のライブ ログが表示されます。 Issue に対する Copilot の処理を停止する場合は、[Stop session] をクリックします。 「Copilot コーディング エージェント ログの使用」を参照してください。

Copilot が終了すると、エージェント セッションが終了し、Copilot がレビューを要求し、通知をトリガーします。 さらに、pull request タイムラインに “Copilot finished work” イベントが表示されます。

Copilot の変更をレビューする

Copilot がコーディング タスクの作業を完了し、pull request レビューを要求したら、pull request をマージする前に、Copilot の作業を十分にレビューする必要があります。

重要: “必須の承認” ルールまたはブランチ保護が有効になっている場合、関連する issue を Copilot に割り当てることで自分が開始した pull request を承認することはできません。 マージする前に、他のユーザーが pull request を承認する必要があります。

Pull request のコメントを使用して変更を行うように Copilot に依頼するか、Copilot のブランチをチェックアウトして自分で変更を加えることができます。

レビュー コメントを個別に送信するのではなく、バッチ処理することをお勧めします。

Copilot の pull request にコメントを残すと、Copilot はコメントを考慮し、新しいエージェント セッションを開始して応答すべきかどうかを決定します。

Copilot only responds to comments from people who have write access to the repository.

Copilot がコメントに応答して新しいエージェント セッションを開始すると、コメントへの応答として目の絵文字 (👀) が追加され、pull request のタイムラインに “Copilot has started work” イベントが追加されます。

Copilot は、コメントが無関係と判断すると、そのコメントを無視できます。 Copilot に確実にコメントに応答させたい場合は、コメントに @copilot を含めることで、Copilot を @mention することができます。

Copilot が pull request のコメントに応答しないようにする場合は、pull request から Copilot の割り当てを解除できます。 後で同じ pull request に Copilot を再割り当てすると、新しいコメントに応答し、さらに変更をプッシュするようになります。 割り当てられていなかった間に追加されたコメントには応答しません。

詳細については、「Copilot を使用してタスクに取り組むためのベスト プラクティス」の「コメントを使用して pull request を繰り返す」セクションを参照してください。


Copilot を使用してタスクに取り組むためのベスト プラクティス

Copilot コーディング エージェント から最適な結果を得る方法について説明します。

Issue のスコープが適切であることを確認する

明確で適切なスコープのタスクを割り当てると、GitHub Copilot はより優れた結果を提供します。 理想的なタスクには以下が含まれます。

  • 解決すべき問題または必要な作業の明確な説明。
  • 適切なソリューションのイメージに関する完全な受け入れ基準 (単体テストが必要かなど)。
  • 変更すべきファイルに関する指示。

Issue を割り当てることでタスクを Copilot に渡す場合は、Copilot に割り当てる issue をプロンプトとして考えると便利です。 Issue の説明が AI プロンプトとして機能する可能性があるかどうかを検討し、Copilot が必要なコード変更を行えるようにします。

Copilot に提供すべき適切な種類のタスクを選択する

Copilot を使用しているうちに、作業に最適なタスクの種類がわかるようになります。 最初に、Copilot に単純なタスクを提供して、コーディング エージェントとしてどのように機能するかを確認するといいかもしれません。 たとえば、バグの修正、ユーザー インターフェイス機能の変更、テスト カバレッジの改善、ドキュメントの更新、アクセシビリティの向上、技術的負債への対処をまず Copilot に依頼できます。

Copilot に割り当てるのではなく、自分で作業することを選択できる issue は次のとおりです。

  • 複雑で広範なスコープのタスク

    • クロスリポジトリの知識とテストが必要となる、広範なスコープのコンテキストに富んだリファクタリングの問題
    • 依存関係とレガシ コードを理解する必要がある複雑な issue
    • ドメインに関する深い知識を必要とするタスク
    • 重要なビジネス ロジックを含むタスク
    • 設計の一貫性が必要なコードベースに対する大きな変更

  • 機密性が高く重要なタスク

    • 運用に重要な影響を及ぼす issue
    • セキュリティ、個人を特定できる情報、認証に影響を及ぼすタスク
    • インシデント対応

  • あいまいなタスク

    • 明確な定義がないタスク: あいまいな要件を含むタスク、明確な答えのないタスク、解決策を見つけるために不確実な状態で作業を行う必要があるタスク

  • 学習のためのタスク

    • 開発者がより深い理解を得るために学習するためのタスク

コメントを使用して pull request を繰り返す

Pull request で Copilot を操作することは、人間の開発者と作業するのと同じです。Pull request をマージする前に、追加の作業が必要になることがよくあります。 Pull request を Copilot が作成した場合、pull request をマージ可能な状態に取得するプロセスは人間が作成した場合とまったく同じです。 必要に応じて、機能ブランチを自分で操作し、pull request に変更をプッシュできます。 ただし、pull request にコメントを追加して、正しくないと思われる内容や改善が可能な内容を説明するだけで、Copilot に必要な変更作業を任せることもできます。

書き込みアクセス権限を持つユーザーからコメントが送信されるとすぐ、Copilot は送信されたすべてのコメントを読み取り、アクションが必要かどうかを決定します。 その後、必要な変更の実行を開始し、完了すると pull request を更新します。 コメントが送信されると、Copilot はすぐにコメントをチェックするため、pull request に対して複数のコメントを作成する可能性がある場合は、[Add single comment] をクリックするのではなく、[Start a review] をクリックしてバッチ処理することをお勧めします。 その後、すべてのコメントを一度に送信することで、Copilot に個別に個々のコメントに対応させるのではなく、レビュー全体の作業を行わせることができます。

Copilot は、リポジトリへの書き込みアクセス権を持つユーザーからのコメントにのみ応答します.

リポジトリにカスタム指示を追加する

リポジトリにカスタム指示を追加することで、プロジェクトを理解する方法と、その変更をビルド、テスト、検証する方法について Copilot に説明できます。

Copilot が独自の開発環境で変更をビルド、テスト、検証できる場合、迅速にマージできる適切な pull request が生成される可能性が高くなります。

リポジトリ内の .github/copilot-instructions.md ファイルに指示を追加します。 詳しくは、「GitHub Copilot のリポジトリ カスタム命令を追加する」をご覧ください。

有効な copilot-instructions.md ファイルの例を次に示します。

This is a Go based repository with a Ruby client for certain API endpoints. It is primarily responsible for ingesting metered usage for GitHub and recording that usage. Please follow these guidelines when contributing:

## Code Standards

### Required Before Each Commit
- Run `make fmt` before committing any changes to ensure proper code formatting
- This will run gofmt on all Go files to maintain consistent style

### Development Flow
- Build: `make build`
- Test: `make test`
- Full CI check: `make ci` (includes build, fmt, lint, test)

## Repository Structure
- `cmd/`: Main service entry points and executables
- `internal/`: Logic related to interactions with other GitHub services
- `lib/`: Core Go packages for billing logic
- `admin/`: Admin interface components
- `config/`: Configuration files and templates
- `docs/`: Documentation
- `proto/`: Protocol buffer definitions. Run `make proto` after making updates here.
- `ruby/`: Ruby implementation components. Updates to this folder should include incrementing this version file using semantic versioning: `ruby/lib/billing-platform/version.rb`
- `testing/`: Test helpers and fixtures

## Key Guidelines
1. Follow Go best practices and idiomatic patterns
2. Maintain existing code structure and organization
3. Use dependency injection patterns where appropriate
4. Write unit tests for new functionality. Use table-driven unit tests when possible.
5. Document public APIs and complex logic. Suggest changes to the `docs/` folder when appropriate

モデル コンテキスト プロトコル (MCP) を使用する

MCP を使用して、Copilot コーディング エージェント の機能を拡張できます。 これにより、Copilot コーディング エージェント はローカルの MCP サーバーによって提供されるツールを使用できます。 詳しくは、「モデル コンテキスト プロトコル (MCP) を使用した Copilot コーディング エージェントの拡張」をご覧ください。

GitHub Copilot の環境に依存関係を事前にインストールする

タスクの作業中、Copilot は、GitHub Actions を利用して独自の一過性の開発環境にアクセスできます。この開発環境では、コードの探索、変更の実施、自動的なテストとリンターの実施などを行えます。

Copilot が独自の開発環境で変更をビルド、テスト、検証できる場合、迅速にマージできる適切な pull request が生成される可能性が高くなります。

そのためには、プロジェクトの依存関係が必要です。 Copilot は、試行錯誤のプロセスを通じてこれらの依存関係自体を検出してインストールできますが、大規模言語モデル (LLM) の非決定論的な性質を考えると、処理が遅く信頼性が低くなる可能性があります。

エージェントが作業を開始する前にこれらの依存関係を事前にインストールするために copilot-setup-steps.yml ファイルを構成することで、効率的な作業を実施できます。 詳しくは、「Copilot コーディング エージェントの開発環境のカスタマイズ」をご覧ください。