1. HOME
  2. ブログ
  3. 開発ユースケース紹介
  4. AIトリアージで実現する遠隔医療予約システム導入事例
BLOG

ブログ

開発ユースケース紹介

AIトリアージで実現する遠隔医療予約システム導入事例

プロジェクト背景と課題認識

医療法人スマイルクリニックを運営する鈴木院長は、コロナ禍以降増加したオンライン診療の問い合わせに対応するため、予約システムのDX化を決断しました。従来は電話とメールでの受付が中心で、スタッフが手動でスケジュールを調整していたため、誤予約や二重登録が頻発し、月あたり約200件、年間で約¥1,200,000相当の運用コストが発生していました。また、緊急度に応じた予約優先度がつけられず、重症者が長時間待たされるケースも散見されていました。鈴木院長は、こうした運用課題を解決する「システム」を求め、AIトリアージ機能を組み込んだ遠隔医療予約プラットフォームの構築を構想。オンライン診療と対面診療を統合した予約管理、患者心理を考慮した問診フロー、自動スケジュール調整による負荷分散など、一連の機能要件を整理しました。

想定読者である事業責任者やマネージャーに向け、この導入事例では、開発会社の選び方、予算策定、発注から納品までの流れを時系列で詳細に追い、同じ課題を抱える読者が自社プロジェクトの計画に活かせるよう、具体的なノウハウと教訓をお伝えします。

開発会社選定と予算モデル

鈴木院長は要件定義を踏まえ、AIチャットボット実績と医療系システム開発力を両立する開発会社を選ぶため、以下のポイントでRFPを発行しました。

  • AIトリアージ経験:自然言語処理による問診自動分類の実績

  • 医療系システム認証:HIPAA(米国)やPマーク(日本)取得状況

  • UI/UXデザイン力:高齢者でも使いやすい問診画面設計

  • インフラ構築:AWS/GCP上のセキュアなFargate運用経験

  • 保守サポート:24時間365日対応とSLA水準

A社はAI基盤に強みがありましたが、医療Pマーク未取得でセキュリティ面の不安があったため候補外に。B社は医療系システム認証を取得し、対面診療予約システムの納入実績も豊富でしたが、AI部分はパートナー企業依存で見積もり相場が¥18,000,000~となり「予算」を超過する見込み。C社は自社開発のNLPエンジンを医療用途にカスタマイズした実績があり、総額¥12,500,000と相場より抑えられる提案でした。最終的にC社を発注先に決定し、PoCフェーズ(¥2,000,000)、本開発フェーズ(¥9,000,000)、保守フェーズ(月額¥200,000)を含む年間TCOを¥12,900,000と試算しました。

PoC(概念実証)フェーズの進め方

発注後、まずはPoCとして以下のスコープでプロトタイプを3カ月で開発しました。

  1. AIトリアージ問診ボット:チャット形式のテキストQ&Aで症状を分類し、緊急度を3段階で判定

  2. 予約候補自動表示:緊急度に応じた優先枠をAPIで生成し、患者に候補を提示

  3. ダッシュボード:医師・スタッフ向けに当日の予約状況を可視化

  4. 認証・決済連携:マイナンバーカード認証とクレジット決済APIを組み込み

要件定義では問診パターンを50種類以上策定し、医師監修のもと意図しない診断バイアスを防ぐチェックリストを作成しました。この段階で、AIの学習データ不足から鋭敏度が70%に留まり、誤判定率が高いことが判明。追加で医療用実データを500件提供し、再学習を実施。工数約80時間、¥600,000の追加費用がかかりましたが、精度は85%まで改善し、患者と医師双方から好評を得られました。

さらに、システム連携部分では、レガシーな電子カルテシステム(HL7 v2)とのインターフェース実装に思いのほか時間がかかり、追加工数120時間、¥900,000のコストが発生しました。この教訓から、PoC段階でレガシー連携要件を十分に洗い出す重要性を認識し、以降の要件定義書に「外部システム連携詳細」を必須項目として追加しました。

本開発フェーズのアーキテクチャ

PoC完了後、本開発では以下のアーキテクチャを採用し、信頼性とスケーラビリティを担保しました。

  • フロントエンド:React+TypeScriptで問診/予約UIを実装

  • バックエンド:Kotlin+Spring Bootで医療APIを提供

  • AI基盤:Python+FastAPIでNLPモデルをコンテナ化し、GCP Cloud Runでホスティング

  • DB:Cloud SQL(PostgreSQL)で予約情報・問診履歴を管理

  • 認証:OAuth2+OIDCでマイナポータル認証と連携

  • 決済:Stripe APIで事前決済を実装

  • メッセージング:Pub/Sub+Cloud Functionsでリマインダー通知

  • ログ監視:Stackdriver+Cloud Monitoringでリアルタイムアラート

マイクロサービス化によるCI/CDパイプラインはCloud BuildとCloud Deployで自動化し、リリースサイクルを週1回から週2回に短縮。運用チームと共同で運用手順書を整備し、リリース失敗率を5%→1%に改善しました。

テスト戦略と品質保証

本開発フェーズでは、品質を担保しつつ迅速にリリースするため、テスト戦略を多層的に設計しました。まずユニットテストでは、問診ロジックや予約スケジューラ部分をKotestで100%カバレッジ近くまで網羅。AIトリアージAPIはPythonのpytestでモデル応答をモック化し、誤判定リスクを低減しました。次に統合テストでは、Cloud Build上でPostman/Newmanを用いてエンドツーエンドの問診→予約→決済フローを自動実行し、API依存関係の変化を検出します。
さらに、Contract Test(Pact)を導入し、フロントエンドとバックエンド間の契約をコードで管理。これにより、UIチームとバックエンドチームの連携時に発生しがちな仕様齟齬を未然に防止しました。パフォーマンステストはk6を利用し、ピークトラフィック1,000同時ユーザーを想定したシナリオでリクエストレイテンシを計測。目標の平均200ms以内をクリアしたことで、本番環境移行の目処を立てました。テスト全体の工数は約150時間、追加「費用」は¥1,050,000でしたが、開発「予算」に対して10%程度の余裕を持たせていたため、大きな影響はありませんでした。

本番展開とリスク管理

本番リリースはフェーズ分割で実施。まず非クリティカルな時間帯(深夜帯)にパイロットリリースを行い、電話受付との併用運用で安定性を確認しました。リリース手順はTerraformで管理するインフラ変更とアプリ新版デプロイをCI/CDパイプラインに組み込み、ボタン一つでローリングアップデートができる仕組みを構築。万一の障害時には、旧版へ5分以内にロールバックできる自動化スクリプトも用意しました。
リスク管理として、DNS TTLを短く設定し、Cloud Runの同時実行数を段階的に引き上げるカナリア方式を採用。実際に初日に特定問診でのデータベース接続エラーが発生しましたが、アラートから10分で原因特定、設定修正、再リリースが完了し、ダウンタイムゼロで運用を継続できました。このスムーズな対応により、スタッフからは「開発会社の保守対応力が高い」と評価され、信頼感を醸成しました。

運用保守体制とKPI設定

リリース後は運用保守体制を整備し、「システム」稼働率99.5%維持をKPIに設定。PagerDutyとSlack連携による24時間オンコール体制で初動対応を1時間以内にコミットし、事後レビューによるインシデントレポートを毎月発行しています。モニタリングにはCloud MonitoringとGrafanaを併用し、以下の指標を常時計測しています。

  • APIエラー率(目標0.5%以下)

  • レイテンシ(95パーセンタイル250ms以下)

  • AI判定精度(継続学習で90%以上維持)

  • 予約完了率(UI離脱防止の改善後95%以上)
    月次のレポートを経営層とシェアし、「費用」対効果を可視化。問題兆候があれば優先度を再評価し、保守予算の最適化を図っています。

効果測定とROI分析

導入から6ヵ月後に行った効果測定では、以下の成果を確認しました。

  • 電話受付件数削減:月200件→月30件(85%削減)、年間約¥1,020,000相当の工数節減

  • 問診誤判定率改善:15%→5%(事前調整学習で80%改善)

  • 予約完了率向上:70%→95%(UI改善と自動スケジュール調整で実現)

  • スタッフ対応工数短縮:月160時間→40時間(75%削減)

初期開発費¥12,500,000+保守費用年間¥2,400,000に対し、年間効果は約¥1,020,000+工数換算¥2,400,000=¥3,420,000。ROIは(3,420,000−2,400,000)÷12,500,000×100≒8.16%。早期に黒字転換を果たし、2年目以降の運用コスト最適化効果はさらに大きくなる見込みです。

今後の展望と教訓

今後は以下の拡張を計画しています。

  • 多言語対応:英語・中国語のAIトリアージを追加し、訪日外国人の予約需要に対応

  • チャットボット連携:LINEやWhatsApp連携で患者接点を拡大

  • データ分析基盤:BigQueryを活用し、問診データを分析、診療トレンド可視化

  • IoT連携:ウェアラブルデバイスからのバイタルデータをリアルタイム問診に統合

最大の教訓は、PoC段階でのレガシーシステム連携要件とAI学習データ要件を徹底的に精緻化しないと、「費用」・「相場」を超える追加コストが発生する点です。開発会社の選び方では、技術検証力と運用ノウハウを重視し、発注前に十分なPoC期間を確保することをおすすめします。

まずは

で御社の開発費用感を把握し、自社の遠隔医療システム構築にお役立てください。

お問合せ

不明点やお見積りの依頼などお気軽にください。




問い合わせを行う

関連記事