「自分で書いたほうが早い」派のエンジニアに捧ぐ、GitHub Copilot を『自分専用』に最適化する技術

はじめに

「AIを使えば業務が爆速になる」 巷に溢れるこの言葉に、違和感を覚えたことはないでしょうか。

熟練のエンジニアであればあるほど、
「AIが吐き出した中途半端なコードを直すより、自分で書いたほうが圧倒的に早い」
と感じる場面は多いはずです。

また、プロジェクト固有の規約を無視した提案をされると、結局「AIは使えない」という結論に至ってしまいがちです。

しかし、GitHub Copilotの本質は「コードの自動生成」ではなく、「開発者の意思を反映させるインターフェース」にあります。

本記事では、AIを「命令したらやってくれるツール」ではなく
「徹底的に制御すべきツール」として使いこなすための、具体的な設定術を紹介します。

AIに「ルール」を強制する：.github/copilot-instructions.md

AIが使いにくい最大の理由は、「プロジェクトのコンテキスト（脈絡）を知らないこと」です。 これを解決するのが、2024年後半から本格導入されたカスタム指示ファイルです。

プロジェクトのルートディレクトリに .github/copilot-instructions.md を配置するだけで、Copilot Chatの回答精度は劇的に変わります。

【設定例】copilot-instructions.md

# 前提
回答は日本語で行うこと。

# プロジェクト固有のコーディング規約
## 基本方針
- **Early Returnの徹底**: ネストを深くせず、例外条件は関数の冒頭で弾くこと。
- **副作用の分離**: ビジネスロジックを純粋関数として記述し、I/O処理と分離すること。
- **ライブラリ制限**: 日付操作に `moment.js` は使用禁止。`date-fns` またはネイティブの `Intl` を使用すること。

## 型定義
- `any` の使用は厳禁。不明な場合は `unknown` を使用し、型ガードを実装すること。
- インターフェース名に `I` プレフィックスを付けない。

## テストコード
- `Vitest` を使用。
- 境界値テスト（Boundary Value Analysis）を必ず含めること。

このような設定ファイルを作成することで、GitHub Copilotの回答はすべてこの規約に沿って行われるようになります。

「AIにすべてお任せ」するのではなく、「このルールから外れた提案はノイズである」とシステム的に定義することで、修正コストを最小化します。

#変数 で小さなタスクをスキップする

「AIに今の状況を説明するのが面倒」という問題は、# から始まるチャット変数（Chat Variables）で解決できます。これにより、AIに「プロジェクトの今」を瞬時に同期できます。

システムの全体像を把握させる：#codebase

巨大な既存プロジェクトにアサインされたとき、全ファイルを読み解くのは骨が折れます。

/explain #codebase このプロジェクトの認証周りのフローはどうなってる？ 

と叩けば、ワークスペース全体をスキャンして概要をまとめてくれます。

ドキュメントが未整備な環境での最初の一歩として非常に強力です。

ターミナルのエラーを丸投げする：#getTerminalOutput

テストが落ちた、ビルドが失敗した。そのログをコピーしてチャット欄に貼り付ける作業ほど無意味なものはありません。

#getTerminalOutput このエラーの解決策を提案して

これだけで、直近のターミナル出力をAIが読み取り、即座に修正案を提示します。

レビューの「低レイヤー作業」を自動化する：review-code.prompt.md

コードレビューは大事な作業ですが、シンタックスの些細なミスや、単純なロジックエラーの確認は「脳の無駄遣い」です。
カスタムプロンプトを使用して、AIに「下読み」をさせることで業務の効率化が行えます。

以下のようなプロンプトファイル（例：.github/copilot/prompts/review-code.prompt.md）を定義します。

あなたはシニアエンジニアです。以下の観点でコードを厳格にレビューしてください。
---
agent: 'ask'
---

1. **計算量**: ループ内での不必要な定数計算や、O(n^2) 以上の処理がないか。
2. **セキュリティ**: SQLインジェクション、XSS、不必要な情報の露出がないか。
3. **可読性**: 変数名が抽象的すぎないか（`data`, `val` など）。

回答は以下の形式で出力してください。
- 🚨 修正必須（理由と修正案）
- 💡 提案（より良い書き方）

実行時は、エディタ上でコードを選択し /review-code を叩くだけで上記の観点でレビューを行ってくれます。
「自分が指摘するまでもない、当たり前のこと」をAIにレビューさせることで、人間は設計レベルの議論に集中できます。

カスタムプロンプトは複数作成できるため、他にも以下のようなプロンプトを作成して利用することが可能です。

• ドキュメント生成：コードから自動でドキュメント作成を行うカスタムプロンプト
• テストコード生成：テストコードを自動生成するカスタムプロンプト
• リファクタリング：コードの整理や最適化を行うカスタムプロンプト
• コード生成：指定した要件に沿ったコードを自動生成するカスタムプロンプト
• コード補完：コードの補完や補助を行うカスタムプロンプト
• etc...

コマンドラインでの活用術：Copilot in the CLI

GitHub Copilot in the CLI（gh copilot）を使えば、 レビューやチャットツールとしての利用だけではなく、 自然言語からコマンドを生成できます。

# 実行例
$ gh copilot suggest "カレントディレクトリ以下の30MB以上のファイルを、最終更新日順に並べて表示して"

# 提案されるコマンド
find . -type f -size +30M -exec ls -lh {} + | sort -k 5 -hr

ここで重要なのは、「AIが生成したコマンドを鵜呑みにしない」というスタンスです。
コマンドの意味を1行ずつ解説させ、納得した上で実行する。
これが、リスクを管理した「エンジニア」らしいAI利用です。

まとめ

AIは「自分の知見」を高速化するためのデバイスである

「自分で書いたほうが早い」というのは、あなたのスキルが高い証拠です。 その高いスキル（＝判断基準）を、.md ファイルという形でAIに同期させてみてください。

• .github/copilot-instructions.md で思考の枠組みを定義する。
• カスタムプロンプト で定型的なレビューを自動化する。
• CLIツール で「暗記のコスト」をゼロにする。

AIを魔法の杖としてではなく、
「高度な設定が可能な、プログラマブルな開発環境」として捉え直す。
これこそが、現代のエンジニアが取るべき最も合理的な戦略ではないでしょうか。

終わりに

あなたのプロジェクトのルートに空の .github/copilot-instructions.md を作り、「AIの癖」を禁止する1行を書き込むことから始めてみませんか？

ここまで読んでいただきありがとうございました！