以前、GASとTwitter APIでXへブログ記事を自動ツイートする仕組みを作った。
Googleスプレッドシートに投稿文をためておく。
GASでランダムに1件選ぶ。
X APIで投稿する。
当時は、それで十分だった。
ブログの記事はたくさんある。
でも、毎日手でXに投稿するのは続かない。
だったら、スプレッドシートに文面を置いて、自動で流せばいい。
かなり素直な自動化だったと思う。
ただ、先日、その投稿が止まっていることに気づいた。
管理画面上では、実行自体は「完了」になっている。
でも、Xには投稿されていない。
調べていくと、内側ではX APIのリクエストが CreditsDepleted で落ちていた。
ざっくり言えば、API側のクレジット不足。
現行のX APIは、公式ドキュメントでも従量課金・クレジット制として説明されている。
Developer Consoleでクレジットを購入し、APIリクエストごとに消費する形だ。
もちろん、必要ならAPI利用料を払えばいい。
でも、僕がやりたかったのは、ブログ記事を1日1件くらい紹介することだった。
そのためにX APIのクレジット管理まで持つのは少し重い。
そこで、仕組みを作り替えることにした。
今は、Codex、Google Sheets、Chromeを組み合わせて、X投稿をAIチーム運用にしている。
GASとX APIの自動投稿は、文面を流す仕組みだった
前の仕組みは、かなりシンプル。
スプレッドシートの tweets シートに、投稿したい文面を1行ずつ入れておく。
GASがそこからランダムに1件選ぶ。
X APIに投げる。
定時トリガーで、朝と夜に実行する。
これで、過去記事を少しずつXに流せるようになった。
これはこれで便利だった。
ただ、文面は基本的に事前に用意したものになる。
記事の中身を読み直して、その日その場で切り口を変えるわけではない。
ハッシュタグも、先に書いておいたものをそのまま使う。
つまり、旧仕組みは「投稿作業の自動化」だった。
記事を読んで、何を伝えるかを考えるところまでは、自動化できていなかった。
止まっていた原因は、X APIのクレジット不足だった
止まっていることに気づいたとき、最初はトリガーの問題かと思った。
GASの実行一覧を見ると、処理自体は終わっているように見える。
でも投稿されていない。
表面上は「完了」に見えても、実際にはその中のAPIリクエストで失敗していることがある。
ログを追うと、X API側で 402 CreditsDepleted が返っていた。
これはコードの書き方というより、API利用条件の問題として見るべきものだった。
X APIのドキュメントを見ると、現在はpay-per-usage、つまり使った分だけクレジットを消費する説明になっている。
クレジット残高が足りなくなると、APIリクエストはブロックされる。
以前の記事では、無料枠で自動投稿できる前提で書いていた。
でも、その前提はずっと同じではない。
外部APIを使う自動化は、相手側の仕様や料金体系が変われば止まる。
今回、それをかなり分かりやすく踏んでいた。
APIに課金するより、Codexで運用を組み直した
ここで選択肢は2つあった。
X APIにクレジットを入れて、これまで通りAPI投稿を続ける。
もしくは、別の運用に切り替える。
今回は後者にした。
理由はシンプルで、目的が「APIで投稿すること」ではなかったから。
やりたかったのは、ブログ記事をちゃんと紹介すること。
しかも、4つのブログとtaupeの記事を、今の文脈に合わせて少しずつ出していくこと。
だったら、決まった文面を自動で流すより、AIに記事を読んでもらって、その記事ごとに投稿文を作ってもらうほうがいい。
そう考えて、Codex、Google Sheets MCP、Chromeを組み合わせる形にした。
Google Sheetsには、投稿候補のURLや文面を置いておく。
CodexがGoogle Sheets MCP経由で候補を読む。
URLがあれば、記事本文を読む。
そこからX向けの紹介文を作る。
ハッシュタグも記事内容に合わせて1〜3個つける。
最後に、ログイン済みChrome上のXから投稿する。
APIで投稿しているわけではない。
Codexが、いつものブラウザ操作に近い形で投稿している。
AIにしたことで、文面もハッシュタグも変わった
この運用に変えて、いちばん大きく変わったのは文面。
前の仕組みでは、シートに書いた文面をそのまま投稿していた。
今は違う。
Codexが記事を読む。
その記事で何を伝えるとよさそうかを考える。
X向けに短く整える。
記事テーマに合うハッシュタグを選ぶ。
たとえば、AIチームと作る、ぼっち事業のOS のような記事なら、単にタイトルを流すだけでは少し弱い。
4つのブログ、公式サイト、事業集計、AIとの作業体制をつなげている話だと分かるようにしたい。
それを、Xで読める長さに圧縮する。
同じように、moss.fish の体験記事なら、季節感や体験の温度を少し出す。
isLog の食や旅の記事なら、場所、料理、空気感が伝わるようにする。
これは、決まった文面を流すだけの自動投稿ではやりにくい。
AIが記事を読んでから投稿文を書くので、記事ごとの読みどころを出しやすくなった。
新規記事の告知も、そのまま同じスレッドで頼める
もうひとつ便利なのは、新規記事の告知です。
記事を書いたあと、同じスレッドにURLを渡して、
「これ、Xに投稿しておいて」と頼める。
するとCodexが記事を読み、X向けの文面を作り、ハッシュタグを整えて、Chromeから投稿する。
投稿後は、投稿文と結果を報告する。
記事を書いたあとに、X用の文面を考えるのは、意外と手が止まる。
タイトルをそのまま貼るだけだと弱い。
かといって、毎回ちゃんと要約するのも面倒。
でも、公開直後の告知はしたい。
その部分を、AIチームの担当にできる。
記事を書く。
URLを渡す。
X用の文面はCodexが作る。
人間は、必要なら最終的に確認する。
この流れになると、発信の摩擦がかなり減る。
ただし、完全放置の自動化ではない
ここは大事なところ。
この仕組みは、完全放置で永久に動くものではない。
Chromeのログイン状態に依存する。
X側の画面変更にも影響を受ける。
CAPTCHAや2FA、追加確認画面が出たら止まる。
投稿ボタンが押せないときも、無理に進めない。
文字数がオーバーしたら、文面を短くする。
それでも解消できない場合は投稿しない。
投稿対象アカウントが確認できない場合も止める。
これは、欠点というより安全設計だと思っている。
SNS投稿は、勝手に暴走されると困る。
認証情報やCookie、トークンをAIに扱わせるのも避けたい。
だから、APIキーを持たせて完全自動で投げるのではなく、ログイン済みChromeの画面を使い、危ない状態なら止まって報告する。
自動化というより、AI担当者に手順を渡している感覚に近い。
人間が決めること、AIに任せること
この運用では、人間が決めることを残している。
何を投稿候補にするか。
投稿してはいけない条件は何か。
どのアカウントから投稿するか。
記事内容にないことを書かない。
煽りすぎない。
ハッシュタグを盛りすぎない。
このあたりのルールは、人間側で決める。
一方で、AIに任せることもある。
候補を選ぶ。
記事を読む。
文面を整える。
ハッシュタグを選ぶ。
文字数を見て削る。
投稿後に結果を報告する。
この分け方が、今のところちょうどいい。
AIに丸投げするのではなく、AIが得意な部分を運用に入れる。
人間は、方針と制約を決める。
これも、Codex × Google APIで事業集計を報告してもらう仕組み と同じ考え方だと思っている。
X自動投稿は、発信運用の小さなOSになった
今回やったことは、こうやって書くと地味。
X APIで投稿していたものをやめて、Codex、Google Sheets、Chromeで投稿するようにした。
それだけのこと。
でも、実際には少し違って、決まった文面を自動で流す仕組みから、AIが記事を読み、文面を考え、タグを選び、投稿結果まで返す仕組みに変わった。
これは単なるAPI代替ではない。
発信運用の一部を、AIチームに渡した感じがある。
もちろん、まだ荒いところはあって。
Chrome操作は画面変更に弱い。
ログイン状態にも依存する。
毎回完璧な文面が出るわけでもない。
でも、ひとりで記事を書き、公開し、告知し、次の記事に進むには、このくらいの仕組みがかなり助かる。
僕が作っているのは、全部を自動化する仕組みではない。
ひとり事業の中で、毎回ちょっと面倒で、でも続けたい作業を、AIチームと一緒に回せるようにすること。
X自動投稿も、そのひとつになった。
旧記事では、GASとX APIで自動投稿を作った。
今回はそれを、CodexとAIチーム運用に作り替えた。
同じ「自動投稿」でも、だいぶ意味が変わってきたと思う。
ポチップ
