MCPサーバーの作り方を4手順で解説｜接続・本番運用まで完全ガイド
- MCPサーバーはツール・リソース・プロンプトの3要素で構成され、AIに「できること」を増やす仕組み。
- 最初の1台は無料で作れる。必要なのはNode.jsかPython、もしくは.NET環境だけ。
- 作成手順は「インスタンス生成→ツール定義→リソース公開→実行確認」の4ステップ。
- 標準入出力型サーバーでは標準出力にログを書くと通信が壊れるため、ログは標準エラー出力へ。
- 本番運用ではDocker化・APIキー管理・ロギング設計が事故防止の要になる。
MCPサーバーとは何か：仕組みと作る前の基礎知識
MCP（Model Context Protocol）とは、AIモデルに外部のツールやデータを安全につなぐための共通規格です。
AnthropicがオープンソースとしてMCPを公開したのが2024年11月。私が触り始めたのもこの頃で、正直、最初は「また新しいプロトコルか」と思いました。でも触ると分かる。これは関数呼び出しの規格を標準化した、地味だけど効くやつです。
MCPの3つの主要概念（ツール・リソース・プロンプト）
MCPサーバーが提供できるのは、ツール・リソース・プロンプトの3種類です。
| 要素 | 役割 | 主導権 | 例 | ||||
|---|---|---|---|---|---|---|---|
| ツール（Tools） | AIが実行する処理・機能 | AIモデル | 天気を取得する、計算する | リソース（Resources） | AIが読み込むデータ | アプリ側 | ファイルの中身、DBのレコード |
| プロンプト（Prompts） | 定型の指示テンプレート | ユーザー | 「このコードをレビューして」 |
最初に作るなら、迷わずツールから入るのがいい。一番分かりやすく、効果を実感しやすいからです。
なぜREST APIではなくMCPを使うのか
REST APIとの最大の違いは、MCPがAIモデルにとって「自己説明的」である点です。
REST APIは人間が仕様書を読んで叩くもの。一方MCPは、サーバーが「自分はこういうツールを持っている」とAIに自己申告します。AIはその情報を見て、自分でどのツールを使うか判断する。仕様書を渡さなくても勝手に使ってくれる、ここが決定的に違います。
だからAIエージェントに新機能を足すなら、MCPで包むのが圧倒的に楽です。
通信方式（標準入出力とHTTP/SSE）とJSON-RPC 2.0
MCPの通信は、データ形式にJSON-RPC 2.0を使い、トランスポートは大きく2種類に分かれます。
| 方式 | 用途 | 特徴 | |||
|---|---|---|---|---|---|
| 標準入出力（stdio） | ローカルで動かす | 設定が簡単。Claude Desktopが直接起動する | HTTP/SSE | リモートで動かす | 複数クライアントから接続可能。サーバーとして常駐 |
最初のうちはstdioで十分。リモート公開したくなったらHTTP/SSEへ、という順番でいい。
標準入出力サーバーで標準出力を使ってはいけない理由
標準入出力型のMCPサーバーでは、標準出力（println、console.log、printなど）にログを書いてはいけません。
これ、初心者が9割ハマります。私も最初、デバッグのつもりでconsole.logを仕込んで接続不能になり、30分溶かしました。
作り始める前の準備：所要時間・難易度・必要な道具
最初のMCPサーバーは、環境が整っていれば30分〜1時間で動かせます。
| 項目 | 目安 | ||||||
|---|---|---|---|---|---|---|---|
| 難易度 | ★★☆☆☆（プログラミング初級者向け） | 所要時間（初回） | 30分〜1時間 | 費用 | 0円（ローカル実行・無料SDKのみ） | 必要なもの | Node.js または Python、もしくは.NET SDK |
前提条件と開発環境の確認
まず使う言語のランタイムが入っているかを確認します。
TypeScriptならNode.js 18以上、Pythonなら3.10以上、C#なら.NET 8以上が目安です。ターミナルで「node --version」「python --version」「dotnet --version」を叩いて、バージョンが返ってくればOK。
ここまでできていれば、開発環境の準備は完了です。
空のプロジェクト作成とパッケージ導入
次に空のプロジェクトを作り、MCP用のSDKを入れます。
C#なら「dotnet new console」で空のコンソールプロジェクトを作成し、「dotnet add package ModelContextProtocol」のようにMCPのSDKパッケージを追加します。TypeScriptなら「npm init -y」のあと「npm install @modelcontextprotocol/sdk」です。
パッケージがエラーなく入れば、ここまで正しく進んでいます。
クイックスタート（雛形の生成）
ゼロから書かず、公式の雛形を使うのが一番速い道です。
TypeScriptなら「npx @modelcontextprotocol/create-server」で対話的にプロジェクトの骨組みが生成されます。中にサンプルのツール定義が入っているので、これを書き換えるのが実質の近道です。
手順で作る：シンプルな自作MCPサーバーの構築
ここでは「2つの数を足し算するツール」を持つ最小のサーバーを、4手順で完成させます。
言語はTypeScriptで進めます。計算ツールは外部APIがいらず、動作確認が一目で分かるからです。
手順1：サーバーインスタンスを生成する
最初にサーバー本体のインスタンスを作ります。
SDKのMcpServerクラスに、サーバー名とバージョンを渡して生成します。「new McpServer({ name: "calc-server", version: "1.0.0" })」のような1行です。これが全機能を載せる土台になります。
エディタでエラーが出なければ、土台は完成です。
手順2：ツール（機能）を定義する
作ったインスタンスに、足し算ツールを1つ登録します。
ツールには「名前」「説明文」「入力スキーマ」「実行する処理」を渡します。説明文はAIがツールを選ぶ判断材料になるので、「2つの数値を足し算して返す」のように具体的に書く。ここを雑にすると、AIがツールを呼んでくれません。
入力にaとbという数値を受け取り、a+bの結果を返す関数を中身に書けば、手順2は完了です。
手順3：リソース（データ）を公開する
必要なら、AIに読ませたいデータをリソースとして公開します。
たとえば「計算の使い方ガイド」というテキストをリソースに登録すると、AIがそれを参照できます。ツールだけのサーバーならこの手順は省いてもかまいません。最初は飛ばしてOKです。
私は最初の1台ではリソースを入れませんでした。まずツールだけ動かして、感覚をつかむのを勧めます。
手順4：サーバーを実行して動作を確認する
最後にトランスポートをstdioに接続し、サーバーを起動します。
「server.connect(new StdioServerTransport())」で標準入出力につなぎ、ビルドして実行します。エラーなく起動し、プロセスが待ち受け状態になれば成功です。
テストとClaude Desktopとの接続
完成したサーバーは、MCPインスペクターで単体テストし、Claude Desktopの設定ファイルに登録して接続します。
MCPインスペクターでデバッグする
クライアントにつなぐ前に、MCPインスペクターで単体動作を確認するのが鉄則です。
「npx @modelcontextprotocol/inspector node build/index.js」のように起動すると、ブラウザでツール一覧が表示され、手動でツールを叩けます。足し算ツールに2と3を入れて5が返れば、サーバーは正常。ここで通っていれば、接続トラブルはほぼ設定ファイル側の問題に絞れます。
設定ファイルの記述と保存場所（OS別）
Claude DesktopにはJSON形式の設定ファイルでサーバーを登録します。
| OS | パス | ||
|---|---|---|---|
| macOS | ~/Library/Application Support/Claude/claude_desktop_config.json | Windows | %APPDATA%\Claude\claude_desktop_config.json |
ファイルが無ければ、同じ名前で新規作成します。中身は「mcpServers」の下に、起動コマンドと引数を書くだけです。パスは必ず絶対パスで書く。相対パスにすると、まず動きません。
Claude Desktopから自作サーバーを呼び出す
再起動後、入力欄付近にツールのアイコンが出れば接続成功です。
チャットで「3と4を足して」と頼むと、Claudeが足し算ツールを使うか確認を出し、実行して7と返します。AIが自分でツールを選んで叩く、あの瞬間が一番気持ちいい。ここまで来たら、自作MCPサーバーの完成です。
接続できないときのトラブルシューティング
接続できないときは、原因の8割が「設定ファイル」か「標準出力へのログ混入」です。
| 症状 | 原因 | 対処 | ||||||
|---|---|---|---|---|---|---|---|---|
| ツールが表示されない | 設定ファイルのパス間違い | 絶対パスに直して再起動 | 起動直後に切断される | 標準出力にログを書いている | ログをstderrに変更 | JSONエラーが出る | 設定ファイルの記法ミス | カンマやカッコをチェック |
インスペクターで動いてClaude Desktopで動かないなら、犯人は設定ファイルです。サーバーのコードは疑わなくていい。
Python・TypeScript版の作り方と他クライアント対応
MCPサーバーはPython・TypeScript・C#などで作れ、Claude Desktop以外にCursorやClineからも使えます。
言語ごとの実装の違いと選び方
考え方はどの言語も同じで、違うのは書き方の作法だけです。
| 言語 | SDK | 向いている人 | ||||||
|---|---|---|---|---|---|---|---|---|
| Python | mcp（公式SDK） | データ処理・AI連携を多用する人 | TypeScript | @modelcontextprotocol/sdk | Web開発者・Node環境の人 | C# | ModelContextProtocol | 業務システム・.NET資産がある人 |
正直、迷うなら好きな言語でいい。私はWeb寄りなのでTypeScriptを使いますが、Pythonのデコレータでツールを定義する書き方も直感的で好きです。
Cursor・Cline・VS Code拡張での利用
作ったサーバーは、CursorやClineなど他のMCP対応クライアントでもそのまま使えます。
Cursorなら設定画面のMCP項目に、Claude Desktopと同じ形式でサーバーを登録します。設定ファイルの場所と書式が違うだけで、サーバー本体は1行も変えなくていい。これがプロトコルを標準化した恩恵です。
リモートMCPサーバー（HTTP/SSE）の構築手順
チームで共有したり常時稼働させたいなら、stdioではなくHTTP/SSEトランスポートに切り替えます。
やることは、トランスポートをStdioからHTTP/SSE用のものに差し替え、Webサーバーとしてポートを開くだけです。ツール定義はそのまま流用できます。ただしネット越しに公開する瞬間、認証が必須になる。ここから先は次章の本番設計の話です。
本番運用のための設計：デプロイ・認証・監視
本番運用では、Docker化での永続稼働・APIキーやトークンによる認証・ロギングの3点が事故を防ぐ柱になります。
ここは競合記事が薄い領域なので、私の実運用の判断を込めて書きます。
クラウドやDockerでの永続稼働とデプロイ
リモートMCPサーバーは、Dockerでコンテナ化してクラウドに置くのが定番です。
Dockerfileでランタイムとコードを固め、Cloud RunやFly.io、ECSなどに載せます。プロセスが落ちても自動再起動する構成にしておくこと。MCPサーバーは常駐前提なので、落ちたまま気づかないのが一番こわい。ヘルスチェックは必ず入れます。
認証・認可（APIキー管理・トークン処理）の実装
リモート公開するなら、認証なしで出すのは絶対にやめてください。
