Python MCPサーバーの限界 — FastMCPとTypeScriptの実運用におけるギャップ

Maru

@maru

Python MCP 서버의 한계 — FastMCP와 TypeScript의 실운영 격차

Python MCPサーバーの限界 — FastMCPとTypeScriptの実運用におけるギャップ

モデルコンテキストプロトコル（MCP）のエコシステムは2,200%以上急成長し、AIエージェントとツールを接続する新しい標準として浮上しました。しかし、実際の市場統計を詳しく見ると、公開されているMCPサーバーの86%は依然として開発者のローカル環境に留まっています。

ローカル環境で設定なしに手軽に動作していた簡便さが、実際の実運用やマルチテナント環境へと移行する際には、深刻なセキュリティ上の攻撃対象領域や設計上の障壁へと豹変してしまうからです。このような矛盾した現象を「MCPのパラドックス」と呼びます。本稿では、最も広く利用されているPythonベースのFastMCPの設計上の限界を指摘し、なぜ実際の商用プロダクション環境ではTypeScriptベースのアーキテクチャや専用のセルフホスティングプラットフォームが代替案として浮上しているのかを詳しく見ていきます。

Pythonエコシステムの急浮上: FastMCPとfastapi-mcp

AnthropicがリリースしたFastMCPは、Python開発者がMCPサーバーを構築する際に直面する面倒なボイラープレートコードを完璧に排除してくれます。複雑なプロトコル仕様を直接扱う必要はなく、FastAPI環境で開発するように、デコレータパターンを数行記述するだけで、ローカルスクリプトや関数をAIエージェントに簡単に連携できます。

さらに、コミュニティライブラリであるfastapi-mcpは、既存のFastAPIエンドポイントをPydanticによるバリデーションとともにMCPツールへと自動変換して公開する賢いアプローチを取っています。これらのツールの登場により、開発者は複雑なインフラ設定に時間を浪費することなく、コア機能の開発に専念できるようになりました。

両エコシステムの代表的なツール登録方式をコードで比較してみると、それぞれが目指す設計上の違いがより明確になります。

python
# Python (FastMCP)
from fastmcp import FastMCP

mcp = FastMCP("My MCP Server")

@mcp.tool
def greet(name: str) -> str:
    """Greets a user by name."""
    return f"Hello, {name}!"

typescript
// TypeScript (SDK v1.0.0+ Modern API)
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { z } from "zod";

const server = new McpServer({
  name: "my-mcp-server",
  version: "1.0.0"
});

server.registerTool(
  "greet",
  {
    description: "Greets a user by name.",
    inputSchema: {
      name: z.string()
    }
  },
  async ({ name }) => ({
    content: [{ type: "text", text: `Hello, ${name}!` }]
  })
);

PythonのFastMCPは、関数自体のPython型ヒントとドキュメント文字列を自動的に解析してスキーマを構成する圧倒的な利便性を誇ります。一方、TypeScriptは現代的な McpServer クラスの下でZodスキーマを明示的に結合する構造をとります。この構造的な違いは、プロトタイピングを超えて大規模なプロダクション環境へ移行する際、コードの安定性と詳細な制御能力という観点から決定的な差を生み始めます。

コード品質と「スクリプトラッピング」の罠

容易かつ迅速なツール連携という利点の裏側には、実運用環境で解決すべきコード品質と安定性のギャップが潜んでいます。学術的なエージェント相互運用性プロトコルの調査レポートによると、JavaScriptやTypeScriptで記述されたMCPサーバーのコードスメルのメディアン（中央値）が2程度であるのに対し、Pythonの実装体は4程度と2倍も高く現れました。

このギャップは、多くのPython開発者が従来個人用に使っていたレガシースクリプトを、FastMCPデコレータで急いでラッピングしてツールとして配布するという、いわゆる「スクリプトラッピング」の慣行に起因しています。この過程で厳格な型バリデーションや体系的なエラーハンドリングが省略されることが多く、些細な例外状況でもAIエージェントが制御不能に陥ったり、誤作動したりするリスクが高まります。

緩やかな動的実行環境に起因するサプライチェーンのセキュリティ上の脅威も無視できません。代表的な例として、postgresのタイプミスを悪用したmcp-server-postgress タイポスクワッティングパッケージの配布事例のように、検証されていない外部ライブラリを動的に読み込んで実行するPythonのMCP環境は、深刻なセキュリティ事故の標的になりやすいのです。ローカルでのプロトタイプ段階を超えて、実際のサービスシステムにMCPを結合する際、開発者が最初に取り除くべき障壁です。

決定的なアーキテクチャの障壁: セッション状態とOAuthの分離

ローカルでの動作を超えてマルチテナントや企業向けのシステムにMCPを拡張する際、最大の障害はセッション状態と認証情報の同期です。Portal Oneのエンジニアリングブログの分析によると、標準入出力(stdio)ベースの独立したプロセスとして実行されるPython MCPサーバーは、メインのWebアプリケーションの基本ユーザーセッションやワークスペース権限に直接アクセスすることが困難です。ツール呼び出しのたびに認証トークンを引数として渡すといったその場しのぎの対応をしない限り、分散環境で精巧な権限制御を保証するのは困難な構造です。

一方、TypeScript MCP SDKは、このような分散セキュリティ環境を処理できる構造的なプリミティブを標準で提供しています。ツール実行コンテキストに内蔵されたauthInfo フィールドにより、呼び出したユーザーの認証コンテキストを即座に参照することができ、専用のProxyOAuthServer クラスを通じて外部のOAuthフローを安全に仲介します。非同期ループの中でこれらの複雑なセッション制御フレームワークをゼロから実装しなければならないPythonとは異なり、TypeScriptは大規模なプロダクション展開に必要な準備をあらかじめ終えていると言えます。

セルフホスティングプラットフォームの代替案: OpenshipのネイティブMCP

実運用環境で直接MCPサーバーを構築し、認証や権限を制御する作業が負担であれば、プラットフォームレベルでMCPをネイティブに統合した代替案を検討してみる価値があります。セルフホスティングプラットフォームであるOpenshipは、既存のCoolifyやDokkuのようなツールとは異なり、プラットフォーム自体にMCPサーバーを内蔵するというユニークなアーキテクチャを採用しました。開発者がセキュリティ上のリスクを冒してインフラ制御用MCPサーバーを直接デプロイする代わりに、プラットフォームが提供する検証済みのインターフェースを通じて安全にシステムを制御できるように迂回させたのです。

OpenshipはBunベースのCLIとOpenRestyを活用しており、ターゲットサーバーに別のエージェントを置かない軽量なアーキテクチャを目指しています。ビルドパイプラインで作成されたイミュータブル（不変）なDockerコンテナを対象サーバーへSSHストリーミングする方式を使用し、ターゲットインフラを単純に保ちます。

OpenshipのBunベースのCLIは、Node.jsがなくてもたった一行のコマンドでインストールし実行できます。

bash
# 오픈쉽 CLI 설치 및 개발 환경 실행
curl -fsSL https://get.openship.io | sh
openship up

サービスを開始するとローカルAPIサーバーとダッシュボードが有効になり、内蔵されたMCPサーバーはClaude CodeやCursorのようなAIツールがローカルAPIトークン認証を経て、プロジェクトのデプロイ、クラスターチェック、環境変数の変更、以前のデプロイへのロールバックまで直接実行できるよう安全に仲介します。

ちなみにOpenshipは最近ソースコードが公開されたAGPL-3.0およびCommons Clauseライセンスへ移行したため、商用SaaS形態での無断転売は不可能ですが、企業内部のセルフホスティングインフラであれば自由に活用できます。手動で複雑なセッションセキュリティやOAuth分離という壁を乗り越えるために苦労するより、このようにプラットフォームレベルでセキュリティゲートウェイの役割を肩代わりするネイティブMCPプラットフォームを導入するのも、実運用のセキュリティを維持するための効率的な折衷案です。

開発者への実践的提言

ローカル環境での簡潔さが実運用環境でのセキュリティ上の脅威へと豹変する「MCPのパラドックス」は、アーキテクチャ選定に重要な基準を提示します。ローカル中心の迅速なプロトタイピングや既存スクリプトの素早い移行には、PythonのFastMCPが素晴らしい出発点となります。しかし、セッション分離、マルチユーザー認証、厳格なサードパーティ権限管理が必須となる商用サービス構築段階であれば、TypeScriptベースのSDKを導入するか、インフラレベルで検証済みのゲートウェイを設計する構造が安定した選択肢となります。

参考リンク