オンライン診療の案件は、ビデオ通話の画面を作る仕事に見えます。ところが指針を開くと、画面の外側に細かな要件が並んでいます。誰の本人確認をどう行うか、記録はいつから残すか、更新は誰と相談して当てるか。設計に着手する前にこの並びを知っておくと、要件の抜けを早い段階で見つけられます。

1. オンライン診療の案件は何を作る仕事なのか

見えている仕事と、指針が引く境界線は別物

オンライン診療の案件は、通話を作るだけの仕事ではありません。むしろ、画面の外側にある要件をどう設計に落とすかが本題です。オンライン診療の案件に触れたことがない人ほど、映像を届ける通話機能さえ動けば要件は満たせると考えがちです。

実際に指針を読み進めると、画面の向こう側に本人確認や記録の要件が控えていることに気づきます。まず押さえたいのは、指針が「システムの種類」で役割の線を引いているという点です。

指針は、オンライン診療で使うことを想定して作られたシステムを「オンライン診療システム」と呼びます⁸。汎用サービスとは区別された、専用の設計を前提にした枠組みです。

一方で、オンライン診療に限らず広く使われているサービスは「汎用サービス」という扱いになります⁹。同じ通話機能でも、どちらの枠に立つかで、システム側が背負う設計項目の量が変わってきます。

境界線を知らずに設計を始めると、後から要件が積み上がる

通話がつながることをゴールにするよりも、専用システムか汎用サービスかを先に決めるほうが、途中の設計変更よりも手戻りが少なくなります。本人確認や記録の仕組みは、後から足そうとするとやり直しの範囲が大きくなりがちです。

案件に入る前にこの分類を確認しておくと、見積もりの段階で「どこまでを作るのか」がはっきりします。次の章では、この線引きが実装のどこに効いてくるのかを具体的に見ていきます。

認証・映像配信・記録基盤の設計に関わってきた経験があるなら、この分類の意味はすぐに飲み込めるはずです。オンライン診療ならではの専門知識よりも、これまで培ってきた設計の型を、指針の言葉に当てはめていく作業に近いと言えます。

参画が決まってから要件を洗い出すよりも、企画段階でこの前提を確認しておくほうが、クライアントとの認識のずれを防げます。どこまでを専用の設計として作り込み、どこから汎用の仕組みに委ねるかは、見積もりの根拠にもなる論点です。

2. 専用のシステムと汎用サービス——線引きで担う範囲が変わる

同じ通話機能でも、前提が違えば設計の範囲が変わる

専用システムと汎用サービス、どちらを選ぶかは机上の分類に見えて、実装の設計図を大きく左右します。オンライン診療システムは、オンライン診療での利用を前提に作られています⁸。その前提があるぶん、本人確認や記録の仕組みをあらかじめ組み込んだ設計になりやすい枠組みです。

汎用サービスは、オンライン診療に限らず広く使われている点が前提です⁹。通話機能そのものは強くても、本人確認や記録の仕組みは、周辺に別途組み合わせる必要が出てきます。

ここで意識したいのは、便利さよりもリスクへの向き合い方です。指針は、使用するシステムに伴うリスクを踏まえた対策を講じることを重視しています¹⁰。通話の使い勝手よりも、リスクに応じた対策が整っているかどうかが選定の軸になります。

比較表で役割の違いを整理する

専用システムと汎用サービスの違いを、位置づけと選定時に踏まえる点で並べると次のようになります。

比較項目	オンライン診療システム	汎用サービス
位置づけ	オンライン診療での使用を想定して作られたシステム8	オンライン診療に限らず広く用いられているサービス9
選定時に踏まえる点	想定した使い方の範囲で設計されている	使用に伴うリスクを踏まえた対策が必要10

図の作成：Remogu編集部。指針が示す位置づけの違いを整理したもので、統計データではありません

表と図を見比べると分かるとおり、汎用サービスを選ぶ案件では、通話以外の要件を別の仕組みで補う設計判断が必要になります。専用システムを選ぶ案件よりも、周辺との接続点が増えることを見込んで見積もる姿勢が求められます。

どちらの前提を選ぶにせよ、後から線引きを変えるのは負担の大きい設計判断です。要件定義の早い段階で、専用システムとして作るのか、汎用サービスの上に薄い層を足すのかを、発注側とすり合わせておく価値があります。

汎用サービスを選ぶか専用システムを選ぶかは、案件ごとの制約や優先したい観点によって変わります。どちらが優れているという話ではなく、指針が求める要件をどちらの土台で満たすかという選択です。

運用が始まった後も、専用システムか汎用サービスかという前提は変わりません。保守や機能追加のたびに、この前提に立ち返って設計判断をすることになります。

線引きを理解したところで、次は本人確認そのものに目を向けます。誰が、どちらの立場で確認されるのかを押さえておくと、認証まわりの設計がぶれません。

3. 本人確認は双方向に要る——患者側と医師側

患者側の確認

本人確認というと、患者側だけの手続きに思えるかもしれません。指針は、初めての診療では顔写真の付いた身分証明書による確認を原則としています³。オンラインだからこそ、対面よりも確認の手順を明確に設計しておく必要があります。

顔写真付きの証明書をどう提示してもらい、どう確認するかは、システム側の画面設計に直結します。確認の手順があいまいなままだと、後から要件を足すことになりかねません。

医師側の確認

確認が必要なのは患者側だけではありません。指針は、医師の側にもなりすましを防ぐための本人証明の方法を定めています⁴。患者からの視点よりも、医師からの視点のほうが見落とされやすい部分です。

医師のアカウントが本人のものであることを、どう継続的に担保するかは、認証設計の課題になります。片方向の確認だけを整えて安心するよりも、双方向で確認の設計をそろえるほうが、抜けの無い実装につながります。

患者側の確認と医師側の確認は、別々の手続きに見えて、同じシステムの中でどちらも欠かせない部品です。片方だけを厚くしても、もう片方が薄ければ、確認の仕組み全体としては弱いままになります。

患者側の確認は画面の入り口で完結させやすい一方、医師側の確認は運用の中で継続的に効かせる仕組みが必要になります。入り口の設計と、継続的な認証の設計は、同じ「本人確認」という言葉でも作り方が異なります。

確認した本人情報を、診療の記録とどう紐づけるかも設計対象です。確認の仕組みと記録の仕組みが別々に動いていると、後から突き合わせる作業に手間がかかります。

図の作成：Remogu編集部。指針が定める確認の関係を整理したもので、統計データではありません

本人確認が双方向で整ったら、次に問われるのが「1対1」であることの証明です。確認と証明は似ているようで、システムに求められる仕組みが異なります。

4. 1対1であることを証明する仕組み

同時に複数を診ることはできない

本人確認が済んでも、それだけでは1対1の診療は証明できません。指針は、情報通信機器を通じて同時に複数の患者の診療を行ってはならないとしています⁵。この前提は、セッション設計そのものに関わってきます。

同時進行のしやすさよりも、1つの通話セッションに1人の患者だけを紐づける設計のほうが、指針の前提に合います。複数の待機患者を同じ画面で切り替えるような作りは、この前提と相性がよくありません。

確認とログで裏付ける

指針は、医師と患者が1対1で診療を行っていることを確認する必要があるとしています⁶。確認の手段の一つとして位置づけられているのが、アクセスログです。

診療の開始時間と終了時間をアクセスログとして記録できるシステムが望ましいとしています⁷。ログは監査のためというより、1対1の診療であったことを裏付けるための記録という位置づけです。

同時実施の禁止・本人の確認・ログの記録という3つの要素を、指針の内容と実装への効き方で整理すると、次のようになります。

要素	指針の内容	実装への効き方
同時実施の禁止	情報通信機器を通じて同時に複数の患者を診てはならない5	1つのセッションに1人の患者を紐づける設計
本人の確認	医師と患者が1対1で診療を行っていることを確認する必要がある6	セッション開始時に確認の手順を組み込む
ログの記録	開始時間・終了時間をアクセスログとして記録するシステムが望ましい7	セッションの開始・終了をログに残す仕組み

図の作成：Remogu編集部。指針が示す3つの要素を整理したもので、統計データではありません

3つの要素は、どれか1つを満たせば良いという関係ではありません。禁止事項と確認とログが揃って、はじめて1対1の診療が成り立っていると言えます。

アクセスログをどこにどれだけの期間保持するかは、この記事の範囲を超える論点ですが、開始・終了時刻を記録する仕組みそのものは、通話機能を作る初期段階から組み込んでおきたい要件です。後から足そうとすると、通話基盤の設計をやり直すことになりかねません。

同時に複数の患者を扱えないという前提を、システムの制約としてどう可視化するかも設計の一部です。医師側の画面に、今どの患者と接続しているかが常に分かる表示があると、指針の前提を運用でも支えやすくなります。

5. 記録は診察の前から始まる

診療前の相談も記録の対象

記録は診療の後にまとめて整えるものではありません。むしろ、診療が始まる前から流れている情報の一部です。指針は、診療の前に行う相談で得た内容も、診療録に記載することを求めています¹。

システム側から見ると、診療セッションが始まる前のやり取りをどこにどう残すかも、設計対象に含まれるということです。診療中の記録だけを設計するよりも、前段階のやり取りまで見渡して設計するほうが、抜けの少ない仕組みになります。

医師の本人確認情報を患者がいつでも見られるように

記録とあわせて、指針が求めているのが情報公開の面です。患者がいつでも医師の本人確認ができる情報と、問い合わせ先をシステム上に掲載することを求めています¹³。

この要件は、記録の裏側にある「誰が診療を担当したか」を、患者側からも確認できる状態にしておくという発想です。管理画面の奥に置くよりも、患者が使う画面のどこかに、常時アクセスできる形で置いておく設計のほうが、この考え方に合います。

記録の起点を診療前まで広げ、確認できる情報を患者側にも開いておく。この2つを合わせて設計しておくと、後から画面や項目を足す必要が少なくなります。

問い合わせ先や医師の本人確認情報をどこに置くかは、細かい画面設計に見えて、指針が明示している要件です。トップ画面から辿りやすい場所に置いておくと、後から患者側の問い合わせ対応に追われることも減らせます。

問い合わせ対応とあわせて、記録の保存期間や、誰がその記録にアクセスできるかという権限設計も、実装段階で詰めていく項目になります。誰に何を見せるかを最初に決めておくと、画面ごとの表示範囲が整理しやすくなります。

記録は診療の後にまとめるものではなく、診療が始まる前から流れている情報の一部です。次の章では、この記録や通信を支える認証と更新の要件に話を進めます。

6. 認証と更新——実装に落ちる要件

更新は事業者との協議が前提

システムを作って終わりではなく、運用の中でOSやソフトウェアを更新していく場面が出てきます。指針は、こうした更新について、事業者と協議・確認した上で実施することを求めています¹¹。

現場の判断だけで更新を当ててしまうよりも、事業者との連絡体制を先に決めておくほうが、運用開始後のトラブルを減らせます。更新の頻度や手順を、設計段階で事業者側とすり合わせておく価値があります。

認証は多要素が望ましい

ログインの仕組みについても、指針は方向性を示しています。システムを使う際は、多要素認証を用いることが望ましいとしています¹²。パスワードだけに頼る認証よりも、もう1つの要素を組み合わせる設計のほうが、指針の考え方に沿います。

更新前に検証環境で動作を確かめる工程を、事業者との協議の中に組み込んでおくと、本番環境への反映もスムーズになります。多要素認証も、最初から選択肢に入れて設計しておくほうが、後から作り替えるより負担が小さくなります。

更新履歴をどう記録に残すかも、認証や記録の設計とあわせて考えておきたい点です。いつ、どの内容の更新を、誰の合意のもとで行ったかを追える状態にしておくと、責任の範囲を説明する場面でも役立ちます。

更新と認証、それぞれの要件と運用のポイントを整理すると、次のようになります。

要件	指針の内容	運用のポイント
更新の進め方	OSやソフトウェアの更新は事業者と協議・確認した上で実施する11	検証環境での確認と、事業者との連絡体制を先に決めておく
認証の方式	多要素認証を用いるのが望ましい12	パスワードだけに頼らない認証方式を組み込む

認証と更新は、一度作って終わりではなく、運用のあいだずっと向き合い続ける項目です。最後に、責任の範囲をどう決めておくかを見ていきます。

7. 責任の範囲を先に決める

分界点をあらかじめ明示する

システムに不具合が起きたとき、どこまでが医療機関の責任で、どこからが提供者の責任なのかがあいまいだと、対応が後手に回ります。指針は、診療の計画に、責任の範囲（責任分界点）と、その範囲が途切れないことの明示を含めるとしています²。

分界点は、患者に説明する項目の一つとして位置づけられています。分界点をあいまいにしておくよりも、医療機関・システムの提供者・回線の事業者という並びのどこにも切れ目や抜けを作らないほうが、指針の考え方に沿います。

図の作成：Remogu編集部。指針が示す責任の並びを整理したもので、統計データではありません

安全管理は別のガイドラインで補われる

システムを作る側がもう一つ知っておきたいのが、医療情報を扱うシステムやサービスの提供者に向けた、別の安全管理ガイドラインが用意されているという点です¹⁴。指針だけを見ていると、この存在を見落としがちです。

この記事で扱った本人確認や記録、認証の要件は、指針の骨格にあたる部分です。実装を仕上げていく段階では、安全管理のガイドラインもあわせて確認する立場になることを、あらかじめ見込んでおくと安心です。

医療という言葉を聞くと、専門知識が不足しているのではという不安を感じるかもしれません。実際に指針が求めているのは、本人確認や記録、認証といった、これまでの経験の延長線上にある設計判断です。特殊な資格ではなく、積み上げてきた設計の経験がそのまま生きる領域だと言えます。

認証や記録基盤の設計経験は、業種を問わず評価されやすい実績です。オンライン診療という特定の領域に閉じた経験ではなく、次の案件でも通用する経験として積み上がっていきます。

線引き・本人確認・1対1の証明・記録・認証・責任の範囲。ここまでの6つを押さえておけば、案件に入ってから要件を1つずつ拾い直す必要はなくなります。まずは自分がこれまで関わってきた認証や記録基盤の経験が、この種の案件のどこに重なるかを確かめてみましょう。

オンライン診療の案件では、医療の知識がないと対応できませんか

この記事で扱った要件は、本人確認や記録、認証といった、開発や保守の経験があれば理解できる項目が中心です。医学的な判断が必要な場面は医療機関側の役割であり、外から開発・保守で関わる立場に求められるのは、指針が定める仕組みを正しく実装することです。案件に入る前に指針の全文を読み込んでおく必要はなく、この記事で整理した要件から着手できます。

汎用サービスを使う案件と、専用システムを使う案件で必要なスキルは変わりますか

汎用サービスを使う案件では、通話機能の周辺に本人確認や記録の仕組みをどう組み合わせるかという設計力が問われます。専用システムを使う案件では、指針が求める要件を最初から組み込んだ設計の経験が生きてきます。どちらの案件も、線引きを理解しているかどうかで、着手のスピードが変わります。

この分野の案件に関わってみたい場合、まず何をすればよいですか

この記事で整理した、本人確認・記録・認証・責任の範囲という切り口を、自分の経験と照らし合わせてみることから始められます。まずは登録して、自分の経験に近い条件の案件がどれくらいあるかを確かめてみるのも一つの進め方です。登録自体はいつでも行えるので、案件を探す前の準備として済ませておく進め方もあります。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 厚生労働省「オンライン診療の適切な実施に関する指針」記録の起点（2026年4月）
＊2 厚生労働省「オンライン診療の適切な実施に関する指針」責任分界点（2026年4月）
＊3 厚生労働省「オンライン診療の適切な実施に関する指針」患者側の本人確認（2026年4月）
＊4 厚生労働省「オンライン診療の適切な実施に関する指針」医師側の本人確認（2026年4月）
＊5 厚生労働省「オンライン診療の適切な実施に関する指針」同時実施の禁止（2026年4月）
＊6 厚生労働省「オンライン診療の適切な実施に関する指針」1対1の確認（2026年4月）
＊7 厚生労働省「オンライン診療の適切な実施に関する指針」ログの要件（2026年4月）
＊8 厚生労働省「オンライン診療の適切な実施に関する指針」システムの定義（2026年4月）
＊9 厚生労働省「オンライン診療の適切な実施に関する指針」汎用サービスの定義（2026年4月）
＊10 厚生労働省「オンライン診療の適切な実施に関する指針」リスクの前提（2026年4月）
＊11 厚生労働省「オンライン診療の適切な実施に関する指針」更新の進め方（2026年4月）
＊12 厚生労働省「オンライン診療の適切な実施に関する指針」認証の要件（2026年4月）
＊13 厚生労働省「オンライン診療の適切な実施に関する指針」画面に載せるもの（2026年4月）
＊14 厚生労働省「オンライン診療の適切な実施に関する指針」提供側のガイドライン（2026年4月）