カスタム命令を使用して Copilot コードレビューの機能を解除する

イントロダクション

GitHub Copilot コードレビューは、指示ファイルを使用してカスタマイズして、チームのニーズとコーディング標準に合わせてレビューエクスペリエンスを調整できます。ただし、効果的なカスタム命令を記述するには、Copilot がこれらの命令をどのように処理するか、どのような方法が最適かを理解する必要があります。

このチュートリアルでは、Copilot がより関連性の高いコードレビューを提供するのに役立つ明確で効果的なカスタム命令を記述する方法について説明します。手順を構成するためのベストプラクティス、回避する一般的な落とし穴、さまざまなファイル間で命令を整理するための戦略について説明します。

このチュートリアルでは、Copilot コードレビューのカスタム手順を使用します。カスタム命令の使用に関する一般的な概要については、 GitHub Copilot のカスタム指示を構成するを参照してください。

学習内容

このチュートリアルの終わりまでに、次の内容を理解できます。

コードレビュー用の簡潔で効果的なカスタム命令を記述する方法。
リポジトリ全体の命令とパス固有の命令の違い。
Copilot コードレビューで適切に動作する一般的なパターン。
現在サポートされていない命令の種類。
最良の結果を得るために指示を構造化して整理する方法。

[前提条件]

Copilot コードレビューへのアクセス。
カスタム命令ファイルを作成できる GitHub リポジトリ。
Markdown 構文に関する基本的な知識。

GitHub Copilot のコードレビューの手順を理解する方法について

カスタム命令を記述する前に、Copilot コードレビューで使用される方法を理解しておくことが役立ちます。 pull request を確認するときに、Copilot は命令ファイルを読み取り、それらを使用してその分析をガイドします。ただし、他の AI システムと同様に、次のような制限があります。

        **非決定的な動作**: Copilot は、毎回すべての命令に完全に従うわけではありません。

        **コンテキストの制限**: 命令ファイルが非常に長い場合、一部の命令が見落とされる可能性があります。

        **特定性の問題**: 明確で具体的な命令は、あいまいな指示よりもうまく機能します。

これらの要素は、指示を書く際に念頭に置いてください。現実的な期待を設定し、より効果的なガイダンスを記述するのに役立ちます。

効果的なカスタム指示の記述

カスタム命令を成功させるには、明確で簡潔で具体的であることが重要です。以下に従う主要な原則を示します。

指示を短くし、集中させる

短い命令ファイルは、Copilot によって完全に処理される可能性が高くなります。最小限の命令セットから始めて、動作に基づいてさらに反復的に追加します。

          **ベスト プラクティス**: 1 つの命令ファイルを最大約 1,000 行に制限します。 それ以外に、応答の品質が低下する可能性があります。

明確な構造と書式を使用する

Copilot は、次のような適切に構造化された命令の利点があります。

異なるトピックを区切る個別の見出し。
容易なスキャンおよび参照のための箇条書きポイント。
長い説明的な段落ではなく、短い指示の文章。

たとえば、次の記述を行う代わりに、次の操作を行います。

When you're reviewing code, it would be good if you could try to look for
situations where developers might have accidentally left in sensitive
information like passwords or API keys, and also check for security issues.

書き込み:

## Security Critical Issues

- Check for hardcoded secrets, API keys, or credentials
- Look for SQL injection and XSS vulnerabilities
- Verify proper input validation and sanitization

具体的な例を提供する

同僚に概念を説明するように、例は Copilot があなたの意図を理解するのに役立ちます。正しいパターンと正しくないパターンの両方を示すコードスニペットを含めます。

例えば次が挙げられます。

## Naming Conventions

Use descriptive, intention-revealing names.

```javascript
// Avoid
const d = new Date();
const x = users.filter(u => u.active);

// Prefer
const currentDate = new Date();
const activeUsers = users.filter(user => user.isActive);
```

ファイル間での手順の整理

Copilot コードレビューでは、次の 2 種類の命令ファイルがサポートされています。

       **
       `copilot-instructions.md`
       **: すべてのファイルに適用されるリポジトリ全体の命令。

       **
       `*.instructions.md`
       **: 特定のファイルまたはディレクトリに適用されるパス固有の命令。

Copilot のフォーカスを維持し、言語固有の規則が誤ったファイルに適用されないようにすることを防ぐために、パス固有の手順を使用します。

リポジトリ全体の手順をいつ使用するか

次の場合に copilot-instructions.md を使用します。

一般的なチームの標準とガイドライン
ユニバーサルセキュリティ要件
エラー処理の理念などの横断的な懸念

ドキュメントの期待値

        **
        `copilot-instructions.md`の構造体の例**:

# General Code Review Standards

## Code Quality Essentials

- Functions should be focused and appropriately sized
- Use clear, descriptive naming conventions
- Ensure proper error handling throughout

## Security Standards

- Never hardcode credentials or API keys
- Validate all user inputs
- Use parameterized queries to prevent SQL injection

## Documentation Expectations

- All public functions must include doc comments
- Complex algorithms should have explanatory comments
- README files must be kept up to date

パス固有の命令を使用する場合

          `*.instructions.md` ファイルを`applyTo` frontmatter プロパティと共に使用する目的は次のとおりです。

言語固有のコーディング標準
フレームワーク固有のパターン
テクノロジ固有のセキュリティに関する懸念事項

コードベースのさまざまな部分に対して異なるルール

        **例: Python 固有の手順**

        `python.instructions.md` ディレクトリに `.github/instructions` という名前のファイルを作成します。

---
applyTo: "**/*.py"
---

# Python Coding Conventions

## Naming Conventions

- Use snake_case for variables and functions
- Use PascalCase for class names
- Use UPPERCASE for constants

## Code Style

- Follow PEP 8 style guidelines
- Limit line length to 88 characters (Black formatter standard)
- Use type hints for function signatures

## Best Practices

- Use list comprehensions for simple transformations
- Prefer f-strings for string formatting
- Use context managers (with statements) for resource management

```python
# Avoid
file = open('data.txt')
content = file.read()
file.close()

# Prefer
with open('data.txt') as file:
    content = file.read()
```

          **例: フロントエンド固有の手順**

          `frontend.instructions.md` ディレクトリに `.github/instructions` という名前のファイルを作成します。

---
applyTo: "src/components/**/*.{tsx,jsx}"
---

# React Component Guidelines

## Component Structure

- Use functional components with hooks
- Keep components small and focused (under 200 lines)
- Extract reusable logic into custom hooks

## State Management

- Use useState for local component state
- Use useContext for shared state across components
- Avoid prop drilling beyond 2-3 levels

## Accessibility

- All interactive elements must be keyboard accessible
- Include appropriate ARIA labels
- Ensure color contrast meets WCAG AA standards

複雑な命令セットの分割

多くの懸念がある大規模なリポジトリの場合は、命令を複数のフォーカスされたファイルに分割します。

.github/
  copilot-instructions.md          # General standards

.github/instructions/
  python.instructions.md           # Python-specific
  javascript.instructions.md       # JavaScript-specific
  security.instructions.md         # Security-specific
  api.instructions.md              # API-specific

各ファイルには、明確で具体的な目的と、必要に応じて適切な applyTo フロントマッターが必要です。

推奨される命令ファイルの構造

Copilot コードレビューで適切に動作するものに基づいて、手順を構成するための推奨されるテンプレートを次に示します。

---
applyTo: "**/*.{js,ts}"  # If this is a path-specific file
---

# [Title: Technology or Domain Name] Guidelines

## Purpose

Brief statement of what this file covers and when these instructions apply.

## Naming Conventions

- Rule 1
- Rule 2
- Rule 3

## Code Style

- Style rule 1
- Style rule 2

```javascript
// Example showing correct pattern
```

## Error Handling

- How to handle errors
- What patterns to use
- What to avoid

## Security Considerations

- Security rule 1
- Security rule 2

## Testing Guidelines

- Testing expectation 1
- Testing expectation 2

## Performance

- Performance consideration 1
- Performance consideration 2

この構造を特定のニーズに合わせて調整しますが、明確なセクションと箇条書きの形式を維持します。

カスタム命令に含める必要がないもの

Copilot コードレビューが現在サポートしていない内容を理解することは、効果がない指示に時間を無駄にしないようにするのに役立ちます。

サポートされていない命令の種類

Copilot コードレビューは現在、以下を試みる命令をサポートしていません。

          **ユーザー エクスペリエンスまたは書式設定を変更します**。

Use bold text for critical issues
Change the format of review comments

Add emoji to comments

        **pull request の概要コメントを変更**します。

Include a summary of security issues in the PR overview

Add a testing checklist to the overview comment

        **GitHub Copilot のコア機能を変更**します。

Block a PR from merging unless all Copilot コードレビュー comments are addressed

Generate a changelog entry for every PR

        **外部リンクに従います**。

Review this code according to the standards at https://example.com/standards

回避策: 代わりに、関連するコンテンツを命令ファイルに直接コピーします
```
        **漠然とした品質の向上**:
```
Be more accurate
Don't miss any issues
Be consistent in your feedback

これらの種類の命令は、正確で一貫したレビューを提供するように既に最適化されているため、Copilotの有効性を向上させることなくノイズを追加します。

指示のテストと繰り返し

効果的なカスタム命令を作成する最善の方法は、小さく開始し、結果に基づいて反復することです。

最小限の命令セットから始める

最も一般的なレビューのニーズに対応する具体的な手順を10〜20個用意し、それが意図したとおりにCopilot コードレビューに影響を与えているかどうかをテストします。

実際の pull request を使用してテストする

手順を作成した後:

リポジトリで pull request を開きます。
Copilot からレビューを要求します。
どの命令に効果的に従っているかを観察します。
一貫して見落とされたり、誤って解釈されたりする命令に注意してください。

結果に基づいて反復処理する

新しい手順を一度に 1 つずつ、または小さなグループに追加します。

Copilot がより適切に確認できるパターンを特定します。
そのパターンの特定の命令を追加します。
新しい pull request を使用してテストします。
結果に基づいて命令を調整します。

この反復的なアプローチは、何が機能するのかを理解し、命令ファイルに焦点を当て続けるのに役立ちます。

例: コードレビューのカスタム手順を完了する

このチュートリアルのすべてのベストプラクティスを組み込んだ完全な例を次に示します。

          **ファイル： `.github/copilot-instructions.md`**

# General Code Review Standards

## Purpose

These instructions guide Copilot コード レビュー across all files in this repository.
Language-specific rules are in separate instruction files.

## Security Critical Issues

- Check for hardcoded secrets, API keys, or credentials
- Look for SQL injection and XSS vulnerabilities
- Verify proper input validation and sanitization
- Review authentication and authorization logic

## Performance Red Flags

- Identify N+1 database query problems
- Spot inefficient loops and algorithmic issues
- Check for memory leaks and resource cleanup
- Review caching opportunities for expensive operations

## Code Quality Essentials

- Functions should be focused and appropriately sized (under 50 lines)
- Use clear, descriptive naming conventions
- Ensure proper error handling throughout
- Remove dead code and unused imports

## Review Style

- Be specific and actionable in feedback
- Explain the "why" behind recommendations
- Acknowledge good patterns when you see them
- Ask clarifying questions when code intent is unclear

## Testing Standards

- New features require unit tests
- Tests should cover edge cases and error conditions
- Test names should clearly describe what they test

Always prioritize security vulnerabilities and performance issues that could impact users.

          **ファイル： `.github/instructions/typescript.instructions.md`**

---
applyTo: "**/*.{ts,tsx}"
---

# TypeScript Development Standards

## Type Safety

- Avoid using `any` type—use `unknown` or specific types instead
- Use strict null checks (no `null` or `undefined` without explicit handling)
- Define interfaces for all object shapes

```typescript
// Avoid
function processData(data: any) {
    return data.value;
}

// Prefer
interface DataShape {
    value: string;
}

function processData(data: DataShape): string {
    return data.value;
}
```

## Naming Conventions

- Use PascalCase for types, interfaces, and classes
- Use camelCase for variables, functions, and methods
- Use UPPER_CASE for constants

## Modern TypeScript Patterns

- Use optional chaining (`?.`) and nullish coalescing (`??`)
- Prefer `const` over `let`; never use `var`
- Use arrow functions for callbacks and short functions

## React-Specific (for .tsx files)

- Use functional components with TypeScript props interfaces
- Type all props and state explicitly
- Use proper event types (e.g., `React.ChangeEvent<HTMLInputElement>`)

一般的な問題のトラブルシューティング

Copilot コードレビューが想定どおりに手順に従っていない場合は、次の解決策をお試しください。

問題: 命令は無視されます

          **考えられる原因**:

命令ファイルが長すぎます (1,000 行を超える)。
指示は曖昧です。
命令は互いに競合します。
```
        **解決策**:
```
重要度の低い命令を削除して、ファイルを短くします。
あいまいな命令をより具体的で実用的に書き換えます。
競合する手順を確認し、最も重要な手順に優先順位を付けます。

問題: 間違ったファイルに適用される言語固有の規則

          **考えられる原因**:

フロントマッター applyTo が不足しているか、間違っています。
パス固有のファイルではなく、リポジトリ全体のファイル内の規則。
```
        **解決策**:
```

        `applyTo` frontmatter をパス固有の命令ファイルに追加します。

言語固有の規則を copilot-instructions.md から適切な *.instructions.md ファイルに移動します。

問題: レビュー全体の動作に一貫性がない

          **考えられる原因**:

命令が多すぎます。
命令に固有性がありません。
AI 応答の自然な変動。
```
        **解決策**:
```
最も優先度の高い手順に焦点を当てます。
意図を明確にするための具体的な例を追加します。
AI システムでは、一部の変動が正常であることを受け入れます。

Conclusion

効果的なカスタム手順は、Copilot コードレビューが、チームの標準に合わせて調整された、より関連性の高い実用的なフィードバックを提供するのに役立ちます。このチュートリアルの原則に従うことで、命令を簡潔に保ち、明確な構造を提供し、具体的な例を使用して、複数のファイル間で整理することで、コードレビューエクスペリエンスを大幅に向上させることができます。

効果的な命令の作成は反復的なプロセスであることを忘れないでください。少数の集中した手順から始めて、実際の pull request でテストし、チームにとって適切な内容に基づいて徐々に拡張します。

次のステップ

Awesome GitHub Copilot リポジトリにあるカスタム命令の例を参考にして、インスピレーションを得てください。
さまざまなカスタマイズオプションについて詳しくは、 GitHub Copilot 応答のカスタマイズについてをご覧ください。
命令ファイルの設定に関する技術的な詳細については、 GitHub Copilot のカスタム指示を構成するを参照してください。

カスタム命令を使用して Copilot コード レビューの機能を解除する

この記事の内容

カスタム命令を使用して Copilot コードレビューの機能を解除する