MCP サーバーの社内マーケットプレイス化｜承認フロー・SBOM・バージョン固定の型（DX・情シス向け）

生成AI（LLM）の業務利用が「チャット」から「エージェント・実行」へとシフトする中で、Model Context Protocol（以下、MCP）への注目が急速に高まっています。MCPを活用すれば、ClaudeなどのAIクライアントから、社内のデータベース、GitHub、SaaS、ローカルファイルへシームレスにアクセス可能です。しかし、企業の実務においては「野良MCPサーバー」の乱立によるセキュリティリスクや、依存ライブラリの脆弱性管理、そしてバージョン不一致による動作不安定が大きな障壁となっています。

本記事では、情シス・DX推進担当者が構築すべき「社内MCPマーケットプレイス」の概念と、その実装に不可欠な承認フロー・SBOM（ソフトウェア部品構成表）・バージョン固定の運用型を具体的に解説します。

1. MCPガバナンスが不可欠な理由とAIシャドーITの正体

MCPは、Anthropic社が提唱した「AIモデルと外部データソースを接続するためのオープン標準プロトコル」です。非常に強力な反面、開発者が各自のローカル環境で勝手にMCPサーバーを立ち上げ、機密データにアクセスする「AIシャドーIT」を容易に引き起こします。

• 認証の欠如： 簡易的に実装されたMCPサーバーが、認証なしで社内DBをフルスキャン可能な状態になるリスク。
• サプライチェーンリスク： OSSのMCPサーバーに含まれる悪意あるライブラリによるデータ漏洩。
• 運用の断絶： 開発者が退職した後、誰も仕様を把握していないMCPサーバーが残り続け、システム変更時にエラーを連発する。

これらの課題を解決するのが、「社内マーケットプレイス」という考え方です。社内で認定されたMCPサーバーのみを「カタログ」として公開し、ユーザーはそこから安全にインストール・接続できる体制を構築します。これは、かつての社内ポータルやSaaS管理に近い、現代のAI管理の必須要件です。

特に、SaaSの増加に伴うアカウント管理やセキュリティの観点については、以下の記事も参考になります。

SaaS増えすぎ問題と退職者のアカウント削除漏れを防ぐ。Entra ID・Okta・ジョーシスを活用した自動化アーキテクチャ

2. 社内MCPマーケットプレイスの全体アーキテクチャ

社内マーケットプレイスを構築する際の標準的な構成は、以下の3つのレイヤーで構成されます。

2.1 カタログ層（レジストリ）

利用可能なMCPサーバーの名前、機能、開発者、現在の安定バージョンを管理するリストです。GitHub EnterpriseのRepositoryリストや、内部Wiki、あるいは独自のWebポータルがこれに該当します。

2.2 審査・承認層（CI/CDパイプライン）

新しくMCPサーバーを追加、あるいは更新する際に、必ずセキュリティチェックを通過させるレイヤーです。ここでSBOMの生成と脆弱性スキャンを実施します。

2.3 配信・制御層（プロビジョニング）

各ユーザーのPC（Claude Desktop等）に対して、承認済みサーバーの設定を流し込むレイヤーです。設定ファイルのバージョンを固定することで、現場での「動かない」というトラブルを未然に防ぎます。

3. 【実務】承認フローとSBOMによる安全性の担保

MCPサーバーを社内配布する前に、最低限実施すべきステップを整理します。

Step 1：GitHub Actionsでの自動SBOM生成

MCPサーバーの実装（TypeScript/Node.jsやPython）には、多くの外部ライブラリが利用されます。まずは、ビルド時にSBOMを出力し、構成を透明化します。
ツールとしては、Syft（SBOM生成）やTrivy（脆弱性スキャン）を組み合わせるのが一般的です。

例えば、GitHub Actionsで以下のようなフローを組みます。

1. ソースコードのPush。
2. Syftを実行し、cyclonedx-json形式でSBOMを出力。
3. TrivyでSBOMをスキャンし、Critical/Highの脆弱性があればビルドを停止。
4. パスした場合のみ、Dockerイメージやパッケージをレジストリに保存。

Step 2：承認ワークフローの統合

技術的なスキャンだけでなく、情シスによる「そのデータにAIがアクセスして良いか」というビジネス判断のプロセスを設けます。GitHubのPull Requestでのレビュー、もしくはバクラクやfreee支出管理のようなワークフローツールを用いて「MCP利用申請」を紐づけるのも有効です。

稟議・承認フローの全体設計については、以下の比較も役立つでしょう。

【徹底比較】バクラク vs freee支出管理。中堅企業が「経費精算・稟議」を会計ソフトと分ける本当の理由

4. バージョン固定とクライアント設定の統制

MCPの最大のハマりどころは、クライアント側の config.json 管理です。各ユーザーが手動で設定を書くと、パスの間違いや古いバージョンの利用による不具合が多発します。

4.1 設定ファイルの集中管理手法

企業レベルでは、以下のいずれかの手法で claude_desktop_config.json を管理することを推奨します。

4.2 セマンティックバージョニングの徹底

MCPサーバーの設定には、必ずタグやバージョンを指定してください。
npx -y @modelcontextprotocol/server-everything のように実行すると、常に最新版がダウンロードされ、破壊的変更があった際に業務が止まります。
npx -y @modelcontextprotocol/server-everything@0.1.5 のように、承認済みの特定バージョンを指定する運用を徹底しましょう。

5. セキュアなMCP運用のためのチェックリスト

MCPサーバーの実装・導入時に、実務担当者が確認すべき項目をまとめました。

• Secretsの外部化： APIキーやDBパスワードをMCPサーバーのソースコードや設定ファイルに直書きしていないか。環境変数（Secret Manager等）を利用しているか。
• 最小権限の原則： そのMCPサーバーに与えられているDB権限は「参照のみ」か。必要以上の書き込み権限を与えていないか。
• レートリミット： AIがループして無限にリクエストを投げた際、社内システムをダウンさせないための制限がMCPサーバー側にあるか。
• 監査ログ： MCP経由で「誰がどのデータを読み取ったか」を、既存のログ基盤（CloudWatch Logs等）に転送しているか。

このような「データの流れ」を設計する思考は、基幹システムのデータ連携設計とも共通しています。以下のガイドも設計のヒントになります。

【図解】SFA・CRM・MA・Webの違いを解説。高額ツールに依存しない『データ連携の全体設計図』

6. よくあるエラーと対処法

エラー1：Internal error: MCP server closed connection

原因： MCPサーバーがクラッシュした、またはNode.js等のランタイムがパスを通っていない。

対処： サーバーの標準エラー出力をログファイルに書き出す設定を追加し、スタックトレースを確認する。また、フルパスで実行ファイルを指定しているか確認してください。

エラー2：Tool call failed: timeout

原因： MCPサーバー側の処理（重いSQLクエリ等）が、クライアント側のタイムアウト（通常30秒〜60秒）を超えている。

対処： クエリの最適化を行うか、MCPサーバー側で非同期処理として受け付け、ステータスを返す設計に変更する。

7. まとめ：AI時代のインフラとしてのMCP

MCPは単なる便利ツールではなく、AIが社内資産を活用するための「神経系」です。その神経系が野放しになれば、企業は深刻なセキュリティインシデントに直面します。

今、情シスやDX担当者が取り組むべきは、個別のMCPサーバーを作ることではありません。「誰でも安全に、承認されたMCPサーバーを、正しいバージョンで利用できるプラットフォーム（社内マーケットプレイス）」を構築することです。SBOMによる透明性と、MDMやGitによる構成管理を組み合わせることで、攻めと守りのバランスが取れたAI活用が可能になります。

本ガイドを参考に、まずは「社内認定MCPサーバー第1号」の承認フローを定義することから始めてみてください。