# CMO マーケティングプレイブック — 全章バンドル > CMO株式会社 がまとめる CMO マーケティングプレイブック全章を 1 ファイルにまとめたバンドル版。AI エージェントが文脈として直接読み込めるように生成しています。 > 公開サイト: https://cmoinc.jp/knowledge/marketing/playbook > 生成日時: 2026-05-21T07:03:10.180Z 本書は、人間と AI が共通の知識基盤に基づいて仕事を行うべきだという思想に基づき、マーケティングの マーケティングサイクル、領域別プレイブック、横断ガイドを Markdown で公開する OS プレイブックです。 # プレイブック **[primary] 知識層 — プレイブック** CMO株式会社 がまとめる **CMO Marketing OS のプレイブック** である。マーケティングを施策単位の経験則ではなく、組織で学習・更新できる運用知として扱う。本書は Marketing OS の知識層として、マーケティングサイクルと 12 知識エリアを定義する。 **[accent] 実行系 — CMO Marketing OS** [`/services/marketing`](/services/marketing) は、本書の知識体系を skill / agent / workspace / 診断に落とし込んだ実行系である。 文体・分量・章テンプレ等の執筆規約は [`knowledge/base/authoring-conventions.md`](../../base/authoring-conventions.md) を参照。 ## 設計思想 — 人間と AI の共通知識基盤 CMO Marketing OS は **人間と AI が、ブラックボックスではない共通の知識基盤に基づいて仕事を行うべきだ** という思想に基づいて設計されている。 マーケティングは長らく、属人的な「センス」や個別ベンダー内側のブラックボックスに依存してきた。AI エージェントがマーケティング業務に入り込む時代において、人間と AI が別々の前提・別々の語彙で動くことは、判断の検証可能性を失わせる。本 OS は、マーケティングサイクル・12 知識エリア・用語集・参考文献をすべて Markdown で公開し、人間とエージェントの双方が **同じテキストを読み、同じ語彙で議論し、同じ判断基準で意思決定できる** 共通基盤を提供する。 そのため本 OS は、公開サイト（[`/knowledge/marketing/playbook/*`](https://cmoinc.jp/knowledge/marketing/playbook/)）の各章ページから **原稿そのもの（Markdown）をダウンロードできる**。AI エージェントに本 OS を読み込ませる場合は、各章ページ上部の「MD をダウンロード」、もしくはトップページの「全章を MD でダウンロード」から取得してそのまま context に投入することを想定している。 ## 4 層モデル 各章は最大 4 層で構成される: | 層 | 役割 | 粒度 | |---|---|---| | **L1 Strategy** | 章の overview、戦略的意思決定軸 | 中（章 overview に該当） | | **L2 Process** | マーケティングサイクル（観測・データ収集 / 理解・分析する / 再構築 / 起動・実装する / 学ぶ）× ITTO | 中 | | **L3 Tactical** | 媒体・チャネル・手法別の運用詳細（"やり方"） | 厚（深い） | | **L4 Tools** | 個社製品・SaaS 詳細（[`knowledge/marketing/tool/`](../tool/) 参照） | 薄（揮発） | L4 は本体には書かず、[`knowledge/marketing/tool/`](../tool/) へリンクで逃がす。 ## 目次 ### Part 0 — 前付け - [`introduction.md`](introduction.md) — 目的・想定読者・PMBOK との関係・改訂ポリシー ### Part 1 — 前提 - [`foundations/principles.md`](foundations/principles.md) — マーケティング原則 - [`foundations/cycle.md`](foundations/cycle.md) — マーケティングサイクル - [`foundations/performance-domains.md`](foundations/performance-domains.md) — パフォーマンスドメイン - [`foundations/vocabulary.md`](foundations/vocabulary.md) — 用語と図式 - [`foundations/structural-issues.md`](foundations/structural-issues.md) — 補論: マーケティング組織の構造的問題 ### Part 2 — 領域別プレイブック（12 知識エリア） 内部 canonical では **12 知識エリア**として管理する。人間が目的から探しやすいよう、公開サイトと目次では次の上位カテゴリに束ねる。 #### 戦略・市場理解 - [`knowledge-areas/integration-strategy/`](knowledge-areas/integration-strategy/) — 統合・戦略 - [`knowledge-areas/intelligence/`](knowledge-areas/intelligence/) — 市場・顧客知能 - [`knowledge-areas/icp-positioning/`](knowledge-areas/icp-positioning/) — ICP・ポジショニング #### ブランド・価値設計 - [`knowledge-areas/brand-narrative/`](knowledge-areas/brand-narrative/) — ブランド・ナラティブ - [`knowledge-areas/product-marketing-jtbd/`](knowledge-areas/product-marketing-jtbd/) — プロダクトマーケティング・JTBD - [`knowledge-areas/pricing-offer/`](knowledge-areas/pricing-offer/) — 価格・オファー設計 #### プロモーション - [`knowledge-areas/content-channel/`](knowledge-areas/content-channel/) — コンテンツ・チャネル運用 - [`knowledge-areas/brand-narrative/pr-comms.md`](knowledge-areas/brand-narrative/pr-comms.md) — 広報・コミュニケーション #### エンゲージメント - [`knowledge-areas/demand-lifecycle/`](knowledge-areas/demand-lifecycle/) — 需要・ライフサイクル - [`knowledge-areas/content-channel/community-led-growth.md`](knowledge-areas/content-channel/community-led-growth.md) — コミュニティ主導の成長 #### 計測・基盤 - [`knowledge-areas/measurement-martech/`](knowledge-areas/measurement-martech/) — 計測・MarTech #### 組織・ガバナンス - [`knowledge-areas/org-capability/`](knowledge-areas/org-capability/) — 組織・能力 - [`knowledge-areas/stakeholder/`](knowledge-areas/stakeholder/) — ステークホルダー連携 - [`knowledge-areas/risk-compliance.md`](knowledge-areas/risk-compliance.md) — リスク・コンプライアンス・ブランドセーフティ ### Part 3 — 横断ガイド - [`cross-cutting/ai-in-marketing.md`](cross-cutting/ai-in-marketing.md) — AI / LLM のマーケティング活用 - [`cross-cutting/org-learning.md`](cross-cutting/org-learning.md) — 組織学習パターン - [`cross-cutting/tailoring.md`](cross-cutting/tailoring.md) — 文脈別テーラリング - [`cross-cutting/playbooks/`](cross-cutting/playbooks/) — 機能対別プレイブック - [`cross-cutting/reference-cycles.md`](cross-cutting/reference-cycles.md) — 参照ケース（事例） - [`cross-cutting/maturity-model.md`](cross-cutting/maturity-model.md) — Marketing OS 成熟度モデル 知識エリアは「マーケティングで管理すべき責任領域」であり、各章が マーケティングサイクル上の process を持つ。上位カテゴリは読みやすさのための入口で、canonical な責任境界は 12 知識エリア側に置く。 プロモーションは、新しい接点を作り、届け、流入を作る領域である。エンゲージメントは、接点後の関係を深め、CV・継続・推奨につなげる領域である。横断ガイドは、AI、組織学習、テーラリング、成熟度、機能対別運用のように複数の知識エリアへまたがって適用される補助軸である。媒体別・手法別の実務ノウハウは原則として該当する知識エリアの L3 Tactical に置き、横断ガイドには置かない。 ### 参照アセット - [`../glossary/glossary.md`](../glossary/glossary.md) — 用語集 - [`../framework/matrix.md`](../framework/matrix.md) — マーケティングサイクル × 12 KA マトリクス - [`../framework/itto.md`](../framework/itto.md) — ITTO 一覧 - [`../../base/skill-mapping.md`](../../base/skill-mapping.md) — skill ↔ process マッピング - [`../reference/references.md`](../reference/references.md) — 参考文献 ### Meta - [`../../base/authoring-conventions.md`](../../base/authoring-conventions.md) — 執筆規約（文体・テンプレ・分量） - [`../../base/marketing-os-migration-map.md`](../../base/marketing-os-migration-map.md) — `knowledge/base/` 既存ファイル → プレイブック行き先表 ## 改訂方針 - プレイブックは **`status: final` 章のみを安定版**とみなす。`draft` / `in-review` / `revised` は予告なく変更される。 - `visibility: public` 章のみが [`/knowledge/marketing/playbook/*`](https://cmoinc.jp/knowledge/marketing/playbook/) に公開される。 - 用語の追加・変更は必ず [`../glossary/glossary.md`](../glossary/glossary.md) を同時更新する。 --- title: はじめに chapter: "00" part: 0-front-matter status: revised visibility: public authors: - claude reviewers: [] revision: 0.2 updated: 2026-05-19 related-skills: [] related-chapters: - foundations/principles - foundations/cycle related-knowledge: [] --- # はじめに ## CMO Marketing OS Playbook の目的 **要点: 本書は、マーケティングを個人の経験則ではなく、組織で更新できる知識体系として扱う。** マーケティングの現場では、施策は増えても学びが残らないことがある。担当者が変わると過去の判断理由が消え、KPI は更新されず、顧客の声は次の意思決定に使われない。AI や外部パートナーを使うほど、誰が何を判断したのかも曖昧になりやすい。 CMO Marketing OS Playbook は、この状態を避けるための共通知識である。マーケティングサイクル、12 知識エリア、用語集、参考文献を Markdown で管理し、人間と AI エージェントが同じ前提を読めるようにする。 目的は、個別手法を置き換えることではない。広告運用、SEO、CRM、ブランディング、価格設計などの既存知識を、組織が学び直せる形で接続することである。 ## 想定読者 **要点: 本書は、マーケティング判断に関わる人間と AI エージェントの両方を読者とする。** 主な読者は次の通りである。 | 読者 | 読む目的 | |---|---| | CMO / 経営層 | マーケティングを事業判断・組織学習として設計する | | マーケター | 個別施策を マーケティングサイクル と知識エリアに接続する | | コンサルタント / パートナー | 支援先と同じ語彙で課題、仮説、成果物を扱う | | AI エージェント | 判断基準、用語、参照先を共有したうえで作業する | 初見の読者は、すべてを一度に読む必要はない。まず本章、[`foundations/principles.md`](foundations/principles.md)、[`foundations/cycle.md`](foundations/cycle.md) を読み、必要な知識エリアへ進む。 ## PMBOK との関係と差分 **要点: 本書は PMBOK の「知識エリア × プロセス群」の考え方を参考にするが、マーケティング向けに組み替える。** PMBOK は、プロジェクトを管理するための標準体系である。本書はその構造をそのまま移植しない。マーケティングは一度きりのプロジェクトではなく、顧客・市場・組織の変化に合わせて繰り返し更新される活動だからである。 継承するのは、知識を領域別に分け、プロセスと対応させる考え方である。具体的には、12 知識エリアを マーケティングサイクル（観測・データ収集 / 理解・分析する / 再構築 / 起動・実装する / 学ぶ）に接続する。 差分は、再構築 と 学ぶ段を明示する点にある。既存施策を続けるだけでなく、古い前提を再構築、結果を次の判断に書き戻す。この循環を中心に置く。 ## CMO Marketing OS（実行系）と Knowledge（知識系）の関係 **要点: Playbook は知識層、CMO Marketing OS はその知識を実行に落とす参照実装である。** 本書は知識層である。概念、原則、プロセス、用語、参考文献を定義する。 CMO Marketing OS は実行系である。Web サービス、skill、agent、workspace、診断機能として、この知識を実務で使える形に落とし込む。参照先は [`/services/marketing`](/services/marketing) である。 両者の責務は分ける。知識層は長く残る判断基準を書く。実行系は UI、ワークフロー、個別ツール連携を扱う。 ## 改訂ポリシー **要点: 安定度は `status`、公開可否は `visibility` で分けて管理する。** 各章は frontmatter で状態を示す。 | フィールド | 値 | 意味 | |---|---|---| | `status` | `draft` | 草稿。構成や内容が変わる可能性が高い | | `status` | `in-review` | レビュー中。章の骨格はあるが未確定 | | `status` | `revised` | レビューを反映済み。最終確認前 | | `status` | `final` | 安定版 | | `visibility` | `internal` | 内部向け | | `visibility` | `public` | 公開対象 | `status` と `visibility` は独立である。`final` でも内部に留める章があり、`draft` を内部で読むこともある。読者は、章を引用・転載・公開する前に必ず frontmatter を確認する。 ## 4 層モデル **要点: 本書は、戦略、プロセス、戦術、ツールを同じ本文に混ぜない。** 各章は最大 4 層で構成する。 | 層 | 扱うもの | 置き場所 | |---|---|---| | L1 Strategy | 章の問題設定、戦略判断、原則 | 各章の overview | | L2 Process | マーケティングサイクル × ITTO | 各知識エリアのプロセス節 | | L3 Tactical | 媒体・チャネル・手法別の実務 | 章内のタクティカル節、またはサブファイル | | L4 Tools | 個社製品や SaaS の詳細 | [`../tool/`](../tool/) | ツール仕様は変化が速い。そのため、本体には長く書かず、`knowledge/marketing/tool/` に逃がす。執筆規約の詳細は [`../../base/authoring-conventions.md`](../../base/authoring-conventions.md) を参照する。 ## 本書の読み方 **要点: まず原則と マーケティングサイクルを読み、その後は目的別に知識エリアへ進む。** - マーケティングサイクル から入りたい場合 → [`foundations/cycle.md`](foundations/cycle.md) - 特定の知識エリアを調べたい場合 → [`README.md`](README.md) の Part 2 目次 - 機能対との連携を見たい場合 → [`cross-cutting/playbooks/`](cross-cutting/playbooks/) - 用語を引きたい場合 → [`../glossary/glossary.md`](../glossary/glossary.md) - テーマから逆引きしたい場合 → [`../../base/INDEX.md`](../../base/INDEX.md) ## 今後の拡張論点 **要点: 本章は入口として最低限の形に整えたが、用語と公開範囲は引き続きレビュー対象である。** - PMBOK 7th edition の "原則 + パフォーマンスドメイン" 構造への接続をどこまで明示するか - 知識層の日本語表示を「ナレッジ」「知識ベース」「標準ガイド」のどれに寄せるか - 想定読者に、非マーケ職の経営メンバーをどこまで明示的に含めるか --- title: マーケティング原則 chapter: "01" part: 1-foundations status: revised visibility: public authors: - claude reviewers: [] revision: 0.4 updated: 2026-05-19 related-skills: - /listen - /release - /learn related-chapters: - foundations/cycle - knowledge-areas/stakeholder - cross-cutting/ai-in-marketing - cross-cutting/org-learning related-knowledge: - knowledge/marketing/framework/marketing-mindset.md - knowledge/marketing/framework/marketing-misconceptions.md - knowledge/marketing/playbook/foundations/structural-issues.md - knowledge/marketing/playbook/knowledge-areas/org-capability/responsibility-design.md --- # マーケティング原則 ## この章で解く問題 **要点: マーケティングを「やりっぱなし」にしないための共通ルールを決める。** マーケティングの失敗は、施策そのものの失敗だけではない。むしろ多いのは、施策を実行しても、組織に知見が残らないことである。 たとえば、次のような状態である。 - キャンペーンは増えるが、何を学んだかが次回に引き継がれない - CPA や CVR は改善しているが、そもそも追うべき顧客や KPI が古いままである - 社内で考えた ICP と、実際の顧客の声がズレている - 本番反映して終わり、結果が profile / playbook / glossary に書き戻されない - AI や外部業者の提案を採用したが、誰が何を判断したのかが残らない CMO Marketing OS Playbook の 7 原則は、こうした失敗を防ぐためのルールである。広告運用、SEO、CRM、ブランディングなどの個別手法を置き換えるものではない。それらを組織として学び続けるための土台である。 この章では、教科書的なマーケ理論（[Kotler](https://en.wikipedia.org/wiki/Philip_Kotler) 系の顧客起点・データ駆動・ファネル思考・ポジショニング等）とは別の層を扱う。教科書系は「マーケティングで何を考えるか」を示す。CMO Marketing OS Playbook の 7 原則は「組織がマーケティングをどう続け、どう学び直すか」を示す。両者は対立しない。 初めて読む場合は、まず 1.1、1.2、1.3、1.7 を読む。理論的背景は 1.5 にまとめるため、必要になってから読めばよい。 ## 七原則 **要点: 7 原則は、マーケティングを組織学習として回すための判断基準である。** 先に全体像を示す。 | 原則 | 一言でいうと | 防ぐ失敗 | |---|---|---| | 第 1 の原則: 組織学習としてのマーケティング | 施策の成否ではなく、学びが組織に残るかを見る | 施策単位の PDCA で終わる | | 第 2 の原則: 戦略レイヤーと最適化レイヤーの分離 | 前提を疑う仕事と、前提の中で改善する仕事を分ける | CPA / CVR 改善だけに閉じる | | 第 3 の原則: 既成の枠組みを疑う | 古い KPI・聖域・「ねばならない」を再構築候補にする | 過去の成功パターンを惰性で続ける | | 第 4 の原則: 顧客同期を独立に保つ | 社内仮説と顧客実態を別々に記録する | ICP と実顧客のズレが見えなくなる | | 第 5 の原則: 本番反映は学習ではない | 実行と書き戻しを分ける | 本番反映して終わる | | 第 6 の原則: AI 判断の責任を人間が持つ | AI 出力の採否と理由を人間が記録する | 「AI が言ったから」で流れる | | 第 7 の原則: 語の規律を持つ | 同じ語を同じ意味で使う | 成果・顧客・施策の意味が人によって違う | ### 第 1 の原則: 組織学習としてのマーケティング **要点: マーケティングは個別施策の集合ではなく、組織が学び続ける活動だ。** マーケティングは、市場や顧客の反応を組織として吸収し続ける活動である。個別の施策・チャネル・キャンペーンだけを単位にすると、知見が施策担当者の中に閉じやすい。 たとえば、LP 改善で CVR が上がっても、なぜ上がったのかが ICP profile や playbook に戻らなければ、次のチームは同じ学びを使えない。広告の検証で勝ちパターンが見えても、その前提が記録されなければ、担当者が変わった瞬間に失われる。 CMO Marketing OS Playbook が重視するのは、施策が一回うまくいったかではない。観測・データ収集 → 理解・分析する → 再構築 → 起動・実装する → 学ぶのサイクルを回し、学びを次回に使える形で残せるかである。 この原則が CMO Marketing OS Playbook の存在理由である。マーケ部門は施策単位で評価されやすい。その結果、起動・実装する（本番反映）に重みが偏り、学ぶ（書き戻し）が抜け落ちる。本書は「施策がうまくいったか」だけでなく、「学びが組織に残り、次の判断に使われるか」を中心の問いとして扱う。 理論的背景と事例は 1.5 にまとめる。実務での運用条件は 1.6 の補題として扱う。 ### 第 2 の原則: 戦略レイヤーと最適化レイヤーの分離 **要点: 「前提を疑う層」と「前提の中で最適化する層」は別物として扱う。** マーケには 2 つのレイヤーがある。 - **最適化レイヤー**: KPI・ICP・施策ラインナップをいったん固定し、入札、配信、クリエイティブ、導線などを改善する層 - **戦略レイヤー**: KPI・ICP・施策ラインナップそのものを疑い、必要なら組み替える層 広告アカウントの入札を調整するのは最適化である。そもそもその顧客を狙うべきか、CPA を主要 KPI にしてよいかを疑うのは戦略である。 両者を混同すると、組織は CPA や CVR の改善だけに閉じる。その KPI が正しいか、その ICP が今も有効か、そもそも続けるべき施策かを問わなくなる。 リアルタイム最適化系の方法（Adaptive Marketing）は本書を否定しない。それは最適化レイヤーで有効である。本書が強く扱うのは、その上にある戦略レイヤーである。 ### 第 3 の原則: 既成の枠組みを疑う **要点: 既成の KPI・聖域・「ねばならない」を機械的に並べ、再構築する段を独立に持つ。** 組織は時間とともに、引き継いだ KPI や看板施策や「ねばならない」に縛られる。これらを意識的に再構築する手段がないと、組織は同じ枠の中で最適化を続けるしかない。 これが 再構築段の存在理由である。再構築では、既存 KPI、聖域化した施策、業界慣習、過去の成功パターンを一度並べる。そのうえで、残すもの、止めるもの、作り直すものを分ける。 PDCA や OODA は「ループを速く回す」ことに向いている。ただし、既成枠の組み替えを独立の段としては持たない。CMO Marketing OS Playbook は、この再構築を マーケティングサイクルの中に明示的に置く。 ### 第 4 の原則: 顧客同期を独立に保つ **要点: ICP 仮説（内部）と顧客実態（外部）は、別の記録として分けて保つ。** ICP 仮説は「自社がこう考えている顧客像」である。顧客実態は「実際の顧客が話し、選び、迷っている内容」である。この 2 つを同じ場所に書くと、ズレが見えなくなる。 たとえば、社内では「中小企業の経営者向け」と考えているのに、実際の問い合わせは「現場責任者の業務改善」から来ているかもしれない。このズレが記録されなければ、施策は古い ICP のまま回り続ける。 Customer Sync を 4 つの観測対象（Team / Customer / Market / Performance）の一つとして独立に置けば、ズレを 再構築段の入力にできる。 これが、Marketing OS と汎用の組織学習ループ（OODA / PDCA）を分ける大きな違いである。詳細は [`cycle.md`](cycle.md) §2.8。 ### 第 5 の原則: 本番反映は学習ではない **要点: 起動・実装する（実行）と 学ぶ（書き戻し）は別物。実行しただけでは組織は学習しない。** 「本番反映した」は実行作業の完了である。組織学習の完了ではない。 LP を公開した、広告を配信した、メールを送った。これらは 起動・実装する段である。その結果から何を学び、どの前提を更新し、次回どこを変えるかを書き戻して初めて 学ぶ段になる。 書き戻しが起きない本番反映は、「やった」ではなく「組織学習に接続されていない実行」として扱う。 この原則を運用に落としたものが次の 2 つだ。 - **本番反映前チェックの省略不可項目**: オーナー / 計測 / ロールバックの 3 項目を本番反映の前に必ず満たす - **Evidence Level（E0〜E3）**: 学ぶ段で得た知見を検証度で分類する 詳細は [`cycle.md`](cycle.md) §2.5、§2.6。 ### 第 6 の原則: AI 判断の責任を人間が持つ **要点: AI 出力も毎回採用可否を判断する。判断と理由を記録する。** 「AI が言ったから」を判断の根拠にしない。AI / agent に作業を委ねても、判断責任は人間に残る。 重要なのは、AI を使ったかどうかではない。何を採用し、何を捨て、なぜそう決めたかが残っているかである。これを残さないと、成果が出ても失敗しても、判断の理由を学習できない。 責任の本質は処罰ではない。**意思決定権・仮説・検証条件・結果の扱い**の 4 点が同じ主体に結びついていることだ。これらが分散すると、責任は機能しない。 この原則は「個人の心がけ」ではなく**構造装置**として運用される必要がある。[Shaw & Nave (2026)](https://ssrn.com/abstract=6097646)（Wharton, 1,372 名 / 9,000+ 試行）は、AI が誤答でも 80% の人間がそれを採用し、**AI の誤りを訂正できた率はわずか 19.7%** という cognitive surrender を実証している。**「間違っている時に人は判断できなくてはいけない」を成立させるには、採否ログ・本番反映前チェック・Evidence Level を省略不可項目として OS に埋め込む**しかない。詳細は [`../cross-cutting/ai-in-marketing.md`](../cross-cutting/ai-in-marketing.md) §17.3、実証根拠は [`../../reference/references.md`](../../reference/references.md) §E.9.5。 ### 第 7 の原則: 語の規律を持つ **要点: 同じ語が違う意味で使われている状態を許さない。** 「マーケティング」「成果」「顧客」「施策」がチーム内で別の意味を指していれば、いくら マーケティングサイクルを回しても合意は形成されない。話している内容自体がすれ違っている。 たとえば、「成果」が売上を指すのか、商談数を指すのか、認知の増加を指すのかが曖昧なままでは、KPI の議論は進まない。「顧客」が購買者を指すのか、利用者を指すのか、決裁者を指すのかも同じである。 新しい語を導入するときは、必ず [`vocabulary.md`](vocabulary.md) と [`../appendices/glossary.md`](../../glossary/glossary.md) を同時に更新する。略語・同義語・翻訳語の扱いは [`vocabulary.md`](vocabulary.md) §4.6 に従う。 ## 七原則の階層構造 **要点: 7 原則はフラットに並ぶのではなく、依存関係を持つ。** ``` 第1の原則: 組織学習としてのマーケティング（最上位） │ ├─ 第2の原則: 戦略レイヤーと最適化レイヤーの分離 │ │ │ ├─ 第3の原則: 既成の枠組みを疑う │ │ │ └─ 第4の原則: 顧客同期を独立に保つ │ ├─ 第5の原則: 本番反映は学習ではない │ └─ 第6の原則: AI 判断の責任を人間が持つ 第7の原則: 語の規律を持つ（上記すべての前提） ``` - 第 1〜2 の原則: マーケの範囲を定義する（哲学） - 第 3〜4 の原則: そのための構造 - 第 5〜6 の原則: 運用の規律 - 第 7 の原則: すべてが成り立つための前提 下位原則は上位原則の**必要条件**であって、十分条件ではない。下位を満たせば上位が自動で成立するわけではない。 ## 既存マーケ思考との関係 **要点: CMO Marketing OS Playbook は既存のマーケ思考を否定しない。その上に運用層として重ねる。** ### Kotler / Drucker 系（一般的なマーケティング理論） [Drucker](https://en.wikipedia.org/wiki/Peter_Drucker) の "Marketing makes selling superfluous" 以来の一般的なマーケティング理論（顧客起点・ファネル思考・STP・ポジショニング・4P・パーソナライゼーション・F-Factor 等）は、CMO Marketing OS Playbook の前提である。 Kotler の「マーケティング 5.0 / 6.0」が描く AI・没入型メディアの活用も、CMO Marketing OS Playbook の範囲に重なる。本書はこれらを否定しない。 CMO Marketing OS Playbook が独自に扱うのは、これらの理論を**組織として継続して運用するための仕組み**である。施策単位の PDCA、閉じた最適化、責任の所在不在、学習の断絶を防ぐ部分だ。 文献は [`../appendices/references.md`](../../reference/references.md) を参照。 ### PDCA / OODA / Double-Loop Learning これらは汎用の組織学習ループだ。内部の意思決定サイクルを回すために設計されている。 マーケティングがこれらと違うのは、**意思決定の前に、顧客との継続的な同期が必要になる**点である。第 4 の原則（Customer Sync の独立化）と第 3 の原則（再構築の独立段）が、汎用ループとの違いを支えている。 ### Adaptive Marketing / Real-time Marketing リアルタイム最適化系の方法論は、CMO Marketing OS Playbook の最適化レイヤーに位置する（第 2 の原則）。本書はこれらを下位レイヤーとして含める。 実装は CMO Marketing OS Playbook 12 章（コンテンツ・チャネル運用）と 13 章（計測・MarTech）が扱う。 ## 理論的背景 **要点: 7 原則は組織学習論と市場志向研究を、マーケティング運用に落としたものである。** この節は補足である。7 原則の意味を先に把握したい読者は、1.6 へ進んでよい。 第 1 の原則は、組織学習論の蓄積に立っている。特に重要なのは、次の 5 系譜である。 - **Cyert & March / Argyris & Schön**: 組織はルーティンを更新することで学習する。Single-loop learning は行動の修正であり、Double-loop learning は前提の修正である。CMO Marketing OS Playbook の 再構築は、後者をマーケティングの中に明示的に置くための段である - **Senge**: 「学習する組織」は広く知られたが、標語化しやすい。CMO Marketing OS Playbook は文化論だけにせず、Customer Sync、再構築、学ぶの記録として扱う - **March**: 学習には Exploration（新しい可能性の探索）と Exploitation（既存の改善）のトレードオフがある。CMO Marketing OS Playbook の第 2 原則は、この 2 つを戦略レイヤーと最適化レイヤーとして分ける - **Nonaka & Takeuchi**: 暗黙知を形式知に変えることが組織知の蓄積につながる。CMO Marketing OS Playbook では、Evidence Level や playbook への書き戻しがこれに当たる - **Kohli & Jaworski / Slater & Narver / Day**: 市場志向研究は、市場情報の生成、共有、組織的応答を重視する。CMO Marketing OS Playbook の 観測・データ収集の 4 観測対象（Team / Customer / Market / Performance）は、この流れを実務に落としたものである - **Shaw & Nave (Cognitive Surrender / Tri-System Theory)**: 第 6 の原則の経験的根拠。Kahneman の System 1 / System 2 に **System 3（脳の外で動く人工的認知）** を加える枠組みで、AI 誤答時の人間の訂正率が 19.7% に留まることを示す。**AI 利用環境では「人が間違いを判断できる」状態は自動には維持されず、構造装置によって維持される**という運用論を支える 実証研究は、学習志向や市場志向が業績と関係することを示している。ただし、因果方向は単純ではない。学習する組織だから業績が良いのか、業績が良いから学習に投資できるのかは切り分けにくい。したがって、CMO Marketing OS Playbook では「学習組織は業績の十分条件である」とは置かない。より安全には、継続的なマーケティング改善のための必要条件として扱う。 事例で見ると、Domino's Pizza Turnaround は Customer Sync → 再構築 → 起動・実装する → 学ぶまでが一周した例である。顧客の厳しい声を受け止め、既存レシピを再構築、新商品として本番反映し、売上結果を書き戻した。一方で Kodak は、デジタル化による顧客行動の変化を把握しながら、フィルム事業の前提を再構築できなかった失敗例として読める。 この章では理論の詳細には深入りしない。詳しくは [`../cross-cutting/org-learning.md`](../cross-cutting/org-learning.md) と [`../appendices/references.md`](../../reference/references.md) §E.5 を参照する。 ## 七原則から導かれる運用補題 **要点: 7 原則を実務に落とすと、9 つの運用補題が出てくる。** 各補題は、原則を現場で使うための言い換えである。 ### 補題 A: 強みは初期仮説と反復検証の組み合わせから生まれる 強みは「探すもの」でも「反復後に残ったもの」でもない。次の 4 つの組み合わせとして**初期仮説を書き出す**ところから始まる。 - 既存資産 - 市場ポジション - 組織能力 - 学習速度 それを反復で検証・強化する。検証なしに「これが強みだ」と主張するなら、それはただの仮説だ。逆に、初期仮説なしで事後的に「発見した」と言うなら、それは結果論に過ぎない。 第 3 の原則（再構築）の運用補題。 ### 補題 B: 責任は処罰ではなく、判断から結果までを同じ主体が持つことである 責任の正体は、次の 4 点が**同じ主体に結びついていること**だ。 - 意思決定権 - 仮説 - 検証条件 - 結果の扱い 失敗時に人をすげ替えられることは責任ではない。それは結果に伴う処理の一形態に過ぎない。設計の観点で責任を捉えれば、平時から「誰が責任主体か」が見えている状態を作れる。 第 6 の原則の運用補題。 ### 補題 C: マーケの責任設計が難しいのは、因果を分けにくく成果が遅れて出るからだ セールスとマーケティングの違いは「個人 vs 統合」ではない。 - セールスは、誰のどの活動が成果に近かったかを比較的たどりやすい - マーケは、複数の接点が重なり、成果が出るまでの時間も長い マーケの KPI 設計が難しい本当の理由は「統合的だから」ではない。「**何が効いたかを分けにくく、効果が遅れて出るから**」である。 ここから、MMM・インクリメンタリティ測定・leading/lagging KPI のペア運用が必要になる。 第 1 と第 5 の原則の運用補題。 ### 補題 D: 失敗は情報取得コストとして設計する 「失敗できる小さな仕事は設計可能」だ。「失敗できない」のではなく、次の 4 つが未設計なだけである。 - 予算（情報取得目的で確保されているか） - 評価（仮説の質や撤退判断の速さが評価対象か） - 撤退条件（kill criteria が事前に書かれているか） - 学習ログ（残る仕組みがあるか） これら 4 項目が未設計の施策は、走らせる前に 再構築候補とする。 第 3 と第 5 の原則の運用補題。 ### 補題 E: KPI は 5 軸が揃って初めて KPI になる KPI として有効と判定するには、次の 5 軸が必要だ。 - **仮説チェーン**: P0（売上 / 利益）までの因果仮説が描けるか - **時間軸**: どの時間軸で動くか - **信頼度**: 仮説の確信度 - **検証方法**: A/B / holdout / MMM / geo / 自然観測のいずれか - **意思決定使途**: 動いたとき / 動かないとき、どの意思決定が起きるか 「P0 へのチェーンが描けるか」だけで判定すると、長期資産（ブランド・カテゴリ創造・指名検索・既存顧客の心理変化）が過小評価される。leading と lagging のペア運用が原則だ。 5 軸が埋まらない指標は、ダッシュボード上の数字に過ぎない。意思決定 KPI ではない。 第 5 の原則の運用補題。 ### 補題 F: 外部業者とは責任の境界を決める。責任そのものは渡さない 外部業者が引き受け可能なのは、実行責任・専門責任・説明責任の一部だ。次の 4 つは内部に残る。 - 事業責任 - 顧客価値責任 - ポジショニング責任 - 最終資源配分責任 健全な外部化の本質は「責任そのものを外部化する」ことではない。「どこまでを外部に任せ、どこからを内部が持つか」を言葉にして残すことだ。 第 6 の原則の運用補題。詳細は 14 章 組織・能力 / 20 章 機能対別プレイブック（Agency / Vendor）。 ### 補題 G: 認識同期は争点を見える化するが、それだけでは戦略は生まれない 観測・データ収集段の同期は、不一致を場に出すことで 再構築入力を作る。それが本来の役割だ。同期そのものが戦略を生み出すわけではない。 戦略は DRI（Directly Responsible Individual）が引き受ける選択だ。会議の合意だけで自然に生まれるものではない。 第 4 と第 6 の原則の運用補題。 ### 補題 H: テーラリングは妥協ではなく設計判断である マーケティングサイクルは状況（規模・成熟度・速度・リスク）に応じて短くしたり、詳しくしたりする。 テーラリングで大事なのは「**省略の理由を残すこと**」だ。「やらなかった」と「意図して外した」は別物として扱う。 詳細は 19 章 文脈別テーラリング。第 1 の原則の運用補題。 ### 補題 I: 成果は非線形であり、線形評価は施策の正誤を見誤る 多くのマーケ施策は、効果が**時間と熱量の累積で初めて見える**。正しい施策でも、短期では差分が見えない。逆に、間違った施策に時間を費やせば、累積した時間と熱量はすべて無駄になる。 線形の時間軸で施策の正誤を判定すると、次の 2 つの誤判定が同時に起きる。 - **偽陰性**: 正しい施策が「効果なし」と評価され、本来は継続すべきものが止まる - **偽陽性**: 間違った施策が「まだ時間が足りない」と擁護され、「とりあえずやっただけ」が積み上がる これが PDCA の本質的な難しさを生む。Plan / Do の質を Check の線形差分だけで評価すると、短期で差分が出ない施策はすべて否定されるか、すべて温存されるかの二極になる。 非線形性に対処する運用条件は次の 4 つだ。 - **時間軸を事前に明示する**: 何週 / 何四半期 / 何年で差分が見えるかを、本番反映前チェックの計測項目で先に決める - **検証方法を時間軸とセットで定義する**: 短期は leading 指標、長期は lagging 指標（補題 E） - **「間違いの早期検出」装置を組み込む**: 全期間を待たずに「正しい方向か」を判定するための中間指標を事前に置く - **撤退条件を時間軸別に書く**: 「3 ヶ月で leading が動かなければ撤退」「6 ヶ月で lagging が動かなければ撤退」のように段階的に書く 第 5 の原則と、補題 C・補題 E の運用補題。 ## アンチパターン **要点: 7 原則と補題に反する典型例。違反元を明示しておく。** - **施策単位 PDCA への逃避**（第 1 違反） — 個別施策の成否評価で組織学習を代替する - **閉じた最適化への逃避**（第 2 違反） — CPA / CVR / CTR の局所最適化に没頭し、前提を疑わない - **再構築不在**（第 3 違反） — 既成 KPI を疑わずに 起動・実装する段に進む - **再構築の儀式化**（第 3 違反） — 「再構築した」と言うだけで実際は残る - **Customer Sync の不在**（第 4 違反） — ICP 仮説と実績データだけで 観測・データ収集を済ませる - **観測・データ収集汚染**（第 4 違反） — 未検証の仮説を事実として profile に書く - **起動・実装する 偏重**（第 5 違反） — 本番反映で満足し、結果を書き戻さない - **計測の取りこぼし**（第 5 違反） — 本番反映を急ぎ計測同時着地を省略する - **学ぶの断絶**（第 5 違反） — 結果を書き戻さない。次サイクルが毎回ゼロから始まる - **AI 出力の丸のみ**（第 6 違反） — AI 出力を判断根拠にする - **AI 採否ログの欠落**（第 6 違反） — 何を採用し何を捨てたかが記録されない - **二重定義**（第 7 違反） — 「マーケティング」「成果」「施策」が同じ場で別の意味を指す - **強み信仰での施策増殖**（補題 A 違反） — 検証なしに保有を主張する強みを根拠に施策を増やす - **責任のすげ替え運用**（補題 B 違反） — 失敗時の処分で責任を擬装する - **失敗の前提排除**（補題 D 違反） — 予算が全額成果目的で組まれ、kill criteria が書かれない - **ダッシュボード KPI 化**（補題 E 違反） — 仮説チェーンも検証方法も意思決定使途もない指標を KPI と呼ぶ - **外部丸投げ**（補題 F 違反） — 事業責任・ポジショニング責任まで外部業者に引き受けさせる - **会議だけでの戦略合成**（補題 G 違反） — 同期会議だけで戦略が決まると期待する - **線形評価による施策誤判定**（補題 I 違反） — 非線形に効く施策を短期の差分なしで止める / 効かない施策を「時間が足りない」と擁護して「とりあえずやっただけ」を積み上げる 完全なアンチパターン一覧は 18 章 組織学習パターン で仕組みとして再整理する。 ## 関連 skill / agent **要点: 7 原則を支える Marketing OS の skill 群。** - **第 3 の原則（再構築）** — `/release`、`/insight consultant` - **第 4 の原則（Customer Sync）** — `/listen customer`、`/insight customer` - **第 5 の原則（本番反映 ≠ 学習）** — `/learn`（本番反映前チェックと Evidence Level の運用） - **第 6 の原則（AI 判断の責任）** — `/learn`（AI 採否ログの記録） Marketing OS は CMO Marketing OS Playbook の参照実装である（[`/services/marketing`](/services/marketing)）。skill ↔ process の完全な対応は [`../appendices/skill-mapping.md`](../../../base/skill-mapping.md) を参照。 ## 今後の拡張論点 - **七原則の数（5 / 7 / 10）** — PMBOK 7 は 12 原則を立てる。CMO Marketing OS Playbook は 7 で十分か、ステークホルダー連携や Tailoring を独立原則に昇格させて 9〜10 にすべきか - **第 7 の原則（語の規律）を原則とすべきか** — 規約に近いため、§4 Vocabulary に移して原則は 6 つにする選択肢もある - **補題（A〜I）の所在** — 本章に置くか、各 KA 章の X.5 / X.6 に分散させるか。本章集約は俯瞰性が高いが、章肥大化のリスクがある - **第 5 の原則の名称** — "本番反映 ≠ 学習" は分かりやすいが、本書では 起動・実装する / 学ぶ という章名で扱う。"起動・実装する / 学ぶ 分離" 等に統一すべきか - **第 2 の原則の "Adaptive Marketing" 用語** — 業界で揺れる用語（Real-time / Adaptive / Continuous Marketing）のうち、CMO Marketing OS Playbook では Adaptive を主表記とする運用でよいか - **Kotler の「マーケティング 5.0 / 6.0」との位置関係** — §1.4.1 で軽く触れたが、CMO Marketing OS Playbook は Kotler 6.0 の "AI 協働実装形" と位置づけるべきか、より独立した知識体系として書くか --- title: マーケティングサイクル chapter: "02" part: 1-foundations status: revised visibility: public authors: - claude reviewers: [] revision: 0.3 updated: 2026-05-20 related-skills: - /listen - /insight - /release - /next - /learn related-chapters: - foundations/principles - foundations/performance-domains - foundations/vocabulary - knowledge-areas/integration-strategy - knowledge-areas/stakeholder - cross-cutting/org-learning - cross-cutting/tailoring related-knowledge: - knowledge/marketing/framework/marketing-cycle.md - knowledge/marketing/playbook/foundations/structural-issues.md --- # マーケティングサイクル ## この章で解く問題 **要点: マーケティングのループは多数提案されてきたが、どれも「閉じた最適化」を防ぎきれない。マーケティングサイクルはこの欠落を埋めるために設計されている。** マーケティングの実務には PDCA、OODA、AARRR、RACE、Build-Measure-Learn、Adaptive Marketing など複数のループモデルが流通している。だが現場では次の状態が頻発する。 - 施策単位の PDCA が回るが、KPI と ICP は古いまま据え置かれる - A/B テストや入札最適化は走るが、そもそもその指標が事業にどう繋がるかを誰も問わない - 顧客の声は集まるが、社内仮説（ICP）の上書きには使われない - 本番反映で達成感を得るが、結果が次サイクルの前提を更新しない - AI が出した提案を採用しても、誰が何を判断したのかが消える これらはすべて、ループ自体は回っていても **前提の組み替えが起きていない** という同じ構造を持つ。既存の汎用ループ（PDCA / OODA / Double-Loop）はループ速度を上げることに最適化されており、前提再構築の段を独立に持たない。Adaptive Marketing 系は戦術最適化に強いが、戦略レイヤーを射程に入れない。 マーケティングサイクルは、この穴を埋めるための構造として設計されている。具体的には次の 3 つを構造的に組み込む。 - **Customer Sync の独立化**: 内部仮説（ICP）と外部実態（顧客の声）を別々に取り込む - **再構築段の独立化**: 既成 KPI・聖域・「ねばならない」を再構築する段を独立に持つ - **起動・実装すると 学ぶの分離**: 本番反映と書き戻しを別段として明示する 本章はこの 5 段の定義、各段の責務、ITTO、成立条件、他ループとの位置取りを扱う。理論的背景は §2.11、既存学派との詳細比較は §2.10、フレームワークカタログは §2.12 にまとめる。先に全体像を把握したい場合は §2.1 のこの導入と §2.2〜§2.7 を読み、必要になってから §2.10 以降に進むとよい。 ### マーケティングサイクルの全体像 **マーケティングサイクル** は、観測・データ収集 → 理解・分析する → 再構築 → 起動・実装する → 学ぶ からなる CMO Marketing OS Playbook の 5 段プロセス群である。すべての知識エリアはこの 5 段の上で動き、すべての process はいずれかの段に属する。 Marketing OS（[`/services/marketing`](/services/marketing)）は、この マーケティングサイクルを skill / agent / workspace / 診断として実装した参照実装である。本書では固有名を **マーケティングサイクル**、説明語を **5 段プロセス群** とする。 ``` 観測・データ収集 ─→ 理解・分析する ─→ 再構築 ─→ 起動・実装する ─→ 学ぶ ─┐ ↑ │ └────────────────────────────────────────────────────┘ （学ぶの終端は次サイクルの観測・データ収集の起点） ``` | 段 | 動詞 | 性格 | 役割 | |----|------|------|------| | **観測・データ収集** | 観測・データ収集 | 入力 | 4 つの観測対象（Team / Customer / Market / Performance）から認識・実態を取り込む | | **理解・分析する** | 理解・分析する | 出力 | 視点を切り替えて選択肢と判断材料を出す | | **再構築** | 再構築する | 認知の再構築 | 既成 KPI・聖域・「ねばならない」を機械的に列挙し、前提を組み替える余白を作る | | **起動・実装する** | 起動・実装する | 実行・本番反映 | セグメント × チャネル × コンテンツに実装し、計測同時着地で本番反映する | | **学ぶ** | 学ぶ | 還流 | 結果を ICP / ポジショニング / プレイブックに書き戻し、次サイクルの観測・データ収集の入力に変える | 5 段はそれぞれ独立した責務をもつ。いずれかが欠落すれば、サイクルは閉じた最適化に逃げ込む（詳細は §2.8）。 ## 観測・データ収集 ### 原則 マーケはチームの頭の中だけでは動かない。**4 つの独立した観測対象**を継続的に取り込み続けることが、すべての判断の起点になる。サイロの中で持っている情報は、組織にとって存在しないのと同じである。 ### 観測・データ収集の 4 つの観測対象 | 観測対象 | 内容 | 主なソース | |--------|------|----------| | **Team Sync**（内部認識） | メンバー間の言葉・前提・存在意義・優先順位 | サーベイ・対話・各メンバーの独立記述 | | **Customer Sync**（顧客同期） | 顧客の生の声・行動・反応・JTBD・離脱理由・刺さった言葉 | 営業ログ / サポート問い合わせ / レビュー / SNS 言及 / サイト行動 / 購買履歴 / 解約理由 / インタビュー | | **Market Sync**（市場・競合同期） | 競合の動き / プラットフォーム仕様 / 業界トレンド | 外部揮発情報、競合 SERP、広告ライブラリ | | **Performance Sync**（自社実績同期） | 過去の成功 / 失敗 / 現状数値 / ベースライン | 解析ツール / 広告管理画面 / 売上 / 解約レポート | ### Customer Sync を独立源として置く理由 顧客情報を「ICP」（内部仮説）と「実績データ」（メトリクス）だけに吸収すると、構造的に **「ICP 仮説 ≠ 実際の顧客」のズレを検出できない**。Customer Sync を独立源として置くことで、次の 3 つが構造的に成立する: - 仮説（ICP）と実態（Customer Sync）のズレが自動的に 再構築段の入力になる - 顧客の生の言葉が KPI ノイズに埋もれずに残る - 「自社の最適は誰の最適か」が常に問い直される構造が組み込まれる これがマーケ OS と汎用組織学習ループ（OODA / PDCA）を分かつ最大の構造的違いである（詳細は §2.8）。 ### 観測・データ収集の投入物・手法と道具・産出物（ITTO） - **投入物（Inputs）**: チーム内独立記述 / 営業・サポート接点ログ / 解約・レビュー / 競合 SERP / 売上・実績数値 - **手法と道具（Tools & Techniques）**: 4 つの観測対象インタビュー、Voice of Customer 構造化、競合スタック調査、ベースライン記録 - **産出物（Outputs）**: 4 つの観測対象レポート、ICP 仮説 vs 実態差分、Performance ベースライン、不一致リスト（再構築入力候補） ### 成立条件 - チーム内で「マーケティング」が指す範囲が一致している - 各メンバーが自分の役割を職能ではなく事業課題への寄与で語れる - Customer Sync が独立した記録として残っている（実績メトリクス に埋もれていない） - 直近の顧客接点ログが構造化された記憶として残っている - 担当者の頭の中だけにある情報がない（属人化が解除されている） ### 失敗モード - **観測・データ収集丸投げ**: 「とにかくいい感じで」と AI に投げる。AI は平均的な回答しか返せない - **Customer Sync の不在**: ICP 仮説と 実績データ だけで 観測・データ収集を済ませ、顧客の生の声を構造的に取り込まない。「ICP ≠ 実態」を検出できなくなる - **観測・データ収集汚染**: 検証されていない仮説を事実として書く。以降すべての出力が歪む ## 理解・分析する ### 原則 データそのものは理解・分析ではない。**「何を理解しているか／していないか」**「**どの視点で何を理解・分析するか**」を意識的に切り替えなければ、観測・データ収集で集めたシグナルは雑音のまま終わる。漠然とした問いには漠然とした答えしか返らない。 ### 理解・分析するの 4 視点 | 視点 | 立ち位置 | 何を出すか | |------|---------|----------| | **CEO** | 上から | 経営インパクト・戦略整合・投資判断 | | **Consultant** | 外から | 第三者の率直な評価・ゼロベース提案 | | **Gemba**（現場） | 下から | 実行可能性・現場の暗黙知・実装制約 | | **Customer** | 受け手 | 顧客の言葉・購買決定要因・離脱理由 | ### 良い理解・分析の構造 良い理解・分析は以下の 5 要素を明示してから出す: 1. **誰の視点で**（CEO / Consultant / Gemba / Customer） 2. **何を**（評価 / 制作 / 分析 / 比較 / 予測） 3. **どの深さで**（案出し 3 つ / 完成品 / レビュー付き / A/B パターン） 4. **何を判断基準に**（ICE / ROI / ブランド整合 / CVR 予測） 5. **どの形式で**（表 / チェックリスト / コード / 原稿） ### 理解・分析のサブタイプ | サブタイプ | 何をするか | |----------|----------| | **Design** | ゼロから設計（戦略 / ICP 仮説 / LP 構成案 / キーワード戦略） | | **Review** | 既存成果物を評価（コピー / LP CVR / 広告整合 / 経営インパクト） | | **Analytics** | データから理解を更新する | ### 投入物・手法と道具・産出物（ITTO） - **投入物（Inputs）**: 観測・データ収集段の 4 つの観測対象レポート、ICP 仮説、Positioning ステートメント - **手法と道具（Tools & Techniques）**: 4 視点切替、JTBD 抽出、ギャップ分析、ICE / RICE 評価 - **産出物（Outputs）**: 選択肢リスト、判断材料、JTBD 言語化、Positioning ギャップ仕様 ### 失敗モード - **理解・分析するの過剰**: 1 つのプロンプトで 10 個聞く。どれも中途半端になる。1 サイクル 1 目的 - **理解・分析する 量産**: 観測・データ収集段の不一致を 再構築に渡さず、理解・分析する段で「正解の戦略」を量産する。"より洗練された無意味さ" を再生産する ## 再構築 ### 原則 マーケ組織の最大のボトルネックは、引き継いだ KPI・看板施策・「ねばならない」が思考を縛ること。これらを意識的に再構築しない限り、前提の組み替えは起きない。 > **再構築は本番反映ではない**。本番反映は 起動・実装するの責務である。再構築は**認知・前提・組織心理の再構築**である。 ### 再構築の対象 - 引き継いだ KPI（P0〜P3 整合性で篩にかけ、P3 × Low Sensitivity を撤退候補とする） - 走っている施策（感応度 High / Mid / Low で篩にかけ、Low を撤退候補とする） - 聖域（過去の意思決定 / 看板施策 / 既存 ICP 像 / 慣習チャネル） - 観測・データ収集段の Customer Sync が示す**実態**と既存 ICP 仮説のズレ — 仮説の方を再構築候補とする - 個人が抱えている負荷 ### 投入物・手法と道具・産出物（ITTO） - **投入物（Inputs）**: 観測・データ収集段の不一致リスト、現行 KPI、現行施策、現行 ICP 仮説 - **手法と道具（Tools & Techniques）**: 機械的列挙（聖域 / 「ねばならない」/ 引き継ぎ KPI）、P0–P3 篩、感応度 High/Mid/Low 篩、ゼロベース問い直し - **産出物（Outputs）**: 再構築決定リスト、残す KPI / 施策 / 仮説、前提を組み替える余白 ### 成立条件 - 「現状の KPI に縛られない場合、別の指標になりうるか」が議論された - 「聖域として触れていなかった前提」が機械的に列挙された - P3 × Low（経営に紐付かず施策にも反応しない指標）がゼロになっている - 既存 ICP 仮説 vs Customer Sync 実態のズレが再構築候補に含まれた - 「ねばならない」と「やりたい」が区別されている - 捨てた後に「最後まで残る一本」が言語化されている ### 重要な制約 再構築は人間にしか引き受けられない判断である。AI は「聖域」「前提」「ねばならない」を機械的に列挙できるが、**実際に再構築の決断**は人間に残る。組織政治を超えて「これは違う」と言うのは AI の役割ではない。 ### 失敗モード - **再構築不在**: 「現状の KPI を疑う」プロセスを飛ばして 起動・実装する段に進む。既成の失敗パターンを再生産する - **再構築の儀式化**: 「とりあえず再構築した」と言うだけで、引き継ぎ KPI も看板施策も実際は残る。再構築したのは言葉だけ - **「強み信仰」での施策増殖**: 再構築で篩にかけずに 起動・実装する段で施策を増やし続ける。「何かやらなきゃ」と「上手く行かなそう」の挟撃に対する防衛反応 ## 起動・実装する ### 原則 自社プロダクトの実力に適合しない目標は、いくら立派でも機能しない。**自分たちのプロダクトに何ができるかを正確に理解した上で**、適した目標とステップに再構成し、本番環境で動く形に落として、計測可能な状態で稼働させる。 > マーケティングとは最適化である。起動・実装するはこの定義を段階として動詞化したものである。**正解は一つではない**。 ### 起動・実装するの責務 - **選ぶ**: 複数案の中から自社の文脈に最も合うものを選択する - **削る**: AI が出しがちな冗長な要素・汎用的な装飾を削る - **足す**: AI が持ちえない現場の暗黙知・1 次情報を足す - **本番反映する**: 本番環境に反映する - **計測する**: 既存値と差分が測れる状態を作る ### 本番反映前チェック 本番反映の前に以下 7 項目を満たす。これは重い承認プロセスではなく、**本番反映・計測・責任の所在を同時に成立させるための軽量な確認手順**である。 | 確認項目 | 確認すること | |---|---| | **オーナー** | 結果に責任を負う個人が 1 名決まっているか。チーム名だけで済ませていないか | | **範囲** | 何を出すか / 出さないか、対象セグメント、対象チャネル、対象期間が明確か | | **予算** | 媒体費・制作費・工数・外注費の上限が決まっているか。超過時の判断者がいるか | | **リスク** | ブランド・法務・顧客体験・計測・オペレーション上のリスクを列挙したか | | **計測** | 反映前の既存値、判定指標、観測期間、計測方法、成功 / 撤退条件が決まっているか | | **承認** | ブランド・法務・予算・実装の承認が必要な場合、誰がいつ承認したか残っているか | | **ロールバック** | 何が起きたら止めるか、止める権限者、元に戻す方法が決まっているか | このうち **オーナー / 計測 / ロールバック** は状況によらず省略不可である。他 4 項目は規模・成熟度・速度・リスクに応じてテーラリングできる（詳細は [`../cross-cutting/tailoring.md`](../cross-cutting/tailoring.md)）。 複数人・複数日・外部依存・承認・高リスクを含む施策では、本番反映前チェックに加えて実行管理成果物（実行計画 / ステークホルダーマップ / リスク登録簿 / 変更履歴 / リソース計画）を併用する。詳細は [`../knowledge-areas/integration-strategy/`](../knowledge-areas/integration-strategy/) を参照。 ### 投入物・手法と道具・産出物（ITTO） - **投入物（Inputs）**: 理解・分析する段の選択肢、再構築段の残す KPI / 施策、自社実力・リソース・制約 - **手法と道具（Tools & Techniques）**: 本番反映前チェック、計測タグ実装、A/B 設計、既存値の記録 - **産出物（Outputs）**: 本番反映、計測同時着地、反映前の既存値の記録、承認ログ ### 進行不可（No-Go）条件 以下のいずれかに該当する場合、起動・実装する 未成立として扱う。例外的に本番反映する場合も例外理由を残す: - オーナー不在 - 範囲不明 - 計測不在 - リスク未確認 - 承認不在（承認が必要な施策の場合） - ロールバック不在 本番反映前チェックを通っていない本番反映は、実行作業としては完了していても 学ぶ段で比較・責任・再現ができない。「やった」ではなく「組織学習に接続されていない実行」として扱う。 ### 失敗モード - **起動・実装する 偏重（本番反映の欠落）**: レビューレポートを読んで満足する。本番反映がなければ何も変わらない - **計測の取りこぼし**: 本番反映を急ぎ、計測タグ・既存値の記録を省略する。学ぶ段で比較対象を失う ## 学ぶ ### 原則 本番反映した結果は、**書き戻されて初めて次サイクルの前提**になる。書き戻されない学びは個人の頭の中にだけ残り、組織知にならない。学ぶ は単なる「振り返り」ではなく、**次サイクルの観測・データ収集の入力を能動的に作る段階**である。 ### 4 軸での整理 本番反映後の結果を以下 4 軸で整理する: - **Funnel Conversion**: ファネル段階ごとの転換率変化 - **Segment Response**: セグメント別の反応差 - **Attribution**: チャネル・接点の寄与 - **Unit Economics Update**: LTV / CAC / Payback の更新 ### Evidence Level（知見の格上げ基準） 学ぶ段で扱う情報は、検証度に応じて E0〜E3 に分類する: | Level | 定義 | profile 反映 | 例 | |---|---|---|---| | **E0: Hypothesis** | 未検証の仮説・解釈・アイデア | 不可 | 「この訴求は刺さるはず」 | | **E1: Observation** | 単発の観測。顧客の声、1 施策の結果、少数サンプル | 不可 | インタビュー 1 件、広告 1 本の反応 | | **E2: Repeated Signal** | 複数接点・複数施策・十分な期間で同じ傾向が再現 | 承認後に可 | 複数商談で同じ反論、2 週間以上の広告傾向 | | **E3: Validated Learning** | 数値・定性・顧客行動が揃い、反証条件も確認した検証済み知見 | 可 | ICP の更新、Positioning の修正、真の ROAS 係数 | E0 / E1 は次サイクルの前提を汚染するため profile に書かない。E2 は承認後に反映、E3 は検証済み知見として反映できる。Evidence Level は反証が出た場合に下げられる。 ### AI 採否ログ AI が出した提案のうち何を採用し何を捨てたか、なぜかを 学ぶ段で必ず残す。これは「AI が言ったから」を判断根拠にしないための構造的歯止めである。詳細は [`../foundations/principles.md`](principles.md) の Principle 4「AI Decision Accountability」を参照。 ### 投入物・手法と道具・産出物（ITTO） - **投入物（Inputs）**: 起動・実装する段のベースライン、本番反映後の数値・定性、AI 出力ログ - **手法と道具（Tools & Techniques）**: 4 軸整理、Evidence Level 判定、書き戻し、採否ログ - **産出物（Outputs）**: 検証済み知見、profile 更新、次サイクルの観測・データ収集の入力、AI 採否ログ ### 成立条件 - 結果の数字と定性が両方残っている - 「うまくいった理由 / うまくいかなかった理由」が検証済みの言葉で書かれている - Customer Sync 側に新しい知見が書き戻されている（数値メトリクスだけで終わっていない） - 次サイクルの観測・データ収集に渡す引き継ぎ事項が明文化されている - AI 出力の採否ログが残っている ### 失敗モード - **学ぶの断絶**: 本番反映した施策の結果を書き戻さない。次サイクルが毎回ゼロから始まる - **profile 汚染**: E0 / E1 を profile に直書きする。以降すべての判断が歪む ## サイクル間遷移と Canonical Flow ### サイクル間遷移 学ぶの終端は次サイクルの観測・データ収集の起点になる。具体的には: - **検証済み知見（E3）** → profile に反映 → 次サイクルの観測・データ収集の 4 つの観測対象の前提を更新 - **残課題・新仮説** → 次サイクルの観測・データ収集に引き継ぎ事項として明示 - **AI 採否ログ** → 次サイクル 再構築で「採用したが効かなかった AI 提案」を再構築候補に 「学ぶ から 観測・データ収集に渡る引き継ぎ事項が空白」であれば、サイクルは閉じている。 ### Canonical Flow（推奨実行順） 初回プロジェクトの典型的な進行: 1. **workspace 立ち上げ** — 対象事業 / プロダクトのスコープ確定 2. **観測・データ収集 / Team Sync** — 組織情報・ブランド・workspace 固有情報の独立記述と合成 3. **観測・データ収集 / Customer Sync** — 顧客接点ログの構造化 4. **観測・データ収集 / Market Sync** — 競合・プラットフォーム・市場の揮発情報取得 5. **理解・分析する** — 視点切替で選択肢を出す 6. **再構築** — 既成 KPI / 聖域 / 「ねばならない」を機械的に列挙して篩 7. **起動・実装する** — 本番反映前チェックの後に本番反映、計測同時着地 8. **学ぶ** — 結果を 4 軸で整理、Evidence Level 判定、書き戻し、次サイクルの観測・データ収集に渡す 途中で不足が見つかれば前段に戻る。`/next` skill は現在地と次の一歩を提示する。 ## マーケ OS と汎用組織学習ループの構造的差異 マーケティングサイクルは OODA / PDCA / Double-Loop Learning のリブランドではない。次の 3 つの構造的差異が、マーケ OS を成立させている。 ### Customer Sync の独立化 汎用ループは内部の意思決定サイクルを回すためのものである。マーケティングがこれらと違うのは、**意思決定の前提として「顧客との継続的な同期」を構造に埋めなければ機能しない**ことである。Customer Sync を 4 つの観測対象の一つとして独立に置くことで、ICP 仮説と顧客実態のズレが構造的に 再構築入力になる。 ### 再構築段の独立化 PDCA / OODA は「ループを速く回す」ことに最適化されており、**既成枠の組み替え**を独立の段として持たない。再構築を独立段として死守することで、**閉じた最適化**（既存 Adaptive Marketing / Real-time Marketing 系統の戦術最適化高速化）と分離する。 ### 起動・実装すると 学ぶの分離 汎用ループの "C/Check" や "D/Decide" は実行と学習の境界が曖昧になりやすい。起動・実装すると 学ぶ段を明示的に分離することで、「本番反映した = 学習した」という誤認を構造的に防ぐ。書き戻しが起きない 本番反映は学習に接続されていないものとして扱う。 ### 開かれた最適化と閉じた最適化 マーケティングサイクルが目指すのは「**開かれた最適化**」である: - **閉じた最適化** — 自部署で観測できる特定指標（CPA / CVR / CTR / PV 等）だけをループに入れる戦術最適化。前提（KPI・ICP・施策ラインナップ）は固定で、運用パラメータだけが動く。**機能不全のマーケ組織はほぼ例外なくここに逃げ込んでいる** - **開かれた最適化** — 顧客・市場・現場・経営・実績の全階層の声を入力にし、前提自体（KPI・ICP・施策・聖域）を最適化対象に含める。観測・データ収集の 4 つの観測対象 + 再構築で前提を組み替える + 学ぶ段で結果を前提に書き戻す、という マーケティングサイクルの構造そのもの 5 段はこの開かれた最適化を組織が継続できる形に動詞化したものである。 ## 関連知識エリアとの接続 ### マーケティングサイクル × 12 KA マトリクス マーケティングサイクルはプロセス軸である。これに直交するのが **12 知識エリア**（KA）であり、マーケティングサイクル × 12 KA の交差点に process が定義される。 12 知識エリア: - 05 統合・戦略 - 06 市場・顧客知能 - 07 ICP・ポジショニング - 08 ブランド・ナラティブ - 09 プロダクトマーケティング・JTBD - 10 価格・オファー設計 - 11 需要・ライフサイクル - 12 コンテンツ・チャネル運用 - 13 計測・MarTech - 14 組織・能力 - 15 ステークホルダー連携 - 16 リスク・コンプライアンス・ブランドセーフティ 各 KA の詳細は [`../README.md`](../README.md) の Part 2 目次から参照する。全体マップは [`../appendices/matrix.md`](../../framework/matrix.md)、各 process の ITTO は [`../appendices/itto.md`](../../framework/itto.md) に集約する。 ### 観測・データ収集段のカバレッジチェック 観測・データ収集段では「自社のマーケが**どの KA をカバーできていて、どこが空白か**」を 12 KA で点検する。空白 KA は次サイクルの観測・データ収集の入力 / 再構築候補になる。 ## 既存の学派・伝統との関係 **要点: マーケティングサイクルは既存ループモデルを否定しない。それぞれが解こうとした問題を一覧化したうえで、CMO Marketing OS Playbook が独自に解く層を示す。** マーケティング実務で参照される主要ループ・プロセスモデルを、年代と主目的で並べる。 | モデル | 出典・主提唱者 | 年代 | 主目的 | マーケティングサイクルとの位置取り | |---|---|---|---|---| | **PDCA**（Plan–Do–Check–Act） | Shewhart → Deming | 1939 / 1950s | 製造工程の品質管理 | 5 段の 起動・実装する / 学ぶ段を細分化したものに相当。前提の再構築は含まれない | | **OODA**（Observe–Orient–Decide–Act） | John Boyd | 1976 | 軍事・対敵意思決定の高速化 | 観測・データ収集 + 理解・分析する + 起動・実装する段に圧縮されたモデル。再構築 / 学ぶが独立せず、書き戻しが構造化されない | | **Double-Loop Learning** | Argyris & Schön | 1974 | 組織が前提を更新する条件 | 5 段の 再構築に対応する概念的基盤。プロセス段としては実装されていない | | **Experiential Learning Cycle** | David Kolb | 1984 | 個人学習の循環構造 | 学ぶ段の理論的下敷き。組織レベルへの拡張は別途必要 | | **Lean Startup / Build–Measure–Learn** | Eric Ries | 2011 | プロダクト仮説検証 | 5 段の 起動・実装する / 学ぶ段を素早く回すモデル。再構築段は明示されない | | **AARRR**（Acquisition–Activation–Retention–Referral–Revenue） | Dave McClure | 2007 | 需要・ライフサイクル分析 | プロセス軸ではなくファネル軸。マーケティングサイクルの 起動・実装する / 学ぶ 内の指標フレーム | | **RACE Planning**（Reach–Act–Convert–Engage） | Dave Chaffey / Smart Insights | 2010 | デジタルマーケ計画 | 起動・実装する段のチャネル設計フレーム。再構築は射程外 | | **Marketing Funnel** | E. St. Elmo Lewis（AIDA, 1898）→各種 | 1898〜 | 認知から購買への線形 | マーケティングサイクルの 起動・実装する / 学ぶ段で使うファネル指標。プロセス自体ではない | | **Kotler の 5 段マーケティングプロセス** | Philip Kotler | 1967〜 | 戦略策定の標準手順（R, STP, MM, I, C） | マーケティングサイクルが 再構築 と Customer Sync を独立化した上位互換と位置づけられる | | **Growth Loops** | Reforge / Brian Balfour | 2018 頃 | 自己拡張型成長メカニズム | 起動・実装する内のチャネル / プロダクト連携の設計手法。サイクル全体の前提組み替えは扱わない | | **Flywheel** | HubSpot / Brian Halligan | 2018 | 顧客起点の循環的成長 | マーケティングサイクルの「学ぶ → 観測・データ収集」遷移に近いが、再構築段を持たない | | **Agile Marketing / Scrum** | 2010s | 2010s | 短いイテレーションでの実装 | 起動・実装する段の運用形態の一つ。戦略レイヤーは別途必要 | | **Adaptive Marketing** | Forrester | 2010s | リアルタイム最適化 | 5 段の最適化レイヤー（起動・実装する）に含まれる。戦略レイヤーは射程外（[`principles.md`](principles.md) Principle 2） | | **Marketing 5.0 / 6.0** | Philip Kotler 他 | 2021 / 2024 | AI / 没入型メディア統合 | マーケティングサイクル と相補的。Marketing OS は Kotler 6.0 の "AI 協働実装形" の一形態と読める | | **Theory of Change** | Carol Weiss 他（プログラム評価） | 1990s〜 | 介入から成果までの因果連鎖 | 13 計測・MarTech の KPI 設計（補題 E）の基礎概念 | このうち PDCA / OODA / Double-Loop の構造的差異は §2.8 で詳述する。本節は landscape 全体の地図を提供することを目的とし、各モデルを否定しない。マーケティングサイクルが他と異なるのは、**Customer Sync と 再構築を独立段として強制する**点である。 ## 理論的背景 **要点: マーケティングサイクルは組織学習論・市場志向研究・プロダクト開発論を、マーケティング運用に落としたものである。** この節は補足である。先に §2.12 フレームワークカタログや §2.13 運用補題を見ても構わない。 ### 組織学習論 - **Cyert & March（1963）"A Behavioral Theory of the Firm"**: 組織はルーティンを更新することで学習する。CMO Marketing OS Playbook の 学ぶ段の理論的基礎 - **Argyris & Schön（1974, 1978）**: Single-loop（行動修正）/ Double-loop（前提修正）の区別。再構築段はマーケティングに Double-loop を組み込むための装置である - **Kolb（1984）"Experiential Learning"**: Concrete Experience → Reflective Observation → Abstract Conceptualization → Active Experimentation の循環。学ぶ段の 4 軸整理（Funnel / Segment / Attribution / Unit Economics）はこの「振り返り → 概念化」段の具体化 - **Senge（1990）"The Fifth Discipline"**: 学習する組織の 5 規律（システム思考・自己マスタリー・メンタルモデル・共有ビジョン・チーム学習）。CMO Marketing OS Playbook は文化論ではなく Customer Sync / 再構築 / 学ぶの **記録**として運用に落とす - **Nonaka & Takeuchi（1995）"The Knowledge-Creating Company"**: SECI モデル（Socialization / Externalization / Combination / Internalization）。観測・データ収集 → 理解・分析する → 起動・実装する → 学ぶの流れに対応し、Evidence Level（E0〜E3）は暗黙知から形式知への昇格度を表す ### 市場志向研究 - **Kohli & Jaworski（1990）"Market Orientation"**: 市場情報の生成（intelligence generation）/ 共有（dissemination）/ 応答（responsiveness）の 3 要素。マーケティングサイクルの 観測・データ収集 → 理解・分析する → 起動・実装する段にほぼ対応する - **Slater & Narver（1995）"Market Orientation and the Learning Organization"**: 市場志向と学習志向の統合。CMO Marketing OS Playbook が両者を構造化して 5 段に埋め込む - **George Day（1994）"The Capabilities of Market-Driven Organizations"**: 市場連動を組織能力として扱う視点。14 章 組織・能力 の理論的下敷き ### プロダクト開発・適応論 - **Boyd（1976）"OODA Loop"**: 高速意思決定の概念的祖。5 段は OODA を否定しない（[`principles.md`](principles.md) Principle 2 の最適化レイヤーで OODA は有効） - **Ries（2011）"The Lean Startup"**: Build–Measure–Learn / Pivot。起動・実装する / 学ぶのループ運用に影響。再構築は明示しないが Pivot 概念は近接する - **March（1991）"Exploration and Exploitation in Organizational Learning"**: 探索と活用のトレードオフ。第 2 原則（戦略 vs 最適化レイヤー分離）の理論基盤 ### 経験的検証と注意点 市場志向・学習志向と業績の関係は数多くの実証研究で確認されている（Kirca et al. 2005 のメタ分析 など）。ただし因果方向は単純ではない。学習する組織だから業績が良いのか、業績が良いから学習投資できるのかは分離が難しい。したがって、CMO Marketing OS Playbook は「学習組織は業績の十分条件」とは置かない。**継続的なマーケティング改善のための必要条件**として扱う。 引用文献の詳細は [`../appendices/references.md`](../../reference/references.md) §E.5 を参照。 ## 主要フレームワーク・手法カタログ **要点: マーケティングサイクルは既存フレームワークを取り込んで運用する器である。各段で使われる主要フレームワークを一覧化する。** 各フレームワークは「どの段で使うか」「何を出すか」を併記する。すべてを使う必要はない。文脈に応じて選ぶ（テーラリングは [`../cross-cutting/tailoring.md`](../cross-cutting/tailoring.md)）。 ### 観測・データ収集段で使うフレームワーク | フレームワーク | 出典 | 何を出すか | |---|---|---| | **Voice of Customer（VoC）構造化** | 各種品質工学・UX 研究 | 顧客の生の声をテーマ・頻度で整理 | | **Jobs To Be Done（JTBD）インタビュー** | Christensen / Klement | 顧客が雇う仕事の言語化 | | **N1 分析** | 西口一希 | 1 人の顧客から仮説を抽出 | | **5W2H ヒアリング** | 古典的調査手法 | 接点の事実を構造化 | | **Net Promoter Score（NPS）コメント分析** | Reichheld | 推奨意向と理由の対応付け | | **競合 SERP / 広告ライブラリ調査** | デジタル時代の常套 | 競合の言語・チャネル戦略の観察 | | **顧客離脱分析（Churn Reason Codes）** | SaaS 業界標準 | 解約・離脱の構造化 | ### 理解・分析する段で使うフレームワーク | フレームワーク | 出典 | 何を出すか | |---|---|---| | **4 視点切替**（CEO / Consultant / Gemba / Customer） | Marketing OS 固有 | 立ち位置を変えた多面評価 | | **JTBD / Outcome-Driven Innovation** | Tony Ulwick | 達成すべき成果と評価軸の特定 | | **STP**（Segmentation–Targeting–Positioning） | Kotler | ターゲットとポジション選択 | | **ICE / RICE スコアリング** | Sean Ellis / Intercom | 施策の優先度評価 | | **Strategy Map / Balanced Scorecard** | Kaplan & Norton | 戦略仮説の可視化 | | **Scenario Planning** | Royal Dutch Shell 系譜 | 将来分岐のストレステスト | ### 再構築段で使うフレームワーク | フレームワーク | 出典 | 何を出すか | |---|---|---| | **Stop-doing リスト** | Jim Collins | 止める活動の明示 | | **Premortem** | Gary Klein | 失敗を仮想体験して前提を疑う | | **Zero-Based Strategy** | Bain / BCG | ゼロから組み直すという思考実験 | | **OKR の四半期再設定** | Doerr | KPI 自体の組み替え機会 | | **Blue Ocean / Eliminate-Reduce-Raise-Create** | Kim & Mauborgne | 業界慣習の機械的列挙 | | **Sacred Cow Hunt** | 組織開発系 | 聖域の発見と命名 | ### 起動・実装する段で使うフレームワーク | フレームワーク | 出典 | 何を出すか | |---|---|---| | **4P / 7P Marketing Mix** | McCarthy / Booms & Bitner | 実行要素の網羅 | | **AARRR Pirate Metrics** | McClure | 需要ファネル設計 | | **RACE Planning** | Chaffey / Smart Insights | デジタルチャネル運用設計 | | **Growth Loops** | Reforge | 自己拡張型施策の設計 | | **A/B Testing / Multi-Armed Bandit** | 統計実験設計 | 仮説検証 | | **Agile / Scrum / Kanban** | Schwaber & Sutherland 他 | 短期イテレーション運用 | | **本番反映前チェックの省略不可項目** | CMO Marketing OS Playbook 固有 | 本番反映の必要条件（オーナー / 計測 / ロールバック） | ### 学ぶ段で使うフレームワーク | フレームワーク | 出典 | 何を出すか | |---|---|---| | **After-Action Review（AAR）** | US Army | 結果と意図の差分整理 | | **Retrospective（5 Whys / Start-Stop-Continue）** | Agile 系 | 原因追求と次サイクル入力 | | **Marketing Mix Modeling（MMM）** | 経済計量モデル | チャネル寄与の長期推定 | | **Incrementality Testing（Geo / Holdout）** | デジタル測定の最新 | 真の因果効果の推定 | | **Attribution Modeling**（Last-touch / Multi-touch / Data-driven） | 各種 | 接点寄与の配分 | | **Cohort Analysis** | SaaS 業界 | 時間断面での挙動差分 | | **Evidence Level（E0〜E3）** | CMO Marketing OS Playbook 固有 | 知見の検証度分類 | これらの選択は L3 タクティカル・プレイブックで状況依存に決まる。CMO Marketing OS Playbook は「どれを使え」とは指定せず、**選択そのものが 再構築 / 理解・分析する段の判断対象**であるとする。 ## 運用補題 **要点: マーケティングサイクルを実務に落とすと、7 つの運用補題が出てくる。** 各補題は「言い換え + 違反時に起きる失敗 + 検出指標」で構成する。 ### 補題 2-A: 観測・データ収集の 4 観測対象は独立した記録として保たないと意味を失う Team / Customer / Market / Performance の 4 つを同じドキュメントに混在させると、「ICP 仮説と顧客実態のズレ」が構造的に見えなくなる。 - **違反時の失敗**: 実績メトリクスに顧客の声が吸収され、ICP が更新されない - **検出指標**: Customer Sync 専用の記録が独立に存在するか / 直近 1 サイクルで Customer Sync 起点の 再構築候補が出ているか 第 4 原則（顧客同期の独立化）の運用補題。 ### 補題 2-B: 理解・分析するは 1 サイクル 1 目的で運用しないと品質が劣化する 1 つのプロンプト / 1 つのセッションで 5 種類の問いを混ぜると、AI も人間も平均的な回答しか出せない。 - **違反時の失敗**: 戦略 / 制作 / 評価 / 比較が混じり、どれも中途半端 - **検出指標**: 理解・分析する 産出物の冒頭に「誰の視点で・何を・どの深さで・何を基準に・どの形式で」が明示されているか（§2.3.3） ### 補題 2-C: 再構築は人間にしか引き受けられない AI は聖域・「ねばならない」を機械的に列挙できる。しかし**実際に再構築の決断**は組織内の政治的・心理的負担を伴い、AI の射程外である。 - **違反時の失敗**: AI が「やめましょう」と言った施策を AI 出力ログだけで止め、責任主体不在のまま戦略が動く - **検出指標**: 再構築段の再構築決定リストに、**判断者の個人名**が記載されているか 第 3 原則（既成枠の再構築）・第 6 原則（AI 判断責任）の運用補題。 ### 補題 2-D: オーナー / 計測 / ロールバックの同時成立が本番反映の必要条件 7 項目のうち他はテーラリング可能だが、**この 3 つを欠いた本番反映は 学ぶ段で比較・責任・再現ができない**。 - **違反時の失敗**: 「やった」が記録されるが「何が起きたか」が再現できない - **検出指標**: 本番反映ログにこの 3 項目が全部埋まっている割合（省略不可項目の完備率） 第 5 原則（本番反映 ≠ 学習）の運用補題。 ### 補題 2-E: Evidence Level の昇格は反証条件を併記したときのみ可能 E2 → E3 への昇格には「どういう観測が出れば仮説が崩れるか」を併記する。これがないと、後で反例が出ても格下げできない。 - **違反時の失敗**: E3 として profile に書かれた知見が実は単なる確信であり、新事実と矛盾しても更新されない - **検出指標**: profile 上の E3 知見に反証条件が明記されているか 第 5 原則・第 7 原則（語の規律）の運用補題。 ### 補題 2-F: 学ぶの書き戻し先と次サイクルの観測・データ収集の起点は構造的に一致しなければならない 学ぶの産出物（検証済み知見・残課題・AI 採否ログ）がどこに書かれるかと、次サイクルの観測・データ収集の 4 観測対象がどこを読むかは、同じ場所でなければサイクルは閉じない。 - **違反時の失敗**: 学ぶの議事録は残るが、次サイクルの観測・データ収集 は古い profile を読む。引き継ぎ事項が空白になる - **検出指標**: 次サイクルの観測・データ収集の入力に、前サイクル 学ぶの引き継ぎ事項が含まれているか 第 1 原則（組織学習）の運用補題。 ### 補題 2-G: 5 段は厳密 sequential ではない。前段に遡及して再開できる 起動・実装する中に Customer Sync の新事実が見つかった場合、即座に 観測・データ収集に戻ってよい。「順番通りでないと壊れる」は誤解である。 - **違反時の失敗**: 「起動・実装する中だから 観測・データ収集に戻れない」と判断し、明らかなズレを放置して本番反映する - **検出指標**: サイクル内で前段に戻った回数 / 戻り判断の記録があるか 第 3 原則（既成枠の再構築）の運用補題。 ## 事例 **要点: マーケティングサイクルの完備 / 欠落が業績に直結する例を示す。事例は説明の補助であり、すべての事例が同じ構造で読めるわけではない。** ### 成功例: Domino's Pizza Turnaround（2009〜） 2008 年時点で Domino's は「ピザ業界最下位の味」と評され、株価も低迷していた。同社は **顧客の生の批判映像をテレビ CM で流す**という異例の Customer Sync 公開を行い、新レシピへの全面切り替え（再構築）と本番反映（起動・実装する）、結果の継続計測（学ぶ）を一周させた。結果として 10 年で株価は約 30 倍に伸びた。 - **観測・データ収集 / Customer Sync**: 顧客の批判（"段ボールの味"）を生のまま受け止めた - **再構築**: 創業以来のレシピを再構築した（強い聖域） - **起動・実装する**: "Pizza Turnaround" キャンペーンで新レシピを本番反映、計測同時着地 - **学ぶ**: 売上 / NPS / 指名検索の全方位指標で書き戻し マーケティングサイクル 的に読めば「Customer Sync → 再構築 → 起動・実装する → 学ぶ」が一周した最も明快な公開事例である。 ### 失敗例: Kodak（〜2012） Kodak はデジタルカメラを早期に内部発明していた（1975 年）。Customer Sync・Market Sync は「フィルム需要が縮小しデジタルに置換される」を継続的に示していた。しかし**フィルム事業の収益構造を再構築する 再構築が起きなかった**ため、デジタルへの本番反映は遅れ続け、2012 年に破綻した。 - **観測・データ収集**: 観測自体は出来ていた（社内研究所が早期検知） - **再構築不在**: フィルムを聖域として再構築できなかった - **起動・実装するの歪み**: デジタル投資は行ったが、フィルム保護を優先した中途半端な本番反映 - **学ぶの断絶**: 観測結果が前提の組み替えに繋がらなかった マーケティングサイクルで読むと、観測・データ収集 と 再構築の間が切れた典型例である。「観測できていれば学べる」が誤りであることを示す。 ### 失敗例: New Coke（1985） Coca-Cola は 20 万人規模の味覚テストで「新フォーミュラは旧来品より好まれる」を確認し本番反映した。しかし「ブランド資産は味だけでなく文化的アイデンティティに紐づく」という Customer Sync 上の事実を取り込まなかったため、発売 3 ヶ月で旧フォーミュラ復活に追い込まれた。 - **観測・データ収集 偏向**: 量的調査（味覚テスト）だけを Customer Sync として扱った - **再構築 過剰**: 再構築するべきでないブランド資産まで再構築した - **学ぶ 速度**: 結果として「発売 → 撤回」のサイクルは速かった（3 ヶ月）。サイクル速度自体は救いになった Customer Sync の独立化は量的調査だけでは成立しないことの例。N=20 万でもサンプリングが偏れば 観測・データ収集汚染と同じ結果になる。 ### 成功例: Netflix の DVD → ストリーミング転換（2007〜） Netflix は DVD 郵送サービスでピーク時に大きな収益を持っていたが、Customer Sync（視聴行動の即時化志向）と Market Sync（帯域コスト低下）の両方を取り込んだうえで、**ストリーミングへの戦略転換を 再構築 として明示**した。後の Qwikster 騒動（DVD と Streaming の分社失敗）も含め、起動・実装する / 学ぶ段を高速に回したことで挽回した。 - **観測・データ収集**: 視聴行動・帯域コスト・コンテンツライセンス条件の継続観測 - **再構築**: DVD 中心モデルを段階的に再構築する宣言 - **起動・実装する**: ストリーミング・自社制作（House of Cards, 2013〜）の本番反映 - **学ぶ**: Qwikster 失敗（2011）を即座に書き戻し、分社案を撤回 再構築の「実行」は失敗を含む。重要なのは 学ぶ 速度であることを示す事例。 ### 事例の扱いに関する注意 事例は「マーケティングサイクルが正しい」ことを証明するものではない。**マーケティングサイクルの欠落が観測されるパターン**を示すに留まる。逆に、マーケティングサイクルを使っていない組織が成功する例もある（例: 創業者の直感が市場と偶然一致した初期 Apple）。CMO Marketing OS Playbook は確率的に組織学習を継続するための設計指針であり、決定論ではない。 事例の追加・更新は [`../../case/`](../../case/) と [`../appendices/references.md`](../../reference/references.md) を参照。 ## 関連 skill / agent Marketing OS 側で 5 段を起動・実装する skill: | 段 | skill | |---|---| | 観測・データ収集 | `/listen team-org` / `/listen team-brand` / `/listen team-workspace` / `/listen customer` / `/listen market` | | 理解・分析する | `/insight ceo` / `/insight consultant` / `/insight gemba` / `/insight customer` / `/brand` | | 再構築 | `/release` | | 起動・実装する | （skill なし。[`knowledge/base/`](../../../base/) のプレイブックを参照したインライン実行） | | 学ぶ | `/learn` | | Meta | `/next` / `/next --verbose` / `/workspace` | skill ↔ process の完全な対応は [`../appendices/skill-mapping.md`](../../../base/skill-mapping.md) を参照。 ## アンチパターン マーケティングサイクル全体に発生する典型的な失敗パターン: - **観測・データ収集丸投げ**（補題 2-A 違反）: 「とにかくいい感じで」と AI に投げる。平均的な回答しか返らない - **Customer Sync の不在**（補題 2-A 違反）: 顧客の生の声を構造的に取り込まない。ICP ≠ 実態を検出できない - **理解・分析するの過剰**（補題 2-B 違反）: 1 プロンプトで 10 個聞く。すべて中途半端になる - **理解・分析する 量産**（補題 2-B 違反）: 再構築を飛ばして 理解・分析する段で "正解の戦略" を量産する。"より洗練された無意味さ" を再生産する - **再構築不在**（補題 2-C 違反）: 既成 KPI を疑わずに 起動・実装する段に進む。既成の失敗パターンを再生産する - **再構築の儀式化**（補題 2-C 違反）: 「再構築した」と言うだけで実際は残る - **再構築の AI 委譲**（補題 2-C 違反）: AI 出力だけで再構築を決定し、判断主体が消える - **起動・実装する 偏重**（補題 2-D 違反）: レビューレポートで満足する。本番反映しない限り何も変わらない - **計測の取りこぼし**（補題 2-D 違反）: 本番反映を急ぎ計測同時着地を省略する - **省略不可項目の欠落**（補題 2-D 違反）: オーナー / 計測 / ロールバックのどれかを欠いて本番反映する - **反証条件なき E3 昇格**（補題 2-E 違反）: 「これは検証済み」と宣言するだけで反証条件が書かれていない - **学ぶの断絶**（補題 2-F 違反）: 結果を書き戻さない。次サイクルが毎回ゼロから始まる - **書き戻し先の不一致**（補題 2-F 違反）: 学ぶ は議事録に残るが、次サイクルの観測・データ収集 は古い profile を読む - **profile 汚染**（補題 2-E 違反）: 未検証の E0 / E1 を profile に直書きする - **遡及禁止の誤解**（補題 2-G 違反）: 起動・実装する中に新事実が出ても「順番」を理由に 観測・データ収集に戻らない - **「AI が言ったから」病**: AI 出力を判断根拠にする。責任の所在が組織から消える（詳細は [`principles.md`](principles.md) Principle 6） ## 今後の拡張論点 - **2.7 Canonical Flow** は 02 章に残すか 00 Introduction に移すか。00 が読み物、02 が定義書という分担なら 00 に簡易版、02 に詳細版を置く案もある - **2.8 開かれた最適化 vs 閉じた最適化** は 02 章で論じるか、01 Principles の Principle 2 と統合するか - **2.9 12 KA カバレッジ** は本章に置くか、04 Vocabulary または appendix B Matrix に移すか - **起動・実装するの skill 不在** をどう扱うか。起動・実装するは「プレイブック参照のインライン実行」となっており、他段と非対称。これを構造として記述するか、将来 `/activate` skill を立てる前提で空欄を残すか - **Evidence Level (E0〜E3)** は本章で一次定義した。13 計測・MarTech や 17 AI in Marketing でも参照されるが、定義は本章のみとする運用でよいか - **§2.10 既存学派カタログ** の網羅範囲: Growth Loops / Flywheel / Theory of Change まで含めたが、もっと業界寄り（Demand Generation Funnel / Frank Cespedes の Aligning Strategy and Sales 等）を入れるか - **§2.11 理論的背景** と 01 章 §1.5 の重複: 同じ研究者（Cyert & March, Argyris, Senge 等）を両方で扱っている。01 章は principle 寄り、02 章は process 寄りで分担としたが、引用文献の一次配置を appendix references に集約すべきか - **§2.12 フレームワークカタログ** の所在: 各 KA 章の §X.5 と本章 §2.12 で重複しうる。本章は段ごとの代表、KA 章は領域ごとの詳細という分担でよいか - **§2.13 運用補題** の番号付け: 01 章は補題 A〜I、本章は補題 2-A〜2-G とした。章番号プレフィックスを付ける運用で他章も統一するか - **§2.14 事例** の扱い: 公開事例（Domino's, Kodak, Netflix, New Coke）は説明上有用だが、出典確認の負荷が高い。自社事例（`knowledge/marketing/case/`）に主軸を移すか - **§2.15 関連 skill の 起動・実装する 欄** の表記: 「skill なし」を明示するか、空欄にするか --- title: パフォーマンスドメイン chapter: "03" part: 1-foundations status: revised visibility: public authors: - claude reviewers: [] revision: 0.3 updated: 2026-05-19 related-skills: [] related-chapters: - foundations/principles - foundations/cycle - knowledge-areas/measurement-martech - cross-cutting/org-learning - cross-cutting/maturity-model related-knowledge: - knowledge/marketing/glossary/metrics-glossary.md - knowledge/marketing/playbook/knowledge-areas/measurement-martech/measurement-incrementality.md --- # パフォーマンスドメイン ## この章で解く問題 **要点: 単一 KPI / 単一 KA で測ると、マーケが組織にもたらす多面的な成果が必ず取りこぼされる。パフォーマンスドメインはこの取りこぼしを構造的に防ぐための観測軸である。** 実務では次の状態が頻発する。 - 短期 ROAS だけで成果を判定し、ブランド資産（指名検索・想起）が枯渇する - NPS だけを見て、パイプライン金額の停滞に気づかない - 「マーケ部門の評価指標 = MQL 件数」となり、組織能力・学習速度・リスク管理が誰の責任でもなくなる - 計測ダッシュボードに 30 指標並んでいるが、ドメイン間のトレードオフは誰も議論しない これらは**1 つの KA に閉じた成果指標**を組織全体の成果と混同したときに起きる。マーケが事業に与える影響は多次元であり、1 軸だけで判定すると残りの軸は犠牲になる。 本章は次の 2 つを提供する。 - **6 つのパフォーマンスドメイン**: KA とは直交する評価軸として、Customer Value / Brand Equity / Pipeline & Revenue / Learning Velocity / Org Capability / Risk & Trust を置く - **ドメイン間トレードオフの可視化**: 衝突パターンを構造的に並べ、経営判断の場に乗せる PMBOK 7th edition の "Performance Domains" 概念を踏襲しつつ、マーケ固有のドメインで再構成した。既存学派との詳細比較は §3.6、理論的背景は §3.7、フレームワークカタログは §3.8 にまとめる。 ### 対象範囲 **パフォーマンスドメイン**は、複数の知識エリアを横断する**成果観点**である。1 つの知識エリアに閉じない成果（例: ブランド資産は 08 だけでなく 11 / 12 / 17 にも影響される）を捕捉するため、KA とは直交する評価軸として置く。 KPI 設計（13 章）、Marketing OS 成熟度評価（22 章）、組織学習速度の測定（18 章）はすべてパフォーマンスドメインを基盤とする。 ## 6 つのパフォーマンスドメイン ### Customer Value（顧客価値） 顧客が実際に得ている価値の量と質。「自社サービスが解消した Job の重要度 × 達成度」で捉える。 主要指標例: NPS、CSAT、JTBD 達成度、解約理由、紹介率、利用頻度の変化 時間軸: 中〜長期（数週〜数四半期） ### Brand Equity（ブランド資産） カテゴリ内での想起・連想・選好の総体。短期施策では動かないが、長期では他のドメイン全てに影響する基底資産。 主要指標例: 指名検索数、ブランド想起率、純粋想起 vs 助成想起、share of voice、指名比率 時間軸: 長期（数四半期〜数年） ### Pipeline & Revenue（パイプライン・売上） 需要創出から売上計上までの流れ。最も直接的な事業貢献を測るドメイン。 主要指標例: MQL / SQL / Opportunity / Closed-Won の各転換率、パイプライン金額、ROAS、Payback Period 時間軸: 短〜中期（数日〜数四半期、業種により変動） ### Learning Velocity（学習速度） 組織が 1 サイクルを回す速さと、サイクル間で profile（前提）が更新される割合。CMO Marketing OS Playbook 独自のドメインであり、Marketing OS の駆動力そのものを測る。 主要指標例: サイクル所要日数、Evidence Level E3 への昇格件数、再構築段で再構築された前提数、AI 採否ログの記録率 時間軸: 短〜中期（数週〜数四半期） ### Org Capability（組織能力） マーケ組織の機能を発揮できる能力。スキル・体制・他部門連携を含む。 主要指標例: 役割充足率、スキルマップのカバレッジ、機能対別の摩擦件数（[`../knowledge-areas/stakeholder/`](../knowledge-areas/stakeholder/)）、属人化指数 時間軸: 中〜長期（数四半期〜数年） ### Risk & Trust（リスク・信頼） ブランド・法務・顧客体験・データ取扱・AI 出力のリスクと、それが棄損されない状態（信頼）。 主要指標例: 重大インシデント数、コンプラ違反件数、AI ハルシネーション検出率、ブランドセーフティ違反件数、顧客信頼指数 時間軸: 平時は監視のみ、有事は短期 ## ドメイン間のトレードオフ 6 つのドメインは独立ではなく、しばしば衝突する。CMO Marketing OS Playbook は衝突を**構造的に可視化することを目的**とし、解消方法は状況依存とする（[`../cross-cutting/tailoring.md`](../cross-cutting/tailoring.md)）。 典型的な衝突パターン: | トレードオフ | 概要 | |---|---| | **Pipeline vs Brand Equity** | 短期売上を追うと指名検索・想起への投資が削られる。逆もまた然り | | **Learning Velocity vs Risk & Trust** | 速く回そうとすると承認・計測・ロールバックが薄くなる | | **Customer Value vs Pipeline** | 解約防止やオンボーディング改善への投資は短期パイプラインを直接増やさない | | **Org Capability vs Pipeline** | 組織能力構築（採用・育成）は短期 KPI を直接動かさない | | **Learning Velocity vs Org Capability** | 速く回すことに最適化すると人材育成のサイクルが追い付かない | トレードオフは**経営判断**であって、Marketing OS は判断を自動化しない。判断と判断根拠を [`../foundations/principles.md`](principles.md) の Principle 6（AI Decision Accountability）に従って記録する。 トレードオフの判定で特に注意すべきは、**多くのドメインが非線形に顕在化する**ことである（[`principles.md`](principles.md) 補題 I）。例えば Brand Equity は数四半期〜年単位で動く一方、Pipeline は週次で動くため、短期の線形比較では Brand Equity が常に「効果なし」と判定される。各ドメインに固有の時間軸を事前に明示し、線形評価で施策の正誤を誤判定しないようにする。 ## 12 KA との対応 各知識エリアがどのドメインに主に寄与するかを以下に整理する。**寄与は排他ではない**（多くの KA は複数ドメインに影響する）。 | KA | 主寄与ドメイン | 副次寄与 | |---|---|---| | 05 統合・戦略 | Learning Velocity / Org Capability | 全般 | | 06 Intelligence | Customer Value / Learning Velocity | Brand Equity | | 07 ICP・ポジショニング | Brand Equity / Pipeline | Customer Value | | 08 ブランド・ナラティブ | Brand Equity | Customer Value | | 09 ProdMkt & JTBD | Customer Value / Pipeline | Brand Equity | | 10 価格・オファー設計 | Pipeline | Customer Value | | 11 需要・ライフサイクル | Pipeline / Customer Value | Brand Equity | | 12 コンテンツ・チャネル | Pipeline / Brand Equity | Customer Value | | 13 計測・MarTech | Learning Velocity | 全般（測定基盤） | | 14 組織・能力 | Org Capability / Learning Velocity | — | | 15 ステークホルダー連携 | Org Capability | Learning Velocity | | 16 リスク・コンプライアンス | Risk & Trust | Brand Equity | このマトリクスは KPI 設計時に「どのドメインを動かしたいか → どの KA を強化すべきか」の参照軸として使う。 ## マーケティングサイクルとの接続 各段で観測・更新するドメイン: | 段 | 主に観測するドメイン | |---|---| | **観測・データ収集** | 全 6 ドメインのベースライン取得 | | **理解・分析する** | Customer Value / Brand Equity のギャップ抽出 | | **再構築** | ドメイン間トレードオフの可視化と再構築判断 | | **起動・実装する** | Pipeline / Customer Value の短期動向、Risk & Trust の事前チェック | | **学ぶ** | Learning Velocity の自己測定、全ドメインの結果書き戻し | Learning Velocity だけは「Marketing OS 自身を測るドメイン」であり、他 5 ドメインとはメタレベルが異なる。 ## 既存の学派・伝統との関係 **要点: マーケの成果観点モデルは複数提案されている。CMO Marketing OS Playbook の 6 ドメインは既存モデルを否定せず、Learning Velocity を独立軸として明示する点で差別化する。** | モデル | 出典・主提唱者 | 年代 | 主目的 | 6 ドメインとの位置取り | |---|---|---|---|---| | **Balanced Scorecard（BSC）** | Kaplan & Norton | 1992 | 財務 / 顧客 / 内部プロセス / 学習成長の 4 視点 | 6 ドメインの祖型。Customer Value / Pipeline / Org Capability / Learning Velocity に対応 | | **OKR**（Objectives & Key Results） | Andy Grove → John Doerr | 1970s / 1999 | 短サイクルでの目標管理 | KPI 設計（13 章）の運用フレーム。ドメイン軸ではなく目標軸 | | **North Star Metric（NSM）** | Sean Ellis 系譜 | 2010s | 単一の北極星指標 | Pipeline / Customer Value のうち 1 つを代表値とする運用。トレードオフは陽に扱わない | | **AARRR Pirate Metrics** | Dave McClure | 2007 | ファネル指標 | Pipeline & Revenue ドメイン内のフレーム | | **HEART Framework** | Google | 2010 | プロダクト体験の 5 指標（Happiness / Engagement / Adoption / Retention / Task success） | Customer Value ドメインの内訳 | | **PMBOK 7 Performance Domains**（8 個） | PMI | 2021 | プロジェクト成功軸（利害関係者 / チーム / 開発アプローチ / 計画 / プロジェクト作業 / デリバリー / 測定 / 不確実性） | 6 ドメインの構造的祖型。マーケに合わせて再構成 | | **Marketing Performance Measurement（MPM）** | Patrick LaPointe 他 | 2000s | 媒体 ROI 中心の評価 | Pipeline & Revenue 単独偏重の典型。ブランド・学習・組織は射程外 | | **EBIT-Driven Marketing**（M&S 系） | Mark Ritson 他 | 2010s | 短期売上と長期ブランドの両立 | Pipeline と Brand Equity のトレードオフを論じる伝統 | | **Customer Lifetime Value（CLV）軸** | Fader / Hardie | 2005〜 | 顧客資産の長期計測 | Customer Value と Pipeline & Revenue の橋渡し | | **Brand Value Chain** | Keller | 2003 | ブランド投資 → 顧客マインドセット → 市場成果 → 株主価値 | Brand Equity ドメインの理論的骨格 | | **ESG / Marketing Sustainability** | 各種 | 2010s〜 | 環境・社会・ガバナンス観点での評価 | Risk & Trust ドメインに部分的に含まれる | このうち BSC と PMBOK 7 Performance Domains が 6 ドメインの最も近い祖型である。BSC の「学習と成長」が Learning Velocity と Org Capability に分かれ、「顧客」が Customer Value と Brand Equity に分かれた、と読める。NSM や AARRR のような単一指標 / 単一ファネル モデルは Pipeline ドメイン内の運用フレームとして併用する。 CMO Marketing OS Playbook が 6 ドメインを構造化する独自性は **Learning Velocity を独立ドメインに昇格させる**点にある。BSC の「学習成長」は実質的に従業員研修・スキル投資に閉じることが多く、組織が **マーケサイクル自体をどれだけ速く更新できるか** という観測軸を持たない。 ## 理論的背景 **要点: 6 ドメインは戦略管理論・組織能力論・マーケティング会計の積み上げをマーケ運用に落としたものである。** この節は補足である。 ### 戦略管理論 - **Kaplan & Norton（1992, 1996）"The Balanced Scorecard"**: 財務指標だけでは戦略遂行を測れないことを示し、4 視点モデルを提案した。6 ドメインの最も近い祖 - **Kaplan & Norton（2004）"Strategy Maps"**: 戦略仮説の因果連鎖を可視化する手法。ドメイン間のトレードオフ（§3.3）を扱うための下敷き - **Porter（1980 / 1985）"Competitive Strategy" / "Competitive Advantage"**: 競争優位の源泉を構造化。Brand Equity / Org Capability の理論的位置づけに寄与 ### 組織能力論 - **Day（1994）"The Capabilities of Market-Driven Organizations"**: 市場連動を組織能力として扱う。Org Capability ドメインの直接の理論基盤 - **Teece, Pisano & Shuen（1997）"Dynamic Capabilities"**: 環境変化に応じた能力再構築。Learning Velocity ドメインの理論基盤 - **Eisenhardt & Martin（2000）"Dynamic Capabilities: What Are They?"**: Dynamic capabilities の実証研究。学習速度と業績の関係を示す ### マーケティング会計・測定論 - **Srinivasan & Hanssens（2009）"Marketing and Firm Value"**: マーケ施策と企業価値の長期関係。Brand Equity と Pipeline & Revenue を分けて測る必要性の実証 - **Lenskold（2003）"Marketing ROI"**: マーケ ROI の構造化。Pipeline & Revenue ドメインの計算基盤 - **Farris, Bendle, Pfeifer & Reibstein（2010）"Marketing Metrics"**: マーケ指標の網羅辞典。13 章 計測・MarTech の参照書 ### リスク管理論 - **COSO ERM Framework**: 企業リスク管理の標準フレーム。Risk & Trust ドメインの構造的祖型 - **AI Risk Management（NIST AI RMF, 2023）**: AI 固有リスクの管理フレーム。17 章 AI in Marketing と連動 引用文献の詳細は [`../appendices/references.md`](../../reference/references.md) §E.6 を参照。 ## 主要フレームワーク・手法カタログ **要点: 6 ドメインを実務で測るためのフレームワークと指標群を、ドメイン別に一覧化する。** ### Customer Value の測定フレーム - **NPS / CSAT / CES**: 推奨意向・満足度・努力度の標準指標 - **JTBD 達成度**: Job ごとの達成率と重要度の積 - **HEART Framework**: Happiness / Engagement / Adoption / Retention / Task success - **Cohort Retention Curves**: 時系列での顧客残存率 - **Customer Lifetime Value（CLV / LTV）**: 顧客一人あたり生涯価値 - **Voice of Customer（VoC）解析**: 顧客の声の構造化 ### Brand Equity の測定フレーム - **Aaker's Brand Equity Model**: Brand Awareness / Perceived Quality / Loyalty / Associations - **Keller's Customer-Based Brand Equity（CBBE）**: ピラミッド構造（Salience → Performance / Imagery → Judgments / Feelings → Resonance） - **Brand Value Chain**: ブランド投資から株主価値までの因果連鎖 - **Share of Voice / Share of Search**: 市場内の言及・検索シェア - **Brand Lift Studies**: 広告露出と想起・選好の差分計測 - **Helpful, Reliable, People-First Content（Google E-E-A-T）**: 検索文脈での信頼形成 ### Pipeline & Revenue の測定フレーム - **AARRR Pirate Metrics**: Acquisition / Activation / Retention / Referral / Revenue - **MQL / SQL / Opportunity / Closed-Won 転換率**: B2B 標準ファネル - **ROAS / Payback Period / CAC / LTV-to-CAC**: ユニットエコノミクス指標 - **Marketing Mix Modeling（MMM）**: チャネル寄与の長期推定 - **Incrementality Testing（Geo / Holdout）**: 真の因果効果 - **Multi-touch Attribution**: 接点寄与の配分 ### Learning Velocity の測定フレーム - **サイクル所要日数**: 観測・データ収集の起点 → 学ぶ書き戻しまでの日数 - **Evidence Level 昇格件数**: E2 → E3 への昇格件数 / サイクル - **再構築候補件数 / 採用件数**: 再構築候補の生成と採用の比率 - **AI 採否ログ記録率**: AI 出力に対する判断ログの完備率 - **再構築頻度**: 前提（KPI / ICP / 施策ラインナップ）の組み替え頻度 - **書き戻し時間ラグ**: 結果発生から profile 更新までの時間 CMO Marketing OS Playbook 独自のドメインであり、業界標準フレームはまだ確立していない。本書が一次定義する。 ### Org Capability の測定フレーム - **役割充足率 / DRI 設定率**: ポストの埋まり方 - **スキルマップ・カバレッジ**: 機能対別のスキル網羅 - **属人化指数**: 1 人に依存する業務の割合 - **9-Box Talent Review**: パフォーマンスとポテンシャルの 2 軸評価 - **eNPS（Employee NPS）**: 従業員推奨度 - **Cross-functional Friction Score**: 機能対別の摩擦件数（15 章 ステークホルダー連携） ### Risk & Trust の測定フレーム - **Brand Safety Violation Rate**: 配信先・隣接コンテンツのブランド毀損率 - **Compliance Incident Count**: 法令・社内規程の違反件数 - **AI Hallucination Detection Rate**: AI 出力の誤りの発見率 - **Crisis Response Time**: 有事の検知から初動までの時間 - **Customer Trust Index**: 信頼度の調査指標 - **Data Privacy Compliance Score**: GDPR / CCPA / 改正個情法対応の充足度 ## 業界トレンドと新興手法 - **AI 駆動の指標自動分類**: 大量メトリクスを 6 ドメインに自動マッピング - **CLV 予測モデルの精緻化**: 機械学習による顧客 LTV 推定 - **Brand Lift の AI 化**: 広告効果のリアルタイム推定 - **Learning Velocity ベンチマーク**: 業界平均との比較（まだデータが少ない） - **AI Risk Scoring**: AI 出力リスクの定量化（17 章と連動） - **Sustainability KPI**: ESG 観点の指標統合 ## 運用補題 ### 補題 3-A: 6 ドメインは少なくとも 4 つを同時に観測しないと、最適化が片寄る 1〜2 ドメインだけを KPI 化すると、他ドメインは「測られていないので無視される」状態になる。最低 4 ドメインを観測対象に置く。 - **違反時の失敗**: Pipeline 偏重で Brand Equity 枯渇（補題 I の典型） - **検出指標**: ダッシュボードに登場するドメイン数 / 6 ### 補題 3-B: ドメイン間のトレードオフは経営判断であり、Marketing OS は判断を自動化しない トレードオフを並べることまでは構造化できる。**どちらを優先するか**は組織の戦略選択であり、AI も CMO Marketing OS Playbook も決定しない。 - **違反時の失敗**: 「AI が言ったから Pipeline を優先した」と AI 判断責任が外部化される（第 6 原則違反） - **検出指標**: トレードオフ判断ログに人間の判断者と理由が記載されているか ### 補題 3-C: 各ドメインに固有の時間軸を事前に明示しないと、線形評価で施策の正誤を誤判定する Brand Equity は数四半期〜年、Pipeline は週次、Learning Velocity はサイクル単位、と時間軸が異なる。これを揃えないで比較すると、長期軸のドメインは常に「効果なし」と判定される（補題 I）。 - **違反時の失敗**: ブランド投資を「3 ヶ月で効果が出ない」と止め、指名検索が数四半期後に枯渇 - **検出指標**: 各ドメインの観測時間軸が KPI 設計時に明示されているか ### 補題 3-D: Learning Velocity を意思決定 KPI にしてはいけない（観測 KPI に留める） Learning Velocity を「速くしろ」と評価対象にすると、AI 採否ログを形式的に埋める / Evidence Level を恣意的に昇格させる、といった歪みが起きる。 - **違反時の失敗**: 採否ログの形式化、E2 → E3 の早期昇格、書き戻しの儀式化 - **検出指標**: Learning Velocity を個人評価 / 部署評価に組み込んでいないか 詳細は [`../cross-cutting/org-learning.md`](../cross-cutting/org-learning.md) §18.6 で扱う。 ### 補題 3-E: Risk & Trust ドメインは平時から運用する。有事だけの観測では遅い ブランドセーフティ違反・AI ハルシネーション・コンプラ違反は、有事に検出しても被害は既に出ている。平時の継続観測が必要条件である。 - **違反時の失敗**: 危機が顕在化してから「実は前から兆候があった」と判明 - **検出指標**: Risk & Trust 指標が定常ダッシュボードに含まれているか ## 事例 ### 失敗例: Pipeline 偏重による Brand Equity 枯渇 ある B2B SaaS 企業は 2 年間 ROAS 改善だけを KPI として追い、有料検索の最適化に予算を集中した。指名検索数は当初横ばいに見えたが、3 年目に競合の参入と同時に指名検索シェアが急落、新規獲得 CAC が 2 倍化した。Brand Equity ドメインの観測がなかったため、枯渇の進行が見えなかった事例である。 - **欠落ドメイン**: Brand Equity（指名検索・想起率の観測なし） - **顕在化**: 3 年目に競合参入で一気に表面化 - **学び**: Brand Equity は遅行指標であり、短期評価では「効果なし」と誤判定される（補題 3-C） ### 成功例: BSC 導入で組織能力を可視化した Mobil（1990s） Kaplan & Norton の BSC を初期に導入した Mobil の北米精製・販売部門は、財務指標だけだった評価軸に「顧客」「内部プロセス」「学習成長」を加えた。1993〜1998 年で同業界最下位から首位に転じた。 - **追加ドメイン**: 顧客（Customer Value）/ 学習成長（Learning Velocity + Org Capability） - **効果**: 単一指標では見えなかった改善余地の特定 - **限界**: Marketing OS の 再構築段に相当する「前提再構築」は BSC 単独では起きない ### 失敗例: NSM 単一最適化による組織歪み Facebook が 2010 年代初頭に "Daily Active Users" を North Star Metric として徹底した結果、長期エンゲージメント・信頼性・コンテンツ品質の劣化が後年に顕在化した（ケンブリッジアナリティカ事件 2018 等）。NSM は強力だが、Brand Equity / Risk & Trust のドメインを単独で守れない。 - **欠落ドメイン**: Brand Equity / Risk & Trust - **顕在化**: 信頼危機・規制当局介入・ブランド毀損 - **学び**: 単一指標は他ドメインの監視を弱める（補題 3-A） 事例の追加は [`../appendices/references.md`](../../reference/references.md) §E.6 と [`../../case/`](../../case/) を参照。 ## アンチパターン - **Pipeline 偏重で Brand Equity を毀損**（補題 3-A / 3-C 違反）: 短期 ROAS だけを KPI 化し、ブランド資産投資をゼロにする。数四半期後に指名検索の枯渇として顕在化する - **Learning Velocity を KPI 化することで採否ログが歪む**（補題 3-D 違反）: 「速く回す」評価で採否ログを形式的に埋める運用に陥り、書き戻しの質が落ちる - **Risk & Trust を平時に無視**（補題 3-E 違反）: 有事になって初めてドメインの存在を思い出す。ブランドセーフティ・AI 出力監視は平時から運用する - **単一ドメイン最適化**（補題 3-A 違反）: 6 ドメインのうち 1〜2 個だけを見て他を無視する。閉じた最適化への逃避（[`principles.md`](principles.md) Principle 2 違反） - **dashboard 化による意思決定使途の喪失**: 6 ドメインを単に並べて見るだけで、ドメイン間トレードオフの判断に使わない（[`principles.md`](principles.md) 補題 E 違反） - **時間軸の不揃え評価**（補題 3-C 違反）: 全ドメインを同一の時間軸（例: 四半期）で比較し、長期ドメイン（Brand Equity）を常に「効果なし」と誤判定する - **AI による自動トレードオフ判断**（補題 3-B 違反）: AI 出力でドメイン優先度を決め、判断主体が組織から消える ## 関連 skill / agent - **観測・データ収集系 skill** — ドメイン横断のベースライン取得 - **`/learn`** — Learning Velocity の自己測定、結果のドメイン別書き戻し skill ↔ process ↔ ドメインの対応は [`../appendices/skill-mapping.md`](../../../base/skill-mapping.md)。 ## 今後の拡張論点 - **ドメイン数（4 / 6 / 8）** — 6 が現状案。PMBOK 7 は 8 パフォーマンスドメイン。CMO Marketing OS Playbook で 6 が適切か、Org Capability と Stakeholder を分けて 7 にすべきか - **Learning Velocity を独立ドメインに立てる是非** — 他ドメインを測る "メタ" 性質を持つため、ドメインとは別のレイヤーに置く案もある（例: 22 章 Maturity Model の単独軸とする） - **Risk & Trust の射程** — AI 出力リスクが急速に拡大しているため、独立 KA（16 章）とドメイン（Risk & Trust）の両方で扱う設計でよいか。重複の整理が必要 - **業種別ドメイン重み付け** — B2B エンタープライズと D2C で各ドメインの重要度は大きく異なる。本章で重み付けの指針を示すか、19 章 Tailoring に委ねるか - **指標例の網羅範囲** — 各ドメイン §3.2.X に "主要指標例" を 3〜5 個列挙したが、これを appendix に集約するか本章に残すか - **§3.6 既存学派カタログ** の網羅範囲: BSC / OKR / NSM / AARRR / PMBOK 7 / MPM / EBIT-Driven / CLV / Brand Value Chain / ESG を入れたが、業界寄り（Marketing Accountability Standards Board / MASB 等）も必要か - **§3.7 理論的背景** と 13 章（計測・MarTech）との分担: マーケ会計・測定論（Srinivasan & Hanssens, Lenskold, Farris 等）は本章と 13 章のどちらに置くか。本章は「観測軸」、13 章は「計測手法」で分けたが、引用文献の重複あり - **§3.8 フレームワーク** の所在: 各ドメインで 5〜6 個のフレームを列挙したが、Customer Value / Brand Equity 系は 06 / 07 / 08 章と重複しうる。本章はサマリ、KA 章は詳細で分担するか - **§3.10 補題 3-D**（Learning Velocity を意思決定 KPI にしない）の運用: 22 章 Maturity Model では Learning Velocity を評価軸として使う。本章補題と矛盾しないか、観測 KPI と評価軸の語の規律（補題 7 / 第 7 原則）で分離するか - **§3.11 事例** の事例選定: Pipeline 偏重 / Mobil BSC / Facebook NSM を入れたが、日本企業の事例が欠落している。地域バイアスを補正すべきか --- title: 用語と図式 chapter: "04" part: 1-foundations status: revised visibility: public authors: - claude reviewers: [] revision: 0.3 updated: 2026-05-20 related-skills: [] related-chapters: - foundations/principles - foundations/cycle - appendices/glossary - appendices/matrix - appendices/itto related-knowledge: [] --- # 用語と図式 ## この章で解く問題 **要点: 同じ語が章によって違う意味で使われる状態を許せば、知識体系は内部矛盾で崩れる。本章は CMO Marketing OS Playbook 全章を貫く記法・命名・略語・図式のルールを一次定義する。** 知識体系で語の規律が崩れると次の症状が出る。 - 「ICP」が章によって「Ideal Customer Profile」と「Intercept Customer Persona」を指し、章間で議論が噛み合わない - 「ファネル」「ジャーニー」「ライフサイクル」が同じ図を別の語で呼び、新規読者が「どれが違うのか」を理解できない - 略語の初出が定義されず、業界経験者でないと読めない - 訳語が場当たり的に作られ、「最終資源配分責任」「最終的なリソース配分の責任」が並走する - 旧称（MVDF / CMOFlow / 5 段サイクル主表記）が章によって残り、リブランド前後の読者で語彙が一致しない 第 7 原則（語の規律）はこれらを防ぐためのものであり、本章はその運用ルール（記法 / 命名 / 略語 / 図式 / 翻訳 / 廃止語）を集約する。 本章は次の 4 つを提供する。 - **中核モデルの記法**: マーケティングサイクル × 12 KA マトリクス、4 層モデル、ITTO 記法 - **命名規約**: 章・節・ファイル・process・メトリクスの命名ルール - **略語と翻訳**: 業界略語の正式名称、英日対応の方針 - **廃止語と改名**: 旧称の retire ルール 執筆者向けの追加規約（文体・分量・frontmatter スキーマ等）は [`../_meta/authoring-conventions.md`](../../../base/authoring-conventions.md) を参照。本章は読者・執筆者の双方が参照する notation reference として位置づける。 ### 対象範囲 本章は CMO Marketing OS Playbook で使用する**記法と規律**を定義する。用語の一次定義は [`../appendices/glossary.md`](../../glossary/glossary.md) に置き、本章は**読者が知識体系を読み解くための notation reference** を担う。 ## 中核モデル CMO Marketing OS Playbook は 3 つの中核モデルで構成される。すべての章はこれらと整合する。 ### マーケティングサイクル × 12 KA マトリクス マーケティングサイクル（観測・データ収集 / 理解・分析する / 再構築 / 起動・実装する / 学ぶ）と 12 知識エリアの直交マトリクス。マーケティングサイクルの各段をプロセス群として扱い、各セルに process が定義される。 ``` 観測・データ収集 理解・分析する 再構築 起動・実装する 学ぶ ┌──┬───────┬────────┬────────┬─────────┬──────┐ 05 │ │ │ │ │ │ │ 統合・戦略 06 │ │ │ │ │ │ │ Intelligence 07 │ │ │ │ │ │ │ ICP・ポジショニング 08 │ │ │ │ │ │ │ ブランド・ナラティブ 09 │ │ │ │ │ │ │ プロダクトマーケティング・JTBD 10 │ │ │ │ │ │ │ 価格・オファー設計 11 │ │ │ │ │ │ │ 需要・ライフサイクル 12 │ │ │ │ │ │ │ コンテンツ・チャネル 13 │ │ │ │ │ │ │ 計測・MarTech 14 │ │ │ │ │ │ │ 組織・能力 15 │ │ │ │ │ │ │ ステークホルダー連携 16 │ │ │ │ │ │ │ リスク・コンプライアンス └──┴───────┴────────┴────────┴─────────┴──────┘ ``` 完成版は [`../appendices/matrix.md`](../../framework/matrix.md)。全 process の ITTO 詳細は [`../appendices/itto.md`](../../framework/itto.md)。 ### 4 層モデル（L1 / L2 / L3 / L4） 各章は最大 4 層で構成される: | 層 | 役割 | 章内での位置 | |---|---|---| | **L1 Strategy** | 章の overview、戦略的意思決定軸 | Overview | | **L2 Process** | マーケティングサイクル × ITTO | プロセス | | **L3 Tactical** | 媒体・チャネル・手法別の運用詳細 | タクティカル・プレイブック | | **L4 Tools** | 個社製品・SaaS 詳細 | 本体には書かず [`../../tools/`](../../tool/) へ | 層の表記は本書で常に「L1〜L4」を用いる。「戦略レイヤー」「最適化レイヤー」と書く場合は別概念（Principle 2、[`principles.md`](principles.md)）であり、混同しない。 ### ITTO 記法 PMBOK 由来の記法を踏襲する。各 process は 3 要素で表現する: - **Inputs**: その process が消費する成果物・情報・状態 - **Tools & Techniques**: 適用する手法・道具・アルゴリズム - **Outputs**: 生成される成果物・情報・状態 記載形式: ```markdown ### 観測・データ収集段のプロセス - **Inputs**: 4 つの観測対象レポート、ICP 仮説、競合 SERP - **Tools & Techniques**: JTBD インタビュー、競合スタック調査 - **Outputs**: 不一致リスト、Performance ベースライン ``` ITTO は process 単位で記述する。1 process につき I / T / O を各 1 ブロック書く。複数 process を 1 ブロックに混ぜない。 ## 命名規約 ### 章・節の命名 - **章**: 日本語名または日本語名 + 英語名。例: `統合・戦略` - **節**: 内容名のみで書く。例: `再構築` - **小節**: 内容名のみで書く。例: `投入物・手法と道具・産出物（ITTO）` 見出しには `1.` / `1.1` のような章番号・節番号を付けない。順序変更時の保守コストを避けるため、順序は frontmatter とサイドバー定義で管理し、本文の見出し文字列には持たせない。 ### ファイル・ディレクトリの命名 - ファイル名: `.md`（例: `integration-strategy.md`） - ディレクトリ名: `/`（章が複数ファイルに分かれる場合） - 章ディレクトリの扉ファイルは `README.md` - ファイル名・ディレクトリ名にも表示用の連番は入れない ### process の命名 - 動詞句で命名する（例: "Customer Sync を取得する"、"ICP 仮説を更新する"） - 主語は省略可（マーケ組織が主語であることを暗黙の前提とする） - 「〜する」形（動詞形）と「〜」形（名詞形）が混在しないよう、動詞形に統一 ### メトリクスの命名 - 業界標準が確立されているメトリクス（CPA / CVR / LTV / CAC / ROAS 等）は英略語のまま使う - 独自メトリクスを導入する場合は日本語名 + 英語略称を併記し、[`../appendices/glossary.md`](../../glossary/glossary.md) に一次定義を残す - 「カスタマー獲得コスト」「顧客生涯価値」のような訳語と原語が混在しないよう、業界で広く使われている方を一つ選ぶ ## 略語 CMO Marketing OS Playbook 内で許容する略語の一覧: | 略語 | 正式名称 | 説明 | |---|---|---| | **マーケティングサイクル** | マーケティングサイクル | 観測・データ収集 / 理解・分析する / 再構築 / 起動・実装する / 学ぶ からなる 5 段プロセス群 | | **KA** | Knowledge Area | 知識エリア（12 領域） | | **L1〜L4** | Layer 1〜4 | 4 層モデル | | **ITTO** | Inputs / Tools & Techniques / Outputs（投入物・手法と道具・産出物） | プロセス記述の 3 要素 | | **ICP** | Ideal Customer Profile | 理想顧客像 | | **JTBD** | Jobs To Be Done | 顧客が雇う仕事 | | **CMO** | Chief Marketing Officer | CMO株式会社 の社名でもある | | **CPA** | Cost Per Acquisition | 獲得単価 | | **CVR** | Conversion Rate | 転換率 | | **CTR** | Click Through Rate | クリック率 | | **CAC** | Customer Acquisition Cost | 顧客獲得コスト | | **LTV** | Lifetime Value | 顧客生涯価値 | | **ROAS** | Return On Ad Spend | 広告費用対効果 | | **ROMI** | Return On Marketing Investment | マーケ投資利益率 | | **MQL / SQL** | Marketing / Sales Qualified Lead | 適格リードの分類 | | **MMM** | Marketing Mix Modeling | マーケ予算配分分析 | | **SEO / AEO / GEO** | Search / Answer / Generative Engine Optimization | 検索系最適化 | | **NPS** | Net Promoter Score | 推奨意向スコア | | **VoC** | Voice of Customer | 顧客の声 | | **RACI** | Responsible / Accountable / Consulted / Informed | 責任分担表 | | **DRI** | Directly Responsible Individual | 単独責任者 | | **E0〜E3** | Evidence Level | 知見の検証度（[`cycle.md`](cycle.md) の Evidence Level） | | **P0〜P3** | Priority Level | 経営整合性の優先度 | | **TAM / SAM / SOM** | Total / Serviceable / Serviceable Obtainable Market | 市場規模区分 | 未定義略語の本文中での初出は **「正式名称（略語）」** 形式で書く。例: 「Voice of Customer（VoC）」。以降は略語のみで可。 ## 図式表現 ### マトリクス図 - 行 = 知識エリア、列 = プロセス群を原則とする - セルは process 名または process ID を入れる - 空セルは「process なし」を意味する。"-" や "N/A" は使わない ### フロー図 - マーケティングサイクルは横方向（左 → 右）に書く - 段の間は `─→` で接続 - 巡回（学ぶ → 観測・データ収集）は二段折り返しで表現: ``` 観測・データ収集 ─→ 理解・分析する ─→ 再構築 ─→ 起動・実装する ─→ 学ぶ ─┐ ↑ │ └────────────────────────────────────────────────────┘ ``` ### RACI 図 ステークホルダー関連の章で使用。記法は標準 RACI に従う: - **R**（Responsible）: 実行責任 - **A**（Accountable）: 最終責任（必ず 1 人） - **C**（Consulted）: 事前相談 - **I**（Informed）: 事後通知 詳細は [`../knowledge-areas/stakeholder/`](../knowledge-areas/stakeholder/) と [`../cross-cutting/playbooks/`](../cross-cutting/playbooks/) を参照。 ## 翻訳ガイド（英日対応） 英語原語と日本語訳の併記方針: - **章タイトル**: 日本語名を原則とし、固有名詞・公式名称・業界標準語として英語名が流通している場合のみ併記する - **本文での初出**: 日本語訳語が業界で確立しているなら日本語のみ。確立していない / 略語が広く使われているなら英語原語のみ。両方が必要な場合のみ併記 - **本文中の英語補足**: 固有名詞・公式名称・業界標準略語・検索語として必要な場合に限る。説明語の権威付けとして英語を括弧補足しない - **glossary 内**: 固有名詞・公式名称・業界標準語・略語は正式名称を記載する。説明語は日本語定義を優先する 確立した訳語の例: | 英語 | 日本語 | |---|---| | Knowledge Area | 知識エリア | | Stakeholder | ステークホルダー | | Tailoring | テーラリング | | 再構築 | 再構築 | | Customer Sync | 顧客同期（Customer Sync を主表記） | | Customer Journey | カスタマージャーニー | | Positioning | ポジショニング | | Funnel | ファネル | 訳語が定まっていない概念は英語のまま使い、glossary に「日本語訳は未定」と記す。場当たり的に訳語を作って二重定義を起こすのを避ける。 ## 廃止語・改名語との関係 CMO Marketing OS Playbook では一部の旧称を使用しない。詳細は [`../_meta/authoring-conventions.md`](../../../base/authoring-conventions.md)「リネーム / 廃止語」セクション。 主な改廃: | 旧称 | 扱い | |---|---| | MVDF / Marketing Value Delivery Framework | 廃止（12 KA に吸収） | | CMOFlow | Marketing OS に統一 | | 5 段サイクル | マーケティングサイクルに統一。説明語として必要な場合のみ「マーケティングサイクル（5 段プロセス群）」のように併記 | 旧称を含む既存ドキュメント（[`../../base/`](../../../base/) 配下）を参照する際も、本文中では新称に置き換える。 ## 既存の標準ドキュメントとの位置取り **要点: CMO Marketing OS Playbook の記法は PMBOK / BABOK / ITIL / Diátaxis 等の既存標準を参考にしている。否定するためではなく、マーケ固有の事情に合わせて選んだ。** | 標準 | 出典 | CMO Marketing OS Playbook との関係 | |---|---|---| | **PMBOK Guide** | PMI | プロセス群 × 知識エリアの直交マトリクス、ITTO 記法、Performance Domains 概念を踏襲 | | **PMBOK 7 Principles + Performance Domains** | PMI 2021 | 「原則 + ドメイン」の二層構造を Principles + Performance Domains にマッピング | | **BABOK Guide** | IIBA | ビジネス分析の知識エリア構成。12 KA 分割の参考 | | **ITIL 4 / Service Value System** | AXELOS | サービス価値の継続更新概念。Marketing OS の マーケティングサイクル（再構築段）の参考 | | **ISO/IEC/IEEE 12207, 15288** | ISO | システム / ソフトウェアライフサイクル。プロセス記述形式の参考 | | **Diátaxis Documentation Framework** | Daniele Procida | チュートリアル / ハウツー / リファレンス / 説明の 4 区分。L1〜L4 で類似の階層を採用 | | **PRINCE2** | UK Cabinet Office | プロジェクト管理標準。本章では参照しないが、Tailoring の概念は PRINCE2 系譜 | | **SAFe / Scrum Guide** | Scaled Agile / Schwaber & Sutherland | アジャイル系の用語規律。起動・実装する段の運用語彙に影響 | | **API 仕様標準（OpenAPI / JSON Schema）** | OpenAPI Initiative 等 | 構造化記述の参考。frontmatter スキーマで類似の規律を採用 | | **Google Developer Documentation Style Guide** | Google | 英文ドキュメントの記法。日本語では参考程度 | CMO Marketing OS Playbook が PMBOK と異なる選択を取っている主な点: - **マーケティングサイクルの 5 つのプロセス群** を Initiating / Planning / Executing / Monitoring & Controlling / Closing ではなく **観測・データ収集 / 理解・分析する / 再構築 / 起動・実装する / 学ぶ** に置き換えた。マーケが「実行管理」よりも「学習継続」を中心に動くため - **Knowledge Areas を 10 ではなく 11 個**にした。マーケに特化した分割（ICP / ポジショニング、コンテンツ / チャネル等）を採用 - **「Performance Domains」を 8 ではなく 6 個**にした。マーケ固有のドメイン（Brand Equity / Learning Velocity）を昇格させ、プロジェクト固有のドメイン（Uncertainty 等）を統合 - **「Project」概念を持たない**。マーケは continuous であり、開始 / 終了が前提となる PMBOK の枠組みは本質的に合わない。代わりに「サイクル」を運用単位とする これらの差分は `introduction.md` で詳述する。 ## 運用補題 **要点: 語の規律を守るための運用ルール。第 7 原則の運用補題として整理する。** ### 補題 4-A: 新しい語の導入と glossary 更新は同一コミットで行う 新しい用語を本文に書いた瞬間に [`../appendices/glossary.md`](../../glossary/glossary.md) を更新しないと、二重定義や別文献での競合が発生する。 - **違反時の失敗**: 章 A で導入された語が章 B で別の意味で使われる - **検出指標**: glossary に存在しない太字用語が本文中に出現していないか 第 7 原則の運用補題。 ### 補題 4-B: 略語の初出は「正式名称（略語）」形式で書く 業界経験者には自明でも、新規読者は略語の意味を辞書で引けない。 - **違反時の失敗**: 読者の理解が章を追うごとに分岐する - **検出指標**: 初出での「Voice of Customer（VoC）」形式の充足率 ### 補題 4-C: 訳語の場当たり的作成を禁止し、未確立の語は原語のまま使う 確立していない訳語を執筆者が自作すると、各章で別の訳語が並走する。 - **違反時の失敗**: 「最終資源配分責任」「最終的なリソース配分の責任」が同じ概念を指して並走する - **検出指標**: glossary に「日本語訳は未定」と記された語の本文中での原語率 ### 補題 4-D: 旧称が出てきたら本文で新称に置換し、廃止語表に記載する [`../../base/`](../../../base/) 既存ドキュメントには旧称（MVDF / CMOFlow / 5 段サイクル主表記 等）が残る。CMO Marketing OS Playbook 側で参照する際は本文中で新称に置換する。 - **違反時の失敗**: リブランド前の読者と後の読者で語彙が一致しない - **検出指標**: 廃止語表に該当する語の本文中での新称率 ### 補題 4-E: 同じ概念に複数の表記が必要なら、主表記と併記表記を明示する 「マーケティングサイクル」と「5 段プロセス群」のように、固有名と説明語の両方を使う必要がある場合に限り、主表記を決めて「主表記（説明語）」の形で書く。 - **違反時の失敗**: どちらが正式名称か読者が判定できない - **検出指標**: 併記表記を使っている語が主表記とセットで初出しているか ### 補題 4-F: 専門用語（ICP / JTBD 等）は許容、難解語は不許容 専門用語と難解語は別物である。専門用語は glossary 一次定義で許容、難解語（残渣・営為・退避する等）は推奨置換に従う（[`../_meta/authoring-conventions.md`](../../../base/authoring-conventions.md)「避けるべき語」）。 - **違反時の失敗**: 平易さの規律が崩れ、新規読者が辞書を引かないと読めない - **検出指標**: 避けるべき語リストとの照合スコア ## 関連 skill / agent 本章は Marketing OS の skill には直接対応しない（記法定義のため）。命名規約や略語の運用は CMO Marketing OS Playbook 全章で参照される。 ## 今後の拡張論点 - **章扉ファイル名** — 章がディレクトリの場合、扉を `README.md` か `index.md` か `00-overview.md` のどれにするか。現在は `README.md` を採用しているが、GitHub レンダリングを優先するなら `README.md` で、Next.js ルーティングを優先するなら `index.md` でも可 - **業界略語の網羅範囲** — 本章に列挙する略語は CMO Marketing OS Playbook 内で実際に出現するものに限るか、マーケ業界で広く使われるものを網羅するか - **訳語の併記スタイル** — 「日本語名（英語名）」と「英語名（日本語名）」の併記順を CMO Marketing OS Playbook 内で統一する判断（現状は日本語先） - **Customer Sync の訳語** — 「顧客同期」と書く際の感触が硬い。「Customer Sync」原語のまま使う方針を継続するか - **既存標準ドキュメント** の比較対象範囲: PMBOK / BABOK / ITIL / Diátaxis / PRINCE2 / SAFe を入れたが、マーケ寄りの標準（Marketing Accountability Standards Board / MASB Common Language Marketing Dictionary 等）も追加すべきか - **運用補題** の所在: 補題 4-A〜4-F は本章に置いたが、第 7 原則（語の規律）の運用補題として Principles に統合する案もある - **理論的背景 / 事例 セクション** の欠落: 本章は notation 章のため省略したが、用語規律の失敗事例（PMI の "scope creep" 定義変遷など）を事例として薄く入れるか --- title: "マーケティングの構造的問題" chapter: "04.5" part: 1-foundations status: revised visibility: public authors: - claude reviewers: [] revision: 0.2 updated: 2026-05-19 related-skills: [] related-chapters: - foundations/principles - foundations/cycle - knowledge-areas/org-capability related-knowledge: - knowledge/marketing/framework/marketing-misconceptions.md - knowledge/marketing/framework/marketing-mindset.md --- # マーケティングの構造的問題 — なぜ機能不全が再生産されるのか ## なぜこのドキュメントを置くか **要点: この補論は、Marketing OS が何を解くための仕組みなのかを先に明らかにする。** マーケティング組織では、施策は増えているのに事業は動かない、KPI は追っているのに顧客理解は更新されない、会議は多いのに判断理由は残らない、という状態が起きやすい。 この問題は、個人の努力不足だけでは説明できない。戦略が現場に一方通行で降りる、短期 KPI と長期資産の時間軸が混ざる、止めた施策の記録が残らない、といった仕組みの問題がある。 本補論は、その問題を整理する。マーケティングサイクル（観測・データ収集 / 理解・分析する / 再構築 / 起動・実装する / 学ぶ）は、ここで列挙する問題への応答として読むと理解しやすい。 ## マーケティングとは何か — 最適化としての定義 **要点: マーケティングは「数字を増やすこと」ではなく、自社条件に合う打ち手を更新し続ける活動である。** 本書では、マーケティングを次のように扱う。 > **マーケティングとは、自社の制約条件の中で、顧客を動かすプロセスを最適化し続けるサイクルである。** AMA（American Marketing Association）は、マーケティングを価値ある提供物を作り、伝え、届け、交換する活動・制度・プロセスと定義する。本書はこの定義と矛盾しない。 本書が加えるのは「最適化」という実務上の見方である。ここでいう最適化は、短期指標を上げることだけではない。自社の能力、資金、顧客像、流通経路、市場条件に合わせて、戦略・目標・チャネル・KPI を更新し続けることである。 「最適化」レンズを置く理由は以下: - **勝者になること**ではない ── 競合を打ち負かすこと、市場で 1 位になることがマーケティングの定義ではない - **数字を増やすこと**ではない ── 売上・リード・PV を「とにかく増やす」ことがマーケティングの本質ではない - **自分たちの能力・リソース・現在地に合わせて、適した戦略・目標・ポジショニング・チャネル・KPI を選び直し続ける活動**である 「最適」は相対概念である。誰かにとっての最適は、別の誰かにとっては最適ではない。プロダクトの完成度、組織のサイズ、資金、得意な顧客像、既存の流通経路が違えば、適した打ち手も変わる。**マーケティングの正解は一つではない**。 ### 閉じた最適化 vs 開かれた最適化 — 「最適化」の質を分ける軸 **要点: 問題は最適化そのものではなく、狭い指標だけを入力にして最適化し続けることである。** 「最適化」と一言で言っても、何を入力として最適化するかで質は変わる。Marketing OS は最適化を二種類に分けて扱う。 | | **閉じた最適化** | **開かれた最適化** | |---|---|---| | 入力 | 自部署で観測できる特定指標（CPA / CVR / CTR / PV 等）のみ | 顧客・市場・現場・経営・実績の全階層からの声。観測・データ収集の 4 つの観測対象（Team / Customer / Market / Performance） | | 反映先 | 既存施策の運用パラメータ（入札・クリエ・LP 文言） | 戦略前提・ICP・ポジショニング・KPI 設計・施策ポートフォリオ自体 | | 前提 | KPI・ターゲット・施策ラインナップは固定 | 前提自体が同期と 再構築の対象 | | 学派 | "Adaptive Marketing" / Real-time Marketing 系統の戦術最適化高速化 | マーケティングサイクル型の組織学習 | | 失敗形 | **閉じた指標への固執**（Section 0.3）／戦術で戦略課題を解こうとする（Section 0.2）／「より洗練された無意味さ」（Section 0.5） | 本書と Marketing OS が目指す型 | 観測・データ収集の 4 つの観測対象（Team / Customer / Market / Performance）は、社内認識・顧客実態・市場変化・実績データを混ぜずに取り込むための最小単位である。事業モデルによっては、規制、パートナー、サプライチェーンなどを第 5 の観測対象にしてもよい。 機能しないマーケティング組織の多くは、閉じた最適化の中で努力を続けている。指標は動いているように見える。施策は走っている。報告会も回っている。だが事業の実体は変わらない。 これは「最適化していない」からではない。閉じたループの内側だけで最適化しているからである。顧客の実態、現場の認識、経営の意図、市場の変化が入力に入らなければ、ループ内で何回改善しても事業は動かない。 Marketing OS が目指すのは **開かれた最適化** である: - **顧客や組織のあらゆる階層の声を入力に取る** ── ICP 仮説（内部）と顧客実態（外部）をそれぞれ別の記録として分ける Customer Sync、現場と上層部の認識ズレを可視化する同期的戦略（Section 0.7）、過去実績と市場揮発情報（Performance / Market Sync）を独立して取り込む構造 - **前提自体を最適化対象にする** ── KPI・ターゲット・施策・聖域は所与ではなく、再構築で機械的に再構築候補にする（Section 3） - **最適化のループを開く仕組みを OS 側に持つ** ── 観測・データ収集 / 再構築 / 学ぶ段を独立段として配置し、戦術最適化だけに逃げ込む状態を防ぐ マーケティングサイクルが **再構築**（既成枠の組み替え）を名前に含むのは、戦術最適化の高速化だけで終わらせないためである。詳細は [`../../framework/marketing-cycle.md`](../../framework/marketing-cycle.md) を参照する。 **「マーケティングは最適化である」は前提として正しい。だが閉じた最適化だけになると、組織は学習しない。** 本書で列挙する問題は、ほぼすべて閉じた最適化への逃げ込みとして読める。 誤解してはいけないのは、**閉じた最適化そのものが悪いわけではない**ということだ。広告運用・LP 改善・メール配信・SEO・CRM など、日々のマーケティング実務の多くは閉じた最適化によって日次・週次で改善される。問題は、閉じた最適化を **戦略前提の検証や顧客理解の更新の代替** として使ってしまうことにある。閉じた最適化は必要である。しかし、それだけでは組織は学習しない。 ### この定義から導かれる帰結 1. **他社のベストプラクティスは、そのまま自社の正解にならない** ── 他社の最適は他社の制約条件下での最適であり、自社の最適とは別物。模倣はしばしば不適合になる 2. **「もっと頑張る」は戦略ではない** ── 数字を増やすこと自体を目的化すると、自分たちの能力を超えた戦線を引いて消耗するか、惰性で続いている施策に資源を吸われる 3. **既成 KPI・聖域・「ねばならない」は再構築できる** ── 引き継いだ目標、業界慣習、過去の成功パターンは、現在の自社条件に最適とは限らない（マーケティングサイクルの 再構築が要求する再構築） 4. **適合は一度では終わらない** ── 自社の能力もリソースも市場条件も時間とともに変わる。最適は移動する。だから マーケティングサイクルは**サイクル**であり、学ぶの終端は次の 観測・データ収集の起点になる 5. **「やったらいいね」は最適化ではない** ── 世の中のあらゆる施策をすべて拾うことは、能力とリソースに対する最適から最も遠い行為である（Section 2.2） この定義は、本書で列挙する問題を統一的に説明する。戦略と戦術の断絶、指標への固執、施策の自己目的化、責任の不在は、いずれも閉じた最適化に逃げ込んだ姿である。マーケティングサイクルの 5 段階（観測・データ収集 / 理解・分析する / 再構築 / 起動・実装する / 学ぶ）は、最適化を組織として続けるための動作に分解したものである。 ## 前提共有の不在 — すべての病理の根 **要点: マーケティング組織の問題は、同じ言葉で別のものを見ている状態から始まる。** なぜマーケティングチームは機能しないか。根にあるのは、次の 3 つの連鎖である。 - 自分の仕事が事業のどの問題に効くのかを語れない - 戦略と戦術が一方通行で分断される - KPI と施策が自己目的化する ### 個人の存在意義が言語化されていない メンバーの一人一人が、**自分が何のためにこの場所にいるのか**を理解していない。「広告運用担当だから」「コンテンツ担当だから」という職能の自己紹介はできても、**自分の仕事が事業のどの問題に効いているのか**を即答できる人は稀である。 さらに深刻なのは、**「マーケティング」という言葉そのものの共通見解がチーム内に存在しない**ということだ。あるメンバーは広告運用、別のメンバーはブランディング、別のメンバーはリード獲得をマーケティングと呼んでいる。同じ単語で別のことを語っているため、議論はそもそも噛み合わない。会議が無意味に長くなる、結論が出ない、決まったはずの方針が翌週にはなし崩しになっている ── これらは大半が「同じ言葉で別のことを話している」ことに由来する。 だからこそ最初に必要なのは、**自分たちがどこにいて、何のために存在しているのかを、チーム全体が共有し、前提を合わせること**である。マーケティングサイクルの 観測・データ収集が最初の段階に置かれているのはこのためである。 ### 戦略と戦術の双方向の断絶 もう一つの根が深い問題がある。**そもそもプロダクトやサービスに十分な強みがない**ことなど珍しくない。にもかかわらず、製品プロセス・セールス・カスタマーサクセス・プロダクト開発・ファイナンスから構造的に切り離されたマーケティングチームは、戦略レベルの決定に関与しないまま、**戦術レベルで戦略レベルの課題を解決することになる**。B2B SaaS や事業会社では特に、マーケが「リード獲得部門」として隔離され、価格・パッケージング・解約理由・契約条件・与信判断といった事業実態の核心情報が流入してこない構造が一般的である。 しかし、戦略レベルの失敗は戦術レベルでは解決できない。広告コピーをいくら磨いても、ファネルをいくら最適化しても、プロダクト・価格・ポジショニングが市場とずれていれば数字は動かない。だからマーケティングチームは機能しなくなる。 #### 断絶は双方向に起きている この断絶は、上から下への片方向ではない。**現場と上層部の両側で、それぞれ違うサイロが形成される**: - **現場側の症状**: 戦略レベルの理解（事業の現在地・なぜこの市場に賭けているか・収益構造）がないまま、個別の専門領域（広告運用 / SEO / コンテンツ / メール）に閉じて知識がサイロ化する。隣の担当者が何をやっているかも、自分の施策が事業全体のどの問題に効いているかも見えない。各人が自分の指標だけを最適化し、足し合わせても事業は動かない - **上層部側の症状**: 現場で何が起きているか（どのチャネルがどう動いているか・顧客が実際にどんな反応をしているか・施策の細部）の解像度がない。だから「具体的にどう PDCA を回すか」を語れず、抽象的な目標（売上 N 倍 / リード M 件）だけを降ろす。降りてきた目標は現場で「どう因数分解すれば届くか」が分からないまま戦術に砕かれ、結局は前期と同じ施策の繰り返しになる つまり、現場は「なぜそれをやるのか」を見失い、上層部は「どう実行するのか」を見失う。**両側から戦略と戦術の橋が落ちている**状態である。片側だけを直しても橋は架からない ── 現場研修だけ強化しても上層部の解像度は上がらず、経営層の戦略合宿だけやっても現場の知識サイロは解消されない。 #### なぜ双方向に断絶するのか — 戦略フローの一方向性 両側で同時にサイロが起きるのは偶然ではない。**戦略フローがほぼ常に「上から下への一方通行」で流れる**ことが、双方向の断絶を構造的に再生産している。 従来型のマーケ組織では、上層部が戦略（ICP / 強み / 競合 / 主要セグメント / 優先順位）を策定し、機能・チャネル・KPI に分解して現場に降ろす。この経路はあるが、**逆方向のチャネル ── 現場の認識を戦略に折り返す経路 ── がない**。 - 上層部は、現場が日々触れている顧客接点・競合の動き・施策ごとの肌感覚を構造的に受け取らない。だから「どう実行するか」の解像度が上がらない（上層部側の症状） - 現場は、自分の認識（このセグメントは無理がある／この強みは誰にも刺さっていない／優先順位は逆だと思う）を戦略に折り返す経路を持たない。だから「なぜそれをやるのか」の納得が降りてこない（現場側の症状） しかも、上層部が前提として置いた「自社の強み」「主要競合」「狙うべきセグメント」は、誰かがある時点で言語化したまま固定された仮説に過ぎない。現場の毎日のシグナルから繰り返し検証される仕組みがなければ、すぐ陳腐化する。**戦略は降ろされた瞬間から劣化を始める**。一方通行のフローは、この劣化を検出できない。 #### もう一つの構造要因 — タイムラインの不一致 フローの一方向性と並んで、双方向断絶を再生産しているもう一つの構造要因がある。**戦略と戦術が、そもそも別の時間軸で物事を見ている**ことだ。 - **戦略（経営側）は長期で物事を考える**。市場ポジションの確立、ブランド資産の形成、カテゴリー創造、組織能力の蓄積、LTV の伸長 ── これらは四半期や半期では動かない。経営層が真に見ている指標の多くは、年単位・複数年単位でしか有意味な差分が出ない - **戦術（現場側）は短期的な PDCA を見たがる**。広告の入札調整、LP の文言改善、メールの件名 A/B、SEO の順位変動、リードの当週着地 ── これらは日次・週次・月次で動かさないと運用が成り立たない。現場の判断材料は構造的に短期反応 KPI に偏る 両者は **「何を見て成功・失敗と判断するか」の時間軸そのものがズレている**。同じ施策を見ても、経営側は「半年後の市場認知への寄与」を問い、現場側は「今週の CPA」を問う。会話は噛み合っているように見えて、**評価関数が違う別ゲームを並行プレイしている**状態になる。 このタイムライン不一致は、0.2 冒頭の双方向断絶を **「情報が流れないから」** とは別の経路で再生産する: - 経営層は「短期 KPI は動いているが事業の地盤が出来ていない」と感じる。だが現場の運用言語（CTR / CPA / CVR）で表現された報告では、なぜ動いていないのかを語れない。結果、「現場は近視眼的だ」という抽象的な不満になり、また長期目標を上から降ろす - 現場は「半年・1 年単位の理想を語られても、明日の入札判断には使えない」と感じる。長期戦略の言語（カテゴリー創造 / ブランド資産）は運用パラメータに翻訳されないので、戦術的には依然として短期 KPI で回すしかない。結果、「上層部は地に足がついていない」という抽象的な不満になり、また短期 KPI に閉じる つまり、**情報量を増やしても時間軸を揃えなければ橋は架からない**。現場の運用ログを経営層に大量に共有しても、それは短期反応 KPI の解像度を上げるだけで、長期資産指標の議論にはならない。逆に、経営層のビジョンを現場に大量に共有しても、それは短期判断のフレームに変換されないまま標語化する。 これは Binet & Field（IPA）が示した **長期ブランド構築 vs 短期セールス活性化** の二系統が、同じ組織内で別レイヤーに分離して走るべきだという論点とも対応する。両者は対立するものではなく、**別の時間軸で因果検証されるべき別物**として並走させ、相互に翻訳する仕組みを置かなければならない（Section 2 で述べる P0–P3 評価の「時間軸」軸、および `marketing-misconceptions.md` Section 5 の 5 軸判定が、この翻訳の実装手段にあたる）。 両側を同時に直すには、戦略フローそのものに**逆方向の同期チャネル**を組み込み、かつ **長期資産指標と短期反応 KPI を時間軸ごと明示して並走させる**必要がある。解の方向性は 0.7 で詳述する。 責任の所在が曖昧になる構造（Section 2）は、しばしばここから始まる。**戦略の失敗を戦術の失敗に見せる／戦術の失敗を戦略の不在のせいにする**、両方向の指差しが同時に成立することで、誰も責任を取らない構造が完成する。 ### 失敗の症状 — 指標への固執と施策の自己目的化 戦略レベルの問題に手を出せず、戦術レベルでも構造的に勝てないチームは、次の 2 つに陥る: - **閉じた指標への固執**: CPA・CVR・PV など、自部署の管理範囲で動かせる**狭い指標**に異常に執着する。事業全体の収益への寄与は問わない（問えない）まま、指標の上下に一喜一憂する - **施策の自己目的化**: それらの指標すら成果が出ないと、今度は指標自体を放棄し、**「施策をやった感」「やること自体が目的化」する**。報告会の枚数が増え、施策の数が増え、しかし事業の何も変わらない どちらも本質的には同じ ── **戦略の失敗を直視できない**ことから来る逃避である。これを断ち切る前提として、KPI が経営ゴールに整合しているかを機械的に検査する必要がある（Section 2 の P0–P3 評価）。なお、ここで扱う「**施策**の自己目的化」と対をなす「**目標（KPI）**の自己目的化 ── 達成しても免除されず ratchet で更新され続ける構造」は Section 2.3 で別途扱う。 ### 「強みは持つもの」という誤ったフレーミング — 施策増殖のメカニズム 0.2 で「そもそもプロダクトやサービスに十分な強みがないことなど珍しくない」と述べた。これは例外ではなく、**むしろ標準である**。世の中には星の数ほど会社があり、その大半は他社に対して明確に差別化された強みなど持っていない。にもかかわらずマーケティングの言説は **「強みを作れ／強みを活かせ」** という命令ばかりを降らせる。この前提と現実のズレが、0.3 の指標固執と施策の自己目的化を生む。 #### 「何かやらなきゃ」と「上手く行かなそう」の挟撃 強みがない会社のマーケティングチームは、二つの圧力に同時に挟まれる: - **「何かやらなきゃ」**: 数字目標は降りてくる、競合は動いている、上司は施策を求める。沈黙は許されない - **「上手く行かなそう」**: しかしプロダクトに強みはなく、市場ポジションも明確ではない。何をやっても刺さらない予感がある この挟撃のなかで、唯一の生存戦略として現れるのが **「施策の数を増やすこと」** である。一つひとつの効果は薄くても、数を打てば「やっている感」は維持できる。失敗が一施策に局所化されるので、責任も希釈される。**KPI と施策が無限に増殖する根本原因は、能力の問題ではなく、強みの不在に対する組織的な防衛反応である**。 #### 強みは「宣言」ではなく「外部シグナルに晒された反復確認」によって前提化される ここで前提のフレーミング自体を疑う必要がある。**強みは会議室で宣言した瞬間に強みになるのではなく、顧客・市場・実績という外部シグナルに晒され、選ばれる理由として反復的に確認されたとき、初めて戦略上の前提として扱える**。1 回や 2 回の施策で強みは出ない。マーケティングサイクルでいえば 学ぶの還流が 10 回・20 回と積み上がった先に「うちはこの判断が他社より早い／深い／一貫している」という差が結果として残る。 順序が逆である: - ❌ **会議室で「強みがある」と合意 → それを所与にして戦略を組む → 反復する** - ⭕ **既存資産を初期仮説として書き出す → 外部シグナルに晒す → 反復で勝ち筋として残ったものを「強み」として前提化する** ここで「既存資産」は無視できない。特許・独自データ・流通網・規制上の許認可・ブランド認知・資本力・創業者の信用・既存顧客基盤などは、最初から組織に存在する **強み候補（resource endowment）** である。だが既存資産は **強み候補のままでは戦略前提にならない**。顧客が実際にそれを理由に選んでいるか、市場で差別化として機能しているか、実績で勝ち筋として再現しているかを確認して初めて「強み」と呼べる。 したがって、強みを「探す」ことに資源を投じる発想は、外部シグナルを欠いたまま会議で合意点を作る作業に堕しやすい。作れるのは強みそのものではない。強み候補を外部シグナルで確認する土台、つまりサイクルの反復速度と判断の一貫性である。詳細な決め方は [`../../framework/marketing-misconceptions.md`](../../framework/marketing-misconceptions.md) Section 8 で扱う。 #### 強みのない会社が取れる手は 2 つしかない 強み信仰を捨てたあと、強みのない会社が現実的に取れる手は二つに絞られる: 1. **競合がやらない／やれない地点を選ぶ**（Positioning を狭くする）── 市場・セグメント・チャネル・ユースケースのいずれかで、競合が降りてこない場所を選ぶ。広い土俵で勝てないなら、勝てる土俵を狭く定義する 2. **同じことをより速く回す**（サイクル速度を強みにする）── 同じ施策でも、仮説検証・撤退判断・再設計のサイクルを競合より速く回す。速度そのものが差別化資産になる 両方とも **「足す」ではなく「絞る」** 方向の動きであり、施策増殖と真逆のベクトルである。これが本質的なポイントで、強みがない状態で取れる打ち手は構造的に 再構築寄りになる。 #### 解は施策を増やすことではなく、捨てた後に残る一本 施策の数を増やしても強みは生まれない。むしろ逆で、`/release` 的に **「何をやらないと決められるか」** の方が、強みらしきものを露出させる。引き継いだ KPI、慣習で続いている施策、「やったほうがいい」と言われ続けてきた領域を機械的に列挙し、捨てる。**捨てた後に最後まで残る一本 ── それが、その会社が反復可能な唯一の判断軸であり、結果として強みになるもの**である。 「強みがないから施策を増やす」は防衛反応として理解できるが、構造的には逆効果である。**強みがないからこそ施策を絞る**。これが マーケティングサイクルが 再構築を独立した段階として置いている理由の一つでもある。 ### AI 時代はこの傾向を加速する AI は指標の集計・施策の量産・きれいな報告書の生成を、いくらでも高速化する。**戦略の失敗を直視しないままでも、戦術レベルの活動量だけはむしろ増やせる**。これは見せかけの生産性を作るには十分で、しかし事業の実体は何も変えない。 「AI が提案したから打ちました」「AI に分析させた結果です」という言い回しが、責任の所在をさらに薄める（詳細は `responsibility-design.md`）。AI 時代の機能不全は、**より洗練された無意味さ**として現れる。 #### 「間違っている時に人は判断できなくてはいけない」── Cognitive Surrender の実証 この論点はもはや観念論ではない。Shaw & Nave (2026) ["Thinking—Fast, Slow, and Artificial: How AI is Reshaping Human Reasoning and the Rise of Cognitive Surrender"](https://ssrn.com/abstract=6097646)（Wharton, 1,372 名 / 9,000+ 試行）は、人間が AI の出力に **認知を明け渡す（cognitive surrender）** 現象を経験的に確認している: - AI が正答のとき正答率 +25pt、AI が誤答のとき正答率 −15pt。**AI が利用可能であるという事実そのもの**が判断を歪ませる - AI が正答のとき 93%、AI が**誤答のときも 80%** が AI 出力を採用する - **AI の誤りを人間が訂正できた率はわずか 19.7%**。30 秒の時間圧をかけると訂正率はさらに 12pt 下がる - 著者らは Kahneman の二重過程理論（System 1 / System 2）に、**脳の外で動く人工的認知 = System 3** を加える Tri-System Theory を提示する 含意は明確である。**AI が間違っているとき、それを判断できる人間が組織内に残っていなければ、誤りはそのまま事業判断に流れ込む**。これは個人の注意力不足ではなく、AI 利用可能性 + 時間圧 + 信頼バイアスが構造的に重なった結果である。マーケティング組織は AI 採用が最も速い領域の一つであり、**「AI が言ったから打ちました」が常態化する前に、誤りを検出できる構造を OS 側に組み込む必要がある**。これが本書の第 6 原則（AI 判断の責任を人間が持つ）、AI Decision Accountability（採否ログの 4 要素）、Evidence Level、本番反映前チェックが「個人の意識」ではなく「省略不可項目」として強制される理由である（[`../cross-cutting/ai-in-marketing.md`](../cross-cutting/ai-in-marketing.md) §17.3 / [`../../reference/references.md`](../../reference/references.md) §E.9.5）。 #### 構造論としての整理 ただし、これは AI を否定する論ではなく、**AI が接続される戦略フローの構造に従属する**という構造論である。整理すると: > **AI は構造を直さない。閉じたループに入れれば閉じた最適化を高速化し、開かれたループに入れれば差分検出と組織学習を高速化する。問題は AI の有無ではなく、AI が接続される戦略フローの構造である。** 開かれたループでの正しい AI 活用例: 顧客インタビューのクラスタリング、競合変化の検知、施策ログの構造化、停止理由の整理、KPI 仮説の棚卸し、認識同期セッションでの差分ラベリング（`marketing-misconceptions.md` Section 7）。これらはいずれも **人間の判断を高速化する補助** であり、**判断を肩代わりさせる代理** ではない。AI を差分のラベラーに限定し、調停者にしない設計が、開かれたループへの接続を保つ。Cognitive surrender の 19.7% 訂正率（Shaw & Nave 2026）は、この設計を「あったら良い」ではなく**必須要件**にする。 ### 解くための起点 これを解消する起点はシンプルだが厳しい: 1. **自分たちの認識と知識を共有し、共通で理解する** ── 「マーケティング」が何を指すか、自分が何のためにいるか、事業の現在地は何か、を全員が同じ言葉で語れる状態にする 2. **現状の目的・KPI・課題を一旦再構築する** ── 引き継いだだけの目標、慣習で続いている KPI、誰も疑わない聖域を機械的に列挙し、保留する（マーケティングサイクルの 再構築） 3. **自分たちの現在地に合った適切な課題・戦術・目的を設定し直す** ── プロダクトの実力、市場の現状、チームのリソースに**適合**した目標へ再構成し、本番反映する（マーケティングサイクルの 起動・実装する） これは順番が大事である。1 を飛ばして 2 をすれば「方針がブレているだけ」に映り、1・2 を飛ばして 3 をすれば「いつも通りの目標が来た」だけになる。**0.1〜0.3 の自覚から始める**こと自体が、マーケティングサイクルの本当の起点である。 ### 同期的戦略への転換 — 戦略は「降ろす」のではなく「同期する」 0.2 で示した一方通行性を解くには、**戦略を「上が決めて下に降ろす」モデル**から、**戦略を「個々の認識を同期して合成する」モデル**に切り替える必要がある。Marketing OS ではこれを **同期的戦略 / 同期的目標** と呼ぶ。マーケティングサイクルが 観測・データ収集を独立した最初の段階に置いているのは、この切替を OS レベルで強制するためである。 #### 同期的戦略 / 同期的目標とは 「同期的」とは、**個々のメンバーが独立に書き出した認識を、同期（sync）したうえで戦略・目標を合成する**ことを指す。最低でも以下 4 項目を各メンバーが個別に書き出す: 1. **自社に対する認識** — 強み・弱み・現在地（「自社が顧客に選ばれている／いない理由」を含む） 2. **市場に対する認識** — 主要競合・競合との比較・市場の成長性／停滞性・想定セグメント 3. **自分／チームが達成すべき目標** — 半年〜1 年で何が動けば成功と言えるか（降ろされた目標ではなく、自分が責任を持てる範囲） 4. **施策の優先順位** — 走っている／走らせるべき施策のうち、何を最優先・何を捨てるか 集約すると、**全員が一致する項目はそのまま戦略の確からしい前提として固定でき、不一致が大きい項目こそが戦略の最も検査されるべき箇所**になる。従来の上意下達モデルでは、不一致は声の大きい人や役職で決着がついて見えなくなる。同期的戦略は、不一致を消さずに**戦略議論の入口**として扱う。 これは 0.4 で述べた「強みは宣言するものではなく、サイクルの結果として後から見えるもの」という再フレーミングとも整合する。**強みは上層部が宣言するものではなく、現場と上層部の認識が同期した結果として後から見えるもの**である。 #### Sync ≠ 平均化・合意形成 注意すべきは、**「同期する」は「合意を作る」とは違う**ことである。AI を使えば回答を平均化したり、それらしい合成案を出したりできる。だがそれは 0.5 で批判した「より洗練された無意味さ」を生むだけで、上意下達の劣化版にしかならない。 同期の本来の役割は: - **一致箇所と不一致箇所を可視化する**（一致箇所＝確からしい前提、不一致箇所＝検査必要箇所） - **不一致の構造を分類する**（情報量の違いか／解釈の違いか／優先度の違いか／そもそも前提が違うのか） - **不一致を 再構築の入力にする**（再構築候補として `/release` に渡す） ここまでが 観測・データ収集の責務である。最終的に「どの認識を採るか／どの目標を採るか」は 起動・実装する段で人間が判定する。**AI は差分のラベラーであって、調停者ではない**。これを守らないと、同期的戦略は再び「AI が代わりに決めてくれる装置」になり、責任の不在（Section 2 / `responsibility-design.md`）を悪化させる。 #### 観測・データ収集に同期メカニズムを内蔵する 同期的戦略は マーケティングサイクルの外側に置く別ツールではなく、**観測・データ収集段階の中核機構そのもの**である。観測・データ収集 は単なる「情報の置き場」ではなく、以下の手順で能動的に多人数の認識を回収・統合する段階として再定義される: 1. 各メンバーから上記 4 項目を独立に収集する（他人の回答に汚染されない順序で） 2. 表現の揺れを統合して論点単位に整理する 3. 一致 / 過半 / 単独意見の 3 層で可視化する 4. 不一致を 再構築の入力として書き出し、聖域・引き継ぎ KPI と並べて再構築検討に回す 5. 同期版の認識を `memory/workspaces//profile/` に保存し、理解・分析する / 起動・実装するの前提とする これは `/listen team-org` `/listen team-brand` `/listen team-workspace` が現状単一入力で扱っている層を、**多人数回答 + 差分集約**へ拡張するという意味を持つ。観測・データ収集が一人の頭の中で完結する限り、戦略フローは依然として一方通行のままで、0.2 の双方向断絶は解消しない。 #### なぜ AI 時代にこそ必要か 知識は AI で平準化された（Section 4）。「正しい戦略」「ベストプラクティス」を出力させること自体は誰でもできる。だが**その戦略を自社の現場認識に着地させる**作業は、依然として組織内の人間にしかできない。同期的戦略は、AI が出力する一般解と、現場が抱える固有解の**接続点**を作るための仕組みである。 逆に、戦略フローが一方通行のまま AI を導入すると、上層部の頭の中の戦略が AI で量産・洗練されるだけで、現場との断絶はむしろ広がる（0.5 の症状の AI 加速）。同期的戦略は、**AI を「上意下達の高速化装置」にしないための歯止め**でもある。 ## 独立的スキル vs 統合的活動 **要点: マーケティングは職能の足し算ではなく、事業判断をつなぐ統合活動である。** マーケティングは、しばしば独立的なスキルの束として扱われる。広告運用、SEO、コンテンツ制作 ── それぞれが専門領域として切り出され、個別のエキスパートが配置される。だがマーケティングとセールスは別物である。職能が違うという話ではなく、論理の階層が違う。 - **セールス**は基本的に個人で行う。個人が活動し、個人が意思決定し、その個人の成績が把握できる。再現性も個人の中に閉じる - **マーケティング**は本質的に統合的な活動である。何を作るか、いくらで売るか、誰に届けるか ── これらは個人の活動ではなく、組織としての判断であり、戦略そのものである この階層の混同が、以降の問題すべての根にある。 ## 責任の所在という根本問題 **要点: 判断する人、仮説を持つ人、結果を受け取る人が分かれると、マーケティングの責任は不明になる。** マーケティングには根源的な機能不全がある。**アカウンタビリティとレスポンシビリティが、誰に帰属するのか不明瞭**になる。 - 仮に責任の所在を明確化しても、失敗したときに実際にどう取るのか - 前期のマーケティング・キャンペーンが失敗したとして、マーケティング・チームが自らをすげ替えるか ── 現実にはまず起こらない - 責任を取れる人間がいない＝すげ替えができない＝もはや機能していないのと同じ 戦略レベルの失敗は、戦術レベルでは覆い隠せない。0.2 で述べた双方向の断絶は、ここで責任の所在を曖昧にする装置として機能する ── 互いに相手を指差せる構造があるかぎり、誰も自らをすげ替える必要がない。**最も KPI を設定しやすいように見えて、最も KPI 設計が難しいのがマーケティングである**。 ### KPI の経営整合性を P0–P3 で評価する KPI 設計の難しさは精神論で解消できない。事業部・施策レベルで設定された KPI が、**そもそも経営レベルのゴールにどれだけ親和性を持つか**を機械的に評価する必要がある。Marketing OS では P0–P3 の 4 段階で扱う: | 階層 | 定義 | 例 | 扱い | |------|------|-----|------| | **P0** | 経営ゴールそのもの。事業の存続・成長を直接定義する財務／市場指標 | 売上・営業利益・粗利・市場シェア・キャッシュフロー・Enterprise Value | 経営の責任範囲。マーケ単独では動かせないが、全 KPI はここに結びつく必要がある | | **P1** | P0 を強く規定する一段下の指標。複数四半期で P0 を動かす | ARR / GMV、新規顧客数、LTV/CAC、Payback Period、Net Revenue Retention | CMO / マーケ責任者の主戦場。経営との合意ライン | | **P2** | P1 を構成する活動指標。マーケ施策で動かせる中間 KPI | CVR、Activation 率、リテンション率、受注率、リード→商談転換率 | チャネル責任者・施策オーナーの管理指標 | | **P3** | P2 の先行・診断指標。施策単位で計測される最小単位 | CTR、インプレッション、エンゲージメント、メール開封率、ページ滞在時間 | 担当者の運用指標。**P2 への寄与パスが説明できなければ無効** | **重要な hedge**: P0–P3 の分類は固定的な普遍法則ではなく、**事業モデルごとに再定義される**。表に示した例は B2C サブスク / 中規模 SaaS を想定した代表例であり、たとえば PLG プロダクトでは Activation / Retention は PM 責任の P1 寄りに繰り上がるし、Enterprise B2B では LTV/CAC はセールス・CS・プライシングの合成指標として P1 をマーケ単独では持てない。**重要なのは階層名そのものではなく、各 KPI がどの上位成果に、どの時間軸で、どの因果仮説によって接続しているか**である（5 軸の判定は `marketing-misconceptions.md` Section 5 を参照）。 **ルール**: 1. **すべての KPI は上位層との関係を言語化する**。P3 → P2 → P1 → P0 のチェーンが描けない指標は、KPI ではなく単なる**観測値**として扱う（無視はしないが意思決定の根拠にしない） 2. **下位層ほど整合性チェックを厳しくする**。P3 は数が多く、自部署で動かしやすいため「閉じた指標への固執」（0.3）に最も陥りやすい。P3 を設定する際は必ず「これが動くと P2 のどの指標がどれだけ動くか」を仮説として明示する 3. **整合性の弱い KPI は 再構築候補**。P0 への線が説明できない KPI は、`/release` で再構築候補として列挙し、起動・実装する段で再設定する 4. **経営層と現場の整合は P1 で取る**。P0 だけ降ろすと現場は分解できず（0.2 上層部側の症状）、P3 だけ積み上げると経営は実感を持てない（0.2 現場側の症状）。**P1 を双方向の橋渡しレイヤとして固定する** このフレームは「KPI を増やすための道具」ではない。**既存 KPI を篩にかけて、整合性が説明できないものを廃棄するための道具**である。指標の数は減ることが正常である。 **短期成果主義への逃げ込みを防ぐ安全装置**: P0 への線が描けるかだけで選別すると、短期 CV に近い指標だけが残る。ブランド、カテゴリー創造、信頼形成、指名検索、既存顧客の心理変化のような **長期資産指標** が過小評価される。短期反応 KPI と長期資産 KPI は、別の時間軸で検証する必要がある。片側だけを残す KPI 設計は、短期最適化に閉じる。 ### KPI と施策の感応度 — 「やったらいいね」を排除する KPI は設定して終わりではない。**設定した KPI が、自分たちの打っている施策に実際に反応するか**を併せて検査しないと意味がない。マーケティング組織には「やったらいいね」が溢れる ── 動画広告もやったほうがいい、SNS もやったほうがいい、ホワイトペーパーもあったほうがいい。**全部やればいいことなんて世の中に山ほどある**。だが、それらが「自社の KPI にどれだけ効いているか」を答えられないまま走る限り、すべては「やった感」の総和にしかならない（0.3 施策の自己目的化）。 そこで P0–P3 の縦軸（経営整合）と直交する **横軸＝施策感応度** を導入する: | 感応度 | 定義 | 判定 | |--------|------|------| | **High** | 施策を動かすと KPI が**観測可能な範囲で**動く。因果の説明が立ち、ラグも特定できる | KPI として有効。継続 | | **Mid** | 動くが、他要因のノイズが大きく単独施策の寄与を分離できない。サンプル数か観測期間が不足 | 計測設計の改善で High に昇格できるか検証。できなければ Mid のまま参考指標 | | **Low** | 施策を動かしても KPI が動かない、または動いたかどうかすら判定できない | KPI ではない。**施策を切るか、KPI を切り替える** | **ルール**: 1. **新規施策には KPI 仮説と感応度の事前宣言を必須にする**。「この施策で KPI X が Y% 動くと想定する／動かなければ撤退する」を文書化していない施策は、走らせる前に止める 2. **「やったらいいね」の檻**: 「業界他社がやっているから」「やらないより良いから」「資料映えするから」しか理由のない施策は、感応度評価以前に 再構築候補。世の中の「やったほうがいい」をすべて拾う必要はない ── **自社の KPI に効くものだけ**を選ぶ 3. **整合性 × 感応度のグリッドで選別する**: P0–P3 の縦軸と High/Mid/Low の横軸で交差させる。**P3 × Low の象限はゼロにする**（経営にも結びつかず、施策にも反応しない指標は存在意義がない） 4. **施策側からも逆引きする**: 走らせている施策を列挙し、それぞれに「どの P 階層のどの KPI を、どの感応度で動かすか」を埋めさせる。空欄になる施策が「やったらいいね」の正体である P0–P3（縦＝経営整合）と感応度（横＝施策へのリアクション）は、KPI 設計の二つの直交軸である。**片方だけ通っても KPI は機能しない**。 ### KPI の自己目的化と目標ラチェット — 達成しても解放されない構造 経営整合性（2.1）と施策感応度（2.2）の二軸を通過した KPI でも、もう一段階の構造的病理が残る ── **KPI が「事業目的を測る計器」であることをやめ、「達成し続けること自体が目的」になる**現象である（0.3 の **施策**の自己目的化に対する **目標** の自己目的化）。一度 KPI が自己目的化すると、組織は次のループに入る: - **目標は毎年自動的に更新される**。前年比成長を要求する構造のなかで、KPI 値そのものが伸び続けることが暗黙の前提になり、適合判定なしに数字だけが先に動く - **達成は次の更新のトリガーになる**。目標を達成した個人・組織が「役割を果たした」と認められて目標を免除されることはなく、達成すればするほどゴールはさらに先に動く（target ratchet） - **組織や個人の実行余力を超える**。市場規模・プロダクト成熟度・チーム実装力に対する適合判定なしに線形成長を強制するため、ある時点から「達成不可能な目標を持ち続ける」ことが既定値になる - **KPI は形骸化する**。達成しても報われず、未達でも通常運転 ── という経験が積み重なると、KPI は意思決定の指標から「儀式として唱える数字」に退化する。短期反応 KPI（CTR・CVR・指名検索）も長期資産 KPI（売上・LTV・市場シェア）も区別なく形骸化の対象になる このループから抜けられるのは、**目標を上回る速度で市場・プロダクト・組織が拡張している、ごく一部の高成長組織だけ**である。それ以外の大多数では、ratchet を緩めない限り KPI は数年で機能を失う。 **運用ルール**: 1. **達成条件を文書化する**: 目標を立てる時点で「達成したら次にどう扱うか」（解除 / 維持 / 上方更新 / 別 KPI への切替）を併せて宣言する。空欄なら ratchet が既定値として自動稼働する 2. **目標の妥当性を毎サイクル再評価する**: 前年比 +X% という慣性で更新するのではなく、市場規模・プロダクト現在地・チームの実行余力から逆算した適合範囲を 観測・データ収集で取り直し、再構築で旧目標を再構築する 3. **形骸化シグナルを観測する**: 「全社で誰も信じていない目標が掲示され続けている」「未達でも何も起きない」「達成しても祝われない」── これらは KPI が判断指標から儀式に退化した兆候。再構築の機械的列挙対象に組み込む 4. **長期資産 KPI を ratchet から守る**: 短期反応 KPI と異なり、ブランド・カテゴリ創造・指名検索のような長期指標は線形成長を強制すると形骸化が早い。時間軸を分けたうえで、線形 ratchet をかけない別運用にする **KPI 設計の三軸**: | 軸 | 問い | 失敗時の症状 | |----|------|------------| | 2.1 経営整合性 (P0–P3) | 上位ゴールに結びつくか | 観測値が KPI を僭称する | | 2.2 施策感応度 | 自社の施策で動くか | 「やったらいいね」の蓄積 | | 2.3 自己目的化 / ratchet | 達成は何を意味するか | 形骸化、未達常態化、目標の儀式化 | 2.1 / 2.2 だけ通っても、2.3 のループに入れば KPI は機能を失う。**三軸すべてを通過して初めて KPI は意思決定指標として機能する**。 ## 再構築不在症候群 — 止めた記憶が残らない構造 **要点: 施策を止めた理由が残らない組織は、同じ施策を何度も再発明する。** 「直近 6 ヶ月で停止した施策は？」と問われて即答できる経営者・マーケ責任者はほぼいない。停止が**決定**として処理されず、自然消滅・予算切れ・担当者異動で**事象**として消えていくため、組織記憶に残らない。これは怠慢ではなく、再構築が独立した動作として OS に組み込まれていないことの構造的帰結である。症状は 3 段階で進行する。 ### 停止記憶の欠落 再構築が「やめる」という能動的な決定として記録されない。施策は静かに走らなくなり、誰も終了宣言をしない。停止理由は誰のメモにも残らず、数ヶ月後には「やったかどうか」自体が曖昧になる。当事者ですら「いつ止めたか」「なぜ止めたか」を答えられない。**再構築の履歴が残らないため、次サイクルで同じ施策が再発明され、止めた理由ごと忘却される**。 ### リソースの即時充填 施策が止まって空いたリソース（人月・予算・運用枠）は、**観測される前に次の施策で埋められる**。「空けたまま観察する」「空けた状態を 再構築の判断材料として使う」という選択肢が、組織の既定値に存在しない。沈黙への耐性がないため、隙間は秒単位で施策に再配分される。これにより 0.4 の「何かやらなきゃ」圧力が機械的に再生産され、施策の増殖は止まらない。 ### 新規余白の枯渇 3.1 + 3.2 の結果、稼働率は常に 100% に張り付く。再構築（再構築で前提を組み替え、起動・実装する段で別の戦線に張り直す）に必要な**思考と実装の余白がゼロ**になる。組織は「忙しいまま動かない」状態に陥り、新しい仮説検証や撤退判断のサイクル速度（0.4 で示した強みのない会社が取れる手の一つ）が構造的に上げられなくなる。新しいチャレンジができないのはリソース不足ではなく、**止めた記録が残らないので止めた事実が組織に蓄積しない**ことに由来する負のサイクルである。 ### 解の方向性 再構築を「事象」から「決定」に昇格させる仕組みが要る: 1. **停止ログの強制**: 施策には開始時に撤退条件を文書化し、撤退時には停止理由・空いたリソース量・再配分の有無を `/learn` で記録する。停止記憶が残るまで、再構築は次サイクルの入力にならない 2. **空白期間の保護**: 施策停止で空いたリソースは、最低一定期間（たとえば次の 観測・データ収集サイクル開始まで）**再配分しない**ことを既定値にする。沈黙を耐えるルールを OS 側に持つ 3. **`/release` の出力に停止施策一覧を必須化**: 直近 90 日で停止した施策が列挙できなければ、再構築議論の材料がそもそも欠落している。停止履歴の可視化を 再構築 skill の前提条件にする 4. **検証施策は終了時点で三分類を強制**: 検証枠で走らせた施策は、検証期間終了時点で必ず「**撤退** / **継続検証** / **本番化**」のいずれかに分類してログに残す。何となく通常運用に吸収されることを禁止する。これは「成功 → 通常運用化」の経路でも同じで、本番化されたなら **検証枠から本番枠への明示的な移管** として記録する。検証と通常運用が混線すると、本番枠の施策に対する撤退判断が機能しなくなる（撤退条件が検証時のものから引き継がれず、本番運用ルーチンに紛れて消える） ## 失敗できないという病 **要点: マーケティングは失敗から学ぶ必要があるが、失敗の単価が高いため学習が起きにくい。** マーケティングを成熟させるには経験が必要である。経験を積むには失敗が必要である。ところが、マーケティングにおける失敗は致命的になりやすい。 - 広告運用の失敗は即座に予算の毀損につながる - SEO をあえて失敗させる者はいない - 既存プロダクトに施策を試して奏功しなかったとき、担当者がその責任を取れるかと問えば、答えは多くの場合否 つまり、**失敗できる小さな仕事が組織の中にほとんど存在しない**。失敗を許容できる空間がなければ、組織として学習することはできない。マーケティングは「学習しないチーム」を生みやすい。 ## 知識の平準化と経験の希少化 **要点: AI 時代に希少なのは知識そのものではなく、判断と失敗を含む経験である。** マーケティングは「誰でもできる仕事」になりつつある。AI 登場以前から知識そのものは平準化していた。フレームワークも事例もインターネット上に溢れ、書籍も無数にある。 - **希少なのは知識ではない、経験である** - 失敗の経験を含む、判断の蓄積こそが希少資源 - この非対称が、マーケティング機能の内製化をいっそう困難にする ## 属人化と新陳代謝のジレンマ **要点: 強い担当者に依存するほど成果は出やすいが、組織としては入れ替わりに弱くなる。** 社内に強いエキスパートが存在すればするほど、業務は属人化する。 - 属人化した業務は他の人間が代替できない - 担当者が抜けたとき、組織は止まる - 会社の命運を一人の担当者が握っているといっても過言ではない状態に陥る だから、本当のインハウス化とは、**属人化と新陳代謝という二つの課題を同時に解くこと**である。属人化を防ぎながら、しかも経験の蓄積を組織に残し、人が入れ替わっても機能する仕組みを作る。これを成し遂げている会社は稀である。 ## なぜ外部業者は消えないのか **要点: 外部業者の価値は知識だけではなく、実行能力、第三者視点、責任境界の明確化にもある。** 「マーケティング・コンサルタントは AI で消える職業だ」という言説は半分は当たっている。しかし冷静に考えると別の答えが見える。 **外部業者が引き受けているのは知識だけではない。専門性、実行キャパシティ、第三者視点、そして何より責任境界の外形化である。** 具体的には以下のような多軸の価値が同時に提供される: - **専門人材の一時的な調達** — フルタイム採用するには需要が立たない領域（広告運用専門・SEO 技術専門・MMM 分析等）への即時アクセス - **他社事例・業界横断知見** — 自社内では絶対に蓄積できない、複数業界・複数ステージの実装知 - **メディア運用・制作・分析の実行キャパシティ** — 内製で抱えると稼働率が低くなる業務の弾力的なスケール - **社内政治から距離を置いた第三者視点** — 内部では言いにくい指摘・聖域への切り込みを契約上の責務として行える主体 - **ベンダーや媒体とのネットワーク** — 単発取引では獲得できない優遇条件・先行情報・運用サポート - **責任境界の外形化** — 契約という形で責任の所在と引き渡し条件を文書化できる このうち最後の **責任境界の外形化** が、「AI で消える」という言説に最も抵抗する性質を持つ。なぜなら、**責任を外部化しないと新陳代謝しない**からである。インハウスのマーケティング・チームは、失敗したときに自らをすげ替える機能を構造的に持たない（Section 2 / Section 6）。前期キャンペーンの失敗を理由に担当者を入れ替えることも、評価を実態どおりに下げることも、現実にはまず起こらない。だから組織の中で責任は循環せず、結果として学習も人の入れ替わりも起きない。 外部業者を介在させると、契約という形で責任の所在と引き渡し条件が外形化される。失敗した代理店は切られ、別の主体が入る ── これは内部では起こりにくい新陳代謝の代替である。一見不健全に見えるこの構造は必ずしも悪ではない。責任を取れない組織が、責任を取れる主体を組み込むためのひとつの解である。 ただし**健全な外部化と不健全な外部化を分ける線**は存在する: - **不健全**: とりあえず計測する、とりあえず施策をやる、とりあえず外部化する。状況は変わらない。徐々にやらなくなる。早すぎる自動化、無意味な施策、やっただけの施策、責任の切り離し - **健全**: 責任の所在を曖昧にする目的での外部化を排する。外部に責任を持たせるなら、その責任の境界と引き渡し条件を明示する 「とりあえず」の連鎖がマーケティングを骨抜きにする。健全/不健全を分けるのは、**責任の所在を曖昧にしたいかどうか**の一点である。 ## マーケティングサイクルはこれらにどう応答するか **要点: マーケティングサイクルは便利な作業手順ではなく、ここまでの組織問題に対する設計である。** | 病理 | マーケティングサイクルの応答 | |------|-----------| | **前提共有の不在**（個人の存在意義・「マーケティング」の共通定義の欠如） | **観測・データ収集 / Team Sync**: チーム全員で「自分たちはどこにいて、何のためにいるか」を同じ言葉で言語化する。職能ではなく事業課題の言語化を強制する | | **顧客との同期チャネルの不在**（ICP 仮説と実態のズレが検出されない） | **観測・データ収集 / Customer Sync**: 顧客の生の声・行動・反応を独立した観測対象として保持する（営業ログ / サポート / レビュー / SNS / 解約理由）。仮説（ICP）と実態（Customer Sync）のズレを 再構築の自動入力にする | | 統合的活動が独立スキルに分解されている | **観測・データ収集**: 全関係者の情報・認識・課題をサイロから出させ、戦略レイヤを再可視化する | | 責任の所在が不明瞭 | **理解・分析する**: 何を理解しているか／していないかを明示し、判断責任の在処を可視化する | | KPI が経営ゴールに結びつかない／施策に反応しない（「やったらいいね」の蓄積） | **再構築 → 起動・実装する**: P0–P3（経営整合）× 感応度 High/Mid/Low（施策反応）の二軸で既存 KPI と施策を選別し、説明できないものを再構築する（再構築）。残った KPI と施策だけで 起動・実装する段を組み直す | | **KPI の自己目的化と目標ラチェット**（達成しても免除されず、毎年自動的に上方更新され、実行余力を超え、形骸化する） | **再構築 → 観測・データ収集 → 起動・実装する**: 目標設定時に達成条件（解除 / 維持 / 上方更新 / 切替）を併記する規約を 起動・実装する段に組み込む。前年比慣性での更新ではなく、市場規模・プロダクト現在地・チームの実行余力を毎サイクル 観測・データ収集で取り直し、適合外の目標は 再構築で機械的に再構築する。「未達でも何も起きない／達成しても祝われない」を形骸化シグナルとして検出し、儀式化した KPI は 再構築候補に列挙する | | **再構築不在症候群**（停止が決定として記録されない／空いたリソースが即時充填される／再構築用の余白が常にゼロ） | **再構築 → 学ぶ**: 施策開始時に撤退条件を文書化し、停止時は理由・空きリソース・再配分の有無を `/learn` で記録する。停止記憶が組織に残るまで 再構築議論は空回りすると認める。`/release` の出力には直近 90 日の停止施策一覧を必須項目として組み込み、空いたリソースは次の観測・データ収集サイクル開始まで再配分しない既定値で「沈黙の耐性」を OS 側に持たせる | | **「強み信仰」が施策増殖を生む**（強みがない前提を直視できず「何かやらなきゃ」と「上手く行かなそう」の挟撃で施策の数を増やす） | **再構築 → 起動・実装する サイクルの反復**: 強みは資産ではなく、同じ判断軸を反復した結果として後から見えるものと再定義する。一手目は施策を**増やすことではなく捨てること**（再構築）── 捨てた後に残る一本が反復可能な判断軸になる。強みがない会社が取れる手は「Positioning を狭くする」か「サイクル速度を上げる」の 2 つに絞られ、両方とも 再構築寄りの動き | | **戦略と戦術の双方向の断絶 / 戦略フローの一方向性**（現場が「なぜ」を見失い、上層部が「どう」を見失う／上から降ろされた前提が現場認識とズレたまま再生産される／指標固執と施策の自己目的化） | **観測・データ収集（同期的戦略）→ 再構築 → 起動・実装する**: 戦略を上意下達ではなく多人数の認識同期で組み立てる（観測・データ収集に Team Sync + Customer Sync を内蔵）。一致箇所を確からしい前提として固定し、不一致を 再構築の入力にして引き継ぎ KPI・聖域と並べて再構築候補にする。残った前提から自社の現在地に適合した課題・戦術・目的を再設定する（起動・実装する）。戦略の失敗を戦術で覆い隠す逃避も、戦術の失敗を戦略不在のせいにする逃避も、両方向の指差しを禁じる | | 失敗できないので学習しない | **再構築**: 既存 KPI・聖域・「ねばならない」を再構築、失敗できる余白を設計する | | 知識は溢れているが経験が希少 | **起動・実装する → 学ぶ**: 自社プロダクトの実力に適合した目標とステップに再構成して本番反映し（起動・実装する）、結果を memory に書き戻して経験を蓄積する（学ぶ） | | 属人化と新陳代謝のジレンマ | **マーケティングサイクル全体**: 個人の頭の中ではなく `knowledge/` `memory/` に経験を構造化して残し、人が入れ替わっても機能する仕組みにする | | AI による洗練された無意味さの加速 | **マーケティングサイクル全体**: 「AI が言ったから」を判断の根拠にしない。再構築 と 起動・実装する / 学ぶ段で必ず人間が再構築と適合判定を行い、`/learn` で採否ログを残す | マーケティングサイクルは AI 協働の便利な型である以前に、これら**組織の病理に対症する設計**である。OS の各段階の意味を見失ったときは本書に戻ること。 ## 関連ドキュメント - `knowledge/marketing/framework/marketing-cycle.md` — マーケティングサイクル canonical OS の定義・段階の責務・スキル対応 - `knowledge/marketing/playbook/knowledge-areas/org-capability/learning-organization.md` — 学習プロセスをチームに埋め込む方法 - `knowledge/marketing/playbook/knowledge-areas/org-capability/responsibility-design.md` — 責任の所在の設計、AI 委譲時代の責任外部化問題 - `knowledge/marketing/framework/marketing-misconceptions.md` — 本書の各論を運用条件付き定式に精緻化した 8 題（強みの定義 / 責任 / セールス比較 / 失敗設計 / KPI 5 軸 / 外部業者境界 / 同期 → DRI 選択 / 強みの決め方） --- title: 統合・戦略 chapter: "05" part: 2-knowledge-areas status: revised visibility: public authors: - claude reviewers: [] revision: 0.2 updated: 2026-05-19 related-skills: - /listen - /insight - /release - /next related-chapters: - foundations/principles - foundations/cycle - foundations/performance-domains - knowledge-areas/icp-positioning - knowledge-areas/stakeholder - cross-cutting/org-learning - cross-cutting/maturity-model related-knowledge: - knowledge/marketing/framework/marketing-cycle.md - knowledge/marketing/framework/marketing-frameworks.md - knowledge/marketing/framework/signature-frameworks.md --- # 統合・戦略 ## 概要と対象範囲 マーケティング戦略全体の**整合性**と、マーケティングサイクル全体の **orchestration（オーケストレーション）** を扱う。他の知識エリアを束ねる「統合」機能を担い、再構築意思決定の所在を明示する章である。 本章は他の KA と性格が異なる。他の KA がそれぞれの専門領域を扱うのに対し、本章は**それらの整合性**そのものを扱う。具体的には: - 12 知識エリア間の整合性をどう保つか - マーケティングサイクル全体の進行をどう管理するか - 戦略レイヤーと最適化レイヤー（Adaptive）の分離をどう運用するか - 再構築意思決定（前提を組み替える判断）の責任主体は誰か Marketing OS の独自貢献は、**戦略策定を一回限りの活動ではなく、組織学習サイクルの一部として運用する構造**を持つことにある。戦略は降ろすものではなく、サイクル内で更新されるものとして扱う（[`../../foundations/principles.md`](../../foundations/principles.md) Principle 1）。 ## 業界トレンドと新興手法 - **AI 駆動の戦略策定**: シナリオプランニング・競合シミュレーションの自動化 - **組織学習速度の戦略変数化**: 「どれだけ速く学ぶか」を戦略の中心指標に据える - **Adaptive Strategy**: 環境変化に応じて戦略自体を継続的に更新するアプローチ - **OKR / 北極星指標との接続**: 戦略を測定可能な目標に翻訳する運用 - **AI 採否ログの戦略 KPI 化**: 採否ログの記録率を戦略遂行の指標にする組織が現れる Adaptive Strategy は CMO Marketing OS Playbook の戦略レイヤーと親和性が高いが、**前提自体を最適化対象に含める**かどうかで本書とは区別される（[`../../foundations/principles.md`](../../foundations/principles.md) Principle 2）。 ## テーラリング | 文脈 | 重点 | |---|---| | **B2B エンタープライズ** | 戦略策定の権限が分散しやすい。意思決定境界の明示が必須 | | **B2B SaaS** | Product-Led Growth の戦略統合。プロダクトと連動した戦略更新サイクル | | **D2C** | ブランド戦略と需要創出の統合。リテンション戦略の比重高 | | **リテール** | チャネルミックスの統合（オンライン / 店舗）が中心 | | **規制業種** | 戦略の承認プロセスが厚い。本番反映前チェックとの連動 | | **スタートアップ（PMF 前）** | 戦略 = 仮説。再構築を週次で回す | ## プロセス（マーケティングサイクル × ITTO） ### 観測・データ収集段のプロセス 戦略整合性のための同期。 - **投入物（Inputs）**: 観測対象別レポート（他 KA から）、Performance ベースライン、ステークホルダー認識 - **手法と道具（Tools & Techniques）**: 戦略マップの可視化、KA 間整合性チェック、認識ズレの構造化 - **産出物（Outputs）**: 統合戦略マップ、不整合リスト、再構築入力候補 ### 理解・分析する段のプロセス 戦略選択肢の生成と評価。 - **投入物**: 観測・データ収集段の統合マップ、JTBD（06 章）、ICP（07 章）、Brand（08 章） - **手法と道具**: 4 視点切替、戦略選択肢の ICE / RICE 評価、シナリオプランニング - **産出物**: 戦略選択肢リスト、判断材料、トレードオフ仕様 ### 再構築段のプロセス **本章の中核**。既成戦略・聖域の機械的列挙と再構築。 - **投入物**: 現行戦略、引き継ぎ KPI、現行施策ポートフォリオ、認識ズレリスト - **手法と道具**: 戦略の前提抽出、聖域・「ねばならない」の機械的列挙、ゼロベース問い直し、トレードオフ顕在化 - **産出物**: 再構築決定、再構築された戦略仮説、残す KPI / 施策 / 前提 ### 起動・実装する段のプロセス 戦略の本番反映と実行管理。 - **投入物**: 再構築された戦略、理解・分析する選択肢、自社実力・リソース - **手法と道具**: 本番反映前チェック、実行管理成果物の選択（§5.5）、本番反映ロードマップ - **産出物**: 統合戦略の本番反映、ステークホルダー合意、計測同時着地 ### 学ぶ段のプロセス 戦略遂行の還流と更新。 - **投入物**: 各 KA の 学ぶ産出物、横断的成果指標 - **手法と道具**: Learning Velocity 測定、戦略仮説の検証、ドメイン間トレードオフの再評価 - **産出物**: 戦略更新、profile への書き戻し、次サイクル戦略入力 ## 実行管理成果物（L3） 複数人・複数日・外部依存・承認・高リスクを含む施策では、本番反映前チェックに加えて以下の実行管理成果物を併用する。PMBOK のスケジュール、ステークホルダー、リスク、スコープ管理、リソースの観点を、起動・実装する段に限定して軽量に取り込む。 ### 成果物一覧 | 成果物 | PMBOK 的観点 | 何を管理するか | 使う条件 | |---|---|---|---| | **delivery-plan.md** | スケジュール / 統合管理 | マイルストーン、依存関係、ブロッカー、本番反映日 | 複数日・複数人・外部依存がある | | **stakeholder-map.md** | ステークホルダー / ガバナンス | 承認者、相談先、通知先、反対・懸念の所在 | 承認・部門調整・顧客影響がある | | **risk-register.md** | リスク | リスク、トリガ、軽減策、発生済みの問題、エスカレーション | 高インパクトリスクがある | | **change-log.md** | スコープ / 変更管理 | スコープ・予算・KPI・スケジュール・ロールバック変更の理由と承認者 | 起動・実装する中に重要変更が発生した | | **resource-plan.md** | リソース / 財務 / 調達 | 社内工数、外注、ツール、AI 委譲範囲、実行余力リスク | 工数・外注・AI 委譲が成果に影響する | これらは **マーケティングサイクルの必須成果物ではない**。簡易運用では必要なものだけ、標準運用 / 厳格運用では本番反映前に要否を判断する。重要なのは「PMBOK を全面導入する」ことではなく、マーケティングサイクルが弱くなりやすい実行管理を 起動・実装する段に限定して支えることである。 ### 実行管理成果物と本番反映前チェックの関係 本番反映前チェック（[`../../foundations/cycle.md`](../../foundations/cycle.md) §2.5.3）の 7 項目は本番反映前の最低条件であり、実行管理成果物はそれを補完する。 - **オーナー** ↔ **stakeholder-map.md**: 個人 1 人の特定と、関係者の全体像 - **計測** ↔ **delivery-plan.md**: 計測同時着地と、マイルストーン全体 - **ロールバック** ↔ **risk-register.md**: 単一施策のロールバックと、リスクポートフォリオ - **承認** ↔ **change-log.md**: 個別承認と、変更履歴 ## 既存戦略フレームワークとの関係 CMO Marketing OS Playbook は既存のマーケ戦略フレームワーク（AARRR / STP / 4P / RAM-CE / Crossing the Chasm 等）を否定しない。これらは戦略レイヤーの「**何を考えるか**」の地図を提供する。CMO Marketing OS Playbook が補強するのは「**どう組織として更新し続けるか**」の運用である。 | フレームワーク | 主な射程 | マーケティングサイクルへの組み込み | |---|---|---| | **AARRR** | ファネル設計 | 理解・分析する / 起動・実装するの Demand & Lifecycle KA | | **STP** | ターゲティング | 観測・データ収集 / 理解・分析するの ICP & Positioning KA | | **4P** | ミックス | 起動・実装するの Content & Channel KA | | **RAM-CE** | カテゴリ想起 | 理解・分析する / 起動・実装するの Brand & Narrative KA | | **Crossing the Chasm** | 採用ライフサイクル | 観測・データ収集 / 理解・分析するの Product Marketing & JTBD KA | | **Blue Ocean** | カテゴリ創造 | 再構築 / 理解・分析するの ICP & Positioning KA | これらフレームワークの**選択**自体が戦略判断の対象である。「どのフレームワークを採用するか」を 再構築で機械的に列挙し、自社文脈に最適なものを選ぶ。 ## 再構築意思決定の責任主体 再構築段で誰が「再構築する」決断をするかは、組織により異なる: | パターン | 責任主体 | 適する組織 | |---|---|---| | **CMO 単独** | CMO がアカウンタブル | 戦略権限が CMO に集約された組織 | | **CEO + CMO 合議** | CEO と CMO の双方の合意 | 経営直結のマーケ組織 | | **経営合議** | 経営チーム全体 | 戦略がマーケ単独で決まらない組織 | | **取締役会承認** | 取締役会の承認が必要 | 大規模変更・公開企業 | 合議モデルを採用しても、**最終アカウンタビリティは 1 人に集約する**（補題 B）。「みんなで決めた」は責任の所在を消す典型パターンである。 組織政治を超えて「これは違う」と言う判断は AI には引き受けられない。再構築は構造的に人間に残る（[`../../foundations/cycle.md`](../../foundations/cycle.md) §2.4.5）。 ## アンチパターン - **戦略の儀式化**: 年次戦略策定で立派なドキュメントが作られるが、マーケティングサイクル内で更新されない - **戦略不在**: KPI と施策はあるが、整合性ない。「何を選び、何を選ばないか」が言語化されていない - **降ろす戦略**: 戦略を上から降ろすだけで、現場の Customer Sync・Performance Sync と接続しない - **合議による戦略合成**: 同期会議で戦略が決まると期待する（補題 G 違反） - **実行管理成果物の過剰運用**: 1 人事業まで delivery-plan / risk-register を要求する。サイクルが止まる - **戦略レイヤーと最適化レイヤーの混同**: Adaptive 系の戦術最適化を戦略と呼んで満足する（Principle 2 違反） - **整合性監査の不在**: 12 KA がバラバラに動いていても誰も気づかない構造 - **再構築の権限分散**: 誰が再構築を決めるかが曖昧で、結局誰も決めない - **戦略 KPI の自己目的化**: 戦略遂行を測る指標が遂行されたかどうかしか測らず、成果に接続しない ## 関連 skill / agent - **`/listen team-org`** — 組織全体の戦略整合性の同期 - **`/insight ceo`** — 経営視点での戦略評価 - **`/insight consultant`** — 第三者視点での戦略診断 - **`/release`** — 再構築意思決定の触媒 - **`/next`** — サイクル全体の現在地と次の一歩の提示 skill ↔ process の完全な対応は [`../../appendices/skill-mapping.md`](../../../../base/skill-mapping.md)。 ## 今後の拡張論点 - **本章の射程の広さ** — 「統合・戦略」は射程が広く、他 KA のメタ層になりがち。具体記述をどこまで本章に置き、どこまで他章に逃がすか - **再構築意思決定の所在モデル** — §5.7 で 4 パターン示したが、現実はもっとグラデーションがある。「業種 × 規模 × 成熟度」のマトリクスで標準化すべきか - **実行管理成果物と PMBOK との関係** — PMBOK の成果物を全面踏襲するのか、マーケ用に再設計するのか。本章では 5 つに絞ったが、追加すべきものはないか - **「戦略策定セッション」の運用** — 一回限りの戦略策定セッションを マーケティングサイクルにどう組み込むか。観測・データ収集から始めるとセッションが進まないリスク - **AI 駆動の戦略策定との境界** — シナリオプランニング等を AI に委ねる範囲。再構築だけ人間に残すで十分か --- title: 市場・顧客知能 chapter: "06" part: 2-knowledge-areas status: revised visibility: public authors: - claude reviewers: [] revision: 0.2 updated: 2026-05-19 related-skills: - /listen - /insight related-chapters: - foundations/cycle - knowledge-areas/icp-positioning - knowledge-areas/product-marketing-jtbd - cross-cutting/ai-in-marketing related-knowledge: - knowledge/marketing/playbook/knowledge-areas/product-marketing-jtbd/customer-research-jtbd.md --- # 市場・顧客知能 ## 概要と対象範囲 市場・顧客・競合の認識を継続的に取り込み、組織判断の前提を更新し続ける営み。CMO Marketing OS Playbook の中で **観測・データ収集段の主たる知識エリア**である。 本章の射程は次の 3 つに分かれる: - **顧客の認識**: JTBD、購買決定要因、離脱理由、未充足ニーズ - **市場の認識**: 業界構造、競合動向、プラットフォーム仕様、規制環境 - **自社実績の認識**: 過去施策の成否、ベースライン、ファネル現状値 これら 3 つを統合した「組織が今何を理解しているか」を可視化することが、本章の中心命題である。ICP・ポジショニングの決定（[`../icp-positioning/`](../icp-positioning/)）と、JTBD のプロダクト適用（[`../product-marketing-jtbd.md`](../product-marketing-jtbd/)）は本章の下流に位置する。 Marketing OS の独自貢献は **Customer Sync を独立した観測対象として置く**構造である。ICP 仮説と顧客実態を別の記録として分けて保つことで、ズレが構造的に検出される（[`../../foundations/principles.md`](../../foundations/principles.md) Principle 4）。 ## 業界トレンドと新興手法 - **顧客フィードバックの自動集約**: 営業ログ / サポート問い合わせ / SNS 言及 / レビュー / 通話録音を LLM で構造化 - **リアルタイム VoC（Voice of Customer）**: ダッシュボード化された連続観測 - **競合インテリの自動化**: 競合 SERP・広告ライブラリ・プレスリリースの継続監視 - **AI 駆動のセグメンテーション**: クラスタリングではなく、JTBD ベースの動的セグメント生成 - **生成的市場リサーチ**: AI による仮想顧客との対話シミュレーション（ただし実顧客の代替にはならない） 新興手法は速度を上げるが、**Customer Sync の独立性**（生の声を内部仮説と混ぜない）を犠牲にしないことが本領域の規律である。 ## テーラリング | 文脈 | 重点 | |---|---| | **B2B エンタープライズ** | Win / Loss / Churn インタビューを構造化。商談プロセスへの埋め込み | | **B2B SaaS** | プロダクト内行動データ + 顧客成功（CS）チームへのヒアリング | | **D2C** | レビュー・SNS 言及・購買履歴のクラスタリング | | **リテール** | 店舗での観察・接客ログ・ロイヤルティデータ | | **規制業種** | プライバシー制約下での同意ベース VoC、規制動向の継続監視 | | **スタートアップ（PMF 前）** | 個別インタビュー重視。N1 から始め、5 セグメントを徐々に埋める | スタートアップは特に「定性 1 件 = E1（単発観測）」の認識を維持しないと、N1 の声を全顧客の声として誤認しやすい（Evidence Level の運用、[`../../foundations/cycle.md`](../../foundations/cycle.md) §2.6.3）。 ## プロセス（マーケティングサイクル × ITTO） ### 観測・データ収集段のプロセス **観測対象の運用**: - Team Sync: チーム内で何が「分かっているつもり」になっているかを可視化 - Customer Sync: `customer-signal.md` に顧客の生の声を独立保管 - Market Sync: 競合・プラットフォーム・規制の揮発情報を `knowledge/marketing/tool/` に取り込む - Performance Sync: 自社実績数値を `results/` に記録 - **投入物（Inputs）**: 営業・サポート・解約ログ / 競合 SERP・広告ライブラリ / 売上・実績数値 / チーム内独立記述 - **手法と道具（Tools & Techniques）**: Win / Loss / Churn インタビュー、N1 分析、Switch Interview、競合スタック調査、ベースライン記録 - **産出物（Outputs）**: 観測対象別レポート、ICP 仮説 vs 実態差分リスト、Performance ベースライン ### 理解・分析する段のプロセス - **投入物**: 観測・データ収集段の観測対象レポート - **手法と道具**: 4 視点切替（CEO / Consultant / Gemba / Customer）、JTBD 抽出、Forces of Progress、Problem エリアと Solution エリアの区別 - **産出物**: JTBD 言語化、ICP ギャップ仕様、競合ポジショニングマップ、未充足ニーズリスト ### 再構築段のプロセス - **投入物**: 顧客実態と ICP 仮説のズレリスト - **手法と道具**: 棄却すべき ICP 像の機械的列挙、誤って前提化された顧客像の検出 - **産出物**: 再構築決定（古い ICP / 過去の成功事例の過剰一般化 / 経営の希望的観測） ### 起動・実装する段のプロセス - **投入物**: 検証済み JTBD・新 ICP 仮説 - **手法と道具**: セグメント定義の本番反映、配信ターゲティング更新、メッセージング更新 - **産出物**: 配信ターゲット定義、計測同時着地 ### 学ぶ段のプロセス - **投入物**: 配信後の反応データ、定性フィードバック - **手法と道具**: Evidence Level 判定、ICP の更新承認、JTBD の検証 - **産出物**: 検証済み ICP（E3）、profile への書き戻し ## タクティカル・プレイブック（L3） ### 顧客インタビュー設計（JTBD ベース） #### 基本フォーマット ``` [いつ] のとき、[誰] は [動機] を満たしたいので、 [これまでの解決手段] ではなく [自社の解決手段] を雇った。 [期待された結果] が得られた / 得られなかった。 ``` #### Switch Interview の 6 タイミング 顧客が「乗り換える」瞬間に焦点を当てて聞く: 1. 初めて問題を意識した瞬間（First Thought） 2. 解決策を探し始めた瞬間（Active Search） 3. 候補を絞った瞬間（Consideration） 4. 購入を決めた瞬間（Purchase） 5. 使い始めた瞬間（First Use） 6. 継続 / 解約を決めた瞬間（Continuation / Churn） 各タイミングで「何が起きたか」「何を考えたか」「何が決め手になったか」を時系列で聞く。仮説検証ではなく、**観察モード**で進める。 #### The Mom Test — 聞き方の罠を避ける - 仮説に同意してもらう質問をしない（「〜だと思いますか？」は誘導） - 過去の行動を聞く（「最近、〜したのはいつですか？」） - 一般論を聞かない（「普通、〜しますか？」ではなく「あなたは先週〜しましたか？」） ### N1 分析（西口一希） 特定の 1 人を徹底的に理解する。N1 から始めて、9 セグメント（5 つの顧客セグメント × 認知 / 未認知）に展開する: 1. ロイヤル顧客（高頻度購入・継続） 2. 一般顧客（購入経験あり・低頻度） 3. 離反顧客（過去購入・現在離脱） 4. 認知・未購買顧客（知っているが買わない） 5. 未認知顧客（存在を知らない） 各セグメントで「なぜそうなったか」を 1 人に集中して掘る。 ### 競合スタック調査 競合の全体像を構造化する: - **ポジショニング**: メッセージング、想起カテゴリ、強み訴求 - **チャネルミックス**: ペイド / オウンド / アーンドの配分 - **オファー**: 価格、プラン、保証、トライアル条件 - **顧客接点**: 商談プロセス、サポート、コミュニティ - **テクスタック**: 利用ツールから推測される運用粒度 詳細手順は [`../content-channel/`](../content-channel/) のタクティカル節と連携する。 ### 市場規模推定（TAM / SAM / SOM） - **TAM (Total Addressable Market)**: 市場全体 - **SAM (Serviceable Addressable Market)**: 自社が現実に届けうる範囲 - **SOM (Serviceable Obtainable Market)**: 短中期で取りに行ける範囲 推定方法には Top-down（業界統計から逆算）と Bottom-up（自社実績の累積から外挿）がある。両者の差が大きい場合、どちらかの前提が誤っている。 ## アンチパターン - **ICP 仮説と顧客実態の混在**: 同じドキュメントに両方書く。ズレが構造的に検出できなくなる（[`../../foundations/principles.md`](../../foundations/principles.md) Principle 4 違反） - **定量データ偏重**: 集計値だけを見て、顧客の生の言葉が profile に書き戻されない - **定性データの過剰一般化**: N1 インタビュー 1 件を全顧客の声として扱う（Evidence Level の運用違反） - **誘導的なインタビュー**: 仮説に同意してもらう質問をする。The Mom Test 違反 - **競合の表面模倣**: 競合がやっているからやる。自社ポジショニングの放棄 - **市場規模の誇張**: TAM だけ示して SAM / SOM を出さない。意思決定に使えない - **顧客の声を「ノイズ」として処理**: 期待外れの声を「特殊例」として除外し、profile を更新しない - **古い ICP の温存**: 新事実と矛盾する ICP を 再構築で再構築しない（停止記憶の欠落） ## 関連 skill / agent - **`/listen customer`** — Customer Sync の独立保管 - **`/listen market`** — Market Sync の取り込み - **`/listen team-workspace`** — workspace 固有の認識整理 - **`/insight customer`** — 顧客視点の 理解・分析する - **`/insight consultant`** — 第三者視点での競合・市場分析 skill ↔ process の完全な対応は [`../../appendices/skill-mapping.md`](../../../../base/skill-mapping.md)。 ## 今後の拡張論点 - **JTBD の所在** — 本章（Intelligence）と 09 章（プロダクトマーケティング・JTBD）の境界。発見プロセスは本章、適用は 09 章で合っているか - **Customer Sync の運用詳細** — 「顧客の生の声」をどこまで構造化するか。`customer-signal.md` の推奨スキーマを本章で定義するか、別ファイルに切るか - **AI による VoC 自動集約と Evidence Level** — LLM 集約された VoC は何 Level として扱うか。E1（単発観測の集合体）か E2（再現された傾向）か - **競合インテリの倫理境界** — 公開情報の収集と、グレーゾーン（採用情報からの推測・社員の SNS 等）の境界 - **市場規模推定の必須度** — 基礎章として TAM / SAM / SOM を必ず扱うか、業種により省略可とするか --- title: ICP・ポジショニング chapter: "07" part: 2-knowledge-areas status: revised visibility: public authors: - claude reviewers: [] revision: 0.2 updated: 2026-05-19 related-skills: - /insight related-chapters: - knowledge-areas/intelligence - knowledge-areas/brand-narrative - knowledge-areas/product-marketing-jtbd related-knowledge: - knowledge/marketing/playbook/knowledge-areas/icp-positioning/category-design.md --- # ICP・ポジショニング ## 概要と対象範囲 **誰を顧客とし、何として認識されるか**を定義する知識エリア。具体的には次の 3 つを扱う: - **セグメント設計**: 市場をどう区切るか - **ICP（Ideal Customer Profile）**: その中で誰を理想顧客とするか - **ポジショニング**: 顧客の頭の中で何として記憶されるか 06 章（市場・顧客知能）が**観察**を扱うのに対し、本章は**選択**を扱う。観察された顧客実態から「誰に・何を」を選び取る判断が本章の中心命題である。 カテゴリ設計（Blue Ocean 系）も本章の射程に含む。既存カテゴリ内のポジショニング選択か、新カテゴリの創造かは戦略レイヤーの分岐点である。 ## 業界トレンドと新興手法 - **JTBD ベースのセグメント**: デモグラではなく Job ベースで顧客を区切る - **意図ベースターゲティング**: 検索意図・行動意図でセグメントを動的生成 - **カテゴリ設計**: April Dunford の Obviously Awesome、Play Bigger の Category Design - **AI による Persona 生成**: ただし実顧客の代替にならない（[`../intelligence/`](../intelligence/) §6.2） - **動的セグメンテーション**: 静的な区分から、サイクルごとに更新されるセグメントへ ## テーラリング | 文脈 | 重点 | |---|---| | **B2B エンタープライズ** | ABM（Account-Based Marketing）、Tier 別 ICP | | **B2B SaaS** | JTBD ベース、PMF 前は ICP 仮説検証が中心 | | **D2C** | RFM × ライフステージ、N1 から拡張 | | **リテール** | 来店動機 × 商圏 | | **スタートアップ** | 「誰の何を解決するか」の 1 行から始める | ## プロセス（マーケティングサイクル × ITTO） ### 観測・データ収集段のプロセス - **投入物**: 06 章の Customer Sync・Market Sync、Performance Sync - **手法と道具**: 顧客実態の構造化、ICP 仮説との差分検出 - **産出物**: ICP 仮説 vs 実態差分、未充足セグメントリスト ### 理解・分析する段のプロセス - **投入物**: 観測・データ収集 差分、JTBD（09 章）、競合ポジショニング（06 章） - **手法と道具**: ポジショニングステートメント生成、カテゴリ設計検討、Obviously Awesome フレーム - **産出物**: ICP 案、ポジショニング案、カテゴリ選択肢 ### 再構築段のプロセス - **投入物**: 現行 ICP、過去の成功事例の前提 - **手法と道具**: 古い ICP の機械的列挙、過剰一般化の検出 - **産出物**: 再構築決定（古い ICP / 棄却すべきセグメント / 残すべきポジショニング） ### 起動・実装する段のプロセス - **投入物**: 新 ICP、新ポジショニング - **手法と道具**: メッセージング更新、配信ターゲティング、Brand 連動（08 章） - **産出物**: 本番反映、ステークホルダー合意 ### 学ぶ段のプロセス - **投入物**: 配信反応、商談データ、顧客フィードバック - **手法と道具**: ICP の検証、ポジショニング浸透度測定 - **産出物**: 検証済み ICP（E3）、profile への書き戻し ## タクティカル・プレイブック（L3） ### ICP 仮説の構造化テンプレ 最低限の項目: - **業種・規模**（B2B の場合）/ **デモグラ・行動**（B2C の場合） - **抱える Job（JTBD）**: 何を達成しようとしているか - **現在の解決手段**: 自社以外でどう解決しているか - **不満・障害**: 現在の解決手段の何が不十分か - **購買決定要因**: 何が決め手になるか - **使用シーン**: いつ・どこで使うか ICP は仮説として書き、検証で更新する。E0 / E1 のまま profile に書かない（[`../../foundations/cycle.md`](../../foundations/cycle.md) §2.6.3）。 ### ポジショニングステートメント（Obviously Awesome） ``` [ICP] にとって、 [競合代替手段] とは違って、 [自社のユニークな強み] を提供する [カテゴリ] の [選択肢] である。 ``` 要素: - **競合代替手段**: 顧客が現在使っている / 検討している選択肢 - **ユニークな強み**: 競合代替手段にない自社の特性 - **カテゴリ**: 顧客の頭の中で自社がどの棚に置かれるか - **その強みが生む価値**: 顧客にとってなぜ重要か ### カテゴリ設計の判定 新カテゴリを作るか、既存カテゴリ内で勝つかの判定軸: - **市場の準備度**: カテゴリを語る言葉が市場に存在するか - **自社の規模**: カテゴリ創造には大量の教育投資が必要 - **競合状況**: 既存カテゴリで勝てる選択肢があるか - **タイムスパン**: カテゴリ創造は 3〜5 年スパン スタートアップは既存カテゴリで勝ちきれない場合に新カテゴリを選ぶことが多い。大企業は既存カテゴリ内での再ポジショニングが基本。 ### セグメンテーション手法 - **JTBD ベース**: 達成したい Job で区分 - **デモグラ + サイコグラ**: 古典的だが、Job が見えない場合の初期仮説に有用 - **行動ベース**: 利用頻度・購買履歴・チャネル接触 - **意図ベース**: 検索キーワード・サイト行動 複数手法をクロスで使い、segment ごとに JTBD と決定要因を埋める。 ## アンチパターン - **ICP の過剰広範化**: 「30〜50 代、男女問わず」のような曖昧な ICP。誰にも刺さらない - **ICP と実態の混在**: 仮説と検証済みを区別しない（Principle 4 違反） - **デモグラ偏重**: JTBD を見ずにデモグラだけで区分し、行動の多様性を無視 - **ポジショニングなしの施策展開**: 「何として認識されるか」が決まらないまま施策を実行 - **カテゴリ語りの欠落**: ポジショニングに「どのカテゴリで勝つか」が含まれない - **競合代替手段の見落とし**: 自社の比較対象を「直接競合」だけに限定し、顧客が実際に使っている代替手段（Excel・代替プロセス）を見ない - **古い ICP の温存**: 新事実と矛盾する ICP を 再構築で再構築しない ## 関連 skill / agent - **`/insight ceo`** — 経営視点でのポジショニング評価 - **`/insight customer`** — 顧客視点でのポジショニング検証 - **`/release`** — 古い ICP の再構築 ## 今後の拡張論点 - **「ICP」と「Persona」の使い分け** — 本書ではどちらを主表記とするか。ICP は B2B、Persona は B2C で使い分けるか - **カテゴリ設計を独立 KA とすべきか** — 本章に含むか、Brand & Narrative（08 章）と分担するか - **[`category-design.md`](./category-design.md) の吸収範囲** — 全文を取り込むか、要旨のみとするか - **ポジショニングと Brand & Narrative の境界** — どちらが上流か。本書は「7 → 8」の流れで整理したが逆もありうる --- title: "カテゴリー設計" chapter: "07" part: 2-knowledge-areas status: revised visibility: public authors: - claude reviewers: [] revision: 0.1 updated: 2026-05-19 related-skills: [] related-chapters: [] related-knowledge: [] --- # カテゴリー設計 **「誰より良いか」ではなく「誰の何の問題を、新しい方法で解くか」**を定義する戦略。 Category Designの思想：**最高の"競合"は"新カテゴリ創造"**。既存カテゴリ内で2位3位を目指すより、**自分がNo.1になれるカテゴリを作る**。 > 「Category Kings take 76% of the total market cap」— *Play Bigger* ## なぜCategory Designか - 成熟市場で**機能優位は模倣される** - カテゴリ内競争は**価格競争に収斂**する - 顧客の選択疲労 → **「既存カテゴリの外」を提案したブランドが記憶される** - **言語（カテゴリ名）を支配した者が市場を支配**する ### Category King例 | 企業 | 創造したカテゴリ | |------|----------------| | Salesforce | Cloud CRM / SaaS | | Uber | Ride-Sharing | | Airbnb | Home-Sharing | | HubSpot | Inbound Marketing | | Drift | Conversational Marketing | | Gong | Revenue Intelligence | | Snowflake | Data Cloud | | Notion | All-in-One Workspace | いずれも「No.1 in 既存カテゴリ」ではなく「**既存カテゴリの外側に新しい言葉**」を作った。 ## Category Kingの3つの条件（Play Bigger） 1. **Problem Definition（問題定義）** — 既存の枠組みで解けない問題を"発見"する 2. **Category Design（カテゴリ設計）** — その問題を解くカテゴリ名と物語を作る 3. **Company Building（会社構築）** — そのカテゴリのNo.1になる組織を作る 3つが揃って初めてCategory Kingになる。1〜2だけでは他社に取られる。 ## Obviously Awesome（April Dunford） 「ポジショニングとは、あなたの製品を**どの市場の**、**何の代替として**、**誰のために**、**どんな価値で**認識させるか」 ### 5つのポジショニング要素 1. **Competitive Alternatives（競合代替手段）** — 顧客が今使っている解決策（多くは"何もしない"や"Excel"） 2. **Unique Attributes（独自属性）** — 自社にしかない特徴 3. **Value（価値）** — その独自属性が顧客にもたらすメリット 4. **Target Customer（最適顧客）** — その価値が最も刺さる顧客像 5. **Market Category（市場カテゴリ）** — 競合との相対位置を決める市場定義 ### カテゴリ選択の3パターン | パターン | 戦略 | 難易度 | リターン | |---------|------|-------|---------| | **Head-to-Head**（真っ向勝負） | 既存Top1と同じカテゴリで競合 | 高 | 限定的 | | **Big Fish, Small Pond**（サブカテゴリ開拓） | 既存カテゴリを細分化して特化 | 中 | 中 | | **Create a New Game**（新カテゴリ創造） | 新しい言葉・新しい枠組みを作る | 極高 | 極大 | ## Category Creationの"Point of View（POV）" 新カテゴリを作るブランドは**必ず強いPOV**を持つ： - 「現状は間違っている」 - 「未来はこうあるべき」 - 「古い解決策では新しい問題は解けない」 ### 代表的なPOVステートメント **HubSpot（2006年当時）:** > 「Outbound Marketingは死んだ。これからはInbound Marketingだ。」 > — コールドコール・メール・DMを"悪"として再定義し、自社を"善"のカテゴリの代表に置いた **Drift:** > 「Formはもういらない。会話がB2Bの未来だ。」 > — Contact Formの代替としてConversational Marketingを発明 **Gong:** > 「セールスリーダーは真実を知らない。営業の会話は全てデータ化されるべきだ。」 > — Revenue Intelligenceというカテゴリを創設 **Gorgias（EC向けサポート）:** > 「Zendeskは全業界向けだから、ECに最適化されたサポートは別物が必要」 > — Vertical SaaS as a POV ## Category Narrative（カテゴリ物語）の型 ### 6つの要素 1. **Seismic Shift（地殻変動）** — 世界で何が変わっているか 2. **Existing Failure（既存の失敗）** — 旧パラダイムではなぜ解けないか 3. **New Problem / Question（新しい問題）** — 変化の結果生まれた課題 4. **New Category Name（カテゴリ名）** — その問題を解く分野の命名 5. **Promised Land（約束の地）** — このカテゴリが実現する未来像 6. **Proof Points（証拠）** — 既にそこに到達している兆候（顧客事例、データ） ### 例: Gongの場合 ``` Shift: SaaS時代、営業の会話がZoomで記録可能になった Failure: 既存CRMは営業が"入力した"データしか持たない（虚構） New Problem: 営業の実際の会話から真実を理解・分析する方法がない Category Name: Revenue Intelligence Promised Land: データ駆動で勝率が30%上がる営業組織 Proof: 4,000社導入、年商数百億ドル ``` ## カテゴリ戦略のリスク ### カテゴリを"教育する"コスト - 新カテゴリは**市場認知が存在しない** - 顧客に**「なぜ必要か」から説明**する必要がある - 獲得コスト（CAC）が高くなる、採用サイクルが長い ### 成功確率 - 新カテゴリ創造の成功確率は**5〜10%以下** - 残りはカテゴリが根付かず消える or 既存カテゴリに吸収される ### 大企業の罠 - 「新カテゴリを作ります」と言いながら、既存の枠組みで語ってしまう - 社内承認プロセスが新カテゴリの尖った物語を丸める - マーケと営業とプロダクトのカテゴリ認識が分裂する → 致命傷 ## Category Designの実装ステップ ### Step 1: Listening（観察） - 顧客インタビュー、購買プロセスの棚卸し - 「顧客が今抱える、既存カテゴリでは解けない問題」を見つける - 競合の言語・比喩・カテゴリ名を全て収集 ### Step 2: POV策定 - 業界の常識を3つ書く - それぞれに「本当か？」を問う - 逆張りできる論点を特定 ### Step 3: Category Naming - **2〜4語**の簡潔な名前 - 既存語の新結合（「Conversational + Marketing」「Revenue + Intelligence」「Data + Cloud」） - 検索可能性（SEO）を意識 - 会社名と混同されない距離感 ### Step 4: Narrative Assets - **Manifesto（ブログ / 宣言）** — 長文で世界観を語る - **2×2 Positioning Map** — 旧カテゴリ vs 新カテゴリの対比 - **Analyst Relations** — Gartner / Forresterを巻き込みカテゴリ公式化 - **Book / White Paper** — 「この分野の定番書」を自社が出す - **Conference / Meetup** — カテゴリ名のイベント主宰 ### Step 5: Ecosystem Building - カテゴリを**自社だけの宣伝**にしない - 競合・顧客・パートナーをエコシステムに巻き込む - カテゴリ全体が大きくなる → カテゴリKingである自社が最大受益 ## Analyst Relations（アナリスト・リレーションズ） 新カテゴリは**業界アナリストの公式認知**で加速する。 ### 主要アナリストファーム | 会社 | 特徴 | |------|------| | **Gartner** | Magic Quadrant、Hype Cycle — B2Bで最大影響力 | | **Forrester** | Forrester Wave、The Total Economic Impact | | **IDC** | 市場規模レポート、シェア分析 | | **G2** | ユーザーレビューベースのGrid | | **Capterra / GetApp** | SMB向けレビュー | ### カテゴリ公式化の段階 1. アナリストとの初回ブリーフィング（教育） 2. 独自レポート / Noteでのカテゴリ言及 3. Hype Cycleへの掲載 4. Magic Quadrantでのカテゴリ化 5. 市場規模予測の対象になる **アナリスト公認カテゴリになると営業サイクルが半分になる**ことも。 ## Vertical Strategy（垂直特化） Category Designの一類型：**既存大カテゴリの中で、特定業界向けに特化**する。 ### Vertical SaaSの例 - **Toast** — Restaurant Tech（飲食店特化POS） - **Veeva** — Life Sciences CRM（製薬業界） - **Procore** — Construction Management - **ServiceTitan** — Field Service（水道工事・空調） ### 強み - 業界特有のワークフローに**深く最適化** - 業界団体・展示会でのリーチが効率的 - 業界内紹介が強い（狭いコミュニティ） - 価格競争に陥りにくい ### 弱み - 市場規模上限が明確 - 業界シェアを取り切るとグロース鈍化 ## カテゴリ戦略のチェック 1. ✅ 新カテゴリ名は**1〜4語で言える**か 2. ✅ 既存カテゴリとの**明確な対比**があるか 3. ✅ 検索で**既存意味とぶつからない**か（Zero Search Volumeで始まってOK） 4. ✅ **POV（世界観）**が尖っているか 5. ✅ 顧客が「これは○○（既存カテゴリ）と何が違うの？」に**1文で答えられる**か 6. ✅ アナリスト・業界メディアが**その言葉を使い始めている**か 7. ✅ 自社マーケ・営業・プロダクトが**同じ言葉を話している**か ## 参考文献 - *Play Bigger* — Al Ramadan, Dave Peterson, Christopher Lochhead, Kevin Maney - *Obviously Awesome* — April Dunford - *Niche Down* — Christopher Lochhead & Heather Clancy - *Category Design Toolkit* — Play Bigger 公式 - *The 22 Immutable Laws of Marketing* — Al Ries & Jack Trout（Law of Leadership） - *Positioning* — Al Ries & Jack Trout - *Crossing the Chasm* — Geoffrey Moore（カテゴリ普及の章） - April Dunford ブログ / YouTube ## マーケティングサイクルとの接続 - **Set**: 既存カテゴリの限界、顧客のJTBD、競合のカテゴリ命名を `memory/profile/positioning.md` に書く - **Ask**: 「このプロダクトに新カテゴリ名を3案」「POVステートメントを書いて」 - **再構築**: Manifesto公開、アナリストブリーフィング、カテゴリ命名を全マーケ資産に反映 - **Feedback**: カテゴリ名の検索量、メディア/アナリスト言及数、指名検索の動きを `knowledge/marketing/case/` に記録 --- title: ブランド・ナラティブ chapter: "08" part: 2-knowledge-areas status: revised visibility: public authors: - claude reviewers: [] revision: 0.2 updated: 2026-05-19 related-skills: - /brand related-chapters: - knowledge-areas/icp-positioning - knowledge-areas/product-marketing-jtbd related-knowledge: - knowledge/marketing/playbook/knowledge-areas/brand-narrative/brand-strategy.md - knowledge/marketing/playbook/knowledge-areas/brand-narrative/narrative-storytelling.md --- # ブランド・ナラティブ ## 概要と対象範囲 ブランド資産（想起・連想・選好）の構築と、それを伝えるナラティブ設計を扱う。本章は既存体系（Aaker / Holt / Wheeler）を要約し、**ナラティブと マーケティングサイクルの接続**を CMO Marketing OS Playbook 独自の記述として置く参照章である。 ## 既存体系との関係 | 体系 | 主な貢献 | |---|---| | **Aaker のブランド資産モデル** | 想起 / ロイヤルティ / 知覚品質 / 連想の 4 軸 | | **Holt の Cultural Branding** | カルチャー文脈に根ざしたブランド構築 | | **Wheeler の Designing Brand Identity** | ブランドアイデンティティの構成要素と設計プロセス | | **Story Brand（Donald Miller）** | 顧客を主人公にしたナラティブフレーム | | **RAM-CE（Romaniuk / Sharp）** | カテゴリ想起の連想ネットワーク | これら既存体系は CMO Marketing OS Playbook の前提として保たれる。本章で独自記述するのは **マーケティングサイクルとの接続**と**ブランド毀損リスク**である。文献参照は [`../appendices/references.md`](../../../reference/references.md)。 ## プロセス（マーケティングサイクル × ITTO） ### 観測・データ収集段のプロセス - **投入物**: ブランド想起調査、競合ポジショニング、顧客の言葉 - **手法と道具**: 想起率測定、連想ネットワーク調査、ブランド資産現状把握 - **産出物**: ブランド資産現状マップ、ナラティブ整合性ギャップ ### 理解・分析する段のプロセス - **投入物**: 現状ブランド資産、ICP（07 章）、JTBD（09 章） - **手法と道具**: ナラティブ仮説、Story Brand フレーム、Cultural Branding 分析 - **産出物**: ナラティブ案、ブランドメッセージ階層 ### 再構築 / 起動・実装する / 学ぶ段 - **再構築**: 古いブランド要素・形骸化したガイドラインの再構築 - **起動・実装する**: ガイドライン更新、`/brand` チェックを経た本番反映 - **学ぶ**: 想起・連想の継続測定 ## ナラティブと マーケティングサイクルの接続（CMO Marketing OS Playbook 独自記述） ナラティブ（自社の物語）は**サイクル間で更新されるもの**として扱う。一度確定したナラティブを永続的に維持するのではなく、観測・データ収集段で「現在のナラティブが顧客実態とどうズレているか」を継続観測し、再構築段で古い物語を再構築する。 接続点: - **観測・データ収集**: 顧客が自社をどう語っているか（自社が語りたい物語との差分） - **理解・分析する**: 競合とのカルチャー文脈での違い、JTBD の物語化 - **再構築**: 古いブランド神話の再構築、機能訴求の整理 - **起動・実装する**: メッセージング階層の本番反映、`/brand` チェック - **学ぶ**: ブランド想起率の中長期測定 ## アンチパターン - **ブランドガイドラインの形骸化**: 立派なガイドラインがあるが、制作物に反映されない - **ナラティブの自社語り偏重**: 顧客を主役にしないストーリーテリング - **ブランドと施策の分断**: Brand チームと Performance チームが独立して動き、メッセージが分裂 - **AI 生成コンテンツの無検収**: 大量生成で一貫性が崩れる（17 章との連動） - **想起調査の自己満足**: 数値が動かないことを「ブランドは長期だから」と正当化し、再構築を回さない ## 関連 skill / agent - **`/brand`** — ブランド適合チェック（creative-direction agent を呼ぶ） - **`/listen team-brand`** — ブランドガイドラインの取り込み - **`/insight customer`** — 顧客視点でのナラティブ検証 ## 今後の拡張論点 - **ナラティブと ICP・ポジショニング（07 章）の境界** — どちらが上流か。7 → 8 の流れか、循環関係か - **既存 [`../base/brand-strategy.md`](./brand-strategy.md) と [`narrative-storytelling.md`](./narrative-storytelling.md) の吸収範囲** — 要旨のみ取り込むか、主要章として厚くするか - **AI 生成コンテンツの章間分担** — Brand 適合判定（本章）と AI リスク（17 章）の境界 --- title: "ブランド戦略" chapter: "08" part: 2-knowledge-areas status: revised visibility: public authors: - claude reviewers: [] revision: 0.1 updated: 2026-05-19 related-skills: [] related-chapters: [] related-knowledge: [] --- # ブランド戦略 ## Brand Identity Framework ### Brand Pyramid ``` ┌────────────┐ │ Purpose │ なぜ存在するか ├────────────┤ │ Values │ 何を大切にするか ├────────────┤ │ Personality│ どんなキャラクターか ├────────────┤ │ Positioning│ 市場でどこに立つか ├────────────┤ │ Expression │ どう見え、どう聞こえるか └────────────┘ ``` ### Tone of Voice Spectrum ブランドの声のトーンを4軸で定義する: | 軸 | ← | → | |----|---|---| | **Formality** | カジュアル | フォーマル | | **Energy** | 落ち着いた | エネルギッシュ | | **Humor** | 真面目 | ユーモアあり | | **Authority** | 親しみやすい | 専門的 | ### Messaging Architecture ``` Brand Promise（ブランドの約束） └── Pillar 1: [価値提案1] │ └── Proof Point: [根拠] │ └── Proof Point: [根拠] └── Pillar 2: [価値提案2] │ └── Proof Point: [根拠] └── Pillar 3: [価値提案3] └── Proof Point: [根拠] ``` ## Copy Writing Principles ### PAS Framework（Problem-Agitate-Solve） 1. **Problem**: 読者が抱える課題を明確に示す 2. **Agitate**: その課題を放置した場合の痛みを具体化する 3. **Solve**: 解決策としてのプロダクト/サービスを提示する ### AIDA Framework 1. **Attention**: 注意を引くヘッドライン 2. **Interest**: 興味を深める具体的な情報 3. **Desire**: 欲求を喚起するベネフィット 4. **Action**: 明確なCTA ### 見出しの4Uルール - **Useful（有用）**: 読者にとって役立つか？ - **Urgent（緊急）**: 今読む理由があるか？ - **Unique（独自）**: 他にない切り口か？ - **Ultra-Specific（超具体的）**: 数字や具体例があるか？ ## ブランド定義の重要性 ブランドは大企業だけのものではない。**ブランディングは中小企業やベンチャーにこそ重要。** ほとんどの製品にはブランドが存在し、顧客はブランドで選んでいる（例: ビールは200〜300円の製品だが、各社で全くブランドが異なる）。 ### 媒体とブランドの関係 — 食べログ vs ホットペッパー 似たサービスでも、対象顧客と提供価値が全く異なる: - **食べログ**: CGM型（顧客が口コミを投稿）。味や雰囲気を重視する高級志向の顧客が多い - **ホットペッパー**: クーポン・割引中心。「できるだけお得に利用したい」という顧客向け。チェーン展開の居酒屋が多い → 同じ飲食店でも、ブランドに合った媒体選択が必要。利用すべき店や対象顧客は全く異なる。 ### 失敗事例 — グルーポン エンドユーザー（消費者）にとってよいサービスだからといって、店舗にとってその顧客がよい顧客であるかどうかはわからない。初回割引で来店した顧客のうち、常連になった顧客は少なかった。**顧客の選択は、1つのサービスの成否を決めるほどに重要。** ### オンリーワン戦略 Appleの「Get a Mac」キャンペーンに見るように、ナンバーワンになれない製品や企業は**オンリーワンを目指すべき**。 「PCの中でどれを選ぶか？」の前に「PCを買うか、Macを買うか？」という選択をさせることで、他の製品と比較する前に顧客がMacを選んでくれる可能性が生まれる。 **キーメッセージを設定し、「この製品がどのような点で他の製品と比べるまでもなく優れているのか」を主張していかなくてはいけない。** ### ブランドを作る事例 - **Facebook**: 当初ハーバード大学の学生限定にしたことで「ハーバード出身者だけが使えるSNS」としてブランドを定義し、正しい顧客のみにアピールできた - **Google**: 採用広告に数学の難問を掲載し、解ける人間だけが応募できる仕組みに → ターゲットを明確に絞ったブランディング - **Apple**: 1983年「1984」CM（Advertising Age誌「10年で最高のコマーシャル」）、「Get a Mac」キャンペーン → 「MacはPCとは違う」というメッセージ **ブランディングとは、自社のビジネスにとって必要な顧客にターゲットを絞ってリーチするための方法。** ## Competitive Positioning ### Positioning Canvas ``` For [ターゲット顧客] Who [ニーズ/課題] Our [プロダクト名] is a [カテゴリ] That [主要ベネフィット] Unlike [主要競合] We [差別化ポイント] ``` ### 競合分析の原則 - 競合によってビジネスの評価や価格は大きく変わる（例: 富士山山頂のペットボトル500円、ホテルのルームサービスのコーラ1,000円） - **競合がいないマーケットは需要もない**。競合を把握し、その存在から学ぶ必要がある - 「敵を知り己を知れば百戦あやうからず」（『孫子』）— デジタルマーケティングには常に競合が必要 - 競合として勝ちやすい／勝ちにくいのはどこか？ を考える - 検索数の多いキーワードで勝つ自信があれば検索中心、既存Webサイトが狙っていない小さなキーワードで集客する方法もある ### 競合のトラフィック分析 SimilarWebなどのツールで競合サイトのトラフィック構成（検索・ダイレクト・リファラル・ソーシャル・メール・表示広告）を分析し、集客ファネルの優先順位を把握する。 ### Category Design 市場のカテゴリを自ら定義する戦略: 1. 既存カテゴリの問題点を明確にする 2. 新しいカテゴリを命名する 3. そのカテゴリの評価基準を自社に有利に設計する 4. カテゴリの伝道者になる ## ソーシャル時代のブランディング ### ブランディングの変化 - SNSにより、感情が共振する構造に変化 - 「共感」を呼ぶことが重要に - チャネルが増え、クリエイティブの数が爆発的に増加（多産多死） - 刺さればどこまでも広がる（バズ） - 時代を「つくる」から、社会の変化に「乗る」意識へ ### マス広告の変化 - **ストーリーとソーシャル性** — ストーリーがあり、共有したくなる広告 - **巻き込む** — 受け手が参加・発信する構造 - **一対一対多** — ブランド→個人→その先の多数へ伝播 ### これからのブランドに求められること 1. いち早く市場の変化に気づくこと 2. 社会課題を捉えること 3. 過去を知り流れを読むこと 4. 当事者性を持つこと — 他人事ではなく自分ごととして語る --- title: "ナラティブ・ストーリーテリング" chapter: "08" part: 2-knowledge-areas status: revised visibility: public authors: - claude reviewers: [] revision: 0.1 updated: 2026-05-19 related-skills: [] related-chapters: [] related-knowledge: [] --- # ナラティブ・ストーリーテリング 人間は**事実**より**物語**を記憶する。脳は論理ではなく、**時系列・因果・登場人物**の構造でしか長期記憶に情報を定着させない。 優れたマーケティングコピーも、プレゼンも、広告も、採用ピッチも、IRストーリーも — 根本は**物語の設計**。 ## なぜストーリーか（Jerome Bruner） - **事実の情報**：記憶定着率 **5〜10%** - **物語に埋め込まれた情報**：記憶定着率 **65〜70%** 脳のデフォルトモードは「物語を聞く」ようにできている。 人類が進化の過程で**言語の前にジェスチャーで物語を共有**してきたため、物語形式での情報処理が最適化されている。 ## StoryBrand（Donald Miller） **「顧客を主人公にする」**が鉄則。ブランドは脇役＝ガイド役。 ### StoryBrandの7フレーム ``` 1. Character（主人公） — 顧客（ブランドではない） 2. Problem（問題） — 外的 / 内的 / 哲学的 3. Guide（ガイド） — ブランド（助ける存在、ヒーローではない） 4. Plan（計画） — 解決の具体的ステップ 5. Call to Action（行動） — 明確な次の一歩 6. Failure（失敗の回避） — 何を失わずに済むか 7. Success（成功） — どんな変化が得られるか ``` ### 典型的な失敗例 ❌ **「我が社は業界20年の実績、最新AI技術を使い…」** → 主人公がブランド自身になっている。顧客は自分の話を聞きたい。 ✅ **「経理の締め作業に毎月40時間を奪われていませんか？（Problem）** **我々は1,000社の経理部門を自動化してきました（Guide）** **3ステップで今月から半分の時間に（Plan）** **14日無料で試す（CTA）** **締めに追われる夜を終わらせて（Failure回避）** **チームが戦略的な仕事に戻れる（Success）」** ### 3種類のProblemを分ける - **External（外的）** — 文字通りの問題 例「締め作業に40時間」 - **Internal（内的）** — 感じている苦痛 例「無力感、家族との時間を奪われる」 - **Philosophical（哲学的）** — そもそも不公平 例「優秀な人が作業に潰される社会は間違っている」 **3層を重ねるとコピーが深くなる。** 多くのコピーはExternalだけで止まる。 ## Hero's Journey（ジョーゼフ・キャンベル） 神話学者が世界中の英雄譚から抽出した**普遍的物語構造**。映画・小説・ブランドナラティブに広く使われる。 ``` ① 日常の世界（Ordinary World） ② 冒険への誘い（Call to Adventure） ③ 冒険の拒絶（Refusal of the Call） ④ 賢者との出会い（Meeting the Mentor） ⑤ 境界の通過（Crossing the Threshold） ⑥ 試練（Tests, Allies, Enemies） ⑦ 最深部への接近（Approach） ⑧ 最大の試練（Ordeal） ⑨ 報酬（Reward） ⑩ 帰路（Road Back） ⑪ 復活（Resurrection） ⑫ 宝を持ち帰る（Return with the Elixir） ``` ### マーケティングでの応用 - **顧客の現状**（日常） → **不満・課題**（Call） → **導入を迷う**（Refusal） → **ブランド**（Mentor） → **試す**（Threshold） → **使う中での葛藤**（Tests） → **本格活用**（Ordeal） → **変化**（Reward） → **新しい日常**（Return） ### 事例 - Apple「Think Different」— 変革者の物語 - Nike「Just Do It」— 挑戦者の物語 - TED Talk構成（Nancy Duarte）— スピーカー自身のHero's Journey ## SUCCESs原則（Heath兄弟『Made to Stick』） **記憶に残るメッセージの6条件**： | 頭文字 | 内容 | |--------|------| | **S — Simple（シンプル）** | コアメッセージを1つに絞る | | **U — Unexpected（意外性）** | 予測を裏切る、好奇心を突く | | **C — Concrete（具体）** | 抽象概念を五感で感じられる形に | | **C — Credible（信頼性）** | 数字・事例・第三者の声 | | **E — Emotional（感情）** | 統計ではなく個人の物語で共感 | | **S — Stories（物語）** | 時系列 × 登場人物で語る | ### Concreteの力 「地球から月までの距離」 vs 「地球を60個並べた距離」 **後者のほうが20倍記憶される**。抽象を具体に変換する技術が決定的。 ### 統計 vs 1人の物語（Identifiable Victim Effect） - 「アフリカで年間数百万人が飢餓」→ 寄付意欲中 - 「マリ共和国のロキアちゃん（7歳）、両親と妹を飢餓で失った」→ 寄付意欲2倍超 **数が大きいほど感情が鈍化する**（Paul Slovic）。マーケコピーは1人の生の物語を描く。 ## ピクサー・ストーリーテリング（Pixar Pitch） ### 22 Rules of Storytelling（Emma Coats） Pixarシナリオ部門が公開した22の経験則。特に重要なのは： #### "Once upon a time ___. Every day ___. One day ___. Because of that ___. Because of that ___. Until finally ___." この型は**あらゆるピッチ・コピー・LPに応用可能**。 ``` Once upon a time: スタートアップCEOは… Every day: 週60時間働いて成長を追っていた。 One day: 顧客データが複数ツールに分散して時間を失うことに気づいた。 Because of that: 自社で統合ダッシュボードを作ろうとした。 Because of that: 開発に半年、運用にさらに時間を奪われた。 Until finally: ○○を導入し、15分でダッシュボードが立ち上がった。 ``` ## WHYから始める（Simon Sinek / Golden Circle） ``` Why（なぜ） ← 世界観・信念 ↑ How（どう） ← 独自のアプローチ ↑ What（何） ← 製品・機能 ``` 多くの企業は**What**から話す。しかし顧客は**Why**に共感する。 - ❌ 「我々は高性能PCを作っています。美しいデザイン、直感的な操作性。買いませんか？」 - ✅ 「我々は現状に挑戦すると信じています（Why）。美しく直感的な製品でそれを実現（How）。Macが生まれました（What）。」 **Appleの広告はほぼ必ずWhyから始まる。** ## Purpose-Driven Branding（パーパス主導） Z世代・ミレニアル世代は**ブランドのパーパス（存在理由）**で選ぶ傾向。 ### Edelman Trust Barometer - **63%の消費者**が「ブランドのスタンスで買うか決める」 - Purpose明示のブランドは**2倍の成長率**（Kantar Purpose 2020） ### ただし注意 - **Purpose Washing（偽装）** は逆効果。実態が伴わないパーパスはZ世代に即座に見抜かれる - 行動・予算・採用・サプライチェーンまで一貫しているか - **「全てのブランドがパーパスを持つ必要はない」** — カテゴリによっては利便性・価格の訴求が正解 ## Vulnerability Marketing（弱さを見せる） 完璧なブランドより、**失敗・迷い・未熟さ**を開示するブランドが信頼される時代。 ### 例 - **Buffer**（SaaS）: 給与・収益・CEO退任理由を全公開 - **Basecamp / 37signals**: 「我々は間違っていた」と明示的に書く文化 - スタートアップの**"Building in Public"** — 開発進捗・失敗・数字を公開 - **"Post-mortem"公開** — 障害報告書を詳細に出す（Incident.ioやOpenAI） 人間的な不完全さが**共感と信頼**を生む。 ## カウンターナラティブ（逆張り物語） 「業界の常識」に反する物語を語ることで、**強いポジション**を取る。 ### 例 - **37signals**: 「ハッスルカルチャーは害悪」→ 静かな働き方の代表格 - **Patagonia**: 「買わないで」広告（Don't Buy This Jacket） - **Basecamp**: 「リモートワークが当たり前になる前から」という先駆者ポジション - **Robinhood**: 「Wall Street の独占を終わらせる」 ### 効果 - 業界内の議論を支配する - ファンとアンチが両方生まれる（アンチはファンの裏返し） - 記憶に残る（凡百のブランドと区別される） ## ストーリーの構造要素 どんな物語にも必要な4要素： | 要素 | 役割 | |------|------| | **Setting（舞台）** | いつ・どこで | | **Character（登場人物）** | 誰が | | **Conflict（対立・葛藤）** | 何が対立しているか | | **Resolution（解決）** | どうなったか | **Conflictがない物語は記憶されない。** 順風満帆のストーリーは退屈。 苦しみ・敵・制約・失敗が物語を駆動する。 ## ブランドナラティブのチェックリスト 書き終えたコピー・LP・ピッチに以下を問う： 1. ✅ 顧客が主人公になっているか（ブランド中心になっていないか） 2. ✅ Problemが3層（External / Internal / Philosophical）あるか 3. ✅ Before → After の変化が具体的か 4. ✅ Whyから始まっているか 5. ✅ 1人の顧客の生の物語があるか（統計だけでないか） 6. ✅ Conflict / 葛藤が描かれているか 7. ✅ 具体的な次の一歩（CTA）が明示されているか 8. ✅ 失敗回避（何を失わずに済むか）と成功（何が得られるか）が対になっているか 9. ✅ 記憶に残るフレーズ or 具体イメージがあるか 10. ✅ 読み終えた後に"余韻"があるか ## 参考文献 - *Building a StoryBrand* — Donald Miller - *Made to Stick* — Chip & Dan Heath - *Story* — Robert McKee（脚本理論の古典） - *The Hero with a Thousand Faces* — Joseph Campbell - *Start With Why* — Simon Sinek - *Resonate* — Nancy Duarte - *伝え方が9割* — 佐々木圭一 - *物語の法則* — 大塚英志 - Pixar Storytelling（Disney+ / MasterClass） ## マーケティングサイクルとの接続 - **Set**: 顧客のExternal/Internal/Philosophical Problem、ブランドのWhyを `memory/profile/` に書く - **Ask**: 「このメッセージをStoryBrand 7フレームで組み直して」「Before/Afterを1人の顧客で描写して」 - **再構築**: LP・広告・メール・プレゼンのコピー、採用ストーリー、IRナラティブへ反映 - **Feedback**: メッセージのABテスト結果、記憶（認知アンケート）、共感指標を `knowledge/marketing/case/` に記録 --- title: "広報・コミュニケーション" chapter: "08" part: 2-knowledge-areas status: revised visibility: public authors: - claude reviewers: [] revision: 0.1 updated: 2026-05-21 related-skills: [] related-chapters: [] related-knowledge: [] --- # 広報・コミュニケーション PRは「**信頼の借り物**」のマーケティング。自社が「すごい」と言うのと、第三者（メディア・業界人・顧客）が「すごい」と言うのでは、**説得力の桁が違う**。 広告が**Paid（お金で買う注目）**なら、PRは**Earned（信頼で稼ぐ注目）**。コスパではなく、**他では代替できない信頼資産**の形成手段として捉える。 ## PRとマーケの違い・重なり | 観点 | マーケティング | PR | |------|--------------|-----| | 目的 | 購買促進 | 認知・信頼・評判形成 | | 時間軸 | 短〜中期 | 中〜長期 | | コントロール | 高（メッセージ自由） | 低（メディアのフィルタを経る） | | 計測 | CV・ROAS | 露出・SOV・センチメント | | 受け手 | 顧客 | 顧客 + メディア + 業界 + 採用候補 + 投資家 | **PRは"売る"ためだけでなく、"誰と組むか・働いてもらうか・投資されるか"を決める**多ステークホルダー活動。 ## ニュース価値の6要素 メディアが取り上げる理由＝ニュースバリュー。以下のいずれかに該当しないと掲載されない。 1. **Timeliness（時宜性）** — 今伝える理由がある 2. **Impact（影響）** — 多くの人に影響する 3. **Prominence（著名性）** — 有名な人/会社が関与 4. **Proximity（近接性）** — 地域・業界・属性が近い 5. **Conflict（対立）** — 対立構造・論争・業界の常識に反する 6. **Novelty（新奇性）** — 初めて・唯一・最大・最年少 **自社視点の「うれしい発表」≠ニュース。** 「社会にとってどう意味があるか」に翻訳する。 ## 戦略PR（本田哲也）の考え方 「世の中ゴト化」＝自社の伝えたいことを、**社会課題・トレンドに接続**して語る。 ### 3つの"カケル" ``` （自社）の強み × （世の中）の関心 × （世論）の文脈 ``` 例: - シャンプーの発表 →「日本人女性の抜け毛増加」という社会課題と接続 - SaaS機能発表 →「働き方改革」「AI時代のスキルシフト」と接続 - スタートアップ資金調達 →「ディープテック国家戦略」文脈と接続 メディアが取り上げる角度は**自社ニュースそのもの**ではなく、**接続された文脈**。 ## プレスリリースの構造 ### 見出し原則（実務ルール） - **20〜35文字**で完結させる - **数字を入れる**（「業界初」「3倍」「0.3秒」） - **1行で誰が何をしたか**が分かる - 記者は1日数百件見る → タイトルで9割決まる ### 本文の型 ``` 1. リード（一段落で要約 — 5W1H） 2. 背景（なぜ今、この取組みをするか / 社会課題接続） 3. 内容（製品・施策の詳細 / 差別化ポイント） 4. 数値・エビデンス（ユーザー数 / 事例 / 調査結果） 5. 今後の展開（ロードマップ / 目標） 6. コメント（経営者・専門家・導入企業） 7. 会社概要（ボイラープレート） 8. 問い合わせ先 / プレスキット ``` ### 添えるべきアセット - ロゴ・スクリーンショット・製品写真（高解像度） - 代表者顔写真（縦横両比率） - 概要1枚シート（A4 / 英語版） - FAQ（記者が迷う質問の先回り） ## メディア戦略 ### メディアの階層 | 階層 | 特徴 | 戦略 | |------|------|------| | **Tier 1（全国紙 / テレビ / 大手経済紙）** | 日経・WSJ・NHK・テレビ東京・Forbes | リレーション必須・個別ピッチ | | **Tier 2（業界専門メディア）** | TechCrunch・ITmedia・MarkeZine・BRIDGE | スタートアップは最重要 | | **Tier 3（Vertical / ブログ / インフルエンサー）** | 業界ニッチ・noteの発信者 | 深く刺さる | | **Owned Distribution** | 自社noteブログ・メルマガ | 完全コントロール | ### リレーション構築の基本 - **ギブファースト** — いきなり「取材してください」は嫌われる。まず**情報・専門家紹介・ネタ提供**を贈る - **記者の関心領域を把握** — 記事を読んで「この記者はAIインフラ系」などカルテ化 - **関係は個人に紐づく** — 記者は異動する、名刺交換を超えた関係を築く - **オフレコでのディスカッション** — 発表前に"背景説明"として記者に会う。記事化約束はなくてよい ## エンバーゴ（情報解禁）とエクスクルーシブ ### エンバーゴ 特定日時までの報道差し止めを条件に、**事前に情報を渡す**。 - 記者に準備期間を与え、**深い記事を書いてもらう** - 解禁日に一斉掲載 → インパクト最大化 - 破られるリスクあり、信頼関係が前提 ### エクスクルーシブ（独占） 特定メディア1社に独占スクープを提供。 - そのメディアの**トップ記事になる確率が高い** - 他社が追随報道する（二次拡散） - ブランド価値とメディア格の一致が重要 ## クライシスコミュニケーション ### 48時間ルール 危機発生後、**48時間以内**の対応で評判の9割が決まる（Deloitte）。 ### クライシス対応の鉄則 1. **沈黙しない** — 「調査中」でも声明を出す 2. **事実を述べる** — 憶測で語らない、言い訳しない 3. **責任を認める** — 「申し訳ございません」を最初に 4. **再発防止策を提示** — 「同じことを繰り返さないために○○する」 5. **影響を受けた人を先に配慮** — 株主・メディアより被害者 6. **スポークスパーソンを一本化** — 複数の声で矛盾しない ### やってはいけないこと - 責任転嫁（パートナー・下請けのせいにする） - 被害規模の過小表現（後日覆ると致命傷） - 法務・広報の内部対立を露呈 - 「ノーコメント」を繰り返す - SNSで感情的反論をする ## 記者発表会・カンファレンス ### 開催の判断基準 - **本当にニュースなのか**（招く価値があるか） - **デモ・試作・実物**が見せられるか（ただの会見なら不要） - **登壇者のストーリー**があるか（創業者 × 著名ゲストなど） ### 実施のポイント - Q&Aを十分に確保（30〜45分） - 写真撮影タイム・個別取材時間を設ける - プレスキットを物理＋デジタルで配布 - **録画・文字起こし**を公開し、参加できなかった記者もリーチ ## SOV / Share of Voice の追い方 ブランドが「業界の話題の中でどれだけ占有しているか」。 ### 計測指標 - **メディア掲載件数**（PR Newswire / Cision / Meltwater / Newsela） - **言及数（Mention）** — SNS・ブログ・ニュースでの自然言及 - **Sentiment分析** — ポジ/ネガ/ニュートラル比率 - **SOV = 自社言及 / (自社 + 競合3社の言及)** ### ツール - Meltwater / Cision / PR TIMES（日本国内最大配信） - Brandwatch / Talkwalker / Mentionlytics - Google Alerts（無料・基礎） - Ahrefs（被リンク発生をPR指標として利用） ## PR × SEOの交点 - **自然な被リンク・ブランド言及**はSEO上も重要な評価材料になる - プレスリリース単体のSEO効果は限定的だが、**二次掲載・記事化・引用される独自データ**は検索上の信頼形成にも効く - **Digital PR** = PRを通じて自然な言及・リンク・指名検索を増やす活動（Ahrefs / BuzzStreamなどで観測） ## Thought Leadership（ソートリーダーシップ） 個人・会社が「業界の賢人」と認識される戦略。B2Bで特に効く。 ### 戦術 - 経営者・専門家のブログ / note / LinkedIn - 業界誌への寄稿・連載 - ポッドキャスト出演 / 主宰 - 自社調査レポートの発表（PR × コンテンツの王道） - カンファレンス登壇 ### 独自調査リリース（PR × Content Marketing王道） 自社で**オリジナル調査**を実施しレポート化 → メディアに配信 → 被リンク獲得。 例:「日本の中小企業SaaS導入実態調査 2026」「Z世代の購買行動調査」など。 **独自データは記者にとって最も引用しやすいネタ**。PR × SEOの最適解。 ## 参考文献 - *戦略PR 世の中を動かす新しい6つの法則* — 本田哲也 - *The Fall of Advertising and the Rise of PR* — Al & Laura Ries - *Trust Me, I'm Lying* — Ryan Holiday - *Made to Stick* — Chip & Dan Heath - Muck Rack / Cision "State of the Media" 年次レポート - Edelman Trust Barometer - 日経BP / 電通PRコンサルティング 公開レポート - PR TIMES「プレスリリースの作り方」ガイド ## マーケティングサイクルとの接続 - **Set**: 会社のニュース価値要素、過去の掲載歴、リレーションあるメディア/記者を `memory/profile/` に書く - **Ask**: 「このリリースネタをニュースバリュー6要素で評価して」「〇〇というトレンド文脈にどう接続できる？」 - **再構築**: プレスリリース執筆・配信、記者個別ピッチ、発表会実施、独自調査公表 - **Feedback**: 掲載件数・SOV・被リンク数・指名検索の変化を `memory/results/performance-data.md` に記録 --- title: プロダクトマーケティング・JTBD chapter: "09" part: 2-knowledge-areas status: revised visibility: public authors: - claude reviewers: [] revision: 0.2 updated: 2026-05-19 related-skills: [] related-chapters: - knowledge-areas/intelligence - knowledge-areas/icp-positioning related-knowledge: - knowledge/marketing/playbook/knowledge-areas/product-marketing-jtbd/customer-research-jtbd.md --- # プロダクトマーケティング・JTBD ## 概要と対象範囲 JTBD（Jobs to be Done）、価値提案、launch、メッセージングフレームを扱う。本章は既存体系（Ulwick / Moore / Christensen）を要約し、**launch ↔ 起動・実装するの接続**を CMO Marketing OS Playbook 独自の記述として置く参照章である。 JTBD の**発見プロセス**は 06 章（市場・顧客知能）の射程、**プロダクトへの適用**が本章の射程、という分担。 ## 既存体系との関係 | 体系 | 主な貢献 | |---|---| | **Christensen の Innovator's Dilemma / JTBD** | 「顧客は製品ではなく Job を雇う」フレーム | | **Ulwick の Outcome-Driven Innovation** | Job を計測可能な outcome に分解する手法 | | **Moore の Crossing the Chasm** | Innovator / Early Adopter / Early Majority への移行設計 | | **Story Brand（Donald Miller）** | メッセージングの 7 要素フレーム | | **April Dunford の Obviously Awesome** | ポジショニングと launch メッセージング | 文献参照は [`../appendices/references.md`](../../../reference/references.md)。 ## プロセス（マーケティングサイクル × ITTO） ### 観測・データ収集段のプロセス - **投入物**: 06 章の JTBD 観測、顧客の言葉、競合の価値提案 - **手法と道具**: Job map、Outcome 抽出、競合価値提案分析 - **産出物**: JTBD 仮説、Outcome リスト、競合との価値差分 ### 理解・分析する段のプロセス - **投入物**: JTBD 仮説、ICP（07 章）、ブランド（08 章） - **手法と道具**: 価値提案設計、メッセージング階層、launch ナラティブ - **産出物**: 価値提案、launch 計画 ### 再構築 / 起動・実装する / 学ぶ段 - **再構築**: 機能訴求中心のメッセージング再構築、過剰機能の棄却 - **起動・実装する**: launch 実行、メッセージング本番反映、本番反映前チェック通過 - **学ぶ**: JTBD 適合の検証、価値提案の更新 ## Launch ↔ 起動・実装するの接続（CMO Marketing OS Playbook 独自記述） プロダクトマーケの launch は Marketing OS の **起動・実装する段**として扱う。launch を単発イベントではなく、マーケティングサイクルの中の 起動・実装するとして位置づけることで、本番反映前チェックの省略不可項目（オーナー / 計測 / ロールバック）が launch にも適用される。 具体的には: - **オーナー**: launch の結果に責任を負う個人を 1 名特定 - **計測**: launch の成功 / 撤退条件を事前に決定（採用率・収益・離脱率） - **ロールバック**: launch がうまくいかなかった場合の方針（撤退・縮小・延期） 「launch して終わり」を防ぎ、学ぶ段で JTBD 仮説の検証に回す構造を担保する。 ## アンチパターン - **機能訴求偏重**: Job ではなく機能を語る。「何ができるか」より「何を達成できるか」が顧客に届く - **launch の打ち上げ花火化**: PR を打って終わり、本番反映前チェックを通さない - **JTBD の自社解釈**: 顧客の言葉ではなく自社のフレームで Job を語る - **Crossing the Chasm の誤適用**: Early Majority に Innovator 向けのメッセージで届けようとする - **既存施策との不整合**: launch ナラティブと、既存の Brand・コンテンツ運用が不整合 ## 関連 skill / agent - **`/insight customer`** — 顧客視点での JTBD 検証 - **`/listen customer`** — Job の継続観測 ## 今後の拡張論点 - **JTBD の所在** — 発見プロセスは 06 章、適用は 09 章という分担は妥当か - **既存 [`../base/customer-research-jtbd.md`](./customer-research-jtbd.md) の分担** — 発見は 06 章吸収、適用は 09 章吸収という分け方 - **章の厚み** — JTBD は CMO Marketing OS Playbook の中で再頻出する用語。主要章として厚くする余地がある --- title: 価格・オファー設計 chapter: "10" part: 2-knowledge-areas status: revised visibility: public authors: - claude reviewers: [] revision: 0.2 updated: 2026-05-19 related-skills: [] related-chapters: - knowledge-areas/product-marketing-jtbd - knowledge-areas/demand-lifecycle related-knowledge: - knowledge/marketing/playbook/knowledge-areas/pricing-offer/pricing-strategy.md - knowledge/marketing/playbook/knowledge-areas/icp-positioning/marketplace-strategy.md --- # 価格・オファー設計 ## 概要と対象範囲 価格戦略、プラン、パッケージング、商談オファー設計を扱うスタブ章。本章は薄く保ち、詳細は外部参照に逃がす。 価格は事業構造（コスト・競合・LTV）と密接に絡むため、マーケ単独で決定する領域ではない。本章は**マーケ視点での価格・オファー判断**に絞る。 ## 主要トピックと参照先 | トピック | 主参照 | |---|---| | **価格戦略の基本**（Cost+ / Value-based / Competitive） | [`../base/pricing-strategy.md`](./pricing-strategy.md) | | **B2B SaaS の Value-based Pricing / Usage-based Pricing** | （業界文献） | | **D2C の心理価格・松竹梅** | （業界文献） | | **マーケットプレイス価格設計** | [`../base/marketplace-strategy.md`](../icp-positioning/marketplace-strategy.md) | | **商談オファー（保証・トライアル・割引）** | （09 章 launch メッセージングと連動） | ## マーケティングサイクルとの最小接続 - **観測・データ収集**: 価格感度・競合価格・顧客の WTP（Willingness to Pay）の継続観測 - **理解・分析する**: 価格戦略選択肢の生成 - **再構築**: 既存価格構造（プラン数・割引・無料枠）の見直し - **起動・実装する**: 価格・プランの本番反映、商談オファーの整合 - **学ぶ**: 価格反応の検証 ## アンチパターン - **コストプラス偏重**: コストに利益率を足すだけで、顧客の WTP を見ない - **割引依存**: 標準価格を信用させず、常に割引を提示する - **プラン数過多**: 顧客が選べないほどプランが増える - **無料枠の設計ミス**: 無料で十分使え過ぎて有料転換が起きない ## 関連 skill / agent なし（価格判断は経営・営業との連携が主）。 ## 今後の拡張論点 - **CMO 株式会社の業務範囲に Pricing 設計はどれくらい入るか** — 頻繁に客と話すなら参照章として厚くするかを検討 - **B2B SaaS の Pricing は独立 KA レベルに値するか** — 業種別のテーラリング扱いで十分か - **オファー設計（保証 / トライアル）は 10 章と 11 章のどちらか** — 価格と紐付くなら 10 章、需要創出側なら 11 章 --- title: "価格戦略" chapter: "10" part: 2-knowledge-areas status: revised visibility: public authors: - claude reviewers: [] revision: 0.1 updated: 2026-05-19 related-skills: [] related-chapters: [] related-knowledge: [] --- # 価格戦略 価格は4Pの中で**唯一、直接売上を左右する**レバー。他の3P（Product / Place / Promotion）がコストを生む一方、Priceは利益を決める。 価格戦略はマーケティングサイクルの **観測・データ収集** と **再構築** の両方に関わる。ICPの支払能力・競合レンジをSetに書き、価格変更は再構築の最重要レバーとして扱う。 ## 価格戦略の3つの立脚点 | アプローチ | 決め方 | 向いている状況 | 罠 | |-----------|--------|--------------|-----| | **コストプラス** | 原価 + マージン | 原価が明確な製造・物販 | 顧客価値を反映できない | | **競合ベース** | 競合±αで決める | 成熟市場・コモディティ | 価格競争に巻き込まれる | | **バリューベース** | 顧客が得る価値から逆算 | SaaS、B2B、新規カテゴリ | 価値の定量化が難しい | **推奨は常にバリューベース。** 顧客が得るベネフィット（時間節約・売上増加・コスト削減・ステータス）を金額換算し、その10〜30%を取るのが基本レンジ。 ## Van Westendorp — 価格感度メーター（PSM） 4つの価格をユーザーに聞く： 1. 「高すぎて買わない」価格 2. 「高いがギリギリ買う」価格 3. 「安いと感じる」価格 4. 「安すぎて品質が不安」価格 交点から以下を算出： - **OPP（最適価格点）**: 「高すぎ」と「安すぎ」の交点 - **IPP（無関心価格点）**: 「高い」と「安い」の交点 - **許容価格帯**: 「安すぎ」〜「高すぎ」のレンジ 50〜100名のICPに聞けば方向感が出る。PMF前の価格仮説検証として有効。 ## Good / Better / Best（3段階価格設計） 単一価格を避け、3プランを用意する理由： 1. **アンカリング効果** — 最高プランが提示されることで中央プランが割安に感じる 2. **顧客のセルフセグメント** — 支払能力・使用量で自己選択する 3. **拡張余地** — LTV向上の天井を引き上げる ### 設計原則 - **中央プランを買わせる設計** — 最上位プランは20〜30%高く、特定のパワーユーザー向け機能を含める - **価格差は2.5倍以内** — それ以上開くと分断感が出る - **Best tierは「Enterprise / お問い合わせ」** — 価格交渉余地と高LTV顧客の捕捉 ## 価格軸（メーター）の選び方 SaaS/サブスクでは「何で課金するか」が重要： | 軸 | 例 | 向いているケース | |----|-----|----------------| | **ユーザー数** | Slack、Notion | チーム利用、スケール連動 | | **使用量** | AWS、Twilio、OpenAI API | 利用頻度に価値が比例 | | **成果** | 広告代理店（ROAS連動） | 成果が明確に計測できる | | **機能/ティア** | SaaS一般 | 機能の違いが分かりやすい | | **ハイブリッド** | HubSpot（Seats + Contacts） | 複数の価値次元がある | **「価値が生まれる単位」を価格軸にする**のが鉄則。ユーザーが価値を感じない単位で課金すると解約される。 ## 心理的価格設定 | テクニック | 内容 | 使用例 | |-----------|------|--------| | **端数価格** | 1,000円 → 980円 | 消費財、EC | | **威光価格** | あえてキリの良い高価格 | 高級ブランド、プレミアムSaaS | | **松竹梅の罠** | 3択にして中央を選ばせる | メニュー、プラン設計 | | **デコイ効果** | 劣化版を置いて本命を際立たせる | 印刷版のみ$125 / Web+印刷$125で後者を選ばせる（Economist例） | | **アンバンドル** | 合算すると高いが、個別は安く見える | 航空券、ソフトウェア | | **リファレンスプライス** | 「定価¥10,000 → ¥6,980」 | EC、セール | ## 価格変更のベストプラクティス ### 値上げ 1. **既存顧客はグランドファザード（据え置き）** or **12ヶ月ロック** — 解約を防ぐ 2. **価値追加と同時に発表** — 新機能・アップデートと抱き合わせ 3. **事前告知 30〜90日** — 突然の値上げは信頼を毀損 4. **契約更新タイミングでの適用** — キャッシュフロー影響を分散 ### 値下げ - **「永続値下げ」は最後の手段** — 一度下げると元に戻しにくい - **期間限定プロモーション / 年間契約割引** を先に試す - **値下げは需要増ではなく「競合排除」のために使う** ## 割引の罠 - 割引は**LTVを下げる**（アンカーが下がる） - 割引で獲得した顧客は**解約率が高い**（価格ドリブン層） - 推奨：**量的インセンティブ**（年間契約-20% / 100席-10%）> **一律割引** - セール連発は「通常価格＝高すぎ」のシグナルを送る ## フリーミアム設計の3原則 1. **無料枠が単体で価値を生む** — でないと使われない 2. **有料化の明確なトリガー** — 使用量・機能・チーム化などで自然にアップグレード動機が生まれる 3. **無料ユーザーのコストがペイする設計** — 有料転換率 × ARPU > 無料ユーザーの変動コスト 転換率の目安：**B2C SaaS 2〜5%** / **B2B SaaS 10〜20%** ## 見るべき価格指標 | 指標 | 定義 | 健全レンジ | |------|------|-----------| | **ARPU / ARPA** | 1ユーザー/アカウント平均売上 | 上昇傾向が必須 | | **ACV** | Annual Contract Value | SMB $1〜5K / MM $5〜50K / Ent $50K+ | | **NDR / NRR** | Net Dollar Retention | >100%（SaaS優良指標） | | **Gross Margin** | 粗利率 | SaaS 70〜85% | | **LTV:CAC** | LTV / CAC | >3（<3は価格が低すぎか獲得コストが高すぎ） | | **Discount Rate** | 値引き率の平均 | <15%が目安 | ## Feature Packaging（機能の振り分け） 各機能を「どのプランに入れるか」で CVR と ARPU が同時に大きく変わる。機能を **3 つの役割**に分類して配置する： | 役割 | 配置先 | 例 | 設計意図 | |-----|-------|-----|---------| | **Acquisition Features** | 下位プラン / Free | 基本ダッシュボード、検索、無料枠の API 呼び出し | **入口になる**機能。下位を魅力的にして取り込む | | **Differentiation Features** | 上位プラン | 高度な分析、無制限プロジェクト、優先サポート | **アップグレード理由を作る**機能。中位 → 上位の境界を作る | | **Expansion Features** | Enterprise / アドオン | SSO、監査ログ、SLA、カスタムロール、SCIM | **大企業要件**。NRR を押し上げる源泉 | 加えて **Usage Limits**（メンバー数・プロジェクト数・ストレージ・API レート）も重要な差別化軸。機能の有無で分けにくいプロダクトは制限値で差をつける。 ### Packaging Audit のチェック - ❌ Acquisition Feature が上位プランに入っている → 入口が狭い、CVR 機会損失 - ❌ Differentiation Feature が下位に入っている → アップグレード理由が消える - ❌ Expansion Feature が中位プランに入っている → Enterprise 単価が伸びない - ✅ 中位プランから上位プランへの「次に欲しくなる機能」が明確 ## Price Signaling & Copy（価格の見せ方） 価格表のコピーと提示方法も価格戦略の一部： - **「Contact us」 vs 明示価格**: - Enterprise / 高 ACV ゾーンでは Contact us（価格交渉余地・高 LTV 顧客の捕捉） - SMB / Mid-market は**透明性**を取る（明示価格の方が CVR 高い、Contact 乱発は信頼を毀損） - **Value translation**: 「$X / 月」の下に「= 10 人チームで月 Y 時間節約」等の換算を添える - **Anchoring**: 上位プランを左 or 「最も人気」バッジで中位プランを誘導 - **Annual default**: トグル切り替えではなく Annual を初期表示（LTV・Cashflow が同時に上がる最強設計） ## プラン名のつけ方 `Good / Better / Best` より、**ターゲット別の名称**（Starter / Professional / Enterprise / Team / Business）の方が機能しやすい。顧客が「自分はどれか」を即決できる。 ## 価格変更の運用（補足） 実際の価格変更は **1 回に 1 レバーまで**。複数同時変更は原因分析不能。 実験プロセスの基本形: 1. **Phase 1**: 新規顧客のみに新価格、既存は旧価格で N 週間 2. **Phase 2**: 効果確認後、既存顧客に段階的移行（Grandfathering の期間設計） 3. **Guardrail**: CVR / ARPU / Churn / NPS を連続監視、悪化したら即ロールバック ## 参考文献 - *Monetizing Innovation* — Madhavan Ramanujam（Simon-Kucher） - *The Strategy and Tactics of Pricing* — Thomas Nagle - *Confessions of the Pricing Man* — Hermann Simon - First Round Review: "The Price is Right" / Patrick Campbell (ProfitWell) シリーズ - a16z: "The SaaS Pricing Problem" - Kyle Poyar (OpenView): "PLG Pricing Teardown" シリーズ ## マーケティングサイクルとの接続 - **Set**: ICPの支払能力、競合価格レンジ、自社のコスト構造を `memory/profile/` に書く - **Ask**: 「このICPに対するVan Westendorp設問を作って」「競合3社のプラン構造を比較して」 - **再構築**: 価格ページ / プラン表 / 契約書の値を**実際に変更**する - **Feedback**: 値上げ後のチャーン率、プラン分布、ACVの変化を `memory/results/performance-data.md` に記録 --- title: 需要・ライフサイクル chapter: "11" part: 2-knowledge-areas status: revised visibility: public authors: - claude reviewers: [] revision: 0.3 updated: 2026-05-19 related-skills: [] related-chapters: - knowledge-areas/icp-positioning - knowledge-areas/content-channel - knowledge-areas/measurement-martech related-knowledge: - knowledge/marketing/playbook/knowledge-areas/demand-lifecycle/b2b-demand-gen.md - knowledge/marketing/playbook/knowledge-areas/demand-lifecycle/retention-lifecycle.md - knowledge/marketing/playbook/knowledge-areas/content-channel/community-led-growth.md - knowledge/marketing/playbook/knowledge-areas/demand-lifecycle/cvr-optimization-playbook.md --- # 需要・ライフサイクル ## 概要と対象範囲 需要創出から顧客ライフサイクル全体（オンボーディング・リテンション・エクスパンション・アドボカシー）を一貫して扱う。「リード獲得」と「顧客維持」を別々の知識エリアとして分離すると、組織の動線が分断されるため、本章は両者を統合する。 本章の射程: - **需要創出（Demand Gen）**: 認知 → 興味 → 検討 → 購入のファネル設計 - **オンボーディング**: 購入直後の習熟・初期成功 - **リテンション**: 継続利用・解約防止 - **エクスパンション**: アップセル・クロスセル - **アドボカシー**: 紹介・推奨・コミュニティ 12 章（コンテンツ・チャネル運用）が「どう届けるか」を扱うのに対し、本章は「**誰に何の段階を作るか**」を扱う。 ## 業界トレンドと新興手法 - **Product-Led Growth**: プロダクト体験を需要創出の中心に据える - **Community-Led Growth**: コミュニティをアドボカシーと需要創出のエンジンとして運用 - **Revenue マーケティング**: Sales / Marketing / CS の Revenue 共同責任 - **AI による Lifecycle 最適化**: 解約予兆検知、レコメンデーション、パーソナライズ - **Dark Social / 隠れた需要**: SNS DM・Slack・コミュニティ等、計測しづらい経路の重要性増大 ## テーラリング | 文脈 | 重点 | |---|---| | **B2B エンタープライズ** | ABM、長期商談、Customer Success との接続 | | **B2B SaaS** | PLG + Sales-led の二極運用、PQL（Product-Qualified Lead） | | **D2C** | LTV / RFM 中心、サブスク or 単発購入で運用が大きく分かれる | | **リテール** | 来店動機、ロイヤルティプログラム、店舗とのオムニチャネル | | **コミュニティ型** | アドボカシーが需要創出と一体化 | ## プロセス（マーケティングサイクル × ITTO） ### 観測・データ収集段のプロセス - **投入物**: ファネル現状値（13 章）、商談データ、解約理由、顧客の声 - **手法と道具**: ファネル可視化、Funnel Conversion 分析、解約ヒアリング - **産出物**: ファネルボトルネックリスト、解約理由構造化 ### 理解・分析する段のプロセス - **投入物**: ボトルネック、ICP（07 章）、競合 Lifecycle 設計（06 章） - **手法と道具**: ファネル仮説、リテンション仮説、エクスパンション機会の抽出 - **産出物**: Lifecycle 改善案 ### 再構築段のプロセス - **投入物**: 効果薄い既存施策、形骸化した Lifecycle ステップ - **手法と道具**: 感応度 High / Mid / Low 篩、形骸化メールの機械的列挙 - **産出物**: 廃止施策、整理されたファネル ### 起動・実装する段のプロセス - **投入物**: 新施策・新 Lifecycle 設計 - **手法と道具**: キャンペーン実行、Lifecycle メール / プッシュ実装、CVR 最適化 - **産出物**: 本番反映、計測同時着地 ### 学ぶ段のプロセス - **投入物**: ファネル変化、リテンション結果、解約変化 - **手法と道具**: 4 軸整理（Funnel Conversion / Segment Response / Attribution / Unit Economics） - **産出物**: Lifecycle 設計の更新、profile への書き戻し ## タクティカル・プレイブック（L3） ### B2B Demand Generation ファネル段階別の主な施策: | 段階 | 主な施策 | KPI | |---|---|---| | **認知** | コンテンツマーケ、PR、広告 | リーチ、指名検索 | | **興味** | ホワイトペーパー、ウェビナー | リード獲得、MQL | | **検討** | 事例、比較資料、ROI 計算 | SQL、商談化率 | | **購入** | 提案、デモ、商談 | 受注率、ASP | ABM では Account 単位で全段階を統合運用。詳細は [`b2b-demand-gen.md`](./b2b-demand-gen.md) を参照する。 ### オンボーディング設計 最初の **TTV（Time to Value）** を最短化する設計が中心: - **Aha! Moment の定義**: 顧客が価値を体感する瞬間 - **オンボーディングステップ**: 必須完了 vs 推奨完了の区別 - **進捗可視化**: 残ステップの明示 - **ヘルススコア**: オンボーディング後の利用度可視化 PLG では Aha! Moment 到達率がリテンションの最大予測因子になる。 ### リテンション・解約防止 - **コホート分析**: 加入月別のリテンションカーブ - **解約予兆検知**: 利用低下・サポート問い合わせ増のスコアリング - **解約理由の構造化**: 価格 / 価値 / 競合 / 一時停止 のセグメント別対応 - **ウィンバック**: 解約後の復帰オファー 詳細は [`retention-lifecycle.md`](./retention-lifecycle.md) を参照する。 ### エクスパンション・アドボカシー - **アップセル**: 上位プランへの移行（プラン設計と連動、10 章） - **クロスセル**: 別プロダクトへの拡張 - **NPS Promoter 活用**: 推奨意向が高い顧客の紹介・事例化 - **コミュニティ運営**: アドボカシーと需要創出の循環設計（[`community-led-growth.md`](../content-channel/community-led-growth.md)） ### CVR 最適化 ファネル段階別の CVR 改善は [`cvr-optimization-playbook.md`](./cvr-optimization-playbook.md) を参照する。主な対象: - **Page**: LP / プロダクトページ - **Signup Flow**: 登録動線 - **Onboarding**: 初回利用 - **Form**: 問い合わせ・申込フォーム - **Popup / Paywall**: 介入 UI ## アンチパターン - **Demand と Lifecycle の分断**: リード獲得チームと CS チームが別 KPI で動き、Lifecycle 全体が断絶 - **TTV の長期化**: オンボーディングで顧客を待たせて初期離脱を生む - **解約理由の表面集約**: 解約理由を「価格」一語にまとめ、本質的な離脱要因（価値・競合・利用文脈）を見逃す - **NPS の数値追求**: NPS スコアを上げることが目的化し、Promoter 活用に接続しない - **ファネル偏重**: ファネルの上流だけ最適化し、リテンションを放置（解約が穴のあいたバケツ状態） - **エクスパンションの押し売り**: 価値提供が不十分な段階でアップセルし、解約を誘発 - **コミュニティの放置**: 立ち上げただけで運営せず、自然消滅させる ## 関連 skill / agent - **`/insight customer`** — 顧客視点での Lifecycle 評価 - **`/insight gemba`** — 現場視点でのファネル課題検出 - **`/learn`** — Lifecycle 変化の検証 ## 今後の拡張論点 - **「Demand」と「Lifecycle」を 1 章で扱う妥当性** — 射程が広く、11A Demand / 11B Lifecycle に分割の検討 - **コミュニティの所在** — 11 章（Lifecycle）か 12 章（Channel）か - **CVR 最適化の所在** — 11 章（Demand）か 13 章（Measurement）か - **既存 tactical ファイル群の粒度** — b2b-demand-gen / retention-lifecycle / community-led-growth を今後も個別ファイルで持つか、章本文へ要約統合するか --- title: "B2B 需要創出・ABM" chapter: "11" part: 2-knowledge-areas status: revised visibility: public authors: - claude reviewers: [] revision: 0.1 updated: 2026-05-19 related-skills: [] related-chapters: [] related-knowledge: [] --- # B2B 需要創出・ABM B2BはB2Cと**購買プロセス・関係者数・時間軸**が根本的に異なる。 典型的なB2B Enterprise取引：**6〜10人の購買委員会**、**6〜18ヶ月の検討期間**、**1億円以上の案件**も珍しくない。 この世界では単一のCVR改善より **ターゲットの精度 × 接点の質 × 営業連携** が成果を決める。 ## B2BとB2Cの根本的な違い | 観点 | B2C | B2B | |------|-----|-----| | 意思決定者 | 本人1人 | 3〜10人（委員会） | | 購買動機 | 感情・欲求 | ROI・リスク回避 | | 検討期間 | 数分〜数週間 | 数ヶ月〜年 | | 単価 | 低〜中 | 中〜極高 | | チャネル | SNS・検索・広告 | 営業・展示会・紹介・コンテンツ | | 評価指標 | CVR・CAC・LTV | Pipeline・ACV・Win Rate・NRR | B2Bマーケは**「リードを渡す」のではなく「営業がクロージングしやすい状態を作る」**のが本質。 ## Demand Generation（デマンドジェネレーション）の全体像 ``` Demand Creation（需要創出） ─ まだ気づいていない課題を認識させる ↓ Demand Capture（需要捕捉） ─ すでに探している人を捕まえる ↓ Demand Conversion（需要転換） ─ 商談化・受注へ ``` **多くの会社はDemand Captureばかりやっている。**（指名検索、比較サイト、RFP対応） しかしそれは"顕在層"の奪い合いで、**市場の3〜5%しかいない**。 残りの95〜97%をDemand Createionで教育しないと、結局指名検索は増えない（Chris Walker / Refine Labs）。 ### 95-5 Rule（LinkedIn B2B Institute） - 市場の**5%が「今検討中」** - 残り**95%はout-of-market**（今は買わない） - でも**95%はいつか5%に入る** - だから**Brand Buildingを常に走らせる**必要がある ## リード分類（MQL / SQL / SAL） | 段階 | 定義 | 誰が判定 | |------|------|---------| | **Lead / Contact** | 単なる連絡先 | マーケ | | **MQL（Marketing Qualified Lead）** | マーケ基準で有望 | マーケ（自動 / スコアリング） | | **SAL（Sales Accepted Lead）** | 営業が「追う価値あり」と受諾 | 営業（or SDR） | | **SQL（Sales Qualified Lead）** | 商談化・案件化 | 営業 | | **Opportunity** | パイプライン登録済み案件 | 営業 | | **Closed Won / Lost** | 受注 / 失注 | 営業 | ### MQL → SQL転換率の罠 - MQL大量生産競争は**虚栄指標ゲーム**になりがち - MQL→SQL転換率が**20%を切るなら定義が緩すぎ** - 最近のトレンド：**MQAs（Marketing Qualified Account）へシフト** — 個人ではなく企業単位で見る ## Lead Scoring — スコアリング設計 2軸で評価： | 軸 | 内容 | 例 | |----|------|-----| | **Fit（適合度）** | ICP一致度 | 業種、従業員数、役職、技術スタック | | **Intent（熱量）** | 行動シグナル | 価格ページ閲覧、デモ資料DL、比較検索、訪問頻度 | **Fit高 × Intent高 = 最優先**。Intentだけ高くてFit低い（学生・転職希望者）は追わない。 ## Account-Based Marketing（ABM） **リードを積み上げる**発想ではなく、**狙うべきアカウントを先に決めて、そこを口説く**発想。 ### ABMが向く条件 - ACV（年間契約額）が**$25K〜$50K以上** - ターゲット企業が**数百〜数千社**に絞れる - Salesが**個別対応に耐える体制**を持っている ### ABMのTier分類（1:1 / 1:Few / 1:Many） | Tier | 対象社数 | 接点の密度 | 手法例 | |------|---------|-----------|--------| | **Tier 1（1:1 ABM）** | 10〜50社 | 完全個別 | 個別LP、カスタムピッチ、経営陣直接訪問 | | **Tier 2（小規模ABM / 1:Few）** | 50〜500社 | 業界 / Persona別 | 業界別LP、小規模ラウンドテーブル | | **Tier 3（プログラマティック / 1:Many）** | 500〜5000社 | ICPベースのパーソナライズ広告 | 6sense / Demandbase広告配信 | ### ABM実行の6 Buying Stages（6sense） ``` Awareness ─→ Consideration ─→ Decision ─→ Purchase ─→ Onboarding ─→ Expansion ``` 各ステージに応じて**接触の仕方を変える**： - Awareness: Thought Leadership記事、業界レポート - Consideration: ケーススタディ、ROI計算ツール - Decision: デモ、プルーフオブコンセプト、RFP対応 - Purchase: 契約交渉、法務支援 - Onboarding / Expansion: CSM連携、エクスパンション ### Intent Data 「どの企業が、今、何を調べているか」のデータ。 提供元例： - **Bombora** — コンテンツ消費ベース（B2B最大） - **6sense / Demandbase** — 自社サイト+サードパーティ統合 - **G2 Buyer Intent** — 比較サイト閲覧データ - **LinkedIn** — Engagement + Company行動 使い方： 1. ICPリストをIntent Dataで絞り込み 2. 「今調べている」企業にピンポイントで広告・営業アプローチ 3. SDRが個別アウトバウンド ## B2Bチャネル戦略の現実 | チャネル | 特徴 | 注意点 | |---------|------|--------| | **SEO / コンテンツ** | 長期・安定・複利 | 効果に1年以上、書き手の質が生命線 | | **検索広告** | 即効性・指名検索捕捉 | 単価が高騰しがち、競合指名で疲弊 | | **LinkedIn広告** | 職種・業種・企業ターゲ精密 | CPC $6〜$15と高い、クリエイティブが命 | | **ウェビナー** | リード + 教育 | 単体集客が難しい、共催が鍵 | | **イベント / 展示会** | 大量接触、商談化率高 | 高コスト、LTV計算必須 | | **パートナー / 紹介** | 最強のCVR・LTV | 育成に時間 | | **アウトバウンド（SDR）** | 能動的、スケーラブル | メール受信箱枯渇、品質管理 | | **レビューサイト（G2 / Capterra）** | Decision段階で効く | レビュー集めの仕組みが必要 | **単一チャネル依存は必ず破綻する。** 3〜4チャネルのポートフォリオを組む。 ## Dark Social / 匿名ジャーニー問題 2024年以降のB2Bの現実： - 意思決定者は**匿名で情報収集**する（Slack community、LinkedIn、Podcast、Newsletter） - First Touch / Last Touchが**計測できない** - 「指名検索で来ました」= 裏側でPodcastを聴いていた可能性 ### 対応 - **Self-Reported Attribution**（「どこで知りましたか？」をフォームに追加） - **Brand Volume指標**（指名検索、ダイレクト流入の総量）を追う - アトリビューションより**「どこで認知されているか」**を聞く ## ABMとデマンドジェネレーションの統合モデル ``` [全市場 = TAM] ↓ ICPで絞る [Total Addressable ICP] ↓ Tier分け [Tier1 ABM] [Tier2 小規模ABM] [Tier3 プログラマティック] ↓ シグナル検知 [In-Market Account] ↓ パーソナライズ接触 [Engaged Account] ↓ 営業連携 [Opportunity] ↓ [Closed Won] ``` ## B2Bで見るべき指標 | 指標 | 定義 | 健全レンジ | |------|------|-----------| | **Pipeline Coverage** | 目標売上 / 既存パイプライン | 3〜4x | | **Win Rate** | Opportunity→受注率 | 20〜30% | | **Average Deal Size / ACV** | 平均受注額 | セグメント別に管理 | | **Sales Cycle** | Opp〜受注までの日数 | 90〜270日（製品規模による） | | **CAC Payback** | CAC回収月数 | SaaS <12ヶ月がHealthy | | **Magic Number** | (新規ARR × 4) / S&M費用 | >1.0がHealthy | | **NRR** | Net Revenue Retention | >110%がBest-in-class | ## Product-Led Growth（PLG）との関係 従来型B2B = Sales-Led（営業主導） PLG = プロダクト主導（フリートライアル → 自己探索 → 個人採用 → チーム拡大 → エンタープライズ） 代表例: Slack、Notion、Figma、Datadog ### PLGの重要指標 - **Time to Value** — 登録から初回価値体験まで - **Product Qualified Lead（PQL）** — プロダクト使用実績ベースの"熱さ" - **Bottom-Up Conversion** — 個人 → チーム → 会社契約のファネル **Sales-LedとPLGは排他ではなくハイブリッド**が主流（Hybrid GTM）。 ## 参考文献 - *Predictable Revenue* — Aaron Ross - *The Qualified Sales Leader* — John McMahon - *The SaaS Playbook* — Rob Walling - *ABM is B2B* — Sangram Vajre - *Product-Led Growth* — Wes Bush - *From Impossible to Inevitable* — Aaron Ross & Jason Lemkin - Chris Walker（Refine Labs / Passetto）: Demand Creationの論客 - LinkedIn B2B Institute: "The B2B Effectiveness Code" - 6sense: "The B2B Buying Experience" レポート - Lenny's Newsletter / OpenView / Reforge のB2B回 ## マーケティングサイクルとの接続 - **Set**: ICPアカウント定義、Tier分類、Intent Dataシグナル、Pipeline目標を `memory/profile/` に書く - **Ask**: 「このICPに対するABMキャンペーン案を3層で設計して」「このLead Scoringモデルを評価して」 - **再構築**: アカウントリスト作成、個別LP、アウトバウンドシーケンス、ウェビナー実施 - **Feedback**: Pipeline Coverage、Win Rate、各チャネル別ROIを `memory/results/performance-data.md` に記録 --- title: "リテンション・ライフサイクル" chapter: "11" part: 2-knowledge-areas status: revised visibility: public authors: - claude reviewers: [] revision: 0.1 updated: 2026-05-19 related-skills: [] related-chapters: [] related-knowledge: [] --- # リテンション・ライフサイクル **「獲得の5倍は既存が効率的」** (Bain) とも言われる領域。CAC高騰・クッキーレス・広告単価上昇時代において、リテンションはほぼ唯一コントロール可能な成長ドライバー。 リテンションはマーケティングサイクルの **起動・実装する / 学ぶ** が効く筆頭領域 — 実データから次のSetへ還元しやすい。 ## リテンションの階層 ``` Acquisition（獲得） ↓ Activation（初回価値体験） ← ここが最重要 ↓ Retention（継続利用） ↓ Revenue（収益化） ↓ Referral（紹介） ``` Reforgeの定義： - **浅い関与（Shallow Engagement）** — ログイン・訪問レベル - **中核行動（Core Action）** — プロダクトの本質価値を体験する行動（Slackで送信、Netflixで視聴完了） - **定着ユーザー（Retained User）** — 一定期間内に中核行動を繰り返す **中核行動を定義できているかが全ての起点。** ## Activation — Aha Momentの設計 ユーザーが「これは価値がある」と気づく瞬間 = **Aha Moment**。 有名な例： - Facebook: 10日以内に7人の友達 - Twitter(X): 30人フォロー - Dropbox: 1デバイス以上で1ファイル保存 - Slack: チーム内で2,000メッセージ送信 ### Aha Momentの見つけ方 1. 長期リテンションユーザーの行動ログを抽出 2. 離脱ユーザーと比較し、**差分となる行動**を見つける 3. その行動の**量・頻度・タイミング**の閾値を特定 4. オンボーディングでその閾値まで誘導する設計に変更 ## リテンションカーブの読み方 ``` 継続率 100%│╲ │ ╲ │ ╲_____ │ ╲___ ← Smiling Curve（優良） │ ╲___ │ 残存率が横ばいに └────────────────────────────→ 時間 100%│╲ │ ╲___ │ ╲___ │ ╲___ ← Declining Curve（PMFなし） │ ╲___ └────────────────────────────→ 時間 ``` - **水平に収束するカーブ** = PMFあり、一定の熱烈ファンが残る - **ゼロに向かうカーブ** = PMFなし、獲得しても穴の空いたバケツ - **リターンカーブ（U字）** = 一度離れても戻ってくる層が存在（季節性・ユースケース頻度） **PMF判定の実務ルール**: Day 30 retentionが横ばいに転じる層が存在するか。 ## コホート分析の基本 コホート = 同じ時期に獲得したユーザー群。 縦軸に獲得月、横軸に経過月を取り、継続率をヒートマップ化する。 見るべき変化： - **最新コホートの初月Activationが上がっているか** — オンボーディング改善の成果 - **M3〜M6の残存率が上がっているか** — プロダクト本体の改善成果 - **特定コホートだけ異常** — 獲得チャネル品質の問題（広告キャンペーンの質など） ## RFM分析（既存顧客セグメント） EC / トランザクション系で必須。 | 指標 | 内容 | |------|------| | **R — Recency** | 最終購入からの経過日数（短いほど良い） | | **F — Frequency** | 購入頻度（多いほど良い） | | **M — Monetary** | 累計購入額（多いほど良い） | 各指標を3〜5段階スコア化し、セグメントを作る： | セグメント | R | F | M | 打ち手 | |----------|---|---|---|--------| | **Champions** | 高 | 高 | 高 | VIP特典、先行アクセス、紹介依頼 | | **Loyal** | 高 | 中 | 中 | アップセル、コミュニティ招待 | | **Potential Loyal** | 高 | 低 | 低 | 次回割引、関連商品レコメンド | | **At Risk** | 低 | 高 | 高 | Win-back、個別メッセージ、価値再訴求 | | **Lost** | 低 | 低 | 低 | 最終Win-backメール、リスト外し | ## ライフサイクルステージごとの打ち手 | Stage | ユーザー状態 | メッセージ | チャネル | |-------|-----------|-----------|---------| | **Welcome** | 登録直後 | Aha Momentへ誘導 | メール、アプリ内 | | **Onboarding** | 初回体験中 | 次の一歩を提示 | プロダクト内ガイド | | **Engagement** | 定着化中 | 新機能・活用法・小さなコツ | メール週次、プッシュ | | **Habituation** | 習慣化 | コミュニティ・UGC・深掘り機能 | アプリ内、Discord | | **Win-back** | 離脱中 | 価値再想起 + インセンティブ | メール、リターゲティング | | **Re-activation** | 長期離脱 | 最後の一撃 | 最終メール、不要なら削除 | ## チャーン予兆の代表的シグナル - ログイン頻度の**前週比-50%以上** - 中核行動の停止（投稿/送信/保存が止まる） - サポートチケットでの**ネガティブワード** - サブスクで**決済失敗**の放置（パッシブチャーン） - 主要ユーザー（管理者・決裁者）の**離脱**（B2B） これらを検知してトリガーメール / CS介入。 ## チャーンの分類と対処 | 種類 | 原因 | 打ち手 | |------|------|--------| | **Active Churn** | 顧客が能動的に解約 | プロダクト改善、価値再訴求 | | **Passive Churn** | カード期限切れ等の決済失敗 | Dunning（リトライ自動化）、更新催促 | | **Seasonal Churn** | 使用頻度が元から低い | 一時停止プラン、年間契約 | | **Hidden Churn** | 契約継続だが使用停止 | 使用量アラート、CS介入 | **SaaSのパッシブチャーンは年間5〜10%を占める。** Stripe Smart Retries / Churnkeyで自動回収。 ## メールライフサイクル設計（B2B/B2C共通） ### 最低限あるべき7通 1. Welcome（登録直後） 2. Onboarding Step 1（翌日 / 初回Aha誘導） 3. Onboarding Step 2（3日後 / 2つ目の機能） 4. Use Case Showcase（1週間後 / 成功事例） 5. Feature Highlight（2週間後 / 深い機能紹介） 6. Renewal / Upgrade（月末 / プラン変更誘導） 7. Re-engagement（離脱7日後 / 「最近お見かけしません」） 開封率・クリック率をコホートで測定し、継続的に改善。 ## NRR（Net Revenue Retention）— SaaS最重要指標 ``` NRR = (当期収益 - 解約 - ダウングレード + アップセル + クロスセル) / 前期収益 ``` - **100%超** = 既存だけで成長する状態（優良SaaSのベンチマーク） - **110%以上** = Best-in-class（Snowflake 158%、Datadog 146%など） - **90%未満** = バケツに穴、獲得を増やしても成長しない NRRを上げる3レバー： 1. **解約率を下げる** (中核行動 / CSM / プロダクト改善) 2. **既存からアップセル** (上位プラン / ユーザー追加 / 使用量増) 3. **クロスセル** (別製品の導入) ## ロイヤルティの測り方 - **NPS（Net Promoter Score）**: 「推奨意向」だけに絞った指標。+40以上は優秀、+70以上はBest-in-class - **CSAT**: 個別接点の満足度 - **CES（Customer Effort Score）**: 「解決のしやすさ」。サポート体験と相関 - **リピート率・継続率**: 行動ベースの真実 NPSスコア単体ではなく、**推奨者と批判者の定性コメント**を読むことが価値の源泉。 ## ライフサイクル別チャーン分類（補足） `Active/Passive/Seasonal/Hidden` の原因軸と直交して、**ライフサイクル位置**でも分類すると対策の精度が上がる： | タイプ | 説明 | 主因 | 効く対策 | |-------|------|-----|---------| | **Involuntary Churn** | 決済失敗による解約 | カード期限切れ・与信落ち | Dunning自動化、期限前通知、カード更新フロー | | **Early Churn**（初月〜3ヶ月） | Activation 失敗 | オンボーディング不良・価値未到達 | TTV短縮、Aha Moment再設計、初期CSM接点 | | **Engaged Churn** | 使っていたが解約 | 競合移行・予算変更・ROI不足 | 競合差分の可視化、ROI再訴求、Annualロック | | **Silent Churn** | 使わなくなって解約 | リエンゲージメント不足 | Early Warning発火、利用停滞時の再接触 | 各タイプは原因も対策も異なる。**まず自社のチャーンを 4 タイプの構成比で分解する**。 ## 解約フロー（Cancellation Flow）の設計 解約ページ自体が Save の最大の機会。以下 5 点で診断する： 1. **Friction Level** — 解約ボタンが見つからないと信頼が壊れる。「見つけやすさ」と「摩擦の少なさ」は別物。導線は明確に、ただし衝動解約を防ぐ確認ステップは設ける 2. **Reason Collection** — 解約理由を必ず聞く。選択式 + 自由記述 + 「それ以外」を併用 3. **Save Offer** — 理由別に異なるオファーを出す（後述のマトリクス） 4. **Downgrade Path** — 「解約 or 現プラン」の二択ではなく、**Pause（1〜3ヶ月停止）/ ダウングレード**を中間選択肢として提示 5. **Exit Experience** — 最終的に解約した場合も、いつでも戻れる経路とデータ保持期間を明示 ### 推奨フロー ``` [解約ボタン click] ↓ [理由選択（必須）+ 自由記述] ↓ [理由別 Save Offer 表示] ↓ ↓ [Save受諾] [継続解約] ↓ [Pause/ダウングレード提示] ↓ ↓ [Pause選択] [解約確定] ↓ [Exit Survey + 復帰経路の明示] ``` **Pause は強力**。「解約」と「継続」の間に中間選択肢を置くだけで実 Churn が減る。 ## Save Offer Playbook（理由別オファー） | 解約理由 | Save Offer 例 | 想定 Save 率の目安 | |---------|------------|--------------| | 高すぎる | 時限割引 / ダウングレード提案 / ROI 再訴求 | 15〜25% | | 使っていない | 1〜3ヶ月 Pause / 1on1 オンボーディング再実施 | 30〜40% | | 機能が足りない | ロードマップ共有 / β機能への早期アクセス | 10〜20% | | 競合に移行 | 機能差分の具体的提示 / 移行コスト可視化 | 10〜15% | | 一時的な事情 | Pause / 年額割引 / 解約リマインダー設定 | 25〜35% | **一律割引は安売りの罠**。理由に応じた対応が信頼を生む。Save 率だけ見ると、強引に残留させて後で解約される罠（LTV 悪化）に陥るので、**Save 後 90 日のリテンション**を必ず Guardrail に置く。 ## Reactivation（復帰）シーケンス 解約者向けの 3 タッチ・リエンゲージメント： | Day | 件名の方向性 | 目的 | |-----|------------|-----| | 0 | お気持ちが変わったら... | データ保持期間と復帰経路の明示。引き止めない | | 30 | 最近の改善を見てください | 新機能・改善点を知らせる | | 90 | 特別オファー | 割引付き復帰オファー | Day 0 で**引き止めない**ことがブランド信頼の起点。90 日割引は LTV を下げるリスクがあるので、**Save 候補ではなく完全離脱者**にだけ送る。 ## Involuntary Churn Fix（決済失敗対策） 工数小・効果大の最優先対策。SaaS では年間 5〜10% を占める。 - **Dunning フロー**: 失敗後 N 通のメール + アプリ内通知 + （重要顧客は）SMS - **Card Update**: カード期限の **30 日前通知** を自動化 - **Smart Retries**: Stripe Smart Retries / Churnkey 等で曜日・時間帯を最適化 - **Grace Period**: 失敗後即解約ではなく N 日の猶予期間 ## 参考文献 - *Loyalty Loop* — Andy Cloyd - *Hooked* — Nir Eyal（既にmarketing-frameworks.mdで言及） - *The Customer Success Economy* — Nick Mehta - Reforge: "Retention + Engagement" シリーズ (Brian Balfour, Casey Winters) - Andrew Chen: "The Cold Start Problem" リテンション章 - Lenny Newberry（Lenny's Newsletter）: リテンション関連回 - ProfitWell / Paddle: Churn関連リサーチ ## マーケティングサイクルとの接続 - **Set**: 中核行動の定義、現状のD1/D7/D30リテンション率、主要セグメントを `memory/profile/` に書く - **Ask**: 「このリテンションカーブを読んで / コホート比較して / ライフサイクルメール案を7通作って」 - **再構築**: メール実装、アプリ内プロンプト、ダッシュボードのアラート設定、Dunning実装 - **Feedback**: 施策前後の残存率・NRR・チャーン率を `memory/results/performance-data.md` に記録 --- title: コンテンツ・チャネル運用 chapter: "12" part: 2-knowledge-areas status: revised visibility: public authors: - claude reviewers: [] revision: 0.3 updated: 2026-05-19 related-skills: [] related-chapters: - knowledge-areas/demand-lifecycle - knowledge-areas/measurement-martech related-knowledge: - knowledge/marketing/playbook/knowledge-areas/content-channel/content-marketing.md - knowledge/marketing/playbook/knowledge-areas/content-channel/digital-advertising.md - knowledge/marketing/playbook/knowledge-areas/content-channel/ad-operations/ - knowledge/marketing/playbook/knowledge-areas/content-channel/seo-fundamentals.md - knowledge/marketing/playbook/knowledge-areas/content-channel/seo-playbook.md - knowledge/marketing/playbook/knowledge-areas/content-channel/video-shorts-strategy.md - knowledge/marketing/playbook/knowledge-areas/content-channel/creator-influencer.md - knowledge/marketing/playbook/knowledge-areas/content-channel/partnership-affiliate.md - knowledge/marketing/playbook/knowledge-areas/content-channel/event-exhibition-playbook.md - knowledge/marketing/playbook/knowledge-areas/brand-narrative/pr-comms.md --- # コンテンツ・チャネル運用 ## 概要と対象範囲 オウンド・ペイド・アーンド・シェアードチャネルの統合運用を扱う。本章は CMO Marketing OS Playbook 内で**最大の L3 Tactical 層**を持ち、媒体・手法別の運用詳細を tactical/ サブディレクトリに抱える。 本章の射程は次の 4 区分: - **オウンド**: 自社サイト、ブログ、メール、自社アプリ、SEO - **ペイド**: 検索広告、SNS 広告、ディスプレイ広告、動画広告 - **アーンド**: PR、メディア掲載、UGC、口コミ - **シェアード**: コミュニティ、パートナー、インフルエンサー、アフィリエイト 11 章（需要・ライフサイクル）が「**何の段階を作るか**」を扱うのに対し、本章は「**どう届けるか**」を扱う。両章はセットで運用される。 ## 業界トレンドと新興手法 - **AI 生成コンテンツ**: 大量生成と品質判定のバランス - **AEO（Answer Engine Optimization）/ GEO（Generative Engine Optimization）**: AI 検索 / 回答エンジン向けの最適化 - **動画ファースト**: ショート動画（TikTok / Reels / Shorts）の比重増 - **コミュニティとの境界**: SNS とコミュニティの融合 - **Retail Media**: EC プラットフォームの広告化 - **ゼロパーティデータ**: 顧客が直接提供するデータでのパーソナライズ AI 生成は速度を上げるが、**ブランド一貫性とハルシネーション検知**を伴わない大量生成はブランド資産を毀損するリスクが高い（17 章のリスク管理と連動）。 ## テーラリング | 文脈 | 重点 | |---|---| | **B2B エンタープライズ** | コンテンツマーケ + ABM 広告 + ウェビナー | | **B2B SaaS** | SEO + コンテンツマーケ + コミュニティ + PLG | | **D2C** | SNS 広告 + UGC + インフルエンサー | | **リテール** | Retail Media + 店舗連動 + ロイヤルティアプリ | | **規制業種** | 表現規制に従う、PR 中心、広告は限定的 | ## プロセス（マーケティングサイクル × ITTO） ### 観測・データ収集段のプロセス - **投入物**: チャネル別パフォーマンス、競合のチャネルミックス、媒体仕様変化 - **手法と道具**: Channel mix 監査、競合スタック調査、媒体仕様の取り込み - **産出物**: チャネル別効率マップ、競合との差分 ### 理解・分析する段のプロセス - **投入物**: チャネル別効率、ICP（07 章）、Brand（08 章） - **手法と道具**: チャネル選択判断、コンテンツ戦略の生成、訴求軸の抽出 - **産出物**: Channel mix 仮説、コンテンツ計画 ### 再構築段のプロセス - **投入物**: 効果薄いチャネル、形骸化したコンテンツ運用 - **手法と道具**: P3 × Low 感応度チャネルの機械的列挙、聖域メディアの否定 - **産出物**: 廃止チャネル、廃止コンテンツライン ### 起動・実装する段のプロセス - **投入物**: 新チャネル設計、新コンテンツ計画 - **手法と道具**: 制作、配信、入札、計測同時着地 - **産出物**: 本番反映、Brand 適合チェック通過 ### 学ぶ段のプロセス - **投入物**: チャネル別反応、コンテンツ別効果 - **手法と道具**: Attribution 分析、A/B 結果、コンテンツ ROI - **産出物**: チャネル別判定、コンテンツ戦略の更新 ## タクティカル・プレイブック（L3） 本章は L3 が最も厚い。媒体・手法別の運用詳細は、本章配下のサブファイルまたはサブディレクトリに置く。各 Markdown ファイルはその内容がそのまま 1 ページとして読まれる前提で管理し、ディレクトリの README は入口・目次として扱う。 ### オウンドコンテンツ（tactical/owned-content/） - **SEO**: 検索意図ベースのキーワード戦略、技術 SEO、コンテンツ最適化（[`seo-fundamentals.md`](./seo-fundamentals.md) / [`seo-playbook.md`](./seo-playbook.md)） - **コンテンツマーケ**: 編集計画、トピッククラスター、コンテンツライフサイクル（[`content-marketing.md`](./content-marketing.md)） - **動画・ショート**: 動画戦略、プラットフォーム別運用（[`video-shorts-strategy.md`](./video-shorts-strategy.md)） ### ペイド広告（tactical/paid-advertising/） ペイド広告は [`ad-operations/`](ad-operations/) に置く。広告運用ページは入口・目次ではなく、実務本文をそのページ内に持つ。 - **広告運用**: 目的、顧客状態、広告手法の選定、オファー、計測、アカウント設計、検索連動型広告、ディスプレイ広告、改善、運用体制を一つの本文ページとして扱う（[`ad-operations/`](ad-operations/)） 戦略レイヤーは [`digital-advertising.md`](./digital-advertising.md) を参照する。 ### アーンドメディア（tactical/earned-pr/） - **PR**: メディア掲載、プレスリリース、危機対応広報 - **UGC**: ユーザー生成コンテンツの活用、ガイドライン - **口コミ**: レビュー獲得、レピュテーション管理 詳細は [`pr-comms.md`](../brand-narrative/pr-comms.md)。 ### コミュニティ・パートナー（tactical/community-partnerships/） - **コミュニティ**: 立ち上げ、運営、需要創出との接続（[`community-led-growth.md`](./community-led-growth.md)、11 章と重複） - **インフルエンサー**: 選定、契約、効果測定（[`creator-influencer.md`](./creator-influencer.md)） - **アフィリエイト・パートナー**: 報酬設計、品質管理（[`partnership-affiliate.md`](./partnership-affiliate.md)） ## アンチパターン - **チャネル偏重**: 1 つのチャネルに依存し、ポリシー変更で全滅 - **コンテンツの大量生成偏重**: AI で大量生成し、ブランド一貫性を放置 - **ブランド適合チェック不在**: 制作・配信前のブランド審査がない - **チャネル間の重複配信**: 同じ顧客に複数チャネルから過剰接触 - **PR の打ち上げ花火化**: 一過性のプレス記事で満足し、コンテンツ資産として蓄積しない - **コミュニティの放置**: 立ち上げただけで運営せず、自然消滅 - **インフルエンサーの選定ミス**: フォロワー数だけで選び、文脈適合性を見ない - **媒体仕様変化への遅れ**: プラットフォーム変更（広告ポリシー / アルゴリズム）を見逃す ## 関連 skill / agent - **`/brand`** — Brand 適合チェック（制作物のブランドレビュー） - **`/insight gemba`** — 現場視点での運用課題検出 - **`/listen market`** — 媒体仕様の継続取得 ## 今後の拡張論点 - **章スコープの広さ** — 12A オウンド & SEO / 12B ペイド / 12C アーンド & コミュニティ への分割案 - **コミュニティの所在** — 11 章 Lifecycle と 12 章 Channel に半分ずつ重複。境界の明示 - **AEO / GEO の扱い** — SEO の延長として 12.5.1 で扱うか、独立節として立てるか - **Retail Media の独立節必要性** — D2C / リテールの比重が高まる業種で必須化するか --- title: "広告運用" chapter: "12" part: 2-knowledge-areas status: revised visibility: public authors: - claude reviewers: [] revision: 0.5 updated: 2026-05-21 related-skills: [] related-chapters: - knowledge-areas/content-channel - knowledge-areas/measurement-martech related-knowledge: - knowledge/marketing/playbook/knowledge-areas/content-channel/digital-advertising.md - knowledge/marketing/playbook/knowledge-areas/content-channel/seo-fundamentals.md - knowledge/marketing/playbook/knowledge-areas/content-channel/seo-playbook.md --- # 広告運用 広告運用は、広告媒体の操作ではなく、事業目的、顧客状態、広告手法、オファー、クリエイティブ、ランディングページ、計測、予算を一つの仮説としてつなぐ運用領域である。 本ページでは、広告運用を **広告手法の選定** と **広告の設計・運用** に分けて扱う。広告手法の選定では、検索広告、ディスプレイ広告、SNS広告、動画広告、リマーケティング、SEOとの使い分けを整理する。広告の設計・運用では、目的/KPI、ターゲット、予算、アカウント構造、広告文、入札、LP、計測、改善、運用体制を一連の運用設計として扱う。 戦略レイヤーの整理は [デジタル広告](../digital-advertising.md) を参照する。 ## 広告手法の選定 広告手法の選定は、「どの媒体を使うか」ではなく、「どの顧客状態を、どの接点で、どの行動へ進めるか」を決める作業である。検索広告、ディスプレイ広告、SNS広告、動画広告はいずれも広告であるが、得意な顧客状態と評価指標が異なる。 ### 選定の基本軸 広告手法は、次の5軸で選ぶ。 | 軸 | 問い | 見るべきこと | |---|---|---| | 顧客状態 | 潜在、準顕在、顕在、既存のどこを動かすのか | 検索需要、認知度、検討期間、既存接点 | | 目的 | 認知、比較検討、獲得、再訪のどれか | KPI と CV ポイント | | 商材適性 | 価格、粗利、検討期間、緊急度はどうか | 許容 CPA、粗利 LTV、購入頻度 | | 表現形式 | テキスト、画像、動画、記事のどれが伝わりやすいか | 商品理解に必要な情報量 | | 計測可能性 | 成果や中間行動を測れるか | CV タグ、イベント、CRM 連携 | 媒体の管理画面から始めると、配信できるものを配信してしまう。先に顧客状態と目的を決めることで、広告手法の過不足を判断できる。 ### 主要広告手法の位置づけ | 手法 | 主な役割 | 向いている局面 | 注意点 | |---|---|---|---| | 検索広告 | 顕在需要の獲得 | 検索意図が明確で、CV ポイントが近い | 検索需要以上には拡張しづらい | | ディスプレイ広告 | 潜在層・再訪層への接触 | 認知、リマーケティング、面での接触 | 短期 CPA だけで評価すると過小評価しやすい | | SNS広告 | 興味関心・属性・文脈への接触 | ビジュアル訴求、UGC、D2C、イベント告知 | クリエイティブ疲労が速い | | 動画広告 | 認知・理解形成 | 商品理解に映像が必要な場合 | 視聴指標と事業指標を分けて読む必要がある | | リマーケティング | 既接触者の再訪促進 | 比較検討が長い商材、カート離脱、資料未請求 | 過剰接触やプライバシー規制に注意する | | LP 最適化 | 流入後の転換率改善 | 広告流入はあるが CVR が低い場合 | 広告側だけを調整しても限界がある | 検索広告は「今すでに探している人」を取りにいく。ディスプレイ広告やSNS広告、動画広告は「まだ検索していない人」や「一度接触したが行動していない人」を動かす。広告手法の選定では、この違いを混同しないことが重要である。 リマーケティングや顧客リスト配信は、Cookie、広告識別子、同意取得、媒体ポリシーの影響を受ける。配信対象を作る前に、プライバシーポリシー、地域別規制、同意管理、媒体ごとのデータ利用条件を確認する。 ### 検索広告を優先するケース 検索広告は、検索語句に行動意図が表れているときに強い。 | 向いているケース | 理由 | |---|---| | 検索需要がある商品・サービス | 顧客が自分で探しているため、CV に近い | | 課題解決型サービス | 「水漏れ」「鍵紛失」「税理士 相談」のように緊急度や意図が明確 | | 比較検討される商材 | 「おすすめ」「比較」「料金」「口コミ」などの検索語句が生まれやすい | | 地域性があるサービス | 地域名との掛け合わせで商圏を絞りやすい | | 指名検索があるブランド | 競合防衛や遷移先制御ができる | 検索広告は、SEOより早く露出でき、遷移先を制御しやすい。一方で、広告を止めると流入も止まる。中長期の検索流入資産は SEO と合わせて設計する。 ### ディスプレイ広告を優先するケース ディスプレイ広告は、検索行動がまだ起きていないユーザーや、過去に接触したユーザーへ再接触したいときに有効である。 | 向いているケース | 理由 | |---|---| | 認知が低い商材 | 検索される前に接触を作れる | | 視覚訴求が重要な商材 | 画像や動画で商品の印象を伝えやすい | | 検討期間が長い商材 | リマーケティングで継続接触できる | | 検索広告だけでは母数が足りない | 配信面を広げて潜在層に接触できる | ディスプレイ広告はクリック単価が安く見えることがあるが、CTR や CVR は検索広告より低くなりやすい。短期 CPA だけで切ると、認知や再想起への貢献を見落とす。 ### SNS広告を優先するケース SNS広告は、属性、興味関心、フォロー関係、文脈、クリエイティブによって接触を作る手法である。 | 向いているケース | 理由 | |---|---| | D2C / EC / アプリ | ビジュアルと行動導線を接続しやすい | | UGC や口コミが効く商材 | ユーザー投稿風の表現が機能しやすい | | イベントやキャンペーン | 短期でリーチを作りやすい | | 若年層や特定コミュニティ | 媒体ごとの利用文脈に乗せやすい | SNS広告では、媒体ごとの正解が異なる。Meta、LINE、X、TikTok では、ユーザーの接触態度、クリエイティブ形式、評価指標が違う。広告文よりもクリエイティブの更新速度が成果を左右する場面が多い。 ### 動画広告を優先するケース 動画広告は、短い接触で商品理解やブランド印象を作りたいときに使う。 | 向いているケース | 理由 | |---|---| | 見せないと伝わりにくい商材 | 使用シーン、操作感、変化を説明できる | | 認知拡大 | 広いリーチを作りやすい | | ブランド理解 | 音声、動き、ストーリーで印象を残せる | | 検索前の需要形成 | 後続の検索、サイト訪問、リマーケティングにつなげられる | 動画広告は、視聴率や視聴完了率だけで判断しない。検索増加、サイト訪問、ブランドリフト、リマーケティング母数など、後続行動とセットで評価する。 ### SEO との使い分け 検索広告と SEO は、どちらも検索意図を扱う。しかし役割は異なる。 | 観点 | 検索広告 | SEO | |---|---|---| | 立ち上がり | 入稿後すぐに配信できる | 評価・インデックス・順位反映に時間がかかる | | コントロール | キーワード、広告文、遷移先、予算を調整しやすい | 検索エンジンの評価に依存する | | 費用 | クリックごとに費用が発生する | 直接のクリック課金はないが制作・改善工数が必要 | | 資産性 | 停止すると流入も止まる | 上位表示できれば継続的な流入資産になる | | 使いどころ | 検証、短期獲得、キャンペーン、遷移先制御 | 中長期の検索流入、信頼形成、情報資産化 | SEO の基礎は [`../seo-fundamentals.md`](../seo-fundamentals.md)、実践は [`../seo-playbook.md`](../seo-playbook.md) に置く。広告手法の選定では、SEO では待てない需要、遷移先を制御したい需要、短期に検証したい訴求を広告で扱う。 ### 選定パターン | 状況 | 優先する手法 | 補完する手法 | |---|---|---| | すでに検索されている | 検索広告 | SEO、リマーケティング | | 認知がない | ディスプレイ広告、SNS広告、動画広告 | PR、コンテンツ、指名検索広告 | | 比較検討が長い | 検索広告、リマーケティング | コンテンツ、メール、営業接続 | | 商品理解が難しい | 動画広告、記事LP | 検索広告、リマーケティング | | LP流入はあるがCVしない | LP最適化 | 広告文、フォーム改善、計測見直し | | 予算が少ない | 検索広告から小さく検証 | SEO、既存顧客接点 | 広告手法は単独で完結しない。検索広告で顕在需要を取り、ディスプレイ広告やSNS広告で潜在層に接触し、リマーケティングで再訪を促し、LP 最適化で転換率を上げる。どの順番で組み合わせるかが、広告手法選定の実務である。 ## 広告の設計・運用 広告の設計・運用は、選んだ広告手法を、事業目的に沿って配信・計測・改善するための実務である。媒体の自動化が進んでも、人間が設計すべきものは残る。目的、ターゲット、訴求、CV、予算、LP、計測が曖昧なままでは、媒体の機械学習も正しく働かない。 ### 広告運用を考える単位 媒体別の細部に入る前に、広告運用は次の5要素で設計する。 | 要素 | 問い | 失敗すると起きること | |---|---|---| | 目的 | 認知、比較検討、獲得、再訪のどれを動かすのか | CTR や CPA だけを追い、事業成果と接続しない | | 顧客状態 | 潜在層、準顕在層、顕在層、既存顧客のどこを狙うのか | 媒体選定が先行し、届く相手が曖昧になる | | オファー | クリック後に何を約束し、何を行動してもらうのか | 広告は反応しても LP で離脱する | | 計測 | 主要 CV とマイクロ CV をどう測るのか | 機械学習も人間の判断も誤った方向へ進む | | 運用判断 | 拡大、維持、修正、停止を何で決めるのか | 成果が悪い施策を惰性で続ける | 媒体仕様は変わる。しかしこの5要素は変わらない。 ### 設計の順序 広告設計は次の順序で進める。 1. **目的を決める**: 認知、検討、獲得、再訪のどれを動かすか。 2. **ターゲットを決める**: 誰が、どの状況で、何を求めているか。 3. **オファーを決める**: 広告接触後に何を約束し、何を行動してもらうか。 4. **CVポイントを決める**: 最終 CV とマイクロ CV を定義する。 5. **広告手法を決める**: 検索、ディスプレイ、SNS、動画などを選ぶ。 6. **LPを用意する**: 広告文の約束と遷移先を一致させる。 7. **計測を整える**: CVタグ、イベント、UTM、媒体レポート、GA4、Consent Mode / 同意管理を確認する。 8. **予算と撤退ラインを決める**: 許容 CPA、目標 ROAS、検証期間を定義する。 この順序を飛ばすと、運用中に「クリックはあるが成果がない」「媒体の最適化案を採用してよいかわからない」「代理店の報告を判断できない」という状態になる。 ### 自動化時代に人間が設計すること 現在の広告運用では、入札、配信調整、広告アセットの組み合わせ、キーワード拡張など、多くの領域が自動化されている。人間に残る仕事は、手作業で細かく入札額を変えることではなく、機械学習が正しく働く前提を作ることである。 | 領域 | 自動化されやすいこと | 人間が設計すること | |---|---|---| | 入札 | ユーザーごとの入札調整 | 目標 CPA / ROAS、予算、CV 設定 | | ターゲティング | 配信対象の拡張・最適化 | 誰に何を届けるか、除外すべき対象 | | 広告文 | RSA による組み合わせ最適化 | 見出し、説明文、訴求軸、ブランド表現 | | キーワード | 部分一致、DSA による拡張 | 検索意図の設計、除外キーワード | | 改善 | 最適化案の提示 | 採用する案と捨てる案の判断 | 媒体は配信を自動化できるが、何を検証し、どこで勝ち、どこで撤退するかは自動化できない。 ### アカウント構造 広告アカウントは、一般に次の階層で管理する。 ```text アカウント └ キャンペーン: 予算、地域、デバイス、配信目的 └ 広告グループ: 同じ検索意図・テーマを持つ広告とキーワード ├ 広告: 見出し、説明文、リンク先 └ キーワード: マッチタイプ、入札、除外 ``` 自動化以前は「1広告グループ = 1キーワード」のような細分化が行われることが多かった。しかし細かく分けすぎると、データが分散し、機械学習も改善判断も遅くなる。 現在は、検索意図と LP を対応させ、データが分散しすぎない構造が基本になる。HAGAKURE、GORIN、MUGEN は、この方向性を表す設計思想として理解すればよい。 | 考え方 | 要点 | |---|---| | HAGAKURE | アカウント構造を簡素化し、検索意図と LP に沿ってデータを集約する | | GORIN | リーチ、ターゲティング、広告フォーマット、効果測定を整え、機会損失を減らす | | MUGEN | 自動入札、DSA、RSA を活用し、手作業では拾えない需要へ広げる | ### ターゲットと訴求 広告設計では、属性だけでターゲットを決めない。年齢・性別・地域は入口にすぎない。見るべきなのは、検索語句や閲覧行動の背景にある課題、緊急度、比較検討状況、購買の障壁である。 | 設計対象 | 問い | |---|---| | ターゲット | 誰が、どの状況で、何を求めているのか | | 検索意図 / 接触文脈 | 情報収集、比較、購入、問い合わせ、再訪のどれに近いか | | 訴求 | 価格、品質、早さ、安心、専門性など何を前面に出すか | | LP | 広告文やクリエイティブの約束に対応するページになっているか | | CV | そのユーザーにとって自然な次の行動は何か | 訴求設計では、競合との差別化だけでなく、ターゲットが「自分向けだ」と感じる表現に落とすことが重要である。 ### 予算と目標 予算は、広告費として使える金額から決めるだけでは不十分である。許容 CPA、目標 CV 数、粗利、粗利 LTV / 限界利益 LTV から逆算する。 | 決め方 | 使う場面 | 注意点 | |---|---|---| | 目標から逆算 | 必要な CV 数と許容 CPA が明確な場合 | CVR や CPC の仮説が必要 | | 予算から逆算 | テスト予算が先に決まっている場合 | 期待できる CV 数を現実的に見る | | 粗利 LTV から逆算 | 獲得単価の上限を決めたい場合 | 売上ではなく粗利または限界利益で見る | | 期間から逆算 | キャンペーンやイベントで期限がある場合 | 学習期間を見込む | 初期配信では、目標値を厳しくしすぎると配信量が不足し、学習が進まない。逆に広げすぎると無駄なクリックを買う。最初は仮説を置き、CPC、CTR、CVR、CPA、ROAS を見ながら調整する。 ### コンバージョンポイント コンバージョンポイントは、広告運用で最も重要な設計要素の一つである。購入完了や問い合わせだけでなく、資料請求、会員登録、カート投入、見積もり開始、予約クリックなど、中間行動も含めて設計する。 | 種類 | 説明 | |---|---| | ラストクリック CV | 最後の広告接点から直接成果に至ったもの | | マイクロ CV | 最終成果の手前にある中間行動 | | ビュースルー CV | 広告を見た後、別経路で成果に至ったもの | | アシスト CV | 複数接点の途中で貢献した広告接点 | | クロスデバイス CV | 別デバイスをまたいで成果に至ったもの | 高額商材や検討期間が長い商材では、最終 CV だけを目標にするとデータが不足する。マイクロ CV を設計し、学習と改善に使えるデータ量を確保する。 ### 検索広告の運用要点 検索広告では、キーワード自体がターゲティングの役割を持つ。キーワードは「自社が売りたい言葉」ではなく、「顧客が課題を言語化するときの言葉」から考える。 キーワード設計の基本は次の順序である。 1. 商品・サービスの軸語を洗い出す。 2. 顧客の課題、用途、比較語、地域語、緊急語を展開する。 3. 検索意図ごとにグループ化する。 4. 対応する広告文と LP を決める。 5. 配信後に検索語句レポートで追加・除外を行う。 | マッチタイプ | 配信範囲 | 使いどころ | |---|---|---| | 完全一致 | 登録キーワードと同じ意味の検索語句 | 重要語句を厳密に管理したい場合 | | フレーズ一致 | 登録キーワードの意味を含む検索語句 | 意図を保ちながら少し広げたい場合 | | 部分一致 | 関連する幅広い検索語句 | 自動入札と組み合わせて拡張したい場合 | 現在は部分一致と自動入札の組み合わせが使われる場面が増えている。ただし、広げるほど意図しない検索語句にも出やすくなるため、検索語句レポートと除外キーワードの管理が不可欠である。 ### 広告文、クリエイティブ、アセット 広告文やクリエイティブは、媒体が自動で組み合わせる素材であると同時に、ユーザーが最初に接触する約束でもある。 | 対象 | 役割 | 注意点 | |---|---|---| | RSA | 検索広告の見出し・説明文の組み合わせを最適化する | 人間が良い素材を用意しなければ成果は出ない | | DSA | LP 内容から検索語句・見出しを広げる | サイト構造や SEO が弱いと意図しない配信になりやすい | | 広告表示オプション | 広告枠を広げ、補足情報を出す | サイトリンク、コールアウト、電話番号などを整備する | | バナー / 画像 | 視覚的に認知や興味を作る | 媒体面に合わせたサイズと訴求が必要 | | 動画 | 使用シーンや理解形成に使う | 冒頭数秒で文脈を作る | 広告文では、キーワードを入れることだけでなく、検索意図に合ったベネフィット、差別化、CTA を入れる。広告文と LP の約束がずれると、クリックは取れても CVR は上がらない。 ### 入札戦略 入札戦略は、「どの成果を最大化したいか」によって決める。 | 戦略 | 目的 | 向いているケース | |---|---|---| | コンバージョン数の最大化 | 予算内で CV 数を最大化する | CV 件数を増やしたい場合 | | コンバージョン数の最大化 + 目標 CPA | 目標獲得単価に近づける | 許容 CPA が明確な場合 | | コンバージョン値の最大化 | 売上や価値を最大化する | EC など売上計測ができる場合 | | コンバージョン値の最大化 + 目標 ROAS | 広告費に対する売上効率を最適化する | 商品単価や利益が異なる場合 | Google 広告の検索キャンペーンでは、目標 CPA / ROAS は「コンバージョン数の最大化」「コンバージョン値の最大化」に設定する任意目標として扱われることがある。媒体 UI の名称は変わるため、何を最大化し、どの目標値で制約するかで理解する。 自動入札には学習期間が必要である。設定変更を頻繁に行うと学習が安定しない。目標 CPA や ROAS は、過去実績から大きく乖離しすぎない現実的な値から始める。 ### LP と CRO 広告はクリックを作るが、CV を作るのは LP とオファーである。LP では次の要素を確認する。 | 要素 | 見るべきこと | |---|---| | ファーストビュー | 広告文の約束がすぐに伝わるか | | CTA | 次に取る行動が明確か | | 信頼要素 | 実績、事例、レビュー、保証に根拠があるか | | フォーム | 入力項目が多すぎないか | | 表示速度 | モバイルで遅くないか | 広告側だけを調整しても、LP が弱ければ CPA は改善しない。CVR 改善のためには、広告文、LP、フォーム、CTA を一体でテストする。 実績数値、削減率、No.1 表示、レビュー評価を広告や LP で使う場合は、調査主体、調査期間、調査対象、比較範囲、算出条件を確認する。根拠を説明できない表示は、媒体審査や景品表示法上のリスクになる。 ### 計測とレポーティング 広告運用の判断は、計測の質に依存する。配信前に、次を確認する。 | 項目 | 確認内容 | |---|---| | CVタグ | 主要 CV とマイクロ CV が正しく発火するか | | UTM | チャネル、キャンペーン、広告単位で識別できるか | | 媒体レポート | 表示、クリック、費用、CV、CPA、ROAS を確認できるか | | GA4 / CRM | GA4 のプロパティ、データストリーム、キーイベント、広告後の商談・売上を追えるか | | 同意管理 | Consent Mode、Cookie バナー、プライバシーポリシー、媒体ポリシーを確認しているか | | 数値差 | 媒体、GA4、CRM の差分を説明できるか | レポートでは、結果だけでなく次の判断を示す。拡大、維持、修正、停止のどれにするかを明確にする。 ### 改善サイクル 広告運用の基本サイクルは次の順序である。 1. **設計**: 目的、ターゲット、オファー、CV ポイント、予算、媒体を決める。 2. **入稿**: キャンペーン構造、広告グループ、キーワード、ターゲティング、クリエイティブ、LP を対応させる。 3. **計測確認**: タグ、CV 計測、UTM、媒体レポート、GA4、同意管理の挙動、数値差を確認する。 4. **初期学習**: 早すぎる判断を避け、必要なデータ量が集まるまで大きな変更を抑える。 5. **改善**: 検索語句、除外、入札、広告文、クリエイティブ、LP、予算配分を順に見直す。 6. **判断**: 拡大、維持、修正、停止を決め、仮説を更新する。 重要なのは、媒体の最適化案をそのまま受け入れることではない。媒体は媒体内の成果を最大化するが、事業全体の利益、ブランド、顧客体験、営業接続までは自動で判断しない。広告運用者は、媒体内 KPI と事業 KPI の間を翻訳する役割を持つ。 ### 運用体制 広告運用は、インハウスでも代理店でも成立する。ただし、どちらの場合も社内に判断者が必要である。 | 体制 | 向いているケース | 注意点 | |---|---|---| | インハウス | 事業理解が重要、改善速度を上げたい | 採用、育成、評価制度が必要 | | 代理店 | 専門知識や運用リソースを補いたい | 丸投げすると学習が社内に残らない | | コンサルタント | 戦略やレビューを補いたい | 実装担当との責任分界が必要 | 代理店を使う場合でも、アカウントの帰属、データ閲覧権限、レポートの粒度、改善提案の判断基準を明確にする。広告運用の責任を外部に出しても、事業判断の責任は社内に残る。 ### 基本方針 広告の設計・運用は、次の順序で考える。 1. 顧客状態と目的を決める。 2. 広告手法を選ぶ。 3. オファー、LP、CV ポイントを用意する。 4. 予算、入札、計測を設計する。 5. 小さく配信し、必要なデータ量を確保する。 6. 成果が出るものに予算を寄せ、出ないものは仮説を変えるか停止する。 広告運用の基本は、媒体機能を覚えることではなく、顧客状態、オファー、LP、計測を一つの仮説として接続し、実績から次の判断を良くすることである。 --- title: "コミュニティ主導の成長" chapter: "12" part: 2-knowledge-areas status: revised visibility: public authors: - claude reviewers: [] revision: 0.1 updated: 2026-05-19 related-skills: [] related-chapters: [] related-knowledge: [] --- # コミュニティ主導の成長 現代マーケティングにおける最強のチャネルは**顧客自身**。コミュニティは、 - リテンションを上げ（仲間ができると辞めにくい） - 獲得コストを下げ（UGCと口コミが広告を代替） - プロダクトを洗練し（フィードバックループ） - ブランドを堀にする（真似できない資産） **Community-Led Growth（CLG）** = Product-Led、Sales-Ledに続く第3のGTMモデル。 ## コミュニティが機能する条件 1. **共通の目的・アイデンティティ**がある（単なる顧客集合ではない） 2. **メンバー同士が価値を与え合える**（ホストだけが発信しない） 3. **継続的な集まり場**がある（Discord / Slack / Discourse / オフライン） 4. **明確なルール・カルチャー**がある 5. **新規参加者への導線とオンボーディング**がある **「コミュニティを作る」ではなく「もともとある共通関心の人々に場を提供する」**が正しい姿勢。 ## SPACESモデル（CMX / David Spinks） コミュニティが企業に提供する価値の分類： | 頭文字 | 価値 | KPI例 | |--------|------|------| | **S — Support** | 顧客サポート | 解決率、サポートコスト削減 | | **P — Product** | プロダクトフィードバック | フィードバック件数、採用アイデア | | **A — Acquisition** | 獲得・紹介 | 紹介経由CV、Referral数 | | **C — Contribution** | コンテンツ・知見の共有 | UGC投稿数、引用被リンク | | **E — Engagement** | 顧客のロイヤルティ強化 | 継続率、アクティブ率 | | **S — Success** | 顧客成功・LTV向上 | NPS、拡張率（NRR） | **最初から全部狙わない。** 1〜2つに絞ってコミュニティを立ち上げ、成熟に伴って広げる。 ## コミュニティのタイプ | タイプ | 特徴 | 例 | |--------|------|-----| | **Product Community** | プロダクト使い方・Tips交換 | Notion / Figma / Webflow | | **Professional Community** | 職種・業界の学び合い | HubSpot INBOUND / Pavilion（Sales/Marketing） | | **Interest / Passion Community** | 趣味・関心の共有 | Pelotonコミュニティ、Harley-Davidson HOG | | **Brand Community** | ブランド愛好家 | Nike+、スタバ Leaf Rewards | | **Creator Community** | 発信者同士の協業 | Substack Writers、Product Hunt | B2B SaaSなら **Professional + Product** の複合が定番。 ## プラットフォーム選定 | プラットフォーム | 向いている用途 | 特徴 | |-----------------|--------------|------| | **Discord** | クリエイター・ゲーム・Web3 | リアルタイム・チャンネル構造・若年層 | | **Slack** | B2B専門職・業界コミュ | 仕事用途で馴染みがある | | **Circle / Mighty Networks / Skool** | 有料・教育系 | 構造化投稿、動画・コース統合 | | **Discourse** | オープンソース・技術 | スレッド型、検索に強い、SEO効く | | **Facebook Group** | マスコミュニティ | 低摩擦・広リーチ、40代以上 | | **LINE OpenChat** | 日本国内の大衆系 | 日常使い、参加ハードル低 | | **Reddit（Subreddit）** | 既存の興味層にアクセス | 新設は難しい、既存ハック型 | **Slackは検索性・DM集中が弱い。** 長期アーカイブ / SEO狙いなら Discourse / Circle。 ## コミュニティ立ち上げの4ステージ ### ① Inspire（立ち上げ前） - 誰のため・なぜ今・何のためかを言語化（**Community Mission**） - 創設メンバー10〜30人を**個別に招待**（Cold Startを避ける） - Code of Conduct（行動規範）策定 ### ② Invite（招待拡大） - 既存顧客・リード・SNSから招待 - **100人までは招待制**（無秩序に開かない） - オンボーディングチャネル / 自己紹介文化の確立 ### ③ Engage（活性化） - 週次コンテンツリズム（AMA、お題、まとめ） - メンバー主導の企画を引き出す - **5% Rule** — 5%の超アクティブ層がコミュ全体を動かす ### ④ Scale（拡大） - モデレーター・アンバサダー制度 - 地域・テーマ別サブコミュニティ - オフラインイベント（Meetup） ## エンゲージメント設計 ### 1:9:90の法則 オンラインコミュニティの参加比率： - **1%** が創造（投稿・動画・記事） - **9%** が反応（コメント・リアクション） - **90%** が閲覧（Lurker） **Lurkerも価値がある**。全員を投稿者にするのではなく、1%と9%を丁寧に育てる。 ### Engagement Ladder（エンゲージメントの階段） ``` Lurker（閲覧） ↓ React（リアクション） ↓ Comment（コメント） ↓ Post（投稿） ↓ Help Others（他メンバーを助ける） ↓ Host Events（イベント主催） ↓ Ambassador（公式アンバサダー） ``` 各段階で**次のステップへの誘導**を設計する。 ## アンバサダー / エバンジェリストプログラム ### 設計原則 - **量より質** — 10人の熱狂 > 1000人の形式的参加 - **金銭以外のインセンティブ** — アーリーアクセス、バッジ、登壇機会、取材機会、他メンバーとのネットワーク - **明確な役割と期待値** — 「月1本投稿」「月1回Meetup」など具体化 - **双方向の関係** — 企業が一方的にお願いしない、価値を返し続ける ### 失敗パターン - **現金報酬のみ** → 外発的動機に依存し、熱量が下がる - **ヒエラルキーを作りすぎ** → 古参vs新参の分断 - **コミュニティを"広告装置"として使う** → メンバーが離反 ## UGC（User Generated Content）の引き出し方 1. **明確なテンプレート提供** — 「#〇〇Before で投稿」「テンプレ画像」 2. **リポスト・引用による承認欲求報酬** 3. **コンテスト・お題** — 賞金より"選ばれる光栄"が動機になる層がいる 4. **使いやすい素材** — ロゴ・ハッシュタグ・フィルター提供 5. **著作権・許諾ポリシーを明文化** — 企業側の再利用ルール ## コミュニティの計測指標 ### Health Metrics | 指標 | 定義 | 注意 | |------|------|------| | **DAU / MAU** | 日次・月次アクティブ | 品質なきAUは無意味 | | **MAU / Total Member** | アクティブ率 | 10%以上が健全 | | **First-Post Rate** | 新規加入者が初投稿する率 | 低ければオンボーディング改善 | | **Reply Rate** | 投稿への返信率 | 80%以上が健全 | | **Time to First Reply** | 初投稿への返信時間 | 1時間以内が理想 | | **7-day Retention** | 加入後7日の継続率 | 60%以上目標 | ### Business Impact - Community経由の紹介CV - Community参加顧客のNRR（非参加と比較） - Supportチケット削減率 - 採用応募者のCommunity経由比率 ## コミュニティマネージャーの役割 **ただの投稿者ではない**。以下の5役を兼任： 1. **Host** — 場を温める、対話を促す 2. **Moderator** — ルール運用、トラブル解決 3. **Producer** — コンテンツ・イベント企画 4. **Analyst** — 健全性の測定、改善 5. **Advocate** — メンバーの声を社内へ 1人目のCMは**カルチャー**を決める最重要ポジション。**創業者・経営者に近い感性**を持つ人を採る。 ## オフラインとの統合 - **Meetup / Conference** が最強のエンゲージメント増強剤 - オンラインのみでは**3年目以降に停滞**する傾向 - HubSpot INBOUND、Figma Config、Notion Make Clubなど代表例 - 小さく始める：10〜20人のディナー、ラウンドテーブル ## アンチパターン | 罠 | 実態 | |------|------| | 「とりあえずSlack作る」 | 目的なき場は3ヶ月で死ぬ | | 「投稿数が多ければ健全」 | スパムと雑談だけなら価値ゼロ | | 「売上に直結しないので縮小」 | 2〜3年の複利効果を見れない | | 「社員だけで活性化」 | 顧客同士の対話を阻害 | | 「KPI未設定」 | 続ける理由を失う | | 「閉じすぎる」 | 新規が入れず老化する | ## 参考文献 - *Get Together* — Bailey Richardson他（People & Company） - *The Business of Belonging* — David Spinks（CMX創設者） - *The Art of Community* — Charles Vogl - *Subscribed* — Tien Tzuo（Zuora） - *コミュニティ・マーケティング* — 小島英揮（AWS Japan） - Andreessen Horowitz "Community-Led Growth" ポスト - Reforge "Community-Led Growth" コース - CMX Hub（David Spinks）のリサーチ ## マーケティングサイクルとの接続 - **Set**: ターゲットの共通関心、既存の熱狂ユーザー、競合コミュニティの状況を `memory/profile/` に書く - **Ask**: 「このICPに対するコミュニティMissionを3案」「立ち上げ初期のプログラム設計を」 - **再構築**: Discord / Slack開設、Code of Conduct策定、オンボーディングフロー実装、月次イベント運営 - **Feedback**: Health MetricsとBusiness Impactを `memory/results/performance-data.md` に記録 --- title: "コンテンツマーケティング" chapter: "12" part: 2-knowledge-areas status: revised visibility: public authors: - claude reviewers: [] revision: 0.1 updated: 2026-05-19 related-skills: [] related-chapters: [] related-knowledge: [] --- # コンテンツマーケティング ## コンテンツマーケティングとは - 顧客にとって価値のある情報を提供することで、何らかの目的を達成すること - 記事を書いて検索トラフィックを集める ≠ コンテンツマーケティング - ホワイトペーパーでメールアドレスを収集、動画活用なども含む幅広い手法 ## コンテンツの目的を区別する | 目的 | 内容 | 評価軸 | |------|------|--------| | **流入のためのコンテンツ** | トラフィック獲得が目的 | 広告など他手段と費用を比較して判断 | | **獲得/刈り取りのコンテンツ** | CV獲得が目的 | CVRとCPAで評価 | 目的を曖昧にしたまま「とりあえずコンテンツを増やす」では成果は出ない。 ## コンテンツマーケティングを成功させるポイント 1. 単にコンテンツを増やすだけでは充分な集客にはつながらない 2. プロダクト改善で対応できるならば、コンテンツとして切り離すよりプロダクトを改善すべき 3. プロダクト改善に膨大な工数がかかる場合は、コンテンツとして切り離すケースもある 4. **機動的に対応できるのがコンテンツマーケティングの強み** ## オウンドメディア ### コンテンツマーケティング ≒ インバウンドマーケティング オウンドメディア（自社メディア・自媒体）などを利用したマーケティング手法を「コンテンツマーケティング」と呼ぶ。インバウンドマーケティングと意味は変わらないが、日本国内では「インバウンド」が外国人観光客向けの施策を指すため、コンテンツマーケティングという言葉が一般的。 ### 構造 ``` 検索 → オウンドメディア → 本サイト リンク → オウンドメディア → 本サイト ``` コンテンツを作ることで、サイトへの流入経路を増やす。 ### オウンドメディアは無料ではない お金を払って記事を執筆し流入させるという構造は、広告と同じ。 ``` 記事（¥30,000）→ 流入 → 本サイト ≒ Web広告（¥30,000）→ 流入 → 本サイト ``` コスト構造を理解した上で、広告とのROI比較を行う。 ### オウンドメディアの現実 **実際にオウンドメディアで成功している企業の数は、運営している企業の数に比べれば少ない。** 「記事を書きさえすれば検索で流入する」という誤解がある。いくら記事を書いたとしても、その記事が本当の意味で顧客にとって効果のあるものでなければ意味をなさない。 メディアを立ち上げる前に「その情報が本当に顧客にとって役に立つのか？」をもう一度考えるべき。 ### オウンドメディア立ち上げのチェックポイント - 大規模な競合がいない - 自分がその分野に関しては専門的である - 一定のキーワードボリュームがある ### フロー型 vs ストック型 - **フロー型**（流れていくコンテンツ）: ニュースなど。フロー型で上手くいっている媒体も多いが、かなりの人的リソースが必要 - **ストック型**（溜まっていくコンテンツ）: 何度も顧客が流入するページ。長期的に資産となる媒体の形成を目指すほうが合理的 オウンドメディアにおいて重要なのは**短期の流入数ではなく、直帰率や滞在時間**などであると考える。 ### 専門性の高いコンテンツ - 外部のライターやクラウドソーシングで毒にも薬にもならない記事を量産してしまうのは、やりがちな間違い - **文字数は専門性の高さを示しうるが、文字数だけでコンテンツの評価が左右されることは（現在は）ない** - 歯科医院や脱毛など医療系がオウンドメディアで集客するのは合理的（専門的であり、大規模な医療サイトもまだ少ない分野） ### 「メディア」にこだわらない - 自前で持つ必要があるのか、自社サイトから切り離すべきか - SNSなどを活用するのも一つの手段（ソーシャルメディアもメディア） - 企業アカウントより社長・社員のアカウントの方が拡散しやすいことも ## ソーシャルメディア・マーケティング ### SNSごとの特性マッピング 2つの軸で整理: **ブランディング↔コミュニケーション** × **写真・動画メイン↔文章メイン** | SNS | 特性 | メイン | |------|------|------| | YouTube | ブランド × 写真・動画 | 動画コンテンツ | | Instagram | ブランド × 写真・動画 | ビジュアルコンテンツ | | Facebook | ブランド × 文章 | 文章+写真 | | LINE | コミュニケーション × 文章 | メッセージ | | X（旧Twitter） | コミュニケーション × 文章 | テキスト・拡散 | | TikTok | コミュニケーション × 写真・動画 | 短尺動画・アルゴリズム拡散 | | Threads | コミュニケーション × 文章 | テキスト・Instagram連携 | ### SNS運用の4タイプ | タイプ | 特徴 | 事例 | |--------|------|------| | **オフィシャル型** | 商品紹介・宣伝中心。写真・動画が重要。担当者は黒子に徹する | スターバックス | | **ユーザーグループ型** | 限定的な顧客を対象。商品開発のフィードバック。ロイヤルカスタマーを育成 | 良品計画（IDEA PARK: 年間8,000件の要望、年間100件近くが商品化） | | **フリースタイル型** | 担当者の色が強く出る。趣味の投稿も多め。通常ツイートと商品関連の割合は9対1 | タニタ | | **カスタマーサポート型** | 質問への返答中心。予約・購入まで完結。宣伝から販売まで1つのプラットフォームで行える | ドミノ・ピザ（LINEで注文、開始4ヶ月で売上1億円超） | **コミュニケーションが増えるほど担当者の自由な発信が必要となるため、より広範な権限委譲が必要。** ### インフルエンサー・マーケティング - YouTube、Instagram、TikTok、X（旧Twitter）などのプラットフォーム上で大きな影響力を持つオピニオンリーダーと協力して行うプロモーション手法 - テレビの衰退と広告ブロッカーの普及が台頭の2大要因 - **マイクロインフルエンサー**（フォロワー数は少ないが独自のネットワークを持つ）のほうがコメント率やいいね率が高い（Markerly調査） - Tomoson調査: インフルエンサー・マーケティングのROIは650% - **その影響が必ずしも全て数値化できるわけではない、テレビ広告に似通った広告手法** ### GoogleではなくSNSで検索する時代 若年層のSNS検索利用は2020年代に入り本格化。特にZ世代では情報収集の主軸がSNS側に移動しており、飲食・ファッション・旅行・美容などビジュアル・体験系のカテゴリで顕著。 - TikTok検索: グルメ・旅行・ハウツー系で台頭。ショート動画による体験ベースの情報が検索意図に合致 - Instagram検索: ハッシュタグ・位置情報・保存機能による「発見→比較→保存」の行動が定着 - X（旧Twitter）検索: リアルタイム性の高いトピック（イベント・障害・トレンド）で依然有効 ファッション・飲食・旅行などは写真・動画からの印象が強く、Google検索より判断しやすいとする層が多い。**顧客が実際にどのプラットフォームで検索しているかを調べ、その場に合わせたコンテンツを用意しないのは大きなリスクになりうる。** ## ホワイトペーパー 適切なコンテンツを用意することで、メールアドレスなどのリスト（リード）を獲得できる。 ダウンロード型コンテンツはリードジェネレーションの有効な手段。 ## Web分析の基礎 ### データ分析の本質 データ分析とは、データの見方を変えること。 - **平均を取る** — 個別データは膨大でも、平均を取れば母集団の傾向がわかる - **クラスタリング** — 平均だけでは見えない場合、粒度を細かくして分類する ### アクセス解析のセグメント軸 - アクセス元（Google、X（旧Twitter）、Facebook等） - ランディングページ - 直帰の有無 - デバイス（PC、モバイル） - 時間帯 個別データを見ていては見えない特徴も、分類するだけで得られる知見がある。 --- title: "クリエイター・インフルエンサーマーケティング" chapter: "12" part: 2-knowledge-areas status: revised visibility: public authors: - claude reviewers: [] revision: 0.1 updated: 2026-05-19 related-skills: [] related-chapters: [] related-knowledge: [] --- # クリエイター・インフルエンサーマーケティング 「広告は疑われ、人間は信じられる」時代。 広告CPMが高騰しブランドセーフティが損なわれる一方、**フォロワーと信頼関係を築いた個人**からの推奨は、従来広告の**数倍のエンゲージメント**と**購買影響力**を持つ。 ただし「インフルエンサーに発注した、で終わる」施策は失敗する。**選定 × ブリーフ × 測定 × 権利** の4点で勝敗が決まる。 ## インフルエンサーの階層 | 階層 | フォロワー数 | 特徴 | 向いているケース | |------|-----------|------|-----------------| | **Nano（ナノ）** | 1K〜10K | 極めて高いエンゲージメント率、身近 | 地域ビジネス、ニッチB2C | | **Micro（マイクロ）** | 10K〜100K | ターゲット明確、コスパ◎ | 多くのB2C、SaaS | | **Mid-Tier（ミッドティア）** | 100K〜500K | 専門性と規模のバランス | 認知拡大＋CV両立 | | **Macro（マクロ）** | 500K〜1M | リーチ大きい、専門色薄まる | 大型ローンチ | | **Mega / Celebrity** | 1M+ | マス認知、高単価 | ブランドキャンペーン | ### エンゲージメント率とフォロワーの反比例 ``` Nano: 6〜10% Micro: 3〜6% Mid: 2〜3% Macro: 1〜2% Mega: 0.5〜1% ``` **Nanoの方が総インプレッション単価（CPM）は安い**ことも多く、B2Cは Micro × 複数人展開が主流。 ## Tierごとの報酬レンジ（日本市場参考） | 階層 | Instagram投稿 | TikTok投稿 | YouTube動画 | |------|------------|-----------|------------| | Nano | ¥10K〜¥50K | ¥10K〜¥50K | ¥30K〜¥100K | | Micro | ¥50K〜¥300K | ¥100K〜¥500K | ¥200K〜¥800K | | Mid | ¥300K〜¥1M | ¥500K〜¥2M | ¥1M〜¥3M | | Macro | ¥1M〜¥5M | ¥2M〜¥10M | ¥3M〜¥10M | | Mega | ¥5M〜 | ¥10M〜 | ¥10M〜 | ※ カテゴリ・二次利用権・独占性で大きく変動。 ## 課金モデル | モデル | 説明 | 適用 | |--------|------|------| | **Flat Fee** | 固定投稿料 | 通常契約 | | **CPM（Cost per Mille）** | 想定インプレッション×レート | 大型キャンペーン | | **CPE（Cost per Engagement）** | 反応ベース | エンゲージ重視 | | **CPA / Affiliate** | 成果報酬（紹介CV） | クーポン・紹介リンク | | **Hybrid** | 固定＋成果 | 最近の主流 | | **Gift / Seeding** | 無償提供のみ | Nano層、長期リレーション | **成果報酬100%**は優良クリエイターには受けてもらえない（労力見合わない）。**固定＋成果ボーナス**が標準。 ## クリエイター選定の5軸 ### ① Audience Fit（オーディエンス一致度） - フォロワーのデモグラ・関心事が**自社ICPと一致**するか - ツール: Modash / HypeAuditor / CreatorIQ / Popular Pays - **フォロワー数だけ見ない。オーディエンス質を見る。** ### ② Engagement Authenticity（エンゲージメントの本物度） - Fake Followers比率（5%以下が健全） - 急激なフォロワー増の履歴（買いフォロワー検出） - コメントの質（「🔥」「😍」だけでなく文章コメント） ### ③ Content Quality（コンテンツの質） - 過去投稿の統一性・編集スキル・ブランド親和性 - NGワード・過去のトラブル歴のチェック（ブランドセーフティ） ### ④ Brand Alignment（価値観一致） - 過去のスポンサーとの相性 - 公言している価値観・政治的立場 - 炎上履歴 ### ⑤ Commercial History（商業実績） - 過去のPR投稿の**開示・コンプライアンス** - エンゲージメント低下の有無 - 結果を数字で語れるか ## ブリーフ（依頼書）の書き方 **「自由にやってください」は最悪**。クリエイターの個性を殺さず、必要条件だけ明確化する。 ### 必須項目 ``` 1. Campaign Goal — 認知 / 検討 / CV / リーンチ 2. Target Audience — 具体的な人物像（ICP） 3. Key Messages（3つまで） — 必ず入れる要素 4. Do's and Don'ts — 言ってほしい / NGワード 5. Call to Action — 何をしてほしいか 6. Hashtags / Mentions — #PR #タイアップ 必須 7. Disclosure要件 — ステマ規制対応 8. Deliverables — 形式・本数・尺 9. Review Process — 下書きチェックの有無・タイミング 10. Usage Rights — 二次利用範囲・期間 11. Timeline — 投稿日・公開時間帯 12. Compensation — 支払い条件 ``` ### ブランドガイドの添付 - ロゴ使用規定・カラーコード・NG表現・製品の正しい呼び方 - ただし**クリエイターのトーンを優先**し、ブランド側の"規制"は最小限に ## ステマ規制（日本） **2023年10月〜景品表示法**: 広告であることを明示しない広告行為は違法。 ### 必須表示 - **「#PR」「#広告」「#タイアップ」「#提供」** のいずれか - キャプション冒頭 or 目立つ位置 - 動画では冒頭または概要欄明記 - 文字が埋もれない大きさ・コントラスト ### 違反時 - 措置命令・公表 - ブランド側が違反責任を負う（クリエイター任せにできない） - クリエイターとの**ブリーフ・契約書に明記義務** ### 実務対応 - ブリーフに明示的に開示要件を記載 - 投稿前レビューで**開示チェック** - 定期的な契約書アップデート ## 測定 — Creator Marketing ROI ### Leading Indicators（投稿直後） - Reach / Impressions - Engagement Rate - Save Rate（Instagram） - Share Rate - Watch Time / 視聴完了率（動画） - Comment Sentiment（ポジ/ネガ） ### Lagging Indicators（中長期） - ブランドリフト（認知・好意度 / Brand Lift Study） - 指名検索量（Google Trends / Search Console） - プロモコード使用数 - UTM / アフィリエイトリンク経由CV - オーガニック流入増加 ### Incrementality測定 インフルエンサー投稿は**Attribution困難**。 → **Geo Lift Test** もしくは **Post-hoc Sales Lift**（投稿前後比較）が有効。 → `knowledge/marketing/playbook/knowledge-areas/measurement-martech/measurement-incrementality.md` 参照。 ## 二次利用権とホワイトリスト広告 ### 二次利用の範囲 - **オーガニック投稿のみ** — デフォルト - **Paid Social用素材として利用可** — 追加料金発生（通常20〜50%上乗せ） - **Webサイト / LP掲載** — 別途交渉 - **TV / OOHへの転用** — 高額、タレント扱いに近い - **期間** — 3ヶ月 / 6ヶ月 / 12ヶ月 / 永続 ### Whitelisted Ads（ホワイトリスト広告） クリエイターのアカウントから**広告を配信**する。 - Meta の **Branded Content Ads** / TikTok の **Spark Ads** - クリエイター本人の投稿として広告配信 → **エンゲージメントがオーガニックに蓄積** - 通常広告より **CTR 2〜3倍、CPA 30〜50%低減** のケースあり ## クリエイターとの長期リレーション 単発投稿より**長期パートナーシップ**が圧倒的に強い。 ### 理由 - オーディエンスが「この人が本当に使ってる」と認識 - 段階的なストーリーテリングが可能 - 単発交渉のオーバーヘッドが消える - 深いブランド理解が生まれる ### 長期施策の型 - **アンバサダープログラム**（6〜12ヶ月） - **月次コンテンツコントラクト**（定期的な投稿義務） - **共同商品開発**（ラインコラボ、シグネチャーコレクション） - **株式・Revenue Share** — クリエイターを経済的ステークホルダーに ## プラットフォーム別の特徴 | プラットフォーム | 強み | 向く商材 | |-----------------|------|---------| | **Instagram** | ビジュアル・リーチ | コスメ・ファッション・D2C | | **TikTok** | 爆発的拡散・Z世代 | 新興D2C・エンタメ・食品 | | **YouTube** | 深掘り・検索・購買意向高 | 家電・教育・B2B SaaS | | **X（Twitter）** | テキスト・専門性・速報 | B2B・金融・メディア | | **LinkedIn** | B2B意思決定者 | SaaS・コンサル・採用 | | **Podcast** | 集中・ロイヤル層 | ライフスタイル・B2B高単価 | | **Substack / Newsletter** | 信頼・深読 | B2B・専門書・教育 | ## UGC Creator との違い - **Influencer** = 自分のオーディエンスを持つ（フォロワー重視） - **UGC Creator** = コンテンツを"作る"が本業、配信は広告主側（素材提供型） ### UGC Creator活用 - **TikTok Creative Marketplace / Billo / Insense** などで発注 - オーディエンスを持たない分、**単価が安い**（$50〜$500/本） - 動画素材として広告運用に投入 - 近年の**主流**：UGC動画を広告として運用し、Meta/TikTokで配信 ## 参考文献 - *Influencer* — Brittany Hennessy - *The Creator's Code* — Amy Wilkinson - *Creator Economy* — Li Jin（a16z記事シリーズ） - *Content Inc.* — Joe Pulizzi - IZEA / Influencer Marketing Hub 年次レポート - HypeAuditor / Modash 公開レポート - 消費者庁「景品表示法 ステマ規制」ガイドライン - ワン・トゥ・ワンマーケティング協会 インフルエンサーガイドライン ## マーケティングサイクルとの接続 - **Set**: ICPが信頼している発信者リスト、ブランド相性条件、NG事項を `memory/profile/` に書く - **Ask**: 「このICPに最適なMicro Influencer層を10人推薦して」「ブリーフをこの商材向けに作って」 - **再構築**: 選定・発注・ブリーフ作成・投稿レビュー・開示確認・素材二次利用 - **Feedback**: エンゲージ・CV・ブランドリフト・ROI比較を `memory/results/performance-data.md` に記録 --- title: "デジタル広告" chapter: "12" part: 2-knowledge-areas status: revised visibility: public authors: - claude reviewers: [] revision: 0.1 updated: 2026-05-19 related-skills: [] related-chapters: [] related-knowledge: [] --- # デジタル広告 ## デジタル広告の3大特徴 1. **計測がしやすい** — ユーザー行動を追跡でき、成果につながっているか可視化できる 2. **購入までが短い** — 契約・購入までの距離がオフラインより圧倒的に短い 3. **パーソナライズしやすい** — ユーザー一人ひとりに合わせた体験を提供できる ## ROIの定義 ``` 便益 ÷ 費用 = ROI（Return on Investment） ``` - 顧客単価が1万円、粗利が3,000円、CAC 1,500円 → ROI 200% - 設定価格に広告費を見込んでいないと、集客戦略が破綻する - **プライシングは極めて重要** ## 広告の種類 ### 分類マップ | 種類 | 主要目的 | 最小費用 | 運用負担 | |------|---------|---------|---------| | **純広告** | 認知・ブランディング | 大きい | 小さい | | **ディスプレイ広告** | 認知・獲得 | 小〜中 | 大きい | | **検索連動型広告** | 獲得 | 小さい | 中〜大 | | **ビュー課金型広告** | 認知 | 中 | 大きい | | **ソーシャルメディア広告** | 認知・獲得 | 小〜中 | 大きい | | **メール広告** | 認知・獲得 | 大きい | 小さい | ### 純広告 - 「枠を買う」タイプ。テレビ広告・雑誌広告に近い - Yahoo!ブランドパネル、クックパッド等の著名サイトに掲載 - インプレッション保証型が多い。クリック課金ではない - 歴史上最初のWeb広告はバナー広告（純広告） ### ディスプレイ広告（アドネットワーク） - サイズに合わせてバナー画像やテキストを配信 - クリック課金型がほとんど - 主要プラットフォーム: GDN（Google）、YDA（Yahoo!ディスプレイ広告 運用型。旧YDNは2022年終了）、SmartNews Ads、LINE広告、Criteo等 - ターゲティング種類: - **コンテンツターゲティング** — Webサイトのコンテンツに合わせた最適化 - **デモグラフィックターゲティング** — 推定された年齢・性別に合わせた最適化 - **リターゲティング** — 閲覧履歴でユーザーに再度配信 ### 検索連動型広告（リスティング広告） - 検索ワードに連動した広告。「今、この瞬間」のニーズを捉えられるほぼ唯一の広告 - キーワードによってはクリック単価が極端に高い（保険: $54.91、ローン: $47.21） - 比較的成果が出やすいが、検索ボリュームに上限がある ### ソーシャルメディア広告 **Facebook/Instagram広告** - FacebookとInstagram両方に出稿可能 - ユーザーが自分の情報を入力しているためターゲティング精度が高い - 出稿タイプ: ニュースフィード、ストーリーズ、インストリーム、メッセージ等 - オーディエンス: 年齢、性別、居住地、職業、興味関心 **X（旧Twitter）広告** - プロモ広告（通常広告、クリック課金等） - フォロワー獲得広告（フォローごと課金可能） - テイクオーバー（トレンド画面・タイムラインに大型表示） **LINE広告** - 出稿タイプ: トークリスト、LINE NEWS、VOOM、LINEマンガ等 - オーディエンス: 年齢、性別、居住地域 ## 課金体系 | 体系 | 課金タイミング | |------|-------------| | **PPC（Pay Per Click）** | クリックごと | | **アフィリエイト** | 成果ごと | | **純広告** | 枠ごとの固定金額 | | **CPM課金** | 1,000インプレッションごと | | **CPV課金** | 動画再生ごと | | **リワード広告** | アプリ連動の特殊課金 | ## オークションの仕組み ### ディスプレイ広告のオークション ``` 1. ユーザーがサイト/アプリを閲覧 2. SSP（サプライサイドプラットフォーム）が検知 → DSPにリクエスト 3. DSPが広告同士でオークション → 勝者を送信 4. 複数DSPからの入札を比較 → 最高額の広告を表示 ``` ### リスティング広告のオークション ``` 1. ユーザーがキーワードを検索 2. キーワードに紐づく広告でオークション 3. インプレッション発生 → 広告を表示 4. クリック → LP遷移 → コンバージョン ``` ## SEOとリスティング広告の3つの違い 1. **短期間で流入をコントロールできる**: リスティング広告は収支の計算さえつけば、ある程度短期間で効果を上げることが可能。SEOは効果が出るまで時間がかかる 2. **広告文とランディングページをコントロールできる**: SEOでは検索エンジンがPLPを決定するため柔軟な運用が難しいが、リスティング広告なら顧客を誘導するページをワンクリックで変更可能 3. **「広告主＝お客様」になる**: SEOではGoogleとWebサイトの目指すこと（ユーザーにとってよいWebサイト）は一緒だが、広告ではGoogleにとって広告主がお客様。ただし効果が低いまま広告費ばかり消化する可能性もある ## Google広告が覇者になった理由 - **セカンドプライスオークション**: Overtureのファーストプライスオークション（最高額入札者が最高額を払う→価格が常に下方圧力を受け不安定）に対し、Google広告は自分よりも低い順位（i+1）の単価を採用。広告主にとっても安心で、実際に収益も大きくなることが研究で判明 - **品質スコア**: 広告が顧客にとって効果的であるかをオークションの要素に組み込み、広告自体を顧客にとってよりよいものにするインセンティブを作った ## 品質スコア（Quality Score） 3つの要素で構成される「広告の品質」の指標（10点満点）: - **推定クリック率**: 似たキーワードに出稿している広告の中でのクリック率 - **広告の関連性**: キーワードと広告文のマッチ度合い（例: キーワード「花 通販」なら広告にも「花」「通販」が入っているか） - **ランディングページの利便性**: ページの速度や見やすさ ``` 広告の掲載順位（Adrank）= 推定入札単価 × 品質スコア ``` 品質スコアが倍になれば、入札単価を半分に減らせる。 ## 指名キーワードへの出稿 自然検索で1位でも、広告を止めた場合その半分のクリックは獲得できなくなる（2012年Google調査: 広告の66%のクリックは増加分）。また指名キーワードで広告を掲載した場合としなかった場合でクリック数が153%に上昇（3Q Digital調査）。競合他社が出稿することも違法ではないため、予防的に出稿するケースが多い。 ## コンバージョンの種類 | 種類 | 説明 | |------|------| | **ラストクリックCV** | 最後のクリックが直接的に寄与しているかでCV判定。最も一般的 | | **ファーストクリック（アシストクリック）CV** | 最初に接点を持ったクリックで評価。Adobeの調査ではラストクリックより94%も価値を増加 | | **ビュースルーCV** | ディスプレイ広告を閲覧した後にCVした場合。認知を取れているとは限らない | | **クロスデバイスCV** | スマートフォンで広告クリック後、PCなどで別途CVした場合 | **マイクロコンバージョン**: 本番のCV前の段階をCVとして設定（例: カートに入れる=500円、会員登録=1,000円）。 ## コンバージョン単価は下がれば下がるほどよい？ 「獲得コストは下がれば下がるほどよい」はよくある誤解。獲得コストを下げるほど出稿できる「面」が細ってしまうことが多い。**大枠で見たときの利益が増えるためには、多少の獲得コストを許容することが大事。** 『マネー・ボール』にならって言えば「あなたのゴールは、収益を最大化することであるべきです。コンバージョン単価を下げることであってはいけません」。 ## 検索連動型広告のキャンペーン構造 ### 基本構造 ``` アカウント └── キャンペーン（予算、言語、配信時間、配信地域、ネットワーク） └── 広告グループ（キーワードと広告のマッチング） ├── キーワード └── 広告 ``` キーワードと広告を適切に紐付けることでCTRが向上する。 例: 「居酒屋 激安」→「5,000円飲み放題」、「居酒屋 ○○駅」→「○○駅徒歩5分」 ### 構造設計の思想（Google推奨の変遷） - **HAGAKURE** — 可能な限りシンプルに構成。データの集約で精度向上 - **GORIN** — 機械学習による自動入札の最適化。適切なタイミングで届ける - **MUGEN** — リーチ拡大で新しいチャンスを増やす。ビジネス拡大志向 ## タグマネジメント - コンバージョン計測にはWebサイトへのタグ埋め込みが必要 - GTM（Google タグマネージャー）を一度埋めれば、サイト編集なしにタグ追加可能 - 計測を整えることでAIによる配信最適化が機能する - **タグマネジメントは広告効果の基盤** ## コンバージョンの考え方 - ECなら売上、Webサービスなら登録者など、商材によってCVポイントは異なる - CV単価が高い商材ほど多くの広告を出稿でき、集客の選択肢が広がる - **設定価格に広告費を見込まないと集客戦略が破綻する** --- title: "SEO 基礎" chapter: "12" part: 2-knowledge-areas status: revised visibility: public authors: - claude reviewers: [] revision: 0.1 updated: 2026-05-21 related-skills: [] related-chapters: [] related-knowledge: [] --- # SEO 基礎 ## 検索エンジンの本質 ### Googleの誕生と覇権 - 1995年、スタンフォード大学の大学院生ラリー・ペイジとサーゲイ・ブリンが開発 - 現在Googleの検索エンジンで月間1,000億以上が検索されている（1秒間に約3万8,000回の検索） - **SEO = Search Engine Optimization = 「検索エンジンのためのデザイン」**。ユーザーは視覚的にWebサイトを評価するが、Googlebotは目を持っていないため、人間相手のデザインとは違う視点での対策が必要 ### Google以前 vs Google - **Google以前**（AltaVistaなど）: 「一致する単語の出現頻度、および一致する単語間の距離によって決定される」→ スパムが容易 - **Google**: PageRankにより、被リンクを使ってページの重要性を順位付けするロジックを開発。**競合と違ったのは、より重要なページを提供するための順位付けのロジック** ### PageRank - Googleの根幹技術。ハイパーリンク（サイト間のリンク）を論文の引用数にたとえ、Webページの重要性を推定する手法（論文はスタンフォード大学のページで公開） - 多くのサイトからリンクされているページ = 価値が高い。さらに支持されているページからリンクされているページも支持されているだろう…と再帰的に計算 - 歴史的には、外部リンクを使った評価が検索品質の差別化要因になった。現在はリンクだけでなく、コンテンツの有用性・信頼性・ページ体験・技術的健全性など複数の観点で評価される ### 検索順位に関わる代表的な観点 Google のランキングシステムは多数のシグナルを組み合わせており、個別の要因や重みを外部から正確に把握することはできない。実務では、公開情報と観測可能な指標をもとに、次の観点で改善余地を見る。 | 観点 | 要素 | 説明 | |------|------|------| | 重要 | コンテンツの関連性 | 検索意図に対して、ページが直接・具体的に答えているか | | 重要 | コンテンツの品質と信頼性 | 独自性、経験、専門性、出典、運営者の透明性 | | 重要 | 外部からの評価 | 自然な被リンク、ブランド言及、業界内での参照 | | 補助 | ページ体験 | モバイル対応、Core Web Vitals、HTTPS、広告や UI の邪魔の少なさ | | 補助 | 技術的健全性 | クロール可能性、インデックス可否、構造化データ、内部リンク | ## SEO必須用語 | 用語 | 説明 | |------|------| | **クローラー/クローリング** | 様々なWebサイトを巡回してWebページを認識するbot（ロボット） | | **インデックス/インデクシング** | 検索エンジンのクローラーが自分たちのデータベースにWebページを認識・登録すること | | **検索クエリ** | 実際に検索されたキーワード。狙っているキーワードと実際のクエリは異なる場合がある | | **オーガニック検索（自然検索）** | 有料検索（リスティング広告）との対義語。「無料検索」とは言わない | | **被リンク** | 自社Webサイトへの外部からのリンク。重要な評価シグナルの一つだが、リンクの量だけで順位が決まるわけではない | ## ブラックハットSEO（絶対に使用しないこと） 使用するとペナルティにより検索流入がなくなる可能性がある: - **ワードサラダ**: 無意味な単語を自動生成して関連する単語が大量に入っているように見せかける - **リンク購入**: かつては効果があったが現在はペナルティとして発見される。上場企業でも検索流入が激減したケースあり - **隠しリンク/隠しテキスト**: 背景色と同色のフォント、極小フォントサイズで密かにリンクを仕込む - **サテライトサイト**: 無料ブログなどで意味のないWebサイトを作り被リンクを集める ## 検索エンジンとの付き合い方 ### 基本原則 ``` ユーザーにとって役に立つこと = 検索エンジンが評価すること ``` - 過度にSEOを気にするより、ユーザビリティを上げていく - 「絶対に順位が上がる方法」はない - まずはGoogleの公式スターターガイドを読む - **SEOが上手くいかないWebサイトのほとんどは、ユーザーにとってもあまり有益ではないWebサイト** - 「SEO的にどうか？」という考え方は一旦捨て、ユーザーにとって使いやすく見やすいWebサイトを心がけることが一番の近道 ### 人間と機械の両方に向けたコンテンツ ``` 人間が見る 人間が見ない ロボットが見る │ 新しいSEO │ 古いSEO ロボットが見ない│ デザイン・UI │ （無価値） ``` 新しいSEO = 人間にもロボットにも見えるコンテンツを作ること。 ## 良いコンテンツとは - ページを訪れる**目的**が大事。コンテンツが多いから良いわけではない - 覚えやすく、内容をはっきり表した名前（ブランディング）は検索にも有利 - 文字数を稼ぐだけのSEOスパム（調べましたが分かりませんでした系）は評価されない ## SEOの本当の効果 ### よくある誤解 ``` SEO改善前: 100% → SEO改善後: 150%（コンテンツの価値が上がる） ``` ### 現実 ``` SEO改善前: 50%（本来の価値の半分しか伝わっていない）→ SEO改善後: 70% ``` SEOは「価値を増やす」のではなく、「伝わっていない価値を伝える」作業。 ## クエリの差別化 検索ボリュームが多いからといって、売上に繋がりやすいとは限らない。 ``` 「ジャイアンツ」 → ボリューム大・購入確度弱 「ジャイアンツ チケット」 → ボリューム中・購入確度中 「ジャイアンツ チケット 購入」→ ボリューム小・購入確度強 ``` ## SEO最適化の判断基準 ### 最適化が必要なケース - 明確な検索ニーズがある - リンクやブランドなどの既存資産がある - 勝ちたいキーワードが明確 ### 最適化が不要なケース - 明確な検索ニーズがない - 新規立ち上げで資産がない - 狙っているキーワードがない ### 重要な認識 - **キーワード検索数を増やすことはできない** - 地道に認知度を上げ「指名キーワード」を増やすことも大事 - 検索を**コントロールしすぎない**ことが重要 ## SEOが必要な企業の3パターン 1. **コンテンツがメインのサイト** — メディア、ブログ、CGM、ポータルサイト。検索トラフィックが事業に不可欠 2. **すでに充分な資産があるサイト** — 既存の検索流入がある場合、タイトルや説明文の変更だけで効果が出る。0→1より100→101のほうが遥かに簡単 3. **明確な競合がいる/勝ちたいキーワードがある場合** — 特定キーワードで競合に勝つことで売上が大きく変わる ## クエリの種類（Google Search Quality Evaluating Guidelines） | クエリの種類 | 説明 | 例 | |----------|------|------| | **知識クエリ** | 質問や特定の知識に関するクエリ | 「ナポレオン」「イチロー 年齢」 | | **実行クエリ** | 特定の行動に関するクエリ | 「パズドラ インストール」「BMI 測る」 | | **サイトクエリ** | 特定のWebサイトに行くためのクエリ | 「クックパッド」「Yahoo!」 | | **訪問クエリ** | 主にモバイルで、実際の店舗や施設に行くためのクエリ | 「コンビニ」「新宿駅 中華料理」 | **クエリの検索数が多いとしても、それがすぐに需要の高さやトラフィックの価値を示しているわけではない。** ### キーワードの規模分類 | 分類 | 月間検索数 | 特徴 | |------|---------|------| | ビッグキーワード | 10万件以上 | 下位でもある程度獲得できる。検索数は多くても薄いキーワードも多い | | ミドルキーワード | 1万〜10万件 | 効果的なキーワードも多い。1つが上位に来るだけでも売上が立つ | | スモールキーワード | 1万件以下 | 1つや2つが上位に行くだけではほとんど効果がない。多数のキーワードを取る「ロングテール戦略」が必要 | ## SEOの基本テクニック ### 手法1: 良いタイトルと説明文をつける - 狙っているキーワードで競合のタイトルを確認 - 差別化しやすいタイトルをつける - クリックしたくなる説明文を書く - 関連度の高いタイトル/説明文をつける（キーワードを含める） - ページごとにタイトルや説明文を分ける（顧客はページ単位で検索する） - **順位が変わらなくても、クリック率が2倍3倍になればトラフィックもそれに応じて上昇する** ### Google検索ポジション別クリック率（平均） | 順位 | クリック率 | |------|---------| | 1位 | 20.5% | | 2位 | 13.32% | | 3位 | 13.14% | | 4位 | 8.98% | | 5位 | 9.21% | ### 手法2: Webサイト構造とPLP - Webサイト構成はカテゴリがまとまってページの種類を検索エンジンに伝えるべき - URLにキーワードが入っているかも重要な要素 - **PLP（Preferred Landing Page）**: キーワードに対して飛ばしたい、遷移させたいランディングページ。検索エンジンは自社では管理できないため、必ずしも狙ったキーワードに適切なLPが紐付くとは限らない ### 手法3: ページの速度を速くする - Page Speed Insights（Google提供）でチェック - とりわけモバイルではページ速度が遅いことによる離脱がよく起こる ### 手法4: 知名度を上げる - 知名度が上がれば検索数も上がる - 「検索したい人」を増やすことも本質的なSEO - 小手先のテクニックより、必要とされるサービスを作りユーザー体験を改善するほうが費用対効果が高い ## 品質の高いコンテンツ（Google Search Quality Evaluating Guidelines） ### ページの3つの構成要素 - **MC（メインコンテンツ）**: ページの目的を達成するためのコンテンツ。MCがしっかりとユーザーにわかりやすく認識されていることが重要 - **SC（サポートコンテンツ）**: 補足的コンテンツ。ヘッダー、サイドバー、関連ページなど - **広告**: 広告があることは必ずしもページ品質を下げるとは限らないが、過度に顧客体験を損なう広告は問題 ### E-E-A-T（ページ品質の評価基準） 2022年12月の検索品質評価ガイドライン改訂でE-A-Tに **Experience（経験）** が追加され E-E-A-T となった。生成AIコンテンツが氾濫する中で「実体験に基づく一次情報」の価値が相対的に上がっている。 - **Experience（経験）**: 書き手が対象について実際の経験を持っているか。商品レビューなら実際に使った経験、旅行記事なら実際に訪れた経験。AIや他記事の要約では代替できない一次情報が評価される - **Expertise（専門性）**: ページのタイプによって定義が異なる。他のページにない独自の詳細な情報があるか。権威者ではない人が専門家であることもある（例: 病気の患者はその病気の専門家） - **Authoritativeness（権威性）**: 「誰」が語っているのかが重要。医療情報なら医師、音楽情報ならプロのミュージシャン。専門性と重なる部分があるが、権威性は外部の評価や過去の蓄積によって評価される - **Trustworthiness（信頼性）**: 充分なエビデンスや出典、根拠のある論文による引用を示すこと。「AよりBがおすすめ」より「○○の論文によると、AよりBのほうが20%ほどユーザーに好まれる」のほうが信頼できる。E-E-A-Tの中でTrustが中心に位置づけられ、他の3要素はTrustを支える要素とされる ### YMYL（Your Money & Your Life） 「お金と生活に関するコンテンツ」。ユーザーにとって不正確な情報は有害であるため、Googleが厳しく監視。病気に関する情報やカードローンの情報などが含まれる。 ### 高品質コンテンツのサマリー - 他のページにない独自のコンテンツを提供する - 自分が（自分たちが）何者であるかをしっかりと明記する - 根拠不明な情報ではなく、エビデンスや数値のある情報を提供する - **文字数は専門性の高さを示しうるが、文字数だけでコンテンツの評価が左右されることは（現在は）ない** ## プラットフォーム最適化の考え方 SEO、MEO、ASOなど、プラットフォーム最適化を考えるときは: - 「どれだけ最適化する余地があるか」 - 「どれだけアップサイドがあるか」 を冷静に判断する。変えられないものを受け入れ、変えられるものに集中する。 --- title: "動画・ショートフォーム戦略" chapter: "12" part: 2-knowledge-areas status: revised visibility: public authors: - claude reviewers: [] revision: 0.1 updated: 2026-05-19 related-skills: [] related-chapters: [] related-knowledge: [] --- # 動画・ショートフォーム戦略 2020年代後半のSNSは**動画がデフォルト**。Instagram ReelsもYouTube Shortsも縦型9:16へ統一され、**静止画・横型動画は補助**になった。 この章では**縦型ショート動画の設計原理**、**ロングフォーム動画の使い分け**、そして**動画広告の実務**を扱う。 ## 動画マーケティングの3層構造 ``` Short-Form（〜60秒） ─ 発見 / 認知 / バイラル ─ TikTok / Reels / Shorts Mid-Form（1〜10分） ─ 理解 / 検討 ─ YouTube / Instagram Long-Form（10分〜） ─ 深堀り / 購買決定 / LTV ─ YouTube / Podcast動画 ``` **1本で全部を狙わない。** 目的別にフォーマットを選ぶ。 ## ショート動画の黄金則：Hook / Retention / CTA ``` 0〜3秒 ┃ Hook（フック） ← 全ての勝負はここ 3〜30秒 ┃ Retention（保持） ← 期待と報酬の連鎖 最後の3秒 ┃ CTA / Loop（次の行動） ← 視聴完了 or 繰り返し視聴 ``` ### 最初の3秒で勝つ 最初の3秒で**スクロールされない**確率は、**残り全体のパフォーマンスより重要**。 #### 効くHookパターン - **逆説・非常識**：「やってはいけない〇〇」「実は△△は間違い」 - **ビフォアフ**：劇的変化を冒頭に出す - **数字・具体**：「97%の人が知らない」「3分でできる」 - **質問**：「〇〇してる？それ危険かも」 - **テキスト重ね**：冒頭に太字でテーマ提示（無音対策） - **視覚的奇抜性**：珍しい構図・動き・色 - **感情のフック**：怒り / 驚き / 好奇心 / 共感 ### リテンショングラフ（視聴維持）の読み方 プラットフォームはどの秒で離脱したかを細かく提供する。 ``` 視聴率 100%│╲ ← 3秒で落ちる＝Hook失敗 │ ╲_____ │ ╲_____ │ ╲╱╲ ← 途中の谷＝退屈ポイント │ ╲___ 0%│__________________ 0s 60s ``` - 冒頭3秒の離脱率 = Hook評価 - 中盤の谷 = 退屈・蛇足シーン - ラストのピーク = Loop成功（再視聴される） **離脱した秒を見て次回編集を改善**する反復プロセスが全て。 ## フォーマット別の特徴 ### TikTok - **FYP（For You Page）アルゴリズム** が強力：フォロワーなしでもバイラル可能 - **初動72時間**でAlgorithmが方向性を決定 - **トレンドサウンド活用**でリーチ増（ただしビジネスアカウントは使用制限あり → **Commercial Music Library**） - **平均視聴完了率60%以上**が目標 ### Instagram Reels - **既存フォロワーへのリーチが高い**（TikTokより関係性重視） - Feed / Stories / Reelsの連携戦略 - **9:16縦型、セーフエリア**（上下にUI被り領域）に注意 - Save / Share が配信促進シグナル ### YouTube Shorts - **ロング動画との回遊**が最大の強み（Shortsから長尺チャンネル登録） - **SEO要素**：タイトル・説明文の検索性が効く - **ループ設計**（終わりが始まりに繋がる）で視聴完了率が2倍超えも ### 使い分けの基本 - **拡散で新規獲得** → TikTok - **既存ファンとの接点強化** → Reels - **本チャンネル（長尺）への誘導** → Shorts ## 動画広告の基本設計 ### ADD-Apart / ADP法則（Meta推奨） ``` 0〜3秒: Attention（注意を掴む） 3〜10秒: Desire（欲求を作る） 10〜15秒: Ask（行動を求める） ``` **冒頭にブランドロゴを出す必要がある**（3秒以内のブランド露出でBrand Liftが2倍）。 ### 音なし前提で作る（Sound-Off Design） - スマホ視聴の**85%は音声オフ** - **字幕（Captions）必須** - 重要な情報はビジュアル＋テキストで伝える - 音はあれば"より良くなる"補助要素として設計 ### Aspect Ratio | 比率 | 用途 | |------|------| | **9:16（縦型）** | Stories / Reels / TikTok / Shorts | | **1:1（正方形）** | Feed / Explore | | **4:5（縦ポートレート）** | Feed（縦に長く取れる） | | **16:9（横型）** | YouTube通常動画 / OTT | **同じ素材を複数比率で出し分ける**のが広告運用の基本（Dynamic Creative）。 ## UGC動画広告（Creative Trend 2024〜） **素人感の強い動画ほど広告効果が高い**傾向。 - スマホ1台で撮影した縦型動画 - 製品の手元映像 / ビフォアフ / 使用シーン / テスティモニアル - プロ制作の「映像作品」より**等身大の推薦**が信頼される - TikTok Creative Marketplace / Billo / Insense で UGC Creator に制作依頼 ### 成功する広告クリエイティブの型（Meta内部データ由来） - **最初の1秒でブランド露出** - **テスティモニアル形式**（本人がカメラに話しかける） - **Problem → Solution → Proof**（15秒以内） - **複数バリエーションで学習を回す**（同じHookで3〜5本） ## ロングフォーム（YouTube長尺 / Podcast動画） ショートだけでは**深い理解と信頼**は作れない。 B2B・高単価商材は**YouTube長尺**or**Podcast動画**が最強。 ### 作る意味 - 検索で発見される（SEOと同じ永続トラフィック） - 15〜30分視聴＝深いエンゲージ - 「この人のファン」を作る - LinkedIn / X でのセカンダリ拡散 ### 型 - **How-To / チュートリアル**（検索流入） - **インタビュー / 対談**（Guest Pull効果） - **実演 / ケーススタディ** - **業界トレンド解説**（Thought Leadership） - **Vlog / 裏側公開**（親密性） ### サムネイルとタイトル - YouTubeは**サムネイル × タイトル**でCTRが9割決まる - A/Bテスト必須（YouTube Studioの機能） - 顔 / 数字 / 対比 / 驚き表情 の組み合わせ ## コンテンツのリサイクル **1本のロング動画を、10本以上のショートに分解**するのが効率的。 ``` 60分インタビュー ↓ 60秒ハイライト × 10本（TikTok / Reels / Shorts） ↓ Quote画像 × 20枚（Instagram / X） ↓ 書き起こし → Blog記事 → Newsletter ↓ Podcast音声のみ配信 ``` **Pillar Content戦略**：1つのコア資産から多数の派生を生む。Gary Vaynerchuk提唱。 ## 制作コスト感（実務参考） | フォーマット | 内製コスト | 外注相場（日本） | |-------------|----------|---------------| | Short（15秒〜60秒） | 1〜3時間 | ¥30K〜¥150K/本 | | Mid（3〜10分） | 半日〜1日 | ¥150K〜¥500K/本 | | Long（10分以上・YouTube） | 1〜3日 | ¥300K〜¥1M/本 | | TV CM品質（15秒） | 不可 | ¥3M〜¥10M/本 | ### 内製化の境界線 - **月20本以上** 作るなら内製化推奨 - **撮影 + 編集 + 企画**を1人で回すプロデューサーを採用 - AI動画編集（CapCut / Descript / Opus Clip）で生産性10倍 ## AI動画ツール（2026年現在） | ツール | 用途 | |--------|------| | **CapCut** | スマホ動画編集、縦型最適 | | **Descript** | 文字起こし編集（テキスト削除で映像カット） | | **Opus Clip / Vizard** | 長尺 → ショート自動切り出し | | **Runway / Sora / Veo** | AI動画生成（プロモ・コンセプト） | | **HeyGen / Synthesia** | AIアバター動画（多言語対応） | | **ElevenLabs** | AI音声 / ナレーション | 制作時間は**10年前の1/10以下**。量と質を両立できる時代。 ## 計測すべき指標 | 指標 | 意味 | 目標レンジ | |------|------|---------| | **View / Impression** | 表示回数 | プラットフォーム別 | | **3-sec View Rate** | 3秒以上視聴された率 | >25% | | **Average Watch Time** | 平均視聴時間 | 尺の >50% | | **Completion Rate（視聴完了率）** | 最後まで視聴した率 | Short: >50% / Long: >30% | | **Engagement Rate** | Like + Comment + Share + Save | プラットフォーム別に追う | | **Share Rate / Save Rate** | バイラル係数の先行指標 | 特に重要 | | **Click-through Rate** | 広告でのクリック率 | >1.5%（Meta基準） | | **Cost per View（CPV）** | 1視聴あたりコスト | 尺と比率で評価 | ### TikTok / Reels特有 - **Play Rate**（表示 → 再生） - **Replay Rate**（繰り返し再生） - **For You Page到達率**（TikTok） ## よくある失敗 | 罠 | 実態 | |------|------| | 「プロっぽい映像で撮ろう」 | 素人っぽい方がネイティブ広告として効く | | 「冒頭でブランド紹介」 | 3秒で離脱される | | 「字幕なし、音楽のみ」 | 音なし視聴85%で伝わらない | | 「同じ素材を全プラットフォームにコピペ」 | 各プラットフォームのネイティブ形式に編集すべき | | 「視聴数だけ見る」 | 完了率・Saveが拡散を決める真の指標 | | 「1本の大作」 | 10本のバリエーションで学習するほうが強い | ## 参考文献 - *Jab, Jab, Jab, Right Hook* — Gary Vaynerchuk - *YouTube Secrets* — Sean Cannell - *TikTok for Business* 公式 Creative Codes - Meta Business "Video Best Practices" - YouTube Creator Academy - *クリエイティブエコノミー* — Li Jin（a16z） - Later / Buffer / Hootsuite 年次Social Mediaレポート - TubeBuddy / VidIQ データ ## マーケティングサイクルとの接続 - **Set**: ブランドトーン・NG表現・ICPの利用プラットフォームを `memory/profile/` に書く - **Ask**: 「このトピックのTikTok Hookを10案」「リテンショングラフから学ぶ改善点を分析して」 - **再構築**: 撮影・編集・字幕付け・複数比率書き出し・投稿・広告化 - **Feedback**: Completion Rate・Share Rate・広告CVRを `memory/results/performance-data.md` に記録 --- title: 計測・MarTech chapter: "13" part: 2-knowledge-areas status: revised visibility: public authors: - claude reviewers: [] revision: 0.3 updated: 2026-05-21 related-skills: - /learn related-chapters: - foundations/performance-domains - knowledge-areas/stakeholder - cross-cutting/ai-in-marketing related-knowledge: - knowledge/marketing/playbook/knowledge-areas/measurement-martech/measurement-incrementality.md - knowledge/marketing/playbook/knowledge-areas/measurement-martech/web-analytics-practice.md - knowledge/marketing/playbook/knowledge-areas/measurement-martech/martech-revops.md - knowledge/base/integrations.md - knowledge/marketing/glossary/metrics-glossary.md --- # 計測・MarTech ## 概要と対象範囲 KPI 設計、アトリビューション、計測基盤、MarTech スタック、データ統合、AI / LLM の計測層への組み込みを扱う。マーケ活動の**測定可能性**を担保する基盤層であり、他のすべての KA から参照される。 本章の射程は次の 3 つに分かれる: - **計測設計**: KPI 設計、アトリビューション、Incrementality 測定 - **MarTech / データ基盤**: ツール選定、データ統合、CDP、運用設計 - **AI / LLM の計測活用**: 自動レポート、異常検知、予測モデル 個社製品の比較は [`../../tools/`](../../../tool/) に逃がす。本章は構造的な設計指針を扱う。 ## 業界トレンドと新興手法 - **計測制約への対応**: ブラウザ制限、広告識別子制限、同意要件を前提にした Identity / CV 補完（CAPI、拡張コンバージョン、Consent Mode、SKAdNetwork 等） - **Incrementality 測定**: 因果推論ベースの効果測定（geo-experiment、lift study、MMM） - **CDP / Composable Stack**: モジュール型 MarTech 構成 - **LLM ベース分析**: 自然言語クエリ、自動インサイト生成 - **Reverse ETL**: データ基盤 → MarTech ツールへの双方向統合 - **First-party Data 戦略**: 自社データを中心に据えた計測・配信設計 ## テーラリング | 文脈 | 重点 | |---|---| | **B2B エンタープライズ** | Salesforce / HubSpot 中心、商談接続、長期 attribution | | **B2B SaaS** | プロダクト内行動データ + CRM 統合、PLG メトリクス | | **D2C** | 広告プラットフォーム計測 + CDP + LTV モデル | | **リテール** | POS / EC / 店舗データの統合 | | **規制業種** | プライバシー制約、PII マスキング、同意管理、媒体ポリシー確認 | | **スタートアップ** | 計測の最小セット（北極星指標 + ファネル基本指標） | ## プロセス（マーケティングサイクル × ITTO） ### 観測・データ収集段のプロセス - **投入物**: 既存計測実装、ファネル現状値、データソース、ステークホルダーの計測要求 - **手法と道具**: 計測カバレッジ監査、データソース棚卸し、KPI 整合性チェック - **産出物**: 計測ギャップリスト、データ基盤の現状マップ ### 理解・分析する段のプロセス - **投入物**: 計測ギャップ、戦略目標（05 章）、Performance ベースライン - **手法と道具**: KPI 5 軸評価（仮説チェーン・時間軸・信頼度・検証方法・意思決定使途）、アトリビューションモデル選択 - **産出物**: KPI ツリー、Attribution 設計、必要計測実装リスト ### 再構築段のプロセス - **投入物**: 現行 KPI ダッシュボード、形骸化指標 - **手法と道具**: ダッシュボード KPI 化された指標の機械的列挙（補題 E）、P0–P3 篩 - **産出物**: 廃止 KPI リスト、残す KPI ### 起動・実装する段のプロセス - **投入物**: 新規計測要件、MarTech 導入計画 - **手法と道具**: 計測タグ実装、Consent Mode / CMP 設定、CDP / データパイプライン構築、ダッシュボード構築 - **産出物**: 本番計測、ベースライン記録、運用ドキュメント ### 学ぶ段のプロセス - **投入物**: 計測結果、ダッシュボード活用度 - **手法と道具**: 計測の意思決定接続度評価、Evidence Level 判定 - **産出物**: 計測設計の更新、profile への書き戻し ## タクティカル・プレイブック（L3） ### KPI 5 軸評価 意思決定 KPI として有効と判定するための 5 軸（[`../../foundations/principles.md`](../../foundations/principles.md) 補題 E）: | 軸 | 問い | |---|---| | 仮説チェーン | P0（売上 / 利益）までの因果仮説が描けるか | | 時間軸 | どの時間軸で動くか（即時 / 週次 / 四半期 / 年次） | | 信頼度 | 仮説の確信度（high / mid / low） | | 検証方法 | A/B / holdout / MMM / geo / 自然観測のいずれか | | 意思決定使途 | この KPI が動いたとき / 動かないとき、どの意思決定が起きるか | 5 軸が埋まらない指標はダッシュボード上の数字に過ぎず、意思決定 KPI ではない。 ### leading / lagging KPI のペア運用 短期反応と長期成果を**両方の時間軸**で揃える: - **leading**（短期反応）: CTR / CVR / 指名検索 / NPS / アクティベーション率 - **lagging**（長期成果）: 売上 / LTV / 市場シェア / リテンション leading だけで判断すると長期資産（ブランド資産・カテゴリ想起）が過小評価される。lagging だけで判断すると施策反応の検証ループが回らない。 ペア運用が必要な構造的理由は、成果が非線形に顕在化することにある（[`../../foundations/principles.md`](../../foundations/principles.md) 補題 I）。線形に短期差分だけで判定すると、正しい施策の偽陰性と、間違った施策の偽陽性（「まだ時間が足りない」擁護）が同時に起きる。leading は方向性の早期検出、lagging は累積効果の確認、という役割分担で非線形性を扱う。 ### Incrementality 測定 「広告を打たなかった場合の売上」との差分で効果を測る。手法: - **geo-experiment**: 地域別に配信する / しないを分けて差分測定 - **holdout test**: 一部ユーザーを除外して配信する / しないの差分測定 - **MMM (Marketing Mix Modeling)**: 統計モデルによる予算配分効果の推定 - **plat lift study**: 媒体提供のインクリメンタリティ計測 詳細実装は [`measurement-incrementality.md`](./measurement-incrementality.md) を参照する。 ### MarTech スタック設計 中核 5 領域: | 領域 | 主な役割 | 例 | |---|---|---| | **アナリティクス** | ファネル可視化、行動分析 | GA4、Mixpanel、Amplitude | | **CDP / データ統合** | 顧客データの統一 | Segment、Treasure Data、Rudderstack | | **CRM / SFA** | 商談・顧客管理 | Salesforce、HubSpot | | **マーケティング自動化** | メール、配信、スコアリング | HubSpot、Marketo、Pardot | | **広告 / 配信** | 媒体配信、入札 | Google Ads、Meta、Smartnews | 新規スタック導入時のチェック: データの双方向統合可能か、API 公開度、価格モデル、ベンダーロックインリスク。ツール連携の詳細は [`integrations.md`](../../../../base/integrations.md) を参照する。 ### 異常検知とアラート設計 - **静的閾値**: 「CV が前週比 −20%」のような単純ルール - **動的閾値**: 季節性・トレンドを考慮した統計モデル - **AI ベース**: LLM による異常パターンの自然言語説明 アラートは「人が判断すべき場面」だけに絞る。アラート疲れは alert の無視を生む。 ## アンチパターン - **ダッシュボード KPI 化**: 5 軸が埋まらない指標を「KPI」と呼ぶ（補題 E 違反） - **leading 偏重**: 短期 ROAS / CVR だけで判断し、長期資産を毀損 - **計測実装の後付け**: 起動・実装する時に計測タグを実装し忘れ、本番反映後に検証不能 - **ベンダー言いなり**: MarTech 導入を媒体担当者主導で決め、データ統合性を考えない - **アトリビューション神話**: Last Click だけで判断し、複雑な購買経路を無視 - **データ統合の自己目的化**: 全データを統合するが、意思決定には使われない - **異常検知のアラート疲れ**: 通知が多すぎて重要なものが埋もれる - **個人情報の野放し**: 計測のために PII を収集し、削除ポリシーがない ## 関連 skill / agent - **`/learn`** — 結果の 4 軸整理と Evidence Level 判定 - **`/listen market`** — プラットフォーム仕様の継続取得 ## 今後の拡張論点 - **「計測」と「MarTech」を 1 章で扱う妥当性** — 射程が広く、分割の検討（13A 計測、13B MarTech）も選択肢 - **Incrementality 測定の必須度** — 全業種の標準扱いにするか、規模により省略可とするか - **個社製品の比較範囲** — `knowledge/marketing/tool/` への分離方針で実用に足りるか - **AI ベース分析の Evidence Level** — LLM 生成インサイトをどの Level として扱うか - **First-party Data 戦略の扱い** — 戦略レイヤー（05 章）と本章の境界 --- title: "マーケティングテクノロジー・収益運用" chapter: "13" part: 2-knowledge-areas status: revised visibility: public authors: - claude reviewers: [] revision: 0.1 updated: 2026-05-19 related-skills: [] related-chapters: [] related-knowledge: [] --- # マーケティングテクノロジー・収益運用 現代マーケティングは**データとツールの総体**で動く。 ツール選定・データ統合・運用体制がボトルネックになれば、どんな戦略も失敗する。 **MarTech**はマーケ単体のツールスタック、**RevOps**はマーケ・営業・CS を**共通のオペレーションで統一**する組織/技術戦略。 ## MarTechスタックの全体像 ``` ┌────────────────── Experience Layer ──────────────────┐ │ Web / App / Email / Ads / Chat / SNS / Events │ └───────────────────────────────────────────────────────┘ ↕ ┌────────────────── Orchestration Layer ───────────────┐ │ Marketing Automation / CDP / CRM / Chatbot │ └───────────────────────────────────────────────────────┘ ↕ ┌────────────────── Data Layer ────────────────────────┐ │ Data Warehouse / CDP / Customer Data Database │ │ Reverse ETL / Data Clean Room │ └───────────────────────────────────────────────────────┘ ↕ ┌────────────────── Infrastructure Layer ──────────────┐ │ Consent / Identity / Analytics / BI / AI │ └───────────────────────────────────────────────────────┘ ``` **Scott Brinker (chiefmartec.com)** によると、2024年時点でMarTechソリューションは **14,000+ 社**。全て使うのは不可能で、**スタック設計**が核心。 ## 代表的なツール分類と選択肢 ### CRM（顧客情報の中心） - **HubSpot** — SMB〜中堅、マーケ・営業・CS統合 - **Salesforce** — 中堅〜Enterprise、拡張性最強 - **Pipedrive** — 小規模営業組織 - **Zoho / Freshsales** — コスパ志向 - **Attio** — 新世代、API-First ### Marketing Automation（MA） - **HubSpot / Marketo / Pardot** — B2B王道 - **Customer.io / Braze / Iterable** — 行動ベースライフサイクル - **Klaviyo** — EC特化 - **ActiveCampaign / Mailchimp** — 中小企業 - **Ortoo / SATORI / b→dash** — 国内B2B ### Customer Data Platform（CDP） - **Segment（Twilio）** — デベロッパー向け、イベント収集 - **mParticle** — モバイル強い - **Treasure Data** — 日本国内・Enterprise - **RudderStack** — OSS / Warehouse-Native - **Hightouch / Census（Reverse ETL）** — Warehouse-Nativeアプローチ ### Data Warehouse - **Snowflake** — マルチクラウド対応、Clean Room - **BigQuery** — Google広告と親和性、GA4連携 - **Redshift** — AWS環境 - **Databricks** — ML / データサイエンス統合 ### Analytics / BI - **GA4** — Webアクセス解析、Free - **Amplitude / Mixpanel** — プロダクト分析 - **Looker / Tableau / Power BI** — BI汎用 - **Hex / Omni / Mode** — 新世代BI、SQL+Notebook ### Ads Management - **Google Ads / Meta Ads Manager** — 直接 - **Skai / Madgicx / Trapica** — マルチチャネル管理 - **Smartly / Pencil** — Creative Automation ### SEO - **Ahrefs / SEMrush / Sistrix** — 被リンク・競合分析 - **Screaming Frog** — テクニカルSEO - **Search Console / Bing Webmaster** — 公式 ### Email - **Postmark / SendGrid / Mailgun** — Transactional - **Customer.io / Braze / Klaviyo** — マーケ用（上記MA重複） ### Landing Page / CMS - **Webflow / Framer** — デザイン×コード - **WordPress** — 汎用 - **Unbounce / Instapage** — LP特化 - **Studio / STUDIO** — 日本国内 ### Chat / Conversational - **Intercom / Drift / Front** — 会話型マーケ - **Zendesk** — サポート統合 - **ChatPlus / KARTE** — 日本国内 ## Composable MarTech — 合成可能なスタック 従来：**Suite Marketing Platform**（Salesforce / HubSpot が全部提供） 現在：**Best-of-Breed Composable Stack**（個別最高を組み合わせる） ### Composableの前提 - **Data Warehouse中心設計**（Snowflake / BigQueryがSSOT） - **Reverse ETL**でWarehouse → 各ツールへデータ送信（Hightouch / Census） - **API / Webhook前提**のツール選定 - 個別ツールの置き換えコストが低い ### メリット - ベストオブブリード選択 - ベンダーロックイン回避 - 機能アップデート速度が早い ### デメリット - 統合・運用コスト増 - データモデリング・ガバナンスが必須 - 人材の専門性依存 ## Reverse ETL — 現代MarTechの核心 **Data Warehouse → SaaSツール**へデータを戻す仕組み。 ``` 従来ETL: SaaS → Warehouse（分析用） Reverse ETL: Warehouse → SaaS（運用用） ``` ### ユースケース - BigQueryの**セグメント定義 → Metaカスタムオーディエンス** - Snowflakeの**解約予兆モデル → Customer.io のWin-Backメール** - WarehouseのLTV計算 → Salesforceに戻し営業優先度に反映 - 複数ソースの購買履歴 → 広告配信除外リスト **Single Source of Truth（SSOT）**がWarehouseで実現する鍵。 ## Identity Resolution — 顧客統合 同一人物が複数デバイス・複数チャネルでどう繋がるかを解決する。 ### 手法 - **Deterministic（決定論的）** — ログインID・メール・電話番号でマッチ - **Probabilistic（確率論的）** — デバイス情報・行動パターンで推定（精度低） - **Clean Room** — プライバシー保護下での突合 ### クッキーレス時代のIdentity - **UID 2.0 / ID5 / RampID** — 広告業界の共通IDソリューション - **Customer 360** — 自社で統合するCDP機能 - **Google Privacy Sandbox** — Chromeネイティブ ## Consent Management Platform（CMP） GDPR / CCPA / 改正個人情報保護法対応： - **OneTrust** — Enterprise標準 - **Cookiebot / Usercentrics** — 欧州系 - **Trustarc** — 北米系 - **PrivacyTools / Axeptio / CustomerIO Consent** — 新興 **Consent-Mode**（Google）でConsent状態に応じて計測方式を変える実装が標準化。 ## RevOps（Revenue Operations）とは **Marketing / Sales / Customer Success の3部門を統合した運用組織・システム**。 ### 背景 - 従来：各部門が**別々のツール・別々のKPI・別々のレポーティング**で運用 - 問題：リードの受け渡し遅延、二重計上、戦略の不整合、Customer Journey分断 - RevOpsで**一つの収益パイプラインとして全段階を設計** ### RevOpsの責務 1. **Tech Stack Consolidation** — 重複ツール整理、統合設計 2. **Data Governance** — ソースの真実、定義統一 3. **Process Design** — リード受け渡し、Deal Review、Forecast 4. **Analytics / Insights** — 統合ダッシュボード、Funnel Conversion 5. **Enablement** — ツール教育、プロセス変更支援 ### RevOps組織モデル - **Centralized（中央集権）** — 独立部門が全体設計 - **Embedded（埋込）** — 各部門内にOpsメンバー - **Hybrid** — 中央戦略＋各部門実行 **従業員50〜200名規模で専任化**されることが多い。 ## KPIの統合定義 RevOps導入で最初に揉めるのは**用語と定義**。 | 指標 | マーケ定義 | 営業定義 | RevOps統一定義 | |------|----------|---------|---------------| | **Qualified Lead** | Form入力者 | Call成立者 | 明文化する | | **Pipeline** | 見込み売上 | 確度70%+ | Stage定義で明文化 | | **Churn** | 月次解約 | 契約未更新 | Gross/Net, Logo/Revenue分離 | | **CAC** | マーケ支出/新規 | マーケ＋セールス/新規 | Fully Loaded CAC | ## Data Governance — データガバナンス ### 必須の整備項目 1. **Schema Design** — イベント命名、プロパティ定義 2. **Tracking Plan** — 何を計測するかの設計書 3. **Data Dictionary** — 全指標の定義集 4. **責任者** — 各データの責任者 5. **Quality Monitoring** — データ欠損・異常検知（Monte Carlo / Datafold） ### Tracking Plan例 ``` Event Name: signup_completed Properties: - user_id (string, required) - plan (enum: free|pro|enterprise, required) - signup_method (enum: email|google|sso, required) - utm_source, utm_medium, utm_campaign (string, optional) - referrer (string, optional) - timestamp (ISO8601, required) ``` **命名規則・命令形/過去形・スネークケース統一**などを最初に決める。後で変更すると全歴史データが不整合になる。 ## AIマーケティング層（2025〜） MarTechの新層として**AI Automation**が台頭： - **AI Copy / Content**: Jasper / Copy.ai / Writer / Claude / ChatGPT - **AI Video**: Runway / HeyGen / Synthesia / Veo / Sora - **AI Voice**: ElevenLabs / Descript - **AI Image**: Midjourney / Flux / Stable Diffusion / Adobe Firefly - **AI Customer Service**: Ada / Intercom Fin / Decagon - **AI SDR**: 11x.ai / Regie.ai / Clay - **AI Analyst**: Hex Magic / Julius / ThoughtSpot Sage - **Agent Framework / Workflow**: Claude Agent SDK / LangChain / n8n / Zapier **Marketing OSもこの層に位置する。** AIが各機能を横断して"オペレーションの接着剤"になる。 ## ツール選定の原則 1. **Jobs to be Doneで選ぶ** — 機能リストではなく、解決したい仕事 2. **既存スタックとの統合可能性** — API / Webhook / ネイティブ連携 3. **データの所有権** — 退出時にエクスポートできるか 4. **Time to Value** — 導入から価値出まで（90日が目安） 5. **TCO（総保有コスト）** — ライセンス＋実装＋運用＋教育 6. **ベンダーのロードマップ** — 今後3年生存できるか 7. **コミュニティ・エコシステム** — SI / 代理店 / 外部エキスパート人材 ## スタック肥大化の罠 - ツール導入はほぼ全て**採択より廃止が難しい** - 年に一度は**スタック監査**（使用率、重複、ROI）を実施 - 「使ってない機能の80%」で年間数百万〜数億円のムダが発生 - **Shadow IT**（各チームが勝手に導入するSaaS）の管理 ### Consolidation（統合）のトレンド - 2020年代前半：Best-of-Breed万能 - 2020年代後半：コスト圧縮 → Suite回帰の流れ（HubSpot・Salesforceの拡大） - AI統合で**中堅ツールがAI機能で一気に機能拡大**（競争激化） ## 参考文献 - *Hacking Marketing* — Scott Brinker（MarTech論の古典） - *Marketing Technology Landscape* — chiefmartec.com 年次 - *The Revenue Acceleration Rules* — Seth Marrs & Craig Rosenberg - *Composable CDP* — Hightouch ホワイトペーパー - *Revenue Operations* — Stephen Diorio & Chris Hummel - Gartner Magic Quadrant: MA / CRM / CDP - Forrester Wave: RevOps - MarTech.org / Chief Martec ブログ - Reforge: "Marketing Architecture" コース ## マーケティングサイクルとの接続 - **Set**: 現状のツールスタック、データソース、データ定義、既知のデータギャップを `memory/profile/` に書く - **Ask**: 「このスタックで重複・ギャップを洗い出して」「Reverse ETLで接続すべきデータセットは？」 - **再構築**: ツール選定・導入・データモデリング・Tracking Plan実装・ダッシュボード構築 - **Feedback**: データ品質スコア、ツールROI、Time to Insightを `knowledge/marketing/tool/` に記録 --- title: "計測・インクリメンタリティ" chapter: "13" part: 2-knowledge-areas status: revised visibility: public authors: - claude reviewers: [] revision: 0.2 updated: 2026-05-21 related-skills: [] related-chapters: [] related-knowledge: [] --- # 計測・インクリメンタリティ 「ROASが3.0ある」— それは本当に広告が売った結果か、**広告がなくても起きた売上**ではないか？ **Attribution（誰が売ったか）** と **Incrementality（広告のおかげでどれだけ増えたか）** は別物。 ブラウザ制限、広告識別子の制限、同意要件の強化により、アトリビューションの仮定は崩れ、**因果推論的な計測**が必須になっている。 ## アトリビューションの限界 従来のアトリビューションモデル： | モデル | 考え方 | 問題点 | |--------|-------|--------| | **Last Click** | 最後のクリックに全振り | 初期接点を過小評価 | | **First Click** | 最初のクリックに全振り | 刈り取り段階を過小評価 | | **Linear** | 全接点に均等配分 | 重要度を反映しない | | **Time Decay** | 直前接点ほど重く | 理論的根拠が薄い | | **Position Based** | 最初と最後を重く | 任意の重み付け | | **Data-Driven（GA4）** | 機械学習で推定 | ブラックボックス、計測漏れに弱い | **根本問題**：アトリビューションは「広告Aと広告Bのどちらがより寄与したか」は議論できても、 **「そもそも広告Aがなかったら売上はどうなっていたか」**という**反事実（Counterfactual）**を測れない。 ## 計測制約ショック ### 何が起きているか - **Safari ITP**（2017〜）— 3rd Party Cookieほぼ全滅、1st Party Cookieも7日制限 - **iOS 14.5 ATT**（2021〜）— Metaが$10B売上影響と公表 - **Chrome の方針変更** — 3rd Party Cookie の一律廃止ではなく、ユーザー選択と既存設定を維持する方向に変更 - **GDPR / CCPA / 改正個人情報保護法** — 同意ベースへ - **Apple Mail Privacy Protection** — メール開封率が虚構化 ### 結果 - ユーザー単位のクロスデバイス追跡が崩壊 - Meta / Google広告の最適化が劣化 - コンバージョン計測漏れ 10〜40% ### 対応策 - **Server-Side Tagging**（sGTM） — ブラウザでなくサーバー経由で計測 - **Meta Conversions API（CAPI）** — Meta にサーバーサイドでイベント送信 - **拡張コンバージョン**（Google） — 同意取得済みのファーストパーティデータをハッシュ化して補完 - **Consent Mode / CMP** — 同意状態に応じて Google タグの挙動を制御 - **Modeled Conversions** — 計測漏れをML推定で補完 - **Data Clean Room** — プライバシー保護下でのデータ突合（AWS Clean Room / Google Ads Data Hub / Meta Advanced Analytics） サーバーサイド計測や拡張コンバージョンは、同意取得や媒体ポリシーを回避する仕組みではない。送信するデータ、同意状態、ハッシュ化、データ保持、地域別規制を確認したうえで実装する。 ## Incrementality Testing — 増分効果の測定 **因果推論的アプローチ**で「広告のおかげで増えた分」を測る。 ### ① Conversion Lift / Holdout Test ``` Test群 ─ 広告配信 ─→ CV率 X% Control群 ─ 非配信 ─→ CV率 Y% Lift = X - Y = 増分 ``` - Meta/Googleが公式機能として提供（Conversion Lift Study） - 2〜4週間、一定予算が必要（$50K〜） - 最もピュアな因果測定 ### ② Geo Lift Test（地理分割） 全ユーザーをHoldoutせず、**地域単位**で分割： - Test地域（例: 関東）で広告ON - Control地域（例: 関西）でOFF - 売上差分から増分を推定 - プラットフォーム非依存（TV / OOH / PR も測定可） - 難易度: 地域の類似性、季節性調整（**Synthetic Control法**） - ツール: Meta Robyn GeoLift、Google Meridian、Recast ### ③ Matched Market Test 類似市場ペアを作り、片方で施策実施。伝統的TV広告測定の派生。 ### ④ Interrupted Time Series / Switchback 同じ地域で**時期をずらしてON/OFF**を繰り返す。 （例: 奇数週ON / 偶数週OFF） ## Marketing Mix Modeling（MMM）の復権 - **ユーザー単位の計測に頼らない統計モデル** - 売上 = f(チャネル別支出, 季節性, 外部要因, トレンド) - 回帰分析で各チャネルの貢献度を推定 - **1st Party Data不要 / Cookieless耐性あり** ### オープンソースMMMの登場 クッキーレスでGAFAがMMMを一般開放した： - **Meta Robyn**（R / Python）— 2021年公開 - **Google Meridian**（Python、2024年公開）— 後継。TensorFlow Probability使用 - **LightweightMMM**（Google、Bayesian MMM） ### MMMの強みと弱み | ○ Pros | ✕ Cons | |--------|--------| | Cookieless耐性 | 過去データ2年以上必要 | | 全チャネル統合（TV / デジタル / OOH / PR） | モデラーのスキル依存 | | 飽和曲線（Adstock / Saturation）を考慮 | 短期の個別最適には弱い | | 因果的解釈がしやすい | 新規チャネルの推定が弱い | ### MMM + インクリメンタリティ + アトリビューション = 統合計測 最新トレンド：3層を組み合わせる ``` MMM ─ 戦略レベル（予算配分） Incrementality Testing ─ 戦術レベル（個別施策検証） Attribution / Last Click ─ 運用レベル（日々の最適化） ``` ## Brand Lift Study — ブランド指標の測定 認知・好意度・購入意向は**売上に出る前に動く**。 ### 測定手法 - **Meta / Google Brand Lift Survey** — 広告配信ユーザーへのアンケート - **独自パネル調査**（Nielsen / Kantar / ネオマーケティング等） - **指名検索量（Google Trends / Search Console）** - **SOV（Share of Voice）/ SOM（Share of Market）** ### ベンチマーク（Binet & Field） **ブランディング：刈り取り = 60:40** が長期ROI最大化の黄金比。 ## Data Clean Room — プライバシー時代の突合基盤 - 広告主 × プラットフォームのデータを**個人特定せず**に突合 - 1st Party DataをCookieなしで活用 - 代表例: Google Ads Data Hub、Meta Advanced Analytics、Amazon Marketing Cloud、AWS Clean Room、Snowflake Clean Room ### ユースケース - 広告接触者 × 自社CRMでLTV分析 - 未CV接触者のクロスチャネル動向 - 顧客セグメント別のCPAリアル測定 ## 実務での計測スタック（2026年現在の推奨） ``` ガバナンス層: ├ CDP（Segment / Treasure Data） ├ Data Warehouse（Snowflake / BigQuery） └ Reverse ETL（Hightouch / Census） 計測層: ├ Server-Side GTM + Meta Conversions API ├ 拡張コンバージョン └ Consent Management Platform（OneTrust等） 分析層: ├ MMM（Meridian / Robyn） ├ Incrementality（GeoLift / Conversion Lift） ├ Attribution（GA4 / Adobe Data-Driven） └ BI（Looker / Tableau） ``` ## ダッシュボード設計の原則 1. **指標は"意思決定"につながるものだけ** — 見る指標 > 飾る指標 2. **Leading（先行）とLagging（遅行）を分ける** — CPC/CTR（先行）とLTV/NRR（遅行） 3. **North Star Metric → Key Driver → Operational** の3層構造 4. **比較対象を必ず付ける** — 前週比 / 前年比 / 目標比 5. **Segment別に見る** — 全体の平均は嘘をつく ## よくある計測の誤り | 誤り | 実態 | |------|------| | 「Last ClickでROAS 3.0」 | Last Clickは貢献度を歪める | | 「Facebookの効果が落ちた」 | iOS 14.5以降の計測漏れの可能性 | | 「SEOでCV増えた」 | ブランド広告の波及効果の可能性 | | 「ブランド広告は測れないから止める」 | 長期では指名検索・NRRが下がる | | 「全部Incrementality Testingで測る」 | コストと期間で現実的でない、MMMと併用 | | 「ダッシュボードで自動化」 | **数字の解釈**こそ人間の仕事 | ## 参考文献 - *Hacking Growth* — Sean Ellis（計測章） - *The Long and the Short of It* — Les Binet & Peter Field - *How Brands Grow* — Byron Sharp - Meta Robyn公式ドキュメント / Google Meridian公式 - Recast "Incrementality Testing" ブログシリーズ - Analytic Edge / Analytics Demystified - Measured.com / Haus / INCRMNTAL（Incrementality SaaS）ブログ - Avinash Kaushik *Web Analytics 2.0* - IAB / MMA 公式ガイドライン ## マーケティングサイクルとの接続 - **Set**: 現状の計測スタック、主要KPIツリー、計測の既知の穴を `memory/profile/` に書く - **Ask**: 「このチャネルでIncrementality Testを設計して」「このMMM結果を解釈して」 - **再構築**: GeoLift実装、Conversion Lift発注、MMMモデル構築、ダッシュボード改修 - **Feedback**: Test結果から得た「真のROAS / 増分係数」を `memory/results/performance-data.md` に記録、予算配分の根拠に --- title: "ウェブ解析実務" chapter: "13" part: 2-knowledge-areas status: revised visibility: public authors: - claude reviewers: [] revision: 0.1 updated: 2026-05-19 related-skills: [] related-chapters: [] related-knowledge: [] --- # ウェブ解析実務 ## データ民主主義 Optimizely創業者ダン・シロカーの言葉。完全な計画は逆効果であり、必要なのはデータであり、データ分析。 自分たちの直感に反する結果を受け入れ、とにかくテストするという文化を作ることが重要。 ### A/Bテストの事例 - **オバマ大統領選挙**: ボタンテキストのA/Bテスト結果、「LEARN MORE」が最も高いCVR。画像との組み合わせで11.6%のサインアップ率向上、元の8.6%と比べて40.6%も上昇 - **Amazon「衝動買い」機能**: 社内で相手にされなかったエンジニアがA/Bテストを実施 → 明らかにAmazonの収益を向上させるものだった。**たった1人の開発者が行った結果が、あらゆる上司のマネジメントを不要にしてしまう可能性がある** ### 勘はあてにならない ダニエル・カーネマン『ファスト＆スロー』: 私たちは一見重要そうな物事に飛びつき、それが本質的に重要であるかについては思いをめぐらさないことが多い。マーケティングの世界でも、私たちは驚くほど顧客のことを知らない（そして顧客自身も自分のことを理解しているわけではない）。 ## 正しいデータを選択する **「選手を買うのではなく勝利を買う」**（映画『マネー・ボール』）。 分析において最も重要なのは「どのような結果が出るか」ではなく「何を分析すべきなのか？」ということ。直感的に正しいことが統計的に正しいとは限らない。 ### KPIの設定 **どのポイントにKPIを置くか**が分析においてもっとも重要なポイント。最終的に購入するかどうかをKPIに置いた場合、それ以外の数値はあくまで目標達成のための1つの要素に過ぎない。単純なアクセス数で広告の成果を測ってしまえば大失敗する。 ### LTVで計測する 広告の効果は一度だけで終わるものではない。一度来た顧客が再度来店したり、ファンになる可能性がある。 例: 飲食店が30万円で広告出稿 → 50人来店 × 顧客単価5,000円 = 25万円（赤字に見える） → しかし生涯平均1.5回来店 → LTV = 5,000円 × 1.5 = 7,500円 → 獲得価値 = 37.5万円、ROI = 125% ### フリークエンシー（購入頻度）分析 購入回数ごとの転換率を確認してボトルネックを特定する。 特に重要なのはF2（購入2回目の）転換率。一般的に、2回目に購入した顧客はそれ以降も購入する可能性が高い。1人あたりの購入回数が増えていけば、顧客のLTVは劇的に増加する。 ### どの指標にポテンシャルがあるかを考える 獲得顧客数・1人あたりの顧客単価・来店回数のうち、どれがもっとも上げやすいか？ **競合と比較したとき、あるいはビジネスモデルを検討したとき、どの指標にポテンシャルがあるか？（競合と比べて低く、まだ上げられるのか？）を考えることが重要。** ### 数値を細かくする（チャンクダウン） コンバージョン単価が悪化した場合、指標を分解して原因を特定する: ``` コンバージョン単価 → 費用 → コンバージョン数 → クリック数 → クリック単価 → コンバージョン率 ``` 問題を細かく分解していくことで、原因を特定することが可能になる。 ## 分析の本質 分析とは、大きなくくりのデータを詳細に見て知見を発見すること。 - 全ユーザーを個別に見ても分からない - 全部を平均化しても何も見えない - **どのように分けるのが適切かを判断するのがWeb分析** ## セグメント分析の軸 ### 時間帯別分析 - 午前と午後でどう変わるか - 朝は何時から、夜は何時まで一定のユーザーがいるか - 通勤通学のユーザーはいるか - スマートフォンとPCで時間帯の差はあるか ### 曜日別分析 - BtoBは月曜日のCVが多く、土日にがくんと落ちることが多い - 週明け月曜・金曜などにCVが増えているか - 土日のユーザー減少幅はどの程度か ### 月初・月末比較 - BtoBは月初月末で変化がある - 月ごとに精算するサービスは顕著に変化が出る - CVRの変化も合わせて確認する ### 性別分析 - BtoCでは顕著な差が出ることが多い - 男女でボリュームの差、行動の差を確認 - 年齢と掛け合わせるとさらに解像度が上がる ### 年齢別分析 - 実際にCVしている年代はどこか - 決裁権者の年齢が高いケースもある - 若年層はスマートフォン率が高い傾向 ### 地域別分析 - 三大都市圏（東京・大阪・名古屋）の比率 - CVが多い特定の地域はあるか - 都市部のみ売上が上がるサービスもある ## 集客チャネル分析 ### チェックポイント - 検索からの流入（安定した流入）はどの程度か - ノーリファラー（直接流入）はどの程度か - 有料の流入と無料の流入の割合は - 突然トラフィックが増えたとき、どの流入が多いか ### 参照元/メディア分析 - 検索エンジン別（Google/Organic、Yahoo/Organic等） - どのようなサイトから来ているか - 検索キーワードはGoogle Search Consoleで確認 ## ページ別分析 ### チェックポイント - 特定のページで離脱率が上がっていないか - トップページと下部ページで差はあるか - **直帰率と離脱率の違い**を理解する - 直帰率: 最初のページだけ見て離脱した割合 - 離脱率: そのページを最後に離脱した割合 ### サイト速度 - 2.5秒以上は「遅い」 - 1.5秒以内を目標にする - 特定の時間帯に負荷がかかっていないか確認 - PageSpeed Insightsも合わせてチェック ## セグメント比較 ### 直帰 vs 非直帰セッション - 集客チャネルの割合に差はあるか - 新規/リピーターの差はあるか - 遷移パスの違いを確認 - ※滞在時間は仕様上、直帰セッションでは測れない ### 新規ユーザー vs リピーター - リピーターが離脱するページ = そこで満足している可能性 - それぞれのランディングページに違いはあるか - よく見るページのトップ3に違いはあるか --- title: 組織・能力 chapter: "14" part: 2-knowledge-areas status: revised visibility: public authors: - claude reviewers: [] revision: 0.2 updated: 2026-05-19 related-skills: [] related-chapters: - knowledge-areas/stakeholder - cross-cutting/ai-in-marketing - cross-cutting/org-learning related-knowledge: - knowledge/marketing/playbook/knowledge-areas/org-capability/learning-organization.md - knowledge/marketing/playbook/knowledge-areas/org-capability/responsibility-design.md - knowledge/base/skills-vs-agents.md --- # 組織・能力 ## 概要と対象範囲 マーケティング組織そのものの**編成・能力・運用設計**を扱う。チームの構造、役割、スキルマップ、AI 時代の分業、新陳代謝の仕組みが本章の射程である。 15 章（ステークホルダー連携）が「他部門との接面」を扱うのに対し、本章は**内部組織**を扱う。両章はセットで読まれることを前提とする。 Marketing OS の独自貢献は、**AI / agent を含めた分業を「組織能力」の一部として明示的に設計する**点にある。AI 委譲は人員削減ではなく、組織能力の再配置として扱う。 ## 業界トレンドと新興手法 - **AI ネイティブ組織**: AI / agent を前提に組織を再設計する流れ - **T 字型 + AI 増幅**: 専門深さ × 横断幅に加え、AI 活用度を能力軸に加える - **Marketing Ops の中心化**: ツール・データ・プロセス設計を担う専門職の台頭 - **Fractional CMO**: 複数企業を兼任する CMO 形態の普及 - **Revenue チーム化**: Marketing / Sales / CS を「収益チーム」として統合 ## テーラリング | 文脈 | 重点 | |---|---| | **B2B エンタープライズ** | 専門職分業、Marketing Ops の独立配置、明示的な RACI | | **B2B SaaS** | Product Marketing の独立配置、Demand と Brand の二極化 | | **D2C** | Brand と Performance の統合、クリエイティブ内製化 | | **スタートアップ** | 役割兼任、AI 委譲比率高、新陳代謝速度速い | | **大企業** | 階層深く、新陳代謝が遅い。属人化解消が中心課題 | ## プロセス（マーケティングサイクル × ITTO） ### 観測・データ収集段のプロセス - **投入物**: メンバー自己評価、能力ギャップ、退職リスク、新陳代謝指標 - **手法と道具**: スキルマップ、属人化検出（半年ごとの引き継ぎテスト）、Team Sync - **産出物**: 能力ギャップリスト、属人化リスト ### 理解・分析する段のプロセス - **投入物**: 観測・データ収集の能力ギャップ、戦略目標（05 章） - **手法と道具**: 役割再設計、AI 委譲境界の判定、外注 vs 内製の判定 - **産出物**: 役割マップ、AI / 外注 / 内製の分業設計 ### 再構築段のプロセス - **投入物**: 現行役割、固定化した分業 - **手法と道具**: 役割固定の機械的列挙、新陳代謝阻害要因の特定 - **産出物**: 役割の再構築決定、組織再設計の余白 ### 起動・実装する段のプロセス - **投入物**: 新役割設計、採用・配置計画 - **手法と道具**: 採用、配置転換、AI 委譲の本番反映、引き継ぎ - **産出物**: 組織変更、引き継ぎログ、新役割の運用開始 ### 学ぶ段のプロセス - **投入物**: 組織変更後のパフォーマンス、能力ギャップの変化 - **手法と道具**: 役割効果の検証、Learning Velocity 測定 - **産出物**: 役割設計の更新、profile への書き戻し ## タクティカル・プレイブック（L3） ### 役割編成の基本パターン | 役割 | 主な責務 | 連携 | |---|---|---| | **CMO** | 戦略整合、再構築意思決定、対経営 | 全役割 | | **Brand リーダー** | Brand & Narrative、ガイドライン | Product Marketing、PR | | **Demand リーダー** | パイプライン、リード品質 | Sales、Data | | **Product Marketing** | JTBD、launch、メッセージング | Product、Sales | | **Content / Channel** | コンテンツ制作、チャネル運用 | Brand、Demand | | **Marketing Ops** | MarTech、データ、プロセス設計 | Engineering、Data、Finance | | **Analyst** | 計測、アトリビューション、レポート | Data、CMO | スタートアップでは複数役割を 1 人が兼任、エンタープライズでは各役割にチーム配置。 ### AI / 外注 / 内製の分業判定 | 判定軸 | AI 委譲 | 外注 | 内製 | |---|---|---|---| | **判断責任** | × | 限定的 | ○（戦略・最終判断） | | **専門深さ** | 中 | ○（一時的） | ○（中長期） | | **再現性** | ○ | △ | ○ | | **コスト** | 低 | 中〜高 | 高（固定費） | | **学習の組織蓄積** | ログのみ | △ | ○ | 戦略判断・再構築は内製、ルーチン実行は AI、一時的な専門性は外注、というのが基本配分（[`../../foundations/principles.md`](../../foundations/principles.md) 補題 F）。 ### 新陳代謝の運用 - **半年ごとの引き継ぎテスト**: 「この役割を別の担当者に渡せるか」を点検 - **属人化検出**: Slack DM で完結している判断、文書化されていない暗黙知のリスト化 - **役割固定の機械的見直し**: 再構築段で「同じ人が同じ役割を何サイクル担当しているか」を可視化 ### スキルマップの運用 スキル軸は最低限以下を含む: - **戦略**: ICP / Positioning / カテゴリ設計 - **コンテンツ**: 編集 / コピー / クリエイティブ判断 - **チャネル**: SEO / 広告 / メール / SNS / コミュニティ - **計測**: KPI 設計 / アトリビューション / 分析 - **オペレーション**: MarTech / プロセス設計 / プロジェクトマネジメント - **AI 活用**: プロンプト設計 / 採否判定 / agent 運用 各スキルに 3 段階（基礎 / 実行可能 / 教えられる）で自己評価と他者評価をマッピング。 ## アンチパターン - **役割の固定化**: 同じ人が同じ役割を何サイクルも担当し続ける - **属人化の放置**: 担当者の頭の中にだけある知見を組織知に分離するインセンティブが働かない - **AI 委譲を人員削減と誤認**: 能力再配置ではなく削減として扱い、判断経験の蓄積が止まる - **スキルマップの形骸化**: 評価のためだけのマップ。能力開発計画に接続しない - **外注依存**: 一時的な専門性のはずが、長期固定化して内製能力が空洞化する（補題 F 違反） - **「経験者を採用すれば解決」病**: 採用で解決しようとし、組織設計を変えない - **Marketing Ops 不在**: ツール・データ・プロセスを兼任で回し、専門職を置かない（成熟度の伸び悩み要因） ## 関連 skill / agent - **`/listen team-org`** — 組織全体の認識整理 - **`/insight ceo`** — 経営視点での組織評価 - **`/insight gemba`** — 現場視点での組織課題の検出 ## 今後の拡張論点 - **14 章と 15 章の境界** — 「内部組織」と「他部門との接面」の境界。役割が他部門との接面を担う場合の所在 - **AI 委譲境界の標準化** — §14.5.2 の判定表は普遍化できるか、業種別に変動が大きいか - **スキルマップの粒度** — 6 軸 × 3 段階で十分か、より細かい標準が必要か - **Fractional CMO の扱い** — 外部 CMO は外注（補題 F）の枠組みで扱えるか、独立した役割形態として立てるか --- title: "学習する組織" chapter: "14" part: 2-knowledge-areas status: revised visibility: public authors: - claude reviewers: [] revision: 0.1 updated: 2026-05-19 related-skills: [] related-chapters: [] related-knowledge: [] --- # 学習する組織 — マーケティング・チームに学習プロセスを埋め込む ## なぜこのドキュメントを置くか `marketing-structural-issues.md` で記述したとおり、マーケティングは構造的に「学習しないチーム」を生みやすい。マーケティングサイクルは単なる AI 協働の型ではなく、**組織学習を回すための OS** である。本書では、学習を組織に埋め込むための原則と実装上のヒントを記録する。 ## 学習が起きない条件 以下が一つでも成立すると、組織学習は起きにくい: - **前提が共有されていない**: 「マーケティング」「成果」「顧客」をチームが別の意味で使っている状態。個々のメンバーが「自分は事業のどの課題に効いているか」を答えられない状態。この状態では、振り返りも学びも全員が違うものを指しているため積み上がらない（詳細 `marketing-structural-issues.md` Section 0） - **失敗が許容されない**: 失敗 = 評価への直接的な打撃。試すこと自体が抑制される - **失敗の責任が個人化される**: 失敗から得た学びが組織知ではなく個人の汚点になる - **成功の理由が言語化されない**: 成功した理由を構造化しないため、再現できない - **新陳代謝がない**: 同じ人間が同じやり方で同じ判断をし続ける - **外部化で学習機会を失う**: 「とりあえず外注」が組織内の判断経験を空洞化させる ## 学習が起きる条件 逆に、以下が揃うと組織学習は回り始める: - **失敗できる小さな空間がある**: ロジックも予算も小さく、失敗してもプロダクト全体を毀損しない場が常設されている - **失敗が組織知に変換される**: 失敗の理由・経緯・学びが `memory/workspaces/active/results/` のような構造化された場に書き戻される - **成功も同じ粒度で言語化される**: 成功体験が暗黙知に閉じず、再現条件が記述される - **新陳代謝が前提になっている**: 担当者の入れ替わりを前提に、引き継げる形で知見が残されている - **判断と責任が外部化されない**: AI も外部業者も「判断の補助」として使い、最終判断は組織内に残す ## AI 時代の新しい責任外部化に抗う 2026 年以降、組織は新しい形の責任外部化に直面する。 > 「AI が言っているから、この施策を打ちました」 このフレーズが日常化するとき、判断はチームの誰の手にも残らない。これまでは個人の判断によってマーケティングの責任を負うという建前があったが、これからは AI に判断を委ねることでチームの誰もが責任を取らない状態が生まれうる。 **AI に委ねる時代に必要なのは、知識そのものではない**。知識に基づいた経験と、それらに基づく分析・判断である。これらを AI 任せにするのではなく、人間が新陳代謝しながら取り入れていく ── すなわち、**学習プロセスをチームに組み込まない限り、マーケティングを活かすことは難しい**。 ## マーケティングサイクルは学習サイクルそのもの マーケティングサイクルの各段階を、組織学習サイクルとして読み直すと以下のようになる: | マーケティングサイクル段階 | 組織学習における役割 | |-----------|--------------------| | **観測・データ収集** | チーム内の情報・認識・課題を表に出す。サイロを解消し、共有された前提から議論を始める | | **理解・分析する** | 何を理解しているか／していないかを実測する。分かっているふりを許さず、知の凸凹を可視化する | | **再構築** | 既成の KPI・聖域・「ねばならない」を一旦再構築する。前提を組み替える余白を作る | | **起動・実装する / 学ぶ** | 自社プロダクトに適合した目標を再構成し、実行・測定し、結果を次の 観測・データ収集に還流する | サイクルを 1 周まわすたびに、組織は前回より少し賢くなっている ── これが達成できていない マーケティングサイクルは、機械的に手順を追っているだけで学習を生んでいない。 ## 実装上のヒント ### 失敗できる空間の作り方 - **新規プロジェクトに小さなブランチを切る**: 既存の本流に影響しないスコープで試行する - **「学習目的」と明示した実験予算を確保する**: 成果を出すための予算と分けて確保することで、失敗が評価減点にならない構造を作る - **失敗の事後録を仕組みに組み込む**: `/learn` の「学び」セクションを、成功時にも失敗時にも必ず書く ### 経験を組織に残す書き戻し - **`memory/workspaces//results/`** に、検証された知見と失敗の理由を残す - **`knowledge/marketing/case/`** に、転用可能な事例として一般化できる学びを残す（自社固有の数字は書かない）。プラットフォーム仕様の変化など、ツール文脈の知見は **`knowledge/marketing/tool/`** に残す - **個人の頭の中にだけ残る暗黙知を許さない**: 担当者が抜けても再現できる粒度まで言語化する ### 新陳代謝を前提にした設計 - **役割の固定化を避ける**: 同じ人が同じスキルを毎回担当する状態を避ける - **引き継ぎ可能性をテストする**: 半年ごとに「この workspace を別の担当者に渡せるか」を点検する - **属人的な口伝を許さない**: 重要な判断は必ず文書化し、Slack の DM で完結させない ### 健全な AI 委譲 - **判断の境界を事前に決める**: AI に委ねるルーチン部分と、人間が必ず判断する部分を切り分ける - **AI の出力を「叩き台」と扱う**: AI が出した提案をそのまま流さず、必ず 再構築（既成枠を再構築する問い直し）と 起動・実装する / 学ぶ（自社適合の判定）を経る - **「AI が言ったから」を理由にしない**: AI の出力に依拠した判断であっても、判断責任は人間に帰属させる。`/learn` の差分セクションに「AI 提案のうち何を採用し、何を却下したか、なぜか」を書く ## 関連ドキュメント - `knowledge/marketing/framework/marketing-cycle.md` — マーケティングサイクルの定義 - `knowledge/marketing/playbook/foundations/structural-issues.md` — 学習が起きにくい構造的背景 - `knowledge/marketing/playbook/knowledge-areas/org-capability/responsibility-design.md` — 責任の所在の設計 --- title: "責任の所在の設計" chapter: "14" part: 2-knowledge-areas status: revised visibility: public authors: - claude reviewers: [] revision: 0.1 updated: 2026-05-19 related-skills: [] related-chapters: [] related-knowledge: [] --- # 責任の所在の設計 — 内製・外注・AI 委譲をどう組み合わせるか ## なぜこのドキュメントを置くか マーケティングが機能不全に陥る最大の原因は、責任の所在の不明瞭さである（詳細は `marketing-structural-issues.md`）。マーケティングサイクルは技術的な手順書である以前に、**責任を曖昧にしないための設計図**として機能する。本書では、責任の所在を設計する際の原則と判断軸を記録する。 ## アカウンタビリティとレスポンシビリティ 混同されがちだが別物である: - **アカウンタビリティ**: 結果に対する説明責任。一人に集約されるべき性質を持つ - **レスポンシビリティ**: 実行の責任。複数人に分散しうる マーケティングでは「みんなで話し合って決めました」が常態化しやすく、両者が同時に曖昧になる。マーケティングサイクルでは各 workspace ごとに「誰がアカウンタブルか」を `business-overview.md` に記載することを推奨する。 ## 内製・外注・AI 委譲の責任配分 意思決定と実行を、3 つの担い手にどう配分するかを設計する。 | 担い手 | 何を任せるか | 残すべき責任 | |--------|------------|-------------| | **インハウス（人間）** | 戦略判断、ブランド整合性の最終判定、再構築（既成枠を再構築の決断）、起動・実装する / 学ぶの最終承認 | アカウンタビリティのすべて | | **外部業者** | 専門的な実行、客観視点の Review、新陳代謝の足りない部分の補完 | 引き渡し条件・成果物の検収責任 | | **AI（Claude/Codex 等）** | 情報整理、選択肢の生成、ルーチンの自動化、Review の叩き台 | 判断責任は人間に残す。AI 出力の採否ログを残す | **原則**: 責任の所在を曖昧にする目的で外注・AI 委譲をしない。 ## 健全な外部化 vs 不健全な外部化 外部業者を使うこと自体は悪ではない。問題はその使い方である。 ### 不健全な外部化のサイン - 「とりあえず計測」「とりあえず施策」「とりあえず外注」が並ぶ - 外注先の成果に対し、自社内で責任を取る人が定まらない - 外注の成果物が `memory/` にも `output/` にも残らず、担当者の頭の中にだけ存在する - 契約期間が終わると組織内に何も残らない - 外注が打ち切られると業務が止まる（属人化が外部に移っただけ） ### 健全な外部化のサイン - 外注の目的・期間・成果物・引き渡し条件が事前に定義されている - 外注の成果が `knowledge/` と `memory/` に書き戻されるフローが組まれている - 自社内に「外注先の判断を評価できる人」が一人以上いる - 外注に依存しない代替手段がある（外注が止まっても致命傷にならない） - 外注先がアカウンタビリティではなくレスポンシビリティを引き受けている（最終判断は自社） ## AI 委譲時代の責任外部化問題 「AI が言っているから、この施策を打ちました」── このフレーズが日常的に発される時代が到来しつつある。 これは新しい形の責任外部化である。チームの誰もが「自分は AI の助言に従っただけ」と言えてしまう。判断の所在がチーム内から蒸発する。AI が出す答えを使うことと、その答えを理解していることは別物であり、後者を欠いたまま前者だけが組織に蓄積していく。 ### 実証根拠 — Cognitive Surrender この危機は推測ではない。[Shaw, S. D., & Nave, G. (2026). *Thinking—Fast, Slow, and Artificial: How AI is Reshaping Human Reasoning and the Rise of Cognitive Surrender*](https://ssrn.com/abstract=6097646)（Wharton School, 1,372 名 / 9,000+ 試行）の主要発見: - AI が正答のとき正答率 +25pt、**AI が誤答のとき正答率 −15pt**。AI の利用可能性そのものが人間の判断品質に下振れリスクをもたらす - AI が誤答でも **80% の被験者が AI 出力を採用** - **AI の誤りを訂正できた率はわずか 19.7%**（時間圧 30 秒で −12pt、即時フィードバック＋金銭インセンティブで +19pt） - 著者らは Kahneman の二重過程理論に **System 3（脳の外で動く人工的認知）** を加える Tri-System Theory を提示。AI 委譲は「補助ツールの利用」ではなく**意思決定主体の一部移管**として起きる **「間違っている時に人は判断できなくてはいけない」── これが Marketing OS の AI 委譲設計の核心要求**である。Shaw & Nave のデータは、この要求が自然には満たされないことを示す。AI が誤答する場面で、人間は構造的に訂正できない。だからこそ Marketing OS は「個人の警戒心」ではなく、採否ログ・本番反映前チェック・Evidence Level・DRI 指定といった**省略不可の構造項目**で AI 委譲の責任所在を維持する。詳細は [`../../../reference/references.md`](../../../reference/references.md) §E.9.5。 ### 「AI を使う」から「AI に委ねる」へ - **2025 年まで**: AI を使う時代。プロンプトを組み、出力を取捨選択する - **2026 年以降**: AI に委ねる時代。自律エージェントが連続的にタスクをこなす しかし AI に委ねたからといって、自動的に物事が上手くいくわけではない。**AI に権限を移譲するという行為そのものが判断を要する**。 - 何を委ね、何を残すか - 委ねた結果をどう評価するか - これらはすべて、人間が引き受けるべき判断 小規模なチームや個人事業においては、ルーチン部分の自動化（クリエイティブ大量生成、広告運用チューニング、SEO 記事量産）は加速する。しかしマーケティング全体の自動化ではない。**判断と責任は依然として人間の領域に残る**。 ## マーケティングサイクルにおける責任の動線 マーケティングサイクルの各段階で、誰が何の責任を持つかの基本配分: | マーケティングサイクル段階 | 責任主体 | AI の役割 | |-----------|---------|----------| | **観測・データ収集** | チーム全員（情報を場に出す責任） | サイロ検出、未共有情報の指摘、共有テンプレート提供 | | **理解・分析する** | 各レビュー観点の担当者（CMO/CEO/Specialist） | 視点の切り替え補助、選択肢生成、抜け漏れ指摘 | | **再構築** | 意思決定者（既成枠を再構築の決断は人間に残す） | 「聖域」「前提」「ねばならない」の機械的列挙 | | **起動・実装する / 学ぶ** | 実行責任者（本番反映と測定の責任） | 実装の叩き台生成、測定設計の補助 | **再構築は人間にしかできない**。既成の KPI を再構築する、聖域を否定する、組織政治を超えて「これは違う」と言う ── これらは AI には引き受けられない判断である。 ## 責任設計のチェックリスト 新しい施策・workspace・外注契約を始めるとき、以下を確認する: - [ ] **アカウンタブルな個人**が決まっているか（チームではなく個人名） - [ ] **失敗時の責任**がどう取られるか定義されているか（取らないなら、それを明示する） - [ ] **外注・AI 委譲の境界**が明示されているか（何を委ね、何を委ねないか） - [ ] **学習の書き戻し先**が決まっているか（成功も失敗も `memory/` のどこに残すか） - [ ] **AI 出力の採否ログ**が残る運用になっているか（`/learn` の差分セクション） - [ ] **外注成果の引き渡し条件**が定義されているか（外注が終わっても組織に残る形か） このチェックが通らないうちは、責任の所在は構造的に曖昧であり、マーケティングサイクルは機能しない。 ## 関連ドキュメント - `knowledge/marketing/framework/marketing-cycle.md` — マーケティングサイクルの定義 - `knowledge/marketing/playbook/foundations/structural-issues.md` — 責任不明瞭がなぜ生まれるか - `knowledge/marketing/playbook/knowledge-areas/org-capability/learning-organization.md` — 学習を組織に埋め込む方法 - `knowledge/marketing/framework/marketing-misconceptions.md` — 責任の判断連鎖（②）・外部業者の責任境界（⑥）・同期 → DRI 選択（⑦）の運用定式 --- title: ステークホルダー連携 chapter: "15" part: 2-knowledge-areas status: revised visibility: public authors: - claude reviewers: [] revision: 0.2 updated: 2026-05-19 related-skills: [] related-chapters: - foundations/principles - foundations/cycle - knowledge-areas/org-capability - cross-cutting/playbooks - cross-cutting/org-learning related-knowledge: - knowledge/marketing/playbook/knowledge-areas/org-capability/responsibility-design.md --- # ステークホルダー連携 ## 概要と対象範囲 マーケティング部門と他部門・他主体との**接面設計**を扱う。ICP / 戦略 / 計測のような内部完結する知識エリアと異なり、本章は**境界**を扱う。境界が機能していない組織では、他のすべての KA が成果に結びつかない。 本章は**接面の原理**を定義し、機能対別の具体的な運用テンプレートは [`../../cross-cutting/playbooks/`](../../cross-cutting/playbooks/) に逃がす。両章はセットで読まれることを想定している。 Marketing OS の独自貢献は次の 3 点を構造化することにある: - **共通言語と翻訳辞書**: 部門ごとに同じ語が違う意味を持つことの構造的対処 - **意思決定境界の明示**: 誰が決め、誰が拒否権を持ち、誰が事後通知でよいか - **マーケティングサイクルとの接続点**: どの段でどの部門が同期するかのマトリクス ## 業界トレンドと新興手法 - **Revenue マーケティング**: Sales と Marketing を「収益チーム」として統合する流れ - **データプロダクト化**: 計測・分析を Marketing が単独所有せず、データチームと共有プロダクトとして運用 - **AI agent 経由の連携**: 部門間連絡を AI が翻訳・要約する（ただし採否ログは人間に残る、Principle 6） - **エンジニアリングとマーケの距離縮小**: MarTech / CDP / 分析基盤がエンジニア領域に深く入り込む - **CMO の役割再定義**: Chief Growth Officer / Chief Brand Officer に分化する組織 ## テーラリング | 文脈 | 重点 | |---|---| | **B2B エンタープライズ** | Sales / Product / Engineering との接面を厳格に設計。RACI が必須 | | **B2B SaaS** | Marketing / Sales / Customer Success の 3 者で Revenue 共同責任 | | **D2C** | Marketing / Product / Operations / Customer Support の連携 | | **リテール** | 店舗運営との接面（販促・MD・店舗 KPI 整合）が中心 | | **規制業種** | Legal / Compliance との接面が常時必要。承認フローが厚い | | **スタートアップ** | 役割兼任が前提。接面ではなく**個人内での切替**が論点になる | ## ステークホルダーマップ マーケティング部門が連携する主体を 3 層に分けて俯瞰する。 ### 内部部門 | 部門 | 主な接面 | |---|---| | **Sales** | リード品質、商談接続、SLA、Revenue 共同責任 | | **Product** | JTBD 共有、launch、ポジショニング合意、ロードマップ翻訳 | | **Engineering / Systems / IT** | MarTech 導入、計測タグ実装、データ基盤接続、本番反映フロー | | **Data / Analytics** | KPI 定義の共同所有、アトリビューションモデル、ダッシュボード | | **Finance** | 予算配分、ROMI、見込み計上、コミット精度 | | **Legal / Compliance** | 表現規制、景表法、プライバシー、契約レビュー | | **Customer Success / Support** | VoC 還流、リテンション、アドボカシー | | **HR / People** | エンプロイヤーブランド、内部広報、採用マーケ | | **PR / IR** | コーポレートコミュニケーション、危機対応、IR メッセージ整合 | | **CEO / 経営** | 戦略整合、ボードナラティブ、四半期レビュー | ### 外部主体 | 主体 | 主な接面 | |---|---| | **顧客** | 直接対話、コミュニティ、アンバサダー | | **Agency / Vendor** | RFP、ブリーフ、納品基準、知的財産 | | **メディア・インフルエンサー** | PR、共創コンテンツ | | **業界団体・規制当局** | コンプライアンス、業界標準への参加 | ### マーケティング部門内の役割 外部との接面は、マーケ部門の特定の役割に紐付くことが多い: - **CMO**: CEO / 経営、Finance、PR との接面の最終責任 - **Brand リーダー**: Legal、PR、Creative Direction との接面 - **Demand リーダー**: Sales、Data との接面 - **Marketing Ops**: Engineering、Data、Finance との接面 - **Product Marketing**: Product、Sales、Customer Success との接面 役割分担が明確でない組織では、複数の役割が同一人物に集中する。これ自体は問題ではないが、**接面ごとの担当者を明示**しないと、相手部門は「誰に話せばよいか分からない」状態になる。 ## 共通言語と翻訳辞書 部門ごとに同じ語が違う意味を持つことが、接面失敗の最大の構造要因である。 ### 翻訳辞書の典型例 | 語 | マーケ側の意味 | 相手部門の意味 | |---|---|---| | **リード** | MQL（マーケ判定の見込み顧客） | SQL（営業判定の有効商談） | | **コンバージョン** | 資料請求・問い合わせ | 契約締結 | | **リアルタイム** | 即時 | ≤ 60s / ≤ 1h / 翌日バッチ | | **セグメント** | 配信対象 | テーブル + WHERE 句 | | **計測** | ダッシュボードの数字 | イベント定義 + パイプライン + 集計層 | | **本番反映** | 公開 | PR → review → deploy → 監視 | | **施策** | キャンペーン / クリエイティブ | プロジェクト / リリース | | **顧客** | ターゲット / ICP | アカウント / 契約者 | | **成果** | 認知 / 想起 / リード | 売上 / 利益 / LTV | ### 翻訳辞書の運用 接面ごとに翻訳辞書を持つことを推奨する。具体的には: - 機能対別 playbook（[`../../cross-cutting/playbooks/`](../../cross-cutting/playbooks/)）に各対の翻訳辞書を埋め込む - 新語の導入時は両部門の合意を取り、glossary に追加する - 共有ドキュメント（戦略書・ブリーフ）には**初出で翻訳を併記する** ## 意思決定境界（RACI 圧縮版） 接面で頻発する問題は「誰が決めるか」「誰が拒否権を持つか」が事前に決まっていないことである。RACI（Responsible / Accountable / Consulted / Informed）を圧縮した形式で接面ごとに定義する。 ### RACI の最低限の運用 各意思決定について次の 4 区分を明示する: - **R（Responsible）**: 実行責任。複数人可 - **A（Accountable）**: 最終責任。**必ず 1 人**（チーム名 NG） - **C（Consulted）**: 事前相談。決定前に意見を聞く相手 - **I（Informed）**: 事後通知。決定後に知らせる相手 A は意思決定権を持ち、C と I は持たない。**A の集中**が責任の所在を明確にする中心装置である（[`../../foundations/principles.md`](../../foundations/principles.md) 補題 B）。 ### マーケ × 他部門の典型 RACI | 意思決定 | A | R | C | I | |---|---|---|---|---| | 新規キャンペーンの開始 | マーケ責任者 | マーケ実行 / 代理店 | 営業 / プロダクト / 法務 | 経営 | | MarTech ツールの導入 | Marketing Ops | Engineering | Finance / Legal | 全マーケ | | ブランドメッセージの大幅変更 | CMO | Brand リーダー | PR / Sales / Legal | 経営 / 全社 | | 予算配分の四半期見直し | CMO | Marketing Ops | Finance | 経営 | | 危機対応の対外メッセージ | 広報責任者 | 広報 + 法務 | CMO / CEO | 経営 | 組織により変動するが、**A が複数いる / 不在**の意思決定は構造的に詰まる。 ## マーケティングサイクルとの接続点 どの段でどの部門が同期するかを整理する。 | 段 | 同期する部門 | 同期内容 | |---|---|---| | **観測・データ収集** | Sales / Customer Success / Engineering / Data / Finance | 顧客の声、計測実装、実績数値 | | **理解・分析する** | Product / PR / Sales | 戦略整合、ポジショニング、競合動向 | | **再構築** | 経営 / Finance | 既成 KPI・聖域の再構築は経営合意が必要な場合がある | | **起動・実装する** | Engineering / Legal / Sales | 本番反映、表現規制、商談接続 | | **学ぶ** | Data / Finance / Sales | 結果集約、Revenue 結節 | 特に **起動・実装する段**は最も多くの部門との接面が発生する段である。本番反映前チェックのオーナー / 承認 / ロールバック項目は、接面の合意を構造化する装置として機能する。 ## 機能対別プレイブック（Part 3 へ） 機能対別の具体的な運用テンプレート（接続目的 / 翻訳辞書 / 定例議題 / 意思決定境界 / マーケティングサイクル 接続点 / 典型的摩擦と対処 / 1 ページ運用テンプレ）は [`../../cross-cutting/playbooks/`](../../cross-cutting/playbooks/) に格納する。 主な機能対: - **20.1 Marketing × Sales** — リード品質・SLA・Revenue 共同責任 - **20.2 Marketing × Product** — JTBD 共有・launch・ポジショニング - **20.3 Marketing × Engineering / Systems / IT** — MarTech・計測・データ基盤 - **20.4 Marketing × Data / Analytics** — KPI 共同所有・アトリビューション - **20.5 Marketing × Finance** — 予算・ROMI・コミット精度 - **20.6 Marketing × Legal / Compliance** — 表現規制・プライバシー - **20.7 Marketing × Customer Success** — VoC 還流・リテンション - **20.8 Marketing × Executive** — 戦略整合・ボードナラティブ - **20.9 Marketing × HR** — エンプロイヤーブランド - **20.10 Marketing × PR / IR** — コーポレートコミュニケーション - **20.11 Marketing × Agency / Vendor** — 外部実行 ## アンチパターン - **「丸投げ」**: 一方が他方に責任ごと預ける。A が相手側にしかいない状態 - **「壁越し」**: 仕様だけ投げて、合意形成を経ない。接面が機能しない - **「翻訳ロス」**: 同じ語を別の意味で使い続け、合意したつもりで合意していない - **「RACI 不在」**: 意思決定境界が言語化されていない。「みんなで決める」が常態化 - **「合議による戦略合成」**: 同期会議で戦略が決まると期待する（補題 G 違反）。同期は争点可視化、戦略は A の選択 - **「あの部門は分かってない」症候群**: 翻訳辞書の整備に投資せず、相手部門の理解不足を一方的に責める - **「ステークホルダー多すぎ問題」**: C / I を増やしすぎて意思決定が遅延する。C / I は**最小限**にする - **「個別最適化された SLA」**: 部門ごとに別々の SLA を持ち、全体最適化されない - **「接面の属人化」**: 特定の人だけが他部門と話せる。担当者が抜けると接面が崩壊 ## 関連 skill / agent - **`/listen team-org` / `/listen team-workspace`** — 組織内の認識整理、部門間のズレ可視化 - **`/insight ceo`** — 経営視点での接面評価 - **`/insight consultant`** — 第三者視点での接面摩擦の検出 機能対別の具体的な運用は [`../../cross-cutting/playbooks/`](../../cross-cutting/playbooks/) を参照。 ## 今後の拡張論点 - **15 章（接面原理）と 20 章（機能対別 playbook）の境界** — 「原理は 15、運用は 20」の境界は崩れやすい。具体例をどちらに置くか - **外部主体の扱い** — 内部部門と外部主体（顧客 / Agency 等）を同じ章で扱うか分けるか。本章は両方含めたが、外部主体だけで独立章にする選択肢もある - **ステークホルダーの射程** — 株主・規制当局・業界団体まで含めるか、内部部門と外部 Agency までに限定するか - **RACI vs DACI vs RAPID** — 意思決定モデルとして RACI を採用したが、DACI（Driver / Approver / Contributor / Informed）や RAPID（Recommend / Agree / Perform / Input / Decide）の方が AI 時代に適する場面もある。複数モデルの併用を許すか - **接面の成熟度評価** — 22 章 成熟度モデルに「接面の成熟度」軸を追加するか、独立評価とするか --- title: リスク・コンプライアンス・ブランドセーフティ chapter: "16" part: 2-knowledge-areas status: revised visibility: public authors: - claude reviewers: [] revision: 0.2 updated: 2026-05-19 related-skills: [] related-chapters: - cross-cutting/ai-in-marketing - cross-cutting/playbooks related-knowledge: [] --- # リスク・コンプライアンス・ブランドセーフティ ## 概要と対象範囲 法務・コンプライアンス、表現規制、プライバシー、ブランドセーフティ、AI 出力リスクを扱うスタブ章。本章は薄く保ち、AI リスクの詳細は [`../cross-cutting/ai-in-marketing.md`](../cross-cutting/ai-in-marketing.md) §17.6 と連携する。 ## 主要トピックと参照先 ### 表現規制 日本の主な規制（業種・媒体により変動）: - **景品表示法**: 優良誤認・有利誤認・過大景品の禁止 - **薬機法**: 医薬品・化粧品・健康食品の効能効果表現 - **金商法**: 金融商品の表示・勧誘 - **医療広告ガイドライン**: 医療機関の広告表現 - **特商法**: 通信販売・連鎖販売の表示義務 ### プライバシー - **個人情報保護法**（日本）: 個人情報の取扱い、第三者提供 - **GDPR**（EU）: 同意ベースのデータ処理、忘れられる権利 - **CCPA / CPRA**（米国）: 消費者プライバシー権 - **Cookie 規制**: 改正電気通信事業法、ePrivacy Directive ### ブランドセーフティ - **広告掲載面の品質**: 不適切なコンテンツ隣接の回避 - **UGC リスク**: ユーザー投稿の品質管理 - **クライシス対応**: ブランド毀損事象への即応 ### AI 出力リスク - **ハルシネーション**: AI が事実でない情報を出力 - **著作権**: 生成物の著作権・学習データ問題 - **deepfake / なりすまし**: 偽情報生成 - **バイアス**: 学習データの偏り 詳細な構造的対応は [`../cross-cutting/ai-in-marketing.md`](../cross-cutting/ai-in-marketing.md) §17.6 を参照。 ### 著作権・知的財産 - **コンテンツ著作権**: 自社制作物・外注成果物の権利帰属 - **商標**: ブランド名・ロゴの保護 - **第三者素材**: ストック写真・音源・フォント等の利用権 ## マーケティングサイクルとの最小接続 - **観測・データ収集**: 規制動向、違反兆候、競合のクライシス事例の継続観測 - **理解・分析する**: リスクシナリオ生成、コンプラ要件の整理 - **再構築**: 廃止規程の再構築、過剰自主規制の見直し - **本番反映前チェックとの連動**: リスク項目で表現規制・プライバシー違反を事前チェック - **学ぶ**: リスク発生事象の検証、再発防止策の整備 ## アンチパターン - **Legal レビューの遅延**: 制作物完成後にレビュー依頼し、差し戻しで全工程やり直し - **「ダメと言われた」の放置**: Legal の指摘理由を理解せず、回避策を考えない - **規制動向の見落とし**: 規制改正をキャッチアップせず、過去基準で運用継続 - **AI 出力の無検収公開**: ハルシネーションを含む生成物をそのまま外部公開 - **UGC の放任**: ユーザー投稿の品質管理を持たず、ブランド毀損を許容 - **クライシス対応の事前準備不足**: 危機発生時にプレイブックがなく、対応が遅れる ## 関連 skill / agent - **`/brand`** — ブランド適合チェック（一部の表現規制リスクを検出） ## 今後の拡張論点 - **AI 関連リスクの章間分担** — 構造的対応（17 章）と法務観点（本章）の境界 - **業種別の必須度** — 規制業種（医療・金融）では主要章として厚くするかを検討 - **Legal との接面プレイブック** — [`../cross-cutting/playbooks/`](../cross-cutting/playbooks/) の `legal.md` との分担 - **クライシス対応プレイブック** — 本章で扱うか、20 章 PR / IR playbook と統合するか --- title: AI / 大規模言語モデルのマーケティング活用 chapter: "17" part: 3-cross-cutting status: revised visibility: public authors: - claude reviewers: [] revision: 0.2 updated: 2026-05-19 related-skills: - /listen - /insight - /release - /learn related-chapters: - foundations/principles - foundations/cycle - knowledge-areas/measurement-martech - knowledge-areas/org-capability - knowledge-areas/risk-compliance - cross-cutting/org-learning related-knowledge: - knowledge/marketing/playbook/knowledge-areas/org-capability/responsibility-design.md - knowledge/base/skills-vs-agents.md --- # AI / LLM のマーケティング活用 ## 概要と対象範囲 本章は AI / LLM をマーケティングに組み込む際の**原則・パターン・リスク管理**を扱う。CMO Marketing OS Playbook の差別化軸の一つであり、[`../foundations/principles.md`](../foundations/principles.md) Principle 6（AI Decision Accountability）を運用面に展開する章である。 AI の活用範囲は急速に拡大しているが、本書は「何ができるか」のカタログではなく、**判断責任が組織から消えない構造**を維持しながら AI を組み込むための設計指針を中心に扱う。具体的な個社製品（Claude / GPT / Gemini 等）の比較は [`../../tools/`](../../tool/) 配下に逃がす。 ## 「AI を使う」から「AI に委ねる」への遷移 AI 活用の段階を 2 つに区分する: - **AI を使う段階**: プロンプトを組み、出力を取捨選択する。人間が判断と実行の主体で、AI は道具 - **AI に委ねる段階**: 自律エージェントが連続的にタスクをこなす。人間は委譲の境界と評価軸を設計する 両段階で本質的に異なるのは**判断の所在**である。AI に委ねたからといって自動的に上手くいくわけではなく、**AI に権限を委譲するという行為そのものが判断を要する**。具体的には: - 何を委ね、何を残すか - 委ねた結果をどう評価するか - 委ねたことの記録をどう残すか これらはすべて人間が引き受けるべき判断であり、Marketing OS の skill / agent 設計はこの境界を構造化する装置として動く。 ## AI Decision Accountability（AI 判断の責任非曖昧化） ### 採否ログの 4 要素 AI 出力を採用するか否かの判断について、次の 4 要素を構造的に記録する: | 要素 | 記録内容 | |---|---| | **採否** | 採用 / 一部採用 / 不採用 | | **判断者** | 採否を決めた個人（チーム名ではなく個人名） | | **理由** | なぜその判断に至ったか（自社文脈・制約・前提との照合） | | **代替案** | 採用しなかった場合に何を採用したか | これら 4 要素が揃った採否ログのみを有効とする。「採用」「不採用」のチェックだけが残り、理由が空欄のログは [`./org-learning.md`](org-learning.md) §18.6 のアンチパターン「AI 採否ログの形式化」に該当する。 ### 責任の本質 責任の本質は処罰ではなく、**意思決定権・仮説・検証条件・結果の扱いの 4 点が同一主体に紐付いていること**である（[`../foundations/principles.md`](../foundations/principles.md) 補題 B）。AI / agent への委譲はこの 4 点のうちのどれかを外部化しうる: - **意思決定権の外部化**: AI が選んだ案をそのまま採用する - **仮説の外部化**: AI が立てた仮説を自社仮説として扱う - **検証条件の外部化**: AI が提案した KPI / 撤退条件をそのまま採用する - **結果の扱いの外部化**: AI に書き戻しまで委ね、人間がレビューしない いずれの外部化も**採否ログによって追跡可能であれば許容**できる。追跡不能な外部化が責任を組織から消す。 ### 「AI が言ったから」病の構造的防止 「AI が言っているから、この施策を打ちました」というフレーズが日常化したとき、判断はチームの誰の手にも残らない。これは新しい形の責任外部化であり、外部業者への丸投げと構造的に同じ問題を生む。 #### Cognitive Surrender の実証 — なぜ「個人の注意」では足りないか 「AI を盲信しないこと」は個人の心がけで解決できない。Shaw & Nave (2026) ["Thinking—Fast, Slow, and Artificial: How AI is Reshaping Human Reasoning and the Rise of Cognitive Surrender"](https://ssrn.com/abstract=6097646)（Wharton, 1,372 名 / 9,000+ 試行）は、AI 利用時の人間の判断歪みを定量化している: - AI が正答のとき正答率 +25pt、AI が誤答のとき正答率 −15pt。**AI が利用可能であるという事実そのもの**で判断が動く - AI が誤答でも **80% の参加者が AI 出力を採用**する - **AI の誤りを訂正できた率はわずか 19.7%**。30 秒の時間圧で訂正率はさらに 12pt 下がる - 著者らは Kahneman の二重過程理論に「**System 3 = 脳の外で動く人工的認知**」を加える Tri-System Theory を提示。AI への委譲は System 1/2 への補助ではなく、**意思決定の主体そのものの一部移管**として起きる 含意は次の一文に集約される ── **「間違っている時に人は判断できなくてはいけない」のに、AI 利用環境では構造的にそれが起きない**。マーケティング判断は時間圧・複数選択肢・正解の遅延フィードバックが揃う領域であり、cognitive surrender の発生条件をほぼすべて満たす。だからこそ、AI 出力の検収を「個人の意識」に委ねず、**省略不可の構造項目**として OS に埋め込む必要がある。 #### CMO Marketing OS Playbook の構造的防止策 - **学ぶ段で採否ログを必須項目とする**（[`../foundations/cycle.md`](../foundations/cycle.md) §2.6.4）── 採否・判断者・理由・代替案の 4 要素を文書化することで、cognitive surrender 状態でも事後検証可能な状態を残す - **本番反映前チェックのオーナー項目**で個人を特定する（同 §2.5.3）── 「AI が言ったから」ではなく「個人 X がその判断を引き受けた」を強制する - **Evidence Level E0 / E1 を profile に書かせない**（同 §2.6.3）── 検証されていない AI 出力が事実として組織知に混入することを防ぐ これら 3 つはセットで機能する。1 つでも欠ければ、責任の所在は構造的に曖昧になる。実証根拠の詳細は [`../../reference/references.md`](../../reference/references.md) §E.9.5 を参照。 ## マーケティングサイクルへの AI 組み込みパターン 各段で AI が果たす役割と、人間が必ず残すべき判断を整理する。 ### 観測・データ収集 — 取り込みの自動化 **AI の役割**: - 顧客フィードバックの自動集約（営業ログ・サポート問い合わせ・レビュー） - 競合動向の継続監視 - 観測対象間の重複・矛盾の検出 **人間の判断**: - どの情報源を観測対象に組み込むか - 取り込んだ情報の信頼度判定（一次情報 / 二次情報 / 推定） ### 理解・分析する — 視点切替の補助 **AI の役割**: - 4 視点（CEO / Consultant / Gemba / Customer）の擬似的な切替 - JTBD 仮説の抽出 - ICP 仮説と顧客実態のズレの検出 **人間の判断**: - 視点の優先順位（どの視点を重く扱うか） - 抽出された仮説の自社文脈への適合性判定 ### 再構築 — 機械的列挙の自動化 **AI の役割**: - 既成 KPI・聖域・「ねばならない」の機械的列挙 - 整合性ない指標の検出 - ゼロベースの代替案生成 **人間の判断**: - 実際に再構築の決断（再構築原則: 再構築は人間にしか引き受けられない） - 組織政治を超えて「これは違う」と言う判断 再構築段が AI 委譲できない理由は、判断が単に論理的ではなく**組織内の政治的・心理的な負担を伴う**ためである。AI は「聖域」を列挙できるが、聖域を実際に再構築する責任は人間に残る。 ### 起動・実装する — 実装と最適化の補助 **AI の役割**: - コンテンツ生成（広告・LP・記事） - 配信最適化（入札・配信時刻・クリエイティブローテーション） - A/B 設計の叩き台 **人間の判断**: - 本番反映前チェックの通過判定（オーナー / 計測 / ロールバック等の 7 項目） - ブランド適合性の最終判定 - 本番反映の承認 Adaptive レイヤー（リアルタイム最適化）の自動化は最も進んでいる領域である。一方で**戦略レイヤー（マーケティングサイクル）の最適化は AI に委譲しない**というのが Principle 2 の含意である。 ### 学ぶ — 還流の自動化と採否ログ **AI の役割**: - 結果の 4 軸整理（Funnel / Segment / Attribution / Unit Economics） - Evidence Level の初期判定の提案 - 書き戻し候補の生成 **人間の判断**: - Evidence Level の最終判定（E2 → E3 への昇格） - profile 反映の承認 - AI 採否ログの記録（人間自身がここで採否を残す） ## Skill / Agent の分業設計 Marketing OS は AI 機能を 2 つの形態で実装する: **Skill**（ユーザー主導の対話）と **Agent**（モデル主導のサブタスク委譲）。両者の使い分けは以下による。 ### 判断基準 | 性質 | Skill | Agent | |---|---|---| | 呼び出し | ユーザーが `/コマンド` で起動 | モデルが Task ツール経由で並列ディスパッチ | | コンテキスト | メインセッションで実行（成果物・履歴が残る） | 独立したサブエージェントで実行（結果のみ返却） | | 副作用 | あり（ファイル書き込み・MCP 呼び出し） | なし（Read のみ、結果を文字列で返す） | | 典型的な用途 | 直接のユーザー対話・制作・観測・データ収集 / 学ぶ操作 | レビュー・評価・並列診断 | Agent 化の判断基準は次のいずれかに該当すること: - ワークフローから並列で呼ばれる（例: CEO / Consultant / Gemba / Customer 視点の同時起動） - レビュー系で副作用なし - メインコンテキストを汚したくない診断タスク ### 設計原則 - **Agent 化された機能は agent 側を canonical とし、Skill は thin dispatcher**（slash エントリ用） - 仕様は agent 側に一本化され、Skill との重複・drift を防ぐ - 専門領域の実行（広告運用・コンテンツ生成・SEO 等）は専用 skill / agent を持たず、`knowledge/` のプレイブック参照で対応する 専門 skill を増やさない設計判断は、「Marketing OS が何の OS か」（= マーケティングサイクルを駆動する OS）の輪郭を維持するためである。Adaptive レイヤーの自動化は LLM 汎用能力 + プレイブックで成立するため、戦略レイヤーの skill だけを置く。 ## AI 出力リスクと対応 AI 活用に伴う主なリスクと、Marketing OS の対応: | リスク | 内容 | 対応 | |---|---|---| | **ハルシネーション** | AI が事実でない情報を自信を持って出力する | Evidence Level E0 / E1 の profile 書き込み禁止 | | **著作権 / 学習データ** | 生成物が既存著作物に類似する | 公開前の検収プロセス、外部チェックツール併用 | | **バイアス / 公平性** | 学習データに含まれる偏りが出力に反映される | 4 視点切替で異なる立場からの再検証 | | **deepfake / なりすまし** | 顧客やステークホルダーの偽情報生成 | ブランドガイドラインへの明示、対外発表前のオーナー承認 | | **プロンプトインジェクション** | 悪意ある入力により AI が意図しない動作をする | 入力サニタイズ、AI が直接外部 API を叩く範囲の限定 | | **個人情報の漏洩** | 顧客データを学習に提供してしまう | 個別契約・テナント分離・PII マスキング | リスクの詳細と法的観点は [`../knowledge-areas/risk-compliance.md`](../knowledge-areas/risk-compliance.md) と連携する。本章は構造的な対応設計を扱い、リスク管理の運用詳細は 16 章に逃がす。 ## 再現性と監査可能性 AI 出力を本番運用に組み込む際は、後から追跡可能な状態を維持する。 ### 記録すべき要素 - **プロンプト**: AI に与えた入力（テンプレート + 動的部分） - **出力**: AI が返した内容（全文） - **採否**: 採否ログの 4 要素（§17.3.1） - **モデル名・バージョン**: どのモデルで生成したか これらをセットで保管することで、後日の検証・問題発生時の追跡・改善判断が可能になる。 ### 保管場所 - **採否ログ**: `memory/workspaces//results/` の 学ぶセクション - **プロンプトテンプレート**: skill / agent の `SKILL.md` 内 - **生成物（公開用）**: `output//` 配下 - **モデル情報**: 採否ログのメタ項目 ## アンチパターン - **「AI が言ったから」病**: AI 出力を判断根拠にする。責任の所在が組織から消える - **AI 採否ログの形式化**: 採否のチェックだけが残り、理由が空欄 - **戦略レイヤーの AI 委譲**: 再構築 / 戦略判断まで AI に任せる - **AI 出力の無検収公開**: ハルシネーションを含む生成物をそのまま外部公開 - **専門 skill の乱立**: AI でカバーできる領域に専用 skill を増やし、Marketing OS の輪郭を曖昧にする - **モデル選択の属人化**: どのモデルをいつ使うかが個人の好みに依存し、組織知にならない - **AI への過剰委譲**: ルーチン以外（戦略・倫理判断・対外発表）まで自動化対象に含める - **Evidence Level 判定の AI 化**: 検証度の最終判定を AI に委ねる（人間の判断責任が消える） ## 関連 skill / agent - **`/learn`** — AI 採否ログを残す主たる skill - **`/insight ceo` / `/insight consultant` / `/insight gemba` / `/insight customer`** — 4 視点切替を agent ディスパッチで実装 - **`/brand`** — ブランド適合の判断チェック（creative-direction agent を呼ぶ） skill ↔ process の完全な対応は [`../appendices/skill-mapping.md`](../../../base/skill-mapping.md)。 ## 今後の拡張論点 - **採否ログの粒度** — 簡易運用（1 行サマリ）/ 標準運用（4 要素）/ 厳格運用（プロンプト + 出力 + 4 要素）の三段階運用は妥当か。テーラリング（19 章）と連動して場合分けすべきか - **モデル個社比較の扱い** — Claude / GPT / Gemini 等の比較は本章で扱うか、`knowledge/marketing/tool/` に完全に逃がすか - **Agent 化と外部化の境界** — 自律 agent への委譲は「外部化」に近づく。本章 §17.3.2 の責任 4 点の枠組みで十分か、agent 固有の論点を立てる必要があるか - **16 章 リスク・コンプライアンスとの分担** — AI リスクは構造的対応（本章）と法務観点（16 章）に分かれる。重複の整理が必要 - **「Adaptive レイヤー」と「戦略レイヤー」の境界の明示** — 起動・実装する内のリアルタイム最適化と 再構築 / 理解・分析するの戦略判断を構造的に分けるためのチェックリストが必要か --- title: 組織学習パターン chapter: "18" part: 3-cross-cutting status: revised visibility: public authors: - claude reviewers: [] revision: 0.2 updated: 2026-05-19 related-skills: - /listen - /release - /learn related-chapters: - foundations/principles - foundations/cycle - foundations/performance-domains - knowledge-areas/org-capability - cross-cutting/ai-in-marketing related-knowledge: - knowledge/marketing/playbook/knowledge-areas/org-capability/learning-organization.md - knowledge/marketing/playbook/foundations/structural-issues.md - knowledge/marketing/playbook/knowledge-areas/org-capability/responsibility-design.md --- # 組織学習パターン ## 概要と対象範囲 本章は **CMO Marketing OS Playbook の存在理由を理論化する** 章である。施策単位の PDCA ではなく組織学習として駆動する（[`../foundations/principles.md`](../foundations/principles.md) Principle 1）という CMO Marketing OS Playbook の中心命題は、「なぜ組織は放置すると学習しなくなるのか」を構造的に説明できなければ宙に浮く。本章はその構造を 6 つの要因に分解し、マーケティングサイクルがそれぞれに対応する仕組みを明示する。 既存の組織学習論（Argyris / Senge / Edmondson）はマーケティングを射程に含むが、マーケティング特有の attribution の困難・時間差・外部依存をフレーム化していない。本章はそれを補う位置に置かれる。 ## 学習しない組織の 6 つの構造要因 組織が放置されると学習しなくなる理由は、個人の能力や姿勢ではなく**構造**にある。以下の 6 要因のうち、いずれか 1 つでも成立すると学習サイクルは閉じる。 ### 前提共有の不在 「マーケティング」「成果」「顧客」「施策」がチーム内で別の意味を指している状態。各メンバーが「自分は事業のどの課題に効いているか」を自分の言葉で答えられない状態。 この状態では、振り返りや学習を試みても**全員が違うものを指している**ため、知見が積み上がらない。観測・データ収集段の Team Sync は、まずこの前提のズレを可視化することを目的とする（[`../foundations/cycle.md`](../foundations/cycle.md) §2.2.2）。 ### 失敗を情報取得コストとして設計していない 組織が「失敗できる小さな空間」を持っていない状態。具体的には次の 4 項目が未設計である: - **予算が情報取得目的で確保されていない**（全予算が成果目的） - **評価が結果ベースのみ**（仮説の質・撤退判断の速さが評価対象に入っていない） - **撤退条件（kill criteria）が事前に書かれていない**（成功条件は書いても失敗条件は曖昧） - **学習ログが残らない** これらが揃わない限り「失敗できない」のではなく、**失敗を組織知に変換する仕組みが構造的に欠落している**（[`../foundations/principles.md`](../foundations/principles.md) 補題 D）。 特に**成果が非線形に顕在化する**マーケ施策では、「間違った施策に時間を費やすと累積した時間が全て無駄になる」という構造（[`../foundations/principles.md`](../foundations/principles.md) 補題 I）が、失敗設計の重要性をさらに高める。中間指標と段階的な kill criteria を事前に置かない限り、「とりあえずやっただけ」が累積する。 ### 停止記憶の欠落（再構築不在症候群） 走り出した施策・採用した KPI・継承した聖域を**意識的に止めた記録**が残らない構造。新しい施策は記録されるが、止めた施策・棄却した KPI・破棄した前提は記録されない。 この非対称性が、次の 3 つの病理を生む: - **リソースの即時充填**: 止めた施策の余白が、考えなしに新規施策で埋め直される - **新規余白の枯渇**: 棄却した前提が言語化されないため、前提を組み替える余白が広がらない - **学習の偏り**: 「やったこと」のログだけが残り、「やらなかった理由」が消える 再構築段は、この非対称性を構造的に解消するために独立段として置かれる（[`../foundations/cycle.md`](../foundations/cycle.md) §2.4）。 ### 責任の外部化 判断責任が組織内で完結しない状態。古典的には外部業者への丸投げが該当するが、AI 時代には新しい形が加わる: > 「AI が言っているから、この施策を打ちました」 このフレーズが日常化したとき、判断はチームの誰の手にも残らない。**意思決定権・仮説・検証条件・結果の扱いの 4 点が同一主体に紐付かない**限り、責任は機能しない（[`../foundations/principles.md`](../foundations/principles.md) 補題 B）。 外部業者は実行責任・専門責任・説明責任の一部を引き受け可能だが、**事業責任・顧客価値責任・ポジショニング責任・最終資源配分責任は内部に残る**（同 補題 F）。境界の明文化なしに責任を外部化すると、incentive のズレが必ず顕在化する。 ### 知識の平準化と経験の希少化 LLM 普及により、知識（What is X / How to X）の取得コストはほぼゼロになった。一方、**知識を文脈に当てはめて判断する経験**は希少性を増している。 この非対称が起きると、組織は次のいずれかに退避する: - **「知っている」で止まる**: 概念は語れるが、自社文脈での適用判断ができない - **AI 提案の表面的採用**: 平均的に正しい AI 提案を、自社固有の制約を踏まえずに採用する 学習する組織は、知識の供給ではなく**判断経験の累積**に投資の重心を移す必要がある。 ### 属人化と新陳代謝のジレンマ 担当者の頭の中にだけ知見が残る状態。担当者が抜けると組織知ごと消える。一方、新陳代謝（人材の入れ替わり）を促すと、属人的に蓄積された知見が失われる。 このジレンマは、**知見を担当者から分離して保管できる場所**（記憶層）の有無で解ける。Marketing OS の `memory/workspaces//profile/` や `results/` は、属人化からの分離を構造的に成立させるための装置である。 ## マーケティングサイクルが学習を起こす構造 §18.2 の 6 要因に対し、マーケティングサイクルは次のように対応する。 | 要因 | 主に対応する段 | 仕組み | |---|---|---| | 前提共有の不在 | 観測・データ収集 / Team Sync | 各メンバーが独立記述した認識を合成し、不一致を 再構築入力にする | | 失敗の前提化欠如 | 本番反映前チェック / 学ぶ | オーナー / 計測 / ロールバックと Evidence Level により、失敗が組織知に変換される | | 停止記憶の欠落 | 再構築 | 既成 KPI・聖域・前提を機械的に列挙し、止めた理由を記録する | | 責任の外部化 | 学ぶの AI 採否ログ | 採用 / 不採用 / 理由を記録し、責任主体を維持する | | 知識の平準化 | 理解・分析する | 4 視点で判断材料を出し、AI 提案を自社文脈に当てはめる判断経験を累積する | | 属人化のジレンマ | 観測・データ収集 / 学ぶの書き戻し | profile / results 層に検証済み知見を分離保管し、担当者から独立させる | 5 段すべてが揃って初めて 6 要因のすべてに対応できる。1 段でも欠ければ、対応していない要因の経路から学習が漏れる。 ## 既存学習組織論との関係 CMO Marketing OS Playbook は既存の組織学習論を否定するのではなく、マーケティング領域への適用上の補強として位置づける。 ### Argyris の Single / Double / Deutero Learning Argyris の枠組みは次の 3 層を区別する: - **Single-loop learning**: 既存ルールの範囲内で行動を修正する（戦術最適化） - **Double-loop learning**: 既存ルール（前提・KPI・ICP）自体を問い直す（戦略最適化） - **Deutero learning**: 「学習の学習」を組織能力として制度化する CMO Marketing OS Playbook の **再構築段は Argyris の Double-loop learning を独立段として制度化したもの**である。Adaptive Marketing / Real-time Marketing 系統は Single-loop に偏り、再構築を独立段として持たない。 ### Senge の Learning Organization 5 ディシプリン Senge は次の 5 つを学習組織の構成要素とする: System Thinking / Personal Mastery / Mental Models / Shared Vision / Team Learning。 CMO Marketing OS Playbook は **Mental Models**（前提の組み替え）と **Team Learning**（チーム同期）に対する具体的な実装を提供する（再構築段と 観測・データ収集 / Team Sync）。System Thinking と Shared Vision は 14 章（組織・能力）と 05 章（統合・戦略）の射程に含まれる。 ### Edmondson の Psychological Safety Edmondson は「失敗を提起しても罰されない心理的安全性」を学習組織の前提条件とする。CMO Marketing OS Playbook の **本番反映前チェックの省略不可項目**（オーナー / 計測 / ロールバック）と **学ぶ段の Evidence Level** は、心理的安全性を **構造装置**として強制する役割を持つ: - オーナーが明示されることで、責任の所在が「全員」に拡散しない - 撤退条件（ロールバック）が事前に書かれることで、撤退が「敗北」ではなく「設計通りの判断」になる - Evidence Level により、未検証の仮説（E0 / E1）を profile に書く誘惑が構造的に抑制される 心理的安全性は文化ではなく**プロセス設計の帰結**である、というのが CMO Marketing OS Playbook の立場である。 ### マーケティング特有の補強観点 既存学習組織論が必ずしも明示しない、マーケティング固有の論点を CMO Marketing OS Playbook は加える: - **Attribution 密度と時間差**: マーケの成果は因果分解が困難で時間差が大きい（補題 C）。Evidence Level による検証度の分類は、この困難を運用化する装置 - **Customer Sync の独立化**: 顧客実態を内部仮説と独立に保つ構造（Principle 4） - **AI 採否ログ**: AI / agent への判断委譲が責任の所在を曖昧にする傾向への対抗（Principle 6） ## 学習速度（Learning Velocity）の操作的定義 組織学習が「起きているかどうか」を測定するための観点。3 章 パフォーマンスドメイン §3.2.4 で定義したものを、ここで操作可能な指標に落とす。 ### 4 指標 | 指標 | 操作的定義 | 測定頻度 | |---|---|---| | **サイクル所要日数** | 観測・データ収集の起点から 学ぶ終端までの実日数の中央値 | 月次 | | **E3 昇格件数** | 学ぶ段で E3（検証済み知見）として profile に書き戻された件数 | 月次 | | **再構築件数** | 再構築段で再構築が決定された前提（KPI / 聖域 / 既成施策）の件数 | 月次 | | **AI 採否ログ記録率** | 採否ログが必須項目で残された比率 | サイクルごと | これら 4 指標は単独では学習を測れない。**4 指標のセットで観測する**ことで初めて学習が起きているかどうかが見える。 ### 操作可能性とトレードオフ Learning Velocity を KPI 化すると、形式的に数値を上げる運用に陥るリスクがある: - サイクル所要日数を縮めるために 再構築を儀式化する - E3 昇格件数を増やすために検証度の判定を緩める - AI 採否ログ記録率を 100% にするために形式的な記録だけ残す これを避けるためには、Learning Velocity を**他のパフォーマンスドメインとセットで観測する**こと（[`../foundations/performance-domains.md`](../foundations/performance-domains.md) §3.3）と、**Learning Velocity 自体を意思決定 KPI にしない**こと（補題 E）が必要である。観測指標と意思決定 KPI を分離する。 ## アンチパターン 学習組織を志向する組織がしばしば陥る典型例: - **学習目標の自己目的化**: 「学習する組織を作る」が単独目標になり、何を学習するかが空洞化する - **儀式化された振り返り**: 定例の振り返り会が実施されるが、書き戻しが起きず profile が更新されない - **失敗の隠蔽インセンティブ**: 評価制度が結果ベースのみで、撤退が減点になる構造 - **AI 採否ログの形式化**: 「採用」「不採用」のチェックだけが残り、理由が空欄 - **ベンチマーク偏重**: 他社事例を集めるが、自社文脈への適用判断が起きない - **学習速度の KPI 化**: Learning Velocity 自体を成果 KPI に置き、数値ゲーミングを誘発する - **「学習する組織」の宣言**: ビジョンとして掲げるが、構造設計（本番反映前チェック / Evidence Level 等）に落ちていない - **属人化を「個人の強み」と誤認**: 担当者の頭の中の知見を組織知に分離するインセンティブが働かない ## 関連 skill / agent - **`/listen team-org` / `/listen team-workspace`** — 前提共有の不在を可視化する - **`/release`** — 停止記憶を構造化する - **`/learn`** — Evidence Level 判定と AI 採否ログを残す - **`/insight consultant`** — 知識の平準化に対し、外部視点での判断経験を補う skill ↔ process の完全な対応は [`../appendices/skill-mapping.md`](../../../base/skill-mapping.md)。 ## 今後の拡張論点 - **6 要因の網羅性** — 6 要因で「学習しない組織」の構造を尽くせるか。情報非対称性・組織政治・短期業績圧力などの追加要因を立てるべきか - **既存学習組織論との接続深度** — Argyris / Senge / Edmondson は概要のみ触れたが、各論への接続をどこまで深く書くか。文献参照（[`../appendices/references.md`](../../reference/references.md)）に逃がす範囲 - **Learning Velocity の 4 指標** — 操作的定義として 4 指標で十分か。組織学習の "質" を測る指標（例: 「同じ失敗の再発率」）を追加すべきか - **22 章 成熟度モデルとの境界** — 18 章は「学習が起きる構造」、22 章は「成熟度判定」。重複を避けつつ、両章の役割分担を明示する必要 - **17 章 AI のマーケティング活用との分担** — AI 採否ログの実装詳細は 17 章。本章では Principle 6 の理論的位置づけのみ扱う、で合っているか --- title: 文脈別テーラリング chapter: "19" part: 3-cross-cutting status: revised visibility: public authors: - claude reviewers: [] revision: 0.2 updated: 2026-05-19 related-skills: [] related-chapters: - foundations/cycle - cross-cutting/maturity-model related-knowledge: [] --- # 文脈別テーラリング ## 概要と対象範囲 業種・規模・成熟度別の CMO Marketing OS Playbook 調整指針を扱う横断参照章。各 KA 章の §X.3 Tailoring 節を横断する位置づけ。 CMO Marketing OS Playbook は省略不可な **中核条件** と、文脈に応じて軽量化・拡張する **調整可能項目** の二層に分かれる。テーラリングは「**省略の正当化を残すこと**」が条件であり、「やらなかった」と「意図して外した」は別物として扱う（[`../foundations/principles.md`](../foundations/principles.md) 補題 H）。 ## 中核条件（文脈に関わらず省略不可） これらを欠くと CMO Marketing OS Playbook が機能しない要素: - **Customer Sync の独立保持** — 規模に関係なく ICP 仮説と顧客実態を別の記録として残す - **再構築段の存在** — 1 行のメモでも良い。「何を、なぜ再構築したか」を残すこと自体が省略不可 - **本番反映前チェックの省略不可項目**（オーナー / 計測 / ロールバック） - **学ぶ段の書き戻し** — 検証済みかどうかの判定は最低限残す - **AI 出力の採否ログ** — 規模と無関係に必須 中核条件を文脈を理由に削るのは、テーラリングではなく中核条件の違反として扱う。 ## 調整可能項目（文脈で調整） | 要素 | 簡易運用（1 人 / スタートアップ初期） | 標準運用（小〜中チーム） | 厳格運用（規制業種 / 複数事業部） | |---|---|---|---| | 4 つの観測対象 | Team Sync は自分自身のみで可。Customer / Performance は必須 | 4 観測対象すべて | 4 観測対象 + 部門別並走 | | 12 KA カバレッジ | 該当 KA のみ点検 | 主要 KA を四半期に 1 回点検 | 全 12 KA、KA 別 owner、月次点検 | | 理解・分析する 4 視点 | 1〜2 視点で十分（多くは CEO + Customer） | 案件に応じて切替 | 4 視点 + 外部 advisory | | `/brand` | スキップ可（個人ブランド一致） | 案件単位 | リリース毎、法務同席 | | 本番反映前チェック 7 項目 | 省略不可の 3 項目（オーナー / 計測 / ロールバック） | 7 項目 | 7 項目 + 承認ログ + 法務 / 計測監査 | | 実行管理成果物 | 必要なものだけ | 複数人・複数日・外部依存があれば作成 | 実行計画 / ステークホルダーマップ / リスク登録簿 / 変更履歴 / リソース計画を原則作成 | | 再構築段の頻度 | 四半期 | 月次 | 週次（複数事業部の portfolio 含む） | | `/learn` 書き戻し先 | `results/` のみ | `results/` + `profile/` | `results/` + `profile/` + `organization/` + `knowledge/marketing/tool/` `knowledge/marketing/case/` | | AI 採否ログ粒度 | 1 行サマリ | 採用 / 不採用 / 理由 | 採用 / 不採用 / 理由 / 代替案 / 法務確認 | ## 文脈別ガイド ### B2B エンタープライズ - **重点**: ABM、長期商談、Sales / Product / Engineering との接面（15 章） - **重み高い KA**: 05 / 06 / 07 / 11 / 15 / 16 - **設定**: 本番反映前チェック全 7 項目、実行管理成果物ほぼ全て、承認フロー厚い ### B2B SaaS - **重点**: PLG、Product Marketing、Customer Success 連携 - **重み高い KA**: 06 / 07 / 09 / 11 / 13 - **設定**: 標準運用。Aha! Moment / TTV 中心 ### D2C / コンシューマー - **重点**: ブランド・想起、Lifecycle、SNS / インフルエンサー - **重み高い KA**: 06 / 08 / 11 / 12 - **設定**: 標準運用。クリエイティブ生産速度が KPI ### リテール（店舗 + EC） - **重点**: オムニチャネル、Retail Media、店舗連動 - **重み高い KA**: 06 / 11 / 12 / 13 - **設定**: 標準運用 + 店舗オペレーション接面 ### 規制業種（医療 / 金融 / 公共） - **重点**: 表現規制、プライバシー、承認フロー - **重み高い KA**: 06 / 15 / 16 - **設定**: 厳格運用。法務同席、承認ログ必須 ### スタートアップ（PMF 前） - **重点**: Customer Sync の独立化、再構築 週次、N1 から始める - **重み高い KA**: 06 / 07 / 09 - **設定**: 簡易運用。省略不可の 3 項目のみ厳守、他は最小化 ## テーラリングの記録 各 workspace で次を残す: - 採用パス（簡易運用 / 標準運用 / 厳格運用 / 部分カスタム） - 省略・縮約した調整可能項目と理由（文脈のどの軸に依拠したか） - 拡張した要素と理由 - 次回見直し時期（規模変化・成熟度変化のトリガ） これがないテーラリングは「忘れた」と区別がつかない。記録の有無自体が中核条件（責任設計）の一部である。 ## アンチパターン - **テーラリング名目の中核条件省略**: 「うちは小さいから」で Customer Sync を削る → CMO Marketing OS Playbook の構造的優位が消える - **省略の不文律化**: 何を外したかを記録しない → 次サイクルで再現できない - **簡易運用のまま固定化**: 規模が拡大してもテーラリングを更新しない - **厳格運用の過剰適用**: 1 人事業に承認ログと法務監査を要求 → サイクルが止まり、結局回らないので「CMO Marketing OS Playbook は重い」と誤解される - **テーラリングを「妥協」と読む**: 妥協ではなく**設計判断**。判断したことを記録すれば妥協ではない ## 関連 skill / agent - **`/next --verbose`** — テーラリングの現状診断 - **`/release`** — テーラリング再評価の触媒 ## 今後の拡張論点 - **簡易 / 標準 / 厳格運用の 3 段階で十分か** — 業種別カスタムを増やすか - **22 章 成熟度モデルとの境界** — テーラリングは Level に応じて自動推奨されるべきか - **業種別ガイドの粒度** — §19.4 は 6 業種だが、もっと細分化が必要か --- title: 機能対別プレイブック chapter: "20" part: 3-cross-cutting status: revised visibility: public authors: - claude reviewers: [] revision: 0.3 updated: 2026-05-19 related-skills: [] related-chapters: - knowledge-areas/stakeholder related-knowledge: [] --- # 機能対別プレイブック ## 概要と対象範囲 マーケと他部門・他主体との**機能対別運用テンプレート**を集約する章。15 章 ステークホルダー連携が**接面の原理**を扱い、本章はその**運用詳細**を担う。両章はセットで読まれることを前提とする。 ### 共通テンプレート 各機能対は次の構造で記述する: | 項目 | 内容 | |---|---| | **接続目的** | なぜこの対が存在するか | | **語の翻訳辞書** | 同じ語の意味差 | | **定例議題と頻度** | 何を週次 / 月次 / 四半期で話すか | | **意思決定境界** | RACI 圧縮版（誰が A、C、I か） | | **マーケティングサイクル接続点** | どの段で同期するか | | **典型的摩擦と対処** | よくある衝突パターンとその解消法 | | **1 ページ運用テンプレ** | 実際の運用に使うテンプレート | 本章は概要のみ示し、各機能対の詳細は個別ファイル（`sales.md` / `product.md` 等）に格納する（W3 段階では本 README のみ作成、個別ファイルは後続 Wave）。 ### 知識エリア別タクティカルとの境界 本章は「Marketing × Sales」「Marketing × Legal」のような**接面運用**だけを扱う。広告運用、SEO、CVR 改善のような媒体・手法別ノウハウは、それぞれ該当する知識エリアの L3 Tactical に置く。 | 対象 | 置き場所 | |---|---| | 広告運用 | [`../../knowledge-areas/content-channel/ad-operations/`](../../knowledge-areas/content-channel/ad-operations/) | | デジタル広告戦略 | [`../../knowledge-areas/content-channel/digital-advertising.md`](../../knowledge-areas/content-channel/digital-advertising.md) | | CVR 改善 | [`../../knowledge-areas/demand-lifecycle/cvr-optimization-playbook.md`](../../knowledge-areas/demand-lifecycle/cvr-optimization-playbook.md) | ## 機能対一覧 ### Marketing × Sales（sales.md） - **接続目的**: リード品質、商談接続、SLA、Revenue 共同責任 - **語の翻訳辞書**: 「リード」（MQL vs SQL）、「コンバージョン」（資料請求 vs 受注） - **典型的摩擦**: 「リードの質が低い」「商談化しない」の責任所在 - **対処**: MQL → SQL のスコアリング基準を両部門で合意、SLA で同期頻度を規定 ### Marketing × Product（product.md） - **接続目的**: JTBD 共有、launch、ポジショニング合意、ロードマップ翻訳 - **典型的摩擦**: 「ローンチ準備が遅い」「メッセージが機能寄り過ぎ」 - **対処**: JTBD を Product Marketing が橋渡し、ロードマップ翻訳プロセス化 ### Marketing × Engineering / Systems / IT（engineering.md） - **接続目的**: MarTech 導入、計測タグ実装、データ基盤接続、セキュリティレビュー、本番反映フロー - **語の翻訳辞書**: 「リアルタイム」（即時 / ≤ 60s / ≤ 1h / 翌日バッチ）、「セグメント」（配信対象 / テーブル + WHERE 句）、「本番反映」（公開 / PR → review → deploy） - **意思決定境界**: マーケが決める = 何を計測 / 配信するか、システムが決める = 実装方式・保持期間・PII 取り扱い、共同 = イベント命名規約・SLA・ロールバック条件 - **典型的摩擦**: 「とりあえずタグ入れて」、計測責任の所在、本番事故時のロールバック - **対処**: イベント仕様書（命名・プロパティ・トリガ条件）を 観測・データ収集段で必須化 ### Marketing × Data / Analytics（data-analytics.md） - **接続目的**: KPI 定義の共同所有、アトリビューションモデル、ダッシュボード - **典型的摩擦**: 「数字が違う」、ダッシュボードの管理責任 - **対処**: KPI 定義を単一の正として共有し、計測責任を 13 章 計測・MarTech に集約 ### Marketing × Finance（finance.md） - **接続目的**: 予算配分、ROMI、見込み計上、コミット精度 - **典型的摩擦**: 「予算がつかない」「ROMI が見えない」「コミットを外す」 - **対処**: leading / lagging KPI のペア運用、見込み精度を継続改善、長期投資（Brand 等）の評価軸を別立て ### Marketing × Legal / Compliance（legal.md） - **接続目的**: 表現規制（景表法・薬機法）、プライバシー、契約レビュー - **典型的摩擦**: 「審査が遅い」「ダメと言われる」 - **対処**: 表現ガイドライン整備、事前相談プロセス化、判例・規制情報を共有 ### Marketing × Customer Success / Support（customer-success.md） - **接続目的**: VoC 還流、リテンション、アドボカシー - **典型的摩擦**: 「不満が伝わってこない」「Promoter が活用されない」 - **対処**: VoC の構造化（[`../../knowledge-areas/intelligence/`](../../knowledge-areas/intelligence/)）、CS と Brand の定期同期 ### Marketing × Executive（executive.md） - **接続目的**: 戦略整合、ボードナラティブ、四半期レビュー - **典型的摩擦**: 「数字で説明しろ」vs「長期投資の価値」 - **対処**: leading / lagging KPI ペア提示、戦略 KPI と運用 KPI の階層化 ### Marketing × HR / People（hr.md） - **接続目的**: エンプロイヤーブランド、内部広報、採用マーケ - **典型的摩擦**: 「ブランドの一貫性」、内向き / 外向きメッセージのズレ - **対処**: Brand ガイドラインを HR にも適用、採用マーケで Brand リーダー連携 ### Marketing × PR / IR（pr-ir.md） - **接続目的**: コーポレートコミュニケーション、危機対応、IR メッセージ整合 - **典型的摩擦**: メッセージの不整合、危機対応の遅れ - **対処**: メッセージング Single Source、危機対応プレイブック事前整備 ### Marketing × External Agency / Vendor（agency-vendor.md） - **接続目的**: RFP、ブリーフ、納品基準、知的財産 - **典型的摩擦**: 「ブリーフが曖昧」「成果物が期待値と乖離」 - **対処**: ブリーフテンプレ整備、納品基準明示、責任境界の明文化（補題 F） - **関連**: [`estimate-playbook.md`](estimate-playbook.md)（見積り・工数計算） ## 機能対別プレイブックの執筆優先度 W3 段階では本 README のみ作成。個別ファイル（W4 以降で作成予定）の優先度: | 優先度 | 機能対 | 理由 | |---|---|---| | **High** | Sales / Engineering / Data-Analytics | 最も頻繁に摩擦が発生、運用詳細の価値高 | | **Mid** | Product / Finance / Executive | 中頻度、戦略連動 | | **Low** | Legal / Customer Success / HR / PR-IR / Agency-Vendor | 業種により頻度大きく変動 | ## アンチパターン（章共通） - **テンプレを書いて満足**: プレイブックを作って終わり、実運用で参照されない - **個別最適化**: 各対別に最適化し、機能対間の整合性が崩れる - **「うちは特別」**: 全機能対で標準テンプレを適用せず、属人化を許容 - **更新の停滞**: 一度書いたプレイブックを更新せず、組織変更・ツール変更に追従しない ## 関連 skill / agent - **`/listen team-org`** — 組織全体の認識整理 - **`/insight consultant`** — 第三者視点での接面摩擦の検出 ## 今後の拡張論点 - **個別ファイル化のタイミング** — W4 のどのタイミングで sales.md / engineering.md 等を個別作成するか - **共通テンプレートの粒度** — §20.1.1 の 7 項目で十分か、もっと項目を絞るか - **業種別 playbook** — 機能対の運用は業種により大きく変わる。19 章 Tailoring との連動方法 - **外部主体（Agency / Vendor）の扱い** — 内部部門と同じテンプレで扱うか、別フォーマットにするか --- title: 参照ケース chapter: "21" part: 3-cross-cutting status: revised visibility: public authors: - claude reviewers: [] revision: 0.2 updated: 2026-05-19 related-skills: [] related-chapters: [] related-knowledge: - knowledge/marketing/case/ --- # 参照ケース ## 概要と対象範囲 マーケティングサイクル × 12 KA の典型適用例を蓄積する参照層。事例本体は [`../../case/`](../../case/) に置き、本章は**それらに マーケティングサイクル段マッピングを与える索引**として機能する横断参照章である。 事例は理論を検証する素材であり、抽象論だけでは把握しづらい運用感を補完する。同時に「他社が成功したから自社も同じ」という単純模倣（[`../knowledge-areas/intelligence/`](../knowledge-areas/intelligence/) §6.6 アンチパターン）を防ぐため、**事例の文脈と判断を明示**することを重視する。 ## 事例一覧（v0.2） ### GM vs Ford（1920s） カテゴリ再設計とポジショニング転換の参照ケース。 - **本体**: [`../../case/gm-defeats-ford-1920s.md`](../../case/gm-defeats-ford-1920s.md) - **マーケティングサイクル段マッピング**: - **観測・データ収集**: 顧客の購買動機の変化（実用 → ステータス）の観測 - **理解・分析する**: 「車種別の階層」というカテゴリ再定義 - **再構築**: 「単一車種で勝つ」前提の再構築 - **起動・実装する**: 階層別ブランド展開（Chevrolet → Cadillac） - **学ぶ**: モデルチェンジサイクルの確立 - **関連 KA**: 07 ICP・ポジショニング、08 ブランド・ナラティブ、12 コンテンツ・チャネル運用 - **教訓**: 既存カテゴリの再定義が、機能優位より持続的に勝てる ### （以降、事例が増えるごとに追記） 事例の追加基準は §21.4 に従う。 ## 事例の読み方 各事例を マーケティングサイクル × 12 KA のどこに位置づけるかを記述する。読み手は次の順序で事例を読む: 1. **文脈**: いつ、どこで、誰が、何を達成したか 2. **観察**: 何が起きていたか（観測・データ収集段の入力） 3. **判断**: どんな 再構築を行ったか（再構築段） 4. **実行**: 何を本番反映したか（起動・実装する段） 5. **検証**: 何が検証されたか / 何が外れたか（学ぶ段） 6. **転用条件**: 自社に転用できる前提条件 特に **6（転用条件）** が重要。「成功した」だけでは転用できない。 ## 事例追加の基準 事例は次の条件を満たす場合に追加する: - **検証可能性**: 公開情報 or 自社一次情報で検証できる - **マーケティングサイクル段マッピング可能性**: サイクルのどの段に該当するかが明確 - **転用条件の明示**: どの文脈で適用可能 / 不可能か言語化できる - **時期の明示**: 「いつの事例か」を明示（古い事例は外部環境前提が崩れている可能性がある） 「面白い話」だけで追加すると、転用できない事例集になる。検証可能性と転用条件を満たさない事例は本章ではなく [`../../case/`](../../case/) の inbox 扱いとする。 ## アンチパターン - **単純模倣**: 「他社がやっているから自社も」。文脈差を無視 - **生存者バイアス**: 成功事例だけを集め、同じことをやって失敗した事例を見ない - **事例の過剰一般化**: 1 事例から普遍法則を導く - **古い事例の温存**: 外部環境が変わった事例を更新せずに使い続ける - **事例の網羅幻想**: 大量に集めれば判断が良くなるという誤認 ## 関連 skill / agent - **`/insight consultant`** — 事例の文脈差を第三者視点で評価 - **`/listen market`** — 競合事例の継続取得 ## 今後の拡張論点 - **事例本体の所在** — [`../../case/`](../../case/) に置くか、CMO Marketing OS Playbook 内に取り込むか - **失敗事例の扱い** — 成功事例と失敗事例を同じフォーマットで蓄積するか、別ファイルに分けるか - **事例の更新サイクル** — 古くなった事例の見直し頻度 - **自社事例 vs 他社事例の比率** — 自社事例の方が transferable だが、サンプル数が少ない --- title: マーケティング OS 成熟度モデル chapter: "22" part: 3-cross-cutting status: revised visibility: public authors: - claude reviewers: [] revision: 0.2 updated: 2026-05-19 related-skills: [] related-chapters: - foundations/performance-domains - knowledge-areas/integration-strategy - cross-cutting/org-learning related-knowledge: [] --- # Marketing OS 成熟度モデル ## 概要と対象範囲 組織の Marketing OS 成熟度を**5 段階で評価する**モデル。CMO 株式会社の診断サービス（[`/services/marketing#diagnose`](/services/marketing#diagnose)）の理論基盤として機能する。 本章は次の 3 つを定義する: - **5 段階の Level 定義**: 各 Level の判定基準 - **評価軸**: 何を測って Level を判定するか - **Level Up の経路**: ある Level から次の Level に到達するための典型的な道筋 成熟度評価は内部評価（自己診断）と外部評価（コンサルによる診断）の両方で運用できるよう設計する。 ## 5 段階モデル | Level | 名称 | 特徴 | |---|---|---| | **Level 1** | **Ad-hoc**（場当たり的） | 施策単位の PDCA、組織学習なし。サイクルとして回っていない | | **Level 2** | **Defined**（定義済み） | マーケティングサイクルを意識的に運用、文書化あり。観測・データ収集 / 起動・実装する / 学ぶの最低限がある | | **Level 3** | **Measured**（計測可能） | Performance Domains で計測、本番反映前チェックの省略不可項目と Evidence Level の運用が成立 | | **Level 4** | **Optimized**（最適化） | Customer Sync 独立化、再構築段の機械的運用、AI 採否ログが必須項目 | | **Level 5** | **Adaptive Learning**（自律学習） | AI / agent による自律的学習、Learning Velocity が組織能力として明示的に管理される | PMI の CMMI モデルを参照しつつ、マーケティング特有の論点（Customer Sync、再構築、AI 採否ログ）を組み込んだ構成である。 ## 評価軸 各 Level の判定は次の 6 軸 × 12 KA のマトリクスで行う。 ### 6 軸 | 軸 | 測定対象 | |---|---| | **プロセス成立度** | マーケティングサイクルの各段が運用されているか | | **計測の意思決定接続度** | KPI が意思決定 KPI として機能しているか（補題 E） | | **組織学習度** | Learning Velocity の 4 指標（[`./org-learning.md`](org-learning.md) §18.5） | | **責任設計度** | RACI の明示、AI 採否ログの記録、A の 1 名集約 | | **観測対象独立度** | Customer Sync が ICP 仮説と分離されているか | | **横断統合度** | 12 KA 間の整合性、15 章 ステークホルダー連携の機能度 | ### 評価マトリクス 6 軸 × 12 KA で 72 セルになる。実運用ではすべてを毎回評価するのは過剰なので、診断目的に応じて切り出す: - **クイック診断（3〜5 分）**: 6 軸を全体で評価（12 KA に展開しない） - **標準診断（30 分）**: 6 軸 × 主要 5 KA - **詳細診断（半日）**: 6 軸 × 全 12 KA ## 各 Level の判定基準 各軸で次の基準が成立するか: ### Level 1 → Level 2 への到達条件 - マーケティングサイクルが**形式上**運用されている（最低限の 観測・データ収集 / 起動・実装する / 学ぶ） - マーケ部門が「何をしているか」が文書化されている - 主要 KA（07 / 08 / 12）の現状が言語化されている ### Level 2 → Level 3 への到達条件 - KPI が 5 軸評価を通過している（補題 E） - 本番反映前チェックの省略不可項目（オーナー / 計測 / ロールバック）が必須項目として運用されている - Evidence Level（E0〜E3）の判定が記録されている - Performance Domains の少なくとも 4 つが定期観測されている ### Level 3 → Level 4 への到達条件 - Customer Sync が ICP と独立した記録として運用されている - 再構築段が独立段として機械的列挙の運用を持つ - AI 採否ログの 4 要素（採否 / 判断者 / 理由 / 代替案）が必須項目 - Learning Velocity の 4 指標が観測されている ### Level 4 → Level 5 への到達条件 - AI agent が自律的にサイクルを部分実行（観測・データ収集自動集約・理解・分析する補助等） - Learning Velocity が組織能力として明示的に管理される - 12 KA 間の整合性監査が定期実行される - 機能対別 RACI（15 章 §15.6）が全機能対で明示されている ## Level Up の典型経路 組織が Level を上げる際の典型的な道筋: - **Level 1 → 2**: マーケティングサイクルの**用語**と**書き戻し先**を導入する - **Level 2 → 3**: KPI の 5 軸評価を導入し、本番反映前チェックを運用化する - **Level 3 → 4**: Customer Sync を独立 path に分離し、再構築段を週次 / 月次で運用する - **Level 4 → 5**: AI agent を採否ログ前提で導入し、Learning Velocity を管理指標化する 各遷移には 6 ヶ月〜2 年程度を要するのが典型的。短縮しようとすると、形式的な達成（後述のアンチパターン）に陥る。 ## 診断質問群 ### クイック診断（5 分版） 各軸について 5 段階で自己評価: 1. マーケティングサイクル（観測・データ収集 / 理解・分析する / 再構築 / 起動・実装する / 学ぶ）のどれが運用されているか 2. KPI に対し「何が起きたらどう意思決定するか」が事前に決まっているか 3. 失敗の事後録が `results/` 等に書き戻されているか 4. AI 出力の採否ログが記録されているか 5. ICP 仮説と顧客実態が別の記録として保持されているか 6. 他部門との RACI が明示されているか 合計スコアで Level 1〜5 を判定。詳細な自己診断は [`/diagnose`](/diagnose) を参照。 ### 標準診断・詳細診断 CMO 株式会社の診断サービスとして提供。本書では設問の骨子のみ示し、具体的な質問項目は別途運用される。 ## アンチパターン - **自己評価バイアス**: 「うちは Level 4」と言いたがる。実態は Level 2 / 3 が多い - **Level 詐称**: 表面的な形式（ドキュメントの存在）だけで Level を判定し、運用実態と乖離 - **Tool 導入 = Level Up の誤認**: MarTech を導入したから Level が上がったと誤認。プロセス成立度は別軸 - **Level 5 への急行**: AI 導入で Level 4 / 5 に飛ぼうとし、Level 2 / 3 の基礎を欠いたまま自動化 - **Level の絶対化**: Level が高いほど良い、と単純化する。業種・規模により最適 Level は変わる - **Level Up を KPI 化**: Level Up 速度を成果指標にし、形式的な達成を誘発する ## 関連 skill / agent - **`/next --verbose`** — 現在地と次の一歩を提示（実質的な簡易診断） - **`/insight ceo`** — 経営視点での組織成熟度評価 ## 今後の拡張論点 - **5 段階 vs 7 段階** — CMMI は 5 段階。Sirius Decisions / Forrester は 4 段階や 6 段階を採用。CMO Marketing OS Playbook が 5 で十分か - **業種別の最適 Level** — 規制業種・スタートアップ・大企業で「目指すべき Level」は異なる。テーラリング（19 章）との連動 - **客観的判定の難しさ** — 自己評価バイアスを補正する仕組み（外部診断・複数評価者）の標準化 - **Level Up 経路の科学性** — §22.5 の典型経路は仮説的。事例蓄積による検証が必要 - **22 章と 18 章の境界** — 18 章「学習が起きる構造」と 22 章「成熟度判定」の役割分担。重複を避ける運用