GitHub MCPの権限を絞る3か所｜Issue・PRの任せ方

「GitHub MCPをつなぎました」という報告と、「Issueの起票はもう任せています」という報告は、同じ意味ではありません。つなぐ作業そのものはコマンド1行で終わります。そのあとAIエージェントの手がどこまで届くのかは、別に決める話です。

しかも、決めていないあいだも範囲は空欄ではありません。既定の設定のままつなぐと、ファイルの作成・更新・削除まで含んだまとまりが、すでに有効になっています。渡ったあとで気づいても、実行された操作のほうは戻りません。

この記事は、GitHub公式のMCPサーバーについて、任せる範囲を絞る場所と、人の手に残す操作の線引きを整理します。素材はGitHub公式リポジトリとドキュメント、fine-grained personal access token（以下PAT）の仕様、それに自社の承認ゲート設計です。自環境でGitHub MCPを接続・実行した記録はないため、主張は公式ドキュメントの記載と自社の設計の範囲にとどめます。確認環境はGitHub MCP Server公式リポジトリと関連ドキュメント、GitHubのfine-grained PAT公式ドキュメントで、時点は2026-07-29です。

進行役は3人です。高梨課長が自分の手で動かす側から聞き、大森部長が体制と責任の側から聞き、鈴木さん（本誌監修）が答えます。

01GitHub MCPをAIエージェントにつなぐと、まず何ができるようになるんですか？

高梨課長

高梨課長の発言

つなぐと、AIがGitHubを触れるようになる、という理解でよいのでしょうか。

鈴木さん

鈴木さんの発言

おおむねそうです。ただ「触れる」の中身がかなり広いので、そこを先に見ておいたほうがいいと思っています。

GitHub MCPは、GitHubが公式に提供するMCP（AIに外部ツールを触らせるための共通の口）サーバーです（出典: GitHub公式リポジトリ）。AIツールがGitHubのプラットフォームへ直接つながり、自然言語の指示でリポジトリ管理・Issue/PR操作・CI/CDの実行まで進められると説明されています（出典: 同）。

用意されているツールは、機能ごとに「ツールセット」というまとまりへ分かれています。--toolsetsフラグかGITHUB_TOOLSETS環境変数で、有効にするまとまりを選べます（出典: 同）。有効にする範囲を絞るとLLMがツールを選びやすくなり、コンテキストサイズも減ると明記されています（出典: 同）。ツールセットは21種類あります（2026-07-29に公式リポジトリで確認）。

まとまりの名前を眺めていると、どれも同じ粒度に見えます。実際には、読むだけの道具と、書き換える道具と、走らせる道具が、同じ箱の中に並んでいます。

02GitHub MCPサーバーへの接続経路は3つあって、AI導入ではどれを選ぶんですか？

接続経路は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

03GitHub MCPをチームで共有すると、AIエージェントの承認は誰がするんですか？

Claude Code側からリモートホスト型を足すときは、HTTPトランスポートの追加コマンドを使います。書式はMCPの選び方｜AIエージェントに任せる範囲から見る5軸で扱った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公式ドキュメント）。設定ファイルは共有できても、承認は1人ずつです。

ここは、設定を配れば運用が揃うと思っていると外れる部分です。リポジトリに置いた記述は全員に届きますが、届いたあと誰がどう応じたかまでは同じになりません。

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

04既定のまま接続したGitHub MCPは、AIエージェントに何を渡してしまうんですか？

何も指定しなかったときの既定は、context・repos・issues・pull_requests・usersの5つのまとまりです（出典: GitHub公式リポジトリ）。

ここにreposが入っている点が、いちばん見落とされます。つまり、接続しただけの状態でも、ファイルの作成・更新・削除まで有効になっています。Issueの起票だけを頼むつもりでつないでも、AIエージェントの手元にはファイルを書き換える道具が並んでいます。

Issue・PRに絞りたいなら、既定値を使わず名指しで指定します。

# Issue・PR関連の道具だけを有効にする
GITHUB_TOOLSETS="context,issues,pull_requests" ./github-mcp-server

書き込み系をいっさい使わせたくない場合は、サーバー起動時に読み取り専用へ切り替えられます。「--read-onlyを指定すると読み取り専用のツールだけが提供され、変更を防ぐ」と明記されています（出典: 同）。トークンの権限を組み立てる前に、この指定で書き込みそのものを止める選び方もあります。

05fine-grained PATで、AI社員に渡すGitHub MCPの権限はどこまで絞れるんですか？

大森部長

大森部長の発言

サーバー側で道具を減らせるなら、トークンの話はもう要らないのでは。

鈴木さん

鈴木さんの発言

そこは分けて考えています。道具を減らすのは差し出す側の都合なので、いつでも戻せます。鍵のほうを絞っておくと、差し出す側が変わっても上限は動きません。

GitHub MCPが実際に何をできるかは、サーバー側の設定だけでなく、渡したトークンの権限でも決まります。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にする必要はありません。

06GitHub MCPに渡すトークンを発行するとき、AI導入で一緒に絞っておく項目は何ですか？

権限カテゴリのほかにも、発行時に絞れる項目があります。

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

3つとも、権限カテゴリとは別の設定項目です。カテゴリだけを丁寧に選んで、対象リポジトリは広いまま、ということが起こります。発行を終える前に、この3つも合わせて見ておきます。

07GitHub MCPで使うclassic PATとfine-grained PAT、生成AIに渡すならどちらなんですか？

古い形式のclassic PATは、repoのような1つのスコープでリポジトリ操作をまとめて許可します。GitHub公式リポジトリのREADMEでは、PATの設定にGITHUB_PERSONAL_ACCESS_TOKEN環境変数を使います。ここへ渡すのがclassic PATかfine-grained PATかで、許される操作の粒度が変わります。

Issue起票だけを頼みたい場面でclassic PATを使うと、ファイル操作の権限も一緒に渡ります。渡した本人には、その差が画面上で見えません。環境変数の名前は同じで、値の中身だけが違うためです。

権限を個別に選べるfine-grained PATのほうが、絞り込みの単位は細かくなります。生成AIに渡す鍵を選ぶときは、鍵の種類そのものが設計の一部だと考えておくほうが安全です。

08GitHub MCPでIssue起票をAIエージェントに任せると、あとから消せるんですか？

Issue操作は、PR操作にくらべれば取り消しやすい部類です。ただし境界はあります。

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

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

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

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

09GitHub MCPで、PRのマージまでAIエージェントに任せて、本当に大丈夫なんですか？

高梨課長

高梨課長の発言

レビューコメントまでは任せたいのですが、マージはどう扱えばいいでしょう。

鈴木さん

鈴木さんの発言

押す人を先に決める操作にしています。マージは1つの動作で本流が変わるので、あとから相談する余地が小さいんです。

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

pull_requestsツールセットには、PRの作成・コメント追加・レビュー追加・マージまでが同じまとまりに入っています（出典: GitHub公式リポジトリ）。まとまり単位で有効にすると、レビューコメントの追加とマージが同じ範囲に同居します。

10GitHub MCPでマージまで任せない場合、AIエージェントはどこで手を止めるんですか？

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

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

11GitHub MCPの操作を承認ゲートにつなぐとき、AIエージェントの設定はどう書くんですか？

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

3列の配分の考え方は、Claude Codeの権限設定｜AIエージェントに任せる範囲と3列の配分で扱ったものと同じです。

{
  "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ツール呼び出しかが違うだけで、承認ゲートの層へ乗せる考え方は変わりません。設計そのものはAIエージェントの承認ゲート｜止める操作4種と3層の選び方にまとめています。

12GitHub MCPで承認した記録は、AI活用の現場で何を残しておくんですか？

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

記録を残す先は、どちらか一方に寄せておきます。台帳と操作ログの両方に少しずつ書くと、あとから追うときに突き合わせの作業が増えます。マージのように押した瞬間が残る操作なら操作ログ側へ、判断の経緯まで残したい操作なら台帳側へ寄せます。

13GitHub MCPをAI社員に渡すとき、絞り忘れやすいのは道具と鍵のどちらですか？

大森部長

大森部長の発言

現場でよく起きる抜けは、どのあたりでしょうか。

鈴木さん

鈴木さんの発言

片側だけ絞って終わりにしてしまう形が多いと思っています。どちらも絞ったつもりになりやすいのが、やっかいなところです。

つまずきやすい点は3つあります。

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

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

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

14GitHub MCPを使うAI社員の運用は、着手前に何を点検するんですか？

GitHubの作業をAI社員に任せる前に見る項目を並べます。順番は、外側から内側へです。

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

書き終えたあとで確かめるのは、設定した範囲と、実際に呼び出せる範囲が一致しているかです。設定ファイルの記述と、トークンの発行画面は別の場所にあります。片方だけを見て点検を終えると、抜けはもう片方に残ります。

15よくある質問

16まとめ｜今日やる3つのこと

手が届く範囲は、サーバーが差し出す道具・トークンが開ける鍵・呼び出しごとの承認という3か所で決まりました。片側だけを絞っても、上限はもう片側に残ります。そして戻せない操作は、押す人を先に決めておきます。