😽

Claude Code × GitHub MCP Server で AI が GitHub を操作する開発体験

に公開

はじめに

MOSHでエンジニアをしている Hiroshi Kaji です。

この記事は MOSH Advent Calendar 2025 の12日目の記事です。

MOSH では、AI を活用した開発効率化に取り組んでいます。その中で出会ったのが Claude CodeGitHub MCP Server の組み合わせです。

「PR作って」「このバグについてIssue作って」「レビューコメント残して」

こんな自然言語の指示で、AI が実際に GitHub を操作してくれる。最初は半信半疑でしたが、使ってみるとこれがかなり便利でした。

本記事では、GitHub MCP Server の概要から具体的な使い方、そして実際に使ってみて感じた良い点・課題点までをご紹介します。


MCP とは何か

MCP(Model Context Protocol)は、AI エージェントと外部サービスをつなぐためのオープンプロトコルです。Anthropic が策定しました。

普通、AI は「GitHubでPRを作って」と言われても、実際に GitHub を操作する手段を持っていません。テキストを返すだけです。

でも MCP があると、この状況が変わります。


MCP を通じて、AI の「言葉」が「行動」に変わります


GitHub MCP Server でできること

GitHub が公式に提供している MCP Server を使うと、AI は GitHub の様々な機能を直接操作できるようになります。

主な機能をざっと挙げると、こんな感じです。

  • リポジトリ操作: ファイルの取得・作成、ブランチ操作、コミット、コード検索
  • Issue 管理: Issue の作成・更新・検索、コメント追加
  • PR 管理: PR の作成・マージ・レビュー・行単位のコメント
  • GitHub Actions: ワークフローの実行や状態確認
  • セキュリティ: コードスキャン、脆弱性アラートの確認

特に PR 関連の機能が充実していて、差分の取得や行単位でのコメント、既存ディスカッションの分析などができます。これがかなり使えるんです。


セットアップ手順

セットアップは意外と簡単で、3ステップで完了します。だいたい5分くらいで終わります。

Step 1: Docker イメージを取得

まずは GitHub MCP Server の Docker イメージを取得します。

docker pull ghcr.io/github/github-mcp-server:latest

Step 2: GitHub Personal Access Token を作成

次に、GitHub の Settings から PAT(Personal Access Token)を作成します。

  1. Settings → Developer settings → Personal access tokens → Tokens (classic) を開く
  2. 「Generate new token」をクリック
  3. reporead:orgread:user スコープにチェックを入れる
  4. トークンをコピーして保存

ここで注意なんですが、この画面を閉じるとトークンは二度と見られません。必ずどこかに保存しておいてください。

Step 3: Claude Code に MCP Server を追加

最後に、Claude Code に MCP Server を登録します。

# 環境変数にトークンを設定
export GITHUB_PERSONAL_ACCESS_TOKEN=ghp_あなたのトークン

# MCP Server を追加
claude mcp add github \
  --env GITHUB_PERSONAL_ACCESS_TOKEN \
  -- docker run -i --rm -e GITHUB_PERSONAL_ACCESS_TOKEN ghcr.io/github/github-mcp-server:latest

ちゃんと追加されたか確認するには、以下のコマンドを実行します。

claude mcp list

これで準備完了です。


実際のプロジェクトでの活用例

ここからは、実際のプロジェクトでどう使っているかを紹介します。

Claude Code を起動したら、あとは自然言語で指示するだけです。

claude

PR を作成する

連絡先検索 API のエンドポイントを追加した後、こんな感じで PR を作成できます。

You: 現在のブランチの変更で PR を作成して。
     タイトルは「feat: 連絡先メール検索 API の追加」で。

すると Claude が GitHub MCP Server を使って PR を作成してくれます。description には、変更の意図や影響範囲、主な変更点などが簡潔にまとめられていました。「何を変更したか」だけでなく「なぜ変更したか」まで書いてくれるのが嬉しいポイントです。

実際に GitHub を開くと、こんな感じで PR が作成されています。

https://github.com/your-org/your-repo/pull/xxx

OpenAPI の変更内容と backend の実装内容を含めてほしい場合は、その旨を伝えるだけでOKです。


PR をレビューして行単位でコメントを残す

これが一番便利だと感じた機能です。

You: PR #342 のコードをレビューして、気になる点があれば
     具体的な行を指定してコメントを残して。

Claude は PR の差分を取得して分析し、気になる点を見つけると、その行に直接コメントを残してくれます。

例えば私たちのプロジェクトではスキーマ駆動開発を採用しているので、「OpenAPI と Zod スキーマの整合性もチェックして」と追加で伝えると、openapi/paths/ の定義と packages/backend/src/handlers/ の Zod スキーマを比較して、不整合があれば指摘してくれます。

実際に受け取ったコメントはこんな感じでした。

OpenAPI 定義では limitmaximum: 100 が設定されていますが、Zod スキーマに .max(100) がありません。z.number().max(100) に修正することをおすすめします。

他にも、OpenAPI のレスポンス定義で 400 エラーが不足している点なども指摘してくれました。人間が見落としがちな部分を拾ってくれるのはありがたいですね。


PR の既存ディスカッションを分析する

これも便利な機能です。途中から PR のレビューに参加するとき、これまでの議論を追いかけるのって結構大変ですよね。

You: PR #298 のディスカッションを分析して、何が議論されているか要約して。

こう指示すると、Claude は PR のコメントとレビューを取得して、議論のポイントをまとめてくれます。どの議論が解決済みで、どの議論がまだ残っているかも教えてくれるので、キャッチアップがかなり楽になります。

シナリオビルダー機能の PR なんかは議論が長くなりがちなので、この機能には助けられました。


レビューコメントに返信する

既存のレビューコメントに対して返信することもできます。

You: PR #342 の「Zod に .max(100) がない」というコメントに、
     「次のコミットで修正します」と返信して。

地味ですが、ブラウザを開かずにターミナルから返信できるのは便利です。


Issue を作成する

フロントエンドでバグを発見したときも、すぐに Issue を作れます。

You: packages/frontend の連絡先一覧画面で
     ページネーションが正しく動作しないバグを発見した。
     再現手順を含めて Issue を作って。

Claude は Issue を作成して、タイトル、再現手順、期待される動作、実際の動作、関連ファイルまで書いてくれます。

https://github.com/your-org/your-repo/issues/xxx

「Issue を書くのが面倒でつい後回しにしちゃう」という人には特におすすめです。


コードを検索する

私たちのプロジェクトはモノレポ構成なので、複数パッケージを横断してコードを検索できるのは助かります。

You: リポジトリ内で "postCreatorContactsEmailSearch" を使っているファイルを探して

packages/backend、packages/frontend、openapi/ を横断して検索結果を返してくれます。「この API どこで使われてるんだっけ?」という疑問がすぐ解決するのは地味に嬉しいポイントです。


Dev Container での Docker 有効化

私たちは Dev Container で開発しているので、コンテナ内で Docker を使えるようにする必要があります。

.devcontainer/devcontainer.json に以下を追加してください。

{
  "mounts": [
    {
      "source": "/var/run/docker.sock",
      "target": "/var/run/docker.sock",
      "type": "bind"
    }
  ],
  "features": {
    "ghcr.io/devcontainers/features/docker-outside-of-docker:1": {}
  }
}

これでコンテナ内からホストの Docker を利用できるようになります。


良い点と課題点

実際のプロジェクトで使ってみて感じた良い点と課題点をまとめます。

良い点

OpenAPI と実装の整合性チェックが便利

私たちのプロジェクトはスキーマ駆動開発を採用しているので、OpenAPI 定義と Zod スキーマ、Prisma モデルの整合性を AI がチェックしてくれるのは非常に助かります。人間だと見落としがちな部分を拾ってくれます。

モノレポの横断検索が楽

packages/backend、packages/frontend、openapi/ を横断してコードを検索できます。「この関数どこで使ってたっけ?」がすぐ解決するのはストレスフリーです。

PR レビューの事前チェックに使える

人間がレビューする前に AI に一度見てもらうことで、typo や明らかな問題点を事前に潰せます。レビュワーの負担軽減につながりますね。

ディスカッションの把握が楽

途中から参加する PR でも、これまでの議論を要約してもらえるので、キャッチアップにかかる時間が減りました。

課題点

セキュリティには注意が必要

PAT を環境変数で渡すので、適切な権限管理が必要です。必要最小限のスコープに絞るのがおすすめです。より高いセキュリティが求められる環境では、GitHub Apps や OIDC を利用した認証方法も検討してみてください。

AI の精度は完璧ではない

レビューコメントが的外れなこともあります。特に、プロジェクト固有のコーディング規約や、ドメイン特有のビジネスロジックに関する指摘は苦手な傾向があります。汎用的なコード品質のチェックには強いですが、最終判断は人間が行う前提で使うのが良いです。

レート制限に注意

GitHub API のレート制限に引っかかる可能性があります。大量の操作を連続で行う場合は気をつけてください。


まとめ

GitHub MCP Server を使うと、AI が GitHub を直接操作できるようになります。

モノレポ × スキーマ駆動開発のプロジェクトでは、OpenAPI 定義と各パッケージの実装を横断してチェックできるのが特に便利でした。PR の作成から行単位のレビューコメント、既存ディスカッションの分析まで、かなりのことが自然言語でできます。

MCP はまだ発展途上の技術ですが、GitHub 以外にも Slack、Notion、データベースなど、様々な MCP Server が登場しています。

AI が「話すだけ」の存在から「行動する」存在に変わりつつある。その入り口として、ぜひ GitHub MCP Server を試してみてください。


参考リンク


最後まで読んでいただきありがとうございました!

質問やフィードバックがあれば、ぜひコメントでお知らせください 🙌

MOSH

Discussion