GitHub Copilot による自動コードレビュー
コードレビューはソフトウェア品質の柱の 1 つですが、同時に 時間とリソースの点で最も高価なプロセスの 1 つです。多くのチームではプルリクエスト レビューを数時間、場合によっては数日間待ち続けることになり、開発サイクル全体が遅くなります。 GitHub コパイロット コード レビュー AI を活用したレビューを提供することでこの問題に対処します で分析が完了します 30秒未満.
この記事では、自動レビューを設定する方法とプロセスの仕組みについて説明します。 分析の方法、チームの基準を満たすようにレビュー ルールをカスタマイズする方法、およびその方法 AI レビューと人間によるレビューを統合して、コードの品質を最大化します。
シリーズ概要
| # | アイテム | 集中 |
|---|---|---|
| 1 | 基礎と考え方 | セットアップとメンタリティ |
| 2 | コンセプトと要件 | アイデアから MVP まで |
| 3 | バックエンドのアーキテクチャ | APIとデータベース |
| 4 | フロントエンドの構造 | UIとコンポーネント |
| 5 | 迅速なエンジニアリング | MCP プロンプトとエージェント |
| 6 | テストと品質 | ユニット、統合、E2E |
| 7 | ドキュメント | README、API ドキュメント、ADR |
| 8 | デプロイとDevOps | ドッカー、CI/CD |
| 9 | 進化 | スケーラビリティとメンテナンス |
| 10 | コーディングエージェント | 自律的な開発 |
| 11 | 現在位置 → コードレビュー | AI を活用したレビュー |
| 12 | 副操縦士の編集とエージェント モード | 複数ファイルの編集 |
| 13 | GitHub スパーク | AI ネイティブのマイクロアプリ |
| 14 | 副操縦士スペース | 共有コンテキスト |
| 15 | AIモデル | マルチモデルと選択 |
| 16 | カスタマイズ | カスタム命令 |
| 17 | 企業 | 組織的な導入 |
| 18 | 拡張機能 | コパイロット拡張機能 |
| 19 | 安全性 | セキュリティとコンプライアンス |
自動コードレビューを行う理由
手動によるコードレビューには、チームの生産性に影響を与えるいくつかの課題があります そしてソフトウェアの品質。これらの問題を理解すると、価値を理解することができます 自動レビューの。
従来のコードレビューの問題点
| 問題 | インパクト | 頻度 |
|---|---|---|
| 待ち時間 | PR は数時間/数日間ブロックされ、レビュー担当者のコンテキストが切り替わります | 非常に頻繁に |
| 矛盾 | 査読者によって基準も異なり、主観的なフィードバックも異なります | 頻繁 |
| 疲労を見直す | 3 回目の PR 以降、注意力が薄れ、確認せずに変更が承認される | 頻繁 |
| 部分的な適用範囲 | レビュー担当者はロジックに重点を置き、セキュリティ、パフォーマンス、エッジケースを無視する | 非常に頻繁に |
| ボトルネック | 少数の上級レビュー担当者がチーム全体のボトルネックになる | 小規模チームによくあること |
| 知識のギャップ | レビュー担当者はコードベースのその部分を知りません | 時々 |
Copilot の自動レビューは人間によるレビューに代わるものではありません。 補完する。 AI が機械的なチェック (スタイル、パターン、一般的なバグ、セキュリティ) を処理し、レビュー担当者を解放します。 人間は、アーキテクチャ、デザイン、読みやすさなど、判断が必要な側面に焦点を当てることができます。 ビジネスロジックの正確性。
役割分担: AI vs 人間
| 待ってます | コパイロットのコードレビュー | ヒューマンレビュー |
|---|---|---|
| スタイルと書式設定 | 素晴らしい | 必要ありません |
| 既知のバグパターン | 素晴らしい | 補完的 |
| セキュリティの脆弱性 | 良い | 複雑なケースには必須 |
| パフォーマンスの問題 | 既知のパターンに適しています | 最適化に不可欠 |
| 論理的な正しさ | 限定 | 不可欠 |
| アーキテクチャ上の決定 | 適用できない | 不可欠 |
| ネーミングと読みやすさ | 良い | 補完的 |
| テストカバレッジ | 良い | 補完的 |
| スピード | 30 秒未満 | 15～60分 |
| 一貫性 | いつも同じ | 変数 |
| 可用性 | 24時間365日 | 労働時間 |
自動レビューを構成する
自動レビュー構成はリポジトリまたは組織レベルで行われます。 すべての PR のレビューから選択的なレビューまで、さまざまなアクティベーション戦略があります。 ブランチまたはパスに基づいて。
すべての PR の自動レビュー
最も単純な構成では、各プル リクエストで Copilot レビューが有効になります。 リポジトリで開きます。このモードは、 すべてのコードに対する最初のレベルの自動制御。
構成 - グローバル自動レビュー
# Nella pagina Settings del repository:
# 1. Vai a Settings > Code review > Copilot
# 2. Seleziona "Automatic" sotto "Copilot code review"
# 3. Scegli il trigger:
# - "All pull requests" - review automatica su ogni PR
# - "When requested" - solo quando richiesto manualmente
# Per abilitare via API GitHub:
# PATCH /repos/{{ '{' }}owner}/{{ '{' }}repo}
# {{ '{' }}
# "copilot_code_review": {{ '{' }}
# "automatic": true,
# "trigger": "all_pull_requests"
# }
# }
# A livello di organizzazione (per tutti i repository):
# Organization Settings > Copilot > Policies > Code Review
# Enable: "Automatic code review for all repositories"選択的レビュー: ブランチとパス
大規模なプロジェクトでは、自動レビューのみを有効にすることができます。 特定の状況: メイン ブランチへの PR、クリティカル パスへの変更、 または特定のチームからの貢献。
構成 - GitHub Actions を使用した選択的なレビュー
# .github/workflows/copilot-review.yml
name: Request Copilot Code Review
on:
pull_request:
types: [opened, synchronize]
branches:
- main
- release/*
paths:
- 'src/**'
- 'lib/**'
- '!src/**/*.test.ts'
- '!src/**/*.spec.ts'
- '!docs/**'
jobs:
request-review:
runs-on: ubuntu-latest
steps:
- name: Request Copilot Review
uses: actions/github-script@v7
with:
script: |
// Richiedi review solo se la PR ha più di 10 righe modificate
const {{ '{' }} data: files } = await github.rest.pulls.listFiles({{ '{' }}
owner: context.repo.owner,
repo: context.repo.repo,
pull_number: context.payload.pull_request.number
});
const totalChanges = files.reduce((sum, f) =>
sum + f.additions + f.deletions, 0);
if (totalChanges > 10) {{ '{' }}
await github.rest.pulls.requestReviewers({{ '{' }}
owner: context.repo.owner,
repo: context.repo.repo,
pull_number: context.payload.pull_request.number,
reviewers: ['copilot'] // Richiedi review a Copilot
});
console.log(`Requested Copilot review for PR #${{ '{' }}context.payload.pull_request.number}`);
} else {{ '{' }}
console.log(`Skipped: only ${{ '{' }}totalChanges} lines changed`);
}ドラフトPRサポート
副操縦士はまた、 ドラフトプルリクエスト、許可します PR が人間によるレビューの準備が整う前に、早期にフィードバックを受け取ることができます。これ フィードバック ループを高速化し、必要な反復回数を減らします。
ドラフトPRの戦略
| 戦略 | いつ使用するか | アドバンテージ |
|---|---|---|
| 早期レビュー | 開発初期段階でのPR | 作業を完了する前に構造上の問題を特定する |
| 反復レビュー | 多くの変更を伴う複雑な PR | 押すたびにフィードバックを受け取り、段階的に修正します |
| 事前レビュー | 人間によるレビューを求める前に | 人間によるレビューの前に機械的な問題を解決する |
レビューの仕組み
Copilot はプル リクエストを分析するときに、一連の詳細なチェックを実行します。 改造コードについて。このプロセスは迅速に行われるように設計されています (30 秒未満)。 広範囲の潜在的な問題をカバーしながら。
分析プロセス
- コンテキストコレクション: コパイロットは PR diff、コンテキスト ファイルを読み取ります (
copilot-instructions.md）とプロジェクトの構造 - カテゴリ別の分析: それぞれの変更は、さまざまなカテゴリの問題 (バグ、セキュリティ、パフォーマンス、スタイル) について分析されます。
- コメントの生成: 見つかった問題ごとに、Copilot は問題の説明と推奨される修正を含むインライン コメントを生成します。
- コードヒント: 可能な場合は常に、[提案を実装] ボタンで置換コード ブロックが提供されます。
- まとめ： 一般的なコメントでは、主な調査結果とリスクのレベルが要約されています。
レビューカテゴリー
Copilot は、それぞれ 1 つの側面に焦点を当てた複数のレンズを通してコードを分析します。 ソフトウェアの品質に特有のものです。
コードレビュー分析カテゴリ
| カテゴリ | 何をチェックするか | 問題の例 | 重大度 |
|---|---|---|---|
| バグと正確性 | ロジックエラー、null 参照、off-by-one、競合状態 | 配列インデックスが範囲外です。null の処理に失敗します。 | 批判 |
| 安全性 | 一般的な脆弱性: インジェクション、XSS、CSRF、認証バイパス | 連結された SQL、サニタイズされていない入力、コード内のシークレット | 批判 |
| パフォーマンス | N+1 クエリ、非効率なループ、メモリ リーク、インデックスの欠落 | ループ内の SELECT *、配列はメモ化されておらず、イベント リスナーは削除されていません | 高い |
| ベストプラクティス | 違反パターン、アンチパターン、非慣用的コード | コールバック地獄、神クラス、シングル責任違反 | 平均 |
| コードの品質 | 命名、複雑さ、重複、読みやすさ | 一般的な名前の変数、長すぎる関数、重複したコード | 平均 |
| ドキュメント | 欠落しているコメント、古いドキュメント、不完全な JSDoc | JSDoc のないパブリック関数、README が古い | 低い |
| テスト | カバレッジの不足、脆弱なテスト、過剰なモック | テストのない新機能、実装を検証するテスト | 平均 |
「提案を実装する」ボタン
Copilot レビューの最も強力な機能の 1 つは、 「提案を実行する」。 Copilot が問題を特定して提案するとき このボタンを使用すると、ワンクリックで変更を適用でき、 自動的に PR にコミットします。
推奨ワークフロー
- Copilot がコード内の問題を特定します
- 問題を説明するインライン コメントを生成する
- 代替コードブロックを提案します
- PR 作成者は「提案を実装する」をクリックできます。
- GitHub は修正を含むコミットを自動的に作成します
- 変更に応じて PR が更新されます
- 継続的レビューが有効な場合、Copilot はコードを再評価します
レビューを続ける
を有効にすると、 レビューは続きます、Copilot が自動的に分析します PR を新たに推し進めるたびに。これは、作成者がコミットを追加するたびに、 レビュー コメントに応答するため、または開発を続行するために、Copilot は再評価を行います。 を変更し、新しいフィードバックを提供します。
継続的レビューの利点
- プッシュするたびに即座にフィードバック
- 修正によって実際に問題が解決されることを確認する
- 修正中に発生した新しい問題を検出します
- 人間によるレビューに必要な時間を短縮します
- PR を常に「レビュー準備完了」に保ちます
構成
- アクティベーション: [設定] > [Copilot] > [継続的レビュー]
- トリガー: 任意のプッシュ (デフォルト) または重要なプッシュのみ
- スロットリング: PR のため 5 分ごとに最大 1 件のレビュー
- 範囲: 前回のレビュー以降に変更されたファイルのみ
- 通知: 各サイクルの概要コメント
個別のレビュー手順
最も重要な機能の 1 つは、 チーム固有の基準に合わせてレビュー ルールをカスタマイズする そして組織。の カスタムレビューの手順 許可してください Copilot が何を検索し、どのようにコードを評価するかを定義します。
命令構成
カスタム命令は、リポジトリ内の構成ファイルで定義されます。 Copilot は各レビューの前にこれらを読み取り、分析のガイドとして使用します。
.github/copilot-review-instructions.md - 完全な例
# Copilot Code Review Instructions
## Standard di Codice del Team
### TypeScript
- Usa `strict: true` in tsconfig.json
- Mai usare `any`: preferisci `unknown` con type guard
- Preferisci `interface` a `type` per oggetti
- Usa `readonly` per proprietà che non devono cambiare
- Enumera sempre i casi in switch su union type
- Usa optional chaining (`?.`) invece di check null manuali
- Preferisci `const` a `let`, mai `var`
### Naming Conventions
- Classi e interfacce: PascalCase (es. `UserService`, `IUserRepository`)
- Variabili e funzioni: camelCase (es. `getUserById`, `isActive`)
- Costanti: UPPER_SNAKE_CASE (es. `MAX_RETRY_COUNT`)
- File: kebab-case (es. `user-service.ts`)
- Test: [name].test.ts o [name].spec.ts
- Boolean: prefisso is/has/should (es. `isActive`, `hasPermission`)
### Error Handling
- Usa custom error classes (AppError, NotFoundError, etc.)
- Non catturare errori senza ri-lanciarli o loggarli
- Includi context nell'errore: `throw new NotFoundError('User', userId)`
- Non usare try/catch per flow control
- Tutti gli endpoint API devono avere error handler
### Sicurezza (PRIORITA ALTA)
- Mai concatenare input utente in query SQL
- Validare TUTTI gli input con class-validator
- Sanitizzare output HTML per prevenire XSS
- Verificare autorizzazione per ogni endpoint protetto
- Non esporre stack trace o dettagli interni in risposte API
- Rate limiting su endpoint pubblici
- Secrets solo via environment variables
### Performance
- Evitare query N+1: usa include/eager loading
- Paginazione obbligatoria per liste: max 100 elementi
- Caching per dati frequentemente accessi
- Async/await per I/O operations
- Evitare operazioni sincrone bloccanti
### Test
- Ogni nuova funzione pubblica deve avere almeno un test
- Test devono essere indipendenti (no ordine di esecuzione)
- Mock solo le dipendenze esterne (database, API, file system)
- Nomi descrittivi: "should [action] when [condition]"
- Almeno un test per il caso di errore
### Angular (Frontend)
- Usa standalone components
- Signals per lo state management
- OnPush change detection per tutti i componenti
- Lazy loading per route non critiche
- Nessun `subscribe()` nei template: usa async pipe o toSignal言語固有のルール
言語ごとに指示を指定できるため、標準化が可能 バックエンドとフロントエンド、または同じプロジェクト内の異なる言語で異なります。
言語固有の指示
# Regole specifiche per linguaggio
## Python (Backend ML)
- Type hints obbligatorie per tutti i parametri e return
- Docstring Google style per ogni funzione pubblica
- Usa `dataclasses` o `pydantic` per data objects
- Black formatting (line length 88)
- Import ordinati con isort
## SQL (Migrations)
- Mai DROP TABLE senza backup plan documentato
- ALTER TABLE deve essere reversibile
- Index per ogni foreign key
- Nomi colonne in snake_case
- Commento SQL per ogni migration spiegando il "perché"
## YAML/Config
- Commenti per ogni sezione non ovvia
- Secrets referenziati via variabili, mai valori hardcoded
- Validazione schema per file di configurazioneチェックすべきアーキテクチャパターン
アーキテクチャパターンの説明
# Pattern Architetturali
## Layered Architecture
Il progetto segue un'architettura a layer:
- Controller → Service → Repository
- I controller NON devono accedere direttamente ai repository
- I repository NON devono contenere business logic
- Ogni layer comunica solo con il layer immediatamente inferiore
## Dependency Injection
- Tutte le dipendenze iniettate via costruttore
- Interfacce per le dipendenze (IUserService, IUserRepository)
- No singleton pattern manuale: usare il DI container
## Event-Driven Communication
- Comunicazione cross-service via eventi
- Eventi devono essere immutabili
- Ogni evento ha un tipo unico e un payload tipizzato
- Handler degli eventi devono essere idempotenti
## VERIFICA:
- Se un controller chiama direttamente un repository: ERRORE
- Se un service istanzia direttamente una dipendenza: WARNING
- Se una query SQL appare fuori da un repository: ERRORE
- Se business logic appare in un controller: WARNING実践的なレビュー例
Copilot がコードを分析する方法をよりよく理解するために、いくつかの例を見てみましょう 自動レビューによって特定される具体的な問題と、自動レビューによって提供される提案。
例 1: SQL インジェクションの脆弱性
PR のコード - SQL インジェクションの脆弱性
// File: src/repositories/user.repository.ts
// Riga aggiunta nella PR:
async findByName(name: string): Promise<User[]> {{ '{' }}
const query = `SELECT * FROM users WHERE name LIKE '%${{ '{' }}name}%'`;
return this.db.raw(query);
}副操縦士のコメント
重大度: クリティカル - SQL インジェクションの脆弱性
パラメータ name SQL クエリに直接挿入されます
消毒なしで。攻撃者は任意の SQL コードを挿入する可能性があります。
提案： SQL インジェクションを防ぐには、パラメーター化されたクエリを使用します。
Copilot によって提案された修正
async findByName(name: string): Promise<User[]> {{ '{' }}
return this.db.query(
'SELECT * FROM users WHERE name LIKE $1',
[`%${{ '{' }}name}%`]
);
}例 2: パフォーマンス - クエリ N+1
PR のコード - クエリ N+1
// File: src/services/order.service.ts
async getOrdersWithDetails(userId: string): Promise<OrderDetail[]> {{ '{' }}
const orders = await this.orderRepo.findByUserId(userId);
const result = [];
for (const order of orders) {{ '{' }}
const items = await this.itemRepo.findByOrderId(order.id);
const customer = await this.customerRepo.findById(order.customerId);
result.push({{ '{' }} ...order, items, customer });
}
return result;
}副操縦士のコメント
重大度: 高 - N+1 クエリ パターン
このコードは、データベースに対して 2N+1 クエリを実行します (注文の場合は 1 + 商品の場合は N + N お客様向け）。 100 件の注文の場合、201 件のデータベース クエリが発生することになります。これでは劣化してしまいます データの増加に応じてパフォーマンスが大幅に向上します。
提案： 積極的な読み込みまたはバッチ クエリを使用して、クエリの合計を 3 に減らします。
Copilot によって提案された修正
async getOrdersWithDetails(userId: string): Promise<OrderDetail[]> {{ '{' }}
const orders = await this.orderRepo.findByUserId(userId);
if (orders.length === 0) return [];
const orderIds = orders.map(o => o.id);
const customerIds = [...new Set(orders.map(o => o.customerId))];
// Batch query: 3 query totali invece di 2N+1
const [allItems, allCustomers] = await Promise.all([
this.itemRepo.findByOrderIds(orderIds),
this.customerRepo.findByIds(customerIds)
]);
const itemsByOrder = new Map();
for (const item of allItems) {{ '{' }}
if (!itemsByOrder.has(item.orderId)) {{ '{' }}
itemsByOrder.set(item.orderId, []);
}
itemsByOrder.get(item.orderId).push(item);
}
const customersById = new Map(
allCustomers.map(c => [c.id, c])
);
return orders.map(order => ({{ '{' }}
...order,
items: itemsByOrder.get(order.id) || [],
customer: customersById.get(order.customerId)
}));
}例 3: ベスト プラクティス - エラー処理
PR 内のコード - 不適切なエラー処理
// File: src/controllers/payment.controller.ts
async processPayment(req: Request, res: Response) {{ '{' }}
try {{ '{' }}
const result = await this.paymentService.charge(
req.body.amount,
req.body.cardToken
);
res.json(result);
} catch (e) {{ '{' }}
console.log(e);
res.status(500).json({{ '{' }} error: 'Something went wrong' });
}
}副操縦士のコメント
重大度: 中 - 複数の問題
- 入力が検証されていません:
req.body.amountereq.body.cardTokenそれらは検証されていません。不正な入力により、支払いサービスでエラーが発生する可能性があります。 - 誤嚥:
console.logそれは構造化されたログではありません。運用環境では、このメッセージが失われる可能性があります。 - 一般的なエラー: エラーが無効な入力 (400) または支払いの拒否 (402) である場合でも、すべてのエラーは 500 を返します。
- 内部の詳細が暴露されました: 元のエラーはログに記録されますが、応答メッセージは一般的すぎてクライアントにとって役に立ちません。
Copilot によって提案された修正
async processPayment(req: Request, res: Response) {{ '{' }}
// Validazione input
const {{ '{' }} amount, cardToken } = req.body;
if (!amount || typeof amount !== 'number' || amount <= 0) {{ '{' }}
return res.status(400).json({{ '{' }}
error: 'Invalid amount',
detail: 'Amount must be a positive number'
});
}
if (!cardToken || typeof cardToken !== 'string') {{ '{' }}
return res.status(400).json({{ '{' }}
error: 'Invalid card token',
detail: 'Card token is required'
});
}
try {{ '{' }}
const result = await this.paymentService.charge(amount, cardToken);
res.json(result);
} catch (error) {{ '{' }}
logger.error('Payment processing failed', {{ '{' }}
amount,
error: error.message,
stack: error.stack,
requestId: req.id
});
if (error instanceof PaymentDeclinedError) {{ '{' }}
return res.status(402).json({{ '{' }}
error: 'Payment declined',
detail: error.declineReason
});
}
if (error instanceof ValidationError) {{ '{' }}
return res.status(400).json({{ '{' }}
error: 'Validation error',
detail: error.message
});
}
res.status(500).json({{ '{' }}
error: 'Internal server error',
requestId: req.id // Per debug senza esporre dettagli
});
}
}利用可能なプラン
Copilot の自動コード レビューは、すべてのプランで利用できるわけではありません。 各プランで利用できる機能の概要は次のとおりです。
プラン別の利用可能状況
| 機能性 | 個人 | 仕事 | 企業 |
|---|---|---|---|
| リクエストに応じてレビューします | 利用不可 | 利用可能 | 利用可能 |
| 自動レビュー | 利用不可 | 利用可能 | 利用可能 |
| レビューは続きます | 利用不可 | 利用可能 | 利用可能 |
| カスタムレビューの手順 | 利用不可 | 利用可能 | 利用可能 |
| 組織のポリシー | 適用できない | 基本 | 前進 |
| 監査ログ | 利用不可 | 基本 | 完了 |
| 指標を確認する | 利用不可 | 基本 | ダッシュボードでさらに進化する |
| コードベースでの微調整 | 利用不可 | 利用不可 | 利用可能 |
既存の PR ワークフローとの統合
Copilot のレビューは、チームの既存の PR ワークフローに自然に統合されます。 ここでは、AI と人間を効果的に組み合わせたレビュー プロセスを設定する方法を説明します。
推奨されるワークフロー
統合レビュープロセス
- オープン PR: 開発者は説明とコンテキストを含む PR を開きます
- AI を確認する (30 秒): Copilot は自動的に分析してコメントを残します
- クイックフィックス: 著者は「提案の実装」で機械的な提案を適用します。
- 最新の AI レビュー: Copilot は修正後に再評価します (継続的なレビューが有効な場合)
- 人間によるレビュー: 人間のレビュー担当者はアーキテクチャ、ロジック、デザインに焦点を当てます
- 反復: 人間のレビュー担当者によって要求された変更
- 承認と結合: PR は少なくとも 1 人の人間の審査員によって承認されました
例 - Copilot レビューを使用したブランチ保護ルール
# Branch Protection Rules consigliate per integrare Copilot
# Settings > Branches > Branch protection rules > main
# Regole obbligatorie:
# 1. Require pull request reviews: 1 reviewer minimo
# 2. Require review from Code Owners: abilitato
# 3. Dismiss stale reviews: abilitato (quando nuovi push invalidano review)
# 4. Require status checks: abilitato
# - Checks richiesti:
# - ci/build (CI pipeline)
# - ci/test (test suite)
# - security/codeql (analisi statica)
# 5. Require Copilot code review: abilitato (opzionale)
#
# Nota: Copilot review può essere richiesta come check
# obbligatorio, ma si consiglia di NON renderla bloccante
# per evitare falsi positivi che rallentano il merge.
#
# Strategia consigliata:
# - Copilot review: obbligatoria ma non bloccante
# - Reviewer umano: obbligatorio e bloccante
# - CI/CD checks: obbligatori e bloccantiAI と人間によるレビューの組み合わせ
レビュープロセスにおける責任
| 誰が | 何をチェックするか | いつ |
|---|---|---|
| 副操縦士 (自動) | 一般的なバグ、脆弱性、スタイル、アンチパターン、パフォーマンス パターン | PRを開いてすぐに |
| CI/CD パイプライン | ビルド、テスト、リンティング、カバレッジ、セキュリティ スキャン | AIの見直しと並行して |
| コードの所有者 | アーキテクチャ、設計、ドメインの正確性、他のモジュールへの影響 | AI レビューと CI がグリーンになった後 |
| テクニカルリード | アーキテクチャ上の決定、トレードオフ、ロードマップの調整 | アーキテクチャに影響を与える PR のみ |
| セキュリティチーム | 複雑な脆弱性、コンプライアンス、データ処理 | 認証、支払い、PII に関わる PR のみ |
メトリクスとレポート
投資を正当化するには、自動レビューの影響を測定することが不可欠です そしてプロセスを最適化します。 GitHub は有効性を評価するための専用のメトリクスを提供します 副操縦士のレビュー。
主要な指標
| メトリック | 測定内容 | 理想的なターゲット | 改善方法 |
|---|---|---|---|
| 最初のレビューまでの平均時間 | PR開始から最初のコメントまで | 5分未満 | 自動レビューを有効にする |
| 提案は受け入れられました | 適用された Copilot の提案の % | 40-60% | カスタム命令を改善する |
| レビューサイクル | マージ前の反復回数 | < 3 | 人間によるレビューの前に機械的に修正 |
| 合流の時間 | PR開設から合併まで | 24 時間未満 | AIレビュー+明確なプロセスで待ち時間を削減 |
| ポストレビュー制作におけるバグ | マージ後に見つかったバグ | < 2% | 逃れられたバグを分析し、指示を更新する |
| 誤検知 | 提案は間違っていたため無視されました | < 20% | カスタム命令とコンテキストを調整する |
レビューダッシュボード
エンタープライズ チーム向けに、GitHub はメトリクスを集約する専用のダッシュボードを提供します チームと組織全体のレビュー。このダッシュボードでできることは、 傾向、改善の余地がある領域、および AI の全体的な影響を特定する コードの品質。
チームの指標
- リポジトリあたりの平均レビュー時間
- カテゴリごとの提案の分布
- AIレビューから見つかった主な問題
- レビューサイクルの週次傾向
- Copilot前後の比較
個別の指標
- 開発者の提案が受け入れられました
- 開発者にとって繰り返し発生する問題
- コメントへの応答時間
- 時間の経過に伴う反復回数の削減
- 改善が提案される領域
品質を最大化するためのベストプラクティス
自動レビューを最大限に活用するには、いくつかのことに従うことが重要です。 フィードバックの質を向上させ、誤検知を減らすベスト プラクティス。
運用上のベストプラクティス
| 練習する | なぜ | として |
|---|---|---|
| 指示を常に最新の状態に保つ | 古い命令により誤検知が発生する | copilot-review-instructions.md ファイルの四半期レビュー |
| 小規模で集中的な PR | コパイロットは、小さくて一貫性のある差分をより適切に分析します | PR あたり最大 400 行、PR あたり 1 コンセプト |
| 詳しいPR内容 | コンテキストによって分析の品質が向上します | 「何を」と「なぜ」セクションを含む PR テンプレート |
| 機械的な修正をすぐに適用する | 重要な問題について人間のレビュー担当者を解放する | 人間によるレビューを要求する前に「提案の実装」を使用してください |
| フィードバックループ | より正確な指示により、Copilot が向上します | 提案が間違っている場合は、手順を更新します |
| 警告を無視しないでください | 今日の警告は明日のバグになります | 警告が誤検知である理由を解決または文書化する |
避けるべき間違い
- 洗練された指示なしで AI レビューをブロックする
- 提案を体系的に無視する
- プロジェクトに合わせて手順をカスタマイズしないでください
- 人間によるレビューを行わず、AI レビューのみに依存
- 分析を混乱させる巨大な PR
- PR の説明にコンテキストを含めないでください
勝利の戦略
- 最初のパスは AI、2 番目のパスは人間
- コードベースの各領域に対する具体的な命令
- 著者とAIの両方をガイドするPRテンプレート
- 無視された提案の振り返り
- セキュリティ問題に対する明確なエスカレーション
- 改善を追跡するための毎週の指標
概要と次のステップ
Copilot による自動コード レビューは、従来の時間のかかるプロセスを変革し、 迅速かつ完全で常に利用可能な第 1 レベルの分析に一貫性がありません。 人間によるレビューに代わるものではありませんが、次のことを可能にすることでより効率的になります。 査読者は人間の判断が必要な側面に焦点を当てます。
重要なポイント
- スピード： 30 秒以内にレビューでき、押すたびにすぐにフィードバックが得られます。
- 一貫性： 同じ基準がすべての PR に 24 時間年中無休で適用され、レビューに疲れることはありません。
- カスタマイズ: カスタム手順により、レビューがチームの基準に合わせられます。
- 統合： これは既存の PR ワークフローに自然に適合し、人間によるレビューを補完します。
- 測定可能性: レビュープロセスを評価および改善するための具体的な指標。
シリーズの進行状況
| # | アイテム | Stato |
|---|---|---|
| 1 | 基礎と考え方 | 完了 |
| 2 | コンセプトと要件 | 完了 |
| 3 | バックエンドのアーキテクチャ | 完了 |
| 4 | フロントエンドの構造 | 完了 |
| 5 | 迅速なエンジニアリング | 完了 |
| 6 | テストと品質 | 完了 |
| 7 | ドキュメント | 完了 |
| 8 | デプロイとDevOps | 完了 |
| 9 | 進化 | 完了 |
| 10 | コーディングエージェント | 完了 |
| 11 | 自動コードレビュー | 完了 |
| 12 | 副操縦士の編集とエージェント モード | Prossimo |
| 13 | GitHub スパーク | 近日公開 |
| 14 | 副操縦士スペース | 近日公開 |
| 15 | AIモデル | 近日公開 |
| 16 | カスタマイズ | 近日公開 |
| 17 | 企業 | 近日公開 |
| 18 | 拡張機能 | 近日公開 |
| 19 | 安全性 | 近日公開 |
次の記事では、詳しく見ていきます 副操縦士の編集とエージェント モード、 複数ファイルの編集、自己修復機能を備えたエージェント モードの使用方法を発見する 複雑なタスクのための計画モードと、スムーズで生産的な編集のための次の編集提案。