前章の【SNS編①】では、X（旧Twitter）の自動投稿と、その最大の悩みである「課金の判断」について書きました。この章はその続き、Threads編です。結論から言うと、Threadsではお金の悩みがまるごと消えます。Threadsへの投稿は無料だからです。 そのかわり、Xにはなかった別の"つまずきどころ"がいくつも待っていました。今回はそこを実体験ベースでお届けします。
なお、SNSの仕様は変わりやすい分野です。この記事は2026年8月時点の内容なので、実際に始めるときは各サービスの公式情報で最新の仕様を確認してください。
X編とここが違う——3つのポイント
同じ「SNSの自動投稿」でも、XとThreadsは性格がかなり違います。要点は3つです。
- 投稿が無料：X編で説明したとおり、Xは投稿するたびに従量課金が発生しました。Threadsは投稿そのものにお金がかかりません。だから「何を自動で流すか」をコストで線引きする必要がありません。
- リンクを貼るペナルティが緩い：Xでは記事URLを貼る投稿の単価が跳ね上がるので、リンク付き投稿は手動にしていました。Threadsは無料なので、記事やnoteへの導線も気兼ねなく置けます。
- 代わりにトークン管理が主題になる：お金の心配が消えたぶん、Threadsでは「アクセス用の合言葉（トークン）が期限切れにならないよう管理し続ける」ことが、いちばんの技術的テーマになりました。
安全策の考え方——1日の上限、テスト用の"投稿せず中身だけ見る"モード、環境変数ひとつの緊急停止スイッチ——は、X編で組んだものとまったく同じ発想でそのまま流用しています。 ここは繰り返さないので、詳しくはSNS編①（X）をご覧ください。この章では、Threadsならではの部分だけを掘り下げます。
Threadsの投稿は"2ステップ"
まず面食らったのが、投稿の手順そのものの違いです。
Xは、投稿したい文章を1回送れば、それで公開されます。ところがThreadsは、投稿が2段階に分かれています。 ざっくり言うと、
- まず「これから出す投稿の下書き（入れ物）」をサーバー側に作る
- その入れ物を「公開する」と指示して、初めて世に出る
という2ステップです。1ステップ目で投稿の"箱"を用意し、2ステップ目でその箱を公開する、というイメージです（この"箱"を専門的にはメディアコンテナと呼びます）。慣れれば何ということはないのですが、Xの「1発で送信」に慣れていると、最初は「なぜ2回に分けるのか」と戸惑いました。仕組みを組むときも、1ステップ目で作った箱の識別番号を受け取り、それを2ステップ目に渡して公開する、という受け渡しを間違えないように気をつける必要があります。
長い話を分けて届ける"ツリー投稿"
Threadsで力を入れたのが、ツリー投稿です。
SNSの1投稿には文字数の上限があります。でも「へぇ」で終わる小ネタだけでなく、少し長めの実録や考え方も届けたい。そこで、1つの話題を「親の投稿」と、それにぶら下げる「返信（リプライ）」に分けて、数珠つなぎに投稿する設計にしました。最初に要点だけの短い親投稿を出し、その直後に続きを返信としてぶら下げていく——読む人は上から順に、一連の流れとして読めます。
仕組みとしては、親を投稿したあと、1〜3分ほど間隔をあけて返信を1本ずつ、直前の投稿にぶら下げてつなげています。間隔をあけているのは、機械的な連続投稿に見せないための配慮です。もし途中の返信が失敗しても、少なくとも親投稿だけは成立するようにして、通知で知らせるようにしました。全部が一度に飛ぶより、こういう「一部が失敗してもリカバリーできる」作りにしておくほうが、無人運用では安心です。
60日で切れるトークンを、切らさずに回す
Threadsで一番の"主題"がこれです。
Threadsに自動で投稿するには、「このプログラムはあなたの代わりに投稿していいですよ」という許可証にあたるトークンが必要です。そしてこのトークンには約60日という有効期限があります。放っておくと2ヶ月で切れて、ある日突然、投稿がすべて止まります。
そこで、期限が切れる前に自動でトークンを更新し続ける仕組みを入れました。毎週1回、決まったタイミングでトークンを"延長"し、新しいものに置き換えます。ここで神経を使ったのは、トークンは機密情報だという点です。更新のたびに設定ファイルの中のトークンだけを書き換えるのですが、「その1行以外は1文字も変わっていない」ことを毎回確認し、もし更新に失敗したら元に戻すようにしています。設定ファイルは他の大事な値も入っている場所なので、自動書き換えを雑にやると事故のもとです。ここは慎重にしすぎるくらいでちょうどよい、と考えました。
Xの課金と対照的に、Threadsは「お金はかからないが、放っておくと合言葉が切れて止まる」。コストの管理から、期限の管理へ——これがThreadsで頭を切り替えた一番のポイントでした。
権限でつまずいた話
きれいに動いたわけではなく、ここでも回り道がありました。とくに「権限まわり」で2回つまずいています。
1つ目は、アカウントの識別番号（ユーザーID）の取り違えです。 最初、設定に入れていたIDが、実は"投稿には使えない種類のID"でした。見た目は同じ数字の羅列なので気づきにくく、投稿しようとしても弾かれ続けました。公式の「自分の情報を返す」問い合わせで正しいIDを取り直して差し替えたら、あっさり通りました。同じ番号に見えても用途の違うIDがある——これは知らないとハマるポイントです。
2つ目は、追加した権限がトークンに反映されない問題です。 Threadsには「キーワードで投稿を検索する」機能があり、これを使って「自動化やAI副業について発信している人」を見つけて、こちらから丁寧に会話のきっかけを作れないか、と考えていました（返信そのものは、スパムにならないよう手動でやる方針です）。ところが、その検索機能を呼ぶと「アプリに権限がありません」というエラーが返り続けました。機能を使う権限を管理画面で足しただけでは不十分で、その権限を含めてトークンを発行し直さないと有効にならない、という仕様だったのです。この"リプ候補の発見"機能は、権限の再発行が必要な作業として、今も保留にしています。
こういう「設定したはずなのに効かない」は、外部サービスのAPIを触っていると必ずぶつかります。エラーメッセージを額面どおりに読み、公式ドキュメントに立ち返るのが結局いちばんの近道でした。
そもそも"何を投稿するか"を先に決めた
最後に、技術の話から少し離れます。自動投稿の仕組みをどれだけ丁寧に組んでも、「何を投稿するか」が決まっていなければ意味がありません。 これはThreadsを始めて痛感したことです。
そこで、投稿の"型"と、それぞれをどれくらいの比率で流すかを先に設計しました。たとえば「自動化の実録」「考え方」「注意喚起」「その日拾った最新情報」「共感を呼ぶ短い話」「noteやブログへの誘導」といった型を用意し、それぞれの割合を決めておく。こうしておくと、毎回ネタに悩まず、かつ「宣伝ばかり」「小ネタばかり」と偏らないバランスで投稿を続けられます。
運用を始めてからは、反応の指標を「いいねの数」ではなく「どれだけ見られたか（閲覧数）」に切り替え、鮮度の高い最新情報を主軸に置く形へと調整しました。自動化は「組んで終わり」ではなく、数字を見ながら中身の比率を変えていく——このあたりの手触りは、ブログ本体をリライトで育てるのと同じでした。
まとめ——課金のX、期限のThreads
SNS編を2章に分けた理由が、ここまで読むと伝わったのではないかと思います。
- Xは、投稿するたびにお金がかかる。だから「何を自動で、何を手動で」をコストで線引きするのが主題でした。
- Threadsは、投稿は無料。そのかわり、トークンの期限を切らさない管理と、2ステップ投稿・ツリー投稿・権限まわりといった実装の作法が主題でした。
技術的な性質がここまで違うので、1本にまとめずに正解でした。共通しているのは、「暴走とトラブルを前提に、安全側へ倒す」という安全策の設計思想だけ。それはX編で書いたとおり、そのままThreadsにも持ち込んでいます。
実際に動いているThreadsアカウントはこちらです。毎日、雑学や拾いたての最新情報が自動で投稿されています。仕組みの"実物"として、のぞいてみてください。
https://www.threads.com/@trivipedia_jp
連載のはじまりは序章から、前章のX編はSNS編①からどうぞ。
なお、この仕組みを「AIに丸投げ・コピペ」でそのまま再現できるファイル集（指示書・スクリプト・設定の一式）を公開しました。あなたが選んだテーマで、同じ仕組みを動かせます。→ AIブログ自動化キットを見る（note）
