GitHub Copilot Spacesとは？

GitHub Copilot Spacesとは、Copilot Chatが回答するために使う「コンテキスト」を、タスク単位で整理・集約できる機能です。
スペースには、リポジトリ、pull request、Issue、自由形式テキスト、画像、ローカルからアップロードしたファイルなど、タスクに必要な情報ソースを追加できます。

スペース内のチャットで質問すると、GitHub Copilotは当該スペースに追加された情報を踏まえて回答を生成します。
また、スペースは共有にも対応しており、オンボーディングやナレッジ共有の起点として活用しやすい点も特徴です。

GitHub Copilot Spaceのイメージ (参考:GitHubブログ)

GitHub Copilot Spacesの主な特徴

GitHub Copilot Spacesは、単なる“メモ置き場”ではなく、Copilot Chatに渡すコンテキストを整理し、タスクごとに再利用するためのハブとして機能します。ここでは、日々の開発で効く主な特徴を5つに整理します。

Instructions と Sources でコンテキストを整理

スペースには「Instructions（指示）」と「Sources（ソース）」の2種類のコンテキストを追加できます。

• Instructions：そのスペース全体で守ってほしい前提やトーンを定義
  例）利用する言語やフレームワーク、コーディング規約、レビュー方針、「この観点は必ずチェックする」といったルール
• Sources：リポジトリやPR、Issue、仕様書、設計メモなど、回答の根拠となる一次情報

「どう答えてほしいか（Instructions）」と「何を根拠に答えてほしいか（Sources）」を分けて設計することで、レビューコメントや設計案のブレを減らしやすくなります。

GitHub上の変更を自動で反映

GitHub上のファイルやリポジトリをSourcesに追加した場合、その後のコミットによる変更は自動的にスペースにも反映されます。プロジェクトが進むたびに同じ資料を再アップロードする必要はありません。

一方、ローカルからアップロードしたドキュメントやスプレッドシートは、その時点のスナップショットとして扱われます。仕様変更や運用ルールの改定があった場合は、古いファイルを削除し、新しい版をアップロードする運用が必要です。

「どこまでをスペースに含め、どこから先はリンクだけにするか」といった線引きを決めておくと、スペース全体の鮮度を保ちやすくなります。

スペース単位で会話と検討ログを保存

スペースには「Conversations」タブがあり、そのスペースで行ったやり取りがまとまって残ります。

• 特定の機能開発や障害対応に関する質問と回答を、後からまとめて振り返れる
• 「なぜこの設計にしたのか」といった検討プロセスを残し、後続メンバーのキャッチアップに使える

といった形で、チャット履歴自体をナレッジとして再利用できます。さらに、スペースごとに利用するLLM（モデル）を切り替えられるため、「調査は高性能モデル」「軽い相談は軽量モデル」といった使い分けもしやすくなっています。

共有してチームの共通前提にできる

スペースは、個人所有・組織所有のどちらの形でも作成でき、いずれの場合も共有が可能です。

• 組織所有のスペース：組織内メンバーに対して、管理者／編集者／閲覧者などの権限を付与できる
• 個人所有のスペース：特定ユーザーとの共有に加え、パブリック公開（閲覧専用）も選択できる

ただし、共有先が実際に参照できるソースは、そのユーザーがGitHub上でアクセス権を持つものに限られます。機密度の高い資料は、リポジトリ側のアクセス権や組織ポリシーと合わせて設計することが重要です。

スペース共有でチームの共通前提を揃える

Copilot Spacesのコンテキストは、GitHub MCP server を通じてIDE（例：VS CodeのCopilot agent mode）からも利用できます。

その際はいくつか制約があります。

• リポジトリだけを含むスペースは、MCP経由ではIDEから参照できない
  → ファイルやIssue、ドキュメントなどの追加ソースを含める必要がある
• IDE側にはリポジトリコンテキストの制約があるため、「どのファイルをスペースに直で追加するか」「どこまでをリポジトリ全体に任せるか」を事前に決めておく必要がある

「ブラウザでスペースを整え、IDEからその文脈を呼び出して開発する」という一連の流れを決めておくと、開発者ごとに使い方がバラつきにくくなります。

GitHub Copilot Spacesの料金・利用条件

GitHub Copilot Spacesは、追加アドオンではなく、Copilot Free / Pro / Pro+ / Business / Enterprise のいずれのプランにも共通で含まれる機能です。

つまり、いずれかのCopilotライセンスを持っていればSpaces自体に別料金は発生せず、費用は各プランの料金とプレミアムリクエストの仕組みに従って決まります（Spacesでのチャットもプレミアムリクエストの対象です）。

代表的なプランごとの料金と、プレミアムリクエストの目安は次のとおりです。法人向けのプランはGitHub Copilot BusinessとGitHub Copilot Enterpriseになります。

プレミアムリクエストとSpacesの関係

GitHub Copilotのチャットやエージェントの利用回数は、（Spacesでのチャットを含めて）「プレミアムリクエスト（premium requests）」という枠で管理されています。

ここでは、このプレミアムリクエストの仕組みと、Free／有料プランそれぞれでの扱いを整理します。

• Freeプラン
• • ・月 50 回分のプレミアムリクエストが付与される
  • ・すべてのチャット利用（Spaces 含む）がプレミアムリクエストとしてカウントされる
  • ・50 回を使い切ると、その月はチャット機能（Spaces での質問も含む）は利用できない
  • ・プレミアムリクエストの追加購入は不可
• 有料プラン（Pro / Pro+ / Business / Enterprise）
• • ・GPT-5 mini / GPT-4.1 / GPT-4o などのプレミアムリクエストを消費しないモデルも存在

　　　　　 ・最新モデル などの高性能モデルを使ったチャットでは「1 プロンプト × モデルごとの倍率」 でプレミアムリクエストを消費する

• • ・プレミアムリクエストは月ごとにリセットされる（翌月への持ち越しなし）
  • ・足りなくなった場合は、管理者が設定した予算の範囲で $0.04 / 回 で追加利用できる

GitHub Copilot Spacesの利用手順

ここからは、実際にSpacesを作って使う流れをステップ形式で整理します。

1. スペースを作成する

1. Copilot Spacesの一覧（https://github.com/copilot/spaces）へ移動し、「Create space」をクリックします。
   
2. スペース名を付け、Ownerを選択します。
   
3. 「Create space」をクリックします。
   

2. Instructions（指示）を入れる

Instructionsには「このスペースでCopilotに何をしてほしいか／何を避けるか」を書きます。
役割や重視点、避けたい観点などを具体化すると、意図に沿った回答になりやすくなります。

3. Sources（ソース）を追加する

Sources は、質問に対してより関連性の高い回答を得るための参照情報（コンテキスト）です。代表例は次のとおりです。

• GitHub上のファイル/フォルダ/リポジトリを追加
• pull request / Issue のURLを貼る
• ローカルのファイルをアップロード（画像、テキスト、ドキュメント、スプレッドシート等）
• 自由形式テキスト（議事録、メモ、仕様の抜粋など）を貼る

「まずは重要ファイルに絞って追加する」ほうが、狙いどおりの回答を得やすい傾向があります。

4. スペース内で質問する

コンテキストを入れたら、スペースのチャットで質問します。
会話は「Conversations」タブで確認でき、必要に応じてモデル切り替えもできます。

5. （必要なら）共有してチームの入口にする

スペースを共有することで、共通の前提（設計・規約・運用）に基づいたやり取りをしやすくなり、オンボーディングやナレッジ共有の効率化に寄与します。
共有範囲や権限設計については、運用ルールを事前に定めておくことを推奨します。

GitHub Copilot Spacesの使い方のコツ

GitHub Copilot Spacesは、“何でも入れれば自動的に賢くなる”タイプのツールではなく、どのコンテキストをどの粒度で入れるかによって精度が変わります。実務で効きやすいコツを整理します。

1. コンテキストは目的に応じて“選び抜く”

スペースに追加する情報は、タスクとの関連度を基準に厳選します。関連度が低いファイルやドキュメントを大量に入れると、Copilotが拾う文脈が散らばり、回答のピントがぼけやすくなります。

• まずは「このタスクで本当に参照してほしい資料」を数点に絞る
• 慣れてきたら、回答の質を見ながら少しずつソースを足していく

といった“足し算”型の運用の方が安定しやすいです。

2. コンテキストは“更新し続ける”

一度作ったスペースも、プロジェクトの進行に合わせて中身を更新する必要があります。古い仕様書や既にクローズした設計案だけが残っていると、Copilotが過去の前提で回答してしまいます。

• 仕様や設計が大きく変わったタイミングで、関連するスペースを見直す
• 「誰がどのスペースをメンテするか」をオーナー単位で決めておく

このあたりの役割分担やルールを決めておくと、スペースの鮮度を保ちやすくなります。

3. Instructions と Sources をセットで設計する

Sourcesだけを追加すると、「どの観点を優先すべきか」が曖昧になりがちです。Instructionsで意図を明示し、Sourcesで根拠を与える組み合わせが基本形になります。

• Instructions例：
• • 「このスペースではTypeScriptでの実装例を優先して提案してください」
  • 「パフォーマンスよりもまずは可読性を重視してください」
  • 「セキュリティ上の注意点があれば必ず指摘してください」

こうした“お願いごと”を最初に書いておくことで、同じスペースを使うメンバー間でも期待値を揃えやすくなります。

4. スペースは“タスク単位・ドメイン単位”で分ける

1つのスペースにすべてを詰め込むのではなく、テーマごとに分割した方が運用しやすくなります。

• 認証・権限周り
• 課金・請求フロー
• ログ／テレメトリ運用
• コーディング規約・レビュー基準
• 特定のマイクロサービスやモジュール単位

このくらいの粒度でスペースを切るイメージです。タスクごとに適切なスペースを選ぶ運用にすると、「何をどこに足せばいいか」も分かりやすくなります。

5. チャットは必ず“スペース側から”始める

GitHub上のスペース画面からチャットを開始すると、そのスペースに含まれるコンテキストを前提に会話が進みます。逆に、何もコンテキストを指定せずにCopilot Chatを開いた場合、その都度前提を説明する必要が出てきます。

• 「まずは関連スペースを開き、そこから質問を投げる」
• 「質問の途中で前提が変わったら、InstructionsやSourcesを更新してから再度聞き直す」

この運用を徹底すると、GitHub Copilotの回答ブレを抑えやすくなります。

6. 出力は必ず検証し、レビューに乗せる

スペースで根拠を与えても、GitHub Copilotの回答が常に正しいとは限りません。意図の取り違えや、コードの単純なバグ、ドキュメントの読み違えなどは普通に起こり得ます。

• コードは必ず動作確認・テストにかける
• 手順書や問い合わせ回答案は、少なくとも一度は人間レビューを通す
• セキュリティ・コンプライアンスに関わる内容は、専門担当者のチェックを必須にする

このように、最後は人が責任を持つ”という前提で運用することが重要です。

GitHub Copilot Spacesの活用シーン

GitHub Copilot Spacesは、回答をタスクに適した文脈へ寄せるだけでなく、チームのナレッジ共有や運用負荷の低減にも役立ちます。代表的な活用シーンを整理します。

新機能開発（仕様→実装のズレを減らす）

新機能開発の際には、次のような情報を1つのスペースに束ねておくと便利です。

• 対象リポジトリ（または関連フォルダ）
• プロダクト仕様書・ユーザーストーリー
• アーキテクチャ図や設計メモ
• 既存の類似機能のコード

このセットをまとめたスペースに対して、GitHub Copilotには次のような質問を投げられます。

• 「この仕様と既存実装を踏まえて、差分設計案を出して」
• 「このPRの実装が仕様を満たしているかチェックして」
• 「この部分の設計上の懸念点を洗い出して」

仕様と実装の両方をコンテキストに含められるため、「仕様書はこう書いてあるが、コードは別のことをしている」といったズレを早期に検知しやすくなります。

定型タスクの標準化（レビュー基準・チェックリスト）

ログ出力の方針やテレメトリの埋め込み、エラーハンドリング、APIの認可チェックなど、頻出の“お作法”が絡むタスクはスペースと相性が良い領域です。たとえば、次のような情報をSourcesとしてまとめておきます。

• ガイドラインやチェックリスト
• 代表的な実装例
• NGパターンの例

そのうえで、Instructionsで「このスペースではログ／テレメトリの観点を最優先して確認する」といった指示を書いておくと、次のような形で活用できます。

• 新規実装時に「この関数に必要なログを追加して」
• コードレビュー時に「このPRがガイドラインに沿っているか確認して」

こうした使い方により、レビューの観点や判断基準をチーム内でブレさせずに運用しやすくなります。

ナレッジ共有・オンボーディング（質問の往復を減らす）

認証・検索・決済基盤・CIパイプラインなど、説明コストが高い領域は、スペースを“生きたドキュメント”として使うと効果的です。たとえば、次のような情報を1か所にまとめます。

• 最新の設計資料やアーキテクチャ図
• コアとなるコードパス
• 過去の議事録や設計検討ログ

このスペースを前提に、「このサービスの認証フローを、新しく入ったメンバーにも分かるように説明して」といった質問を投げると、前提を共有したうえでの説明を自動生成できます。

結果として、次のような効果が期待できます。

• 新規メンバーからの質問ラッシュを減らす
• 「誰に聞けば分かるか」を探す時間を減らす
• シニアメンバーの属人的な知識をスペース側に移していく

GitHub Copilot Spacesの注意点

最後に、導入前に押さえておきたい注意点を整理します。

コンテキストは「全部」が処理されるとは限らない

GitHub Copilot Spacesにはサイズ上限があり、Copilot Chatが実際に処理できるのは、そのうちの一部だけです。スペースに大量のファイルやドキュメントを入れても、毎回すべてが参照されるわけではありません。

回答の安定性を高めるには、次のような工夫が重要です。

• 本当に重要な資料を優先して追加する
• 似たような情報が重複しないよう整理する
• 「このスペースでは何が主役か」を決めておく

IDE連携には制約がある（repository-onlyは不可）

前述のとおり、リポジトリだけを含むスペースは、現状MCP経由ではIDEから利用できません。IDE側でスペースを使いたい場合は、ファイルやIssue、ドキュメントなどの追加ソースを含める必要があります。

また、Copilot Chat自体も、言語やフレームワークによって得意・不得意があります。JavaScriptやTypeScriptのようなメジャー言語に比べて、ニッチな言語や独自フレームワークでは、提案の品質にばらつきが出る可能性があります。

共有設定とアクセス権の設計が重要

スペースを共有した場合でも、閲覧者が実際に参照できるソースは、そのユーザーがGitHub上でアクセス権を持つものに限られます。アクセス権がないリポジトリやファイルは、スペースに含まれていても相手からは見えません。

共有を前提とする場合は、あらかじめ次のようなポイントを決めておくと安全です。

• どの範囲までをスペースで共有するか
• 組織内で誰に編集権限を与えるか
• 機密度の高い情報をスペースに含めるか／別チャネルにするか

これらの設計は、セキュリティポリシーとあわせて事前に整理しておく必要があります。

出力の正確性・セキュリティは最終的に利用者が担保する

Spacesで文脈を与えても、Copilotが生成するコードや文章が常に正しいとは限りません。解釈違い、仕様の読み違え、ライブラリの誤用などは起こり得ますし、セキュリティ的に望ましくないコードが提案される可能性もゼロではありません。

こうしたリスクを踏まえたうえで、次のような運用ルールを設けておくことが大切です。

• 重要な処理や本番向けの変更は必ずレビューとテストを通す
• セキュリティやコンプライアンスに関わる部分は、専門チームによる確認を前提にする
• 「AIが出したから正しい」ではなく、「AIを補助輪として使う」前提で運用する

利用量（プレミアムリクエスト）とコストの影響を意識する

GitHub Copilot Spaces で行う質問は、基本的には Copilot Chat のリクエストとしてカウントされます。特に Copilot Free では、月 50 件のプレミアムリクエスト上限の中にチャット利用（Spaces 含む）がすべて含まれるため、使い方によってはすぐに枠を使い切ってしまう点に注意が必要です。

有料プランでは、含まれるモデル（GPT-5 mini / GPT-4.1 / GPT-4o など）を使う限りは、チャット利用がプレミアムリクエストにカウントされません。一方で、高性能モデルを選択した場合はプレミアムリクエストを消費し、月間の枠を超えた分については、管理者が設定した予算の範囲で 1 回あたり $0.04 の従量課金が発生します。

実務では、次のような運用イメージにしておくと、コストと性能のバランスを取りやすくなります。

• Free プランでは、「どのスペースでどの程度チャットするか」を決めておき、枠の使い切りを前提に計画的に使う
• Pro / Pro+ / Business / Enterprise では、日常利用は含まれるモデルを基本とし、重い調査や精度を重視したいケースだけ高性能モデル＋スペースを組み合わせる

この前提をチーム内で共有しておくと、「Spacesをたくさん使ったら思ったより請求が増えた」という事態を避けやすくなります。

まとめ

本記事では、GitHub Copilot Spacesの概要、特徴、料金・premium requestsの考え方、利用手順、活用のコツと注意点を整理しました。

GitHub Copilot Spacesは、タスクに必要な情報（InstructionsとSources）をまとめ、Copilotの回答を当該タスクに適した文脈へ寄せやすくする仕組みです。
個人の作業効率化に加えて、チーム共有によるオンボーディングやナレッジ集約の入口としても活用できます。

一方で、コンテキストの取捨選択、IDE連携上の制約、共有・権限設計、生成結果の検証といった注意点があるため、まずは限定的な用途で試行し、運用しながら設計指針を固めて展開することが望まれます。
東京エレクトロンデバイスは、GitHub Copilotの導入をはじめ、請求支援、企業の開発プロセスの効率化をサポートしています。

ご興味のある方はお気軽にお問い合わせください。

お問い合わせはこちら