MCP サーバーを社内配布する手順｜SBOM・署名・バージョン固定と情シスの合意形成（実務向け）

生成AIの業務活用が「チャット UI での対話」から「外部ツールとの連携（MCP: Model Context Protocol）」へと進化する中で、情シス担当者が直面するのが「自作・OSSのMCPサーバーをどう安全に全社配布するか」という課題です。

MCPサーバーは、企業の機密データ（データベース、Google Drive、Slack、社内ドキュメント等）に直接アクセスする「橋渡し」の役割を担います。そのため、単純に「各自がGitHubからクローンして実行する」運用では、脆弱性の混入や情報の不正流出、バージョンの不一致による業務停止などのリスクを制御できません。

本記事では、IT実務担当者および情シス向けに、MCPサーバーをエンタープライズ環境で配布するための技術要件（SBOM、署名、バージョン固定）と、組織的な合意形成の手順を詳解します。

1. MCPサーバー社内配布の現状と情シスが直面する壁

Claude DesktopなどのMCPホストから呼び出されるMCPサーバーは、実態として「ローカルで動作するプログラム」です。これを社内配布する際、情シスが最も懸念するのは「実行権限」と「サプライチェーンリスク」です。

1.1 汎用AIツールから「業務特化型AI」への移行

多くの企業では、ChatGPTやClaudeの導入は完了していますが、それらはあくまで汎用的な回答に留まります。自社の売上データや在庫状況をAIに参照させるには、MCPサーバーの導入が不可欠です。しかし、これらのサーバーはエンジニアが個人的に作成したスクリプトであることも多く、企業としてのサポート対象外（野良ツール）になりがちなのが実情です。

1.2 配布における3つの技術的課題

安全な配布を実現するためには、以下の3点を技術的に解決しなければなりません。

• コード署名: macOSのGatekeeperやWindowsのSmartScreenで「未確認の開発元」としてブロックされるのを防ぐ。
• SBOM（ソフトウェア部品表）: そのMCPサーバーがどのようなライブラリ（npmやPythonパッケージ）を使用しており、脆弱性がないかを可視化する。
• バージョン固定: 「昨日は動いたが、パッケージの更新で今日動かなくなった」というトラブルを防ぐため、実行環境を完全に同一にする。

2. 実務的なMCPサーバーの配布構成

MCPサーバーを社内に配布する方法はいくつかありますが、管理の容易さとセキュリティの観点から比較検討する必要があります。特に、従業員の端末に開発環境（Node.jsやPython）がインストールされていることを前提にできるかどうかで、最適な選択肢は変わります。

2.1 配布方式の比較表

実務上、多くの企業で推奨されるのは「シングルバイナリ配布」です。Node.jsであれば pkg や Sea (Single Executable Applications)、Pythonであれば PyInstaller を活用し、ランタイムを含めた単一の実行ファイルとして配布することで、「環境構築エラー」による情シスへの問い合わせを激減させることができます。

このようなインフラの整理は、SaaS導入時のアカウント管理と同様に、初期のアーキテクチャ設計が重要です。例えば、退職者の権限削除やアクセス制御については、以下の記事で解説しているようなID管理（IdP）との連携思想が参考になります。

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

3. セキュリティ担保の3本柱：SBOM・署名・検証

情シスがMCPサーバーの配布を「許可」するためのエビデンスとして、以下の3要素をパイプラインに組み込みます。

3.1 SBOMによる脆弱性管理

MCPサーバーが依存する OSS ライブラリに脆弱性が含まれていないかを証明するため、SBOM を生成します。
実務では、GitHub Actions 等の CI 上で Syft（公式GitHub）を使用して SBOM を出力し、Trivy（公式GitHub）でスキャンをかける構成が一般的です。

3.2 コード署名の実施

配布されたバイナリが「自社でビルドされた正当なもの」であることを保証するために署名を行います。
特に macOS の場合、署名（Code Signing）と公証（Notarization）がないプログラムは、デフォルト設定の Mac では実行できません。Apple Developer Program（組織）への加入と、CI上での証明書管理が必要になります。

4. ステップバイステップ：MCPサーバーのビルド・配布手順

ここでは、TypeScript (Node.js) で作成された MCP サーバーをバイナリ化して配布する実務フローを解説します。

Step 1：ロックファイルによるバージョン固定

npm install ではなく、必ず package-lock.json を含めた状態で npm ci を使用してビルドします。これにより、ライブラリの推移的依存関係（ライブラリが依存しているライブラリ）のバージョンも固定され、再現性が確保されます。

Step 2：SBOM生成とスキャン

ビルドパイプラインに以下のようなステップを追加します（GitHub Actions 例）。

name: Generate SBOM
run: syft . -o cyclonedx-json > sbom.json

name: Scan SBOM
run: trivy sbom sbom.json --severity CRITICAL,HIGH --exit-code 1

ここで CRITICAL な脆弱性が見つかった場合、ビルドを失敗させる（配布させない）ガードレールを構築します。

Step 3：バイナリへのパッケージング

Node.js 20以降でサポートされた SEA (Single Executable Applications) を利用するか、サードパーティ製の pkg を用いて、OS（Windows/macOS）ごとのバイナリを生成します。

Step 4：社内ストレージまたはアーティファクト管理への登録

生成されたバイナリと SBOM、およびハッシュ値（SHA-256）をセットにして、AWS S3 や Google Cloud Storage、あるいは社内のファイルサーバー等の「情シスが管理する場所」に配置します。

こうした一連の自動化フローは、バックオフィス業務の自動化と本質的に同じです。手作業を排除し、証跡を残す設計については、以下の記事も非常に参考になります。

楽楽精算×freee会計の「CSV手作業」を滅ぼす。経理の完全自動化とアーキテクチャ

5. 情シス・セキュリティ部門との合意形成ガイドライン

技術的な準備が整っても、組織的な「許可」が得られなければ MCP サーバーは導入できません。以下のポイントを押さえて合意形成を図ります。

5.1 責任共有モデルの定義

MCP サーバーの運用において、誰が何に責任を持つかを明確にします。

• 開発部門（利用部）: MCP サーバーのビジネスロジックの正当性、およびプロンプトによる出力結果の検証。
• 情報システム部門: 配布基盤の維持、共通ライブラリの脆弱性監視、コード署名用証明書の管理。
• セキュリティ部門: 外部通信のポリシー監視、監査ログの定期レビュー。

5.2 監査ログの取得方針

MCPサーバーは stdio（標準入出力）で通信するため、通信内容はローカルに閉じています。しかし、MCP サーバー側で「どのユーザーが、いつ、どのリソースにアクセスしたか」をログ出力し、それを Datadog や CloudWatch Logs 等に転送する仕組みを要件に加えることで、セキュリティ部門の合意を得やすくなります。

また、こうした社内ツールと既存の基幹システム（SFA/CRM等）を連携させる場合は、全体的なデータ連携図を描いておくことが、承認をスムーズにするコツです。以下の記事では、高額なツールに頼らないデータ連携の設計思想を解説しています。

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

6. まとめ：ガバナンスと利便性を両立したAI活用基盤へ

MCP サーバーの社内配布は、単なるファイルのコピーではありません。それは、企業のデータを AI に開放するための「信頼のパイプライン」を構築する作業です。

• バージョン固定で動作の再現性を確保する。
• SBOMでサプライチェーンリスクを可視化する。
• コード署名で正当性を証明し、OSのブロックを回避する。
• 責任共有モデルを明文化し、情シスと利用部門の対立を避ける。

これらのステップを踏むことで、企業は安全に AI の能力を自社データへと拡張できるようになります。まずは小規模な社内便利ツールから、本ガイドの手順に沿ってバイナリ配布を試行することをお勧めします。