リモートMCPサーバーをECSでたててみよう〜IaCを添えて〜

Last updated at 2025-05-17Posted at 2025-05-17

はじめに

こんにちは！ yu_Matsuです

最近 MCP（Model Context Protocol） が話題になっていますね！ GitHubやSlack、Google Driveなど、さまざまなサービスがMCPサーバーを提供しており、生成AIアプリケーションの開発により柔軟性が増してきました。

今回の記事では、このMCPを振り返るとともに、自分で実装する場合はどんな感じなのかについて見ていきます。また、実装したMCPサーバーを広く利用してもらうための方法の一つとして、AWS ECS（Elastic Container Service）上でサーバーをたててみたいと思います。

本記事の内容に関するサンプルコードをGitHubで公開していますので参考にしていただければと思います。また、記事タイトルにある通り、おまけとしてTerraformでのコード化のサンプルと解説もありますので、合わせてご覧ください。

MCP（Model Context Protocol）とは

MCPは、アプリケーションがLLM（大規模言語モデル）にコンテキスト情報を提供する方法を標準化するプロトコルであり、Claudeシリーズを開発したAnthropic社が提唱しました。（ここでいう「コンテキスト」とは、LLMが会話や情報を適切に理解し処理するために必要な背景情報のことです。）

現在の生成AIアプリケーションのメインストリームであるAIエージェントは、ユーザーの入力に対して最適解を得るために、思考と行動を繰り返します。この行動のフェーズで必要な情報をコンテキストとして取得するのですが、この処理は「ツール」として実装されることが多いです。
従来の生成AIアプリ開発では、このツールを、同じような処理を行うものであっても（例えばよく利用されるGmailやSlackなどを扱うツール）、その都度実装/連携する必要があったり、開発に利用されるフレームワークやプログラミング言語によって実装方法が異なるため、他者に提供しづらい、といった問題がありました。

しかし、MCPによりこのような問題が解決され、さまざまな生成AIアプリケーションが、コンテキスト情報取得のためのツールを共用できるようになりました。また、単なるプロトコルの提唱だけでなく、簡単にアプリケーションに組み込めるようにSDK（ソフトウェア開発キット） まで用意されているため、現在急速に普及しています。

MCPの基本構造としては、下図のような クライアント・サーバー・アークテクチャ に基づいていまして、以下の概念が存在します。

MCPホスト：Claude DesktopやGitHubCopliot、Clineなど、後述するMCPクライアントを内包した生成AIアプリケーション
MCPクライアント：MCPに則ってサーバーと接続、LLMの指示をサーバーに渡し、その処置結果を受け取る
MCPサーバー：MCPに則って、特定の機能を提供するプログラム

(https://modelcontextprotocol.io/introduction から引用)

MCPに関しては、以下の資料が非常に分かりやすくまとまっていますので、一度ご覧いただければと思います。

1. ローカルでMCPサーバーをたててみる

簡単なMCPサーバーの実装

MCP公式ドキュメントのQuickstartを実施して、簡単なMCPサーバーを構築してみましょう。

Quickstartをほぼ愚直に実施するだけですので、もう試されたことがある方は流し読みしていただいて大丈夫です！

また、GitHubのサンプルコードを実行しながら読み進められる場合は、mcp_serverディレクトリに移動して以下を実行してください

下記の手順を参考にuvのインストールと仮想環境のアクティベート
uv syncを実行

Pythonのパッケージ管理ツールであるuvを利用して、MCPサーバー用のプロジェクトを作成します。

# プロジェクトの作成
uv init mcp_server
cd mcp_server

# 仮想環境のアクティベート
uv venv
source .venv/bin/activate

# パッケージのインストール
uv add fastmcp httpx  # 「FastMCP」の v2 をインストールしている

# MCPサーバーを実装するファイルの作成
touch weather.py

Quickstartと異なる点は、MCPサーバー作成に利用する「FastMCP」に関して、v2 をインストールしているところです。FastMCPはMCPサーバーやMCPクライアントを実装しやすくなるSDKであり、v2はMCP公式のPython用SDKであるv1を拡張したものになります。詳しくは以下のドキュメントをご覧ください。

それでは、MCPサーバーを実際に実装していきます。（といっても、Quickstart通りですが...）

weather.py

from typing import Any
import httpx
from fastmcp import FastMCP

# Initialize FastMCP server
mcp = FastMCP("weather")

# Constants
NWS_API_BASE = "https://api.weather.gov"
USER_AGENT = "weather-app/1.0"

まずは必要なライブラリをインポートし、FastMCPクラスを初期化しています。このクラスにより、MCPサーバーのツール実装が容易になります。また、天気情報を取得する外部APIのURLの定数の定義もここでしています。

次に、MCPサーバーで提供するツール群の実装になります。機能としては以下の２つになります

get_alerts: 州名から、その州で発生している気象警報の情報を調べて返す
get_forecast: 緯度と経度から、そのエリアの気象予報を調べて返す

weather.py

async def make_nws_request(url: str) -> dict[str, Any] | None:
    """Make a request to the NWS API with proper error handling."""
    headers = {
        "User-Agent": USER_AGENT,
        "Accept": "application/geo+json"
    }
    async with httpx.AsyncClient() as client:
        try:
            response = await client.get(url, headers=headers, timeout=30.0)
            response.raise_for_status()
            return response.json()
        except Exception:
            return None

def format_alert(feature: dict) -> str:
    """Format an alert feature into a readable string."""
    props = feature["properties"]
    return f"""
Event: {props.get('event', 'Unknown')}
Area: {props.get('areaDesc', 'Unknown')}
Severity: {props.get('severity', 'Unknown')}
Description: {props.get('description', 'No description available')}
Instructions: {props.get('instruction', 'No specific instructions provided')}
"""

まずは、ヘルパー関数の実装になります。
make_nws_request は、APIのURLを受け取ってAPIを実行、そのレスポンスから必要な情報のみ取り出して返します。get_forecast、get_alerts共通で利用されます
format_alertは、気象警報情報を整形して返します。get_alertsでのみ利用されます

weather.py

@mcp.tool()
async def get_alerts(state: str) -> str:
    """Get weather alerts for a US state.

    Args:
        state: Two-letter US state code (e.g. CA, NY)
    """
    url = f"{NWS_API_BASE}/alerts/active/area/{state}"
    data = await make_nws_request(url)

    if not data or "features" not in data:
        return "Unable to fetch alerts or no alerts found."

    if not data["features"]:
        return "No active alerts for this state."

    alerts = [format_alert(feature) for feature in data["features"]]
    return "\n---\n".join(alerts)

@mcp.tool()
async def get_forecast(latitude: float, longitude: float) -> str:
    """Get weather forecast for a location.

    Args:
        latitude: Latitude of the location
        longitude: Longitude of the location
    """
    # First get the forecast grid endpoint
    points_url = f"{NWS_API_BASE}/points/{latitude},{longitude}"
    points_data = await make_nws_request(points_url)

    if not points_data:
        return "Unable to fetch forecast data for this location."

    # Get the forecast URL from the points response
    forecast_url = points_data["properties"]["forecast"]
    forecast_data = await make_nws_request(forecast_url)

    if not forecast_data:
        return "Unable to fetch detailed forecast."

    # Format the periods into a readable forecast
    periods = forecast_data["properties"]["periods"]
    forecasts = []
    for period in periods[:5]:  # Only show next 5 periods
        forecast = f"""
{period['name']}:
Temperature: {period['temperature']}°{period['temperatureUnit']}
Wind: {period['windSpeed']} {period['windDirection']}
Forecast: {period['detailedForecast']}
"""
        forecasts.append(forecast)

    return "\n---\n".join(forecasts)

次に、ツール群本体の実装です。
といっても、開発者が意識するのは関数の内容のみであり、普通に関数を実装すれば良いです。

get_alerts: 外部APIの気象警報情報を取得するためのURLを作成し、先ほどのmake_nws_requestに渡して実行することで、結果を取得します。そして、format_alertで整形し、返しています
get_forecast: 外部APIの気象予報を取得するためのURLを作成し、make_nws_requestに渡して実行します。レスポンスの中から直近5日分の情報を抽出して返しています

それぞれの関数に、コードの最初の方で生成したFastMCPインスタンスのデコレーターである、@mcp.tool() をつけることで、関数をツール化することができます。Pythonに慣れていれば、かなり直感的であることが分かるかと思います。

最後に、サーバーを起動する処理を記述することで、実装完了です！！

weather.py

if __name__ == "__main__":
    # Initialize and run the server
    mcp.run(transport='stdio')

mcp.runの引数として、transport='stdio' を指定していますが、こちらの詳細に関しては後述します。

Claude Desktopでの動作確認

それでは、動作確認をしてみましょう。
まずは、Quickstartに合わせてClaude Desktopで確認してみます。VSCodeがお手元にある場合は、以下のコマンドを実行して設定ファイルを開きます。

Macの場合になります

code ~/Library/Application\ Support/Claude/claude_desktop_config.json

Tips: Claude Desktopのアプリケーションからも設定ファイルを開くことができます。

Claude Desktopの「設定」を開きます
「開発者」タブを開き、「構成を編集」を押下するとファイルブラウザが開きます

開いたclaude_desktop_config.jsonに、以下の内容を記述します。もしすでに他のMCPサーバーの設定がある場合は、weather以下の内容を追加してください。これで設定完了です。

claude_desktop_config.json

{
    "mcpServers": {
        "weather": {
            "command": "uv（Mac/Linuxの場合はuvの絶対パス）",
            "args": [
                "--directory",
                "/ABSOLUTE/PATH/TO/PARENT/FOLDER/mcp_server",
                "run",
                "weather.py"
            ]
        }
    }
}

もしご自身で環境を作らず、GitHubのサンプルコードを実行する場合は、mcp_server/weather.py の L103 mcp.run(transport="stdio") をコメントインし、L104 mcp.run(transport="streamable-http", host="0.0.0.0", port=8000, log_level="debug")をコメントアウトしてください

では、Claude Desktopを開いてみましょう。
ユーザー入力欄の「+」ボタン隣のツールボタンを押下してみると、MCPサーバーが追加されていることが分かります。

ちゃんと get_alerts、get_forecast ともにツールが有効になっています！

Quickstartの入力例である、「What’s the weather in Sacramento?」を入力してみます。

Tips: 今回作成したMCPサーバーをClaude Desktopで動作確認をする際は、ツールの「ウェブ検索」をオフにすることをお勧めします。

ツールの外部連携使用許可に関するメッセージが表示されますが、とりあえず「常に許可する」にします。

エージェントが思考を始めました。MCPサーバーで提供している get_forecast をちゃんと利用してくれていることが分かります。

最終的な回答が返ってきました。サクラメントの気象予報を答えてくれていることが分かります！

ついでに、気象警報についてもQuickstartの入力例「What are the active weather alerts in Texas?」を入力してみます。

こちらも問題なく get_alerts を使ってくれています。

取得した情報を、format_alert で整形して返してくれていることが分かります。

GitHub Copilotでの動作確認

次はGitHub Copilotでも動作確認してみます。
VSCodeを開き、下記の記事を参考に、setting.jsonを開いてください。

setting.jsonに以下の内容を追記してください。

setting.json

{
    "mcp": {
        "servers": {
            "weather": {
                "command": "uv（Mac/Linuxの場合はuvの絶対パス）",
                "args": [
                    "--directory",
                    "/ABSOLUTE/PATH/TO/PARENT/FOLDER/mcp_server（絶対パス）",
                    "run",
                    "weather.py"
                ]
            }
        }
    }
}

すると、「weather」の上の方に「起動」と出てきますので、起動します。

「実行中」になれば、起動成功です

Tips: ここまでの流れを見てもらえれば分かると思いますが、Claude Desktop、Copliot等のMPCホストからMCPサーバーに接続する際は、ローカルであっても手元で先にuv run weather.pyなどでサーバーを起動しておく必要がありません。

しかし、後述するMCP InspectorやMCPクライアントから接続する場合は先にサーバーを起動しておく必要があることに注意しましょう。

Copilotのチャット画面を開くと、ユーザー入力部分にツールのマークが出ていますので、押下して確認してみましょう。MCPサーバーが追加されていることが分かります。

それでは、Claude Desktop と同様に、「What’s the weather in Sacramento?」と入力してみます。

Claude Desktopと同様に、MCPサーバーの get_forecast を利用して気象予報を取得して返していることが分かります。

MCP Inspector での動作確認

先ほどまで、Claude Desktop や GitHub Copilot などのMCPホストを利用して動作確認を行っていましたが、いきなりMCPホストに繋ぎ込みに行く前に、MCP Inspectorというツールを利用することで、簡単にローカルで動作確認できます。

Tips: 実際にMCPサーバーを開発する際は、まずはMCP Inspectorで動作確認してからMCPホスト、MCPクライアントに繋ぎ込みに行く方が良いでしょう。

まず、MCPサーバーの仮想環境に入っているコマンドプロンプト/ターミナルで以下のコマンドを実行し、MCPサーバーを起動します。

uv run weather.py

次に、別のコマンドプロンプト/ターミナルを開き、以下のコマンドを実行してInspectorを起動します。

npx -y @modelcontextprotocol/inspector

すると、InspectorのURLが実行ログに表示されますので、ブラウザでアクセスします。

左メニューでMCPサーバーの接続設定を行い、「Connect」を押下してサーバーに接続します。

Transport Type: STDIO
Command: uv (mac/linuxの場合でもフルパスでなくてOK)
Arguments: --directory /ABSOLUTE/PATH/TO/PARENT/FOLDER/mcp_server run weather.py (それぞれスペースで間を空ける)

接続に成功したら、以下のような画面になります。

「Tools」タブを開き、「List Tools」を実行して、get_alerts とget_forecast が表示されれば一先ず接続確認は完了ということになります。

2. Dockerでサーバーをたててみる

ローカルでサーバーを立てての動作確認は完了しましたが、ECSに載せるにはDockerイメージを作成する必要があります。ということで、次はDockerイメージの作成し、そこからサーバーをたててみましょう。

まずは、mcp_serverディレクトリの下に以下のDockerfileを作成します。

# Pythonのバージョンはお手元のものに合わせる
FROM python:3.11 

# Set working directory
WORKDIR /app

# Install system dependencies
RUN apt-get update && apt-get install -y --no-install-recommends \
    gcc \
    python3-dev \
    && rm -rf /var/lib/apt/lists/*

# Copy requirements first for better caching
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Copy the application code
COPY . .

# Set environment variables
ENV PYTHONUNBUFFERED=1

# Command to run the application
CMD ["python", "weather.py"]

イメージ作成時にインストールが必要なパッケージ一覧を期待した requirements.txt は以下のような内容で、同じくmcp_serverディレクトリ下に作成します。

requirements.txt

httpx>=0.28.1
fastmcp>=2.3.1

次に、Dockerイメージをビルドします。先にDocker Desktopを起動しておいてください。
以下のコマンドでをmcp_severディレクトリで実行してください。

docker build -t mcp-server .

問題なくビルドが完了したら、準備完了です！

MCP Inspectorでの動作確認

それでは、先に MCP Inspectorで動作確認してみましょう。ローカルでの起動確認時と同様に、MCP Inspectorを起動します。また、以下のコマンドで、Dockerイメージからサーバーを起動しておきます。

docker run -i --rm mcp-server

そして、MCPサーバーの接続設定として以下を入力して、サーバーに接続します。

Transport Type: STDIO
Command: docker
Arguments: run -i --rm mcp-server

接続に成功し、Toolsからツール一覧を取得できれば確認完了です。

確認が終わりましたら、起動しているサーバーを docker stop で停止しておきましょう。

Claude Desktop での動作確認

Claude Desktopでも確認しておきます。
ローカルの場合と同様に、設定ファイルを開いて以下のように編集します。

claude_desktop_config.json

"weather": {
    "command": "docker",
    "args": [
        "run",
        "-i",
        "--rm",
        "mcp-server"
    ]
}

設定の変更が完了したので、Claude Desktopを再起動してみます。ツールが利用できる状態であるので、MCPサーバーに接続できていることが分かります。

ではいつもの質問をしてみましょう。

ツールをちゃんと使ってくれていること、意図した回答が返ってきていることが分かります。
これで、DockerからのMPCサーバー起動の確認は完了です！

※ Copilotでの動作確認は省略します。設定ファイルに記載する内容はClaude Desktopと同様になりますので、ご自身で試してみてください。

3. ECSでリモートMCPサーバーを立ててみる

いよいよECSでのリモートMCPサーバーの構築に移ります！

まずは、現在のMCPサーバーのコードをリモート対応するために少し修正します。

weather.py

if __name__ == "__main__":
    # Initialize and run the server
-   mcp.run(transport="stdio")
+   mcp.run(transport="streamable-http", host="0.0.0.0", port=8000, log_level="debug")

MCPサーバー実行処理を記述している部分の transport の指定を streamable-http に変更します。また、コンテナ外からのアクセスを受け付けるためにhostを0.0.0.0にバインド、ポートを8000に指定しています。

GitHubのサンプルコードを実行しながら読み進めていただいている場合は、mcp_server/weather.py の L103 mcp.run(transport="stdio") をコメントアウトし、L104 mcp.run(transport="streamable-http", host="0.0.0.0", port=8000, log_level="debug")をコメントインしてください

MCPサーバーのトランスポートについて

ここで、トランスポートについて見ておきましょう。
トランスポートは、MCPサーバーとMCPホスト/クライアントで情報をやり取りするための方法で、Stdio（標準入出力）とStreamable HTTPの２種類あります。今まで、ローカルやDockerでMCPサーバーを起動する場合はトランスポートにstdioを、今回リモートMCPサーバーをたてる上でstreamable-httpを指定しました。

Stdioは「標準入出力」の名の通り、MCPサーバーをローカルホストで起動し、MCPホスト/クライアントも同じローカル環境から接続しにいくような場合に利用します。標準入力（stdin）と標準出力（stdout）を通じてデータがやり取りされます。

Streamable HTTPは、HTTPベースでMCPサーバーとホスト/クライアント間でデータのやり取りをする方式になります。リモートMCPサーバーのように、MCPホスト/クライアントがインターネット越しでMCPサーバーに接続する必要がる場合などに利用されます。
従来は HTTP + SSE(Server-Side Events) 方式が利用されていましたが、それを代替、補完する方式として普及しつつあります。現状のMCP界隈ではまだHTTP + SSE方式が主流ですが、今後Streamable HTTPに置き換わっていくとのことです。

Tips: Streamable HTTPについてはかなり奥が深いため、より詳しく知りたい方は以下の記事をご覧ください。

https://www.issoh.co.jp/tech/details/6580/#HTTPSSEStreamable_HTTP

AWSのリソースの作成

ECS自体がAWSのサービスの一つですが、その他にもいろいろ必要ですので、作成していきましょう。

まずは、ECSを配置するネットワーク周りです。記事スペースの都合上詳しい作成手順等は省略させていただきますが、以下のリソースを作成してください。（後述しますが、GitHubのTerraformのコードも参考にしていただければと思います。）

VPC
パブリックサブネット（2AZ分）
インターネットゲートウェイ
ルートテーブル
S3へのVPCエンドポイント
セキュリティグループ
- インバウンド、アウトバウンドともにすべてのトラフィックを許可

Tips: 上記に挙げたセキュリティグループ以外のリソースは、「VPCワークフローの作成」で一気に作成してくれるので、とても便利です。

本来はECSをプライベートサブネットに配置するべきですし、セキュリティグループもしっかり絞る必要がありますが、今回はお試しのため上記のようにしています。実際に広く提供するようなリモートMCPサーバーをたてる場合は、セキュリティ観点を踏まえた上でアーキテクチャを検討しましょう。

次に、Dockerイメージを管理するECR（Elastic Container Registory）のリソース作成です。
ECRのコンソールに移動し、「リポジトリを作成」を押下します。

リポジトリ作成画面に遷移するので、リポジトリ名にDockerイメージと同じ名前を入力します（今回は「mcp-server」）。また、イメージタグのミュータビリティは「Mutable」にしておきます。

イメージリポジトリの作成が完了したら、Dockerイメージをpushしていきます。「プッシュコマンドを表示」を押下すると、実行すべきコマンド一覧が表示されます。

今回は、Dockerイメージのビルドはもう出来ているので、実行するコマンドは 1、3 ~ 4になります。

一通り完了すると、リポジトリにイメージがpushされます。

次に、ECSでMCPサーバーをたてる工程です。
ECSのコンソール左メニューから「タスク定義」を開き、「新しいタスク定義の作成」を押下します。

タスク定義作成画面に遷移するので、タスク定義ファミリー名を指定します。

インフラストラクチャの要件を指定します。
起動タイプは「AWS Fargate」、オペレーティングシステム/アーキテクチャは、Dockerイメージをビルドした環境に合わせて選択します。（筆者の環境だと「Linux/ARM64」）

Tips: オペレーティングシステム/アーキテクチャに何を選べば良いかですが、お手元のコマンドプロンプト/ターミナルで、docker inspect <イメージ名> で調べることができます。このコマンドを実行すると、その結果の中に以下のようなOSとアーキテクチャの情報が含まれていますので、それらを参考に選択してください。

タスクロールとタスク実行ロールですが、今回は同じIAMロールを選択します。このロールは、ポリシーとしてマネージドのAmazonECSTaskExecutionRolePolicyのみを持つロールとなっており、タスク定義と並行して作成しておいてください。
（もし、AWSの他のサービスにアクセスするようなMCPサーバーをたてる場合は、タスク実行ロールは適切な権限を持つものを作成してください。）

最後に、コンテナの設定です。
コンテナイメージとして、先ほどpushしたイメージのURIを入力します。
また、ポートマッピングは下画像のように設定してください。

あとの設定はそのままで、タスク定義の作成は完了です。

次に、ECSクラスター/サービスの作成です。
コンソール左メニューの「クラスター」を開いて、「クラスターの作成」を押下します。
クラスターの作成画面に遷移するので、クラスター名とインフラストラクチャを下画像のように指定し、作成します。

クラスターの作成が完了したら、サービスの作成に移ります。クラスター画面の「サービス」タブの「作成」を押下します。

サービスの作成画面に遷移するので、下画像を参考に設定をしてください。ネットワーキングの項目は、作成したVPCやセキュリティグループを選択、パブリックIPは有効にします。

設定が完了したら、サービスを作成します。数分かかることがありますので、気長に待ちましょう。

サービスの作成が完了したら、タスクが一件起動開始しているかと思います。「タスク」タブから確認できます。（下画像は「タスク(2)」となっていますが、気にしないでください）

タスク名を押下すると、タスクの詳細画面が開きます。「前回のステータス」が「実行中」になっていれば正常起動完了です。「パブリックIP」はこの後MCPサーバーへの接続に利用しますので、控えておいてください。

「ログ」タブを開くと、サーバーログを確認することができます。このログはCloudWatch Logsに出されているものになりますので、ログ監視等も可能です。

MCP Inspectorでの動作確認

さて、無事にリモートMCPサーバーが起動しましたので、例の如くまずはMCP Inspectorでの動作確認を実施します。今までと同様にローカルでMCP Inspectorを立ち上げてブラウザで開きます。
左メニューで以下の接続設定をして、「Connect」を押下します。

Transport Type: Streamable HTTP
URL: http://ECSタスクのパブリックIP:8000/mcp/

問題なく接続できました！

「Tools」タブでツール一覧を取得してみます。

問題なく取得できていそうです！
ちなみにこの時点でECSタスクのログを確認すると、サーバーに ListToolsRequest が行われていることが分かります。

Claude Desktop / GitHub Copilotでの動作確認

次に、Claude Desktopでの動作確認をしてみましょう。

基本的には今までと同様に設定ファイルを変更すれば良いのですが、一点注意が必要で、Claude DesktopはリモートMCPサーバーを直接サポートしていません。（当記事執筆時点）ですので、ローカルプロキシを間に噛ませてあげる必要があります。
今回はmcp-remoteというローカルプロキシを使いたいと思いますので、以下のコマンドでインストールしてください。

npm install -g mcp-remote

インストールが完了しましたら、設定ファイルを開いて以下のように編集します。

claude_desktop_config.json

"weather": {
    "command": "mcp-remote（Mac/Linuxの場合はuvの絶対パス）",
    "args": [
        "http://ECSタスクのパブリックIP:8000/mcp/",
        "--allow-http"
    ]
}

では、Claude Desktopを再起動してみましょう。
以下のように、ツールアイコンを開いてツールが有効化されていれば、リモートMCPサーバーへの接続成功です！

試しにお馴染みの質問をしてみましょう。
今回は日本語で「サクラメントの天気を教えて！」と質問してみました。

ちゃんと動いていそうです！
タスクのログを確認しても、外部APIが呼び出されていることが確認できます。

無事にECSでリモートMCPサーバーをたてることができました！🎉

GitHub Copilotでも動作確認しておきます。CopilotはリモートMCPサーバーをサポートしているため、接続設定は以下のようにかなりシンプルになります。

setting.json

"weather": {
    "type": "http",
    "url": "http://ECSタスクのパブリックIP:8000/mcp/"
}

Claude Desktopと同じ質問をしてみましたが、ツールを利用して回答してくれていそうです！

LangChainで実装したMCPクライアントで動作確認

今までは、Claude DesktopやGitHub CopilotのようなMCPホストで動作確認をしていましたが、自前のアプリケーションに組み込んだエージェントから利用することを想定して、LangChainで実装したMCPクライアント（厳密にはMCPホストに近い気がしますが）でも動作確認してみたいと思います。LangChainは、LLMを活用したアプリケーション開発を効率化するためのフレームワークです。

mcp_serverディレクトリと同階層に、uv initで新しくmcp_clientというディレクトリを作成し、mcp_serverディレクトリの時と同じように仮想環境を作成してください。
※ 今までとは別のコマンドプロンプト/ターミナルを開いて作業してください。

GitHubのサンプルコードを実行しながら読み進めていただいている場合は、ここら辺の作業は必要ありませんが、別コマンドプロンプト/ターミナルでmcp_clientディレクトリを開き、仮想環境のアクティベートとuv syncを実行してください

今回はLangChain関連のパッケージが必要になるので、以下のコマンドで追加してください

uv add langchain-mcp-adapters langchain-aws langgraph boto3 streamlit

mcp_clientディレクトリ下にmain.pyを作成し、以下のようなコードを記述します。

main.py

import os
import asyncio
from langchain_mcp_adapters.client import MultiServerMCPClient
from langchain_aws import ChatBedrockConverse
from langgraph.prebuilt import create_react_agent
from dotenv import load_dotenv

load_dotenv()

async def call_agent(user_input):
    # Select the model
    model = ChatBedrockConverse(
        model="us.anthropic.claude-3-7-sonnet-20250219-v1:0"
    )

    async with MultiServerMCPClient(
        {
            "weather": {
                "url": os.environ['MCP_SERVER_ENDPOINT_HTTP'],
                "transport": "streamable_http",
            }
        }
    ) as client:
        # Create the agent with tools
        agent = create_react_agent(model, client.get_tools())
        
        # Simple invocation without callbacks
        response = await agent.ainvoke({"messages": user_input})

        return response
        
if __name__ == "__main__":
    user_input = input("Enter your input: ")
    response = asyncio.run(call_agent(user_input))

    for message in response["messages"]:
        print(message.content)

LangChain（厳密にはLangGraphですが）でエージェントを実装する一つの手段として、create_react_agentがあります。モデルのインスタンスと、エージェントが利用できるツール群を渡してあげることでエージェントを作成してくれます。

今回は、エージェントに渡すツールをMCPサーバーから取得できるように、MultiServerMCPClientを利用しています。コンフィグとしてMCPホストで設定するものと似たような記述をすることで、MCPサーバーに接続することができます。（マルチなので複数サーバーを設定可能）

MCPサーバーのURLは環境変数に外出ししているため、以下のような内容の.envファイルを作成してください。

.env

MCP_SERVER_ENDPOINT_HTTP=http://ECSタスクのパブリックIP:8000/mcp/

また、以下も併せて実行しておいてください。

バージニア北部リージョンのAmazon Bedrockのコンソールで、Anthropic系のモデルを有効化
お手元のAWS CLIのプロファイルに関してバージニア北部用のものを作成して切り替えるか、コマンドプロンプト/ターミナルで環境変数AWS_REGIONの値をus-east-1に変更

それではuv run main.pyで実行してみます。
同じく日本語で「サクラメントの天気を教えて」と入力してみたところ、緯度経度に変換してget_forecastを実行してくれています。

最終的な回答内容もバッチリでした！

ちなみに、記事スペースの都合上コードの掲載はしませんが、Streamlitで簡単なWebアプリケーション（main_gui.py）も作成していますので、気になる方はサンプルコードをご覧ください。

以下のコマンドで起動できます。

streamlit run main_gui.py

起動後、以下のような画面がブラウザで開くので、サイドバーでリモートMCPサーバーのURLを入力、使用したいモデルを選択してください。

あとは、質問を入力し、実行すればエージェントから回答が返ってくるようになっています。（雑なプログラムなので動作不良等あるかもしれませんが、ご了承ください）

このように、比較的簡単に、かつ直感的にMCPクライアントを作成し、システムに組み込むことが出来るということもお分かりいただけるかと思います！

今回はLangChainを利用しましたが、AWS公式からも Inline Agents SDK が提供されており、MCPサーバーに対応しています。Inline Agents SDKを利用した記事もいろいろ出ていますので、調べてみてください。

Tips: 本セクション冒頭にも述べた通り、セキュリティ観点を考慮していないアーキテクチャとなっているため、一通り動作確認が完了して必要がなくなった場合は、以下の手順でECSサービスを止めておくことを推奨します。

サービス一覧から「更新」を押下
「必要なタスク」を0にして更新する

※もし再起動したい場合は、逆に「必要なタスク」を1にして、「新しいデプロイの強制」にチェックを入れてサービスを更新してください

Next Action

とりあえず、ECSでリモートMCPサーバーをたてることは出来ましたが、今後のアクションとしてはどのようなことが考えられるでしょうか。

セキュリティ面の強化

前セクションで再三お伝えしている通り、今回は作成したものはあくまでハンズオンレベルになりますので、セキュリティ面が考慮されていません。もし実運用を考えるのであれば、最低限以下のような対応が必要になるかと思います。

ECSをプライベートサブネット内に配置する
MCPサーバーにhttpsで安全に通信できるように、ECSの前段にALB（Application Load Balancer） を設ける
- セキュリティグループを適切に設定することが併せて必要
MCPサーバーにOAuthなどの認証機構を導入し、ツールを保護する（こちらを参照）

CloudflareにMCPサーバーをデプロイする

自分でリモートMCPサーバーを環境から構築するとなると上記のようなこと配慮する必要がありますが、実はCloudflareにMCPサーバーをデプロイすることで簡単に実現できます。また、環境の維持コストやスケーラビリティなども担保されるので、Cloudflareを利用可能であれば非常に有益な手段であると言えます。

最後に

今回はMCPとは何だったのかを軽く振り返りつつ、簡易なMCPサーバーのたて方や、それをリモートサーバー化する方法例についての記事でした。

MCPは現在の生成AIシーンでは非常に重要な概念となっており、生成AIアプリケーションの進化をさらに一段階進めたのではないかと考えています。しかし、一見難しそうに見えて考え方はシンプルであり、SDKを利用することで非常に簡単にMCPサーバーをたてられることがお分かりいただけたかと思います。

提供されているMCPサーバーを利用するだけでなく、実際に自分で構築してみることで見えてくることも多々あるかと思いますので、しっかりMCPを使いこなしていきましょう！

本記事はこれで以上になります。ご高覧いただきありがとうございました！

Appendix： TerraformでIaCしてみる

もし本格的にリモートMCPサーバーを運用していくとなった際に、今回手動で作成したインフラリソース周りをコード化して管理しておく必要が出てくることもあるかと思います。

ですので、このセクションではTerraformでのコード管理（Infrastructure as Code = IaC）について簡単に触れておきます。

Terraformは、HashiCorp社で開発されているIaCツールであり、AWSやGCPなどのクラウドサービス上のインフラリソースをコードで定義し、コードに基づいたインフラ環境を自動構築することができる優れものです。

当記事のサンプルコードのterraformディレクトリ下で、今回手動で作成したリソース群のコードを作成していますので、興味がある方はご覧ください。本記事ではデプロイの仕方だけ掲載します。

まずは、Terraformのコマンドを実行するためにインストールしてください。バージョン管理を簡単にするために、tfenvでのインストールをお勧めします。

次に、terraformディレクトリに移動、以下のコマンドを実行してterraformの初期化を行います。

terraform init

AWS CLIのプロファイルや環境変数AWS_REGIONをバージニア北部リージョンに切り替えている方は、東京リージョン（ap-northeast-1）に戻しておいてください。

初期化が完了すると、以下のようなメッセージが出ます。

次に、以下のコマンドを実行し、コードからどのようなリソースが作成され得るか、を確認します。（dry-runのようなものになります）

teraform plan

成功すると、以下のように作成される予定のリソース一覧が表示されます。今回は新規作成のみなので緑色の「＋」ばかりですが、もしTerraformで管理している既存のリソースから変更がある場合は「〜」で表現されたり、削除されるリソースや設定があれば赤色の「-」で表現されます。

Terraformでどのリソースを管理しているかは、terraform planの実行後に自動的に作成される、terraform.tfstateをいうファイルに記載されます。次回以降のplanで変更箇所がある場合は、tfstateファイルと見比べて差分が検出される、という仕組みです。

作成予定の内容に問題がなければ、以下のコマンドでapply（デプロイ）していきます。

terraform apply

実行すると、一度planが実行され、本当にapplyしても良いかの確認が入りますので、「yes」と入力します。すると、applyが開始されます。

以下のようなメッセージが出たら、apply完了です！

これで、コードからリソースが作成されたわけですが、実はまだ終わりではありません。

まず、ECRのリポジトリは作成されたものの、イメージがpushされていませんので、リポジトリのpushコマンド一覧を参考に、イメージをpushしてください。（イメージをビルドする際、イメージ名はECRリポジトリ名を合わせた方が良いかもしれません）

あとは、ECSのサービス自体は作成されているのですが、タスクが起動していない状態です。これは、TerraformでECSサービスの定義をする際に、必要とするタスク数（desire_count）を0で設定したからです。（apply完了後にイメージがpushされていないので、自動でタスクを起動しても失敗する）

ですので、ECSサービスの設定を、「新しいデプロイの強制」にチェックを入れ、「必要なタスク」を「1」で更新してください。すると、タスクが起動します。

手動で作成した際と同様に、タスクの実行に成功したら完了です！

Terraformでのデプロイから動作確認まで完了しましたら、もし必要がなければ terraform ディレクトリ下でterraform destroyを実行すると、コード管理しているリソースが全て削除されます。実運用では禁じ手のコマンドですが、ハンズオン後の片付け作業などでは便利です。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

リモートMCPサーバーをECSでたててみよう 〜IaCを添えて〜

はじめに

MCP（Model Context Protocol）とは

1. ローカルでMCPサーバーをたててみる

簡単なMCPサーバーの実装

Claude Desktopでの動作確認

GitHub Copilotでの動作確認

MCP Inspector での動作確認

2. Dockerでサーバーをたててみる

MCP Inspectorでの動作確認

Claude Desktop での動作確認

3. ECSでリモートMCPサーバーを立ててみる

MCPサーバーのトランスポートについて

AWSのリソースの作成

MCP Inspectorでの動作確認

Claude Desktop / GitHub Copilotでの動作確認

LangChainで実装したMCPクライアントで動作確認

Next Action

セキュリティ面の強化

CloudflareにMCPサーバーをデプロイする

最後に

Appendix： TerraformでIaCしてみる

リモートMCPサーバーをECSでたててみよう〜IaCを添えて〜