MUMON

AIファームの武器庫

想定ケース:美容クリニック

ここまで述べてきた武器が、実際の案件でどう組み合わさるのかを、仮想ケースで具体的に示しておきます。

なお、以下は実在の案件を匿名化したものではなく、説明のための仮想シナリオです。数値は典型的な美容医療クライアントを想定した参考値であり、私たちが実案件で約束する成果ではありません。

クライアント像 (仮想)

都内に複数院を展開する美容クリニックを想定します。

  • 年商10億円規模 (うち新規顧客寄与 約7.8億円/既存リピート寄与 約2.2億円)
  • 月間予約問い合わせ800件 (LINE経由: 6割、Web予約経由: 約3割、電話: 1割)
  • 問い合わせ→初回来院CVRが18%
  • 平均LTVは45万円 (新規来院から24ヶ月累計)

Web経由の集客は伸びている一方で、現場の業務には複数の構造的な歪みが残っており、それが集客力に対して成果が伸び切らない原因になっている。

この想定で議論を進めていきます。

構造的な機能不全の、5つの症状

ここで一つ、解釈の角度を最初に置いておきます。

このクリニックで起きていることは、単なる業務改善の問題ではありません。

SaaSという記録系と、LINEという顧客接点の間に、業務を統合し成果に責任を持つOutcome Layerが存在しないこと。それによって生じている、構造的な機能不全です。

このあと挙げる5つの歪みは、互いに独立した「現場のだらしなさ」ではありません。同じ構造的欠落が、異なる場所で症状として現れたものとして読んでください。

1. 予約導線の二重化

SaaS型の予約システムと、LINEを通じた手動予約が、並行して動いている。SaaSには本来、即時予約機能が組み込まれているにもかかわらず、LINEで問い合わせてきた顧客に対しては、結局LINE担当者が手動で空き枠を確認し、対話で日程を調整したうえで、最後にSaaSへ転記する運用になっている。記録系(SaaS)と接点(LINE)が分断されたまま、人間の手作業が両者をつないでいる状態である。

2. LINE返信担当者の兼務による即時性の喪失

LINE返信担当者は、受付、施術補助、電話応対といった他業務を兼務している。だから、LINEに即時返信できる体制が組まれておらず、結果として、SaaS側の即時予約機能が活かしきれていない。深夜帯の取りこぼしはもちろん、日中でも返信に数時間〜半日かかる場面が珍しくない。「即時予約」という機能が現場に存在しているのに、運用が追いつかないために眠っている。

3. 施術後LINE対応の8割が、定型なのに人間処理されている

施術後のフォローアップも、LINEが主要チャネルになっている。来るメッセージの内訳をならしてみると、約8割は「プチっという音が口の中でしたが大丈夫か」「腫れはいつまで続くか」のような定型パターンに分類できる。にもかかわらず、看護師や受付スタッフが一件ずつ手動で返信し、施術直後の繊細な顧客対応に割くべき時間を消費している。

4. 即日施術ニーズの構造的な取りこぼし

美容医療では、「午前にカウンセリングを受けて、その日の夕方に施術してほしい」という即日完了ニーズが一定数ある。しかし、施術可否は、各院のオペ室の稼働状況、その日に出勤している執刀医のスケジュール、施術内容ごとの所要時間と回復時間など、複数の条件をリアルタイムで横断照合しないと判断できない。現状は、カウンセラーが他院や手術室に電話で確認している間に、顧客の意思が冷め、後日改めての来院に流れる。「即日決められないからやめ」という形で、決まりかけた売上が静かに離脱していく構造である。

5. 各院兼務 × 複数SaaS横断による、全体最適不在

各院の予約担当は兼務で動いており、CRM、SaaS予約システム、LINE、Google Calendar、Excelといった複数の画面をまたいで業務を回している。それぞれの画面の中での部分最適は進んでも、業務全体を貫いた最適化には、誰も責任を持てていない。SaaSのレポートを見る人、LINEを返す人、施術スケジュールを組む人が分かれていて、その間の意思決定を統合する主体が不在なまま運用されている。

「業務の谷」を埋める手段は、複数ある

ここで見えるのは、SaaSが悪いわけでも、LINEが悪いわけでもない、という事実です。

SaaSはSystem of Recordとして残るべき道具であり、LINEは顧客接点のチャネルとして強い。問題は、両者の間にできた「業務の谷」を、誰も埋めていないことにある。集客で人が集まっても、その谷で取りこぼされていれば、CVRもLTVも頭打ちになる。

ただし、この谷を埋める手段は、私たちのモデルに限定されるわけではありません。

LINE専属担当者を増員する。自社でAI内製化する。既存BPOへ外注する。これらは確かに、谷を埋める一手にはなります。

しかし、いずれの選択肢も、固定費と人月リスクを積み増すことで谷を埋める発想に立っています。担当者を増やせば人件費が継続的に増え、内製化すれば開発と運用の人材を抱え続ける必要があり、BPO委託は人月単価が課金構造の中心です。

私たちのモデルは、別の経済構造の上に立ちます。

AIエージェントがオペレーションコスト構造そのものを変えることで、固定費を大きく増やさずに谷を埋める設計です。「月額無料 × 完全成果報酬」という提案が現実解として組めるのも、この経済構造を出発点としているからです。

業務の谷を埋めるという目的は同じでも、出発点の経済構造が違うので、最終的な提供価値の形と、リスクの取り方が違ってきます。

業務分解と再設計

最初の2週間で、私たちのPodは現場の業務と顧客動線を棚卸しし、4軸スコアリングを行います。先の5つの歪みは、業務分解の結果として、次のように再配置されます。

LINE一次対応 (深夜帯含む)

定型性が高く、頻度も高い。AI得意領域として切り分け。Mumonが24時間応対し、SaaSの予約枠とリアルタイム連動する。LINE上で会話したまま、その場で予約確定まで運ぶ。返信担当者の兼務に依存していた構造を、Mumonが代替する。

即日施術ニーズへの応答

判断重要度は高いが、判断材料はデータの横断参照で揃う。AI主導 × 人間最終確認のハイブリッド領域。Mumonが各院のオペ室稼働、執刀医スケジュール、施術内容別の所要時間を横断照合し、当日施術が可能な枠を即座に提示する。「午前カウンセリング→当日夕方施術」の同日完了導線を成立させる。最終的な医療判断と適応可否は、当然ながら執刀医が確認する。

施術後LINE対応

定型性が高く、関係性接触はあるが、内容パターンは限定的。「AI得意 × 人間例外対応」の構成。8割の定型対応はMumonが担い、看護師や受付は、緊急性のある2割の例外対応と、感情的サポートが必要な顧客に集中する。施術直後の不安や不満は、人間が手厚く拾える状態に戻す。

事前ヒアリングと施術前後の不安受け止め

関係性接触が高く、判断重要度はカウンセラー側に集約される。ハイブリッド領域。Mumonが過去の相談履歴を踏まえつつ、来院前に不安、希望、過去施術歴を引き出す。人間カウンセラーは、来院した瞬間から、最終提案と契約クロージング、施術前後における個別フォローアップに集中できる状態に立てる。

執刀医の医療判断・リスク説明

判断重要度が最も高く、医療責任を伴う。完全な人間必須領域として切り分け、ここにAIは介入しない。

投入リソースと運用

常駐するEmbedded AI Revenue Podは、戦略・実装・運用を兼ねた少人数(典型的には3〜5名)の人間と、複数のAIエージェントで構成されます。

LINE一次対応、即日予約調整、施術後フォロー、カウンセリング前ヒアリングのそれぞれに、Mumonベースの人格OSを設定し、ブランドのトーンに合わせて応答を制御します。

SaaS、LINE、Google Calendar、CRMはMumonの裏側で連携基盤として走り、Mumonがその上の「業務遂行レイヤー」として動く。各院の予約担当が、複数画面を行き来しなくても業務が完結する状態を作ります。

人間チームは、応答品質のレビュー、エスカレーション設計、KPIモニタリング、月次の改善仮説出しを担当します。

経済性の見立て

戦略的な議論に必要なユニットエコノミクス的な観点も、ここで整理しておきます。

増分売上の主要な源泉は、典型的なケースでは3つに分解できます。

(1) CVR改善による取りこぼし回収

LINE一次対応の即時化と、深夜帯対応の構造的解消によって、これまで失っていた問い合わせ→来院の経路が回復する。

(2) 人間工数の高付加価値領域への転換

施術後LINE対応の8割が定型処理から外れることで、看護師や受付の時間が、より関係性接触の高い領域、つまりLTVに直接効く顧客対応へ振り向けられる。これは間接的だが、リピート率と紹介率に効いてくる。

(3) 即日施術CVRの回復による直接的な売上増分

意思決定が冷める前に当日施術へつなげる導線が成立すれば、これまで構造的に失っていた高単価案件が回収される。

Embedded AI Revenue Podの月次運用コスト (人件費、AI推論コスト、SaaS連携費を含む)に対し、これら3つの増分売上の合計で見たペイバック期間を、3〜6か月の範囲に収めることを目標水準として設計します。

立ち上げの2か月をフィー型でPodの初期コストを賄い、3か月目以降は完全成果報酬で増分売上の一定比率を受け取るハイブリッド構成は、この経済性の上に組まれています。

数値の範囲はクライアントごとの前提条件で変動します。ペイバックが現実的に視野に入る案件しか、私たちは受けません。前章で述べた「案件選別」の規律は、ここに紐づいています。

仮想目標と報酬構造

このような前提のもとで、6か月のターゲットとして、たとえば次のような目標が設定されうる。

  • 問い合わせ→初回来院CVRを18%から22%へ (ベースシナリオ: 22%、ストレッチシナリオ: 25%)
  • 即日施術CVR (午前カウンセリング→当日施術)を、現状の取りこぼし水準から半減
  • 深夜帯問い合わせの取りこぼし率を半減
  • 施術後LINE対応の人間工数を80%削減
  • 初回来院後の3か月以内リピート率を15%向上

報酬構造は、立ち上げの2か月をフィー型、3か月目以降を完全成果報酬とするハイブリッド型から始めることが多くなります。

条件が完全に揃う案件では、最初から完全成果報酬で受けることもあります。

この仮想ケースが示していること

ここまでの仮想ケースが示しているのは、

  • 業務分解
  • AIエージェント群
  • AI人格OS
  • 報酬設計
  • 計測設計

が、ばらばらの武器ではなく、一つの実行モデルとして組み合わさるという点です。

そして、もう一つ重要なのは、ここで描いた歪み、すなわち予約導線の二重化、担当者兼務、定型LINE対応の人間処理、即日施術の取りこぼし、複数SaaS横断による部分最適不在は、美容医療に限らず、AGA、保険、歯科、私学塾、高単価スクール、会員制サービスなど、顧客接点が会話で動き、複数チャネルとSaaSを横断するすべての業界で、形を変えて繰り返し見られる構造であることです。

武器単体ではなく、それらが組み合わさり、業務の谷を埋めて事業KPIに接続したときに、Outcome Layerとして機能する。

これが、本章を通じて伝えたかった核心です。

・・・・・

次章からは、そのMumonの設計思想を詳しく解き明かしていきます。

なぜ高性能LLMの時代に、

  • 人格OSという別レイヤーが必要なのか
  • プロンプトでは作れない振る舞いとは、具体的に何なのか
  • ブランドごとに異なる人格を、どのような構造で実装するのか

ここから先は、私たちが手にしている、最も深い武器の話です。