本記事では、クリニックの集患を支援している筆者が、クリニックの予約処理業務へAI導入を実践した記録です。
トリビューやカンナムオンニ、ホットペッパービューティーといった集患プラットフォームをご活用中のクリニック経営者・院長や集患担当者の方なら、「患者さんからの予約問い合わせに、いかに速く返信するか」が集患率に直結することを痛感されているはずです。
トリビューやキレイパスなどでは、患者さんの奪い合いのような状況が起きているため、問い合わせから短時間で日程を確定させるほど予約確度が高まります。
これまでは、他院より早く予約確定するために、「できるだけ早く返信しましょう」というクリニックのマニュアルがあったのですが、このマニュアルは受付スタッフにとって大きな負担となっていました。
また、患者さんの予約希望が休日や診療時間外に入る場合も多く、そのような時には翌日以降の対応となってしまっており、その間に患者さんに予約キャンセルをされてしまうことで、予約の機会損失が生まれていました。
今回のプロジェクトが目指したのは、単なる業務効率化ではありません。患者さん対応以外の事務作業を自動化することで、スタッフが本来の診療業務に集中できる環境を作ることが、最上位の目的でした。この記事では、同じ課題を抱えるクリニック経営者・院長の方々向けに、その実装記録を共有します。
返信地獄からの解放を目指して
弊社が支援している歯科クリニックでは、この課題を長らく抱えていました。そのクリニックでは、予約管理システムに歯科クリニックに特化した予約管理システム「DESK」を採用していますが、DESKとトリビューの間には公式のAPI連携がないため、受付スタッフが両画面を手作業で行き来する運用を続けていました。
この業務を、AIエージェントである Claude Code を活用して自動化しました。開発期間は実働2日間。非エンジニアでも設計判断に関与できる形で進められた点が、今回の取り組みの特徴です。
既存の予約受付フローと課題
まず、自動化の前段として当該クリニックで行われていた手動オペレーションを整理します。
既存の予約受付フロー
- 患者さんからトリビュー経由で予約希望メールが届く
- メール本文から患者さんの氏名、希望メニュー、希望日時の候補（第一〜第三希望）を読み取る
- DESKのカレンダー画面を開き、該当する担当医の空き枠を確認する
- 患者さんの希望日時とDESKの空き枠を照合する
- 合致する枠があれば、トリビュー管理画面にログインし、日程を確定して返信する
- DESKに予約ブロックを作成する
- スタッフ間共有のためSlackに報告する
一件あたりの処理に、5〜10分ほどかかっていました。
運用上の課題
時間的な問題よりも深刻だったのは、この作業を「短時間で確実に完了させる」必要があるという制約でした。具体的には次のような課題が発生していました。
- 診療中に対応できない：診療が立て込む時間帯にメールが届くと、対応が数時間後になり機会損失が発生する
- 休診日に返信できない：日曜・祝日に届いたメールは翌診療日まで放置され、その間に患者さんが他院へ流れる
- 夜間対応ができない：診療後の時間帯に届いた問い合わせも同様に翌朝対応になる
- 受付担当者が他業務と兼務しているため返信が遅れる：電話応対や会計業務を優先すると、メール確認が後回しになる
- 確認作業が煩雑：DESKとトリビューの2つのシステムを行き来する作業は、慣れていても見落としが発生しやすい
- スタッフのストレス：「急がなければ」というプレッシャーが常にかかり続け、診療補助業務への集中を妨げる
特に最後の点は、経営視点で見過ごせないものでした。受付スタッフが予約メール対応に常時神経を使っている状態は、本来注力すべき来院患者さんへのホスピタリティや診療補助業務の質を下げます。つまり「対応速度向上」と「診療に集中できる環境作り」は、同一のスタッフが両方の業務にあたる限り、実現不可能な課題であったといえます。
なぜ予約管理システムを変えなかったのか
この課題の解決策として最初に浮かぶのは「トリビュー連携済みの予約管理システムに乗り換える」という選択肢です。トリビューが即時予約に対応している電子カルテを活用することで、予約の自動化は可能です。（というかこれが正攻法です）
しかしこのクリニックのケースでは、次のような障壁があり、電子カルテの乗り換えは困難でした。
- 現場オペレーションを根本から変えることになり、スタッフ再教育のコストが発生する
- 既存の患者データ・予約履歴の移行に手間と時間がかかる
- 過渡期に予約管理が混乱する可能性がある
- DESKの強みである歯科クリニックに最適化された運用フロー（歯科特有の診療メニュー管理、担当医ごとの得意領域設定等）をゼロから作り直す必要がある
歯科、特に矯正歯科や審美歯科に特化した予約管理システムを使っているクリニックは、同じジレンマを抱えているはずです。汎用的な予約システムに乗り換えれば連携は楽になりますが、診療領域特有の運用要件を満たせなくなる可能性があります。
そこで第三の選択肢として選んだのが、「DESKとトリビューの両方をそのまま使いながら、その間を自動でつなぐ仕組みを自前で作る」というアプローチでした。これを実現したのが Claude Code です。
Claude Code とは
Claude Code は、AnthropicのAIであるClaudeをコマンドライン上で動作させるツールです。簡単に言えば「日本語で指示すると、それに応じたプログラムを書いて実行してくれるAIエージェント」です。
Claude Codeは、ChatGPTやGeminiのようにウェブ上で会話ができるだけでなく、ブラウザ上でログイン操作をしたり、予約枠をブロックしたりと、人間のように予約ツールのサイトの操作ができることが大きな特徴です。
上記のような特徴から、Claude Codeを使用すれば、非エンジニアであってもある程度自動化されたシステムを構築することができます。
しかしその一方で、Claude Code は見かけほど完璧ではありません。
コードの品質・セキュリティ・既存システムとの整合性確認は、人間が責任を持つ必要があり、システムの検証・バグチェックなどには、エンジニアのようなITシステムへの理解を持つ人材が必要になる点にご注意いただきたいと思います。
設計思想：完全自動化ではなく「半自動化」を選んだ理由
ここから、実際に活用しているシステムの概要を解説していきます。
結論から書くと、今回構築したシステムは完全な全自動ではありません。最終的な予約確定の判断は、Slack上で担当者が「Yes」または「No」のボタンを押すことで行う設計になっています。
完全自動化にしなかった理由は3つあります。
誤予約リスクへの対応：ダブルブッキングがないかどうかや、使用予定のユニットが埋まっていないかなど、最終的な確認は人間が行えるような設計で誤予約を防ぐ必要があります。
特殊要望の拾い上げ：「希望日時の中でできるだけ遅い時間に予約を入れて欲しい」「矯正相談と同時にホワイトニング相談もしたい」など、患者さんの詳細な文脈情報は、機械的な照合では判断しきれないケースがあります。
キャンセル・変更コストの回避：もし誤動作でダブルブッキングをしてしまった場合、一度確定した予約を取り消すのは、患者さんとのコミュニケーションコストが発生します。最終確認に人間が一瞬関与するだけで、このリスクは大幅に下げられます。
これらを踏まえ、「機械ができる作業を全部機械にやらせて、人間の判断が必要な部分だけを残す」という方針を採りました。結果として、担当者の作業時間は「Slackの通知を見てボタンを押す」だけの約10秒にまで短縮されています。
システム全体の流れ
構築したシステムの動作を順を追って説明します。
① メール受信の常時監視
専用のGmailアカウントがトリビューからのメールを受信し続けており、システムは5分ごとにこの受信箱を確認しています。新着メールを検知するとパース処理に入ります。
② メール本文の自動解析
メール本文から以下の情報を自動抽出します。
- 患者さんの氏名
- 希望メニュー（例：矯正相談、ホワイトニング、審美歯科のご相談など）
- 希望日時の候補（第一〜第三希望）
- トリビュー管理画面のURL
- 予約ID
③ トリビュー側の状態確認
メール受信から実際の処理までに時差が発生することがあるため、トリビュー側で既に予約が確定済み、あるいはキャンセル済みになっていないかを確認します。既に処理済みであればそこでスキップします。
④ DESKの空き枠確認
患者さんの希望メニューから担当医を特定し予約状況を確認します。
⑤ 希望日時と空き枠の照合
第一希望から順に、空き枠と照合していきます。希望時間の前後30分程度の揺らぎも許容する設計にしており、完全一致でなくても「この時間帯なら対応可能」と提案できるようにしてあります。
⑥ Slackへの通知とボタン待機
照合結果をSlackに投稿します。メッセージには患者情報、希望日時、提案できる枠、担当医の情報が整理されて表示され、「Yes（この枠で確定する）」「No（スキップする）」の2つのボタンが付きます。
⑦ 担当者の承認後、自動確定
担当者がYesを押すと、システムは次の3つの処理を並行して実行します。
- トリビュー管理画面を自動操作し、患者さんに日程を返信
- DESKに予約ブロックを作成
- Slackの同じスレッドに完了報告を投稿
担当者がNoを押した場合、あるいは30分以内に応答がなかった場合は、そのまま処理を中止し手動対応に回します。
Claude Code を使った開発プロセスの実際
ここからは、実際にどのように開発を進めたかを共有します。同じアプローチを自院で試したい方の参考になれば幸いです。
1日目午前：画面構造の調査と仕様書化
最初に行ったのは、DESKとトリビューの画面構造を Claude Code に理解させる作業です。各システムのログイン画面、カレンダー画面、予約登録画面のスクリーンショットと、開発者ツールで取得したHTML構造を Claude に共有しました。
ここで重要だったのは、いきなりコードを書かせず、まず仕様書を作ってもらったことです。対話しながら「どの画面のどの要素をクリックするか」「どういうルールで空き枠を判定するか」「エラー時にどう振る舞うか」を一つずつ確認していきました。この過程で経営視点の要望（誤予約リスクの排除、スタッフが診療に集中できる設計）をシステム設計に反映できました。
1日目午後：読み取り機能の実装
設計が固まった段階でコード生成に入ります。最初に作ったのは「読み取り専用」の機能、つまりDESKのカレンダーから空き枠を取得する部分だけです。
書き込み処理は後回しにしました。読み取りは何度実行しても本番環境に影響を与えないため、安心して試行錯誤できるからです。
2日目午前：メール解析と照合ロジック
次に、トリビューから届くメールの解析機能を実装。抽出した情報とDESKの空き枠データを照合するロジックもここで組み立てました。
2日目午後：Slack連携と書き込み機能
最後に、Slack への通知、担当者のボタン応答の受け取り、承認後の予約確定処理（トリビュー側とDESK側の両方への書き込み）を実装しました。この段階で全機能が繋がり、実際のメールを使ったテスト運用に入れる状態になりました。
詰まった箇所と、Claude Code にどう相談したか
開発中に詰まった場面をいくつか紹介します。
詰まりポイント①：フォームの値がDESKに反映されない
DESKの予約登録フォームに自動で値を入れても、なぜか送信時に空の状態で送られてしまう現象が起きました。Claude に「こういう挙動をする」と状況を伝えたところ、画面で使われているUIライブラリの仕様が原因だと特定され、対応方法も即座に提示されました。
詰まりポイント②：トリビュー予約ステータスの誤判定
トリビュー側の予約ステータスを判定するコードで、全件「キャンセル済み」と誤判定される不具合がありました。原因はページ内のメニュー文字列を拾ってしまっていたことで、これも Claude と対話しながら「ページに埋め込まれたデータを直接参照する方式」に修正できました。
詰まりポイント③：時刻表記の揺れ
サービス間で、時刻が「09:30」「9:30」のように表記揺れがあり、単純な文字列比較では一致しないケースがありました。Claude に状況を伝えると、両形式に対応する変換ロジックが即座に提案されました。
これらのトラブルシューティングは、人間が1人で進めていたら数時間かかる可能性があるものです。Claude Code との対話によって、どの詰まりも30分以内に解消できました。
動かしてみて感じた効果と運用コスト
システムは院内のPCに常駐させており、追加のサーバー契約は不要した。PC起動時に自動的に立ち上がり、クラッシュしても自動で再起動する設計です。運用にかかる月額コストは、実質的にGmailとSlackの利用料のみのため、両方とも既に導入済みの本院では、追加料金はかかりませんでした。（厳密には、PCを動かし続けるために毎月数百円ほど電気代が上がった可能性はあります）
効果として、以下の変化がありました。
- 対応時間：メール受信から予約確定まで、従来は平均15〜30分 → 現在は数分以内
- 対応率：短時間返信のルール達成率が大幅に改善
- スタッフ負担：一件あたりの実作業時間が5〜10分 → 10秒（Slackボタンを押すだけ）
- 夜間・休診日対応：担当者のスマートフォンにSlack通知が届けば外出先でも対応可能
- 診療業務への集中度向上：受付スタッフが「いつ予約メールが来るか」を常に気にしなくて済むようになり、来院患者さんへの対応品質が向上
特に最後の変化は、当初の目的だった「スタッフが診療業務に集中できる環境作り」に直結するものでした。予約受付という定常業務から解放されたことで、スタッフがカウンセリング準備や来院患者さんへの丁寧な応対により多くの時間を割けるようになっています。
他院への応用可能性と、事前に検討すべきこと
同じアプローチは、次のような条件が揃っているクリニックで応用可能です。
- トリビュー、カンナムオンニ、ホットペッパービューティー、キレイパスなどの集患プラットフォームを活用している
- 上記のサイトと連携していない予約管理システムを使っている
- 夜間・休診日の予約問い合わせを取り逃している自覚がある
- 受付スタッフに診療業務へもっと集中してほしいと考えている
一方で、既に公式連携済みの予約管理システムを使っているクリニックは公式機能の活用が最適ですし、予約問い合わせの件数が少なく手動対応で十分間に合っているクリニックは投資回収が難しいでしょう。また、院内に継続的な保守を担える人材・パートナーがいない場合も別のアプローチを検討すべきです。
Claude Code を使えば初期開発は短期間で済みますが、長期的にはシステムの監視や微修正が必要です。インシデントを報告し合い、運用を継続的に改善していく体制が必要なため、集患担当者や院長だけでなく、現場が一体になって連携していくことが大切です。
今後の展開
現状のシステムには、改善余地がいくつかあります。
キャンセル・変更への対応：既存予約の日程変更やキャンセル処理も、同じアーキテクチャで実装できます。
他プラットフォームへの展開：今回はトリビュー対応のみですが、カンナムオンニ、ホットペッパービューティー、キレイパスなど他の集患プラットフォームにも同じ仕組みを横展開できる構造になっています。
まとめ
トリビューをはじめとする集患プラットフォームとDESKのような予約管理システムの間にシステム連携がないことは、多くのクリニックにとって見過ごせない運用負担でした。しかし Claude Code のようなAIエージェントを活用すれば、API連携を待たずに、自前で、短期間で、低コストで解決できる時代になっています。
今回の取り組みで重要だったポイントをまとめると、次の3つです。
第一に、完全自動化を目指さず、人間の最終確認を残す「半自動化」の設計にしたこと。誤予約リスクを抑えつつ、担当者の作業時間を劇的に短縮できました。
第二に、Claude Code を使うことで、設計から実装までを非エンジニアが主体的にリードできたこと。従来のように「エンジニアに要件を伝えて待つ」のではなく、対話しながら作り上げるプロセスが、現場ニーズへのフィットを高めました。
第三に、単なる業務効率化ではなく「スタッフが診療業務に集中できる環境作り」を最上位の目的に置いたこと。定常業務の自動化によって生まれた時間的・精神的余裕が、来院患者さんへの対応品質向上という形で還元されています。
矯正歯科、審美歯科、ホワイトニング、インビザラインやキレイライン矯正などの自由診療領域における集患チャネルの多様化は、今後さらに加速します。その運用に人的リソースを吸い取られるのか、仕組み化によって診療に集中できる体制を作るのか。この選択がクリニック経営の競争力を左右する時代になっています。
同じ課題を抱える院長・経営者の方々にとって、この記事が解決の糸口になれば幸いです。
太田 旭
株式会社eggside 代表取締役。医学生。
自由診療のための医師向けメディア「doctorside」を運営したり、クリニック集患支援を行っている。