SNS運用の「どの型が伸びるか」が測れていなかった——ラベルが9割欠けた計測ログを直すまで

SNSの自動運用を1か月続け、4,300行の計測データが貯まっていました。それでも「どの型のコンテンツが伸びているか」だけは、一度も数字で答えられませんでした。 原因は集計の書き方ではなく、コンテンツの「型」を示すラベルが投稿の瞬間に消えてしまう設計にありました。この記事は、その欠落に気づいてから直すまでの記録です。実測値はすべて自分の運用データです。

TL;DR

• 計測ログ4,309行のうち、コンテンツの型ラベル(lane)が入っていたのは約10%だけだった
• 原因は2つ。①型の一覧表とログでIDの書き方が違って結合できていなかった ②型ラベルが投稿指示のキューにしか存在せず、投稿し終えると消えていた
• 直した結果、ラベルの網羅率は10%→30%、X(旧Twitter)は0%→41%になった
• 初めて型別に集計できるようになり、Instagram の静止画は再生の中央値10、同じアカウントのリールは158という16倍の差が判明した
• 「毎日ちゃんと投稿できているか」は見ていたが、「その投稿に意味があったか」は見ていなかった、という話

毎日動いているのに、何も分かっていなかった

SNSの投稿は自動化していました。動画を作り、キャプションを付け、時間帯を割り当てて予約する。数値の収集も1日3回動いていて、各投稿の再生数といいねが貯まっていく。ダッシュボードもレポートも毎日生成されていました。

見落としていたのは、その先です。運用ルールには「勝ち型は形を維持して強化、負け型はテーマかフックか画像形式のどれかを必ず変える」と書いてありました。ところが、その判断に必要な「型別の成績」がどこにも存在しませんでした。

数えてみると、計測ログ4,309行のうち型ラベルが入っていたのは443行。約10%です。媒体別では、TikTokが23%、Instagramが0%、Xが0%でした。つまり全体の判断は、毎日ログの文章を読み直して「たぶんこの型が良かった」と推測することで成り立っていました。推測なので、日によって結論が変わります。

原因1: IDの書き方が違って結合できていなかった

型ラベル自体は、実は存在していました。コンテンツの一覧表(台帳)には307行あり、そのうち306行に型が入っていたのです。問題は、その台帳と計測ログが結びついていなかったことでした。

台帳側のIDは、制作を管理するときに付けた tt- tk- ig- x- といった接頭辞付きのままでした。一方、計測ログ側のIDは、各SNSが実際に発行したID(TikTokなら数字、Instagramならshortcode)に揃えられていました。307件のうち190件が接頭辞付きで、素直に突き合わせると165件しか一致しません。

接頭辞を落として正準形に揃えたところ、一致は305/307になりました。これだけでラベルを付けられる行は10%から59%に増えます。

台帳を正準化した後の一致: 305 / 307 (正準化前 165)
ラベル付与できる計測行: 2551 / 4309 = 59% (現状 443行=10%)

同じ種類の問題は媒体名にもありました。Instagram が ig と instagram の2通りで記録されていて、集計上は別の媒体として扱われていたのです。しかもこれは一度直したはずのものが再発していました。

再発した理由は、計測ログへの書き込み経路が2つあったことです。ひとつはスクリプト経由で、ここには正規化が入っていました。もうひとつは、収集を担当するエージェントがCSVへ直接追記する経路で、こちらは正規化を通りません。後者から ig 表記が197行、ig- 接頭辞が172行、再び流れ込んでいました。

つまり「入口を1つだと思って直したが、実際には2つあった」という、よくある話です。対処としては、書き込み側に守るべき値の形をはっきり書いた上で、書き込み経路がどれであっても最後に必ず通る整備処理を毎回の収集後に挟むようにしました。片方だけでは、いずれまた漏れます。

原因2: 型ラベルが投稿の瞬間に消えていた

より根の深いほうがこちらです。台帳の307行のうち、277行の型は `unclassified`(分類なし) でした。ラベルが結合できていなかっただけでなく、そもそも中身が入っていなかったのです。

理由は情報の流れを追うと分かりました。

1. 動画や画像を作る段階では、型は決まっている(配信指示ファイルに「この動画はASMR枠」と書いてある)
2. その配信指示ファイルはキューで、投稿し終えると行が消える
3. 台帳の行は、後から「SNSの管理画面」を見て作られる。管理画面に型など表示されていないので、unclassified になる

型を知っているのは投稿の瞬間だけで、その瞬間に誰も記録していませんでした。型を残す場所が、そもそも設計に無かったわけです。

対処は素直に、キューが消える前に恒久的なアーカイブへ写すようにしました。収集は1日3回動くので、キューの寿命より短い間隔で必ず捕まえられます。加えて過去分については、投稿ログに残っている「ファイル名 → 予約時刻」と、計測ログの「投稿時刻 → 実ID」を突き合わせて遡って復元しました。

Xについては別の発見がありました。Xの投稿は素材ファイルではなく「枠」で型が決まる設計で、それは実は毎日ログに書かれていたのです。

- 2026-08-01 | x | 20:00 | 実数レポート公開枠 | 直近7日のX実数を公開: ...

97件ぶん、きちんと残っていました。書いてあったのに、誰も読んでいなかっただけです。このログを読むようにしただけで、Xのラベル網羅率は0%から41%になりました。自動化の穴は、無いものを作るより「あるのに繋がっていない」ことのほうが多い、と実感した部分です。

直した結果、初めて型別の成績が出た

修正後、全期間の実測から型別の成績を機械生成できるようになりました。1本のバズが平均を歪めるため、主指標は中央値にしています。

2つ、はっきりした差がありました。

Instagram の静止画は、同じアカウントのリールの16分の1しか見られていませんでした。 7本すべてが19回以下です。毎朝きちんと1枚作り続けていた枠が、ほぼ誰にも届いていなかったことになります。

これはキャプションや題材の出来の問題ではなく、構造的な差だと考えています。静止画は発見タブやレコメンドにほとんど乗らないため、届く先が実質フォロワー(当時17人)に限られます。一方リールはレコメンド配信に乗るので、フォロワー数とほぼ無関係に伸びます。同じ手間をかけるなら、届く仕組みに乗るほうへ寄せるべきです。動画在庫は92本あったので、朝の枠は画像からリールへ切り替えました。

Xでは、実数をそのまま出す投稿だけが突出していました。 中央値248に対し、他の枠は27〜67。4〜9倍の差です。最下位は「意見枠」で中央値27でした。持論や問いかけそのものではなく、飾らない実際の数字が読まれている、という読み方をしています。

なお、本数が3本未満の型は判断材料として不十分なので「参考」として扱い、それだけで型を増やしたり捨てたりはしない、というルールも同時に入れました。少ない本数の中央値は簡単に上振れます。

学んだこと

「毎日ちゃんと動いているか」と「その活動に意味があるか」は、別々に測らないと片方だけ盲点になります。 前者の監視は手厚く作ってありました。ジョブの実行状況、失敗の検知、再実行、日報。どれも動いていました。にもかかわらず、後者はまるごと欠けていたのです。動いていることの確認が、成果の確認の代わりになってしまっていました。

もうひとつは、判断の材料を人間の文章に置かないということです。型別の成績は、実はログの文章の中には毎日書かれていました。しかしそれは、読む人(あるいはエージェント)によって解釈がぶれる形でした。判断に使う数字は、機械が同じ手順で同じ答えを出せる形で置くべきです。今は毎回の収集後に型別の成績表を自動生成し、翌日の配分を決めるエンジンはまずそれを読むようにしています。

そして、一度直したデータの不整合は、入口が複数あると再発します。 今回の表記ゆれは7月に一度直したものでした。直す対象がデータだけで、書き込み側の規約と、経路を問わず必ず通る整備処理の2つを用意していなかったので、2週間で元に戻っていました。

計測を始めること自体はすぐできます。難しいのは、貯まったデータが問いに答えられる形になっているかを、時々わざわざ確かめることのほうでした。