マルチテナント業務管理システム

July 19, 202646 min read
Export HTMLExport PDF

サロンマルチテナント業務管理システムブレスト 2026.07.19

用語

  • ユーザ: 当システムを利用する店舗
  • 顧客: 店舗のお客
  • MVP (Minimum Viable Product): ユーザに価値を提供できる最小限のサービスを短期間・低コストで現場に一旦投入してみて、実際のユーザからのフィードバックをもとに改善を重ねる手法

初期コンセプト

エステサロンや鍼灸クリニックに導入するマルチテナント業務管理システム。 顧客管理、予約機能、売上管理、顧客向けブログ、レビュー機能、店舗ウェブサイト、、というようなパッケージ。 ホットペッパービューティー（以下 HPB ）から集客要素を除いたようなシステム。

集客要素がなくなるとプロダクトとして弱いため、代わりにせっかくこれから新規で開発するので AI を活用した機能を増やす。

店舗の「知識・知恵・顧客データ・過去の運用」を AI に蓄積

単なる「ブログを書いて」では、 ChatGPT に直接頼めば済む。 しかし「この店舗の過去の顧客カルテ、メニュー、施術方針、過去のブログ、顧客層、地域特性を踏まえて、今月再来店が期待できる顧客を抽出し、その顧客に送る LINE 文面を作成する」なら、業務システムに組み込まれている意味が出てくる。

ここでの AI の価値はモデルそのものではなく、店舗の業務データと AI が常時接続されていることにある。 「 AI は付加機能」「都度の作業単位の補助」ではなく、「 AI が店舗運営を補助するサロン OS 」を目指すと HPB との差別化が明確。

当件の勝機は「予約システムを作ること・集客してあげること」ではなく、「小規模店舗が自力で集客・顧客維持するための AI 運営アシスタントを作ること」。

店舗ごとに AI が育つ構造

  • 店舗固有の施術方針
  • 店舗独自の接客方針
  • スタッフ毎の得意分野
  • 過去のブログ
  • 顧客カルテ
  • リピート傾向
  • 売上データ

を蓄積していくと、単なる ChatGPT では代替できない「その店舗専用の AI 」に育っていき、 SaaS としての強いロックインが生まれる。使えば使うほど、他のサービスに積極的に乗り換える理由がどんどんなくなっていく。

本当の競合は HPB 離脱先

HPB 、楽天ビューティのような大手は当然競合ではあるものの、集客力を提供できない点では完全に劣っているため、比較してどうしようというより良い点を真似る程度に考える。 本当の競合は「 HPB を使っていたサロンが離脱した乗り換え先」、主にはほぼ無料のサービスでは。

内山が個人的に利用するマッサージ店では、 Wix での簡素なウェブページと Air リザーブでの予約機能のみ。すべて無料で済ませている。 そこまで割り切っている店はユーザになり得ない？

1. 予約・顧客管理の汎用 SaaS

最も直接的な競合

  • Air リザーブ
    • 美容・医療・教育・スポーツ・公共サービス・イベント運営など、ユースケースを問わない
    • 無料プランあり、予約管理・顧客管理・オンライン決済・予約確認メールなど提供。整体・接骨院・マッサージにも対応
    • Air シリーズとの連携。 Air ビジネスツールズの一部として提供されており、 POS レジの「 Air レジ」や決済サービス「 Air ペイ」などと組み合わせることでオールインワンに近づいていくモジュールモデル
  • STORES 予約
    • 店舗やスクール、サロン、医療・施設、イベントなど、ユースケースを問わない
    • 無料プランあり、予約・顧客管理・スタッフ・リソース管理・リマインダ通知・決済・月額課金や回数券管理・ POS 連携まで持っている
    • 外部サービスとの連携充実、 LINE 連携・ Zoom 連携・ Google カレンダー連携・ Google 予約
    • 予約情報から対象顧客を抽出して再来促進メッセージ送信機能あり。「予約＋ CRM 」
  • Square
    • 実店舗やオンライン販売向け
    • 店舗運営プラットフォーム、決済・ POS ・ EC ・予約・請求・在庫管理
    • 無料プランあり
    • 予約管理を中心に決済・ POS との統合が強み

2. サロン特化型の業務管理システム

  • A'staff Cloud
    • 美容室や理容室、ネイル、エステ、リラクゼーション、ペットサロン向け
    • BeautyMerit 、 Reservia 、かんざしなどの予約・集客サービスとの連携
    • POS 、顧客管理、施術履歴、電子カルテ、予約管理、売上分析などを一元化
      • 顧客管理: 来店履歴、施術履歴、購入履歴、担当スタッフなどを一元管理
      • 電子カルテ: 施術内容や使用薬剤、写真、メモなどをデジタルで保存
      • POS レジ・会計: 会計処理やキャッシュレス決済、売上集計と連携
      • 予約管理: 電話予約やネット予約との連携
      • 売上分析: スタッフ別・メニュー別・店舗別などの分析レポート
      • 在庫管理・勤怠管理: 商品・薬剤の在庫やスタッフの勤務状況を管理
      • 多店舗管理: 本部から複数店舗の売上・顧客情報を一元管理、店舗間データ共有
  • エステアンサー
    • 月額 14,800 円〜、初期費用 13 万円
    • iPad 運用が意識されている
    • 顧客管理・ POS ・ウェブ予約を統合
      • 予約管理: 店頭・電話・ネット予約を一元管理
      • 顧客管理: 来店履歴や施術履歴、電子カルテを管理
      • POS レジ・売上管理: 会計、売上集計、レジ締めを効率化
      • 契約・コース管理: 契約書作成、回数券・役務残高、解約計算などに対応
      • 分析機能: RFM 分析や売上分析、各種レポートを活用した経営支援
      • 販促機能: 顧客向けアプリやプッシュ通知などを利用したリピート促進
    • 導入メリット: エステサロンでは未だに紙台帳や個別のシステム運用による入力ミスや重複作業が課題とのこと。その解決を目指す
  • BEAUTY POS
    • 美容室・エステ・ネイルサロンなど向け
    • POS ・予約・顧客管理システム
    • 予約受付から会計、顧客情報、売上分析までを一元管理
  • Aiony
    • ネイルサロン・エステサロンなど美容業界向け。オールインワン POS レジ・顧客管理システム。 iPad を中心に、予約管理、電子カルテ、会計、売上分析などのサロン運営に必要な機能を一元化。
    • iPad 専用設計のため、専用 POS 端末や PC 不要、省スペース。電子カルテでは施術履歴に写真・手書きメモ・音声入力も対応
    • 予約情報・顧客情報・会計データが連携し、受付〜施術〜会計までの業務効率化
  • KireiDot
    • 美容サロン向け
    • 予約・電子カルテ・スタッフシフト・売上分析・顧客 CRM を統合。
    • 初期費用 0 円、無料トライアルあり

3. 店舗が自分で組み合わせる無料サービス

これが最も重要な競合では。

  • 店舗サイト: Wix
  • 予約: Air リザーブ
  • 顧客管理: Air リザーブ、 Excel
  • 決済: Square 、 Air ペイ
  • 連絡: LINE 公式アカウント
  • 集客: Google マップ、 Instagram
  • ブログ: Wix

「 Wix ＋ Air リザーブ＋ LINE でいいのでは？」問題

当システムの価値は、機能の多さではなく、複数サービスを使い分ける手間をなくすことであると同時に、単にこれらがオールインワンパッケージになっているのではなく、「オールインワンだからこそ、店舗運営や顧客情報などすべてを AI が一元的に情報資産として把握できることで、直接的な店舗運営補助や半自動化までできる」こと。 これが当システムの本質であることに気づいてもらうのが重要。

AI が店舗のすべてを把握しているからこそできる例 :

顧客カルテ
    ↓
AIが顧客の状態を把握

予約履歴
    ↓
施術履歴
    ↓
来店間隔
    ↓
売上・メニュー履歴
    ↓
AIが判断
    ↓
「そろそろ再来店時期の顧客」
「前回と異なるメニューを提案できる顧客」
「しばらく来店していない顧客」
    ↓
AIが個別メッセージを作成
季節やイベントなどと絡めて来訪すべき理由づけ
    ↓
LINEで配信

単なる予約システムでなく、「店舗の情報資産を利用して、次に何をすべきかを AI が提案、あるいは実行までする経営支援システム」。 既存のサロン向け SaaS と圧倒的な差別化。大手競合とも差別化。

サロンコネクト

HPB 、楽天ビューティ、ミニモ、 OZmall 、 EPARK 、ネイルブック…それぞれ出店して同時に予約システムを運用しているとダブルブッキングが発生する。その解決を目指した複数サービスの予約情報同期サービス。 たとえば、 HPB から予約が入ると同じ日時の枠を楽天ビューティなどにも反映してダブルブッキングを防ぐ。

但し、 HPB や楽天ビューティがそれぞれ情報提供しているのでなく、サロンコネクトが独自に工夫して無理やり外部情報へアクセスしているようで、正確性・信頼性が低いはず、技術的にかなりリスキーな印象。 届く予約メールをトリガにして把握する方式や、数分ごとに予約状況を確認する方式など、ポータルごとに連携方法が異なる。 情報の取り方や、そもそも取れるかどうか自体が、取得先サービスの仕様に完全に依存している。取得先が仕様変更したらいたちごっこで追従するまで情報取得できなくなる可能性がある。 エラーハンドリングすら、動作成立できるかあやふや。

  • HPB のログイン情報を登録する
  • HPB のログイン情報期限切れを検知する
  • HPB のログインエラーを検知する
  • 予約データが取得できなかった場合に「メール同期」エラーとして通知する

これを主要ポータルすべてに対して継続保守しているようで、奇跡的にぎりぎり動いているような、よくこれで運用できているなとの印象。 HPB や楽天ビューティが予約情報公開 API 提供などしていないのなら、この分野には手を出さないほうが良い。かなり高い技術・運用コストを払う覚悟が必要、リスクが高すぎる。

サロンコネクトのビジネス的価値は、そういう「覚悟を決めている」こと。

開発速度感

MVP 前提にし、要件範囲を定義する。 その要件によるが、着手から 2 ヶ月後にはプロトタイプをデプロイしたい。

この機能を実装するか、 1 週間議論する時間をかけない。 サービス成立にまで関わらないなら、 MVP 要件から外して実装しないとさっさと割り切る。サービス成立に関わるなら、本当に必要か議論している時間でさっさと実装してしまった方が早い。

機能

  • 顧客管理
  • カルテ管理
  • 予約管理
  • 売上管理
  • 顧客向けブログ
  • レビューとコメント
  • 店舗ウェブサイト

カルテ管理

「前回は肩こりが強く、原因はおそらく xxx で、右側の施術時間を長めにした。次回は症状の変化を確認」というような施術履歴を蓄積し、次回来店時に AI が「前回からの経過確認事項」を提示する。

「この顧客には次回どのような施術・会話・提案が適切か」を提案できる。 顧客に合わせ、施術で最終的にどうなりたいかのゴール設定・進捗・直近の具体的目標・そのための具体的施術メニュー・など提案できる。これまでの経緯を自動整理して一覧できる。

予約管理

Google カレンダー連携機能。 規模感のある店は予約スケジュールと個々人のスケジュールは当然別管理すべきだが、個人店などは個人の Google カレンダーに予約枠も自動追加してくれると、プライベートと業務 2 つのスケジュールを突き合わせて予定を立てる必要がなくなりそう。

Google 予約や LINE 予約と干渉するか

どちらも独自の予約システムに依存したサービス。当件には無関係。 Google 予約は、 Google Maps 上から予約ボタンで独自の予約システムに直接予約できる方式とは別に、リンクボタンから自社予約ページにリンクさせる方式もある。しかしそれなら単なるリンクボタンであって、店舗が Google ビジネスプロフィールに予約 URL を置くのと同じであり、どちらにせよ当件とは無関係。

顧客向けブログ

テーマや文体だけ設定しておけば、

  • 店舗の特徴
  • メニュー
  • 施術者の得意分野
  • 過去のブログ
  • 顧客層
  • 季節
  • 地域イベント
  • 予約状況
  • 最近売りたいメニュー

などを材料に、毎月・毎週の集客施策を自動的に提案し、ブログ、各種 SNS 投稿、 LINE 配信文などを自動生成する。 配信先への自動投稿まで可能だが店舗スタッフの承認を設けたほうが安全。

これまでのブログテキスト、見本となるようなテキストを設定しておくことで、店のカラーに合わせたテイストで生成する。 ブログ記事に「いいね」機能をつけるなどして、エンゲージメントが多い記事を特定、学習して、以後さらに好まれる記事を書くように育っていく。

全顧客のカルテから顧客の一般的な悩みを抽出して記事に反映。自分事として関心を持って読んでもらう（顧客を特定するものでなくあくまで一般論）。

レビューとコメント

レビュワーに対してカルテを紐づけて、顧客の状態・履歴を理解しているムードを伝えたり、次につなげる簡単な施術提案を自動生成する。 クレームレビューに適切に対処する。できれば期待を抱いてもらい再来へつなげることを目指す。

但し、カルテ情報を直接使って返信すると本人しか知らない情報を店側が公開してしまうリスクがある。 かといって具体的なことを言わないコメントは、当たり障りないようにとりあえずコメントを付けているだけの親身でない店との印象にもなる。コミュニケーション優先・リスクヘッジ優先のように生成モードを選べるのも良いかもしれない。あるいは、そこまで細やかにカスタマイズできるのは、一見便利に思えるが現場としては面倒かもしれない。

商品設計

HPB 、楽天ビューティー、しんきゅうコンパス、どれもポータル型・マルチテナント型で、ユーザはこの中で店を比較しながら選ぶ。 それを A 型とし、もうひとつ B 型として、店舗専用の独立したウェブサイトを提供（同じバックエンドへ接続するので機能はほぼ同じ）にするとブランディングを重視する店にマッチするのでは。 あるいは、すべて A 型だがオプションでウェブサイト提供も可能（ここでウェブサイト制作受託）というやり方もキャッシュポイントになる。

A 型: ポータル型

まだ自力集客力が弱い店舗と相性良し

地域のユーザー
    ↓
複数店舗を比較
    ↓
自店舗を選択
    ↓
予約

B 型: 独立サイト型

既に一定のブランド力や固定客を持つ店舗と相性良し

Google
SNS
口コミ
紹介
広告
    ↓
店舗専用サイト
    ↓
予約

A 型と B 型はフロントエンドの形態が違うだけで、同じバックエンドにつなぐ設計のため、機能としてはどちらもほぼ同じ。入口と見せ方だけの違い。

┌──────────────────────────────┐
│ 顧客・予約・カルテ・売上・AI     │
│        共通バックエンド         |
└──────────────┬───────────────┘
               │
      ┌────────┴────────┐
      │                 │
  ポータル表示        独立サイト
  /shops/123        shop-a.jp

B 型は厳密には、サイトテンプレートをカスタマイズするだけの B 型と、オーダーメイドで完全に受託制作の C 型の商品になる。

どう見せたいかは変化する

最初は A プランでポータルに掲載していた店舗が、成長したら「もう他店と比較されるポータルより、自社ブランドを前面に出したい」となる可能性がある。

そのとき、ポータルから退会してくださいではなく「独立サイトプランにアップグレードしてください」とできる。顧客が成長しても当サービス内に留まり続ける構造。

また、 HPB のペインである、「人気店になっても掲載料を払い続けなければならない」に対し、「成長したらポータル依存から自社ブランドへ移行できます」という価値提示ができる。

店舗ロードマップ例

店舗が成長しても、「解約」ではなく「型の移行」の導線が描けている

開業直後
  ↓
A型: ポータルで集客

顧客・口コミが蓄積
  ↓
A型＋自社ドメイン

ブランド確立
  ↓
B型: 独立サイト中心

成熟店舗
  ↓
Google・SNS・紹介
C型オーダーメイドサイト、その中でこれまでのAI機能を引き続き利用可能

自社ドメイン販売も可能

ポータル型より独立サイトを優先すべきか

初期にポータルに入ってくれる店舗数による。

ポータルは店舗数が少ないとユーザーにとって価値ない。 「札幌市の鍼灸院を 3 店舗掲載」ではポータルとしては弱い。

独立サイト型は 1 店舗から成立するため、最初はむしろ B 型の独立サイト＋共通業務システムとして作る方が事業上は安全かもしれない。

店舗数が一定数集まった段階で「この地域の店舗を横断して探せるポータル」追加。 最初からポータルを作ると、人が来ない寒いポータルになってしまうリスクがありそう。

成長順 : 初期: 店舗専用サイト × 10 店舗 その後: 10 店舗をまとめた地域ポータル さらに: 複数地域・複数業種へ拡大

集客補助

SNS 露出

直接的な集客力はないし、サービスとして持とうとする意思もない。このサービスの本質でもない。 但し、できるだけの補助は考えられる。

たとえば、 X.com をかたちだけでも集客補助ツールとして使う。一つの専用アカウントを持ち、加盟してくれた店舗を次々にツイートしていく。以後、月に一度ツイートして露出してくれる。 メディアを育て、掲載してくれること自体が価値の一つとして加盟検討してくれる。 メディアとしてインプレッションを持つようになったら、加盟に関わらず、広告枠のように審査のもと有償でツイートするキャッシュポイントにもなりうる。 アカウントでは、季節・イベントなどに応じて（特定の店舗でなく）サロンに行こうというような喚起もする。

X 以外の Instagram や Tiktok などもチャンネルにはなるが、どちらも X と違ってビジュアル作成が非常に重要。 X でも店舗紹介として投稿する以上はテキストのみということはないが、ビジュアルの重要度は他 SNS と段違い。ビジュアルが本質的に重要かではなくて、 Instagram も Tiktok も他者のすべての投稿はビジュアルの魅力を最大化するのが大前提のうえで投稿されている中、インプレッションを意識した投稿を作成していくコストは、サービスのおまけ程度の意識ではすぐに疲弊するはず。

SNS への自動投稿は AI と同じく実費がかかるため、売上が立たないサービス初期からは実装しにくい。 将来そういう機能がつくとビジョンを語る程度。

SNS メディア運用のリスク

プロモーションアカウントが、理由はともかく BAN ・シャドウ BAN されてしまう可能性。 加盟店はアカウントに掲載されることも価値と考えて加盟している可能性もある。 特定の店舗のいいかげんな原稿が理由で BAN され掲載全店舗の露出が機能しなくなる、または AI が作成したコンテンツそのものが原因、ということもありうる。

運営側が考えて運営側の操作で掲載したら BAN の場合も、通常は自社にダメージあるだけだが、この場合は掲載していた全加盟店へのサービス提供の一部を一方的に無くしてしまうのと同じで、 SNS 運用の責任感や緊張感が非常に高い。

その意味では、 Instagram や Tiktok はコンテンツ作成のハードルが高いと言わず、リスクヘッジとしてチャンネルを複数持って分散させておく必要がありそう。 また、「運営公式 SNS への掲載」を加盟店への契約上の保証されたサービスにしない。公式 SNS 等を活用した加盟店紹介・プロモーションを行う場合があります、程度。

将来的な事業展開

業種業態の横展開

「 AI によって使い込むほど店舗ならではの業務 OS に育っていく店舗運営ツール」の意味では、たとえばキャバクラ・風俗店などとも相性が良さそうで、導入されればグループ全体に一気にビジネス契約されそう。 ただそれらの業界は相当強い競合が独占しているイメージ。

機能面においては、 キャバクラはある意味マニュアルに沿った画一的な業務のため、スタッフ管理（キャスト管理）・キャストと顧客の関係性管理を拡充すればそのまま使えそうな気はする。 単に「顧客データを保存」ではなく、

  • この顧客には今週連絡した方がよさそう
  • このキャストとの組み合わせによって再来店確率が高そう
  • この顧客にはイベント告知より個別メッセージの方が有効そう

これらを AI は提案でき、これら店舗固有の顧客知識が蓄積されるほど AI が育って乗り換えにくくなる構造はイメージしやすい。キャバクラの本質的な業務は当システムの提供価値と共通していそう。 風俗店はおそらく属人性が非常に強く、機能に収まらないのでは。送迎、ポータルサイト更新など業界依存の業務も膨大にありそう。

パーソナルジム・パーソナルトレーニングは、 顧客、カウンセリング履歴、身体データ、トレーニング履歴、ゴール設定、進捗管理、次回指導。 AI との相性が非常に良いのでは。

美容サロンのカルテ: 前回どんな施術をしたか パーソナルジムのカルテ: 目標、進捗、ネクストアクションの提案

提案例 :

  • 3 か月前に設定した目標に対して現在の進捗
  • 入会からこれまでの進捗整理・一覧
  • 最近トレーニング頻度が落ちている
  • この顧客は体重よりも体脂肪率を重視した方が成果が出やすい
  • しかし、この顧客は体脂肪率よりも体重を重視した方がモチベーションは高い
  • 過去すべてを遡ると、このトレーニングメニューのときはいつもモチベーションが高い
  • 次回は今回と同じメニューを維持すべき、変えるべき

これらにすべてに対して、なぜそう提案するか、データ・数字・根拠が言える。

同じ理由で教室・スクール・レッスン業も相性が良いのでは。 毎週決まった曜日に通うタイプより、予約制だとシステムがなお活きる。

  • 音楽教室
  • 英会話
  • プログラミング教室
  • ダンス
  • 子供向け習い事

提案例 :

  • この生徒が過去につまづいた箇所の傾向
    • それをもとに推測できる今後のつまづき箇所
  • 最近欠席が増えている
  • 次回はこの課題から再開すべき
  • 保護者への報告文を自動生成

つまり、「顧客理解・目標設定・進捗管理」が本質の事業は AI 管理と相性が良い。 継続すればするほど顧客理解を蓄積していく。ツールが育っていく。

  • カウンセリング、コーチング
  • パーソナルスタイリスト

飲食店も相性が良さそうといえばそれはそうだが、一つ一つの機能のみを見れば業務フローとマッチしているだけであって、 AI が店舗の情報資産を把握して運営補助するという本質とはあまり関係ない。

ペットサロン・動物病院なども、人間向けのサロンの業務モデルに近い？

飼い主管理
  ↓
ペット管理
来店周期
  ↓
カルテ: 犬種・年齢・体質・苦手な施術・飼い主の希望
  ↓
過去の施術・状態
  ↓
次回の推奨
前回から8週間経過しています
この犬種は通常6〜7週間周期です、身体の大きさを考慮すると6週間が理想です
前回、耳周辺の状態について注意がありました

長期的な顧客・ペット理解、使い込むほどその店舗固有の OS になるという思想に素直にマッチする。

横展開を見据えた場合、共通機能と業種依存機能を最初から分離し、共通機能に対して業種依存機能をモジュールのようにくっつける、アダプタのように差し込む設計が良い。

海外展開

基本的には通用しそうだが、単に日本版を翻訳して海外に売る考え方ではなく、コア部分と国ごとのローカライズ部分を分離できるかが重要。

海外展開を見据えた場合、「日本の HPB の代替」でなく「小規模な美容・ウェルネス事業者向けの AI 業務 OS 」をつくる感覚だと展開しやすいはず。

国が変わっても同じ基本的な業務課題 :

  • 店舗・スタッフ管理
  • 顧客管理
  • 予約
  • 施術履歴・カルテ
  • 売上
  • 再来店促進
  • 口コミ対応
  • ブログ・ SNS コンテンツ作成
  • AI による顧客分析
  • 店舗サイト

国固有のエコシステム :

  • 日本
    • HPB 、ポータルで比較 → クーポンを見る → 予約 → 店舗で施術
    • 消費者行動の型ができあがっている
  • 海外、
    • 国によっては、同じポータル型でも集客は個別に
      • Google 、 Instagram 、 Facebook 、 WhatsApp 、 TikTok など SNS
      • Fresha 、 Booksy 、 Treatwell など地域ポータル

国ごとに用意するアダプタ :

  • 言語
  • 決済手段
  • 通貨
  • 税率・税務
  • 電話番号・住所・日付・氏名の形式
  • 主要 SNS 対応
  • メッセージング配信チャンネル
  • 宗教観や慣習の理解
  • 予約の時間通念
    • タイムゾーン概念
    • 日本人のようには厳密でないこと前提の業務フロー設計
    • キャンセル規則の通念
  • 法令・個人情報保護
    • 日本の鍼灸サロンが気軽に取り扱う情報が、国によっては重大な医療情報・健康情報と捉える可能性がある
      • レビューコメントに「前回はひどい腰痛でしたね」など、個人を特定できなくても公開して記載するのが非常識かもしれない
      • これを事業リスクとして重視する場合は、美容サロン・エステ・ネイル・マッサージなど健康情報を扱わない業種が安全、ウェルネス・メディカルに近づく業種ほど難度が高い

国に依存する要素はあるものの、こういった当システムの本質的価値は国を問わない。

  • 前回の施術内容、来店間隔、顧客属性、過去の会話、レビューをもとに、次回のフォローアップメッセージを作る
  • 店舗のブランド・ターゲット・テイストに合わせて、ブログや SNS 投稿を生成する

サービス提供側の運用コスト

技術面

運用開始後の技術範囲で人件費を除いた運用コスト

  • インフラ（サーバ等）月額
  • ドメイン年額
  • AI 従量制

AI 利用費用は、技術的には従量制。各店舗がたくさん AI 機能を使うと、その分コスト増になる。 店舗に従量制であることを意識させ使用量を気にさせるのは、サービス使用感が非常に悪い。 かといって無制限に利用されると運用コストが逼迫する。 店舗へは「ライトプラン、プロプラン」ように感覚的にわかりやすい上限にし、従量制のように 1 回使う度にライフが減っていくような気遣いをさせない。 たとえば、ライトプランなら月のブログ記事生成回数は 20 回上限・レビューへの自動コメントはレビュー先着 30 件まで・カルテ要約月 500 回まで、プロプランなら倍、など。 もしくは、利用超過分のみ請求など。

レベニューのスキーム

及川さん側に期待すること

  • 自社サロンを最初の実証実験場にできる
  • 既存のサロン経営者ネットワークがある
  • ネットワークへのヒアリング
  • ネットワークがそのまま顧客になりうる
  • HPB の深い利用経験
  • サロン運営のワークフローを知っている
  • 既存システムへの不満を具体的に知っている
  • 導入先候補の見積、売上概算試算
  • 少なくとも初期からは法人化しないため、及川さんの法人を一旦フロントとしたい。サロン業界に合った実績・ネットワーク・口座・税務処理・弁護士などのビジネスリソースを既に持っているため

領域分担や権利

内山側

  • システム開発
  • 技術選定
  • データベース設計
  • UI 設計・デザイン
  • AI モデル選定・システム設計
  • デプロイ
  • 継続的な技術運用
  • データ移行
  • 継続的な保守・システム改善・システム拡張・仕様変更対応
  • コスト管理

及川さん側

  • 業界知識、業界側の要件整理
  • 自社店舗での実証
  • 業界ネットワーク
  • 初期顧客獲得
  • 営業・販売
  • 店舗からの一次対応、解約防止
  • 現場フィードバック
  • ビジネスリソース
  • コスト管理

初期のシステム開発費用は内山が自己負担・投資していいと考える。 その場合、ソースコード・知的財産はすべて内山に帰属するのが自然。 経産省 2026 年 6 月知財取引指針では、レベニューシェアを含む対価設定や、「成果物の工賃」と「知的財産権等の対価」を区分する考え方を示している。開発費を受け取らない代わりに知財を渡す必要はないとしている。 https://www.meti.go.jp/press/2026/06/20260624003/20260624003.html?utm_source=chatgpt.com その後も開発・技術判断・運用・保守など技術面はすべて内山が担当。

売上の帰属・分配率どうする。 運営する中で業界展開・横展開したい場合の権利関係・意思決定権どうする。 技術基盤を共同所有にすると将来の開発や事業展開が複雑になる。 曖昧なまま開発を始めると、サービスが成功した後に揉めうる。 財産を共同所有は一見公平だが、実際的には非常に面倒且つ揉める種になる。 上手に分担しても、それぞれの重みは必ず違う。「売上の 50% ずつ、山分け」のように単純化すると後で必ず問題になる。

想定される種

  • どちらが改良版を作れるのか
  • 片方が単独で第三者にライセンスできるのか
  • 片方が事業から撤退したらどうなるのか
  • 相手が別の開発会社に改良を依頼できるのか
  • 知財を持つ内山の意思決定のみで別業種向けに共通基盤を転用できるのか

客観的には、開発コストを負担する内山が知財保有し、及川さんにはサロン業界における一定の利用権・販売権を持ってもらうとなるのが自然なかたちには思う。 たとえば、紹介・営業した店舗については売上の x% を受け取る、一定数の店舗を獲得する限りサロン業界における独占販売権を持つ。 但しこれも単純化すると、レベニューシェアと言いながら結局「内山が開発したシステムの販売代理店でしかない、いいように使われている」という印象に近づいていき共同事業にならない。そういうことがしたいわけではない。 及川さんには業界展開に応じた経済的利益と、必要な範囲の利用・販売権・意思決定権、事業パートナーとして継続的な権利と利益をしっかり持ってほしい。

持ってほしい:

  • サロン業界向け機能の企画権
  • 料金体系についての協議・承認権
  • 重要な機能追加についての協議権
  • 事業方針への一定の拒否権
  • 一定条件下での優先的な業界展開権
  • 事業の売却や第三者へのライセンスに関する同意権

分担として、どちらか一方だけが圧倒的に働いていると感じるモデルにならないように充分気をつけたい。一時的にそうならざるを得ない事情があっても、報酬分配でちゃんと報われる前提にしたい。

所有権でなく構造で分ける:

  • 内山: プロダクト開発・技術・運用の責任者
  • 及川さん: 業界戦略・顧客開拓・店舗運営知見の責任者
  • 共同: 料金体系、機能方針、事業戦略

ビジネスリスク

  • SLA
  • セキュリティ
  • 障害対応
  • 法令対応
  • ユーザのリテラシー（一番怖いのは人間）
    • 導入したのに店長だけは Excel 管理をやめず、情報資産が綺麗に蓄積されない
    • AI 生成された文章を確認せず配信する
    • 自分で判断せず AI の提案のままに施術したせいでトラブルになり、責任を取れ、というリテラシーのオーナー
      • 「 AI は責任を負いません」と規約に書けば解決するわけではない。「 AI はあくまで作業補助（自動化）と提案。判断は人間」が自然と当たり前になるプロダクト設計
      • 「 AI が正解を決める、自動意思決定エンジン」に寄せるとリスクが高まる。「意思決定支援システム」に留める。その支援・提案の根拠は、店舗固有の情報資産。それを食べて育つツール
      • 「 AI: A を提案、スタッフ: B を採用、結果: 良好」と毎回記録を採るのも良いし、漠然と意思決定を求めるのでなく「採用・修正・却下」ボタンを並べて選ばせる（意思決定を宣言させる） UI も考えられる。
      • 「 AI の提案、スタッフの意思決定、その結果」が大量に蓄積されれば、「この店舗ではデータよりスタッフの直感を重視しながら AI 提案するほうがうまく回る」という学習素材にもなる。