Sep 2, 202611 分 READ

リモートMCPサーバーとは?

Jacob Schmitt

シニア テクニカル コンテンツ マーケティング マネージャー

開発がエージェント型ワークフローへと移行するにつれ、AIエージェントの能力は、それがアクセスできるシステムの範囲によって決まります。ローカルMCPサーバーは、デスクトップのCLIやIDEエージェントがマシン上でマルチステップのタスクを実行できるようにします。一方、リモートMCPサーバー(ホスト型MCPサーバーとも呼ばれます)は、その範囲をクラウドベースやバックグラウンドで動作するエージェントにも広げます。これにより、Webブラウザ、CIランナー、バックエンドサービス上で動作するエージェントが、開発者のマシンでローカルの子プロセスを実行することなく、HTTP経由で外部ツールにアクセスできるようになります。

この記事では、MCPとは何か、サーバーが「リモート」(または「ホスト型」)であるとはどういうことか、リモートサーバーとローカルサーバーの違いとそれぞれを選ぶべき場面、そしてホスト型MCPサーバーを使ってAIエージェントをCircleCIに接続する方法について解説します。

MCPとは?

Model Context Protocolは、Anthropicが2024年後半に発表した、AIアプリケーションを外部のツールやデータに接続するためのオープンスタンダードです。共通のプラグのようなものだと考えてください。すべてのAIツールがGitHub、データベース、CIプロバイダーと話すための独自の方法を発明する代わりに、それらはすべてMCPを話します。

MCPは、エージェントにシステムへのアクセスを与える唯一の方法ではありません。専用のコマンドラインツールでも同じことができ、MCPサーバーとCLIのどちらを選ぶかは、それを操作するのが人間なのかエージェントなのかに大きく左右されます。この記事ではMCP、特にサーバーがどこで動作するかに焦点を当てます。

このプロトコルには2つの側面があります。

  • MCPクライアントは、IDEアシスタント、チャットインターフェース、自律エージェントなど、あなたが操作するAIアプリケーションです。
  • MCPサーバーは、あるシステムの前面に立ち、モデルがそこで何を許可されているかを提示します。

各サーバーは3種類の機能を公開します。ツール(「このビルドのログを取得する」のようにモデルが呼び出せるアクション)、リソース(モデルが読み取れるデータ)、プロンプト(サーバーが提供できる再利用可能なテンプレート)です。クライアントは接続時にこれらの機能を検出し、モデルに渡します。そのため、アシスタントは学習データからの推測ではなく、実際のデータに基づいて動作します。

重要なのは分離という考え方です。どのMCPクライアントも、どのブラウザもどのWebサイトを読み込めるのと同じように、どのMCPサーバーとも話すことができます。これが、ローカルかリモートかという問題を、書き直しではなくデプロイの選択にしている理由です。プロトコルは同一で、変わるのはパッケージングだけです。

MCPサーバーが「リモート」(または「ホスト型」)であるとはどういうことか?

その違いは1点に尽きます。サーバーがどこで動作し、クライアントがどのようにそこへアクセスするかです。

ローカルMCPサーバーは自分のマシン上で動作し、クライアントによって子プロセスとして起動され、両者は標準入出力(stdio)でやり取りします。リモート(ホスト型)MCPサーバーは、クライアントがHTTP経由で接続するホスト型サービスとして動作するため、特定の1台のマシンではなくネットワーク上に存在します。

「リモート」と「ホスト型」は、同じものを2つの視点から表しています。リモートはクライアント側の視点(サーバーはネットワークの向こう側、別の場所にある)であり、ホスト型は運用者側の視点(誰かがマネージドサービスとして運用している)です。この2つの用語は同じ意味で使われることがよくあります。

ローカルMCPサーバーとリモートMCPサーバーの違い

どちらのタイプのサーバーも同じプロトコルを話し、同じ方法でツールとリソースを公開します。変わるのは、サーバープロセスがどこで動作するか、どのAIクライアントがそれにアクセスできるか、そして認証がどのように管理されるかです。

項目 ローカルMCPサーバー リモート(ホスト型)MCPサーバー
動作場所 自分のマシン上で子プロセスとして ホスト型サービスまたはクラウドインフラ
トランスポート stdio(標準入出力) Streamable HTTP(POST + SSE)
セットアップ 開発者のラップトップごとにインストール・設定が必要 ローカルセットアップ不要 — URLで接続するだけ
認証 ローカルの環境変数 / ローカルのシークレット 一元化されたサインイン(通常OAuth 2.1)
更新 各ユーザーがローカルのバイナリ/パッケージを更新 運用者が1回更新すれば全員に即時反映
接続できるクライアント ローカルのIDEとターミナルCLI ブラウザベースのエージェントを含むあらゆるクライアント
データの経路 クライアント⇔MCPサーバー間はローカルに留まる(サーバー自体はクラウドAPIを呼び出す場合もある) クライアント⇔MCPサーバー間はHTTPS経由で通信
スケーリング 1プロセスにつき1ローカルユーザー 1つのデプロイでチーム全体をカバー
最適な用途 ローカルファイルへのアクセス、シェルスクリプト、個人のラップトップ上のツール ブラウザエージェント、インストール不要のチーム利用、組織全体での一元的なアクセス

どちらが常に優れているというわけではなく、正しい選択はクライアントとデプロイのニーズによって決まります。

エージェントがデスクトップ上(CursorやターミナルCLIなど)で動作し、ローカルのファイルシステム、ローカルの環境変数、あるいはマシンに紐づいたスクリプトへのアクセスが必要な場合は、ローカルサーバーを選びましょう。クライアントとMCPサーバー間のネットワークオーバーヘッドがゼロになり、ローカルタスクを完全にオフラインで利用できます。

チーム向けにインストール不要のソリューションが欲しい場合や、ローカルのstdioサブプロセスを起動できないブラウザベースのAIエージェントとの互換性が必要な場合は、リモート(ホスト型)サーバーを選びましょう。誰もが1つのHTTPS URLにアクセスするだけで済み、個人のトークンをラップトップごとに分散させることなくOAuthでアクセスを一元管理でき、接続しているすべての開発者に対して更新が即時に反映されます。

リモートMCPサーバーの内部動作

サーバーがラップトップの外に移動すると、3つのことが変わります。トランスポート、認証、そして状態の扱いです。これらを理解することが、リモートMCPの存在を知っているだけの状態と、実際にどれを選び、信頼して使うかを判断できる状態を分けます。

トランスポート: stdio vs. Streamable HTTP

ローカルサーバーはstdioを使用します。クライアントはJSON-RPCメッセージをサーバーの標準入力に書き込み、標準出力から応答を読み取ります。これはシンプルで高速ですが、クライアントがそもそもプロセスを起動できる場合にしか機能しません。

リモートサーバーは、プロトコルの現行のネットワーク接続用トランスポートであるStreamable HTTPを使用します。これは双方向を処理する単一のHTTPエンドポイントを公開します。クライアントはHTTP POSTでリクエストを送信し、サーバーは応答が段階的に届く場合はServer-Sent Events(SSE)を使って結果をストリーミングで返すことができます。これは、プロトコルが元々採用していた2エンドポイント方式のHTTP+SSEトランスポートに代わるもので、その方式は現在非推奨となっています。この単一エンドポイントの設計はステートレスに適しているため、リモートサーバーは標準的なロードバランサーやプロキシの背後に配置し、他のWebサービスと同様に水平スケーリングできます。

認証: ローカルのシークレットの代わりにOAuth

ローカルサーバーは、通常は環境変数に格納されたAPIトークンなど、マシンがすでに持っているアクセス権を継承します。これはインターネット経由でアクセスされる共有サービスにはそのまま適用できないため、リモートトランスポートではOAuth 2.1(PKCE必須)を標準としています。

このフローはおなじみのものです。クライアントはプロバイダーの認可サーバーへユーザーを誘導してサインインと同意を求め、認可サーバーがトークンを発行し、クライアントはその後すべてのリクエストでそのトークンをAuthorization: Bearer <token>ヘッダーとして送信します。サーバーはツールを実行する前にトークンを検証し、正しいスコープを持っているかを確認し、そうでない場合は標準の401または403エラーを返します。多くのサーバーはOAuthディスカバリーと動的クライアント登録もサポートしているため、クライアントは適切なエンドポイントを自動的に見つけて自身を登録できます。実際には、「接続する」をクリックしてサインインすれば完了であり、コピー&ペーストするトークンはありません。

状態とスケール

トランスポートがステートレス対応であり、アクセスがトークンごとに強制されるため、1つのホスト型デプロイで多数のユーザーを同時に処理し、1か所で更新できます。これが、リモートサーバーが共有システムに適している構造的な理由です。運用者は更新の配布や権限の絞り込みを1回行うだけで、各開発者がバイナリを再インストールする必要なく、接続しているすべてのクライアントに反映されます。

設定の違いを見る

この違いは、クライアントの設定にそのまま表れます。ローカルサーバーは実行するコマンドを指定し、リモートサーバーは接続先のURLを指定します。

{
  "mcpServers": {
    "local-example": {
      "command": "npx",
      "args": ["-y", "example-mcp-server"]
    },
    "remote-example": {
      "url": "https://mcp.example.com/mcp"
    }
  }
}

設定形式はクライアントによって異なりますが、パターンは同じです。コマンドが指定されていればサーバーはstdio経由でローカルで動作し、URLが指定されていればクライアントはHTTP経由でホスト型サーバーにアクセスします。

リモートMCP経由でエージェントをCircleCIに接続する

あなたのパイプラインは、ビルドがなぜ失敗したのか、どのテストが不安定なのか、直前のデプロイが成功したかどうかを、すでに把握しています。CircleCIは、そのビルドに関する知識をMCPに対応したあらゆるAIアプリケーションから利用できるようにするホスト型MCPサーバーを提供しています。これにより、開発者がビルドログを手動でプロンプトにコピーする必要なく、エージェントがパイプラインから直接答えを取得できます。

ホスト型サーバーはクラウド上でHTTPサービスとして動作するため、ローカルにインストールするものは何もありません。AIアプリケーションをエンドポイントに向けて設定し、OAuthで認証するだけです。Claude Codeのようなターミナル環境では、サーバーの追加はコマンド1つで完了します。

claude mcp add --transport http circleci https://mcp.circleci.com/v1/mcp -s user

MCP対応のアプリケーションであれば、同じURL(https://mcp.circleci.com/v1/mcp)を使って接続できます。サーバーはOAuth 2.1のディスカバリーと動的登録を自動的に処理し、CircleCIアカウントでのサインインを案内します。

接続が完了すると、エージェントは作業の途中で自律的にCircleCIのツールを呼び出し、次のような質問に答えることができます。

  • 「このブランチの最新のパイプラインが失敗した理由は?」

  • 「今週不安定だったテストはどれ?」

  • 「ジョブXの失敗ログを要約して。」

エージェントは対応するツールを実行し、CircleCIから直接ビルドログを取得して根本原因を分析します。これにより、パイプラインのトラブルシューティングが自動化された対話的なステップになります。

CircleCIエージェントインターフェースの選び方

ホスト型のリモートMCPサーバーは、CircleCIが提供する2つのエージェント向けインターフェースのうち1つです。AIワークフローがどこで動作するかに応じて、環境に最も適したアプローチを選べます。

  • CircleCIリモートMCPサーバー: ローカルへのインストールを一切行いたくない場合、OAuthによるアクセス管理を一元化したい場合、またはローカルの子プロセスを起動できないWeb・ブラウザベースのAIツールとの互換性が必要な場合に使用します。

  • CircleCI CLI(ローカルMCP & シェル): ローカルのターミナルやIDEでのワークフローに使用します。CLIは、マシン上でローカルのstdioMCPサーバーとして動作させることも、シェルベースのエージェント向けに予測可能な--json出力と安定した終了コードで直接ターミナルコマンドを実行させることもできます。CircleCI CLIについて詳しく見る

エージェントがWebブラウザ、IDE、ローカルターミナルのいずれで動作していても、まったく同じパイプラインデータとビルドコンテキストにアクセスできるため、単一の信頼できる情報源を犠牲にすることなく、チームに柔軟性をもたらします。

まとめ

MCPは、AIエージェントが既存のツールにアクセスするための標準的な方法を提供します。リモート(ホスト型)MCPサーバーは、その到達範囲をラップトップごとの設定ではなくチーム全体の機能にします。共有サービスとしてStreamable HTTP経由で動作し、OAuthで一元的に認証を行い、コマンドラインを持たないエージェントを含むあらゆるクライアントに対して開かれています。CI/CDのような共有システムにとって、これは自然な適合です。1回接続して一元的に認証すれば、すべての開発者のエージェントに同じ実際のデータを提供できます。

AIエージェントにパイプラインを見えるようにしたいですか?無料でCircleCIアカウントに登録して、クライアントをCircleCIのホスト型MCPサーバーに接続しましょう。

よくある質問

ローカルMCPサーバーとリモートMCPサーバーの違いは何ですか?

ローカルMCPサーバーは、あなた自身のマシン上でサブプロセスとして動作し、クライアントとはstdio経由でやり取りするため、すべてがデバイス内に留まります。リモート(ホスト型)MCPサーバーはネットワークサービスとして動作し、Streamable HTTPトランスポートを使ってHTTP経由でアクセスされる共有サービスです。1つのデプロイで多数のユーザーを一元的に認証でき、ローカルプロセスを起動できないクライアントからもアクセスできます。

「ホスト型MCPサーバー」と「リモートMCPサーバー」は同じものですか?

はい。この2つの用語は、同じものを異なる視点から表しています。「リモート」はクライアント側の視点(サーバーはネットワークの向こう側にある)であり、「ホスト型」は運用者側の視点(マネージドサービスとして運用されている)です。この2つは同じ意味で使われます。

MCPサーバーがローカルかリモートかはどうすれば分かりますか?

クライアントがどのように接続しているかを確認してください。設定がマシン上でコマンドを起動し、stdio経由でやり取りしている場合はローカルです。HTTP URLを指定してサインインを求めている場合はリモートです。

リモートMCPサーバーを使うためにコードを書く必要はありますか?

いいえ。MCP対応のクライアントにサーバーのURLを追加して認証すれば、そのツールがモデルで使えるようになります。MCPサーバーを書くことと、それを使うことは別のタスクです。

何もインストールせずにリモートMCPサーバーを使うことはできますか?

できます。これはホスト型モデルの大きな利点の1つです。URL経由で接続してサインインするだけなので、Web版のClaudeのようなブラウザベースのエージェントを含む、ローカルプロセスを起動できないクライアントでもリモートサーバーを利用できます。インストールが必要なバイナリはありません。

リモートMCPサーバーはローカルMCPサーバーよりも安全性が低いのですか?

本質的にそうとは限りません。リモートサーバーはOAuthを通じて認証と権限を一元管理するため、多数のラップトップに分散したシークレットよりも監査がしやすい場合があります。また、通信は転送中に暗号化されます。他のホスト型サービスと同様に、その認証モデルと要求されるアクセス範囲を確認してください。

1つのAIエージェントで、ローカルとリモートのMCPサーバーを同時に使うことはできますか?

できます。クライアントは複数のMCPサーバーに同時に接続でき、ローカルとリモートを組み合わせることも可能です。モデルはそれらすべてのツールをまとめて認識します。