結論から書きます。私が自動化で止まった原因のうち、いちばん厄介だったのはコードのバグではなく、認証情報の「置き場所」と「読み方」でした。APIキーやトークンは、値そのものが正しくても、保存されているファイルの文字コードや、何行目まで読むか、いつ切れるかで簡単に事故ります。しかもこの手の事故は画面上に何も出ません。エラーが赤く表示されるわけでもなく、ただ投稿が出ていないだけ、という形で現れます。
私は元調理師で、飲食の現場に10年いました。そこからSNS運用代行のフリーランスとして独立して、いまは在宅で仕事をしています。プログラミングの専門教育を受けたわけではなく、2026年6月から自分の投稿の自動化を組み始めて、まだ2ヶ月ほどです。だからここに書くのは「正しい設計論」ではなく、実際に自分が踏んだ穴と、そのあと何を変えたかという記録です。同じところで止まる人が少しでも減ればと思って書いています。
認証情報の事故は「エラーが出ない」から怖い
プログラムが止まるとき、たいていはエラーメッセージが出ます。出てくれるなら、それを読んで直せばいい。私が手こずったのは、そうならないパターンでした。認証まわりの失敗は、失敗として表に出てこないことがあるんです。
私はThreadsに1日5本、Xにも同じ時間に1日5本を全自動で投稿しています。Windowsのタスクスケジューラーで時間を決めて、Pythonのスクリプトを走らせて、APIを直接叩く作りです。毎朝6時台にAIが投稿文をまとめて生成してGoogleドライブにテキストで置き、投稿スクリプトはそれを読んで投げるだけ。構造としてはとても単純です。
単純だからこそ、認証が通らなければ全部が止まります。そして認証が通らない理由は、たいてい値が間違っているからではありませんでした。値は合っている。合っているのに通らない。この状態を自分で見つけるのが、いちばん時間がかかりました。
「動いていない」ことに気づくまでの時間が長い
2026年7月3日から5日まで、Threadsの投稿が1本も出ていませんでした。このときの直接の原因は早朝にPCがスリープしていて、6時の生成スクリプトが走れなかったことです。認証の話ではありませんが、構造は同じでした。失敗が失敗として通知されない限り、自分は「動いているつもり」でいるということです。
いまは投稿が失敗したらログに残り、Discordに通知が飛び、次にPCを開いたときにも報告が上がるようにしています。この仕組みを入れるまでは、自分が数日ぶんの投稿を落としていたことに、あとから集計して初めて気づいていました。
文字コードで止まる：BOMが混ざっていたトークンファイル
認証トークンは、テキストファイルに書いて保存しています。そのファイルにBOMが混ざっていて、投稿が丸ごと止まったことがありました。
BOMというのは、ファイルの先頭に付く目印のような数バイトです。エディタで開いても見た目は何も変わりません。トークンの文字列はちゃんと表示されているし、コピーして目視で比べても違いが分からない。見た目が同じなのに、プログラムが読むと違う値になっているという状態でした。
Windowsでファイルを保存すると、保存の仕方によってはこのBOMが付きます。私は当時そんなものがあることすら知らなかったので、「トークンは合っているのに認証エラーになる」という状況で完全に手が止まりました。値を作り直して貼り直しても、また同じ保存の仕方をすれば同じことが起きます。原因を知らないうちは、何度やり直しても同じ結果でした。
目視で確認できないものは、目視で確認しない
この件から学んだのは単純なことです。目で見て正しいかどうか判断できない対象を、目で見て確認しようとするのをやめる。トークンが正しいかどうかは、実際に短いテストを一回投げて確かめたほうが早い。私はいま、トークンを差し替えたら本番の時間を待たずに一度だけ手動で認証を通してみるようにしています。
飲食にいたころは、味見をすれば分かるものばかりでした。目で見て、匂いを嗅いで、口に入れれば判断できた。認証情報はそれができません。だから確認の方法そのものを、人間の感覚ではなく機械に投げる形へ変える必要がありました。
読み方で止まる：全行つなげて読んでしまった話
もうひとつ、トークンのファイルを全行つなげて読んでしまい、認証エラーになったことがあります。実際に必要だったのは1行目だけでした。
ファイルには、トークンのほかにメモや改行が入っていました。スクリプト側はファイルの中身を全部読んで、それをそのまま認証情報として使っていた。結果として、トークンのうしろに余計な文字がくっついた状態でAPIに送られていたわけです。当然、通りません。
厄介なのは、この失敗も「値が間違っている」というエラーとして返ってくることです。返ってきたメッセージを見ると、まるでトークンそのものが無効になったように読めてしまう。だから私は最初、トークンを作り直しに行きました。作り直しても直りません。原因は保存されている値ではなく、読み込む側にあったからです。
置き場所と読み方はセットで決める
ここから、認証情報のファイルには値以外のものを一切書かないと決めました。メモを残したいなら別のファイルに書く。1ファイルに1つの値だけを入れて、スクリプトは1行目だけを読む。そのうえで前後の空白を落とす。地味ですが、これで読み込み側の事故はほぼ起きなくなりました。
「置き場所を決める」というのは、フォルダを決めることだと思っていました。実際にはそうではなくて、どのファイルに、どの形式で、何を書くか、そしてそれをどう読むかまでをセットで決めないと意味がありません。片方だけ決めても、もう片方でずれます。
期限で止まる：あと10日で切れるところだったトークン
Threadsの認証トークンは60日で切れます。これに気づいたとき、私のトークンはあと10日で失効するところでした。切れたら投稿が全部止まります。1日5本を全自動で回している状態で、ある日を境に全部止まる。しかも切れた瞬間に誰かが教えてくれるわけではありません。
気づいたその日に延長して、ついでに毎月1日に自動で延長する仕組みを入れました。手で延長する運用にしなかったのは、自分が忘れる前提で作らないと意味がないと思ったからです。60日というのは、忘れるには十分すぎる長さでした。
期限があるものは、期限を管理する仕組みごと作る
APIキーやトークンには、期限があるものとないものがあります。私が触った範囲では、Threads側は期限つき、X側は作ったキーがそのまま使えるという形でした。期限つきのものは、値を保存した時点で「いつ切れるか」も一緒に扱わないと、必ずどこかで踏みます。
自動更新にしてしまえば、少なくとも忘れて止まることはなくなります。ただし自動更新そのものが失敗する可能性は残るので、失敗したらDiscordに通知が飛ぶようにしています。更新の仕組みを入れたことで安心しきってしまうと、今度は「更新できていないことに気づけない」という同じ形の事故に戻るからです。
取得画面で止まる：下6桁しか見られなかったAPIキー
XのAPIキーを取りに行ったときの話です。画面には下6桁しか表示されていませんでした。完全な値を見る方法が見つからず、結局いったん作り直すしかありませんでした。
この手のキーは、発行された瞬間にしか全体を表示してくれないことがあります。一般に、セキュリティ上そういう設計になっていると言われています。理屈は分かるのですが、初めて触る側からすると「さっきの画面に戻ればもう一度見られるだろう」と思ってしまう。戻っても見られませんでした。
さらに、キーを作り直す順番を間違えると、後から作ったほうが無効になります。私の場合、親のキーを先に作り直してから、その下のキーを作り直す必要がありました。逆の順番でやると、せっかく取ったキーがすぐ使えなくなる。これも画面には何も出ません。ただ認証が通らないだけです。
発行画面を閉じる前にやること
いま私が決めているのは、キーが表示されている画面を閉じる前に、保存先のファイルへ貼り付けて、保存まで終わらせることです。あとで整理しようと思って別のところに一時的に置くと、その一時的な場所が本番になったり、逆に消えたりします。
そして貼り付けたあと、実際に一度認証を通してみる。ここまでやって初めて「取得できた」と言えると考えています。画面に表示された時点では、まだ何も確かめられていません。
登録したのに動いていない：引数が空になっていた話
2026年8月4日、Xの自動投稿を組んだときの失敗です。タスクスケジューラーには全部「準備完了」と表示されていたのに、実際は一度も動いていませんでした。
原因は、タスクを登録するスクリプトの中で、変数名にPowerShellの予約語を使っていたことでした。そのせいで、タスクに渡す引数が丸ごと空になっていた。タスク自体は正しく登録されているので、画面上は何の問題もありません。エラーもログも残らないので、気づくのに時間がかかりました。
これは認証情報そのものの話ではありませんが、症状はまったく同じです。設定できたように見えて、中身が空。APIキーを環境変数や設定ファイルに入れて渡すやり方をしていると、同じ形の事故が起きます。渡したつもりのものが渡っていない、という状態です。
「準備完了」の表示を信用しない
それ以来、タスクを登録したあとは表示だけで安心せず、渡している引数が空になっていないか毎回確かめるようにしています。登録した直後に一度だけ手で実行して、結果まで見る。ここまでやらないと、登録が成功したことしか確認できていません。
もうひとつ、日付を整える処理でも似たことがありました。パソコンによって使える書き方と使えない書き方があるのを知らずに書いて、機能がまるごと無言でスキップされていたんです。エラーが表に出ない失敗がいちばんこわい、というのはこの手の経験から来ています。
いま自分がやっている置き場所のルール
ここまでの失敗を踏まえて、いま決めていることを書きます。専門家の推奨ではなく、2ヶ月やってみて自分の環境で事故が減ったやり方です。
- 認証情報は1ファイルに1つだけ。メモやコメントは同じファイルに書かない。
- 読み込むときは1行目だけを使い、前後の空白は落とす。
- 保存し直したら、本番の時間を待たずに一度だけ手動で認証を通してみる。
- 期限があるトークンは、自動で延長する仕組みまで含めて作る。
- 自動更新が失敗したらDiscordに通知が飛ぶようにする。
- 発行画面は、保存が終わるまで閉じない。
- キーを作り直すときは、親から先に作り直す。
- タスクを登録したら、表示ではなく実際の動作で確認する。
置き場所そのものについては、私はGoogleドライブを仕組みの受け渡し場所として使っています。ただしドライブに置いているのは投稿文のテキストで、認証情報は同じ扱いにしていません。共有の可能性がある場所と、そうでない場所を分けておくのは最低限だと考えています。
「安全にする」より先に「壊れたときに分かるようにする」
認証情報の管理というと、まず漏らさないための話が出てきます。それは当然として、私が2ヶ月でいちばん困ったのは漏れることではなく気づかないうちに止まることでした。
だから私が優先したのは、暗号化のような高度な仕組みではなく、失敗したら必ずどこかに残る形にすることです。ログに書く、Discordに飛ばす、次にPCを開いたときに報告が上がる。この3つを重ねてやっと、自分が数日気づかないという事態が減りました。
それでも成果は出ていない、という話も書いておく
ここまで仕組みの話をしてきましたが、正直に書くと、私の自動投稿は数字としてはまったく振るっていません。
Threadsは2026年6月25日から7月27日までに87本を自動投稿して、その間フォロワーは0人のままでした。7月27日時点で数えたときの7月のビューは527、いいね7、返信0、リポスト0。返信は一度も来ていません。週ごとの平均ビューは18.2 → 15.9 → 8.4 → 7.9 → 5.0と右肩下がりでした。8月4日までの7日間では24本投稿して合計ビュー120、いいね1、返信0です。
noteのほうも2026年7月27日時点で記事27本、フォロワー2人、全記事の合計いいねは45。決して自慢できる数字ではありません。自動投稿は「続ける力」はくれましたが、「届く力」は別物でした。投稿の質を上げる前に、そもそも誰にも見られていないことのほうが問題だと今は思っています。
それでも認証情報まわりを直したことには意味があると考えています。止まっていたら、そもそも数えることすらできません。数字が出ないことと、仕組みが動いていないことは別の問題です。私はまず後者だけを潰しました。前者はこれからです。
費用の話
参考までに、この自動化にかかっている費用はXのAPI利用料が1日5本の投稿で月350円ほど、ThreadsのAPIは無料、タスクスケジューラーはWindows標準機能なので0円です。認証情報の管理のために追加で払っているものはありません。
まとめ
- 認証情報の事故は、値が間違っているからではなく、文字コード・読み方・期限で起きることがある。
- トークンファイルにBOMが混ざっていて投稿が丸ごと止まったことがある。見た目では分からなかった。
- ファイルを全行つなげて読んで認証エラーになったことがある。必要だったのは1行目だけだった。
- Threadsのトークンは60日で切れる。あと10日のところで気づき、毎月1日に自動延長する仕組みにした。
- XのAPIキーは下6桁しか見られず、作り直すしかなかった。作り直す順番は親から先。
- タスクは「準備完了」と表示されていても、引数が空で一度も動いていないことがある。
- 置き場所を決めるとは、ファイルの形式と読み方までセットで決めること。
- 漏らさない対策より先に、止まったときに必ず気づける形にすることを優先した。
- 仕組みは動くようになったが、数字はまだ出ていない。そこは別の課題として残っている。
コメント