マーケティングサイクル

定義

マーケティングサイクル は Marketing OS の canonical マーケティング OS である。AI エージェントと協働しながら学習し続ける、マーケ組織のためのオペレーティング・システムであり、個別フレームワーク（AARRR・STP・RAM-CE 等）の上位に位置して、それらを組織学習として機能させるための型を定義する。

5 段階のサイクル ── 観測・データ収集 → 理解・分析する → 再構築 → 起動・実装する → 学ぶ。

観測・データ収集 ─→ 理解・分析する ─→ 再構築 ─→ 起動・実装する ─→ 学ぶ ─┐
   ↑                                                    │
   └────────────────────────────────────────────────────┘
              （学ぶの終端は次サイクルの観測・データ収集の起点）

段	動詞	性格	役割
観測・データ収集	観測・データ収集	入力	4 つの観測対象（Team / Customer / Market / Performance）から認識・実態を取り込む
理解・分析する	理解・分析する	出力	視点を切り替えて選択肢と判断材料を出す。JTBD・ICP 差分・Positioning 機会を言語化する
再構築	再構築する	認知の再構築	既成 KPI・聖域・「ねばならない」を機械的に列挙し、前提を組み替える余白を作る
起動・実装する	起動・実装する	実行・本番反映	セグメント × チャネル × コンテンツに実装し、計測同時着地で本番反映する
学ぶ	学ぶ	還流	結果を ICP / Positioning / Playbook に書き戻し、次サイクルの観測・データ収集の入力に変える

なぜマーケティングサイクルか

マーケ OS の独自性は「顧客との同期」を構造に埋めること

汎用の組織学習ループ（OODA / PDCA / Double-Loop Learning）は、内部の意思決定サイクルを駆動するためのものである。マーケティングがこれらと違うのは、意思決定の前提として「顧客との継続的な同期」を構造に埋めなければ機能しないことだ。マーケティングサイクルが 観測・データ収集 を 4 つの源（中でも Customer Sync を独立源）として明示しているのは、これを OS レベルで強制するためである（詳細は観測・データ収集節）。

再構築を骨格名に昇格させる

マーケ組織の最大のボトルネックは、引き継いだ KPI・看板施策・「ねばならない」が思考を縛ること。マーケティングサイクルが 再構築（既成枠の組み替え）を骨格名に昇格させているのは、再構築を独立段として死守することで、閉じた最適化（既存 "Adaptive Marketing" / Real-time Marketing 系統の戦術最適化高速化）と差別化するためである。再構築は OODA / PDCA との差別化軸でもある。

マーケティングとは何か — 最適化としての定義

マーケティングサイクルが前提とするマーケティングの定義（marketing-structural-issues.md 冒頭）：

マーケティングとは、最適化である。

勝者になることでも数字を増やすことでもなく、自社の能力・リソース・現在地に合わせて適した戦略・目標・ポジショニング・チャネル・KPI を選び、整合させ続ける営為。

ただし「最適化」は二種類に分かれる。マーケティングサイクルが目指すのは 開かれた最適化 である:

閉じた最適化 — 自部署で観測できる特定指標（CPA / CVR / CTR / PV 等）だけをループに入れる戦術最適化。Adaptive Marketing 系統。前提（KPI・ICP・施策ラインナップ）は固定で、運用パラメータだけが動く。機能不全のマーケ組織はほぼ例外なくここに退避している
開かれた最適化 — 顧客・市場・現場・経営・実績の全階層の声を入力にし、前提自体（KPI・ICP・施策・聖域）を最適化対象に含める。観測・データ収集の 4 つの観測対象 + 再構築で前提を組み替える + 学ぶ段で結果を前提に書き戻す、というマーケティングサイクルの構造そのもの

マーケティングサイクルの 5 段階は、この開かれた最適化を組織として継続できる形に動詞化したもの。起動・実装する（適合させて本番反映する）は最適化の動詞化、観測・データ収集は入力の開放、再構築は前提の再構築、学ぶは前提への書き戻し ── どれが欠けても閉じる方向に退避する。詳細な対比（閉じた最適化 vs 開かれた最適化）は marketing-structural-issues.md の「閉じた最適化 vs 開かれた最適化」節を参照。

観測・データ収集段のカバレッジチェック

観測・データ収集段で「自社のマーケがどの領域をカバーできていて、どこが空白か」を点検するためのカバレッジモデルは、CMO Marketing OS Playbook の 12 知識エリア（knowledge/marketing/playbook/）を参照する。空白 KA は次サイクルの観測・データ収集の入力 / 再構築候補になる。

5 段階の詳細

観測・データ収集

原則: マーケはチームの頭の中だけでは動かない。4 つの独立した観測対象を継続的に取り込み続けることが、すべての判断の起点になる。サイロの中で持っている情報は、組織にとって存在しないのと同じ。

観測・データ収集の 4 つの観測対象

観測対象	内容	主なソース	書き込み先（例）
1. Team Sync（内部認識）	メンバー間の言葉・前提・存在意義・優先順位	サーベイ・対話・各メンバーの独立記述	`memory/organization/` `memory/workspaces/active/profile/`
2. Customer Sync（顧客同期）	顧客の生の声・行動・反応・JTBD・離脱理由・刺さった言葉	営業ログ / サポート問い合わせ / レビュー / SNS 言及 / サイト行動 / 購買履歴 / 解約理由 / インタビュー	`memory/workspaces/active/profile/customer-signal.md`（推奨）/ `customer-research-jtbd.md` を参照
3. Market Sync（市場・競合同期）	競合の動き / プラットフォーム仕様 / 業界トレンド	外部揮発情報、競合 SERP、広告ライブラリ	`knowledge/marketing/tool/`（プラットフォーム仕様）/ `knowledge/marketing/case/`（事例）
4. Performance Sync（自社実績同期）	過去の成功 / 失敗 / 現状数値 / ベースライン	GA4 / 広告管理画面 / 売上 / 解約レポート	`memory/workspaces/active/results/`

なぜ Customer Sync を独立源として置くか

顧客情報を「ICP」（内部仮説）と「Performance Data」（メトリクス）だけに吸収すると、構造的に 「ICP 仮説 ≠ 実際の顧客」のズレを検出できない。マーケティングサイクルは Customer Sync を独立源として置くことで:

仮説（ICP）と実態（Customer Sync）のズレが自動的に再構築段の入力になる
顧客の生の言葉が KPI ノイズに埋もれずに残る
**「自社の最適は誰の最適か」**が常に問い直される構造が組み込まれる

これがマーケ OS と汎用組織学習ループ（OODA / PDCA）を分かつ最大の構造的違いである。

やること

言葉の定義を揃える: 「マーケティング」「成果」「顧客」「施策」がチーム内で同じ意味を指しているかを確認する
個人の存在意義を言語化する: 各メンバーが「自分は事業のどの課題に効いているのか」を自分の言葉で言える状態にする
同期的戦略の駆動: 各メンバーが独立に書き出した認識（自社認識 / 市場認識 / 目標 / 優先順位）を同期して合成する。一致箇所を確からしい前提に、不一致箇所を再構築の入力にする（詳細は marketing-structural-issues.md Section 0.7）
顧客接点の構造的吸い上げ: 営業・サポート・解約・レビュー・問い合わせ・サイト行動を、個人の頭の中ではなく customer-signal.md 等に書き戻す
市場・競合・プラットフォームの揮発情報を /listen market 経由で取り込む
過去の成功・失敗、現在のパフォーマンスを memory/results/ に記録する

観測・データ収集が成立しているかのチェック

チーム内で「マーケティング」が指す範囲が一致しているか
各メンバーが自分の役割を職能ではなく事業課題への寄与で語れるか
Customer Sync が独立した記録として残っているか（performance metrics に埋もれていないか）
直近の顧客接点ログ（営業・サポート・レビュー）が memory に書き戻されているか
[TODO] が残っていないか
「弊社は」ではなく具体的な固有名詞・数値で書かれているか
担当者の頭の中だけにある情報がないか（属人化検出）

担い手スキル

/listen team-org（Team Sync）/ /listen team-brand（Team Sync）/ /listen team-workspace（Team Sync）/ /listen customer（Customer Sync）/ /listen market（Market Sync）/ /workspace

Customer Sync は /listen customer で profile/customer-signal.md に顧客の生の声・行動ログを独立に保持する。ICP 仮説は icp.md、顧客実態は customer-signal.md に分ける（customer-research-jtbd.md プレイブック参照）。

理解・分析する

原則: データそのものは理解・分析ではない。「何を理解しているか／していないか」「どの視点で何を理解・分析するか」を意識的に切り替えなければ、観測・データ収集で集めたシグナルは雑音のまま終わる。漠然とした問いには漠然とした答えしか返らない。

やること

視点を切り替えて選択肢と判断材料を出す（ceo / consultant / gemba / customer）
JTBD（Job To Be Done）・潜在需要・購買決定要因を顧客の言葉で理解・分析する
自社の Positioning と市場期待のギャップを言語化する
既存施策の効率と感応度（marketing-structural-issues.md Section 2.2）を診断する
何を理解しているか／していないかを実測する（サーベイ・診断・既存成果物のレビュー）

良い理解・分析の構造

誰の視点で（ceo / consultant / gemba / customer）
何を（評価 / 制作 / 分析 / 比較 / 予測）
どの深さで（案出し 3 つ / 完成品 / レビュー付き / A/B パターン）
何を判断基準に（ICE / ROI / ブランド整合 / CVR 予測）
どの形式で（表 / チェックリスト / コード / 原稿）

理解・分析のサブタイプ

サブタイプ	何をするか	主な skill / playbook
Design	ゼロから設計（戦略 / ICP 仮説 / LP 構成案 / キーワード戦略）	`seo-playbook.md` `customer-research-jtbd.md` とインライン対話
Review	既存成果物を評価（コピー / LP CVR / 広告整合 / 経営インパクト）	`/insight ceo` `/insight customer` `/brand`
Analytics	データから理解を更新する	`web-analytics-practice.md` `measurement-incrementality.md`

サイクル内での回り方

Design 理解・分析 → 起動・実装する（叩き台の反映） → Review 理解・分析 → 起動・実装する（本番反映） のように、理解・分析と起動・実装するが入れ子で回る。

担い手スキル

/insight <ceo|consultant|gemba|customer> と /brand（判断チェック）。専門領域の Design / Analytics は knowledge/base/ のプレイブックを参照しながらインライン対話で進める。

再構築

原則: マーケ組織の最大のボトルネックは、既成の KPI・聖域・「ねばならない」が思考を縛ること。これらを意識的に再構築しない限り、前提の組み替えは起きない。

再構築は本番反映ではない。本番反映は起動・実装するの責務。再構築は認知・前提・組織心理の組み替えである。

やること

「ねばならない」を一旦再構築の対象にする（KPI・スケジュール・既存の戦略）
引き継いだ KPI を機械的に列挙し、P0–P3 の整合性で篩にかける（marketing-structural-issues.md Section 2.1）
走っている施策を列挙し、感応度 High / Mid / Low で篩にかける（同 Section 2.2）。Low は撤退候補
聖域（過去の意思決定 / 看板施策 / 既存 ICP 像 / 慣習チャネル）を否定して並べる
観測・データ収集段の Customer Sync が示す実態と既存 ICP 仮説のズレを並べ、仮説の方を再構築候補にする
観測・データ収集段で出た「不一致箇所」を再構築候補として読み直す
個人が抱えている負荷を表に出して解放する
ゼロベースで「もし制約がなかったら何をするか」を問い直す

再構築が成立しているかのチェック

「現状の KPI に縛られない場合、別の指標になりうるか」が議論されたか
「聖域として触れていなかった前提」が機械的に列挙されたか
P3 × Low（経営に紐付かず施策にも反応しない指標）がゼロになっているか
既存 ICP 仮説 vs Customer Sync 実態のズレが再構築候補に含まれたか
「ねばならない」と「やりたい」が区別されているか
チームメンバーが個別に抱えている負担・不満が場に出ているか
捨てた後に「最後まで残る一本」が言語化されているか（marketing-structural-issues.md Section 0.4）

重要な制約

再構築は人間にしか引き受けられない判断である。AI は「聖域」「前提」「ねばならない」を機械的に列挙できるが、実際に再構築の決断は人間に残る。組織政治を超えて「これは違う」と言うのは AI の役割ではない。

担い手スキル

/release（前提・KPI・聖域の機械的列挙→再構築議論の触媒）/ /insight consultant（外部コンサル視点でのゼロベース率直レビュー）

起動・実装する

原則: 自社プロダクトの実力に適合しない目標は、いくら立派でも機能しない。自分たちのプロダクトに何ができるかを正確に理解した上で、適した目標とステップに再構成し、本番環境で動く形に落として、計測可能な状態で稼働させる。

マーケティングの定義そのもの: マーケティングとは最適化である ── 自社の能力・リソース・現在地に合わせて適した戦略・目標・ポジショニングを選び続けること。起動・実装するはこの定義を段階として動詞化したものである。正解は一つではない。

やること

適合: 自社の実力・リソース・制約に適合した目標とステップを再構成する
セグメント × チャネル × コンテンツの実装: 誰に / どこで / 何を / どう届けるかを具体化
本番反映: 原稿公開、広告入稿、LP デプロイ、価格変更、解約フロー改修 ── 本番環境に反映されて初めて起動・実装する完了
計測の同時着地: UTM / 計測タグ / コンバージョン設定 / A/B テスト分岐を同じリリースで揃える
ベースライン記録: 本番反映時点の事前数値を memory/workspaces/active/results/ に記録

起動・実装するの責務

選ぶ: 複数案の中から自社の文脈に最も合うものを選択する
削る: AI が出しがちな冗長な要素・汎用的な装飾を削る
足す: AI が持ちえない現場の暗黙知・1 次情報を足す
本番反映する: 本番環境に反映する
計測する: ベースラインと差分が測れる状態を作る

担い手

専門領域の実行 skill は持たず、knowledge/base/ プレイブックを参照しながらインライン対話で進める：

領域	参照する knowledge/base/
広告運用	`digital-advertising.md`
コンテンツ制作	`content-marketing.md` `narrative-storytelling.md`
CVR 最適化（page / signup-flow / onboarding / form / popup / paywall）	`cvr-optimization-playbook.md`
価格設計	`pricing-strategy.md`
解約防止・リテンション	`retention-lifecycle.md`
顧客調査	`customer-research-jtbd.md`
見積り・工数計算	`estimate-playbook.md`
ブランド戦略	`brand-strategy.md`
UI / LP レビュー	`cvr-optimization-playbook.md` の page セクション
データ分析・計測	`web-analytics-practice.md` `measurement-incrementality.md`

ブランド適合の判断には /brand を使う。本番反映の可否そのものは、以下の本番反映前チェックで確認する。

本番反映前チェック

起動・実装するは skill を持たないが、本番反映の前に以下 7 項目を満たす。これは PMBOK 風の重い承認プロセスではなく、本番反映・計測・責任の所在を同時に成立させるための軽量な確認手順である。対応する成果物は agent-catalog.md の成果物カタログに定義する。

項目	確認すること	対応する成果物
オーナー	結果に責任を負う個人が 1 名決まっているか。チーム名だけで済ませていないか	`activation-brief.md`
範囲	何を出すか / 出さないか、対象セグメント、対象チャネル、対象期間が明確か	`activation-brief.md`
予算	媒体費・制作費・工数・外注費の上限が決まっているか。超過時の判断者がいるか	`activation-brief.md`
リスク	ブランド、法務、顧客体験、計測、オペレーション上のリスクを列挙したか	`activation-brief.md` / `approval-log.md`
計測	事前数値、判定指標、観測期間、計測方法、成功 / 撤退条件が決まっているか	`measurement-plan.md`
承認	ブランド・法務・予算・実装の承認が必要な場合、誰がいつ承認したか残っているか	`approval-log.md`
ロールバック	何が起きたら止めるか、止める権限者、元に戻す方法が決まっているか	`measurement-plan.md`

起動・実装する段の実行管理成果物（PMBOK 由来の軽量補助線）

本番反映前チェックは本番反映可否の最低条件であり、複数人・複数日・外部依存・承認・高リスクを含む施策では、それだけでは実行管理が薄くなる。そこで PMBOK のガバナンス、スコープ、スケジュール、財務、ステークホルダー、リソース、リスクの観点を、起動・実装する段にだけ軽量な成果物として取り込む。

成果物	PMBOK 的な補完観点	何を管理するか	使う条件
`delivery-plan.md`	スケジュール / 統合管理	マイルストーン、依存関係、ブロッカー、本番反映日	複数日・複数人・外部依存がある
`stakeholder-map.md`	ステークホルダー / ガバナンス	承認者、相談先、通知先、反対・懸念の所在	承認・部門調整・顧客影響がある
`risk-register.md`	リスク	リスク、トリガ、軽減策、発生済みの問題、エスカレーション	高インパクトリスクがある
`change-log.md`	スコープ / 変更管理	スコープ、予算、KPI、スケジュール、ロールバック変更の理由と承認者	起動・実装する中に重要変更が発生した
`resource-plan.md`	リソース / 財務 / 調達	社内工数、外注、ツール、AI 委譲範囲、実行余力リスク	工数・外注・AI 委譲が成果に影響する

これらはマーケティングサイクルの中核条件ではない。簡易運用では必要なものだけ、標準運用 / 厳格運用では本番反映前に要否を判断する。重要なのは「PMBOK を全面導入する」ことではなく、マーケティングサイクルが弱くなりやすい実行管理を起動・実装する段に限定して支えること。

進行不可条件

以下のいずれかに該当する場合、Marketing OS 上では起動・実装する未成立と扱う。例外的に本番反映する場合も、例外理由を activation-brief.md に残す。

オーナー不在: 結果に責任を負う個人がいない
範囲不明: 対象セグメント・チャネル・期間・対象外範囲が曖昧
計測不在: 事前数値、判定期間、撤退条件がない
リスク未確認: ブランド毀損・法務・顧客体験・計測破綻のいずれかを見ていない
承認不在: 承認が必要な施策なのに承認ログがない
ロールバック不在: 広告停止、LP 差し戻し、価格戻し、配信停止などの手順がない

本番反映前チェックを通っていない本番反映は、実行作業としては完了していても学ぶ段で比較・責任・再現ができない。したがって「やった」ではなく「組織学習に接続されていない実行」として扱う。

起動・実装するの同時着地条件

「本番反映して完了」の定義に以下を加える:

計測実装: UTM / 計測タグ / コンバージョン設定 / A/B テスト分岐
ベースライン記録: 本番反映時点の事前数値を results/ に記録
チェック痕跡: 法務・ブランド・予算などの承認ログ（該当する場合のみ）

計測されていない本番反映は学ぶ段で比較対象を失う。

学ぶ（学ぶ）

原則: 本番反映した結果は、書き戻されて初めて次サイクルの前提になる。書き戻されない学びは個人の頭の中にだけ残り、組織知にならない。学ぶは単なる「振り返り」ではなく、次サイクルの観測・データ収集の入力を能動的に作る段階である。

やること

結果の収集: 本番反映後の数字（CVR / CPA / ROAS / 順位 / 売上）と定性（顧客反応 / 営業の声 / サポート問い合わせ）を集める
4 軸で整理:
- Funnel Conversion: ファネル段階ごとの転換率変化
- Segment Response: セグメント別の反応差
- Attribution: チャネル・接点の寄与
- Unit Economics Update: LTV / CAC / Payback の更新
書き戻し: 検証済みの知見だけを以下に書き戻す
- memory/workspaces/active/results/ — 実績数値・施策検証ログ
- memory/workspaces/active/profile/ — ICP / Positioning の更新（仮説ではなく検証済みの事実のみ）
- memory/workspaces/active/profile/customer-signal.md — 顧客の新しい声・行動パターン
- knowledge/marketing/tool/ — ツール・プラットフォーム別の揮発情報（仕様変更・運用 Tips）
- knowledge/marketing/case/ — 検証済み事例として一般化できる学び
AI 出力の採否ログ: AI が出した提案のうち何を採用し何を捨てたか、なぜかを /learn の差分セクションに残す（responsibility-design.md）
次サイクルへの引き継ぎ: 残課題と新仮説を観測・データ収集段の入力として明示する

Evidence Level（知見の格上げ基準）

学ぶ段で扱う情報は、検証度に応じて E0〜E3 に分類する。これは「思いつき」を profile 層に混入させないための基準であり、/learn の検証チェックより上位の共通語彙である。

Level	定義	置き場所	profile 反映	例
E0: Hypothesis	未検証の仮説・解釈・アイデア	`output/` / `results/` の Archive	不可	「この訴求は刺さるはず」
E1: Observation	単発の観測。顧客の声、1 施策の結果、少数サンプル	`customer-signal.md` / `results/`	不可	インタビュー 1 件、広告 1 本の反応
E2: Repeated Signal	複数接点・複数施策・十分な期間で同じ傾向が再現	`results/` + profile 反映候補	承認後に可	複数商談で同じ反論、2 週間以上の広告傾向
E3: Validated Learning	数値・定性・顧客行動が揃い、反証条件も確認した検証済み知見	`profile/` / 必要に応じて `knowledge/marketing/tool/` `knowledge/marketing/case/`	可	ICP の更新、Positioning の修正、真の ROAS 係数

Evidence Write Rules

E0 / E1 は profile に書かない: 次サイクルの前提を汚染するため。results/ や customer-signal.md に観測として残す
E2 は profile 反映候補: /learn で差分を提示し、ユーザー承認後に profile/ へ反映する
E3 は検証済み知見: profile/ に反映できる。外部環境・プラットフォーム仕様など workspace 固有でないものは knowledge/marketing/tool/（ツール仕様）/ knowledge/marketing/case/（事例）に残す
knowledge/base/ へは直接昇格しない: 複数 workspace で再現し、汎用プレイブックとして抽象化できる場合のみ、別途レビューして反映する
Evidence Level は下げられる: 後続サイクルで反証が出た場合、E3 を E2 / E1 に戻し、profile の記述も修正候補にする

学ぶが成立しているかのチェック

結果の数字と定性が両方残っているか
「うまくいった理由 / うまくいかなかった理由」が仮説ではなく検証済みの言葉で書かれているか
Customer Sync 側に新しい知見が書き戻されているか（数値メトリクスだけで終わっていないか）
次サイクルの観測・データ収集に渡す引き継ぎ事項が明文化されているか
AI 出力の採否ログが残っているか

担い手スキル

/learn（次サイクルへの還流チェック）/ /listen market（外部揮発情報の更新）

マーケティングサイクルのスキル対応表

観測・データ収集	理解・分析する	再構築	起動・実装する（本番反映）	学ぶ（還流）	Meta / Ops
`/listen team-org`	`/insight ceo`	`/release`	`knowledge/base/` プレイブック参照のインライン実行	`/learn`	`/next`
`/listen team-brand`	`/insight consultant`				`/next --verbose`
`/listen team-workspace`	`/insight gemba`				`/workspace`
`/listen customer`	`/insight customer`
`/listen market`	`/brand`

設計思想: 専門領域の実行（広告運用・コンテンツ・CVR 最適化・価格・解約・調査・分析・UI レビュー・見積り）は skill 化せず knowledge/base/ のプレイブックでカバーする。skill は「サイクルを駆動する」「workspace 知識を前提に判断する」役割に絞る（詳細: agent-catalog.md）。

/next と /next --verbose は Meta（サイクル全体の進行確認）として運用する。

アンチパターン

観測・データ収集丸投げ: 「とにかくいい感じで」── AI は平均的な回答しか返せない
Customer Sync の不在: ICP 仮説と Performance Data だけで観測・データ収集を済ませ、顧客の生の声を構造的に取り込まない ── 「ICP ≠ 実態」を検出できなくなる
理解・分析するの過剰: 1 つのプロンプトで 10 個聞く ── どれも中途半端になる。1 サイクル 1 目的
理解・分析する量産: 観測・データ収集段の不一致を再構築に渡さず、理解・分析する段で AI に「正解の戦略」を量産させる ──「より洗練された無意味さ」を再生産する（marketing-structural-issues.md Section 0.5）
再構築不在: 「現状の KPI を疑う」プロセスを飛ばして起動・実装する段に進む ── 既成の失敗パターンを再生産する
再構築の儀式化: 「とりあえず再構築した」と言うだけで、引き継ぎ KPI も看板施策も実際は残る ── 再構築したのは言葉だけ
「強み信仰」での施策増殖: 再構築で篩にかけずに起動・実装する段で施策を増やし続ける ──「何かやらなきゃ」と「上手く行かなそう」の挟撃に対する防衛反応そのもの（marketing-structural-issues.md Section 0.4）
起動・実装する偏重（本番反映の欠落）: レビューレポートを読んで満足 ── 本番反映がなければ何も変わらない
計測の取りこぼし: 本番反映を急ぎ、UTM / 計測タグ / ベースライン記録を省略 ── 学ぶ段で比較対象を失う
学ぶの断絶: 本番反映した施策の結果を memory に書き戻さない ── 次サイクルが毎回ゼロから始まる
観測・データ収集汚染: 検証されていない仮説を事実として memory/profile/ に書く ── 以降全ての出力が歪む
「AI が言ったから」病: AI の出力を判断の根拠にする ── 責任の所在が組織から蒸発する（詳細 responsibility-design.md）

Practitioner's Checklist

新しい施策に着手する前に以下を確認:

観測・データ収集: 4 つの観測対象（Team / Customer / Market / Performance）が最新か？ [TODO] が残っていないか？チーム内に未共有の情報がないか？顧客の生の声が直近で記録されているか？
理解・分析する: どの視点・何を判断基準に・どの形式で出させるか、スラッシュコマンドを明示しているか？
再構築: 既成の KPI・聖域・前提を一度再構築したか？ Customer Sync 実態と ICP 仮説のズレを篩にかけたか？ゼロベースで考えたか？
起動・実装する: オーナー / 範囲 / 予算 / リスク / 計測 / 承認 / ロールバックが埋まり、本番反映前に activation-brief.md と measurement-plan.md が作られているか？
学ぶ: 結果を次サイクルの観測・データ収集にどう還流するか決まっているか？ Customer Sync への書き戻しがあるか？

このチェックが通らないうちは、AI に投げても成果は出ない。ただしマーケティングサイクルは文脈（規模・成熟度・速度・リスク）に応じて縮約・拡張するもので、一律のフル運用を強制するものではない。テーラリングの規定は次節「Tailoring」を参照。

Tailoring — マーケティングサイクルの縮約・拡張パス

原則: マーケティングサイクルは省略不可な 中核条件 と、文脈に応じて軽量化・拡張する 調整可能項目 の二層に分かれる。テーラリングは「省略の正当化を残すこと」が条件。「やらなかった」と「意図して外した」は別物として扱う。

中核条件（文脈に関わらず省略不可）

これを欠くとマーケティングサイクルが機能しない要素：

Customer Sync の独立保持 — 規模に関係なく ICP 仮説と顧客実態をそれぞれ別の記録として残す。1 人事業でも customer-signal.md 1 ファイルは持つ
再構築段の存在 — 1 行のメモでも良い。「何を、なぜ再構築したか」を残すこと自体が省略不可
本番反映前チェックのオーナー / 計測 / ロールバックの 3 項目 — 個人事業でも「自分がオーナー」「事前数値と判定期間」「止めるトリガ」は決める
学ぶ段の書き戻し — 検証済みかどうかの判定だけは残す。書き戻し先が results/ 1 ファイルでも可
AI 出力の採否ログ — 「AI が言ったから」病の予防。これは規模と無関係

これら中核条件を文脈を理由に削るのは、テーラリングではなく中核条件の違反として扱う。

調整可能項目（規模・成熟度・速度・リスクで調整）

要素	簡易運用（1 人事業 / スタートアップ初期）	標準運用（小〜中チーム）	厳格運用（規制業種 / 複数事業部）
観測・データ収集の 4 つの観測対象	Team Sync は自分自身のみで可。Customer / Performance は必須	4 つの観測対象すべて	4 つの観測対象 + 部門別並走
CMO Marketing OS Playbook 12 知識エリアのカバレッジ点検	該当領域のみ点検	全領域を四半期に 1 回点検	領域別 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 行サマリ	採用 / 不採用 / 理由	採用 / 不採用 / 理由 / 代替案 / 法務確認

テーラリング判断軸

規模: 1 人 / 小チーム（〜10）/ 事業部（〜100）/ 複数事業部
成熟度: workspace 立ち上げ初週 / PMF 前 / 安定運用 / 改善フェーズ / 再構築
速度: 週単位の本番反映 / 月単位 / 四半期単位
リスク: 個人ブログ / B2C SMB / B2B エンタープライズ / 規制業種（金融・医療・公共）

リスクが高いほど本番反映前チェックと承認を厚く、速度が速いほど観測・データ収集の周期を短くする。規模が大きくなるほど再構築を上位（ポートフォリオ）にも引き上げる。

シナリオ別の入口

シナリオ	推奨パス	重点
個人事業 / 1 人 workspace	簡易運用	`/listen customer` → 本番反映前チェックの省略不可 3 項目 → `/learn` を週次で
スタートアップ初期（PMF 前）	簡易運用 → 標準運用へ移行	Customer Sync 最重視。再構築は週次、起動・実装するは当週中の本番反映を前提
既存事業の改善サイクル	標準運用	`/listen team-org` `/listen team-workspace` から開始。再構築で引き継ぎ KPI を篩
規制業種 / 大企業	厳格運用	本番反映前チェック 7 項目 + 承認ログの徹底、`organization/` 層をポートフォリオ再構築の場として併走
エージェンシー / 複数クライアント	標準運用 / クライアント = workspace	`organization/` にエージェンシー共通知、各 workspace に固有 ICP / Brand

アンチパターン

テーラリング名目の中核条件省略: 「うちは小さいから」で Customer Sync を削る → ICP と実態のズレ検出が効かず、マーケティングサイクルの構造的優位が消える
省略の不文律化: 何を外したかを記録しない → 次サイクルで「なぜ本番反映前チェックの 4 項目しか見ていないのか」が再現できない
簡易運用のまま固定化: 規模が拡大してもテーラリングを更新しない → 後から責任所在不明になる
厳格運用の過剰適用: 1 人事業に承認ログと法務監査を要求 → サイクルが止まり、結局回らないので「マーケティングサイクルは重い」と誤解される
テーラリングを「妥協」と読む: テーラリングは妥協ではなく設計判断。判断したことを記録すれば妥協ではなくなる

テーラリングの記録

各 workspace の memory/workspaces/<slug>/profile/tailoring.md（任意）に以下を残す:

採用パス（簡易運用 / 標準運用 / 厳格運用 / 部分カスタム）
省略・縮約した調整可能項目と理由（文脈のどの軸に依拠したか）
拡張した要素と理由
次回見直し時期（規模変化・成熟度変化のトリガ）

これがないテーラリングは「忘れた」と区別がつかない。記録の有無自体が中核条件（責任設計）の一部である。

Canonical Flow

初回プロジェクトの推奨順:

/workspace new <slug> — workspace を 1 つ作成（実在する事業名で）
/listen team-org — 組織情報（観測・データ収集 / Team Sync）
/listen team-brand — ブランドガイドライン（観測・データ収集 / Team Sync）
/listen team-workspace — workspace 固有情報（観測・データ収集 / Team + Customer Sync）
/next — 次の一歩確認（詳細は /next --verbose）。不足があれば 1〜3 に戻る
/insight ceo（理解・分析する単体）or 横断ワークフロー（観測・データ収集〜学ぶ、未実装）
/release or /insight consultant — 再構築。既成枠の再構築
実行（広告運用・コンテンツ・CVR 改善・分析等）は knowledge/base/ プレイブックを参照しながらインライン対話で進め、本番反映する（起動・実装する）
/listen market + /learn — 観測・データ収集層への還流（学ぶ → 次サイクルへ）

マーケティングサイクル

定義

なぜ マーケティングサイクル か

マーケ OS の独自性は「顧客との同期」を構造に埋めること

再構築を骨格名に昇格させる

マーケティングとは何か — 最適化としての定義

観測・データ収集段のカバレッジチェック

5 段階の詳細

観測・データ収集

観測・データ収集の 4 つの観測対象

なぜ Customer Sync を独立源として置くか

やること

観測・データ収集が成立しているかのチェック

担い手スキル

理解・分析する

やること

良い理解・分析の構造

理解・分析のサブタイプ

サイクル内での回り方

担い手スキル

再構築

やること

再構築が成立しているかのチェック

重要な制約

担い手スキル

起動・実装する

やること

起動・実装するの責務

担い手

本番反映前チェック

起動・実装する段の実行管理成果物（PMBOK 由来の軽量補助線）

進行不可条件

起動・実装するの同時着地条件

学ぶ（学ぶ）

やること

Evidence Level（知見の格上げ基準）

Evidence Write Rules

学ぶが成立しているかのチェック

担い手スキル

マーケティングサイクルのスキル対応表

アンチパターン

Practitioner's Checklist

Tailoring — マーケティングサイクルの縮約・拡張パス

中核条件（文脈に関わらず省略不可）

調整可能項目（規模・成熟度・速度・リスクで調整）

テーラリング判断軸

シナリオ別の入口

アンチパターン

テーラリングの記録

Canonical Flow

関連ドキュメント

なぜマーケティングサイクルか