自動化を組んだあと、実行結果をどこに残すかで一度つまずきました。結論から書くと、人が見る場所と、機械が読む場所は分けたほうがいいというのが今の結論です。スプレッドシートは人が見るための管理表として優秀ですが、自動化スクリプトに読ませる入力元としては私は失敗しました。
私は元調理師で、飲食の現場に10年いたあと、SNS運用代行のフリーランスとして独立しました。自動化を組み始めたのは2026年6月なので、まだ2ヶ月ほどです。その2ヶ月で、スプレッドシートの置き場所を間違えて自動投稿が丸ごと出ていなかった、という事故を実際に起こしています。この記事は、その失敗を踏まえて今どういう構成に落ち着いたかの実践ログです。
スプレッドシートを入力元にして、投稿が一度も出なかった話
先に失敗から書きます。私はnoteの新着をRSSで拾って、月水金に自動で告知する仕組みを動かしています。この告知文を作るところと、実際に投稿するところは別のスクリプトに分かれています。
このとき、告知文を生成する側はスプレッドシートに書き込むようにしていました。ところが投稿する側のスクリプトは、Googleドライブに置いたテキストファイルを読みに行く作りでした。書き込む先と読みに行く先がズレていたわけです。結果として、note告知が一度も投稿されていない時期がありました。
厄介なのは、この失敗が何のエラーも出さないことです。生成側は正常にスプレッドシートを更新して終わります。投稿側は、ドライブのファイルを読んで「中身が無いから投げない」で終わります。どちらのスクリプトも自分の仕事は完遂しているので、ログにも異常として残りません。
私はスプレッドシートを開いて告知文が並んでいるのを見ていたので、動いていると思い込んでいました。実際には、その表は誰も読んでいないただの記録でした。表が埋まっていることと、仕組みが動いていることは別だと、このとき初めて手触りとして分かりました。
ズレが起きた理由は「見やすいほうに寄せた」こと
なぜこんな構成にしたかというと、単純にスプレッドシートのほうが見やすかったからです。生成された文章が行ごとに並んでいて、スマホからでも確認できて、直したければその場で直せる。人間にとっての体験は圧倒的にスプレッドシートのほうが良かった。
それで、生成側だけを先にスプレッドシートに移してしまいました。投稿側を合わせて直すのを忘れた、というより、そもそも「両方直さないといけない」と認識できていなかった。自動化を組み始めて日が浅い時期にやりがちな抜けだと思います。
今の構成｜機械はドライブのテキスト、人はスプレッドシート
今は役割をはっきり分けています。スクリプトが読むのはGoogleドライブに置いたテキストファイルだけで、スプレッドシートは結果を眺めるための管理表に徹しています。
投稿まわりの流れはこうです。毎朝6時台にAIが投稿文をまとめて生成して、Googleドライブにテキストで保存します。投稿スクリプトはその日のテキストを読んで、決まった時間に投げるだけ。Threadsは1日5本（7時・12時・17時・21時・23時）、Xも同じ時間に1日5本を全自動で投稿しています。Windowsのタスクスケジューラー＋Python＋API直叩きという構成です。
この流れの中に、スプレッドシートは一切入っていません。入力にも出力にも噛ませていない。噛ませると、また同じズレが起きるからです。
テキストファイルを入力元にしたときの利点
テキストファイルにして良かったのは、失敗の仕方が単純になったことです。ファイルが無ければ読み込みで落ちる。中身が空なら空だと分かる。文字コードがおかしければそこで止まる。
実際、認証トークンのファイルにBOMが混ざっていて投稿が丸ごと止まったことがありますし、トークンのファイルを全行つなげて読んでしまって認証エラーになったこともあります。どちらも原因特定には時間がかかりましたが、少なくとも「止まっている」ことは分かりました。スプレッドシート経由のズレは、止まりすらしなかった。ここが決定的に違います。
それでもスプレッドシートを捨てない理由
では表は要らないかというと、そうではありません。私がスプレッドシートに残しているのは、実行された結果のほうです。何本投稿したか、どの時間帯が見られているか、ビューが0や1のまま終わった投稿がどれだけあるか。こういう数字は、テキストファイルに散らばっていると絶対に見ません。
週次・月次では自分の投稿を自動集計して、Discordにレポートが飛ぶようにしています。通知は流れていくので、あとから振り返るための置き場として表を持っている、という関係です。通知は気づくため、表は比べるため。この使い分けにしてから、数字を見る回数が明らかに増えました。
表に残すと何が変わったか｜右肩下がりに気づけた
表に残すことの効果がいちばん出たのは、投稿の伸びなさに気づけたことでした。
2026年6月25日から7月27日までに、Threadsへ87本を自動投稿しました。その間、フォロワーは0人のままです。7月27日時点で数えたとき、7月のビューは527、いいね7、返信0、リポスト0でした。返信は一度も来ていません。68本のうち13本は、ビューが0か1のまま終わっていました。
この数字だけでもきついのですが、表にして並べたときにもっとはっきりしたのは推移のほうです。週ごとの平均ビューは18.2 → 15.9 → 8.4 → 7.9 → 5.0と、きれいに右肩下がりでした。1週ずつ単体で見ていたら、たぶん「今週はちょっと少なかったな」で終わっていたと思います。並べたから、下がっていると認識できた。
時間帯ごとに分けたら、朝が強いと分かった
もうひとつ、表にして分かったのが時間帯の差です。7月27日時点のスロット別の平均ビューは、朝15.7・昼5.7・夜1.8でした。朝がいちばん見られていた。7月ひと月で見ても、平均ビューが最も高かったのは朝の枠でした。
ただ、これは固定ではありませんでした。2026年8月4日までの週で見ると、朝6.0・昼6.6・夜2.4で、朝と昼が逆転しています。同じ週のThreadsは24本投稿して、合計ビュー120・いいね1・返信0。ビューが0か1のままだった投稿が8本ありました。
1回集計しただけなら「朝が強い」で結論を出していたはずです。表に残して何週分か並べたから、週によって入れ替わる程度の差でしかないと分かりました。数字が少ないうちは、傾向として扱わないほうがいいという判断ができたのは、記録が残っていたからです。
失敗の日も同じ行に残す
集計表には、うまくいかなかった日も同じ粒度で入れています。7月14日は投稿が3件失敗しました。原因はPCが落ちていたことです。7月3日から5日までは、Threadsの投稿が1本も出ていませんでした。こちらは早朝にPCがスリープしていて、6時の生成スクリプトが走れなかったのが原因です。
こういう日を表から外すと、平均が実態より良く見えます。そして何より、後から「この週だけ妙に少ないな」と思ったときに理由をたどれなくなる。数字が落ち込んだ日の理由が同じ行に書いてあると、それは記録ではなく原因表になります。
AIとの受け渡しに表を使うときに決めたこと
投稿文はAIに書かせています。ここでも一度やらかしました。実際には68本なのに、AIが62本と書いてきたことがあります。文章としては自然なので、読んでも気づけない。
対策として、実際に起きたことと実測値だけを書いた台帳を作り、そこに載っている数字しか使わせないようにしました。ところが台帳を足しただけでは直りませんでした。前から書いてあった「毎回、具体的な出来事を必ず入れる」という指示と噛み合わず、台帳のネタが尽きるとやっぱり作り話をしたからです。「無ければ書かなくていい」と言い直して、やっと止まりました。
この経験から、AIに渡す表について決めたことがあります。渡すのは事実だけ、加工した値は渡さないということです。平均や増減率のような計算済みの数字を渡すと、それを起点にさらに膨らませてしまう。生の本数とビュー数だけを渡して、そこから何が言えるかは自分で書く。この線引きをしてから、数字まわりの事故は起きていません。
人が読む列と、AIに渡す列を混ぜない
表を作っていると、つい列を増やしたくなります。所感を書く列、次にやることの列、うまくいったかどうかのフラグ。人が振り返る分には便利です。
ただ、その表をそのままAIに渡すと、所感の列まで事実として扱われます。「効いている気がする」と自分で書いたメモが、次の生成で断定に変わって出てくる。私は、AIに渡す範囲は数字とその日に起きた事実だけに絞って、感想の列は渡さない範囲に置いています。
表の更新も、できるところは手で触らない
もうひとつ気をつけているのが、集計を手作業でやらないことです。手で転記すると、必ずどこかで写し間違えます。しかも間違えた値のほうが、その後ずっと正しい値として扱われてしまう。
今は週次・月次の集計を自動で回して、Discordにレポートが飛ぶようにしています。表に残す値も、その自動集計から来たものです。自分の手が入る場所を減らすほど、記録は信用できるようになります。
「準備完了」を信じないと決めた日
記録と表の話をするうえで、外せない失敗がもうひとつあります。Xの自動投稿を組んだとき、タスクは全部「準備完了」と表示されていたのに、実際は一度も動いていませんでした。
原因は、登録スクリプトで変数名にPowerShellの予約語を使っていたことです。そのせいでタスクに渡す引数が丸ごと空になっていました。エラーもログも残らないので、気づくのに時間がかかりました。それ以来、タスクを登録したあとは「準備完了」の表示だけで安心せず、渡している引数が空になっていないか毎回確かめるようにしています。
似た性質のものとして、日付を整える処理でも同じ目に遭いました。パソコンによって使える書き方と使えない書き方があるのを知らずに書いて、機能がまるごと無言でスキップされていました。エラーが表に出ない失敗がいちばんこわい。
この2つを経験してから、表に残す項目に「実際に何本出たか」を必ず入れるようにしました。設定画面の状態ではなく、結果の本数を見る。想定と実測が合っていなければ、そこで初めて何かが起きていると分かります。管理表の本当の役割は、システムが自分について言っていることを疑うための材料を持っておくことだと思っています。
期限切れも表に載せておく
Threadsの認証トークンが、あと10日で切れるところだったことがあります。切れたら投稿が全部止まります。気づいたその日に延長して、ついでに毎月1日に自動で延長する仕組みを入れました。
XのAPIキーを取りに行ったときは、画面に下6桁しか表示されなくて、完全な値を見る方法がありませんでした。結局いったん作り直すしかなかった。しかも作り直す順番を間違えると、後から作ったほうが無効になります。親のキーを先に作り直してから、その下のキーを作り直す必要がありました。
こういう情報は、頭の中に置いておくと必ず忘れます。期限のあるものと、作り直しの順番があるものは、表に書いておく価値があると実感しました。動いているときは何の役にも立たない情報ですが、止まってから調べ直すと時間を食います。
それでも解決していないこと
ここまで管理表の話をしてきましたが、正直に書くと、表を整えたことで結果が良くなったわけではありません。
自動投稿は「続ける力」はくれましたが、「届く力」は別物でした。フォロワーが0人のまま87本投稿できたのは、確かに仕組みのおかげです。ただ、投稿の質を上げる前に、そもそも誰にも見られていないことのほうが問題でした。管理表は、その事実をはっきり突きつけてくるだけで、解決はしてくれません。
noteのほうも、2026年7月27日時点で記事27本、フォロワー2人、全記事の合計いいねは45です。数字を並べて眺める習慣はついたけれど、そこから打ち手が自動で出てくるわけではない。誰にも見られていない状況が続くのは、単純にきついです。
自動化を作っているのに、結局そのつど自分の手を動かしてしまっている、という自覚もあります。表を見て、気になって、手で直して、また表を見る。この往復自体は悪くないのですが、当初やりたかった「見なくても回る」からは遠い。
数字が動かない期間をどう扱うか
ひとつだけ、判断の支えにしていることがあります。引き継いだクライアントの案件を、コンセプトから作り直したことがありました。それが最近になって伸びて、素直にうれしかったのですが、伸びるまで手応えは一切ありませんでした。やっている最中は、効いているのかどうか分からないままでした。
手応えが無い時期がしばらく続いたあとで、急に来た。だから今も、反応が無い期間をすぐ失敗とは思わないようにしています。表に残しているのは、その「反応が無い期間」の長さと形を、あとから確認できるようにするためでもあります。
ちなみに傾向として、抽象的な問いかけだけの投稿より、具体的なしくじりを書いた投稿のほうが見られていました。これも、投稿ごとの数字を残していたから気づけたことです。数字が全体として伸びていなくても、中に差はある。
これから表に載せようとしていること
2026年8月6日、自社サイト（7ページ）とLPの公開準備を終えました。問い合わせフォームをGoogleフォームにつなぎ、送信テストまで成功しています。あとはサーバーに置くだけです。
フォームからの送信は、まさに「人が見る場所」と「機械が読む場所」を分ける話になります。送信内容は自動で溜まっていきますが、それをそのまま眺めるのは現実的ではない。何が届いたかに気づくための通知と、あとから並べて見るための表を、投稿まわりと同じ形で作ろうと思っています。
自社の収益がまだ立っていないので、この設計が正しいかどうかは分かりません。業務委託は仕事量が多くて大変なわりに、利益は低い。AIを使った仕事に可能性は感じていますが、収益が立っていないので方向性が合っているのか不安になります。それでも、記録が残っていれば後から検証できる。今はそこだけを頼りに続けています。
自動化にかかっている費用は、XのAPI利用料が1日5本の投稿で月350円ほど、ThreadsのAPIは無料、タスクスケジューラーはWindows標準機能なので0円です。スプレッドシートもGoogleドライブも、私の使い方の範囲では追加費用は発生していません。管理表を作ること自体にお金はかかっていないので、迷っているなら作ってしまったほうが早いと思います。
まとめ
- スプレッドシートを自動化の入力元にしたら、投稿スクリプトが読むドライブ側のファイルとズレて、note告知が一度も出ていない時期があった。エラーが出ないので気づけなかった
- 今は機械が読むのはGoogleドライブのテキストファイルだけにして、スプレッドシートは結果を眺めるための管理表に徹している
- 表に並べたことで、週ごとの平均ビューが18.2 → 15.9 → 8.4 → 7.9 → 5.0と右肩下がりだと分かった。1週ずつ見ていたら気づけなかった
- 時間帯別も、7月27日時点は朝15.7・昼5.7・夜1.8だったが、8月4日までの週は朝6.0・昼6.6・夜2.4。何週か並べて初めて、傾向として扱うには早いと判断できた
- 失敗した日も同じ粒度で表に残す。7月14日の3件失敗（PCが落ちていた）、7月3日〜5日の全停止（PCがスリープしていた）も行として入れている
- AIに渡すのは生の事実と実測値だけ。平均などの加工済みの値や、自分の所感を書いた列は渡さない
- 「準備完了」の表示は信じない。設定の状態ではなく、実際に何本出たかを表で見る
- 期限のあるもの（Threadsのトークンは60日で切れる）と、作り直しの順番があるもの（XのAPIキーは親から先に）は表に書いておく
- 表を整えても結果は良くならなかった。フォロワー0人のまま87本、返信0という事実がはっきりしただけ。それでも、反応が無い期間の長さと形を後から確認できるようにしている
コメント