結論から書きます。私は、AIが書いた投稿文をGoogleドライブのフォルダにテキストで置いて、投稿スクリプトはそのテキストを読んで投げるだけ、という形にしています。生成と投稿を直接つながずに、あいだにドライブの同期フォルダを一枚挟んだということです。これで何が楽になったかというと、AIが書いた文章を投稿前に自分の目で見られるようになったこと、投稿が失敗したときに「文章が無かったのか、投げるところで転んだのか」がすぐ分かるようになったこと、この二つが大きいです。
ただし、いいことばかりではありませんでした。挟んだせいで起きた事故もあります。書き込む先を間違えて、告知が一度も出ていなかった時期があります。ファイルの中身が見た目どおりではなくて、投稿が丸ごと止まったこともあります。この記事では、受け渡し場所としてドライブを使うと何が楽になり、どこで転ぶのかを、私が実際にやらかしたことと合わせて書きます。
私は元調理師で、飲食の現場に10年いました。そこからSNS運用代行のフリーランスとして独立して、自動化を組み始めたのは2026年6月です。まだ2ヶ月ほどしかやっていない人間の実践ログとして読んでください。
そもそも何を受け渡しているのか
いま動かしているものを先に説明します。Threadsは1日5本、7時・12時・17時・21時・23時に全自動で投稿しています。Xも同じ時間に1日5本で、こちらは2026年8月4日に動かし始めました。どちらもWindowsのタスクスケジューラーとPythonで、APIを直接叩いています。
この流れの中で、毎朝6時台にAIが1日分の投稿文をまとめて生成します。生成された文章はGoogleドライブの中のテキストファイルとして保存されます。そして7時になると投稿スクリプトが起動して、そのテキストを読んで、投げます。12時も17時も21時も23時も同じで、投稿する側は「書かれているものを読んで投げる」だけしかやりません。
つまり受け渡しているのは、その日の投稿文そのものです。生成する処理と投稿する処理は、お互いのことを何も知りません。知っているのは「どのフォルダのどのファイルを見るか」だけです。
なぜ直接つながなかったのか
最初は、生成してそのまま投げればいいと思っていました。ひとつのスクリプトの中でAIに書かせて、返ってきた文字列をそのままAPIに渡す。処理としてはそのほうが短いです。
それをやらなかった理由は、投稿の直前まで中身が見えないのが嫌だったからです。AIが書いた文章をそのまま出すのは、私の場合こわい。実際に、AIに投稿文を書かせていたら実際とは違う数字を書いてきたことがあります。本当は68本なのに62本と書いていて、しかも文章としては自然なので、読んでも気づけませんでした。生成と投稿が一続きになっていたら、私はその文章を一度も見ないまま公開していたことになります。
朝6時台に生成して、最初の投稿は7時。この1時間のあいだ、文章はドライブの中にテキストとして置かれたままです。私が起きていれば、その時点で開いて読めます。おかしなことが書いてあれば消せます。受け渡し場所を挟むというのは、要するに人間が割り込める隙間を作るということでした。
ローカルのフォルダではだめだったのか
正直に書くと、最初から「ドライブにしよう」と考えて選んだわけではありません。PCの中の適当なフォルダに置いても、同じPCでスクリプトが動いているなら読めます。実際、動き自体はそれで成立します。
ドライブの同期フォルダにしたのは、スマホから中身を見られるからです。私は昼に出かけていることもあるので、外にいるときに「今日の12時の投稿、何が入っていたっけ」と確認したくなることがあります。ローカルのフォルダだと家に帰るまで分かりません。同期フォルダなら、スマホのGoogleドライブアプリでテキストを開けば読めます。
もうひとつは、PCが壊れたときに全部消えないという理由です。これは実際に助かった経験があるわけではないので、いまのところ「安心のため」でしかありません。ただ、自動化の中身が全部ローカルにしかないという状態は、考えるとけっこう落ち着かないです。
同期フォルダ特有のクセ
ローカルのフォルダとまったく同じかというと、そうではありませんでした。同期フォルダは、書き込んだ瞬間にクラウド側と一致しているとは限りません。書いてから同期が終わるまでに時間差があります。
私の場合、生成が6時台で最初の投稿が7時なので、1時間近く余裕があります。この余裕が結果的にクッションになっています。もし生成の直後に投稿するような組み方をしていたら、同期の途中のファイルを読んでしまう可能性を考えないといけなかったはずです。時間差のある受け渡しにするなら、その時間差は自分で確保しておいたほうがいいと思っています。
もっとも、これは私が余裕を持たせた設計にしていたから問題が出ていないだけで、詰めた設計で本当に事故るかどうかは検証していません。私は未検証です。
書き込む先を間違えて、告知が一度も出ていなかった
受け渡し場所を挟む構成でいちばん派手にやらかしたのが、これです。
noteの新着はRSSで拾って、月水金に自動で告知するようにしています。告知文はAIに作らせて、それを投稿スクリプトが読んで投げる。ここまでは他のものと同じ作りです。
ところが、告知が一度も投稿されていない時期がありました。原因は、告知文をGoogleスプレッドシートにだけ書き込んでいて、投稿スクリプトが読むドライブ側のファイルを更新していなかったことです。
書く側と読む側が、別の場所を見ていました。書く側から見れば、ちゃんと文章は生成されているし、スプレッドシートには行が増えています。読む側から見れば、ドライブのファイルには何も書かれていないので、投げるものがない。どちらも自分の仕事はしているので、どちらもエラーを出しません。
なぜ気づけなかったのか
この構成の弱点がまさにここでした。あいだにファイルを挟むと、書く側と読む側が独立します。独立するということは、片方が壊れてももう片方は普通に動くということです。普通に動いてしまうから、静かに何も起きない。
スプレッドシートを開けば告知文は並んでいるので、私は「生成できている」と思っていました。生成できていることと、届く場所に置けていることは別だったんですが、そこが分かれているという自覚がありませんでした。
いまは、書き込んだ先と読みに行く先が同じかどうかを、組んだ直後に一度だけ手で確かめるようにしています。具体的には、書く側を1回だけ手で走らせて、ドライブ側のファイルの更新日時が変わったかを見ます。更新日時が動かなければ、そのファイルには何も書かれていません。
ファイルの中身が、見た目どおりではなかった
ドライブに置いたテキストを読む側でも、けっこう転びました。共通しているのは、開いて見た目を確認しても分からない種類の失敗だということです。
ひとつは、認証トークンのファイルにBOMが混ざっていて、投稿が丸ごと止まったことです。BOMというのはファイルの先頭に付く見えない印のようなもので、テキストエディタで開いても何も変わって見えません。中身は正しいのに認証が通らない。見た目が正常なので、原因を疑う場所が思いつかず、特定に時間がかかりました。
もうひとつは、トークンのファイルを全行つなげて読んでしまって認証エラーになったことです。実際に必要だったのは1行目だけでした。ファイルの中に改行が入っていて、その後ろまで全部読んで一本の文字列にしていました。これも、ファイルを開いて見れば「ちゃんと書いてある」ようにしか見えません。
置き場所を挟むと、こういう失敗が増える
これは構成のせいでもあります。処理の中で変数を渡していれば、文字コードも改行も気にしなくていい。ファイルに書いて、ファイルから読むという形にした瞬間に、書いた文字がそのまま読めるとは限らない世界に入ります。
受け渡し場所を挟むということは、書いたものと読んだものが一致する保証を自分で持たないといけないということでした。私はそれを知らずに挟んだので、後から一つずつ踏みました。
いまは、読む側で「読んだ結果がどうなっているか」をログに出すようにしています。中身そのものは残しませんが、何文字だったか、何行だったかは残します。0文字だったらその時点でおかしいと分かるし、1行のはずが3行あればそこで気づけます。
失敗を、ログとDiscordと後追い報告の三段で拾う
受け渡し場所を挟むと静かな失敗が増える、という話をしました。その対策として、いまは失敗を三段で拾うようにしています。
まず、投稿が失敗したらログファイルに残ります。次に、Discordに通知が飛びます。そして、次に私がPCを開いたときにも報告が上がります。同じ失敗を三回別の経路で知らせる形です。
三段にしているのは、通知だけだと見落とすからです。Discordの通知は、外にいるときに来ると読まずに流れます。ログだけだと、そもそもログを開く習慣がないと気づけません。PCを開いたときの報告は、作業を始める瞬間なので確実に目に入ります。
それでも取りこぼしたもの
2026年7月3日から5日まで、Threadsの投稿が1本も出ていませんでした。原因は早朝にPCがスリープしていて、6時の生成スクリプトが走れなかったことです。
この失敗は、いま書いた三段のどれにも引っかかりませんでした。投稿スクリプトが失敗したのではなく、そもそも起動していないからです。起動していないプログラムは、失敗の通知も出せません。
7月14日にも投稿が3件失敗しています。こちらも原因はPCが落ちていたことでした。受け渡し場所を挟んでいると、ファイルが空のままなのか、そもそも書きに来ていないのかは、ファイルを見ただけでは区別がつきません。どちらも「何も書かれていないファイル」に見えます。
この区別をつけるために、いまは生成が終わったときに「終わった」という記録を残すようにしました。記録が無ければ生成が走っていない、記録があるのに中身が空なら生成は走ったが書けなかった。ここが分かれるだけで、次に見に行く場所が変わります。
受け渡し場所は、AIへの指示を渡す場所にもなった
最初は投稿文を置くだけの場所でしたが、いまはAIに渡す材料も同じ場所に置いています。
きっかけは、さっき書いた「実際とは違う数字を書いてきた」件です。対策として、実際に起きたことと実測値だけを書いた台帳を作りました。そこに載っている数字しか使わせないようにして、台帳もドライブに置いています。生成スクリプトは毎朝、台帳を読んでからAIに投稿文を書かせます。
台帳の中身は、たとえばこういうものです。6月25日から7月27日までに87本を自動投稿して、その間フォロワーは0人のままだった。7月27日時点で数えたとき、7月のビューは527・いいね7・返信0・リポスト0だった。返信は一度も来ていない。こういう、私が実際に数えた値だけが並んでいます。
台帳を置いただけでは直らなかった
ただ、台帳をドライブに置いてAIに読ませるようにしても、作り話は止まりませんでした。
理由は、前から書いてあった別の指示と噛み合っていなかったからです。「毎回、具体的な出来事を必ず入れる」という指示が先にありました。台帳のネタが尽きると、AIは指示を守るために出来事を作りました。守るべきものが二つあって、片方を守ると片方が破れる状態でした。
「無ければ書かなくていい」と言い直して、やっと止まりました。置き場所を用意することと、置いたものをどう使わせるかは、別の作業でした。受け渡し場所を整えれば勝手に精度が上がるわけではない、というのが正直な実感です。
この台帳は、いまも自動で伸びています。週次・月次で自分の投稿を自動集計して、Discordにレポートが飛ぶようにしているんですが、その値が台帳にも追記されます。2026年8月4日までの7日間でThreadsに24本投稿して、合計ビュー120・いいね1・返信0だった。2026年7月は82本投稿して、合計ビュー582・いいね8・平均ビュー7.1だった。こういう値が、私が手で書かなくても溜まっていきます。
受け渡し場所を挟んで、実際に何が変わったか
ここまで事故の話ばかり書いたので、良かったほうも整理しておきます。
いちばん大きいのは、切り分けが速くなったことです。投稿が出ていないとき、まずドライブのファイルを見に行きます。中身が入っていれば投げるところで転んでいるし、空なら生成のほうです。以前は、どこで止まっているのかを探すところから始めていました。
次に、投稿の中身を後から見返せるようになりました。何を投げたかがテキストとして残っているので、伸びた投稿と伸びなかった投稿を並べて読めます。抽象的な問いかけだけの投稿より、具体的なしくじりを書いた投稿のほうが見られていた、というのはこうやって並べて気づいたことです。
三つ目は、片方だけ作り直せることです。Xの自動投稿を組んだとき、投稿する部分はゼロから書きましたが、生成する部分はThreadsのものをそのまま使えました。読む場所が決まっていれば、投げる先が違っても同じ文章を使い回せます。
それでも解決していないこと
正直に書くと、受け渡し場所を整えても数字は動いていません。6月25日から7月27日までに87本投稿して、フォロワーは0人のままでした。週ごとの平均ビューは18.2、15.9、8.4、7.9、5.0と右肩下がりです。7月27日時点で、68本のうち13本はビューが0か1でした。
8月4日までの週も、ビューが0か1のままだった投稿が8本あります。noteは7月27日時点で記事27本、フォロワー2人、全記事の合計いいねは45です。
自動投稿は「続ける力」はくれますが「届く力」は別物でした。受け渡し場所を挟んだのは、続ける力のほうを支える工夫です。届く力のほうには、いまのところ何もしていません。投稿の質を上げる前に、そもそも誰にも見られていないことのほうが問題だと感じています。
自社の収益もまだ立っていません。業務委託は仕事量が多くて大変なわりに利益は低いです。AIを使った仕事に可能性は感じていますが、収益が立っていないので方向性が合っているのか不安になります。自動化を作っているのに、結局そのつど自分の手を動かしてしまっている、というのも自覚があります。
これから同じことをやる人が確かめたほうがいいこと
私が2ヶ月で踏んだ範囲でしかありませんが、先に確かめておけば避けられたと思うものを書きます。
- 書く側が書き込む場所と、読む側が読みに行く場所が、本当に同じか。組んだ直後に、書く側を1回手で走らせてファイルの更新日時が動くかを見る。
- ファイルの先頭に見えない文字が入っていないか。テキストエディタで開いて正常に見えても、中身が同じとは限らない。
- 読む側が、ファイルのどこまでを読んでいるか。1行目だけでいいのに全行つなげて読んでいた、というのが実際にあった。
- 生成の時刻と投稿の時刻のあいだに、同期が終わる余裕があるか。
- 生成そのものが走らなかったときに、それが分かる記録が残るか。空のファイルは「書けなかった」のか「来ていない」のか区別がつかない。
あと、これは受け渡し場所の話とは少しずれますが、タスクスケジューラーで動かしている場合は「準備完了」の表示を信じないほうがいいです。Xの自動投稿を組んだとき、タスクは全部「準備完了」と表示されていたのに、実際は一度も動いていませんでした。原因は登録スクリプトで変数名にPowerShellの予約語を使っていて、タスクに渡す引数が丸ごと空になっていたことでした。エラーもログも残らないので、気づくのに時間がかかりました。
いまは、タスクを登録したあとは表示だけで安心せず、渡している引数が空になっていないかを毎回確かめています。
費用について
この構成にかかっている費用も書いておきます。XのAPI利用料が1日5本の投稿で月350円ほど、ThreadsのAPIは無料、タスクスケジューラーはWindows標準機能なので0円です。Googleドライブは私が普段から使っている範囲で足りています。テキストファイルなので容量もほとんど使いません。
置き場所として何かを新しく契約する必要はありませんでした。もともと持っていたものを、受け渡しの場所として使い回しただけです。
まとめ
- AIが書いた投稿文をGoogleドライブにテキストで置き、投稿スクリプトはそれを読んで投げるだけ、という形にしている。生成と投稿は直接つながっていない。
- 挟んだ理由は、投稿の前に自分の目で中身を見られるようにするため。実際にAIが実測値と違う数字を書いてきたことがあり、そのまま出さずに済む隙間が要ると感じた。
- 同期フォルダにしたのは、外出先のスマホから中身を確認できるからと、ローカルにしか無い状態を避けたかったから。生成6時台・投稿7時という時間差が、結果的に同期のクッションになっている。
- いちばん派手な事故は、告知文をスプレッドシートにだけ書き込んで、投稿スクリプトが読むドライブ側のファイルを更新していなかったこと。書く側と読む側が別の場所を見ていて、どちらもエラーを出さなかった。
- ファイルにBOMが混ざって投稿が丸ごと止まった、トークンを全行つなげて読んで認証エラーになった、という失敗もあった。開いて見ても分からない種類の失敗が増える。
- 失敗はログ・Discord通知・PCを開いたときの報告の三段で拾っているが、7月3日から5日のようにPCがスリープして生成が走らなかった場合は三段のどれにも引っかからなかった。起動していないものは失敗の通知も出せない。
- 台帳を同じ場所に置いてAIに読ませても、それだけでは作り話は止まらなかった。「毎回具体的な出来事を入れる」という別の指示と噛み合っておらず、「無ければ書かなくていい」と言い直して止まった。
- 良くなったのは切り分けの速さ、投稿の見返しやすさ、生成と投稿を別々に作り直せること。Xを組んだとき生成部分をそのまま使い回せた。
- それでも数字は動いていない。87本投稿してフォロワーは0人のまま、週の平均ビューは18.2から5.0まで下がった。自動投稿は続ける力はくれても、届く力は別物だった。
- 費用はXのAPIが月350円ほど、Threads APIは無料、タスクスケジューラーは0円。置き場所のために新しく契約したものはない。
コメント