クリニックのSalesforce Health Cloud活用｜問い合わせ一元化の整理と医療業界の運用設計

クリニック経営において、患者からの問い合わせ対応は「経営の生命線」です。しかし、分院展開や自由診療の強化に伴い、電話、Webサイトのフォーム、LINE、InstagramのDMなど、患者とのタッチポイントが複雑化しています。その結果、スタッフは複数のツールを行き来し、情報の転記ミスや対応漏れが発生し、最終的には「どの広告から来た患者が、最終的に受診に至ったのか」というマーケティング投資の対効果すら不透明になっているケースが散見されます。

本記事では、医療特化型のCRMプラットフォームであるSalesforce Health Cloudを核とした、問い合わせ一元化の概念と具体的なシステム構成について解説します。単なるツール導入に留まらず、実務者が直面する「電子カルテとの使い分け」や「LINEの名寄せ」といった技術的課題まで踏み込んで整理します。

1. クリニックにおける問い合わせ一元化の必要性とHealth Cloudの役割

1.1 患者接点の多様化が招く「情報の断絶」という課題

多くのクリニックでは、予約システム、LINE公式アカウント、そして電話が個別に運用されています。この状態では、以下のような「情報の断絶」が発生します。

• LINEで相談してきた患者が、Webフォームから別名義で予約を入れ、初診時に同一人物だと判明する。
• 電話で問い合わせを受けた内容がメモ書きで終わり、CRM（顧客管理）に蓄積されないため、次回の接客に活かせない。
• Web広告（Google/Meta）のコンバージョン計測が「予約完了」までしか追えず、その後のキャンセルや「実際の来院・成約」と紐付かない。

1.2 なぜSalesforceの標準機能ではなくHealth Cloudなのか

Salesforceには一般的な「Sales Cloud」や「Service Cloud」もありますが、クリニックがHealth Cloudを選択すべき最大の理由は、「患者（Patient）」を中心としたデータモデルが標準実装されている点にあります。

Health Cloudでは、従来の「取引先（Account）」や「取引先責任者（Contact）」を医療用に拡張した「個人取引先（Person Account）」をベースとし、家族構成、ケアチーム、タイムライン形式の活動履歴などが最初から定義されています。これにより、問い合わせ履歴を「一人の患者のジャーニー」として直感的に把握することが可能になります。

1.3 医療DXの基盤となる「患者360度ビュー」の概念

「患者360度ビュー」とは、患者に関するあらゆるデータ（属性、問い合わせ履歴、予約状況、過去の診療サマリー、マーケティングセグメント）をHealth Cloud上で統合することです。問い合わせ窓口（コールセンターや受付）がこの画面を一目見るだけで、「この患者様は昨日LINEで〇〇について相談され、本日お電話をくださった」というコンテキストを把握できる状態を目指します。

2. Health Cloudを中心とした問い合わせ一元化のアーキテクチャ設計

2.1 Webフォーム・LINE・電話の統合フロー

問い合わせを一元化する場合、すべてのチャネルからの入力をHealth Cloudの「リード（Lead）」または「ケース（Case）」オブジェクトに集約します。新規患者であれば「リード」として起票し、カウンセリング予約や初診が確定した段階で「患者（個人取引先）」へ変換するフローが一般的です。

ここで重要なのは、既存のデータ基盤との親和性です。例えば、Web行動とLINE IDをシームレスに統合することで、問い合わせ前の検討状況まで可視化できるようになります。このあたりの設計思想については、以下の記事が参考になります。

LIFF・LINEミニアプリ活用の本質。Web行動とLINE IDをシームレスに統合する次世代データ基盤

2.2 Health Cloudにおけるデータオブジェクトの使い分け

Health Cloudでのデータ管理では、以下のオブジェクトを戦略的に使い分ける必要があります。

2.3 外部ツールとの連携比較表

Health Cloudにデータを流し込むためのツール選定は、API連携の柔軟性とコストのバランスで決まります。

3. 実務：チャネル別・Health Cloud連携の構築手順

3.1 LINE連携：Messaging APIとSalesforceのID紐付け

クリニックにおいて、LINEは最もコンバージョンに近いチャネルです。しかし、LINE上のユーザー（UID）とSalesforce上の患者（ID）が紐付いていなければ、一元化は不完全です。

1. LIFF（LINE Front-end Framework）の活用: 予約フォームや問診票をLIFFで構築し、ユーザーがLINE内で入力した瞬間にSalesforceへデータを飛ばします。
2. ログイン連携: LINEログインを介してWebサイトと連携させることで、Cookie情報とLINE UIDを名寄せします。

詳細な名寄せのアーキテクチャについては、こちらのガイドが実務上の指針となります。

WebトラッキングとID連携の実践ガイド。ITP対策・LINEログインを用いたセキュアな名寄せアーキテクチャ

3.2 Webフォーム連携：Web-to-Leadの限界と対策

Salesforce標準の「Web-to-Lead」は、無料で利用できる非常に便利な機能ですが、クリニック実務では「スパム対策」や「添付ファイル（患部の写真送付など）」への対応が課題となります。
より高度な要件（複数回のやり取りを1つのスレッドにまとめる等）がある場合は、Salesforceが提供するポータル機能「Experience Cloud」で患者マイページを構築するか、外部フォームツール（FormAssembly等）を介してAPIでHealth Cloudの「ケース」に流し込む設定を推奨します。

3.3 電話（CTI）連携：着信ポップアップの設定

電話問い合わせの一元化におけるゴールは、「受話器を取る前に、相手が誰で、前回の診察がいつだったかを知る」ことです。
Amazon Connectなどのクラウド電話をSalesforceと統合すると、電話番号をキーにして個人取引先を検索し、一致するレコードがあれば自動で画面を立ち上げることができます。これにより、患者に診察券番号や名前を再度聞き直す手間が省け、顧客体験（CX）が劇的に向上します。

4. 電子カルテ（EMR）との責務分解とデータ連携

4.1 「診療データ」と「コンタクトデータ」の境界線

Health Cloudを導入する際、最も多い失敗が「Salesforceにすべての医療データを入れようとする」ことです。しかし、日本の医療法規制や現場の入力速度を考慮すると、以下の責務分解が適切です。

• 電子カルテ（EMR）: 診療録、処方箋、画像診断データ。法的な保管義務があるもの。
• Salesforce Health Cloud: 問い合わせ履歴、予約管理、マーケティング情報、紹介元管理、術後満足度アンケート。

つまり、Health Cloudは「診療の前後（プリケア・ポストケア）」を管理する器として機能させます。

4.2 API非対応カルテとの「CSV/RPA」による現実的な連携

多くの国産電子カルテは、APIが公開されていないか、連携費用が極めて高額です。この場合、以下のステップで「疑似的な同期」を行います。

1. 電子カルテから1日1回、その日の来院患者リストをCSVエクスポートする。
2. Salesforce Data Loader、あるいはRPA（Power Automate等）を使用して、Health Cloudの個人取引先（患者マスター）を更新する。
3. 「来院フラグ」や「最終診察日」をHealth Cloudに書き戻すことで、再診促進のLINE自動配信などのトリガーにする。

このように、システムを繋ぐのは必ずしもAPIである必要はありません。重要なのは、データの整合性が保たれていることです。SFAやCRMをどのように他のシステムと連携させるべきかの全体像については、以下の記事で詳しく解説されています。

【図解】SFA・CRM・MA・Webの違いを解説。高額ツールに依存しない『データ連携の全体設計図』

4.3 3省2ガイドラインを意識したセキュリティ設計

医療情報を扱う以上、厚生労働省、経済産業省、総務省が定めるガイドラインへの準拠は不可欠です。Salesforce自体はこれらに準拠した設定が可能ですが、「利用者側の設定ミス」による漏洩リスクは常に存在します。多要素認証（MFA）の強制、IP制限、そして「不要な個人情報をSalesforceに持たない（カルテのリンクのみ置く）」といった最小特権の原則を徹底してください。

診療科・クリニック規模別 × Salesforce Health Cloud問い合わせ一元化の設計パターン × EMR連携の実務ポイント 早見表

前のセクションでSalesforce Health Cloudを中心とした問い合わせ一元化のアーキテクチャ設計とチャネル別の構築手順を説明しましたが、「一般内科・単科クリニック」「複数科・外来中心のクリニック」「美容・自由診療クリニック」「訪問診療・在宅医療クリニック」ではHealth Cloudへの問い合わせ統合の優先チャネルとEMR連携の設計アプローチが異なります。クリニックの診療形態に合わない統合設計は「患者からの問い合わせが複数チャネルに分散したまま」または「スタッフの入力工数が増えてHealth Cloud導入前より業務が増える」問題を引き起こします。診療科・規模別の設計パターンとEMR連携の実務ポイントを整理しました。

この表でSalesforce Health Cloudのクリニック問い合わせ一元化において最重要の原則が「診療形態（一般外来・美容・訪問診療）と規模（スタッフ数・患者数）によってHealth Cloudに統合すべきチャネルとEMRとの責務分解の設計が根本的に異なるため、導入前の業務フロー整理と患者データの取り扱いポリシーの確立を設計の出発点とすること」です。医療機関でのHealth Cloud導入はIT設計の問題である前に「患者データの保護・スタッフの受け入れ・医師のワークフローとの整合性」という医療現場固有の課題を先に解決することが導入成功の最大の鍵です。

5. 問い合わせ一元化によるKPI可視化と運用改善

5.1 広告チャネル別のCPA・予約転換率（CVR）の計測

Health Cloudに問い合わせが統合されると、これまで「点」でしか見えなかったデータが「線」になります。
Google広告から入った「リード」が、その後何度LINEで質問し、最終的にどの施術を成約したのか。この「LTV（顧客生涯価値）」に基づいた広告運用の最適化が可能になります。

5.2 スタッフの応対工数削減と「再診・離脱」の検知

問い合わせが一元化されると、ダッシュボードで以下の指標をリアルタイムに監視できます。

• チャネル別の平均応答時間（どのチャネルがボトルネックになっているか）。
• 未読・未返信の問い合わせ件数（対応漏れのゼロ化）。
• 特定の期間来院がない患者への「自動フォローアップ」の対象数。

5.3 よくある導入失敗パターンと回避策

最後に、Health Cloudによる一元化が失敗する典型的なパターンを挙げます。

• 入力項目の多すぎ: 現場の受付スタッフに、詳細すぎるデータ入力を強いると、運用が形骸化します。自動取得できるデータは自動化し、手入力は最小限にします。
• 現場不在の設計: 本部や経営層だけで要件を決め、現場のオペレーション（電話を取りながらのPC操作など）を無視した画面構成にすると、使われないシステムになります。
• データの重複管理: 予約システムとHealth Cloudの両方に手動で情報を入れる状態になると、必ず不整合が起きます。どちらが「正（マスター）」であるかを明確に定義してください。

クリニックのDXは、ツールを入れることが目的ではありません。患者とのコミュニケーションを円滑にし、スタッフが診療サポートに集中できる環境を作ることこそが本質です。Salesforce Health Cloudを正しく設計し、散らばった問い合わせを統合することで、その一歩を踏み出すことができます。