3行まとめ
read onlyから始め、書き込みや削除は別枠で判断します。
workspace、外部API、ネットワーク、OS差を同時に確認します。
月額だけでなく、Agent Modeのrequest量やAI creditsも見ます。
MCP server選びより先に、agentへ渡す権限境界を決めるのが出発点です。
- VS CodeのCopilot Agent ModeにMCPを足すと、agentが外部tool、ローカルコマンド、外部サービスの情報を使いやすくなります。その分、認証情報、ファイル操作、ネットワーク、料金の入口も増えます。
- 最初に見るべきなのは、どのMCP serverを入れるかではなく、read-onlyで始めるか、書き込みを許すか、workspaceだけに閉じるか、外部APIへ出すかです。
- 2026年6月9日時点の公式Docsでは、VS CodeのMCP sandboxはmacOS/Linuxのローカルstdio server向けで、Windowsでは未対応です。料金とデータ利用もIndividualとBusiness/Enterpriseで扱いが違うため、導入前に公式ページで再確認してください。
この記事でわかること
MCP server追加でAgent Modeが使える道具とリスクがどう増えるかを見ます。
mcp.json、workspace設定、user設定の使い分けを確認します。
sandboxEnabled、server trust、toolの有効化と無効化を分けて考えます。
ローカルVS Code設定とGitHub.com側のrepository MCP設定を混同しないようにします。
plan、AI credits、premium requests、BYOKを導入判断に含めます。
IndividualとBusiness/Enterpriseの扱いをチームルールへ落とします。
この記事は、ローカルのVS CodeでAgent Modeを使う場面に絞って確認します。
この記事では、VS Code上のGitHub Copilot Agent ModeにMCP serverをつなぐ前に、チームで最低限そろえておきたい判断材料を整理します。
対象は、個人開発者、Web開発チームのリード、MCP連携を許可するか確認したいセキュリティ担当です。GitHub Copilotの全機能比較や、GitHub上でIssueを任せるcloud agent運用そのものではなく、ローカルのVS CodeでAgent Modeを使う場面に絞ります。
この記事で確認するのは、主に次の6点です。
- MCP serverを追加すると、Agent Modeの権限境界がどう変わるか
- VS Codeの
mcp.json、workspace設定、user設定をどう分けるか sandboxEnabled、MCP server trust、toolの有効化/無効化をどう見るか- GitHub MCP serverやrepository MCP設定を、VS Codeローカル設定と混同しない方法
- Copilotの料金、AI credits、premium requests、BYOKを導入判断にどう入れるか
- IndividualとBusiness/Enterpriseのデータ利用の違いをどうチームルールへ落とすか
すでにMCPのTools、Resources、Promptsの基本を整理したい場合は、先に<a href="https://ai-dev.blog.mo-gmo.com/mcp-tools-resources-prompts-permission-design/">MCPとは何かを開発者向けに整理した記事</a>を読むと、この記事の権限設計が追いやすくなります。
前提知識
MCP serverは単なる検索窓ではなく、agentの実行面を広げる部品です。
Agent Modeは「会話」ではなく「作業ループ」に近い
判断基準
Copilot Chatを質問回答として使うだけなら、主なリスクは入力したコードや説明がどこへ送られるか、回答を人間がどう検証するかに寄ります。Agent Modeではもう一段進んで、agentがタスクを分解し、ファイルを読み、編集案を作り、terminal commandを提案し、結果を見て再試行します。
GitHubの2026年6月3日のVS Code向けCopilot更新では、VS Code v1.120からv1.123のMay/early June 2026 releasesとして、Agents windowのStable preview、remote agents preview、session preferencesの維持、session syncなどが説明されています。これは、agent作業が一度きりの補助ではなく、複数sessionや長めの作業として扱われ始めているという文脈です。
この流れでMCPを追加すると、agentが使える道具が増えます。道具が増えるほど、作業は速くなる可能性がありますが、確認すべき権限も増えます。
MCP serverは「便利なcontext追加」だけではない
VS Code公式Docsでは、MCP serverはtoolsだけでなく、resources、prompts、interactive appsも提供できると説明されています。つまり、MCP serverは単なる検索窓ではありません。
たとえば、次のように役割が分かれます。
| MCP capability | Agent Modeでの意味 | 導入前の確認 |
|---|---|---|
| Tools | API呼び出し、ブラウザ操作、ファイル操作、DB照会などをagentが呼べる | 書き込みや外部送信があるか |
| Resources | server側の情報をcontextとして添付できる | 秘密情報や顧客情報が混ざらないか |
| Prompts | serverが定義した定型promptを使える | チーム方針と矛盾しないか |
| MCP Apps | chat内にUIを出せる | 入力値や認可の境界が明確か |
便利さだけで判断すると、後から「このserverはどのrepositoryを読めるのか」「このtoolは外部SaaSに何を送るのか」を追うことになります。導入前に、server単位ではなくtool単位で権限を分けておくほうが運用しやすくなります。
結果: 最初はread-onlyとworkspace限定から始める
追加するserver名ではなく、agentが何を読めるか、何を書けるかで判断します。
すぐ使ってよい候補
初期導入のOKライン
実務で最初に試すなら、次のような用途から始めるのが現実的です。
| 用途 | 初期設定の考え方 | 理由 |
|---|---|---|
| 公式Docs検索 | read-only、外部送信先を限定 | 破壊的操作がなく、調査効率を上げやすい |
| GitHubの現行repository参照 | read-only、対象repository限定 | Issue、PR、コード参照に役立つが、scopeを狭めやすい |
| Playwrightなどの検証補助 | sandboxまたは隔離環境で実行 | UI確認に便利だが、ブラウザ操作と外部アクセスを伴う |
| 社内ナレッジ検索 | read-only、検索対象とログを明示 | 情報漏えい時の影響範囲を説明しやすい |
逆に、最初から書き込みtool、deploy tool、課金API、顧客DB、社内管理画面をAgent Modeに渡すのは避けたほうがよいです。MCPの問題というより、agentが使える実行面が広すぎるからです。
すぐ許可しないほうがよい候補
次の条件に当てはまるMCP serverは、個人の試用でも慎重に扱います。
- 認証情報を
mcp.jsonに直接書く必要がある - read-onlyとwriteのtoolが同じserverで混在している
- tool名だけでは外部送信の有無がわからない
- serverのpublisher、repository、更新履歴、licenseが確認しづらい
- agentが承認なしで書き込みや削除を実行できる
- ログにprompt、token、API response、顧客情報が残る
VS Code公式Docsも、ローカルMCP serverは自分のマシン上で任意コードを実行できるため、信頼できるsourceからだけ追加し、publisherとserver configurationを確認するよう注意しています。これはかなり重要です。MCP serverを追加することは、npm packageやCLI toolを開発環境に入れるのと同じ系統の判断です。
VS CodeのAgent ModeにMCPを足すと何が変わるか
ローカルで目の前に見えている確認感覚を、cloud agentへそのまま持ち込まないことが重要です。
ローカルVS Codeの設定とGitHub.com側の設定を分ける
混同しないための境界
混乱しやすいのは、VS Codeで使うMCP設定と、GitHub.com上でCopilot cloud agentやcode reviewが使うrepository MCP設定が似て見えることです。
| 場面 | 主な設定場所 | 誰が使うか | 主なリスク |
|---|---|---|---|
| VS CodeローカルAgent Mode | user profileのmcp.json、workspaceの.vscode/mcp.json | ローカルのCopilot Chat/Agent Mode | ローカルコマンド、workspaceファイル、外部通信 |
| GitHub.com上のcloud agent/code review | repositoryのCopilot MCP設定 | GitHub上で動くagent | repository権限、Actions環境、server自動使用 |
| Copilot CLIやその他agent | それぞれのagent設定 | CLIや別host | terminal権限、sessionログ、外部接続 |
この記事の主役は1行目、つまりVS Codeローカルです。GitHub.com側のcloud agent向けMCP設定は、似た名前でも実行場所と承認の前提が違います。GitHub Docsでは、repository MCP設定を入れると、Copilotがserverのtoolsを自律的に使えるようになり、使用のたびに承認を求めない旨の警告が出ています。ローカルVS Codeの「その場で確認する」感覚を、そのままcloud agentへ持ち込まないほうが安全です。
GitHub上のIssueをCopilotへ任せる運用を知りたい場合は、<a href="https://ai-dev.blog.mo-gmo.com/github-copilot-coding-agent-issue-instructions-environment-review/">Copilot Coding AgentにIssueを任せる前のinstructionsとPRレビューの記事</a>に分けています。
workspace設定とuser設定を混ぜない
VS CodeのMCP設定は、workspaceとuser profileで扱いが変わります。
- workspace:
.vscode/mcp.jsonに置く。teamで共有しやすいが、repositoryに入るため秘密情報は置かない。 - user profile: userごとの
mcp.jsonに置く。個人の環境に閉じやすいが、複数workspaceへ効きやすい。 - remote/dev container: serverがどこで動くかが変わる。ローカルで動くと思い込まない。
チームに配るなら、workspaceにはserverの形だけを置き、credentialは環境変数、OAuth、secret manager、またはuser側設定へ逃がすのが基本です。VS Code Docsも、API keyのようなsensitive informationをhardcodeしないよう注意しています。
sandboxはOSとserver typeで前提が変わる
- 11. OSを確認する
macOS/LinuxとWindowsで、MCP sandboxの前提が同じではありません。
- 22. server typeを見る
local stdioかremote HTTPかを説明できる状態にします。
- 33. file writeを絞る
workspace内の必要pathだけを許可します。
- 44. networkを絞る
必要domainだけを許可し、広い外部接続を避けます。
- 55. credentialを分ける
設定ファイルに秘密情報を直接書かず、認証方式を明示します。
チームに複数OSが混在する場合、sandbox以外の境界も合わせて設計します。
macOS/Linuxのstdio serverではsandboxを確認する
filesystemとnetworkの確認項目
2026年6月9日時点のVS Code Docsでは、macOSとLinuxで、ローカル実行されるstdio MCP serverにsandboxを有効化できると説明されています。sandboxEnabledをserver設定に入れ、top-levelのsandbox objectでfilesystemやnetworkのruleを指定する形です。
ここで大事なのは、sandboxを「安全のお墨付き」と見ないことです。sandboxは被害範囲を狭める仕組みです。許可するpathやdomainが広すぎれば、効果は薄くなります。
最初の確認項目はこの4つです。
| 確認項目 | 見る場所 | OKの目安 |
|---|---|---|
| server type | mcp.json | local stdioかremote HTTPかを説明できる |
| file write | sandbox.filesystem | workspace内の必要pathだけ |
| network | sandbox.network | 必要domainだけ |
| credential | env/OAuth/secret管理 | 設定ファイルに直接書かない |
Windowsでは同じ前提で語らない
OS混在チームの補強策
同じVS Codeでも、公式DocsではMCP sandboxは現在Windowsでは利用できないとされています。つまり、チームにmacOS、Linux、Windowsが混在している場合、「VS Codeでsandboxを有効にしたから全員同じ安全性」とは言えません。
Windows端末でMCP serverを使う場合は、sandbox以外の対策を厚くします。
- server自体をread-only用途へ限定する
- write toolを無効化する
- 外部APIへの接続を別のproxyやgatewayで制御する
- 社内repositoryではなく検証用repositoryで試す
- 実行ログと承認ログを残す
- 可能ならdev containerや隔離された作業環境で試す
OS差は、導入手順の細部ではなく、リスク評価の前提です。特に法人導入では、開発者のOS分布を先に確認してから運用ルールを作るべきです。
allowlistはserver、tool、terminal commandを分けて考える
- 1Server allowlist
server名、source、実行場所、認証方式、更新確認を記録します。
- 2Tool allowlist
read tool、write tool、delete、deploy、billing、admin変更を分けます。
- 3Terminal command allowlist
test、lint、typecheck、read only git commandなどから始めます。
- 4監査
CopilotがMCP経由で何をしたか、定期的に確認できる状態にします。
allowlistは便利さを止める表ではなく、agentに任せる範囲を説明する表です。
MCP server allowlist
server単位で記録する項目
まずは、どのMCP serverを使ってよいかを決めます。GitHub DocsのMCP best practicesでも、MCP serverには最小権限を与え、接続を定期的に監査し、CopilotがMCP経由で何をしたか監視することが推奨されています。
チームでは、server allowlistに次の情報を含めるとレビューしやすくなります。
| 項目 | 書く内容 |
|---|---|
| server名 | 例: GitHub MCP、Docs検索、Playwright検証 |
| publisher/source | 公式Docs、公式repository、社内管理者 |
| 実行場所 | local、remote、dev container、GitHub.com |
| 認証方式 | OAuth、fine-grained PAT、API key、なし |
| 許可tool | read-only toolだけ、または限定したwrite tool |
| 禁止tool | delete、deploy、billing、admin変更など |
| 更新確認 | version、release notes、review担当 |
この表をAGENTS.mdや開発環境READMEに置くと、agentに読ませるための指示にも、人間レビューの観点にも使えます。AGENTS.mdの運用をそろえる話は、<a href="https://ai-dev.blog.mo-gmo.com/agents-md-standardization-team-ai-coding-instructions/">AGENTS.md標準化の実務影響の記事</a>も参考になります。
tool allowlist
serverを許可しても、server内のすべてのtoolを許可する必要はありません。VS CodeのMCP server画面やchat inputのConfigure Toolsから、serverごとのtoolを確認し、不要なものを外します。
特に分けたいのは次のtoolです。
- read: issue、PR、Docs、repository metadataを読む
- search: code search、Docs検索、社内ナレッジ検索
- write: file更新、issue comment、PR作成、DB更新
- execute: shell、browser操作、workflow起動
- admin: token管理、権限変更、billing、組織設定
最初に許可するのはreadとsearchだけで十分です。write以上は、作業目的、承認条件、rollback方法、ログの残り方を決めてから許可します。
terminal command allowlist
MCP以外の抜け道を閉じる
Agent ModeではMCPだけでなくterminal commandも重要です。VS Code settings referenceでは、agentのterminal command自動承認に関するchat.tools.terminal.autoApproveや、全tool自動承認に近いchat.tools.global.autoApprove、sessionのpermission levelに関するchat.permissions.defaultなどが説明されています。
ここでやってはいけないのは、MCP serverを慎重に選んだのにterminal側で広い自動承認を入れてしまうことです。外部APIを直接叩くMCPを禁止しても、terminalで同じことができれば境界は崩れます。
初期設定の考え方は次の通りです。
| command種別 | 初期方針 |
|---|---|
npm test、npm run typecheck、npm run lint | repositoryごとに許可候補 |
git diff、git status | read-onlyとして許可候補 |
| package install | 原則は人間承認 |
| deploy、migration、release | 自動承認しない |
| secret操作、権限変更、削除系 | 自動承認しない |
| 外部HTTP送信 | 宛先と目的が説明できない限り自動承認しない |
terminal allowlistとMCP allowlistは、同じ表でレビューしてください。片方だけ締めても、もう片方が抜け道になります。
GitHub MCP serverを使うならread-only tokenから確認する
- 11. 実行場所
ローカルVS Codeで使うのか、GitHub.com上のcloud agentが使うのかを分けます。
- 22. tokenの主体
誰の権限で発行され、どのrepositoryへ届くかを確認します。
- 33. read-only
現行repositoryの参照から始め、Issue commentやPR作成は後で検証します。
- 44. OAuth優先
OAuthが使えるなら優先し、PATが必要な場合はfine grainedで短期限にします。
- 55. 取り消し手順
tokenを取り消す担当者と手順を事前に決めます。
GitHub.com側のrepository MCP設定と、VS Codeローカルの認証設定は前提が違います。
VS CodeのGitHub MCPとrepository MCP設定を混同しない
GitHub Docsでは、Copilot cloud agentやCopilot code review向けのrepository MCP設定について、GitHub MCP serverがデフォルトで現行repositoryへのread-only accessを持つ特別なtokenで接続されると説明されています。外部repositoryへ広げる場合は、fine-grained PATを推奨する説明もあります。
ただし、これはGitHub.com側のrepository MCP設定の話です。VS CodeローカルでGitHub MCP serverを使う場合は、ローカルの認証方式、VS CodeのMCP設定、組織ポリシー、OAuth/PATのscopeを別途確認します。
混同を避けるため、次の質問に答えてから設定します。
- これはローカルVS Codeで使うMCPか、GitHub.com上のcloud agentが使うMCPか
- tokenは誰の権限で発行されるか
- 現行repositoryだけを読めるのか、organization内の他repositoryも読めるのか
- issue comment、branch作成、PR作成などのwrite操作を含むか
- tokenを取り消す担当者と手順は決まっているか
PATよりOAuthを優先する
token棚卸しの条件
GitHub DocsのMCP best practicesでは、GitHub MCPのようにOAuthが使えるserverではOAuthを優先するよう案内されています。PATは便利ですが、作った本人以外がscopeや期限を把握しづらく、退職、異動、端末紛失、漏えい時の運用が重くなりがちです。
PATが必要な場合は、fine-grained PATを使い、対象repository、permission、期限を最小にします。記事や社内Docsには実tokenを書かず、手順だけを残します。
実務では、次のように段階を切ると安全です。
- 現行repository read-onlyで使う
- Issue/PRのreadを追加する
- commentやbranch作成など限定writeを検証用repositoryで試す
- 本番repositoryではCODEOWNERS、branch protection、PR reviewを必須にする
- token棚卸しと失効手順を運用に入れる
料金はMCP接続料ではなくCopilot利用量として見る
Agent Mode、MCP、Business/Enterprise policyの可否が変わります。
長いagent sessionほど消費が増えやすくなります。
選ぶmodelや作業の長さで上限確認が必要になります。
個人や小規模チームでは予算超過を防ぐ設定を確認します。
API key管理、請求先、data policyが変わります。
月額plan名だけではなく、1タスクあたりのagent sessionとmodel選択を見ます。
agent作業はusageを押し上げやすい
検証期間で見る数字
MCP serverを追加したから即座に別料金、という見方は雑です。見るべきなのは、Agent Modeでのrequest量、選んだmodel、AI credits、premium requests、BYOK、追加購入の有無です。
GitHubの公式Plans/Princingページでは、Free、Pro、Pro+、Business、Enterpriseなどのplan、agent mode、MCP、premium requests、AI creditsに関する説明が掲載されています。また2026年6月9日時点では、Copilot Pro、Pro+、Max、Studentの新規sign-up一時停止や、Businessの新規self-serve sign-up一時停止に関する注意も公式Docsに出ています。
つまり、導入判断では「月額いくらか」だけでなく、次を見る必要があります。
| 確認項目 | なぜ必要か |
|---|---|
| 利用plan | Agent Mode、MCP、Business/Enterprise policyの可否が変わる |
| AI credits/premium requests | 長いagent sessionほど消費が増えやすい |
| 追加購入/上限 | 個人や小規模チームで予算超過を防ぐ |
| 使用model | 高性能modelほど単価や消費が大きい場合がある |
| BYOK | API key管理、請求先、data policyが変わる |
| session syncやremote agent | 利用範囲とログの見方が変わる |
AI coding tool全体の料金比較を深掘りしたい場合は、<a href="https://ai-dev.blog.mo-gmo.com/ai-coding-tool-pricing-plan-limits-team-enterprise-decision/">AIコーディングツール料金改定の見方</a>に分けています。この記事では、VS Code + Copilot Agent Mode + MCPを使う前の確認に絞ります。
チームでは「誰が使えるか」と「どこまで使えるか」を分ける
個人なら、使いすぎたときに自分の請求で止まります。チームでは、利用者、repository、model、MCP server、terminal auto approve、AI creditsの上限が絡みます。
おすすめは、最初から全員に開放しないことです。
- まずは2から3人の検証枠を作る
- 対象repositoryを1つに絞る
- MCP serverはread-onlyとDocs検索だけにする
- 1週間単位でrequest量、PR数、修正差分、review時間を記録する
- 予算超過や危険操作が出たらallowlistを戻す
これは消極的な話ではありません。制約を小さくすると、何が効いたのか、どこで危なかったのかが見えます。
データ利用と保持はIndividualとBusiness/Enterpriseで分ける
個人契約で業務repositoryを扱う運用は、組織契約と同じ前提にしないでください。
Copilot側のデータ利用
GitHubの公式Pricingページでは、Individual subscribers、つまりFree/Pro/Pro+のCopilot interaction dataについて、prompt、suggestions、code snippetsなどがmodel trainingやimprovementに使われる場合があり、ユーザーは設定からopt outできると説明されています。一方で、Copilot BusinessまたはEnterpriseのデータはGitHubのmodel trainingに使わないと説明されています。
ここはチーム導入で誤解が出やすいところです。個人契約で業務repositoryを触る運用にしている場合、組織契約と同じデータ利用前提にはなりません。
導入前に次を確認します。
- 業務コードを個人Copilot planで扱ってよいか
- opt-out設定をチームルールで確認するか
- Business/Enterprise契約で組織policyを使うか
- session syncを許可するrepositoryと除外するrepositoryを決めるか
- audit logやagent activityの確認範囲をどうするか
MCP server側のデータ利用
Copilot契約外のログ
Copilot側のデータ利用だけ見ても不十分です。MCP serverを入れると、serverや接続先SaaSにも情報が渡ります。
たとえばDocs検索serverなら検索queryが残るかもしれません。GitHub MCP serverならIssueやPRの情報を読むかもしれません。社内APIをMCP化するなら、API gatewayやapplication logにprompt由来の入力が残るかもしれません。
チームルールでは、MCP serverごとに次を確認してください。
| 見る対象 | 確認する内容 |
|---|---|
| MCP server本体 | publisher、license、更新履歴、telemetry |
| 接続先サービス | data retention、training use、subprocessor |
| 認証 | OAuth scope、PAT scope、secret保管 |
| ログ | prompt、tool input、tool output、error logの保持 |
| 削除 | token失効、server削除、ログ削除の手順 |
Business/Enterprise planだからすべて安全、とは言えません。Copilotの契約範囲外にあるMCP serverや外部SaaSは、別途レビューが必要です。
失敗点
serverがどこで動き、何を外部へ送り、どのcredentialで動くかを確認します。
sandbox ruleが広すぎると、許可したfileやnetworkの範囲も広がります。
repository MCP設定はcloud agentやcode review向けで、ローカルVS Codeとは前提が違います。
Agent Modeの調査、tool呼び出し、再試行で利用量が増えることがあります。
失敗の多くは、権限・場所・承認・利用量をひとまとめにしたときに起きます。
失敗1: MCP serverの名前だけで安全と判断する
「GitHub MCP」「Playwright MCP」「Docs MCP」のような名前だけで安全性は判断できません。見るべきなのは、serverがどこで動くか、どのtoolを出すか、何を外部へ送るか、どのcredentialで動くかです。
特にPlaywright系のbrowser操作は、UI検証には便利ですが、外部siteへのアクセス、cookie、screenshot、フォーム入力が絡みます。検証用profile、検証用account、検証用URLに閉じるのが基本です。
失敗2: sandboxを入れたので全toolをauto approveする
VS Code Docsでは、sandboxが有効なserverのtool callはcontrolled environmentで動くためauto-approvedになると説明されています。ここで油断して、sandbox ruleを広くしすぎると意味が薄れます。
allowWriteをworkspace全体にするか、特定dirにするか。networkを広く許すか、必要domainだけにするか。この差が実際の被害範囲になります。
失敗3: GitHub.com側のMCP設定をローカルと同じつもりで扱う
GitHub.comのrepository MCP設定は、Copilot cloud agentやcode reviewが使う設定です。Docsでは、設定したserverのtoolをCopilotが自律的に使えるようになる旨が警告されています。
ローカルVS Codeでは自分が目の前で確認している感覚がありますが、cloud agentは背景で動きます。承認、ログ、PR review、branch protectionを別枠で設計してください。
失敗4: 料金を月額だけで見る
Agent Modeは、短いchatよりも多くのrequestを使いやすいです。MCPを足すと、agentが調査、tool呼び出し、再試行を行いやすくなります。月額のplan名だけでは、実際の利用量や上限を説明できません。
検証時は、1タスクあたりのsession数、PRあたりのrequest量、失敗時の再実行回数、使ったmodelをメモします。速度だけでなく、レビュー時間とコストも一緒に見ます。
実務で使うなら
- Day 1
対象repositoryを1つに限定し、GitHub read onlyと公式Docs検索だけにします。
- Day 2-4
terminal auto approveはtest、lint、typecheck、read only git commandに絞ります。
- Day 5
すべてのagent PRに、実行した確認、未確認、使ったMCP toolを書かせます。
- 週末
差分品質、review時間、失敗回数、料金影響を見直します。
- 次の段階
効果が見えたら、限定writeを検証します。deployやDB migrationは後回しにします。
空欄が残るserverは、本番repositoryへ入れない判断ができます。
導入前チェックリスト
MCP serverを追加する前に、次の表を1つ埋めてください。全部を完璧に書けなくても、空欄が残るserverは本番repositoryへ入れない判断ができます。
| 確認項目 | OK基準 | NGなら |
|---|---|---|
| 目的 | read/search/write/adminのどれか説明できる | 使わない |
| 実行場所 | local、remote、GitHub.comを説明できる | 検証環境へ隔離 |
| server source | 公式または社内管理sourceを確認済み | 追加しない |
| tool一覧 | 許可toolと禁止toolを分けた | toolを無効化 |
| credential | OAuthまたは最小scopeのsecret | credential設計を先に直す |
| file access | workspace内の必要範囲だけ | sandboxやcontainerを検討 |
| network | 必要domainだけ | gatewayやproxyで制御 |
| approval | write/adminは人間承認あり | 自動承認しない |
| log | 誰が何を確認できるか決めた | 運用前に止める |
| cost | plan、credits、上限を確認済み | 検証枠で制限 |
小さく始める運用例
1週間pilotの完了条件
最初の1週間は、次のような運用にします。
- 対象repositoryを1つに限定する
- MCP serverはGitHub read-onlyと公式Docs検索だけにする
- terminal auto approveはtest、lint、typecheck、read-only git commandに絞る
- 書き込みtoolは無効化する
- すべてのagent PRに「実行した確認」「未確認」「使ったMCP tool」を書かせる
- 週末に差分品質、review時間、失敗回数、料金影響を見直す
この運用で効果が見えたら、次に限定writeを検証します。いきなりdeployやDB migrationに進まないでください。AI agentの外部通信やallowlistをもう少し広く設計したい場合は、<a href="https://ai-dev.blog.mo-gmo.com/codex-network-access-allowlist-web-search-mcp-security/">Codexのnetwork access、web search、MCP securityの記事</a>も参考になります。
レビュー観点
MCPを使ったagent作業のレビューでは、差分だけでなく「agentが何を見て、何を呼んだか」を確認します。
- どのMCP serverを使ったか
- どのtoolを何回呼んだか
- tool outputに秘密情報や不要な外部情報が含まれていないか
- terminal commandに危険な操作がないか
- 失敗後に同じ操作を繰り返していないか
- 料金が膨らむ長いloopになっていないか
- 人間承認が必要な操作を勝手に進めていないか
PR templateに「MCP/tool使用」「実行command」「未確認項目」「security/cost注意」を入れておくと、人間レビューが楽になります。
セキュリティ・コスト注意
安全性と費用は、serverを入れた時点ではなく、agentが何を繰り返せるかで変わります。
セキュリティ注意
自動承認しない操作
MCP導入で一番危ないのは、外部toolを使えること自体ではありません。危ないのは、どのtoolが何をできるかを人間が説明できない状態で、agentに長い作業を任せることです。
最低限、次の原則を置きます。
- OAuthが使えるならOAuthを優先する
- PAT/API keyはfine-grained、短期限、対象repository限定にする
- write/admin toolは最初から許可しない
- MCP outputは未信頼入力として扱う
- prompt injectionを想定し、外部DocsやIssue本文をそのまま命令として扱わせない
- terminal commandのauto approveを広げすぎない
- session syncやログに残る情報を把握する
MCP outputやIssue本文に混ざるprompt injectionを深掘りする場合は、<a href="https://ai-dev.blog.mo-gmo.com/ai-coding-agent-prompt-injection-issues-docs-mcp-guardrails/">AIコーディングエージェントのprompt injection、Issue、Docs、MCP guardrailsの記事</a>へ進むと整理しやすいです。
コスト注意
Agent Modeは、1回の質問で終わるchatよりも長く動きます。MCPを足すと、agentは調査し、toolを呼び、失敗を見て再試行できます。これは強みですが、料金や上限の見方も変わります。
チーム導入では、次のメトリクスを見ます。
| メトリクス | 見る理由 |
|---|---|
| 1タスクあたりのsession時間 | 長いloopを検出する |
| tool呼び出し回数 | 不要なMCP呼び出しを見つける |
| 失敗後の再試行回数 | コスト増と品質低下を見つける |
| PR review時間 | agent導入の実質効果を見る |
| AI credits/premium requests | 予算超過を防ぐ |
| 差分の採用率 | 速度だけでなく成果を見る |
料金は変わりやすいので、本文の数字を鵜呑みにせず、公開時点のGitHub公式Plans/Princingページを必ず確認してください。
FAQ
良いcontextやtoolは助けになりますが、不要なtoolや広すぎる権限は失敗を広げます。
共有したいserver設定はworkspace、個人credentialや試験的serverはuser profileで扱います。
read only server、tool無効化、dev container、検証repositoryなどで境界を厚くします。
どの権限で、どのrepositoryに、どのtoolを使えるかを確認します。
会社の規程、契約、opt out設定、Business/Enterprise契約の有無を確認します。
FAQは、MCPそのものより運用前提の確認に使うと判断しやすくなります。
MCPを入れればCopilot Agent Modeは自動で賢くなりますか
自動で万能にはなりません。MCP serverが良いcontextやtoolを提供すれば作業精度が上がる可能性はありますが、不要なtool、古いDocs、広すぎる権限、曖昧なpromptがあると、むしろ失敗の面積が広がります。
MCP serverはworkspaceに置くべきですか、user profileに置くべきですか
チーム共有したいserver設定はworkspaceの.vscode/mcp.jsonに置く候補になります。ただし秘密情報は置かないでください。個人のcredentialや試験的serverはuser profileに置き、teamに配る前にレビューします。
Windowsユーザーがいるチームではどうすればよいですか
2026年6月9日時点のVS Code Docsでは、MCP sandboxはWindowsでは利用できません。Windowsユーザーがいる場合、read-only server、tool無効化、dev container、検証repository、proxy/gatewayなど、sandbox以外の境界を厚くします。
GitHub MCP serverなら安全ですか
安全と断定はできません。GitHub MCP serverでも、どの権限で、どのrepositoryに、どのtoolを使えるかを見る必要があります。GitHub.com側のrepository MCP設定とVS Codeローカル設定では前提も違います。
個人のCopilot Proで会社のrepositoryを触ってよいですか
会社の規程と契約次第です。GitHubのPricingページでは、Individual subscribersのCopilot interaction dataがmodel trainingやimprovementに使われる場合があり、opt outできると説明されています。業務コードを扱うなら、Business/Enterprise契約や組織policyを確認してください。
参照した主な情報源
- https://github.blog/changelog/2026-06-03-github-copilot-in-visual-studio-code-may-releases/
- https://github.blog/news-insights/product-news/github-copilot-app-the-agent-native-desktop-experience/
- https://docs.github.com/en/enterprise-cloud@latest/copilot/tutorials/enhance-agent-mode-with-mcp?tool=vscode
- https://code.visualstudio.com/docs/agent-customization/mcp-servers
- https://code.visualstudio.com/docs/agents/reference/copilot-settings
- https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/configure-mcp-servers
- https://docs.github.com/en/copilot/get-started/plans
- https://github.com/features/copilot/plans
次に読むなら
更新履歴
- 2026年6月9日
GitHub Copilot in VS Code May releases、GitHub Copilot app、GitHub DocsのMCP best practicesを確認しました。
- 同日
VS CodeのMCP server、sandbox、settings referenceを確認しました。
- 同日
GitHub Copilot plans/pricingを確認し、X/Twitterの直近需要シグナルは根拠に使っていません。
料金や機能は変わりやすいため、導入前に公式ページで再確認してください。
- 2026年6月9日: GitHub Copilot in VS Code May releases、GitHub Copilot app、GitHub DocsのMCP best practices、VS CodeのMCP server/sandbox/settings reference、GitHub Copilot plans/pricingを確認して初版を作成しました。X/Twitterの指定アカウントから直近72時間の安定した需要シグナルは確認できなかったため、記事内の根拠には使っていません。
- 利害関係: スポンサー、アフィリエイト、無償提供、検証環境提供はありません。