MCPサーバーの作り方｜自作の実装手順とMCP開発案件の単価

着手前に決める3つのこと

結論から言うと、コードを書く前に「言語」「トランスポート」「公開範囲」の3つを決めておくと手戻りが出ません。 この3つは後から変えると、認証とデプロイをまるごと書き直すことになります。

言語とSDKの選び方

公式SDKはPython・TypeScriptのほか、Java・Kotlin・C#・Rustなど複数が用意されています。実務では既存の社内コードと同じ言語を選ぶのが正解になりやすい。MCPサーバーの中身は結局、社内APIやDBを叩く薄いラッパーだからです。認証ロジックやモデルクラスを流用できる言語を選べば、実装量は半分以下になります。

迷ったときの目安はこうです。データ分析基盤やML推論に繋ぐならPython。Node.jsのバックエンドや既存のTypeScript資産に繋ぐならTypeScript。

本記事執筆時点（2026年10月）に公式ドキュメントとパッケージレジストリで確認した範囲では、PyPIのmcpパッケージは2系、TypeScript側もサーバー専用パッケージが2系として公開されていました。ただしパッケージ名もバージョンも更新が続いているため、着手前に必ず公式ドキュメントで現行の推奨パッケージを確認してください。日本語の解説記事は旧パッケージ名のまま更新されていないものが見られ、そのまま写経すると最初のimportで止まることがあります。

トランスポートの選び方

MCP仕様が定める標準トランスポートは2つです。

まずstdioで作り、必要になってからStreamable HTTPへ移すのが安全です。stdioは認証を考えなくていい代わりに、サーバーを使う人のマシンに実行環境を配る必要があります。社内10人に配る段階で面倒になり、そこでHTTPへ移行するケースが多い。

旧仕様にあったHTTP+SSEの単独トランスポートは、現行仕様ではStreamable HTTPに統合されています。古い記事を参考にするときは、ここも読み替えが必要です。詳細はMCP公式仕様を参照してください。

公開範囲を先に決める

自分のマシンだけで使うのか、チームに配るのか、顧客環境に置くのか。ここで決まるのはシークレットの持たせ方です。個人利用ならホストの設定ファイルに環境変数として書いて済みますが、チーム配布になった瞬間、その方式は破綻します。

ミニFAQ：着手前の疑問

Q. ツールとリソースとプロンプト、どれから作ればいい？

A. ツールからで構いません。仕様上サーバーが提供できる機能は、リソース（モデルやユーザーが読むデータ）、プロンプト（定型のワークフロー）、ツール（モデルが実行する関数）の3種ですが、実案件の大半はツールだけで要件を満たせます。

Q. 既存のREST APIがあるなら、MCPサーバーは不要では？

A. モデルに使わせるなら必要です。MCPサーバーの価値は、エンドポイントを並べることではなく、モデルが読んで判断できる説明文とスキーマを付けることにあります。REST APIの設計そのものについてはREST APIとは｜設計原則・HTTPメソッド・GraphQL/gRPCとの違いが参考になります。

MCPサーバーの作り方【6ステップ】

公式クイックスタートの流れを実務向けに整理すると、次の6ステップになります。 最小構成のサーバーなら、環境構築を含めて30〜60分あれば「ホストからツールが1本見えて、呼ぶと値が返る」状態まで到達します。

なお、動くコード自体は公式のサーバー構築ガイドに言語別のサンプルが揃っており、SDKの更新に追従して保守されています。本記事ではサンプルを再掲するかわりに、その通りに書いても詰まる箇所と、実務で変えるべき箇所に絞って解説します。

ステップ1：開発環境を用意する

Pythonの場合は、パッケージマネージャにuvを使うのが公式の推奨です。プロジェクトを初期化し、仮想環境を作り、uv add "mcp[cli]" で依存を入れます。CLI付きで入れておくと、後述のインスペクタ連携が楽になります。

TypeScriptの場合は、npm initでプロジェクトを作り、公式のサーバーパッケージとzodを入れます。型定義とtsx、あるいはtscでのビルド環境も合わせて用意しておきます。

どちらも、ここで詰まるのはNode.jsやPythonのバージョンが古いパターンです。先にバージョンを確認しておくと無駄が減ります。言語自体の立ち位置はPythonとは？できること、将来性、年収・キャリアまで徹底解説！、TypeScriptとは？JavaScriptとの違いや年収、将来性について解説も参考になります。

ステップ2：サーバーインスタンスを生成する

SDKのサーバークラスをimportし、名前とバージョンを渡してインスタンスを作ります。Pythonならサーバークラスにサーバー名を渡すだけ、TypeScriptならnameとversionを持つオブジェクトを渡すだけです。

ここで指定した名前は、ホスト側のUIに表示されます。社内に複数サーバーを配る予定があるなら、ここで命名規則を決めておくと後が楽です。

ステップ3：ツールを関数として登録する

MCPサーバー実装の中心はここです。Pythonはデコレータで関数を修飾し、TypeScriptはregisterToolに名前・説明・入力スキーマ・ハンドラを渡します。

重要なのは、関数名やdocstring、descriptionがそのままモデルへの指示書になる点です。「ユーザーIDを受け取って契約情報を返す」程度の曖昧な説明では、モデルは呼ぶべき場面を判断できません。「どんなときに使うか」「何を返さないか」まで書きます。

説明文の書き方そのものが精度を左右するという意味で、ここはプロンプト設計に近い作業です。

ステップ4：入力スキーマを設計する

TypeScriptではzod、PythonではPythonの型ヒントがそのままスキーマになります。

実務でのコツは、自由文字列の引数を減らすこと。列挙できる値はenumにし、範囲があるなら最小値・最大値を指定します。モデルは説明がないパラメータに対して、平気で想像上の値を入れてきます。

ステップ5：stdioで起動する

Pythonはrunメソッドにtransportとしてstdioを指定、TypeScriptはStdioServerTransportのインスタンスをconnectに渡します。

ここで必ず押さえてほしいのが、stdioサーバーは標準出力にログを書いてはいけないという制約です。標準出力はJSON-RPCの通信路なので、printやconsole.logを1行混ぜるだけでプロトコルが壊れます。ログは標準エラー出力へ出してください。デバッグで最も時間を溶かすのがこの罠です。

ステップ6：ホストに登録して接続する

Claude Desktopを使う場合、設定ファイルのmcpServersに、サーバー名・起動コマンド・引数を書きます。執筆時点の公式ガイドでは、設定ファイルはmacOSならユーザーのApplication Support配下、WindowsならAppData配下に置かれると案内されています。この場所はクライアントの種類とバージョンで変わるため、アプリの設定画面から設定ファイルを開く導線を使うのが確実です。

ここでの頻出ミスは3つ。相対パスを書いている、ビルドを忘れている（TypeScriptの場合）、アプリを再起動していない。この3つで大半の「繋がらない」は説明がつきます。

Claude Desktop以外にも、Claude CodeやCursorなどMCP対応クライアントは複数あります。開発中の動作確認はClaude Codeとは｜使い方・料金プラン・案件動向を解説で触れているCLI環境のほうが、ログが追いやすい場面もあります。

ミニFAQ：実装中の疑問

Q. 1つのサーバーにツールをいくつまで入れていい？

A. 仕様上の上限はありませんが、実務では10〜20個を超えたあたりからモデルの選択精度が落ちます。ドメインごとにサーバーを分けるほうが結果的に安定します。

Python版とTypeScript版の違い

結論として、やることは同じで、書き味が違うだけです。 判断材料になる差分を整理します。

配布のしやすさではTypeScriptに分があります。公開されている公式・コミュニティのMCPサーバー集を見ても、npxで起動できるTypeScript製が目立ちます。社外に配る前提ならTypeScript、社内のデータ基盤に繋ぐだけならPython、という選び方で大きく外しません。

動かないときのデバッグ手順

接続できないときは、上から順に切り分けます。

1. ターミナルから直接サーバーを起動する。ここでエラーが出るなら、MCP以前のコードの問題

2. MCP Inspectorで繋ぐ。公式のInspectorはツール一覧の取得と単発実行ができ、ホストを介さずに検証できます

3. ホスト側のログを見る。Claude Desktopの場合、執筆時点の公式案内ではmacOSはユーザーのLogs配下、WindowsはAppData配下のlogsフォルダにmcp関連のログが出力されます。サーバーごとのログファイルには、そのサーバーの標準エラー出力がそのまま書かれます。ログの出力先はクライアントごとに異なるので、他のホストを使う場合はそれぞれのドキュメントで確認してください

4. 設定ファイルのJSON構文を疑う。末尾カンマひとつで、サーバーは一覧に出てきません

この順序で見れば、たいていは15分以内に原因にたどり着きます。いきなりホストのログから見始めると、情報量が多すぎて遠回りになります。

よくあるエラーと対処

実務で詰まる設計の勘所

ここからは、クイックスタートを終えた後に効いてくる話です。案件で評価されるかどうかは、動くかどうかではなく、この層をどう設計したかで決まります。

ツールの粒度を業務単位で切る

API単位でツールを生やすと、モデルは3回も4回も往復します。「顧客を検索する」「契約を取得する」「請求履歴を返す」を別々に置くより、「顧客の契約状況をまとめて返す」1本のほうが精度も速度も上がります。

設計の軸は、エンドポイント単位ではなく人間の作業単位です。

書き込み系ツールは最初は出さない

削除・更新・送信など、副作用のあるツールは、読み取り系が安定してから追加します。MCP仕様でも、ツールは任意のコード実行の経路であり、ホストは実行前にユーザーの明示的な同意を得るべきだと明記されています。とはいえ、同意UIがあるから安全とは限りません。取り消せない操作は、確認用のdry-run引数をこちら側で用意しておくと事故が減ります。

認証とシークレットの扱い

stdio構成では、APIキーはホストの設定ファイルに環境変数として持たせる形になります。個人利用なら許容範囲ですが、配布するなら平文のキーが各人のマシンに散ることになります。

Streamable HTTPで公開する場合は、認証に加えてネットワーク境界の設計が必要です。ローカルで動かすHTTPサーバーをそのまま外部に晒すと、DNSリバインディングなどの攻撃経路が開きます。ローカルバインドの徹底とOriginヘッダの検証は出発点として押さえたい項目ですが、これだけで十分というわけではありません。実際に必要な対策は、公開範囲・認証方式・扱うデータの機微性によって変わります。設計時はMCP公式仕様のセキュリティ要件と、自社のセキュリティ基準の両方を確認してください。

加えて、ツールの説明文経由でモデルを誘導する攻撃も現実的な脅威です。外部から取り込んだデータをツールの戻り値に含める場合は、プロンプトインジェクション対策｜LLMアプリのセキュリティ実装ガイドの観点を併せて確認してください。

配布と公開

社内配布なら、プライベートなnpmレジストリやGitリポジトリ経由が現実的です。公開サーバーとして外に出す場合は、MCP公式レジストリという選択肢もあります。

MCP開発案件の実情と単価の目安

結論を先に言うと、MCP開発だけで募集される案件はまだ多くありません。 MCPは案件カテゴリというより、AIエージェント開発やLLMアプリ開発の中に現れるスキル要件として扱われています。

以下の単価は、2026年10月時点で、首都圏中心の主要フリーランスエージェント数社の公開案件ページ（募集要項が掲載されている一般公開の案件一覧）を「MCP」「AIエージェント」「LLM」のキーワードで検索し、該当した数十件規模の募集を観測ベースで整理した目安です。対象は週4〜5日稼働・準委任の案件に絞っています。MCPを明示する公開案件の件数自体がまだ限られる領域のため、相場として固まった数字ではなく、観測ベースの目安として読んでください。

公開案件ベースではこのレンジが中心です。これとは別に、非公開で打診される案件は個別条件で上振れするケースがありますが、こちらは再現性が低いため、まずは公開案件の数字を基準に考えるのが安全です。

近接領域の単価はAIエージェント開発案件の単価相場｜必要スキル・獲得ルートを解説、RAG構築案件の実情｜単価相場・必要スキル・獲得方法で詳しく整理しています。AI案件全体の見取り図はAI案件の種類と単価相場｜フリーランスエンジニア向け完全ガイドが参考になります。

自分がどのレンジを狙えるか把握しておきたい方は、無料のフリーランスエンジニア単価診断で現在の市場単価の目安を確認できます。単価を体系的に上げる考え方は【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？で整理しています。

単価が上振れしやすい条件

募集要件を見ていると、上のレンジで差がつくのは技術スタックの新しさよりも、次の3点です。

• 既存の社内システムに繋いだ経験があること。基幹システムやSaaSとの接続は、プロトコルの知識より業務理解が効く

• 権限設計を説明できること。誰がどのツールを呼べるかを設計し、監査ログまで考えられる人は少ない

• 評価の仕組みを作れること。ツールが正しく選ばれているかを測る仕組みがないと、本番運用に移れない

逆に、クイックスタートをなぞっただけの経験は、面談で深掘りされるとすぐに底が見えます。小さくても1本、社内データに繋いだサーバーを本番で動かした経験があるかどうかが分岐点です。

案件の探し方

エージェントの検索では、MCPというキーワード単体で絞ると件数が出ません。「AIエージェント」「LLM」「生成AI」の職種・技術タグで母集団を作り、そのうえでキーワード欄に「MCP」を足して絞り込むのが実務的です。フリコンでもフリーランスエンジニア向けの案件一覧を公開しているので、要件の書かれ方を確認する用途に使えます。

スキルシートには「MCPサーバーを実装した」ではなく、「どの社内システムに」「何本のツールとして」「どんな権限設計で」繋いだかを書いてください。ここまで書けている人は、公開案件の応募者の中では目立ちます。

よくある失敗と対策

失敗1：仕様のバージョンを混ぜて実装する

MCPの仕様は日付ベースで版が切られています。古い記事のサンプルと最新SDKを混ぜると、トランスポートまわりで整合が取れません。着手時に、参照する仕様の版を1つに決めるところから始めてください。

失敗2：ツールを足しすぎる

「あれもできたほうがいい」で30個並べたサーバーは、だいたい使われません。モデルが選択を誤り、ユーザーが信用しなくなるからです。初版は3〜5個に絞り、実際に使われたツールだけ残していくほうが早く安定します。

失敗3：本番データで試す

開発中に本番DBへ読み書きできる状態で繋ぐのは避けてください。モデルは想定外のタイミングでツールを呼びます。読み取り専用の接続情報から始めるのが鉄則です。客先環境で生成AIツールを使う際の契約面の注意は業務委託で生成AIを使うときの契約・機密情報の注意点｜客先案件の実務にまとめています。

実装前チェックリスト

着手前に、この10項目を埋めてから書き始めると手戻りが減ります。

まとめ

MCPサーバーは、公式SDKでツールを関数として登録し、stdioまたはHTTPで公開して、ホスト側の設定ファイルに登録すれば動きます。 実装そのものは公式SDKを使えば1時間で終わり、案件で差がつくのはツールの粒度・権限設計・配布方法の設計です。

• 着手前に「言語」「トランスポート」「公開範囲」を決める。後から変えると認証とデプロイを書き直すことになる

• 実装は、SDK導入→サーバー生成→ツール登録→スキーマ設計→stdio起動→ホスト登録の6ステップ

• stdioでは標準出力にログを書かない。接続直後に切れる原因の多くがこれ

• 初版のツールは3〜5個に絞り、書き込み系は読み取りが安定してから追加する

• MCP単独の公開案件はまだ少なく、AIエージェント・LLMアプリ案件の要件として登場する

• 公開案件ベースの単価の目安は月60〜110万円前後。差がつくのは社内システム連携と権限設計の経験

• 次の一歩は、自分が毎日使っている社内ツールに読み取り専用で繋ぐサーバーを1本作ること

参照した一次情報は以下のとおりです。

• MCP公式仕様

• MCPサーバー構築ガイド（公式）

• 公式・コミュニティのMCPサーバー集（GitHub）

• MCP Inspector（GitHub）

• MCP公式レジストリ

• mcp（PyPI）