[MCP·Skill #1] MCPサーバーとは？接続方法からセキュリティ上の注意点まで

ChatGPTやClaudeを使っていると、物足りなさを感じる瞬間があります。モデルは賢いのに、自分のデータベースも社内Wikiも読めないからです。

そこで、APIを直接接続し始める人が増えました。しかしモデルやツールごとに連携方法が異なるため、組み合わせが増えるほど連携コードも幾何級数的に増えていきます。

MCP（Model Context Protocol）は、この問題を解決するために登場した標準です。一言でいえば、AIモデルに外部ツールやデータを接続する共通仕様です。よく「AI界のUSB-C」と呼ばれます。

この記事では、MCPが何を解決するのか、導入前後で連携作業がどう変わるのか、内部構造とfunction callingとの違い、そして今すぐ接続できる代表的なサーバーまで整理します。

まずは要点から見ていきましょう。

1. MCPはAIと外部ツールを接続するオープン標準プロトコルです（Anthropicが2024年11月に公開）。
2. 直接連携なら数百行かかる作業も、MCPサーバーがあれば数行の設定で完了します。
3. function callingを置き換えるのではなく、その上でツールを標準化し再利用する層です。
4. OpenAIやGoogleも採用し、事実上の業界標準となり、サーバーのエコシステムも急速に拡大しています。

---

MCPが解決する問題、M×N連携地獄

まずMCP以前の状況を見てみましょう。

AIアプリがM個、接続したいツールがN個あるなら、必要な連携コードはM×N個でした。Claude用、ChatGPT用、Cursor用のGitHub連携をすべて別々に作る必要があったのです。

MCPはその間に標準仕様を挟みます。ツール側はMCPサーバーを一度作り、AIアプリ側はMCPクライアントを一度実装すれば完了です。M×NがM+Nになります。

USB-C以前、機器ごとに異なる充電ケーブルを持ち歩いていた時代を思い出すと正確です。MCPはそのケーブル規格を統一したものです。

ただ、M+Nのような式だけでは違いを実感しにくいでしょう。同じ機能を2通りで作ってみると、差がはっきりします。

---

同じ機能を導入前後で比較

「GitHubのIssueを取得して答えるAI」を作るとしましょう。

MCP以前は、次の作業をすべて自分で行う必要がありました。

1. ツールスキーマの定義：「list_issuesはowner、repo、stateを受け取る」をJSONスキーマとして直接記述
2. 実際の呼び出しコードの作成：GitHub REST APIクライアント、トークン管理、ページネーション処理
3. 実行ループの実装：モデルがツールを呼び出したら結果を受け取り、再びモデルへ返す往復処理
4. これらをアプリごとに繰り返す：Claude連携用、社内チャットボット用を別々に作成

Issue取得だけでボイラープレートを含め数百行になり、ツールを追加するたびに1〜3回繰り返すことになります。

MCPがあれば、次のように終わります。

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"]
    }
  }
}

スキーマ定義、API呼び出し、認証、エラー処理はすべてサーバーに組み込まれています。サーバーを登録して、「このリポジトリの最近のバグIssueを要約して」と言うだけです。

項目	直接連携	MCPサーバーを使用
記述するコード	スキーマ・呼び出し・ループの数百行	設定5行
認証・エラー処理	手動で実装	サーバーに組み込み
別のAIアプリを追加	最初から作り直す	同じサーバーを再利用
ツールを追加	コードを修正・再デプロイ	サーバーを更新するだけ

特に重要なのは最後の行です。サーバーに機能が追加されても、自分側のコードは一行も変わりません。これが標準化の力です。

---

内部構造、ホスト・クライアント・サーバー

MCPには3つの登場人物がいます。

構成要素	役割	例
ホスト	ユーザーが使うAIアプリ	Claude Desktop, Cursor
クライアント	ホスト内でサーバーと1対1通信	ホストに組み込み
サーバー	ツールやデータを公開するプログラム	GitHubサーバー、DBサーバー

1つのホストが複数のクライアントを起動し、各クライアントが1つのサーバーに接続します。通信仕様はJSON-RPC 2.0で、ローカルプロセスにはstdio、リモート接続にはHTTPストリーミングを使います。

サーバーが公開する機能は3種類に分かれます。

• ツール（tools）：モデルが呼び出す関数。「Issueの作成」「クエリの実行」などの操作
• リソース（resources）：モデルが読むデータ。ファイル内容やDBスキーマなどの読み取り資料
• プロンプト（prompts）：サーバーがあらかじめ用意したプロンプトテンプレート

重要なのは、ツール一覧を実行時に問い合わせる点です。クライアントがサーバーに接続すると「何ができる？」と尋ね、サーバーがツール一覧とスキーマを返します。サーバーを更新しても自分のコードがそのままで済む理由です。

---

function callingとは何が違う？

ここまで読むと、こう疑問に思うでしょう。「それはfunction callingですでにできたのでは？」

層が異なります。function callingはモデルと対話するための規約です。「モデルよ、これらの関数があるので、必要なら呼び出し形式で答えてください」という約束です。関数をどう実装し、どこから取得するかは開発者の責任です。

MCPはそれらの関数を配布し、再利用するための規約です。ツールの実装・認証・ドキュメントをサーバーというパッケージにまとめ、どのAIアプリでも使えるようにします。

function callingが「関数呼び出しの構文」なら、MCPは「関数が入ったライブラリエコシステム」です。実際、MCPクライアントは内部でfunction callingをそのまま使います。代替関係ではなく、上下の層の関係です。

したがって「function callingとMCPのどちらを使う？」という問い自体が成立しません。1つのアプリだけで使う関数が数個ならfunction callingを直接実装すれば十分です。複数アプリで再利用したり、他人が作ったツールを使ったりするならMCPが適しています。

---

今すぐ接続してみたい代表的なサーバー

エコシステムは急速に拡大しており、一般的なツールの多くにはすでにサーバーがあります。反応のよい5つを選びました。

サーバー	できること
Playwright	AIがブラウザを直接操作。クリック・入力・スクリーンショット
Figma	デザイン案を読み取り、フロントエンドコードに変換
Notion	文書・議事録の検索と整理、ページ作成
GitHub	Issue・PRの取得と作成、コード検索
Supabase(Postgres)	自然言語でDBをクエリし、スキーマを把握

1つだけ選ぶならPlaywrightです。接続して、「このサイトを開いて会員登録フォームに入力し、スクリーンショットを撮って」と言ってみてください。AIがブラウザを開き、実際にクリックして入力するのを見れば、ツール接続がなぜゲームチェンジャーなのかを説明する必要はありません。E2Eテストの自動化や繰り返しのWeb作業にもすぐ使えます。

Figmaもフロントエンド開発者なら効果を実感できます。デザインを見ながら手作業でマークアップを移していた作業が、デザインを直接読めるAIに「このフレームをReactコンポーネントにして」と頼む作業に変わるからです。

---

注意点と限界

万能ではありません。実務で問題になりやすい点も確認しておきましょう。

まずセキュリティです。MCPサーバーはモデルに実行権限を与える経路なので、信頼できないサーバーを接続するとプロンプトインジェクションでデータが漏れる可能性があります。公式レジストリか検証済みのサーバーだけを使うのが安全です。

コンテキストコストもあります。接続するサーバーが増えるほどツール定義がコンテキストウィンドウを消費し、かえってモデル性能が低下する逆説が生じます。表の内容どおり、今必要なものだけを選んで接続するのが得策です。

---

まとめ

MCPは「モデルをより賢く」する技術ではなく、「モデルが手を伸ばせる範囲」を標準化する技術です。直接連携で数百行書いていた作業が設定数行になったこと、そして他人が作ったツールをそのまま接続して使えるエコシステムが生まれたこと。この2つが本質です。

次回は、MCPとよく比較されるClaude CodeのSkillとサブエージェントが、それぞれどのような役割を持つのか整理します。

あわせて読みたい

• なぜCLAUDE.mdは短くあるべきか？AIエージェントの常時ロードコンテキスト設計法
• MCP vs Skill vs サブエージェント、いつ何を使うべき？判断基準を総整理