エンジニアと一緒に仕事をしているマーケや企画担当の方から、こんな相談を受けることがあります。「GitHubにIssue(社内の課題チケットのようなもの)が溜まっているけど、自分で開いて全部読むのは厳しい」「PR(変更案)の流れを横で把握したい」と。
Claude CodeとGitHubをつなげば、こうした作業の手助けが現実的になります。この記事は、その接続と運用を整理したものです。エンジニアの作業効率化はもちろん、エンジニアと並走するビジネス側にも効く話です。
人がいない時間に動かすならGitHub Actions上でClaude Codeを動かすのほうが近い話をしています。
GitHubの情報をAIに渡す仕組みが整った
これまでもAPI経由でGitHubの情報を取りに行く方法はありましたが、Claude CodeとGitHubを行儀よくつなぐ標準的な方法として、MCP(AIに外部サービスをつなぐ共通仕様)サーバーが定番化しました。サーバーというのは、つなぎ役の小さなプログラムのことです。
MCPは、Notion、AWS、Figmaなど、それぞれのサービス用に個別のサーバーが用意されている仕組み。GitHubもその一部、と捉えると分かりやすいです。MCP設定の基本は別記事に整理しました。
GitHub MCPサーバーで何ができるか
ここからGitHubの用語が並びます。Issue(課題チケット)、PR(変更の提案)、コミット(変更の保存履歴)、差分(変更前後の比較)、と読み替えてください。
サーバー実装によりますが、できることはおおむね次のとおりです。
- リポジトリ(コードをまとめて置いてある場所)のIssueの検索・読み込み
- Pull Request(PR)の一覧と差分の取得
- コミット履歴の参照
- リポジトリ内のファイル内容の取得
- IssueやPRへのコメント書き込み(権限による)
「コードを読んで提案する」だけでなく、「Issueを起点に差分を提案する」「PRレビューの観点を抜き出す」といった、運用と密接な使い方ができます。
どのGitHub MCPサーバーを使うか
2026年5月時点での標準は、GitHub公式の github/github-mcp-server です。リモート版とローカル(Docker)版があり、まずはこれを試すのがおすすめです。
リファレンス実装は modelcontextprotocol/servers リポジトリにあり、こちらも以前はGitHub向けサーバーを含んでいました。現状の主流はGitHub公式のほうで、迷ったらそちらを選ぶ、で問題ありません(細かい話なので非エンジニアの方は読み飛ばしてOKです)。
接続用のPersonal Access Tokenとスコープの選び方
GitHub MCPサーバーは、あなたのGitHubアカウントの権限で動きます。認証用にGitHubの Personal Access Token(あなた専用の合鍵のようなもの) を発行して、サーバーに渡す必要があります。
GitHubには2系統のトークンがあり、古くからあるClassic PATと、新しい Fine-grained PAT。現在はFine-grained PATが推奨で、これから新規発行するならFine-grained PATを選ぶのが無難です。
トークン発行時に、どの操作を許可するか(スコープ=合鍵で何ができるかの範囲)を選ぶ画面が出ます。最小権限の原則で絞ります。
Classic PATの場合
- プライベートリポジトリも読む → repo スコープ
- 公開リポジトリだけ → public_repo スコープ
- 組織横断のメタ情報も追加 → read:org スコープを足す
Fine-grained PATの場合(Repository permissions)
- Contents を Read-only
- Issues を Read-only
- Pull requests を Read-only
- コメント書き込みが要れば該当項目を Read and write へ
APIキーの扱いと考え方は同じです。
設定の流れの大まかな型
設定の流れは、ふつうのMCPサーバーと同じ3段階です。
- GitHub公式のMCPサーバーを準備(リモート版を使うか、Docker版をローカルで起動)
- 設定ファイル(
.claude/settings.jsonというテキストファイル)にサーバーの登録情報とトークンを書く - Claude Codeを再起動して、サーバーが認識されているか確認
具体的な設定値は、公式リポジトリのREADMEに従うのが確実です。
ハマりやすい3つの落とし穴
私が運用してつまずいた箇所を書きます。
ひとつめは、トークンのスコープ不足。Issue読み取りはできるのに、コメント書き込みで弾かれる、というのが典型的な発生パターン。エラーメッセージにスコープ名が出るので、それを参考に追加します。
ふたつめは、レートリミット(一定時間に呼び出せる回数の上限)。Claudeが繰り返しGitHubのAPI(外部から自動で操作するための窓口)を呼ぶと、短時間で上限に当たります。重い処理を頼む時は、対象リポジトリやIssue範囲を絞って渡すと衝突を避けられます。
みっつめは、組織所有のリポジトリでのSAML認可。SAML(会社で導入されているシングルサインオン経由の追加認証)が有効なorg(GitHub上の会社アカウント)では、トークン発行後にorgで認可する操作が要ります。これを忘れると、トークンは有効なのにリポジトリにアクセスできない、という詰まり方をします。
私の業務での使いどころ
参考までに、いまの私の運用です。
毎週、自社リポジトリの未対応Issueを抽出する作業は、Claude CodeにGitHub MCP経由で頼んでいます。手で見るより速いし、優先度の傾向まで指摘してくれる。
業務委託先のリポジトリのPRを横断的にレビューする時も、GitHub MCP経由で複数PRの差分を一度に読ませて、共通の論点を抜き出してもらいます。レビュー所要時間が体感で4割減りました。
まとめ
- GitHub MCPサーバーで、Claude CodeとGitHubの情報を行儀よくつなげる
- 2026年現在の標準はGitHub公式の
github/github-mcp-server - 接続にはPersonal Access Tokenが必要。Fine-grained PATが推奨
- 読み取り中心ならClassicは
repo(またはpublic_repo)、Fine-grainedは Contents を Read-only など - 設定はサーバー準備+トークン受け渡し+再起動の3段階
- 落とし穴はスコープ不足・レートリミット・SAML認可の3つ
