第8章 アカウント運用を自動化する（後編：外から見る・広げる）

「外から見る」ことが要る理由

第 7 章で扱ったのは、自分のアカウントに投稿し、インサイト（公式 API から取れる非公開の実績）を読む側でした。ところが自分の数字をいくら眺めても、「良いのか悪いのか」は決まりません。再生数 3,000 は、フォロワー 500 人の店なら当たりですし、5 万人の店なら不調です。判断には比べる相手が要ります。比べる軸は 3 つ。

• 自分の過去平均。 直近 12〜20 投稿の中央値と比べます。「エンゲージメント率 3% 以上なら合格」といった固定のしきい値だけでは判断できません。業種と規模で基準が変わるからです。
• 競合。 同業・同エリアの 3 アカウントと、投稿頻度・形式の比率・再生数の中央値で比べます。
• 業界の当たり。 その業種でいま実際に効いている広告や投稿の型です。自分も競合も、揃って外していることがあります。

1 つ目は第 7 章の範囲で済みます。残りの 2 つは他人のアカウントを外から読む作業で、公式 API のインサイトは付いてきません。外から読めるのは、公開されている範囲だけ。この章はそこが出発点になります。

もう 1 つ、先に決めておくことがあります。Meta（Facebook・Instagram）と TikTok の画面は、エージェントに自動で読ませません。 両社とも利用規約で、自動化した手段で情報を取得することを禁じています。Instagram はログインしているかどうかも問いません。誰でも見られる広告ライブラリも例外ではありません（条文は第 3 章）。この章で「公開データ」「実査」と書くとき、Instagram と TikTok の分は、人がブラウザやアプリで検索して記録した数字か、利用者から受け取った画面写しを指します。エージェントの仕事は、その記録を読んで採点・判定・下書きを作るところからです。競合の広告は、広告データを MCP で提供している商用サービスから取る方法もあります（後の「競合アカウントの実査と『当たり』の判定」）。

全体像: 6 つの入口と委譲先

入口は 6 つありますが、中身はどれも「集める → 判定する → 下書きを作る → 人が決める」の同じ型です。外部に何かを出す工程（投稿・返信・打診の送信）だけは、必ず人の承認を通します。

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

図の元になった mermaid を見る

mermaid

flowchart TD
    Q(["依頼: 外から見る・広げる"]) --> A{"何を知りたいか"}
    A -->|"自分や候補のアカウントの出来"| AUD["アカウント監査・採点<br>公開データの記録 → 4 軸で採点"]
    A -->|"競合が何を出しているか"| CMP["競合の調査と当たり判定<br>人の検索・広告データの MCP → 継続配信で判定"]
    A -->|"誰に頼めば来店につながるか"| INF["インフルエンサー発掘<br>人が発掘・記録 → 検証 → 打診文面"]
    A -->|"いま何が話題か"| TRD["トレンド便乗<br>検知 → リスク判定 → 投稿案"]
    A -->|"外で何を言われているか"| LIS["ブランドリスニング<br>横断収集 → 差分 → 返信下書き"]
    A -->|"地図で見つかるか"| MEO["Google ビジネスプロフィール<br>診断 → 順位計測 → 月次運用"]
    INF -->|"候補の本格診断"| AUD
    LIS -->|"口コミ返信の実施"| MEO
    TRD -->|"投稿の実行"| PUB["第 7 章の投稿の口<br>（承認つき・予約は正時のみ）"]
    CMP -->|"動画の分解・台本化"| CH4["第 4 章"]
    AUD --> OUT(["レポート。取得経路と時点を明記"])
    CMP --> OUT
    INF --> OUT
    LIS --> OUT
    MEO --> OUT

これはエージェントに渡す用途分岐グラフ（第 2 章）そのものです。箱が行為なのは、描いているのがモノの図（オントロジー）ではなく手順の図だからです。「診断して」と「探して」、「口コミを見て」と「口コミに返して」は取り違えやすい。入口を先に固定しておけば、同じ依頼で毎回違う手順が立つことは無くなります。

「読むだけ」と「操作できる」を道具で分ける

外部のサイトを見に行く運用では、道具を 2 種類に分けます。読むだけ（取得・レンダリング・スクリーンショット）の道具は、宛先を絞りません。競合もクライアントのサイトも案件ごとに変わるので、ネットワーク層の許可リストは維持できないからです。維持できない許可リストは、いずれ「全部許可」の 1 行になって残ります。絞るのは操作できる（クリック・入力・ログイン・送信）道具だけです。例外は、利用規約が自動化した手段での取得そのものを禁じているサービスで、Meta（Facebook・Instagram）と TikTok がこれにあたります。ここは読むだけの道具でも宛先にせず、人が見て記録します。検索のような公開プラットフォームは全案件共通の固定の表で持ち、案件と競合のサイトは案件ごとの設定から足します。固定の表にクライアントのサイトを書き始めると、案件が増えるたびに運用で表を書き換えて回ることになります。

守りは 3 層に分けます。どれか 1 つで済ませようとすると、それぞれ別の抜けが残るからです。1 層目はブラウザ自体のリクエスト遮断で、リンクを踏んだ移動やページ内の通信まで止められる唯一の層です。ただし道具側が「リダイレクトには効かない」と明言しているので、ここ 1 枚には寄せません。2 層目はツール呼び出しの手前のフックで、理由を書いて断ります。遮断だけだとエージェントには「ネットワークエラー」しか届かず、環境が壊れたと読んで延々と試し直します。3 層目は、任意のコードをブラウザで走らせるツールを配らないこと。残しておくと、1 層目も 2 層目もまとめて迂回できてしまいます。そして拒否には必ず代替（読むだけの道具で取れる）を書きます。書かないと、エージェントは回り込む経路を探し始めます。

もう 1 つの軸が実行環境です。手元の PC ではブラウザにログインできますが、サーバー上の実行（run）は実査用の認証情報を持たず、データセンターの IP はほぼ確実にログインや CAPTCHA のチャレンジを受けます。だから「ログインが要る収集はサーバーでは通らない」と最初から決めておく。環境の判定は「コマンドを実行できるか」の 1 軸だけで行い、無いと決まっているものを探しに行かせません。この章の実装でいちばん効くのは、正直に言えばこの 1 行です。

アカウントを監査して採点する

印象ではなく採点表で

診断を印象で語ると、読む人ごとに結論が変わります。100 点を 4 軸に分け、各項目の満点の条件を実数で書いた採点表にします。著者が運用している配点は次のとおりです。

• プロフィールと導線（24 点） … 「何者か」「誰に何を提供するか」「予約・購入・応募への案内」が揃い、リンクが機能し、ハイライトが整理されている。
• 投稿の運用（24 点） … 週 2 本以上。たて型動画が投稿の半分以上。直近 90 日に 3 週間以上の空白が無い。
• 中身の質（28 点） … 冒頭 3 秒のつかみが過半の動画で明確。音なしでも伝わる字幕。尺が冗長でない。行動のうながしがある。
• 成果（24 点） … 反応率（平均いいね ÷ フォロワー数）。再生数の中央値がフォロワー数の 3 割以上。中央値の 3 倍以上に伸びた投稿がある。

配点は業種で変えて構いません。譲れないのは 2 つだけです。採点根拠が収集データの実数に紐づいていること（「頻度が低い」ではなく「直近 90 日で週 0.8 本」）。そして競合比較を配点に混ぜないこと。混ぜると、競合を集めない簡易版と集める本格版で満点が変わり、点数の連続性が失われます。競合は各軸の微調整（±3 点まで）の根拠と、定性の比較表に回します。

診断の前には受付基準を通します。公開アカウントであること、投稿が 10 本以上あること、直近 90 日以内に投稿があること。満たさなければ診断ではなく「立ち上げ（設計）の提案」に切り替えます。基準未達を低い点数として返しても、誰も得をしません。

依頼の例: アカウント監査

監査を頼むときは、対象・目的・比べる相手・取得の制約・出力の形を 1 回の依頼に入れます。次の 2 つを比べてください。

（足りない例）
@example_salon のインスタを診断して、点数をつけてください。

この依頼では、何のための診断か（集客か採用か）、競合と比べるか、取れない数字をどう扱うかが決まっていません。エージェントは配点をその場で決め、保存数のような公開されていない指標を推定で埋めることがあります。翌月に同じアカウントを診断しても、点数を比べられません。

（良い例）
駅前の美容室（Instagram @example_salon）のアカウント診断をお願いします。

目的: 新規の予約を増やすこと（店舗集客型として採点してください）
採点: 共有している採点表（4 軸・100 点満点）に従う。配点は変えない
比較: 同じ駅の半径 1km にある美容室 3 アカウント。候補と選定理由を先に出してください。
      私が確認してから、3 アカウントの数字を記録して渡します
数字: 私が Instagram の画面で確認した記録表を使う（添付。対象と競合の直近 20 投稿の
      再生数・いいね・投稿日・尺）。表に無い値は「未取得」と書き、0 や推定で埋めない
禁止: Instagram の画面を自動で開いて数字を取りに行かない（利用規約で禁止されている）。
      フォロー・いいね・コメント・DM などの操作もしない
出力: ①収集データ（JSON。取得日と取得経路つき）
      ②レポート（一言でいうと → 軸ごとの点と根拠の実数 → 改善 3 つ）
      改善は「7 日以内にできること / 1〜2 か月 / 運用体制」に 1 つずつ
表現: 「必ず伸びる」など成果を保証する言い方をしない

「比較」の行で確認を挟んでいるのは、競合の選び方が各軸の調整（±3 点）に直接効くからです。選定をエージェントに任せたままにすると、規模の違うアカウントとの比較で調整が入ることがあります。

依頼のたびに同じ条件を書かずに済むように、本格版の診断を手順書にしておきます。この章の手順書はどれも、数字を人が記録した表か画面写しから読む前提の骨子で、description には依頼の言い方と扱わない依頼の行き先を書いています（第 2 章）。使うときは本文の規則を足してください。

---
name: account-audit
description: >-
  見込み客や自社の SNS アカウントを 100 点満点で採点し、競合 3 アカウントとの比較と
  改善案 3 つを含む診断レポートを作る。
  「アカウント診断」「フル診断」「この会社の SNS を診断して」で使う。
  ※数分で当たりを付けるなら簡易診断のスキル、自社の月次実績は実績レポートのスキル（第 7 章）。
---
# アカウント診断（本格版）

## 入力
- 対象 1 + 競合 3 の記録表（人が画面で確かめて記録したもの。
  フォロワー数・投稿数と、直近 20 投稿の形式・投稿日・再生数・いいね・尺）
- 根拠の画面写し。採点表（別ファイル）

## 手順
1. 受付基準を通す（公開 / 投稿 10 本以上 / 直近 90 日に投稿あり）。
   満たさなければ診断ではなく**立ち上げの提案**に切り替える
2. 4 軸で採点する（プロフィールと導線 / 投稿の運用 / 中身の質 / 成果）。
   配点は採点表に従い、その場で決めない
3. 競合比較は配点に混ぜず、各軸の微調整（±3 点）と定性の表に回す
4. 総合点を 4 つの帯に当て、帯ごとの書き方で結論を書く
5. 改善は「7 日以内 / 1〜2 か月 / 運用体制」に 1 つずつ

## 守ること
- 採点根拠は実数で書く（「頻度が低い」ではなく「直近 90 日で週 0.8 本」）
- 取れなかった項目は 0 点にせず「未評価」と書く
- 非公開の指標（保存数・リーチ）を採点に使わない
- アカウントを操作しない（フォロー・いいね・コメント・DM）
- 成果を保証する言い方をしない

この手順書がやるのは、人が記録した表と画面写しを読んで採点するところまでです。数字を取りに行く工程はありません。著者が fetch で SNS のページを読ませ、「未着手」と誤判定したことがあります。そのとき直したのは道具の選び方ではなく、「取りに行かない」という決めのほうでした。第 7 章の実績レポートを別の手順書へ送ったのは、自社のアカウントには公式 API のインサイトが付き、こちらは公開データだけで採点するからです。

受付基準が先頭にあるのは、基準未達を低い点数にして返しても誰も得をしないからです。続く「配点はその場で決めない」「競合比較は配点に混ぜない」「根拠は実数で書く」の 3 つは、どれも翌月の診断と比べられる点数を守るための規則。配点がその場で決まれば連続性が消えます。競合を混ぜれば、競合を集めない簡易版と満点がずれます。「頻度が低い」とだけ書いてあっても、翌月の変化は比べようがありません。

0 点ではなく「未評価」と書かせるのは、0 点だと「やっていない」と「見られなかった」が見分けられないためです。「操作しない」は規約の話だけではありません。フォロー・いいね・コメント・DM が診断の手順に混ざれば、確認画面を通らない外部反映の経路がそこにできてしまいます。最後の「成果を保証しない」は、診断が営業ツールとして使われることを見越した一行で、点が低いほど言葉選びが要ります。依頼文に残るのは、目的と比べる相手と記録表だけです。

採点表の書き方

採点表は、依頼文とは別のファイルにしてエージェントに渡します。各項目には「満点の条件」を実数で書き、途中の点数の段階も決めておきます。段階が無いと、エージェントは満点か 0 点かの二択で付けるか、中間の点数をその場で作ります。

# 採点表の書き方の例（軸 2: 投稿の運用 24 点のうち 2 項目）
version: 0.2          # 配点を変えたら上げ、レポートに版を書く
axis: 投稿の運用
items:
  - name: 投稿頻度
    points: 10
    measure: 直近 90 日の投稿数 ÷ 13 週
    levels:           # しきい値は実数で書く
      - {if: "週 2 本以上", score: 10}
      - {if: "週 1 本以上", score: 6}
      - {if: "月 2〜3 本", score: 4}
      - {if: "月 1 本以下", score: 2}
  - name: たて型動画の比率
    points: 7
    measure: 直近 20 投稿に占める動画の割合
    levels:
      - {if: "50% 以上", score: 7}
      - {if: "25% 以上 50% 未満", score: 4}
      - {if: "静止画のみ", score: 2}
  # 継続性（7 点）も同じ形で書く
unavailable: 代わりの指標で採点したら「推定」と書く。代わりが無ければ採点外とし、その旨を書く

version を持たせるのは、配点を変えた前後の点数を同じものとして比べないためです。レポートに版が書いてあれば、点数が上がった理由が運用の改善なのか、配点の変更なのかを区別できます。

公開データで取れるもの・取れないもの

外から読めるのは公開範囲だけです。取れる／取れないを先に決めておかないと、取れない指標が「推定」のまま点数に混ざります。

著者が実際に踏んだ失敗を 1 つ書いておきます。ページを取得して HTML を読む道具（fetch）で SNS のページを読ませたところ、bot 対策で中身が返らず、取れなかった値を「未着手」と誤判定しました。ただし、直すべきは道具の選び方ではありません。Instagram と TikTok のページは、fetch でもブラウザの自動操作（Playwright など）でも取りに行かないと決めておきます。両社とも利用規約で自動収集を禁じているからです。SNS の実数は人が画面で確かめて記録し、エージェントはその記録を正として扱います。

人が記録する範囲も先に決めておきます。対象 1 と競合 3 の計 4 アカウント、各アカウントの直近 20 投稿まで。記録するのは、フォロワー数・投稿数と、投稿ごとの形式・投稿日・再生数・いいね数・尺です。記録した表には取得日と記録した人を書き、根拠として画面写しを残します。範囲を決めずに頼むと、記録する人の作業が終わりません。エージェントに渡すのは、この表と画面写しです。画面写しから読み取った値が表と食い違ったら、表を正とせずに食い違いを報告させ、人が画面で確かめ直します。

採点表のスキーマ

収集データと採点は 1 つのファイルに残し、レポートの数字はすべてここから引きます。推定で埋めた値には印を付け、取れなかった項目は省略します。0 を入れてはいけません。

{
  "collected_at": "2026-09-01",
  "method": "manual",
  "target": {
    "platform": "instagram",
    "handle": "example_store",
    "followers": 3450,
    "posts": [
      {"type": "reel", "views": 12400, "likes": 342,
       "posted_at": "2026-08-28", "duration_s": 28, "estimated": false}
    ]
  },
  "competitors": [
    {"handle": "rival_a", "followers": 5100, "reel_ratio": 0.6, "views_median": 8000}
  ],
  "score": {"profile": 18, "cadence": 14, "quality": 20, "performance": 12, "total": 64},
  "collection_notes": "いいね数 3 件は画面写しから手入力。保存数は公開されておらず未取得"
}

最後の collection_notes が監査証跡です。レポートの値とこのファイルを突合できる状態にしておけば、「数字が合っているか」を後から誰でも確かめられます。

点数を結論に変える

点数を出しただけでは、読んだ人は次に何をすればよいか分かりません。総合点を 4 つの帯に分け、帯ごとにレポートの書き方を決めておきます。

帯を先に決めておくのは、書く人によって同じ 55 点が「もう一歩」にも「危険」にもなるのを防ぐためです。

質の評価に使う語彙を固定する

中身の質の軸のうち、冒頭 3 秒のつかみは評価者の感想になりやすい項目です。つかみの型を 7 つの名前で固定し、「どの型が何本中何本で使われているか」で書きます。

• 疑問提起型（「〇〇って知っていますか」）
• 損失回避型（「知らないと損」）
• 見た目の強さで止める型
• 文字で止める型（強いテロップを先に出す）
• 主観視点型（撮影者の目線で見せる）
• 結論先出し型
• 変化型（ビフォーアフター）

「つかみが弱い」ではなく「直近 12 本のうち型が明確なのは 3 本。うち 2 本が結論先出し型」と書けば、改善の提案も型の名前で書けます。

取れなかった項目は減点しない

項目が最後まで取れなかったときは、その項目を 0 点にせず「未評価」と書きます。0 点にすると、「やっていない」と「見られなかった」の区別がつかなくなります。取り直しの順序も決めておきます。

1. 記録した人に、その項目だけ画面を見直してもらう（1 回だけ）
2. 画面写しがあれば、画像から数値を読み取る（取得経路に「画面写し」と記録する）
3. それでも無ければ、依頼主に画面写しを頼む。プロフィール全体・たて型動画の一覧・上位 3 投稿の 3 枚があれば診断は成立する
4. それでも欠けた項目は「未評価」のまま、取れた範囲でレポートを出す

比べる相手の選び方

競合 3 アカウントは次の条件で選びます。

• 依頼主が意識している競合があれば、必ず含める
• 同じ業種で、同じエリア（それが難しければ同じくらいの規模）
• 診断対象と同じ受付基準を満たす（公開・投稿 10 本以上・直近 90 日に投稿あり）
• フォロワー数が対象の 0.5〜10 倍の範囲。全国チェーンの公式アカウントのように規模が大きく違う相手は外す

規模が大きく違う相手と比べると、各軸の調整（±3 点）が規模の差を映しただけの数字になります。

渡す前の確認と、相手に見せる形への作り替え

レポートを送る前に、担当者が次の 4 点を確認します。

• 数値の実在確認: レポートの数値と収集データのファイルを突き合わせる
• 表現の確認: 略称を使っていないか、成果を保証する書き方をしていないか、非公開の指標に「推定」と付いているか、競合を批判していないか
• 競合の選び方: 同業・同エリアになっているか
• 改善の提案が、依頼主の目的（店舗集客・EC での購買・採用）とずれていないか

簡易版の所見は社内の判断材料として書くので、「商談で最初に聞くこと」のような社内向けのメモが入ります。これを依頼主本人に見せるファイルにする場合は書き直します。社内向けのメモと競合の個別アカウント名を消し、宛名と提供元を書きます。「上位 3 課題」は「伸ばせる点」に、「次の一歩」は依頼主が取る行動（まず着手すること・1〜2 か月でやること・仕組みにすること）に書き換え、末尾に免責文を入れます。

出力の型も示します。簡易版の診断をチャットに返すときの形です。

## 簡易診断: 駅前の美容室（@example_salon / Instagram）
**総合: 58 / 100 点（立て直しが要る）** ※競合との比較は本格版で行う

| 軸 | 点 | 根拠（実数） |
|---|---|---|
| プロフィールと導線 | 15/24 | 予約リンクはあるが、ハイライトにメニューが無い |
| 投稿の運用 | 12/24 | 直近 90 日で週 0.8 本。3 週間以上の空白が 2 回 |
| 中身の質 | 17/28 | 直近 12 本のうち、つかみの型が明確なのは 3 本 |
| 成果 | 14/24 | 再生数の中央値はフォロワー数の 22% |

**上位 3 課題**
1. 投稿の間隔が空いている（週 0.8 本）
2. 冒頭で止める工夫がある投稿が 12 本中 3 本
3. メニューと料金がプロフィールから辿れない

※公開データの実査（2026-09-01 時点）による。保存数・リーチなどの非公開指標は含まない。

根拠の列に実数を書かせるのが、この型でいちばん大事な点です。「週 0.8 本」と書いてあれば、翌月の診断で同じ項目がどう変わったかを比べられます。

簡易版も手順書にしておきます。商談前に 10〜20 分で当たりを付けるための手順書で、競合の記録は受け取りません。

手順の 1 番目は「本格版と同じ 4 軸・同じ 100 点満点・同じデータ形式」です。簡易版で起こしたデータを、そのまま本格版に引き継げるようにしてあります。簡易版だけ別の配点にしてしまうと、本格版に進んだ時点で点数が比べられず、記録を捨てて集め直す羽目になります。「競合比較は行わない」を明記させるのは、書いていなければ競合と比べたうえでの点数だと受け取られるからです。description の「ざっくり」「商談前」は、時間と用途を表す語。「診断して」の一言だけでは、本格版と区別がつきません。

---
name: quick-audit
description: >-
  渡された記録と画面写しから、粗い点数・上位 3 課題・次の一歩を 1 枚で返す。
  「ざっくり診断して」「商談前にチェックして」「簡易診断」で使う。
  ※競合比較まで含む本格版はアカウント診断のスキル。
---
# アカウント診断（簡易版）

## 手順
1. 本格版と**同じ 4 軸・同じ 100 点満点・同じデータ形式**で採点する
   （後から本格版にそのまま引き継げるため）
2. 競合比較は行わない。行わないことをレポートに明記する
3. 上位 3 課題と次の一歩だけを返す

## 出力
総合点と帯 → 4 軸の表（点と根拠の実数）→ 上位 3 課題 → 取得日と出所の注記

競合アカウントの実査と「当たり」の判定

出稿額と再生数は無い。長く回っているかで判定する

競合が何を出しているかは、公開されています。Meta（Facebook・Instagram）の広告ライブラリ（ https://www.facebook.com/ads/library/ ）は配信中の広告を誰でも検索できますし、Google には広告主単位で配信中の広告を見られる透明性センター（ https://adstransparency.google.com/ ）、TikTok には上位の広告とトレンドを公開するクリエイティブセンター（ https://ads.tiktok.com/business/creativecenter/ ）があります。

ただし、そこに出稿額と再生数はありません。無い数字を「推定 〇〇万円」と書いた瞬間、資料はもっともらしいだけのものになります。当たりの判定は、そこにある情報だけで行います。

レポートには「継続配信 〇日・同一素材 〇件（取得日つき）」という事実の形で書き、「推定出稿額」には変換しません。再生数が多い＝当たり、でもありません。予算で伸びているだけの場合もあれば、遷移先ページで説得し切っている場合もあります。

Meta の広告ライブラリには公式 API もあります。ただ執筆時点では引ける範囲が政治・社会問題などの一部カテゴリと EU 向けに限られ、日本の一般の商用広告は Web の画面でしか見られません。その画面をスクレイピングすることも、Meta の利用規約が禁じています（第 3 章）。取り方は 2 つです。人が広告ライブラリで検索して記録するか、広告データを集めて MCP で提供している商用サービスを使うかです。後者の例が動画広告分析Pro で、Meta・TikTok を含む 13 媒体の広告をエージェントから検索できます。海外ブランドの広告なら Foreplay、出稿額と表示回数の推定なら Pathmatics も候補です（第 3 章の表）。API の対象範囲は、実装前に 公式ドキュメント で確認してください。

調べ方の設計: メタ情報を広く、本命だけ深く

一覧のカードだけで、広告主・配信開始日・配信面・本文・ボタン文言・遷移先・重複出稿数が揃います。動画を 1 本も再生しなくても、テキストと日付だけで「どれが当たりか」の一覧を作れます。 長寿命の広告の顔ぶれ、勝ち遷移先の分布、コピーの型、出稿の厚みをまとめ、深掘りの候補を 2〜4 本に絞ります。深掘りは本命だけ。動画を人が見て文字起こしを作り（台本を返すサービスならそれを使う）、総文字数を尺で割ってテンポ（文字／秒）を出し、遷移先ページを実際に開いてファーストビューの訴求・フォームの項目数・特典を控えます。台本の分解は第 4 章に渡します。

エージェントに任せる部分で効いてくるのは、コストの設計です。広告データを MCP で引くと、1 回の検索で数百件が返ることがあります。これを長く続く会話に読み込むと、以降の全ターンの推論コストが上がります。検索と一覧の整理は使い捨ての子エージェント（第 2 章のサブエージェント）に任せ、親には項目を揃えた表だけを返させます。検索の回数と取得件数の上限は、始める前に決めます。読み込みすぎても判定の精度は上がりません。人が記録する場合も同じで、1 回に記録する範囲（広告主の数と 1 社あたりの件数）を先に決めておきます。

動画広告分析Pro のように MCP で接続できるサービスは、エージェントのツールとして検索・絞り込み・読み取りを行わせます。サービスの画面をブラウザで自動操作する形にはしません。エージェントから使ってよい範囲は、契約とサービスの利用規約で確かめてから接続します。そうしたサービスの出稿額は推定値なので、「〇〇の推定・取得日」と出典を付けます。

見て終わりにしない: 勝ち型と NG 型のナレッジ

競合分析の最大の無駄は、見た結果が記憶にしか残らないことです。構造化して蓄積し、次の企画の入力にします。 1 件 1 行で広告主・配信開始日・継続日数・重複数・フックの型・遷移先の型・取得日を持ち、当たり順に並べ直せる形にします。画像を載せるなら、ファイルに落としてから貼ります。配信 URL は署名付きで短時間に失効するので、URL をそのまま貼ると翌日には全部消え、「画像が出ない」以外の手掛かりが残りません。

競合を定点で見張る

単発の「調べて」と定点の「見張って」は別の仕事です。定点の価値は差分にあるので、初回はベースラインを作るだけ。差分が出るのは 2 回目からです。見る面は、サイト・料金ページの差分、ニュース・採用、広告の入れ替え、SNS 公開面の投稿頻度と伸びた投稿、口コミの低評価本文。勝ちたい領域に効く面から優先し、やらなかった面は「今回は対象外」と書きます。対象は 3 社まで。増やすほど 1 社あたりの分析が浅くなります。

変化は「期間＋実測値＋変化量」で書きます（「配信中の素材 12 → 19 本、うち動画 5 本が新規」）。低評価の口コミに同じ不満が繰り返されていれば差別化の余地ですが、自社がそこで勝てていない不満は訴求になりません。競合を名指しする比較は、両方の現行の出典が揃った事実に限ります。

依頼の例: 競合の定点観測

定点観測の依頼には、「前回値をどこから読むか」と「見る面・見ない面」を必ず書きます。書かないと、エージェントは毎回を初回として扱い、差分ではなく同じ一覧を毎週作ります。

温泉旅館（自社）の競合 3 館を、毎週月曜の朝に定点観測してください。

対象: 同じ温泉街の A 館・B 館・C 館（公式サイトの URL を添付）
前回値: 先週の定点レポートにある「次回のベースライン」表を読む。
        レポートが無ければ今回をベースラインとし、差分は出さない
見る面: ①公式サイトの宿泊プランと料金のページ ②Meta 広告ライブラリで配信中の広告
        ③Instagram の直近投稿（投稿頻度と伸びた投稿） ④Google マップの星 1〜2 の口コミ本文
        ②と③は私が月曜の朝に画面で確認し、記録シートに追記しておく。
        あなたはシートを読むだけにし、広告ライブラリと Instagram の画面を自動で開かない
        （利用規約で禁止されている）
見ない面: 採用とニュースは今回は対象外（月 1 回の棚卸しで見る）
書き方: 変化は「期間＋前回の値＋今回の値＋変化量」で書く。広告の出稿額は書かない。
        当たりの判定は継続配信日数と同一素材の重複数で行い、代理の指標だと明記する。
        開けなかった面と記録が無い面は「未取得」、見なかった面は「対象外」と分けて書く
出力: 一言でいうと → 差分の表（面・前回・今回・変化・根拠 URL・取得日）
      → 自社が勝てている不満だけを乗り換え訴求の候補にする → 次回のベースライン表

最後の「次回のベースライン表」が、翌週の依頼の入力になります。機械で読み直せる表をレポートの中に残しておけば、実行環境に前回のファイルが無くても差分を出せます。「未取得」と「対象外」を分けるのは、開けなかったのか見なかったのかで、次にやることが違うからです。

毎週の依頼を短くするために、定点観測の進め方を手順書にしておきます。差分を出すところまでを担う手順書で、単発の深掘りも自社側の評判も扱いません。

---
name: competitor-watch
description: >-
  指名した競合を定点で見張り、前回からの差分をレポートにする。
  「競合を監視して」「毎週競合をチェック」「乗り換え訴求を探して」で使う。
  定期実行の中身にもなる。
  ※単発の深掘りは企業調査のスキル（第 10 章）、自社側の評判はリスニングのスキル。
---
# 競合の定点観測

## 手順
1. 前回値を読む。①前回の定点レポートの「次回の基準」表 ②案件の記録シートの順。
   どちらも無ければ「今回が基準。差分は次回から」と先頭に書く
2. 見る面を選ぶ（サイト・料金 / ニュース / 採用 / 広告 / SNS / 口コミ）。
   **見ない面は「対象外」と明記する**
3. SNS と広告の数字は、人が記録したシートから読む
4. 変化は「期間＋前回の値＋今回の値＋変化量」で書く
5. 低評価の不満の塊を探し、**自社が勝てている不満だけ**を訴求候補にする
6. 次回の基準表をレポートの中に残す

## 守ること
- 対象は 3 社まで（増やすほど 1 社あたりが浅くなる）
- 「未取得」と「対象外」を分けて書く
- 競合を名指す比較は、両方の現行の出典が揃った事実に限る

単発の「調べて」と定点の「見張って」は、手順書を分けてあります。定点の価値は差分にあり、初回はベースラインを作って終わります。深掘りの依頼にこの手順書が立つと、「差分は次回から」だけの薄いレポートが返ってきます。自社側の評判をリスニングの手順書へ送るのも、型は同じでも出口が違うからです。

手順の先頭には、前回値の読み先を順番に書き、無いときの宣言まで決めてあります。実行環境は毎回新品で、前回のファイルはどこにもありません。依頼文にこの行が無い週、エージェントは毎回を初回として扱い、同じ一覧を作り直します。最後に次回の基準表をレポートの中へ残させるのも同じ理由からで、この表が翌週の入力になります。「未取得」と「対象外」を分けるのは、開けなかったのか見なかったのかで、次にやることが変わるためです。

「自社が勝てている不満だけ」が太字なのは、低評価の塊が見つかると、勝てていない不満まで訴求候補に載りやすいからです。対象を 3 社までに切ったのは、増やすほど 1 社あたりの分析が浅くなるため。一方、見る面と見ない面、人が記録するシートの中身は案件ごとに変わります。ここは依頼文に残します。

監視する面ごとに読むこと

面ごとに「変化から何を読むか」を決めておくと、差分がただの変更一覧で終わりません。

採用の行のように推測を含む読み方は「可能性がある」と書き、事実（求人の件数と職種）とは分けて残します。

不満から乗り換えの訴求候補を作る

低評価の口コミから訴求を作る手順は 3 段です。

1. 同じ不満が繰り返されている「塊」を探す。1 件の苦情は塊として扱わない。件数と代表的な口コミの URL を添える
2. 塊ごとに、依頼主がこの点で実際に勝てているかを、実績や自社の口コミで確かめる
3. 勝てている不満だけを訴求の候補にする。勝てていない不満は候補から外し、外した理由も書く

出力は次のような形にします。

complaint_clusters:
  - topic: チェックインの待ち時間
    competitor: B 館
    count: 7                # 直近 90 日の星 1〜2 の口コミのうち
    examples:
      - https://…           # 代表的な口コミ（2〜3 件）
    collected_at: 2026-09-01
    our_evidence: 自社の口コミで「チェックインが早い」が直近 90 日に 5 件
    can_win: true
    angle: チェックインの早さ（コピーにする工程へ渡す）
  - topic: 夕食の品数が少ない
    competitor: A 館
    count: 4
    our_evidence: 自社にも同じ指摘が 3 件ある
    can_win: false          # 訴求にしない

can_win: false の行も残しておくのは、同じ不満を翌月にもう一度検討しないためです。広告で比べる表現を使う場合は、両方の現行の料金や仕様の出典が揃っている事実に限ります。

インフルエンサーの発掘とキャスティング

「フォロワーが多い人」を並べるのが仕事ではありません。来店・予約につながる人を、実測の根拠つきで選ぶのが仕事です。要件の確定 → 発掘 → 一次絞り込み → 検証 → 候補リストと打診文面、と進み、送信と交渉は人が行います。最初に固めるのは、目的（送客・認知・素材の獲得・多言語）、地域（商圏。来られない人のフォロワーは数でしかない）、予算帯（無償提供・有償・継続）、NG 条件です。

発掘の第一候補は、店のスポット（位置情報）やメンション、タグ付き投稿の公開面です。実際に来た人は熱量が本物で、打診の返答率も高い。そこから地域とジャンルのハッシュタグ面、同業他店の PR 投稿から起用クリエイターを辿る、有力候補のコラボ相手を辿る、と広げます。

Instagram と TikTok での発掘と数字の確認は、人がアプリやブラウザで行い、候補ごとに記録表へ書き込みます。両社とも利用規約で自動収集を禁じているので、エージェントに検索させたり、プロフィールを開かせたりはしません。エージェントの仕事は、記録表から中央値と比率を計算し、兆候・適合度・打診文の下書きを作ることです。人の記録の代わりに、Instagram の公式の Business Discovery API（他のプロアカウントのフォロワー数や投稿ごとの反応の数を返す）や、クリエイターのデータを API で提供している商用サービス（HypeAuditor、Modash など）を使う方法もあります（第 3 章の表）。

検証はリストに載せる前に必ず行います。フォロワー数は絞り込みにしか使いません。

• エンゲージの実測。 直近 10〜12 投稿のいいね・コメントの中央値（平均は 1 本のバズに引っ張られる）とフォロワー比。取得日を添える。
• フォロワー品質の兆候。 コメントが定型文や絵文字だけの並びか、いいねに対してコメントが極端に少ないか、反応が期間で不連続に跳ねていないか。「買っている」と断定はしません。 確かめる手段が無いので、事実を兆候として書き、判断は発注者に残します。
• PR 投稿と通常投稿の落差。 大きい人は費用対効果が読みにくい。
• 客層の適合。 外から実測できないので、コメント欄の言語や発信テーマから読める範囲で書き、断定しません。

料金は創作しません。公開の料金表やメディアキットがあるときだけ数字を載せ、それ以外は「要打診」。適合度には理由を 1 行付けます。打診文面は下書きまでで、「なぜあなたか」（具体的な投稿への言及）を必ず入れます。テンプレの一斉送信は返答率を下げるだけでなく、クライアントの評判を落とします。

有償タイアップには広告であることの明示（PR 表記）が必須です（景品表示法のステルスマーケティング規制。2023 年 10 月施行。 消費者庁の案内 ）。表記の責任は広告主側にあるので、依頼条件に明記します。無償提供でも、投稿内容を指示すれば対象になりえます。「自由に書いてください」と「この訴求で書いてください」は法的に別物なので、依頼文面にどちらかを明示します。候補の本格診断が要るなら、前節の監査に委譲します。

依頼の例: 発掘から実測検証まで

キャスティングの依頼では、要件（目的・商圏・予算帯・NG 条件）と検証の方法を先に固定します。「インフルエンサーを 10 人探して」だけでは、フォロワー数の多い順の一覧が返ってきます。商圏の外に住む人や、エンゲージを実測していない人が混ざり、打診の前に人が全員を調べ直すことになります。

商店街のカフェの新メニューの告知に向けて、Instagram の発信者の候補を絞り込んでください。

目的: 来店につなげること（認知だけが目的の人は優先度を下げる）
商圏: 店から電車で 30 分以内に住んでいる、または普段この地域を発信している人
予算帯: 無償の招待（飲食の提供のみ）。有償の依頼はしない
NG: 他のカフェと継続的にタイアップしている人、飲酒を中心に発信している人
候補: 私が Instagram で探して記録した表を使う（添付。①店のスポットとメンションの公開投稿
      ②「#地名カフェ」の上位と新着 ③近隣の同業店の PR 投稿、の順に探した。
      候補ごとに直近 12 投稿のいいね・コメント数と記録日を書いてある）
      Instagram をあなたが自動で開いて候補を探し足さない（利用規約で禁止されている）
検証: 記録表から、候補ごとにいいね・コメントの中央値とフォロワー比を計算し、記録日を付ける。
      フォロワーの質は気づいた事実を「兆候」として書き、「買っている」とは断定しない
料金: 公開の料金表がある人だけ数字を書く。それ以外は「要打診」
出力: 候補リスト（ハンドル・フォロワー・エンゲージ中央値・適合度と理由 1 行・根拠 URL・取得日）
      本命 3 人ぶんの打診文の下書き。その人の具体的な投稿に 1 か所触れること
      送信はしない。投稿内容をこちらが指定するのか、自由に書いてもらうのかを文面に明示する

最後の行は法令への対応です。無償の招待でも、投稿内容を指示すればステルスマーケティング規制の対象になりえます。依頼の段階でどちらにするかを決めておかないと、エージェントが訴求を細かく指定した打診文を書くことがあります。

発掘から打診文の下書きまでの進め方を手順書にすると、次のようになります。記録表を読んで検証し、下書きを作るところまでの手順書で、探し足しも送信もしません。

---
name: influencer-casting
description: >-
  来店・予約につながる発信者を、実測の根拠つきで選び、打診文の下書きまで作る。
  「インフルエンサーを探して」「キャスティング候補」「PR してくれる人を見つけて」で使う。
  ※候補の本格診断はアカウント診断のスキル。送信と交渉は人が行う。
---
# キャスティング

## 先に固める
目的（送客 / 認知 / 素材 / 多言語）・商圏・予算帯・NG 条件

## 手順
1. 候補の記録表を受け取る（人が探して記録したもの。自分で探し足さない）
2. 候補ごとに、直近 10〜12 投稿のいいね・コメントの**中央値**と
   フォロワー比を計算し、記録日を付ける（平均は 1 本のバズに引っ張られる）
3. フォロワーの質は**気づいた事実を「兆候」として書く**。「買っている」と断定しない
4. 料金は公開の料金表がある人だけ数字を書く。それ以外は「要打診」
5. 適合度に理由を 1 行付ける。本命 3 人の打診文を下書きする

## 守ること
- 打診文には「なぜあなたか」（具体的な投稿への言及）を必ず入れる
- **投稿内容を指定するのか、自由に書いてもらうのかを文面に明示する**
  （無償の招待でも、内容を指示すれば広告の表示が要る）
- 送信しない

手順の 1 にある「自分で探し足さない」は、Instagram と TikTok の検索とプロフィールの閲覧が、利用規約で自動収集を禁じられていることへの手当てです。手順書に書いておけば、候補が少ない回にエージェントが探しに出るのを、依頼文で毎回止めずに済みます。送信と交渉を人に残したのは、打診の送信が外部に出す工程だからです。この章では、どの入口でもそこは人の承認を通すと決めています。

検証の方法として、中央値とフォロワー比を明記しました。「インフルエンサーを 10 人探して」だけの依頼では、フォロワー数の多い順の一覧が返ってくるからです。平均でなく中央値を使うのは、平均が 1 本のバズに引っ張られるため。「兆候として書く。買っていると断定しない」も手順に入れてあります。フォロワーの質を外から確かめる手段が無いからです。

守ることでは「なぜあなたか」を必須にしました。誰に送っても成り立つ文面は、相手には一斉送信に見えます。返答率が下がるうえ、クライアントの評判まで落とします。投稿内容を指定するのか、自由に書いてもらうのかの明示が太字なのは、無償の招待でも内容を指示すればステルスマーケティング規制の対象になりえて、表記の責任は広告主側にあるからです。依頼の段階で決めていなければ、エージェントは訴求を細かく指定した打診文を書いてきます。案件ごとに変わる目的・商圏・予算帯・NG 条件は、依頼文に残します。

打診文の下書き

打診文は、相手が「なぜ自分に声がかかったのか」を最初の段落で分かるように書きます。次の 2 つを比べてください。

（足りない例）
はじめまして。〇〇カフェです。いつも素敵な投稿を拝見しています。
新メニューのPRをお願いできないでしょうか。ご検討よろしくお願いいたします。

この文面は、誰に送っても成り立ちます。相手からは一斉送信に見え、返事が来にくくなります。有償か無償か、投稿の内容を指定するのかも書かれていません。

（良い例）
はじめまして。商店街で〇〇カフェを営んでいる△△と申します。
8 月に投稿されていた、駅の北口の喫茶店めぐりの動画を拝見しました。
店内の光の入り方を丁寧に撮っていらしたのが印象に残り、ご連絡しました。

10 月から季節のタルトを出します。ご来店のうえ、召し上がっていただけないでしょうか。
・お代はいただきません（飲食のご提供のみで、謝礼はありません）
・投稿するかどうか、何を書くかはお任せします。こちらから内容の指定はしません
・投稿される場合は、店からの招待であることが分かるように書いていただけると助かります

ご都合のよい日を 2〜3 日教えていただければ、席をご用意します。

2 段落目で相手の具体的な投稿に触れ、条件は箇条書きで明示しています。3 つ目の点は、招待であることの表示の依頼です。内容を指定しない無償の招待が規制の対象になるかは、事業者が投稿の内容にどこまで関わったかで判断されます。表示を頼んでおけば、この点で迷う必要がなくなります。個別の判断に迷うときは、消費者庁の案内で確認してください。

トレンドに便乗する

検知から投稿案まで、1 回の実行で出し切ります。ただし「乗れるか」より先に「乗ってよいか」を判定します。 便乗の失敗は投稿しないことでは起きません。乗ってはいけない話題に乗ることで起きます。

検知の当たり先は公開面です。X の話題は公開のリアルタイム検索、TikTok の流行はクリエイティブセンター（TikTok の利用規約が自動収集を禁じているので、人が開いて見た話題を記録する）、検索の急上昇は Google トレンド、業界ニュースは期間を 24〜72 時間に絞った Web 検索。各話題に根拠（URL と観測時刻）を付け、「バズっているらしい」を根拠なしに案の土台にしません。公式 API で定期取得できるトレンド源もありますが、媒体ごとに申請や審査が要り、取れる範囲も違います。取れない面は「未取得」のままにします。

迷う話題は乗らない側を選びます。トレンド 1 本の機会損失は小さく、判定ミス 1 本の信頼損失は大きい。非対称なので、迷ったら見送りが正解です。見送った話題は理由つきで記録し、次に似た話題が来たときの判断を速くします。

採用条件は、ブランドとの接続を 1 行で言えること（「トレンド × 自社の持ちネタ」）。案には賞味期限を書きます（48 時間以内・週内・季節もの）。投稿はしません。実行は第 7 章の投稿の口（承認つき、予約は正時のみ）に渡し、「今すぐ出すべき案」はその旨を明記して人に渡します。定期実行に載せるなら毎日 1 回、朝です。週次では、検知した時点でもう遅い。そして「今日は乗る話題なし」は正常な結果です。無理に案をひねり出さず、季節ネタの前倒し提案だけ返します。

この節の判定の順序は、そのまま手順書に落とせます。毎朝の定期実行に載せるときも、中身はこの手順書です。

---
name: trend-post
description: >-
  いま起きている話題を検知し、便乗してよいかを判定してから投稿案に落とす。
  「トレンドに乗りたい」「時事ネタの投稿案を」で使う。定期実行の中身にもなる。
  ※投稿の実行は投稿のスキル（第 7 章）、カレンダーに組むのは投稿計画のスキル。
---
# トレンドへの便乗

## 手順
1. 公開面から話題を集め、**根拠（URL と観測時刻）**を付ける
2. **「乗れるか」より先に「乗ってよいか」を判定する**
   - 乗らない：災害・事故・訃報・事件、係争中、個人への攻撃、宗教・政治
   - 慎重に：他社の炎上、権利物のミーム、真偽の固まっていない速報
   - 乗ってよい：季節・気象・地域、前向きな流行、業界の明るいニュース
3. 採用条件は「トレンド × 自社の持ちネタ」を 1 行で言えること
4. 案に賞味期限を書く（48 時間以内 / 週内 / 季節もの）

## 守ること
- 迷ったら見送る。見送った話題も理由つきで記録する
- **「今日は乗る話題なし」は正常な結果**。無理に案をひねり出さない
- 投稿しない

この手順書は、検知から投稿案までを 1 回の実行で出し切り、投稿はしません。「今すぐ出すべき案」でさえ、その旨を書いて人に渡します。承認と正時の予約という仕組みの側の規則は、急ぐ案でも曲げません。description に定期実行の中身にもなると書いたのは、毎日 1 回、朝に回す前提があるからです。週次では、検知した時点でもう遅い。

手順の 2 では「乗れるか」より先に「乗ってよいか」を判定させ、乗らない話題の一覧まで書き込みました。便乗の失敗は、投稿しないことでは起きません。乗ってはいけない話題に乗ったときに起きます。基準が依頼文の側にあると、書かれていない朝、エージェントは話題の伸びだけを見て案を作ります。根拠に URL と観測時刻を付けさせるのは、「バズっているらしい」を土台にした案を止めるためです。

守ることの「迷ったら見送る」と「今日は乗る話題なしは正常な結果」は、機会損失と信頼損失の非対称から来ています。トレンド 1 本を逃す損は小さく、判定ミス 1 本の損は大きいのです。とはいえ毎朝の定期実行は、案が出てくることを期待して回ります。書いておかなければ、エージェントは無理にでも案をひねり出します。

ブランドリスニングと返信

第 3 章では戦略設計の材料として、評判を一度集める側を扱いました。この章は運用の側です。定点で回して差分を追い、返信の下書きまで出すところまでを扱います。口コミが予約・来店を直接左右する店舗型ビジネスでは、見つけてから返すまでの速さ自体が商品になります。

チャネルと表記ゆれ

見る面は、Google マップの口コミ、グルメ・美容・宿泊のポータル、X（公開のリアルタイム検索）、Instagram と TikTok のハッシュタグ・スポット面、Web 記事とブログです。Instagram と TikTok の面は、利用規約が自動収集を禁じているので、人が確認して記録した分だけを使います。最初に表記ゆれ（ひらがな・カタカナ・英字・略称・旧店名）を洗います。正式名だけで検索すると、不満を書く人の書き方をまるごと取りこぼします。「店名 最悪」「店名 ひどい」まで含めて拾う。開けなかった面は「未取得」と明記し、0 件とは書きません。「言及なし」と「見られなかった」は別の事実です。

定点の持ち方: 前回値は外から取り直す

実行環境は毎回新品で、前回のファイルはありません。前回値は外の永続先から取り直します。第一候補は前回の定点レポート（成果物）、次に案件の記録シート。どちらも無ければ初回として「今回がベースライン。差分は次回から」と宣言します。差分をでっち上げないためです。競合の定点監視も、まったく同じ型です。

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

図の元になった mermaid を見る

mermaid

flowchart LR
    B{"前回のレポートはあるか"} -->|"ある"| D["前回値を読み込み<br>差分モードで収集"]
    B -->|"無い・初回"| I["ベースラインを作り<br>「差分は次回から」と宣言"]
    D --> C["公開面だけ収集<br>閉じた面は未取得と記録"]
    I --> C
    C --> T{"要対応はあるか"}
    T -->|"ある"| R["返信・対応の下書き<br>（投稿は人が行う）"]
    T -->|"無い"| P
    R --> P["定点レポート<br>数値表は機械で拾える形"]
    P --> N(["次回のベースラインになる"])

レポート自体を次回の入力にできる形にします。数値表（チャネル・件数・評点・取得日）を機械で拾い直せる形で残し、差分は 1 レコードずつ持ちます。

{
  "brand": "example_store",
  "period": {"from": "2026-08-25", "to": "2026-09-01"},
  "channel": "google_maps",
  "collected_at": "2026-09-01T09:00:00+09:00",
  "count": 128,
  "rating": 4.3,
  "previous": {"count": 121, "rating": 4.3, "collected_at": "2026-08-25T09:00:00+09:00"},
  "delta": {"count": 7, "rating": 0.0},
  "new_items": [
    {"posted": "2026-08-30", "rating": 2, "topic": "待ち時間", "url": "https://…",
     "triage": "action", "reply_draft": "（下書き。投稿前に店舗が確認）"}
  ],
  "unavailable": ["tabelog"]
}

unavailable に入った面は「未取得」で、件数には入れません。

トリアージと返信の下書き

• 要対応: 事実誤認、衛生・安全への言及、返金やクレームの明言、同じ話題が複数チャネルに出た（拡散の始まり）。返信の下書きを作り、レポートの先頭に置きます。
• 経過観察: 単発のネガティブ、本文の無い低評価。次回の差分で増減を見ます。
• ポジ活用: 熱量の高い好意的な言及や UGC（利用者の投稿）。転載許諾を取って投稿素材にする提案に回します。

「急増」「炎上の兆候」を形容詞で書かず、「期間＋実測値＋変化量」で書きます（「直近 7 日で言及 18 件、前週 3 件の 6 倍。うちネガティブ 11 件が同じ待ち時間の話題」）。サンプルが少ない期間に割合で断定しません。「ネガティブ 67%」が 3 件中 2 件なら、件数のまま書きます。

返信を自動投稿する経路は作りません。下書きをレポートに載せ、投稿はクライアント承認後に人が管理画面から行います。事実誤認への返信は裏が取れてから書きます。裏の取れない反論は炎上を広げるので、確認事項を質問として添えます。サクラや自作自演、良い評価の人だけの誘導、口コミ削除の「代行」は提案しません（次節）。

定期実行の頻度は、口コミ返信を運用中なら毎週、キャンペーン・テレビ露出・炎上対応中は毎日。定点で見るのは数値表、本文まで読むのは新着だけにすると、実行時間が安定します。自動で動いたものは必ず通知に残し、通知先の無い定期実行は有効にできない形にします（第 11 章）。

スキルの例: 口コミ・評判の定点監視

第 2 章では、このスキルの frontmatter（description）だけを示しました。ここでは本文側を具体的に書きます。公開面を読んで差分を出し、返信の下書きまでを作る役割で、返信の投稿はしません。

---
name: review-watch
description: （第 2 章の例と同じ。依頼の言い方と、扱わない依頼の行き先を書く）
---
# 口コミ・評判の横断定点監視

## 手順
1. 表記ゆれの一覧を作る（正式名・略称・ひらがな・英字・旧店名）。
   「店名 最悪」「店名 ひどい」も検索語に入れる。
2. 前回値を読む。①前回の定点レポートの数値表 ②案件の記録シート の順に探す。
   どちらも無ければ、冒頭に「今回がベースライン。差分は次回から」と書く。
3. 面ごとに収集する。本文まで読むのは前回以降の新着だけ。Instagram と TikTok は開かず、人が記録した分を読む。
   開けなかった面は unavailable に入れ、件数に含めない。
4. 新着を 3 区分に分ける（要対応 / 経過観察 / ポジ活用）。
   要対応 = 事実誤認・衛生や安全・返金やクレーム・複数の面に同じ話題。
5. 要対応には返信の下書きを付ける。裏の取れていない点には反論せず、
   店舗への確認事項として書き出す。
6. 下の型でレポートを書く。

## 出力の型
- 一言でいうと（1〜2 文）
- 要対応（下書きつき。「投稿前に店舗が確認」と明記する）
- 面ごとの数値表：面・件数・評点・前回比・取得日（次回の入力になる）
- 変化は「期間＋実測値＋変化量」で書く。3 件中 2 件を「67%」と書かない

## やらないこと
- 返信・投稿はしない（下書きまで）
- サクラ、良い評価の人だけへの誘導、口コミ削除の代行を提案しない

## 縮退先
- 開けない面がある → 開けた面と Web 検索で作り、欠けた面を明記する
- どの面も開けない → 店舗に「管理画面の口コミ一覧の画面写し（直近 30 日分）」
  を依頼し、届いた分から同じ型で作る

手順の 1 では、表記ゆれに加えて「店名 最悪」まで検索語に入れさせます。正式名だけで検索すると、不満を書く人の書き方をまるごと取りこぼすからです。手順の 2 に前回値の読み先を順番で書き、無いときの宣言まで決めたのは、実行環境が毎回新品で、前回のファイルを探しても出てこないからです。ここまで書いてあれば、差分をでっち上げる余地は残りません。手順の 3 で開けなかった面を unavailable に入れ、件数に含めないのは、「言及なし」と「見られなかった」が別の事実だからです。

下書きについては「裏の取れていない点には反論せず、確認事項として書き出す」と決めています。裏の取れない反論は、炎上を広げるだけです。やらないことには、返信の投稿と、サクラ・誘導・削除代行を並べました。前者は人の承認を通す外部反映、後者はそもそも提案しない規則。どちらも、依頼文の書き方に左右されずに止めておくためです。

縮退先は 2 段にしました。面が開けない回に「取れませんでした」で止まると、その週の差分がまるごと欠けます。2 段目では、店舗に頼む内容を「管理画面の口コミ一覧の画面写し、直近 30 日分」まで決めてあります。ここまで書かないと、エージェントは「口コミを送ってください」とだけ返し、店舗は何を送ればいいのか分かりません。

店舗のもう 1 つのアカウント: Google ビジネスプロフィール（MEO）

店舗のお客さまにとって、Google マップはサイトより先に見られる入り口です。MEO（マップ検索での発見性を高める運用）は、プロフィールを埋める・写真を更新する・口コミに返す、の繰り返しです。地味な分野に見えますが、やってはいけないことがはっきりしているという点で、他の運用より線が引きやすい。まずそこから書きます。

やってはいけないこと

判定の根拠は 2 つです。Google のマップ投稿ポリシー（ 禁止および制限されているコンテンツ ）が対価付きの依頼、ネガティブの抑制、選択的な依頼を禁じていること。そして日本のステルスマーケティング規制です。エージェントの指示には「対価付きの依頼と良い評価だけの誘導は提案しない・真似しない」を入れ、クライアント側の独断で走らないよう合意文書にも一文入れます。口コミ促進ツールを導入済みの店舗では、満足度アンケートの回答スコアで投稿ページへの導線が出る・出ないが分岐していないかを外形で検査します。分岐があればアウトです。

導入済みの口コミツールを点検する

依頼主がすでに口コミを増やすためのツールを入れている場合は、最初の診断で導線を外から確かめます。見るのは 3 点です。

1. 口コミを頼む前に、満足度のアンケート（5 段階評価など）を挟んでいるか
2. アンケートの回答によって、口コミ投稿ページへのリンクが出たり出なかったりするか。低い評価の人だけが社内の意見フォームに送られていないか
3. 「投稿で特典」のような対価の表示が、導線に含まれていないか

アンケートを挟むこと自体は問題ありません。問題になるのは 2 と 3 です。該当したら、リスクを具体的に伝えたうえで、全員に同じ依頼をする導線への切り替えを提案します。伝えることは 2 つあります。1 つ目は国内の行政処分です。2024 年 6 月、口コミで高い評価を付けることを条件に費用を割り引いていた医療機関に対し、ステルスマーケティング規制に基づく初の措置命令が出ました（ 消費者庁の案内 ）。処分を受けるのは依頼主の事業者です。2 つ目はプラットフォーム側の措置で、ポリシー違反と判断されると、口コミの削除などを受けることがあります。

初期診断

健康診断で見るのは 4 点。プロフィールの埋まり具合（カテゴリ、営業時間、写真の枚数と新しさ、投稿の有無）、口コミ（件数・平均評点・返信率）、同じエリア・同じ業種の上位 3 店との差の表、そして名称・住所・電話番号（NAP）が Google 以外の地図サービスや業種ポータルでも揃っているか。表記が揺れていると、別の店として扱われることがあります。診断は「いまの点数」と「直す順番（緊急度つき）」で出し、採点の分母は判定できた項目だけにします。判定不能を 0 点にすると、「未設定」と同じ意味になってしまいます。

導入時に一度だけ行う整備

月次の運用に入る前に、次の順で一度だけ整備します。

1. 権限を整理する。プロフィールのオーナー権限は依頼主の側に置き、支援する側は管理者として入る。逆にすると、契約が終わったときにプロフィールを誰も管理できなくなる
2. プロフィールを埋める。ビジネス名はガイドラインどおりにする（地名や業種の語を足さない）。メインと追加のカテゴリ、説明文、祝日と特別営業時間を含む営業時間、属性、メニューやサービス、予約リンクまで埋める
3. 写真を揃える。外観・内観・商品や客室・スタッフ。SNS 用に撮った素材を使い回す
4. 名称・住所・電話番号を、Google、他社のマップサービス、業種のポータル（飲食ならグルメサイト）で突き合わせ、表記の違いを直す
5. 基準値を記録する。表示回数・行動数・口コミの件数と評点と返信率・主要キーワードの順位を、導入時点の値として残す
6. 過去の未返信の口コミにさかのぼって返信する
7. 自社サイトによくある質問のページがあるか、内容が古くないかを確かめる。AI による回答がプロフィール以外の情報も参照するようになってきているため、確認の対象に含める
8. 口コミを頼む導線を作る（後の「口コミ依頼の文面と記録」）

5 の基準値は忘れやすい項目です。運用を始めてから記録しても、始める前の値は取り戻せません。後で成果を比べることも、事例としてまとめることもできなくなります。

キーワードを決める

計測するキーワードは「地域名 × 業種・サービス」を基本の形にします。地域名は 3 つの粒度で洗い出します。市区町村名、駅名、観光地や繁華街の名前です。1 店舗あたり 5〜10 個に絞ります。多すぎると毎月の計測の回数が増え、実査が止められやすくなります。訪日客が多い店は英語のキーワードも加えます。管理画面の検索語句レポートがあれば、実際に表示につながった語句を最優先で入れます。

# 温泉旅館のキーワード設計の例
store: 温泉旅館（自社）
keywords:
  - {kw: "〇〇温泉 旅館", source: 検索語句レポート, note: 表示回数が最も多い}
  - {kw: "〇〇温泉 日帰り", source: 検索語句レポート}
  - {kw: "〇〇駅 旅館", source: 机上, note: 駅名の粒度}
  - {kw: "〇〇市 露天風呂付き客室", source: 机上, note: 市区町村の粒度}
  - {kw: "ryokan 〇〇", source: 机上, note: 訪日客向け}
fixed_since: 2026-09-01   # 途中で入れ替えたら日付を残す

source を残すのは、検索語句レポートに裏付けのあるキーワードと、机上で選んだキーワードを区別するためです。机上で選んだものは、検索語句レポートに現れるかを毎月確かめます。入れ替えるときは日付を残し、入れ替えの前後で順位の推移を続けて読まないようにします。

順位の正しい測り方

マップの順位は、検索した人の現在地からの距離に強く影響されます。店舗の目の前で測れば 1 位。ただ、その順位に意味はありません。測定地点・キーワード・日時（と測定方法）を必ず記録し、商圏の広さに応じて複数の地点で測り、同じ条件で毎月測って推移として見ます。地点は 3 種類に分けて固定します。店舗前（順位が出やすい基準点。ここ「だけ」で測らないための基準）、駅前のような集客の起点、商圏の外縁（露出がどこまで届くかの境界）。

順位とレビューを一括で返す商用 API の契約は無い前提なので、数値は実査で取ります。ログインしていないクリーンなブラウザで測り、検索の間に数秒の待機を入れ、1 セッションの検索回数を控えめに保ちます（キーワード 5 個 × 地点 5 箇所程度が上限の目安）。CAPTCHA が出たら即座に中断して報告し、リトライしません。中断までの結果は残し、未計測の行は作りません（欠測を 0 や圏外として記録しない）。検索 URL に座標を付けて地点を指定する方法は、順位に効くかどうかの一次情報がありません。だから検証プロトコル（離れた 2〜3 地点で同じキーワードを開き、表示が座標に応じて変わるかを確かめる）に通るまで本線に置かず、通っていない段階では「測定環境の既定地点で測った」と正直に書きます。

記録は追記専用のログにし、既存行は変えません。

date,keyword,location,rank,note
2026-09-01,渋谷 美容室,"店舗前(35.6595,139.7005)",3,"10:05 実査・クリーン・基準地域の表示あり"
2026-09-01,渋谷 美容室,"駅前(35.6580,139.7016)",>20,"10:08 実査・圏外"

順位は小さいほど良いので、改善・悪化は数字の増減ではなく言葉で書きます（「3.2 位 → 1.8 位（改善）」）。

商圏全体での見え方をまとめる

地点を複数にすると、キーワードごとに地点の数だけ順位が並びます。これを 1 つの数字にまとめる方法として、上位 3 位以内に表示された地点の割合（シェア）を使います。

シェア = 上位 3 位以内に表示された地点の数 ÷ 実際に計測できた地点の数 × 100

分母は「計測できた地点」です。CAPTCHA などで取れなかった地点を圏外として分母に入れると、計測の失敗が順位の悪化に見えます。表に並べるときも、取れなかった地点は「?」のような別の記号で書き、圏外（20 位より下）と区別します。

キーワード: 渋谷 美容室（2026-09-01 10:00〜10:20 実査・ログインなし）
          西     中央    東
  北      5      3      ?
  中央    2      1      4
  南     >20     6      8
シェア: 上位 3 位以内 3 地点 ÷ 計測できた 8 地点 = 38%

この値は「この条件で観測された値」として出し、日時・ログイン状態・測定した回線の地域を併記します。座標を指定した計測がその地点の順位になっているかは、前に書いた検証プロトコルに通してから使います。

複数地点での計測も手順書にしておきます。測って 1 つの指標にまとめるだけの手順書で、プロフィールの運用には触れません。

---
name: map-intelligence
description: >-
  商圏内の複数地点で地図の順位を測り、見え方の広がりを 1 つの指標にまとめる。
  「商圏全体での見え方」「地点を変えて測って」「競合の半径」で使う。
  ※月次の運用はプロフィール運用のスキル。
---
# 商圏での見え方

## 手順
1. 地点を 3 種類に分けて固定する（店舗前 / 集客の起点 / 商圏の外縁）
2. 同じ条件で毎月測る（ログインしていない状態、検索の間に数秒の待機）
3. 上位 3 位以内に出た地点の割合を出す。
   **分母は「実際に計測できた地点」**（取れなかった地点を圏外にしない）
4. 表に並べるときも、取れなかった地点は別の記号にする

## 守ること
- 座標を指定した計測がその地点の順位になっているかは、
  **離れた 2〜3 地点で表示が変わるかを確かめてから**本線に使う
- 確かめていない段階では「既定の地点で測った」と正直に書く
- 順位の改善・悪化は数字の増減ではなく言葉で書く

月次運用から切り出しているのは、複数地点の計測が運用と独立に頼まれる仕事だからです。成果報酬型の業者が順位の出やすい地点だけで測った報告を、依頼主が持ち込むことがあります。そのセカンドオピニオンに運用の手順書が立つと、投稿や返信の手順が一緒に走ります。

手順の 1 で地点を 3 種類に分けて固定させるのは、店舗前だけで測った順位に意味が無いからです。それでも店舗前は外しません。基準点として置くことで、「ここだけで測らない」を形にしています。手順の 3 では、分母の「実際に計測できた地点」を太字にしました。CAPTCHA で取れなかった地点を圏外として分母に入れれば、計測の失敗が順位の悪化に見えてしまいます。

守ることに検証プロトコルを入れたのは、検索 URL に座標を付けて地点を指定する方法が順位に効くのか、一次情報が無いからです。確かめずに載せると、地点ごとに並べた順位が実は全部同じ既定の地点の値だった、ということが起きます。改善・悪化を言葉で書かせる理由は、順位が小さいほど良い数字である点にあります。「3.2 位 → 1.8 位」を数字の減少と読まれたら、意味が逆になります。

月次運用と効果測定

毎月やることは 4 つに絞れます。投稿を週 1〜2 本（SNS 運用で作った動画・写真の転用が第一候補）。写真の定期更新。口コミへの返信は 24〜48 時間以内・返信率 100% を目標。口コミのお願いは来店直後の声かけと QR 案内で、対価を付けない。投稿文も返信文も公開前に店舗側の確認を取ります。返信は店舗の公式な発言として残るので、言葉づかいを合わせる必要があります。口コミ獲得のタイミングは業種で変わります（飲食は会計直後の卓上 QR、宿泊はチェックアウト後の同日中、美容室は仕上がり確認時）。歩留まりは「依頼数 → 口コミ件数の月次差分」で追い、チャネル別の反応率のような一次データの薄い数値は「〜という報告がある」に留めます。

依頼の例: 口コミ返信の下書き

返信の下書きを頼むときは、店の事実（実際に何があったか）と、書いてはいけないことを渡します。事実を渡さずに頼むと、謝罪と一般的な改善の約束だけの文ができます。どの口コミにも同じような文が並ぶと、読んだ人には定型文だと分かります。

駅前の美容室の Google ビジネスプロフィールで、未返信の口コミ 4 件に返信の下書きを作ってください。

口コミ: 添付の CSV（投稿日・星・本文）。星 2 の 1 件は、予約時刻から 20 分待ったという内容
店の事実: その日は前のお客様の施術が延びた。待ち時間の連絡はしていなかった。
          来月から、遅れが 10 分を超えそうなときは受付から声をかける
トーン: 丁寧語。「お客様」と呼ぶ。1 件 150 字前後。絵文字は使わない
書かないこと: 個人を特定できる情報（担当者名・来店日時の詳細）、割引やクーポンの提案、
             店の事実に無い理由づけ（「混雑のため」など）
高評価への返信: 本文で触れられている具体的な点（仕上がり・説明など）に 1 か所触れる
出力: 口コミごとに下書きを 1 つ。店長の確認後にこちらで公開するので、投稿はしない

（星 2 の口コミへの下書き）
このたびはご来店いただき、ありがとうございます。ご予約のお時間から 20 分お待たせし、
その間にご連絡もせず、申し訳ございませんでした。前のお客様の施術が延びたことが原因です。
来月からは、お待たせが 10 分を超えそうなときに受付からお声がけいたします。
またのご来店をお待ちしております。

下書きの 3 文目と 4 文目が、渡した事実から書かれた部分です。原因と次の対応が書いてあれば、後からこの口コミを読む人にも、店が何を変えたかが伝わります。「書かないこと」に割引を入れているのは、返信で特典を約束すると、口コミへの対価のように読まれるおそれがあるためです。

口コミ依頼の文面と記録

口コミを増やす導線は、3 つの原則で作ります。全員に同じ依頼をする（満足度で相手を選ばない）。対価を付けない。依頼は 1 回にして、催促を重ねない。

口コミ投稿用のリンクと QR コードは、Google ビジネスプロフィールの管理画面から作れます（ 公式ヘルプ ）。執筆時点では、QR コードを作れるのはパソコンのブラウザからだけです。このリンクを、店頭の声かけ・卓上やレシートの QR・LINE やメールのメッセージに載せます。文面は業種ごとに用意し、店の確認を取ってから使います。

（美容室・施術後に仕上がりを確認するときの声かけ）
本日はご来店ありがとうございました。
もしよろしければ、仕上がりのご感想を Google の口コミに書いていただけるとうれしいです。
（QR コードのカードを渡す）

（温泉旅館・チェックアウト当日のメッセージ）
〇〇旅館をご利用いただき、ありがとうございました。
よろしければ下記から、ご滞在の感想を Google の口コミにお寄せください。
率直なご意見を今後の参考にいたします。（リンク）

どちらの文面にも、「良い評価を」「星 5 つで」のような評価の指定と、特典の案内がありません。「率直なご意見」と書くのは、不満のある人にも同じ依頼をしていることを文面で示すためです。

歩留まりは、依頼の件数と口コミの増えた件数で、月ごとに記録します。QR 経由の依頼はクリックを追いにくいので、依頼の件数はスタッフの記録か、配ったカードの枚数で代わりに数えます。

date,channel,requested_count,posted_count_diff,note
2026-09-30,店頭の声かけ;卓上QR,180,9,"9月から施術後の声かけを開始"
2026-10-31,店頭の声かけ;卓上QR;LINE,210,14,"LINE の文面を追加"

posted_count_diff は口コミ件数の前月からの差です。依頼以外の理由で増えた口コミも含まれるので、依頼の効果そのものではありません。文面や経路を変えた月は note に残し、前後の月を比べられるようにします。

月次で見る数字

月次で見る数字は 5 つです。表示回数（検索から／マップから、別々に）、実際に検索された語句、行動の数（電話・経路案内・サイト遷移）、口コミ（件数・評点・返信率）、計測できる範囲での成果。「表示 → 行動 → 転換」の順で見ます。実際に表示につながった検索語句はキーワード設計のいちばん強い材料なので、管理画面を見られるなら最優先で採用します。時間軸は先に共有しておきます。表示回数が動き出すのに 1〜2 か月、売上につながる数字まで 4〜6 か月が目安で、1 か月で成果を断定しません。

口コミの読み方

集めた口コミは 3 つの観点で読みます。

• 評価の分布と、低評価の理由の分類（接客・待ち時間・価格・設備など）
• よく出てくる話題。強みとして繰り返し書かれている言葉は、プロフィールと投稿の文面に使う。弱みは改善の提案の根拠にする
• 同じエリアの競合との比較（件数・評点・返信率・話題）

数字は定義を決めてから出します。返信率は「オーナーの返信がある口コミの数 ÷ 口コミの総数」、増えるペースは「直近 6 か月の、月あたりの新しい口コミの数」です。

競合の口コミを読んでいると、不自然な口コミのまとまりに気づくことがあります。次の兆候が 2 つ以上重なる口コミには、一覧で印を付けておきます。

• 同じ日や同じ時間帯に、まとまって投稿されている
• 投稿者の過去の口コミがほとんど無い
• 本文が他の口コミとほぼ同じ
• それまでの水準から急に、星 5 の口コミだけが増えている
• 増えた時期に、それを説明できる販促の動きが見当たらない

「偽の口コミ」とは断定しません。外から確かめる手段が無いので、兆候として事実を書き、判断は読む人に残します。インフルエンサーのフォロワーの質を扱ったときと同じ書き方です。

月次レポートの章立て

月次のレポートは 5 章で組みます。

1. 一言でいうと（今月いちばん大きい変化。前月比に加え、季節の影響が大きい業種は前年同月比も）
2. 5 つの数字の推移
3. 順位の計測結果（地点・キーワード・日時・方法を書いた表。店舗前の順位だけを載せない）
4. 今月やったこと（投稿・写真・返信の件数）
5. 来月の提案（検索語句と口コミの話題を根拠にする）

SNS の月次レポートと 1 つの資料にまとめてもかまいません。依頼主が読む資料の数を増やさずに済みます。

初期診断から月次のレポートまでを 1 つの手順書にすると、次のようになります。診断・計測・月次運用を全部持つ手順書で、口コミの増やし方だけは禁じ手を先に断っています。

---
name: gbp-operations
description: >-
  店舗の地図プロフィールを診断し、順位を測り、月次の運用とレポートを回す。
  「MEO」「マップで上位表示したい」「口コミ返信」「口コミを増やしたい」で使う。
  ※サイト側の点検はローカル SEO のスキル、横断の評判監視はリスニングのスキル。
---
# 地図プロフィールの運用

## 提案しないこと（先に書く）
- 対価付きの口コミ依頼（「投稿で割引」）
- 満足度で相手を選んでから投稿を依頼する導線
- 自作自演・代行発注・低評価の削除代行
- 測定条件の無い順位の報告

## 手順
1. 初期診断：プロフィールの埋まり具合・口コミ・同エリア上位 3 店との差・
   名称と住所と電話番号の一致。**分母は判定できた項目だけ**
2. キーワードを 5〜10 個に絞る（市区町村・駅名・観光地の 3 粒度）
3. 順位は**測定地点・キーワード・日時・方法**とセットでしか記録しない。
   追記専用のログにし、既存行を変えない
4. 月次：投稿週 1〜2 / 写真の更新 / 口コミ返信 24〜48 時間 / 口コミ依頼の導線
5. 月次の数字は 5 つ（表示回数・検索語句・行動数・口コミ・成果）

## 縮退先
- 実査が止められた → 繰り返さず、管理画面の書き出しや画面写しの持ち込みに切り替える
- 測れなかった地点は圏外と区別し、割合の分母に入れない

「提案しないこと」が手順より前にあるのは、この手順書が「口コミを増やしたい」という依頼で立つからです。増やす方法としてまず思いつくのは、「投稿で割引」と高評価の人だけへの案内。どちらもポリシー違反で、対価付きの依頼には 2024 年 6 月に措置命令が出ています。処分を受けるのは依頼主の事業者です。横断の評判監視は別の手順書へ送りました。見つける側と、管理画面で返す側を分けておくためです。

初期診断の分母「判定できた項目だけ」は太字にしてあります。判定不能を 0 点にすると、「未設定」と同じ意味になってしまうからです。順位は測定地点・キーワード・日時・方法とセットでしか記録させません。条件の無い順位は「不可」の表に入っているので、記録の形としても作れないようにしておきます。月次の 4 つと数字の 5 つは、案件が変わっても同じ。だから手順書に固定し、店の事実やトーンは口コミ返信の依頼文に残します。

縮退先の 1 行目の「繰り返さず」は、実査が止められたときにエージェントが別の経路を探し始めるのを防ぐためのものです。止まったらどうするかを先に書いておくのは、拒否に代替を書くのと同じ考え方。2 行目の測れなかった地点の扱いも外せません。中断までの結果を残す以上、欠測の行が圏外と混ざる入口はここにあります。

API と実査の使い分け

Google ビジネスプロフィールには公式 API があります（ Google Business Profile APIs ）。口コミの一覧と返信（ 口コミの取得と返信 ）、パフォーマンス（表示回数・行動数・検索語句）の取得が対象で、オーナーまたは管理者の権限が前提です。執筆時点では利用にアクセス申請が要るとされているので、実装前に公式ドキュメントで確認してください。

公式の前提条件のページには、確認済みで 60 日以上運用しているプロフィールを管理していること、事業を表すウェブサイトがあること、申請にプロフィールのオーナーか管理者のメールアドレスを使うこと、が挙げられています（ 前提条件 ）。審査の結果はメールで届き、使えるようになるまで時間がかかります。定期の取得を API で組む予定があるなら、契約の初月に申請しておきます。

代替できないものは正直に伝えます。24 時間のリアルタイム監視、数百地点級のジオグリッド（商圏を格子に切って各点で順位を測る手法）、多店舗の一括配信は、実査ベースでは提供できません。「自動で取れた」ように書かず、確認方法と確認日を残します。

プロフィールの無断の変更を月次で見つける

プロフィールは、第三者からの修正の提案が反映されて、店の知らないうちに変わることがあります。公開されているプロフィールを月に 1 回読み取り、同じ形のファイルに残して前回と比べます。

{
  "snapshot_date": "2026-09-01",
  "name": "ヘアサロン〇〇 駅前店",
  "category": "美容院",
  "address": "〇〇県〇〇市…",
  "phone": "000-0000-0000",
  "hours": {"mon": "定休日", "tue": "10:00-19:00"},
  "attributes": ["予約可", "キャッシュレス決済"],
  "url": "https://example.com/"
}

項目ごとに前回の値と今回の値を並べ、変わった項目だけを表にします。変わっていたら、店が自分で変えたのかを確認します。店に覚えが無ければ管理画面で直し、月次レポートの特記事項に書きます。この方法では、変更に気づくのが最大で 1 か月遅れます。そのことは最初に店と共有しておきます。

店舗のサイト側を整える: ローカル SEO

Google ビジネスプロフィールと並んで、店舗の公式サイトもマップ検索の結果に影響します。SEO 全般は第 6 章で扱いました。ここでは、店舗のサイトに固有の点検だけを書きます。

まず事業の形を判定する

点検の項目は店の形で変わります。最初に、次の 3 つのどれに当たるかを判定します。

出張型の事業を「住所が無い」と減点すると、正しい状態を問題として報告することになります。判定を最初に置くのはこのためです。

サイトのページで見ること

• タイトルと H1 見出しに、地域名とサービス名が入っているか（「〇〇駅 美容室」）
• 店名・住所・電話番号（NAP）がページの文字として表示されているか（フッターやアクセスのページ）。画像の中の文字だけでは、検索エンジンが読み取れない
• 電話番号が、押すと発信できるリンク（tel:）になっているか
• 主なサービスごとに専用のページがあるか（カット・カラー・ヘッドスパを 1 ページに詰め込まない）
• マップの埋め込みは、表示速度を落とさないように遅延読み込みにしているか

複数の拠点を持つ事業では、拠点ごとのページの質を見ます。確かめ方として「入れ替えテスト」があります。ページの地名を別の拠点の地名に入れ替えても文章が成り立つなら、そのページは地名だけを変えて量産したページです。Google のスパムポリシーは、地域や都市ごとに作って利用者を 1 つのページへ誘導するページを、誘導ページの不正な使い方の例に挙げています（ スパムポリシー ）。拠点ごとに、その店の写真・スタッフ・アクセスの説明・その地域のお客さまの声など、入れ替えのきかない内容を入れます。

名称・住所・電話番号を 3 つの出どころで突き合わせる

NAP は、①ページに表示されている文字、②ページに埋め込んだ構造化データ、③Google ビジネスプロフィール、の 3 か所から取り出して比べます。食い違いには重さを付け、直す順番を決めます。次の表は著者の運用での優先度です。

同じ突き合わせを、Google 以外のマップサービスと業種のポータルにも広げます。オーナー登録をしていない媒体にも、店の情報が自動で載っていることがあります。「載っていない」と決めつけずに、検索して確かめます。

構造化データ（LocalBusiness）

構造化データ（検索エンジンが読み取れる形で、ページの内容を書き添えるデータ）は、店舗なら LocalBusiness の型で書きます。Google の説明では、必須のプロパティは name と address、推奨は geo・openingHoursSpecification・telephone・url・priceRange などです（ Google 検索セントラルの説明 ）。型は、業種に合ういちばん具体的なものを選びます。美容室なら HairSalon、飲食店なら Restaurant、宿泊施設なら Hotel や LodgingBusiness です。LocalBusiness のままにはしません。

{
  "@context": "https://schema.org",
  "@type": "HairSalon",
  "@id": "https://example.com/shops/ekimae/#shop",
  "name": "ヘアサロン〇〇 駅前店",
  "address": {
    "@type": "PostalAddress",
    "postalCode": "000-0000",
    "addressRegion": "〇〇県",
    "addressLocality": "〇〇市",
    "streetAddress": "駅前 1-2-3"
  },
  "geo": {"@type": "GeoCoordinates", "latitude": 35.65951, "longitude": 139.70052},
  "telephone": "+81-00-0000-0000",
  "url": "https://example.com/shops/ekimae/",
  "priceRange": "カット 4,000〜6,000 円",
  "openingHoursSpecification": [{
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "Sunday"],
    "opens": "10:00",
    "closes": "19:00"
  }]
}

書くときの注意は 3 つです。

• 緯度と経度は小数点以下 5 桁以上で書く（Google の説明にある条件）
• priceRange は 100 文字未満にする。100 文字以上だと価格帯が表示されない
• 自店の口コミの評点（aggregateRating）を自店のページに書かない。評価される側が自分で管理している口コミは、LocalBusiness の星の表示の対象外だと Google は説明しています（ レビュー スニペットの説明 ）。プロフィールの口コミをサイトに埋め込んだ場合も同じ扱いです

複数の拠点がある事業では、拠点のページごとに LocalBusiness を 1 つ置き、@id をページごとに変えます。1 つのデータに全拠点を並べると、どの住所がどのページの店なのかを読み取れません。

この節の点検も手順書にまとめておきます。サイトを読んで点検するだけの手順書で、地図の順位も表示回数も測りません。

手順の 1 は事業の形の判定で、「出張型を減点しない」まで書いてあります。住所の点検が先に走ると、正しい状態を問題として報告してしまうからです。手順の 3 の「文字として」が太字なのは、画像の中の店名や電話番号が、人の目には表示されているように見えても、検索エンジンには読み取れないため。守ることの「自店の口コミ評点を書かない」は、評価される側が自分で管理している口コミがレビュースニペットの対象外だからです。最後の「順位も表示回数も分からないと明記する」は、description で地図プロフィール側を別の手順書に送ったのと同じ理由です。サイトの点検が通ったことを、地図で見つかることだと読ませないためです。

---
name: local-seo-check
description: >-
  店舗の公式サイトを、地域検索の観点で点検する。
  「ローカル SEO」「店舗のサイトを見て」「NAP の一貫性」で使う。
  ※地図プロフィール側の運用はプロフィール運用のスキル。
---
# 店舗サイトの点検

## 手順
1. **事業の形を先に判定する**（実店舗 / 出張・訪問型 / 両方）。
   出張型を「住所が無い」と減点しない
2. タイトルと見出しに地域名とサービス名が入っているか
3. 名称・住所・電話番号が**文字として**表示されているか（画像の中の文字は読めない）
4. 電話番号が発信リンクになっているか
5. 主なサービスごとに専用のページがあるか
6. 名称・住所・電話番号を**3 つの出どころ**（表示 / 構造化データ / 地図プロフィール）
   で突き合わせ、食い違いに重さを付ける（名称 = 高 / 住所 = 中〜高 / 電話 = 中）
7. 拠点ページは**入れ替えテスト**にかける

## 守ること
- 構造化データは業種に合う具体的な型を使う。自店の口コミ評点を書かない
- この点検では地図の順位も表示回数も分からないと明記する

YouTube と海外プラットフォーム

YouTube は、公開データを公式 API（ YouTube Data API ）で取れる数少ないプラットフォームです。チャンネル情報、動画の一覧、再生数・いいね・コメント数の統計が取れます。執筆時点で既定の割り当ては 1 日 10,000 ユニット。検索は別枠の回数上限があり、操作ごとに消費量が違います（ 割り当ての説明 ）。

競合分析の型は「外れ値」です。チャンネルの平均再生数の 2 倍を超える動画を研究対象にし、タイトルに共通する語とサムネイルの型を抽出します。投稿頻度の高いチャンネルは 1 本あたりの平均が下がるので、倍率で比べます。自分のチャンネルの分析にアクセスできるなら、提案した型を公開後の実績（表示回数・クリック率・平均視聴時間）と比べ、勝った候補だけを型に昇格させます。アナリティクスで確かめるまで、型を「検証済み」とは呼びません。 一括収集のスクリプトは手元の環境でしか動きません。サーバー上の実行では 1 件ずつ叩く道具を試し、鍵が無ければそこで止めて、利用者に分析の CSV 書き出しや人気順の画面写しの持ち込みを依頼します。

訪日客向けの運用では、中国のプラットフォーム（抖音・小紅書）が出てきます。国際版とは別のアプリ・別のアカウント体系で、企業認証や現地法人の要件があり、外部リンクへの誘導が配信の抑制対象になるなど、作法が根本から違います。抖音は完了再生率がフォロワー数より先に効き、小紅書は「保存」が評価の中心で、検索から消費されるメディアです。効果測定は、位置情報（POI）のクリックから保存、来店証明（クーポン利用）まで見ます。技術的に押さえるのは 2 点だけ。公開 API で取れるものはほぼ無く、実査も国内からは制約が多いこと。現地の広告法の表現規制（「最」「No.1」「絶対」の禁止）と日本のステルスマーケティング規制の両方がかかること。運用の型（採点・定点・承認）は同じで、取得経路と規制だけが違います。

YouTube の外れ値を「検証済みの型」にするまで

外れ値の動画から抜き出したタイトルやサムネイルの型は、まだ仮説です。自分のチャンネルで試し、数字で確かめてから型として使います。公開の前に、次の項目を記録しておきます。

video_id: （公開後に記入）
published_at: 2026-09-10
title: 温泉旅館の朝ごはん、5 分でわかる全 12 品
thumbnail_concept: 料理を真上から撮った写真 + 大きな数字「12」
hook: 最初の 5 秒でいちばん豪華な一品を見せる
topic: 食事
source_pattern: 競合の外れ値（平均の 3.1 倍）にあった「〇分でわかる」型
baseline: 同じトピックの過去 5 本の中央値

見る数字によって、判断できるまでの期間が違います。著者の運用では、次の期間を置いてから読んでいます。

期間を決めずに見ると、公開翌日の数字で型を採用したり捨てたりすることになります。基準（同じトピックの過去の動画の中央値）を上回った場合だけ、その型をタイトルの書き方やサムネイルの決まりとして残します。

型の候補も挙げておきます。長尺では「〇〇をわかりやすく解説」「〇時間分を〇分で」「いちばん手間のかからない〇〇のやり方」。ショートでは、「去年と今年の〇〇」の比較、「普通・良い・最高」の 3 段階の並べ方、「〇〇はやめて、△△をしよう」のような逆の提案です。どれも候補であり、自分のチャンネルで確かめるまでは検証済みと呼びません。

依頼の例: 数字の持ち込みを前提にした分析

一括で取得する仕組みが使えない環境では、依頼の中で数字の出どころを決めておきます。

（足りない例）
ライバルの旅館の YouTube チャンネルを分析して、バズる動画の法則を教えてください。

この依頼では、分析する期間も、再生数をどこから取るかも決まっていません。エージェントが数字を取得できないまま一般論の「法則」を書いたり、見えない数字を推定で埋めたりすることがあります。

（良い例）
温泉旅館の YouTube チャンネルの改善のために、外れ値の分析をお願いします。

データ: ①自社は YouTube Studio のアナリティクスから書き出した CSV（過去 365 日・
        動画ごとのタイトル・公開日・視聴回数）を添付します
        ②競合 2 チャンネルは、動画の一覧を人気順に並べた画面写し（上位 20 本）を添付します
判定: チャンネルごとの平均視聴回数の 2 倍以上を外れ値とする。チャンネルをまたいで
      視聴回数を直接比べず、各チャンネルの平均に対する倍率で比べる
出力: 外れ値の一覧（タイトル・公開日・倍率）→ タイトルとサムネイルに共通する型 → 次に試す 3 本の案
      画面写しに無い数字（クリック率・視聴維持率など）は「未取得」と書く
      レポートの冒頭に、データの出どころと取得日を書く

「倍率で比べる」と指定しているのは、登録者数の違うチャンネルの視聴回数をそのまま並べると、規模の差しか見えないからです。

外れ値の分析を手順書にしておくと、依頼のたびに判定の基準と読むまでの期間を書かずに済みます。

---
name: youtube-outlier
description: >-
  YouTube チャンネルの**外れ値**（平均の 2 倍超え）を拾い、
  タイトルとサムネの型を抜き出す。
  「YouTube の競合分析」「バズる動画のパターン」「サムネのヒントがほしい」で使う。
---
# 外れ値の分析

## 入力
- 自社：分析画面から書き出した CSV
- 競合：人気順に並べた一覧の画面写し

## 手順
1. チャンネルごとの平均を出し、**倍率**で外れ値を拾う
   （チャンネルをまたいで再生数を直接比べない）
2. タイトルに共通する語と、サムネの型を抜き出す
3. **抽出した型はまだ仮説**。自社で試し、下の期間を置いてから読む
   - クリック率・序盤の視聴維持：24〜48 時間
   - 平均視聴時間：7 日 / トピックの持続・登録者：28 日
4. 基準（同じトピックの過去の中央値）を上回ったときだけ型に昇格させる

## 守ること
- 分析で確かめるまで「検証済み」と呼ばない
- 画面写しに無い指標（クリック率など）は「未取得」と書く

入力は、分析画面の CSV と人気順の画面写しにしました。一括収集のスクリプトは手元の環境でしか動かず、サーバー上の実行では鍵が無ければそこで止まります。取得を手順に入れてしまうと、足りない例の依頼と同じく、数字が取れないまま一般論の「法則」が返ってきます。手順の 1 の倍率が太字なのは、登録者数の違うチャンネルの視聴回数をそのまま並べても、規模の差しか見えないからです。

手順の 3 には「抽出した型はまだ仮説」と書き、読むまでの期間を数字で入れました。期間を決めずに見ると、公開翌日の数字で型を採用したり捨てたりすることになります。この期間は案件が変わっても同じなので、置き場所は依頼文ではなく手順書です。守ることの「検証済みと呼ばない」は、基準を上回ったときだけ昇格させる手順の 4 と対になっていて、外れ値から抜いた型がそのまま決まりとしてレポートに載るのを止めます。画面写しに無い指標を「未取得」と書かせるのも、足りない例で起きる「見えない数字を推定で埋める」を防ぐためです。

代理店規模の運用へ

ここまでは 1 案件 1 アカウントを前提に書きました。代理店になると、1 案件に同じ SNS のアカウントが複数あり（1 店舗 1 アカウントの案件はふつうにあります）、案件も複数になります。複数アカウントは配列で持ち、宛先を推測せず、指定が無ければ弾く。アカウントをまたいで数字を足さない（リーチはユニーク数なので二重に数える）。定点監視と定期実行は案件ごとに登録し、通知先の無いものは有効にできない。この「置き場」と「人が判断する点」の設計は、第 11 章でまとめて扱います。

章のまとめ

• 自分の数字だけでは相対評価ができない。自分の過去平均・競合・業界の当たりの 3 軸で比べる。
• 外から読めるのは公開範囲だけ。取れる／取れないを先に決め、取れないものは「未取得」か「公開データからの推定」と書く。Meta（Facebook・Instagram）と TikTok は利用規約で自動収集を禁じているので、エージェントに画面を読ませず、人が検索して記録するか、広告データを MCP で提供する商用サービスを使う。
• 採点は 100 点を 4 軸に分け、根拠を実数に紐づける。競合比較は配点に混ぜない。
• 広告の当たりは出稿額ではなく継続配信日数と重複出稿数で判定し、事実の形で書く。見た結果は構造化して蓄積する。
• インフルエンサー・トレンド・リスニングは「検知 → 判定 → 下書き → 人が決める」の同じ型。送信・投稿・返信はエージェントからは行わない。
• 定点監視の前回値は外の永続先から取り直し、初回はベースラインと宣言する。変化は期間＋実測値＋変化量で書く。
• MEO は対価付きの口コミ依頼と良い評価だけの誘導をしない。順位は測定地点・キーワード・日時とセットでしか報告しない。
• ログインが要る収集はサーバーでは通らない。環境の判定は 1 軸で行い、無いものを探しに行かせない。
• 取れなかった項目は 0 点にせず「未評価」とし、商圏でのシェアのような割合は計測できた数を分母にする。
• 店舗のサイトは、事業の形を判定してから点検する。NAP は 3 か所で突き合わせ、自店の口コミの評点を構造化データに書かない。

演習

1. 自分の領域で「外から読める公開データ」を 1 つのプラットフォームについて洗い出し、取れる／ログインで隠れる／公開されていない、の 3 列の表にしてください。取れない列に「推定」で入れていたものが無いかを確認します。
2. 競合 3 社の配信中の広告を広告ライブラリで集め、継続配信日数の降順に並べた表を作ってください。出稿額や再生数の欄を作らず、取得日を必ず添えます。
3. 口コミか競合か、どちらかの定点監視を 1 つ選び、ベースラインの数値表（面・値・取得日）を作ってください。次回、その表だけを入力に差分を出せるかを試します。
4. 自店（または依頼主）の店名・住所・電話番号を、サイトの表示・構造化データ・Google ビジネスプロフィールの 3 か所から書き出し、食い違いを表にしてください。食い違いごとに重さ（高・中）を付けます。

次の章へ

アカウントの外側を見る運用は、ここまでです。第 7 章とこの章で、SNS と地図で知ってもらうところまでを扱いました。知ってもらった人を再来店とリピートにつなげるのが LINE 公式アカウントの役割です。次の第 9 章「LINE 運用を自動化する」では、友だち・タグ・セグメント・配信の設計と、流入経路の計測、広告の成果との接続を扱います。