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 原則までを、現役エンジニアの目線で整理します。

最短で 1 回動かしたい方は Python の最小サンプルから、Cursor / Claude Code につなぐ設定だけ知りたい方はクライアント接続を、セキュリティが気になる方は本番運用 3 原則からどうぞ。MCP そのものの意味や「使う側」の話は、親記事の AIエージェント MCP に集約しています。本記事は「自分で MCP サーバーを作る」ことに集中します。

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

まず全体像｜MCP サーバーとは何か・どの言語の SDK で作るか

📖 この章で使う用語

MCP（Model Context Protocol）：AI に外部のもの（ファイル・DB・API）を渡すための共通ルール（仕様）。

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

SDK：MCP サーバーを書くための公式の道具箱。Python / TypeScript などで配られています。

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

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

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

読む順番は状況に応じて変えて大丈夫です。「最短で 1 回動かしたい」方はステップ 3 まで、「社内のデータをつなぎたい」方はステップ 5、「本番前提でセキュリティが心配」な方はステップ 6 を中心にどうぞ。Python SDK での自作と本番運用は実体験として自分の言葉で、C# / Java の SDK や Azure の細部は公式ドキュメントを確認しながら出典つきで書きます。

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

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

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

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

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

特定の会社に閉じていないので、Claude でも Cursor でも、対応するクライアントから同じ MCP サーバーを使えます。社内向けに 1 本作ったサーバーを Cursor からも Claude Code からも呼べるようにしておくと、チームへの展開がぐっとラクになりました。

どの言語の SDK で書くか

最初の分かれ道が「どの言語で書くか」です。「mcp サーバー作り方」と一緒に検索される言葉には python / typescript / c# / java が並び、ここが最大の関心どころだと分かります。

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

「C# / Java の現場でも書けるのか」という疑問もよくあります。公式ドキュメントで確認した範囲では、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 で書く場合も考え方はそのまま流用できます。判断軸は次の 3 点です。

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

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

最小の MCP サーバーを作る｜Python・TypeScript の数十行サンプル

📖 この章で使う用語

FastMCP：Python SDK の高レベルな書き方。@mcp.tool() を関数につけるだけで tool として公開できます。

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

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

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

Streamable HTTP：MCP のリモート通信方式。ネットワーク越しに公開するときに使います。

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

Python SDK で最小サーバーを作る（5 分）

公式ドキュメントではパッケージ管理に 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）

server.py を作り、「2 つの数を足す」という最小の tool を 1 個だけ公開します。

# 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 が「この道具は何をするものか」を理解する手がかりになるので、丁寧に書くほど適切な場面で選んでくれます。

動作確認は公式の MCP Inspector で画面から行えます。

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

ブラウザで add tool が見え、引数に数値を入れて結果が返れば、最小サーバーは完成です。初手のつまずきとして多いのは次の 3 つです。

import エラー：mcp が見つからないときは uv / venv の有効化忘れが大半。pip install した環境とサーバーを動かす環境がずれていないか確認します。
stdio を print で汚す：print() で標準出力に文字を出すと通信が壊れます。ログは標準エラー出力（sys.stderr）かロギングの仕組みへ（失敗パターンで再掲）。
Python のバージョン：古いと動かないことがあるので、エラー時はまずバージョンを疑うと早いです。

TypeScript SDK で作る

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

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）

// 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 を登録する → 通信方式で起動する」という流れは言語が変わっても同じです。一度どちらかで作れば、もう片方への乗り換えはそこまで大変ではありません。

tools / resources / prompts と通信方式の使い分け

3 種類の公開対象は、次のように使い分けます。

種類	役割	例
tools	AI に「やってもらう」操作	DB 検索、API を叩く、ファイル書き換え
resources	AI に「読んでもらう」データ	ファイルの中身、設定値、API レスポンス
prompts	使い回せる定型文	「この作業はこの聞き方で」のテンプレ

私の自作では「AI に業務操作を任せる」用途が中心で、tools が主役です。最初は tools 1 本に絞り、必要になったら resources / prompts を足す、で十分でした。

通信方式も用途で選びます。手元の PC で同じマシンのクライアント（Cursor / Claude Code）と動かすなら stdio、ネットワーク越しに複数人へ公開するなら Streamable HTTP（リモート公開で扱います）。

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

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

クライアントにつなぐ＋社内 API・自社 DB を MCP 化する

📖 この章で使う用語

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

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

環境変数：API キーや接続先を設定ファイルに直書きせず、外（シェル / OS）から渡す方式。

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

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

作ったサーバーは、クライアントに登録して初めて使えます。私は Cursor と Claude Code を常用しているので、その 2 つを自分の使い方ベースで、VS Code は公式の案内をもとに添えます。

Cursor・Claude Code・VS Code につなぐ

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} と書くと、シェルに設定した環境変数の値が読み込まれます。この「秘密情報を直書きしない」作法はセキュリティでも繰り返し出てくるので、最初の 1 本目から徹底しておくのがおすすめです。

Claude Code では、コマンドで追加できます。

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

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

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

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

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

基本の考え方（コマンドと環境変数でサーバーを登録する）はどのクライアントも共通です。Windows に展開するときは、次の差に注意します。

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

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

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

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

まず、やりたいことが既存の MCP サーバーで足りるなら、自作しないほうがラクです。

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

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

社内認証が必要だったり社内ネットワークからしか叩けない 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 を切ること。エンドポイントを 1 対 1 で並べるのではなく、「受注を検索する」「在庫を確認する」のように、AI（と人間）が一読して用途が分かる粒度にまとめます。

DB の MCP 化は便利さと危うさが背中合わせです。私が最初から守るルールは 2 つ。本番 DB には絶対に向けず、まずはステージングか読み取り専用ユーザーを使う。書き込み系（DML）は tool 化を急がず、やるとしても「人間が確認してから実行」の段を必ず入れる、です。

# 自社 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 とはの考え方と地続きです。なお、まとまった手順やファイルをパッケージで渡したいなら、MCP より Claude Skills 自作が向くこともあります。「外部リソースにつなぐなら MCP、手順とファイルをまとめて渡すなら Skills」と覚えておくと設計で迷いません。

本番へ載せる｜クラウドデプロイとセキュリティ 3 原則

📖 この章で使う用語

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

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

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

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

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

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

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

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

クラウド（AWS / Azure）へのデプロイ

stdio は「同じマシンの中」の通信です。自分の PC 以外（チームメンバー、CI、別サーバー）から使いたい、常時起動で複数人が同時に使う、といった場面では Streamable HTTP に切り替えてリモート公開を検討します。逆に、個人で手元のツールとして使うだけなら無理に HTTP 化しなくて大丈夫です。

AWS に載せるなら、選択肢はおおむね次の 3 つです。

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

「常時起動が必要か」「アクセス頻度」「運用にどこまで手をかけられるか」で決まります。最初は ECS / Fargate で始めるチームが多い印象です。Azure は私の常用クラウドではないので、公式ドキュメントの範囲で添えます。

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

考え方は AWS と同じで、「コンテナで動かす（Container Apps）」か「リクエストごとに起動する（Azure Functions）」かの選択です。

リモート公開すると「誰でもアクセスできる状態」になりがちなので、ここは慎重に設計します。外せないのは、VPC 内通信に閉じる（社内からしか叩けないネットワークに置けるならまずそれを）、IAM で最小権限（触れるクラウド資源を必要な分だけに）、認証を必ず挟む（公開エンドポイントを認証なしにしない）の 3 点です。クラウド基盤側の前提としては、AWS Bedrock や Vertex AI の記事もあわせて参考になります。

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

最初にお断りすると、自作 MCP サーバーは社内データや外部リソースにつながるので「絶対に安全」とは言い切れません。本番投入してよいかの最終判断は、組織の情シス・セキュリティ・法務部門に委ねてください。そのうえで、私が「最初の 1 本目から守る」と決めている 3 原則がこれです。

権限分離を最初から設計する：読み取り tool と書き込み tool を分け、それぞれが触れる範囲を最小にします。「全部できる管理者権限で動かす」がいちばん事故ります。
Secrets はサーバー側で管理する：API キーやパスワードはコードにも設定 JSON にも直書きせず、環境変数で渡し、.gitignore で除外し、本番ではクラウドの秘密情報管理（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"

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

リスク	内容
権限過大	tool に必要以上の権限を持たせる（OWASP の Excessive Agency）。
Secrets 漏れ	キー・パスワードを直書きし、リポジトリやログへ流出。
プロンプトインジェクション	読み込んだデータの悪意ある指示で 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）

最小権限を具体に落とすなら、読み取り tool と書き込み tool を分け、DB はステージングか読み取り専用ユーザーから始め、ファイル操作は AI が触れるパスを特定フォルダ（sandbox）に閉じ込めます。ここまでやっても「絶対に安全」にはならないので、Audit log を残し、最終判断は専門部門に委ねる二段構えが現実的です。

コスト・失敗パターン・非エンジニアの使いどころ

📖 この章で使う用語

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

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

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

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

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

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

お金がかかるのは大きく 2 か所です。1 つは接続先 API のコスト（外部検索 API、商用 SaaS、クラウドの従量課金など）、もう 1 つはクライアントが叩く LLM の利用料（Claude や ChatGPT などの API 利用料。キー管理は Anthropic Console 使い方でも触れています）。金額はサービスや時期で変わるので各公式ページで最新を確認してください。「自作そのものは無料、つなぐ相手と AI 側にお金がかかる」という構造だけ押さえれば十分です。

失敗パターン 5 個：自作で踏むつまずき

私や周囲が実際に踏んだ（あるいは寸前で避けた）つまずきを 5 つ挙げます。先に知っておくだけで、だいぶ回避できます。

本番 DB に直結してしまう：手早く動かしたくて書き込み権限ユーザーで tool を作り、AI の想定外クエリで本番データに影響。→ ステージングか読み取り専用ユーザーから始め、書き込み系は人間の最終確認を挟む（社内 DB の MCP 化の原則）。
絶対パス前提で他人の PC で動かない：/Users/自分の名前/... を設定に直書きし、チームメンバーの環境で起動エラー。→ パスは環境変数や設定で外出しし、ポータビリティを意識（Windows のパスはクライアント接続も参照）。
権限過大で動かす：開発を急いで管理者権限で通し、レビューで止まる（あるいは事故る）。→ 最初から最小権限で設計し、読み書きを分ける（本番運用 3 原則）。
Secrets をハードコードする：動作確認でキーを直書きしたままコミットし、慌てて作り直し。→ 最初から環境変数＋.gitignore 除外。「あとで直す」は大体間に合いません。
stdio を print で汚す：デバッグ用の print() が標準出力に出て stdio 通信を壊し、「サーバーが応答しない」。→ ログは sys.stderr かロギングへ。標準出力は通信専用と割り切る。MCP 独特の落とし穴です。

エンジニアでない方が「MCP 化」で得られること

「自作」と聞くとエンジニア寄りに感じますが、MCP 化の本質は 手元のデータ（CRM・台帳・請求データ・取材メモ）を AI から直接引けるようにする こと。視点を「使う側」と「自分用に小さく作る側」に分けると、非エンジニアの方にも関係します。

使う側は、案件 DB や定型台帳が MCP 化されていれば AI クライアントの操作を覚えるだけ。営業なら「この顧客の直近の動きを 3 行で」、事務なら読み取り専用の台帳に「今月の件数を部署別に」。最初の壁は「どの情報を AI に渡してよいか」の線引きで、ここは情シス相談が要ります（読み取り専用なら安全に始めやすい部類です）。

自分用に小さく作る側は、自分のデータ（請求スプレッドシート、取材メモ、公開 API）を小さな MCP サーバー 1 本でつなぐと、AI に「先月との差分を」「下調べの叩き台を」と頼めます。自分専用なら手元の stdio で十分、SDK は無料。Python の最小サンプルから始めるのが近道で、興味あるデータを繋ぐこと自体が立派なポートフォリオになります。

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

よくある質問

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 では、絶対パス指定と環境変数の確実な反映に少し注意すると安心です（クライアント接続参照）。

AIエージェント MCP — MCP の概念と「使う側」を扱う親ハブ記事。本記事と並走で読むと全体像がつかめます。
Claude Agent SDK とは——Claude Code の中身（自律エージェントの動き）を Python/TS で自分のアプリに組み込む SDK を業務利用視点で整理
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 で
LM Studio 使い方——ターミナル不要の GUI でローカル LLM を入れる→モデル管理→OpenAI 互換 API まで、Ollama との使い分けも整理

訂正・お問い合わせ

本記事の内容に誤りや古くなった情報を見つけられた場合は、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）