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

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

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

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

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

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

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

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

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

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

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

  • 生産に関わる重大な問題
  • セキュリティ、個人を特定できる情報、認証に影響を及ぼすタスク
  • インシデント対応

•         **あいまいなタスク**
  

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

•         **学習のためのタスク**
  

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

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

Pull request で Copilot を操作することは、人間の開発者と作業するのと同じです。Pull request をマージする前に、追加の作業が必要になることがよくあります。 Pull request を Copilot が作成した場合、pull request をマージ可能な状態に取得するプロセスは人間が作成した場合とまったく同じです。

Pull request のコメントに @copilot をメンションして、正しくないと思われる内容や改善できる内容を説明することで、Copilot に必要な変更作業を任せることもできます。 または、機能ブランチを自分で操作し、pull request に変更をプッシュできます。

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

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

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

リポジトリにカスタム命令を追加することで、Copilot をガイドし、projectを理解する方法と、その変更をビルド、テスト、検証する方法について説明します。

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

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 に特定のリポジトリに pull request を作成するように初めて依頼すると、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 コンポーネントなどの場合、リポジトリに 1 つ以上の .github/instructions/**/*.instructions.md ファイルを作成します。Copilot がこれに対応します。 これらのファイルには、ファイルの種類に関する情報 (ビルドやテストの方法など) と、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コーディングエージェント は、最初にリポジトリ全体のカスタム命令に優先順位を付けます。 組織のカスタム手順を構成する方法の詳細については、 GitHub Copilot の組織のカスタム手順を追加する を参照してください。

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

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

カスタム エージェント を作成する

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

こちらが作成できる カスタム エージェント の例です。

•         **テスト スペシャリスト**: 特定のテスト フレームワークで構成され、テスト カバレッジ、テスト品質、テストのベスト プラクティスに重点を置いたエージェント。 読み取り、検索、編集のツールに制限され、運用コードに意図しない変更が加えられるのを防ぎ、包括的なテスト カバレッジを確保できます。
  

•         **ドキュメントの専門家**: ドキュメントの標準、スタイル ガイド、およびコードを分析して正確な API ドキュメントとユーザー ガイドを生成する機能に関する深い知識を持つ、プロジェクト ドキュメントの作成と保守に特化したエージェント。
  

•         **Python スペシャリスト**: Python の規則、Django や Flask などの一般的なフレームワークを理解し、PEP 標準に従う言語固有のエージェント。 Python ツール、仮想環境、pytest などのテスト フレームワークに関する専門知識が必要です。
  

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

カスタム エージェント は、Copilotコーディングエージェント を使用するすべての場合、たとえばイシューを割り当てる場合やタスクをプロンプトするときなどに使用できます。

カスタム エージェント の作成と構成の詳細については、「Copilotコーディングエージェント 用のカスタム エージェントの作成」を参照してください。

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

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

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

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

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