第7章 アカウント運用を自動化する（前編：自分のアカウントを回す）

7.1 運用のループを 1 枚に描く

SNS のアカウント運用は、広告と違って「止まる」ことで失敗します。最初はがんばって投稿していたのに、担当者が忙しくなった月にぱたりと止まり、気づけば半年空いている。著者の周りで一番多い失敗がこれです。

だから自動化の狙いは、投稿を AI に書かせることではありません。ループが人の都合で止まらない形にすること。工程は 5 つあります。

図は横にスクロールできます。図を原寸で開く

図の元になった mermaid を見る

mermaid

flowchart LR
  P["投稿設計<br>柱・配分・カレンダー"] --> M["制作<br>台本・画像・動画（第 4 章）"]
  M --> R["予約のツールを呼ぶ<br>宛先アカウント・正時"]
  R --> A{"確認画面<br>人が中身を見る"}
  A -->|"許可"| S["正時の巡回が投稿する"]
  A -->|"断る"| P
  S --> I["計測<br>媒体ごとのインサイト"]
  I --> REP["レポート<br>投稿ごと・自アカウント平均との相対"]
  REP -->|"翌月の配分へ"| P

人が持ち続けるのは、このうち 2 箇所だけです。何を選ぶか（投稿設計の柱と配分）と、外に出してよいか（確認）。後者はパーミッション（ツールを確認なしで使わせるか、呼び出すたびに人に確認させるかの設定。第 2 章）で行います。エージェントが予約や投稿のツールを呼ぶと、その場で、会話を操作している人に確認画面（呼び出すツールの名前と引数を表示し、実行してよいかを尋ねる画面）が出て、人が許可したときだけ実行されます。残りは連携と自動化の仕事で、この章の大半をそこに使います。

登場するモノと ID

姉妹記事で描いたオントロジーを、この領域に当てはめてみます。運用アカウントは案件（クライアント 1 社）に属し、1 案件が同じ媒体のアカウントを複数持てる。1 店舗 1 アカウントの会社はふつうにあるからです。予約は「どのアカウントに、いつ、何を」の 1 件で、確認画面で許可された呼び出しで作られる。実績はアカウントごと、投稿ごとに取り、案件の中で足し合わせません。

前提になるのは「アカウントは案件に属する」という 1 行です（原則 U）。Search Console のプロパティは URL に属しますが、SNS アカウントは URL ではなく案件に属する。ここを取り違えると、後で出てくる複数アカウントの扱いが全部ぶれます。

7.2 運用の設計：目的 → KPI → 投稿設計

設計には順番があります。①目的とペルソナを確定する ②テーマの柱を決める ③編集カレンダーを組む ④主軸の 1 本を各 SNS へ翻訳する ⑤投稿の文面を書く ⑥計測の型を先に決める。飛ばして⑤から始めたくなるのですが、それをやると投稿はできても「良かったのか」を後から判定できません。

目的は 3 類型に寄せる

店舗型ビジネスの SNS 運用は、目的を 3 つのどれかに寄せると設計が速くなります。店舗集客型（来店・予約）、EC 購買型（購入導線）、採用特化型（応募数）。どれに寄せるかで、見る数字が変わる。店舗集客なら見た人数（リーチ）とプロフィールのリンクのタップ、EC ならリンククリック、採用なら保存とプロフィール遷移です。

KPI（途中の目標）も先に決めておきます。認知なら見た人数の伸び、反応なら保存率とシェア率、獲得ならプロフィール遷移から先の予約や応募、育成ならフォロワーの増加率。月次のレビューで見る前提で組みます。

テーマの柱を先に決める

続かないアカウントを見ていくと、ネタ切れより先に「このアカウントは何を出す場所なのか」が決まっていない。正直に言うと、ほとんどがこれです。先にテーマの柱を 3〜5 本に固定し、どの柱にも当てはまらないネタは投稿しない。ここが運用の基準になります。割合の目安は、教える 4 割・楽しませる 3 割・気持ちを動かす 2 割・宣伝 1 割。宣伝をこの 1 割に収め、残りで信頼と見つけてもらう機会を稼ぎます。

頻度は「無理なく続く下限」から（たとえば週 3）。質を落として本数を追うと、伸びないうえに続きません。編集カレンダーは 1 行 1 投稿で、日付・柱・形式・媒体・テーマと 1 行目のフック・うながし・状態（案・撮影待ち・予約済み）を列に持たせます。この表がそのまま、7.3 で述べる予約の元になります。

この設計をエージェントに頼むときの依頼文を示します。駅前の美容室が Instagram を主軸にし、TikTok へ展開する場合の例です。

依頼の例（前提を書いた依頼）

駅前の美容室（スタッフ 4 名、20〜30 代の女性客が中心）の Instagram と TikTok について、
11 月の投稿計画を作ってください。

目的: 新規の予約を増やす（店舗集客型）。見る数字はリーチとプロフィールのリンクのタップ。
主軸: Instagram。TikTok には同じ素材を TikTok の作法に翻訳して出す。
頻度: Instagram は週 3 本、TikTok は週 2 本。これより増やさない。
テーマの柱: ①髪のお手入れの知識 ②施術のビフォーアフター ③スタッフと店の雰囲気
  ④予約・キャンペーンの告知。④は全体の 1 割以内にする。
使える素材: 10 月に撮影した施術写真 40 枚と、スタッフ紹介の動画 3 本（一覧を添付）。
  手持ちの素材で出せない投稿は、状態を「撮影待ち」にして分ける。

出力: 1 行 1 投稿の表。列は日付・柱・形式・媒体・1 行目のフック・うながし（1 つだけ）・
  使う素材・状態。表の後に、柱ごとの本数と宣伝の割合を集計する。

やらないこと:
  - 予約と投稿のツールは呼ばない（今回は計画だけ）。
  - お客様が写っている写真は、素材一覧の掲載許諾が「済」のものだけ使う。
  - 料金と割引率は書かず「（料金は確認中）」と空けておく。

目的と見る数字が書いてあれば、柱の配分も、1 投稿に 1 つだけ付ける「うながし」の選び方も決まります。「やらないこと」で予約と投稿のツールを封じたのは、計画を頼んだだけの回に確認画面を出さないためです。計画の依頼と外部反映の依頼は、別の回に分けておきます。料金を空けさせるのも同じ用心です。エージェントが推測した価格が下書きに残ると、そのまま予約の確認画面まで進みかねません。

足りない例

インスタの 11 月の投稿ネタを 30 個考えて。

この依頼では目的も頻度も柱も決まっていないので、エージェントは一般的な美容室のネタを 30 個並べます。30 個は毎日投稿する前提の本数で、スタッフ 4 名の店では続きません。柱が無いため、投稿前のセルフレビューにある「どの柱に属するか」も判定できず、翌月に柱ごとの良し悪しを比べる材料が残りません。素材の一覧も渡していないので、撮影が必要なネタと手持ちで出せるネタの区別もつきません。

この小節の設計の進め方を手順書（SKILL.md）にすると、次のようになります。description には依頼の言い方と、扱わない依頼の行き先を書きます（第 2 章）。この章で小節に添える手順書の多くは骨子なので、使うときは本文の規則を書き足してください。

---
name: content-calendar
description: >-
  複数の SNS を横断した投稿計画（柱・配分・カレンダー・文面）を設計する。
  「今月の投稿計画を作って」「テーマの柱を決めたい」「キャプションを書いて」
  「ネタが尽きた」で使う。
  ※投稿の実行・予約は投稿のスキル、単発のショート企画はショート企画のスキル（第 4 章）。
---
# 投稿計画

## 手順
1. 目的を 3 類型のどれかに寄せる（店舗集客 / EC 購買 / 採用）
2. テーマの柱を 3〜5 本に固定する。どの柱にも入らないネタは投稿しない
3. 配分の目安を置く（教える 4 / 楽しませる 3 / 気持ちを動かす 2 / 宣伝 1）
4. 頻度は「無理なく続く下限」から始める
5. 1 行 1 投稿の表にする（日付・柱・形式・媒体・1 行目のフック・
   うながし（1 つだけ）・使う素材・状態）
6. 主軸の 1 本を他の SNS の作法に**翻訳**する（貼り付けにしない）

## 守ること
- 持ち素材で出せない投稿は、状態を「撮影待ち」にして分ける
- 料金・割引率は推測で埋めず「確認中」と空ける
- 投稿しない（計画まで）

この手順書が持つのは、投稿の文面の書き方ではなく、計画を組む順番と落とす基準です。目的の 3 類型と柱の固定を先頭に置いた理由は単純で、止まるアカウントの原因はネタ切れではなく「何を出す場所か」が決まっていないことにあります。ここを手順書に固定しておけば、依頼文に柱が無い回でも、エージェントは柱を決める工程から始めます。配分と頻度の目安をあえて数字で書いたのは、目安が無いと毎日投稿する前提の本数が返ってくるからです。続かない計画を、その場で弾く基準になります。

「翻訳する（貼り付けにしない）」を手順に入れたのは、主軸の 1 本を他の媒体へ展開する依頼で、同じ文面の複製がいちばん起きやすいためです。守ることの「撮影待ち」と「料金は確認中」は、案件が変わっても同じ形で出る失敗への備え。手持ちの素材で出せない投稿が混ざれば計画は実行できず、推測した価格は下書きに残ったまま予約の確認画面まで進みます。最後の「投稿しない」は計画の依頼と外部反映の依頼を別の回に分けるもので、依頼文の「やらないこと」と合わせて二重に止めています。description の末尾では、投稿の実行と単発のショート企画を別の手順書へ送りました。「投稿して」という依頼でこの手順書が立てば、計画だけ作って終わるか、逆に計画の依頼で予約のツールが呼ばれるか、どちらかになるからです。

形式の役割と、各 SNS への翻訳

形式にはそれぞれ役割があります。たて型動画が新規に見つけてもらう役、カルーセル（複数枚の画像）が保存される役、ストーリーズが関係の維持、ハイライトが初めて来た人への説明、という分担。うながし（保存して・プロフィールから・コメントで）は 1 投稿に 1 つだけにします。全部書くと、どれもされない。伝えたいことが 2 つあるなら 2 投稿に分けます。

主軸にする SNS を 1 つ決め、そこで作った 1 本を他へ展開します。ただしそのまま貼り付けず、それぞれの作法に翻訳する。

• TikTok — 流行の音源とテンポ。作り込みすぎない
• Instagram — たて型動画で見つけてもらい、カルーセルで保存させる。投稿は単体ではなく 9 枚のグリッドとしての見え方で判断する
• YouTube ショート — 同じ動画でも、タイトルと説明に探される言葉を入れる
• X — 要点をスレッドに。一方的な告知より会話への参加を優先する

文面は型で書きます。1 行目でスクロールを止め、本文は価値 → 具体 → 共感の順、うながしは 1 つ。ハッシュタグは Instagram と TikTok で 5〜8 個、大・中・小を混ぜ、実際に上位を狙える中〜小を主力にする。X は 1〜2 個で足ります。自分たちのタグを 1 つ用意しておくと、お客さんの投稿を集められます。

公開後 1 時間の初動が届く範囲を左右するので、投稿直後はコメントへの返信に時間を充てます。X ではメンションと DM に営業時間内 2 時間以内、評判に関わる事案は 30 分以内、という反応の基準を先に置いておく。お客さんの投稿（UGC）を転載するなら事前の許諾が必須で、どの投稿を・どこで・どう使うかを明示して許諾を取り、やり取りを記録に残します。対価と引き換えに投稿してもらったものは広告にあたるので、PR 表記を条件に含めます。

Instagram：運用方針を 1 枚にまとめる

Instagram では、形式の使い分けに加えて「誰の投稿か一目で分かる」見た目の統一が効きます。投稿を 1 本ずつ頼むと、写真の色味も文字の置き方も毎回変わります。そこで最初に運用方針を 1 枚にまとめ、以後の依頼はすべてこの 1 枚を前提にします。

方針に入れるのは 5 つです。①見た目の決まり（色を 3〜5 色、写真の質感、カルーセルの表紙の型）②形式ごとの役割と頻度 ③ハイライトの分類（初めて来た人が読む順に並べる）④ストーリーズの使い方（毎日の接点と、フィードやリールへの案内）⑤コメントと UGC の扱い。見た目の良し悪しは 1 投稿ではなく、プロフィールに並ぶ 9 枚で判定します。

account: 駅前の美容室（Instagram）
purpose: 店舗集客型（新規の予約）
visual:
  colors: ["#F4EDE4", "#3B3B3B", "#C98B6B"]   # 地の色・文字・差し色
  photo: 自然光、店内の木目が入る構図、人物は後ろ姿か手元
  cover_template: 上 1/3 に見出し 1 行、下 20% には文字を置かない
  check: 9 枚並べて色と余白が崩れていないかを投稿前に確認する
formats:
  reel:     {role: 新しい人に見つけてもらう, per_week: 2}
  carousel: {role: 保存される, per_week: 1}
  stories:  {role: 常連との接点, per_day: 1, link_to: 最新のリール}
highlights: [はじめての方へ, メニューと料金, スタイル集, お客様の声, よくある質問]
community:
  reply: 公開後 1 時間は返信を優先する
  ugc: 掲載は許諾を取ったものだけ。許諾のやり取りを記録に残す

方針をこの形で持っておくと、投稿の依頼には「方針の visual に従う」と書くだけで済みます。保存率のような数字の目標は方針に入れず、7.9 のレポートで自分の過去平均と比べます。

新しい人に届けたいリールでは、「保存したくなる」より「誰かに送りたくなる」を設計します。Instagram の責任者は執筆時点で、フォロワー以外への配信では送信（DM でのシェア）がより重く扱われると説明しています。フォロワーの反応を気にせず企画を試したいときは、フォロワー以外にだけ先に表示するお試しリール（Trial Reels）が使えます（公式の案内）。使えるアカウントの条件は公式ヘルプで確認してください。

運用方針を作る作業も、依頼のたびに書かずに済むように手順書にしておきます。方針の中身（上の YAML）は案件ごとに変わり、手順書のほうは方針の作り方を持ちます。

---
name: instagram-playbook
description: >-
  Instagram の運用方針を 1 枚にまとめ、以後の依頼の前提にする。
  「インスタの運用を設計して」「世界観を決めたい」「ハイライトを整理して」
  「フォロワーを増やしたい」で使う。
  ※縦型動画の台本はショート企画のスキル、実績のレポートは月次レポートのスキル。
---
# Instagram の運用方針

## 1 枚に入れる 5 つ
1. 見た目の決まり（色を 3〜5 色、写真の質感、表紙の型）
2. 形式ごとの役割と頻度（たて型動画 = 見つけてもらう / カルーセル = 保存される）
3. ハイライトの分類（初めて来た人が読む順に並べる）
4. ストーリーズの使い方
5. コメントと、お客さんの投稿の扱い（転載は許諾を取り、やり取りを残す）

## 守ること
- 見た目の良し悪しは 1 投稿ではなく、並んだ 9 枚で判定する
- 数字の目標はこの 1 枚に入れない（レポートで過去平均と比べる）

この手順書が作るのは、方針という 1 枚の文書だけです。投稿の文面も画像も作りません。方針を手順書から切り離したのは、投稿を 1 本ずつ頼むたびに写真の色味も文字の置き方も変わってしまうからです。色や写真の質感は案件ごとに違うので、手順書ではなく方針の 1 枚に置き、以後の依頼から「方針に従う」と指せるようにします。手順書のほうは、その 1 枚に何を入れるかだけを持ちます。5 つを列挙したのは、ハイライトやストーリーズの扱いが方針から抜けると、そこだけ投稿ごとの判断に逆戻りするためです。

守ることの「並んだ 9 枚で判定する」は、見た目の統一が 1 投稿では確かめようがないことから来ています。「数字の目標はこの 1 枚に入れない」のほうは、固定のしきい値だと業種と規模で基準が変わるため。数字は 7.9 のレポートで自分の過去平均と比べます。方針にまで目標を書けば、比べる相手が 2 つに割れます。転載に許諾と記録を条件として入れたのは、方針に無いと転載の可否が投稿ごとの判断になり、やり取りも残らないからです。description の末尾で縦型動画の台本と実績のレポートを別の手順書へ送っているのは、方針の守備範囲が形式ごとの役割と頻度までだからで、台本の中身も数字の評価もここでは持ちません。

カルーセル：本編を先に書き、表紙は最後に書く

カルーセルは保存を取りにいく形式です。見られる順番は表紙 → 本編 → まとめ → うながしですが、書く順番は逆にします。元の素材（ホームページ、よく読まれた過去の投稿、スタッフへの聞き取り）から論点を箇条書きで抜き出し、1 投稿で扱うテーマを 1 つに絞り、論点を読む順に並べて 1 枚 1 論点に割り当てる。表紙は本編が固まってから、いちばん価値のある結果を選んで書きます。先に表紙を書くと、表紙の約束に本編を合わせることになり、中身の薄い枚が混ざります。

枚数は目的で変えます。著者の目安は、手順の解説で 6〜10 枚、「◯選」のリストで 7〜10 枚、体験談で 5〜7 枚、1 論点の深掘りで 3〜5 枚。迷ったら 6〜8 枚です。どれにも「まとめ」の 1 枚を入れます。全体を 1 枚で見返せる枚があると、保存する理由になるからです。

作りの決まりは 4 つです。1 枚に 1 つのことだけ書く。見出しを一番大きくし、解説は 2〜3 行にする。下端の 2 割には大事な文字を置かない（ユーザー名や操作ボタンに隠れる）。色・書体・余白は表紙で決めた型を最後まで使う。

媒体の仕様も先に確かめておきます。執筆時点の Instagram の公開 API では、カルーセルは画像と動画を合わせて 10 件までで、すべての画像が 1 枚目の縦横比で切り取られます（コンテンツ公開）。TikTok の写真投稿は API から 35 枚まで出せますが、写真は URL から取り込ませる方式しかなく、そのドメインの所有確認が要ります（写真投稿のリファレンス）。7.6 で動画はファイルのままアップロードすると書きましたが、写真は条件が違います。アプリから手で出せる枚数が API より多いこともあるので、アプリの上限を前提に 11 枚以上で構成すると、予約のツールに弾かれます。

文字が主役の枚は、画像生成 AI に作らせません。執筆時点の画像生成では日本語の文字が崩れることがあるので、HTML で組んで画像として書き出すか、デザインツールのテンプレートに流し込みます。生成に任せるのは背景や挿絵だけです。どの方法でも、書き出したあと 1 枚ずつ開いて文字を検品します。

エージェントに頼むときは、画像より先に構成シートを出させます。構成シートまではどの環境でも作れるので、画像化の手段が無いときもここまでは必ず納品できます。

# カルーセル構成: 施術の前に知っておきたい 4 つのこと
- 媒体: Instagram（全 7 枚。API の上限 10 件以内）
- 目的: 保存 / 見る数字: 保存数とシェア数（自分の過去平均と比べる）
- 素材: 施術写真の一覧のうち、掲載許諾が「済」のもの

| # | 役割     | 見出し（1 行）                   | 解説（2〜3 行）            | 画の指示                   |
|---|----------|----------------------------------|----------------------------|----------------------------|
| 1 | 表紙     | 施術の前に知っておきたい 4 つ    | 予約の前に読んでほしい理由 | 手元の写真、見出しは上 1/3 |
| 2 | 本編     | 論点 1（例: 前日に避けたいこと） | 結論 → 理由の順で          | アイコン 1 つ              |
| … | …        | …                                | …                          | …                          |
| 6 | まとめ   | 4 つを 1 枚で                    | 予約の前に見返す用         | 4 項目の一覧               |
| 7 | うながし | 保存して予約の前に確認           | うながしは 1 つだけ        | 差し色で締める             |

## 投稿前の確認
- 表紙だけで何が得られるか分かるか / 各枚 1 論点か / 下端 2 割に文字が無いか
- まとめの枚があるか / うながしは 1 つか / 施術の説明は店が確認した内容か

最後の確認項目は、エージェントが一般論で書いた施術の説明を、店の確認なしに出さないためのものです。

構成シートまでを作る手順を手順書にすると、次のようになります。画像化と投稿は別の手順書が扱うので、description の末尾にその行き先を書いています。

---
name: carousel-design
description: >-
  複数枚のスライド投稿（カルーセル）の構成を設計する。
  「カルーセルを作って」「保存される投稿」「表紙のフック」で使う。
  ※画像化は画像生成のスキル（第 4 章）、投稿は投稿のスキル。
---
# カルーセルの構成

## 手順（書く順番は見る順番の逆）
1. 元の素材から論点を箇条書きで抜き出す
2. 1 投稿 1 テーマに絞る
3. 1 枚 1 論点で割り当てる（手順の解説 6〜10 枚 / 体験談 5〜7 枚）
4. 「まとめ」の 1 枚を必ず入れる（保存する理由になる）
5. **表紙は最後に書く**（先に書くと中身の薄い枚が混ざる）

## 作りの決まり
- 1 枚に 1 つだけ書く / 見出しを一番大きく / 解説は 2〜3 行
- 下端の 2 割に大事な文字を置かない（操作ボタンに隠れる）
- 枚数の上限はアプリではなく**予約の口が受け付ける上限**で決める
- 文字が主役の枚は生成 AI に作らせない

この手順書の出口は構成シートで、画像化も投稿もしません。構成シートまでなら、どの環境でも作れるからです。画像化の手段が無い案件でも、成果物がゼロにはなりません。description に「表紙のフック」を入れたのは、表紙だけを頼まれた回にもこの手順書を立たせ、本編から書く順番に乗せるためです。

手順の見出しに「書く順番は見る順番の逆」と書き、表紙を最後に回しました。先に表紙を書くと、表紙の約束に本編を合わせることになり、中身の薄い枚が混ざります。エージェントは頼まれた順に書くので、順番は手順書が持たないと守られません。「まとめ」の 1 枚を必ず入れさせるのは、カルーセルが保存を取りにいく形式だからです。全体を 1 枚で見返せる枚が、保存する理由になります。

作りの決まりの「上限は予約の口が受け付ける上限で決める」は、アプリから手で出せる枚数が API より多い場合への備えです。執筆時点の Instagram の公開 API は画像と動画を合わせて 10 件まで。アプリの上限を前提に 11 枚以上で構成すると、構成を終えたあとで予約のツールに弾かれます。「文字が主役の枚は生成 AI に作らせない」を構成の手順書にも書いたのは、画の指示を書くのがこの手順書だからです。ここで「生成」と書いた指示は、そのまま画像化の手順書へ渡ってしまいます。

X：告知ではなく会話に加わる

X は、店舗型ビジネスのクライアント案件より、会社や経営者自身の発信で使う場面が多い媒体です。一方的な告知より、他の人の投稿への返信や引用で会話に加わるほうが見つけてもらえます。配分は、教える投稿・体験談・業界の話題への論評を中心に、会話への参加（返信・引用）を 1〜2 割含め、告知は 1 割に収めます。

文字数の数え方を先に押さえます。X は日本語の文字を 1 文字 2 として数えるので、通常の投稿は日本語で 140 字までです（文字数の数え方）。長い投稿と記事（Articles）は有料プランの機能で、使えるプランも上限も変わるため、執筆時点の X のヘルプで確認します（X Premium について）。エージェントに下書きを頼むときは、どの形式で出すかを先に書きます。書かないと、140 字を超えた下書きが 1 本の投稿として返ってきます。

スレッド（連続した投稿）は次の型で組みます。

1 本目: 結論か約束（「〜すると予約の取りこぼしが減る。理由は 3 つ」）
2〜n 本目: 1 本に 1 つの論点。具体例か数字を必ず入れる。
          1 本だけ読まれても意味が通るように切る
n+1 本目: 要点を短く並べ直す（あとで見返す人のため）
最後: うながしを 1 つだけ（プロフィールのリンクか、保存か）
使わない締め: 「最後まで読んでいただきありがとうございました」

X は調べる場としても使います。自社名や業界の言葉の会話を読むときは、観測した事実と自分の解釈を分けて書き、確信度を添えます。証拠として投稿の URL、観測した時刻、使った検索語、対象期間を必ず残す。数件の投稿から「話題になっている」と断定しないためです。報告は次の形にします。

# X の会話の報告（10/1〜10/7。検索語: 「店名」「店名 予約」「店名 駐車場」）
| 観測した事実                   | 件数 | 証拠                       | 解釈（仮説）               | 確信度 | 次の一手                 |
|--------------------------------|------|----------------------------|----------------------------|--------|--------------------------|
| 「駐車場が分かりにくい」の投稿 | 4    | URL 4 件（観測 10/3〜10/6） | 行き方の案内が足りない     | 中     | 行き方のカルーセルを作る |
| 新メニューへの好意的な言及     | 2    | URL 2 件                   | 件数が少なく傾向とは言えない | 低     | 様子を見る               |

取れなかったもの: 非公開アカウントの投稿（見られないため。0 件とは書かない）

定点で見張る方法と返信の下書きは、第 8 章で扱います。

X の投稿と調べ方は、1 つの手順書にまとめます。経営者の名前で出す長文は、次の小節の手順書が扱います。

---
name: x-playbook
description: >-
  X（旧 Twitter）の運用と、公開の会話の調べ方を扱う。
  「X の運用」「スレッドの構成」「リプライの方針」「自社の話題を調べて」で使う。
  ※経営者の長文投稿は長文投稿のスキル、横断の口コミ監視はリスニングのスキル（第 8 章）。
---
# X の運用

## 投稿
- 配分：教える / 体験談 / 業界の話題への論評を中心に、
  会話への参加（返信・引用）を 1〜2 割、告知は 1 割
- 日本語は 1 文字 2 として数える——**どの形式で出すかを先に指定させる**
- スレッドは「結論 → 1 本 1 論点 → 要点の並べ直し → うながし 1 つ」

## 調べる
- 観測した事実と解釈を分け、確信度を添える
- 証拠として投稿の URL・観測時刻・検索語・対象期間を必ず残す
- 数件の投稿から「話題になっている」と断定しない
- 非公開の投稿は「未取得」。0 件と書かない

この手順書は投稿の作法と調べ方を 1 つに持ち、外へ出す操作は持ちません。投稿と調べ方を分けていないのは、X で見つけてもらう手段が一方的な告知ではなく、他の人の投稿への返信や引用だからです。会話に加わるには、まず会話を読まなければなりません。

文字数の規則を「どの形式で出すかを先に指定させる」という形にしているのは、上限そのものを手順書に書けないからです。長い投稿と記事は有料プランの機能で、使えるプランも上限も変わります。代わりに、日本語は 1 文字 2 として数えるという変わらない数え方だけを持たせ、形式の指定が無い回に 140 字を超えた下書きが 1 本の投稿として返ってくる失敗を止めます。

調べる側の規則は、数件の投稿を読んだだけのエージェントに「話題になっている」と書かせないためのものです。証拠として URL・観測時刻・検索語・対象期間を残させれば、報告にある「4 件」が、どの検索語で、いつ、どの期間を見た 4 件なのかを読む人が判断できます。非公開の投稿を 0 件と書かせないのは、見られなかったものと無かったものを報告の上で区別するため。検索語と対象期間は案件ごとに違うので依頼文に残し、手順書はその扱い方だけを持ちます。description の末尾では、経営者の長文と横断の口コミ監視を別の手順書へ送りました。長文には AI の文章の癖を拾う別の確認が要り、横断の定点監視は媒体をまたぐ第 8 章の話だからです。

経営者の声で書く長文投稿

会社の発信では、経営者の名前で長文を出すことがあります。ここを AI に書かせると、整っているのに誰が書いても同じ文章になりがちで、読む人は数行で気づきます。長文のスキルに持たせるのは、構成・材料の規則・出す前の確認の 3 つです。

構成は「冒頭 1〜2 行で意外な主張か数字を出す → 2〜3 行で書き手が何者かを示す → 問題、実際に起きたこと、直し方の順で節を重ねる → 多くの人が口にしない本音 → やってよかったか、その理由」。材料は実業務の数字と出来事だけを使います。実数が無いなら数字を書かない。クライアント名と非公開の金額は出さない。

出す前の確認では、AI の文章に出やすい癖を拾います。否定で定義する言い回し（「これは〜ではない。〜だ」）、重要性を大きく言う形容（「画期的な」「重要な転換点」）、出典の無い「専門家によると」、根拠の無い 3 つ並べ、同じ意味の言い換えの繰り返し、締めの「今後が楽しみです」。見つかったら書き直します。

型は実績を見てから変えます。書く前に似た話題の過去の投稿の数字（表示回数・反応・プロフィールへのクリック・フォロワーの増減）を取り、公開後に同じ数字を取って比べる。比べる相手より良かったときだけ型を変え、元に戻す条件も書いておきます。下の「型は勝ったときだけ更新する」と同じ規則です。

---
name: founder-longform-post
description: >-
  経営者の名前で出す X の長文投稿・スレッドを書く。
  「社長の名前で長文を書いて」「創業の話をスレッドにして」「この失敗談を投稿にして」で使う。
  ※X の日々の運用と会話の調査は X 運用のスキル、投稿の実行は投稿のスキルが扱う。
  このスキルは下書きまで。投稿はしない。
---
# 経営者の長文投稿

## 入力（無ければ聞く）
- テーマ / 切り口（逆の立場からの主張か、独自の見方）/ 材料（実際の数字・出来事）
- 出す形式: 通常の投稿のスレッドか、長い投稿か（長い投稿は有料プランが要る）

## 手順
1. 似た話題の過去の投稿の数字を取り、効いた冒頭の型を選ぶ
   （取れなければ「比較なし」と書く）
2. 構成: 冒頭の主張 → 書き手の立場 → 問題・起きたこと・直し方 → 本音 → 結論
3. 数字は材料にあるものだけ。無ければ数字を使わない
4. 出す前の確認で引っかかった文を書き直す

## 出す前の確認
- 否定で定義する言い回し / 大げさな形容 / 出典の無い「専門家によると」
- 根拠の無い 3 つ並べ / 締めの決まり文句 / クライアント名・非公開の金額

## 出力
- 貼り付けられる本文だけ（前置きを付けない）
- 別紙: 使った数字の出典、比べた過去の投稿、公開後に見る数字と日付

この手順書は下書きまでで、投稿はしません。X の日々の運用と別の手順書にしているのは、経営者の名前で出す文章に固有の失敗が 2 つあるからです。AI に書かせると整っているのに誰が書いても同じ文章になり、読む人は数行で気づくこと。そして、材料の無いところに数字が入ることです。

入力を「無ければ聞く」としたのは、材料を実業務の数字と出来事に限っているからです。エージェントは材料が無くても書けてしまうので、何を聞くかは手順書の側で決めておきます。出す形式も入力に含めました。長い投稿は有料プランの機能で、指定が無いと 140 字を超えた下書きが 1 本の投稿として返ってきます。手順 1 で過去の投稿の数字を先に取らせるのは、型を勝ったときだけ更新するため。勝ち負けの記録が無いまま型を変え続けると、伸びたのが型のせいか話題のせいか分からなくなります。取れなければ「比較なし」と書かせるのは、比べてもいない冒頭を効いた型として選んだ回を、後から見分けるためです。

出す前の確認に AI の文章の癖を列挙しているのは、書き方の指示より出す前に自分で落とす基準のほうが効くと、著者が実際にやってみて分かったからです（7.2）。手順 3 と出力の別紙は、数字をでっち上げさせないための仕掛けです。別紙に出典を書けない数字は本文にも入れられず、公開後に見る数字と日付を別紙に残せば、次に書くときの手順 1 の材料になります。テーマ・切り口・材料は案件ごとに違うので依頼文に残し、構成と癖の一覧と出典の規則は案件が変わっても同じなので手順書が持ちます。

スキルにするのは「型」と「セルフレビュー」

ここまでの設計は、そのまま AI エージェント（第 2 章。以下、エージェント）に渡すスキルの中身になります。柱・配分・形式の役割・各 SNS への翻訳の作法を手順書にし、末尾に投稿前のセルフレビューを置く。「この投稿はどの柱に属するか即答できるか」「1 行目だけで続きを読みたくなるか」「うながしは 1 つに絞られているか」「各 SNS へ翻訳済みか（単純な貼り付けになっていないか）」。実際にやってみて分かったのは、AI に書かせるときに効くのが書き方の指示ではなく、出す前に自分で落とす基準だということです。

数字は自分の過去平均と比べ、型は勝ったときだけ更新する

数字の良し悪しは、自分のアカウントの過去平均と比べます。「エンゲージメント率 3% 以上なら合格」のような固定のしきい値だけでは判断しない。業種と規模で基準が変わるからです。たて型動画なら見る順番も決めておきます。3 秒まで見てもらえた割合 → 平均視聴秒数 → 保存率とシェア率 → プロフィール遷移率。離脱の大半は冒頭で起きるので、冒頭を 3〜5 パターン作って本編と締めを固定し、差が付いたら冒頭のせいだと切り分けられる作りにしておきます。

型の更新にも規則を置きます。投稿ごとにフックの型・構成・うながし・話題を記録し、公開後に実績を取り、類似投稿のベースラインと比べる。上回ったときだけ型を直し、戻す条件も書いておく。勝ち負けの記録が無いまま型を変え続けると、伸びたのが型のせいか話題のせいか分からなくなります。どの投稿が反応を得たかを柱ごとに記録し、翌月の配分に反映します。これがループの「翌月の配分へ」の矢印です。

企画には実例の根拠を付け、出典の無い数字を使わない

たて型動画の企画を AI に頼むと、「いま伸びている型です」という説明付きで返ってきます。この一文は、受け取った人には確かめようがありません。企画ごとに、参考にした実在の投稿の URL、そのとき取れた数字（再生・いいね・保存など）、取得した日を根拠として付けさせます。参考にする投稿の候補と数字は、人が Instagram や TikTok の画面で集めた一覧を渡します。両社とも利用規約で自動収集を禁じているので、エージェントに探しに行かせません。実例が見つからなかったときは「参考実例なし（型から作った）」と書かせる。存在しない投稿や数字で埋めるより、根拠が無いと分かるほうが判断できます。他社の投稿は URL で示し、スクリーンショットを企画書に貼りません。自社の素材と混ざると、使ってよい素材に見えるからです。

出典の無い数字も、企画や報告に入れません。「視聴維持率 70% が合格ライン」「離脱の半分は最初の 3 秒」のような数字は広く出回っていますが、たどっても媒体の公式な一次データに行き着かないものが多くあります。媒体が視聴維持率の基準値を公表していない以上、良し悪しは自分のアカウントの過去平均と比べて決めます。企画の依頼には、この 2 点を書き込んでおきます。

（企画の依頼文の末尾に足す 3 行）
添付の参考投稿の一覧から選び、各企画に「参考にした投稿の URL・一覧にある再生数などの数字・取得日」を付けてください。
見つからなければ「参考実例なし」と書き、投稿や数字を作らないでください。
視聴維持率などの基準値は使わず、このアカウントの直近 3 か月の平均と比べてください。

3 行目があると、エージェントが一般論の基準値を持ち出して「合格」「不合格」を付けることがなくなります。比べる相手が決まっていれば、判定の根拠を後から確かめられます。

カレンダーは「やること」と「ひとりでに動くもの」を同じ月に並べる

投稿の予約を、それ単体のカレンダーにしないでください。タスクの期日と、決まった時刻に自動で動くもの（定期実行・広告の時間指定・毎日の自動実行）を同じ月に並べます。「今月やること」と「今月なにが自動で動くのか」を突き合わせられないと、期日の当日に何も動かない予定になっていることに、誰も気づけません。

止めているものも薄く出しておきます。カレンダーから消すと、「止めたつもりが動いている」「動いているつもりが止まっている」を確かめる方法が無くなる。登録と変更の入口はそれぞれの置き場に 1 つずつ置き、カレンダーからは飛ぶだけにします。同じ設定に入口が 2 つあると、どちらで直したかで結果が変わって見えます（原則 A：正本は 1 箇所）。

7.3 投稿・予約を API 化する

公式の投稿 API に「予約」は無い

先に前提を揃えておきます。執筆時点で、主要な SNS の公式 API は呼んだ瞬間に公開されるものがほとんどで、予約の機能は API 側にありません。

出典はそれぞれ公式ドキュメントです（Instagram のコンテンツ公開、TikTok Content Posting API、X API の投稿作成、YouTube Data API の動画リソース）。仕様は変わるので、実装前に必ず確認してください。

YouTube だけが例外で、非公開でアップロードしておき公開予定時刻を指定すると、その時刻に公開されます。裏を返せば、YouTube 以外は「時刻が来たら出す」仕組みを自分で持たなければならない。TikTok には、推測で回避してはいけない制約が 2 つあります。公開範囲の選択肢はアカウントごとに違い、照会が返した選択肢以外を送ると弾かれること（非公開アカウントには「全体公開」が現れません）。そして審査前のアプリからの投稿は、何を指定しても非公開になること。だから公開範囲を既定値に落としてはいけません。推測した公開範囲で投稿すると、取り消せない形で外に出ます。

予約は自前で持つ

予約の実体は、自分のデータベースの 1 テーブルです。最小の形はこのくらいで足ります。

scheduled_post:
  id: spost_01J…
  project_id: prj_…            # 案件（契約単位のテナントに属する）
  status: scheduled            # → publishing → published / partial / failed / cancelled
  content: "本文"
  platforms: [tiktok, instagram]
  accounts:                    # 予約するときに確定。配信時に選び直さない
    tiktok: "open_id_A"
    instagram: "ig_user_id_B"
  media:                       # 公開 URL はここでは作らない（素材の ID だけ）
    - {type: video, asset_id: vid_…}
  scheduled_for: "2026-10-01T01:00:00Z"   # 判定用（UTC）
  scheduled_local: "2026-10-01T10:00"     # 表示用（予約した人の地域時刻）
  timezone: Asia/Tokyo
  results: []                  # 媒体ごとの結果。どのアカウントに出たかを名前で残す
  last_error: null

状態の設計で 1 つだけ強調しておきます。出なかった予約には、状態と一緒に理由を残すこと（上の例では last_error）。同じ「出なかった」でも、原因が「媒体の API が落ちていた」のか「宛先アカウントの連携が切れていた」のかで、次の一手が違います。前者は人が様子を見て予約し直し、後者は連携し直してから予約し直します。

配信は、期限の来た予約を拾う巡回で行います。巡回は 1 時間に 1 回、定期実行の仕組み（第 11 章）に同乗させる。ここから 2 つの決まりが出てきます。

• 予約できるのは正時だけ（毎時 00 分）。分単位で指定できても、巡回が毎時なら 19:07 の予約は「指定した時刻には出ない予約」にしかなりません。刻みを 1 時間に固定して、指定した時刻と実際に出る時刻の意味を揃えます（原則 M）。
• 正時かどうかの判定は、予約した人が入力した地域時刻で行います。いったん UTC に直してから分を見ると、時差が 30 分・45 分の地域では正時の入力だけが弾かれる。判定用の UTC と表示用の地域時刻を両方保存するのはこのためです。

予約のツールが受け付けるのは未来の時刻だけです。確認画面で内容を読んでいる最中に予約の時刻が来てしまわないよう、数十分以上先を要求します。一方で、予約の取り消しのツールは確認の対象にしません。外に何も出さない向きだからです。

時刻が来てから初めて落ちるものは、予約のツールが実行された時点で弾き、予約の行を作らずに理由を返します。本文が空、投稿先が未選択、同じ媒体を 2 回選んでいる、TikTok なのに動画が無い、公開範囲が未指定、Instagram なのに画像も動画も無い、素材が実在しない・種類が違う、時刻が過去。時刻が来てから落ちても、その場で理由を読む人はいません。また、確認画面はツールが実行される前に出るので、人はこの検証より先に呼び出しを目にします。人が確認画面で「内容は良いが日付が過去」を見つけて断るのは無駄な往復なので、宛先・素材・時刻は、エージェントにも予約のツールを呼ぶ前に確かめさせます（後で示すスキルの手順 1〜4）。

パーミッション：予約する呼び出しを人が確認する

投稿は外部反映です。取り消せません。削除はできても、見た人にはもう届いている。だから外へ出る向きの操作のツールは、すべてパーミッション（第 2 章）で確認の対象にします。投稿の作成・公開・変更・削除・返信と、予約の作成・変更です。実績の取得と予約の取り消しは、確認なしでかまいません。Claude Code では settings.json の ask に書き、claude.ai のコネクタでは「承認が必要」を選びます。SNS の MCP サーバーを sns という名前で接続しているなら、Claude Code の設定は次のようになります（ツールの名前は例です）。

{
  "permissions": {
    "allow": ["mcp__sns__get_*", "mcp__sns__cancel_scheduled_post"],
    "ask": ["mcp__sns__schedule_post", "mcp__sns__update_scheduled_post", "mcp__sns__publish_now"]
  }
}

ツールを自分で作るなら、外へ出る向きのツールに確認必須の印（anthropic/requiresUserInteraction。第 2 章）も付けておきます。Claude Code では、この印の付いたツールは、確認を省くモードでも、利用者が allow に書いていても、毎回確認画面が出ます。

確認画面に表示されるのは、ツールの名前と引数だけです。だから予約と投稿のツールには、投稿先のアカウント名（ID だけにしない）・本文・時刻（予約した人の地域時刻）・素材の名前を引数として持たせ、確認画面でそのまま読めるようにします。サーバーの側では、引数のアカウント名と ID が食い違っていないかを確かめます。誰がいつ許可したかは、パーミッションの仕組みでは、ツールを提供する側に残りません。予約と投稿を実行したツールの側で、誰の接続で・いつ・何を・どのアカウントへ実行したかを 1 件ずつ記録します。

予約投稿に特有なのは、確認した時点と実際に出る時点が離れていることです。確認画面が出るのは予約のツールを呼んだ時点の 1 回だけで、配信の時点で人がもう一度確認する仕組みは、パーミッションにはありません。

図を原寸で開く

図の元になった mermaid を見る

mermaid

flowchart TD
  CALL["エージェントが予約のツールを呼ぶ<br>本文・素材・宛先のアカウント名・時刻（正時）"] --> D{"確認画面（人）<br>ツールの名前と引数を読む"}
  D -->|"断る"| X["何も外に出ない<br>別の経路を探さず、報告して止まる"]
  D -->|"許可"| V{"予約のツールの検証<br>宛先が 1 つに決まるか／素材は実在するか／時刻は未来か"}
  V -->|"NG"| REJ["予約を作らず、理由を返す"]
  V -->|"OK"| SCH["予約済み<br>この時点では投稿しない"]
  SCH --> T["正時の巡回（サーバーのコード）<br>期限の来た予約を拾う"]
  T --> CL{"claim<br>別の巡回が拾っていないか"}
  CL -->|"負け"| N["何もしない"]
  CL -->|"勝ち"| PUB["投稿<br>実装は即時投稿と同じ 1 本"]
  PUB --> W["結果を予約に書き戻す<br>失敗しても再投稿しない"]

巡回はエージェントではなくサーバーのコードなので、パーミッションとは関係なく動き、時刻の来た「予約済み」の行を投稿します。そのため、予約の行を作ったり内容を変えたりできる経路を、確認が必要なツール（予約の作成と変更）だけにしておきます。データベースを直接書き換える経路は作らず、エージェントにはターミナルと鍵を渡しません（第 2 章）。こうしておけば、時刻が来た予約の中身は、人が確認画面で読んで許可したときのままです。巡回のコードに残るのは、同じ予約を二重に投稿しないことと、失敗しても投稿し直さないことの 2 つです。

for post in due(status="scheduled", until=now):       # 毎時の巡回（サーバーのコード）
    if not claim(post):                               # 同時起動の二重投稿を防ぐ
        continue
    publish(post)                                     # 失敗しても再投稿しない

claim は、巡回が同時に 2 つ走ったときの対策です。定期実行の再試行やインスタンスの重複で同じ予約を 2 回拾うと、同じ内容が 2 回投稿される。こちらから消す手段はありません。「自分の印を書いてから読み直し、印が残っていれば進む」という条件付き更新で、2 つのうち 1 つだけを通します。

そして、失敗しても自動では再投稿しません（原則 R）。二重に出るほうが、出ないより悪い。失敗の理由を予約の行に残し、人が直してから予約し直します。原因として多いのは、トークンの期限切れと、素材が投稿先の条件に合っていないことの 2 つです。

もう 1 つ、投稿の実装は 1 本にします。予約でも「いますぐ出す」でも、実際に媒体の API を叩くコードは同じものを通す。経路を 2 本にすると「即時なら通るのに予約だと落ちる」差が生まれ、切り分けができなくなります。即時投稿のツールも確認の対象です。確認画面で許可した呼び出しが、表示された内容のまま 1 回だけ実行されます（原則 H）。予約との違いは「許可した時点で外に出る」ことだけです。

エージェントを人のいないところで動かす実行（定期実行で起動した作業や、外部チャットから起動した作業）では、確認画面に答える人がいないので、予約と投稿のツールは断られます（第 2 章）。予約は、人が会話しているときに行います。人のいない実行に任せるのは、投稿計画と文面の下書きまでです。

予約の一覧では、状態を必ず読みます。取り消した予約と失敗した予約も一覧に残るので、件数だけ数えて「予約済み」と報告してはいけません。確認画面で断った予約は、そもそも一覧にありません。投稿したあとは、どのアカウントに出たかを名前で報告し、投稿 URL・時刻・経路（予約か即時か）を成果物に残します。「投稿した」と「公開されている」も別物です。予約済みならまだ投稿されておらず、審査前の TikTok なら投稿しても非公開です。

予約を頼む依頼文は、確認画面でそのまま読める内容にします。宛先・時刻・素材・本文のどれかが曖昧だと、予約のツールに弾かれるか、確認画面で判断できずに断ることになります。温泉旅館の例です。

依頼の例（予約投稿）

次の投稿を予約してください。

宛先: Instagram の「本館」のアカウント（「カフェ」のアカウントには出さない）
時刻: 10 月 17 日（土）19:00（日本時間）
素材: 素材一覧の「露天風呂_夕景_縦型.mp4」（先週アップロードした実写の動画）
本文: 下の文面をそのまま使う。直したい箇所があれば、予約のツールを呼ぶ前に案を見せてください。
---
日が沈む少し前、露天風呂から見える山の色が変わります。
この時間に入りたい方は、16 時までのチェックインがおすすめです。
ご予約はプロフィールのリンクから。
#温泉旅館 #露天風呂 #紅葉の宿
---
進め方: 予約のツールを呼ぶと確認画面が出るので、私が内容を見て許可します。
  断った場合は、別の方法で投稿しないでください。
報告: 予約した宛先をアカウント名で、時刻を日本時間で書いてください。

時刻が 19:00 なのは、予約が毎時 00 分の巡回で出る仕組みだからです。19:10 と書けば予約のツールに弾かれるので、依頼の段階で正時にそろえておきます。「断った場合は、別の方法で投稿しないで」の一文は、断られた操作を別の経路で実行させないための歯止めです。auto モード（ルールに無い操作を許可するかを、人ではなく自動の判定が決めるモード。第 2 章）では、止められた操作の代わりをエージェントが探すことがあります。同じことは手順書にも書きますが、依頼文にもあれば二重に止まります。

この依頼を受ける手順書は、外へ出す操作だけを担う形にしています。何を投稿するかは決めず、企画と文面は投稿計画の手順書に任せます。骨子は次のとおりです。

---
name: publish-social-post
description: >-
  SNS（Instagram / TikTok）へ投稿する・予約する・予約を取り消す。
  「投稿して」「予約投稿しておいて」「このリールを明日出して」「予約を取り消して」で使う。
  投稿と予約のツールは、呼ぶたびに確認画面が出る。
  ※投稿の企画・文面は投稿計画のスキル、広告の出稿は広告運用のスキル、
  実績の集計はレポートのスキルが扱う。このスキルは外へ出す操作だけを担う。
---
# SNS 投稿の実行

## 手順
1. 繋がっているアカウントの一覧を取り、表示名を読む。
   - 同じ媒体に 2 つ以上あり、依頼に宛先が無ければ、ここで止めて宛先を聞く。
     既定のアカウントを選ばない。
2. TikTok に出すときは、宛先のアカウントで公開範囲の選択肢を取得し、返った値から選ぶ。
   推測した既定値を入れない。
3. 素材は素材一覧の ID で指定する。公開 URL を自分で作らない。
   実写（アップロード）か生成画像かを読み、実写が必要な投稿に生成画像を使わない。
4. 時刻を確かめる。予約は正時（毎時 00 分）で、数十分以上先の時刻だけ。依頼者の地域時刻で判定する。
   正時でなければ、前後の正時を 2 つ示して選んでもらう。
5. 予約（または即時投稿）のツールを呼ぶ。確認画面で断られたら、別の経路を探さず、
   断られたことを報告して止まる。

## 報告の形式
- 宛先はアカウント名で書く（ID だけにしない）
- 状態をそのまま書く: 予約済み / 投稿済み / 一部だけ投稿 / 失敗 / 取り消し済み
- 「投稿した」と「公開されている」を分ける（審査前の TikTok は非公開になる）

## できないときの縮退先
- 連携が無い、または目当てのアカウントが一覧に無い: 別のアカウントで代用しない。
  本文・素材・宛先・時刻を 1 つにまとめた投稿パッケージを成果物として出し、
  人が手で投稿できる形にする。「投稿した」とは書かない。
- 投稿が失敗した: 自動で投稿し直さない。理由と直し方を書いて止まる。

この手順書を「外へ出す操作だけ」に切っているのは、投稿が取り消せない操作だからです。企画と実行を 1 つの手順書に入れると、「投稿の文面を考えて」という依頼でもこの手順書が選ばれ、文面を作った勢いでそのまま予約のツールを呼びます。文面だけを頼んだ人に確認画面が出る。description の末尾で企画と実績の集計を別の手順書へ送っているのは、この取り違えを依頼の段階で断つためです。

手順の先頭に宛先の確認を置き、既定のアカウントを選ばないと書いたのは、宛先の推測が「別のアカウントに投稿された」に直結するからです（7.4）。予約のツールも指定の無い呼び出しを弾きますが、手順書に書いておけば、エージェントはツールに弾かれる前に候補を並べて止まります。往復が 1 回減ります。TikTok の公開範囲を「返った値から選ぶ」と限定しているのも同じで、推測した既定値は審査前のアプリでは非公開に固定され、非公開アカウントには全体公開の選択肢がありません（7.3）。時刻を正時に限る手順は、巡回が毎時にしか動かない仕組みの側の都合を、依頼する人に毎回説明しなくて済むように手順書へ移したものです。

「確認画面で断られたら別の経路を探さない」を手順に明記したのは、auto モードだと止められた操作の代わりをエージェントが探すことがあるからです。依頼文にも同じことを書きますが、手順書にあれば書き忘れた回にも効きます。報告で「投稿した」と「公開されている」を分けさせるのは、審査前の TikTok では投稿しても非公開のままで、報告だけを読んだ人が公開済みだと誤解するからです。縮退先に投稿パッケージを置いたのは、連携が無い案件でも成果物をゼロにしないため（第 2 章）。あわせて「投稿した」と書かせないことで、手で投稿する人が二重に出す事故を防ぎます。

7.4 宛先を推測しない：複数アカウントの設計

1 案件に、同じ媒体のアカウントを何個でも繋げる作りにします。1 店舗 1 アカウントの案件はふつうにあって、「1 案件 1 アカウント」で作ると 2 店舗目が繋げない。

保存形は配列。再認可は置き換え、別のアカウントは追加

{
  "tiktok": {
    "accounts": [
      {"account_id": "open_id_A", "username": "hotel_main",
       "access_token": "…", "refresh_token": "…", "expires_at": 1760000000,
       "scopes": ["user.info.basic", "video.publish"],
       "authorized_at": "2026-09-01T02:00:00Z"},
      {"account_id": "open_id_B", "username": "hotel_cafe", "access_token": "…"}
    ],
    "default_account_id": "open_id_A"
  },
  "instagram": {"accounts": [], "default_account_id": ""}
}

判定の鍵は媒体側の ID（TikTok は open_id、Instagram はユーザー ID）です。同じ ID の再認可は行を置き換え、別の ID は追加する。常に置き換えると 2 つ目が繋がらず、常に追加すると再連携のたびに同じアカウントが増えて、どれが生きているトークンなのか画面から分からなくなります。保存形はこの 1 つだけにし、読み書きを 1 箇所に通しておきます。形を 2 通り読める作りにすると、必ずどこかが片方だけに対応する。

1 予約 = 各媒体 1 アカウント。指定が無ければ弾く

同じ媒体の 2 アカウントへ出すなら、予約を 2 件に分けます。1 件にまとめると、結果と失敗の扱いが宛先ごとに分かれ、「一部だけ出た」状態を予約の一覧から読めなくなるからです。

繋がっているアカウントが 2 つ以上あるのに宛先の指定が無ければ、予約のツールはその呼び出しを受け付けません（原則 S）。既定のアカウントを自動で選ぶと、選び忘れがそのまま「別のアカウントに投稿された」になります。「既定」は指定しなかったときに使われるものであって、今回出すべき先ではありません。

宛先を書かなかった依頼が、実際にどう扱われるかを示します。温泉旅館の案件で、Instagram に「本館」と「カフェ」の 2 アカウントが繋がっている状態です。

依頼:
  この動画を明日の 12 時にインスタに予約しておいて。

エージェントの返答:
  Instagram には 2 つのアカウントが繋がっています。
    - 本館（表示名: 〇〇温泉 本館）
    - カフェ（表示名: 〇〇温泉 茶房）
  どちらに予約しますか。両方に出す場合は、予約を 2 件に分けます。
  時刻は 10 月 18 日（日）12:00（日本時間）で予約する予定です。
  宛先が決まるまで、予約のツールは呼んでいません。

「インスタに」は媒体の指定で、アカウントの指定ではありません。エージェントは既定のアカウントを選ばず、候補を表示名で並べて止まります。「明日」を日付と曜日に直して返しているのも同じ理由で、相対的な言い方のまま予約しないためです。仮にエージェントが宛先を聞かずに予約のツールを呼んでも、宛先の無い呼び出しは予約のツールが受け付けず、既定のアカウントへ落とすこともありません。エージェントが宛先を推測して書いた場合は、確認画面にそのアカウント名が表示されるので、人がそこで気づけます。手順書の指示、ツールの検証、確認画面の表示、この 3 段で止めています。

宛先は予約のときに確定して保存し、配信時に選び直しません。予約から配信までのあいだにアカウントが増えていると、確認画面で許可した宛先と実際に出る宛先が変わりえます。配信の時点で確定した宛先が繋がっていなければ、別のアカウントへ切り替えず失敗にする。理屈は同じです。

連携したら、必ずアカウント名を画面に出す

ブラウザが別のアカウントでログインしていると、そちらのアカウントで連携されます。このとき同意も疎通確認も通る。API は正常に動き、数字も出る。ただし出てくるのは別アカウントの数字で、投稿も別アカウントへ出ます。名前を見る以外に気づく手段がありません。 連携直後の画面と予約の一覧には、ID ではなくアカウント名を出します。確認画面に表示されるのはツールの名前と引数だけなので、予約と投稿のツールには宛先のアカウント名を引数として持たせ、確認画面に表示させます（7.3）。ID だけを見せられても、人は何も判断できません。同じ媒体に複数アカウントがあるとき、確認画面が外に出る前の最後の確認になります。

7.5 連携とトークンの寿命

共用クライアント 1 つ、コールバックは固定 1 本

Search Console や GA4 の連携（第 6 章）と同じく、SNS の連携も OAuth クライアントはサービス全体で 1 つ、コールバック URL は媒体ごとに固定 1 本です。案件ごとに URL を発行する構成は、こちらの都合ではなく構造的に取れない。TikTok はリダイレクト URI に「パラメータ・フラグメント・動的な値」を許さず、1 アプリ 10 本までです（Login Kit for Web）。Instagram はアプリに登録した URI と完全一致したものしか受け付けません（Business Login for Instagram）。

つまり「どの案件に保存するか」を URL では運べない。署名済みの state からだけ引きます。 state には案件 ID・テナント ID・認可先の媒体名を載せ、サーバーの鍵で署名し、期限を持たせる。媒体名まで署名に載せるのは、署名鍵が全媒体で共通だからです。載せないと、TikTok の同意で得た state を Instagram のコールバックに持ち込むような取り違えを検出できません。

連携の手順は「認可 → 疎通確認 → 名前を目で見る」

利用者に渡す手順は 3 手で固定します。①対象がプロアカウント（ビジネス／クリエイター）になっていることを確かめる。Instagram の個人アカウントは、連携自体は通っても数字が読めません。②連携ボタンを押し、別タブで開く媒体の画面で、その案件のアカウントでログインした状態で許可する。③戻ってきたら接続確認（実際に API を 1 回叩く操作）を押し、表示されたアカウント名と種別を目で見る。

「連携済み」が示すのは鍵の有無までで、読めるかどうかは含みません。読めるかどうかを示すのは接続確認の結果です。画面に出す接続状態は、この実測から作ります（原則 B）。認可したときの記録（アカウント名・スコープ）は鍵が消えても残るので、それを根拠にすると「接続状況は未設定なのに、許可した範囲は連携済み」という読めない画面になる。これは著者の環境で実際に起きました。別タブで終わる操作は、終わったことを元の画面へ知らせます。放っておくと元の画面は「未設定」のまま何も起きず、接続確認を押す必要があると知っている人にしか完了できません。

トークンの寿命は媒体ごとに違う

出典は TikTok のアクセストークン管理と、上の Business Login のページです。TikTok の行を守らないと、次の更新で失敗して「しばらく動いていたのに突然 401」になる。Instagram の長期トークンには refresh_token にあたるものが無く、期限が来る前に同じトークンを延長し続ける方式です。使う直前に残り日数を見て延長し、保存し直します。

期限切れのトークンは、そもそも展開しません。「鍵はあるのに 401」を作らないためです。ただし期限切れでも選択肢からは消さず、「要再連携」と印を付けて出す。使う直前に更新されることがあるので、消してしまうと直る予定のものまで選べなくなります。

トークンをエージェントに渡さない

投稿できるトークンは、サーバー側に閉じます（原則 I）。エージェントが Bash を持てば、環境変数に載せた鍵はそのまま投稿できる鍵になる。エージェント側の入口は MCP（Model Context Protocol）のツール（第 2 章）だけにし、「予約する」と「いますぐ出す」の 2 つを用意して、実行はサーバーの中で行います。サーバー自身が使う環境変数も、宛先アカウント 1 件ぶんだけを投稿の直前に組み立てる。refresh_token はどの経路にも出しません。アクセストークンの寿命を超えて、何度でも新しいトークンを作れてしまうからです。

アプリ審査が前提になる

SNS の直接連携には、コードが正しくても動かない期間があります。TikTok は Login Kit と Content Posting API の審査を通すまで、開発者ポータルに登録したアカウントしか連携できず、投稿は公開範囲に何を指定しても非公開に固定される。それまでは「下書きとして送り、本人がアプリで公開する」運用にします。Instagram はアプリレビューに加えて、他社のアカウントを扱う事業者としての認証が要り、それまではアプリに役割を付けたアカウントしか連携できません。

厄介なのは、この状態が鍵の設定ミスと見分けがつかないことです。リダイレクト URI もアプリ ID も正しく、同意画面まで進んだうえで弾かれる。ダッシュボードには「連携できませんでした」としか出ず、押した人は自分のアカウントの権限を疑い続けます。対策は、審査の状態を「誰でも連携できる」「運営が登録したアカウントだけ」「準備中」の 3 つに分け、押す前に画面へ出すこと（原則 W）。審査の却下は通知されないことがあるので、状態はメールではなく開発者ポータルで確かめます。著者も、通知を待っていて却下に気づくのが遅れたことがあります。

7.6 素材の受け渡しは宛先ごとに違う

第 4 章で作った画像・動画を媒体へ渡すとき、渡せる形は宛先ごとに違います。無理に揃えようとしないでください。

投稿の口にも素材の条件を置きます。TikTok は動画が必須、Instagram は画像か動画が必須で、どちらも本文だけの投稿はできない。素材は生成したものと持ち込んだものを同じ一覧から選ばせ、由来（生成／アップロード）を各行に出します。アップロードの上限は、実行基盤のリクエスト上限より下に置く。超えるとこちらのコードに届く前に切られ、画面には原因の分からないネットワークエラーだけが残ります。

Instagram の公開リンクは、素材をログイン無しで取れる状態にするということです。だから守ることが 5 つあります。発行するのは投稿の直前だけ（予約した時点で発行すると、数週間先の予約でもその間ずっと素材が公開状態になる。実際に外から見えるのは投稿直前の数時間だけにする）。1 トークン = 1 素材（素材 ID を署名に載せ、パスを差し替えて別の素材を引けないようにする）。短い期限を署名の中に持つ（外から延ばせない）。用途も署名に載せる（鍵が OAuth の state と共通なら、載せないと state をこの口へ持ち込める）。そして読み取り専用（この経路に書き込みも一覧も生やさない。1 本渡した相手が案件の素材を全部辿れるようになる）。

生成した素材は「何をどのモデルに投げたか」と一緒に保存し（原則 P）、アップロードされた写真とは由来を分けて持ちます。アップロードされた写真は実在の店舗・スタッフ・料理で、生成画像はそうではない。取り違えると、実在しない料理を実店舗の投稿として出すことになります。

7.7 インサイト（計測）：確認した名前だけ使い、足せないものは足さない

廃止された名前を 1 つ混ぜると、インサイトが丸ごと消える

Instagram のインサイト API は、複数の指標をカンマ区切りで 1 回に要求します。ここに存在しない名前が 1 つでも混ざると、そのリクエスト全体が落ちます。表示回数（impressions）とプロフィール表示回数は執筆時点で廃止済みで、後継は views とプロフィールのリンクのタップ（profile_links_taps）。廃止前のサンプルコードをそのまま使うと、リーチも保存も含めて全部が空になり、画面は「何も取れていない」になります。

だから指標名は、公式リファレンスの表に載っているものだけを書きます（アカウントのインサイト、投稿ごとのインサイト）。「たぶんある」で足さない（原則 G）。同じ「保存」でも投稿側は saved、アカウント側は saves と綴りが違う。取り違えると片方だけ常に空になります。

ユニーク数は期間窓をまたいで足さない

執筆時点で、since と until で指定できる期間は 1 リクエスト 30 日までです。90 日を見るには 3 回に分けて取る。ここで指標が 2 種類に分かれます。

SUM_METRICS    = ("views", "total_interactions", "shares", "saves", "profile_links_taps")  # 延べ数。窓をまたいで足せる
UNIQUE_METRICS = ("reach", "accounts_engaged")   # 人数。窓をまたいで足せない

windows = split_into_30_day_windows(since, until)
totals = {}
for w in windows:
    for name, value in fetch(SUM_METRICS, w, metric_type="total_value"):
        totals[name] = totals.get(name, 0) + value

if len(windows) == 1:          # 1 窓に収まるときだけ、期間のユニーク数を出す
    for name, value in fetch(UNIQUE_METRICS, windows[0], metric_type="total_value"):
        totals[name] = value
else:                          # 足せない期間は、期間合計を出さず日次の平均に切り替える
    daily = fetch("reach", windows, metric_type="time_series")   # 各値の日付は end_time の前日
    totals["reach_avg_per_day"] = mean(daily)                   # 名前で「平均」と言う

リーチ（reach）と反応したアカウント数（accounts_engaged）はユニークな人数です。30 日の窓を 3 つ足すと、両方の窓に現れた人を二重に数える。リーチの水増しです。足せない期間では期間合計を出さず、日次の平均に切り替えて、指標の名前でそう言います（原則 E）。何も書かずに消すと「0 件」に見えます。

時系列の日付は 1 日ずれる

時系列で取ると、各点に end_time が付きます。これは集計期間の終わりで、日ごとの値が指すのはその前の 24 時間です。1 日引かずにそのままグラフにすると、Instagram アプリの画面と 1 日ずれた折れ線になり、「アプリの数字と合わない」という問い合わせが来ます。

確定まで 48 時間、保持は 90 日、100 人未満では属性が返らない

インサイトの値は最大 48 時間遅れて確定します。直近 1〜2 日が少なく見えるのは未確定のためで、評価には使いません。急いで取り直す意味も無いので、毎分の再取得には載せず、短時間のキャッシュを通します。キャッシュのキーはアクセストークンの指紋にする。別アカウントで連携し直した瞬間に別のキーになり、前のアカウントの数字が残りません。

保持期間にも上限があります。アカウントのインサイトは直近 90 日ぶんしか保持されず、それより前は空で返る。0 ではありません。フォロワーの属性（国・都市・年齢・性別）は、フォロワー 100 人未満のアカウントでは返りません。これは失敗ではないので、空だと分かる文言で返します。カルーセルの中の各枚にもインサイトはありません。投稿ごとのインサイトは 1 件ずつ独立に叩き、落ちた行は空のまま出す。0 を入れると「見られていない投稿」として表示されます（原則 C）。

後から足したスコープは、既存のトークンに付かない

インサイトには専用の権限が要ります。運用の途中でこの権限を足しても、それより前に連携したアカウントのトークンには付かない。そのアカウントではインサイトだけが 403 になり、いいね・コメント・投稿一覧・フォロワー数は読めています。これをトークンの失効と同じ「連携し直してください」で括らないでください。前者は「インサイトだけ止まっている」、後者は「全部止まっている」。まとめた瞬間に画面の説明が嘘になります。何が止まっていて、何は動いているのかまで書く。直すには、そのアカウントで連携ボタンを押し直すだけでよいことも添えます。

7.8 合算しない

TikTok と Instagram の数字は、数えているものが違う

TikTok の Display API で取れるのは、投稿ごとの再生数・いいね・コメント・シェア（累計）と、フォロワー数・投稿数（現在値）までです（動画一覧、ユーザー情報）。日別の再生数、プロフィール表示、リーチ、視聴者属性は別系統（広告向けの API）の機能で、この経路にはない。取れない指標は 0 で埋めず、表示もしません。

再生数はその動画の累計なので、時系列を作ると「その日に投稿した動画が、今までに何回再生されたか」になります。一方、Instagram のインサイトの表示回数はその期間に発生した実数です。この 2 つを足すと、「露出」の意味が経路によって変わった数字ができあがる。同じ Instagram の中でも、投稿一覧のいいね・コメントは投稿ごとの累計で、インサイトの反応数はその期間に付いた数です。同じ「いいね」を同じ名前で持ってはいけません。

「率」は分母を確かめてから比べます。表示回数は人数ではなく、同じ人に 3 回出れば 3 回と数える。リーチは人数なので、期間をまたいで足せません。同じ「CTR」でも媒体によって分母が違うことがあります（原則 D）。

グラフの基準を、見出しに必ず出す

同じ折れ線に見えて、意味は正反対です。「投稿日ベースの累計」なのか「その日に発生した実数」なのかをデータの側に印として持ち、画面の見出しに必ず出します。基準を書かずに並べると、前日比を読んだ人が必ず誤解する。

同じ媒体の複数アカウントも合算しない

ダッシュボードは「どのアカウントを見るか」を選ばせ、選んだ 1 アカウントぶんを出します。そして、どれを見たかを保存するスナップショットに残す。残さないと、アカウントを切り替えた前後の推移が「急に伸びた」に見えます。

媒体が指標の定義を変えた日をまたいで比べない

同じ名前の指標でも、媒体が数え方を変えることがあります。YouTube は 2025 年 3 月 31 日にショート動画の再生数を「再生が始まった回数」に変え、それまでの数え方は「エンゲージビュー」という別の指標として残しました。さらに 2026 年 8 月 24 日からは、通常の動画とライブ配信を含むすべての形式で、再生が始まった時点で 1 回と数えています。収益化の判定には引き続きエンゲージビューが使われます（YouTube ヘルプ）。

こうした日をまたいで前年同月比を出すと、運用の成果ではなく数え方の変化で数字が伸びて見えます。数字そのものは媒体が返した正しい値なので、誰も誤りに気づきません。対策は、指標の定義の変更を 1 箇所に記録し、レポートがそれを読むことです。比べる 2 つの期間のあいだに変更日があれば、比較を出さずに理由を書くか、定義の変わらない別の指標（この例ならエンゲージビュー）で比べます。

metric_definition_changes:        # レポートを作る前に必ず読む
  - platform: youtube
    metric: 再生数
    scope: ショート動画
    changed_on: 2025-03-31
    change: 再生が始まった時点で数える（従来の数え方はエンゲージビューとして残る）
    compare_with: エンゲージビュー
  - platform: youtube
    metric: 再生数
    scope: すべての形式（通常の動画・ライブを含む）
    changed_on: 2026-08-24
    change: 再生が始まった時点で数える
    compare_with: エンゲージビュー
  - platform: instagram
    metric: 表示回数（impressions）
    scope: アカウントと投稿のインサイト
    changed_on: （公式の告知で確認した日付を記入）
    change: 廃止。後継は views（7.7）
    compare_with: null            # 旧指標と新指標を 1 本の推移として繋がない

compare_with が空の行は、変更日をまたぐ比較そのものを出さないという意味です。前年同月比の欄には「数え方が変わったため比較できません」と書き、変更日を添えます。

7.9 レポート：読み手は数字が読めない人

計測の出口はレポートです。読むのは広告代理店の運用者ではなく、店舗のオーナー・広報担当・経営者（原則 O）。

取得の経路は 3 つ。どれで取ったかを出所として書く

実績の取り方は 3 つあり、どれも正規の選択肢です。①公式 API（インサイト。リーチ・保存・属性など非公開の数字まで取れる）②公開ページを人が見て記録した数字（ログイン無しで見える再生数・いいね・フォロワー数・投稿日だけ。Instagram と TikTok は利用規約で自動収集を禁じているので、エージェントにページを開かせて取らせない）③利用者が管理画面から書き出した CSV やスクリーンショットの持ち込み。連携が生きていれば①、無ければ②か③を利用者に確かめてから選びます。勝手にどちらかへ決め打ちしない。②では非公開の指標が取れないので、リーチや保存は「未取得」と書き、どの経路で取ったかと対象期間をレポートに必ず明記します。動画の取得や文字起こしのように、サーバー側の実行では成立しない工程は、探りに行かず持ち込みに切り替え、埋まらない列は空欄のまま残す（原則 T）。

投稿ごとの実績を、自アカウント平均との相対で診断する

月次レポートの要素は、アカウントの概況（見た人数・表示回数・反応した人数・リンクのタップ）、フォロワーの推移、フォロワーの属性、形式別（リール・ストーリーズ・フィード）の内訳、視聴者の国と地域、そして投稿 1 本 1 枚のカードです。カードにはサムネイル、見た人数、平均視聴秒数、保存、シェア、冒頭のつかみが効いたかの診断を載せる。診断は固定のしきい値ではなく、そのアカウントの平均に対する比率で出します。固定値にすると、8 万リーチのバズ動画が「伸び悩み」と誤判定される。ここは決定的であるべき計算なので、生成 AI にはやらせません（原則 Q）。計算とタグ付けはコードで行い、言葉にするところだけ AI に任せます。

社内で使っている指標名は、そのまま出しません。著者の場合、平均視聴秒数 × 見た人数にシェアと保存の率を掛けた指標を社内では英語の略称で呼んでいますが、画面に出す名前は「フック力」です。横に「冒頭のつかみで、どれだけの人をどれだけ長く引き留めたか」と 1 行添え、算出式は脚注に置く。数字が合っていても、読めなければ届いていません。

翌月の企画へ戻す分析も型にします。投稿別に「再生数 × 冒頭の文字 × 冒頭の描写」を 1 行 1 投稿で並べ、冒頭のパターンと再生数の相関を見る。同じ投稿を TikTok と Instagram の両方に出しているなら、再生数は 2 列に並置して足しません。冒頭の描写は動画のフレームを見る作業で、AI に見せる画像は推論コストが最も嵩む入力です。フレームを見る作業だけを使い捨ての小さなエージェントに閉じ込め、本体は文字になった 2 列だけを受け取って検品する。この分業で費用が桁で変わります。

この小節の診断の進め方を、月次レポートの手順書にしておきます。この手順書は 1 アカウントの実績を読んで書くだけで、投稿もアカウントの設定も触りません。骨子は次のとおりです。

---
name: reels-report
description: >-
  自社アカウントの月次実績を、投稿 1 本ごとの診断つきでレポートにする。
  「今月の数字をまとめて」「インサイトを見て」「どの投稿が伸びた」で使う。
  ※チャネル横断の定例は定例レポートのスキル（第 3 章）。
---
# 月次の実績レポート

## 手順
1. 取得経路を確かめる（公式の連携 / 人が記録した表 / 持ち込みの CSV）。
   利用者に確かめてから選ぶ（勝手に決め打ちしない）
2. アカウントの概況 → フォロワーの推移 → 形式別の内訳 → 投稿 1 本ごとのカード
3. 1 本ごとの診断は**そのアカウントの平均に対する比率**で出す（固定値で判定しない）
4. 計算とタグ付けはコードで行い、言葉にするところだけを AI に任せる

## 守ること
- 社内の指標名をそのまま出さない（言い換えて、1 行説明を添える）
- アカウントをまたいで足さない。媒体もまたいで足さない
- 取れなかった数字は「未取得」と理由を書く

手順の先頭に取得経路の確認を置き、「利用者に確かめてから選ぶ」と書きました。経路によって、取れる数字が違うからです。公開ページから取った回は非公開の指標が取れないので、経路が書かれていなければ、リーチの欄が空いている理由を読む人は判断できません。もう 1 つ、Instagram と TikTok は利用規約で自動収集を禁じています。エージェントに、ページを開かせる経路を自分で選ばせないためでもあります。

診断を「そのアカウントの平均に対する比率」に限ったのは、固定のしきい値だと 8 万リーチのバズ動画が「伸び悩み」と誤判定されるからです。基準は業種と規模で変わります。計算とタグ付けをコードに寄せたのは、診断が決定的であるべき計算だからです（原則 Q）。「社内の指標名をそのまま出さない」を守ることに置いたのは、著者の社内でも指標を英語の略称で呼んでいるためです。読み手の店舗のオーナーや広報担当には、数字が合っていても、読めなければ届きません。

「アカウントをまたいで足さない。媒体もまたいで足さない」の根拠は 7.8 のとおりで、TikTok の再生数は投稿日ベースの累計、Instagram の表示回数はその期間の実数です。足せば露出の意味が経路で変わります。「全体で」と頼まれたエージェントは足し合わせられる形を探すので、依頼文に「合計を作らない」と書き、手順書にも同じ規則を持たせて両方で止めます。「未取得」に理由を添えさせるのは、0 と書けば「見られていない投稿」に見え、一言で済ませれば何を直せばいいのか読む人に分からないからです。対象期間・対象アカウント・読み手は案件ごとに違うので、依頼文に残します。一方、「一言でいうと」から始める構成は手順書に書いていません。書き方の規則は、レポートを作るすべての手順書が読む正本 1 つに置いてあるからです。書き写せば、片方だけが古くなります。

投稿別の棚卸し表を作る

冒頭と再生数の関係を見る前に、投稿を 1 行 1 投稿の表に棚卸しします。同じ動画を TikTok と Instagram の両方に出している運用では、2 つの媒体の同じ投稿を 1 行にまとめる必要があり、ここに規則が要ります。

突き合わせは、投稿日が近いこと（著者は前後 3 日以内）と、表記ゆれを吸収したうえでタイトルが似ていることの両方を満たしたときだけ行います。候補が複数あれば、日付が最も近く、最も似ているものを選ぶ。条件を満たさなければ、片方の媒体だけの行として残します。誤って別の動画と結合すると、ある動画の Instagram の数字が別の動画の実績として記録され、あとから見分けられません。結合せずに 2 行になるほうが安全です。

表の作りも決めておきます。再生数は「12.4K」のような表示用の列と、生の整数の列に分け、分析は必ず整数の列で行う。冒頭の文字と冒頭の描写は、映像から読み取れなかったら空欄のまま残し、推測で埋めない。表計算ソフトで開いても文字化けしないよう、BOM 付きの UTF-8 で書き出します。この表は分析用の手元の集計で、数字の正本は案件の数値の置き場のままです。

冒頭の描写は、書くときの語彙を固定します。カメラの動き（固定・パン・ズーム・手持ち）、アングル（正面・俯瞰・寄り・引き）、文字の位置（上・中央・下）、構成の名前（「結論先出し → 実演 → うながし」など）。月ごとに書き方が変わると、同じ冒頭を別のものとして数えてしまいます。1 本を深く分解するときは、台本の復元 → 構成の区切り → カット割り、の順に進めます。前の段の結果が次の段の入力になるので、順番を飛ばしません。

No.,投稿日,タイトル,冒頭文字,冒頭描写,再生数(TikTok),再生数(TikTok・数値),再生数(IG),再生数(IG・数値),URL(TikTok),URL(IG)
1,2026-10-12,露天風呂の夕方,この時間だけ山の色が変わる,露天風呂(引き・固定)→湯面(寄り)→山(パン)→湯上がり処→客室,12.4K,12418,8.1K,8093,https://…,https://…
2,2026-10-09,朝ごはんの全品,,食堂(俯瞰)→焼き魚(寄り)→ご飯をよそう手元,3021,3021,,,https://…,
3,2026-10-05,客室からの眺め,,,,,4.4K,4410,,https://…

1 行目は両方の媒体で突き合わせられた投稿、2 行目は TikTok にしか無い投稿、3 行目は Instagram にしか無く、冒頭をまだ見ていない投稿です。空欄は「未取得」か「該当なし」で、0 ではありません。分析では、冒頭文字の型（否定・数字・問いかけなど）と 1 カット目に何を見せたかを、それぞれ整数の再生数と並べて見ます。

棚卸し表を作る手順も手順書にしておきます。突き合わせの条件と冒頭の描写の語彙を手順に書いておくと、月ごとに表の作りが変わりません。

---
name: hook-csv
description: >-
  投稿を 1 行 1 本で棚卸しし、「再生数 × 冒頭の文字 × 冒頭の描写」の相関を見る。
  「伸びた動画の冒頭の共通点」「投稿別に一覧化して」で使う。
  ※1 本を深く分解するのは動画分解のスキル（第 4 章）。
---
# 投稿別の棚卸し表

## 手順
1. 実績を 1 行 1 本で並べる。再生数は**表示用と整数の 2 列**に分ける
2. 同じ動画を 2 媒体に出しているなら、1 行にまとめる。
   突き合わせの条件は**投稿日が前後 3 日以内かつタイトルが似ている**こと。
   満たさなければ 2 行のまま残す（誤結合のほうが危険）
3. 冒頭の文字と描写を埋める。**語彙を固定する**
   （カメラの動き・アングル・文字の位置・構成の名前）
4. 分析は必ず整数の列で行う

## 守ること
- 映像から読み取れなかった欄は空欄のまま。推測で埋めない
- 2 媒体の再生数を足さない（並置する）

この手順書が作るのは手元の集計表だけで、数字の正本は案件の数値の置き場から動きません。月次レポートと手順書を分けたのは、冒頭の描写を埋めるのが動画のフレームを見る作業だからです。AI に見せる画像は、推論コストが最も嵩む入力です。フレームを見る作業を小さなエージェントに閉じ込め、本体は文字になった 2 列だけを受け取ります。この分業で費用が桁で変わります。1 本を深く分解する手順書を別にしているのも同じ理由で、台本の復元から始まる分解は 1 本ずつの作業、この表は横並びの作業です。

突き合わせの条件を「前後 3 日以内かつタイトルが似ている」に固定し、満たさなければ 2 行のまま残す。こう書いたのは、誤って別の動画と結合すると、ある動画の Instagram の数字が別の動画の実績として記録され、あとから見分けられないからです。結合しなかった 2 行は見れば分かります。誤結合のほうは、表の上で正しく見えてしまいます。3 日は著者の目安ですが、手順書に置いておかないと、月ごとに条件が変わって表の作りも変わります。

再生数を表示用と整数の 2 列に分けさせるのは、「12.4K」のような表示用の値では並べ替えも相関も取れないからです。冒頭の描写の語彙を固定させるのは、月ごとに書き方が変わると、同じ冒頭を別のものとして数えてしまうため。「空欄のまま。推測で埋めない」は、空欄の意味が「未取得」か「該当なし」であって 0 ではないことから来ています。埋めれば、相関に嘘の点が混ざります。「2 媒体の再生数を足さない（並置する）」は 7.8 の規則をこの表に落としたもの。媒体が数えているものが違う以上、足した値は何の回数でもありません。

「一言でいうと」から始める

構成は固定します。①一言でいうと（3 行以内、専門用語ゼロ）②いま何が起きているか（事実と良し悪しの判定）③なぜそうなったか（仮説と明記）④次にやること（3 つまで、担当と期限つき）⑤詳しく見たい人へ（指標の明細・取得方法・データの限界）。専門用語と計算式は⑤に集める。見出しで結論を言い、「分析結果」「まとめ」のような中身の無い見出しは使いません。

数字には必ず意味の文を添えます。「保存 42 件（前月比 +30%）」ではなく、「保存が 42 件。先月は 32 件だったので、あとで見返したい投稿が増えている」。率は人数に言い換える。「反応率 2.1%」は「見た 100 人のうち 2 人が反応した」です。比べる相手（前月・目標・自アカウントの平均）を必ず置き、無いときは「今回を基準にする」と書きます。

取れなかったデータは「未取得」の一言で終わらせません。何が取れていないか、それが分かると何を判断できるか、どうすれば取れるか（画面での操作）を 1 行ずつ書く。推測で埋めず、0 とも書きません。

月次のレポートを頼む依頼文の例です。7.7 と 7.8 で述べた「足さない」規則を、依頼の側にも書いておきます。

依頼の例（月次レポート）

温泉旅館の SNS の月次レポートを作ってください。対象期間は 10 月 1 日〜10 月 31 日です。

対象アカウント:
  - Instagram「本館」
  - Instagram「カフェ」
  - TikTok「本館」
読み手: 旅館の女将と支配人。広告や SNS の用語は知らない前提で書く。

構成: 一言でいうと（3 行以内）→ いま何が起きているか → なぜそうなったか（仮説と明記）
  → 次にやること（3 つまで、担当と期限つき）→ 詳しく見たい人へ

数字の扱い:
  - アカウントごとに章を分ける。3 アカウントを足した「合計」は作らない。
  - Instagram のリーチと反応したアカウント数は、期間を分けて取った値を足さない。
    1 回で取れない長さなら日次の平均として出し、見出しに「1 日平均」と書く。
  - TikTok の再生数は動画ごとの累計なので、「10 月に見られた回数」とは書かない。
  - 投稿ごとの良し悪しは、そのアカウントの直近 3 か月の投稿の平均と比べる。
  - 取れなかった数字は 0 と書かず「未取得」とし、理由と取り方を 1 行で添える。
  - 取得した経路（公式 API か、持ち込みの CSV か）と取得日を最後に書く。

出力: 1 つの文書。表は各アカウント 1 枚まで。

10 月は 31 日あるので、執筆時点の Instagram のインサイトでは 1 回のリクエストに収まりません（7.7）。依頼の側でリーチの扱いを決めておけば、エージェントが 2 つの窓の値を足して出すことはありません。「読み手」を書くのは、構成と言い換えの基準をレポートを読む人に合わせるためです。

足りない例（合計を求める依頼）

今月のインスタと TikTok の数字をまとめて、全体でどれくらい伸びたか教えて。

「全体で」と書くと、エージェントは足し合わせられる形を探します。TikTok の累計再生数と Instagram の期間内の表示回数を足した「総露出」や、本館とカフェのリーチを足した「総リーチ」ができあがります。どちらも計算はできるので、レポートは整って見えます。しかし前者は数えているものが違う数字の和で、後者は同じ人を二重に数えた人数です（7.8）。依頼には「合計を作らない」と書き、手順書にも同じ規則を持たせ、両方で止めます。

この書き方の規則は、レポートを作るすべてのスキルが読む正本を 1 つにします。スキルごとに書き写すと片方だけ古くなり、同じ依頼でもどのスキルが立ったかで読みやすさが変わってしまう。

定例の数字を Slack に流す、Slack や Chatwork から投稿案の下書きを頼む、といった外部チャットからの指示の経路は、第 11 章「全体最適を考える」で扱います。外部チャットから起動した作業には確認画面に答える人がいないので、予約と投稿のツールは断られます（7.3）。

7.10 訪日客向けに中国のプラットフォームを回す

訪日客を呼び込む案件では、中国のプラットフォームのアカウントを運用することがあります。来日前の中国の旅行者が見ているのは、国際版の TikTok ではなく中国本土の抖音（Douyin）と、小紅書（RED。中国語表記は小红书）です。第 8 章では外から見る側の要点だけに触れます。ここでは、自分のアカウントとして回すときの設計を扱います。

国際版とは別のアプリ・別のアカウント

抖音は TikTok と同じ会社が運営していますが、アプリもアカウントも別です。企業として運用するには中国側の企業認証が要り、現地の電話番号や法人の有無で開設の方法が変わります。小紅書も同じで、海外の企業は越境向けの企業アカウントか、代理店を通した開設になることが多い。要件は変わるので、運用を引き受ける前に公式の窓口か代理店で確認します。

投稿や実績を API で扱えるかも、国内の媒体と同じ前提では考えられません。海外の事業者が申請して使える範囲は限られるので、先に確かめます。使えない前提で運用を組んでおけば、あとから API が使えるようになったときに置き換えるだけで済みます。実績は管理画面からの書き出しか公開範囲の確認で取り、取れない指標は「未取得」とします（7.9 の取得経路の規則と同じです）。API を通さずに人が投稿するので確認画面は出ませんが、承認は手順で残します。投稿前の文面と素材を承認者が読み、承認の記録を残してから人が投稿する。

抖音：位置情報と保存で来店につなげる

抖音は、フォロワー数より 1 本ごとの見られ方で配信の広がりが決まる、という見方が業界では一般的です。最後まで見られたか（完播率）が重視されるとも言われます。公式の説明ではないので、数字の基準は置かず、冒頭で結論や驚きを出し、スポット紹介を短く保つ、という作り方にだけ反映します。

店舗型ビジネスにとって大事なのは、位置情報（POI。店舗や施設の所在地のページ）です。動画に位置情報を付けると、見た人は所在地・営業情報・同じ場所の他の動画へ移れます。位置情報のページには前売り券やクーポン（团购）を載せられ、見る・保存する・来店して使う、までがアプリの中で完結します。来日前の旅行者は行きたい場所を保存しておき、現地で開きます。

外部のサイトへ誘導する文言（「リンクは概要欄」「別のアプリで」）は、配信が絞られる原因になると言われるので使いません。予約や購入はアプリ内の仕組みで完結させます。効果は再生数ではなく、位置情報のクリック → 保存 → クーポンの利用（来店の証明）の順に見ます。

抖音での運用の設計を手順書にすると、次のようになります。description では、写真と文章が主体の小紅書の依頼を別の手順書へ回しています。

---
name: douyin-playbook
description: >-
  訪日客向けに、中国本土のショート動画アプリでの発信を設計する。
  「訪日中国人にリーチしたい」「位置情報から送客したい」で使う。
  ※写真と文章が主体の媒体はそちらのスキル。
---
# 中国のショート動画アプリ

## 先に確かめる
- 企業認証の要件（現地の番号・法人の有無）。公式の窓口か代理店に確認する
- API で取れる範囲（取れない前提で運用を組む）

## 設計
1. 冒頭で結論か驚きを出し、スポット紹介を短く保つ
2. **位置情報を必ず付ける**（見る → 保存 → 来店の線をアプリ内で完結させる）
3. 外部サイトへの誘導文言を使わない
4. 効果は再生数ではなく、位置情報のクリック → 保存 → クーポンの利用の順で見る

## 守ること
- 最上級の表現を使わない（現地の広告法）。謝礼を払った投稿には広告の表示を付ける
- 国内の数字と足さない

この手順書が出すのは発信の設計だけです。投稿は人がアプリから行い、承認も人の手順で残すので、外へ出す操作は持ちません。「先に確かめる」を設計より前に置いたのは、企業認証の要件が現地の番号や法人の有無で変わるうえ、要件そのものも変わっていくからです。手順書に要件を書けば古くなるので、書いたのは確かめる先だけ。API を「取れない前提で運用を組む」としたのは、海外の事業者が使える範囲が限られるためです。使えない前提で組んでおけば、使えるようになった日に置き換えるだけで済みます。

設計の 1 に数字の基準が無いのは、完播率が重視されるという話が公式の説明ではないためです。出典の無い数字は使わず（7.2）、冒頭で結論か驚きを出して短く保つ、という作り方にだけ反映しました。位置情報を「必ず」としたのは、店舗型ビジネスの成果が位置情報のページで完結するからです。来日前の旅行者は行きたい場所を保存して現地で開き、クーポンの利用までがアプリの中で起きます。効果を再生数ではなく位置情報のクリック → 保存 → クーポンの利用の順で見させるのも、来店の証明がクーポンの利用として残るからです。

最上級の表現と広告の表示を「守ること」に入れたのは、日本語の「No.1」「絶対」「最高」をそのまま訳すと中国の広告法に触れるからです。しかも、それを持ち込むのは翻訳の時点のエージェントです（後の小節「表現の規制は 2 か国ぶんかかる」）。「国内の数字と足さない」は、7.8 の規則がそのまま当たるため。抖音は TikTok と同じ会社の運営でも、アプリもアカウントも別です。description の末尾では、写真と文章が主体の媒体を別の手順書へ送りました。同じ訪日客向けでも、こちらは動画の冒頭と位置情報、あちらは検索語と表紙と保存と、設計の軸が違うからです。

小紅書：検索される言葉で作り、保存を狙う

小紅書は、流れてくる投稿を眺めるより、検索して使われることが多いメディアです。旅行の下調べでは「東京 3 日間 行程」のような語で探されます。だから投稿（笔记。表紙画像・タイトル・本文・タグでできたノート）は、実際に検索される語への答えとして作ります。タイトルと本文の冒頭に検索語を入れ、位置情報を付けます。評価の中心は保存（收藏）で、攻略・リスト・行き方のような、あとで見返す実用情報が向いています。

開かれるかどうかは表紙の 1 枚でほぼ決まります。表紙の文字には、地名か数字、得られること、自分で試したことを示す言葉、の 3 つを入れます。企業アカウントの作り込んだ投稿より、実際に行った人の体験談が信頼されやすいため、フォロワーの少ない一般に近い投稿者（KOC）に同じテーマで複数書いてもらう方法がよく使われます。依頼では型・入れてほしい検索語・位置情報・禁止表現を渡し、文面は本人の言葉に任せます。

小紅書の投稿の設計も手順書にしておきます。表現の規制は次の小節で扱いますが、手順書の「守ること」にも入れておきます。

---
name: xiaohongshu-playbook
description: >-
  訪日客向けに、中国の写真・文章型の SNS での発信を設計する。
  「中国の口コミで拡散させたい」「保存される投稿を作りたい」で使う。
  ※ショート動画主体の媒体はそちらのスキル。
---
# 中国の写真・文章型 SNS

## 設計
1. **検索される言葉への答え**として作る（旅行の下調べで使われる）
2. タイトルと本文の冒頭に検索語を入れ、位置情報を付ける
3. 表紙の 1 枚に 3 つ入れる：地名か数字 / 得られること / 自分で試したこと
4. 評価の中心は保存。攻略・リスト・行き方の実用情報が向く
5. 一般の投稿者に同じテーマで複数書いてもらう場合は、
   型・検索語・位置情報・禁止表現だけを渡し、文面は本人に任せる

## 守ること
- 数字の仕様（文字数・タグ数の上限）は設計書に書かず、投稿する人が画面で確かめる
- 最上級の表現を使わない。謝礼を払った投稿には広告の表示を付ける

この手順書も出すのは設計だけで、投稿はしません。設計を「検索される言葉への答え」から始めたのは、小紅書が流れてくる投稿を眺めるより検索して使われる媒体だからです。旅行の下調べは「東京 3 日間 行程」のような語で行われます。国内の SNS と同じ発想で設計すると、その検索に現れない投稿になります。表紙に入れる 3 つを列挙したのは、開かれるかどうかが表紙の 1 枚でほぼ決まるためです。

一般の投稿者に書いてもらう場合は、「型・検索語・位置情報・禁止表現だけを渡し、文面は本人に任せる」と限定しました。信頼されるのは企業アカウントの作り込んだ投稿より、実際に行った人の体験談だからです。文面まで渡せば、作り込んだ投稿に逆戻りします。「数字の仕様は設計書に書かず、投稿する人が画面で確かめる」は、文字数やタグ数の上限が変わるためで、X の手順書が文字数の上限を固定しないのと同じ判断です。最上級の表現と広告の表示を「守ること」に入れたのは、次の小節の規制が 2 か国ぶんかかるからです。日本語の最上級は、そのまま訳した瞬間に違反になります。謝礼を払った投稿は、中国のプラットフォームであっても日本の景品表示法の対象です。

description の「保存される投稿を作りたい」は、この媒体の評価の中心が保存だからですが、同じ言い方はカルーセルの手順書にもあります。取り違えないように、description の先頭で「訪日客向けに、中国の写真・文章型の SNS」と媒体を先に置いています。末尾でショート動画主体の媒体を別の手順書へ送っているのは、設計の軸が検索語と表紙と保存であって、動画の冒頭と位置情報ではないからです。

表現の規制は 2 か国ぶんかかる

中国の広告法は「国家级」「最高级」「最佳」のような最上級の表現を禁じています（第 9 条）。日本語の「No.1」「絶対」「最高」をそのまま訳すと違反になります。一方で、日本の景品表示法では 2023 年 10 月から、広告であることを隠した表示（ステルスマーケティング）が規制の対象です。対価を払って書いてもらう投稿は、中国のプラットフォームであっても広告と分かる表示を付けます。国境や領土の表記、政治的な話題にも注意が要り、アカウントが停止されるリスクも見込んでおきます。

投稿 1 本ぶんの構成を、エージェントに次の形で出させます。数字の仕様（文字数やタグ数の上限）は変わるので、シートには書かず、投稿する人がアプリの画面で確かめます。

# 小紅書の投稿構成: 温泉旅館（来日前の個人旅行者向け）
- 型: 行き方と過ごし方の攻略（あとで見返す実用情報）
- 狙う検索語: 「〇〇温泉 攻略」「〇〇温泉 行き方」「東京から 温泉 1 泊」（中国語に訳して使う）
- 位置情報: 旅館の施設ページを付ける
- 投稿者: 企業アカウント 1 本 + 実際に泊まった投稿者 3 名（謝礼あり → 広告の表示を付ける）

## 表紙（縦長）
- 文字: 地名 / 得られること（例: 乗り換え 1 回で行ける）/ 自分で試したことを示す言葉
## 本文
- 冒頭に検索語を入れて結論から / 行き方・所要時間・予算を具体的に / うながしは保存の 1 つだけ
## 出す前の確認
- 最上級の表現（最・第一・絶対）が無いか / 料金と条件は旅館が確認したものか
- 謝礼を払った投稿に広告の表示があるか / 数字や体験を作っていないか
## 計測（取れない指標は未取得と書く）
- 閲覧 / 保存 / コメント / 位置情報からの問い合わせ（旅館側の予約の記録と突き合わせる）

種類も媒体も違いますが、設計の規則はこの章と同じです。宛先のアカウントは名前で確かめる。外に出す前に人が承認する。取れない数字は 0 で埋めない。国内の媒体の数字とは足さない。

章のまとめ

• 運用ループのうち人が持つのは「何を選ぶか」と「外に出してよいか」の 2 箇所。残りは連携と自動化にする。
• 公式の投稿 API に予約は無い（YouTube を除く）。予約は自前のテーブルと毎時の巡回で持ち、正時だけ受け付ける。判定は予約した人の地域時刻で行う。
• 予約・予約の変更・即時投稿のツールはパーミッションで確認の対象にし、人が確認画面で宛先のアカウント名・時刻・本文・素材を読んで許可する。確認は予約のツールを呼んだ時点の 1 回だけなので、予約の内容を変えられる経路を確認が必要なツールだけにする。人がいない実行では、これらのツールは断られる。
• 投稿の実装は 1 本。失敗しても自動で再投稿しない。同時起動は claim で 1 つに絞る。
• アカウントは案件に属し、配列で持つ。宛先は予約のときに確定し、指定が無ければ弾き、繋がっていなければ別のアカウントへ落とさない。連携後は名前を画面に出す。
• コールバックは固定 1 本、保存先は署名済み state から。トークンの寿命は媒体ごとに違い、期限切れは展開しない。投稿できる鍵はエージェントに渡さない。
• インサイトは公式で確認した名前だけを使い、ユニーク数を期間窓をまたいで足さず、媒体もアカウントも合算しない。グラフの基準は見出しに出す。
• レポートは「一言でいうと」から始め、社内指標名を言い換え、診断は自アカウント平均との相対で出す。
• 形式ごとに書き方の型を持つ。Instagram は運用方針を 1 枚にし、カルーセルは本編を先に書いて表紙を最後に書く。X は日本語 140 字の数え方を前提に会話へ加わり、長文は実数だけで書いて AI の文章の癖を出す前に拾う。
• 企画には実在の参考投稿の URL・数字・取得日を付け、出典の無い基準値を使わない。媒体が指標の定義を変えた日は 1 箇所に記録し、その日をまたいで比べない。
• 同じ投稿を媒体をまたいで突き合わせるときは、条件を満たさなければ結合しない。訪日客向けの中国のプラットフォームは、取得と承認を手順で持ち、表現の規制を 2 か国ぶん確かめる。

演習

1. 自分が運用している（または担当する）SNS アカウントについて、7.1 の表を埋めてください。運用アカウント・予約・投稿の結果・実績のそれぞれに、一意キーと「どのシステムが正本か」を書き添えます。予約の行を作ったり変えたりできる経路が、確認が必要なツールだけになっているかを確かめてください。
2. 使っている媒体の公式ドキュメントを開き、7.3 の表の自分の行を作ってください。投稿 API の手順、予約の有無、素材の渡し方、審査の要否、トークンの寿命の 5 項目です。「執筆時点」の日付を添えます。
3. いま出しているダッシュボードやレポートの中で、足してはいけない数字を足している箇所を 1 つ探してください。媒体間、アカウント間、期間窓をまたいだユニーク数のどれかです。見つけたら、並べて出す形に直し、グラフの見出しに基準を書き足してください。
4. 自分が見ている指標のうち、媒体が定義を変えたものを 1 つ調べ、7.8 の変更記録の形で書いてください。直近 1 年のレポートに、その変更日をまたいだ比較が無いかも確かめます。

次の章へ

自分のアカウントを回す話はここまでです。次の第 8 章「アカウント運用を自動化する（後編：外から見る・広げる）」では、アカウントの監査と採点、競合アカウントの実査、インフルエンサーの発掘、ブランドリスニング、そして店舗のアカウントとしての Google ビジネスプロフィールを扱います。