mcluhan × bateson で組む受注 funnel の全体設計 — 2 engine の役割分担

本記事に登場する HUMAN_INPUT マーカーとは、AI 執筆 skill が記事本文に残す「ここは人間が後で確定値を埋めるべき」を示すプレースホルダー（形式例: ）。

owned media に記事を書いても、問い合わせに繋がらない。コンテンツと受注の間に経路の断絶がある。Yakumo はこの問題を 2 つの engine の役割分担で解決しようとしている。mcluhan（owned media 運用 engine）が作る流入を、bateson（予約・受注 engine）が予約へ変換する。2 engine が連携して初めて「記事を読んだ人が相談できる」という経路が成立する。Yakumo ではこの funnel を現在実際に運用中だ。本記事では、2 engine の役割分担と funnel の全体像、AI エージェントによる自律運用の概要を示す。

2 engine の役割分担 — marketing と sales の境界

mcluhan = owned media 運用 engine（集客 / ナーチャリング / 検討促進）

mcluhan は「見てもらう」側の engine だ。役割は次の 3 つに整理できる:

集客: 検索・SNS・AI 検索引用で見込み客を記事に誘導する
ナーチャリング: 記事を読み続けることで課題認識を深め、Yakumo のアプローチへの理解を育てる
検討促進: 「この人たちに相談してみようか」という気持ちを醸成する

mcluhan は「受注する」機能を持たない。mcluhan の出口は「問い合わせ / 予約 CTA へのクリック」だ。そこから先が bateson の領域になる。

mcluhan の詳細なアーキテクチャは pillar「owned media 運用エンジン mcluhan の構造設計」で解説している。

bateson = sales engine（予約受付 / CTA 管理 / 受注オペレーション）

bateson は「受注する」側の engine だ。役割は次の 3 つだ:

予約受付: 初回ミーティングの日程調整を自動化する
CTA 管理: 記事末尾・コーポレートサイト・問い合わせフォームに予約 CTA を配置する
受注オペレーション: 予約後のリマインダー・提案書送付・受注確認まで担う

bateson の詳細な Phase 設計は pillar「Booking Engine を自作する設計戦略」で、multi-tenant 対応設計は spoke「bateson を single-tenant 実装で multi-tenant 化を妨げない Phase 設計」で解説している。

mcluhan が終わって bateson が始まる接合点の定義

2 engine の境界は「予約 CTA のクリック」だ。

mcluhan の領域:
  記事を発見する → 読む → 課題を認識する → 解決策を探す → 「相談してみようか」

接合点:
  記事末尾の予約 CTA をクリックする

bateson の領域:
  日程を選ぶ → 確認メールを受け取る → ミーティングに参加する → 受注

この接合点は物理的な UI として存在する。記事末尾の「初回相談を予約する」ボタンがそれだ。mcluhan が育てた「相談したい」という気持ちを、bateson がキャッチする設計になっている。

funnel の全体像 — 流入から受注までの経路設計

mcluhan が作る流入経路：検索 / SNS / AI 検索引用

見込み客が記事に辿り着く経路は複数ある:

検索 (SEO): Google / Yahoo で課題に関連するキーワードを検索し、記事が表示される
SNS: X（旧 Twitter）でのシェアや引用で記事が拡散される
AI 検索引用: ChatGPT / Claude / Perplexity が記事を参照情報として引用し、AIに質問した読者が記事に辿り着く

AI 検索引用は 2026 年以降に重要度が増している流入経路だ。mcluhan engine は SEO だけでなく AI 検索への引用可能性も設計基準に含む。

bateson への CTA 配置：記事末尾 / コーポレートサイト / 問い合わせフォーム

funnel の接続点（CTA）は複数の場所に配置する:

記事末尾: 読み終えたタイミングで「次のアクション」として予約を提案する
コーポレートサイト: サービス説明を読んだ後の自然な次のステップとして配置する
問い合わせフォーム: 従来型の問い合わせフォームと並行して予約 CTA を設ける

CTA の設計で重要なのは「読者の意思決定ステージと CTA の温度感を合わせる」ことだ。初めて記事を見た読者に「今すぐ購入」は早すぎる。「無料相談を予約する」という温度感の CTA が funnel の入口として機能する。

予約 → 初回ミーティング → 受注への conversion 経路

予約 CTA クリック
  ↓
bateson: 日程選択
  ↓
bateson: 確認メール自動送信
  ↓
初回ミーティング（30〜60 分）
  ↓
課題ヒアリング・提案概要の提示
  ↓
提案書送付
  ↓
受注

2026-05 時点では funnel 全体の運用を開始したばかりで、問い合わせ → 受注の conversion 率は実数として観測できる段階に達していない。数字が安定し始めたタイミングで別記事として diagnostic を書く想定だ。

この経路を AI エージェントが自律運用することで、オーナーの時間投入を「初回ミーティング」と「提案書作成・判断」に集中させる。

AI エージェントによる自律運用

mcluhan engine を動かす AI エージェントの役割（コンテンツ生成 / SEO 最適化）

mcluhan engine を自律運用する AI エージェントは次のことを担う:

記事生成: brief YAML を入力に、blog-tech-write / blog-case-write skill で本文を執筆
品質ゲート: blog-review skill で SEO / 事実確認 / narrative 整合を自動チェック
公開スケジュール管理: publish skill で公開日程を管理し、定期的に記事を公開する

Yakumo の場合、2 名 + エージェントという構成でこれらを運用している。

bateson engine を動かす AI エージェントの役割（予約管理 / リマインダー / 受注オペ）

bateson engine を自律運用する AI エージェントは次のことを担う:

予約受付: 空きスロット管理、日程選択 UI の提供
リマインダー: ミーティング前日・当日のメール自動送信
オペレーション補助: 議事録の自動作成、次のアクションの reminder

オーナーが意思決定する介入ポイント — 初期は調査結果と送信文に判断を入れ、徐々に介在を減らす

初期段階での介入ポイントは、AI エージェントが問い合わせ企業を調査して送信文を執筆した直後に置く。オーナーは調査内容と文面を確認し、問題がなければそのまま送信、問題があれば修正してその修正を学習データとして AI に戻す。

運用の方向性としては、修正フィードバックが蓄積するに従って介入ポイントを段階的に後ろにずらし、最終的には人間が事前確認しなくても送信できる状態を目指す。介入は「品質ゲート」ではなく「初期の学習データ供給口」として位置づける。

AI エージェントが自律運用する範囲と、オーナーが介入する範囲の境界を設計することが重要だ。「完全自動化」ではなく「適切な場所にオーナーの判断を組み込む」設計が、品質と速度の両立を可能にする。

まとめ — 2 engine で受注 funnel を設計する

engine の役割分担が明確になると AI に委ねる範囲も明確になる

mcluhan と bateson の役割分担を明確にする最大のメリットは、「AI に何を委ねるか」が明確になることだ。

mcluhan: コンテンツ生成・品質管理・公開スケジュール → AI が高い精度で自律実行できる
bateson: 予約受付・リマインダー → ルールベースで自動化しやすい
接合点（CTA の最適化）: 継続的な改善が必要 → AI + オーナーの共同判断

「AI で営業する」という誇大なビジョンではなく、「適切に設計された funnel を AI が自律運用する」という現実的な設計だ。

次のステップ：各 engine の詳細設計（mcluhan pillar / bateson pillar）への参照

2 engine の全体設計を理解した後は、各 engine の詳細設計に進む:

mcluhan engine の詳細: owned media 運用エンジン mcluhan の構造設計
bateson engine の詳細: Booking Engine を自作する設計戦略
bateson の Phase 設計: bateson を single-tenant 実装で multi-tenant 化を妨げない Phase 設計
funnel の経営判断: 受託から商用ライセンスへの経営判断

funnel の全体像を把握した上で各 engine を設計すると、2 engine の接合点（CTA / データ連携）の設計判断がブレにくくなる。部分最適ではなく funnel 全体の最適化を意識して進める。

Booking Engine を自作する設計戦略 — 受託から商用ライセンスへ — Pillar