Copilotが書いたコードを捨てる勇気が、一流エンジニアの条件になった理由

はじめに：Copilot、便利すぎて逆に怖くない？

GitHub Copilotが出てから3年くらい経ちましたね。もう使ってない人の方が少ないんじゃないかってレベルで普及してます。

でも最近、面白いことに気づいたんですよ。めちゃくちゃできるエンジニアほど、Copilotの提案をバシバシ却下してるんです。

「え、逆じゃない？」って思いますよね。でも、これが今のリアルなんです。

Copilotが生み出した新しい問題

考えなくてもコードが書ける、という罠

Copilotの補完、マジで便利ですよね。Tab押すだけで関数が完成するし、めんどくさいボイラープレートも一瞬で終わる。

でもこれ、ヤバい落とし穴があって。

昔のStack Overflowからのコピペって、一応「これ何やってるコードだ？」って確認してから貼り付けてたじゃないですか。でもCopilotの補完ってシームレスすぎて、何も考えずにTab押しちゃうんですよ。

知り合いのCTOが愚痴ってたんですけど、

「コードレビューで『このコード何してるの？』って聞いたら、『わかんないです、Copilotが書きました』って言われた時は目眩がしたわ」

って。マジであるあるらしいです。

「よくあるパターン」が必ずしも正解じゃない件

Copilotが提案してくるのって、要は「世の中によくあるコード」なんですよね。でも、あなたのプロジェクト、本当に「よくあるケース」ですか？

• 独自のアーキテクチャの制約がある
• パフォーマンス要件が特殊
• チーム独自のルールがある
• ドメイン固有のロジックがある

こういうの全部無視して「汎用的な正解」を突っ込んでいくと、プロジェクト全体がカオスになっていきます。

できるエンジニアの「選り好み」テクニック

すぐにTab押さない

デキる人たち、Copilotの提案が出てきてもすぐTab押さないんですよ。2〜3秒くらい見て考えてる。

「これほんとに要る？」
「もっとシンプルにできない？」
「半年後の自分、これ理解できる？」

この数秒が、コードの品質を決めてたりします。

Copilotを品質チェックに使う裏技

これ面白いんですけど、Copilotをテストの答え合わせみたいに使う人がいるんです。

// まず自分でテスト書く（Copilot使わずに）
test('重複メールのチェック', async () => {
  // 自分の頭で考えて書く
});

// で、実装の時にCopilotの提案を見る
async function registerUser(email: string) {
  // Copilotの提案が自分の考えと合ってるか確認
}

Copilotの提案と自分の考えがピッタリ合った時だけ採用。合わない時は「あ、自分の考えがあいまいだったな」って気づけるわけです。

「半分削除ルール」

あるスタートアップが面白いことやってて、コードレビューで「Copilotが書いたコードの50%は削除しよう」って推奨してるんですよ。

理由は簡単で、Copilotってミニマムな実装を提案しないんです。エラーハンドリングとか、ログとか、「あったらいいよね」みたいなコードをめっちゃ盛り込んでくる。

でもYAGNI（必要になるまで作るな）の原則って、まだ生きてるんですよね。いらないコードは、あとでバグの原因になるだけです。

こういう時は捨てよう

即却下したほうがいいやつ

1. パッと見て理解できないコード

   • 無駄に複雑なワンライナー
   • 抽象化しすぎてて逆にわかりにくい関数

2. 依存増やそうとしてくるやつ

   • 新しいライブラリのimport
   • 既にあるユーティリティと被ってる関数

3. プロジェクトの空気読んでないやつ

   • チームの命名ルールと違う
   • 今あるエラーハンドリングと合ってない

4. テスト書きづらそうなやつ

   • グローバル変数に依存してる
   • 副作用ありまくり

これは採用してOK

1. 定型文の自動化

   • TypeScriptの型定義
   • APIリクエストの基本形

2. アルゴリズムのたたき台

   • ソートとか検索の基本ロジック（あとでカスタマイズ前提）

3. ドキュメント系

   • JSDocの生成
   • 複雑なところの説明コメント

データで見る意外な事実

ある調査結果が面白くて。

• 経験3年未満のエンジニア: Copilot提案の採用率 78%
• 経験5〜10年: Copilot提案の採用率 45%
• 経験10年以上: Copilot提案の採用率 32%

でも、実際の生産性（機能完成の速さ、バグの少なさ、レビュー時間）は、ベテランの方が圧倒的に高いんです。

つまり、Copilot使わないほうが、速くて良いコードが書けてるってこと。

実際に試してみよう

1週間実験

これ、マジでやってみてほしいんですけど。

月〜水曜: Copilotの提案、全部受け入れる
木〜金曜: Copilotの提案、半分は却下する意識で

金曜の終わりに両方のコード見比べてみてください。たぶん後半の方がシンプルで読みやすいはず。

チームで「却下率」を共有する

チーム内で「今週何回Copilot却下した？」って共有するのもアリです。却下率高い人を褒める文化。

これって「Copilot使うな」じゃなくて、ちゃんと考えて使おうぜって話なんですよね。

まとめ：AIとの付き合い方

Copilotは神ツールです。マジで便利。でも、最終的に決めるのは自分です。

今のトップエンジニアに必要なのは「AIを使えること」じゃなくて、AIの提案を評価して、いらないものは切り捨てられることなんですよ。

捨てる勇気＝選ぶ力、です。

---

今日、あなたはCopilotの提案を何回却下しましたか？

その回数が、あなたの成長度合いかもしれません。

ちなみに僕は今日、15回くらい却下しました。Tab押す前に考えるクセ、つけていきましょう。