---
name: x-pulse
description: 発信・広告・製品の訴求軸を「推測」ではなく X 上の実測エンゲージメントで決める。KUZIRAでX検索を巡回し、どの切り口に熱量があるかを測って、訴求案・キーワード案まで出す。魚拓とノートで調査自体を資産として残す。広告出稿前、記事や投稿のテーマ決め、製品の売り方を考えるときに使う。
---

# /x-pulse — 訴求軸を実測で決める

「この言い方なら刺さるはず」は、たいてい外れます。
このスキルは **X（旧Twitter）で実際に伸びている投稿のエンゲージメント数**を測って、
どの切り口に熱があるかを事実で判断し、訴求文とターゲティング用キーワードまで出します。

> このスキルは **KUZIRA**（マーケター特化ブラウザ）が必要です。
> XはログインなしではJS描画されず、公式APIの検索は有料枠のため、
> 「ログイン済みブラウザをAIが直接読む」経路が実質的に唯一の手段になります。
> ダウンロード: https://kuzira.uni-core.jp （Windows / Mac・無料）

## 使い方

```
/x-pulse <調べたいテーマ or 製品>
/x-pulse <テーマ> --queries 7      # 調査クエリ数（既定5）
/x-pulse <テーマ> --no-archive     # 魚拓とノートを残さない（既定は残す）
```

例：
```
/x-pulse 自作のタスク管理アプリ
/x-pulse オンライン英会話の集客
/x-pulse KUZIRA（マーケター向けブラウザ）
```

## 前提：KUZIRAの接続確認

最初に必ず接続を確認してから始めること。

1. `mcp__kuzira__list_tabs` が使えるならそれを使う
2. 使えない場合は HTTP MCP を直接叩く（KUZIRA起動中なら常に開いている）

```bash
curl -s -X POST http://127.0.0.1:8377/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"list_tabs","arguments":{}}}'
```

接続できない場合は「KUZIRAを起動してください」と伝えて中断する。憶測でリサーチを続けない。

> 日本語を含むリクエストは、シェル経由だと文字化けすることがある。
> その場合は Python（`json.dumps(..., ensure_ascii=False).encode('utf-8')`）でPOSTする。

## 手順

### STEP 1: 調査クエリを設計する（AIが考える）

テーマから、**性質の違う切り口**を5つ前後つくる。似たクエリを並べても意味がない。

必ず次の4種類を混ぜること：

| 種類 | 狙い | 例（タスク管理アプリの場合） |
|---|---|---|
| 直接指名 | その物自体の話題量 | `タスク管理 アプリ` |
| **隣接コミュニティ** | 熱いのは本体より周辺のことが多い | `Notion 使い方` `Obsidian タスク` |
| 課題・悩み | 買う理由になる痛み | `タスク管理 続かない` |
| **競合・代替** | 乗り換え needs と不満 | `Todoist 乗り換え` |

**隣接コミュニティを必ず1つ以上入れること。** 今回の実例では、製品の直接領域（競合分析）より
隣接領域（Obsidian × AI）の方がエンゲージメントが50倍高く、訴求軸の判断が丸ごと変わった。

#### ⚠️ クエリ設計の落とし穴（実測で判明）

Xの検索は指定語がページ内のどこかに含まれれば拾うため、**抽象語や一般語を並べるとノイズだらけになる**。

| 悪い例 | 何が起きるか | 直し方 |
|---|---|---|
| `Lステップ 高い` | 「高い」が一般語すぎて決算記事などが混ざる | `Lステップ 料金` のように具体語にする |
| `LINE公式 配信 疲れた` | 3語が離れて含まれる無関係投稿が上位に来る | 2語までに絞る／`"..."` でフレーズ検索 |
| `AI 便利` | ほぼ全投稿がヒットして意味をなさない | 固有名詞（製品名・ツール名）を必ず1つ入れる |

**固有名詞を1つ以上含むクエリが最も信頼できる。** ノイズが多いと感じたら、
そのクエリの結果は「判断に使えない」と明記して捨てる。無理に読み取らない。

### STEP 2: KUZIRAでX検索を巡回する

裏タブ（`background: true`）で開き、ユーザーの画面を占有しない。
プロファイルは `own`（ログイン済みセッション）を使う。

```
open_tab { url: "https://x.com/search?q=<URLエンコード済み>&f=live", profile: "own", background: true }
```

- `f=live` は「最新」タブ。いま何が話されているかを見るため必須（`f` 無しだと話題順で古い投稿が混ざる）
- 2件目以降は `navigate` で同じタブを使い回す（タブを増やさない）
- 読み込み待ちに4〜5秒置いてから `read_page`

```
read_page { tabId: <id> }
```

`read_page` は本文・リンク・検出タグを構造化して返す（生HTMLより桁違いに軽い）。

### STEP 3: 熱量を測る

`read_page` の本文から、投稿ごとに次を拾って表にする。

- 投稿者名／投稿の要旨（1行）
- **エンゲージメント数**（本文末尾に並ぶ数値。表示回数・いいね等）
- 投稿日時（「◯時間前」が多いクエリ＝いま動いている話題）

**数値の読み取りは正規表現に頼らないこと（実測で判明）。**
`read_page` の本文はプレーンテキストなので、数値だけを機械抽出すると
どの投稿の数字か対応が崩れる。**「アカウント名から次のアカウント名まで」を1投稿の塊として
AI自身が読み、投稿内容と数値をセットで拾う。** 対応が曖昧な数値は使わない。

判断のしかた：

| 観察 | 意味 |
|---|---|
| 数千〜万のエンゲージが複数ある | **熱い領域**。ここに訴求を寄せる |
| 数百以下ばかり | 冷たい領域。ここを主軸にしない |
| 同じ趣旨の投稿が連日出ている | 一過性でない持続的な関心 |
| 特典配布・保存版が伸びている | **配布物（スキル・テンプレ）が刺さる層** |

### STEP 4: 逆張りの声を必ず拾う（重要）

伸びている投稿だけ見ると判断を誤る。
**「それ要らない」「使わなくなった」系の投稿**を探し、エンゲージが高ければ重く受け止める。

実例：「Obsidianユーザーだけど、そもそも情報収集のためにwebページを見なくなった」（2,104エンゲージ）
→ 「ページを見る手間が減る」という訴求は却下し、「見たものが資産になる」に変更した。

### STEP 5: 訴求案とキーワード案を出す

**必ず「その製品が実際にできること」と突き合わせる。** 熱い話題に寄せるあまり、
実装していない機能を訴求するのは誇大広告になる。次の表を必ず作る：

| Xで求められていること（実測） | 自社の実装（事実） |
|---|---|
| （観測した需要） | （できること・できないこと） |

両方が埋まる交点だけを訴求にする。埋まらないなら「今回は訴求できる強みがない」と正直に報告する。

出力：
1. 熱量マップ（クエリ別のエンゲージメント実測）
2. 推奨する訴求軸（＋却下した軸とその理由）
3. 広告文・投稿文の案（見出し／本文）
4. 広告ターゲティング用キーワード案（指名キーワード優先）

### STEP 6: 調査を資産として残す（既定でON）

**ここをやらないと、次回また同じ調査を1からやることになる。**

1. **魚拓**：判断根拠になった投稿ページを保存する
   ```
   screenshot { tabId: <id>, fullPage: true, path: "<保存先>/x-pulse_<テーマ>_<日付>.png" }
   ```
   KUZIRAの魚拓ボタン（フルページPNG＋HTML保存）を使えば、投稿が消えても根拠が残る。

2. **ノート**：調査結果を Markdown で保存する
   KUZIRAの分析ノートは **Obsidian互換の .md**。次回のリサーチや記事執筆で、
   Claude Code / Codex にそのまま前提知識として読ませられる。

   ```markdown
   # x-pulse: <テーマ>（<日付>）
   ## 熱い領域（実測）
   | クエリ | 代表投稿 | エンゲージ |
   ## 冷たい領域
   ## 逆張りの声
   ## 決定した訴求軸と理由
   ## 却下した訴求軸と理由
   ```

3. **継続監視（任意）**：伸びていたアカウントやテーマは KUZIRA の**競合ウォッチ**に登録しておくと、
   変化があったときにAIが要約して通知する。次回は差分から始められる。

## 守ること

- **公開情報の閲覧の範囲で行う。** 大量スクレイピングや高頻度アクセスはしない（クエリ数は10以内が目安）
- **数字は実測値だけを書く。** 「たぶん人気」のような推測を実測のように書かない
- 事実（観測したエンゲージメント）と意見（訴求の提案）は分けて報告する
- 他社アカウントの投稿を引用する際は、批判・揶揄をしない

## このスキルが向いていない場面

- 極端にニッチで、Xに投稿自体がほぼ無いテーマ（サンプルが取れず判断できない）
- BtoB専門領域（意思決定者がXにいない場合がある。LinkedIn等を別途見るべき）
- 緊急で今すぐ出稿したい場合（調査に10〜20分かかる）

## 実例：この手順で訴求軸が変わったケース

マーケター向けブラウザ KUZIRA の広告で実際に起きたこと。

- **当初案（推測ベース）**：「競合のLP、開くだけで丸裸」＝競合分析ツールとして訴求
- **実測**：競合分析系の投稿は最大111エンゲージ。一方、隣接領域の
  「Claude Code × Obsidian で第2の脳を育てる」は5,548・4,450・1,831と桁違い
- **変更後**：「Claude Code に Obsidian で第2の脳を育ててる人へ。その入力、まだ手でコピペしてませんか」
- キーワードも `競合分析/広告運用` → `Obsidian/Claude Code/第二の脳/NotebookLM` に変更

出稿前に気づけたので、外れる広告費を使わずに済んだ。