患者が「歯がしみる」「銀歯が気になる」といった自分の言葉で症状を入力すると、AIが分類し、医院ごとのコンテンツをTikTok風の全画面縦スワイプUIで提示する——歯科医院向けのAI症状検索プラットフォームを開発しました。守秘義務のあるプロジェクトのため、サービス名・クライアント名は伏せてお届けします。

「サイトのコンテンツが患者に届かない」という課題

クライアントは現役の歯科医師。「サイトにコンテンツを充実させても、患者に届かない」という違和感を持っていました。

従来の医院サイトは症状名や診療メニューで構造化されています。ところが患者は、自分の症状が「知覚過敏」なのか「虫歯」なのかもわからない。「なんとなく歯が痛い」という曖昧な言葉でしか悩みを表現できません。結果、丁寧なコンテンツを用意した医院ほど埋もれ、広告費をかけた医院に患者が流れる。ここに切り込むためのプラットフォームを作れないか、というのがご相談でした。

「TikTok風UI」を選んだ理由

UIとして特徴的なのが、患者が症状を入力するとマッチしたコンテンツを全画面 + 縦スワイプで切り替えるTikTok風UIを採用したこと。

従来のFAQ型やチャットボットは選択式なので、「選択肢に自分の悩みがない」時点で離脱します。一方TikTok型は「受け身で受け取り、興味があれば掘る、なければ次へ」という消費体験で、意思決定コストが極めて低い。医療情報を「読ませる」のではなく「流す」ことで、患者が能動的に学ぶ入口を作れる、と考えました。

合わせて、「役に立ちましたか？」のような明示的フィードバックは取らない設計に。視聴時間・スキップ速度・CTA到達などの行動データから興味を推定します。意識的な回答より、無意識の反応のほうが正直な信号になるからです。

技術選定：LLMは差し替え可能な抽象化レイヤに

構成はNext.js + TypeScript（Widget / 管理画面 / LP）+ Python FastAPI（API）+ Supabase + GCP。フロントはVercelに乗せる一方、API・分析基盤はGCP（Cloud Run + BigQuery）に寄せています。データ活用の主戦場が「行動ログの蓄積と分析」だから、BigQueryを中心に据える判断です。

症状の分類はLLMで行いますが、OpenAI / Geminiを差し替え可能な抽象化レイヤを1枚噛ませています。LLM界隈はモデル・API・料金体系が短いスパンで変わり続けるため、特定ベンダーに直接依存させるとモデル更新のたびにビジネスロジック側まで書き換えることになる。「モデルは常に更新される前提でアーキテクチャを組む」という設計思想です。

マルチテナントは初日から入れました。1医院で作ってから後付けでマルチテナント化するのは、認証・データ分離あたりで必ず地雷を踏みます。Row Level Securityで医院ごとにデータを完全分離しています。

本質的な価値は「行動ログを起点にした改善サイクル」

このプロダクトの本質的な価値は、Widgetの機能そのものではなく行動ログを起点にした改善サイクルにあります。全医院のログをBigQueryに集約することで、「このコンテンツの視聴時間が長いので類似コンテンツを追加してはどうか」「この症状ワードでマッチが弱いのでコンテンツを1本足しませんか」といった提案を、プラットフォーム運営側から能動的に出せる構造です。

広告費の消耗戦ではなく、「知識で選ばれる医院を作る」というクライアントのビジョンを、技術構成のレベルで再現することを目指しました。

まとめ

面白かったのは、単なるAIチャットボットではなく「現場の課題感 → プロダクト設計 → 技術構成 → 運用ループ」が一気通貫でつながっていたこと。ITベンダーが作った「歯科向けツール」ではなく、現役歯科医師が「患者のために欲しかったもの」として設計している。ここが競合との根本的な違いです。

弊社では、こうした業界特化SaaSやAI × 業務プラットフォームの開発を、要件定義・技術選定からローンチ後の運用改善までお手伝いしています。お気軽にご相談ください。