Projects / 実践記録

CodexでX投稿を考え直した。承認制でもブラウザ自動操作とは分ける

本ページはアフィリエイトプログラムを利用しています

更新注記（2026年7月21日）
この記事は、X APIのcredit不足をきっかけに、Codexとログイン済みChromeを使う承認制へ移った当時の実践記録を、X公式Developer Guidelinesに照らして見直したものです。
人間が投稿内容を承認することと、公式API以外のbrowser automationを使うことは別の判定軸でした。今後の実運用方式は、まだ決めていません。

以前、GASとTwitter APIでXへブログ記事を自動投稿する仕組みを作った。
Googleスプレッドシートに投稿文をため、GASが1件選び、X APIから投稿する。
当時は、それで十分だった。

ただ、2026年5月、その投稿が止まっていることに気づいた。
実行画面では処理が終わっているように見えたが、APIリクエストはCreditsDepletedで失敗していた。
そこで、自分はAPI投稿をいったん外し、Codexが記事を読み、人間が文面を確認したあと、ログイン済みChromeから投稿する承認制へ移った。

候補をAIが出す。
投稿文もAIが作る。
最後に人間がOKする。

この分け方なら、完全自動よりも自分の発信に合うと思っていた。
でも、実運用後にX公式のDeveloper Guidelinesを読み直すと、見落としていた境界があった。

問題は、承認があるかどうかだけではない。
Xへアクセスする手段そのものにも、別の条件がある。

この記事は「X APIへの課金を避ける方法」を勧めるものではない。
自分が一度組んだ運用を、公式ポリシーの文言まで戻って見直した記録です。

GASとX APIが止まり、承認制へ移った

前の仕組みは、投稿作業を自動化するものだった。
スプレッドシートに用意した文面をGASが選び、X APIへ渡す。
定刻になれば、過去記事の紹介が流れる。

便利ではあった。
ただ、投稿文は先に書いたものなので、その日の文脈で記事を読み直すわけではない。
記事ごとの読みどころを拾い直すところまでは、自動化できていなかった。

API requestがcredit不足で止まった時、選択肢を二つに分けた。
公式APIの利用条件を満たして運用を続けるか。
API投稿をやめ、AIチームの作業として組み直すか。

当時の自分は後者を選んだ。
CodexがWordPressの記事から候補を選び、本文を読み、X向けの文面を作る。
人間が内容と投稿先アカウントを確認し、OKしたものだけをログイン済みChromeから送る形です。

決まった文面を流す時より、記事ごとの温度を出しやすくなった。
AI運用の記事なら、仕組みと判断点を短くする。
体験記事なら、場所や季節、実際に起きたことを拾う。

「投稿するか」は人間が決める。
ここは、今も残したい考え方だった。

人間のOKと、アクセス手段は別の判定軸だった

最初の見落としは、承認制なら問題を避けられると考えていたこと。

人間の確認は必要です。
記事にないことを書かない。
投稿先を間違えない。
煽りすぎない。
送信前に止められる。
これは発信内容を管理するための境界になる。

一方、X公式Developer Guidelinesは、user initiatedであるかに加えて、official API onlyであるかを別に確認している。
同ガイドは、scraping、browser automation、unofficial methodsを使わず、公式X APIだけを使うよう案内している。

つまり、内容を人間が承認していても、それだけでnon-API browser automationという技術手段が許容されるわけではない。
承認は「何を送るか」の制御。
公式APIかどうかは「どう送るか」の制御。
同じ安全策としてまとめてはいけなかった。

2026年7月21日時点の公開ガイドの文言上、ログイン済みブラウザをスクリプトやエージェントが操作して投稿する方式は、non-API browser automationの禁止対象として扱う必要がある。
これは法的評価をしているのではない。
また、個別アカウントにどの措置が行われるかを断定するものでもない。
公開されているプラットフォーム方針に照らし、実運用を再検討するという話です。

自動いいねは、投稿とは分けて考える

もう一つ、明確に分けるべきだったのが「いいね」です。

X公式Developer Guidelinesでは、likes must be directly initiated by the authenticated userと説明されている。
ユーザー、キーワード、ハッシュタグ、scheduleなどを条件にしたauto-like、bulk liking、indiscriminate likingは禁止とされている。

ここでは「人間が自動いいね機能を一度ONにした」だけでは、各いいねを直接開始したことにはならない。
投稿候補を人間が承認する仕組みと、自動いいねを同じ承認制として扱わない方がいい。

さらに、公式APIを使えばauto-likeもよい、という整理でもない。
公式API onlyという技術条件と、各likeがauthenticated userによって直接開始されるという操作条件は、両方を見る必要がある。

自分の運用を見直すなら、投稿、予約投稿、いいね、返信、フォローを一つの「X自動化」にまとめない。
操作ごとに公式ルールと開始主体を確認する。

Codexは、投稿する前まででも役に立つ

browser automationを外すと、Codexに任せられることがなくなるわけではない。

公開済み記事から候補を選ぶ。
記事を読み直す。
過去に紹介済みかを整理する。
X向けの文案を作る。
文字数を確認する。
記事内容から外れた表現や、強すぎる断定を直す。
投稿先アカウントの候補を明示する。

ここまでは、Xへ操作を送らなくてもできる。

もともと価値があったのは、投稿ボタンを押すことだけではなかった。
記事を読み、何を紹介するかを毎回考え直せることが大きかった。
候補選定と文案作成をCodexへ渡し、人間がXのnative UIで投稿する形なら、その部分は残せる。

新規記事の告知も同じです。
公開URLをもとにCodexが文案を作る。
人間が内容を確認する。
その後、人間がXの画面で投稿または予約する。

一手は増える。
でも、AIがXを操作しなくても、毎回ゼロから文面を考える負担は減らせる。

native UIで人が送るか、公式APIを使うか

今のところ、現実的な案は二つに見える。

一つ目は、Codexを候補選定、記事読解、文案作成までに留める方法。
投稿や予約は、authenticated userである自分がXのnative UIから直接行う。
小規模な運用なら構成が単純で、投稿前に文面とアカウントを目で確認できる。

二つ目は、自動投稿が必要な範囲を定め、公式X APIを使う方法。
APIのaccess、cost、rate limit、automated accountの表示や運用条件などを、その時点の公式資料で確認して設計する。
公式APIを選んでも、spam、unsolicited interaction、auto-likeなど、別の制限まで消えるわけではない。

どちらにも作業と費用がある。
native UIなら、人間が投稿する時間が必要になる。
公式APIなら、実装、利用条件、費用、rate limit、運用記録を持つ必要がある。

現時点では、どちらを今後の標準方式にするか決めていない。
この記事のために、運用方式まで採用済みにするつもりもない。

まず、non-API browser automationを推奨手順として残さない。
そのうえで、必要な投稿頻度と、人がnative UIで扱える範囲を見直す。
公式APIが必要なら、現行条件を確認して別の実装として考える。