【2026年8月版】MCP(Model Context Protocol)中小企業活用ガイド｜厳選6サーバー比較と接続4ステップを徹底解説

「ChatGPTやClaudeを使い始めたが、社内のNotionやGitHub、Slackとつなげて業務データを扱いたい」「MCPサーバーという言葉を最近見かけるが、中小企業でも導入できるのか判断がつかない」「AIエージェントに社内情報へアクセスさせるとき、権限や情報漏洩をどう制御するか整理したい」——従業員10〜100名規模の企業から寄せられる典型的な質問です。この記事では、Anthropicが2024年11月にオープンソース標準として公開したMCP(Model Context Protocol)の仕組み、対応クライアント3タイプ、公式・準公式のMCPサーバー厳選6種と料金、接続4ステップ、失敗3パターンを、公式ドキュメント(modelcontextprotocol.io)の一次情報をもとに実測ベースで解説します。読み終わる頃には「まずFilesystem+GitHubから始めて、次にNotion/Slackへ広げる」という現実的な導入順序が描けるはずです。

MCP対応クライアント3タイプ

MCPは「MCPホスト(AIアプリ本体)」「MCPクライアント(サーバーごとに張られる接続コンポーネント)」「MCPサーバー(データ・ツール提供側)」の3層で構成されます。中小企業の実務では、まずどのMCPホストを社内標準にするかで選択肢が絞られます。2026年8月時点で普及しているホストを3タイプに分類しました。

中小企業でMCPを最初に配布するなら、非エンジニアも含む全社員向けはClaude DesktopかChatGPT Desktopが導線として自然です。理由は、GUIから接続を追加でき、承認プロンプトが逐一表示されるため権限管理の透明性が高い点にあります。開発者中心のチームであれば、Claude Codeやターミナル・エディタ統合のCursor/VS Codeの方が生産性が高く、GitHub PR作成やローカルファイル生成までを一気通貫で扱えます。設定ファイルはいずれも共通で、`~/.config/claude/claude_desktop_config.json`(Claude Desktop)や`.cursor/mcp.json`(Cursor)といったパスに、サーバー起動コマンド(`npx`や`uvx`)と環境変数(APIトークン等)をJSONで記述するだけで接続が成立します。同じ設定JSONを社内の別クライアントへ移植できるのがMCP標準化の実務的な最大メリットで、Claudeの詳細活用はClaude中小企業活用ガイドに整理しています。

主要6MCPサーバーと料金

MCPサーバー本体は原則すべてオープンソースで無料ですが、実際にかかる費用は「サーバーがつなぐ先のSaaS利用料」です。例えばGitHub Team(1ユーザー月$4=約620円、1USD=155円換算)を10名で使う企業がGitHub MCPを追加しても、MCPサーバーは無料で追加費用は発生しません。Notionだけは例外で、公式のリモートMCPサーバー(Notionのサーバー上でホスト)がOAuth接続でNotionプラン料金に組み込まれる形になっています。Filesystem・Git・Fetch・Memory・Sequential Thinking・Time・EverythingはAnthropic主導のMCP運営グループがメンテナンスする公式リファレンスサーバーで、Slack・Google Drive・PostgreSQLはservers-archivedリポジトリへ移管された後もコミュニティやZencoder等のフォーク版で継続利用可能な位置付けです。archived判定は「新機能追加が止まった」を意味するもので、既存機能自体は動きますが、セキュリティ更新の主体を選定段階で必ず確認する運用が実務標準となります。より高度なエージェント設計は中小企業向けAIエージェント実装ガイドで整理しています。

AIと担当者の役割分担

MCPの実務では「AIに何を許すか」を人間側が事前設計する姿勢が導入成否を左右します。MCPクライアントはツール呼び出しの都度、ユーザーに承認を求めるダイアログを表示するため、機械的な暴走は起こりにくい設計ですが、逆に承認を惰性で押し続ける「承認疲れ」が発生すると想定外の書込みが通ってしまう構造になります。回避には、書込み系ツール(Issue作成、メッセージ投稿、ファイル書換)は情シスが事前に用途を限定し、読取専用サーバーとの分離運用にしておくのが実務的です。ユーザー承認はAIの実行を止められる仕組みで、監査ログのレビュー体制と組み合わせて初めて機能します。教育面では「MCPは自社アカウントの権限で動く」——つまり社員個人のトークンで動く場合、そのトークンが持つ全権限にAIがアクセスできることを社内利用ガイドラインへ明記する運用が有効です。より広い社内AIリテラシー教育の設計は既存記事で扱っています。

導入手順の4ステップ

ステップ1：用途特定と対象業務の洗い出し——最初にやるべきは「MCPで何をしたいか」を業務プロセスから逆算することです。例えば従業員25名のソフトウェア受託開発企業なら、「顧客要件の議事録(Google Docs)を読み込んでGitHub Issueに起票」「Slack問合せをNotion FAQと照合して回答草案生成」といった業務単位で棚卸しします。この段階では技術選定はせず、対象データが「社内のどこにあるか」「読取だけで済むか、書込みまで必要か」の2軸で仕分けます。読取専用で完結する用途から着手すれば、権限事故のリスクは最小化できます。用途3〜5件を書き出したら次のステップへ進みます。

ステップ2：MCPサーバー選定と対応クライアントの決定——用途に合うMCPサーバーを6サーバー表から選び、社内標準クライアント(Claude Desktop/Cursor/VS Code等)を1つ決めます。中小企業の実務では、公式リファレンス(Filesystem等)と企業公式(GitHub/Notion)を優先し、archived発のサーバーは「メンテナンス主体が明記されているフォーク版のみ採用」とルール化する組み立てが安全です。同じMCPサーバーでも複数のフォークが存在するため、GitHubリポジトリのスター数・最終コミット日・Issue回答速度を目視で確認してから採用します。この段階で、接続に必要なAPIトークンや権限スコープの一覧を整理しておくと、次のステップが早くなります。

ステップ3：接続設定JSONの編集とローカル動作確認——選んだクライアントの設定ファイル(例:Claude Desktopなら`claude_desktop_config.json`)に、サーバー起動コマンドと環境変数を追記します。TypeScript製サーバーは`npx -y @modelcontextprotocol/server-filesystem /path/to/folder`のようにnpx経由で、Python製は`uvx mcp-server-git`のようにuvx経由で起動する定型パターンです。APIトークンは`env`フィールドに`GITHUB_PERSONAL_ACCESS_TOKEN`等を入れます。設定後クライアントを再起動し、AIに「接続中のMCPツール一覧を教えて」と尋ねて、期待するツールが出てくれば接続成立です。ここで詰まる典型原因はNode.js/Python未インストールとトークン権限不足の2つで、いずれもエラーメッセージから切り分けられます。

ステップ4：権限管理・監査ログ設定と社内展開——動作確認後、実運用に入る前に権限スコープを最小化します。GitHub MCPならファイングレインドPATで対象リポジトリと必要操作のみ許可、Filesystem MCPなら`/home/user/project`のように読取可能ディレクトリを明示指定、PostgreSQL MCPなら読取専用ユーザーで接続する構成が原則です。監査ログは、クライアント側の実行履歴(Claude Desktopなら開発者モードのMCPログ)と接続先SaaS側のアクセスログ(GitHub Audit log、Slack Access log等)の両面で残す設計にします。社内展開時は、MCPを付与するユーザーを段階的に増やし、最初の2週間は情シスが利用ログを毎日確認する運用で異常挙動を早期検知します。

失敗パターン3つと回避策

失敗1：権限過剰付与でAIが想定外のリソースを操作する——最も多い事故は、APIトークンにフルアクセス権限を付与した状態でMCPを使い始めるケースです。例えばGitHub Personal Access Tokenを`repo`(全リポジトリ書込)スコープで発行すると、AIが誤ってプライベートリポジトリのmainブランチへPushしてしまう可能性が残ります。回避策は、GitHubならファイングレインドPATで対象リポジトリと操作(Contents:Read、Issues:Write等)を絞る、Google DriveならOAuthスコープを`drive.readonly`に限定する、PostgreSQLなら読取専用ロールで接続するといった「最小権限の原則」を接続設定の段階で徹底することです。書込みが必要な用途は用途別にトークンを分割し、書込み系は情シス承認を経てから発行する社内フローに落とし込みます。

失敗2：APIトークン・秘密情報の漏洩——設定JSONへAPIトークンを直接書き込んだ状態でファイルをGitHubへコミット、あるいはSlackで共有してしまう漏洩事故が実務で頻発しています。MCPの設定ファイルは`env`フィールドにトークンを平文で保持するため、ファイル自体が機密扱いです。回避策は、(1)設定ファイルを`.gitignore`に必ず追加、(2)可能なMCPクライアントでは環境変数参照(`${env:GITHUB_TOKEN}`形式)に切替、(3)チームで設定を共有する場合はトークン抜きのテンプレートJSONのみ配布し、各自がローカルで環境変数を設定する運用に統一、の3点です。漏洩が起きたら即座に該当トークンを失効(GitHubなら該当PATを削除、Slackならアプリを再インストール)し、監査ログで不正利用の有無を確認します。AIチャットとセキュリティの一般論はチャットボットのセキュリティとプライバシー設計で整理しています。

失敗3：archivedリファレンスサーバーのライセンス・保守主体誤認——2024年後半から2025年にかけて、Slack・Google Drive・PostgreSQL・SQLite・Redis等の初期リファレンスサーバーはservers-archivedリポジトリへ移管され、公式メンテナンス対象から外れました。archived判定を見落として本番導入し、脆弱性報告が来ても更新が来ない状態に陥る事例が中小企業で散見されます。回避策は、(1)採用前に必ずGitHubリポジトリの最終コミット日と直近3か月のIssue対応状況を確認、(2)可能なら企業公式サーバー(GitHub公式、Notion公式、Sentry公式)に置き換え、(3)コミュニティフォーク版を使う場合はメンテナンス主体(Zencoder等)とライセンス(多くはMIT)を社内資産台帳へ登録、の3点です。導入判断時点で「誰が直すか」を明確にできないサーバーは本番運用に載せない基準を設けます。

よくある質問