Cursor MCPとGitHub連携完全ガイド：設定から活用まで

CursorとGitHubをMCPでつなぐと何ができるのか

MCP（Model Context Protocol）の基本概念

テキトー教師.AI認定講師

MCPって最近よく聞くけど、「Model Context Protocol」の略なんですよね。Cursorから外部のツールやデータソースにつなぐためのプロトコルです。

室谷代表取締役

そう。Anthropicが2024年11月にオープンソースで公開したんだけど、Cursorもすぐに対応した。

いわば「AIエージェント用のUSB-C」みたいな規格ですね。

テキトー教師.AI認定講師

その比喩、分かりやすいです。これまではGitHubやSlackとつなぐのに個別にAPI連携を組む必要があったけど、MCPなら一つのプロトコルで統一できる。

GitHub MCPで実現できること：Issues、PR、コード検索

室谷代表取締役

GitHub MCPサーバを立ち上げると、CursorのAgentが直接Issueを読んだりPRを作成したりできる。コードベースの検索も依頼できる。

テキトー教師.AI認定講師

実は初めて触る人は「これってブラウザ経由じゃなくてエディタ内で完結するんだ」って驚きますね。いちいちGitHubのページを開かなくなる。

室谷代表取締役

うちの現場でも、PRレビューのたびにタブを切り替える手間が減ったと。時給換算すると月に結構な時間が浮く計算です。

なぜCursorでMCPを使うのか：Agentとの連携

テキトー教師.AI認定講師

で、なぜCursorでMCPなのかというと、Agentが自動でツールを使い分けてくれるからですよね。手動でAPIキーを渡す必要がない。

室谷代表取締役

そうです。Agentがコンテキストを判断して、必要なときにGitHub MCPのToolを呼び出す。

例えば「このIssueの修正方法を考えて」と頼むと、自動でIssueを取得してコード提案までやる。

テキトー教師.AI認定講師

最初に戸惑うのは「どんなタイミングでMCPが動くのか」という点ですが、実際に使ってみると自然で。設定さえしてしまえば後はAgent任せです。

室谷代表取締役

まさに。「AIにGitHubの操作を任せる」というワークフローが、ROIで見て十分ペイする時代になってきたんですよね。

mcp.jsonを使ったGitHub MCPサーバの設定方法

ローカルMCPサーバ（stdio）の基本的な設定

室谷代表取締役

MCPサーバの設定、基本はmcp.jsonに書く形ですね。Cursorが自動で読み込んでくれます。

テキトー教師.AI認定講師

そうなんです。プロジェクトルートかユーザの設定ディレクトリに置くんですが、まずはローカルで動くstdioタイプから試すのがいいですよ。

室谷代表取締役

うちの現場でも、最初は手元で動かしてからリモートに移行してます。ローカルなら認証周りもシンプルなんで。

mcp.jsonの記述例と環境変数の管理

テキトー教師.AI認定講師

具体的にはこんな感じです。

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "<your_token>"
      }
    }
  }
}

室谷代表取締役

envで環境変数渡せるのが地味に便利ですよね。トークン直書きは避けたいので、.envから読み込む運用にしてます。

テキトー教師.AI認定講師

初めて設定するときは、トークンが正しいか確認するのに少し戸惑うんですけど、一度動けばあとは安定します。

手動インストールとCursor Marketplaceからの追加

室谷代表取締役

Marketplaceも充実してきましたね。公式のGitHubプラグインが一発で入れられる。

テキトー教師.AI認定講師

そう、Customize画面からポチッと追加してOAuthの認証を通すだけ。手動でmcp.jsonを書く必要がなくなります。

室谷代表取締役

ただ、チーム全体で同じ設定を共有したいときはmcp.jsonの方が管理しやすい。僕はプロジェクトにコミットしちゃってます。

テキトー教師.AI認定講師

どちらでも使いやすい方を選べばいいですね。まずはMarketplaceで試して、慣れたらmcp.jsonでカスタマイズするのがおすすめです。

認証方式を理解する：PATとOAuthの使い分け

Personal Access Token（PAT）の生成と設定方法

室谷代表取締役

GitHub MCPをローカルで動かすなら、PATが一番手軽なんですよね。トークンを発行してmcp.jsonのenvに仕込むだけ。

テキトー教師.AI認定講師

そうですね。最初に戸惑うのがトークンのスコープ設定。

repoとread:userぐらいあれば大抵の操作はカバーできます。

室谷代表取締役

ただ、PATをそのまま書くと漏れたときが怖い。MYUUUでは環境変数経由で読み込むようにしてます。

テキトー教師.AI認定講師

それはいい対策です。あと、PATは有効期限を設定できるので、短めにしておくのがおすすめです。

OAuthを使った認証フローと静的OAuthクライアント

室谷代表取締役

チームで使うならOAuthの方が現実的です。CursorのMCPはリモートサーバー向けにStatic OAuthクライアントをサポートしてる。

テキトー教師.AI認定講師

静的OAuthって何かというと、mcp.jsonにあらかじめClient IDとClient Secretを書いておく方式ですね。動的登録が不要でシンプル。

室谷代表取締役

GitHubのOAuthアプリを登録して、そのクレデンシャルをmcp.jsonのheadersかurlパラメータに仕込む感じです。

テキトー教師.AI認定講師

フローとしては、初回接続時にCursorがブラウザを開いて認証、コールバックを受け取ってトークンを保存。その後は自動でリフレッシュされます。

認証方式の選び方：個人開発とチーム開発でのベストプラクティス

室谷代表取締役

個人でローカル完結ならPATで十分。でもチームで同じMCPサーバーを共有するならOAuth一択です。

テキトー教師.AI認定講師

現場でよく聞かれるのは「どっちが安全か」という質問。PATはシンプルだけど管理が面倒。

OAuthは初期設定がちょっと多いけど長期的には楽。

室谷代表取締役

そう。ROIで考えると、3人以上のチームならOAuthの初期投資はすぐ回収できます。

トークン管理のコストが減るので。

テキトー教師.AI認定講師

あと、GitHubのOAuthだと組織のポリシーでアクセス制御できるのもメリットですね。

リモートMCPサーバでGitHubを操作する

SSEとStreamable HTTPの違いと設定

室谷代表取締役

リモートMCPサーバにはSSEとStreamable HTTPの2方式があるんですよね。USだとStreamable HTTPが新しい標準になりつつあって、接続の確立がワンステップで済むって利点があります。

テキトー教師.AI認定講師

そうですね。SSEだとイベントストリームを維持する必要があって、その分サーバ側のリソース管理が面倒なんですよ。

一方Streamable HTTPはリクエスト・レスポンスが完結するので、サーバーレス環境でも動かしやすい。

室谷代表取締役

現場で最初に迷うのは「どっちを選べばいいか」ですよね。GitHub連携なら、普通に動く既存のサーバがあるならSSEでもいい。

でも新規で立てるならStreamable HTTPを選ぶ方が後々楽です。

テキトー教師.AI認定講師

mcp.jsonの書き方自体は似ていて、"url"フィールドにエンドポイントを指定するだけ。違いを意識しすぎず、まずは提供されているURLをそのまま設定してみるのがおすすめです。

リモートサーバのURL指定とOAuth連携

テキトー教師.AI認定講師

実際の設定はこんな感じになります。

{
  "mcpServers": {
    "github": {
      "url": "https://your-server.example.com/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_TOKEN"
      }
    }
  }
}

室谷代表取締役

でも、GitHub APIみたいにOAuthが必要なケースだと、静的トークンじゃなくてOAuthフローを組み込みたいんですよね。Cursorはmcp.jsonに静的OAuthクライアント情報を持たせることもできるので、プロバイダからClient IDとSecretをもらって設定できます。

テキトー教師.AI認定講師

初期接続時にブラウザが開いて認証する流れになるので、ローカルのstdioよりちょっと手間は増えますが、一度設定すれば複数人で共有できる利点があります。

室谷代表取締役

時給で考えると、チーム全体で同じGitHubサーバを使い回せるなら、設定コストは十分ペイしますよ。

ローカルとリモートの使い分け基準

室谷代表取締役

結局、ローカルとリモート、どっちを選ぶかは使う人数と環境次第です。個人開発ならnpxで起動するローカルで十分。

テキトー教師.AI認定講師

初めてMCPを触る人は、まずはstdioのローカルサーバで動作確認してから、リモートに移行するのが安全ですね。

室谷代表取締役

複数人で同じGitHubアカウントの操作を共有したい場合や、CI/CDパイプラインからGitHub MCPを叩きたい場合はリモート一択。AWS LambdaとかでStreamable HTTPサーバを立てると、課金も安く済みます。

テキトー教師.AI認定講師

リモートにするとネットワークレイテンシが気になりますが、最近の接続方式なら実用上ほとんど問題になりません。迷ったら「まずローカルで慣れて、共有が必要になったらリモートに切り替える」という段取りで進めるのが良いです。

Cursor AgentとGitHub MCPを組み合わせた実践活用

自動PRレビューの設定と運用

室谷代表取締役

GitHub MCPを入れると、PRのレビューをAgentに任せられるんですよね。コードレビューのルーチン作業が一気に減る。

テキトー教師.AI認定講師

最初に戸惑うのが「どこまで任せていいか」ですね。全部任せると変なレビューが返ってくることもある。

室谷代表取締役

そこはルールで縛るしかないです。CursorのRulesでレビューの観点を定義しておくと、出力が安定します。

テキトー教師.AI認定講師

たしかに。初期は「コードスタイルとテストの有無だけ見て」くらいから始めるのが無難です。

Issue管理の自動化：作成、割り当て、クローズ

テキトー教師.AI認定講師

Issueの自動作成と割り当て、これができると運用が楽になりますね。

室谷代表取締役

例えばコードレビューでバグを見つけたら、Agentが自動でIssueを立てる。Assigneeまで決められる。

テキトー教師.AI認定講師

ただ、全部自動だとノイズが増えるので、条件を絞る工夫が必要です。クローズも同様ですね。

室谷代表取締役

そう。ワークフローに組み込むときは「人の承認を経る」ステップを入れるかどうかが設計ポイントです。

複数リポジトリの横断検索とコードベース理解

テキトー教師.AI認定講師

複数リポジトリにまたがるコードベース、Agentに理解させるのは大変ですよね。

室谷代表取締役

GitHub MCPを使えば、横断検索も可能です。リポジトリまたいで関数の参照を追ったり。

テキトー教師.AI認定講師

現場でよく聞くのが「どのリポジトリに何があるか忘れる」問題。Agentが代わりに探してくれるのは助かります。

室谷代表取締役

結果として、新規参画者のオンボーディングが速くなる。時給換算すると結構なコスト削減になるんですよね。

トラブルシューティング：よくあるエラーと対処法

MCPサーバが認識されない：バージョンと設定の確認

室谷代表取締役

これ、結構あるんですよね。設定したはずのMCPサーバが認識されないケース。

大抵はCursorのバージョンが古いか、設定ファイルの場所が間違ってる。

テキトー教師.AI認定講師

たしかに。フォーラムでも「SettingsにMCPのタブが見当たらない」って声が多くて、原因は古いバージョンってパターンが多かった。

0.46から専用タブになったので、まずは更新を確認するのが手っ取り早い。

室谷代表取締役

設定ファイルも、プロジェクトルートの .cursor/mcp.json か、ユーザー全体の設定かで認識が変わる。ドキュメント通りに書いてるはずなのに動かない時は、ファイルのパスとJSONの構文をもう一度見直した方がいい。

テキトー教師.AI認定講師

そうそう。あと、mcpServers のキー名が間違ってるとか、余計なカンマが付いてるとか、初歩的なミスも意外と多い。

認証エラー：PATとOAuthの再設定手順

室谷代表取締役

GitHub MCPの認証エラーは、トークンの有効期限切れかスコープ不足が主な原因。PATを使うならrepoとread:userは最低限必要。

テキトー教師.AI認定講師

現場でよく聞くのは「先月までは動いてたのに」というパターン。トークンの有効期間を見直すか、OAuthなら再認証を試すといい。

Remoteサーバの場合はOAuthクライアント情報をmcp.jsonに静的に設定する方法もある。

室谷代表取締役

認証周りは地味に時間を取られる。時給換算すると、ちゃんとドキュメント読んで1回で通した方が圧倒的に安い。

テキトー教師.AI認定講師

最初にPATを発行する時は、スコープを絞りすぎないことも大事です。後から追加するより、最初に広めにとっておく方が安心。

ネットワーク問題とプロキシ設定

室谷代表取締役

会社のProxy環境下だとMCPサーバへの接続が通らないケースが多い。Cursor自体のプロキシ設定はOSの設定に従うけど、MCPサーバのコマンドがネットにアクセスできないとタイムアウトになる。

テキトー教師.AI認定講師

npx で起動するサーバだと、npmのレジストリにアクセスできない場合もあります。プロキシ経由なら環境変数 HTTP_PROXY を設定するか、mcp.jsonのenvに明示的に入れると動くことがある。

室谷代表取締役

リモートMCPサーバ（HTTP/SSE）の場合は、URLが間違ってないか、ファイアウォールでポートが塞がれてないかもチェック。localhostで動かすなら問題ないけど、外部サーバだと結構ハマる。

テキトー教師.AI認定講師

とりあえず、curl で同じエンドポイントにアクセスできるか試すのが確実です。そこで通らないならネットワーク設定を見直すしかない。

よくある質問

Q1. MCPを使わずにGitHubと連携する方法と、MCPを使う方法の違いは何ですか？

室谷代表取締役

Cursorには既存のGitHub連携機能もありますよね。でもMCPを使うと、Agentが直接IssueやPRを操作できるので、手動でポチポチしなくて済むんです。

テキトー教師.AI認定講師

現場でよく聞かれるんですが、従来のGitHub連携は基本的にファイルのPull/Pushだけ。MCPだとリポジトリ作成やIssueの管理までコードの流れの中で完結できるんですよ。

Q2. 複数のGitHubアカウントを使い分けたい場合はどうすればいいですか？

室谷代表取締役

設定ファイルmcp.json内で、サーバごとに異なるトークンを使えばいいですね。サーバ名を分けて、それぞれに別のGitHub PATを設定する。

テキトー教師.AI認定講師

これ、意外とハマる人が多いですね。MCPサーバは複数定義できるので、例えばpersonalとworkで分けておけば、切り替えもスムーズです。

Q3. GitHub Enterpriseを使っている場合、MCPは対応していますか？

室谷代表取締役

公式ドキュメントを見ると、GitHub Enterprise向けのAPIエンドポイントが指定できるようです。通常のgithub.com用のサーバ設定の代わりに、独自ドメインを指定すれば動くはず。

テキトー教師.AI認定講師

最初に戸惑うのがその設定ですね。認証方式もPAT一本でいいので、自分でAPIエンドポイントを確認しておけば大丈夫です。

Q4. MCPでGitHubに接続するときのセキュリティ上の注意点はありますか？

室谷代表取締役

PATトークンは読み取り専用と書き込みを分けるのが基本ですね。必要最小限の権限に絞って発行する。

あと、トークンはコードに直接書かずに環境変数から読み込むようにしています。

テキトー教師.AI認定講師

現場感覚で言うと、書き込み権限を与えすぎて事故るケースがあるので、OAuthよりPATの方が制御しやすいかもしれません。

Q5. Cursor以外のエディタ、例えばVS Codeでも同じMCP設定を流用できますか？

室谷代表取締役

MCPのプロトコル自体はエディタ依存じゃないので、同じ設定ファイルは使えますね。ただし、Cursorの設定パス（.cursor/）に置くかどうかはエディタ次第です。

テキトー教師.AI認定講師

初めて触る人は「移植できるの？」って気になりますが、mcp.jsonの内容はそのまま使えます。ただしクライアントによって設定の読み込み場所が違うので注意ですね。

まとめ

室谷代表取締役

今回の流れを整理すると、mcp.jsonにGitHub MCPサーバを追加して認証を通せば、CursorのAgentがGitHubのIssueやPRを自在に扱えるようになるんですよね。

テキトー教師.AI認定講師

たしかに。記事内で紹介した設定を試すだけでも、かなり開発の効率が変わります。

最初はIssueの一覧表示からでもいいと思います。

室谷代表取締役

この連携を突き詰めると、リポジトリの初期化からデプロイまで、Agent任せにできる未来が見えてきますね。

テキトー教師.AI認定講師

実践編でも触れましたが、まずは小さなタスクからMCPを組み込んでみるのがおすすめです。手動と比べてどれだけ楽か体感できるはず。

室谷代表取締役

ぜひ今日の設定を振り返りながら、ご自身のワークフローに取り入れてみてください。