GitHub MCPでIssueとPRを任せる｜トークン権限の絞り方

GitHub公式のMCPサーバーは、Issue起票やPull Requestのレビューを、AIエージェントに直接接続できるようにします。接続そのものはコマンド1行で終わりますが、どこまでの操作を任せてよいかは別の判断です。本記事は、GitHub公式リポジトリとドキュメント、fine-grained personal access token（以下PAT）の仕様をもとに、権限の絞り方を整理します。

あわせて、自社の承認ゲート設計から、任せない方がよい操作の線引きも示します。自環境でGitHub MCPを接続・実行した記録はなく、公式ドキュメントの記載を根拠に書いています。

確認環境は、GitHub MCP Server公式リポジトリと関連ドキュメント、GitHubのfine-grained PAT公式ドキュメントです。時点は2026-07-29です。

01結論：GitHub MCPでIssueとPRをどこまで任せられるか（3行）

結論は3点です。

1. GitHub MCPには21種類のツールセットがあります（2026-07-29に公式リポジトリで確認）。Issue・PR以外にファイル操作やActionsの実行まで扱えるため、任せる範囲はツールセット単位・ツール単位で絞ります。
2. トークン権限はfine-grained PATで絞れます。権限カテゴリはIssues・Pull requests・Contents・Administrationなどです。カテゴリごとにno access・read・writeを選べます（出典: GitHub公式ドキュメント）。GitHub MCP自体ではなく、渡すトークン側で権限の天井を決めます。
3. マージ・ファイル削除・ワークフロー実行は取り消しにくい操作にあたるため、自社の承認ゲート設計（可逆性・対外性の2軸）をそのまま当てはめ、人間ゲートに残します。

MCP全般の選び方は『MCPの選び方｜権限と提供元で見る判断軸5つ』の5軸で判定します。本記事はその5軸のうち権限範囲を、GitHub MCP1本に絞って掘り下げます。承認ゲートの設計思想そのものは『AIエージェントの承認ゲート｜送信・公開・削除で止める仕組み』で扱った可逆性・対外性の2軸を、Issue・PR操作に当てはめ直したものです。

02GitHub公式MCPで何ができるか｜ツールセット一覧と実装の実態

GitHub MCPは、GitHub公式のMCPサーバーです（出典: GitHub公式リポジトリ）。リモートホスト型サーバー（https://api.githubcopilot.com/mcp/）、Docker、ローカルバイナリのいずれかで動きます。AIツールがGitHubのプラットフォームへ直接つながり、自然言語でリポジトリ管理・Issue/PR操作・CI/CD実行を進められると説明されています（出典: 同）。

ツールは機能ごとに「ツールセット」というグループに分かれています。--toolsetsフラグまたはGITHUB_TOOLSETS環境変数で、有効にするグループを絞れます（出典: GitHub公式リポジトリ）。有効化するツールセットを絞ると、LLMがツールを選びやすくなり、コンテキストサイズも減ると明記されています（出典: 同）。

何も指定しない場合の既定は、context・repos・issues・pull_requests・usersの5ツールセットです（出典: GitHub公式リポジトリ）。つまり接続しただけの状態でも、ファイルの作成・更新・削除まで含むreposツールセットが既に有効になっています。

Issue・PRに絞りたい場合は、既定値を使わず明示的に指定します。

# Issue・PR関連ツールだけを有効にする例
GITHUB_TOOLSETS="context,issues,pull_requests" ./github-mcp-server

書き込み系のツールを一切使わせたくない場合は、サーバー起動時に読み取り専用モードへ切り替えられます。「--read-onlyを指定すると読み取り専用のツールだけが提供され、変更を防ぐ」と明記されています（出典: GitHub公式リポジトリ）。トークン側の権限を絞る前に、まずサーバー側のこの1行で書き込みそのものを止める選択肢があります。

03GitHub MCPサーバーへの3つの接続経路｜リモート・Docker・バイナリ

GitHub MCPには、性質の異なる3つの接続経路があります。

1. リモートホスト型：https://api.githubcopilot.com/mcp/へHTTP接続します。初回はOAuthでログインし、サーバー自体の実行・更新はGitHub側が担います（出典: GitHub公式リポジトリ）。
2. Dockerイメージ：ghcr.io/github/github-mcp-serverをローカルで実行します。PATを環境変数として渡します（出典: 同）。
3. ローカルバイナリ：ビルド済みの実行ファイルを直接動かします。社内ネットワークから出したくない場合に使う経路です。

Docker経由の起動コマンドは次の形です（出典: GitHub公式リポジトリ）。

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

Claude Code側からリモートホスト型を追加する場合、HTTPトランスポートのMCP追加コマンドを使います。書式は『MCPの選び方』で扱ったproject scope追加の構文と同じです。

# リモートホスト型のGitHub MCPをproject scopeで追加する例
claude mcp add --transport http github https://api.githubcopilot.com/mcp/ --scope project

# 追加したサーバーとツールセットの承認状態を確認する
claude mcp list

project scopeで追加すると.mcp.jsonはGit管理下に置かれます。ただし接続の承認操作は、各メンバーが自分の端末で個別に行います（出典: Claude Code公式ドキュメント）。チームで同じGitHub MCPを共有しても、承認は1人ずつ必要です。

リモート版には読み取り専用モードの指定方法もあります。URLの末尾に/readonlyを足すか、X-MCP-Readonlyヘッダーを付けます（出典: GitHub公式リポジトリ）。ツールセットも同様に、URLパスの/x/{toolset}かX-MCP-Toolsetsヘッダーで絞り込めます（出典: 同）。ローカル版の--toolsetsフラグと、できることはほぼ同じです。

04fine-grained PATでどこまで絞るか｜GitHub MCPに渡す前の5チェック

GitHub MCPが実際に何をできるかは、サーバー側の設定だけでなく、渡したトークンの権限で決まります。GitHubのfine-grained PATは、リポジトリ権限を1つずつ選んで発行できるトークンです。権限ごとに「read」「write」「admin」のいずれかを設定できますが、全ての権限が全レベルに対応しているわけではありません（出典: GitHub公式ドキュメント）。

Issue・PR運用でまず見る5つの権限カテゴリは次のとおりです。

（出典: GitHub公式ドキュメント「fine-grained personal access token向け権限一覧」）

Issue起票とPRレビューだけを任せる場合、IssuesとPull requestsをwriteにします。Contentsはread、Administrationはno accessにします。この組み合わせが、権限範囲としては最も狭くなります。マージまで任せる場合もPull requestsのwriteが前提で、Contentsのwriteまでは不要です。

トークン発行時には、権限カテゴリ以外にも絞れる項目があります。

• リポジトリ範囲：「Only select repositories」を選び、対象リポジトリを個別に指定します（出典: GitHub公式ドキュメント）。組織全体ではなく、Issue/PR運用を任せたいリポジトリだけに限定できます。
• 有効期限：無期限も設定できますが、組織側の最大有効期間ポリシーでブロックされる場合があります（出典: 同）。
• 組織の承認：組織がfine-grained PATの承認を必須にしている場合、発行直後は「pending」状態になります。管理者が承認するまで、公開リソースにしかアクセスできません（出典: 同）。

古い形式のclassic PATは、repoのような1つのスコープでリポジトリ操作をまとめて許可します。GitHub公式リポジトリのREADMEでは、PAT設定にGITHUB_PERSONAL_ACCESS_TOKEN環境変数を使います。ここに渡すのがclassic PATかfine-grained PATかで、許可される操作の粒度が変わります。Issue・PRだけを任せたい場面では、権限を個別に選べるfine-grained PATのほうが、絞り込みの単位が細かくなります。

05Issue起票をGitHub公式MCPに任せる範囲と、任せない操作

Issue操作は、PR操作に比べると取り消しやすい部類に入りますが、境界はあります。GitHub REST APIには、Issueそのものを削除するエンドポイントは用意されていません（出典: GitHub公式ドキュメント「Issues」）。用意されているのはPATCHでの更新で、stateをclosedにするクローズ操作までです（出典: 同）。つまりGitHub MCP経由でも、Issueの完全削除はできません。

一方で、公開リポジトリのIssueは、作成した瞬間から第三者にも見えます。社内情報を書いてしまった場合、クローズしても本文は残り、検索エンジンやフォークに複製が渡っている可能性があります。削除できない設計だからこそ、作成前のチェックのほうが重要になります。

任せる範囲は、可逆性・対外性の2軸（出典: 自社の承認ゲート設計）で仕分けます。

自社の運用ルールでは、送信・公開・削除・決済/契約の4カテゴリを承認ゲートの対象としています。公開リポジトリへのIssue作成は「公開」に近い性質を持つため、社内向けリポジトリでの下書き作成とは扱いを分けます。

06PRレビューをGitHub MCPサーバーに任せる範囲と、任せない操作

PR操作は、Issue操作よりも影響範囲が広がります。理由は、マージという1操作でコード変更が本流に入り、多くの場合CI/CDやデプロイが連動して動くためです。

pull_requestsツールセットには、PR作成・コメント追加・レビュー追加・マージまでが1つのグループに含まれます（出典: GitHub公式リポジトリ）。ツールセット単位で有効化すると、レビューコメントの追加とマージが同じ権限の中に同居する点に注意が要ります。

GitHub公式のCopilot coding agentは、1タスク1ブランチ・1PRに絞り、最長59分で作業を区切ります（出典: GitHub公式ドキュメント）。ただし、マージするかどうかの最終判断は、リポジトリ側の権限・ブランチ保護ルールに委ねる設計にするのが妥当です。コーディングエージェントはPRを作成するところまでとし、マージツール自体は既定で持たせない、という自社の承認ゲート設計の適用です。GitHub MCPを使う場合も、この境界をそのまま踏襲する設計が妥当です。

マージを許可制にする理由は、取り消しにくさだけではありません。マージ後にCIが失敗した場合、原因の切り分けにも時間がかかります。1回の誤マージが、レビュー待ちのPR数本分の手戻りにつながることもあります。

07GitHub公式MCPを承認ゲートにつなぐ｜自社の線引きをそのまま使う

ここまでの表を、実際の権限ルールに落とし込みます。Claude Codeでは、MCPツールも権限ルールの対象にできます。書式はmcp__サーバー名__ツール名で、allow・ask・denyを指定します（出典: Claude Code公式ドキュメント）。GitHub MCPならmcp__github__ツール名です。

3列の配分の考え方は『Claude Codeの権限設定｜allow・ask・denyの配分と設定例』で扱ったものと同じです。

{
  "permissions": {
    "deny": [
      "mcp__github__delete_file"
    ],
    "ask": [
      "mcp__github__merge_pull_request",
      "mcp__github__issue_write",
      "mcp__github__pull_request_review_write"
    ]
  }
}

denyに置いたdelete_fileは、ファイルをコミットとして削除するツールです。GitHub MCPには、リポジトリそのものを削除するツールは含まれていません（2026-07-29に公式リポジトリのツール一覧で確認）。壊せる範囲は「ファイル単位のコミット」までで、「リポジトリごと消える」事故はこのMCPの範囲では起きません。

自社は、Bashレベルでも同じ考え方を使っています。rm -rfやforce pushをPreToolUseフックでdenyする仕組みを、危険コマンド遮断として運用しています。GitHub MCP経由の操作も、対象がBashコマンドかMCPツール呼び出しかが違うだけで、承認ゲートの層に乗せる考え方は同じです。

承認したという事実の残し方も、GitHub MCPだから特別ではありません。自社の運用ルールは、承認者・承認日時・承認の証跡・対象のハッシュ値の4項目を記録すると定めています（出典: 自社の承認ゲート設計）。GitHub MCP経由のマージ許可も、この4項目を台帳か操作ログのどちらかで満たす前提で運用します。

08GitHub MCPサーバーでつまずきやすい3つの点

1. 既定のツールセットに書き込み系が含まれていることに気づかない。何も指定せずに接続すると、reposツールセットが既定で有効になり、ファイルの作成・更新・削除まで含まれます（出典: GitHub公式リポジトリ）。Issue・PRだけのつもりで接続すると、意図しない書き込み権限まで一緒に渡してしまいます。

2. classic PATとfine-grained PATの粒度差を意識しない。classic PATのrepoスコープは、Issue・PR・ファイル操作をまとめて許可します。Issue起票だけを任せたい場面でclassic PATを使うと、必要以上の権限がGitHub MCPに渡ります。

3. ツールセット単位の絞り込みと、トークン権限の絞り込みを混同する。GITHUB_TOOLSETSはサーバー側が提供するツールの範囲、fine-grained PATはトークンが持つ権限の範囲です。片方だけ絞っても、もう片方が広ければ、実際に呼び出せる操作は広いままです。両方を同時に絞る必要があります。

09GitHub MCPチェックリスト

• 接続経路（リモートホスト型・Docker・ローカルバイナリ）を、社内ネットワークの制約に合わせて選んだ
• GITHUB_TOOLSETSまたは--toolsetsで、Issue・PR運用に必要なツールセットだけを有効にした
• 既定値のまま接続していないか確認した（既定はcontext・repos・issues・pull_requests・users）
• fine-grained PATで、Issues・Pull requests・Contents・Administrationの権限カテゴリを個別に設定した
• トークンの対象リポジトリを「Only select repositories」で絞った
• mcp__github__merge_pull_requestをask、または常時denyに設定した
• mcp__github__delete_fileなど書き込み系ツールの扱いを、deny・ask・allowのどれにするか決めた
• 承認者・承認日時・承認の証跡を記録する運用を、マージ許可に対しても決めた
• 書き込みを一切許可しない場合は、--read-onlyフラグまたは/readonlyパスを使う選択肢を確認した

10FAQ