X MCP公式サーバー完全解説｜できること全機能と、事業へ組み込むアイデア

こんにちは。仕様書を書かないPM@カイです。

「X MCP、エンジニアが何か新しいの入れてるらしい」——でも自分には関係ないかな、と後回しにしていませんか。

設定手順の記事は探せばいくらでも出てきます。

でも「で、これは自社の何に効くの？」に正面から答えた整理は意外に少ない。

公式ドキュメントを読み込み、X MCPで何が任せられるか・事業フローのどこに組み込めるかを、コードを書かない側の言葉で整理しました。

読み終えたら、エンジニアに要件レベルで依頼できる状態になるはずです。

MCP Servers - X

Connect Grok, Cursor, and other AI tools to the X API and X developer docs through hosted Model Context Protocol servers using xurl and docs search.

docs.x.com

X MCPとは何か：AIがXを直接操作できるようになった仕組み

X MCPは、X（旧Twitter）が公式に出したModel Context Protocolサーバーです。

Claude CodeやCursorのようなAIエージェントから、Xの投稿・検索・ユーザー情報取得を直接呼べるようになる接続口です。

これまで自前のスクリプトでX APIを叩く必要があったところに、AIへの自然言語の指示でアクセスできる経路が公式に用意されました。

事業側の言葉に直すと、「Xに関わる反復業務をAIへの指示に変換できるようになった」というのが本質です。

X MCPが登場した背景と、何が新しいのか

AIエージェントが普及する中で、各SaaSが「自社APIをAIに直接叩かせる窓口を出す」流れが2026年から加速しています。

Xはこれを公式機能として実装し、認証と権限管理を自社側で完結させたのが要点です。

「AIにX運用を任せたい」事業側の要望が、第三者ツールを挟まずに最短で実現できる構図になりました。

X MCPとDocs MCP、2種類のサーバーの違い

公式MCPは2系統あり、https://api.x.com/mcp がX APIの操作用、https://docs.x.com/mcp がドキュメント検索用です。

事業活用で使うのは前者ですが、AIに「Xで何ができるか」を自走して調べさせるためにDocs MCPも同時接続するのが普通です。

事業側として把握するのは「操作用」と「参照用」の2系統がある、という事実だけで十分です。

従来のX API連携との違い

これまでのX API連携は、エンジニアにスクリプトを書いてもらい、それをcronで回す、という形でした。

X MCPでは、その「スクリプトを書く」工程をAIが代行します。

「キャンペーン期間中、ハッシュタグ #xxx の投稿を集計して毎日Slackに流して」を自然言語の指示で実行できる、という構図です。

「エンジニアに頼むと数週間かかる」が、企画側の指示文ひとつで動き始める——そのイメージを持って次のセクションを読むと、各機能の見え方が変わります。

X MCPでできること一覧：機能カテゴリと業務への翻訳

公式ドキュメントが定義する機能は、6カテゴリに整理できます。

機能リストの軸ではなく、自社業務のどこに効くかで見ると価値が変わります。

投稿・全文検索・反応分析

投稿関連は「読み」と「書き」の両方に対応しています。

「読み」は、ある投稿に対する引用RTやいいね一覧の取得で、エゴサと反応分析の自動化に直結します。

担当者が毎朝手でやっていた「バズり確認」が、AIへの一言で完結するようになります。

「書き」は新規投稿・リプライが対応しています。

なお、引用RTは2026年4月以降Enterprise専用に変更されており、一般プランでは実行できません。

書き込み系はレート制限が厳しめで、ここは後ほど触れます。

ユーザー情報の取得とタイムライン解析

特定ユーザーのタイムラインを直近数十件まで取得できます。

競合企業の公式アカウントの直近投稿を毎朝AIに要約させ、トーン変化や新機能告知を検知する用途が組めます。

「あの会社、最近やたら『AI』って言ってない？」を、感覚ではなく頻度の数字で出せるようになります。

定期的な競合ウォッチをしているなら、ここだけで導入価値があります。

ブックマーク管理とフォルダ整理

ブックマークをフォルダ単位で操作できるのが、意外と効きます。

AIに「今週見たブックマークを業界別に振り分けて」と指示すれば、リサーチ素材の整理がほぼ自動化されます。

「後で読む」にしたまま埋もれていく情報を、AIが自動で整理してくれる。

リサーチ業務の比率が高い職種だと、ここだけで導入価値があると感じる人もいるはずです。

地域別トレンド・ニュース収集

トレンドは地域コード指定で取得でき、「東京の現在のトレンド」「アメリカ西海岸の今日のニュース」を狙って引けます。

海外展開しているプロダクトでは、現地のリアルタイム文脈をAIに渡して翻訳・要約まで一気通貫させられます。

英語が分からなくても、現地担当に頼まず一次情報に当たれるのが、グローバル展開している組織で効きます。

X Articlesの下書き作成と公開

長文投稿機能のX Articlesも操作対象です。

AIに「この記事のドラフトをX Articlesに下書き保存して」と頼めば、配信前の最終チェックだけ人間がやる運用が組めます。

下書きと公開を分けられるので、AIが投稿する内容を必ず人がレビューする運用にしておくと安全です。

X MCPの対応AIクライアントと認証・料金の全体像

「うちのチームのAIで動くか」と「いくらかかるか」、ここに答えます。

使えるAIクライアント（Claude Desktop・Cursor・VS Code・Grok Build）

公式ドキュメントに動作確認が明記されているのは、Claude Desktop、Cursor、VS Code（GitHub Copilot）、Grok Buildの4つです。

MCP対応のクライアントなら技術的には繋がるので、Claude Codeや社内で使っているAIツールがMCPに対応していれば追加準備はほぼ不要です。

開発側に「うちのAIクライアント、MCP対応してる？」と聞くのが最初の確認ポイントです。

確認さえとれれば、設定作業は開発側に丸ごと任せられます。

OAuth 2.0 PKCEで何を認証しているのか

認証はOAuth 2.0 PKCEがデフォルトです。

初回だけブラウザでXのログイン画面が出て、AIエージェントに「自分のXアカウントとして操作する権限」を渡します。

いわば「このAIに私のXアカウントの鍵を渡す」手続きが、最初の1回だけあるイメージです。

トークンはローカルに自動キャッシュ・自動更新されるので、毎回ログインし直す手間はありません。

事業側として押さえるのは「AIが操作するのは認可したアカウントの権限で、認可は最初の1回だけ」という1点で十分です。

X MCPの料金の考え方：従量課金で「どの操作にいくら」を把握する

X APIは2026年から従量課金が中心に移っており、X MCPで叩く操作もそのコストに乗ります。

書き込みと読み取りでレートが分かれていて、書き込みのほうが単価は高めです。

最新の単価はX Developer Portalで確認するのが確実で、月次の業務量に対する概算は「1日の読み書き回数 × Portalの単価」の掛け算で出せます。

最初は読み取り中心の使い方から始めると、コストを抑えながら効果を確かめられます。

X MCPをプロダクトと事業に組み込む活用シーン4選

「設定したけど、結局何に使うんだっけ」——そこが抜けると、せっかく入れたのに動かない状態になります。

企画側が明日から動ける粒度で4つ出します。

競合・市場調査（キーワード検索からトレンド把握まで自動化）

毎朝AIに「自社プロダクト名と競合3社の名前でXを検索し、新規言及の要約と感情傾向をSlackに投稿」と指示する運用が組めます。

担当者が30分かけてキーワード検索→転記→要約していた工程が、AIへの1回の指示で完結します。

「Xでの言及をマーケに渡すフロー」がすでにある組織は、最初に置き換える価値が高い領域です。

「今週競合がXで何を言っていたか」が、毎朝自動で届くようになります。

リリース告知とSNS運用の効率化

新機能リリース時の告知投稿を、AIにドラフトさせる用途です。

リリースノートをAIに渡し、「これをX用に280文字で5パターン書き分け、X Articlesに長文版も下書き保存して」と頼めば、初稿作成工程がスキップできます。

公開判断は人間が握る前提で、ドラフトと下書き保存までをAIに任せる線引きが現実的です。

リリースのたびにSNS文案で時間が消えていた、という組織にとって刺さるシーンです。

ユーザーの声・フィードバック収集

プロダクト名やハッシュタグでX全体を検索し、ユーザーの声をAIに分類・要約させる用途です。

「不満」「機能要望」「使い方の質問」「ポジティブな感想」のような分類軸を渡せば、毎週のフィードバックが整理された形でプロダクトチームに届きます。

人間は要約結果へのコメントと、深掘りすべき投稿の選別だけに時間を使えるようになります。

SNSのエゴサが「やらなきゃいけない作業」から「AIが整理した素材を見るだけ」に変わります。

「企画→AIに指示→X操作」の実務ワークフロー

事業側の関与の仕方を整理すると、次の3段です。

1. 企画側が「何を知りたいか」「何を発信したいか」をAIへの指示文に落とす
2. AIがX MCP経由でXに対して読み書きを実行する
3. 結果を人間がレビュー・承認する

企画側の役割は「指示文の品質」と「承認基準」の設計になります。

スクリプトを書く必要はないけれど、「何を集めるか」「公開していい線とNGの線をどう分けるか」を言語化する仕事は、企画側にしかできません。

この線引きの設計に入る前に、制約として知っておくべきことが3つあります。

X MCPを導入する前に押さえたい注意点

知っておきたい制約を3つに絞ります。

レート制限と書き込み操作の制約

書き込み系の操作は、読み取り系よりレート制限が厳しめです。

特に「投稿」「リプライ」を短時間に大量に叩くと、429エラー（レート制限超過）でブロックされます。

また、2026年2月以降のポリシー変更で、APIによるリプライは「元の投稿著者が自分をメンションまたは引用した場合」のみ可能になっています（自己サービスプラン全般）。

自由にリプライを撒ける状況ではなくなっています。

読み取り中心の使い方なら、レート制限にひっかかることはほぼありません。

「AIにX運用を完全自動化」より、「下書きと分析はAI、公開は人間」という線引きで運用したほうが安定します。

トークン・認証情報のセキュリティ運用

OAuthのトークンはローカルにキャッシュされるので、開発端末や運用サーバーのセキュリティ管理が前提になります。

企業アカウントで運用する場合、トークンが流出すれば第三者がそのアカウントで投稿できる状態になります。

「誰の端末で、どのアカウントを認可しているか」を運用チームで管理する仕組みは、最初に作っておきたいところです。

X APIポリシーと自動化の許容範囲

X APIの利用規約では、「Xユーザーになりすます投稿」「スパム的な大量自動投稿」「無断のデータ大量収集」は禁止されています。

技術的に叩ける範囲と、規約上やっていい範囲は別物だと割り切る必要があります。

特に「AIが完全自動で投稿する運用」は、規約と信用の両面で、慎重に設計すべき領域です。

まとめ：X MCPで「AIにXを任せる」を始める最小手順

明日から動ける最小手順を3つだけ。

1. 試す：開発側に「Claude CodeかCursorにX MCPを繋いで、検索だけ試してほしい」と依頼する。書き込みなしの読み取り限定なら、レート制限も規約もほぼ問題にならない
2. 設計：自社業務の中で「Xから情報を取って→人間が判断→Xに発信」のループになっている業務を1つ選び、AIに任せる範囲とレビュー基準を決める
3. 運用：書き込みは必ず「下書き保存→人間レビュー→人間公開」のフローで始める。完全自動化はチームが慣れてから

X MCPの本質は、API操作の自動化ではなく、「企画側がエンジニアを介さずにXを動かせるようになった」という組織への影響のほうです。

事業フローのどこに組み込むかを決めるのは、ずっと企画側の仕事のままです。

技術が降りてきたぶん、企画の言葉の解像度が問われるようになりました。