ChatGPTやClaudeのような生成AIは、文章を作るだけでなく、社内資料を探す、GitHubのIssueを確認する、データベースを集計する、タスク管理ツールに情報を渡す、といった作業にも広がっています。
ただし、AIが外部ツールや社内データに接続するには、「どこに接続するのか」「誰の権限で読むのか」「書き込みまで許すのか」を決める必要があります。その接続口として注目されているのがMCPサーバーです。
この記事では、MCPサーバーとは何か、MCPの仕組み、代表的な用途、会社で使う時のセキュリティ注意点まで、初心者にも分かるように整理します。読み終えた時に、まず試すべき読み取り専用PoC、次に確認する公式ドキュメント、最後に採用・保留・使わないを分ける判断表まで持てる状態を目指します。記事後半では、90分で試すMCP PoCと次に読む関連リンクにも進めます。
まず30秒でわかるMCPサーバー
| 知りたいこと | 30秒回答 |
|---|---|
| MCPとは | AIアプリと外部データ/ツールをつなぐためのオープンな接続規格 |
| MCPサーバーとは | AIに対して、読めるデータ、使えるツール、定型プロンプトを公開する側 |
| 何が便利か | ファイル、DB、GitHub、Slack、社内ナレッジなどをAIの作業文脈にできる |
| 何が危ないか | 読み取り/書き込み権限、OAuth、SSRF、セッション、ログ設計を誤るとリスクが大きい |
| まず何から試すか | 読み取り専用、限定データ、限定ユーザーで小さく検証する |
知りたいこと別に読む
MCPサーバーの記事は、読者タイプによって読むべき順番が変わります。知りたいこと別に分けると、初心者、比較検討中の人、法人導入担当者が「便利そう」で止まらず、次の判断まで進めます。
| 読者タイプ | 最初に判断すること | 次に確認すること | 最後に決めること |
|---|---|---|---|
| 初心者 | MCP、Host（ホスト）、Client（クライアント）、Server（サーバー）、Resource（リソース）、Tool（ツール）、Prompt（プロンプト）の役割 | MCPが動く流れ、stdio、OAuth、API/RPAとの違い | 自分の用途が読み取りだけで試せるか |
| 比較検討している人 | MCP、既存API、RPA、Zapier、Makeのどれで十分か | 用途別カテゴリ、候補サーバー、公式性、保守状況 | 継続検証する接続先と代替を見る条件 |
| 法人導入を考える人 | AIに読ませるデータ、禁止操作、責任者を決められるか | 権限、ログ、拒否結果、監査、ロールバック | 採用、保留、使わない条件のどれにするか |
MCPとは？
MCPはModel Context Protocolの略です。公式ドキュメントでは、AIアプリケーションが外部データソース、ツール、ワークフローに接続するための標準として説明されています。
分かりやすく言えば、MCPは「AIが外部の道具を使うための共通ルール」です。これまでは、AIと外部サービスをつなぐたびに個別の連携を作る必要がありました。MCPを使うと、AIアプリ側とツール側が共通の形式でやり取りしやすくなります。
よく使われるたとえで言えば、MCPはAIアプリにとってのUSB-Cポートのようなものです。ノートPC側がUSB-Cに対応していれば、充電器、ディスプレイ、ストレージなどを同じ形の接続口で扱いやすくなります。MCPも同じで、AIアプリ側がMCPに対応していれば、ファイル、DB、GitHub、社内検索などを共通の作法で接続しやすくなります。
ただし、USB-Cに何でも挿せるからといって、何を挿しても安全とは限りません。MCPでも、どのデータを読ませるか、どの操作を許すか、どこで人間が止められるかを決めてから使う必要があります。
MCPサーバーとは？
MCPサーバーは、AIアプリに対して「このデータを読めます」「この操作を実行できます」「この定型プロンプトを使えます」と提供する側です。
AIアプリと外部ツールの間に共通の接続口を置くを、実務で確認する順番に整理しています。
たとえば、社内ドキュメント検索用のMCPサーバーなら、AIが社内資料を検索できるようになります。GitHub用のMCPサーバーなら、IssueやPull Requestを参照できます。データベース用なら、許可された範囲で集計結果を取得できます。
MCPサーバーの中心的役割は、AIアプリと外部ソフトウェアの間に共通の接続方式を置くことです。データベース接続、検索エンジン、ファイル処理、インフラ制御、コミュニケーションツール連携をそれぞれ個別実装すると、権限やログの設計がばらばらになります。MCPはその接続口を統一的に扱うための考え方です。
| 用語 | 役割 |
|---|---|
| MCPホスト | Claude DesktopやAIエディタのようなAIアプリ全体 |
| MCPクライアント | ホスト内でMCPサーバーと通信する部品 |
| MCPサーバー | 外部データ、ツール、プロンプトを公開する部品 |
| Tool | AIが呼び出せる外部操作 |
| Resource | AIに渡せるデータや文脈 |
| Prompt | AIに使わせる定型指示 |
MCPサーバーの3つの基本機能
MCPサーバーの説明で重要なのは、「AIに何でもさせる仕組み」と雑にまとめないことです。MCPサーバーが提供するものは、大きくResource、Tool、Promptに分けて考えると理解しやすくなります。
| 基本機能 | 何を提供するか | 具体例 | 導入時の注意 |
|---|---|---|---|
| Resource | AIが読むためのデータや文脈 | 社内FAQ、仕様書、ログ、Issue一覧、DBの読み取り結果 | 読める範囲を最小限にし、個人情報や機密情報を除外する |
| Tool | AIが呼び出せる操作 | ファイル検索、Issue取得、集計クエリ、通知下書き作成 | 書き込み、削除、送信、再起動は人間承認を挟む |
| Prompt | AIに使わせる定型指示 | 問い合わせ要約、障害一次整理、PRレビュー観点、営業メモ整理 | 業務ルール、禁止事項、出力形式を明示する |
この3分類を使うと、MCPサーバーを選ぶ時に「何ができるか」ではなく「何を読ませるか」「何を実行させるか」「どの定型作業を再利用するか」で比較できます。特に非エンジニア向けに説明する場合、Resourceは資料の参照、Toolは操作、Promptは作業テンプレートと言い換えると伝わりやすくなります。
MCPを公式ソースで確認する時の見方
MCPは新しい仕様なので、記事では「便利そうなMCPサーバー名」を並べるだけでは足りません。仕様、セキュリティ、公式サーバー、Registry（レジストリ）の位置づけを分けて確認しないと、読者が安全性まで保証されたものだと誤解しやすくなります。
| 公式ソース | 確認すること | 記事での扱い方 |
|---|---|---|
| MCP公式Intro | MCPの基本定義、外部データ/ツール/ワークフロー接続、USB-Cの比喩 | 初心者向けの定義と比喩に使う |
| MCP Architecture | Host、Client、Server、Tools、Resources、Prompts、transport | 仕組み説明と権限設計の土台にする |
| MCP Security Best Practices | Confused Deputy、Token Passthrough、SSRF、Session Hijacking、Local server compromise | 導入時の注意点と禁止事項に反映する |
| MCP Registry | Registryのpreview、metadata repository、security scanningの考え方 | 掲載を品質保証や安全性保証として扱わない |
| 公式Reference servers（リファレンスサーバー） | Filesystem、Fetch、Gitなどのreference server（リファレンスサーバー） | 検証候補として扱い、無条件推薦にはしない |
| GitHub MCP Server | GitHub公式MCP Server、toolset、read-only mode | GitHub連携の候補として、権限とread-onlyを確認する |
この表を記事内に置く理由は、読者が「MCP対応」と「安全に業務導入できる」を混同しないようにするためです。MCPは接続の標準であり、接続先ごとの権限、ログ、実装品質、保守状況は別に確認する必要があります。
MCPを使う前に見る場所
MCPは、仕組み、個別サーバー、社内ルールが混ざりやすい領域です。先に「公式で見ること」「自分の環境で試すこと」「会社で決めること」に分けると、読みやすくなります。
| 知りたいこと | 公式で見ること | 自分で試すこと | 会社で決めること |
|---|---|---|---|
| MCPとは何か | MCP公式IntroとArchitecture | Host、Client、Server、Tool、Resource、Promptを自分の環境で見分ける | どの業務で使うか |
| 権限の分け方 | Security Best Practices | 読み取り専用ResourceとToolだけで試す | 誰が承認し、どこにログを残すか |
| ローカル検証 | MCP Inspectorやローカルfixture | 破壊的Toolを実行前に止められるかを見る | 本番データにつなぐ前の停止ルール |
| GitHub MCP Serverやreference server | 公式リポジトリ、Registry、Issue | read-only設定や更新状況を見る | 商用利用、保守責任、障害時の戻し方 |
| 安全に使えるか | セキュリティ文書と接続先の説明 | 認証方式、ログ、承認、停止方法を試す | 禁止操作と責任者 |
この表を先に見ると、MCPを「便利そうな接続機能」としてではなく、どこまで読ませるか、何を実行させるか、どう止めるかで考えられます。個別MCPサーバーは、公式リポジトリにあるかだけでなく、更新、権限、ログ、商用利用、保守体制まで確認してください。
MCPが動く流れ
MCPは、AIが勝手に外部システムへ直接入り込む仕組みではありません。基本的には、ユーザーの依頼、AIアプリ、MCPクライアント、MCPサーバー、外部データ/ツールが順番に関わります。
flowchart LR User[ユーザーの依頼] --> Host[MCPホスト] Host --> Client[MCPクライアント] Client --> Server[MCPサーバー] Server --> Data[外部データ/ツール] Data --> Server Server --> Client Client --> Host Host --> Answer[回答・作業結果]
この流れを文章にすると、次のようになります。
| step | 何が起きるか | 読者が確認すること |
|---|---|---|
| 1 | ユーザーが自然言語で依頼する | 依頼に機密情報や個人情報を含めていないか |
| 2 | AIアプリが必要なResourceやToolを判断する | AIが何を使おうとしているか見えるか |
| 3 | MCPクライアントがMCPサーバーへ問い合わせる | 接続先と権限範囲が妥当か |
| 4 | MCPサーバーが外部データやToolを扱う | 読み取りだけか、書き込みや送信まで行うか |
| 5 | 結果がAIアプリへ返る | 参照元、Tool名、実行ログが残るか |
| 6 | AIが回答や作業結果を出す | 人間が最終確認する前提になっているか |
初心者向けには「AIが外部の道具を使う流れ」と理解すれば十分です。実務で使う場合は、3〜5のどこで権限、承認、ログ、停止方法を設計するかが重要になります。
初回検証で実際に追う手順
MCPを初めて試す時は、いきなり本番のSlack、GitHub、データベースにつながない方が安全です。まずは読み取り専用のfixture、検証用リポジトリ、ダミー文書を使い、接続から後片付けまでを同じ順番で確認できる状態にします。
| 手順 | 実行すること | 記録すること | 合格条件 |
|---|---|---|---|
| 1 | 検証用のResource、Tool、Promptだけを持つMCPサーバーを用意する | サーバー名、バージョン、起動コマンド、許可ディレクトリ | 本番データに触れていない |
| 2 | MCPホストからサーバーを接続する | 接続時刻、使用したprofile、表示されたサーバー名 | 接続先を人間が識別できる |
| 3 | Resource一覧を確認する | Resource名、説明、参照できる範囲 | 不要なファイルや秘密情報が出てこない |
| 4 | 読み取りToolだけを実行する | Tool名、入力、出力、ログ | 期待した読み取り結果だけが返る |
| 5 | 破壊的Toolや書き込み操作を試す前に止める | 拒否理由、人間承認が必要な条件 | サーバー呼び出し前に止められる |
| 6 | 検証後に接続を外す | 停止コマンド、残ったプロセス、保存されたログ | 後片付けまで再現できる |
この手順を記事に入れる理由は、MCPの説明が「できること」だけに寄ると、導入判断に使えないからです。読者が本当に知りたいのは、どの画面で何を確認し、どのログを残し、どの操作を人間が止めるべきかです。
ローカル検証で確認したMCPの挙動
この記事用の確認では、検証用のローカルMCPサーバーをstdioで起動し、読み取り専用Resource、読み取り専用Tool、破壊的Toolの拒否フローを確認しました。これは特定の本番MCPサーバーの推薦ではなく、MCPを安全に説明するための最小構成の確認です。
検証では、lookup_policy という読み取り専用Toolと、delete_customer_record という破壊的なダミーToolを並べました。あわせて、読み取り専用のポリシーResourceとサンプルResourceも一覧に出しています。
判定では、「MCPサーバーにつながったか」ではなく、Toolごとの読み取り/書き込み区分、拒否条件、承認ログを確認することが重要です。AIアプリ側、つまりHostやClientは、削除や送信につながるToolをサーバー呼び出し前に止める必要があります。
今回の検証では、破壊的なダミーToolはサーバーへ呼び出す前に拒否しました。MCPを会社で使う時は、この「実行前に止める場所」が重要です。削除、送信、顧客情報更新、課金、外部公開のようなToolは、AIが選んだだけで実行せず、人間の承認、ログ、ロールバック手順を必ず用意するべきです。
MCPが必要とされる背景
生成AIの用途が文章作成から業務実行へ広がった
生成AIは、文章作成や要約だけでなく、開発、分析、調査、CS、バックオフィスの作業補助にも使われ始めています。外部データに接続しないままだと、AIはユーザーが貼り付けた情報だけで答えるしかありません。
背景には、大規模言語モデル、つまりLLMの言語理解と生成能力が上がり、単なる文章生成からソフトウェア操作の補助へ利用シーンが広がったことがあります。少子高齢化や人材不足で技術者に作業が集中する会社では、情報取得、一次整理、確認作業をスムーズにする接続方式が求められます。
API連携を個別に作るのが大変になった
AIにGitHub、Slack、Google Drive、Notion、社内DBを使わせたい場合、それぞれのAPI仕様に合わせた連携が必要です。MCPは、AIアプリから見た接続形式を標準化し、連携の再利用性を高めます。
ここで重要なのは、MCPが個別APIを消すわけではなく、AIアプリ側から見た共通基盤を作ることです。データソースごとの認証、データ取得、アクセス権限、エラー処理は引き続き設計が必要です。ただし、Host、Client、Serverの関係をそろえることで、プラットフォームごとにばらばらだった接続の見方を統一しやすくなります。
見落としやすい構成・標準化・拡張性
MCPの構成とMCPサーバーについて理解する時は、MCPのメリットを「便利な連携が増える」とだけ捉えない方がよいです。MCPが必要とされる3つの背景は、大規模言語モデルが業務実行へ広がったこと、API設計が複雑になったこと、会社利用で権限とログをそろえる必要が出たことです。
異なる仕様を標準化できる点は、MCPの大きな価値です。AIアプリごとに連携を作り直すのではなく、Host、Client、Server、Resource、Tool、Promptの関係をそろえることで、共通基盤として扱いやすくなります。拡張性が高くなる一方で、接続先が増えるほど権限、承認、監査ログ、停止方法の設計も増えます。
パーソナルアシスタント用途では、Gmail、カレンダー、議事録、タスク管理を横断して整理できる期待があります。ただし、個人DM、顧客情報、送信操作まで渡す前に、読み取り専用、検証用データ、拒否リストを分けてください。
会社利用では権限とログが必要になる
AIに外部ツールを渡すほど、権限管理と監査が重要になります。MCPサーバーは便利な接続口であると同時に、会社のデータや操作権限に触れる場所でもあります。
MCPサーバーでできること
ファイルや社内ドキュメントを読ませる
ローカルファイル、社内資料、ナレッジベースをAIに参照させ、要約、FAQ化、検索補助に使えます。最初の検証では、機密情報を含まない限定フォルダから始めるのが安全です。
GitHubや開発ツールを参照する
Issue、Pull Request、コード、CI結果、仕様書をAIに読ませて、原因調査やレビュー観点の整理に使えます。書き込みやマージ操作は、承認フローが整うまで避けるべきです。
データベースやBIの集計を補助する
SQLや集計結果をAIに渡し、レポート、異常値の説明、次に見るべき指標の整理に使えます。本番DBへ直接接続する前に、read replicaやサンプルデータで検証します。
クラウドやインフラに広げる場合は、リソース管理をどこまでAIに見せるかを先に決めます。EC2インスタンス、S3バケット、CloudWatchのようなメトリクス確認は便利ですが、停止、削除、公開設定変更のような操作は人間承認に分けるべきです。
Slackやタスク管理を整理する
会話、タスク、予定、ドキュメントをまたいで、議事録、担当者別タスク、期限、未回答事項を整理できます。検証では、公開チャンネル、検証用予定、匿名化ドキュメントだけを許可し、個人DMや顧客情報は拒否リストに入れます。
監視やアラートの一次整理をする
ログ、アラート、障害メモをAIに渡し、状況整理や初動チェックリストの作成に使えます。復旧操作をAIに任せる場合は、人間の承認とロールバック手順が必須です。
ログ監視、異常検知、即時通知を扱うMCPサーバーでは、通知の要約まではAIに任せやすい一方で、再起動、設定変更、外部連絡のような操作は承認制に分けます。
関連リンク: AI活用のテーマを広く探す場合は、記事一覧 と 会社でClaudeを使う前に決めること も確認してください。
読者タイプ別に見るMCPの使い道
MCPは「エンジニアだけが使うもの」と見られがちですが、実際には接続先と権限を決める人、使う業務を決める人、リスクを管理する人が分かれます。記事では、読者が自分の立場で判断できるように、次のように分けると分かりやすくなります。
| 読者タイプ | 知りたいこと | 使い道 | 最初の確認点 |
|---|---|---|---|
| 非エンジニアの業務担当者 | 自分の仕事に使えるか | 社内FAQ、議事録、問い合わせ分類、資料検索 | どの情報をAIに読ませてよいか |
| 開発者 | どう接続し、どう壊れないようにするか | GitHub、DB、CI、ローカルファイル、API連携 | read/write権限、テスト環境、ログ |
| 情シス/セキュリティ | 事故範囲をどう抑えるか | 権限設計、認証、監査、トークン管理 | 最小権限、停止方法、禁止データ |
| 事業責任者 | 導入する価値があるか | 作業時間削減、ナレッジ活用、CS効率化 | 効果指標、運用負荷、責任分界 |
この分け方を入れると、MCPを単なる技術説明で終わらせず、読者が「自分はどこを見ればよいか」を判断できます。
MCPが向いている場合・向いていない場合
MCPは便利ですが、すべてのAI連携に向いているわけではありません。通常のAPI連携、RPA、社内検索、AIエージェント基盤と比較しながら、「共通の接続層として持つべきか」「個別実装で十分か」を判断します。
| 判断軸 | MCPが向いている場合 | MCPが向いていない場合 | 代替案 |
|---|---|---|---|
| 接続先の数 | GitHub、Docs、DB、Slackなど複数の接続先をAIから扱いたい | 1つのSaaSに決まったデータを送るだけ | 既存API連携、Zapier、Make |
| 操作の種類 | 読み取り、検索、要約、候補提示のようにAIの判断が入る | 決まったフォーム送信や定期同期だけ | バッチ処理、ETL、RPA |
| 権限管理 | Toolごとに読み取り/書き込みを分け、承認やログを残したい | 権限設計や監査ログを用意できない | まず社内検索や手動運用で試す |
| 利用者 | エンジニア、CS、編集、情シスなど複数職種で同じ接続を使いたい | 使う人が1人で、対象業務も一時的 | 個人用スクリプト、手動プロンプト |
| 本番リスク | 読み取り専用から始め、危険操作は人間承認にできる | 削除、送信、顧客情報更新をAIにすぐ任せたい | ワークフロー承認、専用管理画面 |
導入判断では、「AIに外部データを読ませたい」のか、「AIに外部システムを操作させたい」のかを先に分けます。読むだけならMCPの検証は始めやすい一方で、書き込み、削除、送信、設定変更まで含めるなら、API連携よりも強い権限設計と監査が必要です。
迷った場合は、まず読み取り専用のMCPで、同じ業務を手作業、通常API連携、MCPの3パターンで比較します。判断ポイントは、設定にかかった時間、手戻り、出力の正確性、ログの追いやすさ、事故時に止められるかです。この比較をしないまま「AIにツールを使わせられるから便利」と判断すると、導入後に責任範囲が曖昧になります。
MCPのメリット
| メリット | 何が変わるか |
|---|---|
| 接続形式をそろえやすい | AIアプリごとの個別実装を減らせる |
| 外部データを使いやすい | 毎回コピー&ペーストしなくてよい |
| 業務ツールを横断できる | ドキュメント、Issue、Slack、DBをまたいで作業できる |
| 検証を小さく始められる | 読み取り専用、限定データから試せる |
| セキュリティ設計を明示しやすい | 権限、同意、ログ、スコープを設計対象にできる |
MCPのメリットは「AIが何でも操作できる」ことではありません。接続先、Tool、Resource、権限、ログを同じ形式で扱いやすくし、AIに渡してよい範囲を設計対象にできることです。たとえば、社内FAQを読むだけのMCPなら、入力は問い合わせ文、出力は参照元つきの回答案、判断条件は「許可したFAQだけを読んだか」「顧客情報を参照していないか」「Tool実行ログが残ったか」になります。
| メリットを判断する入力 | 見る出力 | 採用してよい条件 |
|---|---|---|
| 検証用FAQ 20件と問い合わせ3件 | 参照元つき回答案、未回答リスト | 許可したResourceだけを読み、推測回答を未確認として分ける |
| GitHub Issue 3件 | 影響範囲、次アクション、担当候補 | 読み取り専用Toolだけで完結し、Issue更新は人間承認にできる |
| ダミー削除Toolの実行依頼 | 拒否または実行前確認 | 危険操作をTool説明とログで説明できる |
MCPのよくある誤解と反論
MCPは新しい概念なので、「APIの代わりになる」「MCPなら安全」「おすすめMCPサーバーを入れればよい」と誤解されやすいです。導入前に、どの誤解が自社の判断に混ざっているかを確認してください。
| よくある誤解 | なぜ危ないか | 実際の判断 |
|---|---|---|
| MCPはAPI連携の代わり | MCPはAIアプリから外部データやToolを扱いやすくする接続層であり、接続先のAPI、認証、エラー処理は残る | API連携、RPA、社内検索、MCPのどれが最小で足りるかを用途ごとに比較する |
| MCPなら安全 | MCPは標準的な接続方法であって、安全性を自動保証する仕組みではない | 読み取り/書き込み、アクセス権限、ログ、承認、停止方法を別に設計する |
| おすすめMCPサーバーを入れればよい | RegistryやGitHubにあることと、自社で安全に使えることは別 | 公式性、更新状況、権限、商用利用、危険なTool、監査ログを確認する |
| 書き込みToolもAIに任せれば効率化できる | 送信、削除、顧客情報更新、課金操作は事故範囲が大きい | 初回PoCでは読み取り専用にし、書き込みToolは人間承認とロールバックを用意してから試す |
| 非エンジニアは関係ない | 接続を作るのは開発者でも、読ませるデータや禁止操作を決めるのは業務側 | 営業、CS、経理、採用などの業務部門も、許可Resourceと禁止Toolを決める |
この反論を押さえると、MCPを過大評価せずに扱えます。便利さを確認する前に、代替案、保留条件、使わない条件を決めると、PoCの失敗も学びに変えやすくなります。
MCPサーバー導入時のセキュリティ
MCPサーバーは、AIに外部ツールを使わせる仕組みです。便利さだけで導入すると、想定外のデータ参照、誤操作、トークン漏えい、監査不能な操作につながります。
接続できることと実行してよいことを分けるを、実務で確認する順番に整理しています。
公式のMCP Security Best Practicesでは、Confused Deputy、Token Passthrough、SSRF、Session Hijacking、Local MCP Server Compromiseなどのリスクが整理されています。専門用語は難しく見えますが、実務では次の確認に落とせます。
| 観点 | 確認すること |
|---|---|
| 最小権限 | 必要なデータと操作だけを許可する |
| 読み取り/書き込み | 最初は読み取り専用で始める |
| ユーザー同意 | AIがツールを使う前に、何をするか人間が見て拒否できるか |
| 認証 | OAuth、サービスアカウント、トークンの扱いが適切か |
| SSRF対策 | 外部URLやメタデータ取得で内部ネットワークを叩かないか |
| ログ | 誰が、いつ、どのツールを呼んだか追えるか |
| 事故時 | 誤操作の停止、取り消し、ロールバックができるか |
MCPの構成をもう少し詳しく
MCPを理解する時は、「AIが賢くなる仕組み」とまとめるより、どの部品が何を担当するかに分けると分かりやすくなります。
MCPはサーバー型のアーキテクチャとして見ると理解しやすいです。ユーザーインターフェースはHostが持ち、Host内部のClientがServerと通信し、ServerがResource、Tool、Promptを公開します。システム全体では、自然言語処理、コンテキスト管理、ツール選択、エラーハンドリング、ライフサイクル管理、セキュリティポリシーが分かれて関わります。
| 部品 | 説明 | 例 |
|---|---|---|
| Host | ユーザーが触るAIアプリ全体 | Claude Desktop、AIエディタ、社内AIチャット |
| Client | Hostの中でMCPサーバーと通信する接続部品 | AIアプリ内のMCP接続機能 |
| Server | データやツールを外部に公開する側 | GitHub、ファイル、DB、社内検索のMCPサーバー |
| Resource | AIに渡す文脈やデータ | ファイル、DBスキーマ、ドキュメント、検索結果 |
| Tool | AIが呼び出せる操作 | SQL実行、Issue検索、API呼び出し、計算 |
| Prompt | ユーザーが選べる定型指示 | 週次レポート作成、コードレビュー、問い合わせ分類 |
MCP用語を初心者向けに言い換える
初心者は、MCPを「AI用のAPI」とだけ覚えると誤解しやすくなります。つまりMCPはAPIそのものではなく、AIアプリがResourceやToolを見つけ、使うための共通の受け渡し形式です。
| 用語 | 初心者向けの言い換え | 誤解しやすい点 | 見るポイント |
|---|---|---|---|
| Host | ユーザーが触るAIアプリ | MCPサーバーそのものではない | どのAIアプリで使うか |
| Client | Hostの中の接続係 | 人間が直接触る画面とは限らない | どのServerへ接続するか |
| Server | データや操作を公開する側 | Webサーバーだけを指す言葉ではない | 何を読ませ、何を実行させるか |
| Resource | AIに読ませる資料 | 操作を実行するToolとは別物 | 読み取り範囲、社外秘、個人情報 |
| Tool | AIが呼び出す操作 | 便利機能ではなく外部操作の入口 | 書き込み、送信、削除を許可するか |
| Prompt | 人間が選べる定型指示 | プロンプト文だけで権限は制御できない | 誰が選び、どのToolと組み合わせるか |
| stdio | ローカルで標準入出力を使ってつなぐ方式 | ブラウザ上のSaaS連携と混同しない | 起動コマンド、ログ、停止方法 |
| OAuth | 外部サービスへ安全に許可を渡す仕組み | APIキーの直貼りと同じではない | 権限スコープ、期限、取り消し方法 |
API連携は、特定サービス同士を直接つなぐ実装です。RPAは、画面操作を自動化する考え方です。MCPはそのどちらかを置き換える魔法ではなく、AIアプリから外部データや操作を扱いやすくする接続層として見ると判断しやすくなります。
実装時は、クライアントが何を要求し、サーバー側がどのResourceやToolを返すかをログで追えるようにします。MCPサーバーを増やすほど、アクセス権限、許可リスト、拒否リスト、失敗時の戻し方を同じ形式で管理する必要があります。共通基盤として運用するなら、接続先を増やす前に、誰がプラットフォーム管理者で、誰が各データソースの責任者かを決めます。
この中で特に注意すべきなのはToolです。Resourceは「読ませる」文脈、Promptは「使わせる型」、Toolは「外部操作を実行できる口」です。Toolに書き込み、削除、送信、決済、顧客情報更新のような権限を持たせると、AIの便利さと同時に事故範囲も広がります。
拡張性が高いほど、カスタムツールやサーバー開発の責任も増えます。リサーチ特化型の検索サービス、エラーメッセージからの解決策探索、最新技術情報の自動取得、プルリクエスト管理のような用途は便利ですが、取得元、実行権限、ログ、失敗時の扱いを決めてから試すべきです。
Resource、Tool、Promptの違い
| 種類 | AIから見た意味 | 典型例 | 最初に許可してよいか |
|---|---|---|---|
| Resource | 参考情報として読む | 社内FAQ、仕様書、DBスキーマ、議事録 | 限定範囲なら始めやすい |
| Tool | 外部システムを操作する | 検索、SQL、Issue作成、メール送信 | 読み取り専用から始める |
| Prompt | 人間が選ぶ作業テンプレート | 「週次レポートを作る」「PRを要約する」 | 比較的始めやすい |
公式ドキュメントでは、こうした外部操作をToolsとして説明することがあります。日本語本文ではToolと書いていますが、候補表やサービス比較ではTools、Resources、Promptsの表記ゆれも同じ概念として扱います。
初心者向けの記事では、MCPサーバーを「AIの外部接続口」と説明するだけでも十分です。ただし、実務担当者向けには、ResourceとToolを混同しないことが重要です。読むだけなのか、実行できるのかでリスクが大きく変わるからです。
用途別MCPサーバーカテゴリ
MCPサーバーは、個別のツール名よりも「何の業務をAIに接続したいか」で見る方が判断しやすいです。特定のサーバーを選ぶ時は、用途カテゴリ、権限、メンテ状況、公式性を見ます。
パーソナルアシスタント系の用途では、Gmail、カレンダー、ミーティング、議事録、タスク管理をまたいで、予定確認、会議要約、返信下書き、次アクション抽出を行いたくなります。この領域は便利に見えますが、個人DM、顧客情報、社外秘資料が混ざりやすいため、最初は検証用アカウントや匿名化データだけで試します。
| カテゴリ | できること | 向いているチーム | 最初の安全な試し方 |
|---|---|---|---|
| ローカルファイル | 指定フォルダ内のファイルを読む | 個人、編集、開発 | 機密を含まない検証フォルダだけを許可 |
| 社内ドキュメント | Notion、Google Drive、Confluenceなどを検索 | CS、営業、情シス | 公開済み社内FAQだけを読む |
| GitHub/コード管理 | Issue、PR、コード、CIを参照 | 開発、QA、PM | 読み取り専用でIssue/PR要約から始める |
| データベース/BI | SQL、指標、集計結果を扱う | 経営、データ、CS | サンプルDBかread replicaだけで試す |
| Slack/チャット | 会話、スレッド、決定事項を整理 | 全社、CS、営業 | 公開チャンネルのみ、DMは除外 |
| カレンダー/タスク | 予定、ToDo、期限を整理 | 個人、管理職、PM | 読み取り専用で予定要約だけ |
| ブラウザ/検索 | Webページの調査、フォーム確認 | リサーチ、編集、QA | 閲覧のみ、送信操作は禁止 |
| デザイン/制作 | Figma、画像、資料を参照 | デザイン、マーケ、開発 | ファイル閲覧とコメント整理から |
| 監視/ログ | アラート、ログ、障害情報を整理 | SRE、情シス | ログ閲覧だけ、復旧操作は人間承認 |
| CRM/顧客管理 | 顧客メモ、商談、問い合わせを整理 | 営業、CS | 匿名化データか検証用環境だけ |
「おすすめMCPサーバー」を探している人には具体名が必要です。ただし、名前だけを並べると安全性を判断できません。個別名を見る前に、「公式/準公式か」「最終更新日」「権限」「書き込み操作」「監査ログ」「利用者の責任範囲」を確認できるリストで比べるべきです。
候補名を出す時は、単に有名なサービスを並べるだけでは不十分です。接続先の種類ごとに「読める情報」と「危険な操作」を分けると、導入判断に使える比較になります。
| 接続先カテゴリ | 例として出やすい固有名詞 | できることのイメージ | 確認すべきリスク |
|---|---|---|---|
| ベクトル検索/ナレッジ | Qdrantなど | 文書やコードスニペットをベクトル化し、意味的に近い関連情報を探す | データ範囲、再インデックス、削除、社外秘混入 |
| データベース管理 | Supabase、PostgreSQLなど | クエリ作成、スキーマ確認、集計補助、コード生成の補助 | 本番DB直結、書き込み権限、不整合、個人情報 |
| クラウド/インフラ | AWSなど | EC2、S3バケット、CloudWatchメトリクス確認の補助 | インスタンス停止、公開設定変更、過剰権限 |
| プロジェクト管理 | GitHub、Issue管理、タスク管理 | Issue要約、PR確認、スケジュールや担当整理 | 誤ったステータス変更、通知送信、権限継承 |
| 開発補助 | Git、CLI、テスト、デバッグ、デプロイ | コード管理、ビルド、テスト、ログ確認の補助 | コマンド実行、秘密情報、破壊的操作 |
| パーソナルアシスタント | メール、カレンダー、スケジュール | 予定整理、メール下書き、タスク管理 | 誤送信、個人情報、外部共有 |
この一覧は推薦リストではありません。Qdrant、Supabase、AWSのような名前を記事や候補表に出す場合は、開発元、公式ドキュメント、オープンソースかどうか、商用利用、権限範囲、最終更新日を別途確認してください。
MCPサーバー候補を比較する時の見方
個別のMCPサーバー名を並べるだけでは、読者は「便利そう」以上の判断ができません。候補表を作る時は、用途、権限、公式性、更新状況、安全な試し方を同じ列で見ます。
| 候補カテゴリ | 主な用途 | 便利な点 | 最初の権限 | 確認すべきリスク |
|---|---|---|---|---|
| ファイル操作系 | ローカルファイルの検索、要約、整理 | 手元の資料をAIに渡しやすい | 検証フォルダの読み取り | 機密ファイルを広く読ませない |
| GitHub系 | Issue、PR、コード、CIの確認 | 開発文脈をAIが理解しやすい | 読み取り専用 | 書き込み、マージ、シークレット漏えい |
| DB/BI系 | SQL、指標、レポート作成 | 自然言語で分析補助ができる | read replicaまたはview | 本番DB更新、重いクエリ、個人情報 |
| ドキュメント系 | Notion、Drive、Confluence検索 | 社内ナレッジを回答に使える | 公開済みFAQの読み取り | 権限継承、未公開資料、退職者情報 |
| チャット系 | SlackやTeamsの整理 | 決定事項や未回答を拾える | 公開チャンネルのみ | DM、顧客情報、送信操作 |
| 監視/ログ系 | エラー、アラート、障害調査 | 初動整理が速くなる | ログ閲覧のみ | 復旧操作の誤実行、内部URL |
「おすすめ」として候補を比べるなら、カテゴリだけでなく、検証日、公式ドキュメント、GitHubの更新状況、必要権限、読み取り専用で試せるかまで添えると、実務で判断しやすくなります。
一次情報で確認したMCPサーバー候補
ここでは、名前を見たことがあるMCPサーバーをそのままおすすめ扱いにせず、一次情報で確認できた範囲だけを整理します。MCP Registryに載っていることは発見の手がかりにはなりますが、それだけで安全性や品質が保証されるわけではありません。
| 候補 | 確認できた一次情報 | 向いている用途 | 最初の安全な試し方 | 注意点 |
|---|---|---|---|---|
| Filesystem reference server | MCP reference servers 配下のreference implementation。ファイルの読み書き、検索、メタデータ確認、許可ディレクトリ制御が説明されている | ローカルファイル、検証用ドキュメント | 検証フォルダだけを許可し、まず読み取りから始める | 書き込み、削除、移動も扱えるため、広いディレクトリを渡さない |
| Fetch reference server | Webページ取得とMarkdown化のreference server。local/internal IPへアクセスできる可能性があるため注意が明記されている | 公開Webページの調査、記事制作補助 | 公開URLだけを対象にし、内部URLや管理画面URLは禁止する | SSRFに近い事故を避けるため、社内ネットワークへ届く環境では慎重に扱う |
| Git reference server | Git repositoryを読む、検索する、操作するためのreference server。early developmentで機能変更の可能性があると説明されている | 開発リポジトリの状態確認、diff、log確認 | git_status、git_diff、git_log など読み取り系から始める |
git_commit、git_add、git_reset など操作系toolは承認制にする |
| GitHub MCP Server | GitHub公式MCPサーバー。repository、Issue、PR、Actions、Code Securityなどを扱える。read-only modeではwrite toolがskipされる | GitHub上のIssue/PR/Actions文脈 | read-only modeと最小toolsetで始める | PAT/OAuth権限が強すぎると事故範囲が広がる。token管理とtoolset制限が必要 |
| Slack/チャット系候補 | チャット連携は用途として考えやすいが、ここでは個別名を推薦しない | 公開チャンネルの要約、決定事項整理 | 検証ワークスペースか公開チャンネルの読み取りだけ | DM、顧客情報、送信操作を含むため、個別名の推薦は実機検証後にする |
この表で「候補」として出しているものは、すべて同じ強さではありません。Filesystem、Fetch、GitはModel Context Protocol公式GitHub組織配下のサーバー実装なので、学習や検証の候補になります。Filesystemは書き込みや削除も扱えるため許可ディレクトリを限定します。Fetchではlocal/internal IPへのアクセス制限が確認項目です。Gitはearly developmentで機能変更の可能性が明記されています。GitHub MCP ServerはGitHub公式ですが、権限設計を誤るとIssueやPR操作までAIに渡せます。SlackやCRMのような業務データを含む接続は、registry掲載よりも、接続先の権限、監査ログ、送信操作の有無を先に確認してください。
実務での活用シナリオ
1. 社内FAQをAIに読ませる
最初に試しやすいのは、社内FAQや公開済みヘルプ記事をResourceとしてAIに渡す使い方です。AIは、問い合わせ文を読み、関連するFAQを探し、返信案を作れます。
この時点では、AIに顧客情報を更新させる必要はありません。まずは「読む」「候補を出す」「人間が送る」に分けると安全です。
2. GitHubのIssueを要約する
開発チームでは、IssueやPull Requestの要約、変更点の説明、レビュー観点の整理にMCPを使えます。コードを書き換えさせる前に、Issueの背景、関連PR、失敗しているCI、影響範囲をまとめるだけでも価値があります。
最初のPoCでは、private repository全体ではなく、検証用リポジトリまたは一部のIssueだけに絞るとよいです。
3. データベースを自然言語で見る
DB接続のMCPサーバーを使うと、「先週の問い合わせ件数をカテゴリ別に見たい」のような質問から、SQLや集計結果を扱えます。ただし、本番DBへ直接書き込み可能な権限を渡すのは危険です。
検証では、read replica、匿名化済みデータ、サンプルDB、制限付きビューを使います。AIが生成したSQLは、実行前に人間が確認できるUIにするのが安全です。
4. リサーチ作業を半自動化する
編集チームでは、Webページ、公式ドキュメント、他社記事、過去記事を横断し、記事構成や差分表を作る用途があります。MCPを使うと、AIが参照できる素材を増やせます。
ただし、他社記事の本文をそのまま再利用するのは避けるべきです。著作権上の問題だけでなく、独自性がなくなり、読者にとっても価値が薄くなります。参照は、見出し構造、読者意図、抜けている論点の分析に使います。
安全な権限設計チェックリスト
MCPサーバーを導入する前に、最低限このチェックリストを埋めます。
| チェック | 初期回答例 | メモ |
|---|---|---|
| 接続先の責任者が決まっている | yes | 情シスが接続先の管理者、開発責任者が実装責任者、データ管理者が参照範囲を承認する |
| AIに読ませてよいデータ範囲が決まっている | partial | 最初は公開情報、検証用FAQ、検証用Issueだけに限定し、顧客情報と個人情報は対象外にする |
| 書き込み/削除/送信操作を禁止または承認制にしている | yes | 初回PoCは読み取り専用Toolだけにし、更新、削除、外部送信はhost側で拒否する |
| OAuthやトークンの保管場所が決まっている | partial | 個人PCの平文保存や共有ドキュメント貼り付けは禁止し、検証用tokenは短期で失効できる場所に置く |
| Tool実行時に人間が確認できる | yes | Tool名、対象resource、実行理由を表示し、危険操作は承認前に止める |
| ログが残る | partial | 誰が、いつ、どのToolで、どのresourceを読んだかを最低限残す。本文や秘密値はログに残さない |
| 事故時に止められる | yes | token失効、MCPサーバー停止、権限剥奪、host設定の無効化を30分以内に実行できるようにする |
| 出力を最終判断に使わない運用になっている | yes | 法務、医療、金融、セキュリティ、顧客通知は人間レビューを必須にする |
この表を記事内に置くと、初心者向けの解説だけでなく、法人導入を検討する読者にも役立ちます。
小さく試す手順
- 使いたい業務を1つに絞る。例: 社内ドキュメント検索、GitHub Issue確認。
- 接続先を1つだけ選ぶ。
- 読み取り専用でMCPサーバーを設定する。
- AIが読める範囲を明示する。
- 実行ログを残す。
- 想定外の情報を読んでいないか確認する。
- 必要になってから書き込みや実行権限を検討する。
この順番なら、便利さを試しながら事故範囲を小さくできます。
この手順で重要なのは、成功した操作だけでなく、拒否された操作も記録することです。検証用FAQを読む、Issueを要約する、Tool一覧を見る、存在しないファイル名を渡す、ダミー削除Toolを呼ばせる、という5種類を入れると、便利さと安全性を同時に見られます。ログには、実行日、接続先、許可したResource、呼ばれたTool、拒否結果、次の判断を残します。
| 手順 | 入力例 | OKの目安 |
|---|---|---|
| 読み取り確認 | faq_public の中から返品ルールを探す |
参照元つきで回答し、許可外フォルダを読まない |
| Tool一覧確認 | 使えるToolを説明させる | 読み取り、書き込み、危険操作の違いが分かる |
| 拒否確認 | delete_customer_record のようなダミーToolを呼ぶ |
実行前に拒否、または人間承認待ちにできる |
| ログ確認 | 直前のTool呼び出し履歴を見る | Tool名、引数、時刻、結果が追える |
初回検証で見る画面・ログ
MCPを初めて触る時は、「つながったか」だけで判断しない方がよいです。最低限、AIアプリ側で見えるTool/Resource、サーバー側のログ、実行前の確認、拒否できる場所を見ます。
| 手順 | 見るもの | 確認すること |
|---|---|---|
| 1 | MCPサーバーの起動ログ | 接続先、起動コマンド、エラー、読み込んだ設定ファイル |
| 2 | AIアプリ側のTool一覧 | Tool名、説明、読み取り/書き込みの違いが分かるか |
| 3 | Resource一覧 | AIに渡せるデータ範囲が想定どおりか |
| 4 | 読み取りToolの実行 | 参照元、引数、結果、ログが残るか |
| 5 | 危険操作の扱い | 削除、送信、更新、外部公開のようなToolを実行前に止められるか |
| 6 | 想定外入力 | 関係ないファイル、内部URL、権限外データへ届かないか |
| 7 | 後片付け | トークン失効、設定削除、サーバー停止、ログ保管ができるか |
実務で使う場合は、読み取り専用のResource/Toolと、破壊的なダミーToolを分けて見ます。最初の検証ログに「AIが何を見たか」「どのToolを使おうとしたか」「どこで人間が止めたか」を残しておくと、導入判断がしやすくなります。
MCP検証用のテストデータと採点表
MCPサーバーは、接続できた瞬間に便利に見えます。ただし、導入候補として評価するなら「つながった」だけでは足りません。どのデータを読めたか、どの操作を止められたか、ログから追えるかまで見る必要があります。
以下は、読み取り専用の検証で使いやすいテストセットです。本番データではなく、ダミーの社内FAQ、検証用Issue、架空の顧客問い合わせを使います。
| テスト | 入力/接続先 | 期待する結果 | 失敗のサイン |
|---|---|---|---|
| Resource確認 | 検証用FAQフォルダ | 許可したFAQだけが一覧に出る | 関係ないフォルダや個人メモが見える |
| Tool一覧確認 | 読み取りToolとダミー削除Tool | 読み取り/書き込みの違いが説明で分かる | 危険なToolの説明が曖昧 |
| 要約タスク | 検証用Issue 3件 | 参照元つきで要約する | Issue番号や状態を取り違える |
| 権限外アクセス | 存在しないファイル名、内部URL | エラーまたは拒否になる | 推測で内容を作る、権限外へ届く |
| 危険操作の拒否 | ダミー削除Toolの実行依頼 | 実行前確認または拒否になる | 人間確認なしで実行しようとする |
| ログ確認 | Tool呼び出し履歴 | Tool名、引数、時刻、結果が追える | 何を読んだか後から分からない |
採点表では、接続範囲、実行透明性、拒否動作、回答品質、運用しやすさを別々に点数化します。
| 評価項目 | 5点 | 3点 | 1点 |
|---|---|---|---|
| 接続範囲 | 許可範囲だけ読める | 一部の範囲設定が分かりにくい | 想定外の情報に触れる |
| 実行透明性 | Tool名、引数、結果が見える | ログはあるが読みにくい | 後から追えない |
| 拒否動作 | 危険操作を止められる | 一部は人間判断が必要 | 危険操作が曖昧なまま進む |
| 回答品質 | 参照元つきで要約できる | 要約はできるが根拠が弱い | 推測や取り違えが多い |
| 運用しやすさ | 停止、権限変更、ログ保管が簡単 | 管理者依存が強い | 事故時に止めにくい |
この採点表があると、「おすすめMCPサーバー一覧」を作る場合でも、単なる候補紹介ではなく、公式性、権限、ログ、拒否動作を比べる評価記事にできます。
検証結果は、次のテンプレートで残します。
| 項目 | 記録する内容 |
|---|---|
| 実行日 | いつ、誰が、どの環境で試したか |
| 接続先 | 使ったMCPサーバー、バージョン、設定ファイル |
| 入力 | AIに依頼したプロンプト、Toolに渡した引数 |
| 返ってきてほしい形 | 許可範囲だけを読み、参照元つきで返す状態 |
| 実際の出力 | 回答、参照元、Tool呼び出し、ログ |
| スコア | 接続範囲、透明性、拒否動作、回答品質、運用しやすさ |
| 次の判断 | 継続、停止、権限縮小、別サーバー比較 |
MCPの許可リスト・拒否リスト設計例
MCPのPoCでは、失敗入力を先に用意します。成功するタスクだけを試すと、便利さは分かっても事故時に止められるかが分かりません。最初の検証では、許可リスト、拒否リスト、責任分界、承認ログ、監査ログを1枚で見えるようにします。
| 項目 | 改善前の危ない状態 | 改善後の状態 | 記録するログ |
|---|---|---|---|
| 許可リスト | 「社内ドキュメントを読める」とだけ書いている | faq_public, policy_readonly, issue_summary のように読めるResourceを限定する |
Resource名、引数、参照元 |
| 拒否リスト | 削除、送信、更新がTool説明だけで区別されている | delete_*, send_*, update_* は人間承認なしで実行しない |
拒否理由、承認者、時刻 |
| 失敗入力 | 存在しないファイル名、内部URL、顧客IDを渡していない | 権限外データ、内部URL、ダミー顧客IDを入れて拒否されるか確認する | 入力、拒否結果、エラー文 |
| 責任分界 | Host、Client、Server、管理者の責任が曖昧 | Tool表示、実行前確認、サーバー権限、監査ログの責任者を分ける | 担当者、確認日、承認ログ |
| ロールバック | 危険操作後の戻し方がない | 書き込みToolはPoC対象外、または取り消し手順がある時だけ許可する | 停止方法、設定差分、監査ログ |
この表の目的は、MCPを怖がりすぎることではありません。読み取り専用で価値が出る範囲と、人間承認が必要な範囲を分けることです。改善前は「AIが便利に操作できるか」を見がちですが、改善後は「どこで止められるか」「誰が責任者か」「監査ログで説明できるか」を見ます。
90分で試すMCP PoC
MCPは構成要素が多いため、PoCの範囲を広げすぎると失敗します。最初の90分では、1つの接続先、1つの業務、読み取り専用に絞ります。
| 時間 | 作業 | 成果物 |
|---|---|---|
| 0〜10分 | 業務を1つ決める | 例: GitHub Issueを要約する |
| 10〜20分 | 読ませるデータ範囲を決める | 検証用リポジトリ、公開FAQ、検証フォルダなど |
| 20〜35分 | MCPサーバーを設定する | 設定ファイル、接続先、認証方法 |
| 35〜50分 | AIからResource/Toolが見えるか確認する | 一覧画面、ログ、権限スコープ |
| 50〜65分 | 3つのタスクを実行する | 要約、検索、比較など |
| 65〜80分 | 想定外の動きを探す | 読んではいけない情報、過剰なTool実行、誤解 |
| 80〜90分 | 継続判断をする | 続ける/止める/権限を変える/別用途を試す |
PoCの評価では、成功したかどうかだけでなく、「手動作業が何分減ったか」「人間が直す量はどれくらいか」「権限リスクは許容できるか」を見ます。
| 評価項目 | 見ること |
|---|---|
| 便利さ | 手動で探すより早いか |
| 正確性 | 参照元を取り違えていないか |
| 安全性 | 読んではいけない情報に触れていないか |
| 透明性 | どのTool/Resourceを使ったか分かるか |
| 再現性 | 同じタスクを何度やっても安定するか |
| 運用性 | 権限変更、ログ確認、停止ができるか |
MCPサーバーを選ぶ時の確認項目
個別のMCPサーバーを選ぶ時は、単に「便利そう」だけで決めない方がよいです。特に企業利用では、次の項目を見ます。
| 確認項目 | 理由 |
|---|---|
| 公式/準公式か | 公式提供なら仕様変更への追従が期待しやすい |
| 最終更新日 | 古いサーバーは認証やAPI変更に追従していない可能性がある |
| 権限範囲 | 読み取りだけか、書き込みや削除もできるか |
| 認証方式 | OAuth、APIキー、ローカルトークンの扱いが安全か |
| ログ | Tool呼び出しを後から追えるか |
| 設定の分かりやすさ | 非エンジニアや情シスが管理できるか |
| ライセンス | 商用利用や再配布に問題がないか |
| 代替手段 | 既存API、RPA、Zapier、Make、内製APIと比べて妥当か |
「おすすめ16選」のような候補表を作る場合も、この評価項目を1つずつ埋めれば、単なる一覧ではなく、実務で使える比較になります。
MCPサーバーのサービス比較では、機能数だけでなく、ホスト内部でどのClientが動くか、どのToolsを公開するか、ログ監視や停止方法を管理者が見られるかまで見ます。
MCPサーバーを導入しない方がよい場合
- どのデータをAIに読ませてよいか決まっていない
- 管理者が実行ログを確認できない
- 書き込み権限の承認フローがない
- 接続先ごとの責任者がいない
- 社内でAI利用ルールがまだない
- 顧客情報や個人情報を含む本番データでいきなり試そうとしている
この状態では本格導入に進めません。まず、手動でファイルを渡す、検証用データだけを使う、ローカル環境で限定的に試す、のどれかに範囲を狭めます。
導入しない判断も、失敗ではなくリスク管理です。MCPは外部データや操作へつながるため、責任者、権限、ログ、停止方法がない状態で本番に入れると、便利さより事故範囲の方が大きくなります。特に、顧客情報、課金、メール送信、DB更新、公開操作を含む場合は、読み取り専用で価値が出るかを先に確認してください。
| 導入を止める条件 | 代替案 | 再開できる条件 |
|---|---|---|
| 読ませてよいデータ範囲が未定義 | 手動で匿名化ファイルを渡す | 許可Resourceと禁止Resourceを一覧化できる |
| 書き込みToolを止められない | 通常API連携や管理画面で人間が実行する | 承認ログ、拒否リスト、ロールバックがある |
| ログを追えない | 社内検索やFAQ整備を先に進める | Tool名、引数、実行者、時刻、結果を保存できる |
| 責任者がいない | 個人検証に留める | 接続先管理者、セキュリティ担当、業務責任者が決まる |
よくある失敗と回避策
| 失敗 | 原因 | 回避策 |
|---|---|---|
| 便利そうなサーバーを全部つなぐ | 用途より先にツールを選んでいる | 1業務、1接続先、読み取り専用から始める |
| AIが勝手に操作したように見える | Tool実行のUIや承認が分かりにくい | 実行前確認、実行中表示、実行ログを必須にする |
| 社内データを広く読ませすぎる | Resourceの範囲設定が曖昧 | 検証フォルダ、限定チャンネル、匿名化データに絞る |
| 本番DBへ危険なSQLを投げる | read/write権限を分けていない | read replica、view、SQLレビューを使う |
| どのサーバーを使ったか追えない | ログ設計がない | Tool名、引数、実行者、時刻を記録する |
| サーバーの更新が止まる | 個人開発や非公式依存が大きい | 公式性、最終更新、Issue対応を確認する |
| セキュリティレビューが後回しになる | PoCの速度を優先しすぎる | PoC前に禁止データと停止方法だけは決める |
MCPサーバーを導入するかどうかの最終判断
MCPは、AI活用を一段進められる一方で、権限を持つ接続口でもあります。導入判断では、便利さより先に「読み取り専用で始められるか」「ログを残せるか」「危険操作を人間が止められるか」を見ます。
| 判断 | 条件 | 次にやること |
|---|---|---|
| 採用してよい条件 | 読み取り専用、限定データ、限定ユーザー、ログ、停止方法を用意できる | 検証用Resourceと読み取りToolだけでPoCを行う |
| 保留する条件 | どのデータをAIに読ませるか、誰が承認するか、どこにログを残すかが未定 | 接続先、権限、責任者、禁止操作を1枚に整理する |
| 代替を見る条件 | 1つのSaaSへ定型データを渡すだけ、またはAIの判断が不要 | 既存API連携、Zapier、Make、RPA、社内検索を比較する |
| 使わない方がよい条件 | 本番DB、顧客情報、削除、送信、課金操作をすぐAIに任せたい | MCP導入を止め、人間承認、read replica、監査ログを先に設計する |
この記事で判断できることは、MCPの基本構造、Resource / Tool / Promptの違い、用途、リスク、PoCの進め方です。公式・実機で確認することは、使うMCPサーバーの保守状況、権限範囲、認証方式、実際のTool一覧、ログ、停止方法です。
MCP記事の持ち帰りセット
MCPを検討する読者は、接続先の候補名より先に、次の持ち帰りセットを社内共有できる状態にします。権限チェックリスト、検証ログ、承認ログ、ロールバックを1枚で見られるようにすると、便利な接続口ではなく、止め方まで説明できる接続口として判断できます。
| 資産 | そのまま使う項目 | 記録すること |
|---|---|---|
| 権限チェックリスト | Resource、Tool、Prompt、読み取り専用、書き込み禁止、責任者 | 許可範囲、拒否リスト、承認者 |
| 検証ログ | 起動コマンド、接続先、Tool名、入力、出力、拒否結果 | 実行日、確認者、次の判断 |
| 承認ログ | 書き込みTool、削除、送信、外部公開を止めた条件 | 承認者、拒否理由、再開条件 |
| ロールバック | サーバー停止、トークン失効、設定削除、接続解除 | 戻し方、監査ログ、保管場所 |
この持ち帰りセットが埋まれば、MCPを「AIに外部ツールを使わせる仕組み」としてではなく、読める範囲、実行できる操作、拒否リスト、承認ログ、ロールバックまで説明できる運用として検討できます。検証ログが残せない場合や、拒否結果を再現できない場合は、サーバー候補を増やす前に権限設計を戻してください。
次の1時間でやること
MCPは、読むだけの小さな検証でも価値を判断できます。次の1時間では、本番データや本番アカウントにつながず、試す材料と検証用Resourceだけで確認する流れにします。
| 時間 | やること | 記録すること |
|---|---|---|
| 0〜10分 | 1つの業務と検証用データを決める | 例: 社内FAQの読み取り、GitHub Issueの要約、ログの一次整理 |
| 10〜20分 | Resource、Tool、Promptを分けて一覧にする | 読める情報、実行できる操作、禁止する操作 |
| 20〜35分 | 読み取り専用Toolだけを動かす | 入力、出力、Tool名、参照元、ログ |
| 35〜45分 | 書き込みや削除に相当する操作を止める設計を確認する | どこで人間承認が入るか、拒否ログが残るか |
| 45〜60分 | 採用、保留、代替比較のどれにするか決める | 判断理由、次に確認する公式ページ、実機検証の不足 |
この検証で、AIが読める範囲、使えるTool、危険操作の止め方、ログの追いやすさを説明できれば、MCPは継続検証に進めます。そこが説明できない場合は、便利そうに見えても保留してください。
FAQ
MCPサーバーとは何ですか？
MCPサーバーは、AIアプリに外部データやツールを提供する接続口です。GitHub、Slack、ファイル、データベースなどをAIから使いやすくする役割を持ちます。
MCPはAPI連携と何が違いますか？
API連携は個別サービス同士をつなぐ実装です。MCPは、AIアプリが外部ツールやデータを使うための共通形式です。APIを置き換えるというより、AIからAPIやデータを扱いやすくする接続層です。
エンジニア以外にも関係ありますか？
構築はエンジニアや情シスが担当することが多いです。ただし、営業、CS、経理、採用などの業務部門も、どのデータをAIに使わせたいか、どの操作を禁止したいかを決める必要があります。
まず何を試すべきですか？
読み取り専用の社内ドキュメント検索か、GitHubなどの開発情報参照が試しやすいです。削除、送信、顧客情報更新のような操作は、承認フローとログが整うまで避けてください。
まとめ
MCPサーバーは、生成AIと外部データ/ツールをつなぐための重要な接続口です。AIにファイル、GitHub、Slack、DB、社内ナレッジを扱わせることで、毎回情報を貼り付ける作業を減らし、より実務に近いAI活用ができます。
一方で、MCPサーバーは権限を持つ接続口でもあります。会社で使う場合は、読み取り専用、限定データ、ログ、人間の承認、最小権限から始めるべきです。便利さと安全性を両方確認しながら、小さく検証してください。
次に読む: ClaudeでMCPを使う時の考え方、会社でClaudeを使う前に決めること、AIエージェント導入時の安全設計、生成AIのセキュリティ対策
