MetaのAIエージェント「Muse」でXに自動投稿する方法を4つ試し、0円で動いたのはログイン済みのCookie（セッションの合い鍵）を渡す方式でした。
Museのブラウザで新しくログインする方法は、3回とも入口で弾かれています。
ただし、Cookieの方式はXの利用規約に触れるおそれがあり、規約に沿うのは公式X API（URL付きは1投稿0.2ドル）です。
- 公式のX API：動く。URL付きは1投稿0.2ドル
- Museのブラウザでログイン：入口で弾かれて使えない
- 自宅のPCを中継：設計だけで、作らずに済んだ
- ログイン済みのCookieを渡す：0円で動く。規約上のリスクは自分で負う
楽天ポイントの告知を自動化したときの記録で、2026年11月5日・6日・9日に試しました。
→ 関連：AIボット4つの比較｜dots・Duet・Grok Bot・Muse
やりたかったこと｜楽天ポイントの告知を自動化する
楽天市場のクーポンのキャンペーンページには、おすすめショップのバナーを押すと1枚につき1ポイントもらえる企画があります。
これをポイ活向けのXアカウントで知らせる作業を、Museに丸ごと任せたいと考えました。
流れは3つに分かれます。
- 新しいキャンペーンページが出たことに気づく
- バナーの枚数（＝もらえるポイント）と期限を数える
- 自分の楽天アフィリエイトのリンクを付けて、Xに投稿する
1と2はすぐに片付きました。
ページのHTMLを取ると、adsClickPointInner という区間の中に広告枠のID（rdn-adspot-*）が並んでいます。
このIDの種類の数が、そのままもらえるポイントの数でした。
ブラウザで目で数えた値とも、3ページすべてで一致しています（33枚・5枚・7枚）。
見回りは毎日3回（0時20分・10時20分・20時20分）の定期実行にしました。
残ったのが3つ目の「Xにどう投稿するか」で、ここに一番時間がかかっています。
Xへの投稿4つの方式｜費用と結果の早見表
| 方式 | 1投稿の費用 | 結果 |
|---|---|---|
| 公式のX API | 0.2ドル（URL付き） | 動く。予備に残した |
| Museのブラウザでログイン | 0円 | 入口で弾かれて不可 |
| 自宅のPCを中継 | 0円 | 設計だけ |
| ログイン済みのCookie | 0円 | 採用。規約の注意あり |
費用だけで見るとCookieの方式が一番安く、規約の面では公式のX APIが一番安全です。
以下、試した順に書きます。
方式1：公式のX API｜動くが1投稿約30円
X APIは2026年に、使った分だけ払う従量課金に変わりました。
月額の契約は無く、先にクレジットを買って、使うたびに減っていく形です。
| 操作 | 料金 |
|---|---|
| 投稿（URLなし） | 1回0.015ドル |
| 投稿（URL付き） | 1回0.200ドル |
| 投稿の読み取り | 1件0.005ドル |
出典：X Developer Platform「X API pay-per-usage pricing and credits」（2026年11月9日確認）
告知にはいつもリンクを入れるので、1件0.2ドル（約30円）になります。
月に10〜15件なら2〜3ドルで、払えない額ではありません。
とはいえ、報酬が出るかどうかわからない告知1本に30円は重く感じました。
開発者のアカウントと投稿するアカウントは別にできる
ここで一度つまずきました。
- クレジットは、買ったXアカウント（開発者のアカウント）に付き、ほかのアカウントへは移せない
- 同じ開発者のアカウントの下のアプリなら、投稿先が別のアカウントでも残高を共有できる
- 投稿するアカウントの側は、アプリのクライアントIDで認可（OAuth）するだけでよい
- 投稿するアカウントで開発者の登録をし直す必要は無かった（試すと「必須パラメーターがありません」と出た）
アプリの設定で要ったのは、権限を「Read and write」にすること、アプリの種類をWebアプリにすること、コールバックURLとWebサイトのURLを入れることの4つです。
接続テストで投稿先のアカウントが合っているのを確かめ、実際のキャンペーン3件（合計45ポイント分）を投稿しました。
費用は3件で0.6ドルでした。
投稿の頭のPR表記が消えていた
最初の投稿では、文頭に付けたはずのPR表記が抜けていました。
投稿文をいったんファイルに書き出して受け渡すあいだに、その部分だけ落ちていたのが原因です。
3件ともすぐに消して投稿し直したので、さらに0.6ドルかかっています。
それからは、投稿したすぐ後に、APIが返してきた本文の先頭を毎回確かめるようにしました。
作った文と、実際に載った文は別のものとして扱う、という考え方です。
方式2：Museのブラウザでログイン｜入口で3回とも弾かれた
Museにはクラウド上のブラウザがあり、画面を操作してログインすることもできます。
11月5日・6日・9日の3回試して、結果は3回とも同じでした。
- ユーザー名を入れて「次へ」を押した直後に「問題が発生しました。やりなおしてください。」と出る
- パスワードを入れる画面に一度も進まない
- 本人確認もCAPTCHAも出ない
パスワードを確かめる前に止まっているので、IDやパスワードが原因ではありません。
ログインの入口の時点で、通信の出どころごと断られていると見ています。
Museのブラウザは、出口が米国のデータセンターのIPです。
同じ環境でもGoogle・DMM・楽天にはログインでき、Amazon.co.jpはトップページの時点で弾かれました。
データセンターからの通信にどこまで厳しいかは、サービスごとに違うようです。
→ 関連：MuseでAmazonにログインできない理由｜出口IPを調べた
入力欄に値を直接流し込む小技も考えましたが、MuseのブラウザにはJavaScriptを実行する手段が無く、試せませんでした。
試せたとしても、入口で通信の出どころを見ている以上、入力の仕方で変わる見込みは薄いはずです。
調べてわかったこと｜無料の道具も「パスワードでは入れない」
XをAPIキー無しで扱うPythonの道具に、twikitがあります。
その更新が止まったあとを引き継いでいるのがtwiforkで、説明文にはっきり書かれていました。
- Xは、ログインの流れを古い方式から入れ替えた（2026年7月29日に確かめた、とある）
- 新しい流れは、ページ内のJavaScriptが作る確認用の値や、パスキーを前提にしている
- そのため、パスワードでのログインはどの道具でも動かせない
- ブラウザでログインしたときのCookieを書き出して使うように、と案内している
出典：PyPI「twifork」（2026年11月9日確認）
つまり、無料で投稿する道の本筋は「ログインを自動化する」ではありませんでした。
人が一度ログインしたセッションを使い回す、というのが今の標準の形です。
方式3：自宅のPCを中継する｜設計だけで済んだ
最初に本命と考えていたのは、Xへの投稿を自宅から出す形でした。
Muse ──（Tailscale）──> 自宅のPCの中継サービス
└ 自宅のブラウザでログイン済みのセッションで投稿
（通信は家庭のIPから出る）Museに入っているTailscaleで、自宅のネットワークに参加するところまではできました。
ただ、Museのブラウザ自体を自宅のIPから出す設定（Exit Node）には対応していません。
「ブラウザを自宅のIPで使う」形は無理で、「自宅側のサービスをAPIとして呼ぶ」形なら作れる、という切り分けです。
結局、次の方式4で足りたので、中継のサービスは作っていません。
方式4：ログイン済みのCookieを渡す｜0円で動いた
最後に採用したのは、普段のブラウザでログインしたときのCookieをMuseに渡す方式です。
- 普段のパソコンのChromeで、投稿したいXアカウントに手でログインする
- デベロッパーツールの「Application」から「Cookies」→「https://x.com」を開く
- auth_token（ログイン状態の鍵）とct0（送信の確認用）の2つの値を控える
- Museのクラウドの中の1つのファイルにだけ置き、投稿用の小さなプログラム（twiforkを使用）から読む
値はパスワードと同じ重さの情報なので、上の画面ではぼかしています。
2つあれば、そのアカウントをほぼ丸ごと操作できます。
新しいログインは弾かれても、発行済みのセッションは通った
- Cookieでホーム画面を取ると、ログイン中のユーザーが投稿したいアカウントになっていた
- プログラムで取ったユーザーIDと名前が、公式APIで確かめた結果と一致した
- テストの投稿を作って、すぐ消すところまで成功した（費用0円）
- 見回り→数える→投稿の定期実行を、X APIからこの方式に切り替えた
入口で弾かれるのは「新しくログインする」ときだけで、すでにあるセッションを使う分には通りました。
ここが今回、一番大きな発見です。
つまずいた所｜プロキシの扱いが2つ
Museの中でPythonから通信するときに、2回止まりました。
- 環境変数のNO_PROXYに、かっこ付きのIPv6の書き方（[::1]）が入っていて、httpxが「Invalid port」で落ちた。プログラムの中でNO_PROXYとALL_PROXYを外して直った
- プロキシを環境変数任せにすると、直接つなぎに行ってTLSのエラー（WRONG_VERSION_NUMBER）になった。プロキシのURLを明示して渡すと通った
Museのクラウドは外への通信がプロキシ経由なので、同じ所で止まる人は多いはずです。
どのアカウントで使うか
止められたり、ロックされたりするリスクは、Cookieを渡したアカウントそのものにかかります。
捨てアカウントのCookieを使えば投稿も捨てアカウントから出て、告知用のアカウントで投稿したいなら、リスクも告知用のアカウントが負います。
今回は運営者の判断で、告知用のアカウントのCookieをそのまま使いました。
Xの利用規約との関係｜Cookieの方式は自分の責任で
Xの利用規約は、Xが提供する公開インターフェース以外の方法でサービスに入ることを禁じています。
自動のプログラムかどうかは問わない、と書かれています。
Cookieを公式でない道具から使う方式は、この「公開インターフェース以外」に当たると読むのが自然です。
見つかれば、アカウントの停止やロックになり得ます。
規約に沿って自動で投稿したいなら、答えは方式1の公式X APIです。
当方はCookieの方式を使いながら、X APIの設定も消さずに予備として残しています。
Cookieが漏れたと思ったら、Xの「設定とプライバシー」→「セキュリティとアカウントアクセス」→「アプリとセッション」から、その端末のセッションを終わらせてください。
自動投稿で決めた運用のルール
- 投稿したすぐ後に、返ってきた本文でPR表記が付いているかを確かめる
- Cookieが切れたら、勝手に有料のX APIへ切り替えず、運営者に取り直しを頼む
- Cookieの値は1つのファイルにだけ置き、メモやログに写さない
- 見回り・数えた結果・投稿の記録は台帳とログに残し、いつ何を数えたかを後から追えるようにする
2つ目は、知らないうちにお金がかかるのを防ぐためのルールです。
AIエージェントに任せると、止まったときに「動く別の道」を自分で選びがちなので、先に決めておきました。
わかったこと｜「ログインできない」は3つに分けて考える
- IDやパスワードの問題か、新しいログインへの環境の判定か、発行済みのセッションが使えるかは、全部別の話だった
- 新しいログインが弾かれる環境でも、セッションの使い回しは通ることがある
- 自動化の前に、その道具を保守している人の説明を読むと遠回りが減る
- つながったかどうかは推測で報告させず、サービス側で実際に確かめさせる
最後の点は、今回も「つながったはず」という報告が何度かくつがえったことから入れています。
よくある質問
MuseでXにログインできないのはなぜ？
ユーザー名を入れた直後に止まるので、IDやパスワードではなく、Museの通信の出どころ（米国のデータセンター）で断られていると考えられます。
当方の環境では3日とも同じ結果でした。
X APIで投稿するといくらかかる？
2026年11月9日時点で、URLなしの投稿は1回0.015ドル、URL付きは1回0.2ドルです。
無料の枠は無く、先にクレジットを買って使います。
auth_tokenとct0はどこで見られる？
ChromeでXにログインした状態でデベロッパーツールを開き、「Application」→「Cookies」→「https://x.com」の一覧にあります。
人に見せたり、ブログやチャットに貼ったりしないでください。
Cookieを使った自動投稿は規約違反？
Xの利用規約は、公開インターフェース以外からの利用を禁じているため、当たる可能性は高いと考えます。
規約に沿いたい場合は、公式のX APIを使ってください。
まとめ
MuseのブラウザからXへ新しくログインするのは、11月の3回とも入口で弾かれて無理でした。
普段のブラウザでログインしたCookieを渡せば、0円で投稿まで自動にでき、当方はこの形で動かしています。
ただし規約に沿うのは公式のX APIで、URL付きの投稿は1件約30円です。
費用と規約のどちらを取るかは、アカウントを失ったときに困るかどうかで決めるのがよいと思います。
