AI エージェントに社内ツールや外部データを繋ぐ Model Context Protocol（MCP、エージェントとツール・データソースを標準規格で仲介する仕組み）を使い始めると、必ず「サーバーをどこで動かすか」という選択に直面します。Claude Code（Anthropic が提供するコーディング支援エージェント）から SEO データや監視データを取得するツールを繋ぐ場面を例に、Hosted HTTP と Local stdio という 2 つの接続方式を、SRE・インフラ運用の観点から整理します。
この判断は SEO ツールに限りません。監視 API、内部 CMDB（構成管理データベース）、社内のログ検索基盤など、Claude Code に「今の状態」を取りに行かせたい場面すべてで同じ選択が発生します。エージェントは与えられたコンテキストを推論できても、外部のライブデータには自力でアクセスできないためです。手作業でブラウザ検索の結果をコピペして渡す運用は、位置情報・言語・デバイス設定が毎回ぶれる、順位や URL が欠落する、同じ条件で再現できないといった問題を抱えます。MCP サーバーを正しく選んで繋ぐことが、この再現性の問題を解決する出発点になります。
Hosted HTTP と Local stdio は何が違うのか
Hosted HTTP は、MCP サーバーのプロセスが外部の事業者側で稼働し、Claude Code は HTTPS 経由でリモートのエンドポイントに接続する方式です。サーバーの起動・スケーリング・アップデートは提供元が担当します。
Local stdio は、手元のマシンでプログラムをプロセスとして起動し、標準入力・標準出力（stdin/stdout）を使ってプロトコルメッセージをやり取りする方式です。ローカルで動くのはあくまで MCP のプロセスであり、そのプロセスが裏側でどのデータソースに問い合わせているかは別問題という点に注意が必要です。「ローカル MCP だからデータも社内で完結している」とは限りません。ラッパーの先で外部 API を叩いていれば、結局リクエストは外に出ます。
この区別は SRE の視点で重要です。障害対応時に「どこで何が落ちたか」を切り分けるには、MCP の接続層（トランスポート）と、その先のデータソース（アップストリーム）を別レイヤーとして扱う必要があります。Hosted と Local を比較する際に、裏側の SERP（検索結果ページ）データ提供元が違うサーバー同士を比べてしまうと、差の原因がトランスポートなのかデータ収集方法なのか切り分けられなくなります。
判断軸
運用責任の所在
Hosted は障害発生時のログやエラー詳細がリモート側の運用に依存します。自分たちでプロセスを覗けないため、原因調査は相手のステータスページやサポート窓口に頼ることになります。Local stdio はローカルの標準エラー出力（stderr）とプロセスの状態を直接確認できるため、デバッグの自由度は高くなります。オンコール体制がどこまで自前で持てるかで、この負担の許容度が変わります。
バージョン固定と再現性
Hosted は提供元の都合でリモート側の実装が変わることがあり、ある日突然レスポンス形式が変化するリスクがあります。Local stdio はランタイム・パッケージ・コマンド・環境変数を含めてバージョンをピン留めできます。IaC（Terraform や Pulumi など、インフラをコードで定義・管理する仕組み）でインフラを固定管理している組織なら、MCP サーバーの起動設定もコード化して同じ再現性の思想を適用できます。
シークレットの露出範囲
Local のラッパー自体が保持する認証情報はローカルに留まりますが、そのラッパーが上流の API を呼ぶ際の通信は外部に出ます。Hosted は認証情報とリクエストがそのままリモートサービスに到達します。セキュリティ要件が厳しい環境では、どちらの方式でも「結局どこまでデータが外部に渡るか」を明文化しておく必要があります。
チーム間の一貫性
Hosted は 1 つのエンドポイントを共有するだけで済み、チーム全員が同じ設定にアクセスできます。Local stdio はメンバーごとに再現可能なインストール手順が必要になり、オンボーディングコストが上がります。逆に言えば、個人の検証作業やプロトタイピングでは Local の身軽さが有利です。
選択肢の比較
| 観点 | Hosted HTTP | Local stdio |
|---|---|---|
| サーバー運用 | 提供元が担当 | 開発者側のマシンで担当 |
| 接続 | リモート HTTPS エンドポイント | stdin/stdout 経由の子プロセス |
| 初期設定 | エンドポイントと認証情報 | ランタイム・パッケージ・コマンド・環境変数 |
| アップデート | リモート側で変わり得る | 既知バージョンにピン留め可能 |
| デバッグ | リモートログとエラー詳細に依存 | ローカル stderr とプロセス調査が可能 |
ケース別の推奨
複数チームで同じ SEO データや監視データを共有し、設定管理の手間を減らしたいなら Hosted を選びます。オンボーディングの速さと、エンドポイント 1 つで済む単純さが効いてきます。
再現性を厳密に担保したい検証や、監査対応でバージョンや実行環境を固定する必要があるなら Local stdio を選びます。IaC でインフラ全体を管理している組織なら、MCP サーバーの起動コマンドや依存パッケージのバージョンも同じリポジトリで宣言的に管理できます。
デバッグのしやすさを優先するなら Local stdio です。障害調査の初動で、リモートのサポート窓口の対応を待つより、手元の stderr を直接見られる方が SRE のオンコール対応には向いています。
チームでの認証情報の一元管理を優先し、各メンバーの手元環境の差異をなくしたいなら Hosted を選びます。ただし認証情報とリクエストがリモートに渡る点は、契約前にデータ取り扱いポリシーで確認しておく必要があります。
あえて見送るべき条件
Hosted と Local の裏側のデータソース（アップストリームの SERP プロバイダーなど）が異なる状態で、単純にトランスポートだけを比較して優劣を決めるのは避けるべきです。同じクエリ・同じ位置情報・同じ言語・同じデバイス設定・同じ出力契約で揃えない限り、観測される差がトランスポートによるものか、データ収集方法の違いによるものか判別できません。
また、セキュリティ要件やデータ主権の要件を確認しないまま Hosted を採用するのも避けるべきです。認証情報とクエリ内容がリモートサービスに到達する以上、社内の個人情報や機密情報を含むクエリを投げる前に、データ取り扱いのポリシーを確認しておく必要があります。
導入前に確認すること
MCP サーバーを Claude Code に繋ぐ前に、まず 1 件のクエリを固定して Hosted と Local の両方で実行し、レスポンスの構造・順位・URL・パラメータをそのまま記録する作業から始めるのが安全です。ベンチマーク数値を捏造せず、実際に観測した出力だけを比較材料にします。
判断軸としては、運用責任の所在、バージョン固定と再現性、シークレットの露出範囲、チーム間の一貫性の 4 つを、自分のチームのオンコール体制と照らし合わせて見直してみてください。
最後に、選んだ方式に関わらず、MCP サーバーの接続設定・バージョン・認証範囲は IaC やドキュメントとして残しておくと、後から障害対応や監査で振り返る際の助けになります。