LINE公式アカウントで、広告からの予約と再来院をつなぐ

1. いま起きていること

• LINEを通ると広告のデータが途切れる: 9/26の理事長MTGで弊社田内が申し上げた点です。院のLINEに直接飛ぶと、どの広告から来た方が予約・来院したのかが分からなくなります
• インプラントLPにLINEの入口がない: 着地はWEB予約フォーム（メール通知）と電話の2つだけです
• 広告→予約→来院が1本で追えない: GA4で取れているのは「予約ボタンのタップ」と「予約完了」までで、来院まではつながっていません
• LINEが院ごとに分かれている: 院別アカウントが約22院、共通アカウント（院IDで8院）があり、法人全体のアカウントはありません

理事長の「どうせやるなら早く」を受け、院が増える前に基盤を作る案です。

2. 提案の全体像

広告 → LP（LINEボタンを追加）→ 同意 → 友だち追加 → 予約（LINE内で完結）
     → 前日リマインド → 来院 → 定期検診の案内 → 再予約
          ↑                                    │
          └──── 予約完了を広告媒体に返す ─────────┘

• 法人共通のLINE公式アカウントを新しく1つ作り、広告からの入口・予約・全体配信をここに集めます
• 広告のクリック情報は、友だち追加の前に暗号化して保存します。予約が完了したら、その情報を添えて媒体に「予約が取れた」と返します
• 既存の院別LINEは、人の対応が必要な相談の受け皿として今のまま使います（8章）

3. 座組（体制）

会議体と報告

• 週次: 定例で、PGからどこまで進んだか・課題・確認事項をご報告します
• 月次: 友だち追加・予約・来院・広告費あたりの予約数をスライドにまとめ、数値としてご報告します
• 配信文の承認: PGが文面を作り医療広告ガイドラインで点検 → 片寄様が承認 → PGが配信します

4. LINEシナリオ全体

患者さんがLINEで受け取るメッセージと、その順番の全体です。v3の22通を見直し、未予約の方へのフォロー、無断キャンセル後の再案内、来院確認を起点にした来院後のお礼と定期検診までを、1行1文面の41項目にまとめました。

設計の考え方は次の5つです。

• 同意1タップで友だち追加、「予約する」1タップで予約画面が開きます。広告の学習は予約完了に合わせ、来院はスタッフの来院確認を起点に広告媒体へ返します
• 1通に入れる次の行動は1つです。CT検査費用の文は「初回相談のご案内（S03）」と「初回相談の予約完了（S10a）」の2か所だけに置きます
• 症状・既往・お薬・個人情報はLINEに書いていただかない設計です。受信はキーワードでの判定を先に済ませ、通った本文だけをAIに渡します
• 未予約の方へのフォローは2通、定期検診のご案内も2通、無断キャンセル後の再案内は1通で止めます
• 受信には必ずその場で返します。AIが作るのは下書きまでで、送るのはスタッフです

4-1. 全体の流れ

flowchart TD
  AD["広告（Meta・Google）"] --> LP["インプラントLP<br>「LINEで無料相談を予約」"]
  LP --> C["S01 同意画面"]
  C -->|"同意しない"| BK["LPに戻る<br>院の電話を表示"]
  C -->|"同意して友だち追加"| F["友だち追加"]
  F --> G["S02 初回挨拶（すぐに）"]
  G --> O["S03 初回相談のご案内（60秒後）"]
  O --> Q{"予約したか"}
  Q -->|"予約した"| B["B1〜B5 予約画面<br>院→内容→日時→お名前など→確認"]
  Q -->|"予約しない"| F1["F1 未予約フォロー1<br>翌日18:00"]
  F1 -->|"まだ予約しない"| F2["F2 未予約フォロー2<br>さらに3日後18:00・ここで終了"]
  F1 -->|"予約する"| B
  F2 -->|"予約する"| B
  B --> D["S10a・S10b 予約完了<br>予約画面とトークでお知らせ"]
  D -.->|"予約完了を広告媒体へ返す"| AD
  D --> R["S11 前日リマインド<br>前日12:00"]
  R -->|"キャンセル"| CX["S17 キャンセルの受付"]
  R --> V{"V1 来院確認<br>スタッフが管理画面で記録"}
  V -->|"来院なし"| NS["14日間は配信を止める<br>S18 再案内（1通のみ）"]
  NS -->|"予約する"| B
  V -->|"来院"| T["S13a〜c 来院後のお礼<br>確認当日17:00"]
  V -.->|"来院を広告媒体へ返す"| AD
  T --> K1["S14 定期検診のご案内<br>最終来院から3か月"]
  K1 --> K2["S15 定期検診のご案内<br>6か月・ここで終了"]
  K1 -->|"検診を予約する"| B
  K2 -->|"検診を予約する"| B

• 停止条件: 未予約フォローは「予約した」「ブロックした」「2通送った」のどれか1つで止めます
• 前日リマインドは12:00に送り、当日朝のご案内は送りません
• ブロックを解除して再び友だち追加した方にはS19を送り、S03・F1・F2は送りません
• GMOの来院データが取れるまでは、スタッフの来院確認だけを来院の記録として扱います

4-2. シナリオ一覧

差し込み項目は {院名} {院の電話} {予約サイトURL} {日時} {氏名} {メニュー} {返信の目安} {次回目安} に統一します。院ごとの固定項目（{診療時間} {休診日} {駐車場の案内} {支払方法} {初診の流れ} {初診の所要時間} {自由診療の案内URL}）は院の基本情報から差し込みます。{予約番号}は予約データ（GMOの予約成立時の値）、{翌営業日}は診療カレンダーから取ります。

No.の頭文字は、S＝配信、R＝リッチメニュー、B＝予約画面、V＝来院確認、F＝未予約フォロー、H＝受信への返答、Q＝よくある質問、T＝時間外です。

4-3. 受信メッセージの判定

患者さんからメッセージが届いたときは、次の順で判定します。受信の本文はデータベースに保存せず、判定の結果だけを残します。

1. キーワードでの判定と情報の除外（全件・AIより先）: 時間外を含むすべての受信に、まずこの判定をかけます。院の資料を使ったAIの下書き（RAG）と判定用AI（Jev）の手前で行い、当てはまった本文と、安全を確かめられない本文はAIに渡さず人が対応します
2. 時間外（デモでは18:00〜9:00）: T1・T2を返します。本文は保存せず、AIにも渡しません。受信箱には受信の記録だけを残し、翌営業日にスタッフがトーク画面で本文を見て対応します
3. それ以外: 院の資料をもとにAIが下書きを作り、判定用AIが5つの質問で確かめます。患者さんにはその場でH3の受付文を返し、下書きは受信箱に置きます

判定用AIに聞く5つの質問（はい／いいえで答えさせます）

1. この文は、症状・痛み・治療の経過・薬について相談していますか
2. この文は、不満・苦情・謝罪の求めを含みますか
3. この文は、予約の変更・キャンセルを求めていますか
4. この文は、今日や明日など急ぎの対応を求めていますか
5. この下書きは、院の公開資料だけを根拠に、質問に過不足なく答えていますか

• 1・2に「はい」が0.3以上なら人の対応を必須にし、下書きは捨てます。3が「はい」なら下書きをH5の文に差し替え、4が「はい」なら受信箱の先頭へ
• 5が0.8未満なら、下書きに「要修正」の表示
• 迷ったら人へ: 判定が割れたとき、エラーやタイムアウトのときは人へ回します。開始から2週間は、全件をスタッフの目で確認する期間です
• 受付文の自動返信: その場で自動で返すのは、H1〜H5と時間外のT1・T2という決まった文だけ。質問への答えそのものは送りません
• 下書きは人が送る: 下書きは受信箱に置き、スタッフが中身を確かめ、必要なら直してから送ります。AIが患者さんに直接送ることはない設計です
• 月次の見直し: 判定用AIの結果とスタッフの最終判断が食い違った件を、2つに分けて数えます。人が要対応に変えた件は見落とし、要対応と出たのに人が不要とした件は判定しすぎです。見落としが1件でもあれば、その質問の基準を0.05下げるか、キーワードに語を足します。判定しすぎが全体の2割を超えた質問は、基準を0.05上げる対象です。変更は1回に1問だけにし、変更前後の値と理由を記録して、翌月に効果を確かめます

予約の変更・キャンセルは、予約システム（GMO メディカル革命）側に操作の窓口がないため、院の電話か予約サイトへご案内します。

4-4. 再来院の設計

• 数え始め: 来院後のお礼と定期検診のご案内は、スタッフが管理画面で「来院」を記録した日から数えます。キャンセルが無かったことを来院とはみなしません
• GMOの来院データが取れない間: スタッフの来院確認だけを起点にします。本番でGMOの来院データが取れたら、スタッフの記録との一致率を2週間見てから自動に切り替えます
• 間隔と回数: 次回の予約が無いまま最終来院から3か月（S14）と6か月（S15）の2回です。治療中の方、次回の予約がある方には送りません
• やめ時: S15で終わり、文面でも「今回で最後」とお伝えします。次に来院の記録が入れば、その日から数え直します。ブロックされた方には送りません
• 無断キャンセル後: スタッフが「来院なし」を記録すると、その方への配信を14日間止め、14日後の10:00にS18を1通だけ送ります。その間に予約が入れば送りません。2回目の「来院なし」では送らず、院へ知らせます
• 書き方: 「時期の目安」という言い方にそろえ、割引や期限は書きません
• 院のLINEへの橋渡し: 来院後のご相談は、リッチメニュー「相談する」（R4a）から院のLINEへご案内します。法人のLINEは予約と時期のお知らせを、日々のやり取りは院のLINEを受け持ちます

5. 医院から見た運用

• AIの返信は「下書き」から始めます: AIが返信案を作り、スタッフが確認して送ります。自動で送るかどうかは3か月の実績（そのまま使えた割合・誤りの割合）を見て決めます（4-3）
• 症状の相談はAIに渡しません: 「痛い」「腫れた」などの言葉を院内のルールで見つけ、電話へご案内します。この本文は外部のAIに送りません
• 人の対応が要る相談は院のLINEと電話へ: 自院のLINEを持つ院は、そのLINEで続きを受けます。院スタッフは今のチャット画面のまま返信でき、他院の相談は見えません
• 本部の受信箱: 自院のLINEがない院（共通アカウントの8院など）の相談は、本部の担当者がまとめて返します。担当者を割り当て、二重返信を防ぎます
• 配信は承認してから送る: 文面は作成→医療広告ガイドラインの点検→片寄様の承認→配信の順です（3章）

6. 広告の成果が見える

• CAPI（広告媒体に成果を返す仕組み）で「予約完了」を返す: Metaへは予約完了を「Schedule」として返し、スタッフの来院確認のあとに来院をオフラインの成果として追加します。Googleには広告クリックID（gclid）をつけて予約完了と来院を取り込みます。友だち追加は記録しますが、媒体には返しません
• 患者DBとつなぐ: 弊社で構築中の患者DB（P2）と、同意をいただいた方についてつなぎ、来院・再来院まで追えるようにします

記録するイベント（順番）

lp_view → line_cta_click → consent_agree → friend_add → reserve_start → reserve_clinic → reserve_menu → reserve_datetime → reserve_info → reserve_confirm → reserve_complete → visit_confirmed／reservation_cancel／noshow → recall_sent → recall_click → reserve_complete（src=recall）→ visit_confirmed（src=recall）

各イベントがどの文面で起きるかは、4-2の表の「計測イベント」列のとおりです。

どの広告の成果かの結びつけ

• LPを開いたときに訪問ごとのID lp_sid を発行し、広告クリックID、流入元を示すUTM、オファーの種類 offer=ct0 を保存します。同意画面でLINEのユーザーIDと結びつけます
• 最初に結びついた訪問を first touch、予約完了の直前の訪問を last touch として両方保存し、レポートは last touch を主に見ます
• 広告媒体へ送るのは、予約・来院のイベント、日時、イベントID（event_id）、電話番号のハッシュ値、広告クリックID（Metaは fbc・fbp、Googleは gclid）だけです。氏名・症状・生年月日・メニュー名・院名は送りません。送る項目は同意画面の文と一致させます（7章）

見る指標

A/Bテストの初期案

1. 初回相談のご案内 S03 を、60秒後に送るか送らないか
2. 未予約フォロー1 F1 を、翌日18:00に送るか友だち追加の3時間後に送るか
3. 前日リマインド S11 を、12:00に送るか19:00に送るか。来院なしの割合で比べます

目標値は現状の数値（広告費・予約数・来院率の直近3か月）をいただいてから一緒に決めます。

7. 安全と規制

• 医療広告ガイドライン: LINEの配信・自動返信・メニューも対象です。効果の断定、費用の強調、体験談、他院比較は使いません。見出しとボタンには費用の言葉を置かず、CT検査費用の文はS03とS10aの本文だけに置きます。「無料相談」という言葉を使うのは、LPのボタンだけです
• 自由診療の案内ページが配信の条件: CT検査費用の文を置くS03・S10aと、自由診療と表示するB2f・Q3には、{自由診療の案内URL}を添えます。案内ページで明示するのは、治療内容・標準的な費用・主なリスクや副作用の3点です。医療広告ガイドラインでは、自由診療の費用などを広告に載せるとき、こうした情報をあわせて示すことが条件になっています。この条件を案内ページで満たします。御院の自由診療の案内ページが整い、公開と記載内容の確認が済むまで、S03・S10aは配信しません
• こちらで足す文言の設計方針: LPに追加するLINEボタンと案内文、LINEの配信文は、医療広告ガイドライン（費用の強調・他院との比較で優れていると示す表現・「最高」「No.1」などの最上級・体験談を使わない）と景品表示法（実際より有利だと誤認させる表示＝有利誤認を避ける）に沿って作っています。まだ作っていない機能は、できることとして書きません
• 先方の既存LP由来の表現: 現行LPから引き継ぐ表現は、こちらでは書き換えず、御院の広告チェック体制で再確認をお願いします（付録の確認事項4）
• 同意画面に書く範囲: 友だち追加の前の同意画面（S01）で、使う情報と目的に加えて、広告媒体へ送る項目を明記します。送るのは、予約・来院のイベント、日時、イベントID、電話番号のハッシュ値（元に戻せない形に変えた値）、広告クリックID（fbc・fbp・gclid）です。氏名・症状は送りません。6章で送る項目を、同意画面に書いた範囲より広げません
• 要配慮情報を扱わない設計: 予約画面には自由に書ける欄を置かず、受信の本文も保存しません。キーワードでの判定と情報の除外は全件にかけ、安全を確かめられない本文はAIに渡さず人が対応します（4-3）
• 誤った返信を防ぐ: AIは患者さんに直接送りません。自動で返すのは決まった文だけです
• 送りすぎを防ぐ: 未予約フォロー2通・定期検診のご案内2通・再案内1通で止めます。F1・F2のあとのブロック率が2%を超えたら、配信を止めて見直す決まりです。こちらから送るpush配信は、1人に月4通までにします
• 配信前の点検: 配信文は、医療広告ガイドラインと景品表示法の点検に加え、日本語の機械チェック（lint）で警告ゼロを確かめてから、片寄様の承認に回します
• データの置き場所: 患者に関わるデータはGoogle Cloudの東京リージョンに置く案を基本にします（患者DBと同じ環境）。最終判断は御院の規程に照らして決めます
• 変更・キャンセル: 電話か予約サイトでお受けします（4-3）

8. 既存の仕組みとの関係

• 院別LINE（約22院）・共通LINE（8院）: 移行や統合はしません。人の対応が要る相談の受け皿として今のまま使います。統合するかは、運用の実績を見て100院化の前に改めてご相談します
• Lステップとの違い
  • Lステップ: 配信とシナリオが得意。院別アカウントでの利用はこのまま続けられる
  • ただし予約はGMOの空き枠と別管理で、30院を1アカウントに集めると全院の相談が全員に見える
  • 本案: GMOの空き枠で予約を取り、広告→予約→来院を1人単位でつなぐことに絞った仕組み
• GMO メディカル革命との連携: Web API（有料オプション）で空き枠を表示し、新規予約をLINE内で作成します。院内や電話で入った予約・キャンセルは、5分ごとに取り込んでLINE側に反映します

9. デモで見られるもの

2026年10月2日時点の状態です。

動くもの

仮のデータ・まだつないでいないもの

• 予約システム: 本物のGMO メディカル革命には接続していません。GMOのWeb APIと同じ形で応答する試験用の仕組みに、仮の空き枠を入れて動かしています。院・電話番号・予約サイトは「アルバ歯科 小田原院（デモ）」の架空の情報です
• 担当者への通知: 人へ回したときに業務チャット（Lark）へ知らせる部分は、まだ設定していません
• 来院後のお礼と定期検診のご案内: 文面（S13a〜S15）は用意済みですが、スタッフが来院を記録する管理画面がまだないため、送っていません。本番では来院確認を起点に送り、GMOの来院データが取れたら切り替えます（4-4）
• 広告媒体への返却: 予約完了を媒体へ返すデータの形は作ってありますが、デモでは送らずに記録だけ残しています
• 成果の集計画面: 広告→友だち→予約→来院の数を並べる画面は、F1で作ります
• プライバシーポリシーと返信の目安: リンク先と「目安は翌営業日まで」は仮の値です
• 実際の患者情報は使いません

本番での表現: 「24時間いつでも予約」は、GMOとの接続を本番で実装し、対象の院とメニューで動くことを確かめてから使います。それまでの資料・LPでは「LINEの画面から空き枠を見て予約」と書きます。

10. 進め方とスケジュール

まず1院・1媒体で始め、結果を確かめてから全院に広げます。

• 期間は、作業者1〜1.5人が週40時間ずつ取り組む場合の想定です。フェーズを並行して進める部分や、GMO・御院からの回答待ちの期間は含みません
• 初期に取りかかる範囲は F0・F1・F2（下書きまで）・F4 です。F3は本部受信箱の最小版から始めます
• 全体の期間: ご相談のうえ決定（最短で2026年11月着手を想定）〜先行1〜3院で3か月検証後に順次（想定）（F0の回答時期で確定）
• 費用: 別途お見積り。GMOのAPI費用・LINEの通数費用・クラウド利用料は月額として別にお示しします

11. 決めていただきたいこと

1. 対象院の順番: 最初の1院と、展開する順
2. 返信の担当と時間: 本部で返す担当者、対応時間、1日の相談件数の見込み
3. 来院確認の運用: 各院のスタッフが、来院当日中に管理画面で「来院」「来院なし」を記録する運用を回せるか。記録が遅れると、来院後のお礼と定期検診のご案内も遅れます
4. 自由診療の案内ページ: 治療内容・標準的な費用・主なリスクや副作用を載せた案内ページを、どなたがいつまでに整えるか。公開と記載内容の確認が済むまで、S03・S10aは配信しません（7章）
5. 同意画面の文とプライバシーポリシー: 同意画面（S01）に入れた広告の効果測定の1文を、御院のプライバシーポリシーに合わせて載せてよいか
6. 通院中の方へのS03: すでに通院中の方が友だち追加したときも、初回相談のご案内（S03）を送るか。送らない場合は、友だち追加のときに「初めて／通院中」を1問だけお聞きします
7. GMO APIの契約と費用: 弊社佐藤からGMOへ確認した結果をもとにご判断ください
8. 友だち追加広告を試すか: LINE広告は医療機関の掲載に制限がかかる場合があるため、Meta・Google経由を基本とし、試すかどうかを決めていただきます
9. データの置き場所の方針: Google Cloud東京を基本とすること、外部AIに症状を含まない短い文を送ることの可否

12. 付録: 要確認事項