.jpg&w=96&q=75){kind=small}
本記事では、2025年8月7日に開催されたイベント「GitHub Copilotの全体像と活用のヒント AI駆動開発の最初の一歩」の内容をお届けします。イベントでは『Visual Studio Code 実践ガイド』の著者である、Atsushi Morimoto (@74th)氏が登壇。GitHub Copilotの基本から、AIと人間が協調する未来のコーディングスタイルまで、その活用術を詳しく解説いただきました。
また、イベント当日に回答しきれなかった質問についても、本記事にて回答いただいています。ぜひ本編のアーカイブ動画とあわせてご覧ください。
Morimoto氏は、AIコーディングの世界は日々変容しており、今回の内容は当日時点の最新情報であること、イベントではVisual Studio Code（VS Code）を例として挙げる点を前置きしつつ、GitHub Copilotの多岐にわたる機能を紹介しました。
GitHub Copilotを活用する、AI駆動開発の3つのスタイル
GitHub Copilotの活用術は、大きく3つのAI駆動開発スタイル（レベル）に分けられます。これらは優劣ではなく、「人間の関与率」と「AIの自立率」をもとに設定されており、それぞれの状況に応じた活用法として示されました。
レベル1 コーディングサポート
人間がコーディングの主体で、AIがサポートする「コーディング支援」 。このレベルでは、人間の集中力を途切れさせずにAIの支援を得ることがGitHub Copilotで最も意識されている点です。
コード補完
前後の文脈を読んで、続くコードを予測・補完し、Tabキーで確定できます。例えば、Pythonで日付を扱う関数を作成する際、コメントを書くだけで関数名を提案したり、型情報を加えることで次の定義を提案したりします。
また、プロパティの追加など人間が忘れがちな関連箇所の修正を提案する「Next Edit Suggestions」機能も便利です。構造化補完のコツは、メソッド名やコメントを説明的に記述すること、Pythonではメソッドのパラメーターに型ヒントを与えること、参照してほしいファイルを別タブで開いておくことなどが挙げられました。
VS Codeで使えるCopilot Chat
チャット欄からCopilotに直接質問できます。言語やフレームワークの質問、エラーメッセージの説明、ワークスペースのコードに関する質問（例：「このクラスの役割は？」）などが可能です。
タブやファイルツリーからドラッグ＆ドロップで参照ファイルを指定でき、エディタ上でコードを選択することでも参照可能。@xxxとつけることで「特殊な質問モード」に移行し、コードやプログラミング以外のことも質問できます。
チャットで指示 Chat Editモード
チャットの指示に基づいてコードを部分的に編集し、差分を確認しながら適用・元に戻すことができます。
「面倒なことはCopilotに任せよう」という感覚で使うのがおすすめです。例えば、JSONデータをGoの構造体に変換したり、既存のクラスに属性を追加し、その利用箇所もまとめて修正したりするような面倒な作業をCopilotに任せられます。
エラーの説明と解決
VS Codeで下線が引かれたエラーに対し、「Copilotで説明・修正」を実行すると、エラーの原因と修正案を提示し、そのまま適用できます。カンマの入れ忘れや改行コードの不一致といった、人間が見落としやすいミスも指摘してくれるため、まずはGitHub Copilotに聞いてみる進め方が有効です。
モデルとプレミアムリクエスト
GitHub Copilotは複数のLLMモデルをサポートしており、使用するモデルを選択できます。ベースモデル以外を使用するとプレミアムリクエストとしてクレジットを消費します。[1] [2]
クレジットの消費状況はVS Code画面右下のメニューにある「プレミアムリクエスト」から確認でき、上限に達すると定額内のベースモデルに切り替えるか、従量課金に移行します。
レベル2 並走エージェント（Vibe Coding）
AIが主体で人間が細かく指示する「並走エージェント」。AIが抽象的な指示から技術的課題をコーディングで解決し、人間が細かく指導・チェックして完成に近づけるスタイルです。
Copilot Chat ― Agentモード
Editモードよりも広範な能力を持ち、ワークスペース全体のコード検索、MCP（Model Context Protocol）サーバー連携による外部リソースの利用、ターミナルでのコマンド実行と結果の読み取りなど、VS Code上で人間ができることの多くをGitHub Copilotが行えます。
Editモードとの作業スコープの違いとして、Editモードが「今開いてる、指示したファイル」を参照するのに対して、Agentモードでは「ワークスペース全体」が参照されます。Editモードと意識的に使い分ける必要はなく、常にAgentモードで問題ありません。
MCPの活用
MCPはLLMから外部ツールやデータリソースを連結するプロトコルで、GitHub CopilotはMCPクライアントとして、GitHub Issue/PR操作、Webブラウザ操作、AWSリソース操作などのツールを利用できます。VS Codeでは拡張機能としてMCPサーバーが提供されインストールできるものもあります。利用可能なツールをCopilotのAgentモードで確認・選択します。
WebアプリのブラウザテストをPlaywrightで自動実行するデモでは、GitHub Copilotが外部ツールの使用前に必ず確認を求めることで、プロンプトインジェクション対策が施されていることが示されました。
エージェントの理解度
現状のAIエージェントは、ワークスペース全体を最初から把握しているわけではなく、ファイルツリーなどから推測して順にファイルを読み込みます。そのため、コード内のヒントが見つけやすい、作業しやすい状態にしておくことが重要です。
エージェントへの効果的な指示方法として、チャット欄の他、「共通ルール（インストラクションファイル）」や「再利用可能プロンプト（プロンプトファイル）」を活用することが推奨されました。
共通ルールにはコーディング規約やコードレビュー方針、外部環境情報などを記述し、現在のコードを解析して自動生成することも可能です。
再利用可能プロンプトは、テスト生成の方針などをまとめて /プロンプト名 で呼び出せる機能で、使用するモデルやMCPツールも指定できます。インストラクションファイルは分割すること、プロンプトではファイルパスやクラス名まで具体的に指示することなどが、より安定した結果を得るためのコツとして挙げられました。
Agentモードのセキュリティリスク
ターミナルでコマンドが実行されるため、ワークスペース外へファイルにアクセスしたり、秘匿情報の誤送信のリスクがあることが指摘されました。
対策として、GitHub Copilot側ではコマンドごとのユーザー確認や利用可能ツールの絞り込みがあり、ユーザー側は本番環境にアクセス可能な状態での不用意な実行を避け、コンテナなどのサンドボックス環境で試すことが推奨されます。
レベル3 独走エージェント（Agentic Coding）
AIが自分でタスク分解して問題解決に導く「自律エージェント」。 GitHub Copilotでは「コーディングエージェント」というサービスとして提供されています。
このレベルでは、Issueに@copilotをアサインするだけで、クラウド上で起動したCopilotがIssueの内容に基づいてコーディングし、プルリクエスト（PR）を作成します。開発者はPR上でのやり取りを通じて、実装と差分を確認し、うまくいけばマージへと進めます。
Copilotの作業ログは「View session」から確認でき、AIがどのようにファイルを読み、判断を下したかの時系列記録が残ります。タスク分割と順次実行をCopilotが行う、まさにコーディングエージェントの機能です。
その他の機能とGitHub Copilotの現在地
GitHub Copilotはここまでに挙がった機能のほかに、コードレビュー、テストや運用コマンドの生成、エディタ上での結果確認など、様々な機能を提供しています。
GitHub.com上でもPRに対して質問やレビューを要求でき、タイポや一般的なセキュリティリスクの指摘など、人間によるレビュー前の一次チェックとして非常に有用です。
Morimoto氏は、AIコーディングの世界が今も変わり続けており期待通りに動かないこともあるため、CursorやClaude Code、Geminiといった他のツールとの併用も視野に入れつつ、実際に使用して効果を測り、AIに任せる範囲を広げていくことの重要性を強調し、講演を締めくくりました。
Q&A
イベント当日、チャット欄に寄せられた質問
Q. CursorでもVS Codeと同様のことができますか？また、Claude CodeやCursorとの一番の違いは、GitHubのリポジトリを参照できることなのでしょうか？
A. Cursorを使い込んでいるわけではないですが、大体近いことはできると思います。機能は切磋琢磨していて、今使える/使えないは来月には変わる世界観です。GitHub Copilotだけが特別に強いのは「GitHubとの連携」が一番充実している点だと感じます。参照能力自体はMCPサーバーを与えれば他でも得られるので、そこだけが決定的に強いというわけではありません。
Q. MCPでツールの数が128個を超えるとエラーになります。回避策はありますか？
A. 確かに128個は少ないという声が多いです。基本は使うツールだけチェックして有効化する運用になります。プロンプトファイル側で「このプロンプトでは使うツールを列挙」して限定する方法や、ツールセット機能でひと括りにしてオン/オフする方法があります。状況に応じて使い分けるのが現状の回避策です。
（イベント後追記）8月のリリースで、128個を超えても自動で絞り込みを行ってくれる機能がリリースされました。
Q. プロキシ環境でMCPツールの一部がうまく動かない場合の対処法を教えてください。
A. そのツールがプロキシに対応しているかどうか次第のため、回答は難しいです。自分はプロキシ環境下ではあまり使っておらず、IPレベルのフィルタで対応しているケースが多いです。
Q. 型エラーチェックを入れていると、GitHub Copilotが出力するコードがほとんど黄色や赤の波線になって困っています。静的テスト対策はありますか？
A. 最近は賢くなって、編集箇所だけチェックすることもありますが、確かにそういうことはあります。VS Code側の一時的な無効化や、エラーは一旦無視して進め、余計な対策を始めたら止める、といった運用をしています。動いている流れを一旦止めて「そこはいいので続けて」と指示を上書きすることもよくあります。
Q. コーディングエージェントがメインブランチにしかPRを出してくれません。特定のブランチでPRしてほしいのですが可能ですか？
A. 今はデフォルトブランチにPRする仕様だと思います。リリースされたばかりの機能なので制限がある状態かもしれません。
Q. 他のVS Code拡張にも補完機能はありますが、GitHub Copilotとの違いは何でしょうか？
A. 一般的なコード補完は文脈から類推して候補を出しますが、GitHub Copilotは「次に何をしたいか」を踏まえた提案をしてくれます。次の単語だけでなく、パラメータ一式まで保管してくれるなど、広い単位での補完が得意です。逆に、厳密に作り込まれたクラスだけに頼ってほしいケースでは合わないこともあります。
Q. MCPのツール名が被って使えないことがあります。回避策はありますか？
A. 現状、ツール側が固有で短めの名前を提供してくれないと難しいです。MCPは選択肢から厳密一致で選ぶのではなく、与えられた情報から推測して名前を出すので、長い名前だとズバリ答えられないことがあります。今は決定的な回避策はなく、将来的なリネーム機能などに期待、という回答になります。
追加のご回答
イベント内で触れられなかった質問に回答いただきました
Q. 参考コードの提示はGitHub Copilotの機能由来ですか？もしくは選択したモデルの機能由来でしょうか？
A. ChatやAgentでは主に選択したモデル機能由来ですね。補完機能についてはGitHub Copilot用のモデルを利用しているようです。
Q. @githubコマンドについて質問です。公式ドキュメント[3]によるとGitHub固有のスキルを実行する（Web 検索、コード検索、エンタープライズのナレッジベースに基づいている回答を得る）と出てくるのですが、リポジトリの参照なのでしょうか？
A. GitHub.com上にある機能を使って回答してくれます。GitHub.com上でできるコード検索や、リポジトリの参照など、GitHub.comのUIで可能な機能の一部が提供されているイメージです。特定のリポジトリを指定した検索もできますし、GitHub.com全体のコード検索もできます。GitHub.com上でできることをイメージして指示してみると良いでしょう。
Q. コードは学習に使われることはありますか？
A. 契約の種類によります。個人では学習に使われることもあり、OrganizationのBusiness/Enterpriseプランでは学習されないと規約に書かれています。
Q. 拡張機能で導入したMCPサーバーはどこで起動されているのでしょうか？
A. 通常、MCPサーバーの利用には、「A. ローカルでプログラム起動する」ケースと、「B. 外部MCPサーバーにアクセスする」ケースがあります。 拡張機能からMCPサーバーを提供する方法には、以下の2種類があります。
拡張機能から通常のMCPサーバーと同様に設定を追加する方法
拡張機能がMCPツールとして振る舞う方法
1.の場合は、A.、B.それぞれで提供可能です。
2.の場合には、ローカルのVS Code内の拡張機能がMCPサーバーとして振る舞う形になります。
Q. 企業で使う場合、セキュリティ面はどのようにされていますか？
A. 企業それぞれのセキュリティポリシーに沿った運用が求められます。GitHub Copilotでは、Business/Enterpriseプランの場合、企業のポリシーに合うように機能を一つずつ有効・無効が切り替えられるようになっています。
LLMを利用する際のセキュリティリスクについては、OWASP Top Tenというサイトに代表的な10のリスクが優先度順に提示されています。こちらからセキュリティリスクを評価して、対策すると良いと思います。
主にGitHub Copilotで保証できないリスクとしては、悪意あるMCPサーバーを利用したことによるプロンプトインジェクションによる環境破壊・情報摂取や、LLMのもつ古い情報の参照による脆弱性の埋め込みなどがあります。利用するMCPサーバーを選定したり、実行環境を隔離したり、生成されたコードに脆弱性診断を実施するなど、セキュリティポリシーに合わせて実施すると良いでしょう。
Q. 次の4つのカスタムインストラクション間に優先順位はありますか？
（1）copilot-instructions.md／（2）prompt.md／（3）.vscode/settings.json／（4）カスタムチャットモード
A. 特にはないように思われます。LLMには、等しくコンテキストとして渡されるだけのようです。
Q. Markdown形式の詳細設計書を読み込ませる場合、ファイルサイズの上限はどの程度でしょうか。
A. 私の個人的な肌感でしかないのですが、現状は最大500行程度と思っています。読み込めたとしても情報が多いと忘れ去られるので、200行程度の情報であるのが適切だと思っています。
Q. GitHub Copilotのコードレビュー機能でも、インストラクションファイルは適用できますか。
A. 現状では、リポジトリ内のAgentで使うインストラクションファイルは参照していないようです。VS Code上のレビュー機能のインストラクションファイルはVS Codeの設定上に記述できます。GitHub.com上のレビュー機能にもリポジトリのインストラクションを設定できますが、Enterpriseプラン専用の機能となっています。
Q. AI駆動開発における、品質管理で活用できる代表的なAIツールがあれば教えてください。
A. すみません、AIツールという意味では把握しておりません。基本的に、人のコーディングで利用してきたコードリンターや脆弱パッケージ診断等のツールは、そのままAI駆動開発でも有用であると思っております。私自身も新しいツールの導入はしていませんでした。
アーカイブ動画
イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。
▼動画・資料はこちら
※動画の視聴にはFindyへのログインが必要です。