X API MCPをAIエージェントに渡す前に決めること：投稿権限・コスト・人間承認

3行まとめ

このテーマをもう少し広げて見るなら、MCP Registryからサーバーを選ぶ前に：OAuth・tool poisoning・allowlistの安全な見方 と LangGraphとMastraで承認付きワークフローを設計する：状態保存・再実行・人間承認の比較 も合わせて確認してください。X API MCPを導入する前に、MCP serverの選び方とallowlistの見方を確認できます。

Read-only

検索や取得から始め、query、件数、保存先を限定します。

Dry-run

投稿案やpayloadを作らせても、X APIへのwriteは実行しません。

Human approval

投稿、返信、削除、フォローは人間承認へ戻します。

Budget stop

rate limit、credits、予算上限を停止条件にします。

接続できることより、AIに見せるtoolと止める条件を先に決めます。

• X公式のAgent Resourcesとxdevplatform/xmcpにより、X APIをAIエージェント向けのMCP toolとして扱う入口は見えています。ただし、最初に設計すべきなのは自動投稿ではなく、AIに見せるtool、OAuth scope、予算、承認ログです。
• 初期値はread-only、tool allowlist、dry-run、人間承認、budget stopにします。投稿、返信、削除、フォロー、DMなどのwrite操作は、承認なしに実行させない前提で設計します。
• 2026年6月1日時点で、X公式docs、Developer Policy、XMCP GitHub repository、公開OpenAPI specを確認しました。X/Twitterの個別投稿は需要シグナルの確認対象にしましたが、公開ページから直近72時間の確実な確認ができなかったため、本文の事実根拠には使いません。

AIエージェントにX APIをつなぐと、検索、投稿案作成、返信候補の作成、利用状況の確認などをワークフロー化できます。一方で、X APIは公開アカウント、第三者への返信、課金、rate limit、Developer Policy、OAuth tokenをまとめて扱います。MCP化した瞬間に便利になるのではなく、権限境界を間違えると、誤投稿、想定外のAPI消費、ポリシー違反、token漏洩の入口にもなります。

ここでは、XMCPの細かな起動手順よりも、AIエージェントへX APIを渡す前の設計判断に絞ります。MCPの基本概念を先に確認したい場合は、MCPとは何か：Tools・Resources・Promptsと権限設計を開発者向けに整理するを入口にしてください。

この記事でわかること

Tool分類

read-only、dry-run、write、high-risk writeへ分けます。

OAuth scope

許可するtoolから必要scopeを逆算します。

Cost

tool call、pagination、retryに上限を置きます。

Approval

本文だけでなく対象、scope、cost、policy flagを確認します。

Policy

Developer Policyを実装条件として扱います。

読後のゴールは、自社のX API操作を承認表へ落とせる状態です。

• X公式Agent ResourcesとXMCPをどう読むか
• X API操作をread-only、dry-run、write、high-risk writeへ分ける考え方
• OAuth scopeとrefresh tokenをAIエージェント運用でどう扱うか
• X APIのpay-per-usage、credits、Rate Limitsをどう停止条件へ落とすか
• 投稿前の人間承認で、本文以外に何を見せるべきか
• X Developer GuidelinesとDeveloper Policyを実装条件へ落とす方法
• XMCPをPoCする時に、OpenAPI由来toolを全部見せない理由
• 導入前、運用中、権限拡張時のチェックリスト

読者として想定しているのは、Xの検索や投稿支援をAIエージェントに組み込みたいWebエンジニア、MCP Serverを社内ツール化したい開発基盤担当、企業アカウント運用にAIを入れる前のレビュー担当です。

この記事は「AIでX運用を自動化しよう」という記事ではありません。実務で必要なのは、AIの判断範囲を小さくし、write操作を承認へ戻し、API利用量とpolicy違反の兆候で止めることです。

前提知識

1. 1AI Agent

   自然言語の依頼からtool call候補を作ります。

2. 2MCP Host

   tool呼び出しと人間承認の入口になります。

3. 3XMCP Server

   OpenAPI由来のoperationをtoolとして公開します。

4. 4OAuth token

   実行できるアカウント権限を決めます。

5. 5X API

   公開投稿、取得、課金、rate limitに接続します。

MCPは接続形式であり、安全性はscope、allowlist、承認、ログ、予算で作ります。

X公式docsには、AIエージェント向けの入口としてAgent Resourcesが用意されています。そこでは、llms.txt、skill.md、Docs MCP、XMCP、OpenAPI specが案内されており、AIツールがX APIのドキュメントを読み、X API endpointをtoolとして扱う導線が示されています。

XMCPは、X APIのOpenAPI specをFastMCP serverとして公開するrepositoryです。READMEでは、OpenAPI specをtoolとして公開すること、streamingやwebhook系endpointは除外されること、X_API_TOOL_ALLOWLISTでtoolを絞れることが説明されています。XMCPを使う時の中心は、「接続できるか」より「どのoperationをAIに見せるか」です。

MCP toolにするとはどういうことか

MCPでいうToolsは、モデルが呼び出し得る操作です。検索や取得のようなread-only操作もあれば、投稿、削除、フォロー、DM送信のように外部状態を変える操作もあります。MCPになったから安全になるわけではありません。安全性は、Host側の承認、Server側のallowlist、OAuth scope、実行環境、監査ログ、予算上限で作ります。

X APIの場合、toolの向こう側には公開アカウントと課金があります。検索queryを広げすぎるとAPI消費が増えます。write操作を誤ると、公開投稿や第三者への返信として外部に残ります。OAuth tokenを広く持たせると、tool allowlistを間違えた時の影響範囲も広がります。

需要シグナルと事実根拠を分ける

今回の実行では、指定されたXアカウントの公開ページから直近72時間の投稿を安定して確認できませんでした。X上ではMCP、Codex、Claude Code、agent権限設計への関心が継続して見えますが、この記事では個別投稿の主張や反応数を本文の根拠にしません。

事実確認には、X公式docs、X Developer Policy、xdevplatform/xmcp、公開OpenAPI spec、ローカル取得ログを使います。市場の関心と実装判断の根拠は分けて扱います。

結果: 初期値はread-only、dry-run、承認付きwrite

項目	内容	見方
read-only		投稿検索、ユーザーlookup、rate limit確認は限定条件つきで許可候補にします。
dry-run		投稿案、返信案、実行予定payloadの作成までに止めます。
write		投稿、返信、削除、フォローは人間承認を必須にします。
high-risk write		大量返信、DM、複数アカウント操作、権限変更は初期導入で禁止または個別審査にします。

read-onlyでも検索条件、取得結果、保存先、ログ、再利用目的を確認します。

2026年6月1日に公開OpenAPI specを取得したところ、info.versionは2.164、HTTP operationは163件、GET以外のoperationは66件でした。この数は、tool生成方法やXMCP側のfilterによって変わり得ます。だから、AIエージェントに「X APIが使えるMCP server」を丸ごと渡すのではなく、導入時点でtool一覧を保存し、承認表へ落とします。

実アカウント操作は検証しない線引きにする

確認に使ったローカル検証は次の範囲です。

node -e 'const res=await fetch("https://api.x.com/2/openapi.json"); const spec=await res.json(); console.log(spec.info.version);'
node -e 'const res=await fetch("https://docs.x.com/llms.txt"); console.log(res.status);'
git ls-remote https://github.com/xdevplatform/xmcp.git HEAD

この検証では、X APIの実アカウント操作、OAuth token取得、投稿、返信、DM、削除、フォロー操作は行っていません。記事に必要なのは、実投稿の成功ではなく、AIに見せるtoolが多すぎること、非GET操作が存在すること、allowlistと承認が必要になることの確認です。

操作を4段階に分ける

X APIをMCP toolとして渡す前に、操作を次の4段階へ分けます。

分類	例	初期判断
read-only	投稿検索、ユーザーlookup、rate limit確認	限定query、件数上限、ログ設計つきで許可候補
dry-run	投稿案、返信案、検索条件、実行予定payloadの作成	API writeなしで許可候補
write	投稿、返信、削除、フォロー、ミュート、ブロック、リスト操作	人間承認必須
high-risk write	大量返信、DM送信、複数アカウント操作、削除、権限変更	初期導入では禁止または個別審査

評価基準

read-onlyは、外部状態を変えないからといって無条件に安全ではありません。検索条件、取得結果、保存先、ログ、再利用目的を確認できる場合だけ許可候補にします。

dry-runは、AIに文章やpayloadを作らせる段階です。X APIへwriteしないためPoCに向いていますが、投稿案に社内情報や個人情報が混ざる可能性があります。レビュー画面に出す前にredactionとpolicy checkを入れます。

writeは、原則として人間承認へ戻します。承認者が見るべきなのは投稿本文だけではありません。対象アカウント、返信先、引用元、media、URL、tool名、operation id、必要scope、予算上限、policy flagまで確認できる形にします。

X公式Agent ResourcesとXMCPで何が見えたか

1. 1Agent Resources

   AIツール向けのdocs、llms.txt、skill.mdが案内されています。

2. 2Docs MCP

   X APIの情報探索をAIツールから行う入口です。

3. 3XMCP

   OpenAPI spec由来のoperationをMCP toolとして扱います。

4. 4Tool allowlist

   AIに見せるoperationを必要最小限に絞ります。

5. 5Approval boundary

   write操作、予算超過、policy疑いを人間確認へ戻します。

公式に接続導線があることと、write権限を自動実行させてよいことは別です。

X Agent Resourcesは、AIツール向けにX APIを読ませる、使わせる、接続させる導線を整理しています。llms.txtとllms-full.txtはドキュメント探索用、skill.mdはエージェント向けの能力説明、Docs MCPはドキュメント検索、XMCPはX API操作をMCP toolとして扱う入口です。

これは、AIエージェントからX APIを扱う流れが公式情報として整理されつつある点で重要です。ただし、公式入口があることと、実務でwrite権限をAIへ渡してよいことは別です。

公式入口と実行許可を分ける

X公式docsにAI向け導線があることは、仕様確認の入口としては心強いです。一方で、AIエージェントへ渡す権限は自分たちのAPI app、OAuth scope、MCP host、承認UI、監査ログで決まります。公式情報を確認したら、次に見るべきなのは「使えるか」ではなく「どこまで見せるか」です。

判断条件

Docs MCPやllms.txtは調査補助として扱いやすい一方、XMCPのようにAPI操作へ近い入口は別扱いにします。read-onlyの調査、dry-runの下書き、writeの実行を同じ承認レベルに置かないことが、最初の分岐です。

XMCPはOpenAPI由来toolの束として見る

XMCPのREADMEでは、X API OpenAPI specをFastMCP serverとしてtools化する構成が説明されています。さらに、tool filteringとしてX_API_TOOL_ALLOWLISTが用意されています。この一点は実務上重要です。

OpenAPI specからtoolが作られる場合、便利なread系toolだけでなく、外部状態を変えるoperationも候補に入ります。XMCPのREADMEはstreamingやwebhook系endpointの除外にも触れていますが、それでもwrite系operationをどう見せるかは利用側の設計問題として残ります。

確認項目

PoC前に、最低でも次を確認します。

• 実際に生成されるtool名の一覧
• GET以外のoperationの一覧
• X_API_TOOL_ALLOWLISTで許可するtool
• OAuth tokenが持つscope
• debug出力でtokenやauthorization headerが出ない設定
• tool呼び出しのログ形式
• 429や課金上限に到達した時の停止条件

「MCP serverが提供しているから使える」ではなく、「AIに見せてよいtoolだけを明示的に見せる」へ発想を変えます。

OAuth scopeとtoken保管を最小化する

項目	内容	見方
読む		read系scopeだけで足りるか確認します。
下書き		投稿案作成はX API write scopeを要求しない構成にします。
投稿する		write系scopeは承認付きtoolに限定します。
長期運用		offline.accessとrefresh tokenは別レビューにします。
保管		token、authorization header、debug outputをログへ出しません。

tool allowlistとOAuth scopeは、片方だけでなく二重の境界として設計します。

X APIをAIエージェントへ渡す時、MCP serverが保持するtokenは実質的なアカウント権限です。自然言語で「投稿しないで」と書いていても、tokenとtoolが投稿可能なら、設計上は投稿できる状態です。

XのOAuth 2.0 Authorization Code with PKCE docsでは、fine-grained scopesが説明されています。たとえばtweet.read、tweet.write、users.read、offline.accessなどです。access tokenは標準では短時間で失効し、offline.accessを使うとrefresh tokenが発行される説明もあります。

scopeはtoolから逆算する

scopeは「X APIを使うために広く取る」のではなく、許可するtoolから逆算します。

やりたいこと	tool分類	scope設計の考え方
投稿やユーザー情報を読む	read-only	read系scopeだけで足りるか確認する
投稿案を作る	dry-run	X API write scopeを要求しない構成にする
投稿する	write	tweet.write相当のscopeを承認付きで扱う
長期運用する	recurring	offline.accessの必要性と保管設計を別レビューにする

注意点

refresh tokenは長期権限です。PoCで便利だからといって、MCP serverの環境変数、debug log、issue本文、チャット履歴に出してはいけません。XMCPのREADMEにはtokenやauthorization headerを出力するdebug系flagが見えますが、本番運用では無効化し、レビュー対象にします。

tokenとtool allowlistを別々に信用しない

tokenとtool allowlistは、どちらか片方だけでは十分ではありません。tokenのscopeが広い場合、allowlistのミスで危険なtoolが見えるかもしれません。allowlistが正しくても、tokenが漏れればscopeの範囲で悪用されます。scopeとallowlistは、二重の境界として設計します。

確認項目

権限レビューでは、MCP hostに表示されるtool一覧、XMCPのallowlist、OAuth consent画面、tokenのscope、debug出力、secret保管場所を別々に確認します。どれか1つが安全に見えても、他の境界が広ければ実行時の影響は広がります。

コストとRate Limitsを設計に入れる

1. 1Tool call候補

   実行予定のendpoint、件数、paginationを出します。

2. 2Cost見積もり

   credits消費とrun単位の上限を確認します。

3. 3Rate limit確認

   per-endpoint、per-user、per-appの残数とreset時刻を見ます。

4. 4Retry制限

   429後の再試行回数と停止条件を決めます。

5. 5Stop/alert

   予算超過、credits不足、usage急増は要レビューにします。

予算上限やrate limit到達は通常完了ではなく、停止して原因を確認します。

X API v2は、Usage and Billing docsでpay-per-usage、credits、app-level usage tracking、budget controlsが説明されています。具体的な価格や最新の上限はDeveloper Consoleや公式docsで再確認すべきですが、AIエージェント運用では「呼び出し前に止める」設計が必要です。

AIエージェントは、人間よりも速く、広く、繰り返しtoolを呼びます。曖昧な依頼から広い検索queryを作り、paginationを伸ばし、429でretryし、複数回の再試行を重ねることがあります。rate limitと課金は、運用後の請求確認ではなく、tool設計の一部にします。

Rate Limitsはretry設計とセットで見る

X API Rate Limits docsでは、per-endpoint、per-user、per-appの制限と、429時の扱いが説明されています。レスポンスheaderには、上限、残数、reset時刻を示す情報が含まれます。

停止条件

AIエージェントにX APIを渡すなら、少なくとも次を決めます。

• 1 runあたりの最大tool call数
• 1日あたりの検索回数
• 1回の検索で許す最大件数
• paginationの最大深さ
• 429後のretry回数
• credits不足時の停止条件
• budget上限到達時の通知先
• write操作の1日上限

429が返った時に「待って再試行」を無限に続ける設計は避けます。reset時刻を確認し、再試行回数を決め、一定回数で人間レビューへ戻します。

予算超過時は完了扱いにしない

AIエージェントが「調査できませんでした」と返すだけならまだよいですが、credits不足やbudget上限に当たった状態を通常完了扱いにすると、読者や運用担当は原因を見落とします。

実務では、予算超過、rate limit到達、usage急増、想定外tool要求を、未完了または要レビューとして扱います。X APIの利用量はapp単位で追えるため、run idやtool call logと紐づけて、どの依頼が消費したのかを追えるようにします。

人間承認は投稿直前だけでは足りない

項目	内容	見方
対象アカウント		どのアカウントで実行するかを確認します。
operation/tool名		投稿、返信、削除、フォローなどの操作を確認します。
対象ID		返信先、削除対象、フォロー対象を確認します。
payload		本文、URL、media、metadataを固定して確認します。
scope/cost/policy		必要権限、追加消費、policy flagを同時に見ます。
audit log		run id、approval id、payload hash、response idを残します。

承認後にpayloadを再生成せず、承認時と実行時の内容を照合します。

人間承認というと、投稿ボタンの直前で本文を確認する画面を想像しがちです。しかし、AIエージェントにX APIを渡す場合、承認すべき対象は本文だけではありません。

承認画面に必要なのは、次の情報です。

承認対象	見る理由
対象アカウント	どのアカウントで実行するかを誤らないため
operation/tool名	投稿、返信、削除、フォローなどの操作を確認するため
対象ID	返信先、削除対象、フォロー対象を確認するため
payload	投稿本文、URL、media、metadataを確認するため
OAuth scope	実行に必要な権限が広すぎないか見るため
cost見積もり	追加のAPI消費が許容範囲か見るため
policy flag	AI返信、同一文面、opt-out、spam疑いを確認するため

AI-generated repliesは事前承認の扱いを明確にする

X Developer Guidelinesでは、AI生成の返信に関して事前承認が必要な場面が示されています。自動返信やAI生成返信は、便利なサポート機能に見えても、第三者へ直接届く公開コミュニケーションです。

評価基準

AI返信を扱うなら、次を満たすまでwrite toolにしません。

• ユーザーが先に関与したケースだけを扱う
• 返信先と文脈を人間が確認する
• 返信本文を固定してから実行する
• opt-outを処理できる
• 自動化アカウントの表示や運用責任を確認する
• policy疑いで停止する

「AIが良い返信だと判断したから投稿する」ではなく、「AIは候補を作る。公開操作は承認されたpayloadだけ実行する」にします。

承認ログは監査できる形で残す

承認ログには、単に「承認済み」とだけ残しても意味が薄いです。後から追えるように、run id、approval id、tool name、operation id、payload hash、approved by、approved at、policy flags、X API response id、error、rollback noteを残します。

特に、承認時に見たpayloadと実行時payloadがずれないようにします。承認後にLLMへ再生成させると、承認者が見た内容と実行内容が変わる可能性があります。承認対象は固定し、実行直前にhashを照合する設計が現実的です。

Developer Policy違反を設計で避ける

項目	内容	見方
spam/manipulation		類似文面の連続投稿や大量返信をallowlist、rate上限、policy checkで止めます。
unsolicited contact		自動DMや無関係なmention返信はwrite tool禁止や承認条件で止めます。
AI replies		AI生成返信は事前承認と文脈確認を必須にします。
labeling/透明性		自動化アカウントの表示や運用責任を確認します。
data handling		保存期間、削除対応、利用目的、再配布を管理します。
credential handling		tokenをログ、repo、issue、チャット履歴に出しません。

X API MCPでは、official API、scope、rate limit、billing、policyの範囲内で設計します。

X Developer GuidelinesとDeveloper Policyは、記事末尾の注意書きではなく設計条件です。AIエージェントで扱う場合、特に次の領域を先に止めます。

リスク	起きる場面	止める場所
spam/manipulation	類似文面の連続投稿、大量返信、トレンド便乗	tool allowlist、rate上限、policy check
unsolicited contact	自動DM、無関係なmention返信	write tool禁止、承認条件
AI replies	AI生成返信の自動実行	事前承認、policy review
labeling/透明性	botや自動化の表示不足	運用前チェック
data handling	Xデータの長期保存、再配布、別目的利用	保存期間、削除対応、利用目的管理
credential handling	tokenをログやrepoに出す	secret管理、redaction、debug禁止

official APIだけを前提にする

この記事では、XのWeb UIを自動操作する手順や、スクレイピング、制限回避、非公式手段は扱いません。X Developer Guidelinesでも、official APIを使うこと、非APIの自動化やスクレイピングを避けることが示されています。

X API MCPの記事で、ブラウザ操作やログイン済みセッション操作へ話を広げると、MCPの権限設計ではなく別の攻撃面を増やします。X APIを使うなら、X APIのscope、rate limit、billing、policyの中で設計します。

data handling restrictionsをログと保存に反映する

read-only検索でも、取得したXデータをどこに保存し、誰が見られ、どれくらい保持し、何に再利用するかを決める必要があります。AIエージェントの会話履歴、MCP server log、アプリケーションlog、監査logに同じデータが散らばることもあります。

取得データをモデル学習、再配布、別目的利用へ流さない設計にし、削除要求や利用停止時の扱いも確認します。これはセキュリティだけでなく、X Developer Policy上のリスク管理です。

失敗点

全部見せる

OpenAPI由来toolを丸ごと渡し、write操作まで候補に入ります。

read-only過信

検索query、取得結果、保存先、ログのリスクを見落とします。

本文だけ承認

返信先、media、scope、cost、policy flagが見えません。

retry任せ

429やbudget不足をAIが再試行し続ける可能性があります。

復旧条件は、allowlist、保存設計、承認画面、停止条件を明文化することです。

このテーマで失敗しやすいのは、XMCPを「便利なMCP server」として入れてから、あとで権限を考える順番です。実務では逆です。最初にtool一覧、scope、budget、承認、policy、ログを決め、最後に接続します。

失敗1: OpenAPI由来toolを全部見せる

OpenAPI specからtoolを作ると、想定以上のoperationが候補になります。検索だけをしたかったのに、投稿、削除、DM、follow系のtoolが見えている状態は避けます。

復旧条件

XMCPを使う場合は、X_API_TOOL_ALLOWLISTで必要最小限のtoolだけを許可します。allowlist変更はPull Requestや設定レビューの対象にし、変更理由、承認者、影響範囲を残します。

失敗2: read-onlyなら安全だと思い込む

read-onlyでも、検索queryに顧客名や社内事情が含まれることがあります。取得結果をログに残せば、別の場所で再配布や長期保存の問題が起きます。

復旧条件

検索query、取得件数、保存先、ログ、表示先をセットでレビューします。PoCでは取得結果を保存しない、または短期保持にするなど、最初から消す設計にします。

失敗3: 投稿本文だけ承認する

投稿本文だけを承認しても、返信先、引用元、media、URL、対象アカウント、tool名、scope、policy flagが見えていなければ、承認として弱いです。

復旧条件

承認画面では「何を投稿するか」だけでなく、「どのAPI操作で、どの対象へ、どのアカウントから、どの上限内で実行するか」を見せます。

失敗4: costと429をエージェント任せにする

AIエージェントは、失敗すると自分でretryしようとします。429やbudget不足を通常のエラーとして扱うと、無駄な再試行や中途半端な完了報告が起きます。

復旧条件

429、credits不足、budget上限、想定外のusage増加は、エージェントの自己判断ではなく停止条件にします。再開には人間承認を必要にします。

実務で使うなら

1. 1. 公式情報確認

   X公式docs、Developer Policy、Security docsを読みます。

2. 2. tool一覧確認

   OpenAPI specとXMCPのtool一覧を確認します。

3. 3. read-only allowlist

   必要なread-only toolだけを許可します。

4. 4. scope最小化

   OAuth scopeをread-onlyに合わせます。

5. 5. dry-run

   投稿案や返信案だけを作り、X API writeを実行しません。

6. 6. 承認付きwrite

   検証用アカウント、限定scope、限定tool、限定予算で個別に試します。

権限を広げる判断は、失敗ログ、却下ログ、cost、policy確認を見て行います。

最初のPoCは、X APIのwrite操作を外したread-onlyから始めます。投稿支援をしたい場合でも、AIにやらせるのは「投稿案を作る」「policy疑いを指摘する」「承認画面に出すpayloadを整える」までです。

導入前チェックリスト

項目	初期値	広げる条件
Tool	read-onlyだけ	allowlist、承認、ログが揃ったらdry-runへ
OAuth scope	必要最小限	tool単位の理由が説明できる時だけ追加
refresh token	使わない	長期運用、保管、失効、監査が決まった時だけ
Write	禁止	承認UI、payload固定、policy check後に限定許可
Cost	低い上限	usage logで想定内と確認できたら段階的に拡張
Logs	token非表示	redaction test後に運用ログへ接続
Policy	事前レビュー	運用ルールと停止条件が揃ったら本番検討

PoCの順番

1. X公式docs、Developer Policy、Security docsを読む。
2. OpenAPI specとXMCPのtool一覧を確認する。
3. allowlistをread-only toolだけで作る。
4. OAuth scopeをread-onlyに合わせる。
5. API消費とrate limitを小さい上限で記録する。
6. dry-runで投稿案や返信案だけを作る。
7. 承認画面にtool名、payload、scope、cost、policy flagを出す。
8. writeは検証用アカウント、限定scope、限定tool、限定予算で個別に試す。
9. 失敗ログと却下ログを見て、権限を広げるか判断する。

既存のAIエージェントに外部通信を許可する設計は、Codexにインターネットアクセスを許可する前に：web search・allowlist・MCP外部通信の分け方も近いです。X APIに限らず、domain、HTTP method、MCP tool、secret、監査ログを分ける観点は共通します。

セキュリティ・コスト注意

Secret

API key、token、authorization codeをログやrepoに出しません。

Scope

必要最小限の権限にし、debug flagを本番で無効にします。

Cost

検索件数、retry、pagination、run単位の上限を実行前に決めます。

Transparency

自動化アカウントの表示、bio、opt-out、運用責任を確認します。

Redaction

記事、チケット、Slack、issueへ貼る前に検証ログを伏せます。

token漏洩、policy違反、API消費は、同じ監査ログと停止条件で追える形にします。

X API MCPは、securityとcostを別々に考えると抜けが出ます。広いread権限はデータ取り扱いリスクを増やし、広いwrite権限は公開アカウントの操作リスクを増やし、広い検索やretryはAPI消費を増やします。

秘密情報をログに出さない

X Security docsでは、API keysやtokensをclient-side code、logs、repositoriesに出さないこと、環境変数や安全な設定で扱うこと、必要最小限の権限にすることが説明されています。MCP serverでは、stdout、stderr、debug log、error report、agent transcriptにtokenが混ざりやすくなります。

確認項目

• .envやsecret managerに置いたtokenがログへ出ないか
• OAuth callbackやauthorization codeを保存していないか
• refresh tokenを暗号化またはsecret managerで扱っているか
• debug flagが本番で無効か
• エラー時のpayloadにtokenやauthorization headerが入らないか
• 記事、チケット、Slack、issueに検証ログを貼る前にredactionしているか

コストは実行前に見積もる

Usage and Billing docsでは、credits、app-level usage tracking、budget controlsが説明されています。AIエージェント側でも、実行前に見積もりと上限を持ちます。

「この調査は最大何件まで読むか」「何回retryするか」「同じ投稿を再取得した場合の扱いはどうなるか」「このrunで予算上限に近づいたらどう止めるか」を、tool設計へ入れます。

自動化アカウントの透明性を確認する

Developer Guidelinesでは、automated accountsのlabel、bioでの開示、人間が管理するアカウントとの関連、opt-outなどが説明されています。AIエージェントを使う場合も、運用主体が曖昧な自動化にしないことが重要です。

FAQ

自動投稿できますか

技術的可能性と、承認なしに初期値へ置くべきでないことを分けます。

read-onlyなら安全ですか

検索条件、取得結果、保存先、ログ、再利用目的にリスクがあります。

offline.accessは使えますか

長期運用では必要でも、保管、失効、ローテーション、監査を先に決めます。

コスト超過を防げますか

budget controlsに加えて、tool call数、pagination、retry、1日上限を持ちます。

MCPなら安全ですか

MCPは接続形式であり、安全性は別の設計で作ります。

迷ったら、AIの判断範囲を小さくし、人間レビューへ戻せるかを見ます。

X APIをAIに渡せば自動投稿できますか

技術的にはwrite系operationをMCP toolとして扱える可能性があります。ただし、実務では承認なしの自動投稿を初期値にすべきではありません。まず投稿案のdry-run、policy check、人間承認、監査ログから始めます。

read-onlyだけなら安全ですか

安全とは言い切れません。検索query、取得結果、保存先、ログ、再利用目的にリスクがあります。read-onlyは最初の検証範囲としては扱いやすいですが、データ分類と保存方針は必要です。

OAuthのoffline.accessは使ってよいですか

長期運用では必要になる場面があります。ただしrefresh tokenは長期権限なので、短いPoCでは避けるのが無難です。使う場合は、保管、失効、ローテーション、監査、利用者単位の分離を先に決めます。

コスト超過をどう防ぎますか

X側のbudget controlsやusage trackingだけでなく、AIエージェント側で1 runあたりのtool call数、pagination上限、retry上限、1日あたりの上限を持ちます。429やbudget到達は通常完了ではなく、停止して人間レビューへ戻します。

MCPなら安全になりますか

なりません。MCPは接続とtool公開の形式です。安全性は、OAuth scope、tool allowlist、承認UI、実行環境、secret管理、監査ログ、budget control、policy reviewで作ります。

---

次に読むなら

参照した主な情報源

情報源	URL	確認した内容
X Agent Resources	https://docs.x.com/tools/ai	llms.txt、skill.md、Docs MCP、XMCP、OpenAPI specの案内
X OAuth 2.0 Authorization Code with PKCE	https://docs.x.com/fundamentals/authentication/oauth-2-0/authorization-code	fine-grained scopes、access token、offline.access、refresh token
X API Rate Limits	https://docs.x.com/x-api/fundamentals/rate-limits	per-endpoint、per-user、per-app、429 handling、rate limit headers
X Usage and Billing	https://docs.x.com/x-api/fundamentals/post-cap	pay-per-usage、credits、app-level usage tracking、budget controls
X Security	https://docs.x.com/fundamentals/security	credential storage、minimal permissions、token storage、logging without credentials
X Developer Guidelines	https://docs.x.com/developer-guidelines	official API、automation rules、opt-out、AI-generated replies、data handling
X Developer Policy	https://docs.x.com/developer-terms/policy	spam/manipulation禁止、automated replies/DM、bot開示、policy compliance
xdevplatform/xmcp	https://github.com/xdevplatform/xmcp	FastMCP server、OpenAPI由来tool、X_API_TOOL_ALLOWLIST、debug系flag
X OpenAPI spec	https://api.x.com/2/openapi.json	2026年6月1日にstatus 200、info.version 2.164を確認
X llms.txt	https://docs.x.com/llms.txt	2026年6月1日にstatus 200を確認

更新履歴

1. 2026年6月1日

   X Agent Resources、X API docs、Developer Policy、XMCP、OpenAPI spec、llms.txtを確認して初版を作成しました。

2. 次回確認

   Usage and Billing、Rate Limits、Developer Guidelines、Developer Policy、XMCP README、OpenAPI versionを再確認します。

料金、policy、scope、tool一覧、非GET operation数に差分があれば、判断表も更新します。

日付	確認対象	内容
2026-06-01	X Agent Resources、X API docs、Developer Policy、XMCP	初版作成。公開OpenAPI specはstatus 200、info.version 2.164、HTTP operations 163、non-GET operations 66としてローカル確認。docs.x.com/llms.txtはstatus 200。xdevplatform/xmcpのHEADは63d34362d88ed9f94d54ccd5ecd5bb4d12e11759。

次回更新では、X APIのUsage and Billing、Rate Limits、Developer Guidelines、Developer Policy、XMCP README、OpenAPI version、Agent Resourcesの導線を再確認します。特に料金、policy、scope、tool一覧、非GET operation数に差分がある場合は、本文の判断表と公開前リスクも更新します。