GitHub Copilotで基本設計の精度をあげて効率化する実践プロンプト集

Posted at 2026-09-19

基本設計のレビューで「考慮漏れがある」と指摘された経験、ありませんか？

一人で仕様を考えていると、どうしても視野が狭くなりがちです。

そんなとき頼りになるのがGitHub Copilotです。今回は基本設計フェーズで実際に使えるプロンプトを、実践的にまとめてみました。

この記事でわかること

結論から言うと、Copilotに仕様をいきなり書かせるのではなく「壁打ち相手」として使うのが一番効果的です。

前提条件を渡したうえで質問形式にすると、精度がぐっと上がります。

基本設計は「何を作るか」を決める工程なので、抜け漏れがあると後工程すべてに影響します。

私も最初はCopilotにいきなり設計書を書かせていましたが、それだと一般論しか返ってきませんでした。

前提を渡し、対話形式で詰めていくやり方に変えてから、レビュー指摘が目に見えて減りました。

エンジニアなら読むべき本を30冊以上紹介しています。
正直、私の仕事のやり方をガラッと変えた神本やSQLのチューニングに悩んだ時にめちゃくちゃ役に立ったもあります👇
→記事を読む

Copilot Chatはコンテキストが薄いと、当たり障りのない一般論しか返してきません。

そこでまず「toC向けサービス」「想定同時アクセス数〇〇」「DBは〇〇」のように、前提を先に書き込むのがポイントです。

【前提】

toC向けWebサービス
想定同時アクセス数：1,000
DB：PostgreSQL
認証方式：OAuth2.0

この前提で、ユーザー登録機能の基本設計を検討したいです。
考慮すべき観点を洗い出してください。

前提が曖昧なまま聞くのと、こうして具体的に渡すのとでは、返ってくる回答の質がまったく違います。

ぶっちゃけ、ここを丁寧にやるかどうかで後の手戻りが3倍くらい変わる気がします。

設計のたたき台を書かせるより、「このユースケースで想定外のケースはありますか？」と質問形式で投げるほうが、考慮漏れの発見には向いています。

以下のユースケースについて、想定していない異常系や
エッジケースがあれば指摘してください。

【ユースケース】
ユーザーが会員登録を行い、確認メールのリンクをクリックして本登録する。

こうした質問を投げると、「メール未達のケース」「リンクの有効期限切れ」「二重登録」など、自分では気づきにくい観点が返ってきます。

一人で考えるより、圧倒的に抜け漏れが減るはずです。

Copilotに肯定的な回答ばかり求めていると、リスクに気づきにくくなります。

そこで「この設計のデメリットやリスクを教えてください」と、あえて反対の立場から聞くのがコツです。

この設計方針について、将来的な拡張性・運用コスト・
セキュリティの観点からリスクを指摘してください。

私も最初は「褒めてくれる回答」ばかり求めていましたが、それだと自分の考えを補強するだけで終わってしまいます。

反対意見をあえて引き出す使い方に変えてから、レビューでの指摘が減りました。

反対意見を求めるプロンプトは、既に固まった仕様に対して使うと「今さら言われても」となりがちです。設計の早い段階で使うのがおすすめです。

一つの機能に対して、実装方法は複数あることがほとんどです。

Copilotに複数パターンを出させて、メリット・デメリットを整理してもらうと、比較検討のスピードが上がります。

ユーザー登録機能の実装方法を3パターン提案し、
それぞれのメリット・デメリットを表形式で整理してください。

観点	パターンA	パターンB	パターンC
実装コスト	低	中	高
拡張性	低	中	高
運用コスト	中	低	中

こうした比較表があると、チーム内の合意形成もスムーズになります。口頭で説明するより、表を見せたほうが納得感があるんですよね。

基本設計で見落としがちなのが非機能要件です。

性能・セキュリティ・可用性など、機能要件に比べて後回しにされがちな観点を、Copilotにチェックリスト化させると抜け漏れを防げます。

以下の機能について、考慮すべき非機能要件を
性能・セキュリティ・可用性の観点でリストアップしてください。

このプロンプトは汎用性が高いので、どの機能にも使い回せます。設計レビューの前に一度通しておくと、指摘を受ける前に自分で潰せる項目が増えるでしょう。

基本設計は後工程への影響が大きい分、一人で抱え込むと視野が狭くなりがちです。

Copilotを壁打ち相手として使うことで、精度を保ちながら作業スピードも上げられるはずです。

ぜひ明日からの設計業務で試してみてください。