GitHub Copilot入門:実践ガイド
私は10年以上コードを書いてきましたが、正直に認めます。GitHub Copilotが最初にリリースされた時は懐疑的でした。「コードを書いてくれるAI?スパゲッティコードの元凶になりそうだ」と。しかし、過去6ヶ月間毎日使い続けた結果、予想以上に便利で、同時に予想以上に frustrating なツールだと分かりました。ここでは、セットアップ方法、得意な分野、そして絶対に時間を無駄にする場面を詳しく説明します。
本当の問題点:コンテキストスイッチング
Copilot以前に私を悩ませていたのはこれです:Reactコンポーネントに没頭して複雑な状態更新を書いている最中に、ユーティリティ関数を書くために中断しなければならない。または半年に一度使うライブラリのドキュメントを確認する必要がある。あるいは90%が定型コードの関数のテストを書く必要がある。中断のたびに15〜20分の集中力が失われます。Copilotはそのコストをなくすわけではありませんが、数秒に短縮してくれます。
Copilotのセットアップ:10分で完了
まず、前提条件:GitHubアカウント(無料または有料)と、VS Code、JetBrains IDE、またはNeovimのいずれかが必要です。私はVS Code 1.85以上でテストしました。
拡張機能をインストール:VS Codeを開き、拡張機能(Ctrl+Shift+X)に移動し、「GitHub Copilot」を検索して公式のものをインストールします(青いアイコン、5000万ダウンロード以上)。クローンがありますが、それらはスキップしてください。
認証する:ステータスバー(右下)のCopilotアイコンをクリックします。ブラウザタブが開いて認証を求められます。GitHubにサインインしている必要があります。仕事用アカウントを使用している場合は、正しい組織の権限があることを確認してください。これで20分も無駄にしました。
補完を有効にする:デフォルトでCopilotはオンになっています。アクティブなときはステータスバーに小さなスパークルアイコンが表示されます。静かな時間が必要な場合はクリックしてオフに切り替えます。
以上です。設定ファイルもAPIキーもモデル選択もありません。このシンプルさは長所でもあり短所でもあります。
Copilotを使った最初の10分間
weather.jsという新しいファイルを開きます。次のように入力します:
// 都市名を受け取り、現在の天気を返す関数
1秒待ちます。Copilotはおそらく次のようなものを提案します:
async function getWeather(city) {
const response = await fetch(`https://api.openweathermap.org/data/2.5/weather?q=${city}&appid=YOUR_API_KEY`);
const data = await response.json();
return data;
}
Tabキーを押して受け入れます。次に入力します:
// 温度をケルビンから摂氏に変換
次のように提案されます:
function kelvinToCelsius(kelvin) {
return (kelvin - 273.15).toFixed(1);
}
もう一度Tabキーを押します。これがCopilotの最も得意とするところです:退屈で予測可能な変換です。しかし、ここからが厄介なところです。
Copilotが失敗する(そして時間を無駄にする)場面
1. プロジェクトのコンテキストを理解しない。 Expressを使ったNode.jsバックエンドで作業していました。// authenticate userと入力しました。CopilotはJWTベースの認証フローを提案しました。これは80%のプロジェクトでは正しいでしょう。しかし私のプロジェクトはRedisを使ったセッションベースの認証を使用していました。提案は完全に間違っていました。削除して自分で実際のコードを書かなければなりませんでした。
2. APIをでっち上げる。 これは危険です。ある時、// send email using SendGridと入力しました。Copilotは実際のSendGrid v3 APIには存在しない関数シグネチャでsgMail.send()を提案しました。ドキュメントを確認していなければ、本番環境で実行時エラーが発生していたでしょう。
3. エッジケースを処理しない。 Copilotは90%の確率でハッピーパスを生成します。エラーハンドリング?タイムアウト?レート制限?明示的に要求しない限り、これらはスキップされます。
Copilotのための実践的なプロンプトエンジニアリング
何ヶ月もの試行錯誤の末、実際に効果があるのはこれです:
悪いプロンプト:
// 配送料を計算
良いプロンプト:
// 重量と距離に基づいて配送料を計算
// 重量はkg、距離はkm
// コストはUSDで返す
// 100kg以上の注文には10%割引を適用
コメントが具体的であればあるほど、Copilotの出力は良くなります。コメントに型、単位、ビジネスルールを含めると、編集が必要なコードが80%削減されることがわかりました。
実際のプロジェクト例:Todo APIの構築
実際のセッションを説明します。Todoアプリ用のシンプルなExpress APIを構築しています。
次のように始めます:
const express = require('express');
const app = express();
Copilotは定型のapp.listen()とミドルウェアを提案します。Tabキーで進めます。次に入力します:
// インメモリのTODOストレージ
Copilotは次のように提案します:
let todos = [];
let id = 0;
受け入れます。次に入力します:
// POST /todos - 新しいTODOを作成
Copilotは次のように提案します:
app.post('/todos', (req, res) => {
const todo = {
id: id++,
title: req.body.title,
completed: false,
createdAt: new Date()
};
todos.push(todo);
res.status(201).json(todo);
});
完璧です。受け入れます。次に入力します:
// GET /todos - すべてのTODOを一覧表示
明白な実装を提案します。受け入れます。次に入力します:
// PATCH /todos/:id - completedを切り替え
ここでCopilotが私を驚かせました。次のように提案しました:
app.patch('/todos/:id', (req, res) => {
const todo = todos.find(t => t.id === parseInt(req.params.id));
if (!todo) {
return res.status(404).json({ error: 'Todo not found' });
}
todo.completed = !todo.completed;
res.json(todo);
});
自動的に404ケースを処理しました。要求していないのに。これが一般的なパターンから学習するCopilotです。
テストの罠
メールアドレスを検証する関数を書きました:
function isValidEmail(email) {
const re = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
return re.test(email);
}
次に// tests for isValidEmailと入力しました。Copilotは次のように提案しました:
describe('isValidEmail', () => {
it('should return true for valid email', () => {
expect(isValidEmail('test@example.com')).toBe(true);
});
it('should return false for invalid email', () => {
expect(isValidEmail('invalid')).toBe(false);
});
it('should return false for email without @', () => {
expect(isValidEmail('testexample.com')).toBe(false);
});
});
素晴らしいように見えますよね?しかし、空白を含むメールのエッジケースを見逃しています。そのテストは手動で追加する必要がありました。Copilotが生成したテストを盲目的に信頼してはいけません。 テストはパスしますが、正しいことをテストしていない可能性があります。
時間を節約するキーボードショートカット
Copilotを100時間以上使って、最もよく使うショートカットはこれらです:
- Tab:提案を受け入れる
- Escape:提案を拒否
- Ctrl+Enter:Copilotパネルを開く(10個の代替案を表示)
- Alt+]:次の提案に切り替え
- Alt+[:前の提案に切り替え
最も過小評価されている機能:Ctrl+Enter。Copilotが1つの悪い提案をしたとき、Ctrl+Enterを押すと10個の代替案が表示されます。5番目や6番目の提案が最初のものより良いことがよくあります。
重要な隠し設定
VS Codeの設定(Ctrl+,)を開き、「Copilot」を検索します。私にとって違いを生んだ3つの設定:
github.copilot.enable:MarkdownとYAMLファイルではfalseに設定。Copilotはそれらでは役に立たず、ノイズを追加するだけです。editor.inlineSuggest.enabled:これをtrueに保ちます。ただし、提案が邪魔だと感じる場合はfalseに設定し、Ctrl+Spaceで提案をトリガーするだけにできます。github.copilot.advanced:これは隠されています。"github.copilot.advanced": { "length": 100 }をsettings.jsonに追加して提案の長さを制限します。長い提案(100文字以上)はしばしば幻覚(hallucination)であることがわかりました。
本当のコスト:あなたの注意力
正直な真実:Copilotは定型コードを書くのを速くしますが、複雑なロジックを推論するのを遅くします。トリッキーなアルゴリズムや新しいデザインパターンに取り組んでいるときは、Copilotをオフにします。その提案は私の流れを断ち切り、間違った方向に導きます。
今では精神的なルールがあります:提案を評価するのに自分で書くより時間がかかる場合は、拒否します。これは約30%の確率で発生します。
次のステップ
Copilotをすべてに使おうとしないでください。代わりに、今日20分間この演習を行ってください:
- 先週書いた関数が含まれるファイルを開きます。
- 関数本体を削除します。
- 型、エッジケース、エラーハンドリングを含む、その関数が何をするかの詳細なコメントを書きます。
- Copilotが何を提案するか見てみます。
- 元のコードと比較します。
この20分間で、何時間も読むよりもCopilotの強みと弱みについて多くを学べます。そして、いつ信頼すべきか、いつ自分でコードを書くべきかが正確にわかるでしょう。