GitHub MCP完全攻略 2026 — Secret Scanning GA・OAuth scope filtering・実運用5つの落とし穴

公式MCPサーバーのスコープと格付け

GitHubは2026年1月28日に公式MCPサーバーの大規模アップデートを行い、現在github/github-mcp-serverとして公開されている。AIエージェント・アシスタント・チャットボットに対し、リポジトリ閲覧、コードファイル読み取り、Issue/PR管理、コード解析、ワークフロー自動化の機能をMCPツールとして提供する。

KanseiLinkのAEO格付けでは、GitHubは Aグレード(Trust score 0.7)。認証OAuth 2.0、ドキュメント整備度、公式MCPサーバー有無、API安定性のいずれも上位だが、レート制限の3層構造(Auth種別×APIファミリー×Secondary制限)が複雑なため、AAグレードには届いていない。

認証3方式の選び方 — PAT / GitHub App / OAuth

GitHub MCPは3つの認証方式をサポートする。本番運用での選び方は明確だ。

2026年1月のアップデートで、Classic PATの場合のみOAuthスコープを自動検知して、使えないツールを非表示にする機能が入った(GitHub Changelog 2026-01-28)。これは『issuesスコープを持たないPATでcreate_issueツールを呼び出してエラーで詰まる』ような事故を防ぐ機械的措置。fine-grained PATは元々スコープが厳密なため、この補助は適用されない設計になっている。

ツール構成 — Repos / Issues / PRs / Projects / Actions / Secret Scanning

GitHub公式MCPサーバーは2026年5月時点で以下の主要ツールセットを提供する(GitHub公式ドキュメント、Changelog 2026-01-28・2026-05-05による)。

• Repository Management — リポジトリ閲覧、コード検索、コミット解析、ファイル取得
• Issue & PR Automation — Issue/PRの作成・更新・コメント・マージ
• Projects (2026-01-28追加) — projects_list / projects_get 等の統合ツールでGitHub Projectsを扱う
• CI/CD & Actions Intelligence — ワークフロー実行確認、ビルド失敗解析、リリース管理
• Code Analysis — Dependabotアラート確認、セキュリティ調査
• Secret Scanning (2026-05-05 GA) — コミット前/PR作成前のシークレット検出 ✅
• Insiders Mode (opt-in) — 実験的・プレビュー機能の早期利用

2026年5月5日 Secret Scanning GAの意味

2026年5月5日に公式リリースされたSecret ScanningのGA(GitHub Changelog)は、AIコーディング時代の最終防衛線として重要だ。エージェントがコミットを作成する前にコード内のAPIキー・トークン・認証情報を検出するツールが公式MCP経由で呼べる。Cursor、Claude Desktop、VS Code、Copilot等のMCP対応IDE/エディタから直接利用できるため、「エージェントがシークレットを誤ってコミットする事故」を構造的に減らせる変化だ。

レート制限の3層構造とGraphQL最適化

GitHubのレート制限は単一の数字ではなく、3層に分かれている。

1. Primary Rate Limit — 認証単位の毎時上限(PAT 5,000 / GitHub App 15,000)。REST + GraphQLが合算される。
2. Search API個別上限 — 30リクエスト/分という別枠の厳しい制限。コード検索・Issue検索を多用するエージェントで真っ先に詰まる。
3. Secondary Rate Limit — 短時間の連続アクセスや並列度過剰でabuse判定された場合の動的制限。HTTPステータス403で返ることもあり、Retry-Afterヘッダで指示される。

quotaを温存する3つの実装パターン

// 1. X-RateLimit-Remainingヘッダを毎回確認
const remaining = parseInt(res.headers['x-ratelimit-remaining'] || '5000');
if (remaining < 100) {
  // 100以下なら非クリティカルな処理を遅延
  await scheduleLowPriorityRetry();
}

// 2. ETag / If-None-Match で条件付きリクエスト → 304ならquota消費なし
const cached = cache.get(`gh:${url}`);
const headers: Record = {
  'Authorization': `Bearer ${token}`,
  'X-GitHub-Api-Version': '2022-11-28',
};
if (cached?.etag) headers['If-None-Match'] = cached.etag;

const res = await fetch(url, { headers });
if (res.status === 304) return cached.body; // quota消費0

// 3. 大量読み取りはGraphQL v4で1クエリ集約
// REST: repo情報 + issues + PRs + commits = 4呼び出し
// GraphQL: 1 query で全部 → quota 25%削減

実運用5つの落とし穴

落とし穴1: 1MB超のファイルが読めない

Contents API(/repos/{owner}/{repo}/contents/{path})はBase64エンコードで1MBまで。大きいJSON、ビルドログ、PDFファイル等はGit Data API blobs(/repos/{owner}/{repo}/git/blobs/{file_sha})へフォールバックが必須。公式MCPサーバー経由なら自動分岐するが、直接REST呼び出し時は明示実装が必要。

落とし穴2: Search APIで頻繁に詰まる

30リクエスト/分の別枠制限。コード検索を連続実行するエージェントは1分以内に詰まる。対処は(a)結果キャッシュ、(b)検索クエリ集約(複数クエリを1つに統合)、(c)GraphQL v4のsearchクエリへ移行。

落とし穴3: Issue/PR番号の混同

GitHubのissue_numberとpr_numberはリポジトリ単位で連番(グローバルにユニークではない)。複数リポジトリを横断するエージェントは必ず{owner}/{repo}でスコープすること。「PR #42」だけを保持してしまい後で参照不能になるバグが頻出する。

落とし穴4: Classic PATの権限漏洩

Classic PATはユーザーが所属する全リポジトリに適用される。1つのリポジトリ用に発行したつもりでも、漏洩時には組織全体のリポジトリにアクセスされる。最小権限原則のためにfine-grained PATへの移行が2026年標準。

落とし穴5: ETagを使わずに条件付きキャッシュを失う

リポジトリのIssue一覧を5分ごとにポーリングするエージェントが、変化がないのに毎回フルレスポンスを取得すると、quotaが急減する。ETag + If-None-Matchで304を受ければquota消費なしでキャッシュヒット可。これは公式が推奨するベストプラクティスだ。

Enterprise HTTPモードと共有MCP戦略

2026年1月のリリースで、GitHub MCPサーバーにHTTPサーバーモードが追加された(GitHub Changelog 2026-01-28)。OAuthトークンをAuthorizationヘッダで都度受け取り、Enterprise Server互換でも動作する。

これが意味するのは、「社内に1台のGitHub MCPサーバーを立て、複数エージェントがOAuth tokenで個別認証する」共有MCP構成が公式に可能になったこと。各エージェントが個別にnpx起動する従来構成と比べて、(1) 認証ローテーションが集中管理できる、(2) ロギング・監査が一元化、(3) Secondary Rate Limit回避のためのスマート分配、を実現できる。

本番チェックリスト

• fine-grained PAT または GitHub App で認証している(Classic PATは新規利用しない)
• X-GitHub-Api-Version: 2022-11-28 ヘッダを必ず付与している
• X-RateLimit-Remaining を毎回確認し、低下時は非クリティカルな処理を遅延させている
• ETag / If-None-Match で条件付きリクエストを実装している
• 大量読み取り(>5回)はREST個別呼び出しではなくGraphQL v4で1クエリに集約している
• Search API利用箇所はキャッシュ + クエリ集約で30/分制限を超えない設計になっている
• Issue/PR番号は {owner}/{repo} でスコープして保持している
• 1MB超のファイルはContents API失敗 → Git Data API blobsへフォールバック実装済み
• Secret Scanning(2026-05-05 GA)を採用してコミット前/PR前にシークレット検出している
• 本番組織展開ではGitHub App + HTTPモードで共有MCP構成を検討した

FAQ

Q1. GitHub MCPサーバーはどう導入するのが最速ですか?

個人・PoCは fine-grained PAT を発行してnpx @github/mcp-serverを起動。組織展開はGitHub App(15,000リクエスト/時)を作成しインストール。Enterprise/組織共有はHTTPサーバーモード+OAuthトークン転送が2026年4月以降の推奨構成。

Q2. fine-grained PATとClassic PAT、どちらを使うべき?

原則fine-grained。Classicは全リポジトリに適用されるため漏洩時の被害が広い。fine-grainedは対象リポジトリ・権限・有効期限を細かく制御できる。2026年新規導入時にClassicを選ぶ理由はない。

Q3. 2026年5月にGAしたSecret Scanning統合とは?

2026年5月5日(GitHub Changelog)、GitHub MCPサーバーのSecret ScanningがGA。エージェントがコミット/PR前にコード内のAPIキー・トークン・認証情報を検出する。MCP対応IDEから直接呼べるため、AIコーディング事故を構造的に防げる重要な変化。

Q4. GitHub MCPのレート制限はどのくらい?

(1) PAT: 5,000リクエスト/時(REST+GraphQL合算)、(2) GitHub Appインストール単位: 15,000リクエスト/時、(3) Search API: 30/分(別枠)、(4) Secondary制限はabuse判定時に発動。X-RateLimit-Remainingヘッダ確認・ETag条件付きリクエスト・GraphQL集約の3点でquotaを温存。

Q5. 1MB超のファイルはどう取得?

/repos/.../contents/{path}は1MBまで。それ以上はGit Data API blobs(/repos/.../git/blobs/{file_sha})にフォールバック。公式MCPサーバー経由なら自動処理されるが、直接REST呼び出し時は明示実装が必要。

Q6. KanseiLinkはGitHub MCPをどう評価していますか?

KanseiLinkのAEO格付けはAグレード(Trust score 0.7)。公式MCPサーバー、OAuth/PAT/App 3方式の認証、ドキュメント整備、API安定性で高評価。AAグレードに届かない要因はレート制限の3層構造(認証種別×APIファミリー×Secondary)の複雑さ。開発者ツール AEO比較 2026でGitLab・AWS・Playwrightと並べた格付けレポートを公開している。