GitHub Copilotを使用して技術的負債を削減する

イントロダクション

技術的負債は、コードの重複、テストの欠落、古い依存関係、一貫性のないパターンなど、すべてのコードベースに蓄積されます。通常、機能開発の優先順位が高くなるため、これらの問題が蓄積される可能性があります。このチュートリアルでは、機能の速度を犠牲にすることなく、 GitHub Copilot を使用して技術的負債に体系的に対処する方法について説明します。

このチュートリアルの目的

このチュートリアルは、エンジニアリングチームとテクニカルリーダーが、新機能が提供されるペースを維持しながら技術的負債を削減できるように設計されています。次のことが必要です。

Copilot へのアクセス権を持つサブスクリプション Copilot cloud agent
少なくとも 1 つのリポジトリへの管理者access
チームの開発ワークフローに関する知識

作業内容

このチュートリアルの終わりまでに、以下について学習しました。

Copilotを使用して現在の修正プログラムを実装する
大規模なクリーンアップタスクに Copilot cloud agent を活用する
チームの標準に合わせて Copilot を調整するカスタム命令を作成する
技術的負債に対する Copilot の影響の測定

技術的負債の問題を理解する

コードベースの技術的負債の削減を開始する前に、チームが最も頻繁に直面する技術的負債の種類を特定するために少し時間を取る必要があります。

技術的負債の一般的な種類は次のとおりです。

コードの重複 - 複数の場所に実装された同じロジック
欠落しているテスト - 十分なテストカバレッジがない機能
古い依存関係 - 現在のリリースの背後にある複数のバージョンのライブラリ
一貫性のないパターン - コードベース全体で同じ問題に対するさまざまなアプローチ
レガシコード - 動作するが現在の標準に従っていない古いコード

技術的負債のコストは時間とともに累積します。

シニアエンジニアがアーキテクチャ設計の代わりに定期的な更新に時間を費やす
校閲者が矛盾したパターンについて議論するにつれて、コードレビューが長くなる
コード編成が混乱するため、新しい開発者のオンボードに時間がかかる
古い依存関係が脆弱性を蓄積すると、デプロイリスクが増加する

IDE で Copilot を使用して現在の修正を行う

コードベースに技術的負債が蓄積されることを避ける最善の方法は、最初からコードベースへの侵入を防ぐことです。

開発中に技術的負債が発生した場合は、IDE で Copilot を使用してすぐに修正します。

クイックリファクタリングワークフロー

IDE で作業しているときに、改善が必要なコードを強調表示します。
IDE で Copilot Chat を開きます。
コードをリファクタリングするように Copilot に依頼します。例えば次が挙げられます。
- Extract this into a reusable helper and add error handling
- Standardize this logging format to match our pattern
- Add null checks for all optional parameters
- Replace this deprecated API call with the current version
推奨される変更を確認します。
変更を受け入れるか、そのアプローチを変更するように Copilot に依頼します。
テストを実行して、変更が正しく機能することを確認します。

例: エラー処理の標準化

一貫性のないエラー処理が見つかる場合は、次のようにします。

// Highlight this code
try {
  await fetchData();
} catch (e) {
  console.log(e);
}

コードを改善するように Copilot に依頼します。次に例を示します。

Copilot prompt

Refactor this to use structured logging and proper error handling

// Highlight this code
try {
  await fetchData();
} catch (e) {
  console.log(e);
}

Refactor this to use structured logging and proper error handling

Refactor this to use structured logging and proper error handling

Copilot が提案する可能性があります。

try {
  await fetchData();
} catch (error) {
  logger.error('Failed to fetch data', {
    error: error.message,
    stack: error.stack,
    timestamp: new Date().toISOString()
  });
  throw error;
}

メモ

この応答は例です。 Copilot Chat 応答は非決定論的であるため、同じコードに対して同じプロンプトを実行すると、異なる応答が返される場合があります。

現時点での修正アプローチを採用することで、標準以下のコードがコードベースに追加されないようにし、対処できないバックログの問題の作成を回避できます。

IDE で Copilot を使用する方法の詳細については、「 GitHub CopilotにIDEで質問を行う」を参照してください。

大規模なリファクタリングに Copilot cloud agent を使用する

一部のリファクタリングタスクは、チームの全員が新機能の開発に忙しい間に完了するには大きすぎます。このような状況では、 Copilot cloud agent を使用して、これらのタスクを自律的に処理できます。少なくとも Copilot cloud agent 提案された変更を確認するには、人の努力が必要ですが、作業の大部分を行う Copilot を取得することで、チームの生産性に大きな影響を与えない大規模なリファクタリングを実行できます。

どのようなときに Copilot cloud agent を使用するか

次のタスクには Copilot cloud agent を使用します。

コードベース全体で多数のファイルをタッチする
体系的な変更が必要 (古い機能フラグの削除など)
慎重なテストが必要ですが、簡単に実装できます
手動で行うと、機能の開発が中断される

たとえば、次のようになります。

50 以上のファイルに影響するフレームワークのアップグレード
非推奨の機能フラグの削除
厳密な TypeScript への移行
依存関係バージョンの更新
インポートパターンの標準化

ワークフロー Copilot cloud agent

リファクタリングタスクを説明する GitHub の問題を作成します。

変更する必要がある内容について具体的に確認します。例えば次が挙げられます。

Remove all feature flags marked for cleanup in Q2.

These flags are:
- `enable_new_dashboard`
- `beta_export_feature`
- `experimental_search`

All three flags are enabled by default in production.

Remove the flag checks and keep the "enabled" code path.

Copilot ユーザーに問題を割り当てます。
Copilot cloud agent は:
- 開発環境を設定する
- 下書きのプルリクエストを開く
- コードに必要な変更を加える
- テストの実行
- レビューの pull request を最終処理する
- pull request のレビューを要求する
人間がプルリクエストを作成した場合と同様に、プルリクエストをレビューします。
変更が必要な場合はコメントを残します。Copilot cloud agent は、フィードバックに基づいて pull request を更新します。
作業が正しく完了するまで、この方法で反復処理します。
プルリクエストを承認し、マージする。

詳細については、「GitHub Copilot セッションの開始」および「Copilot からの出力を確認する」を参照してください。

安全ガードレール

Copilot cloud agent は、組み込みの安全対策で動作します。

独自の copilot/* ブランチにのみプッシュできます
あなたの承認が必要なため、プルリクエストをマージできません。
すべてのコミットがログに記録され、監査可能
既存のブランチ保護はアクティブなままです
コードがマージされる前に CI/CD チェックが実行される

チームのカスタム手順の作成

カスタム手順 Copilot 、チームのコーディング標準とパターンを理解するのに役立ちます。これにより、最初から提案が期待と一致するようになります。

カスタム命令の設定

リポジトリで、.github/copilot-instructions.md という名前のファイルを作成します。
箇条書きを使用するなど、明確で簡単なステートメントでチームのコーディング標準を追加します。
ファイルをリポジトリにコミットします。

カスタム命令の例

効果的なカスタム命令の例を次に示します。

## Our Standards

- Use structured logging, not console.log
- Sanitize user input before database queries
- Check for null/undefined on all optional parameters
- Keep functions under 50 lines (extract helpers if needed)
- Every public function needs a test
- Flag any loops that might trigger N+1 queries

## Error Handling

- Always use try-catch blocks for async operations
- Log errors with context (user ID, request ID, timestamp)
- Never swallow errors silently
- Return appropriate HTTP status codes

## Testing Requirements

- Unit tests for all business logic
- Integration tests for API endpoints
- Mock external services in tests
- Test both success and failure paths

カスタム命令の記述に関する詳細なガイダンスについては、GitHub Copilot用のリポジトリカスタム命令の追加を参照してください。

カスタム命令の利点

カスタム命令が設定されている場合:

Copilot は、パターンに従ってコードを提案します
コードレビューが速くなり、スタイルの変更に関する議論が少なくなります
新しいチームメンバーが Copilot 提案を通じて標準を学習する
コードベース全体で一貫性が向上する

パイロットプログラムの実行

小規模から始めて、技術的負債に対する Copilotの影響を検証してから、広くロールアウトしてください。

第 1 週: ベースラインを設定して確立する

すべてのパイロット参加者が、Copilotを有効にしてCopilot cloud agentアクセスできることを確認します。
バックログの技術的負債項目をカウントします。
- "「tech debt」や「chore」、またはそれに類似したラベルが付けられた問題の数"
- 古い依存関係の数
- リンターチェックに失敗したファイルの数
現在のメトリックを追跡する:
- プルリクエストの作成からマージまでの平均時間 (PR のリファクタリング)
- リファクタリングPRごとのレビューラウンド数の平均
最も重要な標準の 3 から 5 を使用して、最初の .github/copilot-instructions.md ファイルを作成します。

週 2 から 4: 試験運用を実施する

パイロット用に 5 から 10 個のリポジトリを選択します。
対処する 1 ~ 2 個の特定の問題を選択します。例えば次が挙げられます。
- 特定の領域でのコードの重複
- 頻繁に変更されるファイルに対するテストが見つからない
- 古い依存関係
IDE で Copilot を使用して、問題が発生した際の迅速な修正を行います。
より大きなクリーンアップタスクを Copilot cloud agentに割り当てます。
Copilot生成されたすべての PR を慎重に確認します。
お客様の好みをCopilotが学ぶための提案についてフィードバックを提供してください。

第 5 週: 結果を評価する

パイロットの後、結果を測定します。

プルリクエストのリファクタリングがマージされる速度はどのくらいですか?
現在必要なレビューラウンドの数はいくつですか?
pull request で Copilot cloud agent によって行われたコード変更の提案の種類は、開発者が最も頻繁に受け入れたのですか?
最もリビジョンが必要な提案はどれですか?
技術的負債メトリックは改善していますか?
- リンター警告が減少していますか?
- テストカバレッジが増えましたか?
- 依存関係のバージョンが最新ですか?

最も Copilot に役立つガイダンスについて学習した内容に基づいて、カスタム手順を更新します。

成功の測定

特定のメトリックを追跡して、技術的負債に対する Copilotの影響を把握します。

速度メトリック

Copilotが開発速度に与える影響を監視します。

技術的負債の問題をクローズする時間 (目標: 30 - 50% 削減)
毎週マージされる技術的負債に関するプルリクエストの数 (目標値: 2 倍から 3 倍までの増加)
リファクタリングプル要求あたりのレビューサイクルの平均数 (これが増加したか減少したかを評価します)

品質メトリック

速度と共に品質が向上することを確認します。

リンター警告の数 (これは減少傾向になります)
テストカバレッジの割合 (これは上昇傾向になります)
リファクタリングされたコードに関連する運用インシデントの数 (これが変更されたかどうかを評価する)

エンジニアの満足度

チームを定期的に調査する:

エンジニアは定期的なメンテナンスに費やす時間が少なくなりますか?
コードレビューはスタイルよりもアーキテクチャに重点を置いていますか。
新しいチームメンバーのオンボーディングはより速くなっていますか?

トラブルシューティング

Copilot 不適切な変更を提案する

Copilot一貫してニーズに合わないコードを提案する場合:

カスタム命令を確認する -- あいまいすぎるか矛盾している可能性があります
プロンプトでより具体的なコンテキストを指定する
カスタム命令に適切なコードの例を追加する
pull request レビューに詳細なフィードバックを残して、 Copilot cloud agent が問題を解決できるようにします

プルリクエストが大きすぎてレビューできません

Copilot cloud agentが確認が困難なプル要求を作成する場合:

大規模なタスクをより小さな重点的な問題に分割する
一度に 1 つのファイルまたはディレクトリを処理するように Copilot cloud agent に依頼する
より具体的な問題の説明を使用する

破壊的変更テスト

リファクタリングでテストエラーが発生した場合:

テストスイートを使用する前に、信頼性を持って確実に実行させるようにする Copilot cloud agent
マージする前に Copilot の変更を慎重に確認する
コードの変更と共にテストを更新するように Copilot に依頼する

チームの導入が遅い

チームが技術的負債の対策としてCopilotを使用していない場合:

早期導入者から成功事例を共有する
チーム会議で時間の節約を実証する
最も厄介な技術的負債項目の解消から始める
カスタム命令の作成をチームアクティビティにする

Conclusion

このチュートリアルでは、 Copilot を使用して技術的負債を体系的に削減する方法について説明しました。これで、次の方法がわかります。

IDE で Copilot を使用して技術的負債を直ちに修正する
大規模なリファクタリングタスクを Copilot cloud agent に割り当てる
チームの標準に合わせて Copilot を調整するカスタム命令を作成する
パイロットプログラムを実行してアプローチを検証する
技術的負債に対する Copilotの影響を測定する

定期的なリファクタリングとメンテナンスのタスクを自動化することで、 Copilot アーキテクチャ、機能開発、およびその他の価値の高い作業に集中できるようになります。

クイックアンケート

このチュートリアルを読んだ後、 Copilot を使用してコードベースの技術的負債を削減できると確信していますか?

Yes No

次のステップ

パイロットを拡大: パイロットの結果に基づいて、より多くのリポジトリに導入します。
依存関係の更新を自動化する: 依存関係の更新を処理するために、 Copilot cloud agent の定期的な問題を作成します。
リファクタリングキューを作成する: バックログの課題にCopilotに適したラベルを付け、定期的にこれらのバッチをCopilotが作業するように割り当てます。
ベストプラクティスを共有する: 成功したプロンプトとチームのカスタム指示を文書化します。