ブログ

はじめに

開発チーム内でMCP（Model Context Protocol）の導入を進めるにあたり、「メンバーがネット上の『野良サーバー』を勝手にローカル環境へ導入しないか」「検証用APIキーの漏洩や、社内ネットワークへの意図しないアクセスの温床にならないか」といったリスクへの対策は、あらかじめ検討しておくべき重要な課題です。

私たちのチームは、インフラからアプリケーションまで自律的に管理・運用しています。だからこそ、誰かに指摘される前に、自分たちで責任を持ってセキュリティリスクをコントロールしなければなりません。かといって、ガチガチの厳しいルールを敷いて開発スピードを落としてしまっては本末転倒です。

本シリーズは、「概念とアーキテクチャの全体像」を解説する【前編】と、「AWS CDKやCI/CDを用いた実装の裏側」に踏み込む【後編】の2本立てでお届けします。

前編となるこの記事では、GitHubの組織設定による「野良MCPの排除」を中核に据え、CI/CDでの自動スキャンや安全な配信基盤を組み合わせたプライベートMCPレジストリの「全体アーキテクチャ」を解説します。私たちが実際に構築した仕組みの大枠を通じて、どのように「開発の自由度」と「チームの自律的なセキュリティ統制」を両立させているのかをご紹介します。

▼ この記事の対象読者

• GitHub Copilot Enterprise等を導入し、チーム内で安全にMCPを活用したいテックリードやDevOpsエンジニア
• 開発スピードを落とさずに、自律的なセキュリティ統制（ガードレール）を敷きたい開発チーム
• 設定ファイルのレビューや手作業での運用に限界を感じている方

▼ 本記事で取り扱わないこと

• MCPサーバー自体の具体的な開発手法やプログラミング
• GitHub Copilot 以外のAIアシスタントにおける個別のMCP設定手順
• AWS CDKやCI/CDツールの基礎的な使い方（後編で実装コードは紹介しますが、ツールの入門的な解説は割愛します）

概念説明：なぜ「野良MCP」は危険なのか？

解決策に入る前に、そもそもMCPを無統制に利用すること（野良MCP）が、なぜセキュリティインシデントに直結するのか、その脅威モデルを正しく理解しておく必要があります。

MCPサーバーは、AIに対して「ファイルシステムの読み書き」や「外部APIへのリクエスト」「データベースへのクエリ実行」といった具体的な能力を提供します。もし、悪意のある（あるいは脆弱性を抱えた）MCPサーバーを開発者がローカル環境にインストールしてしまった場合、以下のようなリスクが生じます。

• 内部ネットワークへの不正アクセス: MCPサーバーが 127.0.0.1 や社内LANのプライベートIP宛にAPIリクエストを送信し、踏み台として利用される
• クレデンシャルの漏洩: 外部サービス連携用のAPIトークンやパスワードを、設定ファイルへ直書きしてしまう（ヒューマンエラーによる漏洩）
• 意図せぬデータの外部送信: AIとのやり取りに含まれる機密データが、非公式なサードパーティサーバーへ送信・蓄積される

この脅威を防ぐためには、個々の開発者のリテラシーや「気をつける」という精神論に依存するのではなく、「システムによるガードレール」を設けることが不可欠です。

ホワイトリスト運用：GitHub組織設定によるガバナンス

上記の脅威に対する最適解として私たちが採用したのが、GitHubの組織設定と自チーム専用の「プライベートMCPレジストリ」の組み合わせです。

GitHubのRestrict MCP access to registry servers 機能を有効化すると、「許可（レジストリに登録）したMCPサーバー」以外、IDEから利用できなくなります。これにより、「野良MCP」の実行をシステム的にブロックすることが可能です。

しかし、ここで新たな運用課題が生まれます。

「許可リスト（レジストリのJSONファイル）を誰がどうやって管理し、安全性を担保するのか？」です。

最初は「チーム内で許可リストを作って、手動でJSONを管理すればいいか」と甘く見ていましたが、手作業でのJSON編集とPRレビューは、あっという間に形骸化します。「閉じカッコ忘れ」でCIが落ちるだけならまだしも、検証用のAPIトークンをうっかり直書きしてしまうような設定ミスによるインシデントは、時間の問題だと気づいたのです。

生成AIとCI/CDによる「自律的」なレジストリ運用基盤

手作業の限界を超えるため、私たちは「設定の生成とセキュリティの事前調査をAIに任せ、最終的な検証をシステム（CI/CD）に任せる」というアプローチを採用しました。

全体のワークフローは以下のようになります。

JSONの「手書き」を禁止し、AIに生成させる

複雑なMCPサーバーの定義ファイル（JSON）を手作業で書くことはチームのルールで禁止しました。代わりに、事前に厳格なプロンプト定義を用意し、AIアシスタントに自動生成させます。

「必ず公式スキーマに準拠すること」「要求する権限や認証方式を明記すること」をプロンプトで指示しておくため、フォーマットの揺れがなくなり、構文エラーによる手戻りが消滅します。

AIによる自律的な「セキュリティサーベイ」

単にJSONを生成するだけではなく新しいサーバーを追加する際、セキュリティサーベイを自律的に実施させる仕組みを構築しました。

開発者が追加したいMCPサーバーを指定すると、AIが以下のような観点で公開情報（公式レジストリ、リポジトリの状況、ドキュメントなど）を自動調査します。

• 出所と信頼性: 公式レジストリに登録されているか？直近のメンテナンス状況はどうか？
• 権限とアクセス制御: どのような権限（Read/Write）を要求するか？認証方式は適切か？
• データハンドリング: 外部APIへのデータ送信はあるか？永続化されるか？

AIはこの調査結果を基に、リスクレベル（低/中/高）を判定し、PRのテンプレートを自動で生成・入力します。これにより、レビュアーは「このサーバーはそもそも何をするもので、どこにリスクがあるのか」が整理された状態でレビューを開始できるため、負担が劇的に軽減されます。

CI/CDパイプラインによる厳格な静的スキャン

AIによる定性的なサーベイ結果に加えて、コードがPushされた段階で、独自のスクリプトを用いた定量的なセキュリティスキャンをCI/CD上で自動実行させます。

この自動スキャンでは、MCP特有の脅威モデルに基づき、以下の点を機械的に弾きます。

• ネットワークの制限: 127.0.0.1, localhost、あるいは社内のプライベートIPセグメント宛のURL指定の禁止。
• 秘匿情報の検知: TOKEN, SECRET, API_KEY といった文字列の直書きチェック（環境変数からの読み込みを強制）。
• プロトコルの強制: すべての外部通信設定における https:// 始まりの徹底。

まとめ

GitHubの組織設定で制限をかけ、AI生成とCI/CDスキャンを組み合わせたプライベートレジストリを運用することで、「開発スピードの向上」と「厳格なガバナンス」を両立させることができます。

次回の【後編】では、今回解説したアーキテクチャの「真髄」である実装の詳細に踏み込みます。

AWS CDKを用いたS3配信基盤のインフラ構築コードや、CIパイプラインで動かすセキュリティスキャンのスクリプト、そして実際のRegistry JSONの実例など、現場ですぐに活かせる具体的なノウハウを余すところなく解説します。ぜひご期待ください！