問診システム開発のPoC・プロトタイプ・モックアップ開発について

問診システムは、電子カルテ・レセプト・院内物流までを横断的に統合する病院全体の総合基幹システムとは異なり、患者が受診の前後にスマートフォンやタブレットで症状・既往歴・服薬状況などを入力し、そのデータを電子カルテやレセコンへ自動連携する「受診前後の問診票入力とトリアージ」に特化したシステムです。紙の問診票をそのままデジタル化しただけのWeb問診であれば比較的シンプルに実装できますが、入力内容からAIが質問を自動分岐させ緊急度まで判定するAI問診になると、いきなり本開発に着手するのはリスクが高く、モックアップ・プロトタイプ・PoC（概念実証）という段階的な検証を経ることが欠かせません。医療機関の情報システム担当者からは「問診システムのPoCはどれくらいの期間・費用でできるのか」「何を検証すればAI問診の導入判断ができるのか」といった相談が数多く寄せられます。特に、いきなり多額の予算を投じて本開発に着手し、稼働後に「思っていたものと違う」「現場で全く使われない」という結果に終わってしまうケースは、問診システムに限らず医療系システム開発全般で後を絶ちません。段階的な検証工程を挟むことは、遠回りに見えて実は最短で成功にたどり着くための近道です。

本記事では、問診システム開発におけるモックアップ・プロトタイプ・PoCの違いと位置づけ、それぞれの期間・費用目安、既存の電子カルテ・レセコンとの連携技術検証、総合病院・クリニック・オンライン診療といった導入現場ごとに異なる検証ポイント、そしてAI問診・トリアージ機能特有のSaMD（プログラム医療機器）該当性の見極めと陥りやすい失敗パターン・対策までを具体的な数値とともに解説します。問診システムは、いきなり本格開発に踏み切ると「思っていたものと違う」「現場で使われない」という失敗に陥りやすい領域です。段階的な検証をどう組み立てるかが、プロジェクト成功の分かれ目になります。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・問診システム開発の完全ガイド

問診システムにおけるモックアップ・プロトタイプ・PoCの違い

問診システムの開発では、モックアップ・プロトタイプ・PoCという三つの検証手法を目的に応じて使い分けることが重要です。モックアップは画面イメージや操作フローの見た目を確認するための静的な視覚検証で、動作はしません。プロトタイプは限定的な機能を実際に操作できる試作品で、患者や医療スタッフに触ってもらいながら操作感・UXを検証します。PoCは、既存の電子カルテとの連携や、AIによるトリアージ判定ロジックの実現可能性そのものを検証する、技術・概念の実証工程です。単純なWeb問診であればモックアップとプロトタイプの検証で十分なケースも多い一方、AI問診・トリアージ機能を導入する場合は、技術的な実現性と規制対応の両面でPoCによる事前検証が不可欠になります。三つの手法はいずれも「本開発に入る前にリスクを小さく安く発見する」という共通の目的を持ちますが、投じる予算と検証の深さが段階的に大きくなっていく点を理解しておくと、自院のプロジェクト規模に見合った検証計画を立てやすくなります。

いきなり本開発に着手してしまうと、想定より開発期間・費用がふくらんだり、現場で使われないシステムが出来上がったりするリスクが高まります。まずは自院が開発したい問診システムがWeb問診・AI問診のどちらに近いのか、そしてどこまで検証工程に投資すべきかを見極めることが、プロジェクト全体の成功確率を高める第一歩です。

PoCの設計を考えるうえでも、問診システムがどの範囲を担うシステムなのかを明確にしておく必要があります。予約受付から診察・会計・院内の医薬品や診療材料の物流管理までを横断的に統合する総合基幹業務システムは、病院運営全体を裏側で支える巨大なインフラ基盤であり、そのPoCは複数部署・複数システムを横断した大掛かりな検証になります。これに対して本記事で扱う問診システムは、患者と医療機関の最初の接点における情報収集やトリアージに特化した「フロントエンド・アプリケーション」であり、PoCで検証すべき範囲もあくまで「問診データの入力・分岐・連携」というスコープに絞られます。この違いを踏まえてPoCの検証範囲を過不足なく設計することが、検証コストと期間を適切にコントロールする前提になります。

問診システムでPoCが特に重要視される理由は大きく二つあります。第一に、電子カルテ・レセコンはメーカーごとに仕様が異なり、実際に連携してみないと技術的な実現可能性が分からないという不確実性があるためです。第二に、AIによる自動分岐・トリアージ判定機能を持たせる場合、それが薬機法上のプログラム医療機器（SaMD）に該当するかどうかという規制上の論点が、開発の初期段階で解消しておくべき重大なリスクだからです。この二つの不確実性を、本開発に多額の投資をする前にPoCで解消しておくことで、「作ったものの使えない」「作ったものの医療機器該当が発覚し頓挫する」という最悪の事態を避けられます。特にAI問診・トリアージ機能を検討している医療機関ほど、PoCへの投資を惜しまないことが結果的にプロジェクト全体のコストとリスクを下げることにつながります。逆に、単純なWeb問診の入力・表示機能のみであれば、これらのリスクは相対的に小さいため、モックアップとプロトタイプによる視覚的合意形成と操作感の確認だけで本開発に進めるケースも多く、すべての問診システム開発に一律で重厚なPoCが必要というわけではない点にも留意が必要です。

期間・費用目安と検証すべき技術ポイント

モックアップ・プロトタイプ・PoCは、それぞれ検証する目的が異なるため、かかる期間・費用の目安も段階的に変わります。ここでは各手法の目安と、問診システム特有の技術検証ポイントを整理します。

モックアップは、画面イメージや問診票の設問フローを視覚的に確認するだけの工程で、期間は1〜2週間程度、費用は30万〜40万円程度が目安です。動作はしませんが、発注側と開発側の間で「どのような画面・分岐で問診を進めるか」を視覚的に合意形成できる、最も低コストな検証手段です。プロトタイプは、限定的な機能を実際に操作できる試作品で、期間は1〜3週間程度、費用は70万〜90万円程度が目安です。患者役・医療スタッフ役に実際に触ってもらい、入力のしやすさや問診結果の確認しやすさといった操作感・UXを検証します。PoCは、電子カルテとの連携やAIによる分岐・トリアージロジックの技術的な実現可能性を検証する工程で、期間は数日〜2週間、長くとも3ヶ月以内に収めるのが基本です。費用は検証範囲によって幅があり、小規模な検証で50万〜100万円程度、中規模な検証で100万〜300万円程度、AI問診トリアージまで含む大規模な検証では300万円以上になることもあります。コア機能に絞ったMVP（実用最小限の製品）としてPoCを実施する場合は、初期投資100万〜300万円程度でコア機能に絞った現場検証を行うのが現実的な進め方です。

問診システムのPoCで最も重要な技術検証の一つが、既存の電子カルテ・レセコンとの連携です。電子カルテはメーカーごとに仕様が異なり、標準規格であるHL7 FHIRやSS-MIX2に対応しているかどうかで連携の難易度が大きく変わります。PoCの段階で、問診データが正しく自動連携されるか、データ同期のタイムラグが実運用上許容できる範囲に収まっているかを実機に近い環境で検証しておくことで、本開発フェーズでの手戻りを大幅に減らせます。この連携検証には別途100万〜300万円程度の追加費用が発生するケースもありますが、本開発に入ってから「連携できない」と判明するリスクを考えれば、PoC段階での投資は十分に見合う費用と言えます。あわせて、連携先の電子カルテがHL7 FHIRやSS-MIX2といった標準規格に対応しているか、それともメーカー独自仕様なのかをPoCの初期段階で確認しておくと、その後の本開発における連携実装の工数とスケジュールの見通しを立てやすくなります。標準規格に対応していない場合は、個別のAPI仕様書を電子カルテベンダーから取り寄せ、想定しているデータ項目がすべて取得・書き込み可能かを一つずつ突き合わせる作業が必要になります。

現場受容性の検証──導入現場ごとの検証ポイント

問診システムのプロトタイプ・PoCでは、技術的な実現可能性だけでなく、実際に導入する現場でスムーズに使われるかという「現場受容性」の検証も欠かせません。導入現場によって検証すべきポイントが異なるため、それぞれの特性に応じたテスト設計が必要です。

総合病院の外来受付・救急トリアージにおけるプロトタイプ検証では、複数科にまたがる複雑な問診分岐が現場の実際のフローに即しているか、緊急度の高い患者を見落とさずにトリアージできているかを重点的に確認します。特に、待合室に設置する多数のタブレット端末を医療スタッフが一元管理できるか、通常操作だけでなく入力ミス時のエラー表示や複数アカウントの同時ログインといったイレギュラーな状況でも問題なく動作するかを、実際の医師・看護師・受付事務スタッフに操作してもらいながら検証することが重要です。多忙な現場では、操作に手間取ること自体が受容性を大きく下げる要因になるため、実運用に近い負荷状況を想定したテストが欠かせません。また、救急外来では患者本人が問診に答えられない状態で搬送されるケースも想定されるため、家族・救急隊からの代理入力や、既存の救急トリアージ基準（緊急度判定支援システム等）との整合性をどう担保するかも、プロトタイプ段階で医師・看護師と丁寧にすり合わせておくべき論点です。

クリニックの受診前問診では、高齢者から若年層まで幅広い年代の患者が、自宅のスマートフォンから迷わず入力できるかというシンプルさが検証の中心になります。ITリテラシーが高くない患者を想定したユーザーテストを行い、入力完了までにかかる時間や、途中で離脱してしまう設問がないかを確認することが重要です。オンライン診療の事前問診では、単独の問診機能だけでなく、Web予約・ビデオ通話・決済といった一連のペイシェントジャーニー全体とシームレスに連携できているかをプロトタイプ段階で検証する必要があります。特に、問診の回答内容によってオンライン診療に適さない症状（対面受診が必要な症状）を適切に振り分けられるかどうかは、患者の安全に直結する重要な検証項目であり、PoC段階で判定ロジックの精度を十分に確認しておく必要があります。クリニックの受診前問診・オンライン診療事前問診のいずれも、事務スタッフの入力・転記作業をゼロにすることが導入効果の大きな柱となるため、プロトタイプ検証の段階から「入力された問診情報がどのタイミングで電子カルテ・レセコンに反映されるか」を実際の受付フローに沿って確認しておくことも忘れてはなりません。

SaMD該当性の見極めと陥りやすい失敗パターン

AI問診・トリアージ機能を持つ問診システムのPoCでは、技術検証・現場受容性検証に加えて、薬機法上のプログラム医療機器（SaMD）該当性の見極めが最重要の検証項目になります。ここでは、その見極め方と、問診システムのPoCで陥りやすい失敗パターン・対策を整理します。

入力情報をもとに疾病候補や疾病リスクを提示したり、重症化確率にもとづいて患者を層別化したりするプログラムは、薬機法上のプログラム医療機器（SaMD）に該当する可能性が高くなります。特にトリアージ・緊急度判定機能は、不具合が生じた場合に患者の生命や健康に影響を与えるリスクがあるとみなされやすく、医療機器としての規制対象となる可能性が高い領域です。PoCの段階では、検討している機能が「単なる情報の記録・連絡」にとどまるのか、それとも「疾病候補の提示・重症化確率の評価」まで踏み込むのかを、薬機法専門の弁護士やPMDAの「医療機器該当性に関する相談」窓口へ相談し、機能要件を確定する前に法的な境界線を明確にしておくことが不可欠です。この見極めを怠ると、開発が相当程度進んだ段階でSaMD該当が発覚し、数百万〜数千万円規模の薬事申請費用と数ヶ月〜年単位の審査期間が新たに必要になるという最悪の事態を招きます。なお、単なる記録・連絡・予約の機能は非該当となることが多く、該当・非該当の境界線は「AIが医学的な判断や評価を行っているかどうか」にあります。PoCの企画段階でMoSCoW法などを用いてMust（必須）機能を極限まで絞り込み、トリアージ判定はあくまで参考情報の提示にとどめ最終判断は医療従事者が行うという設計にすることで、SaMD該当のリスクを抑えながら段階的に機能を拡張していくアプローチも有効です。

問診システムのPoC・プロトタイプ開発で陥りやすい失敗は大きく三つあります。第一に、要件定義段階でAIによる高度な診断推論やトリアージ機能を安易に盛り込もうとし、後からSaMD該当が発覚してプロジェクトが頓挫するパターンです。対策は前述の通り、企画の初期段階でSaMD該当性を確認し、まずは非該当のシンプルなデジタル化からスモールスタートすることです。第二に、電子カルテ・レセコンとの連携仕様の確認を後回しにし、PoCを実施しないまま本開発に着手した結果、「使用しているカルテのメーカーがAPI連携を開放していない」ことが開発中盤で発覚するパターンです。対策は、要件定義・設計の段階で連携先の仕様書を入手し、技術的に可能かどうかを検証するPoCを必ず先行して実施することです。第三に、患者目線の操作性ばかりを重視し、医療従事者側が問診結果を確認する管理画面の使いやすさを検証しないまま本開発に進んでしまい、リリース後に「現場の業務効率がかえって落ちる」という問題が発覚するパターンです。対策は、プロトタイプの段階で、想定患者だけでなく実際の医療スタッフにも操作してもらう現場受容性のテストを必ず実施し、そのフィードバックを設計に反映させることです。また、PoCの結果を「導入決定」と誤認してしまうことも典型的な失敗の一つで、PoCはあくまで技術的・概念的な実現可能性を確認する工程であり、本番導入の可否は、その後のプロトタイプ検証や限定運用での定量的な成功基準の達成状況を踏まえて、段階を踏んで判断することが重要です。加えて、IT部門・開発会社だけでPoCを進め、実際に問診票を使う受付スタッフや医師・看護師を巻き込まないまま検証を終えてしまうと、本番導入後に現場から反発を受け、システムが定着しないという事態にもつながりかねません。PoCの初日から現場の当事者を巻き込み、「自分たちの意見が反映されている」という当事者意識を持ってもらうことが、最終的な現場定着率を高める重要な鍵になります。

まとめ

本記事では、受診前後の問診票入力とトリアージに特化した問診システムにおけるモックアップ・プロトタイプ・PoCの違いと位置づけ、それぞれの期間・費用目安、既存の電子カルテ・レセコンとの連携技術検証、導入現場ごとの現場受容性の検証ポイント、そしてAI問診・トリアージ機能特有のSaMD該当性の見極めと陥りやすい失敗パターン・対策までを解説しました。期間・費用の目安は、モックアップが1〜2週間・30万〜40万円程度、プロトタイプが1〜3週間・70万〜90万円程度、PoCが数日〜2週間（長くとも3ヶ月以内）・小規模50万〜100万円から大規模300万円以上と、検証の深さに応じて段階的に変わります。検証すべきポイントは、既存電子カルテ・レセコンとの連携技術、総合病院・クリニック・オンライン診療といった導入現場ごとの現場受容性、そしてAI問診・トリアージ機能のSaMD該当性の三つに集約され、陥りやすい失敗パターンはいずれも、これらの検証を省略して本開発に進んでしまうことに起因します。まずは自院が開発したい問診システムの機能範囲を整理したうえで、モックアップによる視覚的合意形成、プロトタイプによる現場受容性の確認、そしてPoCによる技術・規制両面のリスク解消という段階を踏んで、本開発への投資判断を行うことをお勧めします。特にAI問診・トリアージ機能の導入を検討している場合は、開発会社選びの段階で、電子カルテ連携の実績だけでなく、薬機法・SaMD該当性に関する知見や、専門家への相談支援まで含めて提案できるパートナーかどうかを確認しておくことが、後工程での手戻りを防ぐうえで大きな意味を持ちます。

▼全体ガイドの記事
・問診システム開発の完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。