GitHub Copilotの使い方は「補完」「チャット」「エージェント」の3つに分かれる
GitHub Copilot の使い方は、書きかけのコードの続きを提案させる「コード補完」、対話でコードについて尋ねる「Copilot Chat」、作業そのものを任せる「エージェントモード」の 3 つに分かれます。
どれもエディタの中で動きますが、任せる範囲と、人が確認する量が違います。最初にこの区別を持っておくと、目の前の作業をどれで進めるかを迷わずに決められます。
関連記事:GitHub Copilotでできること|開発の5つの場面と料金・違いを整理
使い方1|コード補完で書きかけの続きを出す
関数名や変数名を書き始めると、周辺のコードから続きになりそうな数行が薄い文字で表示されます。意図と合っていればキー操作ひとつで確定し、違えば無視して書き続けられます。
人が主導権を持ったまま、手を動かす速度だけを上げる使い方です。3 つのうち最も確認の負担が軽く、最初に慣れておきたい操作になります。
使い方2|Copilot Chatで聞く・直してもらう
チャットでは、選んだコードの動きを説明させたり、エラーメッセージを貼って原因の候補を挙げさせたりできます。検索して当たりを付けるのと違い、いま開いているコードを踏まえた回答が返ってきます。
書く前の調査と、書いた後の見直しの両方で使えます。ここから先は、人が問いを立てる分だけ返ってくる情報が変わります。
使い方3|エージェントモードでまとめて任せる
エージェントモードでは、変更するファイルを Copilot が決め、コードの変更とターミナルのコマンドを承認用に提示し、元のタスクが終わるまで修復を繰り返します(出典: github.com)。
補完やチャットが「1 手ずつ」なのに対し、こちらは目的を伝えて経過を承認していく形です。確認する範囲が広くなるぶん、任せる作業を選ぶ必要があります。
GitHub Copilotの始め方|VS Codeに入れて最初の提案が出るまで
導入は短時間で終わります。特別なサーバーは要らず、普段使っているエディタに拡張機能を入れてサインインするだけです。
公式のクイックスタートに沿うと、最初の提案が出るまでの導入手順は次の 4 ステップです。
- GitHub アカウントを用意し、使うプランを決める
- 使っているエディタの拡張機能マーケットプレイスから GitHub Copilot をインストールする
- エディタ上で GitHub アカウントにサインインして認証する
- ファイルを開いて関数の書き出しを打ち、灰色の文字で提案が出ることを確認する
最初に決めるのはプランだけ
Copilot を使うには、GitHub プランにアクセスできる個人用の Copilot アカウントが必要です(出典: github.com)。無料の Copilot Free で試すか、上位プランを契約するかをここで決めます。
迷う場合は無料枠から始めて構いません。プランごとの違いは後の章で整理します。
認証まで終われば設定はほぼ不要
拡張機能をインストールした後は、エディタ上で GitHub にサインインします。VS Code なら「GitHub で Visual Studio Code にサインイン」、JetBrains 系なら IDE 内で GitHub にサインインする流れです(出典: github.com)。
組織のアカウントで使う場合は、組織側で Copilot の利用を許可し、対象の利用者に席を割り当てる操作が別に要ります。個人で試した手順のまま社内展開すると、この一段が抜けて動かない状態になりやすい部分です。
自分の開発環境が対応しているかを先に確認する
対応環境は Visual Studio Code のほか、Visual Studio(Windows 用 2022 17.8 以降)、JetBrains 系 IDE、Xcode、Eclipse、Windows Terminal、そして GitHub の Web 画面です(出典: github.com)。
機能の対応範囲は環境によって差があります。まず試す段階であれば、対応が最も広い Visual Studio Code から始めるのが分かりやすい選び方です。
コード補完の使い方|提案の受け入れと切り替えのキー操作
コード補完は、関数ヘッダーを入力すると関数本体が灰色のテキストで自動的に提案され、Tab キーで受け入れる仕組みです(出典: github.com)。日常的に使うのはこの一連のキー操作なので、先に手に覚えさせておくと迷いが減ります。
受け入れる・断る・別の案を見る
公式が挙げている操作は次のとおりです。VS Code と JetBrains 系 IDE では同じキー割り当てになっています(出典: github.com)。
| 操作 | Windows / Linux | Mac |
|---|---|---|
| 提案を受け入れる | Tab | Tab |
| 提案を断る | Esc | Esc |
| 次の候補を見る | Alt + ] | Option + ] |
| 前の候補に戻る | Alt + [ | Option + [ |
| 手動で提案を出す | Alt + \ | Option + \ |
Visual Studio では次の候補が Alt + . 、前の候補が Alt + , に割り当てられています。Eclipse には Ctrl + →(Mac は Command + →)で 1 単語ずつ受け入れる操作もあり、書き出しだけ借りたいときに向きます(出典: github.com)。
コメントを1行書いてから提案させる
処理の内容が決まっているのに書き方を思い出せない場面では、コメントでやりたいことを 1 行書いてから改行します。「この配列を日付の新しい順に並べ替える」のような日本語のコメントからでも提案が出ます。
関数まるごとを作らせたいときも同じ考え方です。先に意図を文章にしておくほど、返ってくる実装が狙いから外れにくくなります。
次に直す場所まで提案させる
VS Code、Xcode、Eclipse では、次に編集する箇所を予測する next edit suggestions が使えます(出典: github.com)。変数名を変えた後に、同じ変更が要る箇所を続けて提示するような動き方をします。
1 か所直すと関連箇所も直す必要がある、という修正でまとまった手数を減らせます。補完を「今カーソルがある行だけのもの」と捉えていると見落とす機能です。
Copilot Chatの使い方|モードの選び分けと入力の型
Copilot Chat には、コードの中に開くインラインチャットと、画面の横に出すチャットビューの 2 つの入口があります。インラインチャットは VS Code と JetBrains 系 IDE で Ctrl + i(Mac は Command + i)、チャットビューはタイトルバーのチャットアイコンから開きます(出典: github.com)。
書いている手を止めずに 1 か所だけ直すならインラインチャット、調べながら考えるならチャットビューです。
全国8,000人調査で、AI活用方法によって生産性向上に約3.8倍の差が生まれることが判明。
4つのモードを選び分ける
チャットには目的別のモードがあり、どこまで任せるかが変わります(出典: github.com)。
| モード | できること | 向いている場面 |
|---|---|---|
| Ask | 質問に答える。コードは変更しない | 仕組みを知りたい、エラーの原因を絞りたい |
| Edit | 指定した複数ファイルへの編集を提案し、受け入れを都度判断できる | 変更する対象が自分で決まっている |
| Agent | 変更するファイルの選定から実行まで進め、承認を求めながら修復を繰り返す | 手順が読めない、複数ファイルにまたがる |
| Plan | 先に実装計画を作り、承認するまでコードを変更しない | 要件を固めてから着手したい |
迷ったときは Ask から入り、直す場所が見えたら Edit、手順ごと任せたくなったら Agent に上げます。Plan は、他の人と方針を合わせてから着手したい作業で効きます。
スラッシュコマンドと変数で入力を短くする
毎回同じ説明を書かずに済む仕組みもあります。VS Code では次のコマンドが使えます(出典: github.com)。
| 入力 | 何が起きるか |
|---|---|
| /explain | 選んでいるコードの動きを説明する |
| /fix | 選んでいるコードの問題に修正案を出す |
| /tests | 選んでいるコードの単体テストを生成する |
| /fixTestFailure | 落ちているテストを探して直す |
| /new | 新しいプロジェクトの雛形を作る |
渡す情報の指定には # から始まる変数を使います。#file で開いているファイルの中身、#selection で選択範囲、#function でカーソルのある関数、#project でプロジェクトの文脈が渡ります(出典: github.com)。@terminal や @vscode のように、ターミナルやエディタの文脈を呼び出す指定もあります。
GitHub Copilotの提案精度を上げる書き方|公式が挙げる4つの原則
提案の質は、渡している情報の量と質でかなり変わります。公式のプロンプトエンジニアリングの解説では、次の 4 つが中心に挙げられています(出典: github.com)。
原則1|目標から入って要件を並べる
最初に何を作りたいのかを 1 文で伝え、そのうえで満たしたい条件を並べます。いきなり細かい仕様から入るより、全体像を先に共有したほうが噛み合います。
「CSV を読み込んで集計する関数を作りたい」と伝えてから、「列名は指定できるようにする」「空行は無視する」と足していく順番です。
原則2|入力と出力の例を示す
言葉で説明しづらい要件は、例を出すほうが早く伝わります。入力データと期待する出力を並べて見せると、解釈のぶれが減ります。
すでに単体テストがあるなら、それ自体が例として機能します。テストを先に渡してから実装を頼む進め方も取れます。
原則3|大きな作業を小さく分ける
機能まるごとを一度に頼むと、返ってくる量が増えて確認が追いつかなくなります。処理の単位で区切って頼むと、直しも局所で済みます。
分けた結果として手戻りが減るため、結局は早く終わります。任せる範囲を広げるのは、精度の感触が掴めてからで構いません。
原則4|参照してほしいコードを開くか指定する
参照してほしい型定義や設定ファイルをタブで開いておくと、提案がプロジェクトの実態に寄ります。前の章で触れた #file や #selection で明示的に渡すこともできます。
あわせて、一貫した命名やコメント、処理の分割といった書き方の基礎が効きます。既存コードが整理されているほど、提案も既存の書き方に沿ったものになります。
GitHub Copilotの提案が出ない・的外れなときの対処
使い始めた直後は、思ったように動かない場面に必ず当たります。原因はいくつかの型に分かれるので、上から順に切り分けると早く復旧できます。
- 提案がまったく出ない:拡張機能が有効になっているか、サインインが完了しているかを確認します。手動で提案を出す Alt + \(Mac は Option + \)が効くかどうかも切り分けに使えます
- 提案が的外れになる:参照できる情報が足りていない可能性が高い状態です。関連ファイルを開く、コメントで意図を先に書く、
#fileで対象を指定する、のいずれかを足します - 途中で提案が止まる:無料プランには利用回数の上限があります。プランの利用枠に達していないかを確認します
- 日本語の指示が伝わらない:1 つの指示に複数の要求が入っていることが多い状態です。原則 3 のとおり、要求ごとに分けて渡し直します
どれも設定を大きく変える必要はなく、渡す情報か、頼み方を変えるだけで解消することがほとんどです。それでも改善しない場合は、対象の言語やフレームワークで学習に使われた公開コードが少ない可能性を疑うと、期待値の調整がしやすくなります。
GitHub Copilotの料金プランと無料で使える範囲
使い方が固まってきたら、どのプランで続けるかを決めます。料金は個人で契約するか組織で契約するかで体系が分かれます。以下は各プランの月額です(2026年8月時点、出典: github.com)。
| プラン | 対象 | 月額 | 位置づけ |
|---|---|---|---|
| Copilot Free | 個人 | 無料 | 機能とモデルが限定される試用向け |
| Copilot Student | 学生(認証が必要) | 無料 | コード補完が無制限。チャットは限定 |
| Copilot Pro | 個人 | 10 ドル | コード補完が無制限。モデルを選べる |
| Copilot Pro+ | 個人 | 39 ドル | 利用枠が増え、上位モデルが使える |
| Copilot Max | 個人 | 100 ドル | 個人向けで最大の利用枠 |
| Copilot Business | 組織 | 19 ドル/ユーザー | 集中管理とポリシー制御が可能になる |
| Copilot Enterprise | 大規模組織 | 39 ドル/ユーザー | 利用枠が広く、企業向け機能が加わる |
関連記事:GitHub Copilotの料金はいくら?プラン別の月額とクレジット消費を整理
無料で試せる範囲と、有料に移る目安
Copilot Free は、組織や企業を通じて Copilot を使えない個人開発者向けに用意されているプランです(出典: github.com)。機能とモデルが限定されるため、まず操作を確かめる用途に向きます。
コード補完が無制限になるのは Copilot Pro からで、上位プランほど選べるモデルと月次の利用枠が広がります(2026年8月時点、出典: github.com)。日常的にコードを書くのであれば、上限に当たった時点で Pro へ移る流れが分かりやすい進め方です。
個人契約と組織契約は体系が違う
組織向けの Copilot Business と Copilot Enterprise は、席(ユーザー)単位の課金です。管理者がポリシーをまとめて適用できるため、設定を利用者ごとの判断に委ねずに済みます。
個人で試した感触をチームに広げる段階では、契約形態が変わる点を先に押さえておくと、見積もりの話が噛み合います。料金と課金の細かい条件は、料金だけを扱った記事で整理しています。
全国8,000人調査で、AI活用方法によって生産性向上に約3.8倍の差が生まれることが判明。
GitHub Copilotを使うときの注意点
便利な一方で、使い始める前に知っておきたい制約もあります。とくに次の 3 点は、チームで使うほど効いてきます。
- 生成されたコードをそのまま採用しない:実在しないライブラリや関数を、もっともらしい形で提案してくることがあります。公開されているコードに似た実装が返ることもあるため、著作権の扱いが気になる処理ほど人の目で確認する前提で使います
- プロジェクト全体を理解しているわけではない:参照できるのは開いているファイルや周辺のコードなど限られた範囲です。既存の設計と噛み合わない実装が提案されることがあります
- セキュリティ要件は組織のポリシーで固める:非公開コードが学習に使われる範囲はプランによって異なり、組織向けプランでは管理者が一括で適用できます
テストコードについても同じ考え方が要ります。生成されたテストが通ることと、仕様どおりに動くことは別の話なので、テストの中身が仕様を反映しているかは人が判断します。
関連記事:Copilotに学習させない設定|製品別の手順とオフでも残るリスク
GiftXがAIコーディングツールの使い方をチームで揃えている方法
使い方が個人の中に閉じたままだと、同じ作業でも人によって結果が変わります。GiftX では、業務で使うプロンプトや定型フローを「スキル」として整備し、誰が実行しても同じ品質になる形で共有しています。
以前はプロンプトが個人のメモに散らばっていましたが、スキル集にまとめたことで全員が同じ手順を実行できるようになりました。改善のたびにスキルへ書き戻す運用にしているため、気づきが個人の中に留まらずチームの資産として積み上がります。結果として品質の個人差が解消され、新しいメンバーの立ち上がりも約 50% 短くなりました。使っているのは AIコーディングエージェントで、本記事で扱った補完やチャットの使い方も、この形で共有の対象にしています。
GitHub Copilotを使う前と後で実装作業はどう変わるか
実装作業がどう変わるかを、既存の処理に似た関数を新しく書き起こす場面で比べてみます。実務 3 年目の開発担当者が、機能追加のたびに繰り返している種類の作業です。
導入前は、似た処理を探して開き、書き方を確認しながら手で写して書き換えていました。使うライブラリの引数は都度ドキュメントで確認するため、1 関数あたり約 25 分、週 12 関数で週 300 分ほどかかります。
導入後は、参照したい既存ファイルを開いた状態でコメントに処理内容を 1 行書き、提案された実装を読んで直す形になります。1 関数あたり約 10 分、週 120 分ほどで収まり、作業時間を約 60% 削減できる計算です。空いた週 3 時間ぶんを設計とレビューに回せます。
GitHub Copilotの使い方チェックリスト
最後に、ここまでの内容を確認できる形にまとめます。導入直後に「思ったより提案が的外れだ」と感じたときは、上から順に当てはめてみてください。
- 拡張機能とサインインが完了しているか:手動で提案を出す操作が効くかどうかで切り分けられます
- 参照してほしいファイルを開いているか:型定義や設定ファイルを開いた状態にすると、提案がプロジェクトの実態に寄ります
- 意図をコメントか指示で先に書いているか:何を作りたいのかを 1 文で伝えてから、条件を並べます
- 1 回の指示に要求を詰め込みすぎていないか:処理の単位で区切って頼むと、確認も直しも局所で済みます
- 例を渡せる場面で渡しているか:入力と出力の組、または既存の単体テストが例として機能します
- モードを目的に合わせているか:質問なら Ask、対象が決まっているなら Edit、手順ごと任せるなら Agent を選びます
- 出てきたコードを確認する時間を見込んでいるか:確認の時間まで含めて、はじめて短縮になります
これらはどれも特別な準備を必要とせず、普段の書き方を少し変えるだけで効きます。一通り試しても提案が実務に届かない場合は、対象の領域が AI の得意な範囲から外れている可能性を疑います。
AIコーディングツールの導入で陥りがちな3つの落とし穴
ツールを配れば成果が出るとは限りません。GiftX が実施した「ビジネス職生成AI活用実態調査2026」では、エンジニア職が AI を使っている業務は次のように分かれていました。
| 使っている業務 | 回答した人の割合 |
|---|---|
| 社内資料の作成 | 39% |
| 技術調査 | 35% |
| コード生成 | 30% |
| テストコードの作成 | 28% |
| バグ調査 | 27% |
| コードレビュー | 18% |
コード生成が 30% にとどまり、レビューまで任せている人は 18% でした(複数回答のため合計は 100% を超えます)。同じ調査では、エンジニア職の AI 利用率は 7 職種で最も高い一方、AI に一連の作業を任せる段階に届いた割合は 5% で最下位でした。使ってはいるが任せきれていない構図です。
詳細な調査データは「ビジネス職生成AI活用実態調査(2026年版)」にてご覧ください。ここでは、GiftX がさまざまな現場を支援してきた経験から、特に多い 3 つの落とし穴を紹介します。
落とし穴1|いきなり全ての開発工程をAIに任せようとする
最初から設計もテストもレビューもまとめて任せようとすると、確認すべき箇所が増えすぎて手が止まります。まずは 1 つの作業に絞り、任せられる範囲を見極めるところから始めるのが近道です。
落とし穴2|壮大なAI活用戦略から考えて手が止まる
「全社でどう活用するか」という大きな構想から入ると、検討だけで時間が過ぎていきます。小さく試して手応えを掴んだ方が、結果として早く前に進みます。
落とし穴3|既製品のチャット型AIでは業務フローに組み込めない
汎用のチャット型 AI は手軽ですが、自社固有の手順に合わせた作り込みが難しく、現場で使い続けられる質に届かないことがあります。業務フローに組み込める形まで作れるかどうかが分かれ目になります。
スモールスタートで1業務をAIエージェントに任せる
これらを避けるコツは、スモールスタートに徹することです。まず 1 つの定型業務を選び、そこを AI エージェントに任せて効果を確かめてから、対象を少しずつ広げていきます。GitHub Copilot のような補完型のツールで手を速めつつ、任せきれる作業からエージェントに移していく進め方であれば、無理なく段階を上げられます。GiftX では、こうした 1 業務単位のスモールスタートからの構築・活用を伴走支援しています。詳細はAIエージェント構築支援サービスをご覧ください。
まとめ
GitHub Copilot の使い方は、コード補完・Copilot Chat・エージェントモードの 3 つに分かれます。導入は拡張機能をインストールしてサインインするまでで完了し、あとは受け入れと候補の切り替えのキー操作、チャットの 4 つのモード、スラッシュコマンドと変数の指定を押さえれば日常の作業は回ります。提案が的外れなときは設定を疑う前に、渡している情報と頼み方を見直すほうが早く解決します。料金は無料の Copilot Free から始められ、コード補完が無制限になるのは Copilot Pro からです。そして忘れたくないのは、ツールを配ることと成果が出ることは別だという点です。まず 1 つの作業を選んで任せ、効果を確かめてから対象を広げる進め方が、結果として早く前に進みます。
AIエージェント活用の伴走支援をご検討の方へ
本記事で紹介したような AI 活用を、自社の業務でも具体的に進めたい・相談したいとお考えの方は、ぜひ GiftX AIエージェント構築支援までお問い合わせください。
GiftX AIエージェント構築支援では、貴社の業務に合わせて 1 業務単位のスモールスタートから本番運用まで、AIエージェント構築をワンストップで支援します。ユースケースの洗い出しから、試験導入、本番運用、社内への定着まで伴走します。
AI活用にご関心のある方は、ぜひ一度ご相談ください。
▶ GiftX AIエージェント構築支援の詳細・お問い合わせはこちら