スレッズの自動投稿

ほかの作り方：自分用の管理画面を作る

確認した原稿を、決めた日時に投稿する

細かい手順を最初から全部決める必要はありません。まずはCodexに、作りたいものと今の状況をざっくり伝えてください。必要な確認をしながら、あなたに合う順番を提案してくれます。

自分用のThreads自動投稿ツールを作りたいです。
AIが下書きを作り、私が確認して承認した原稿だけを、指定した日時に投稿できるようにしたいです。
まず現在の環境と、すでに持っているアカウントや素材を確認してください。
いきなり全部作らず、Metaへのログイン、公式APIでの1件投稿、最小の管理画面、自動投稿の順に、小さく確認しながら進めてください。
二重投稿と勝手な課金を防ぎ、外部への投稿や権限変更の前には私に確認してください。
決めたことと、次にやることを作業メモに残してください。

1. どこまで作るか決める
2. Metaへ入れるか確かめる
3. 公式APIで1件投稿する
4. 管理画面を作る
5. 投稿事故を防ぐ
6. 必要な機能を育てる

投稿内容を作る仕組みは、先に別の手順で整えられます。

Threadsとインスタの発信を作る

01　最初に、どこまで作るか決める

同じ自動投稿でも、必要な仕組みは人によって違います。最初から調査、文章生成、分析まで入れません。

自分だけで使うのか、ほかの人のThreadsも接続するのかも先に決めます。ほかの人へ提供する場合は、Metaの審査やログイン画面が関係します。

Threads自動投稿について、私が最初に作る範囲を一緒に決めてください。
自分だけで使うのか、ほかの人にも提供するのかを確認してください。
最初は、下書き、本人の承認、予約投稿、投稿結果の確認までに絞ってください。
調査やAIの自動提案は、後から追加する前提にしてください。
候補の構成、必要なアカウント、追加費用、難しさを比べて提案してください。

確認すること
最初に作る範囲と、誰が使うものかを説明できる。

02　Metaへログインできるか確認する

アプリを作る前に、Facebook、Meta for Developers、投稿したいThreadsの3つへ入れるか確認します。ここで止まると、その先の設定へ進めません。

• Facebookへログインできる
• Meta for Developersを開ける
• 投稿したいThreadsアカウントへ入れる
• 必要な本人確認を完了できる

Meta for Developersを開く

Threads APIを使う前のログイン確認を手伝ってください。
私の実際の画面を見ながら、Facebook、Meta for Developers、投稿したいThreadsアカウントへ入れるかを一つずつ確認してください。
画面名や場所を推測せず、現在の表示に合わせて案内してください。
パスワード、認証コード、本人確認情報は私が入力します。
この段階ではアプリ作成や権限変更をしません。

確認すること
3つの画面へ入れて、どのアカウントで作るか分かる。

03　MetaアプリとThreadsの接続を準備する

Metaの開発者画面でアプリを作り、用途にThreadsを追加します。管理画面の名称や配置は変わることがあるため、実際の画面と公式手順を見ながら進めます。

1. Metaアプリを作る
2. Threadsの用途を追加する
3. threads_basic と threads_content_publish を確認する
4. 自分のThreadsアカウントをテスターとして追加する
5. Threads側でも招待を承認する
6. ユーザートークンを発行し、長期トークンへ交換する
7. トークンをコードやGitHub以外の安全な場所へ保存する

長期トークンの有効期間は、現在の公式例では60日です。期限が切れる前に更新する仕組みも後で加えます。

Metaのアプリ管理を開く
Threads APIの公式手順を見る

自分のThreadsへ投稿するMetaアプリの準備を手伝ってください。
Meta公式の最新情報と、私の実際の画面を確認しながら、一つずつ案内してください。
アプリ作成、Threadsの用途、threads_basic、threads_content_publish、テスター追加、Threads側での承認、ユーザートークン、長期トークンの順に確認してください。
自分専用のテストに審査が必要かも、その時点の条件で確認してください。
トークンやアプリシークレットを、チャット、スクリーンショット、コード、GitHubへ表示しないでください。
外部への公開や権限変更の直前には、内容を説明して私に確認してください。

確認すること
接続するThreadsアカウント、権限、トークンの期限が分かる。

04　仕組みを作る前に、文章を1件投稿する

管理画面やAI機能を作り込む前に、公式APIから自分のThreadsへ文章を1件投稿します。ここで接続と権限を確かめます。

現在の公式APIでは、文章投稿に auto_publish_text を使えるため、文章は1回の処理で公開できます。画像や動画は準備状態の確認が必要になるため、文章とは分けて後で試します。

Threads APIの接続確認として、文章を1件だけ投稿するテストを作ってください。
最新のMeta公式仕様を確認し、文章投稿ではauto_publish_textを使えるか確認してください。
最初は送信せず、投稿先アカウント、本文、必要な権限を私に見せてください。
私が公開を了承した後にだけ、1件を投稿してください。
投稿後はThreadsの画面、返された投稿ID、投稿URLを確認してください。
失敗した場合は、同じ本文をすぐ再送せず、実際に投稿されていないか先に確認してください。

確認すること
自分のアカウントへ1件投稿でき、投稿IDを取得できる。

05　最小の管理画面を作る

APIでの投稿が確認できてから、下書きと予約を管理する画面を作ります。技術は先に固定せず、今の環境と使う人数からCodexに提案してもらいます。

画面付きのアプリにする場合は、ログイン、データベース、秘密情報、定期実行を一か所で扱える構成が候補です。NagiではNext.jsとSupabaseを使いました。自分専用の小さな運用なら、さらに簡単な構成も選べます。

見送り、失敗、取消、要確認も用意します。本文や日時を直した投稿は、再承認が必要な状態へ戻します。

公式APIでの1件投稿が確認できました。次に、自分用の最小の管理画面を設計してください。
必要な機能は、ログイン、下書き保存、本文編集、採用・見送り、予約日時、状態、投稿結果です。
状態は、下書き、承認済み、予約済み、投稿中、投稿済み、見送り、失敗、取消、要確認を使います。
本文や日時を変更したら再承認へ戻してください。
認証情報をブラウザへ渡さず、本人のデータだけを表示してください。
現在の環境を調べ、候補の構成、追加費用、難しさを比べてください。
設計書を先に作り、別のAIにもレビューできる形にしてください。まだ実装しないでください。

確認すること
設計書に画面、データ、投稿状態、認証情報の保管場所が書かれている。

06　二重投稿を防いでから、自動化する

自動投稿で最も先に守るのは、二重投稿を出さないことです。同時に2つの処理が動いても、同じ投稿を選ばない仕組みにします。

1. 予約投稿を取り出すときに、データベースで鍵をかける
2. 投稿中のまま止まった処理を見つける
3. 通信エラーでも、すぐに再投稿しない
4. 自分の直近の投稿に同じ本文がないか確認する
5. 結果が分からない場合は要確認で止める

Supabaseを使う場合は、予約投稿の取り出しを原子的な処理にし、同時実行時に同じ行を選ばないようにします。別の構成を使う場合も、同じ考え方が必要です。

予約投稿の二重送信を防ぐ設計を最優先で確認してください。
同時に2つ動いても同じ投稿を取らない、原子的な取り出しにしてください。
投稿前に状態を投稿中へ変え、処理IDと開始時刻を保存してください。
通信エラーやタイムアウトでは自動で再送せず、直近のThreads投稿に同じ本文がないか確認してください。
投稿済みなら結果を記録し、分からない場合は要確認で止めてください。
投稿中のまま止まったものを回収する条件も設計してください。
この処理のテスト項目を先に作り、二重投稿が起きないことを確認してから定期実行へ進んでください。

確認すること
同時実行、通信切断、途中停止のテストで二重投稿されない。

07　定期実行と、止める仕組みを作る

手動での予約投稿が安定してから、5分ごとなどの定期実行を追加します。NagiではSupabase CronからEdge Functionを呼ぶ構成にしました。

投稿直前に、緊急停止、投稿可能時間、1日の上限、空の本文、文字数、NGワード、連絡先、直近の似た投稿を確認します。

• 全体を止める緊急停止スイッチ
• 投稿ごとの取消
• 1日の投稿上限
• 処理する件数の上限
• トークン期限の確認と更新
• 失敗と要確認を見つける画面

無料枠は、現在の上限内で使えるという意味です。ずっと無料を保証する表現にはしません。利用量の上限を超えそうなときは、自動で止めて人が判断します。

手動の予約投稿と二重投稿防止のテストが通りました。定期実行と安全機能を追加してください。
現在の構成に合う定期実行方法を選び、5分ごとを目安に予約済みだけを確認してください。
緊急停止、投稿可能時間、1日の上限、1回の処理件数、取消を用意してください。
空の本文、文字数、NGワード、電話番号やメールアドレス、直近の似た投稿を確認してください。
トークンの期限と更新方法、失敗と要確認の見つけ方も用意してください。
無料枠と現在の料金を公式情報で確認し、上限前に停止する条件を設計してください。
定期実行を有効にする直前に、私へ対象と影響を説明してください。

確認すること
定期投稿、停止、取消、上限、トークン切れを実際に試せる。

08　安定してから、AIの提案機能を育てる

投稿の仕組みが安定したら、AIによるテーマ提案や調査を追加します。最初から必須にはしません。

• Obsidianの経験や過去投稿からテーマを出す
• 過去の投稿から本人の口調を整理する
• 見送った理由を、次の提案で避ける
• 最近の投稿から、言葉の変化を更新する
• 必要な場合だけApifyなどで公開情報を調べる
• 実測値とAIの推測を分けて表示する

ローカルAI、競合投稿の点数計算、Xの巡回などは発展機能です。本人が必要だと判断してから追加します。

自動投稿が安定しました。次に、AIの提案機能を一つずつ追加したいです。
Obsidianの材料、過去の投稿、本人の言葉のルールを先に確認してください。
まずテーマを3案出し、本人が選んだ案だけを下書きにしてください。
見送った理由は本人に確認し、次回の提案で避けるルールとして保存してください。
外部リサーチは必要性を説明し、取得先、取得できる情報、料金を確認してから提案してください。
実際に取得した数値とAIの推測を、画面ではっきり分けてください。
一度に複数機能を追加せず、1機能ごとにテストしてください。

確認すること
追加した機能が、本人の確認を飛ばさずに動く。

このページの使い方

最初は、ページ上部の短い依頼文だけで大丈夫です。Codexが確認しながら道筋を作ります。途中で止まったときや、説明が足りないときに、該当する工程の依頼文を使ってください。

公式の確認先

• Meta：認証と投稿のAPI
• Meta：Threads APIの変更履歴
• Supabase：定期実行
• Supabase：無料プロジェクトの一時停止

仕様の確認日：2026年9月18日。管理画面の名称、料金、制限は変更されることがあります。実際に作るときに公式情報を確認します。

原稿づくりの手順に戻る
実践15に戻る