JMDC TECH BLOG

JMDCのエンジニアブログです

トップ > GitHub Copilot向けMCP RegistryをGitHub Pagesで構築する

GitHub Copilot向けMCP RegistryをGitHub Pagesで構築する

[!NOTE] この記事は筆者が下書きした内容をAIを活用して文章化し、筆者が監修して執筆しました。

Pep Up モバイルアプリチームのスクラムマスター兼エンジニアの @mrtry です。

今年、JMDCではアドベントカレンダーに参加しています。 qiita.com 本記事は、JMDC Advent Calendar 2025 23日目の記事です。

Model Context Protocol（MCP）サーバーの登場により、Coding Agentの機能拡張が容易になりました。MCPサーバーを導入することで、外部サービスとの連携やカスタムツールの利用が可能になります。しかし、MCPサーバーは便利である一方、適切な管理なしに導入すると、セキュリティインシデントを引き起こすリスクがあります。認証情報の漏洩や意図しないAPI呼び出しなど、組織にとって深刻な問題につながる可能性を無視できません。このような懸念から、私たちはMCPサーバーの全社導入を慎重に検討していました。

そんな中、2025年11月にGitHub CopilotにおいてMCP Registryを利用した制御機能がStableとなりました。

github.blog

MCP Registryを利用することで、管理者はMCPサーバーの利用をマネジメントできるようになり、利便性とセキュリティのバランスを取れるようになりました。本記事では、GitHub Pagesを利用してMCP Registryを構築・運用した事例を共有します。

MCP Registryの仕組みと動作確認

まず、MCP Registryの仕組みを理解するため、modelcontextprotocolが公開している公式レジストリを使って動作を確認してみました。

GitHub Copilotの管理画面でMCP RegistryのURLを登録し、「Registry only」モードに設定することで、Registryに列挙されたMCPサーバーのみが利用できるようになります。具体的には、Organization または Enterprise の設定画面から「Copilot」→「Policies」へ進み、 MCP registry URL (optional) に MCP RegistryのURLとして https://registry.modelcontextprotocol.io/ を登録します。また、「Registry only」モードを有効にします。

この状態でVS Codeの拡張機能で@mcpと検索すると、公式レジストリに列挙されているMCPサーバーが表示されることを確認できました。

GitHub Pages での MCP Registry の構築

GitHub Pagesを採用した背景

MCP Registryの構築方法として、公式ドキュメントではセルフホスティングとAzure API Centerによる管理が示されています。

docs.github.com

私たちのチームではAzureを利用していなかったため、新たなサービス依存を増やすことは避けたいと考えました。一方で、セルフホスティングでサーバーを立てるほどの運用コストをかけることも望ましくありません。そこで、既存のインフラであるGitHub Pagesで対処できないかを検討しました。

ちなみに、もしAzureで Registryを構築される場合には、以下の記事が参考になりそうです。

medium.com

MCP Registry APIの要件

MCP RegistryのAPIドキュメントを調査したところ、GitHub Copilotが動作するために必要なエンドポイントは以下の3つであることがわかりました。

docs.github.com

エンドポイント 説明
GET /v0.1/servers 全サーバー一覧の取得
GET /v0.1/servers/{serverName}/versions/latest 特定サーバーの最新バージョン取得
GET /v0.1/servers/{serverName}/versions/{version} 特定サーバーの指定バージョン取得

また、CORSヘッダーについて、ドキュメントでは以下の指定が必要とされています。

Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, OPTIONS
Access-Control-Allow-Headers: Authorization, Content-Type

GitHub PagesではAccess-Control-Allow-Origin: *のみが自動付与されます。他の2つのヘッダーは返されませんが、GitHub CopilotのMCP Registry取得は単純なGETリクエストであるため、CORSのシンプルリクエストとして処理され、実際には問題なく動作しました。

実装アプローチ

GET /v0.1/serversのレスポンスを作成しておけば、その内容を分配することで残りの2つのエンドポイントも満たせることに気づきました。この知見をもとに、以下の実装を行いました。

1. レジストリ定義ファイルの作成

mcp-registry.jsonとして、MCP Registry APIの GET /v0.1/servers のスキーマに準拠したJSONファイルを作成しました。このファイルには、許可するMCPサーバーの情報（名前、バージョン、説明、リポジトリURL、配置方法など）を記述します。

2. エンドポイント生成スクリプトの作成

generate-registry-endpoints.jsというNode.jsスクリプトを作成しました。このスクリプトはmcp-registry.jsonを読み込み、各エンドポイントに対応するHTMLファイルを生成します。GitHub Pagesでは/path/index.htmlが/pathとしてアクセスできるため、この仕組みを利用してAPIエンドポイントを模倣しています。

3. GitHub Actionsによる自動デプロイ

mainブランチへのpush時に自動的にエンドポイントを生成し、GitHub Pagesへデプロイするワークフローを構築しました。

4. GitHub CopilotへのRegistry URL設定と動作確認

GitHub Pagesへのデプロイが完了したら、GitHub Copilotの管理画面でMCP RegistryのURLを設定します。Organization または Enterprise の設定画面から「Copilot」→「Policies」へ進み、 MCP registry URL (optional) にGitHub PagesのURLを登録します。また、「Registry only」モードを有効にします。

このとき、GitHub Pagesはパブリック公開が必須です。プライベートリポジトリのGitHub Pagesを設定した場合、VS Code上で「Failed to fetch」とエラーが発生し、Registryを取得できないので注意してください。

また、MCP registry URLにはAPIのBase URLを指定するということに気をつけてください。 例えば、https://example.github.io/mcp-registry というGitHub Pagesを構築した場合、MCP registry URLには https://example.github.io/mcp-registry を設定します。 GitHub Copilotは、このURLを起点として https://example.github.io/mcp-registry/v0.1/servers にリクエストを送信します。 誤って https://example.github.io/mcp-registry/v0.1/servers のようにエンドポイントまで含めたURLを設定してしまうと、https://example.github.io/mcp-registry/v0.1/servers/v0.1/servers にリクエストが送信され、正常に動作しませんのでお気をつけください。

正しく設定できると、設定変更後にVS Codeの拡張機能で@mcpと入力して検索すると、Registryに登録したMCPサーバーのみが表示されるようになりました。これで、許可されていないMCPサーバーの利用を制限できていることが確認できます。

運用ワークフローの設計

また、MCPサーバーの追加・管理をスムーズに行うため、以下のワークフローを設計しました。

PRベースの追加フロー

社員がMCPサーバーの追加を希望する場合、リポジトリにPull Requestを作成します。mcp-registry.jsonのスキーマは複雑であるため、追加作業を支援するPromptを作成しました。/mcp-registryコマンドでPromptを呼び出し、追加したいMCPサーバーのドキュメントを渡すと、mcp-registry.jsonを適切に更新してくれます。これにより、MCPサーバーを利用したい側はJSON Schemaの詳細やMCP Registryの仕様を理解していなくても、「このMCPサーバーを導入したい」と依頼するだけで済むようになりました。

セキュリティチェックの自動化

PRが作成された際、そのMCPサーバーを導入して良いかの判断を支援するため、セキュリティサーベイを実行するPromptも作成しました。このPromptは/mcp-registryのPrompt内でチェーン実行されるように記述してあり、MCPサーバーの追加と同時にセキュリティチェックが自動で行われます。このPromptは、以下の観点からMCPサーバーを評価します。

  • 出所と信頼性（公式レジストリへの登録状況、メンテナンス活動）
  • 権限とアクセス制御（要求する権限の種類、認証方式）
  • データハンドリング（送信されるデータの種類、外部への送信有無）
  • コードと運用のセキュリティ（プロンプトインジェクション対策など）

mcp-security-servey.prompt.md | Gist

評価結果はPRのdescriptionに記載するテンプレートに沿って出力され、レビュワーが判断しやすい形式で提供されます。追加依頼時には、このレポートをそのままPull Requestのdescriptionに貼り付けてもらう運用にしています。

結果

運用実績

現時点で20個のMCPサーバーを登録しています。主な選定基準は以下のとおりです。

  • GitHub MCP Registryに列挙されているもの
  • 信頼度の高い企業（GitHub、Cloudflare、Sentryなど）が提供しているもの
  • セキュリティチェックPromptで低リスクと評価されたもの

セキュリティチェックの効果

セキュリティチェックPromptは、MCPサーバーの導入判断において有効に機能しました。具体的な事例として、modelcontextprotocolが提供しているfetchサーバーを当初リストアップしていましたが、セキュリティチェックを実行したところ高リスクと評価されました。

この結果を受けて検討したところ、「GitHub Copilotには既にfetch機能が実装されているため、このMCPサーバーは不要である」という判断に至りました。「便利そうだから入れてみよう」という安易な導入を防ぎ、適切な意思決定を促す仕組みとして機能しています。

考察

GitHub Pagesを選択した利点

サービス依存の最小化

Azureを新たに導入する必要がなく、既存のGitHubエコシステム内で完結できました。GitHub Copilotを利用している組織であれば、追加のサービス契約や学習コストなしに導入できます。

開発フローとの親和性

PRベースでMCPサーバーの追加・変更を管理することで、通常の開発ワークフローと同じ流れで運用できます。コードレビューの文化がある組織では、MCPサーバーの審査も自然に組み込めます。

限界とトレードオフ

継続的な検査の必要性

承認フローは構築できましたが、一度許可したMCPサーバーの継続的な検査については課題が残ります。脆弱性が発見された場合の対応や、定期的なバージョン更新の管理が必要です。今後の対応として、GitHub ActionsでセキュリティチェックPromptを定期実行し、登録済みMCPサーバーの状態を監視する仕組みを検討しています。google-github-actions/run-gemini-clのようなLLM AgentのAPIをGitHub Actions上から利用することで、実現できるのではと考えています。

パブリック公開が必須

実装アプローチでも述べたとおり、GitHub PagesをMCP Registryとして利用する場合はパブリック公開が必須です。Registry URLを知っていれば誰でもアクセス可能な状態となるため、URLを推測困難なものにするなどの工夫が必要です。

他組織への適用可能性

GitHub Copilotを採用している組織は、ほぼ確実にGitHubを利用しています。そのため、本記事で紹介した方法は追加のサービス契約なしに導入できます。特に以下のような組織に適していると考えられます。

  • Azureを利用していない、または新規サービスの導入に慎重な組織
  • PRベースのワークフローが確立している組織
  • MCPサーバーの導入を段階的に進めたい組織

おわりに

本記事では、GitHub Pagesを利用してMCP Registryを構築・運用する方法を紹介しました。MCPサーバーは開発者の生産性を向上させる強力なツールですが、「便利そう！！！」という気持ちだけで雑に導入すると意図しないインシデントに繋がる可能性もあると思っています。今後とも、用法用量を守りつつ、諸々の問題解決を爆速に片付けることができる環境構築に取り組んでいこうと思います💪

明日24日目は、 片岡さんによる「RedisからValkeyに移行しようとしたら思わぬ落とし穴にハマった話」です。お楽しみに！

JMDCでは、ヘルスケア領域の課題解決に一緒に取り組んでいただける方を積極採用中です!フロントエンド / バックエンド / データベースエンジニア等、様々なポジションで募集をしています。詳細は下記の募集一覧からご確認ください。

hrmos.co

まずはカジュアルにJMDCメンバーと話してみたい/経験が活かせそうなポジションの話を聞いてみたい等ございましたら、下記よりエントリーいただけますと幸いです。

hrmos.co

★最新記事のお知らせはぜひ X(Twitter)をご覧ください!

twitter.com