ブログを書いたあとに、Threadsにも投稿したい。けれど、毎回手作業で文案を作り、URLを貼り、投稿するのは地味に手間がかかります。特に個人ブログを継続運用していると、記事を書く作業そのものよりも、公開後のSNS共有で手が止まることがあります。
そこで今回は、WordPressブログ「半農エンジニアラボ」の運用実験として、Threads APIを使ってブログ記事をThreadsへ投稿する仕組みを作りました。ただし、最初から完全自動投稿にはしていません。今回の主役は「自動化」そのものよりも、「誤投稿しないための半自動化」です。
実際にやったことは、Threads APIのアクセストークン取得、.env への安全な保存、投稿前の DryRun、人間確認後の -ConfirmPost、そして公開済みブログ記事のThreads投稿です。途中でMetaの画面に迷ったり、リダイレクトURIが保存できなかったり、ユーザーIDの値が違っていたりと、かなり実験ログらしいつまずきもありました。
この記事では、きれいな完成手順だけでなく、実際につまずいたポイントも含めて整理します。Threads APIの画面や仕様は変わる可能性があるため、最終的な確認はMeta公式ドキュメントを見てください。この記事は、個人ブログ運用者が「こういう流れで組めば安全に始められる」という実践記録として読んでもらえればと思います。
結論：完全自動投稿ではなく、確認つき半自動投稿にした
今回作った仕組みの結論は、次の形です。
- Threads APIのアクセストークンは
.envに保存する - 投稿文案はMarkdownファイルとして残す
- 投稿前に必ず
-DryRunで内容を確認する THREADS_AUTO_POST_ENABLED=trueかつ-ConfirmPostの時だけ投稿する- WordPress下書きURLや認証情報が含まれていたら投稿前に止める
つまり、ボタン一発で毎回勝手に投稿する仕組みではありません。人間が見て「この文面なら投稿してよい」と確認した時だけ、Threads APIへ投稿する設計です。
この判断にした理由はシンプルです。SNS投稿は外部に公開されるからです。WordPress下書き保存なら、間違ってもまだ非公開です。しかしThreads投稿は、実行した瞬間に公開されます。ブログ運用を自動化するほど、公開まわりには安全弁が必要になります。
今回のゴール
今回のゴールは、次の3つでした。
- Threads APIのアクセストークンを取得し、ローカル環境からAPI接続できること
- Codexで作った投稿文案を、DryRunで確認できること
- 公開済みWordPress記事のURLを含むThreads投稿を、明示操作で実行できること
最終的には、公開済み記事「Codex Automationsの設定方法：ブログ運用を毎日7:00と12:00に回すまでの記録」をThreadsへ投稿できました。最初のテスト投稿は動作確認用だったため、投稿後に削除しました。テスト投稿を削除したことも含めて、今回はよい検証になりました。
先に決めた安全ルール
実装前に、まずThreads投稿の運用ルールを決めました。これは地味ですが、かなり大事です。API連携では、コードを書く前に「何をしてよいか」「何をしてはいけないか」を決めておかないと、動いた瞬間に危ない仕組みになります。
今回決めた主なルールは以下です。
- WordPress下書きURLはThreadsへ投稿しない
- 公開済み記事URL、またはURLなしの実験ログだけを投稿対象にする
- アクセストークンやApp Secretはリポジトリへ直書きしない
.envまたは環境変数で秘密情報を扱う- 初期状態では自動投稿を無効にする
- 人間が内容を確認した後だけ投稿する
このルールは、リポジトリ内の docs/threads-post-policy.md に残しました。あとから自分で見返すためにも、ルールを文章にしておくのはおすすめです。自動化は、時間が経つと「なぜこうしたのか」を忘れます。忘れた頃に誤操作するので、先にルールを書いておきます。
Threads APIの準備でつまずいたところ
最初につまずいたのは、アクセストークン取得です。
Threads APIでは、投稿するためにアクセストークンが必要です。Meta for Developersの画面でアプリを作り、Threads APIのユースケースを追加し、必要な権限を設定します。投稿に必要な権限としては、少なくとも threads_basic と threads_content_publish が関係します。
ただ、この「権限で認可URLを開く」という表現が分かりにくい。実際には、URLの scope に次のような値を入れて、Meta/Threads側に「この権限を許可してください」と伝える意味です。
scope=threads_basic,threads_content_publish認可URLの例は次のような形です。
https://threads.net/oauth/authorize?client_id=APP_ID&redirect_uri=REDIRECT_URI&scope=threads_basic,threads_content_publish&response_type=codeここで使う client_id は、Metaアプリの基本設定にあるアプリIDではなく、Threads APIの設定画面に出てくる「ThreadsアプリID」を使う場面がありました。このあたりは画面の見え方によって迷いやすいです。
さらに、リダイレクトURIの登録でも詰まりました。Metaの画面で「OAuthリダイレクトURIを記入してください」と出るのに、どこへ何を入れれば保存されるのかが分かりにくい。今回はそのルートに時間を使いすぎず、画面下部にある「ユーザートークン生成ツール」を使うルートに切り替えました。
結果的には、「Threadsテスター」を追加し、ユーザートークン生成ツールからアクセストークンを取得する方法で進めました。個人で自分のThreadsアカウントに投稿するテストなら、このルートがかなり分かりやすいです。
.envに入れた値
アクセストークンが取れたら、リポジトリには直接書かず、.env に保存します。実際の値は秘密情報なので、この記事にも書きません。
THREADS_API_BASE_URL="https://graph.threads.net/v1.0"
THREADS_USER_ID="your-threads-user-id"
THREADS_ACCESS_TOKEN="your-threads-access-token"
THREADS_AUTO_POST_ENABLED="false"
THREADS_REQUIRE_CONFIRM_POST="true"
THREADS_API_TIMEOUT_SECONDS="30"ここで大事なのは、最初は必ず THREADS_AUTO_POST_ENABLED="false" にしておくことです。これが false の間は、投稿スクリプトを実行しても実投稿前に止まります。
また、アクセストークンはチャットにも貼らないようにしました。AIに作業を手伝ってもらう場合でも、トークンそのものは渡さない。ローカルの .env に置き、スクリプトだけが読む形にします。
トークン確認用スクリプトを作った
アクセストークンが有効かどうかを確認するために、投稿とは別に scripts/check-threads-token.ps1 を作りました。このスクリプトは、Threads APIの /me を呼び出して、ユーザーIDとユーザー名を確認するだけです。投稿はしません。
確認結果では、最初に .env に入っていた THREADS_USER_ID と、アクセストークンから返ってきた実際のユーザーIDが一致していませんでした。トークン自体は有効でしたが、投稿用に使うユーザーIDが違っていたわけです。
そこで、APIから返ってきた正しいユーザーIDに .env を更新し、もう一度確認しました。最終的には、ユーザー名 kobashin29 のアカウントとしてAPI接続が成功し、env_user_id_matches=true になりました。
この確認ステップはかなり重要です。アクセストークンが有効でも、ユーザーIDが違うと投稿時に失敗する可能性があります。投稿の前に /me で本人確認しておくと、原因切り分けが楽になります。
投稿用スクリプトの考え方
投稿スクリプトは scripts/publish-threads-post.ps1 として作りました。役割は、Markdownファイルから投稿文を読み取り、Threads APIへ投稿することです。
ただし、すぐには投稿しません。まず投稿文を取り出し、危ない内容が含まれていないか簡単にチェックします。
- 本文が空ではないか
- 文字数が長すぎないか
wp-adminやpreview=trueなど下書きURLらしい文字列を含んでいないかTHREADS_ACCESS_TOKENやOPENAI_API_KEYなど秘密情報名を含んでいないか
さらに、実投稿には2つの条件を付けました。
THREADS_AUTO_POST_ENABLED=true
-ConfirmPost を指定するこの2つがそろわない限り、スクリプトは投稿を拒否します。実際、最初のテストでは THREADS_AUTO_POST_ENABLED の指定がうまく効かず、スクリプトが「投稿不可」と判断して止まりました。これは良い止まり方です。危ない時に止まるのが安全弁の仕事です。
DryRunで投稿前確認する
実投稿の前には、必ず -DryRun を実行します。
powershell -ExecutionPolicy Bypass -File scripts/publish-threads-post.ps1 -PostFile drafts/your-threads-post.md -DryRunDryRunでは、実際の投稿は行わず、読み取った投稿文、文字数、自動投稿フラグの状態だけを確認します。今回のテストでは、次のように確認できました。
auto_post_enabled: false
投稿内容チェック: OK
実投稿: なしこの段階で、文章が変だったり、URLが下書きURLだったり、ハッシュタグが多すぎたりしたら直します。SNS投稿は短いですが、短いぶんミスが目立ちます。DryRunを一度挟むだけで、かなり安心感が変わります。
テスト投稿と削除
最初は、本番記事の紹介ではなく、API連携のテスト文を投稿しました。
Threads API連携のテストです。
WordPressブログ運用を、下書き作成からSNS共有まで安全に半自動化する実験を進めています。このテスト投稿は成功しました。Threads APIから container_id と threads_post_id が返ってきたため、投稿自体はできていると判断できました。
ただし、この投稿はテストなので、確認後に手動で削除しました。ここも大事な運用ポイントです。API実験では、テスト投稿を残すか消すかも事前に決めておいた方がよいです。今回はブログ運用の実験としては価値がありますが、読者向けの投稿として残す必要はないため削除しました。
公開済みブログ記事をThreadsへ投稿した
テストが通ったあと、公開済みブログ記事をThreadsへ投稿しました。対象にしたのは、次の記事です。
Codex Automationsの設定方法：ブログ運用を毎日7:00と12:00に回すまでの記録
投稿文は、単なる「記事を書きました」ではなく、記事の中身が分かるようにしました。
Codex Automationsで、ブログ運用を毎日7:00と12:00に回す設定をまとめました。
調査、記事案づくり、WordPress下書き保存までをどう分けるか。
「完全自動化」よりも、下書きと人間確認を残す半自動運用の実験ログです。この投稿も、まずDryRunで確認してから実投稿しました。投稿後には threads_post_id が返り、Threads側でも投稿できたことを確認しました。
なお、公開済み記事は他にもありましたが、連投にならないよう最新1本だけ投稿しました。APIで投稿できるようになると、ついまとめて流したくなります。しかし、SNS運用としては投稿間隔も大事です。自動化できることと、全部すぐ自動化すべきことは別です。
今回作ったファイル
今回の実験で作った主なファイルは以下です。
docs/threads-post-policy.md：Threads運用ルールdocs/threads-access-token-guide.md：アクセストークン取得メモscripts/check-threads-token.ps1：トークン確認スクリプトscripts/publish-threads-post.ps1：Threads投稿スクリプトtemplates/threads-post-template.md：投稿文案テンプレートdrafts/2026-06-23-codex-automation-settings-guide-threads.md：実際に投稿した文案
このように、投稿スクリプトだけでなく、ルール、テンプレート、検証メモも一緒に作りました。自動化はコードだけではなく、運用ルールまで含めて仕組みです。
SE視点：安全弁は最初から入れる
SE視点で見ると、今回いちばん大事だったのは安全弁です。
API投稿は、動くようにするだけならそれほど難しくありません。アクセストークンを取り、エンドポイントへPOSTすれば投稿できます。しかし、実運用では「投稿してはいけないものを投稿しない」方が重要です。
今回の仕組みでは、DryRun、THREADS_AUTO_POST_ENABLED、-ConfirmPost の3段階で止まれるようにしました。さらに、本文に下書きURLや秘密情報らしい文字列があれば止めます。
この設計は、WordPress下書き保存の運用とも相性がよいです。ブログ記事本文はWordPressに draft で保存し、SNS投稿は公開後のURLだけを使う。公開前と公開後の境界を明確にしておくと、自動化しても事故が起きにくくなります。
PT視点：作業負荷を減らす設計にも意味がある
理学療法士としての視点を入れるなら、これは身体ケアの記事ではありませんが、作業負荷の分散という意味では身体にも関係します。
ブログを書き、WordPressに整え、SNS文案を考え、投稿する。ひとつひとつは小さな作業ですが、毎日積み重なるとかなりの認知負荷になります。疲れている時ほど、URLの貼り間違いや、下書きURLの共有ミスが起きやすくなります。
そこで、文案生成、DryRun、投稿実行を分けておくと、確認すべきことが明確になります。これは身体のセルフケアでいう「無理のない姿勢を先に作る」ことに近い感覚です。気合いでミスを防ぐのではなく、ミスしにくい環境を先に作る。デスクワークにもブログ運用にも、この考え方は効きます。
農・生活視点：一気に全自動化しない
半農や家庭菜園の視点で見ると、今回の自動化は「畑の仕組みづくり」に似ています。
畑でも、最初から大規模にやろうとすると失敗しやすいです。まず小さく畝を作り、種をまき、水の流れを見て、虫や天気の影響を観察する。うまくいったら少し広げる。今回のThreads投稿も同じで、いきなり画像投稿、予約投稿、複数記事の連投まで広げるのではなく、まずテキスト投稿1本から始めました。
自動化は便利ですが、生活に組み込むには「観察できる小ささ」が必要です。今回のようにテスト投稿を行い、削除し、公開済み記事を1本だけ投稿する。このくらいの小さな実験から始める方が、長く続けやすいと感じました。
今後やりたい改善
今回で、テキスト投稿の基本ルートは確認できました。次に改善したいのは以下です。
- WordPress公開済み記事の一覧から、未投稿の記事だけを選ぶ
- Threads投稿済みIDをログに残す
- 同じ記事を二重投稿しない仕組みを作る
- アイキャッチ画像付き投稿に対応する
- 投稿文案を3パターン作り、人間が選べるようにする
- 公開直後ではなく、時間を置いて投稿する運用を考える
ただし、予約投稿や完全自動投稿は慎重に扱います。ブログ記事の内容によっては、医療・健康・農薬・税金・法律など、表現に注意が必要なものもあります。このブログでは、そうした記事を人間確認なしでSNSへ流す設計にはしません。
まとめ
今回は、Threads APIを使ってWordPressブログ記事をThreadsへ半自動投稿する仕組みを作りました。
実際にやってみると、難しかったのはAPI投稿そのものよりも、アクセストークン取得と運用設計でした。Metaの画面でリダイレクトURIの扱いに迷ったり、ThreadsアプリIDと通常のアプリIDの違いに戸惑ったり、ユーザーIDの不一致を確認したりと、実験ログとして残す価値のあるポイントがいくつもありました。
最終的には、.env に保存したアクセストークンでAPI接続し、DryRunで投稿内容を確認し、-ConfirmPost 付きで公開済み記事をThreadsへ投稿できました。
今回の学びは、「SNS投稿の自動化は、最初から完全自動にしない方がよい」ということです。下書き、確認、実行を分ける。秘密情報はファイルに直書きしない。下書きURLは投稿しない。こうした地味なルールが、ブログ運用を長く続けるための土台になります。
半農エンジニアラボでは、今後もこうしたAI・WordPress・SNS運用の実験を、うまくいったことだけでなく、詰まったところも含めて記録していきます。
