GitHub MCP — ユースケース, インストール & ライブデモ

Name: GitHub MCP Server
Author: github

なぜ使うのか

主な機能

第一者により提供 — GitHub が公開・署名しています
読み取り専用モードで安全に探索でき、書き込みツールは明示的なオプトインが必要です
きめ細かい PAT サポート — 特定のリポジトリとアクセス権セットにスコープ設定できます
GitHub Search API 経由のコード検索を含みます
署名付き Docker イメージとして配布され、検証されていないコードの npm install は不要です

ライブデモ

実際の動作

github.replay ▶ 準備完了

0/0

インストール

クライアントを選択

~/Library/Application Support/Claude/claude_desktop_config.json · Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "github": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e",
        "GITHUB_PERSONAL_ACCESS_TOKEN",
        "ghcr.io/github/github-mcp-server"
      ]
    }
  }
}

Claude Desktop → Settings → Developer → Edit Config を開く。保存後、アプリを再起動。

~/.cursor/mcp.json · .cursor/mcp.json

{
  "mcpServers": {
    "github": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e",
        "GITHUB_PERSONAL_ACCESS_TOKEN",
        "ghcr.io/github/github-mcp-server"
      ]
    }
  }
}

Cursor は Claude Desktop と同じ mcpServers スキーマを使用。プロジェクト設定はグローバルより優先。

VS Code → Cline → MCP Servers → Edit

{
  "mcpServers": {
    "github": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e",
        "GITHUB_PERSONAL_ACCESS_TOKEN",
        "ghcr.io/github/github-mcp-server"
      ]
    }
  }
}

Cline サイドバーの MCP Servers アイコンをクリックし、"Edit Configuration" を選択。

~/.codeium/windsurf/mcp_config.json

{
  "mcpServers": {
    "github": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e",
        "GITHUB_PERSONAL_ACCESS_TOKEN",
        "ghcr.io/github/github-mcp-server"
      ]
    }
  }
}

Claude Desktop と同じ形式。Windsurf を再起動して反映。

~/.continue/config.json

{
  "mcpServers": [
    {
      "name": "github",
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e",
        "GITHUB_PERSONAL_ACCESS_TOKEN",
        "ghcr.io/github/github-mcp-server"
      ]
    }
  ]
}

Continue はマップではなくサーバーオブジェクトの配列を使用。

~/.config/zed/settings.json

{
  "context_servers": {
    "github": {
      "command": {
        "path": "docker",
        "args": [
          "run",
          "-i",
          "--rm",
          "-e",
          "GITHUB_PERSONAL_ACCESS_TOKEN",
          "ghcr.io/github/github-mcp-server"
        ]
      }
    }
  }
}

context_servers に追加。保存時に Zed がホットリロード。

claude mcp add github -- docker run -i --rm -e GITHUB_PERSONAL_ACCESS_TOKEN ghcr.io/github/github-mcp-server

ワンライナー。claude mcp list で確認、claude mcp remove で削除。

ユースケース

実用的な使い方： GitHub

良い最初のイシューを見つけて 1 時間で修正をマージする方法

👤 摩擦の少ない初回 PR を探しているオープンソースコントリビューター ⏱ ~60 min beginner

使うタイミング： プロジェクトに貢献したいが、どこから始めればよいかわかりません。メンテナーの CONTRIBUTING.md は汎用的すぎて役に立ちません。

前提条件

repo:read と issues:read を持つ GitHub PAT — github.com/settings/tokens — きめ細かく、貢献したいリポジトリにスコープ設定します
filesystem MCP もインストール済みであること — Claude がリポジトリをローカルにクローンして読み取り、実際に修正を書き込めるようになります

フロー

good first issue にマークされたコメントなしのイシューを見つけるよう Claude に依頼します。シンプルさでソートします

Find open issues in modelcontextprotocol/servers labeled 'good first issue' with no assignee and zero comments. Pick the one that looks easiest to fix and explain why.✓ コピーしました

→ Claude が 3～5 個の候補を返し、それぞれ 1 行の難易度評価を付けます
Claude にイシュー本文と関連するコードを取得させます

Pull the full issue body for #<num> and read the file it mentions. Tell me the actual change that needs to happen.✓ コピーしました

→ 具体的な diff の意図。イシューの単なる言い換えではなく
filesystem MCP を使用してエディットしてから、GitHub MCP を使用して PR を作成します

Apply the change, write a PR description that thanks the maintainer and explains the fix in 3 sentences.✓ コピーしました

→ PR が開き、リンクが返されます

結果： プロジェクトのスタイルを尊重し、イシューを参照し、同日マージ可能なサイズのオープン PR。

注意点

Claude が実は 2 年間ずっと放置されていた 'good first issue' を選んでしまった。これは修正について誰も同意できなかったからです。 — 過去 90 日間にメンテナーからの新しいコメントがない をフィルターとして追加します
PR 本文が汎用的な AI の話し方になってしまった — 最初にプロジェクトの最後の 3 つのマージ済み PR のトーンを模倣するよう Claude に指示します

組み合わせ： filesystem · git

チームの週間 PR ダイジェストを生成します

👤 エンジニアリングマネージャー、テックリード ⏱ ~10 min intermediate

使うタイミング： 毎週月曜朝に、40 個の PR 通知をクリックして回りたくないときに

前提条件

pull_requests:read でチームのリポジトリにスコープ設定された PAT — きめ細かいトークンを使用します。従来の 'all repos' トークンは使用しないでください

フロー

先週マージされた PR と差分サイズを依頼します

List all PRs merged into our org/repo between last Monday and today. Include author, +/- lines, and one-line summary.✓ コピーしました

→ 10～30 行のテーブル（具体的なデルタ付き）
著者とテーマでグループ分けします

Group these by area (auth, payments, frontend, infra...) and flag any that look like reverts or hotfixes.✓ コピーしました

→ テーマクラスタリングを含むセクション
Slack 対応のダイジェストを作成します

Now write a Slack post summarizing the week — celebrate the big wins, call out the risky changes, name the people who shipped them.✓ コピーしました

→ @mentions と emoji を含む Markdown。貼り付け準備完了

結果： 月曜朝に実際に読みたくなる 5 個の要点の概要。

注意点

組織に多くのレポジトリがある場合、レート制限に達します — 一度に 1 つのリポジトリにフィルタリングするか、GitHub App トークンにアップグレードします（15k req/h vs 5k）

組み合わせ： linear · sentry

コードベースが非推奨 API を使用している場所をすべて見つけます

👤 マイグレーションを計画しているバックエンドエンジニア ⏱ ~30 min intermediate

使うタイミング： 内部クラス/関数を非推奨にしようとしており、発表前に誰が使用しているかを知る必要があります。

前提条件

組織内のすべてのリポジトリに対する repo:read を持つ PAT — GitHub App を組織全体へのアクセスに使用します。リポジトリごとの PAT をやり繰りするより簡単です

フロー

組織全体でコード検索を使用します

Search across our entire acme-corp org for any usage of the LegacyAuth class. Return file paths grouped by repo.✓ コピーしました

→ リポジトリとファイルのリスト（行番号付き）
各マッチについて、コンテキストを取得します

For each match, fetch 5 lines around the usage and tell me whether it's a real call or just a comment/import.✓ コピーしました

→ 実際の呼び出しをノイズから区別するフィルター済みリスト
マイグレーション追跡イシューを生成します

Create a tracking issue in acme-corp/platform titled 'Migrate off LegacyAuth' with a checklist of every real callsite and the team that owns each repo.✓ コピーしました

→ 包括的なチェックリスト付きで作成されたイシュー

結果： プラットフォームチームがマイグレーションを進めるために使用できる、唯一の信頼できる情報源となる追跡イシュー。

注意点

コード検索はクエリあたり 1000 件の結果の上限があり��す — 上限に達した場合は、言語またはパスで絞り込みます。LegacyAuth language:python またはリポジトリプレフィックスでクエリを分割します
GitHub はデフォルトブランチのみをインデックス化します — フィーチャーブランチの使用は見つかりません。クローン済みリポジトリでローカル grep で補助します

組み合わせ： filesystem

承認前に複雑な PR の第二意見を取得します

👤 専門分野外の PR に直面しているコードレビューアー ⏱ ~15 min intermediate

使うタイミング： よく知らないコードに触れている PR のアサインされたレビューアーで、単にゴム印を押したくない場合

フロー

PR の差分と説明を取得します

Fetch PR #<num> in org/repo — give me the diff and the description. What's the author claiming this does?✓ コピーしました

→ 意図の明確な言い換え
アーキテクチャの読み取りを依頼します

Now look at the existing files this PR touches. Does the change fit the existing patterns, or does it introduce a new one? If new, is the new pattern justified?✓ コピーしました

→ 汎用的な賞賛ではなく、具体的な指摘
リスクを調査します

Where in this diff is something most likely to break in production 6 months from now? Be specific — point to the line.✓ コピーしました

→ 'テストをさらに追加' ではなく、具体的な行レベルの懸念

結果： PR に投稿できる 3 つの具体的で実行可能なコメント。さらりと見るより、レビューを大幅に向上させます。

注意点

Claude がイエスマシンになり、すべてを賞賛します — 'この会社のシニアエンジニアは何に異議を唱えるでしょうか？' と明示的に質問します。対立的なフレーミングが役立ちます

組み合わせ： filesystem

レビューで腐っている PR を特定して解決します

👤 エンジニアリングリード、リポジトリメンテナー ⏱ ~20 min beginner

使うタイミング： 1 スプリント 1 回。PR が誰にも気づかれずに静かに経年劣化していると疑われるときに

フロー

5 日以上オープンで最近のアクティビティがない PR をリストします

Find open PRs in org/repo last updated more than 5 days ago. For each, tell me the author, the assigned reviewer, and the stated reason for delay (look at the last comment).✓ コピーしました

→ PR ごとの診断付きテーブル
遅延を分類します

Group these into: 'waiting on reviewer', 'waiting on author', 'waiting on CI', 'waiting on decision'. Be specific about which.✓ コピーしました

→ 各カテゴリに具体的な PR が 4 つ
軽く促すドラフトを作成します

For the 'waiting on reviewer' bucket, draft a polite nudge comment for each. Different tone if the reviewer is a peer vs senior to the author.✓ コピーしました

→ PR ごとのコメントテキスト。貼り付け準備完了

結果： 15 分でブロック解除できる短い PR のリスト。PR ごとの具体的なアクション付き。

注意点

自動投稿コメントはスパムのように見えます — Claude にコメントのドラフトを作成させ、自分で投稿します。人間をループに保ちます

組み合わせ： linear

組み合わせ

他のMCPと組み合わせて10倍の力を

github + sentry

Sentry が新しいエラーを表示 → GitHub MCP がリリースタグ経由でそれを導入したコミットを見つけ → ホットフィックス PR を 1 つのチャットで作成

There's a new error in Sentry — issue WEB-3a91. Find which commit on main introduced it (cross-reference the release tag), then draft the smallest possible revert PR.✓ コピーしました

github + linear

GitHub バグレポートから適切なラベルと優先度で Linear イシューを自動作成します

For every issue opened in our octocat/api repo this week with label 'bug', create a matching Linear issue in the BACKEND team with priority Medium.✓ コピーしました

github + filesystem + git

エンドツー��ンドコントリビューション。リポジトリをローカルにクローンして、変更を加え、ブランチをプッシュして、PR をオープンします。チャットを離れることなく

Clone acme/widgets locally, fix the typo in src/utils/format.ts:42, push to a new branch, open a PR.✓ コピーしました

ツール

このMCPが提供する機能

ツール	入力	呼び出すタイミング	コスト
search_issues	owner: str, repo: str, labels?: str[], state?: str	ラベル、状態、アサイン者、またはアクティビティでイシューを見つけたい場合	1 API 呼び出し
get_issue	owner: str, repo: str, issue_number: int	search_issues 後に、完全な会話が必要な場合	1 API 呼び出し
create_issue	owner, repo, title, body, labels?, assignees?	新しいイシューを報告します。ユーザーが実際にこれを望んでいることを確認します	1 API 呼び出し（書き込み）
list_pull_requests	owner, repo, state?, sort?, base?, head?	状態/ブランチ/著者で PR を見つけます	1 API 呼び出し
get_pull_request	owner, repo, pull_number	特定の PR の差分とメタデータを読みます	1 API 呼び出し
merge_pull_request	owner, repo, pull_number, merge_method?	明示的に指定されたときのみ。最初にドライランディスカッションを使用します	1 API 呼び出し（書き込み、取り消し不可）
search_code	q: str, sort?	組織全体でシンボル使用法を見つけます	1 API 呼び出し（レート制限が低い: 30/分）
get_file_contents	owner, repo, path, ref?	クローンしないでリポジトリから単一ファイルを読みます	1 API 呼び出し
create_or_update_file	owner, repo, path, message, content, sha?	1 回限りのファイル編集。複数ファイルの変更にはブランチ + PR を使用します	1 API 呼び出し（書き込み）
list_commits	owner, repo, sha?, path?	ファイルまたはブランチの履歴を監査します	1 API 呼び出し

コストと制限

運用コスト

APIクォータ: 個人用 PAT: 5,000 リクエスト/時間。GitHub App: 15,000/時間。コード検索: 個人用 30/分（別途）
呼び出しあたりのトークン: issue/PR メタデータ: 200～500 トークン。大規模ファイル取得時は 5k 以上になることがあります
金額: 任意の GitHub アカウントで無料です。GitHub Enterprise はより高い制限があります。
ヒント: 制限に達している場合は、GitHub App に切り替えます。複数の PAT をやり繰りするより簡単で、3 倍の速度が得られます。反復処理時に list_issues の結果をキャッシュします。

セキュリティ

権限、シークレット、影響範囲

最小スコープ： repo:read issues:read

認証情報の保管： 環境変数（例：GITHUB_PERSONAL_ACCESS_TOKEN）にきめ細かい PAT を格納します。dotfiles にコミットしないでください。

データ送信先： すべての API 呼び出しは api.github.com へのみです。サードパーティのテレメトリはありません。

絶対に付与しない： admin:org delete_repo admin:enterprise

従来の 'all repos' トークンではなく、特定のリポジトリにスコープ設定されたきめ細かい PAT を使用します。
プロンプトを信頼するまで、書き込みツール（issues:write、pulls:write）を無効にします。

トラブルシューティング

よくあるエラーと対処法

401 Unauthorized

PAT の有効期限が切れているか、そのリポジトリへのアクセス権がありません。github.com/settings/tokens で正しいスコープを使用して再作成します。

確認： curl -H "Authorization: Bearer $GITHUB_PERSONAL_ACCESS_TOKEN" https://api.github.com/user

403 レート制限超過

個人用 PAT で 5000 req/h に達しました。リセットウィンドウまで待つか、GitHub App トークンに移行します（15k/h）。

確認： curl -H "Authorization: Bearer $TOKEN" https://api.github.com/rate_limit

404 プライベートリポジトリで見つかりません

PAT の許可リポジトリリストにそのリポジトリが含まれていません。きめ細かい PAT を編集して、リポジトリを追加します。

Docker: 'イメージが見つかりません'

最初にイメージをプルします: docker pull ghcr.io/github/github-mcp-server。プライベートの場合は ghcr.io に認証されていることを確認します。

確認： docker images | grep github-mcp-server

代替案

GitHub 他との比較

代替案	代わりに使う場面	トレードオフ
GitLab MCP	GitLab.com またはセルフホスト GitLab を GitHub の代わりに使用している	機能が少なく、コミュニティメンテナンス
Gitea MCP	セルフホスト Gitea インストール	公式 GitHub MCP と比較してツール制限がある
git MCP	リモートなしでローカル git 操作（status、log、diff、blame）が必要なだけの場合	issues、PR、またはリモート操作がありません。認証なしでローカルリポジトリで動作します

その他

リソース

📖 GitHub の公式 README を読む

🐙 オープンな issue を見る

🔍 400以上のMCPサーバーとSkillsを見る