# MCP連携 分析AIプロンプト集【完全版】

バージョン 1.0（2026年8月）
© HAPPY ANALYTICS — 本書の組織外への配布・転売・公開は利用規約により禁止されています

---

## 📐 全体構成（商品版・確定）

### Part 1: データソース横断編
| 章 | 内容 |
|---|---|
| 第1章 | GA4基本分析（月次/施策評価/サイト内改善/週次ヘルスチェック） |
| 第2章 | GA4×Search Console連携（LP総合診断を含む） |
| 第3章 | BigQuery分析（セグメント/探索/アトリビューション） |
| 第4章 | AI流入・GEO分析 |
| 第5章 | データ品質・異常検知 |

### Part 2: 業種別編
| 章 | 内容 |
|---|---|
| 第6章 | ECサイト分析 |
| 第7章 | オウンドメディア分析 |
| 第8章 | B2Bマーケティング分析 |
| 第9章 | 店舗・O2O分析 |
| 第10章 | コーポレート・IR・PR分析 |

### 付録
| 章 | 内容 |
|---|---|
| 第11章 | 変数一覧 / トラブルシューティング / 用語ミニ辞典 / CLAUDE.md活用ガイド |

※旧「プロジェクト設定」章は同梱のCLAUDE.mdテンプレート（5種）へ移管。

> **📅 今後の無料アップデート予定**
> **Microsoft Clarity連携分析（6プロンプト・制作済み）**: ヒートマップ・セッション録画とGA4を突合する分析章です。現時点ではClarityのデータエクスポートAPIの制限（取得期間・リクエスト回数）が厳しく、日常運用に耐えないと判断したため初版から外しています。API提供状況の改善を見極めた上で、購入者への無料アップデートとして追加予定です。

## 🔧 変数一覧（購入者はまずここを置換）

本書のプロンプトは `{{変数名}}` 形式のプレースホルダーを使用しています。テキストエディタの一括置換で、以下を自社の値に置き換えてから利用してください。

| 変数 | 意味 | 記入例 |
|---|---|---|
| `{{サイトURL}}` | 分析対象サイトのURL | https://www.example.com/ |
| `{{GA4プロパティID}}` | GA4のプロパティID | 308XXXXXX |
| `{{BQデータセット}}` | BigQueryのGA4エクスポート先 | project.analytics_308XXXXXX |
| `{{主要キーイベント}}` | 最重要のキーイベント名 | purchase / form_submit |
| `{{記事ディレクトリ}}` | 記事・ブログの配下パス | /blog/ |
| `{{予約完了イベント}}` | 予約完了のイベント名 | reservation_complete |
| `{{完読イベント}}` | 記事完読のイベント名 | article_finished_reading |

CLAUDE.mdテンプレート（同梱）を設定済みの場合、多くの変数はCLAUDE.mdから自動的に補完されるため、プロンプト側の置換は最小限で済みます。

※ここには使用頻度の高い主要変数のみ掲載しています。業種別の変数を含む**完全版の変数一覧は第12章（付録）**にあります。

---

## 🚀 クイックスタート：まずこの5本から

77本を前に迷ったら、この順番で実行してください。環境の確認と成功体験を最短で得られる順序です。

| 順 | プロンプト | 目的 |
|---|---|---|
| 1 | 3-1 BigQuery接続・データ確認 | 環境が正しく繋がっているかの健康診断 |
| 2 | 2-1 SC×GA4連携確認 | 検索データの取得確認と数値のズレの理解 |
| 3 | 1-4 週次ヘルスチェック | 最も軽く、毎週の習慣になる1本 |
| 4 | 1-1 月次レポート作成 | 本商品の主力。1時間の作業が数分に |
| 5 | 5-1 Direct急増bot診断 | 自社データの「汚れ」を最初に知っておく |

この5本が動けば環境は完成です。あとは自社の業種章（第6〜10章）と、気になる課題の章から自由に使ってください。

---

## 📏 共通実行ルール（全プロンプトに適用）

**実行前**
1. 対象MCPサーバー（GA4 / Search Console / BigQuery）の接続・認証状態を確認してから分析を開始すること
2. 分析期間が指定されていない場合は「先月（前月1日〜末日）」を既定とし、実行前にユーザーへ確認すること

**BigQuery課金事故の防止（重要）**
3. クエリ実行前にスキャン量を見積もること。10GBを超える場合は実行せず、まずユーザーに確認を取ること
4. `events_*` テーブルは必ず `_TABLE_SUFFIX` で期間を限定すること（全期間スキャン禁止）
5. `events_intraday_`（当日速報値）と `events_`（確定値）を同一集計に混在させないこと

**データ解釈**
6. GA4 API経由の数値はしきい値適用・サンプリングにより管理画面と差異が出る場合がある。厳密な検証が必要な場面ではBigQueryを正とすること
7. 比較期間に計測欠損・仕様変更が含まれる場合（CLAUDE.mdの「データ品質の注意書き」参照）は、結論に必ず注記を付けること

**出力表記**
8. 表タイトルに集計期間（YYYY-MM-DD形式）を明記
9. ページはtitleタグ文字列で表記（URL・ディメンション生値は不可）
10. すべての改善提案に定量的根拠と期待効果の数値を付す

---
---

# 第1章 GA4基本分析

## 1-1. 月次レポート作成

```markdown
# GA4月次レポート作成プロンプト

## 目的
{{サイトURL}} のGA4データから、経営層・クライアント報告に使える月次レポートを作成する

## 基本設定
- **期間**: 前月 vs 前々月・前年同月
- **形式**: PowerPoint想定のMarkdown（1見出し=1スライド相当）

## 事前確認（順次質問し、回答を得てから次へ）
1. eコマース計測（purchase等）の有無
2. 複数キーイベントがある場合、使用対象（「all」or特定イベント名）

## 出力構成
### 1. エグゼクティブサマリー（300-500文字）
主要数値変化（AU/セッション/CV数/CVR）、伸長・減少したチャネル/ページ/CV種類、重要な気づき3つ

### 2. 改善施策TOP5
表: 番号|施策名|対象|実施内容|評価指標|期待効果|難易度(3段階)
全施策実施時のセッション&CV数見込み（悲観/平均/楽観の3シナリオ）

### 3. サイト評価（10項目×10点満点）
ヒートマップ表（前月/前々月/前年同月）:
AU/セッション/CV数/CVR/検索流入/エンゲージメント率/平均PV/平均訪問回数/平均滞在時間/売上
＋気づき300文字

### 4. 時系列流入推移
- 主要指標13か月推移（表）
- TOP5チャネル別セッション&CV数13か月（表）
- チャネル×LP TOP10セッション数13か月（表）
- デバイス別・都道府県別（前月vs前年同月）
- インサイト・課題・改善案

### 5. ページ閲覧
- LP TOP10（タイトル/セッション/エンゲージ率/前月比）
- 検索流入LP TOP10 / PV TOP10（表）
- SEO改善TOP5（具体的なtitle案/description案/コンテンツ追加案）
- インサイト・課題・改善案

### 6. イベント発生
TOP20（表: イベント名/回数/UU/回数÷UU）※page_viewを超える回数のイベントは除外
＋インサイト・課題・改善案

### 7. eコマース（purchase計測時のみ）
購入回数・金額の年間推移 / 1人当たり購入回数・単価 / TOP20商品 / 成長TOP10（前々月比）
＋インサイト・課題・改善案

### 8. 成功・失敗要因
良かった点3つ / 悪かった点3つ

### 9. 来月の方針
注目すべき指標、重点3施策

## ルール
- 共通実行ルールに従うこと
- 定量的根拠のある提案のみ。期待効果は数値で明記
```

## 1-2. 施策評価レポート

```markdown
# GA4施策評価レポート作成プロンプト

## 目的
実施した施策の効果を、実施前後のGA4データ比較で定量評価する（Markdown形式）

## 事前確認（順次質問し、回答を得てから次へ）
1. **施策タイプ**: a)集客 b)機能追加 c)ページ作成/改修
2. **詳細情報**:
   - a→対象流入元（例: email/campaign, facebook）
   - b→実装内容と目標指標
   - c→対象URL＋評価用イベント名（あれば）
3. **実行日**: YYYY-MM-DD形式
4. **評価期間**: 前後X日（数値入力）
5. **キーイベント**: 「all」または特定イベント名

## レポート構成
### 1. エグゼクティブサマリー（300-500字）
評価結果・気づき・次に取るべき施策

### 2. 施策別分析（該当タイプのみ）
**a) 集客施策**
- 対象流入元の6指標（流入数/エンゲージメント率/キーイベント数 等）を実施前後比較
- 他流入元との比較で「施策固有の変化」か「全体傾向」かを判定
- 気づき3行

**b) 機能追加**
- 目標指標の前後比較、キーイベントへの貢献度
- 気づき3行

**c) ページ作成/改修**
- 新規→類似ページとの比較 / 改修→前後比較
- 指標: 閲覧開始数/エンゲージ率/離脱率/滞在時間/LP時のキーイベント
- カスタムイベントデータ（あれば）、対象ページURL（リンク付き）
- 気づき3行

### 3. 最終評価
- 統計的有意差の確認（差が偶然の範囲か検定し、判断根拠を明記）
- **100点満点評価**: 変化なし50点／悪影響0点／好影響100点
  （ポジティブな指標変化とキーイベント貢献で加点）
- **改善策3つ**: 具体的かつ実行可能なもの

## ルール
- 共通実行ルールに従うこと
- 評価期間内にセール・連休など外部要因がある場合は評価に注記すること
```

## 1-3. サイト内改善分析

```markdown
# GA4サイト内改善分析プロンプト

## 目的
GA4データからサイト内のボトルネックを特定し、CVR改善の打ち手を提案する（Markdown形式）

## 事前確認（順次質問し、回答を得てから次へ）
1. **分析範囲**: サイト内施策・サイト外（集客）施策・両方のどれを提案するか
2. **データ期間**: YYYY-MM-DD形式
3. **キーイベント**: 「all」または特定イベント名
4. 事前に伝えておきたい条件や制約（なければ「なし」）

## レポート構成
### 1. エグゼクティブサマリー（300-500文字）

### 2. コンバージョン経路分析
- 全体パフォーマンス（セッション、CV、CVR等）
- デバイス別・流入元別・LP別の詳細分析（CVR差に着目）
- 推定されるサイト内行動パターン
- カスタムイベントの発生状況に基づくCV貢献
- カスタマージャーニー上のボトルネック箇所の特定

### 3. 改善提案（4-5施策）
優先基準: 低コスト・低工数 ＞ 技術難易度が低い ＞ インパクト大 ＞ 静的ページ優先
各施策に含める: 現状課題（定量根拠）/ 具体的改善案（UI例含む）/ 新規コンテンツ案（title・description・キーワード）/ 期待効果（数値目標）

### 4. 期待効果
施策別KPI・目標値の表 / 統合効果（重複考慮後のCVR改善見込み）/ 実施ロードマップ / ROI試算

## ルール
- 共通実行ルールに従うこと
- CLAUDE.mdの「実施不可能な施策」に該当する提案は行わないこと
```

## 1-4. 週次ヘルスチェック 【新規】

```markdown
# GA4週次ヘルスチェックプロンプト

## 目的
毎週1回の定例実行で、サイトの健康状態を3分で把握できる軽量レポートを作成する

## 基本設定
- **期間**: 先週（月〜日）vs 前週
- **形式**: チャットで読み切れる短文レポート（ファイル生成しない）

## 出力構成
### 1. 今週のステータス（1行）
「🟢 正常 / 🟡 要注意 / 🔴 要対応」のいずれか＋理由を1文で

### 2. 主要5指標の前週比（表1つ）
セッション / {{主要キーイベント}}数 / CVR / 検索流入 / エンゲージメント率

### 3. アラート照合
CLAUDE.mdの「アラート条件」と照合し、該当があれば挙げる。なければ「該当なし」と明記

### 4. 変動の要因（該当時のみ）
±15%以上変動した指標について、チャネル別・LP別に要因を1段階だけ深掘り

### 5. 来週見るべきポイント（1〜2個）

## ルール
- 共通実行ルールに従うこと
- 全体で600文字以内。深掘り分析は行わず、必要なら「1-3 サイト内改善分析の実行を推奨」と案内する
- 直近データは反映遅延の可能性があるため、日曜までのデータが揃っているか冒頭で確認する
```

---
---

# 第2章 GA4×Search Console連携

Search Consoleは「サイトに来る前（検索結果上）」を、GA4は「来た後（サイト内）」を計測します。本章は両者をランディングページやクエリで突合し、単体では見えない「検索意図とコンテンツのズレ」「流入の質」を可視化するプロンプト群です。

## 2-1. 連携確認

```markdown
# SC×GA4連携確認プロンプト

## 目的
{{サイトURL}} のSearch ConsoleとGA4のデータ取得を確認し、連携分析の準備を整える

## 実行手順
1. SC: プロパティへの接続確認と、直近28日のクリック数・表示回数・CTR・平均順位のサンプル取得
2. GA4: プロパティへの接続確認と、同期間のOrganic Searchセッション数の取得
3. 両者の突合可否確認: SCのクリック数とGA4のGoogle自然検索セッション数を比較

## 出力構成
1. 取得可否の確認結果（SC / GA4）
2. 主要指標のサンプル値（表）
3. SCクリック数とGA4検索セッション数の差異と、その理由の説明
   （計測方式の違い・(not provided)・ブラウザ設定等による正常な乖離範囲か）
4. 以降の分析で使う期間・対象の前提と制約

## ルール
- 乖離が±30%を超える場合は、SCプロパティの対象範囲（ドメイン/URLプレフィックス）とGA4の計測範囲のズレを疑い、指摘する
- SCデータは直近2〜3日が未確定な点を注記する
```

## 2-2. LP×キーワードの掛け合わせ分析

```markdown
# LP×キーワード掛け合わせプロンプト

## 目的
どのページが・どんな検索語で集客できているかの全体像を把握する

## 実行手順
1. SC: 直近1ヶ月の流入上位10ランディングページを取得
2. SC: 各LPについてクリック数上位5キーワードを取得
3. 各LP×キーワードの組み合わせで、クリック数・表示回数・CTR・平均順位を整理

## 出力構成
1. LP別サマリー表（LP / クリック / 表示 / CTR / 平均順位）
2. LPごとの上位キーワード表（LP単位で区切る）
3. 気づき: 想定外のキーワードで集客しているLP、1つのキーワードに依存しているLP
4. ブランドワード（{{ブランド名}} を含む語）と非ブランドの割合

## ルール
- ページはtitleタグ文字列＋URLを併記
- クリック1桁のロングテールは「その他」に集約し、表を肥大化させない
```

## 2-3. キーワード順位の変化分析

```markdown
# キーワード順位変化プロンプト

## 目的
前月と当月のキーワード順位を比較し、上昇・下落の傾向とその要因を把握する

## 実行手順
1. SC: 前月・当月それぞれの主要キーワード（表示回数上位100）の平均順位を取得
2. 順位帯別分布（1位 / 2-3位 / 4-10位 / 11-20位 / 21位以下）を両月で作成
3. 順位変動の大きいキーワードを抽出

## 出力構成
1. 順位帯別分布の比較表（前月 vs 当月、各帯のキーワード数と流入数）
2. 上昇TOP10 / 下落TOP10（表: キーワード / 順位変化 / クリック変化 / 対象LP）
3. 変動の傾向分析（特定LPに集中しているか、サイト全体か、特定トピックか）
4. 下落キーワードへの対応優先度（流入インパクトの大きい順）

## ルール
- Googleコアアップデート等の時期と重なる場合はその可能性を注記する
- 表示回数が少ないキーワード（月間50未満）の順位変動はノイズとして扱う
```

## 2-4. 低CTRキーワードの改善案

```markdown
# キーワードCTR改善プロンプト

## 目的
「表示されているのにクリックされていない」キーワードを特定し、タイトル・description改善案を作成する

## 実行手順
1. SC: 先月の表示回数上位50キーワードから、順位の割にCTRが低いものを5つ抽出
   （目安: 掲載順位ごとの期待CTRを大きく下回るもの）
2. 各キーワードを実際にGoogleで検索し、上位3サイトのタイトル・description・コンテンツ構成を確認
3. 自サイトの該当LPと比較し、クリックされない要因を分析

## 出力構成
1. 対象5キーワードの現状表（表示回数 / クリック / CTR / 順位 / 対象LP）
2. キーワードごとの競合比較と、クリックされない要因の仮説
3. 具体的な改善案: 新title案（文字数考慮）/ 新description案 / 必要なコンテンツ追加
4. 期待効果: CTRが期待値まで改善した場合の流入増加数

## ルール
- title案は検索意図を反映し、キーワードを不自然に詰め込まない
- 改修後は2-3（順位変化）で2〜4週間後に効果検証することを案内する
```

## 2-5. キーワードのCV貢献可視化

```markdown
# キーワード別CV貢献プロンプト

## 目的
どの検索キーワードがコンバージョンに貢献しているかを推定し、SEO投資の優先順位を決める

## 実行手順
1. SC: 直近1ヶ月のクリック数上位50キーワードとそのLPを取得
2. GA4: 各LPの検索流入セッションのCVR（{{主要キーイベント}}）を取得
3. 推定CV算出: キーワードのクリック数 × 対象LPの検索流入CVR を基準に、
   キーワード特性（ブランド/固有名詞/情報収集系/購入意向系）と掲載順位・CTRで重み付け

## 出力構成
1. キーワード別推定CV貢献ランキング（表: キーワード / クリック / LP / LPのCVR / 推定CV）
2. 算出ロジックと重み付けの根拠の明示
3. 4分類: 貢献大×順位良（維持）/ 貢献大×順位改善余地（最優先）/ 貢献小×流入大（コンテンツ改善）/ その他
4. 最優先キーワード3つの具体的な順位改善アクション

## ルール
- あくまで推定値であることを明記し、精緻な計測にはLP別CVRの実測を正とする
- ブランドワードは別枠で集計する（SEO施策の対象外のため）
```

## 2-6. LPのCV貢献可視化（4象限分析）

```markdown
# LP別CV貢献4象限プロンプト

## 目的
検索流入LPを「流入量×CV率」の4象限で分類し、ページ単位の投資優先度を決める

## 実行手順
1. SC: 直近1ヶ月のTOP50ページの表示回数・クリック数・CTR・平均順位を取得
2. GA4: 同ページの検索流入セッション数・CV数・CVR・収益（EC時）を取得
3. 評価指標の算出: 貢献度＝流入数×CVR / 質スコア＝CTR×CVR
4. 流入数とCVRそれぞれの中央値で4象限に分類

## 出力構成
1. 4象限マップの説明と各象限のページ数
   - A: 流入多×CV高 → 強化・維持
   - B: 流入多×CV低 → ページ内改善
   - C: 流入少×CV高 → 流入増（順位改善）
   - D: 流入少×CV低 → 低優先
2. 各象限のTOP5ページ（表）
3. B象限・C象限それぞれの具体的改善案（Bはページ内導線/CTA、Cはtitle/コンテンツ強化）
4. 改善による全体CVインパクトの試算

## ルール
- 検索流入が月10セッション未満のページは分類対象から除外する
- B象限の改善は2-8（LP改善総合診断）との併用を案内する
```

## 2-7. コンテンツミスマッチ分析

```markdown
# 検索意図ミスマッチ検出プロンプト

## 目的
「クリックはされるが、期待に応えられていない」ページを検出し、検索意図とのズレを解消する

## 実行手順
1. SC: CTR 5%以上のページTOP30を抽出（各ページの主要クエリ上位3と順位を含む）
2. GA4: 同ページの平均滞在時間・エンゲージメント率・PV/セッション・CVを取得
3. ミスマッチ判定:
   - CTR高 × 滞在極短 → タイトルと内容の乖離（タイトル詐欺型）
   - CTR高 × 直帰・即離脱高 → 検索意図との不一致
   - 順位良 × エンゲージメント低 → コンテンツ品質の問題
4. 深刻度スコア（流入規模×乖離度）で優先順位付け

## 出力構成
1. 判定結果一覧（表: ページ / 主要クエリ / CTR / 滞在 / 判定タイプ / 深刻度）
2. 深刻度TOP10の詳細: 検索意図の推定 / 現コンテンツとのギャップ / 改善案（構成・情報追加・CTA）
3. 改善ロードマップ（今週やるもの / 今月やるもの）

## ルール
- 判定前に、ページの性質（辞書型コンテンツは滞在が短くて正常等）を考慮する
- 深刻度上位はGoogleで該当クエリを実際に検索し、検索結果の傾向を確認してから改善案を出す
```

## 2-8. LP改善総合診断（GA4×SC統合）

```markdown
# LP改善総合診断プロンプト

## 目的
1つのLPについて、集客（SC）→流入・ページ内行動（GA4）を一気通貫で診断し、改善案をまとめる

## 事前確認
1. 診断対象LP（URL、1ページ。未指定なら先月の検索流入上位LPから提案）
2. このLPに期待する役割（例: {{主要キーイベント}}の起点 / 検索流入の受け皿）

## 実行手順
1. SC: 対象LPの流入クエリTOP10・表示回数・CTR・平均順位（直近28日）
2. GA4: 流入元別セッション / エンゲージメント率 / 平均エンゲージメント時間 /
   離脱率 / キーイベント率（先月）
3. GA4: ページ内の行動イベント（スクロール90%到達または{{完読イベント}}、
   リンク・CTAクリック等の計測があれば）を取得
4. 統合: 「集客の質 → 期待値との一致 → ページ内の関与 → CV到達」の4段階で診断

## 出力構成
1. 診断サマリー（このLPの最大のボトルネックは4段階のどこか）
2. 段階別の評価と根拠データ（表）
3. 改善案5つ（優先度・工数・期待効果付き）
4. 改善後の検証プラン（見るべき指標と期間）

## ルール
- 検索意図とコンテンツのズレが疑われる場合は、実際に該当クエリで検索し上位3サイトと比較する
- ページ内行動の詳細（スクロールの崖の位置・クリック位置）はGA4では粗くしか分からない
  限界を明記する。行動計測イベントが未実装の場合は「関与」段階の評価を保留とする
- SCとGA4でデータ期間が異なる点を明記し、結論への影響を注記する
```

---
---

# 第3章 BigQuery分析

GA4のエクスポートデータをBigQueryで直接分析することで、GA4画面の制約（しきい値・サンプリング・保持期間・カーディナリティ）を超えた精緻な分析が可能になります。本章のプロンプトはGA4の「探索レポート」で作れる分析をBQで再現・拡張するものです。

> **⚠️ BigQuery利用時の共通注意（必読）**
> - すべてのクエリで `_TABLE_SUFFIX BETWEEN 'YYYYMMDD' AND 'YYYYMMDD'` による期間限定を必須とします
> - 実行前にスキャン量を見積もり、10GBを超える場合はユーザー確認を取ります
> - セッション数は `event_name = 'session_start'` ではなく `user_pseudo_id × ga_session_id` のユニーク数で数えます（再入場や計測仕様による欠落を避けるため）
> - GA4画面の数値とは推定・しきい値の影響で差が出ます。BQを正とします

## 3-1. 接続・データ確認

```markdown
# BigQuery接続・データ確認プロンプト

## 目的
{{BQデータセット}} への接続と、分析に使えるデータの範囲・品質を確認する

## 実行手順
1. データセット内のテーブル一覧を取得し、events_ テーブルの存在する日付範囲を確認
2. 直近の確定日1日分で、総イベント数・主要イベント（page_view, session_start, {{主要キーイベント}}）の件数を取得
3. スキーマ確認: カスタムディメンション・カスタムイベントの格納状況

## 出力構成
1. 利用可能なデータ期間（開始日〜最新確定日）
2. events_intraday の有無（当日速報データが使えるか）
3. 主要イベントの1日あたり件数（GA4画面との照合用）
4. 分析に使えるカスタムイベント・パラメータの一覧
5. 注意点（欠損日、極端に件数が少ない日があれば列挙）

## ルール
- このプロンプトは初回セットアップ時と、月次分析の開始前に実行することを推奨
- 欠損日が見つかった場合はCLAUDE.mdの「データ品質の注意書き」への追記を促す
```

## 3-2. セグメント分析（セッションスコープ）

```markdown
# セッションセグメント分析プロンプト

## 目的
「コンバージョンしたセッション」をセグメントとして作成し、規模を把握する

## 事前確認
1. 分析期間（YYYY-MM形式。未指定なら先月）
2. CVとみなすイベント名（未指定なら {{主要キーイベント}}）

## 実行手順
1. 期間内に対象イベントが発生したセッション（user_pseudo_id × ga_session_id）を抽出
2. 該当セッションのユーザー数・セッション数・表示回数（page_view数）を集計
3. 全体に対する割合を算出

## 出力構成
1. セグメント該当: ユーザー数 / セッション数 / 表示回数（表）
2. サイト全体との比較（該当セッションの割合、1セッションあたりPVの差）
3. 気づき（CVセッションは平均何ページ見ているか等）

## ルール
- BQ共通注意に従うこと
- セッションの定義（user_pseudo_id × ga_session_id）を結果に明記する
```

## 3-3. セグメント分析（ユーザースコープ）

```markdown
# ユーザーセグメント分析プロンプト

## 目的
「コンバージョンしたユーザー」をセグメントとして作成し、その全行動を把握する

## 事前確認
1. 分析期間（YYYY-MM形式。未指定なら先月）
2. CVとみなすイベント名（未指定なら {{主要キーイベント}}）

## 実行手順
1. 期間内に対象イベントを1回以上発生させたユーザー（user_pseudo_id）を抽出
2. 該当ユーザーの期間内すべての行動（CVしていないセッションも含む）を対象に、
   ユーザー数・セッション数・表示回数を集計

## 出力構成
1. セグメント該当: ユーザー数 / セッション数 / 表示回数（表）
2. セッションスコープ（3-2）との差の説明
   （CVユーザーはCVしなかった訪問も含めて平均何回来ているか）
3. 気づき（CVまでに必要な訪問回数の示唆）

## ルール
- BQ共通注意に従うこと
- user_pseudo_idはブラウザ・デバイス単位であり「人」と完全一致しない点を注記する
```

## 3-4. 経路セグメント分析

```markdown
# 経路セグメント分析プロンプト

## 目的
特定の行動ステップを順に踏んだユーザーを抽出する（GA4探索のシーケンスセグメント相当）

## 事前確認
1. 分析期間（YYYY-MM形式。未指定なら先月）
2. ステップ定義（未指定なら以下の既定を使用）
   - STEP1: session_start 発生
   - STEP2: 2ページ以上閲覧
   - STEP3: {{完読イベント}} 発生

## 実行手順
1. 各ステップをイベントの発生順序（event_timestamp）を保って判定
2. STEP1→2→3を同一セッション内でこの順に満たしたユーザーを抽出
3. 各ステップの通過人数と通過率を算出

## 出力構成
1. ステップ別ファネル（表: STEP / 該当ユーザー数 / 前ステップからの通過率）
2. 最終ステップ到達ユーザー数
3. 最大の離脱ステップとその改善示唆

## ルール
- BQ共通注意に従うこと
- 「同一セッション内」か「期間内の順序」かの判定条件を結果に明記する（既定は同一セッション内）
```

## 3-5. 経路セグメントの閲覧ページ分析

```markdown
# 経路セグメント×閲覧ページプロンプト

## 目的
特定の行動経路を辿ったユーザーが「他に何を見ているか」を把握し、コンテンツ戦略に活かす

## 事前確認
1. 分析期間・ステップ定義（3-4と同じ。3-4実行済みならその条件を引き継ぐ）

## 実行手順
1. 3-4の条件で対象ユーザーを抽出
2. 該当ユーザーの期間内の全page_viewを集計し、閲覧ページTOP10を作成

## 出力構成
1. 閲覧ページTOP10（表: ページタイトル / 閲覧ユーザー数 / PV）
2. サイト全体の人気ページとの比較（このセグメント特有によく見られるページはどれか）
3. コンテンツ示唆（完読ユーザーが次に求めているものは何か）

## ルール
- BQ共通注意に従うこと
- ページはpage_titleで表示し、同一タイトルの別URLがある場合は統合前に指摘する
```

## 3-6. 探索: 地域別分析（地図表示）

```markdown
# 都道府県別分析プロンプト

## 目的
都道府県別の訪問状況を集計し、地図上のヒートマップで可視化する

## 事前確認
1. 分析期間（YYYY-MM形式。未指定なら先月）
2. 集計指標（未指定ならセッション数。CV数・CVRも指定可）

## 実行手順
1. BQ: geo.region から日本の都道府県別に指標を集計
2. 都道府県名を日本語に整理（Tokyo→東京都 等）
3. 日本地図のヒートマップ＋実数値の表として可視化

## 出力構成
1. 都道府県別ヒートマップ（日本地図）
2. 全都道府県の実数値表（降順）
3. 人口比で見た強い/弱い地域の気づき

## ルール
- BQ共通注意に従うこと
- region不明（not set）の割合を明記する
```

## 3-7. 探索: ファネルデータ探索

```markdown
# ページ遷移ファネルプロンプト

## 目的
指定した複数ページの遷移をファネル形式で可視化し、離脱地点を特定する

## 事前確認
1. ファネルのステップとなるURL（2〜5ページ、遷移順に）
   例: {{サイトURL}} → {{サイトURL}}category/ → {{サイトURL}}category/detail/
2. 分析期間（未指定なら直近1ヶ月）

## 実行手順
1. 各URLのpage_viewを、同一セッション内で指定順に踏んだかを判定
2. ステップ別の到達セッション数と通過率を算出
3. ファネル図として可視化

## 出力構成
1. ファネル図（ステップ / 到達数 / 通過率 / 離脱率）
2. 最大離脱ステップの特定
3. 離脱したセッションが代わりにどこへ行ったか（離脱後の遷移先TOP5）
4. 改善示唆

## ルール
- BQ共通注意に従うこと
- 「直接遷移のみ」か「間に他ページを挟んでも可」かの判定条件を明記（既定は挟んでも可）
```

## 3-8. 探索: 経路データ探索（遷移先/遷移元）

```markdown
# ページ遷移経路プロンプト

## 目的
指定ページの「次に見たページ」または「1つ前に見たページ」のTOP10を把握する

## 事前確認
1. 対象ページのURL
2. 方向: 遷移先（次に見たページ）/ 遷移元（1つ前のページ）/ 両方
3. 分析期間（未指定なら直近1ヶ月）

## 実行手順
1. セッション内のpage_viewをevent_timestamp順に並べる
2. 対象ページの直後（または直前）のページを集計
3. ページタイトルでTOP10を作成

## 出力構成
1. 遷移TOP10（表: ページタイトル / 遷移数 / 割合）
2. 「離脱（次のページなし）」の割合
3. 気づき: 設計者の意図した導線と実際の遷移のギャップ

## ルール
- BQ共通注意に従うこと
- リロード（同一ページ→同一ページ）は除外する
```

## 3-9. 探索: セグメント重複分析

```markdown
# セグメント重複（ベン図）プロンプト

## 目的
3つのセグメントのユーザー重複を可視化し、重なりの大きさから施策対象を定める

## 事前確認
1. 3つのセグメント定義（未指定なら以下の既定）
   - A: モバイルデバイス
   - B: 自然検索流入
   - C: トップページ閲覧
2. 分析期間（未指定なら直近1ヶ月）

## 実行手順
1. 各セグメントの該当ユーザー（user_pseudo_id）を抽出
2. 単独・2重複・3重複の各領域のユーザー数を算出
3. ベン図として可視化

## 出力構成
1. ベン図（7領域すべてに実数値）
2. 各セグメントの単独数と重複率の表
3. 気づき: 最大の重複領域が示すユーザー像と、そこへの施策案

## ルール
- BQ共通注意に従うこと
- セグメント定義（判定条件）を結果に明記する
```

## 3-10. 探索: コホート分析

```markdown
# コホート分析プロンプト

## 目的
新規訪問ユーザーがその後どれだけ再訪しているかを週次コホートで可視化する

## 事前確認
1. 分析期間（YYYY-MM形式。未指定なら先月）
2. コホート条件（既定: サイトへの新規訪問）/ リピート条件（既定: サイトへの再訪）

## 実行手順
1. 期間内の新規ユーザー（first_visit）を訪問週ごとにコホート化
2. 各コホートの翌週以降の再訪ユーザー数を週次で集計
3. 実数と、各コホートの初週を100%とした再訪率の2表を作成

## 出力構成
1. コホート表（実数）
2. コホート表（再訪率%、ヒートマップ形式）
3. 気づき: 再訪率の高いコホートの獲得週に何があったか（流入元・コンテンツとの関連）

## ルール
- BQ共通注意に従うこと
- 週の定義（月曜始まり等）を明記する
```

## 3-11. 探索: ユーザーエクスプローラー

```markdown
# 個別ユーザー行動ログプロンプト

## 目的
条件に合致する1ユーザーの行動ログを時系列で復元し、実際のジャーニーを目視理解する

## 事前確認
1. 抽出条件（未指定なら「直近1ヶ月でCVを2回達成したユーザーから1人」）

## 実行手順
1. 条件に合致するユーザーを抽出し、代表1人を選定（選定理由を明示）
2. 該当ユーザーの全イベントをevent_timestamp順に取得
3. 1行1イベントの時系列ログに整形（page_viewは閲覧ページタイトルを表示）

## 出力構成
1. ユーザープロファイル（初回流入日・流入元・デバイス・訪問回数・CV回数）
2. 時系列ログ（日時 / イベント / 詳細）※セッションの切れ目を明示
3. ジャーニーの解釈: このユーザーがCVに至った転機はどこか

## ルール
- BQ共通注意に従うこと
- user_pseudo_idはマスクして表示する（個人特定への配慮）
- ログが数百行を超える場合は主要イベントに絞り、その旨を明記する
```

## 3-12. 探索: ライフタイムバリュー

```markdown
# 流入元別LTVプロンプト

## 目的
初回流入元ごとのユーザーの生涯価値を比較し、獲得チャネルの質を評価する

## 事前確認
1. 分析期間（未指定なら直近1ヶ月に初回訪問したユーザー）
2. 価値の定義（未指定なら {{主要キーイベント}} 発生人数と売上）

## 実行手順
1. 期間内の新規ユーザーを初回流入のデフォルトチャネルグループで分類
2. チャネル別に集計: 新規ユーザー数 / 平均セッション数 / 平均滞在時間 / CVイベント発生人数 / 売上
3. ユーザー1人あたり価値でランキング

## 出力構成
1. チャネル別LTV表
2. 「量のチャネル」と「質のチャネル」の分類
3. 獲得投資の再配分示唆

## ルール
- BQ共通注意に従うこと
- 観測期間が短いほどLTVは過小評価される点を注記する
```

## 3-13. アトリビューション: モデル比較

```markdown
# アトリビューションモデル比較プロンプト

## 目的
CVに対する各流入元の貢献を複数モデルで比較し、ラストクリック評価の偏りを補正する

## 事前確認
1. CVイベント（未指定なら {{主要キーイベント}} 実行ユーザー数）
2. 分析期間（未指定なら直近1ヶ月）

## 実行手順
1. CVユーザーの全流入履歴（デフォルトチャネルグループ）を時系列で取得
2. 3モデルで貢献を配分:
   - ファーストクリック: 初回流入元に100%
   - ラストクリック: CV時の流入元に100%
   - 線形: 流入回数で均等割り（例: 検索→Direct→CVなら各0.5）
3. モデル別のチャネル貢献度を比較

## 出力構成
1. モデル別チャネル貢献表（3モデル並列）
2. モデル間で評価が大きく変わるチャネルの特定
   （ファースト>ラスト → 認知起点型 / ラスト>ファースト → 刈り取り型）
3. 予算・施策配分への示唆

## ルール
- BQ共通注意に従うこと
- Direct流入の解釈（参照元不明を含む）に注意を促す
```

## 3-14. アトリビューション: 再訪の流入分析

```markdown
# 再訪流入分析プロンプト

## 目的
初回流入から2回目訪問までの時間と流入元の関係を把握し、再訪を生むチャネルを特定する

## 実行手順
1. 直近1ヶ月に初回訪問し、2回目訪問があったユーザーを抽出
2. 初回→2回目の経過時間分布をヒストグラム化
3. 初回流入元別に、再訪率・経過時間の平均値/中央値を算出

## 出力構成
1. 経過時間ヒストグラム（時間帯ビン: 24時間以内 / 1-3日 / 4-7日 / 8日以降 等）
2. 初回流入元別の再訪率と経過時間（表: 流入元 / 再訪率 / 平均 / 中央値）
3. 気づき: 再訪に繋がりやすい初回流入元と、再訪喚起施策のタイミング示唆

## ルール
- BQ共通注意に従うこと
- 観測期間の打ち切り（期間末の初回訪問は再訪機会が短い）による偏りを注記する
```

## 3-15. アトリビューション: 再訪LPの組み合わせ分析

```markdown
# 初回LP×再訪LP分析プロンプト

## 目的
初回に見たページと2回目に見たページの組み合わせから、再訪を生むコンテンツ連鎖を特定する

## 実行手順
1. 直近1ヶ月で2回以上訪問したユーザーを抽出
2. 初回流入ページ（ページタイトル）× 2回目流入ページ（ページタイトル）の組み合わせでユーザー数を集計
3. 組み合わせ上位を抽出

## 出力構成
1. 組み合わせTOP20（表: 初回LP / 2回目LP / ユーザー数）
2. パターン分類: 同一ページ再訪（ブックマーク型）/ 関連ページ回遊（学習型）/ CV系ページへ移行（検討進行型）
3. コンテンツ施策示唆: 初回LPに置くべき「次の一手」への導線

## ルール
- BQ共通注意に従うこと
- ページタイトルが変更された期間をまたぐ場合は同一URL判定に切り替える
```

---

---
---

# 第4章 AI流入・GEO分析 【新設】

ChatGPT・Perplexity・Gemini・Claude等のAIサービス経由の流入は、2025年以降急速に存在感を増しています。本章では「AIからの流入をどう計測・評価するか」と「AIに引用されるサイトになるにはどうするか（GEO: Generative Engine Optimization）」の両面を扱います。

> **📌 前提知識: AI関連トラフィックの3分類**
> 1. **学習用クローラー**（GPTBot, ClaudeBot, Google-Extended等）: AIモデルの学習用にサイトを収集。JavaScriptを実行しないため**GA4には一切記録されません**
> 2. **AI検索クローラー**（OAI-SearchBot, PerplexityBot等）: AI検索の索引作成用。これもGA4には映りません
> 3. **ユーザー起点の流入**: AIの回答内リンクを人間がクリックした訪問。これは**GA4にリファラルとして記録されます**
>
> つまりGA4で見えるのは3番のみです。1・2の把握にはサーバーログやCDNログが必要になります（4-4参照）。この構造を理解していないと「AIからのアクセスは無い」と誤認します。

## 4-1. AI経由流入の現状把握

```markdown
# AI流入把握プロンプト

## 目的
AIサービス経由の流入がどの程度あるかを把握し、継続モニタリングの基準値を作る

## 実行手順
1. GA4: 参照元（session_source）に以下を含むセッションを抽出（直近3ヶ月・月別）
   chatgpt.com / chat.openai.com / perplexity.ai / gemini.google.com /
   claude.ai / copilot.microsoft.com / その他AI系と思われる参照元
2. 月別推移と、全セッションに占める割合を算出
3. 検出されなかった参照元も「観測ゼロ」として明示

## 出力構成
1. AIサービス別セッション数の月別推移（表）
2. 全流入に占めるAI経由の割合と伸び率
3. 最も多いAIサービスと、その流入が始まった時期
4. モニタリング推奨: この結果を基準値としてCLAUDE.mdに記録

## ルール
- 参照元のドメイン表記はサービス側の仕様変更で変わるため、部分一致で広めに拾い、内訳を明示する
- 割合が小さくても「伸び率」を重視して評価する（絶対数より変化がシグナル）
```

## 4-2. AI流入の質評価

```markdown
# AI流入の質評価プロンプト

## 目的
AI経由の訪問者が「質の高いユーザー」かを、既存チャネルとの比較で評価する

## 実行手順
1. GA4: AI経由セッション（4-1の定義）と、Organic Search・Direct・全体平均について
   以下を比較（直近3ヶ月）
   - エンゲージメント率 / 平均セッション時間 / PV per session
   - 新規ユーザー率 / {{主要キーイベント}}のCVR
2. AIサービス別の差も算出（ChatGPT経由とPerplexity経由で質が違うか）

## 出力構成
1. チャネル比較表（AI経由 vs Organic vs Direct vs 全体）
2. AIサービス別の質の比較（データ量が十分な場合のみ）
3. 解釈: AI経由ユーザーの特性仮説
   （AIの回答で事前に要約を得てから来るため、目的が明確な傾向がある等）
4. 対応方針: AI流入の受け皿ページで整えるべき要素

## ルール
- セッション数が月100未満の場合、CVRの比較は統計的に不安定である旨を必ず注記する
- 「質が高い/低い」の断定ではなく、既存チャネルとの相対評価として提示する
```

## 4-3. AI流入ランディングページ分析

```markdown
# AI流入LP分析プロンプト

## 目的
AIがどのページを引用・案内しているかを特定し、引用されるコンテンツの共通点を見つける

## 実行手順
1. GA4: AI経由セッションのランディングページTOP20を取得（直近3ヶ月）
2. 各LPの通常検索流入・全体流入と比較し、「AI経由比率が特に高いページ」を特定
3. 上位ページのコンテンツ特性を分析
   （形式: 定義解説型/手順型/一覧型/FAQ型、構造: 見出し階層・表・箇条書きの使い方）

## 出力構成
1. AI流入LP TOP20（表: ページ / AI経由セッション / AI経由比率）
2. AI経由比率の高いページの共通点分析
3. 「AIに引用されやすいコンテンツ」の自サイトなりの仮説
4. 横展開案: 同じ型を適用できる既存ページ3つ

## ルール
- AIの回答は事実ベースの明確な記述を引用しやすい傾向を踏まえて分析する
- 仮説はあくまで自サイトデータからの帰納であることを明記する
```

## 4-4. AIクローラーアクセス分析（GA4の盲点を埋める）

```markdown
# AIクローラー分析プロンプト

## 目的
GA4には映らないAIクローラー（学習用・AI検索用）のアクセス状況を、サーバーログ等から把握する

## 事前確認
1. 利用可能なログの確認: サーバーアクセスログ / CDNログ（Cloudflare等）/
   ホスティングのアクセス統計 のいずれが提供可能か
   → いずれも無い場合: 取得方法の案内のみ行い、分析は行わない

## 実行手順（ログ提供時）
1. User-Agentから主要AIボットを分類:
   - 学習用: GPTBot / ClaudeBot / Google-Extended / meta-externalagent 等
   - AI検索用: OAI-SearchBot / PerplexityBot / Claude-SearchBot 等
   - ユーザー起点フェッチ: ChatGPT-User / Perplexity-User 等
2. ボット種別×クロール先ページの集計
3. robots.txtの現在の許可/拒否設定と突合

## 出力構成
1. ボット種別のアクセス量（表: ボット名 / 分類 / リクエスト数 / 主なクロール先）
2. よくクロールされるページTOP10と、4-3のAI流入LPとの一致度
3. robots.txt設定の現状評価と方針の論点整理
   （学習利用を許可するか、AI検索の索引は許可するか — 判断は経営方針に依存するため選択肢を提示）
4. ユーザー起点フェッチの量（AI回答内で自サイトが参照されている強度の代理指標）

## ルール
- 学習許可/拒否の判断は正解のない経営判断であるため、メリット・デメリットを両論併記する
- ボットのUser-Agentは偽装可能である点を注記し、IPレンジ検証（公式公表値）の方法を案内する
```

## 4-5. AI検索時代の流入トレンドモニタリング

```markdown
# 検索流入トレンド監視プロンプト

## 目的
AI検索の普及による「表示はされるがクリックされない（ゼロクリック）」の影響を定点観測する

## 実行手順
1. SC: 直近12ヶ月の月別 表示回数・クリック数・CTRの推移を取得
2. GA4: 同期間のOrganic SearchセッションとAI経由セッション（4-1定義）の推移を取得
3. 分析:
   - 表示回数が維持/増加しているのにクリックが減少していないか（ゼロクリック化のシグナル）
   - Organic減少とAI経由増加に相関があるか
   - 影響を最も受けているクエリ群（情報収集系 vs 指名系）の特定

## 出力構成
1. 12ヶ月トレンドグラフ（表示回数 / クリック / CTR / Organicセッション / AI経由セッション）
2. ゼロクリック化の影響評価（影響大のクエリタイプとページ群）
3. 対応方針の整理:
   - 影響を受けやすい「浅い情報」ページ → AIに代替されない深さ・一次情報への転換
   - 指名・比較検討系 → 従来SEOを維持
4. 四半期ごとの再実行を推奨（結果をCLAUDE.mdの学習ログへ）

## ルール
- CTR低下の要因はAI以外（検索結果のレイアウト変更・順位変動）もあるため、多面的に検証する
- 悲観・楽観に寄らず、自サイトの実データで語る
```

## 4-6. GEO対策診断（AIに引用されるサイトへ）

```markdown
# GEO診断プロンプト

## 目的
自サイトが生成AIに引用・推薦されやすい状態かを診断し、改善アクションを提示する

## 事前確認
1. 診断対象: サイト全体の方針診断か、特定ページの個別診断か

## 実行手順
1. 技術面の確認:
   - llms.txt の設置有無（{{サイトURL}}llms.txt をフェッチ）
   - 構造化データ（FAQ / HowTo / Article等）の実装状況
   - robots.txtのAIボット設定（4-4と連携）
2. コンテンツ面の診断（対象ページをフェッチして評価）:
   - 冒頭に結論・定義があるか（AIが引用しやすい構造）
   - 見出しが質問形式・トピック明示型か
   - 一次情報・独自データ・具体的数値の含有度
   - 更新日の明示と情報の鮮度
3. 実態確認: 主要な想定質問を挙げ、AI検索で自サイトが引用されるかの確認手順を提示

## 出力構成
1. GEO診断スコアカード（技術面/コンテンツ面の項目別評価）
2. 優先改善アクション5つ（工数と期待効果付き）
3. 「AIに引用される価値」と「AIに要約され訪問を失うリスク」のバランス整理
4. 効果測定方法: 4-1の基準値からの変化で評価

## ルール
- GEOは発展途上の領域であり、断定的なテクニック論を避け、原理（明確・構造化・一次情報）で説明する
- 従来SEOとの共通部分と相違部分を明示する
```

---
---

# 第5章 データ品質・異常検知 【新設】

分析の価値は、データが正しいことが大前提です。本章は「数値がおかしい」に気づき、原因を切り分け、再発を防ぐためのプロンプト群です。特に2025年以降増加している自動化トラフィック（bot）によるDirect急増は、多くのサイトで月次レポートを歪めています。

## 5-1. Direct急増のbot診断

```markdown
# Direct急増bot診断プロンプト

## 目的
Direct流入の急増が実ユーザーによるものか、bot・自動化トラフィックかを判定する

## 実行手順
1. GA4: Direct流入の日別推移（直近3ヶ月）で急増の開始日と規模を特定
2. 急増分のセッションについて以下の特徴を通常期と比較:
   - 地域分布（特定国・特定都市への偏り）
   - デバイス/OS/ブラウザ（特定バージョンへの不自然な集中）
   - エンゲージメント率・平均セッション時間（ゼロ近傍への偏り）
   - ランディングページ（トップページや特定1ページへの集中）
   - 時間帯分布（人間なら生じる昼夜の波が無い均一分布）
   - 新規ユーザー率（100%近い場合はCookieを保持しない自動アクセスの疑い）
3. bot判定チェックリストで総合判定（該当項目数でスコア化）

## 出力構成
1. 急増の概要（開始日 / 規模 / 継続状況）
2. 特徴比較表（通常期 vs 急増分）とチェックリスト判定結果
3. 判定: 「bot濃厚 / 実ユーザーの可能性あり / 混在」＋根拠
4. 実ユーザーの可能性がある場合の確認事項
   （TVCM・SNSバズ・アプリ内ブラウザ・QRコード等、Directに分類される正当な要因）
5. bot濃厚の場合 → 5-2（除外設計）への接続

## ルール
- 近年のbotはUser-Agentを一般ブラウザに偽装するため、UA単体での判定は行わない
- 判定を急がず、複数特徴の重なりで結論づける
- レポート数値への影響額（セッション水増し分・CVR希薄化）を必ず算出する
```

## 5-2. bot・スパム除外の設計（段階的除外）

```markdown
# bot除外設計プロンプト

## 目的
検出したbotトラフィックへの対処を、誤除外リスクを踏まえた段階的アプローチで設計する

## 事前確認
1. 5-1の診断結果（未実施なら先に5-1を実行）
2. レポートへの影響許容度（少数の誤差は許容 / 厳密性が必要）

## 実行手順
以下の3段階から適切なレベルを提案:
- **レベル1: 分析時除外（可逆・即日）**
  レポート集計時にセグメント/フィルタで除外。元データは無傷。まずここから
- **レベル2: レポート用ビューの整備（可逆・恒久運用）**
  BigQuery側で除外条件を組み込んだビュー/クエリテンプレートを作成し、以後のレポートはそれを参照
- **レベル3: 計測時除外（非可逆・慎重に）**
  GA4の内部トラフィック除外・IPフィルタ等。誤除外すると実ユーザーデータを恒久的に失う

## 出力構成
1. 推奨レベルと理由
2. 具体的な除外条件の定義（地域×行動×LPの組み合わせ条件。単一条件での除外は避ける）
3. 誤除外リスクの評価（この条件で実ユーザーを何%巻き込む可能性があるか）
4. 除外前後の主要指標比較（除外の影響を可視化）
5. CLAUDE.mdの「データ品質の注意書き」への記載文面（除外開始日と条件を記録）

## ルール
- 「疑わしきは段階的に」を原則とし、いきなりレベル3を提案しない
- 除外条件は定期的な見直しが必要（botのパターンは変化する）と明記する
```

## 5-3. 計測欠損・異常の検知

```markdown
# 計測異常検知プロンプト

## 目的
タグ停止・二重計測・イベント消失などの計測トラブルを早期発見する

## 実行手順
1. GA4/BQ: 直近90日の日別で以下を取得
   - 総イベント数 / page_view数 / session_start数 / {{主要キーイベント}}数
2. 異常検知:
   - 急落: 前7日平均から-40%超の日（タグ停止・実装変更の疑い）
   - 急増: +100%超の日（二重計測・bot・バズの切り分けが必要）
   - ゼロ: 特定イベントの消失（リリースでのイベント実装漏れの疑い）
   - 比率異常: page_view/session比の急変（SPAの計測変更等）
3. 検知した異常の前後で、サイトリリース・GTM変更の有無を確認するよう促す

## 出力構成
1. 異常検知結果一覧（日付 / 指標 / 異常タイプ / 変化率）
2. 各異常の推定原因と確認手順（GTMバージョン履歴・リリースノートの照合）
3. 影響範囲: 欠損・水増しの推定量と、影響を受ける比較分析（前月比等）の列挙
4. CLAUDE.mdの「データ品質の注意書き」への記載文面

## ルール
- 曜日変動・祝日を異常と誤検知しないよう、比較は同曜日ベースを基本とする
- 「異常なし」の場合もその旨を明確に報告する（定期健診としての価値）
- 月次レポート作成前の実行を推奨（歪んだデータで報告する事故を防ぐ）
```

## 5-4. 参照元スパム・ノイズ検出

```markdown
# 参照元スパム検出プロンプト

## 目的
リファラルスパムや自己参照などのノイズ流入を検出し、チャネル分析の精度を上げる

## 実行手順
1. GA4: 直近3ヶ月の参照元（session_source）一覧をセッション数順に取得
2. 以下を検出:
   - スパム疑い: 実体のないドメイン・アダルト/カジノ系・エンゲージメントほぼゼロの参照元
   - 自己参照: 自社ドメインが参照元に出現（クロスドメイン設定漏れ・決済経由の戻り）
   - 誤分類: 本来Email/Social等に分類すべきものがReferralに混在（utm欠落）
3. それぞれの件数と影響を評価

## 出力構成
1. 検出結果（表: 参照元 / 分類 / セッション / 判定根拠）
2. 自己参照の原因診断（決済サービス・認証・別サブドメインのどれか）と設定修正案
3. utm欠落の検出（メール・広告なのにパラメータが無い流入）と命名規則の徹底案
4. 対処一覧: 除外設定 / クロスドメイン設定 / utmルールのそれぞれ

## ルール
- 自己参照はデータ汚染ではなく設定不備のシグナルとして扱い、根本対応を優先する
- 見慣れない参照元を機械的にスパム認定せず、実際にドメインの素性を確認してから判定する
```

## 5-5. GA4画面×BigQuery突合監査

```markdown
# GA4×BQ数値突合プロンプト

## 目的
GA4管理画面とBigQueryエクスポートの数値差を定量化し、「どちらを正とするか」の判断基準を作る

## 実行手順
1. 同一期間（先月）・同一定義で両者から取得:
   - セッション数 / ユーザー数 / page_view数 / {{主要キーイベント}}数
2. 差異率を算出し、既知の要因で説明:
   - しきい値適用（Googleシグナル有効時のプライバシー保護）
   - ユーザー数の推定方式の違い（GA4画面は高速化のため概算方式=HyperLogLog近似を使用。BQは正確なユニーク数）
   - エクスポートの遅延・intraday混在
   - セッション集計定義の違い
3. 説明できない差異が残る場合はエクスポート設定を点検

## 出力構成
1. 突合結果表（指標 / GA4画面 / BQ / 差異率 / 主要因）
2. 差異の許容範囲判定（±数%は正常 / それ以上は要調査）
3. 運用ルールの提案: 「報告書はどちらの数値を正とするか」の明文化案
4. CLAUDE.mdへの記載文面

## ルール
- 差異ゼロはあり得ない前提で、「説明できる差異か」を判定軸にする
- クライアント報告で両数値が混在すると信頼を損なうため、使い分けルールの明文化を強く推奨する
```

## 5-6. 計測設定の健全性監査

```markdown
# 計測設定監査プロンプト

## 目的
イベント設計・キーイベント設定・パラメータの健全性を定期監査し、負債化を防ぐ

## 実行手順
1. GA4: 直近1ヶ月の全イベント一覧（イベント名 / 件数 / UU）を取得
2. 以下を点検:
   - 命名の一貫性（snake_case統一か、類似イベントの重複がないか）
   - 発生ゼロ・激減イベント（実装が死んでいる疑い）
   - キーイベント設定と実際のビジネスゴールの一致
   - 自動収集イベントと独自実装の重複（クリック計測の二重化等）
3. URL・イベントパラメータへの個人情報混入チェック
   （メールアドレス・氏名・電話番号がpage_locationやパラメータに含まれていないか）

## 出力構成
1. イベント棚卸し表（イベント名 / 件数 / 状態: 健全・重複疑い・停止疑い・廃止候補）
2. 個人情報混入の検出結果（検出時は最優先対応として警告。該当URLパターンと修正方法）
3. キーイベント設定の評価と変更提案
4. 命名規則の整備案（今後の新規イベント向け）

## ルール
- 個人情報混入は規約違反・法令リスクに直結するため、検出時はレポート冒頭で警告する
- 廃止候補イベントは即削除ではなく、利用者（レポート・広告連携）の確認手順を添える
- 四半期に1回の実行を推奨
```

---

---
---

ここからPart 2（業種別編）です。Part 1が「ツール別の分析手法」だったのに対し、Part 2は「業種特有のビジネス課題」から出発するプロンプト群です。自社業種の章＋Part 1の併用を想定しています。

---
---

# 第6章 ECサイト分析

ECの分析は最終的に「売上＝セッション×CVR×客単価」の分解に帰着します。本章はカート放棄（CVR）、カテゴリ（品揃えと回遊）、リピート・LTV（客単価と頻度）の3領域をカバーします。eコマース計測（purchase, add_to_cart, begin_checkout等）の実装が前提です。

## 6-1. カート放棄率の基本確認

```markdown
# カート放棄率確認プロンプト

## 目的
カート追加からの離脱規模を把握し、EC改善の最大の伸びしろを定量化する

## 実行手順
1. GA4: 直近30日の add_to_cart / begin_checkout / purchase の各イベント数とユニークユーザー数を取得
2. ファネル化: カート追加→チェックアウト開始→購入完了の通過率を算出
3. カート放棄率（1 − purchase÷add_to_cart）を算出し、放棄による機会損失額を試算
   （放棄セッションの平均カート内金額 × 放棄数。取得できない場合は平均注文額で代用し、その旨明記）

## 出力構成
1. ファネル表（イベント / 件数 / UU / 前段階からの通過率）
2. カート放棄率と機会損失額の試算
3. 一般的な放棄率の目安との比較と、自サイトの位置づけ
4. 次の分析への接続: 放棄率が高い → 6-2（セグメント別）で悪化箇所を特定

## ルール
- add_to_cart と purchase のイベント定義（発火タイミング）の整合を実行前に確認する
- 放棄率は業態（高額商品・比較検討型は高くて正常）を踏まえて評価する
```

## 6-2. デバイス別・流入元別のカート放棄分析

```markdown
# カート放棄セグメント分析プロンプト

## 目的
カート放棄が特に悪化しているセグメントを特定し、改善対象を絞り込む

## 実行手順
1. GA4: 先月データで、デバイスカテゴリ別・デフォルトチャネルグループ別に
   add_to_cart数 / begin_checkout数 / purchase数 / 放棄率を算出
2. 全体平均との乖離が大きい「最悪セグメント」を特定
3. 最悪セグメントの特性を深掘り（新規/リピーター比率、LP、平均カート金額）

## 出力構成
1. デバイス別放棄率（表）
2. チャネル別放棄率（表）
3. 最悪セグメントの特定と、悪化要因の仮説
   （例: モバイル×SNS流入 → 衝動的カート追加で購入意向が浅い / フォームがモバイルで使いにくい）
4. セグメント別の改善案3つ（仮説に対応させる）
5. ページ内の実態をさらに深掘りする場合 → 2-8（LP改善総合診断）への接続

## ルール
- begin_checkout を中間点に置き、「カート→チェックアウト」と「チェックアウト→購入」のどちらで落ちているかを必ず分離する
- セグメントのサンプルが月50件未満の場合は判断保留とする
```

## 6-3. カート放棄の詳細分析（BigQuery）

```markdown
# カート放棄詳細分析プロンプト（BQ）

## 目的
カート追加後の行動をイベントレベルで追跡し、放棄の瞬間に何が起きているかを特定する

## 実行手順（BQ共通注意に従う）
1. 先月データで、add_to_cart発生セッションを抽出
2. 以下を分析:
   - カート追加から離脱（セッション終了）までの経過時間分布
   - 放棄セッションの最終閲覧URL TOP10（どのページで離脱したか）
   - カート内商品点数×放棄率（点数が多いほど放棄するか）
   - 曜日・時間帯別の放棄率
   - 放棄直前の行動パターン（配送情報ページ閲覧→離脱、クーポン検索の痕跡等）

## 出力構成
1. 経過時間分布（即離脱型 / 検討離脱型の割合）
2. 離脱URL TOP10と離脱理由の仮説
3. 点数別・曜日時間帯別の傾向
4. 放棄パターンの類型化（3〜4類型）と、類型別の対策
   （例: 配送料確認後の離脱が多い → 送料の事前明示）
5. リマインド施策の設計示唆（放棄後どのタイミングでメールを打つべきか）

## ルール
- セッション切断の定義（30分無操作等）を結果に明記する
- 「カートに入れて比較検討する」正常行動と混同しないよう、同一ユーザーの後日購入率も確認する
```

## 6-4. カテゴリ別CVR分析

```markdown
# カテゴリ別CVRプロンプト

## 目的
商品カテゴリ別の集客とCVRを把握し、強いカテゴリ・弱いカテゴリを特定する

## 事前確認
1. カテゴリの判別方法: item_category（eコマースデータ）/ URLパス（{{カテゴリパス}} 配下）のどちらを使うか

## 実行手順
1. GA4: 先月のカテゴリ別に セッション（またはアイテム表示）/ 購入数 / CVR / 売上 を算出
2. CVR順・売上順の2軸でランキング
3. 「集客は多いがCVRが低い」「CVRは高いが集客が少ない」カテゴリを抽出

## 出力構成
1. カテゴリ別パフォーマンス表（セッション / 購入 / CVR / 売上 / 平均単価）
2. 2軸マトリクス分類（集客×CVR）と各象限の解釈
3. 象限別の打ち手（集客多×CVR低 → 品揃え・価格・商品ページ改善 / CVR高×集客少 → 露出強化）
4. 気づき3つ

## ルール
- カテゴリ判別方法を結果に明記し、判別不能（uncategorized）の割合も示す
- 単価が大きく異なるカテゴリのCVR比較は、その旨注記する
```

## 6-5. カテゴリ別詳細パフォーマンス比較

```markdown
# カテゴリ詳細比較プロンプト

## 目的
上位・下位カテゴリの行動指標を比較し、下位カテゴリの改善点を具体化する

## 実行手順
1. GA4: 直近3ヶ月で、カテゴリ別に CVR / 平均注文金額 / エンゲージメント率 /
   平均滞在時間 / カート追加率 を算出
2. 売上上位5カテゴリと下位5カテゴリを抽出し、指標を並列比較
3. 上位と下位の差が最も大きい指標を特定（どこで差がついているか）

## 出力構成
1. 上位5 vs 下位5の比較表
2. 差の分解: 下位カテゴリは「見られていない」のか「見られても買われない」のか
3. 下位カテゴリごとの改善ポイント（商品画像・説明・レビュー・価格帯・導線のどれか）
4. 上位カテゴリの成功要因の横展開案

## ルール
- 季節性の強いカテゴリは3ヶ月平均で歪む可能性を注記する
- 「下位＝撤退」ではなく戦略的位置づけ（集客用・利益用等）の確認を促す
```

## 6-6. カテゴリ横断・相関分析（BigQuery）

```markdown
# カテゴリ横断分析プロンプト（BQ）

## 目的
カテゴリ間の回遊・同時購入・顧客タイプ別傾向を分析し、クロスセル施策を設計する

## 実行手順（BQ共通注意に従う）
1. 直近3ヶ月データで以下を分析:
   - カテゴリ別ファネル（閲覧→カート→購入の通過率比較）
   - カテゴリ間回遊パターン（Aカテゴリ閲覧者は次にどこを見るか）
   - 同時購入の組み合わせTOP10（同一トランザクション内のカテゴリペア）
   - 新規 vs リピーターのカテゴリ傾向（入口カテゴリと定着カテゴリの違い）
   - 月別の季節性

## 出力構成
1. カテゴリ別ファネル比較表
2. 回遊マトリクス（主要カテゴリ間の遷移率）
3. 同時購入ペアTOP10と、未実現だが親和性の高そうなペア
4. 「入口カテゴリ」（新規が最初に買う）と「定着カテゴリ」（リピーターが買い続ける）の特定
5. クロスセル施策5つ（レコメンド設定・セット販売・導線追加）と期待効果

## ルール
- 同時購入の組み合わせは件数だけでなくリフト値（偶然の同時購入との比較）で評価する
- レコメンド施策はサイトの実装可能性（CLAUDE.mdの制約条件）を確認して提案する
```

## 6-7. 基本リピート率分析

```markdown
# リピート率確認プロンプト

## 目的
購入者の初回/リピート構成を把握し、LTV改善の起点となる基準値を作る

## 実行手順
1. GA4: 直近3ヶ月の購入者を「期間内初回購入」と「リピート購入」に分類
2. 月別に 初回購入者数 / リピート購入者数 / リピート率 を算出
3. 売上ベースでも同じ分解を行う（売上の何%がリピーター由来か）

## 出力構成
1. 月次推移表（初回 / リピート / リピート率）
2. 売上構成比（新規売上 vs リピート売上）
3. 気づき: リピート依存度と、新規獲得・リピート育成のどちらが課題か
4. この数値をCLAUDE.mdの基準値として記録することを推奨

## ルール
- user_pseudo_idベースの分類はデバイス跨ぎで新規に誤判定される点を必ず注記する
  （会員IDでのUser-ID計測があればそちらを優先）
- 同一トランザクションIDの重複計測を除外する
```

## 6-8. リピート詳細分析

```markdown
# リピート行動詳細プロンプト

## 目的
リピーターと1回きり購入者の違いを分析し、2回目購入を生む要因を特定する

## 実行手順
1. GA4/BQ: 直近6ヶ月で以下を分析:
   - 初回→2回目購入の平均・中央値日数
   - 購入回数分布（1回のみ / 2回 / 3回以上）
   - リピート購入時の流入元（何経由で戻ってくるか）
   - リピーターがよく買う商品カテゴリ vs 1回きり購入者の初回カテゴリ
2. 「2回目を買った人」と「買わなかった人」の初回購入時の行動差を比較
   （初回のカテゴリ・金額・閲覧ページ数・会員登録有無）

## 出力構成
1. リピート基礎データ（日数分布 / 回数分布 / 再訪流入元）
2. 2回目購入者と1回きり購入者の初回行動比較表
3. 「リピートに繋がる初回体験」の仮説
   （例: 「初回で◯◯カテゴリを買った人はリピート率2倍」→ 初回導線をそこへ）
4. リピート率改善施策3つ（タイミング×チャネル×オファーを具体化）

## ルール
- 初回→2回目の日数中央値を、リマインドメール・広告のタイミング設計に直結させる
- 消耗品/耐久財で正常なリピート周期が違う点を考慮する
```

## 6-9. コホート＆LTV分析（BigQuery）

```markdown
# EC LTV分析プロンプト（BQ）

## 目的
初回購入月コホート別のLTV推移とRFM分類から、顧客育成の優先順位とロードマップを作る

## 実行手順（BQ共通注意に従う）
1. 初回購入月別コホートで、その後の累計購入額の推移を作成（可能な範囲の全期間）
2. RFM分析: Recency（最終購入からの日数）/ Frequency（購入回数）/ Monetary（累計金額）で
   顧客をランク分類（例: 3×3×3=27セグメントを実務用に5ランクへ集約）
3. ランク別の行動特性（訪問頻度・閲覧カテゴリ・メール反応）を比較
4. 簡易LTV推定: コホートの購入額推移から12ヶ月LTVを外挿

## 出力構成
1. コホート別累計LTV表（ヒートマップ形式）
2. RFMランク別の人数・売上構成・行動特性
3. 12ヶ月LTV推定値と算出根拠（外挿の前提を明示）
4. 育成ロードマップ: どのランクをどのランクへ引き上げるのが売上インパクト最大か
   （ランク間の遷移施策を優先度順に3つ）

## ルール
- 外れ値（1件の超高額購入等）はLTV平均を歪めるため、中央値併記か除外基準を明示する
- user_pseudo_idの限界（Cookie削除・デバイス跨ぎでLTVが過小評価）を注記する
- LTV推定は「推定」であることを強調し、CAC上限の意思決定には保守的な値を使うよう促す
```

---
---

# 第7章 オウンドメディア分析

メディアの分析は「読まれること」と「事業成果（収益・リード・ブランド）に繋がること」の2層で評価します。本章は記事パフォーマンス、キーワード戦略、広告収益最適化の3領域をカバーします。記事は {{記事ディレクトリ}} 配下にある前提です。

## 7-1. 記事パフォーマンスの基本分析

```markdown
# 記事パフォーマンス基本プロンプト

## 目的
記事のPV・エンゲージメントのTOP群を把握し、「読まれる記事」の特徴を抽出する

## 実行手順
1. GA4: 先月の {{記事ディレクトリ}} 配下ページについて
   PV TOP10 / 平均エンゲージメント時間TOP10 / エンゲージメント率TOP10 を取得
2. 記事全体の平均値と比較
3. 上位記事の共通点を分析（トピック・形式・タイトルの型・文字量の傾向）

## 出力構成
1. 3種のTOP10表（PV / 滞在 / エンゲージ率）＋全体平均
2. 3つのランキングすべてに入る「万能記事」と、PVのみ/滞在のみの「偏り記事」の分類
3. 読まれる記事の特徴仮説（トピック・構成・タイトルの型）
4. 次月の編集方針への示唆3つ

## ルール
- 公開直後の記事とストック記事は分けて評価する（公開月バイアス）
- PVが多くても外部流入頼みか、サイト内回遊で読まれているかを区別する
```

## 7-2. 記事タイプ別エンゲージ比較

```markdown
# 記事タイプ別比較プロンプト

## 目的
記事タイプ（how-to / ニュース / インタビュー / レビュー等）別の強弱を把握し、編集リソース配分を最適化する

## 事前確認
1. 記事タイプの判別方法（URLパターン / カテゴリパラメータ / タイトル命名規則）

## 実行手順
1. GA4: 直近3ヶ月で記事タイプ別に
   PV / 平均エンゲージメント時間 / スクロール到達（90%到達イベントか {{完読イベント}}）/
   次ページ遷移率 / 登録・CV率（{{主要キーイベント}}）を算出
2. タイプ間比較と、タイプ×流入元のクロス分析

## 出力構成
1. タイプ別主要指標の比較表
2. 「集客に強いタイプ」と「成果（CV・登録）に強いタイプ」の特定
3. 要改善タイプの課題診断（読まれない/読まれるが成果に繋がらない、の切り分け）
4. リソース配分提案: 増やすタイプ・改善するタイプ・減らすタイプ

## ルール
- タイプ判別できない記事の割合を明示し、多い場合は分類ルールの整備を先に提案する
- 各タイプの本数が偏っている場合は「1記事あたり」の値で比較する
```

## 7-3. 記事の総合エンゲージ分析（BQ＋SC統合）

```markdown
# 記事総合分析プロンプト（BQ+SC）

## 目的
検索露出から完読・回遊・CVまでの記事ファネルを統合分析し、編集方針を決める

## 実行手順（BQ共通注意に従う）
1. SC: 記事別の表示回数・クリック・CTR（直近3ヶ月）
2. GA4/BQ: 同記事の閲覧開始→スクロール→{{完読イベント}}→次ページ遷移→CVのファネル
3. 統合分析:
   - 記事の公開経過月数×流入の関係（鮮度が効くタイプ/ストックで効くタイプ）
   - 記事の長さ（文字量の代理として滞在時間帯）×完読の相関
   - 曜日・時間帯別の読まれ方
   - 完読後の回遊パターン（どの記事へ流れるか）

## 出力構成
1. 記事ファネル表（表示→クリック→閲覧→完読→回遊→CV）と各段階の平均通過率
2. ボトルネック段階の特定（露出不足 / CTR不足 / 完読されない / 回遊しない）
3. 鮮度分析: 更新（リライト）で効果が見込める記事リスト
4. 編集方針5つ（新規テーマ / リライト対象 / 内部リンク設計 / 公開タイミング / 長さの目安）

## ルール
- 完読イベント未実装の場合はスクロール90%で代替し、その旨明記する
- リライト候補は「順位11〜20位×表示回数多」を優先する（伸びしろ最大）
```

## 7-4. 基本キーワード分析

```markdown
# メディア向けキーワード分析プロンプト

## 目的
検索流入の柱となるキーワード群を4つの観点で把握する

## 実行手順
1. SC: 直近28日で以下の4リストを作成
   - 流入数TOP20（現在の柱）
   - CTR高TOP20（タイトルが刺さっている）
   - 平均順位良（3位以内）TOP20（資産キーワード）
   - 表示回数多×CTR低TOP20（改善余地最大）
2. 各キーワードに対応するLPを紐付け
3. ブランド系/一般系に層別

## 出力構成
1. 4リストの表（キーワード / 表示 / クリック / CTR / 順位 / LP）
2. 層別サマリー（ブランド依存度、一般キーワードでの戦闘力）
3. 「表示多×CTR低」リストへの対応 → 2-4（CTR改善）の実行を案内
4. 気づき3つ

## ルール
- 4リストで重複するキーワードは最重要としてマークする
- 検索ボリュームの季節性が疑われる語は注記する
```

## 7-5. キーワード×コンテンツのミスマッチ検出

```markdown
# メディア向けミスマッチ検出プロンプト

## 目的
検索意図とコンテンツのズレによる機会損失を検出し、リライト優先度を決める

## 実行手順
1. SC×GA4: 過去3ヶ月で、キーワード別の流入とLPのエンゲージメントを突合
2. 検出:
   - 流入は多いがエンゲージメント率が著しく低いキーワード×LPの組み合わせTOP10
   - 検索意図の推定（情報収集/比較/手順/最新情報）とコンテンツ内容の照合
   - 流入後すぐ離脱してサイト内検索や別記事に移動しているパターン
3. 優先度順に施策を5つ提示

## 出力構成
1. ミスマッチTOP10（表: キーワード / LP / 流入 / エンゲージ率 / ズレの内容）
2. ズレの類型（内容が浅い / 古い / 意図と違う切り口 / 構成が悪く答えに辿り着けない）
3. リライト施策5つ（優先度・具体的な修正内容・期待効果）

## ルール
- 判定前に該当キーワードを実際に検索し、上位サイトの傾向と検索意図を確認する
- 「意図的に広く浅く書いた記事」等、編集方針として正しい場合もあるため断定を避ける
```

## 7-6. キーワード戦略の最適化（SC＋BQ）

```markdown
# キーワード戦略統合プロンプト

## 目的
キーワード群を戦略的に整理し、新規制作とリライトの年間計画に落とす

## 実行手順（BQ共通注意に従う）
1. SC: 直近6ヶ月の全キーワードを取得し、トピッククラスタに分類
2. 分析:
   - クラスタ別のカバー状況（流入を取れているクラスタ/穴のあるクラスタ）
   - ギャップ: 表示はあるが上位を取れていないクラスタ
   - カニバリゼーション: 同一キーワードで複数記事が競合しているケース
   - クラスタ別のCV貢献（BQでLP別CVRと突合）
   - 季節性: クラスタ別の月別需要変動
   - ロングテール: 少量多数キーワードの合計インパクト

## 出力構成
1. クラスタマップ（クラスタ / 記事数 / 流入 / 平均順位 / CV貢献）
2. カニバリ検出リストと統合・棲み分けの提案
3. 攻めるべきクラスタの優先順位（需要×競合状況×CV親和性）
4. 四半期ごとの制作計画（新規テーマ / リライト対象 / 統合対象）

## ルール
- クラスタ分類の基準を明示する（トピックの意味的まとまり）
- カニバリは「順位が交互に入れ替わる」「クリックが分散」の実データで判定する
```

## 7-7. 広告収益の基本分析

```markdown
# 広告収益基本プロンプト

## 目的
サイト全体の広告収益とRPMを把握し、収益源となっている記事を特定する

## 事前確認
1. 広告収益データの取得方法: GA4のパブリッシャー広告指標（AdSense連携等）の
   計測有無を確認。未計測の場合は連携設定の案内のみ行う

## 実行手順
1. GA4: 先月の 総広告収益 / RPM（収益÷PV×1000）を算出
2. 記事別の収益TOP10とRPM TOP10を取得
3. デバイス別の収益・RPM比較

## 出力構成
1. 全体サマリー（総収益 / 総PV / RPM / 前月比）
2. 収益TOP10（量で稼ぐ記事）とRPM TOP10（効率で稼ぐ記事）の2表
3. デバイス別比較と気づき
4. 「PVは多いがRPMが低い」記事の抽出（広告配置改善の候補）

## ルール
- 広告収益指標の計測範囲（連携している広告ネットワーク）を結果に明記する
- RPMはジャンル・読者層で大きく異なるため、サイト内比較を主軸にする
```

## 7-8. 広告パフォーマンス詳細分析

```markdown
# 広告収益詳細プロンプト

## 目的
収益を分解し、RPM20%向上に向けた具体的な改善レバーを特定する

## 実行手順
1. GA4: 直近3ヶ月で以下を分析:
   - 記事カテゴリ別の収益・RPM
   - 流入チャネル別の収益・RPM（検索流入とSNS流入で単価が違うか）
   - 滞在時間×収益の相関（長く読まれる記事は収益も高いか）
   - 新規 vs リピーターの収益性
   - 曜日・時間帯別の傾向

## 出力構成
1. 5つの分析軸それぞれの表と気づき
2. 収益の方程式分解: 収益＝PV×RPM のどちらに効く施策かで改善案を分類
3. RPM20%向上のための施策5つ（優先度・根拠データ・期待効果付き）
4. 実施時の注意: 広告増加によるUX悪化 → 回遊・再訪への副作用の監視指標

## ルール
- 「広告を増やす」系の施策には必ずUX副作用の監視指標をセットで付ける
- チャネル別RPM差は読者の質だけでなく広告ターゲティング精度の差も要因として挙げる
```

## 7-9. 広告収益の総合最適化（BigQuery）

```markdown
# 広告収益統合最適化プロンプト（BQ）

## 目的
回遊・コンテンツタイプ・セグメントを統合し、収益30%向上のロードマップを作る

## 実行手順（BQ共通注意に従う）
1. 直近6ヶ月データで以下を統合分析:
   - ユーザージャーニー×収益（1訪問の閲覧記事数と収益の関係、理想の回遊パターン）
   - コンテンツタイプ別の収益性（7-2のタイプ分類を流用）
   - ユーザーセグメント別（流入元×新規リピート×デバイス）の収益貢献
   - 記事内の広告配置と読了の関係（完読イベントとの突合）
   - 月別季節性と収益予測

## 出力構成
1. 収益構造の全体像（何が収益を生んでいるかの分解図）
2. 「収益効率の高い回遊パターン」と、それを増やす内部リンク・レコメンド設計
3. セグメント別戦略（高収益セグメントを増やす集客 / 低収益セグメントの収益化改善）
4. PVと収益の関係式（現状の構造でPVがX%増えたら収益は何%増えるか）
5. 30%向上ロードマップ（3ヶ月単位のフェーズ分け、各フェーズのKPI）

## ルール
- 収益最大化とユーザー体験・SEOのトレードオフを必ず明示する
- 予測には前提（季節性・単価変動）を明記し、幅を持たせて提示する
```

---

---
---

# 第8章 B2Bマーケティング分析

B2Bは「リード獲得はゴールではなく起点」です。検討期間が長く、複数回の訪問・複数のコンテンツ接触を経て商談に至るため、単発CVRだけでなく**リードの質と育成プロセス**の可視化が中心になります。リード獲得イベント（{{リード獲得イベント}}: form_submit等）の実装が前提です。

## 8-1. 基本的なリード評価

```markdown
# リード獲得状況プロンプト

## 目的
先月のリード獲得状況をチャネル・LP・デバイス別に可視化し、最良の獲得経路を特定する

## 実行手順
1. GA4: 先月の {{リード獲得イベント}} 総数を取得
2. チャネル別・ランディングページ別・デバイス別にリード数とCVRを算出
3. リード1件あたりのセッション効率が最も良い組み合わせを特定

## 出力構成
1. 総リード数（前月比・前年同月比）
2. チャネル別リード数とCVR（表）
3. LP別リード数とCVR TOP10（表）
4. デバイス別CVR比較
5. 最良チャネル×LPの組み合わせと、そこへの集中投資案

## ルール
- 対象イベントの定義（どのフォームを含むか）と除外条件（テスト送信・社内）を冒頭に明記する
- 問い合わせ・資料請求・デモ依頼など複数フォームがある場合は種別ごとに分けて集計する
```

## 8-2. リード品質の評価基準づくり

```markdown
# リード品質評価プロンプト

## 目的
「質の高いリード」の行動特徴を抽出し、行動ベースの5段階リードスコア基準を作る

## 事前確認
1. 質の定義: 商談化・受注データ（CRM側）との突合が可能か。
   不可の場合は「サイト内の深い関与行動」を質の代理指標とする（その旨を結果に明記）

## 実行手順
1. GA4/BQ: 直近3ヶ月のリード獲得ユーザーについて、獲得までの行動を集計
   - 初回訪問からリードまでの日数・訪問回数
   - 閲覧ページ群（料金 / 事例 / 機能 / ブログ の閲覧有無）
   - 資料DL・動画視聴等の中間行動
2. 質の高い/低いリードの行動差を比較
3. 差が大きい行動に重み付けし、5段階スコア基準を設計

## 出力構成
1. リード獲得までの行動サマリー（日数分布・訪問回数分布）
2. 高品質リードの特徴 / 低品質リードの特徴（対比表）
3. チャネル別の品質傾向
4. 5段階リードスコア基準（各行動の配点と根拠）
5. 運用案: スコア別のフォロー優先度と、営業へのパス基準

## ルール
- 初回訪問で即フォーム送信するリードは「情報不足での判定」となるため例外処理する
  （指名流入・紹介経由の可能性があり、低品質と断定しない）
- スコア基準は仮説であり、商談化実績での検証・改訂を前提とする旨を明記する
```

## 8-3. 資料ダウンロード状況の把握

```markdown
# 資料DL状況プロンプト

## 目的
ホワイトペーパー等の資料DL状況を可視化し、効果的な資料と獲得経路を特定する

## 実行手順
1. GA4: 先月の {{資料DLイベント}}（file_download等）を資料別に集計
2. 資料DL TOP10・流入元・DLに至る直前ページ・デバイス別DL率を算出
3. 資料をタイプ分類（入門ガイド / 事例集 / 比較資料 / 技術資料 等）し、タイプ別の傾向を分析

## 出力構成
1. 資料別DL数 TOP10（表: 資料名 / DL数 / 主な流入元）
2. DL直前ページTOP5（どのコンテンツが資料への入口か）
3. デバイス別DL率
4. タイプ別の傾向（検討初期向けと検討後期向けのどちらが強いか）
5. 気づきと、DLが弱い資料の露出改善案

## ルール
- DLイベントの計測方式（自動収集file_download / 独自イベント / サンクスページ表示）を確認し、
  資料名の判別方法を結果に明記する
- ゲート有無（フォーム必須か否か）で数値の意味が違うため分けて評価する
```

## 8-4. ダウンロード導線の最適化

```markdown
# DL導線最適化プロンプト

## 目的
資料DLまでの導線とフォーム離脱を分析し、DL数30%向上の施策を設計する

## 実行手順
1. GA4/BQ: 直近3ヶ月で以下を分析
   - DL到達経路の上位10パターン（流入→中間ページ→DLページ）
   - DLフォームページの到達数→送信数（フォーム完了率）
   - フォーム離脱の発生状況（フォーム表示後の離脱率、可能なら項目単位）
   - DL後のサイト内行動（回遊するか、離脱するか、他資料も見るか）
   - 資料タイプ別のフォーム完了率差

## 出力構成
1. 主要導線TOP10と、導線ごとのDL率
2. フォーム完了率と離脱分析（離脱要因の仮説: 項目数・必須項目・入力負荷）
3. DL後行動の分類（即離脱 / 回遊 / 追加DL）と、DL直後に見せるべきコンテンツ案
4. 改善施策5つ（導線追加 / フォーム項目削減 / 資料の出し分け等、優先度・期待効果付き）

## ルール
- フォーム項目単位の離脱はGA4標準では取れないため、取得可能な範囲を確認してから分析する
  （未計測の場合は項目単位の深掘りは行わず、到達→送信の完了率で評価する旨を明記する）
- 項目削減の提案時は「営業に必要な情報」とのトレードオフを明示する
```

## 8-5. コンテンツエコシステム最適化（BigQuery）

```markdown
# B2Bコンテンツエコシステムプロンプト（BQ）

## 目的
ブログ・資料・事例等のコンテンツ群を「リード獲得への貢献」で統合評価し、制作優先順位を決める

## 実行手順（BQ共通注意に従う）
1. 直近6ヶ月データで以下を分析:
   - コンテンツ消費パターンの分類（ブログのみ / ブログ→資料 / 直行DL 等）
   - コンテンツ間の相関（この記事を読んだ人はこの資料をDLする、の組み合わせ）
   - コンテンツ起点のリード獲得ファネル（初回接触コンテンツ→リードまでの経路と日数）
   - コンテンツROI: 制作コンテンツ別のリード貢献数（初回接触・最終接触の両方でカウント）
2. リード貢献の高いコンテンツの共通点を抽出

## 出力構成
1. 消費パターン分類と各パターンのリード転換率
2. コンテンツ相関マップ（強い組み合わせTOP10）
3. コンテンツ別リード貢献ランキング（初回接触ベース / 最終接触ベースの2列）
4. パーソナライズ戦略: 閲覧コンテンツに応じた次のオファー出し分け案
5. 制作優先順位: 強化すべきテーマ / 不足しているファネル段階のコンテンツ

## ルール
- 初回接触と最終接触で評価が大きく異なるコンテンツ（認知型 vs 刈り取り型）を明示する
- セグメント軸（業種・企業規模）が取得できる場合は複合して分析する
```

## 8-6. リード育成の基本指標

```markdown
# ナーチャリング基本プロンプト

## 目的
リード獲得後の再訪・行動を可視化し、育成施策（主にメール）の効果を把握する

## 実行手順
1. GA4/BQ: 直近3ヶ月にリード化したユーザーの獲得後行動を集計
   - 再訪率 / 再訪までの日数分布
   - 再訪時の閲覧コンテンツTOP10
   - 再訪時の追加CV率（別フォーム送信・デモ依頼等）
2. utm_campaign からメール施策経由の再訪を特定し、施策別の効果を比較

## 出力構成
1. リード獲得後の再訪サマリー（再訪率 / 日数の中央値）
2. 再訪時に見られるコンテンツTOP10（検討が進んだリードは何を見るか）
3. 再訪時CV率と、CVした再訪の直前接触チャネル
4. メール施策別の再訪貢献（表: campaign / 再訪数 / 再訪後CV）
5. 育成メールの改善示唆（送るタイミング・載せるコンテンツ）

## ルール
- utm_campaignの命名規則が不統一な場合は、まず命名の整理案を提示してから分析する
- リード後の行動はuser_pseudo_idベースのため、メール既読者がPCとスマホで別人扱いになる
  限界を注記する
```

## 8-7. ナーチャリングシナリオ評価

```markdown
# ナーチャリングシナリオ評価プロンプト

## 目的
6ヶ月スパンで育成施策の効果を検証し、効果的なシナリオ3パターンを設計する

## 実行手順
1. GA4/BQ: 直近6ヶ月のリードについて
   - 施策（utm_campaign）別の再訪率と行動の質（閲覧深度・料金/事例ページ到達率）
   - 商談化率（CRM突合可能な場合）または深い関与イベント率（代理指標）
   - タッチポイント数（メール接触回数）× 商談化率の関係（接触は多いほど良いのか）
   - 接触頻度別の効果（週1 / 隔週 / 月1相当の比較）

## 出力構成
1. 施策別効果ランキング（再訪→関与→商談化の各段階）
2. タッチポイント数と成果の関係（逓減点・逆効果になる閾値の有無）
3. 最適接触頻度の推定と根拠
4. 推奨シナリオ3パターン（対象セグメント × コンテンツ順序 × 頻度を具体化）
5. 各シナリオの検証計画（見る指標と判定期間）

## ルール
- 施策の効果とリードの元々の質（自己選択バイアス）を混同しないよう、
  獲得チャネルを揃えた比較を基本とする
- 商談化データが無い場合、結論は「関与の深まり」までに留め、断定を避ける
```

## 8-8. マルチタッチアトリビューション（BigQuery）

```markdown
# B2Bマルチタッチ分析プロンプト（BQ）

## 目的
長い検討期間の全タッチポイントを可視化し、チャネルの真の貢献度と投資配分を導く

## 実行手順（BQ共通注意に従う）
1. 直近6ヶ月のリード獲得ユーザーの全訪問履歴を時系列で取得
2. 分析:
   - 代表的なジャーニーパターンの可視化（チャネル遷移の頻出順序TOP10）
   - アトリビューションモデル比較（ファースト / ラスト / 線形。第3章3-13の手法を流用）
   - 検討期間の分布と、期間の長短による経路の違い
   - 休眠→復活パターン（30日以上空いて再訪しリード化したケースの復活きっかけ）
   - 検討ステージ別（初回接触期 / 比較検討期 / 直前期）に効いているチャネル

## 出力構成
1. ジャーニーパターンTOP10と平均検討期間
2. モデル別チャネル貢献比較と、評価が変わるチャネルの解釈
3. 休眠復活の起点チャネル（復活施策の設計材料）
4. ステージ別の最適チャネル・コンテンツのマッピング
5. 投資配分の見直し案（過小評価されているチャネルへの再配分）

## ルール
- ラストクリック偏重で過小評価されがちなチャネル（ブログ・SNS・ウェビナー）の
  補正観点を必ず示す
- Cookie期限とuser_pseudo_idの限界により長期ジャーニーは分断される点を注記し、
  検討期間の数値は下限値として解釈させる
```

---
---

# 第9章 店舗・O2O分析

店舗ビジネスのサイト分析は「オンラインの行動」と「オフラインの成果（来店・予約・電話）」の接続が主題です。本章は予約行動と地域の2軸で構成しています。予約完了イベント（{{予約完了イベント}}）の実装が前提です。

## 9-1. 予約パターンの基本把握

```markdown
# 予約パターン把握プロンプト

## 目的
予約の発生パターン（曜日・時間帯・デバイス）を可視化し、強い時間帯・弱い時間帯を特定する

## 実行手順
1. GA4: 先月の {{予約完了イベント}} を集計
2. 曜日別・時間帯別（イベント送信時刻）・デバイス別に分解
3. 予約フォーム到達数に対する完了率を算出

## 出力構成
1. 曜日別予約数（表＋傾向）
2. 時間帯別予約数（ピークタイムの特定。※サイト上で予約操作をした時刻である点を明記）
3. デバイス別予約数と完了率
4. 予約が弱い曜日・時間帯と、そこを埋める施策仮説（時間帯限定オファー等）

## ルール
- 「予約操作の時刻」と「来店希望日時」は別物である点を混同しない
- 完了率の分母（フォーム到達の定義）を結果に明記する
```

## 9-2. 予約導線と属性別分析

```markdown
# 予約導線分析プロンプト

## 目的
予約に至る経路と離脱ポイントを特定し、予約数20%増の施策を設計する

## 実行手順
1. GA4: 直近3ヶ月で以下を分析
   - 予約完了までの主要導線TOP5（流入→閲覧ページ→フォーム）
   - 予約完了までの平均閲覧PV数
   - フォーム内の離脱ポイント（到達→完了の落差。ステップ計測があればステップ別）
   - 予約操作時刻×来店希望時刻の関係（直前予約型か計画予約型か）
   - 流入元別の予約率
   - 店舗別の予約数・予約率比較（{{店舗判別方法}}: URLパラメータ等で判別）

## 出力構成
1. 主要導線と導線別予約率
2. フォーム離脱分析と改善仮説
3. 直前予約/計画予約の比率と、それに応じた訴求の出し分け案
4. 流入元別・店舗別の比較（好調店舗の導線の横展開案）
5. 予約20%増に向けた施策5つ（優先度・期待効果付き）

## ルール
- 店舗判別方法を実行前に確認し、判別不能な予約の割合を明示する
- 店舗間比較は商圏規模の差を考慮し、率ベースを主軸にする
- 電話予約が併存する場合、サイト経由数値だけで店舗を評価しない旨を注記する
```

## 9-3. 予約最適化とキャパシティ管理（BigQuery）

```markdown
# 予約最適化プロンプト（BQ）

## 目的
予約データを時系列・セグメント・価値の観点で統合分析し、キャパシティ運用と予約数最大化を両立する

## 実行手順（BQ共通注意に従う）
1. 可能な範囲の全期間データで以下を分析:
   - 予約数の時系列（季節性・キャンペーン時の増加・長期トレンド）
   - 予約までの検討期間（初回訪問→予約完了の日数）
   - 時間帯×曜日の予約ヒートマップ（埋まりやすい枠 / 空きやすい枠）
   - セグメント別傾向（新規/リピート、デバイス、流入元）
   - 予約1件あたりの価値差（メニュー・コース情報が取れる場合）
2. 直近トレンドから翌月の予約数レンジを予測

## 出力構成
1. 時系列分析と季節性のまとめ
2. 検討期間の分布（即決型 / 比較検討型の割合）
3. 時間帯×曜日ヒートマップと、空き枠を埋めるオファー設計
   （空きやすい枠への誘導インセンティブ等）
4. セグメント別の予約傾向と狙うべき層
5. 翌月予約数の予測レンジ（前提条件明記）と人員配置への示唆

## ルール
- 予約数最大化と運用効率（ピーク集中の緩和）のバランスを明示的に扱う
- 予測は幅を持たせ、キャンペーン等の変動要因を前提条件として列挙する
- キャンセルデータが取れない場合、「予約＝来店ではない」限界を注記する
```

## 9-4. 地域別の基本パフォーマンス

```markdown
# 地域別パフォーマンスプロンプト

## 目的
都道府県別のサイト利用状況を可視化し、店舗所在地とのマッチ度を評価する

## 事前確認
1. 店舗所在地（{{店舗所在地リスト}}。例: 東京・大阪・名古屋・福岡）

## 実行手順
1. GA4: 先月の都道府県別に セッション / CVR（{{予約完了イベント}}）/
   平均エンゲージメント時間 / エンゲージメント率 を算出
2. 4指標それぞれのTOP10を作成
3. 店舗所在地の都道府県と、アクセス上位地域のマッチ度を評価

## 出力構成
1. 4指標のTOP10表
2. 店舗所在地×アクセスのマッチ度評価
   - 店舗あり×アクセス多 → 順調（深耕）
   - 店舗あり×アクセス少 → 認知不足（ローカル施策）
   - 店舗なし×アクセス多 → 出店候補 or EC/通販の機会
3. 気づき3つ

## ルール
- 地域判定（IPベース）の精度限界を注記する（モバイル回線は実際と異なる場合がある）
- 商圏は都道府県より狭い（市区群）ケースでは、cityディメンションでの深掘りを案内する
```

## 9-5. エリア別キャンペーン効果比較

```markdown
# エリアキャンペーン効果プロンプト

## 目的
地域限定キャンペーンの効果をエリア間で比較し、成功要因と改善点を特定する

## 事前確認
1. 対象キャンペーンと実施エリア（例: 関東 / 関西 / 東海）、実施期間、判別方法（utm等）

## 実行手順
1. GA4: 直近3ヶ月でエリア別に以下を比較
   - 対象地域内でのリーチ（該当地域からのキャンペーンLP訪問）
   - エンゲージメント率
   - 店舗関連アクション率（店舗ページ閲覧 / 地図クリック / 電話タップ / {{予約完了イベント}}）
   - 費用データが提供された場合はエリア別CPA
2. 対象エリア外からのアクセス分析（無駄打ちか、越境需要か）

## 出力構成
1. エリア別効果比較表（リーチ / エンゲージ / 店舗アクション / CPA）
2. 最良エリアと要改善エリアの要因分析
   （クリエイティブ・オファー内容・地域特性・競合状況のどれか）
3. エリア外アクセスの解釈と対応（配信地域の調整 or 越境需要の取り込み）
4. 次回キャンペーンへの改善案3つ

## ルール
- エリア間で人口・商圏規模が違うため、絶対数でなく率とCPAで比較する
- 店舗アクション率の定義（含めるイベント）を結果に明記する
```

---
---

# 第10章 コーポレート・IR・PR分析

コーポレートサイトは売上CVが無い分、評価軸の設計が最重要です。本章では採用・IR・ブランド/PRの3領域それぞれに「何をもって成果とするか」を定義した上で分析します。

## 10-1. 採用ページの基本指標

```markdown
# 採用ページ基本プロンプト

## 目的
採用セクションのファネル（訪問→募集要項→エントリー）を可視化し、採用サイトの健全性を測る

## 実行手順
1. GA4: 先月の採用関連ページ（{{採用ディレクトリ}}: /recruit/ 等）について
   - 採用トップ訪問数
   - 募集要項ページ閲覧数（職種別）
   - エントリーフォーム到達数
   - エントリー完了（{{採用エントリーイベント}}）
2. 各段階の通過率と全体CVR（採用トップ→エントリー完了）を算出
3. 採用セクションへの流入元を分解

## 出力構成
1. 採用ファネル表（各段階の数と通過率）
2. 職種別の閲覧数とエントリー率の差
3. 流入元分析（求人媒体 / 検索 / SNS / 社名指名の比率）
4. ボトルネック段階の特定と改善仮説

## ルール
- 職種別の差を必ず併記する（全体CVRだけでは人気職種に埋もれた課題が見えない）
- エントリーが外部ATS（採用管理システム）に遷移する場合、遷移クリックを完了の代理指標とし、
  その旨を明記する
```

## 10-2. 採用マーケの総合最適化（BigQuery）

```markdown
# 採用マーケ統合プロンプト（BQ）

## 目的
応募に至るジャーニーとコンテンツ貢献を統合分析し、採用広報の改善ロードマップを作る

## 実行手順（BQ共通注意に従う）
1. 直近6ヶ月データで以下を分析:
   - 応募者のジャーニー（初回接触→応募までの訪問回数・日数・閲覧コンテンツ順序)
   - コンテンツ貢献: 社員インタビュー・ブログ・福利厚生ページ等の応募への寄与
   - 応募者ペルソナの推定（流入元・デバイス・閲覧傾向・地域からの類型化）
   - SC連携: 採用関連の検索キーワード（社名+採用 / 職種名 / 「働き方」系）
   - 採用イベント・説明会告知の効果（開催前後のアクセス変化）

## 出力構成
1. 応募ジャーニーの類型（即応募型 / じっくり研究型 等）と各類型の割合
2. 応募貢献コンテンツランキングと、不足しているコンテンツの提案
3. ペルソナ類型別の効果的な訴求・導線
4. 検索キーワード分析（指名依存度と、職種名検索での戦闘力）
5. 改善ロードマップ（今月 / 四半期 / 半年の3段階）

## ルール
- 「応募の質」（書類通過・内定率）はサイトデータでは測れないため、
  人事データとの突合を推奨事項として添える
- 検討期間が長い（数ヶ月〜転職周期）ため、ジャーニー分断の限界を注記する
```

## 10-3. IRページの基本指標

```markdown
# IRページ基本プロンプト

## 目的
IRセクションの利用状況を可視化し、投資家への情報提供が機能しているかを評価する

## 実行手順
1. GA4: 先月のIR関連ページ（{{IRディレクトリ}}: /ir/ 等）について
   - IRトップ訪問数
   - 決算資料ダウンロード数（資料別）
   - 株価情報ページ閲覧数
   - IRニュース閲覧数
   - 経営方針・中期経営計画ページ閲覧数
2. 前年同月と比較
3. 流入内訳（検索 / 直接 / リファラル: 証券会社・IRポータルサイト等）を分解

## 出力構成
1. IR主要指標の表（当月 / 前年同月 / 増減）
2. 資料別DLランキング
3. 流入元分析（どこから投資家が来ているか）
4. 気づき: 閲覧の多い情報と、埋もれている重要情報

## ルール
- 決算発表月とそれ以外で数値水準が大きく違うため、比較は前年同月を基本とする
- リファラル元の内訳（IRポータル・証券会社・ニュースサイト）を可能な範囲で分類する
```

## 10-4. 投資家行動の詳細分析

```markdown
# 投資家行動分析プロンプト

## 目的
1年間のIRアクセスパターンから投資家の関心と行動を読み解き、IRサイト改善につなげる

## 実行手順
1. GA4/BQ: 直近12ヶ月で以下を分析
   - 決算発表前後のアクセス推移（発表日を起点に前後2週間の日別）
   - 資料タイプ別DL傾向（決算短信 / 説明会資料 / 有報 / 統合報告書）
   - 投資家タイプの推定: 閲覧パターンからの類型化
     （発表直後に短信へ直行=機関・プロ型 / 週末に幅広く閲覧=個人投資家型 等）
   - IRイベント（説明会・株主総会）前後の変化
   - 流入元別の行動差（IRポータル経由 vs 検索経由）

## 出力構成
1. 決算前後のアクセスパターンと、情報公開タイミングの評価
2. 資料タイプ別の需要ランキング
3. 投資家タイプ推定と、タイプ別に不足している情報
4. 流入元別の行動差
5. IRサイト改善提案5つ（情報の配置・公開タイミング・資料形式）

## ルール
- utm_campaignやメール配信（IRメール）があれば識別に使う
- 投資家タイプはあくまで行動からの推定であり、断定表現を避ける
- 公平開示（フェアディスクロージャー）の観点から、特定層優遇にならない改善案とする
```

## 10-5. ブランドの基本指標

```markdown
# ブランド指標プロンプト

## 目的
ブランド力の代理指標（指名検索・直接流入・理念系ページ閲覧）を定点観測する

## 実行手順
1. GA4/SC: 先月について以下を算出し、前月比・前年同月比を付す
   - 指名検索の割合（SC: {{ブランド名}} を含むクエリのクリック÷全クリック）
   - Direct流入の割合
   - 会社概要ページ閲覧数
   - 企業理念・ミッションページ閲覧数
   - トップページ平均エンゲージメント時間
   - サイト全体のリピート率

## 出力構成
1. ブランド指標一覧表（当月 / 前月 / 前年同月）
2. 指名検索とDirectの推移解釈（ブランド認知の変化シグナル）
3. 理念系ページの閲覧者分析（誰が見ているか: 就活層 / 取引先 / メディア の推定）
4. 気づきと、次月注視すべき指標

## ルール
- 3つの比較軸（前月・前年同月）を全指標で揃える
- Direct割合はbot・アプリ内ブラウザの影響を受けるため、第5章5-1の診断結果を踏まえて解釈する
- 単月の変動で一喜一憂せず、3ヶ月移動平均での判断を促す
```

## 10-6. ニュース・PRの基本効果

```markdown
# ニュース・PR効果プロンプト

## 目的
ニュース・プレスリリースの閲覧状況と、問い合わせ・採用への波及効果を可視化する

## 実行手順
1. GA4: 先月について以下を算出し、前月と比較
   - ニュース一覧ページ閲覧数
   - ニュース記事別閲覧TOP10
   - プレスリリース別閲覧TOP10
   - ニュース閲覧セッションからの問い合わせ数・採用ページ遷移数
2. ニュースを種別（新商品 / 業績 / 提携 / 受賞 / 人事 / CSR等）に分類して集計

## 出力構成
1. ニュース閲覧サマリー（前月比）
2. 記事別・リリース別TOP10（種別タグ付き）
3. 波及効果: ニュース閲覧→問い合わせ / 採用閲覧への遷移率
4. 種別ごとの読まれやすさの傾向

## ルール
- 公開日からの経過日数で閲覧数は大きく変わるため、公開月を明記して比較する
- 配信サービス（PR TIMES等）経由の流入は参照元で識別し、自社サイト閲覧との重複に注意する
```

## 10-7. ニュース種別の効果分析

```markdown
# ニュース種別効果プロンプト

## 目的
6ヶ月のニュースを種別横断で分析し、広報戦略（何を・いつ・どう出すか）に反映する

## 実行手順
1. GA4: 直近6ヶ月の全ニュース・リリースを種別分類し、以下を比較
   - 種別ごとの平均閲覧数・平均エンゲージメント時間
   - SNS・外部メディアからの流入量（拡散されやすい種別はどれか）
   - ニュースからの次ページ遷移先（製品 / 会社概要 / 採用 / IR）
   - 効果の時間減衰（公開後1日 / 1週間 / 1ヶ月の閲覧分布。話題の寿命）

## 出力構成
1. 種別別の効果比較表
2. 拡散パターン分析（拡散される種別と、その流入元構成）
3. 遷移先分析: 種別ごとに「次の行動」がどこへ向かうか
4. 時間減衰カーブと、追い掛け発信（SNS再投稿等）の最適タイミング
5. 広報戦略提案: 強化すべき種別 / 発信タイミング / 導線設計

## ルール
- 個別ニュースの当たり外れ（大型発表の有無）が平均を歪めるため、中央値を併記する
- 配信サービス経由の効果（外部での閲覧）はサイトデータに現れない限界を注記する
```

---
---

# 第11章 付録

## 11-1. 変数一覧（完全版）

| 変数 | 意味 | 主な使用章 |
|---|---|---|
| `{{サイトURL}}` | 分析対象サイトのURL | 全章 |
| `{{GA4プロパティID}}` | GA4プロパティID | 全章 |
| `{{BQデータセット}}` | BigQueryのGA4エクスポート先 | 3章ほか |
| `{{主要キーイベント}}` | 最重要キーイベント名 | 全章 |
| `{{ブランド名}}` | 指名検索判定用のブランド名 | 2・7・10章 |
| `{{記事ディレクトリ}}` | 記事配下のURLパス | 7章 |
| `{{カテゴリパス}}` | 商品カテゴリのURLパス | 6章 |
| `{{完読イベント}}` | 記事完読イベント名 | 2・3・7章 |
| `{{リード獲得イベント}}` | リード獲得イベント名 | 8章 |
| `{{資料DLイベント}}` | 資料DLイベント名 | 8章 |
| `{{予約完了イベント}}` | 予約完了イベント名 | 9章 |
| `{{店舗判別方法}}` | 店舗の判別方法（パラメータ等） | 9章 |
| `{{店舗所在地リスト}}` | 店舗の所在都道府県 | 9章 |
| `{{採用ディレクトリ}}` | 採用セクションのパス | 10章 |
| `{{採用エントリーイベント}}` | エントリー完了イベント名 | 10章 |
| `{{IRディレクトリ}}` | IRセクションのパス | 10章 |
| `{{期間}}` | 分析対象期間（未指定時は先月） | 全章 |

## 11-2. トラブルシューティング

**Q. MCPサーバーに接続できない / ツールが見つからない**
接続設定（認証情報・プロパティID）を再確認してください。SC・BQは接続確認プロンプト（2-1 / 3-1）を最初に実行するのが確実です。GA4は1-4（週次ヘルスチェック）を軽く実行し、数値が返ってくれば接続OKです。

**Q. GA4の管理画面と数値が合わない**
正常な差異の可能性が高いです。第5章5-5（GA4×BQ突合監査）を実行し、差異の要因を特定してください。しきい値・推定・集計定義の違いで数%の差は常に発生します。

**Q. BigQueryで料金が心配**
共通実行ルール（スキャン量見積もり・`_TABLE_SUFFIX`必須）を守っている限り、通常の分析でのスキャン量はわずかです。心配な場合はプロンプトに「スキャン量が1GBを超える場合は実行前に必ず確認して」と一文追加してください。

**Q. 出力が浅い・一般論しか返ってこない**
CLAUDE.mdの記入不足が最大の原因です。特に「過去の施策と結果」「制約条件」「データ品質の注意書き」の3セクションが埋まっているかを確認してください。

**Q. プロンプトの実行が途中で止まる**
分析範囲が広すぎる可能性があります。期間を短く（1ヶ月→1週間）、対象を狭く（全ページ→特定ディレクトリ）して再実行し、動くことを確認してから範囲を広げてください。

**Q. 業種章に自社にぴったりのものがない**
最も近い章をベースに、CLAUDE.mdで自社の文脈を補うのが基本です。例: SaaSは8章（B2B）+6章のリピート分析、教育系は7章（メディア）+9章の予約分析、の組み合わせで大半をカバーできます。

## 11-3. CLAUDE.md活用ガイド（要点）

1. **最初に30分かけて記入する**: プロンプトの出力品質はCLAUDE.mdの質で決まります
2. **学習ログを育てる**: 分析で得た知見を追記するたび、次の分析が賢くなります
3. **データ品質の注意書きを最新に保つ**: 第5章の各プロンプトが出力する「記載文面」をそのまま貼り付ける運用が効率的です
4. **月次でメンテナンス**: 施策履歴・アラート条件・KPI目標を月初に見直してください

詳細は同梱の「CLAUDE.mdテンプレート」冒頭の解説を参照してください。

## 11-4. 用語ミニ辞典

本書に登場する用語のうち、つまずきやすいものを平易に説明します。

| 用語 | 意味 |
|---|---|
| MCP | Model Context Protocol。ClaudeなどのAIがGA4等の外部ツールに直接アクセスするための接続の仕組み |
| user_pseudo_id | GA4がブラウザ・アプリごとに振る匿名ID。「人」ではなく「ブラウザ」単位のため、PCとスマホは別人として数えられる |
| セッション | 1回の訪問のまとまり。30分間操作がないと終了する |
| キーイベント | ビジネス上の成果として指定したイベント（旧称: コンバージョン） |
| しきい値 | プライバシー保護のため、少人数のデータをGA4が意図的に表示しない仕組み。画面とAPIで数値がズレる主因のひとつ |
| サンプリング | データ量が多いとき、一部を抜き出して全体を推定する処理。精密さが必要な分析ではBigQueryを使う |
| `_TABLE_SUFFIX` | BigQueryで日付ごとに分かれたテーブルの範囲を指定する書き方。指定しないと全期間を読み込み、料金が跳ね上がる |
| アトリビューション | 成果（CV）に対して、どの接点（チャネル）にどれだけ功績を割り当てるかの考え方 |
| コホート | 同じ時期に来訪・購入した人のグループ。グループごとの経過を追うことで定着や離脱が見える |
| リフト値 | 「偶然そうなる確率」と比べて何倍起きているか。同時購入分析などで偶然と本物の関係を見分ける指標 |
| RPM | 1,000PVあたりの広告収益。メディアの収益効率の基本指標 |
| GEO | Generative Engine Optimization。生成AIの回答に引用・推薦されるための最適化 |
| bot（ボット） | 人間ではない自動プログラムによるアクセス。分析データを歪ませる主要因のひとつ |

---
