仕組みは最初に作るのが理想でした ― 公開15本のあとに台帳とカレンダーを作った私の、順番の比較
ブログを15本公開してから、やっと気づいたことがあります。
記事が増えるほど、「何を公開して、どこに投稿したか」が分からなくなる。
書くこと自体は、AI執事のモカが担ってくれます。でも、公開したあとの管理は、仕組みが無ければ人の記憶頼みになります。私はその仕組みを全部後回しにして、15本のあとにまとめて作りました。
この記事は、その反省と比較です。最初に作っておくのが理想の順番と、私が実際にやった順番を比べて書きます。これからブログやSNS発信を始める方が、私の遠回りをしなくて済むように。
理想の順番と、私の順番
まず結論の比べです。
| 項目 | 理想の順番（最初に作る） | 私の順番（15本のあとに作る） |
|---|---|---|
| 台帳 | 1本目から1行ずつ積む | 15本分を記憶とファイルから拾い直す |
| 投稿の状態 | 投稿のたびにその場で残る | 記録が無く「未確認」が残った |
| カレンダー | 公開日に自動で積もる | 15件をまとめて入れ直す |
| 共有の設定 | 最初に1回だけ済む | 「アクセス権が必要です」で足止め |
私の場合は順番が逆でした。ブログを作り（11月3日）、記事を先に出し続け、管理の仕組みは11月7日に後付けしたのです。
仕組み1：台帳は、モカ用のスプレッドシート
1つ目は、記事と投稿の状態を1行にまとめた表です。私はこれを「モカ管理台帳」と呼んでいます。置き場はGoogleスプレッドシートです。
列は、こんな並びです。
- 公開日、タイトル、カテゴリー
- ブログの状態（公開済み／下書き）
- X、Bluesky、Threads、Instagram、Facebook、noteの投稿状態
- 告知文ファイルのありか
- 本文ファイル（MD）の置き場所
- 置き場の印（本番／下書き）
大事な決めが2つあります。
本文は表に貼らない。置き場所だけを貼る。
本文まで表に入れると、表を読むたびに全文が付いてきて、AIが読む量（トークン）が増えます。表は目次、本文は別の場所。これが、読み量を抑えるコツでした。
状態は、確かめられたものだけを書く。
後から作った私の台帳には、正直に「未確認」と書いた欄がたくさん残りました。初期の記事は、どこに投稿したかの記録がファイルに残っていなかったからです。たとえばXは、15本のうち「投稿済み」と確かめられた記事が、まだ1本もありません。文面は用意したのに、投稿したかどうかを後から確かめる材料が無いのです。
最初から台帳があれば、この「未確認」は最初から生まれませんでした。
仕組み2：カレンダーは、人が見るための表
2つ目は、カレンダーへの反映です。
台帳はモカ（AI）が読み書きする裏側の道具です。私が毎日開くのは、台帳ではなくカレンダーです。そこで、公開した記事は公開日に、終日の予定として「タイトル」でカレンダーへ入れることにしました。予定を開けば、ブログの住所と各SNSの状態が見えます。
工程管理には「ガントチャート」という、線が何本も並ぶ専門の図があります。あれは読み方を覚えるところから始まります。
カレンダーは、ガントチャートよりもわかりやすい。
誰もが毎日開いているもので、覚えることが何もありません。「この日に、これが出た」という事実が、そのまま目に入ります。専門の道具を新しく覚えるのではなく、いつもの道具に仕事を寄せる。それが私には合っていました。
仕組み3：ステータスで動く、自動投稿の受け皿
3つ目は、投稿そのものの自動化です。まだ検証の途中ですので、できたところまでを正直に書きます。
きっかけは、Yoomという自動化サービスの公式記事でした。
- 参照元：Yoom公式ブログ「Google スプレッドシートを更新するとXへ自動投稿する方法」 https://lp.yoom.fun/blog-posts/google-spreadsheet-x-auto-post-app-integration
この記事の仕組みは、スプレッドシートでステータスが更新されたら、Xへ自動で投稿するというものです。これを、Yoomを使わずにモカでできないか、と試しています。
Yoomの仕方と、モカの仕方の違いは、こうです。
| 項目 | Yoomの仕方 | モカの仕方 |
|---|---|---|
| 仲介役 | 外部サービス | モカ自身 |
| 追加の契約 | Yoomのプラン | なし |
| 起点 | ステータスの更新 | ステータス「投稿する」 |
| Xへの投稿 | サービス経由の連携 | 専用連携なし（検証中） |
| 人の確認 | なし（即投稿） | 文面の承認を挟む |
| 結果の記録 | サービス側 | 表とカレンダーに書き戻す |
受け皿の表（テスト用のスプレッドシート）は作りました。投稿文とステータスを入れる表で、ステータスを「投稿する」に変えた行だけをモカが拾う形です。
ただし、最後の関門が残っています。モカにはX専用の連携が無く、ブラウザからの投稿は過去にログインの制限で止まったことがあります。ここが通るかどうかが、今の検証の焦点です。通らなければ、Xの公式の仕組み（API）を使うかどうかを、あらためて決めることになります。
「最初に作っておく」べきなのは、この受け皿と「ステータスで管理する」という決めです。投稿の自動化そのものは、そのあとで育てられます。
後から作ると、何が起きるか
私の実例を並べます。
1. 過去分を拾い直す手間が出る
15本分の状態を、記憶と告知文ファイルから1本ずつ拾いました。記録のある最近の記事は埋まりますが、初期の分は「未確認」が残ります。最初から積んでいれば、この拾い直し自体がありません。
2. 共有のし忘れで足止めされる
モカが作った表は、持ち主がモカ側のアカウントになります。私が自分のアカウントで開くと「アクセス権が必要です」と出て、足止めされました。表を作ることと、共有まで済ませることは、セットにしておくべきでした。
3. 「投稿したかどうか」が一番消えやすい
記事の本文は残ります。公開した事実も残ります。一番消えやすいのは「SNSに投稿したかどうか」でした。これは、まさに台帳が最初から要る理由です。
測って分かったこと
台帳の効果も、実際に測ってみました。「特定の記事の本文の場所と投稿状態を特定する」という作業を、台帳なしと台帳ありで比べた記録です。
- 単純な記事では、台帳の方がむしろ遅かった（表を取りに行く通信に、1回0.5〜0.9秒かかるため）
- 別版が5本ある記事では、道具を呼ぶ回数が4回から2回へ半減し、「どれが正本か」で迷う工程が消えた
つまり台帳の効果は「秒の速さ」ではなく、手数の少なさと、取り違えが消えることに出ます。速いと決めつけて書くのは水増しですので、そのまま書いておきます。
なぜ、ここまでするか
理由は単純です。
人の手でやると、必ずヒューマンエラーが起こるからです。
ホームページ作りの頃も、よくありました。途中からは、ドキュメントで記事を書き、スプレッドシートにリンクを貼り、ワードプレスに上げる、という手作業のリレーでした。道具は揃っていても、つなぐのは全部人の手で、投稿のたびのコピペにはうんざりしていました。
今回の仕組みは、そのリレーを無くすためのものです。人が触るのは「文面を決める」と「ステータスを変える」だけ。帳面付けと転記は、執事の仕事にしました。
まとめ：順番は違っても、作った日から効く
理想は、発信を始める前にこの3つを作っておくことです。
- 台帳（モカ用のスプレッドシート）― 1行1記事、本文は置き場所だけ
- カレンダー（人用の目視確認）― 公開日に記録が積もる
- 自動投稿の受け皿 ― ステータスで管理する決めと、投稿用の表
私は順番が逆で、全部後回しにしました。それでも、作ったその日から「分からなくなる不安」は消えました。
順番が違っていても、仕組みは裏切りません。これから始める方は、ぜひ理想の順番でどうぞ。私の遠回りが、その近道になれば幸いです。
- 公開：2026年11月7日（約3,180字）