GitHub Copilotのプロンプト設計｜望むアウトプットを引き出す方法・テンプレート

「GitHub Copilotを導入したけれど、思った通りのコードが出てこない」と感じている方も多いのではないでしょうか。原因はツールではなく、指示の出し方と前提情報の渡し方にあります。本記事では、良いプロンプトと悪いプロンプトの違いをBefore/Afterで比較したうえで、毎回同じ指示を書かずに済ませるカスタム命令とプロンプトファイルの設計方法まで整理します。あわせて、AI経営総合研究所が​独自に取材した先行企業の活用実態​から、開発現場での運用の型も紹介します。

弊社では、Github Copilotのプロンプト設計に役立つ資料を配布しています。プロンプトの考え方や社内ルール、リスク対策などが分かる内容です。AIを使いこなして望むアウトプットを引き出す、組織に根付かせるノウハウを知れますので、ぜひご覧ください。

GitHub Copilotにおけるプロンプトの重要性

GitHub Copilotは入力された指示と開いているファイルの文脈からコードを生成するため、指示の精度がそのまま出力の精度になります。言語・フレームワーク・目的の3点が欠けた指示では、修正工数が生成短縮分を上回ります。

GitHub Copilotは「指示駆動型」の仕組み

GitHub Copilotは膨大なコードから学習したAIモデルを基盤とし、入力された言葉と開発中のファイルの内容をもとに候補を返します。プロンプトの精度が低ければ、返ってくるコードも汎用的なものになります。ChatGPTのような汎用対話型AIと違い、リポジトリの構造や既存コードという開発コンテキストに強く依存する点が特徴です。

プロンプトの質が生産性を左右する

プロンプトが明確であれば、短時間で実用的なコードを得られます。逆に指示が曖昧だと、生成されたコードの修正に時間を取られ、「結局自分で書いた方が早い」という状態に陥ります。プロンプトを適切に設計できるかどうかが、GitHub Copilotを効率化の武器とするか時間の浪費とするかの分かれ目です。

プロンプトの質による成果の違い

以下の表は、プロンプトの精度と成果物の違いを整理したものです。キーワードを並べるだけでなく、どの要素を満たすと修正工数が減るのかを把握できます。

プロンプトの質	生成されるコードの特徴	開発者にとっての影響
曖昧なプロンプト	コードが不完全・汎用的で修正が必要	修正工数が増え効率が落ちます
部分的に具体的	一部正しいが要件不足で誤りが残る	デバッグに時間がかかります
明確かつ具体的	要件を満たし実行可能なコードが生成されやすい	修正が最小限で済み効率が上がります

この比較のとおり、プロンプト設計はGitHub Copilotの効果を大きく左右する要素です。

個人技から仕組みへ移すと成果が安定する

「とりあえず使ってみる」段階では、指示の書き方が人によってばらつき、出力の品質も安定しません。後述するカスタム命令とプロンプトファイルを使えば、優れた指示を個人のスキルではなくリポジトリの設定として共有できます。書き方の原則そのものは良い例・悪い例で学ぶプロンプト設計の実践テンプレートでも整理しています。

この差は実際の開発現場にも現れています。CursorとGitHub Copilotを併用するピクスタ株式会社は、新規プロダクト開発で初期段階のコードの多くをAIで記述する水準まで到達しました（後述の他社の取り組みで詳述）。到達点を分けるのは、指示を書く力を個人に閉じ込めるか、チームの設定として残すかの違いです。

プロンプト作成の基本ルール

GitHub Copilotのプロンプトは、処理内容・言語やフレームワーク・目的の3点をセットで書くと精度が安定します。制約条件（エラー処理、命名規則、依存ライブラリ）を1行加えるだけでも、修正回数は目に見えて減ります。

明確で具体的な指示を与える

「関数を作って」という指示では、期待通りの結果になりません。「PythonでFizzBuzzを出力する関数を作成し、結果を標準出力に表示する」のように、処理内容・言語・出力形式をセットで指定します。具体的であるほど余計な修正を避けられます。

言語やフレームワークを必ず指定する

同じ処理でも、JavaScriptとPythonでは書き方が大きく異なります。ここを明示しないと、GitHub Copilotはどちらともとれる中途半端なコードを返します。「Reactを使ったフロントエンド」「Djangoを利用するバックエンド」のように、使用する言語・環境をセットで伝えると品質が安定します。

目的をコメントで補足する

プロンプトの中に「このコードは何のために必要か」を明記すると、GitHub Copilotは文脈に合った提案を返します。処理指示だけでなく、背景や意図をコメントとして加えることで、精度の高い補完を引き出せます。

基本ルールを守るうえで押さえる観点

テクニックの羅列ではなく、「なぜそのルールが必要か」を理解すると応用が利きます。実際にプロンプトを書くときは、以下の3点を確認します。

• 曖昧表現を避けます。「早く」「うまく」など抽象的な表現ではなく、数値や条件で具体化します
• 利用環境を明示します。OSやフレームワーク、バージョンを補足すると、誤った依存関係の提案を回避できます
• ゴールを先に示します。「最終的にWebフォームでユーザー登録できるようにしたい」のように最終目的を明示すると、コードの一貫性が保たれます

これらを徹底すると、GitHub Copilotが意図を読み違えるリスクを最小化できます。

GitHub Copilotのプロンプト Before/After｜同じ目的でも出力が変わる

同じ「テストコードを書かせる」という目的でも、指示の書き方で戻ってくるコードは変わります。ここでは実際の指示文と生成物の違いを、3つのユースケースで比較します。

Before（修正前）｜目的だけを伝えた指示

この関数のテストを書いて

この指示では、テスト対象の範囲・使用するテストフレームワーク・カバーすべき異常系が不明です。多くの場合、正常系1件だけの雛形が返り、そこから自分で書き足すことになります。

After（修正後）｜前提・制約・出力形式を含む指示

# 対象: src/services/user.ts の createUser 関数
# フレームワーク: Vitest（describe / it / expect を使用）
# 観点: 正常系1件、異常系3件（メール形式不正・重複メール・必須項目欠落）
# 制約: 外部DBはモック化する。既存の tests/helpers/mock-db.ts を利用する
# 出力: テストファイル1つ分のコードのみ。解説文は不要
このテストコードを生成してください

改善点は、対象ファイルの指定・フレームワークの固定・網羅すべき観点の列挙・既存ヘルパーの再利用指示・出力形式の限定の5点です。GitHub Copilotは開いているファイルとリポジトリの構造を参照するため、パスを明示すると推測が減ります。

3つのユースケースで見る書き分け

用途によって、指示に含めるべき要素は変わります。以下は代表的な3パターンです。

用途	Before（避けたい指示）	After（推奨する指示に含める要素）
実装	「ログイン機能を作って」	言語・フレームワーク・認証方式・エラー時の挙動・既存の型定義ファイルのパス
リファクタリング	「このコードを綺麗にして」	改善したい観点（可読性／計算量／責務分割）・変更してはいけない外部インターフェース・準拠する命名規則
レビュー	「問題ないか見て」	確認してほしい観点（入力値検証／N+1クエリ／例外処理）・プロジェクトのコーディング規約・指摘の出力形式

共通しているのは、「やってほしいこと」だけでなく「やってはいけないこと」を書く点です。変更禁止の範囲を明示すると、意図しない書き換えが減ります。

そのまま使える3つのプロンプト例

上の表の要素を実際の指示文に落とすと以下のようになります。対象パスとフレームワーク名を自社の環境へ置き換えて使えます。

​実装（ログイン機能）​

# 目的: メールアドレスとパスワードによるログインAPIを実装する
# 言語/FW: TypeScript / NestJS
# 認証方式: JWT（アクセストークン15分・リフレッシュトークン14日）
# 既存資産: src/types/auth.d.ts の型定義に従う。DBアクセスは既存の UserRepository を使う
# エラー時: 認証失敗は401、入力値不正は400を返す。パスワードはログに出力しない
# 出力: コントローラとサービスのコードのみ。解説文は不要
上記の条件でログインAPIを実装してください

​リファクタリング（可読性の改善）​

# 対象: src/utils/report.ts の buildMonthlyReport 関数
# 観点: 可読性を優先する。ネストを2階層以内に収め、責務ごとに関数を分割する
# 変更禁止: エクスポートしている関数名・引数・戻り値の型は変更しない
# 規約: 命名はキャメルケース、早期リターンを優先する
# 出力: 変更後のコードと、分割した関数の役割を1行ずつの箇条書きで
上記の条件でリファクタリングしてください

​レビュー（プルリクエスト前の自己点検）​

# 対象: 選択範囲のコード
# 観点: 入力値検証の漏れ、N+1クエリ、例外処理の握りつぶし、秘匿情報のログ出力
# 規約: プロジェクトのコーディング規約（.github/copilot-instructions.md）に従う
# 出力形式: 指摘ごとに「該当行 / 深刻度（高中低） / 理由 / 修正案コード」の4項目
# 制約: 問題がない箇所は列挙しない。推測で仕様を補わず、不明点は質問として最後にまとめる
上記の観点でレビューしてください

いずれも、末尾の一文以外はすべて前提条件です。指示文の大半を前提条件が占める状態が、精度の高いプロンプトの目安になります。

GitHub Copilotでよくある失敗パターンと改善の方向性

「思った通りに動かない」と感じるケースの多くは、曖昧な指示・言語指定の欠落・コンテキスト不足の3つに分類できます。それぞれ原因が異なるため、対処法も分けて考えます。

曖昧すぎる指示が原因の失敗

「簡単な関数を作って」「APIを呼び出してほしい」といった抽象的な指示は、解釈の幅が広すぎます。結果として、汎用的で使えないコードが返ります。何を・どの言語で・どのように使いたいかを具体的に書くと、生成結果は大きく変わります。

言語・環境を省略した失敗

GitHub Copilotは複数の言語・フレームワークを学習しているため、言語指定がなければ推測でコードを返します。想定外の書き方や古い構文が混じる原因もここにあります。「Pythonで」「Reactを利用して」といった前提を明記するだけで、生成精度は上がります。

コンテキスト不足による誤生成

一見具体的なプロンプトでも、利用目的や制約条件を伝えなければ誤解が生じます。「フォームを作成する」とだけ入力すると、入力チェックやセキュリティ要件を省いた不完全なコードが出力されます。目的や制約をコメントで補足し、GitHub Copilotが前提を正しく理解できる状態を作ります。

3つの失敗は、1行の追記で対処できます。

# 曖昧すぎる指示
簡単な関数を作って
→ CSVの1行を受け取り、日付・金額・摘要の3項目に分割して返す関数を作って

# 言語・環境の欠落
APIを呼び出してほしい
→ Python 3.12 / httpx で、リトライ3回・タイムアウト5秒つきのGETリクエストを書いて

# コンテキスト不足
フォームを作成する
→ 社外向け問い合わせフォームを作成する。必須項目の未入力チェックとCSRF対策を含める

失敗を防ぐためのチェックポイント

プロンプトを書く前に、以下の観点を確認します。

• 指示は十分に具体的か、曖昧さを残していないかを確認します
• 使用言語・フレームワーク・バージョンを指定したかを確認します
• 目的や制約、変更してはいけない範囲を補足したかを確認します

これらを守ると、修正前提のコード生成から、そのまま使えるコード生成へ近づきます。

プロンプトを毎回書かない｜カスタム命令でリポジトリに前提を固定する

毎回同じ前提を書き直す必要はありません。GitHub公式が提供するカスタム命令を使うと、コーディング規約や使用ライブラリをリポジトリ側に置き、すべてのチャットへ自動的に適用できます。プロンプトの品質を個人技からチームの資産へ移す仕組みです。

カスタム命令は3階層に分かれる

GitHub公式ドキュメントでは、カスタム命令を「個人の指示」「リポジトリのカスタム指示」「組織のカスタム手順」の3階層で整理しています。適用範囲と設定者が異なります。

種類	適用範囲	設定者・場所
個人の指示	自分のすべてのチャット	各ユーザー（GitHub.com上のGitHub Copilot Chatのみ対応）
リポジトリのカスタム指示	そのリポジトリでの作業全般	リポジトリにファイルを追加
組織のカスタム手順	組織全体	組織の所有者（GitHub Copilot Business／Enterpriseで利用可）

法人利用でまず整えるのは、リポジトリのカスタム指示です。設定ファイルをコミットするだけで、チーム全員に同じ前提が配られます。

リポジトリのカスタム指示は3種類のファイルで書き分ける

リポジトリ内に置けるファイルは3種類あり、それぞれ適用のされ方が違います。全体に効かせたい規約と、特定の言語・ディレクトリにだけ効かせたい規約を分けて管理できます。

ファイル	パス	効かせ方
リポジトリ全体の指示	.github/copilot-instructions.md	そのリポジトリのすべてのリクエストに適用されます
パス固有の指示	.github/instructions/NAME.instructions.md	指定した種類のファイルやディレクトリにのみ適用されます
エージェント命令	AGENTS.md（CLAUDE.md・GEMINI.mdも可）	エージェント向けの指示として読み込まれます（GitHub Copilotの全機能では未対応）

全体の指示ファイルに何もかも詰め込むと、指示同士が競合して精度が落ちます。テスト用・フロントエンド用など、対象を限定できるものはパス固有の指示に分けるのが公式の推奨です。

複数の指示が競合したときの優先順位

複数の階層に指示を置いた場合、GitHub Copilotには関連するすべての指示が渡されます。優先順位は上から順に以下のとおりです。競合する内容を複数の階層に書かない運用が必須です。

1. 個人の指示が最優先で反映されます
2. 次にリポジトリのカスタム指示が反映されます（パス固有 → リポジトリ全体 → エージェント命令の順です）
3. 最後に組織のカスタム手順が反映されます

なお、プルリクエストのコードレビューでは、GitHub Copilotはベースブランチではなくヘッドブランチのカスタム命令を読み込みます。規約を更新したブランチ内では、その更新後の規約でレビューされます。

書くべき内容と、書いても効かない内容

公式は、短く自己完結した文章で書くことを推奨しています。含めると効果が高いのは、プロジェクト概要・フォルダー構造・コーディング標準・使用ライブラリとそのバージョンの4点です。

一方、以下のような指示は公式が「機能しない例」として挙げています。

• 外部ファイルの参照を求める指示は機能しません（「別リポジトリのスタイルガイドに常に従うこと」など）
• 特定のチャット参加者の使用を強制する指示は機能しません（「Gitの質問には必ず@terminalを使うこと」など）
• 回答のトーンや口調を指定する指示は機能しません（「常にフレンドリーな同僚の口調で答えること」など）
• 回答の文字数を制限する指示は機能しません（「1,000文字以内、12文字以内の単語のみで答えること」など）

設定ファイルの置き場所やエディタ側の初期設定については、GitHub Copilotの設定手順をまとめた記事で詳しく整理しています。

定型作業を1コマンドにする｜プロンプトファイル（.prompt.md）の作り方

カスタム命令が「常に効く前提条件」だとすれば、プロンプトファイルは「呼び出したときだけ効く作業手順」です。.prompt.md として保存した指示を、チャット欄で /ファイル名 と打つだけで再実行できます。

カスタム命令との役割の違い

両者は競合せず、組み合わせて使います。公式は「カスタム命令は各AIワークフローにコードベース全体のコンテキストを追加し、プロンプトファイルは特定のチャット操作に指示を追加する」と説明しています。

観点	カスタム命令	プロンプトファイル
適用タイミング	自動で毎回適用されます	チャットから手動で呼び出します
書く内容	規約・技術スタック・禁止事項	レビュー手順・雛形生成・翻訳などの作業手順
ファイル名	copilot-instructions.md ／ *.instructions.md	*.prompt.md
対応環境	幅広く対応しています	パブリックプレビュー。Visual Studio Code・Visual Studio・JetBrains IDEで利用できます

プロンプトファイルはパブリックプレビュー段階の機能です。全社展開の前に、対象IDEと動作を検証したうえで配布します。

作成と実行の手順

Visual Studio Codeでの作成手順は3ステップです。所要時間は最初の1本で10分程度です。

STEP1. ファイルを作成します（約2分）​

コマンドパレットから Chat: New Prompt File を実行します。ワークスペースに配置する場合は .github/prompts フォルダー、自分専用にする場合はユーザープロファイルへ保存されます。

STEP2. フロントマターと本文を書きます（約5分）​

先頭にYAMLフロントマターを置き、その下にMarkdownで手順を書きます。設定できる項目はすべて任意です。

項目	役割
description	プロンプトの短い説明を書きます
name	チャットで / の後に入力する名前を指定します（省略時はファイル名が使われます）
argument-hint	チャット入力欄に表示する引数のヒントを書きます
agent	ask / agent / plan またはカスタムエージェント名を指定します
model	使用するモデルを指定します（省略時はモデルピッカーの現在値が使われます）
tools	利用するツールやツールセットを配列で指定します

本文からは、相対パスのMarkdownリンクで他のワークスペースファイルを参照できます。参照先に規約ファイルを指定すれば、手順と規約を分けて管理できます。

STEP3. チャットから呼び出します（約1分）​

チャット入力欄で / に続けてファイル名（または name で指定した名前）を入力すると実行されます。作成済みのファイルは Chat: Open Customizations から一覧で管理できます。

チームで最初に用意する3本

公式はユースケースとして、コード生成・ドメイン知識の共有・チームのコラボレーション・オンボーディングの4種類を挙げています。実務では、以下の3本から始めると効果が見えやすくなります。

• ​レビュー用​​：セキュリティ観点（入力値検証・認可・秘匿情報のログ出力）を固定した指摘用の手順を書きます
• ​テスト生成用​​：使用するテストフレームワークとモックの方針、網羅すべき異常系の観点を書きます
• ​オンボーディング用​​：ディレクトリ構成と主要なデータフローを説明させる手順を書き、新メンバーが最初に叩くコマンドにします

いずれも、優れたプロンプトを書ける人の頭の中をファイルに落とす作業です。属人化していた指示の型を、リポジトリの資産へ移せます。

GitHub Copilot Chatのスラッシュコマンドとコンテキスト指定

プロンプトを長く書く前に、標準機能で済む部分は記号で指定します。/ で定型タスク、# で参照範囲、@ で専門領域を指定でき、そのぶん自然文の指示を短くできます。

スラッシュコマンドはIDEごとに異なる

同じGitHub Copilot Chatでも、利用できるコマンドは環境によって違います。主要な環境での対応は以下のとおりです。

環境	利用できる主なコマンド
Visual Studio Code	/clear（新しいチャットセッション）、/explain、/fix、/fixTestFailure、/help、/new、/tests
Visual Studio	/doc、/explain、/fix、/help、/optimize、/tests
JetBrains IDE	/chronicle、/compact、/explain、/fix、/help、/remote、/tests
Xcode	/doc、/explain、/fix、/simplify、/tests
GitHub Webサイト	/clear、/delete、/new、/rename

「このコードを説明して」と毎回書く代わりに /explain、「テストを書いて」の代わりに /tests を使えば、指示文は観点の記述だけに絞れます。

# で参照範囲、@ で専門領域を指定する

Visual Studio Codeでは、# に続けてキーワードを入力すると参照させる範囲を明示できます。#file（特定ファイル）、#selection（選択範囲）、#project（プロジェクト全体）、#function（関数）、#class（クラス）、#sym（シンボル）などが用意されています。Visual Studioでは #MyFile.cs や #MyFile.cs: 66-72 のようにファイル名と行番号を直接指定します。

@ で始まるチャット参加者は、特定領域の文脈を持ち込む仕組みです。@github（GitHubの情報）、@terminal（ターミナルシェルとその内容）、@vscode（VS Codeのコマンドと機能）、@azure（パブリックプレビュー）が使えます。ターミナルのエラーを貼り付ける代わりに @terminal を使うと、直前の実行内容を踏まえた回答が返ります。

記号とプロンプトファイルの使い分け

3つの記号は、毎回のチャットを短くするための道具です。同じ組み合わせを繰り返し使うようになったら、その手順ごとプロンプトファイルへ切り出します。判断の目安は「週に3回以上、同じ指示を書いているか」です。記号とプロンプトファイルで指示の型が固まったら、次はエージェントモードで複数ファイルの変更をまとめて任せる段階へ進みます。

GitHub CopilotとChatGPTの違いと使い分け

GitHub CopilotはIDE内のコード補完と実装支援、ChatGPTは設計検討や文章生成に強みがあります。リポジトリの文脈を必要とする作業はGitHub Copilot、前提のない検討はChatGPTと分けると、手戻りが減ります。

GitHub CopilotはIDE内での補完に特化

GitHub CopilotはVisual Studio CodeなどのIDEに組み込み、リアルタイムでコード補完を行います。開発中のファイルや既存コードを文脈として理解し、短時間で実装可能なコードを提示する点に強みがあります。「今すぐ動くコードが欲しい」場面に適しています。

ChatGPTは設計・学習・文章生成に強い

ChatGPTはIDEに依存せず、自然言語ベースの会話に対応します。アルゴリズムの解説や設計方針の検討、ドキュメントの生成など、コード以外の知識補完や学習用途に向いています。曖昧な質問や背景説明も含めてやり取りできる点が特徴です。

併用時の役割分担

開発フローの中では、以下のように工程で切り分けると無駄が減ります。

• 設計方針の比較検討や技術選定の壁打ちはChatGPTで行います
• リポジトリの既存コードを踏まえた実装・テスト・リファクタリングはGitHub Copilotで行います
• 実装後の仕様書やREADMEの下書きは、生成したコードを渡してChatGPTでまとめます

なお、両者を行き来する回数が増えるほど文脈の受け渡しコストがかかります。リポジトリの情報が必要な作業は、カスタム命令を整えたGitHub Copilot側に寄せると効率的です。

GitHub Copilotを活用する応用プロンプト設計の考え方

基本を押さえたら、レビュー・テスト・チーム標準化の3領域に展開します。個人の補完速度ではなく、レビュー工数とコード品質のばらつきを削る使い方が、組織としての投資対効果を決めます。

コードレビューを補助するプロンプト

レビュー工程では、可読性や改善点を確認する作業が発生します。「この関数をリファクタリングできるか」「セキュリティ的に問題がある箇所はないか」といった観点を指定すると、改善ポイントを自動で抽出させられます。人手の確認を補完することで、レビューの質と速度が同時に上がります。

テストコードを生成するプロンプト

テスト工程もGitHub Copilotが支援できます。「この関数に対するユニットテストを作成して」と指示するだけで基本的なテストケースが生成され、品質確保のベースを短時間で整えられます。精査は必要ですが、ゼロから書くより工数を圧縮できます。前述のプロンプトファイル化と組み合わせると、テストの観点そのものをチームで統一できます。

チームで統一ルールを設けるプロンプト設計

個人が自由にプロンプトを書くと、コード品質や出力結果がばらつきます。チームで統一したフォーマットを設ければ、成果物の一貫性を保ち、属人化を防げます。ここで有効なのが、口頭やドキュメントでのルール共有ではなく、copilot-instructions.md としてリポジトリにコミットする方法です。ルールがコードと同じレビュー対象になり、形骸化を防げます。

ルールは一度作って終わりではありません。株式会社Finatextホールディングスは、自社AIガイドラインを2023年3月の初版以降、継続的に改定しています。禁止事項や推奨ライブラリが変われば、その差分をカスタム命令にも反映します。この更新サイクルまで含めて設計すると、ルールが実態と乖離しません。

GitHub Copilotのセキュリティ・品質リスクと注意点

生成されたコードをそのまま採用すると、入力値検証の不足や古いライブラリの利用といった脆弱性を取り込むリスクがあります。レビューと検証を工程として組み込み、法人利用ではプラン選定を含めたガバナンス設計を先に固めます。

生成コードの脆弱性に注意する

GitHub Copilotは学習した膨大なコードを参考に出力します。そのため、セキュリティ的に脆弱な書き方を提案する場合があります。特に入力値の検証不足や古いライブラリの利用は頻発します。開発者がレビューを省けば、そのまま脆弱性を組み込むことになります。

レビューと検証をセットにする

「GitHub Copilotが出したから大丈夫」という判断は成立しません。動作確認やテストコードによる検証を行い、人間のレビュー工程と組み合わせて使います。レビューを前提にすると、生成されたコードを叩き台として安全に活用できます。カスタム命令に禁止事項（秘匿情報のログ出力禁止、非推奨APIの使用禁止など）を書いておくと、レビュー前の段階で問題の混入を減らせます。

法人利用ではガバナンス設計が不可欠

法人利用では、知的財産の扱いやセキュリティ基準の担保が求められます。後述のとおり、知財免責とデータプライバシーの保護はGitHub Copilot Business／Enterpriseに限定されています。個人向けプランを業務で使う運用は、契約面のリスクを抱えたままになります。想定されるリスクと対策の全体像は、GitHub Copilotのセキュリティリスクと対策で整理しています。

ガバナンス対策については以下の資料で詳しく解説していますので、ぜひご覧ください。

プラン別にできること｜Free〜Enterpriseの機能差

GitHub Copilotの公式プランは、個人向けのFree・Pro・Pro+・Max、ビジネス向けのBusiness・Enterpriseの計6つです。2026年6月1日にリクエスト回数ベースの課金からGitHub AI Credits（トークン量ベース）へ移行しました。

6プランの比較

以下は公式のプラン一覧に基づく整理です（1ユーザーあたり月額、米ドル建て）。

プラン	月額	AI Credits	コード補完	主な特徴
Free	$0	―	月2,000件	エージェントモードは月50件までです
Pro	$10	​合計$15（基本$10＋Flex$5）​	​無制限​	​コードレビュー・クラウドエージェント・モデル選択に対応します（個人の第一候補）​
Pro+	$39	合計$70（基本$39＋Flex$31）	無制限	プレミアムモデルと監査ログに対応し、Pro比で利用枠が4倍以上です
Max	$100	合計$200（基本$100＋Flex$100）	無制限	Pro+比で利用枠が2.9倍以上、新機能を優先的に利用できます
Business	$19／ユーザー​	​基本$19（Flexなし）​	​無制限​	​知財免責・SSO・アクセスコントロール・予算管理に対応します（法人の第一候補）​
Enterprise	$39／ユーザー	基本$39	無制限	共有枠が1ユーザーあたり月1,000回、第三者エージェントへの委任がプレビュー提供されています

法人で選ぶ基準は利用枠の大きさではなく、知財免責とガバナンス機能の有無です。この2点を満たすのはBusinessとEnterpriseに限られます。

クレジットの消費対象を理解する

課金の考え方を誤ると、想定外の追加請求につながります。公式が示す条件は以下のとおりです。

• コード補完とNext Edit Suggestionsはクレジットを消費しません
• Chat・エージェントモード・コードレビュー・クラウドエージェント・CLI・Appsがクレジットを消費します
• 上限を超えた際に安価なモデルへ自動でフォールバックする仕組みは廃止され、追加課金か利用ブロックのいずれかになります
• 年間契約中のユーザーは、契約期限まで旧方式（Premium Requests）も選択できます

補完中心の使い方であればクレジットはほとんど減らず、エージェントモードを多用するほど消費が増えます。プラン選定の前に、チーム内でどの機能を主に使うのかを確認します。詳しい料金の考え方はGitHub Copilotの料金とコスパの比較で解説しています。

チーム導入で成果を最大化するために

個人で試すだけでは、成果が属人化したまま終わります。カスタム命令とプロンプトファイルをリポジトリに置き、レビュー対象に含める運用まで設計すると、チーム全体の出力品質が揃います。

共通プロンプトルールをリポジトリで管理する

エンジニアが個別にプロンプトを書けば、成果物の品質やスタイルにばらつきが出ます。「テストコードを必ずセットで生成する」「利用するライブラリを明示する」といった共通ルールを copilot-instructions.md に書き、プルリクエストのレビュー対象に含めます。ルールの更新履歴がコードと同じ場所に残るため、なぜその規約になったのかを後から追えます。

学習機会を組織的に設計する

プロンプト設計は、個人の試行錯誤に任せるより、失敗パターンを共有する場を作るほうが定着が早まります。プロンプトファイルのレビュー会を月1回設けるだけでも、優れた指示の型がチームに広がります。教育設計と効果測定の進め方はGitHub Copilot研修の設計方法で整理しています。

定着度を測る指標を決める

導入効果を「体感」で語ると、投資判断ができません。プルリクエストのレビュー指摘件数、テストコードのカバレッジ、実装からレビュー完了までのリードタイムなど、既存の開発指標のうち2〜3個を導入前後で比較します。指標を先に決めておくと、次のプラン更新時の判断材料になります。

成果を出すための組織体制については以下の資料でより詳しく解説しています。正しいプロンプト設計を全社展開したい方はぜひご覧ください。

他社の取り組み｜ピクスタ・Finatextホールディングスに学ぶAI前提の開発体制

プロンプト設計をチームの成果へつなげている企業は、指示の書き方だけでなく運用の枠組みを整えています。AI経営総合研究所が独自に取材した2社の事例から、その共通点を整理します。

ピクスタ株式会社｜新規プロダクトのコードの多くをAIで記述

ピクスタ株式会社は、「検索体験を良くしたい」という強い課題意識からAI活用を進め、新規プロダクト開発では初期段階のコードの多くをAIで記述しています。CursorとGitHub Copilotを作業に応じて併用し、2026年を全プロダクト・業務へのAI活用実現の年と位置づけています。担当者は「​​各部署それぞれに業務の知識を持っている人がいて、その人たちが自分の仕事をAI前提でアップデートしていくことが重要だと考えます。​​」と語っています。

注目すべきは、​​業務知識を持つ担当者自身が、自分の仕事の進め方をAI前提に組み替えている​​点です。プロンプトの巧拙を一部のエンジニアに任せるのではなく、現場が自分の文脈で指示を設計する体制が、出力品質の底上げにつながります。

詳細はピクスタ株式会社のインタビュー記事で紹介しています。

株式会社Finatextホールディングス｜ガイドライン改定とガードレール設計を並走

株式会社Finatextホールディングスは、セキュリティや信頼性を求められる一方で生産性向上が急務だったため、自社AIガイドラインを2023年3月の初版以降、継続的に改定しています。従量課金APIで複数AIモデルを一画面から選択できる社内ツール「Alfred」を開発し、非エンジニアであるCFOがGitHub Copilot等でシステム間の自動連携を構築するまで活用が広がりました。同社は「​​今後は開発エージェントをより広範囲に活用し、業務のライフサイクルを自動化していきたいと考えています。そのために重要になるのが、AIの暴走を防ぐためのガードレールをしっかりと作り上げることです。新卒の社員をサポートする仕組みと同じように、AIに対しても適切な制御をかけていきます​​」と語っています。

注目すべきは、​​活用範囲を広げる施策と制御の仕組みを同時に設計している​​点です。カスタム命令に禁止事項を書き込む運用は、まさにこのガードレールをリポジトリ単位で実装する方法にあたります。

詳細は株式会社Finatextホールディングスのインタビュー記事で紹介しています。

2社に共通する設計思想​​：①プロンプトの巧拙を個人任せにせず、現場の業務知識を持つ人が自分で指示を設計する ②活用範囲の拡大と制御ルールの整備を同時に進める ③ルールを一度作って終わりにせず、継続的に改定する。この3点を、カスタム命令ファイルとそのレビュー運用として自社のリポジトリに実装するのが次の一歩です。

【まとめ】GitHub Copilotはプロンプト設計が鍵

GitHub Copilotを使いこなせるかどうかは、プロンプト設計と、その設計を仕組みに落とせるかで決まります。本記事の要点は以下のとおりです。

• 曖昧な指示では汎用的で不完全なコードが返ります。処理内容・言語・目的の3点をセットで指定します
• 「やってはいけないこと」を書くと、意図しない書き換えが減ります
• 毎回書いていた前提は .github/copilot-instructions.md に固定し、対象を絞る規約は *.instructions.md に分けます
• 繰り返す作業手順は .prompt.md に切り出し、/コマンド で呼び出せる状態にします
• /explain #file @terminal などの標準機能を使うと、自然文の指示を短くできます
• 法人利用では、知財免責とガバナンス機能を持つBusiness以上を選びます

つまり、GitHub Copilotを補助ツールで終わらせるか開発基盤に変えるかは、指示をどこまでチームの資産として設計できるかで決まります。

そして、プロンプトの型が固まった次に立ちはだかるのは、ルールをチームの標準として定着させ、活用度を測りながら更新し続ける運用の設計です。ツールの使い方から一段上がった、組織としての整備が成果を分けます。

以下の資料では、プロンプトの考え方や運用設計などをより深く解説しています。AIを使いこなして望むアウトプットを引き出す、組織に根付かせるノウハウを知れますので、ぜひご覧ください。

よくある質問