MCP サーバー作り方｜Python/TypeScript SDK で自作し本番運用まで（現役エンジニアの実装マニュアル）

Q: C# や Java でも MCP サーバーは作れますか？

公式ドキュメントで確認した範囲では、C# や Java（Kotlin）向けの SDK も提供されています。基本構造（tools / resources / prompts、stdio / HTTP）は共通です。

Q: Windows でも MCP サーバーは作れますか？

作れます。Python や Node.js が動けば OS は問わない設計です。ただし設定 JSON のパス区切り（バックスラッシュのエスケープ）や環境変数の読み込みで OS 差が出ます。Windows では絶対パス指定と環境変数の確実な反映に注意してください。

MCP サーバーを自分で作りたいけれど、Python と TypeScript のどちらで書くのか、最小サンプルはどう動かすのか、社内のデータや API を AI につないで本番で使って大丈夫なのか——調べるほど情報が散らばって、最初の一歩が踏み出せていないのではないでしょうか。「MCP サーバー作り方」はラッコキーワード実測（2026 年 6 月時点）で月 1,000 人前後が検索しており、私自身も社内 API や自社 DB を自作の MCP サーバーにして本番運用に投入してきました。

結論から言うと、MCP サーバーは公式の道具箱（SDK）を使えば、最小構成なら数十行から動かせます。本記事では、Python / TypeScript SDK の最小サンプルから、Cursor / Claude Code への接続、社内 API・自社 DB の MCP 化、クラウドへのデプロイ、本番運用のセキュリティ 3 原則までを、業務で自作 MCP を動かす現役エンジニアの目線で整理します。

とりあえず最短で 1 回動かしたい方はセクション 4（Python SDK の最小サンプル）から、Cursor / Claude Code につなぐ設定だけ知りたい方はセクション 6、社内の API や DB を MCP 化したい方はセクション 7、セキュリティが気になる方はセクション 9 から読み進めていただくのがおすすめです。MCP そのものの意味や「使う側」の話をまだ押さえていない方は、親記事の AIエージェント MCP と並走で読むと、全体像が一気に立ち上がります。

この記事は、営業職を経て未経験から SE へ転職し、現在は社内 API・自社 DB を自作の MCP サーバーにして本番運用している現役の生成AIエンジニア aikun が、自身の業務体験から書いています。

01 — 結論：MCP サーバーは公式 SDK で数十行から作れる

📖 この章で使う用語

MCP（Model Context Protocol、モデル・コンテキスト・プロトコル）：AI に外部のもの（ファイル・データベース・API）を渡すための、共通のルール（仕様）。営業時代の「どの取引先でも通用する共通の名刺フォーマット」のイメージ。

MCP サーバー：外部のものを MCP のルールにのっとって AI に公開する側のプログラム。今回あなたが「作る」のはこちら側です。

SDK（Software Development Kit）：何かを作るための公式の道具箱。MCP サーバーを書くための公式 SDK が Python / TypeScript などで配られています。

tools / resources / prompts：MCP サーバーが AI に公開できる 3 種類。「実行できる操作 / 読み取り対象のデータ / 使い回せる定型文」という役割分担です。

MCP サーバーの自作は、大きな流れで見ると 6 ステップに分かれます。先に全体地図を 1 枚で持っておくと、途中で迷子になりません。

SDK を選ぶ（Python か TypeScript が二大主軸）
tools / resources / prompts を定義する（まずは tools 1 個でOK）
通信方式を決めて起動する（手元なら stdio、リモート公開なら HTTP）
クライアントからつなぐ（Cursor / Claude Code / VS Code に登録）
接続先を広げる（社内 API・自社 DB を MCP 化する）
本番運用に耐える形に整える（権限分離・Secrets 管理・監査ログの 3 原則）

読者の状況によって、読む順番を変えても大丈夫です。「とにかく最短で 1 回動かしたい」方はステップ 3 まで、「社内のデータを AI につなぎたい」方はステップ 5、「本番で使うのが前提でセキュリティが心配」な方はステップ 6 を中心に読んでみてください。

この記事の温度感を、最初に正直にお伝えしておきます。Python SDK での自作、社内 API・自社 DB の MCP 化、本番運用での失敗やセキュリティ運用は、私が業務で実際に手を動かしてきたことなので、自分の言葉で書きます。一方、C# / Java の SDK や、私の常用クラウドではない Azure のデプロイ細部などは、公式ドキュメントで確認した範囲の概論として、出典をつけて書きます。「実際にやったこと」と「調べて整理したこと」を、読みながら区別できるようにしておきます。

なお、MCP そのものの意味や「使う側（Cursor から MCP を呼ぶなど）」の話は、別記事の AIエージェント MCP に集約しています。本記事は「自分で MCP サーバーを作る」ことだけに集中します。

02 — MCP サーバーとは何か（作る側の視点で 30 秒）

📖 この章で使う用語

MCP クライアント：MCP サーバーに接続して、情報や操作を取りに行く側。Cursor / Claude Code / VS Code / Claude Desktop などがこれにあたります。

オープン仕様：特定の会社に閉じず、誰でも実装してよい公開ルール。USB や HTTP のような立ち位置です。

LLM（大規模言語モデル）：Claude や ChatGPT、Gemini の正体にあたる「文章を予測する装置」。MCP サーバーは、この LLM に「使える道具」を渡す役割を担います。

作る側に必要な最小限だけ、ここで整理します。MCP サーバーとは、「自分が持っている外部のもの（API・データベース・ファイル）を、AI が使える形で公開するプログラム」です。レストランでたとえると、AI が「お客さん」、MCP サーバーが「厨房とお客さんをつなぐホール係」のイメージです。お客さんは厨房（社内システム）に直接入れませんが、ホール係（MCP サーバー）を通せば、決められたメニュー（tools）の中から注文できます。

公開できるものは 3 種類です。tools は「実行できる操作」（例：DB を検索する、API を叩く）、resources は「読み取り対象のデータ」（例：ファイルの中身、API のレスポンス）、prompts は「使い回せる定型文」（例：レビュー依頼のテンプレ）です。自作のときは、私の場合は tools が主役になることがほとんどです。「AI に何かをやってもらう」用途が多いからですね。

MCP は、Anthropic が 2024 年 11 月 25 日に公開したオープン仕様です。

MCP は、AI アシスタントを、データが存在するシステムへ接続するための新しい標準です。出典: Introducing the Model Context Protocol｜Anthropic（取得：2026-06-02）

特定の会社に閉じていないので、Claude でも Cursor でも、対応するクライアントから同じ MCP サーバーを使えます。「一度作れば、いろいろなクライアントから使い回せる」のが、作る側にとっての大きな手応えです。私自身、社内向けに 1 本作った MCP サーバーを、Cursor からも Claude Code からも呼べるようにしておくと、チームへの展開がぐっとラクになりました。

MCP の概念そのものや、「使う側（既存の MCP サーバーを Cursor につないで使う）」をまだ押さえていない方は、先に AIエージェント MCP を読んでおくと、この先がスムーズです。

03 — 作る前の準備：どの言語の SDK で書くか

📖 この章で使う用語

公式 SDK：仕様を作った主体（や公式コミュニティ）が配っている正式な道具箱。コミュニティ製より、仕様の変更に追従するのが早い傾向があります。

型安全：プログラムの「型のミス」（数値を入れるべき所に文字を入れた等）を、動かす前に見つけられる性質。TypeScript の強みです。

最初の分かれ道が「どの言語で書くか」です。「mcp サーバー作り方」と一緒に検索される言葉を見ると、python / typescript / c# / java と、言語名がずらりと並びます。それだけ「どの言語で書くか」が、みんなの最大の関心ということです。

1. Python SDK と TypeScript SDK が二大主軸

MCP には複数の言語で公式 SDK が用意されていますが、情報量・サンプルの豊富さで見ると、Python と TypeScript の 2 つが二大主軸です。私自身は、業務で使う言語スタック（Ruby / Python / Scala など）に近い Python SDK を軸にしています。とくに AI まわりは Python の周辺ツール群が厚いので、自作 MCP サーバーも Python から入ると、つまずきが少なかったです。

2. C# SDK / Java（Kotlin）SDK も公式に存在する

「うちは C# / Java の現場だけど、MCP サーバーは書けるの？」という疑問もよくあります。公式ドキュメントで確認した範囲では、C# や Java（Kotlin）向けの SDK も用意されています。

MCP は複数言語の SDK を提供しており、TypeScript・Python・C#・Java・Kotlin・Go・Ruby・Rust・Swift・PHP 向けのものが公開されています。出典: SDKs｜Model Context Protocol（取得：2026-06-02）

基本の構造（tools / resources / prompts を定義して、通信方式で起動する）はどの言語でも共通です。ただし、C# / Java は私の常用言語ではないので、本記事の手を動かす部分は Python / TypeScript に寄せます。C# / Java で書く場合も、考え方はそのまま流用できるはずです。

3. 言語選択の判断軸

「絶対にこれ」という正解はありません。私が判断するときに見ているのは、次の 3 点くらいです。

既存の業務スタックに近いか：チームが普段書いている言語に寄せると、メンテする人が増えます。
型安全 vs 実験の速さ：堅く作りたいなら TypeScript の型安全が効きます。とにかく速く試したいなら Python が軽快です。
AI 連携まわりの周辺ツールの厚み：エージェントや RAG とつなぐ前提なら、Python のほうが周辺の道具がそろっている印象です。

迷ったら、「自分（やチーム）が一番ストレスなく書ける言語」を選ぶのが、結局いちばん続きます。私の場合は、それが Python でした。

04 — Python SDK で最小の MCP サーバーを作る（5 分・コード）

📖 この章で使う用語

FastMCP：Python の MCP SDK が用意している、書きやすい高レベルの書き方。@mcp.tool() という目印（デコレータ）を関数につけるだけで、その関数を tool として公開できます。

stdio（標準入出力）：プログラム同士が「標準の入り口・出口」で文字をやり取りする通信方式。手元で動かすときの基本です。

venv / uv：Python のパッケージを「プロジェクトごとに隔離」する仕組み（venv）と、その高速版のツール（uv）。プロジェクトをきれいに保つための道具です。

MCP Inspector：作った MCP サーバーの動作を画面で確認できる、公式のデバッグツール。

まずは、いちばん小さい MCP サーバーを Python で動かしてみましょう。やることは「tool を 1 個だけ定義して、手元で起動する」だけです。

1. 環境を準備する

公式ドキュメントでは、パッケージ管理に uv を使う流れが案内されています。uv がなければ pip でも問題ありません。

# uv を使う場合（公式ドキュメント推奨の流れ）
uv init mcp-hello
cd mcp-hello
uv add "mcp[cli]"

# pip を使う場合
python -m venv .venv
source .venv/bin/activate   # Windows は .venv\Scripts\activate
pip install "mcp[cli]"

インストール方法の出典は次のとおりです。

出典: MCP Python SDK（README）｜GitHub（取得：2026-06-02）

2. 最小のサーバーを書く

server.py というファイルを作り、tool を 1 個だけ公開してみます。ここでは「2 つの数を足す」という、いちばん単純な tool です。

# server.py — 最小の MCP サーバー
from mcp.server.fastmcp import FastMCP

# サーバーに名前をつける（クライアント側に表示される）
mcp = FastMCP("hello-server")

# @mcp.tool() をつけた関数が、AI から呼べる「道具」になる
@mcp.tool()
def add(a: int, b: int) -> int:
    """2つの数を足して返す"""
    return a + b

if __name__ == "__main__":
    # stdio（標準入出力）で起動する。手元のクライアントから繋ぐときの基本
    mcp.run(transport="stdio")

ポイントは、@mcp.tool() という目印を関数につけるだけで、その関数が AI から呼べる「道具」になることです。関数のすぐ下に書いた説明文（"""2つの数を足して返す"""）は、AI が「この道具は何をするものか」を理解する手がかりになります。ここを丁寧に書くほど、AI が適切な場面で道具を選んでくれます。営業時代に「商品の説明は、相手が一読して用途を想像できる一文に削る」と教わったのを、私はここでも思い出します。

3. ローカルで動作を確認する

書いたサーバーが正しく動くかは、公式の MCP Inspector で画面から確認できます。

# MCP Inspector でサーバーを起動して、ブラウザから tool を叩いてみる
uv run mcp dev server.py

ブラウザが立ち上がり、add という tool が見えていれば成功です。引数に数値を入れて実行し、足し算の結果が返ってくれば、最小の MCP サーバーは完成です。

4. つまずきやすい初手

私や周囲がよく踏むつまずきを、先回りで挙げておきます。

import エラー：mcp が見つからないと言われたら、uv や venv の有効化を忘れているケースが多いです。pip install を実行した環境と、サーバーを動かす環境がずれていないか確認してみてください。
stdio を print で汚す：stdio で通信しているとき、print() でうっかり標準出力に文字を出すと、通信が壊れます。ログを出したいときは標準エラー出力（sys.stderr）か、ロギングの仕組みを使ってください。これはセクション 11 でも改めて触れます。
Python のバージョン：古い Python だと動かないことがあります。エラーが出たら、まず Python のバージョンを疑うと早いです。

05 — TypeScript SDK で作る＋ tools / resources / prompts の使い分け

📖 この章で使う用語

zod：TypeScript で「入力の型・必須項目」を検証するライブラリ。tool の引数の決まりを書くのに使います。

StdioServerTransport：TypeScript SDK で stdio 通信を担当するクラス。「stdio で話す係」だと思ってください。

Streamable HTTP：MCP のリモート通信方式。手元ではなく、ネットワーク越しにサーバーを公開するときに使います。

TypeScript で書きたい方向けに、同じ「足し算 tool」を TypeScript SDK で書いてみます。型安全が効くので、引数の決まりをきっちり書きたいチームに向いています。

1. 環境を準備する

mkdir mcp-hello-ts && cd mcp-hello-ts
npm init -y
npm install @modelcontextprotocol/sdk zod
npm install -D typescript @types/node

パッケージ名や最小サンプルの出典は次のとおりです。

出典: MCP TypeScript SDK（README）｜GitHub（取得：2026-06-02）

2. 最小のサーバーを書く

// server.ts — 最小の MCP サーバー（TypeScript）
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

// サーバーに名前とバージョンをつける
const server = new McpServer({ name: "hello-server", version: "1.0.0" });

// tool を登録する。zod で引数の決まりを書く
server.registerTool(
  "add",
  {
    description: "2つの数を足して返す",
    inputSchema: { a: z.number(), b: z.number() },
  },
  async ({ a, b }) => ({
    content: [{ type: "text", text: String(a + b) }],
  })
);

// stdio で起動する
const transport = new StdioServerTransport();
await server.connect(transport);

Python 版と見比べると、構造はそっくりです。「サーバーに名前をつける → tool を登録する → 通信方式で起動する」という流れは、言語が変わっても変わりません。だから一度どちらかで作れば、もう片方への乗り換えはそこまで大変ではありません。

3. tools / resources / prompts の使い分け

ここで、3 種類の公開対象の使い分けを整理しておきます。

tools（道具）：AI に「何かをやってもらう」操作。DB を検索する、API を叩く、ファイルを書き換える、など。
resources（読み取り対象）：AI に「読んでもらう」データ。ファイルの中身、設定値、API のレスポンスなど。
prompts（定型文）：「この作業はこの聞き方で」という、使い回せるテンプレ。

私の自作では、tools が主役になることがほとんどです。「AI に業務操作を任せる」用途が中心だからですね。resources は「読み取りの入り口」として補助的に、prompts は「チームで聞き方をそろえたいとき」に使う、という温度感です。最初は tools 1 本に絞って作り、必要になったら resources / prompts を足す、で十分だと思います。

4. stdio と Streamable HTTP の選び方

通信方式は、用途で選びます。

stdio：手元の PC で、クライアント（Cursor / Claude Code など）と同じマシンで動かすときの基本。設定がシンプルです。
Streamable HTTP：ネットワーク越しに公開して、複数の人・複数のマシンから使ってもらうときに使います。リモート公開の話はセクション 8 で扱います。

2025 年 3 月の仕様更新で、従来の HTTP+SSE トランスポートに代わって Streamable HTTP トランスポートが導入されました。出典: Transports｜Model Context Protocol（取得：2026-06-02）

最初は迷わず stdio で大丈夫です。「手元で動いた」を先に作ってから、公開が必要になった段階で HTTP に切り替える、という順番が、結果的にラクでした。

06 — Cursor・Claude Code・VS Code から自作サーバーにつなぐ

📖 この章で使う用語

.cursor/mcp.json：Cursor で MCP サーバーを登録する設定ファイル（JSON 形式）。プロジェクトの中に置きます。

claude mcp コマンド：Claude Code で MCP サーバーを追加・確認するためのコマンド。

環境変数：API キーや接続先などの情報を、設定ファイルに直接書かず、外（シェルやOS）から渡す方式。秘密情報の漏洩を防ぐ基本の作法です。

作ったサーバーは、クライアントに登録して初めて使えます。私は Cursor と Claude Code を業務で常用しているので、まずこの 2 つの設定を、自分の使い方ベースで書きます。VS Code は触れる範囲で、公開情報からの整理として添えます。

1. Cursor につなぐ

Cursor では、プロジェクト内の .cursor/mcp.json に自作サーバーを登録します。API キーなどの秘密情報は、JSON に直書きせず、環境変数を参照させるのがポイントです。

// .cursor/mcp.json
{
  "mcpServers": {
    "hello-server": {
      "command": "uv",
      "args": ["run", "python", "server.py"],
      "env": {
        "MY_API_KEY": "${MY_API_KEY}"
      }
    }
  }
}

env のところで ${MY_API_KEY} のように書いておくと、シェルに設定した環境変数の値が読み込まれます。秘密情報を JSON に直書きしないこの作法は、後のセクション 9（セキュリティ）でも繰り返し出てきます。最初の 1 本目から、この形にしておくのがおすすめです。

2. Claude Code につなぐ

Claude Code では、コマンドで MCP サーバーを追加できます。

# 自作サーバーを Claude Code に登録する
claude mcp add hello-server -- uv run python server.py

# 登録済みの MCP サーバーを確認する
claude mcp list

登録すると、.mcp.json という設定ファイルにも反映されます。プロジェクト単位で管理できるので、チームで共有するときも扱いやすいです。Claude Code 本体の使い方は Claude Code 使い方に、Cursor 本体の使い方は Cursor 使い方にまとめてあります。

3. VS Code につなぐ

VS Code でも、GitHub Copilot の拡張や MCP 対応の拡張から MCP サーバーを利用できます。

VS Code は、GitHub Copilot Chat のエージェントモードで MCP サーバーをサポートしています。出典: Use MCP servers in VS Code｜Visual Studio Code Docs（取得：2026-06-02）

私は普段 Cursor / Claude Code を主に使っているので、VS Code の細かい設定は、公式ドキュメントで確認した範囲の整理として添えるにとどめます。基本の考え方（コマンドと環境変数でサーバーを登録する）は共通です。

4. Windows 環境の注意

社内に Windows 端末向けに展開したときの実感として、Windows ではいくつか注意点があります。

パスの区切り：JSON の中でパスを書くとき、\ は \\ とエスケープが必要です（例：C:\\Users\\...）。
絶対パスが安定：相対パスより、絶対パスで書いたほうが「動く人と動かない人が分かれる」事故が減りました。
環境変数の反映：環境変数を設定したのに読まれないときは、設定後にターミナルやエディタを再起動すると反映されることが多いです。

このあたりは OS の差なので、Mac / Linux で書いたサーバーをそのまま Windows に持っていくときは、設定ファイルのパスまわりを一度見直すと安心です。

07 — 社内 API・自社 DB を MCP 化する実装パターン

📖 この章で使う用語

ステージング環境：本番そっくりの「練習用」環境。本番に影響を出さずに試せる場所です。

読み取り専用ユーザー：データベースを「見るだけ（書き込み不可）」に制限したアカウント。事故を防ぐための基本装置です。

DML（INSERT / UPDATE / DELETE）：データベースのデータを書き換える操作。誤って実行すると事故につながります。

ここからが、自作 MCP サーバーの本領です。「既製の MCP サーバーにはない、自分たちの社内 API や自社 DB を AI から使える形にする」ところに、自作の最大の価値があります。私自身、社内向けの API や自社の DB を MCP 化して、業務の本番運用に投入してきました。具体的なシステム名や業界は伏せますが、「型」としてのパターンはお伝えできます。

1. 作る前に「既存のサーバーで足りないか」を確認する

自作に入る前に、一度立ち止まってください。やりたいことが、すでに公開されている MCP サーバーで足りるなら、自作しないほうが結局ラクです。

Anthropic は MCP サーバーのリファレンス実装を集めた、オープンソースのリポジトリを公開しています。出典: Example Servers｜Model Context Protocol（取得：2026-06-02）

ファイル操作や一般的な SaaS との連携なら、既製のサーバーで足りることも多いです。「社内独自の API」「自社の DB」のように、世の中に出ていないものだけを自作する、という線引きが現実的でした。

2. 社内独自の API を MCP 化するパターン

社内認証が必要だったり、社内ネットワークからしか叩けない API は、既製のサーバーではカバーされません。ここを tool 化します。

# 社内 API を 1 つの tool にまとめる例（抽象化したサンプル）
import os
import httpx
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("internal-api-server")

# 接続情報は環境変数から。コードにもJSONにも直書きしない
BASE_URL = os.environ["INTERNAL_API_BASE_URL"]
API_KEY = os.environ["INTERNAL_API_KEY"]

@mcp.tool()
def search_orders(keyword: str, limit: int = 20) -> list[dict]:
    """社内の受注情報をキーワードで検索する（読み取りのみ）"""
    resp = httpx.get(
        f"{BASE_URL}/orders/search",
        params={"q": keyword, "limit": limit},
        headers={"Authorization": f"Bearer {API_KEY}"},
        timeout=10.0,
    )
    resp.raise_for_status()
    return resp.json()["items"]

if __name__ == "__main__":
    mcp.run(transport="stdio")

コツは、「業務的に意味のある単位」で tool を切ることです。API のエンドポイントをそのまま 1 対 1 で並べるのではなく、「受注を検索する」「在庫を確認する」のように、AI（と人間）が一読して用途が分かる粒度にまとめます。営業時代に「お客様に渡す資料は、機能の羅列ではなく、相手の業務シーンで並べ替える」と意識していたのに近い感覚です。

3. 自社 DB を MCP 化するパターン

DB の MCP 化は、便利さと危うさが背中合わせです。私が最初から守っているルールを、先に書きます。

本番 DB には絶対に向けない：まずはステージング環境、または本番でも読み取り専用ユーザーを使います。
書き込み系は人間の最終確認を挟む：DML（INSERT / UPDATE / DELETE）を tool 化するのは、最初はおすすめしません。やるとしても、AI が直接実行するのではなく「人間が確認してから実行」の段を必ず入れます。

# 自社 DB を読み取り専用で MCP 化する例（抽象化したサンプル）
import os
import psycopg
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("internal-db-server")

# 読み取り専用ユーザーの接続情報を環境変数から渡す
DSN = os.environ["READONLY_DB_DSN"]

@mcp.tool()
def find_customer(name: str) -> list[dict]:
    """顧客名で顧客レコードを検索する（SELECT のみ）"""
    # 文字列連結ではなくパラメータ化クエリで渡す（SQLインジェクション対策）
    with psycopg.connect(DSN) as conn:
        rows = conn.execute(
            "SELECT id, name, plan FROM customers WHERE name ILIKE %s LIMIT 50",
            (f"%{name}%",),
        ).fetchall()
    return [{"id": r[0], "name": r[1], "plan": r[2]} for r in rows]

if __name__ == "__main__":
    mcp.run(transport="stdio")

ここで地味に大事なのが、SQL を文字列でつなげずパラメータ化クエリで渡すことです。AI が組み立てた検索語をそのまま SQL に流し込むと、SQL インジェクションの入り口になります。「AI が入力を作る」という前提が増えるぶん、従来以上に入力の扱いを丁寧にしておきたいところです。

社内ドキュメントや DB を AI から検索的に使う構成は、RAG とはで扱った RAG の考え方とも地続きです。「DB を MCP 化して AI に渡す」のは、RAG の入り口を MCP で作っている、と捉えても良いと思います。

4. どれで公開するか（tools / resources / prompts）

業務での私の整理は、シンプルです。操作は tools、読み取りの入り口は resources、チームで聞き方をそろえたいときは prompts。最初は tools だけで十分機能します。あとから「これは読み取り専用の参照だな」と思うものを resources に切り出す、くらいの順番で問題ありませんでした。

なお、MCP（接続層）と似て非なる仕組みに Claude Skills があります。「Claude にまとまった手順やファイルをパッケージで渡す」用途なら、MCP より Claude Skills 自作のほうが向くことがあります。「外部リソースにつなぐなら MCP、手順とファイルをまとめて渡すなら Skills」という使い分けを覚えておくと、設計で迷いません。

08 — クラウド（AWS / Azure）へのデプロイと運用

📖 この章で使う用語

コンテナ：アプリと、その動作に必要な環境を 1 つの箱に固めて、どこでも同じように動かす仕組み（Docker など）。

IAM（Identity and Access Management）：クラウド上で「誰が何をできるか」を管理する仕組み。

VPC（Virtual Private Cloud）：クラウドの中に区切った「自分専用のネットワーク」。

手元の stdio で動くサーバーを、チームや複数マシンから使ってもらうには、ネットワーク越しに公開する必要が出てきます。ここはクラウドの話になります。

1. stdio から HTTP へ移行が必要になる場面

stdio は「同じマシンの中」での通信です。次のような場面では、Streamable HTTP に切り替えてリモート公開を検討します。

自分の PC 以外（チームメンバー、CI、別サーバー）から使ってもらいたい
常時起動させて、複数人が同時に使う前提にしたい

逆に言えば、個人で手元のツールとして使うだけなら、無理に HTTP 化しなくて大丈夫です。

2. AWS へのデプロイ選択肢

私は業務で AWS を触っており、EC2 / Lambda / ECR あたりは自分の手で動かしてきた範囲です。MCP サーバーを AWS に載せるなら、選択肢はおおむね次の 3 つに整理できます。

コンテナ（ECS / Fargate）：常時起動の HTTP サーバーとして動かす標準的な形。Docker でコンテナにして、ECR（コンテナの保管場所）に置いてから動かします。
Lambda：リクエストごとに起動する軽量な形。常時起動が不要で、呼び出し頻度が読めないときに向きます。
EC2：1 台のサーバーをまるごと自分で管理する形。柔軟ですが、運用の手間は増えます。

どれを選ぶかは、「常時起動が必要か」「アクセス頻度はどれくらいか」「運用にどこまで手をかけられるか」で決まります。最初は ECS / Fargate のコンテナで始めるチームが多い印象です。

3. Azure へのデプロイ選択肢

Azure は私の常用クラウドではないので、ここは公式ドキュメントで確認した範囲の整理です。

Azure Container Apps は、コンテナ化されたアプリケーションをサーバーレスで実行できるマネージドサービスです。出典: Azure Container Apps の概要｜Microsoft Learn（取得：2026-06-02）

考え方は AWS と同じで、「コンテナで動かす（Container Apps）」か「リクエストごとに起動する（Azure Functions）」かの選択になります。具体の手順は、Azure を主に使っているチームの方が、公式ドキュメントを正として進めるのが確実だと思います。

4. リモート公開時の認証・ネットワーク

リモート公開すると、「誰でもアクセスできる状態」になりがちなので、ここは慎重に設計します。私が業務の基盤まわり（AWS / GCP の IAM・VPC）で意識してきた範囲で言うと、外せないのは次の点です。

VPC 内通信に閉じる：社内からしか叩けないネットワークに置けるなら、まずそれを検討します。
IAM で最小権限：サーバーが触れるクラウド資源は、必要な分だけに絞ります。
認証を必ず挟む：公開エンドポイントには、認証なしでアクセスできる状態を作らないようにします。

ここから先、つまり「自社の本番環境に、社内データにつながる MCP サーバーを公開してよいか」の最終判断は、組織の情シス・セキュリティ部門に委ねるのが筋です。私の経験はあくまで「型」の共有であって、各社の本番環境の安全性を保証するものではありません。クラウド基盤側の前提として、AWS Bedrock や Vertex AI のようなエンタープライズ AI 基盤の記事も、あわせて参考になると思います。

09 — セキュリティ：本番運用 3 原則とリスク 5 項目

📖 この章で使う用語

権限分離：読み取りと書き込みなど、操作の種類ごとに権限を分けること。

Secrets：API キー・パスワード・トークンなどの秘密情報。

プロンプトインジェクション：外部から読み込んだ文章の中に悪意ある指示が混ざっていて、AI がそれに従ってしまう攻撃。

Audit log（監査ログ）：誰が・いつ・何を操作したかの記録。

OWASP LLM Top10：LLM アプリの代表的なセキュリティリスクをまとめた、業界標準のリスト。

最初にお断りしておきます。自作 MCP サーバーは、社内データや外部リソースにつながるプログラムなので、「絶対に安全」と言い切れるものではありません。ここでは、私が本番運用で守っている原則と、踏みやすいリスクを、できるだけ正直に共有します。最終的に本番投入してよいかの判断は、組織の情シス・セキュリティ・法務部門に委ねてください。

1. 本番運用 3 原則

私が「最初の 1 本目から守る」と決めているのは、次の 3 つです。

権限分離を最初から設計する：読み取り tool と書き込み tool を分け、それぞれが触れる範囲を最小にします。「とりあえず全部できる管理者権限で動かす」が、いちばん事故ります。
Secrets はサーバー側で管理する：API キーやパスワードは、コードにも設定 JSON にも直書きしません。環境変数で渡し、.gitignore で Git から除外し、本番ではクラウドの秘密情報管理（AWS Secrets Manager や Vault など）に寄せます。
Audit log を最初から組む：「誰が・いつ・どの tool を・どんな引数で呼んだか」を記録します。後から付け足すのは大変なので、最初から仕込んでおくとラクです。

# Secrets を Git に上げないための .gitignore 例
.env
.env.local
*.key
secrets/

# 環境変数は .env などから読み込む（コードに直書きしない）
export INTERNAL_API_KEY="xxxx"
export READONLY_DB_DSN="postgresql://readonly_user:****@staging-host/db"

2. リスク 5 項目

業界標準のリスク一覧である OWASP の「LLM アプリ Top 10」に照らすと、自作 MCP サーバーで特に意識したいのは次の 5 つです。

権限過大：tool に必要以上の権限を持たせてしまう。OWASP では「過剰なエージェンシー（Excessive Agency）」として挙げられています。
Secrets 漏れ：キーやパスワードを直書きして、リポジトリやログに流出させてしまう。
プロンプトインジェクション：MCP 経由で読み込んだデータの中に悪意ある指示が混ざり、AI が意図しない操作をしてしまう。OWASP の筆頭リスクです。
Rate limit・コスト爆発：AI が tool を大量に呼んで、接続先 API の料金や負荷が想定外に膨らむ。
Audit log 欠如：問題が起きたとき、何が起きたのか追えない。

リスクの根拠となる業界標準は次のとおりです。

OWASP Top 10 for LLM Applications（2025 年版）は、プロンプトインジェクションを LLM01、過剰なエージェンシーを LLM06 として挙げています。出典: OWASP Top 10 for LLM Applications 2025｜OWASP GenAI Security Project（取得：2026-06-02）

3. 最小権限の原則を具体に落とす

抽象論で終わらせないために、私が実際にやっている具体策を挙げます。

読み取り tool と書き込み tool を分ける：1 つの tool に「読みも書きも」させない。
本番 DB に向けない：セクション 7 でも書いたとおり、DB はステージングか読み取り専用ユーザーから始めます。
ファイル操作は決めたフォルダだけに限定する：ファイルを触る tool は、AI が触れるパスを特定のフォルダ（sandbox）に閉じ込めます。「どこのファイルでも読み書きできる」状態を作らないことです。

ここまでやっても「絶対に安全」にはなりません。だからこそ、Audit log を残し、本番投入の最終判断は専門部門に委ねる、という二段構えにしておくのが現実的だと、私は考えています。

10 — 無料で作れるか：SDK は無料、コストは接続先

📖 この章で使う用語

従量課金：使った分だけ料金が発生する課金方式。接続先 API やクラウドでよく採用されています。

「mcp サーバー作り方無料」という検索もあるとおり、コストは気になるところです。結論を先に言うと、MCP の SDK と公式の MCP サーバーは無料です。

MCP の仕様・SDK・公式サーバー群は、オープンソースとして公開されています。出典: Introducing the Model Context Protocol｜Anthropic（取得：2026-06-02）

では、どこにお金がかかるのか。大きく 2 か所です。

接続先 API のコスト：MCP サーバーがつなぐ先（外部の検索 API、商用 SaaS、クラウドの従量課金など）に料金が発生します。たとえば外部の検索 API を tool にする場合、その API 側の料金がかかります。
クライアントが叩く LLM の利用料：MCP サーバーを使うのは、Claude や ChatGPT などの LLM 側です。その LLM の API 利用料は別途かかります。クライアント側の API キー管理は、Anthropic Console 使い方でも触れています。

具体的な金額は、サービスや時期によって変わります。料金は必ず各公式ページで最新を確認してください。「自作そのものは無料、つなぐ相手と AI 側にお金がかかる」という構造だけ、押さえておけば十分です。

11 — 失敗パターン 5 個：自作 MCP サーバーで踏むつまずき

📖 この章で使う用語

ポータビリティ：別の環境・別の人の PC でも、そのまま動く性質。絶対パス前提だと、ここが崩れます。

エラーハンドリング：エラーが起きたときの処理。MCP では stdio を print で汚すと通信が壊れる、という独特の落とし穴があります。

私や周囲が実際に踏んだ（あるいは寸前で避けた）つまずきを、「症状 → 原因 → 対処」の形で 5 つ挙げます。先に知っておくだけで、だいぶ回避できます。

1. 本番 DB に直結してしまう

症状：AI が想定外のクエリを投げて、本番データに影響が出る。
原因：手早く動かしたくて、本番 DB の書き込み権限を持つユーザーで tool を作ってしまった。
対処：ステージング環境か読み取り専用ユーザーから始める。書き込み系は人間の最終確認を挟む。セクション 7 で書いた原則です。

2. 絶対パス前提で、他の人の PC で動かない

症状：自分の PC では動くのに、チームメンバーの環境で起動エラー。
原因：/Users/自分の名前/... のような絶対パスを設定に直書きしていた。
対処：パスは環境変数や設定で外出しし、ポータビリティを意識する。Windows のパスはセクション 6 の注意点も参照。

3. 権限過大で動かしてしまう

症状：tool が「何でもできる」状態で、レビューで止められる（あるいは事故る）。
原因：開発を急いで、管理者権限でとりあえず通してしまった。
対処：最初から最小権限で設計する。読み取りと書き込みを分ける。セクション 9 の本番運用 3 原則です。

4. Secrets をハードコードしてしまう

症状：API キーがリポジトリに上がってしまい、慌てて作り直す。
原因：動作確認のとき、キーをコードに直書きしてそのままコミット。
対処：最初から環境変数＋.gitignore 除外。「あとで直す」は大体間に合いません。

5. stdio を `print` で汚して通信が壊れる

症状：手元では動くのに、クライアントにつなぐと「サーバーが応答しない」と言われる。
原因：デバッグ用の print() が標準出力に出ていて、stdio 通信を壊していた。
対処：ログは標準エラー出力（sys.stderr）かロギングの仕組みを使う。標準出力は通信専用と割り切る。これは MCP 独特の落とし穴なので、最初に知っておくと事故が減ります。

12 — 職種別ユースケース：エンジニアでない方がどう活かせるか

📖 この章で使う用語

CRM：顧客や案件の情報を管理する仕組み（システム）。営業の現場でよく使われます。

「自作」と聞くとエンジニア寄りに感じるかもしれませんが、視点を「誰かに作ってもらった MCP サーバーが、自分の仕事をどう変えるか」に変えると、非エンジニアの方にも関係する話になります。ここでは、私の営業時代の感覚も交えつつ、職種別に整理します（営業以外は、一般的な業務例として書きます）。

1. 営業職：案件 DB を MCP 化して、商談前の準備を短縮

Before：商談前に、CRM と案件 DB を行き来して、過去のやり取りを 15 分かけて手で拾い集める。
After：案件 DB を MCP 化しておけば、AI に「この顧客の直近の動きを 3 行で」と頼むと、骨子がすぐ出てきます。
所要時間・コスト：サーバー自体はエンジニアが用意する前提。使う側は AI クライアントの操作を覚えるだけ。
最初の壁：「どの情報を AI に渡してよいか」の線引き。ここは情シスと相談が要ります。

営業時代の私だったら、間違いなくここに使っていたと思います。お客様の「次の一言」を半歩先で読む準備に、いちばん時間を割いていたからです。

2. 事務職：定型台帳を MCP 化して、集計を AI に頼む

Before：複数のファイルやシートを開いて、毎月の集計を手作業でまとめる。
After：台帳を読み取り専用で MCP 化しておけば、AI に「今月の件数を部署別に」と頼める。
所要時間・コスト：読み取り専用なので、安全に始めやすい部類です。
最初の壁：元データの形がバラバラだと、AI も読み違えます。まず整える手間は残ります。

3. 個人事業主：請求データを軽く MCP 化して、経理を補助

Before：請求のスプレッドシートを見ながら、月末に売上を手集計。
After：自分用の小さな MCP サーバーを 1 本作れば、AI に「先月との差分を」と聞けます。
所要時間・コスト：自分専用なら手元の stdio で十分。SDK は無料。
最初の壁：最初の 1 本を作るまでの環境構築。セクション 4 の最小サンプルから始めるのが近道です。

4. 副業ライター：取材メモや公開 API を MCP 化して、下調べを自動化

Before：取材メモのファイルを開き直し、関連情報を手で検索してまとめる。
After：メモや公開 API を MCP 化しておけば、AI に下調べの叩き台を作ってもらえます。
所要時間・コスト：公開 API 中心なら、コストも軽めに始められます。
最初の壁：公開 API の使い方（キー取得や利用規約）に慣れること。

5. エンジニア志望：最小 MCP サーバーがポートフォリオになる

Before：「何を作れば実力が伝わるか」が分からず、学習が手につかない。
After：セクション 4 の最小サーバーを土台に、自分の興味あるデータをつなぐと、立派な作品になります。
所要時間・コスト：最小サンプルなら 1 日で形になります。SDK は無料。
最初の壁：「動くだけ」で満足せず、セキュリティ（セクション 9）まで踏み込めるかが差になります。

なお、MCP は「外部とつなぐ接続層」の話です。AI が自分で考えて動く「エージェント」全体の設計は、AIエージェント作り方で 4 つのルートとして整理しています。MCP はそのうちの「つなぐ」部分を担う、と捉えると位置づけが見えてきます。

13 — よくある質問

Q1: MCP サーバーは無料で作れますか？

A. SDK（Python / TypeScript）と公式の MCP サーバーは、オープンソースで無料です。お金がかかるのは「接続先の API（外部検索や商用 SaaS、クラウドの従量課金）」と「クライアント側が叩く LLM の利用料」のほうです。金額は変わることがあるので、各公式ページで最新を確認してください。

Q2: Python と TypeScript、どちらの SDK で作るのが良いですか？

A. 「絶対こちら」とは言えませんが、既存の業務スタックに近い言語を選ぶのが現実的です。型安全・堅さ重視なら TypeScript、実験の速さや AI 連携の周辺ツールの厚みなら Python が向きます。私自身は、業務の言語スタック（Ruby / Python / Scala）に近い Python SDK を軸にしています。

Q3: C# や Java でも MCP サーバーは作れますか？

A. 公式ドキュメントで確認した範囲では、C# や Java（Kotlin）向けの SDK も提供されています（出典: SDKs｜Model Context Protocol、取得：2026-06-02）。基本構造（tools / resources / prompts、stdio / HTTP）は共通です。私の常用言語ではないため、本記事の手を動かす部分は Python / TypeScript に寄せています。

Q4: 自作 MCP サーバーを本番運用しても大丈夫ですか？

A. 私自身は社内 API・自社 DB を MCP 化して本番運用していますが、「絶対に安全」とは申し上げられません。本番 DB に直結しない・Secrets は環境変数＋Git 除外・最小権限・Audit log を最初から設計、が出発点です。本番投入の最終判断は、組織の情シス・セキュリティ・法務部門に委ねてください。

Q5: Windows でも MCP サーバーは作れますか？

A. 作れます。Python や Node.js が動けば、OS は問わない設計です。ただし設定 JSON のパス区切り（\\ のエスケープ）や環境変数の読み込みで OS 差が出ます。Windows では、絶対パス指定と環境変数の確実な反映に少し注意すると安心です（セクション 6 参照）。

AIエージェント MCP — MCP の概念と「使う側」を扱う親ハブ記事。本記事と並走で読むと全体像がつかめます。
AIエージェント作り方 — MCP を含むエージェント構築の 4 ルートを俯瞰。
Cursor 使い方 — 自作サーバーをつなぐ Cursor 本体の使い方。
Claude Code 使い方 — 自作サーバーをつなぐ Claude Code 本体の使い方。
Claude Skills 自作 — 「手順とファイルをまとめて渡す」用途との使い分け。
Anthropic Console 使い方 — クライアント側の API キー管理。
RAG とは — DB を MCP 化して AI に渡す発想と地続きの考え方。
FAISS とは — RAG の「検索」を担う Meta 製の無料ベクトル検索ライブラリ。
Gemini CLI 使い方——Google のターミナル型 AI コーディングを 3 ツール比較で整理
Gemini API 使い方——コードから Gemini を呼ぶ最小サンプルを Python・GAS で

訂正・お問い合わせ

本記事の内容に誤りや古くなった情報を見つけられた場合は、send@bon-bon-tools.com までお知らせいただけると助かります。仕様や料金は変わることがあるため、最終的には各公式ドキュメントをご確認ください。本番運用やセキュリティに関わる最終判断は、組織の情シス・セキュリティ・法務部門に委ねるのが筋です。

出典

Introducing the Model Context Protocol｜Anthropic（取得：2026-06-02）
Build an MCP server（Quickstart）｜Model Context Protocol（取得：2026-06-02）
SDKs｜Model Context Protocol（取得：2026-06-02）
Transports｜Model Context Protocol（取得：2026-06-02）
Example Servers｜Model Context Protocol（取得：2026-06-02）
MCP Python SDK（README）｜GitHub（取得：2026-06-02）
MCP TypeScript SDK（README）｜GitHub（取得：2026-06-02）
Use MCP servers in VS Code｜Visual Studio Code Docs（取得：2026-06-02）
Azure Container Apps の概要｜Microsoft Learn（取得：2026-06-02）
OWASP Top 10 for LLM Applications 2025｜OWASP GenAI Security Project（取得：2026-06-02）

01 — 結論：MCP サーバーは公式 SDK で数十行から作れる

02 — MCP サーバーとは何か（作る側の視点で 30 秒）

03 — 作る前の準備：どの言語の SDK で書くか

1. Python SDK と TypeScript SDK が二大主軸

2. C# SDK / Java（Kotlin）SDK も公式に存在する

3. 言語選択の判断軸

04 — Python SDK で最小の MCP サーバーを作る（5 分・コード）

1. 環境を準備する

2. 最小のサーバーを書く

3. ローカルで動作を確認する

4. つまずきやすい初手

05 — TypeScript SDK で作る＋ tools / resources / prompts の使い分け

1. 環境を準備する

2. 最小のサーバーを書く

3. tools / resources / prompts の使い分け

4. stdio と Streamable HTTP の選び方

06 — Cursor・Claude Code・VS Code から自作サーバーにつなぐ

1. Cursor につなぐ

2. Claude Code につなぐ

3. VS Code につなぐ

4. Windows 環境の注意

07 — 社内 API・自社 DB を MCP 化する実装パターン

1. 作る前に「既存のサーバーで足りないか」を確認する

2. 社内独自の API を MCP 化するパターン

3. 自社 DB を MCP 化するパターン

4. どれで公開するか（tools / resources / prompts）

08 — クラウド（AWS / Azure）へのデプロイと運用

1. stdio から HTTP へ移行が必要になる場面

2. AWS へのデプロイ選択肢

3. Azure へのデプロイ選択肢

4. リモート公開時の認証・ネットワーク

09 — セキュリティ：本番運用 3 原則とリスク 5 項目

1. 本番運用 3 原則

2. リスク 5 項目

3. 最小権限の原則を具体に落とす

10 — 無料で作れるか：SDK は無料、コストは接続先

11 — 失敗パターン 5 個：自作 MCP サーバーで踏むつまずき

1. 本番 DB に直結してしまう

2. 絶対パス前提で、他の人の PC で動かない

3. 権限過大で動かしてしまう

4. Secrets をハードコードしてしまう

5. stdio を print で汚して通信が壊れる

12 — 職種別ユースケース：エンジニアでない方がどう活かせるか

1. 営業職：案件 DB を MCP 化して、商談前の準備を短縮

2. 事務職：定型台帳を MCP 化して、集計を AI に頼む

3. 個人事業主：請求データを軽く MCP 化して、経理を補助

4. 副業ライター：取材メモや公開 API を MCP 化して、下調べを自動化

5. エンジニア志望：最小 MCP サーバーがポートフォリオになる

13 — よくある質問

Q1: MCP サーバーは無料で作れますか？

Q2: Python と TypeScript、どちらの SDK で作るのが良いですか？

Q3: C# や Java でも MCP サーバーは作れますか？

Q4: 自作 MCP サーバーを本番運用しても大丈夫ですか？

Q5: Windows でも MCP サーバーは作れますか？

関連記事

訂正・お問い合わせ

出典

5. stdio を `print` で汚して通信が壊れる