--- 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 レイヤー」と「戦略レイヤー」の境界の明示** — 起動・実装する内のリアルタイム最適化と 再構築 / 理解・分析するの戦略判断を構造的に分けるためのチェックリストが必要か