GitHub MCP Serverの設定｜公式接続の選び方と注意点
GitHub公式MCP Serverを入れる人向けに、リモート接続とローカル起動の違い、PATやOAuthの扱い方、Clientごとの設定差分、追加後の登録・認証・呼び出し確認と、権限を広げすぎない注意点までを一つの流れで丁寧に整理します。
- MCP
- GitHub
- GitHub Copilot
- 設定
- セキュリティ
- 他1
GitHubのリポジトリ操作をMCP経由で行いたいとき、公式のGitHub MCP Serverを選ぶと入口が揃いやすいです。一方で、リモート接続とローカル起動、Personal Access Token（PAT）の扱い、Clientごとの設定差分が重なると止まりやすいです。
本記事では、公式案内を前提に「どの接続形を選ぶか」「秘密情報をどう避けるか」「追加後に何を確認するか」を整理します。
今日の結論
- 正本は公式リポジトリとインストール案内です。npmの旧パッケージは非対応になった、という注意が公式側にあります。
- 代表的な経路は、リモート（例: Copilot向けHTTP）と、Docker等でのローカル起動です。環境と権限方針で選びます。
- PATやOAuthの取り扱いはClientと方式で違います。値を記事やリポジトリに直書きしないことが最低ラインです。
- Cursor／VS Code／Claudeでは設定キーやパスが違うため、同じJSONを無検証で使い回さない方が安全です。
- 追加後は「登録されたか」「認証できたか」「意図したリポジトリ操作だけ呼べるか」を分けて確認します。
本記事は、筆者が公式ドキュメントを確認した内容をもとに整理しています。掲載した画面名や操作の流れは実機未確認です。バージョン差で表示が違う場合は、公式ドキュメントの現行案内を優先してください。
公式Serverを選ぶ理由と範囲
GitHub MCP Serverは、Issue・PR・リポジトリ情報などGitHub側の操作をMCP経由で扱うための公式Serverです。正本はgithub/github-mcp-serverと、そこに載るインストール案内です。
本記事の範囲は次のとおりです。
| 扱う | 扱わない |
|---|---|
| 接続形の選び方（リモート／ローカル） | 全ツール一覧の網羅 |
| トークン・権限の注意喚起 | セキュリティ監査や保証 |
| Client差分の整理 | 各Clientの画面操作の完全手順（隣記事へ） |
「おすすめ一覧」で候補を見たい場合はおすすめMCP Server一覧へ。本記事はGitHub公式Serverに絞ります。
リモート接続とローカル起動を選ぶ
公式案内では、大きく次の系統があります。
| 系統 | ざっくりしたイメージ | 向く場面 |
|---|---|---|
| リモート（HTTP） | 公式が案内するエンドポイントへ接続する | Copilot／VS Code側で案内される経路を使うとき |
| ローカル（Docker等） | 手元で公式イメージを起動する | ローカル起動方針や、案内どおりのPAT運用が必要なとき |
VS Code向けのリモート例では、servers配下にGitHub向けのHTTP設定を置く案内があります。次は構造確認用の最小例です。接続情報としては使えません。
{
"servers": {
"github": {
"type": "http",
"url": "https://api.githubcopilot.com/mcp/"
}
}
}
ローカル起動では、公式が案内するDockerイメージ（例: ghcr.io/github/github-mcp-server）と、環境変数による認証が中心になります。npmの@modelcontextprotocol/server-githubは、公式側で非対応になった、という注意があるため、古いブログ記事の手順をそのまま使わない方が安全です。
Cursor側では設定キーがmcpServersになるなど、Client差分があります。CursorのMCP設定と公式READMEの「自分のClient向けブロック」を突き合わせてください。VS Code中心ならVS CodeのMCP設定もあわせてどうぞ。
トークンと権限を最小にする
GitHub MCPは便利な一方で、渡す権限が広いほど意図しない操作のリスクも増えます。
- PATを使う場合は、必要最小限のスコープから試す
- トークン値をMarkdown・チャット・Gitに貼らない
- 公式が案内するinput変数や環境変数参照を使う
- 用途不明の第三者ラッパーより、公式イメージ／公式リモートを優先する
認証の細部（OAuthの画面、PATの作成画面、必須スコープ）は変わりやすいため、実行直前に公式READMEとGitHub DocsのCopilot×MCPを確認してください。必須スコープや組織制限の正本も、その時点の公式案内です。
追加後に登録・認証・呼び出しを分けて確認する
- 登録: ClientのMCP一覧または設定ファイルにGitHub Serverがある
- 認証: OAuthやPATの手順が公式どおりに完了している（失敗時は権限・期限・保存先を疑う）
- 呼び出し: 読み取り系の短い依頼から試し、書き込み系は必要になってから許可する
- 範囲: 想定外のリポジトリや組織に届いていないかを確認する
「設定が保存された」だけでは不十分です。認証と呼び出しを分けて見ると、止まりどころが見えやすくなります。
止まったら隣記事へ切り分ける
| 症状 | 次に確認すること |
|---|---|
| VS Codeの置き場所・キー名 | VS CodeのMCP設定 |
| Cursorのmcp.json | CursorのMCP設定 |
| Claude Desktop／Code | Claude Desktop／Claude Code |
| 接続方式の用語 | stdioとSSE |
| どのServerから試すか | おすすめ一覧 |
シリーズ全体の入口はMCPガイドです。
よくある質問（FAQ）
Q1. 古いnpmパッケージの手順でも動きますか？
公式の注意では、旧npmパッケージは非対応になった、と案内されています。公式イメージ／公式リモートを優先してください。
Q2. PATはどこまで権限を付ければよいですか？
「とりあえず全部」は避け、読み取りから試すのが安全です。必須スコープは公式の現行案内を正とします。
Q3. 会社リポジトリでも同じ手順ですか？
組織のSSO、IP制限、Copilot契約の有無で差が出ます。個人アカウント向けの最短手順がそのまま通るとは限りません。社内ルールと公式の組織向け注意を優先してください。
まとめ
GitHub MCP Serverは、公式の接続形を選び、トークンを直書きせず、Client差分を意識すると迷いが減ります。まずは読み取り系の短い確認まで通し、書き込みは必要になってから許可を広げるのが事故を減らす進め方です。
次の一歩:
- VS Codeの置き場所を固める → VS CodeのMCP設定
- 候補Serverを比較する → おすすめMCP Server一覧
- シリーズ入口に戻る → MCPガイド
本記事の内容は執筆時点（2026-09-16）の情報に基づきます。公式ドキュメントを参照して整理していますが、掲載した手順の実機動作は確認していません。エンドポイント・イメージ名・認証方式・必須権限は変更される可能性があります。接続の成功や安全性を保証するものではなく、重要な判断は公式ドキュメントで確認してください。