「コード補完は使っているけど、それ以外の場面でどう使えばいいかわからない」「上流工程や調査業務にはあまり活かせていない」と感じていませんか？実はGitHub Copilotは、実装だけでなく設計書の起こし、テスト観点の洗い出し、障害調査の当たりづけといった、SEが実際に時間を取られている工程でこそ真価を発揮します。この記事では、実際に投げるプロンプトの形まで含めて、明日から使える具体的なテクニックを紹介します。
この記事でわかること
- 既存コードから機能設計書やシーケンス図のたたき台を作らせる方法がわかる
- テスト仕様書（正常系・異常系・境界値）を観点ごとに洗い出させるプロンプトの型がわかる
- 障害調査やログ解析でCopilotをどう使うと当たりが早くつくかがわかる
- 改修時の影響範囲調査やレガシーコードの解読に活かす実践的な手順を理解できる
結論：Copilotは「実装させる」より「読ませて言語化させる」ほうがSEの業務では効きます
結論から言うと、SEの日常業務でCopilotが本当に効いてくるのは、コードを書かせる場面よりも、既存のコードや資料を読み込ませて、人間の代わりに言語化・整理させる場面です。設計書の起こし、テスト観点の洗い出し、障害調査の当たりづけは、どれも「読んで整理する」作業であり、Copilotが最も得意とする領域と重なります。
なぜそう言えるのか
実装を丸ごと任せるやり方は、実はまだ発展途上です。設計書をインプットにCopilotへ実装まで任せた事例では完璧なものは無理で、Copilotに実装させて間違った部分を人間が直す必要があり、体感で8割程の正解コードを生成してくるという報告があります。つまり「書かせる」場面では、まだ人間のチェックが前提です。
一方で、既存コードを読み込ませて設計書やテスト観点を「起こす」場面は話が別です。GitHub Copilotは現在開いているソースコード、特に選択範囲をコンテキストとして利用でき、仕様書ではなく自分たちの書いた既存コードを参照して、それを入力として何らかの生成を行うこともできます。私は個人的に、ゼロから書かせるより「すでにあるものを読ませて整理させる」使い方のほうが、手戻りが少なく実務で信頼できると感じています。
エンジニアなら読むべき本を30冊以上紹介しています。
正直、私の仕事のやり方をガラッと変えた神本やSQLのチューニングに悩んだ時にめちゃくちゃ役に立ったもあります👇
→記事を読む
SEの現場で使えるGitHub Copilot活用テクニック10選
ここからは、実際に投げるプロンプトの形も交えながら、工程別に紹介していきます。
① 既存コードから機能設計書のたたき台を作らせる
対象の関数・クラスを開いた状態（または#file:で指定した状態）で、次のように投げます。
#file:OrderService.java
このクラスの処理内容を、以下の項目で機能設計書の形式に整理してください。
概要（このクラスが何をするものか）
入力パラメータと型、意味
処理の流れ（箇条書きで手順化）
出力・戻り値
例外発生時の挙動
GitHub Copilotを活用し、既存プログラムのコードからプログラム設計書の生成を検証する取り組みは実際に報告されており、私も似た形で試してみましたが、処理の流れを箇条書きに落とす精度は思った以上に高く、ゼロから書くよりレビューする方が圧倒的に早いと感じました。ただし専門用語や社内独自の呼び方までは汲み取ってくれないので、用語だけは自分で置き換える前提で使うのがコツです。
② シーケンス図・ER図をMermaid形式で出力させる
文章の設計書だけでなく、図として起こしたい場合はMermaid記法を指定すると扱いやすくなります。
#file:OrderController.java #file:PaymentService.java
これらのクラス間の呼び出し関係を、Mermaidのsequence diagramの形式で出力してください。
異常系（決済失敗時）の分岐も含めてください。
出力されたMermaidコードはそのままGitHubのMarkdownやQiitaに貼れば図として表示されるので、設計書用の画像を別途作る手間が省けます。私はレビュー会の説明資料を作るときに、この方法で叩き台を用意してから手直しする流れに変えてから、資料作成の時間が体感で半分以下になりました。
③ テスト仕様書を「観点表」として洗い出させる
テストコードを直接書かせるより先に、まず観点表を作らせるのがポイントです。
#file:validateOrder.py
この関数に対するテスト観点を、以下の表形式で洗い出してください。
| No | 観点区分（正常系/異常系/境界値） | 入力条件 | 期待結果 |
GitHub Copilotを使ってテストコードを自動生成するには、まずテスト対象のコードを記述し、テストコードのコメントを記述してCopilotにテストコードの生成を依頼すると、コメントに基づいて適切なテストコードを提案してくれます。この流れをそのままテスト仕様書作りに応用し、いきなりコードにせず「観点表」を先に作らせることで、テストケースの抜け漏れをレビューしやすくなります。境界値の洗い出しは特に得意なので、私はここだけは毎回Copilotに一度チェックさせるようにしています。
テスト観点の洗い出しは強力ですが、業務ロジック特有の「暗黙のルール」（例：特定の顧客ランクだけ例外的に許可する等）は仕様書やコードに明記されていないと拾えません。ドメイン知識が必要な観点は、必ず人間側でも別途洗い出してください。
④ I/F仕様書をAgentモードで自動生成させる
実際の開発現場でも、GitHub CopilotのAgentモードを使って、I/F仕様書を自動生成する取り組みが報告されています。API定義やコントローラのコードをコンテキストとして渡し、「リクエスト・レスポンスの項目一覧、必須/任意、型、桁数を表形式で整理して」と依頼すれば、項目の洗い出しレベルではかなり実用的な出力が得られます。私が試した範囲では、桁数までは推測になりがちなので、その部分だけ元のDB定義を突き合わせて確認する運用にしています。
⑤ 障害調査でスタックトレースとログを読ませる
障害対応時は、まずログとエラーメッセージをそのまま貼って聞くのが手っ取り早いです。
以下はエラーログです。発生しうる原因を可能性が高い順に3つ挙げ、
それぞれ確認すべきコード箇所や設定を教えてください。
[ここにスタックトレースを貼る]
コードベースを開いた状態で聞けば、該当のクラスやメソッドまで踏み込んで候補を出してくれることが多く、「まずどこから疑うか」の当たりをつけるスピードが上がります。私はこの使い方をしてから、原因調査の最初の1時間を丸々節約できたと感じることが何度もありました。
⑥ 改修時の影響範囲調査に使う
grepで呼び出し元を手作業で追うより先に、Copilotに聞いてしまう方法です。
#codebase
UserRepositoryのfindByEmailメソッドを変更しようとしています。
このメソッドを呼び出している箇所を一覧化し、
それぞれの呼び出し元で戻り値がnullの場合の扱いを整理してください。
'#codebase' を使用するときにエージェント コード検索を有効にすることで、コードベースの検索が強化されます。大規模なリポジトリほど手作業の全文検索では見落としが起きやすいので、まずCopilotに一覧化させてから、重要な箇所だけ自分の目で裏取りする、という二段構えが安全です。
⑦ レガシーコードの読み解きに使う
コメントもドキュメントもない古いコードを引き継いだときほど、Copilotの読解力が活きます。
#file:LegacyBatchProcess.java
このバッチ処理を新人エンジニアに説明する想定で、
処理の目的、主要な分岐条件、注意すべき副作用を平易な言葉で説明してください。
一気に全体を理解しようとせず、まず「何をしているか」を言語化させてから細部を追う、という順番にすると、自力で1行ずつ追うよりも早く全体像がつかめます。
⑧ 議事録・ヒアリングメモから要件のたたき台を作る
要件定義やヒアリングの直後に、メモをそのまま貼って整理させるのも有効です。
以下は顧客ヒアリングのメモです。要件を「機能要件」「非機能要件」「未確定事項」に分類し、
それぞれ箇条書きで整理してください。
[ここにメモを貼る]
未確定事項を分けて出させることで、次回のヒアリングで確認すべき項目が自然とリストアップされるのが便利なポイントです。
⑨ コードレビュー観点をチェックリスト化させる
レビュー担当になったときは、まず観点の整理をCopilotに手伝わせます。
#file:PaymentController.java
このコードをレビューする際にチェックすべき観点を、
セキュリティ・パフォーマンス・可読性・例外処理の4カテゴリに分けてリストアップしてください。
指摘そのものをCopilotに任せるのではなく「見るべき観点」を先に整理させることで、レビューの抜け漏れを減らしつつ、最終判断は自分で行える体制を保てます。
⑩ 設計書をインプットに実装のたたき台を作らせる（人間チェック前提で）
逆方向、つまり設計書からコードを起こす場合にも使えます。クラスとシーケンスの設計をプロンプトファイルにまとめ、新しいチャットセッションを作成し、設計書とcodebaseを追加して実行するという手法が実際に試されており、この方法である程度パターン化された画面実装であれば、たたき台としては十分使えるレベルの出力が得られたとのことです。ただし前述の通り正解率は完璧ではないので、「8割できている前提で、残り2割を人間が直す」くらいの温度感で任せるのが安全です。
エンジニアなら読むべき本を30冊以上紹介しています。
正直、私の仕事のやり方をガラッと変えた神本やSQLのチューニングに悩んだ時にめちゃくちゃ役に立ったもあります👇
→記事を読む
まとめ
- ✅ 設計書やI/F仕様書は「既存コードを読ませて整理させる」使い方が特に効く
- ✅ テスト仕様書はいきなりコードにせず、観点表を先に作らせて抜け漏れをレビューする
- ✅ 障害調査ではログやスタックトレースをそのまま貼って原因の当たりをつけさせる
- ✅ 影響範囲調査は
#codebaseで呼び出し元を一覧化させてから人間が裏取りする - ◎ どのテクニックも「Copilotの出力を鵜呑みにせず、最後は人間が確認する」前提で使うのが安全