困りごと：AIエージェントが X のリンクを読めない
AIエージェントの Muse を日常的に使っていると、「この X の投稿、どういう内容？」とリンクを渡す場面が頻繁にあります。ところが、X 公式（x.com / twitter.com）は crawler が robots.txt で拒否されるため、通常の Web fetch では公開投稿ですら取得できませんでした。
自分の環境では、保存済みログイン経由のアクセスも X 側の制限で使えず、手動ログインも通らない状態が続いていました。新規アカウント作成も電話番号の紐付けで詰まり、「読む」という一番基本の操作ができない。この記事は、その解決策を「ルール」として仕様化した話です。
解法：FxEmbed 系プロキシ経由で再取得する
採用したのは、FxEmbed（旧 FixTweet）系の第三者埋め込みプロキシです。Discord や Telegram でリンクプレビューを正しく出すために作られた仕組みで、公開投稿の OGP と本文を再構成して返してくれます。
取得の優先順位はこう決めました。
-
https://fxtwitter.com/{user}/status/{id}を fetch する - 本文が空・エラーなら
https://fixupx.com/{user}/status/{id}を試す - それでも足りなければ
https://api.vxtwitter.com/{user}/status/{id}で JSON を取る
URL のクエリ（?s= や ?t= など）は変換前に捨てます。また、やってはいけないことも明記しました。x.com を crawler に直接投げない、r.jina.ai 経由の x.com も使わない（同様に弾かれる）、Nitter はインスタンスが落ちていることが多いので第一候補にしない、の3点です。
ハマりどころ：X Articles は本文が分離している
運用して初めて分かったのが、長文投稿（X Articles）の扱いです。記事へのリンク投稿では、JSON の text に https://x.com/i/article/{articleId} だけが入っていて、本文が status 側に存在しません。
判定条件は「本文が article URL だけ」「数行で明らかに『続きは記事』構造」「JSON に article へのポインタがある」のいずれか。この場合は status を fxtwitter で展開した結果を本文として使うルールにしました。article URL を x.com で直接開きにいくのは禁止です。
実地検証では、Articles の全文は fxtwitter 展開のレンダリングで取れ、通常ポストは vxtwitter の JSON が速く確実、という使い分けが効くことが分かりました。
スレッド・引用・メディアの扱い
- スレッド：続く投稿が必要なら、各 status を同じ変換ルールで個別に取る。1投稿からスレッド全体を捏造しない
- 引用RT：引用元も同じ手順で取る。取れなければ「引用元は未取得」と書く
- メディア：プロキシが返す media URL をそのまま使う。x.com の media 直リンクを追加で這わない
一番大事なのは「出力ルール」
取得手順より重要だったのが、出力側の規律です。
- 出典はユーザーが渡した元の x.com URL を残す（変換後 URL を公式扱いにしない）
- 投稿者名・@id・投稿日時・本文・使った取得経路・取れなかった部分を必ず含める
- fxtwitter を「X 公式 API」と言わない。「公開投稿を埋め込みプロキシ経由で再取得した」と表現する
- 全部のプロキシが落ちたら Web 検索で断片を探すが、推測で本文を埋めない。失敗時は「X公式は crawler 拒否のため読めない。fxtwitter / fixupx / vxtwitter も本文を返せなかった」と書いて止める
AIエージェントは、情報が取れないときに「それらしい内容」で穴埋めしがちです。だからこそ「取れなかったことを取れなかったと書く」ルールを先に固定しておく。これがないと、読み取り基盤そのものの信頼性が崩れます。
参考にした別のエージェントのやり方
他の AI エージェント（Hermes）の X 調査事例も参考にしました。公開タイムラインのミラーで気になる投稿を「発見」し、FxTwitter で取得し、リンク先の公式情報で裏どりして、結果をファイルに残して重複提案を避ける、という4ステップです。自分のルールは「URL を渡された前提」なので、発見の入口と記録の仕組みは今後取り入れる価値があると感じています。実際、定期紹介タスクでは取得済みリストを持つ運用を既にしています。
注意点
- このプロキシは X 社非公式の第三者サービスです。認証が必要な投稿や削除された投稿は読めません
- 第三者サービスである以上、仕様変更や停止で突然使えなくなる可能性があります。依存していることを前提に、失敗時の扱いまで含めて仕様化しておくのが安全です
- 規約面の最終確認は各自の利用形態に合わせて必要です（要確認：プロキシ経由の取得が自分の利用規約・所属組織のポリシーに適合するか）
おわりに
「読めない」という問題への答えは、新しいツールではなく手順と出力規律の仕様化でした。ルールをファイルに書いてエージェントに持たせておけば、毎回同じ品質で読み取りが回ります。AIエージェント活用は、こういう地味な仕様化の積み重ねだと思っています。