GitHub Copilot の高度なカスタマイズ
GitHub Copilot は、モノリシックな万能システムではありません。代わりに、3 つのレベルが提供されます の カスタマイズ アシスタントの動作を調整できるようになります AI は個人、プロジェクト、組織のニーズに対応します。理解して設定する これらのレベルを正確に把握することが、より正確な提案を得る鍵となり、 騒音を軽減し、チームの生産性を最大化します。
この記事では、構成からカスタマイズの各レベルについて詳しく説明します。 担当者からリポジトリの指示、組織のポリシーまで。私たちも探索してみます との統合 モデルコンテキストプロトコル (MCP) と戦略 コンテンツの除外 機密コードを保護します。
シリーズ全体の概要
| # | アイテム | 集中 |
|---|---|---|
| 1 | 基礎と考え方 | セットアップとメンタリティ |
| 2 | コンセプトと要件 | アイデアから MVP まで |
| 3 | バックエンド/フロントエンドのアーキテクチャ | APIとデータベース |
| 4 | コードの構造 | 組織と命名 |
| 5 | 迅速なエンジニアリング | MCP プロンプトとエージェント |
| 6 | テストと品質」 | ユニット、統合、E2E |
| 7 | ドキュメント | README、API ドキュメント、ADR |
| 8 | デプロイとDevOps | ドッカー、CI/CD |
| 9 | 進化 | スケーラビリティとメンテナンス |
| 10 | コーディングエージェント | GitHub自律エージェント |
| 11 | コードレビュー | 自動レビュー |
| 12 | 副操縦士の編集 | 複数ファイルの編集 |
| 13 | GitHub スパーク | コード不要のマイクロアプリ |
| 14 | 副操縦士スペース | 共有コンテキスト |
| 15 | AIモデル | マルチモデルと選択 |
| 16 | 現在位置 → カスタマイズ | 手順とセットアップ |
| 17 | エンタープライズとビジネス | 計画、分析、ポリシー |
| 18 | 拡張機能とマーケットプレイス | 拡張機能と統合 |
| 19 | 安全性と責任ある使用 | セキュリティとコンプライアンス |
カスタマイズの 3 つのレベル
GitHub Copilot は 3 つのレベルでカスタム ステートメントをサポートしており、それぞれにスコープがあります そして別の優先順位。複数のレベルが同時にアクティブな場合、指示は 正確な優先順位に従って結合されます。
命令階層
| レベル | 範囲 | 優先度' | 管理者 | 可用性' |
|---|---|---|---|---|
| 個人的な指示 | すべての個人的な会話 | 高 (オーバーライド) | シングルユーザー | 全フロア |
| リポジトリの説明 | 単一リポジトリ | 平均 | プロジェクトチーム | 全フロア |
| 組織の指示 | 組織全体 | 低（基本） | 組織所有者 | 企業 |
組み合わせの仕組み
Copilot はリクエストを受信すると、利用可能なすべてのレイヤーから命令を収集します。 そしてそれらを単一のコンテキストに結合します。競合がある場合は、優先順位の高い命令が優先されます。 勝つ。たとえば、組織の指示で英語での回答が必要な場合 しかし、個人的な指示にはイタリア語が指定されており、副操縦士はイタリア語で応答します。
カスタム指示が会話のコンテキストとして自動的に追加されます 副操縦士チャットで。これらはインライン コード補完の提案には適用されません。 ただし、チャット、エージェント モード、レビューでの応答には影響します。
個人的な指示
個人的な指示が適用されるのは、 すべての会話 あなたが持っているもの GitHub Web サイト (github.com) の Copilot Chat。これらはカスタマイズする最も直接的な方法です 副操縦士の動作は個人の好みに応じて変更できます。
設定できる内容
個人的な指示は、あらゆるものに適用される設定を定義するのに最適です。 あなたが取り組んでいるプロジェクト。カスタマイズの主なカテゴリは次のとおりです。
パーソナルパーソナライゼーションのカテゴリ
| カテゴリ | Esempio | 効果 |
|---|---|---|
| Lingua | 必ずイタリア語で返信してください | 答えはすべてイタリア語で行われます |
| 対応スタイル | 簡潔にしてください（最大 200 単語） | 短くて直接的な回答 |
| 形式 | 常に言語とともにコード ブロックを使用する | 正しくフォーマットされたコード |
| スキル | 私は上級 Java 開発者です | 上級レベルの解答 |
| 技術的な好み | 関数型プログラミングの方が好きです | 機能的なスタイルのヒント |
| 仕事の背景 | Spring Boot マイクロサービスに取り組んでいます | コンテキストに応じた提案 |
個別指示の設定方法
GitHub で個人的な指示を設定するには:
- 上がる github.com そしてログインしてください
- 右上のプロフィール写真をクリックします
- 選択 設定
- サイドバーで、 副操縦士
- 「個人的な説明」セクションで、をクリックします。 編集
- テキストエリアに指示を書きます
- クリック 保存
効果的な個別指導の例
# Profilo Sviluppatore
Sono un senior full-stack developer con 8 anni di esperienza.
Stack principale: Java (Spring Boot), TypeScript (Angular), PostgreSQL.
Lavoro su architetture a microservizi in ambiente cloud (AWS).
# Preferenze Lingua
Rispondi sempre in italiano.
Usa terminologia tecnica in inglese quando appropriato
(es. "dependency injection", "middleware", "endpoint").
# Stile di Risposta
- Sii conciso e vai dritto al punto
- Fornisci sempre esempi di codice quando possibile
- Includi commenti nel codice solo per logica complessa
- Specifica le versioni quando suggerisci dipendenze
- Segnala potenziali problemi di performance o sicurezza
# Convenzioni di Codice
- Java: Google Java Style Guide
- TypeScript: ESLint con configurazione strict
- SQL: uppercase per keywords, lowercase per nomi tabelle
- Naming: camelCase per variabili, PascalCase per classi
- Test: pattern Given-When-Then per test names
# Anti-Pattern da Evitare
- Non suggerire mai codice senza gestione errori
- Non usare "any" in TypeScript
- Non suggerire query SQL con SELECT *
- Non ignorare la validazione degli input個人的な指示の制限
個人的な指示が適用されます 一人で github.com の会話へ (ブラウザでの副操縦士チャット)。これらは IDE (VS Code、VS Code、 ジェットブレインズ）。 IDE での動作をカスタマイズするには、リポジトリの手順を使用します。 またはエディター固有の設定。
さらに、個人的な指示には、そのような明示的な文字数制限がありません。 ただし、コンテキストが過負荷にならないように、簡潔に保つことをお勧めします。 モデルの。
リポジトリの説明
リポジトリ ステートメントは、チームにとって最も強力なレベルのカスタマイズです 開発の。これらはリポジトリ内のファイルを介して定義され、適用されます。 そのプロジェクトに取り組んでいるすべてのチームメンバーに自動的に送信されます。
メインファイル: .github/copilot-instructions.md
リポジトリ手順のメイン ファイルは次のとおりです。 .github/copilot-instructions.md。
このファイルは、ユーザーが操作するたびに Copilot によって自動的に読み取られます。
リポジトリ。コンテンツは、すべての Copilot の会話にコンテキストとして追加されます
プロジェクトに関するチャット。
# Copilot Instructions per TaskFlow Frontend
## Stack Tecnologico
- Framework: Angular 21 con standalone components
- Linguaggio: TypeScript 5.9 strict mode
- Styling: SCSS con BEM methodology
- State Management: Angular Signals
- HTTP: Angular HttpClient con interceptors
- Routing: Angular Router con lazy loading
- Testing: Jasmine + Karma per unit, Cypress per E2E
## Convenzioni di Codice
### Componenti
- Usa SEMPRE standalone components (no NgModules)
- Change detection: OnPush per tutti i componenti
- Usa signals() per stato reattivo, non BehaviorSubject
- Template: file separato (.html) per componenti > 20 righe
- Stili: file separato (.scss) sempre
### Naming Conventions
- Componenti: PascalCase con suffisso Component (es. UserProfileComponent)
- Servizi: PascalCase con suffisso Service (es. AuthService)
- Interfacce: PascalCase con prefisso I (es. IUserProfile)
- File: kebab-case (es. user-profile.component.ts)
- Costanti: UPPER_SNAKE_CASE (es. MAX_RETRY_COUNT)
### Pattern Obbligatori
- Ogni servizio HTTP deve avere error handling centralizzato
- Usare pipe async o toSignal() nel template, mai subscribe manuale
- Route guards come functional guards (non class-based)
- Form: reactive forms con FormBuilder, mai template-driven
- Validazione: custom validators in file separato
### Struttura Directory
```
src/app/
features/ # Feature modules (lazy loaded)
shared/ # Componenti, pipe, direttive condivise
core/ # Servizi singleton, interceptors, guards
models/ # Interfacce e tipi
environments/ # Configurazioni ambiente
```
### Testing
- Ogni componente DEVE avere unit test
- Coverage minima: 80% per servizi, 70% per componenti
- Mock pattern: usa jasmine.createSpyObj per dipendenze
- Naming test: "should [expected behavior] when [condition]"
### Performance
- Lazy load tutte le feature routes
- Usa trackBy per *ngFor (o @for con track)
- Immagini: usa NgOptimizedImage
- Bundle size alert: > 500KB per chunk e' un warning
### Accessibilita'
- Ogni elemento interattivo deve avere aria-label
- Contrasto colori: WCAG AA (4.5:1 minimo)
- Tab navigation deve funzionare per tutti i form
- Screen reader: testare con NVDA o VoiceOverパス固有の命令
一般的なファイルに加えて、Copilot は特定のパスに対する特定の命令をサポートします。 リポジトリの。これらの命令は、次のファイルを操作する場合にのみロードされます。 指定されたパターンと一致します。
パス固有のファイルはディレクトリに配置する必要があります
.github/instructions/ 拡張子付き .instructions.md。
各ファイルには、どのパスに適用されるかを指定する YAML ヘッダーが含まれています。
---
applyTo: "**/*.spec.ts"
---
# Istruzioni per File di Test
## Struttura Test
- Usa describe() per raggruppare test per metodo/funzionalità'
- Usa beforeEach() per setup comune
- Pattern AAA: Arrange, Act, Assert in ogni test
## Naming Convention
- describe: nome della classe/funzione sotto test
- it/test: "should [cosa fa] when [condizione]"
## Mock Pattern
```typescript
const mockService = jasmine.createSpyObj('ServiceName', ['method1', 'method2']);
mockService.method1.and.returnValue(of(expectedResult));
```
## Coverage Requirements
- Branch coverage: >= 80%
- Line coverage: >= 85%
- Ogni path condizionale deve avere almeno un test
## Anti-Pattern da Evitare
- Non testare dettagli implementativi
- Non fare mock di tutto (testa integrazione dove possibile)
- Non usare setTimeout() nei test (usa fakeAsync/tick)
- Non ignorare test flaky: fixali o rimuovili---
applyTo: "src/app/core/services/**/*.ts"
---
# Istruzioni per Servizi API
## Pattern Obbligatorio
Ogni servizio API deve seguire questo pattern:
```typescript
@Injectable({ providedIn: 'root' })
export class EntityService {
private readonly apiUrl = `${environment.apiUrl}/entities`;
constructor(private http: HttpClient) {}
getAll(): Observable<Entity[]> {
return this.http.get<Entity[]>(this.apiUrl).pipe(
catchError(this.handleError)
);
}
private handleError(error: HttpErrorResponse): Observable<never> {
// Centralizzato nell'interceptor, qui solo log specifico
console.error(`EntityService error: ${error.message}`);
return throwError(() => error);
}
}
```
## Regole
- Tutti i metodi HTTP devono restituire Observable<T>
- Error handling tramite interceptor globale + log locale
- URL base da environment, mai hardcoded
- Metodi CRUD standard: getAll, getById, create, update, delete
- Usare HttpParams per query parameters
- Cache con shareReplay(1) dove appropriato---
applyTo: "src/app/features/**/*.component.ts"
---
# Istruzioni per Componenti Feature
## Template Componente Standard
```typescript
@Component({
standalone: true,
selector: 'app-feature-name',
templateUrl: './feature-name.component.html',
styleUrls: ['./feature-name.component.scss'],
changeDetection: ChangeDetectionStrategy.OnPush,
imports: [CommonModule, ReactiveFormsModule]
})
export class FeatureNameComponent {
// Signals per stato locale
readonly items = signal<Item[]>([]);
readonly loading = signal(false);
readonly error = signal<string | null>(null);
// Computed per derivazioni
readonly itemCount = computed(() => this.items().length);
// Inject dependencies
private readonly service = inject(FeatureService);
private readonly destroyRef = inject(DestroyRef);
}
```
## Regole
- OnPush change detection OBBLIGATORIO
- Signals per tutto lo stato locale
- inject() function, non constructor injection
- DestroyRef per cleanup sottoscrizioni
- Template max 50 righe, altrimenti splitta in sub-componentiSpring Boot のリポジトリ命令の完全な例
# Copilot Instructions per TaskFlow Backend
## Stack
- Java 21 con Spring Boot 3.3
- Build: Gradle Kotlin DSL
- Database: PostgreSQL 16 con Flyway migrations
- Cache: Redis 7
- Auth: Spring Security + JWT
- API: REST con OpenAPI 3.1 documentation
- Testing: JUnit 5 + Mockito + Testcontainers
## Architettura
Hexagonal Architecture (Ports and Adapters):
```
src/main/java/com/taskflow/
domain/ # Entità', value objects, eccezioni di dominio
application/ # Use cases, DTO, port interfaces
infrastructure/ # Adapter: DB, HTTP, messaging
config/ # Spring configuration
```
## Convenzioni Java
- Record per DTO immutabili
- Sealed interface per gerarchia tipi controllata
- Optional solo come return type, mai come parametro
- Stream API per operazioni su collection
- Naming: verbo + sostantivo per metodi (es. createOrder, findUserById)
## API Design
- Endpoint: /api/v1/{resource} (plurale)
- Response: wrapper con data, metadata, errors
- Pagination: page, size, sort query params
- Error format: RFC 7807 Problem Details
- Versioning: URL-based (/api/v1/, /api/v2/)
## Database
- Migrations: Flyway con naming V{version}__{description}.sql
- Naming tabelle: snake_case, plurale (es. user_profiles)
- Ogni tabella: id (UUID), created_at, updated_at
- Indici: su tutte le foreign key e campi di ricerca frequente
- NO cascade delete: gestire esplicitamente
## Security
- Input validation su TUTTI gli endpoint
- SQL injection: solo PreparedStatement/JPA
- Rate limiting: 100 req/min per user
- CORS: whitelist esplicita
- Secrets: mai in codice, sempre da environmentリポジトリ手順のベスト プラクティス
- バージョン管理: リポジトリ命令はリポジトリ内のファイルであるため、Git でバージョン管理されます。すべての変更は追跡可能です。
- レビュー： 命令の変更をコードの変更と同様に扱い、PR とコード レビューを行います。
- 簡潔： 指示が長すぎると、内容が薄れてしまう可能性があります。明確かつ具体的なルールに重点を置きます。
- 特異性': 一般的な指示は避けてください。フレームワーク、バージョン、パターン、規約については具体的に説明してください。
- アップデート： チームの規則やプロジェクトの依存関係が変更された場合は、指示を更新します。
組織の指示
構成手順はサブスクリプションでのみ利用可能です GitHub コパイロット エンタープライズ e 仕事。彼らは、 組織の所有者は、すべてのメンバーに適用される設定を定義できます。 そして組織内のすべてのリポジトリに。
構成
組織的な指示を設定するには:
- GitHub 上の組織のページに移動します
- 上がる 設定 → Copilot → カスタム命令
- トグルで機能を有効にします
- 専用のテキスト領域に指示を書き込みます
- 変更を保存します
組織指示の特徴
| 特性 | 詳細 |
|---|---|
| 文字数制限 | 最大4,000文字 |
| バージョン管理 | バージョン管理されていない (Git なし) |
| 可視性」 | 組織所有者のみが表示/編集できます |
| 応用 | すべての組織メンバーで自動 |
| オーバーライド | これらはリポジトリや個人的な指示によって上書きできます。 |
| 可用性' | エンタープライズおよびビジネスのみ |
# Acme Corp - GitHub Copilot Instructions
## Lingua
Rispondi sempre in italiano per il team italiano,
in inglese per tutti gli altri.
## Standard di Sicurezza
- Non suggerire mai codice che espone secrets o credenziali
- Includi sempre input validation negli endpoint
- Usa prepared statements per tutte le query database
- Implementa rate limiting su ogni API pubblica
- Log sensibili: mai loggare PII, token o password
## Convenzioni Codice Aziendali
- Tutti i servizi devono avere interfaccia + implementazione
- Naming: prefisso "Acme" per package base (com.acme.*)
- Documentazione JavaDoc obbligatoria per metodi pubblici
- Commit message: Conventional Commits format
- Branch naming: feature/, bugfix/, hotfix/ + JIRA ticket
## Compliance
- Codice deve essere compatibile GDPR
- Dati utente: sempre criptati a riposo
- Log retention: max 90 giorni
- Audit trail obbligatorio per operazioni CRUD su dati sensibili
## Librerie Approvate
- HTTP Client: OkHttp o Spring WebClient (no Apache HC legacy)
- JSON: Jackson (no Gson)
- Logging: SLF4J + Logback
- Testing: JUnit 5 + AssertJ + Mockito重要な制限: 4,000 文字
組織上の指示の 4,000 文字制限は制限的であるように思えるかもしれませんが、 特に多くの契約を結んだ大規模な組織の場合。推奨される戦略は、 組織の指示にルールのみを含めるには 普遍的で重要な (セキュリティ、コンプライアンス、命名ベース)、プロジェクト固有のルールを委任する リポジトリの説明。
モデル コンテキスト プロトコル (MCP) の統合
Il モデルコンテキストプロトコル (MCP) これはオープンスタンダードであり、 Copilot を外部ツールやデータ ソースに接続します。 MCP を通じて、Copilot は次のことができます。 データベース、API、ドキュメント システムなどにアクセスし、拡張します 彼の能力は顕著です。
GitHub MCP レジストリ
GitHub が提供するのは、 MCP レジストリ MCP サーバーのカタログとして機能する厳選されたもの 検証済みで安全です。このレジストリを使用すると、サーバーを迅速に検出して統合できます。 MCP では、各接続を手動で設定する必要がありません。
MCP サーバーの種類
| タイプ | 輸送 | どこに転向するのか | 使用事例 | 構成 |
|---|---|---|---|---|
| リモート (HTTP/SSE) | サーバー送信イベントを使用した HTTP | リモートサーバー | クラウドAPI、SaaS、共有サービス | URL+認証 |
| ローカル (stdio) | 標準 I/O (stdin/stdout) | ローカルマシン | ローカルデータベース、ファイルシステム、CLIツール | コマンド + 引数 |
IDE での MCP 構成
VS Code で MCP サーバーをセットアップするには、ファイルを作成または編集します .vscode/mcp.json
プロジェクトのルートにあります。このファイルは、どの MCP サーバーが利用できるかを定義します。
開発中の副操縦士。
{
"servers": {
"github": {
"type": "remote",
"url": "https://api.githubcopilot.com/mcp/github",
"description": "GitHub API access for issues, PRs, repos"
},
"postgres-local": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-postgres",
"postgresql://localhost:5432/taskflow"
],
"description": "Local PostgreSQL database access"
},
"filesystem": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"--root",
"${workspaceFolder}"
],
"description": "File system access for project files"
},
"documentation": {
"type": "remote",
"url": "https://docs-mcp.example.com/v1",
"headers": {
"Authorization": "Bearer ${env:DOCS_API_KEY}"
},
"description": "Internal documentation search"
},
"sentry": {
"type": "remote",
"url": "https://mcp.sentry.io/sse",
"headers": {
"Authorization": "Bearer ${env:SENTRY_AUTH_TOKEN}"
},
"description": "Sentry error tracking integration"
}
}
}MCP とコーディング エージェント
MCP 統合は、 コーディングエージェント 副操縦士による。エージェントは MCP ツールを使用して情報を収集し、クエリを実行できます。 自動化された開発プロセス中に外部システムと対話します。
コーディング エージェントを使用した MCP の使用例
| シナリオ | MCPサーバー | エージェントのアクション |
|---|---|---|
| 問題からのバグ修正 | GitHub + セントリー | 問題を読み取り、Sentry からスタック トレースを取得し、コードを分析して修正を提案します。 |
| 新機能 | GitHub + データベース | 課題から要件を読み取り、DB スキーマを分析し、コードを生成してテストします |
| ドキュメント | ファイルシステム + API ドキュメント | ソースコードを分析し、APIドキュメントを自動的に更新します |
| データ移行 | PostgreSQL + Redis | 現在の構造を分析し、移行スクリプトを生成し、整合性を検証します |
| パフォーマンスのチューニング | プロメテウス + データベース | メトリクスを収集し、遅いクエリを特定し、最適化を提案します |
MCP のエンタープライズ ポリシー
エンタープライズおよびビジネス組織の場合、ポリシーは 「Copilot の MCP サーバー」 組織の管理者が明示的に有効にする必要があります。デフォルトでは、 このポリシーは 無効.
有効にすると、所有者はどの MCP サーバーにアクセスできるかを制御できます 組織のメンバーに通知し、承認されたデータ ソースのみが使用されるようにします。
コンテンツの除外
コンテンツの除外により、特定のファイルとディレクトリを処理から除外できます。 副操縦士による。これは機密性の高い独自のコードを保護するために不可欠です または、機密または機密構成を含むファイル。
コンテンツ除外レベル
除外レベルの比較
| レベル | 構成者 | 範囲 | 可用性' |
|---|---|---|---|
| リポジトリ | 管理リポジトリ | 特定のリポジトリ内のファイル | エンタープライズとビジネス |
| 組織 | 組織所有者 | 任意の組織リポジトリ内のファイル | エンタープライズとビジネス |
| 企業 | エンタープライズ管理者 | すべてのエンタープライズ組織内のファイル | 企業 |
除外されるもの
ファイルが除外対象としてマークされている場合、Copilot はいくつかのコンテキストでそのファイルを無視します。
コンテンツの除外の影響
| 機能性」 | 除外の効果 |
|---|---|
| インライン補完 | 除外されたファイルに対する提案は生成されません |
| 副操縦士のチャット | 除外されたファイルは応答のコンテキストとして使用されません |
| コードレビュー | 除外されたファイルにはレビュー コメントがありません |
| 副操縦士の編集 | エージェントが変更できない除外ファイル |
| コーディングエージェント | エージェントは除外されたファイルを読み取りまたは変更できません |
コンテンツ除外の構成
# Formato: un pattern per riga
# Supporta glob patterns
# Escludere file di configurazione sensibili
*.env
*.env.*
config/secrets/**
# Escludere codice legacy non modificabile
legacy/**
vendor/**
# Escludere file generati automaticamente
generated/**
dist/**
node_modules/**
# Escludere file con dati sensibili
**/credentials*
**/private-keys/**
**/*.pem
**/*.key
# Escludere directory specifiche
src/app/proprietary/**
src/internal/billing/**
# Escludere file di test con dati sensibili
test/fixtures/sensitive-data/**コンテンツの除外の制限
- シンボリックリンク: シンボリックリンク経由でアクセス可能なファイルは自動的に除外されません。除外は、ファイルの実際のパスに基づいて行われます。
- リモートファイルシステム: リモート ファイル システム (SSH、SFTP など) 上のファイルに対しては、除外は機能しません。
- 伝搬： 除外ルールの変更がすべてのユーザーに反映されるまでに最大 30 分かかる場合があります。
- サブモジュール: Git サブモジュール内のファイルには、サブモジュール リポジトリ用の個別の除外ルールが必要です。
チームのパーソナライゼーション戦略
3 つのレベルのパーソナライゼーションを効果的に組み合わせるには、明確な戦略が必要です。 ここでは、さまざまな規模のチームに推奨されるアプローチを示します。
小規模チーム (開発者 2 ～ 5 人)
何をするか
- リポジトリの指示に注目する
- リポジトリ用の copilot-instructions.md ファイル
- 重要な領域に対するパス固有の指示
- 個人の好みに合わせた個人的な指示
- 指示の定期的な見直し（毎月）
避けるべきもの
- 組織化に関する指示 (小規模チームにはやりすぎ)
- 説明が詳細すぎる（利益が減少する）
- 個人用の命令とリポジトリの命令の間の重複
- 実際には適用されないルール
- 更新頻度が高すぎる
中規模チーム (5 ～ 20 人の開発者)
何をするか
- 各プロジェクトの詳細なリポジトリ手順
- テスト、API、テンプレートのパス固有の手順
- 横断的な標準に関する組織の指示
- 機密コードのコンテンツの除外
- チームによる四半期レビュー
- 新しいリポジトリの手順テンプレート
避けるべきもの
- レベル間で命令が矛盾している
- 廃止された指示を残す
- 開発者のフィードバックを無視する
- ルールが厳しすぎるとチームがイライラする
- 指示の所有権の欠如
大規模組織 (開発者 20 名以上)
何をするか
- 会社のポリシーに関する組織の指示
- あらゆる種類のプロジェクトのテンプレート リポジトリの手順
- 企業全体のコンテンツの除外
- 一元化された承認済みの MCP サーバー
- 指示変更の正式なプロセス
- 指導効果の指標
- 新しい開発者向けのオンボーディング ガイド
避けるべきもの
- 組織の指示が制限的すぎる
- 個人的な指示でシステムをバイパスする
- MCP サーバーのガバナンスの欠如
- 指示の採用を監視しない
- 専門チームのニーズを無視する
- 指示の価値を保持: 共有する
実践例: プロジェクトのセットアップを完了する
実際のプロジェクトの完全なカスタマイズを構成する方法を見てみましょう。 すべてのレベルを組み合わせます。
my-project/
.github/
copilot-instructions.md # Istruzioni generali del progetto
instructions/
testing.instructions.md # Regole per file di test
api-controllers.instructions.md # Regole per controller API
database.instructions.md # Regole per query e migrations
components.instructions.md # Regole per componenti UI
.vscode/
mcp.json # Server MCP del progetto
settings.json # Impostazioni VS Code
# A livello organizzazione (UI GitHub):
# - Organization Instructions (4000 char max)
# - Content Exclusion patterns
# - MCP server policy
# A livello personale (Settings GitHub):
# - Personal Instructions
# - Preferenze lingua e stile指示メンテナンスのワークフロー
更新プロセス
| 頻度 | アクション | 責任者 | トリガー |
|---|---|---|---|
| このために | 個人的な指示を更新する | 単一の開発者 | 設定を変更する |
| スプリント向け | リポジトリの手順を確認する | 技術リード | 新しい規約が採用されました |
| 毎月 | パス固有の指示を更新する | チーム | 開発者のフィードバック |
| 四半期ごと | 組織の指示を確認する | 組織所有者 + リード | 会社方針の変更 |
| 四半期ごと | 監査コンテンツの除外 | セキュリティチーム | セキュリティレビュー |
| 半年ごと | MCP サーバーの完全なレビュー | プラットフォームチーム | 新しいツールが利用可能 |
よくある問題の解決
カスタマイズのトラブルシューティング
| 問題 | 考えられる原因 | 解決 |
|---|---|---|
| リポジトリ指示が適用されない | ファイルが正しいパスにありません | ファイルが次の場所にあることを確認します .github/copilot-instructions.md |
| パス固有の命令は無視される | 間違った YAML パターン | YAML フロントマターで applyTo 形式を確認する |
| 組織の指示が表示されない | 機能が有効になっていません | [設定] → [Copilot] → [カスタム指示] で切り替えを有効にします |
| MCPサーバーが接続されていません | ポリシーが無効になっています | 組織管理者に「Copilot の MCP サーバー」を有効にするよう依頼します。 |
| コンテンツの除外が機能しない | 伝播中です | 完全に伝播するまで最大 30 分かかります |
| 命令間の競合 | 矛盾した指示 | 階層を確認します:personal > repo > org |
| 説明が冗長すぎる | 飽和したコンテキスト | 重要なルールに絞り込み、詳細についてはパス固有のルールを使用する |
パーソナライゼーションチェックリスト
Copilot カスタマイズ設定チェックリスト
| エリア | アクション | 完了 |
|---|---|---|
| 個人的 | 応答に使用する優先言語を定義する | ☐ |
| 経験値とスタックを指定する | ☐ | |
| 優先応答スタイルを構成する | ☐ | |
| リポジトリ | .github/copilot-instructions.md を作成する | ☐ |
| スタック、規則、パターンを定義する | ☐ | |
| テスト用のパス固有の命令を追加する | ☐ | |
| API のパス固有の命令を追加する | ☐ | |
| 組織 | 組織の指示でセキュリティ標準を定義する | ☐ |
| 機密データのコンテンツ除外を構成する | ☐ | |
| MCP サーバー ポリシーを有効にして構成する | ☐ | |
| MCP | プロジェクトで .vscode/mcp.json を構成する | ☐ |
| MCP サーバーへの接続をテストする | ☐ | |
| チームが利用できる MCP サーバーを文書化する | ☐ | |
| メンテナンス | 定期的なレビュープロセスを確立する | ☐ |
| 新しいリポジトリのテンプレートを作成する | ☐ |
結論
GitHub Copilot のカスタマイズはすぐに報われる投資です 生産性とコードの品質。適切に構成された命令が Copilot を変革します 一般的な推奨者から、あなたのスタックや慣例を理解するアシスタントまで そしてあなたのチームのルール。
成功の鍵はアプローチです 増分: リポジトリから始めます 基本的な指示に加えて、必要な領域を特定するときにパス固有の指示を追加します。 具体的なガイダンスの恩恵を受け、チームの成長に応じて組織的な指示を拡大します。 MCP の統合とコンテンツの除外によって全体像が完成し、Copilot が確実に 強力かつ安全です。
次の記事では、オプションについて説明します。 エンタープライズとビジネス 副操縦士によって、 組織の価格設定、分析、ポリシー管理、ROI に関する洞察が得られます。
シリーズの進行状況
| # | アイテム | Stato |
|---|---|---|
| 1 | 基礎と考え方 | ✅ |
| 2 | コンセプトと要件 | ✅ |
| 3 | バックエンド/フロントエンドのアーキテクチャ | ✅ |
| 4 | コードの構造 | ✅ |
| 5 | 迅速なエンジニアリング | ✅ |
| 6 | テストと品質」 | ✅ |
| 7 | ドキュメント | ✅ |
| 8 | デプロイとDevOps | ✅ |
| 9 | 進化 | ✅ |
| 10 | コーディングエージェント | ✅ |
| 11 | コードレビュー | ✅ |
| 12 | 副操縦士の編集 | ✅ |
| 13 | GitHub スパーク | ✅ |
| 14 | 副操縦士スペース | ✅ |
| 15 | AIモデル | ✅ |
| 16 | 高度なカスタマイズ | 📍 |
| 17 | エンタープライズとビジネス | ◻ |
| 18 | 拡張機能とマーケットプレイス | ◻ |
| 19 | 安全性と責任ある使用 | ◻ |