X公式「Hosted MCP」が登場 ローカル構築なしでAIからXを動かせる

X(旧Twitter)が、公式の Hosted版 MCPサーバー を公開しました。エンドポイントは https://api.x.com/mcp。これに xurl mcp というローカルの軽量ブリッジ経由で接続すれば、Claude Desktop や Cursor、VS Code などのAIクライアントから、Xを自然言語で動かせるようになります。

ポイントは、ローカルにMCPサーバー本体を立てる必要がないことです(ただし、OAuthを扱うための軽量な xurl mcp ブリッジはローカルで起動します)。これまでX関連のMCPは、自前で立てるか、コミュニティ製のサーバーを使うか、4月に公開されたX公式のローカル版 xdevplatform/xmcp を自分のPCで動かすか、のいずれかでした。今回出てきたHosted版は、X側が本体をホスティングしてくれるので、アプリ作成と初回OAuth設定を済ませれば、以後は xurl mcp ブリッジを1コマンドで起動して使えるようになります。

「MCP」自体を一行で押さえると、Model Context Protocol(MCP)は Anthropic が提唱した、AIクライアントと外部サービスをつなぐ標準仕様で、Anthropic / OpenAI / Google / Microsoft / AWS など主要ベンダーが支持しています。Hosted版の登場は、X公式がこの標準に運用責任まで含めてコミットしたことを意味します。

この記事では、Hosted X MCP の中身、ローカル版との違い、認証や料金の前提、業務での使い分けまでを整理します。

Hosted X MCP とは ホスト型の公式エンドポイントが登場

Hosted X MCP は、X が自社で運用する公式の MCP サーバーです。エンドポイントは https://api.x.com/mcp(プロトコル 2025-06-18)。詳細は X公式ドキュメントに整理されています。

これまでX関連のMCPサーバーを使う場合、利用者側がローカルにサーバーを立てる必要がありました。Python環境を用意し、依存ライブラリをインストールし、.env に認証情報を設定し、python server.py でプロセスを起動する。Pythonに触れる人が社内にいれば半日で済みますが、そうでなければ最初の一歩としては重い。Hosted版が出たことで、この MCPサーバー本体をローカルで動かす工程が消えます(後述の認証用ブリッジは別途ローカルで動かしますが、本体ほどの重さはありません)。

利用者がやるのは、後述する xurl mcp という軽量ブリッジを起動して、Claude Desktop / Cursor / VS Code などのMCPクライアント側にそれを参照させること。本体の運用・更新は X 側が見てくれます。これまでコミュニティ製サーバーで「メンテナーが消えたら詰む」のような不安があった部分も、本家ホスティングなら見通しが立ちやすい。

同時にあるローカル版「xmcp」との違い

ここで、4月にX公式が公開していた ローカル版 との違いを整理します。両方ともX公式が出しているMCPサーバーですが、配置と運用が違います。

項目	ローカル版(xdevplatform/xmcp)	Hosted版(api.x.com/mcp)
動作場所	自分のPC(127.0.0.1:8000で起動)	X 側のサーバー
必要な環境	Python 3.9+、FastMCP、依存関係インストール	xurl ブリッジ(npx 1コマンド)
認証	OAuth 1.0a / OAuth 2.0 / Bearer	OAuth 2.0 PKCE / App-only Bearer
カスタマイズ性	tools の選定や allowlist を細かく制御可	X が提供する範囲を利用
運用負荷	自分で更新・保守する	X が運用
向く用途	細かい制御、社内サーバーへの組み込み	軽く試す、運用負荷を下げる

どちらも X 公式から出ているので、安心感はほぼ同じ。違うのは「どこまで自分で持つか」です。エンタープライズの統合や、ツール選定を細かくチューニングしたい場合はローカル版、まずは触ってみたい・社内にPython環境がない、という場合はHosted版、という棲み分けになります。

xurl mcp ブリッジが間に入る仕組み

Hosted版を使うときに少しだけ意識しておきたいのが、xurl mcp という軽量ブリッジが間に入る、という構造です。

「Hosted」と言っても、AIクライアント(Claude Desktop など)が直接 api.x.com/mcp を叩くわけではありません。間に挟まる xurl mcp ブリッジが、OAuth 2.0 PKCE フローで認証を処理し、トークンの自動更新まで面倒を見てくれます。AI側に X API のキーを直接渡さずに済む、というセキュリティ設計です。

起動は、初回設定を済ませてしまえば npm 経由の1コマンドです。

npx @xdevplatform/xurl mcp https://api.x.com/mcp

ただし、最初の1回は X Developer Console でのアプリ作成、OAuth 2.0 の有効化、redirect URI の登録、CLIENT_ID / CLIENT_SECRET の設定、初回ブラウザログインの一連の手順が必要です。ここを通したあとは、上記の1コマンドでローカルにブリッジが立ち上がり、Claude Desktop / Cursor / VS Code(GitHub Copilot Agent mode)/ Grok Build などのMCP対応クライアントの設定で、このローカルブリッジを参照させれば、Xを自然言語で操作できる状態になります。

ヘッドレス環境(GUIなしで動かしたいサーバー上など)では、xurl auth oauth2 --headless で事前認証する形にも対応しています。

何ができるか Capabilities at a glance

X公式ドキュメントの「Capabilities at a glance」で示されている、Hosted X MCP の機能カテゴリを整理します。

カテゴリ	主な機能
Posts	投稿の取得、いいね・リツイート・引用者の確認
Search	全文検索、ユーザー検索、ニュース検索
Users	ユーザー解決(ID / ハンドル)、タイムライン取得
Bookmarks	リスト表示・追加・削除、フォルダ管理
News & Trends	ニュース取得、トレンド取得
Articles	ドラフト作成・公開

たとえば Claude Desktop から「先週の自社名を含むポストを集計して、好意的・否定的・中立で分類してまとめて」と頼めば、内部で Search を呼んで結果を分類して返す、という流れになります。「業界の主要キーワードのトレンドを毎週月曜に取得して、社内Slackに要約を送って」というような、定点観測+他ツール連携も、Claude Code から組めます。

なお、DM やリスト管理、コミュニティノート関連の操作は、現時点の Hosted MCP の「Capabilities at a glance」には明示されていません。これらをAIから動かしたい場合は、API側で個別に権限を確認したうえで、必要に応じてローカル版や自前実装を組み合わせる、という選択肢になります。

認証・料金・前提条件

業務で使い始める前の前提を、4つ。

前提1: 認証は OAuth 2.0 が中心

推奨は OAuth 2.0 ユーザーコンテキスト(xurl ブリッジが PKCE フローで処理)。読み取りだけで十分なら App-only Bearer トークンでヘッダー経由の直接接続も可能ですが、その場合はユーザーコンテキストを持たない読み取り専用になります。

前提2: Production 環境への移行が必要

Hosted X MCP を使うには、X Developer Platform のアプリが Production 環境 に上がっている必要があります。Development のままだと制限がかかるので、業務利用に向けてアップグレードしておくのが先です。

前提3: 料金は X API の Pay-Per-Use 従量課金

現在のX APIは Pay-Per-Use(従量課金)が中心です。サブスクリプション契約をせず、使った分だけ、事前に購入したクレジットから差し引かれる仕組みです。Basic/Pro などの旧プランや Enterprise 契約の扱いは、契約状況やアカウントの種類によって異なるため、業務利用前に X Developer Console で自分のアカウントの体系を確認してください。

前提4: 書き込みは厳しめのレート制限

X 公式ドキュメントは「書き込み操作は読み取りより厳しいレート制限の対象」と明記しています。429 エラーが出たらバックオフ(間隔を空けて再試行)する設計が前提です。

中小企業はどう使い分けるか + 業務ユースケース

ローカル版と Hosted 版、どちらを選ぶか。中小企業の場合の現実的な使い分けは、こうなります。

• Hosted 版が向く: 軽く試したい、社内に Python 環境がない、Hosting の運用負荷を下げたい、最初の一歩を素早く踏み出したい
• ローカル版が向く: tools の選定を細かく制御したい(X_API_TOOL_ALLOWLIST で公開する tools を絞る等)、社内サーバーで動かしたい、エンタープライズ統合の文脈

中小企業の現場では、最初の一歩は Hosted 版が現実的だと思います。Pythonサーバーを立てる工程が消えるだけで、試せる人の幅がだいぶ広がる。慣れてきて「もっと細かく制御したい」となったら、ローカル版に乗り換える順序が自然です。

業務ユースケースは、たとえば次のようなものが現実的です。

• SNS運用の支援: 自社名・業界キーワードへの反応やトレンドを取得し、AI側で投稿案を作る。実際の投稿は人間が行うか、利用可能な書き込みtoolを確認したうえで段階的に開けていく運用にする
• リサーチ: ニュース・トレンドの定点観測、関連ポストの要約
• 顧客対応の補助: 自社メンションの収集、リプライ下書き(送信は人間が承認)
• ブックマーク整理: 関連ポストのフォルダ仕分けを自動化、後でまとめて読む仕組み
• Articles の下書き: 取得した情報を元にドラフトをAIに書かせ、公開だけ人が判断

私たち自身、社内のSNS運用に Claude Code 経由でAI補助を入れていますが、最終確認は必ず人間が通す運用にしています。AIが返してきた案を10秒で目視チェックして送る、というワークフローを崩さない。これが事故率を下げる最低ラインです。

試す前のガードレール + さいごに MCP標準化の本気度

Hosted X MCP を業務に組み込む前に、最低限整えておきたいガードレールを5つ挙げておきます。

• テストアカウントで先に試す: 本番のブランドアカウントにいきなり繋がない
• 投稿・削除系は最初は無効にする: 検索・取得系から始め、投稿系は人間承認付きで段階的に開ける(ローカル版なら X_API_TOOL_ALLOWLIST で明示的に絞れる。Hosted版でも AIへの指示文で明示)
• 投稿前の人間レビューを必須に: 自動投稿(レビューなし)はブランド毀損リスクが大きい
• API利用上限とコスト監視: Pay-Per-Use は設計次第で予想を超える金額になり得る。月次のリミットとアラートを最初に設定
• 操作ログ・投稿履歴の証跡: AI が何を取得・投稿したかをログとして残す。事故時の追跡と社内説明のために必須

X 公式 Hosted MCP が出てきたことは、単に「便利な接続方法が増えた」という話を超えて、X が MCP 標準の運用責任までコミットしたシグナルです。14本目Microsoft Copilot Coworkが示した「業務に住み着くAI」も、13本目/loopで扱った「AIに継続的に仕事を任せる設計」も、その下では MCP が共通言語になりつつあります。各社サービスが公式 MCP を運用責任付きで出す動きが続けば、AIから見える「触れる業務」は加速度的に増えていきます。

中小企業として今やれるのは、「自社で使っているサービスに公式MCPがあるか」を時々チェックし、出てきたものから順に、小さく試していくこと。ガードレールを整えたうえで、最初の1業務を選んで小さく試す。これが、MCP時代に乗り遅れない素直な始め方です。