Skip to main content

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

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

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

Copilotコーディングエージェント は、GitHub Copilot Pro、GitHub Copilot Pro+、GitHub Copilot ビジネス、GitHub Copilot Enterprise プランで使用できます。 エージェントは、マネージド ユーザー アカウント によって所有されて明示的に無効になっているリポジトリを除き、GitHub に格納されているすべてのリポジトリで使用できます。
Sign up for Copilot

メモ

          Copilotコーディングエージェントの概要については、[AUTOTITLE](/copilot/concepts/about-copilot-coding-agent) を参照してください。

課題の範囲が適切であることを確認する

          GitHub Copilot は、明確で適切なスコープのタスクが割り当てられた場合に、より優れた結果を提供します。 理想的なタスクには以下が含まれます。
  • 解決すべき問題または必要な作業の明確な説明。
  • 適切なソリューションのイメージに関する完全な受け入れ基準 (単体テストが必要かなど)。
  • 変更すべきファイルに関する指示。

ヒント

          Copilotコーディングエージェント には、セマンティック コード検索を含むコードベースを検索する機能があります。これは、テキストの正確な一致だけでなく、意味に基づいて関連するコードを見つけるのに役立ちます。 タスクで正確なファイル パスを指定しない場合でも、エージェントは多くの場合、適切なコードを単独で検出できます。

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

与えるタスクの適切な種類の選択 Copilot

          Copilotを使用すると、作業に最適なタスクの種類を把握できます。 最初に、 Copilot 単純なタスクを提供して、コーディング エージェントとしての動作を確認することをお勧めします。 たとえば、バグの修正、ユーザー インターフェイス機能の変更、テスト カバレッジの向上、ドキュメントの更新、アクセシビリティの向上、技術的負債への対処を Copilot に依頼することから始めることができます。

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

* 複雑でスコープが広いタスク

  • クロスリポジトリの知識とテストが必要となる、広範なスコープのコンテキストに富んだリファクタリングの問題

  • 依存関係とレガシ コードを理解する必要がある複雑な issue

  • ドメインに関する深い知識を必要とするタスク

  • 重要なビジネス ロジックを含むタスク

  • 設計の一貫性が必要なコードベースに対する大きな変更

  •         **機密性が高く重要なタスク**
    
    • 生産に関わる重大な問題
    • セキュリティ、個人を特定できる情報、認証に影響を及ぼすタスク
    • インシデント対応
  •         **あいまいなタスク**
    
    • 明確な定義がないタスク: あいまいな要件を含むタスク、明確な答えのないタスク、解決策を見つけるために不確実な状態で作業を行う必要があるタスク
  •         **学習のためのタスク**
    
    • 開発者がより深い理解を得るために学習するためのタスク

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

pull request での Copilot の操作は、人間の開発者と一緒に作業するのと同じです。プル要求がマージされる前に、さらに作業が必要になるのが一般的です。 プル要求をマージ可能な状態に取得するプロセスは、pull request が Copilot によって作成されたときと、人間が作成したときとまったく同じです。

さらに、あなたは次のことができます:

  • pull request のコメントに@copilotを記載し、正しくない点や改善の余地がある点について説明してください。Copilotは、その内容をプルリクエストのブランチに直接コミットします。
  • pull request でのマージの競合を解決するように Copilot に依頼します。 「既存の pull request に変更を加えるようにGitHub Copilotに要求する」を参照してください。
  • 機能ブランチで自分で作業し、変更をプル要求にプッシュします。

書き込みアクセスメンションを持つユーザーがコメントに @copilot すると、 Copilot は必要な変更を開始し、完了すると pull request を更新します。 Copilotは送信されるとすぐにコメントの表示を開始するため、pull request で複数のコメントを作成する可能性がある場合は、[1 つのコメントの追加] をクリックするのではなく、[レビューの開始] をクリックしてバッチ処理することをお勧めします。 その後、すべてのコメントを一度に送信し、個々のコメントを個別に操作するのではなく、 Copilot をトリガーして、レビュー全体で作業することができます。

メモ

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

          Copilotが pull request に変更を加えると、タイトルと本文が最新の状態に保たれ、現在の変更が反映されます。

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

リポジトリにカスタム命令を追加することで、プロジェクトを理解する方法と、その変更をビルド、テスト、検証する方法に関する Copilot をガイドできます。

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

          Copilotコーディングエージェント では、さまざまな種類のカスタム命令ファイルがサポートされています。
  • /.github/copilot-instructions.md
  • /.github/instructions/**/*.instructions.md
  • **/AGENTS.md
  • /CLAUDE.md
  • /GEMINI.md

詳細については、「GitHub Copilot用のリポジトリカスタム命令の追加」を参照してください。

リポジトリ全体のガイドライン

リポジトリ内の Copilot に割り当てられているすべてのタスクに適用される手順を追加するには、リポジトリのルートに .github/copilot-instructions.md ファイルを作成します。 このファイルには、プロジェクトのビルドとテスト方法、および従う必要があるコーディング標準や規則など、プロジェクトに関する情報 Copilot 含める必要があります。 手順は、 Copilot チャット と Copilotコード レビューにも適用されることに注意してください。

指定されたリポジトリでプル要求を初めて作成するように Copilot に依頼すると、Copilot はカスタム命令を自動生成するためのリンクが含まれたコメントを残します。 また、推奨されるプロンプトを使用して、いつでもカスタム命令を生成するように Copilot に依頼することもできます。 「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

パス固有の指示

単体テストや React コンポーネントなど、 Copilot が動作する特定の種類のファイルに適用される手順を追加するには、リポジトリに 1 つ以上の .github/instructions/**/*.instructions.md ファイルを作成します。 これらのファイルには、ファイルの種類に関する情報 (ビルドとテストの方法など) と、従う必要があるコーディング標準や規則 Copilot 含めます。

指示ファイルの front matter で glob パターンを使って、それを適用する必要があるファイルの種類を指定できます。 たとえば、Playwright テストの命令を作成するには、次の内容を含む .github/instructions/playwright-tests.instructions.md という命令ファイルを作成できます。

---
applyTo: "**/tests/*.spec.ts"
---

## Playwright test requirements

When writing Playwright tests, please follow these guidelines to ensure consistency and maintainability:

1. **Use stable locators** - Prefer `getByRole()`, `getByText()`, and `getByTestId()` over CSS selectors or XPath
1. **Write isolated tests** - Each test should be independent and not rely on other tests' state
1. **Follow naming conventions** - Use descriptive test names and `*.spec.ts` file naming
1. **Implement proper assertions** - Use Playwright's `expect()` with specific matchers like `toHaveText()`, `toBeVisible()`
1. **Leverage auto-wait** - Avoid manual `setTimeout()` and rely on Playwright's built-in waiting mechanisms
1. **Configure cross-browser testing** - Test across Chromium, Firefox, and WebKit browsers
1. **Use Page Object Model** - Organize selectors and actions into reusable page classes for maintainability
1. **Handle dynamic content** - Properly wait for elements to load and handle loading states
1. **Set up proper test data** - Use beforeEach/afterEach hooks for test setup and cleanup
1. **Configure CI/CD integration** - Set up headless mode, screenshots on failure, and parallel execution

組織全体のカスタム手順

          Copilotコーディングエージェント は、組織のカスタム指示をその作業の一部として活用します。 
          Copilotコーディングエージェント 最初に、リポジトリ全体のカスタム命令に優先順位を付けます。 組織のカスタム手順を構成する方法の詳細については、 [AUTOTITLE](/copilot/how-tos/configure-custom-instructions/add-organization-instructions) を参照してください。

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

MCP を使用して、 Copilotコーディングエージェント の機能を拡張できます。 これにより、 Copilotコーディングエージェント はローカルおよびリモートの MCP サーバーによって提供されるツールを使用できます。 GitHub MCP サーバーと Playwright MCP サーバーは、既定で有効になっています。 詳細については、「モデル コンテキスト プロトコル (MCP) を使用したGitHub Copilotコーディング エージェントの拡張」を参照してください。

作成中 カスタム エージェント

カスタム手順はリポジトリ全体の Copilotの一般的な動作をガイドするのに役立ちますが、 カスタム エージェント 集中した専門知識とカスタマイズされたツール構成を使用して、完全に特殊なエージェントを作成できます。 これらのエージェントは、ドメインの専門知識と一貫した動作が重要な特定の繰り返しのワークフロー用に設計されています。 カスタム・エージェント は、 エージェント プロファイルと呼ばれる Markdown ファイルとして定義されます。

作成できる カスタム エージェント の例をいくつか次に示します。

  •         **テスト スペシャリスト**: 特定のテスト フレームワークで構成され、テスト カバレッジ、テスト品質、テストのベスト プラクティスに重点を置いたエージェント。 読み取り、検索、編集のツールに制限され、運用コードに意図しない変更が加えられるのを防ぎ、包括的なテスト カバレッジを確保できます。
    
  •         **ドキュメントの専門家**: ドキュメントの標準、スタイル ガイド、およびコードを分析して正確な API ドキュメントとユーザー ガイドを生成する機能に関する深い知識を持つ、プロジェクト ドキュメントの作成と保守に特化したエージェント。
    
  •         **Python スペシャリスト**: Python の規則、Django や Flask などの一般的なフレームワークを理解し、PEP 標準に従う言語固有のエージェント。 Python ツール、仮想環境、pytest などのテスト フレームワークに関する専門知識が必要です。
    

既定では、 カスタム エージェント リポジトリで構成されている MCP サーバー ツールを継承しますが、特定のツールにのみアクセスできるように カスタム エージェント を構成することもできます。

          カスタム エージェントは、問題の割り当て時やタスクのプロンプト時など、Copilotコーディングエージェントを使用する任意の場所で使用できます。

          カスタム エージェントの作成と構成の詳細については、[AUTOTITLE](/copilot/how-tos/use-copilot-agents/coding-agent/create-custom-agents) を参照してください。

          GitHub Copilotの環境での依存関係の事前インストール

タスクに取り組んでいる間、 Copilot は独自のエフェメラル開発環境にアクセスでき、 GitHub Actionsを利用して、コードの探索、変更、自動テストやリンターの実行などを行うことができます。

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

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

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