shika-inbox
概要
歯科医院に届いた問い合わせを1つの受信箱にまとめ、分類・急ぎの判定・返信の下書きまでを自動で用意するWebアプリ。
受け取り口は3つある。医院のホームページに置く公開フォーム、医院の問い合わせ用メールアドレス(届いたメールが自動で受信箱に入る)、電話・窓口で受けたぶんの手入力。どこから来ても同じ1つの一覧に並ぶ。
画面はメールの受信トレイに寄せてあり、まだ返していないものは太字、対応が済んだものは細字。左端の色帯で「予約・痛みの相談・料金・クレーム・求人・その他・未分類」を見分ける。急ぎの印は緊急なものだけに付く。
返信画面は開いた時点で下書きが入っているが、ワンクリックで送るボタンは意図的に作っていない。下書きの上には「この下書きの根拠」が並び、医院が設定画面に登録していない事実(時間・料金・住所など)が文中に出てきた場合は黄色の帯で警告する。
技術構成: Next.js 16 / React 19 / TypeScript / Tailwind v4 / Supabase(RLS有効) / Vercel Cron。約12,000行、専用テーブル14本。静的検査73件・カナリア27件・DBのDDL実測17件・実起動での全ルート21件・実際に押してDBが動くかの確認7件で FAIL 0。375px幅での横はみ出し0件。
なぜ作ったか
地方都市の歯科医院を調べたところ、そもそもWebからの問い合わせ導線が無い医院が少なくなかった。一方で、76.9%の歯科医院が電話受付業務に負担を感じており(SCOグループ調査)、医院にかかる電話の70%以上が予約に関するもの、診療時間外の予約希望が60%以上(ジニーのDXレポート)というデータがある。つまり問い合わせは存在していて、その全部が電話に来ている。
そこで「フォームを付けます」で終わらせず、「届いた問い合わせの返信下書きまで自動で作ります」まで含めた形にした。
もう一つ、作りを決めた大きな理由がある。歯科向けの競合を7本調べたところ、6本が「AIが患者さんに直接答える」型で、「人が読んでから送る」型は1本も無かった。 ところが医療広告ガイドラインは、チャットボットが吐いた文言もウェブサイトと同様に医院の広告として規制対象としており、罰則は6月以下の懲役または30万円以下の罰金、悪質な場合は開設許可の取消まである。そこであえて逆を行き、下書きまでしか作らない形にした。
どういう場面で使うか
歯科医院の受付スタッフと院長が、診療の合間の数分で触ることを前提にしている。
- 朝いちで受付が画面を開き、上から順に返していく(急ぎの印が付いたものが上に並ぶ)
- 夜間や休診日に届いた問い合わせを、翌朝まとめて処理する
- 電話で受けた相談を「電話・窓口の記録」から手入力し、Web経由のものと同じ一覧で追う
- 「駐車場はありますか」「日曜は診療していますか」のような毎回同じ質問に、登録済みの事実から作られた下書きで返す
- 痛みの相談は文章で解決させず、受診のご案内・当日の急患枠・電話番号の3点に固定した下書きが出る
- 12時間以上返していない件を、翌朝の通知で拾う
自動化されているポイント
- 分類と急ぎの判定 — 届いた本文から「予約／痛みの相談／料金／クレーム／求人／その他」を判定する。判定できないものは推測で振り分けず「未分類」に置く
- 返信の下書きの生成 — 医院が設定画面に登録した診療時間・臨時休診・料金・アクセス・定型文だけを材料に、返信の文案を作る
- 事実の捏造の機械検出 — 下書きに出てきた数字や固有名詞を、登録された値と1つずつ突き合わせる。結び付かないものがあれば黄色の帯で警告し、根拠の一覧も表示する
- 診療時間外の自動返信 — 営業時間の外に届いたものへ、設定した文面ですぐ返す
- 返し忘れの朝いち通知 — 設定した時間(既定12時間)を超えて返信の記録が無い件を、毎日決まった時刻に自動で拾って通知する
- メールの自動取り込み — 医院の問い合わせ用アドレスに届いたメールを、webhook経由で自動的に受信箱へ入れる。受信時刻は実際に相手が送った時刻で記録する(取り込み時刻で記録すると、配信のリトライぶんが「たった今届いた」ことになり、放置時間が短く見えてしまうため)
- 公開フォームの荒らし対策 — 極端に短い滞在時間や自動投稿の特徴を判定して弾く
使い方(画面の流れ)
①トップは受信箱。まだ返していないものが上、対応が済んだものは下に畳まれている。
左端の色帯が分類、その隣が差出人・件名・冒頭の一文。急ぎの印は緊急なものだけに付く。 全部に3段階の優先度を付けると、全部が目立って何も目立たなくなるため、印を付ける対象は絞ってある。分類できなかったものは点線の帯で「未分類」として残り、推測でどこかに振り分けられることはない。
②返信画面。開いた時点で下書きが入っていて、その上に「この下書きの根拠」が並ぶ。
黄色い帯は、下書きの中に医院の登録内容と結び付けられなかった書き方があったという警告。 下書きは隠さず出したうえで、どこを確かめるべきかを伝える形にしてある。「この下書きの根拠(3件)」を開くと、その文がどの登録内容から作られたかが1件ずつ出る。
ボタンは上下2段に分けてある。上段の[メールソフトで返信][本文をコピー]は端末が動くボタンで、押しても記録は残らない。下段の[送信しました][電話でお答えした][返信不要]が記録するボタン。ここを1つに混ぜると、送り直すたびに記録が増えるか、記録し忘れるかのどちらかが必ず起きる。ワンクリックで送信するボタンは、この画面のどこにも無い。
③設定画面は、左に入力欄・右にスマートフォンの形をしたプレビュー。
打ちながら患者さんへの見え方が確認できる。ここに登録した診療時間・臨時休診・料金・アクセス・定型文が、そのままAIの下書きの材料になる。逆に、ここに入れていないことは下書きに書かれない。 空欄のところは「お答えできません」と返る。
④スマホ幅(375px)でもそのまま使える。
受付カウンターで立ったまま片手で押せる大きさにしてある。1行を4要素で横に並べず、差出人と時刻／件名／冒頭の一文の3段に折り返す。横スクロールが発生する要素は0件。
訴求ポイント
一番の差別化は「AIに答えさせない」こと。 競合7本のうち6本は「AIが患者さんに直接答える」型だった。医療広告ガイドラインはチャットボットの文言もウェブサイト同様に規制対象とし、罰則は6月以下の懲役または30万円以下の罰金、悪質な場合は開設許可の取消まである。下書きまでしか作らず必ず人が読んでから送る形は、院長にとって機能ではなく保険になる。
「この下書きの根拠」を見せられること。 AIが書いた文の中に医院が登録していない事実が混ざっていないかを機械で突き合わせ、その結果を画面に出す。「AIは嘘をつくのでは」という一番大きな不安に、実物の画面で答えられる。
分からないものを分かったふりで扱わないこと。 分類できない問い合わせは「未分類」に置き、判定材料が無いものを推測で振り分けない。この姿勢は検査結果の数え方にも徹底していて、確かめられなかった項目は合格にも不合格にも混ぜず「未確認」のまま残している。
課題提示から解決までが1本で繋がること。 「問い合わせフォームが無い」という課題をその場で示し、そのまま「フォームを付けたうえで、届いたぶんの返信下書きまで自動で作ります」まで提案できる。
技術構成: Next.js 16 / React 19 / TypeScript / Tailwind v4 / Supabase(RLS有効) / Vercel Cron。画面7ルート、専用テーブル14本、約12,000行。検査145項目(静的73／カナリア27／DBのDDL実測17／実起動での全ルート21／実際に押してDBが動くかの確認7)でFAIL 0。
現在はローカル環境でのみ動作。本番公開は準備中です。掲載している画面はすべて架空のデータによるもので、実在の医院名・患者名は含まれていません。