X APIで記事の自動投稿ツールを自作した。料金は1本0.2ドル、ブラウザ操作を選ばなかった理由

X（旧Twitter）へブログ記事の告知を自動投稿するツールは、X API で作りました。ブラウザを自動操作する方法は選んでいません。費用は URL 入りの投稿1本あたり 0.2 ドルで、月額の固定費はありません（2026年9月時点の公式料金表）。ツールは Python の標準ライブラリだけで書き、実装は AI（Claude Code）に任せました。

8月に Threads 版を先に作ってから、X 版だけを後回しにしていました。理由は費用です。Threads の API は無料なのに、X は有料で最低5ドルのチャージが要ります。

9月に入って「やってみるか」という気持ちで課金し、2日で本番投稿の手前まで作りました。この記事は、その記録です。

この記事で分かること

ブラウザ操作の自動化を選ばなかった3つの理由（規約・手離れ・記事の筋）
X API の料金（2026年9月時点）と、月2〜4本での試算
開発者ポータルで詰まった3ヶ所
自作ツールの形（1件完結・URL は最終行・送信後の失敗は再試行しない）
テスト投稿が通ったあと、AI のレビューに3時間かけて分かったこと

X の自動投稿に、ブラウザ操作でなく API を選んだ理由

作り始める前に、私は AI（Claude Code）に「Threads と同じで API 経由を想定してるでしょ？ブラウザを操作させたら、それ要らなくね？」と聞きました。費用も開発者登録も要らなくなるなら、そのほうが楽に見えたからです。

答えは「技術的には動く。でも選ばない理由が3つある」でした。私が納得した順に書きます。

理由1: 規約が「API を使わない自動化」を永久凍結の対象にしている

X の自動化ルール（2026年4月更新版）は、やってはいけないことの1つに「API を使わない形の自動化。たとえば X のウェブサイトをスクリプトで操作すること」を挙げています。この方法はアカウントの永久凍結につながりうる、とも書いています。一方で、やってよいことの筆頭は「役に立つ情報を自動で投稿する仕組みを作る」です。API 経由の自動投稿は、規約が正面から認めている形でした。

このブログの X アカウントには凍結歴があります。一度凍結されたアカウントで、規約が名指しで禁じる方法を選ぶ理由はありませんでした。

「自分の Chrome を AI に操作させて投稿ボタンを押させる」形も、API を使わない自動化であることに変わりはありません。AI の答えでは、この形は毎回人が画面を見ている前提なので、手動投稿の代行であって自動化ではない、とされていました。

理由2: ブラウザ操作は手離れしない

ログインセッションの失効、2要素認証、画面の作り替えでボタンの位置が変わること。ブラウザ操作の自動化では、この3つがいつか起きて、そのたびに人が直します。

私が欲しいのは、記事を公開したあとに1コマンドで済む道具です。費用対効果はいまのところ薄くても、自動化できるものは自動化しておきたいからです。数ヶ月に1回の修理が要る道具は、告知の自動化としては失格でした。

API のほうは、固定の鍵4本で動きます。公式の認証 FAQ によると、アクセストークンは明示的には失効しません。利用者が取り消すか、アプリが停止されたときに無効になります（2026年9月時点）。Threads 版で60日ごとのトークン更新に付き合っている身としては、これだけでも API に傾きました。

理由3: 記事の題材として筋が悪い

作ったら記事にする前提でした。ブラウザ操作版だと「規約に触れる手口を読者に勧める記事」になります。読んだ人が同じことをして凍結されたら、書いた意味がありません。

退路として残るのは、ブラウザ操作ではなく「半自動」です。ツールが文面と文字数・URL の検証だけをして、投稿は人がコピペする形です。そこまで落とす前に、まず API で作ることにしました。

X API の料金は、自動投稿1本 0.2 ドル（2026年9月時点）

料金は公式の料金ページで 2026年9月3日に確認しました。従量課金だけで、月額の固定費や契約はありません。今回のツールに関係する3つを抜き出します。

操作	料金	ツールでの使いどころ
投稿の作成	1件 0.015 ドル	URL を含まない検証投稿
URL を含む投稿の作成	1件 0.200 ドル	記事の告知（本番）
ユーザー情報の読み取り	1件 0.010 ドル	認証確認

記事の告知は URL を含むので、1本 0.2 ドルです。月2〜4本なら 0.4〜0.8 ドル、5ドルで25本分になります。私が開発者コンソールでチャージしたとき、選べる最低額は5ドルでした（2026年9月3日）。料金は変わりうると公式ページにも書いてあるので、読む時点で料金表を見てください。

実際に使った額は、この記事を書いている時点で 0.025 ドルです。認証確認が 0.010 ドル、URL なしの検証投稿が 0.015 ドル。URL 入りの本番投稿は、この記事の告知が1回目になります。

X API の自動投稿。開発者ポータルで詰まった3ヶ所

開発者登録から鍵の保存までは、私の手作業です。公式の手順どおりに進む部分は省いて、止まった3ヶ所だけ書きます。画面の名称は 2026年9月3日時点のものです。

① ユーザー認証設定は、コールバック URL とウェブサイト URL が必須

投稿の権限（Read and Write）を付ける画面は、コールバック URL とウェブサイト URL を埋めないと保存できません。自分のアカウントに投稿するだけの使い方では、コールバックは一度も呼ばれません。形式が通ればよいので、両方ともブログのトップページの URL を入れました。アプリの種類は「ウェブアプリ、自動化アプリまたはボット」を選んでいます。

Threads のときも、コールバック URL の3欄で止まりました。「使わないのに必須」は、これで2度目です。

② 保存すると出てくる OAuth 2.0 の Client ID と Secret は使わない

認証設定を保存した直後に、OAuth 2.0 の Client ID と Client Secret が表示されます。手順に無い値が出てきたので「これは何」と止まりましたが、今回の方式（OAuth 1.0a）では使いません。使うのは Keys and tokens タブにある API Key と Secret、Access Token と Secret の4つだけです。

この4つは 1Password に置き、リポジトリには参照だけを入れています。ツールが鍵を画面に出すことは無く、API のエラー本文も鍵の部分を伏せてから表示します。

③ 権限を変えた「あと」で Access Token を再生成する

Access Token は、権限を Read and Write に変えたあとで再生成しました。公式の開発者アプリの説明に、権限を変えたら新しいトークンを取り直す必要があると書かれているためです（2026年9月時点）。順番が逆だと、投稿のときに権限エラー（403）で止まることになります。

この罠は8月の設計時に手順へ先に組み込んでいたので、私自身は踏んでいません。ツールには、403 が返ったら「権限変更のあとにトークンを再生成したか」を疑うメッセージを入れてあります。

自作ツールの形。1件完結で、URL は最終行に置く

ツールは Threads 版の複製で、コマンドは3つです。

認証確認: 鍵が正しいアカウントのものかを確かめる（読み取り1件・0.010 ドル）
dry-run: 本文・URL・文字数を検査して表示するだけ（通信なし・課金ゼロ）
post: 投稿する（URL 入り・0.200 ドル）

本文はファイルで渡します。型は「本文 → 改行 → 最終行に記事 URL だけ」の1件完結です。dry-run で見た文面がそのまま投稿されるように、ツールは本文の連結や整形を一切しません。

8月上旬の設計では「親投稿にリンクを入れず、リプライに URL を置く」2件スレッドの型でした。リンク入り投稿は表示が減る、という当時の調べに合わせた形です。これを改めたきっかけは、2026年7月末の X 上のやり取りでした。

X のプロダクト責任者 Nikita Bier 氏が「もうリンクをリプライに入れる必要はない」と投稿しました。それを受けた Paul Graham 氏の「リンク入りの投稿にはもうペナルティを課していないのか」という問いに、Elon Musk 氏が「1年以上前から課していない」と答えています（ppc.land の報道・やり取りは 2026年7月28〜29日）。同じ報道は、公開されたアルゴリズムの分析からリンク入り投稿の表示が少ない傾向も併記しているので、私は鵜呑みにしていません。

手動投稿で末尾の URL がリンクカードになり、記事のアイキャッチが出ることは自分で確かめました（2026年8月13日）。それを見て、この型に決めています。

ツールが機械で止めるのは、次の3つです。

最終行が、自分のブログの記事 URL の形になっていない
URL の行を除いた本文に、URL やドメインらしき表記がある
文字数が 280 を超える（X の重み付きの数え方＝全角2・半角1・URL は長さによらず23。公式が案内する twitter-text の計算に合わせた・2026年9月時点）

送信したあとの失敗は、自動で再試行しません。X 側では投稿が成功しているのに応答だけが壊れた場合、再試行すると二重投稿になるからです。ツールは「成否不明」と表示して止まり、プロフィールを目視してから人が実行し直します。

中身は Python の標準ライブラリだけで、OAuth 1.0a の署名も自前で計算しています。コードは Claude Code に書かせました。

テスト投稿が通ったのに、AI 同士は何を直し合っていたのか

9月4日、URL なしの検証投稿（0.015 ドル）が通りました。X の画面で投稿を確認して、手で消しました。ここで終わりだと思っていたのに、AI のレビューは続きます。Claude Code が書き、Codex が指摘し、また Claude Code が直す往復です（この往復のルールは別の記事に書きました）。

私は「今なにを修正し合ってるの？さっきのテスト投稿で OK なわけじゃないのか」と聞きました。答えは「テスト投稿が証明したのは、うまくいく道だけ。レビューが見ているのは、うまくいかなかったときの道」でした。たとえば、X 側では投稿が成功しているのにツールが失敗と誤認して再実行を促し、二重投稿になる型です。

実装前のレビューで出た重大指摘を、往復ごとに並べます。

往復	重大	何が出たか
1	2	文字数の計算が公式の twitter-text とずれる（URL 直後の句読点を URL に巻き込んで少なく数える）ほか
2	2	URL の抽出に穴が残る。汎用の抽出をやめ「最終行＝記事 URL」の型へ構造変更
3	2	URL 行末のピリオドを23字に含めてしまう。国際化ドメイン（日本語の TLD）を見逃す
4	1	結合記号を含む TLD（インド系文字など）が検査をすり抜ける
検証	0	別の AI が twitter-text の URL 抽出を移植し、全 TLD 1,574 件と無作為の文字列70万件で取りこぼし0を確認

実装後にもレビューを2往復回して、重大2件のあと「重大指摘なし」で収束しました。合計で約3時間。Codex の5時間枠をほぼ1回分使う量でした。

直した内容はどれも正しい指摘でした。ただ、毎回 dry-run を見てから投稿する運用では、どれも起きにくいものです。

「完璧を求めていない」と言って、方針を変えた

私は AI に「投稿を試みて、成功ならそれで終わり。URL を開けば確認できる。誰かに提供するならまだしも、自分しか使わない。問題が起きたときに、その都度対処でいい」と言いました。

AI の評価は賛成でした。実装後の往復1で出た重大2件は、URL だけの本文が通ることと、想定外の応答が返ったときに「成否不明」の案内が出ないことです。どちらも dry-run で一目で気づくか、起きても無料で消せるものでした。そのうえで、先回りの費用に見合う「本当にまずい」パターンを5つに絞りました。

無人で取り消せない副作用が出る（人が毎回見る運用なら該当しない。記事公開と同時の自動投稿へ変えた瞬間に該当する）
秘密が漏れる（トークンがログやコミットに載る。気づくのが遅れる）
お金が勝手に膨らむ（自動再試行のループ。今回はチャージした5ドルが上限になる）
既存データを壊す（8月に記事本文の上書き事故が実際に起きた型）
規約違反・法令違反など、一般にまずいこと（ブラウザ操作案を弾いた判断軸そのもの）

この5つを、AI に渡している作業ルールのファイルへ書き込みました。今回に当てはめると、実装前の3・4往復目と実装後の2往復は要らなかった計算です。4往復ぶん、時間にして1時間強を、この線引きが無かったから使いました。

まとめ

X の自動投稿は API で作る。ウェブサイトのスクリプト操作は、規約が永久凍結の対象と明記している
料金は URL 入り投稿1本 0.2 ドル・月額なし（2026年9月時点）。月2〜4本なら1ドル未満
詰まりは開発者ポータルの3ヶ所。必須の URL 欄、使わない OAuth 2.0 の値、権限変更後のトークン再生成
型は1件完結・URL は最終行・送信後の失敗は再試行しない
自分専用のツールに完璧は要らない。先回りするのは「本当にまずい5つ」だけ

この記事の告知が、URL 入り投稿の1回目です。API 経由でもリンクカードにアイキャッチが出るかは、投稿してから分かります。

フォロワーがほぼいない状態で流入が増えるとは思っていません（アルゴリズムを読んだときの期待値のままです）。それでも、告知を忘れる・面倒で後回しにするという失敗は、Threads と同じく仕組みごと消えます。結果は続報で書きます。