AnthropicがベータでMCP Connectorを提供開始したが、Messages APIから直接MCPサーバを呼べる利便性の裏側に、運用上の落とし穴がいくつかある。本稿では実機検証で確認した「ツールリスト直列取得」「パブリックIP到達性」「tool_choiceの挙動」という3つのハマりどころを整理する。Connector導入を検討するチームが事前に押さえておくべき仕様面の癖だ。
ツールリスト取得は直列、サーバ3〜4台で初動2〜3秒の遅延
最初の感触として意外だったのは、Anthropic側がツールリストを取りに行く順番が、リクエストに書いた順そのままだったこと。並列で取得してくれると思い込んでいたら直列だった。
サーバが3〜4本になると、初動が2〜3秒重くなる。検証では2系統だったため許容できたが、社内の汎用Bot基盤のように常時5本以上のMCPサーバをぶら下げる用途では、ユーザー体感に影響が出るレベルだ。プロダクション運用で気になる場合は、Connector呼び出し前にツールリストのキャッシュ層を挟むのが現実的な対処になる。
ストリーミングレスポンスの場合、初動の遅延はそのまま最初のトークン到達までの時間に響く。「待たされ感」を嫌うインタラクティブUIに組み込むなら、最初に呼ぶMCPサーバを軽量なものに固定する設計上の工夫も効く。
パブリックIP到達性：社内VPN下のMCPサーバはつながらない
ここは仕様面の最大の落とし穴と言える。ConnectorはAnthropicのIPレンジからMCPサーバへインターネット経由でアクセスする。社内VPN内のみ到達可能なサーバは、当然ながらつながらない。
回避策は基本的に2つ。1つはMCPサーバを公開ホストに置き、認証を強める方向。2つ目はCloudflare Tunnelなどで穴をあけ、認証層を別に組むBYOC的な構成だ。
筆者個人としては、用途が「社内ツール参照」と割り切れるならVPN下に置きたい派だ。とはいえ今回はConnectorの恩恵を優先し、社内サーバを公開ホストへ移し、Anthropicの公開IPレンジのみを許可するACLに切り替えた。3年前にWebhookを公開ホストに移行したときと、心理的な判断としてはほぼ同じだった。
セキュリティ部門が絡むケースでは、AnthropicのIPレンジが将来変更される可能性も含めて、ACLの保守運用フローを事前に決めておくのが望ましい。
tool_choice は auto が安定、any / none だとレスポンス時間がブレる
Connector経由でツールを使うとき、tool_choice の挙動が地味に重要になる。試した結果、auto が体感ベストだった。
any や none を指定するとClaudeがツールを呼ぶ判断を歪ませる場面があり、Connectorのレスポンス時間が安定しない。具体的には、本来呼ばなくてよいツールに引きずられたり、逆に呼ぶべきツールを避けた結果、応答が長文化したりする。
auto のままにしておくと、Claudeが「呼ぶべきか」を毎ターン判断する。これがHaiku 4.5の判断速度と相性が良い。Sonnetだと判断にやや時間がかかり、Connector経由で得たレスポンス短縮の旨味がやや薄れる印象を受けた。インタラクティブ用途でConnectorを使うなら、Haiku系モデルとの組み合わせを第一候補に据えるのが現状の落としどころだ。
導入前にチェックすべき項目
これからConnectorを試すチームは、以下を事前に確認しておくと事故が減る。
- 接続予定のMCPサーバがパブリックIPから到達可能か。VPN下のみのサーバは公開ホスト化かトンネル化が必要
- 同時接続するMCPサーバの本数。3本を超えるなら初動遅延のキャッシュ対策を検討
- アプリ側で
tool_choiceを明示している場合はautoに揃え、モデル選定はHaiku系を起点に評価 - AnthropicのIPレンジを許可するACLの保守フロー
Connectorは利便性が高い一方で、Anthropic側に処理が寄る分、デバッグの主導権も部分的に渡る形になる。落とし穴を踏み抜く前に、上記の項目で自チームの構成と突き合わせておくと運用上の事故を避けやすい。
