MCPとは？仕組み・できること・APIとの違い・安全な導入方法

MCPの仕組みをHost・Client・Serverで理解する

MCPは、AIアプリが外部の情報や機能を共通の形式で利用するための接続ルールです。実務では、利用者が操作するAIアプリ側のHost、接続を管理するClient、データや操作機能を公開するServerを分けると、どこで認証し、何を許可し、どこにログを残すかを整理できます。

Tools・Resources・Promptsの違い

Toolsは検索、登録、更新など実行可能な操作、Resourcesは文書やデータなど参照対象、Promptsは再利用する指示のひな型として考えると整理しやすくなります。顧客台帳を読むResourcesと、顧客情報を更新するToolsでは事故時の影響が異なるため、同じ権限で公開しません。

ローカル接続とリモート接続

端末内のファイルや開発環境へ接続する場合と、社内外のサーバーへ接続する場合では、認証、ネットワーク、秘密情報の保管、ログの管理者が変わります。検証では読み取り専用のローカル環境から始め、外部送信と書き込み操作は承認工程を追加してから広げます。

MCPとA2Aは目的が異なる

MCPはAIアプリとツール・データの接続を標準化する考え方です。一方、A2Aは複数のエージェントが役割や進捗を共有して協働する場面で比較されます。社内データを読ませたいだけなら、最初から複数エージェント連携まで導入する必要はありません。

営業資料検索から始める導入例

最初の検証では、公開済みの営業資料だけをResourcesとして読み取り、質問に対して候補資料名と該当箇所を返す構成にします。CRMへの書き込みやメール送信はまだ許可しません。回答が正しいか、資料を探す時間が減ったか、古い版を参照していないかを2週間測ります。読み取りで再現性が確認できた後に、下書き作成、承認依頼、登録と一段ずつToolsを増やします。

この順序なら、MCPを導入したこと自体ではなく、検索時間、誤参照、承認待ち、手作業登録のどこが改善したかを切り分けられます。接続数を増やすほど成果が上がるわけではありません。使われないServer、広すぎる権限、所有者不明の接続は、月次で停止候補にします。

MCPサーバー選定で見る項目

提供者、更新履歴、ソース公開状況、必要権限、送信データ、認証方式、ログ、障害時の停止方法を確認します。便利な配布物でも、管理者が不明、過剰な権限を要求する、更新が止まっている場合は本番利用を避けます。自作する場合も、入力値の検証と権限確認をClient任せにしません。

本番化の可否を決める記録

接続名、所有者、利用部署、読み取り・書き込み範囲、認証方式、保存するログ、承認が必要な操作、停止方法、見直し日を台帳にします。PoC終了時には、削減時間だけでなく、誤取得、権限超過、操作失敗、人の承認で止めた回数を確認します。成果が小さい接続や管理者不在の接続は、便利そうでも本番へ残しません。

MCPとは「AIと外部データ・操作の接続方法をそろえる規格」

MCP（Model Context Protocol）は、AIアプリケーションが外部のデータ、ツール、定型プロンプトへ接続する方法を標準化するオープンプロトコルです。USBのように何でも安全につながる魔法ではありません。接続形式をそろえやすくする一方、どのデータを渡すか、どの操作を許すか、誰が承認するかは導入側が設計します。

MCPの全体像をHost・Client・Serverで理解する

重要なのは、MCP Serverが通常、会話全体や他のServerを自動的に見られる設計ではない点です。Hostが必要な情報と接続を管理します。ただし実装が不適切なら境界は崩れるため、「規格を使っている＝安全」とは判断できません。

Tools・Resources・Promptsの違い

読み取りと書き込みを同じToolへまとめると、権限管理が難しくなります。検索、下書き、更新、削除は別のToolとして公開し、利用者と環境ごとに許可を変えます。

MCPとAPI・Function Calling・RAGの違い

MCPを採用しても、基盤となるAPIやデータ設計は不要になりません。接続先が一つで処理も固定なら、直接APIの方が単純な場合があります。複数のAIアプリから同じ機能を利用したい、接続を交換・再利用したい場合にMCPの価値が大きくなります。

ローカルMCPとリモートMCPの違い

ローカルServerは外部公開しないから無条件に安全ではありません。公式仕様ではローカルHTTPはlocalhostへ束縛し、Originを検証し、適切な認証を実装する考え方が示されています。0.0.0.0で不用意に待ち受けると、他端末やWeb経由の攻撃面が広がります。

MCP導入で起きる主なセキュリティリスク

MCPの認可仕様はHTTP接続でOAuth 2.1に基づく仕組みを定義していますが、認可は実装と運用が必要です。受け取ったtokenを別の下流サービスへそのまま渡すtoken passthroughは避け、対象リソースへ結び付いたtokenを検証します。

安全なMCP Serverを選ぶ12項目

MCPを企業へ導入する7ステップ

1. 業務を検索・提案・承認・実行へ分解する
2. 最初は読み取り専用の1接続を選ぶ
3. 利用データ、Tool、権限、禁止操作を台帳化する
4. 正常・例外・攻撃ケースの評価データを作る
5. 限定利用者と検証環境で接続する
6. ログ、停止、失効、復旧を実際に試す
7. 品質・削減時間・事故リスクで本番可否を決める

営業・マーケティングでのMCP活用例

魚見の実務では、広告予算の変更や記事公開まで最初から自動化しません。データ収集、異常値の抽出、改善案の下書きを先に標準化し、人の承認結果を評価データへ戻します。自動実行よりも、成果検証のループを安定させる方が先です。

MCPを使わない方がよいケース

接続先が一つでAPI実装が十分安定している、利用するHostが一つだけ、標準化の維持費が便益を上回る場合は、直接APIが適する可能性があります。また、権限管理や監査ログが整っていない状態で、契約・送金・削除など高リスク操作を接続するのも避けます。

PoCで測るべきKPI

2026年仕様更新を追うときの注意点

MCPは発展中の規格で、仕様版により通信、認可、拡張、非推奨機能が変わります。ブログ記事や設定例をコピーする前に、対象HostとServerが対応する仕様版、SDK版、移行手順を確認します。新しい仕様が出ても、既存環境が即時対応するとは限りません。

台帳にはServer名だけでなく、仕様版、SDK、配布元、設定更新日、所有者を残します。アップデート後はTools一覧、権限、認証、評価データ、監査ログを再確認します。

MCP導入後の運用台帳テンプレート

MCPで「記事改善」を行う場合の具体的な設計例

Search Console、記事台帳、WordPressを接続する場合でも、最初から公開権限は与えません。第一段階は検索データと記事本文の読み取り、第二段階は改善候補と差分の作成、第三段階は担当者承認後の下書き保存です。公開は別権限とし、表示確認に合格した場合だけ実行します。

この分離により、悪意ある外部ページや誤った検索結果を読み込んでも、直ちにサイト全体を書き換える経路を作らずに済みます。さらに、対象ドメイン、投稿ID、更新可能な項目、1回の件数を通常のプログラム側で制限します。

MCPの導入効果を過大評価しないための確認

MCPは連携実装を再利用しやすくしますが、業務ルール、データ品質、モデル精度、承認負担を自動で解決するものではありません。導入前後で、接続開発時間、追加できた利用先、1件の処理時間、重大誤り、運用工数を測ります。

利用するAIアプリが増えても、同じServerを安全に再利用できなければ標準化の効果は出ません。反対に、接続台帳、権限、評価、監査を共通化できれば、個別API実装の重複を減らせます。技術の採用数ではなく、管理可能な接続を増やせたかで慎重かつ総合的に判断してください。