GitHub Copilot の仕組みとデータフロー
プロンプトを入力してから、提案が画面に表示されるまでの間に、GitHub Copilot の内部では何が起きているのでしょうか。このページでは、その処理の流れと、データの扱い、提案を作り出す AI（LLM）の仕組みを整理します。
この記事で分かること
- プロンプトが処理される流れ（インバウンドフローとアウトバウンドフロー）
- 途中で働く 2 つのフィルター（プロキシと、有害性フィルタリング）
- 提案を返す前に行われるチェック
- コード補完と Copilot Chat での、データの扱いの違い
- コンテキストウィンドウの制限と、その対処
- LLM とは何か。微調整と LoRA
試験範囲では、「GitHub Copilot のデータとアーキテクチャを理解する」（比重 10〜15%）の分野にあたります。
数値や名称について
このページの元になっている公式の教材は、2024 年に書かれたものです。そのため、現在の公式情報と食い違う部分があります。
- 「データの扱い」の節は、2026 年 10 月に、GitHub の最新の公式情報で確認し直しました。教材の説明と、現在の公式情報の両方を載せています。
- 公開されているコードとの一致の基準は、現在の公式ドキュメントの説明を書き添えています。
- コンテキストウィンドウの大きさは、教材の説明のままです。最新の公式情報では確認していません。
用語の整理
| 用語 | 意味 |
|---|---|
| インバウンドフロー（inbound flow） | 利用者のプロンプトが、Copilot の側へ送られて、処理されるまでの流れ |
| アウトバウンドフロー（outbound flow） | 生成された提案が、チェックを経て、利用者に届くまでの流れ |
| コンテキスト（context） | 提案を作るときに参考にされる、周囲の情報 |
| プロキシサーバー（proxy server） | 利用者と AI モデルの間に立って、通信を中継する仕組み。ここで通信の検査が行われる |
| LLM（Large Language Model：大規模言語モデル） | 大量の文章で学習し、人の言葉を理解・生成できる AI モデル |
| トークン（token） | LLM が文章を扱うときの、細かく区切った単位 |
| コンテキストウィンドウ（context window） | モデルが一度に処理できる、周囲のコードや文章の量 |
| 微調整（fine-tuning：ファインチューニング） | 学習済みのモデルを、特定の作業や分野に合わせて、追加で学習させること |
全体の流れ
Copilot の処理は、プロンプトを受け取るインバウンドフローと、提案を返すアウトバウンドフローに分けられます。全部で 7 つの段階があります。
【インバウンドフロー】プロンプトが Copilot の側へ送られる
1. 安全なプロンプト送信と、コンテキストの収集
↓
2. プロキシフィルター
↓
3. 有害性フィルタリング
↓
4. LLM によるコード生成
【アウトバウンドフロー】提案が利用者に返される
5. 後処理と、応答の検証
↓
6. 提案の提示と、フィードバックループの開始
↓
7. 後続のプロンプトに対して繰り返すインバウンドフロー
1. 安全なプロンプト送信と、コンテキストの収集
処理は、プロンプトを HTTPS（通信の内容を暗号化する方式）で安全に送信するところから始まります。プロンプトには、Copilot Chat への入力と、コードの中に書いた自然な言葉のコメントの、両方が含まれます。
同時に、Copilot は次のコンテキストを集めます。
| 集める情報 | 目的 |
|---|---|
| カーソルの位置の前後のコード | プロンプトのすぐ近くの状況を理解する |
| 編集しているファイルの名前と種類 | ファイルの種類に合った提案にする |
| 隣接する、開いているタブの情報 | 同じプロジェクトのほかのコードと、整合する提案にする |
| プロジェクトの構造と、ファイルのパス | — |
| プログラミング言語と、フレームワーク | — |
集めた情報は、Fill-in-the-Middle（FIM） という手法で前処理されます。これは、カーソルより前のコードだけでなく、後ろのコードも考慮に入れる手法です。より広いコンテキストを使えるので、正確で、状況に合った提案を作れます。
この段階で、利用者の大まかな依頼が、具体的なコーディングの作業に置き換えられます。
2. プロキシフィルター
コンテキストが集められ、プロンプトが組み立てられると、プロキシサーバーに安全に渡されます。このプロキシサーバーは、GitHub が所有する Microsoft Azure の環境で動いています。
プロキシは通信を検査して、次のような試みを阻止します。
- プロンプトを乗っ取ろうとする試み
- モデルがどのように提案を生成しているのかを、聞き出そうとしてシステムを操る試み
3. 有害性フィルタリング
意図の読み取りとコードの生成に進む前に、内容のフィルタリングが行われます。生成されるコードや応答に、次のものが含まれないようにするためです。
| 対象 | 内容 |
|---|---|
| ヘイトスピーチと不適切な内容 | 憎悪をあおる表現、攻撃的な言葉など、害を与えたり不快にさせたりする内容を検出して、取り込まないようにする |
| 個人データ | 名前、住所、識別番号などの個人データを、積極的に取り除く。利用者のプライバシーと、データの安全を守るため |
4. LLM によるコード生成
フィルターを通り、分析されたプロンプトが、LLM に渡されます。LLM は、プロンプトと周囲のコンテキストをもとに、適切なコードの提案を生成します。
アウトバウンドフロー
5. 後処理と、応答の検証
モデルが応答を生成すると、まず有害性フィルターが、有害な内容や不快な内容を取り除きます。そのあと、プロキシサーバーが最終的なチェックを行います。
| チェック | 内容 |
|---|---|
| コードの品質 | よくある不具合や脆弱性が含まれていないかを調べる。例として、クロスサイトスクリプティング（XSS）と SQL インジェクションが挙げられている |
| 公開されているコードとの一致（任意） | 管理者が有効にできるフィルター。約 150 文字を超える提案が、GitHub で公開されている既存のコードによく似ている場合に、その提案を返さないようにする |
公開されているコードとの一致のフィルターは、偶然一致したコードが、新しく作られたものとして提案されるのを防ぐためのものです。
「約 150 文字を超える提案」という説明は、教材（2024 年）のものです。現在の公式ドキュメントでは、Copilot は、提案と、その前後の約 150 文字のコードを、GitHub で公開されているコードと照合する、と説明されています。設定のしかたは、「GitHub Copilot のプライバシーとデータ保護」で扱っています。
チェックに通らなかった部分は、切り詰められるか、破棄されます。
6. 提案の提示と、フィードバックループの開始
すべてのフィルターを通過した応答だけが、利用者に届けられます。
そのあと、利用者の行動をもとにしたフィードバックループが始まります。
- 受け入れられた提案から、知識を増やす
- 提案が修正されたり、拒否されたりしたことから学び、改善する
7. 後続のプロンプトに対して繰り返す
利用者が新しいプロンプトを入力するたびに、この流れが繰り返されます。Copilot は、積み重なったフィードバックとやり取りのデータを活かして、利用者の意図の理解と、コードの生成の精度を高めていきます。
フィルターとチェックのまとめ
どの段階で、何が、何を確認しているのかを整理します。
| 段階 | 流れ | 働くもの | 確認する内容 |
|---|---|---|---|
| 2 | インバウンド | プロキシ | プロンプトの乗っ取りや、モデルの仕組みを聞き出そうとする操作 |
| 3 | インバウンド | 有害性フィルタリング | ヘイトスピーチや不適切な内容、個人データ |
| 5 | アウトバウンド | 有害性フィルター | 生成された応答に含まれる、有害な内容や不快な内容 |
| 5 | アウトバウンド | プロキシ | コードの品質（不具合や脆弱性）、公開されているコードとの一致（任意） |
入力の側と出力の側の両方で、フィルターが働く点が要点です。
データの扱い
データの扱いは、どこで Copilot を使うかと、契約しているプランによって違います。この節では、まず公式の教材（2024 年）の説明を紹介し、そのあとで、現在の公式情報を整理します。試験は教材の内容をもとに出題される可能性があるので、両方を知っておくと安心です。
公式の教材での説明（2024 年）
コード補完
- コードエディターの中の Copilot は、提案を作るために使ったプロンプト（コードや、そのほかのコンテキスト）を、基盤となるモデルの学習のために保持しない
- 提案を返したら、プロンプトを破棄する
- 個人向けのプラン（教材では「GitHub Copilot Individual」）の利用者は、プロンプトを GitHub と共有しないように設定できる。設定しない場合、プロンプトは GitHub の基盤となるモデルの微調整に使われる
Copilot Chat
Copilot Chat は、会話の形でやり取りをする機能です。コード補完とは違う処理として、次の 3 つが挙げられています。
| 処理 | 内容 |
|---|---|
| 書式の整形 | 生成した応答を、チャットの画面で見やすいように整える。コードの部分を強調して表示し、自分のコードに直接取り込むための操作を付けることもある |
| 利用者とのやり取り | 続けて質問したり、説明を求めたり、情報を追加したりできる。チャットは会話の履歴を保持していて、あとのやり取りで文脈を理解するために使う |
| データの保持 | コードエディターの外で使う Copilot Chat では、GitHub は通常、プロンプト、提案、関連するコンテキストを 28 日間保持する。コードエディターの中の Copilot Chat については、保持の扱いが異なる場合がある |
教材では、コードエディターの外で使う場合の扱いは、CLI（コマンドで操作する画面）、モバイル、GitHub.com 上の Copilot Chat にも当てはまる、とされています。このうち CLI の扱いは、現在の公式情報とは違っています（後述）。
現在の公式情報（2026 年 10 月に確認）
GitHub は、Copilot のデータの扱いを、Trust Center（GitHub がデータの扱いを説明しているページ）と、公式ドキュメントで公開しています。
GitHub が保持する期間
企業向けのプラン（Business、Enterprise）の、既定の扱いです。保持される対象は、入力（プロンプト）と出力（Copilot の応答）です。
| 使い方 | 入力と出力の保持 |
|---|---|
| IDE（コードエディター）の中での、チャットとコード補完。Copilot CLI | 既定では保持しない |
| それ以外の使い方（GitHub.com 上のチャットなど） | 既定で、最大 28 日間 |
どちらの場合も、次の例外があります。利用規約や利用上のルールへの違反が確認されて、その調査に必要な場合、または、サービスの安全と健全性を守るために必要な場合には、GitHub は入力と出力を、限られた期間保持することがあります。この保持は、対象を絞り、期間を限って行う、とされています。
入力と出力のほかに、次のデータも保持されます。
| データの種類 | 内容 | 保持期間 |
|---|---|---|
| 利用状況のデータ（user engagement data） | 提案を受け入れたか、拒否したか、といった操作の記録 | 2 年間 |
| フィードバックのデータ（feedback data） | 利用者が送った評価や意見 | 目的のために必要な期間 |
| コーディングエージェントの作業の記録 | 作業を任せると GitHub の側で自律的に進める機能の、作業の記録 | アカウントが存在する間 |
GitHub.com 上のチャットの履歴
GitHub.com 上の Copilot Chat について、公式ドキュメントでは、次のように説明されています。
| 項目 | 内容 |
|---|---|
| 保存される会話の数 | 最近の会話を、最大 100 件まで |
| メッセージの保存期間 | 会話の中の各メッセージを、28 日間 |
| 28 日が過ぎると | メッセージは完全に削除される |
| メッセージがなくなった会話 | 履歴から、自動的に取り除かれる |
保持する理由は、機能を動かすためです。Copilot Chat は、前のやり取りを踏まえて答えます。そのためには、これまでの会話が保存されている必要があります。
保存期間を延ばす設定は、公式ドキュメントには書かれていませんでした。残しておきたい内容は、28 日が過ぎる前に、自分でファイルなどに保存しておく必要があります。
画面に見えている履歴は、どこにあるのか
「GitHub が保持するデータ」と、「自分の画面に見えている、過去の会話の履歴」は、使う場所によって、同じものの場合と、別のものの場合があります。
| GitHub.com 上のチャット、モバイルアプリ | VS Code などの IDE の中のチャット | |
|---|---|---|
| 履歴が保存される場所 | GitHub のサーバー | 自分の PC の中 |
| GitHub による保持 | 最大 28 日間 | 既定では保持しない |
| 28 日が過ぎると | 完全に削除される。画面の履歴からも消える | 28 日の期限は関係しない。PC の中に残る |
| ほかの PC から見られるか | 見られる | 見られない |
1 つの会話が 2 か所に保存されるわけではありません。どこで使ったかによって、保存される場所が決まります。
VS Code の拡張機能の GitHub Copilot は、右の列にあたります。VS Code で過去の会話を見られるのは、VS Code が自分で PC の中に記録しているためです。
なお、「保持しない」というのは、処理が終わったあとに保存しない、という意味です。VS Code で会話を続けるとき、これまでのやり取りは、その都度 Copilot に送られて、応答を作るために処理されます。
この項目の根拠について
VS Code の履歴が PC の中に保存されることは、公式ドキュメントでは確認できていません。GitHub の利用者向けの掲示板と、VS Code の不具合の報告の内容にもとづいています。保存の形式は VS Code の内部の仕様で、バージョンによって変わる可能性があります。
保持されたデータの使われ方
GitHub が Copilot のデータを使う目的として、Trust Center では、次のものが挙げられています。
| 目的 | 内容 |
|---|---|
| サービスの提供と維持 | 利用者の設定や使い方に合わせて、サービスを提供し、維持し、更新する |
| 問題への対処 | 不具合や、セキュリティ上の問題を、防ぎ、見つけ、解決する |
| 品質の向上 | サービスの信頼性、品質、プライバシー、安全性などを高める |
| 不正利用の検出と防止 | 利用規約に違反する使い方を見つけ、防ぐ |
| 法的な義務への対応、料金とアカウントの管理 | 法律で求められる対応や、請求を行う |
AI モデルの学習に使われるかどうかは、プランによって違います。
| プラン | AI モデルの学習への利用 |
|---|---|
| 個人向け（Free、Pro、Pro+、Max） | 入力、出力、やり取りの中で生成されたコードが、AI モデルの学習と改善に使われることがある。設定で、使われないようにできる。 使われないようにしても、Copilot の機能はそのまま使える |
| 企業向け（Business、Enterprise） | 使われない。 利用者のデータは、データ保護契約（DPA：Data Protection Agreement）の対象で、利用者の許可なく学習に使うことは禁じられている |
組織のコードを扱うときは、使っているのが、組織が契約した企業向けのプランなのか、個人のプランなのかを確認しておくと安心です。
教材と、現在の公式情報の違い
| 項目 | 教材（2024 年） | 現在の公式情報 |
|---|---|---|
| Copilot CLI の入力と出力 | コードエディターの外で使う場合と同じく、28 日間保持される | IDE の中での利用と同じ扱いで、既定では保持しない |
| 個人向けのプランの名前 | GitHub Copilot Individual | Free、Pro、Pro+、Max。まとめて「Individual」と呼ばれる |
| 個人向けのプランでの、学習への利用 | 共有しない設定にしなければ、プロンプトがモデルの微調整に使われる | 入力や出力が、学習と改善に使われることがある。設定で止められる |
Copilot Chat が扱えるプロンプトの種類
| 種類 | 内容 | 例 |
|---|---|---|
| 直接の質問 | コーディングの考え方、ライブラリ、問題の解決について、具体的に質問する | 「Python でクイックソートを実装するには、どうすればよいか」 |
| コードに関する依頼 | コードの生成、修正、説明を依頼する | 「階乗を計算する関数を書いて」「このコードを説明して」 |
| 自由な形の質問 | 考え方を調べたり、一般的な助言を求めたりする | 「読みやすいコードを書くためのベストプラクティスは何か」 |
| コンテキストを添えたプロンプト | コードの一部を示したり、状況を説明したりして、それに合った支援を求める | 「これが私のコードの一部です。改善点を提案してください」 |
コンテキストウィンドウの制限
コンテキストウィンドウとは、提案を生成するために、モデルが一度に処理できる、周囲のコードや文章の量のことです。この量には上限があります。
公式の教材では、次のように説明されています。
| 対象 | コンテキストウィンドウの大きさ |
|---|---|
| GitHub Copilot（コード補完） | 通常、約 200〜500 行のコード、または数千トークンまで |
| Copilot Chat | 4,000 トークン（4k トークン） |
この大きさは、使っている Copilot の実装やバージョンによって変わる、とされています。
制限への対処
上限を超える情報は、モデルが一度に扱えません。プロンプトを作るときは、次の工夫が有効です。
- 込み入った問題を、小さく、焦点を絞った質問に分ける
- 関連するコードの一部を示す
「プロンプトエンジニアリングの基本」で扱った、単一（Single）や短くする（Short）の原則は、この制限への対処にもなっています。
LLM とは
LLM（大規模言語モデル） は、人の言葉を理解し、生成し、操作するように設計され、学習された AI モデルです。GitHub Copilot は、LLM を使って動いています。
LLM の特徴として、4 つの面が挙げられています。
| 面 | 内容 |
|---|---|
| 学習データの量 | さまざまな出どころの、膨大な量の文章で学習している。そのため、言葉、文脈、表現の細かな違いを、幅広く理解できる |
| コンテキストの理解 | 文脈に合った、一貫性のある文章を生成できる。文の続き、段落、文書全体まで生成できる |
| 機械学習と AI の統合 | 機械学習と人工知能の考え方に基づいている。数百万から数十億ものパラメーター（学習によって調整される数値）を持つ、ニューラルネットワークである |
| 汎用性 | 特定の種類の文章や言語に限られない。特定の作業に合わせて調整でき、さまざまな分野や言語に使える |
Copilot での LLM の役割
Copilot は、LLM を使って、コンテキストを踏まえたコードの提案を行います。LLM は、現在のファイルだけでなく、IDE（統合開発環境：コードを書くためのソフトウェア）で開いているほかのファイルやタブも考慮に入れます。
微調整と LoRA
微調整（ファインチューニング）
微調整は、学習済みの LLM を、特定の作業や分野に合わせて調整する手続きです。大きなデータで学習済みのモデルが持っている知識とパラメーターを活かしながら、その作業に特化した、より小さなデータでモデルを追加学習させます。
| 言葉 | 意味 |
|---|---|
| ソースモデル（source model） | 大きなデータで、あらかじめ学習されたモデル |
| ターゲットデータセット（target dataset） | 特定の作業に特化した、より小さなデータ |
LoRA による微調整
従来の、完全な微調整は、ニューラルネットワークのすべての部分を学習させます。そのため、時間がかかり、多くの計算資源が必要になります。
LoRA（Low-Rank Adaptation：低ランク適応） は、これに代わる方法です。すべての学習をやり直さずに、学習済みの LLM を、特定の作業でうまく働くようにします。GitHub は、この方法を使っています。
| 項目 | 内容 |
|---|---|
| 仕組み | すべてを変える代わりに、学習済みのモデルの各層に、小さな学習可能な部品を追加する |
| 元のモデル | 変わらない。そのため、時間と資源を節約できる |
| ほかの方法との比較 | アダプター（adapters）や、プレフィックスチューニング（prefix-tuning）といった、ほかの適応の方法よりも優れている、とされている |
| 完全な微調整 | LoRA | |
|---|---|---|
| 学習させる範囲 | ニューラルネットワークのすべての部分 | 各層に追加した、小さな部品だけ |
| 元のモデル | 変わる | 変わらない |
| 時間と資源 | 多く必要 | 節約できる |
訳語の違いに注意
日本語版の教材は機械翻訳です。英語とセットで覚えておくと安心です。
| 英語 | 日本語版の教材での表記 |
|---|---|
| Inbound flow / Outbound flow | インバウンド フロー / アウトバウンド フロー |
| Proxy filter | プロキシ フィルター |
| Toxicity filtering | 有害性フィルタリング |
| Post-processing and response validation | 後処理と応答の検証 |
| Matching public code | 一般公開されているコードとの一致 |
| Feedback loop | フィードバック ループ |
| Context window | コンテキスト ウィンドウ |
| Fine-tuning | 微調整。「ファインチューニング」とも表記される |
| LoRA（Low-Rank Adaptation） | LoRA（低ランク適応） |
| Foundational model | 基本モデル。一般には「基盤モデル」とも呼ばれる |
| Data retention | データ保有期間 |
まとめ
- Copilot の処理は、インバウンドフロー（送信とコンテキストの収集 → プロキシフィルター → 有害性フィルタリング → LLM による生成）と、アウトバウンドフロー（後処理と検証 → 提示とフィードバックループ → 繰り返し）に分けられる。
- フィルターは、入力の側と出力の側の両方で働く。すべてのフィルターを通過した応答だけが、利用者に届く。
- 公開されているコードとの一致のフィルターは、管理者が任意で有効にする。約 150 文字を超える提案が対象である。
- GitHub による入力と出力の保持は、使い方で違う。IDE の中での利用は既定では保持されず、GitHub.com 上のチャットなどは最大 28 日間保持されて、そのあと完全に削除される。
- 学習への利用は、プランで違う。個人向けのプランでは使われることがあり、設定で止められる。企業向けのプランでは使われない。
- コンテキストウィンドウには上限がある。問題を小さく分け、関連するコードを示す。
- LoRA は、学習済みのモデルの各層に小さな部品を追加する微調整の方法で、元のモデルは変えない。
確認問題
このページの内容から作った、自作の問題です。実際の試験問題ではありません。選択肢を選んで「答えを確認する」を押すと、正解と解説が表示されます。
参考資料と確認の記録
- Introduction to prompt engineering with GitHub Copilot（Microsoft Learn）
- GitHub Copilot を使用したプロンプト エンジニアリングの概要（Microsoft Learn・日本語版）
- Study guide for Exam GH-300: GitHub Copilot（Microsoft Learn）
- GitHub Copilot Trust Center の FAQ
- Asking GitHub Copilot questions in GitHub（GitHub Docs）
| 項目 | 内容 |
|---|---|
| 最終確認日 | 2026 年 10 月 11 日 |
| 検証の状況 | 公式の教材（英語版と日本語版）の 3 つの単元（プロンプトの処理の流れ、データ、LLM）と照合した。「データの扱い」の節の「現在の公式情報」は、GitHub の Trust Center と公式ドキュメントで確認した。確認問題と、整理のための表は、このサイトで作成したもの |
| 公式の情報で確認できていない内容 | VS Code のチャットの履歴が PC の中に保存されること（利用者向けの掲示板などの情報にもとづく）。個人向けのプランでの、入力と出力の保持期間（Trust Center の説明は、企業向けのプランについてのもの） |
| 変わる可能性がある内容 | コンテキストウィンドウの大きさ（200〜500 行、4,000 トークン）は、2024 年の教材の説明で、最新の公式情報では確認していない。保持期間やプランの名前も、今後変わることがある |
| 更新の記録 | 2026 年 10 月 11 日：「データの扱い」の節を、現在の公式情報をもとに書き直した。確認問題の問 7 を作り直し、問 9 と問 10 を追加した。公開されているコードとの一致の基準について、現在の公式ドキュメントの説明を書き添えた |
| このページで扱っていない内容 | プライバシーの設定と、コンテンツの除外は、別のページ（13）で扱っている |