クラウドカルテのネットワーク障害失敗事例集【2026年版・回線冗長化/オフライン運用/SLA確認】

本記事には広告（PR）が含まれます。掲載判断は当サイトの編集部に基づき行っています。編集方針｜最終更新日: 2026-05-09

クラウド型電子カルテは初期投資を大幅に抑えられる一方、インターネット回線に診療が依存するという構造的なリスクを抱えています。実際に「ISP障害でカルテにアクセスできず午前の診療を全キャンセルした」「ベンダーのメンテナンス告知が担当者に届いておらず開院時刻にシステムが落ちていた」という事例が公開情報として報告されています。厚生労働省「医療情報システムの安全管理に関するガイドライン第6.0版」でも、クラウドサービス利用時の通信断・障害時対応手順の整備を医療機関に求めています。本記事では、ネットワーク障害の失敗パターン5種を体系化し、回線冗長化・SLA確認・オフライン運用・障害対応手順を公開情報のみをもとに整理します。

この記事でわかること

クラウドカルテのネットワーク障害で起きる典型的な5パターンと発生メカニズム
回線冗長化（有線＋LTE）・UPS・オフラインキャッシュの具体的な構成イメージ
ベンダーSLAの読み方と障害時の損害補償条項の確認ポイント
障害発生後の紙運用・代替診療・後追入力の実践的な手順
10項目以上の障害対策チェックリストとFAQ 8問

[PR]

1. はじめに——クラウドカルテの普及と通信障害リスク

クラウド型電子カルテの導入率は年々上昇しており、特にクリニック・診療所規模では2025年度以降の新規導入の過半数がクラウド型に移行していると推測されます（厚労省「医療DXロードマップ」2024年公表の方向性から）。オンプレミス型と比較した際のメリットは明確です。サーバー設置コストが不要、ソフトウェア更新が自動化、遠隔アクセスが可能、といった点が院長・事務長の意思決定を後押ししています。

しかし、クラウド型への移行で見落とされがちな構造的リスクが「通信依存」です。オンプレミス型の場合、院内LANが生きていれば電子カルテへのアクセスは維持できます。一方、クラウド型はインターネット回線が途絶した瞬間にカルテへのアクセスが失われます。患者様の診療情報が参照できなければ、問診や投薬の安全性が著しく低下し、最悪の場合は診療そのものを中断せざるを得ません。

厚生労働省「医療情報システムの安全管理に関するガイドライン第6.0版」（2023年）では、クラウドサービスを利用する医療機関に対して、「通信障害時の業務継続手順をあらかじめ策定し、定期的に訓練すること」を明示的に求めています。また、経済産業省・総務省「医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン」（2023年）でも、クラウド事業者側に対して障害時の通知義務・復旧目標時間（RTO）・復旧目標時点（RPO）の明示を求めており、医療機関がSLAを確認・交渉する根拠となっています。

本記事は、公開情報を整理しながら、クラウドカルテのネットワーク障害に関する失敗事例のパターンを体系化します。個別ベンダーの評価・批判は行わず、医療機関の院長・事務長・IT担当者が導入前・運用中に自施設の状況を点検するための判断材料を提供することを目的とします。なお、具体的な設定・構成変更・データ復旧については、あらかじめご利用のベンダーおよびIT部門・情報システム責任者に相談のうえ実施してください。

2. 通信障害の典型パターン全体像（5パターン）

クラウドカルテで発生する通信障害は、発生源によって大きく5つに分類できます。複数パターンが複合して起きるケースもあり、特に「院内側の問題」と「ベンダー側の問題」が重なると復旧に時間がかかります。

パターン番号	障害の発生源	主な症状	想定復旧時間の目安
N-1	院内回線の一本化（ISP障害・基地局障害）	カルテへのアクセスが完全に途絶	ISP復旧待ち（数時間〜数日）
N-2	ベンダーデータセンター障害・計画メンテナンス	特定のユーザー全員がアクセス不能	ベンダー復旧待ち（数時間〜）
N-3	オフラインモード動作不良・同期失敗	一部記録が消える・重複・整合性破綻	ベンダーによるデータ修復（数時間〜数日）
N-4	院内停電（UPS未設置）	端末・ルーター・スイッチが同時停止	電源復旧次第（分〜時間）
N-5	障害時のスタッフ判断ルール未整備	対応が個人任せとなり診療が混乱	手順策定まで再発リスク継続

以降のセクション3〜5では、特に影響が大きいパターンN-1〜N-3について詳細に解説します。N-4（UPS）とN-5（運用ルール）は、セクション7の障害対策チェックリストで具体的な対処を整理します。まず全体像として押さえておくべき点は、「回線冗長化・SLA・オフライン設計・電源・手順書」の5要素がすべて揃わないと障害リスクは下がらない、という相互依存関係です。

3. パターン詳細1：回線一本化での全停止（ISP障害・基地局障害）

クラウドカルテ障害の中で最も発生頻度が高いのが、院内のインターネット回線が一本しかなく、そのISPで障害が発生した際の全停止です。特にクリニックでは「光回線1本で十分」という判断のまま開院し、ISP側の設備障害・工事ミス・光ケーブル切断で診療が完全停止するという事態が起きています。

3-1. ISP障害の発生メカニズム

光回線（FTTH）は安定性が高い一方、回線事業者側の設備トラブル・局内工事・台風や地震による物理的なケーブル断が発生するリスクがゼロではありません。総務省「電気通信事業法」に基づく電気通信事業者の重大な事故報告制度では、影響が3万人以上かつ2時間以上の障害は報告対象とされており、ISP障害は現実に起きていることがわかります。院内の機器は正常でもISP側の設備が落ちれば、クラウドカルテへの接続は途絶します。

3-2. 携帯基地局障害の見落とし

「光回線が落ちてもスマートフォンのテザリングで対応できる」と考えているクリニックも多いですが、大規模災害時や輻輳時には携帯基地局も接続できなくなるケースがあります。また、建物内での電波状況によっては平常時から通信が不安定なこともあります。テザリングはあくまで「緊急時の補助手段」であり、冗長化の主軸とするには安定性が不足しています。

3-3. 回線冗長化の基本構成

ISP障害対策の基本は「メイン回線（光）＋バックアップ回線（LTE/5G）」の二重化です。ルーターに複数WAN口またはSIMスロットがある機種を採用し、メイン回線が切れると自動でバックアップ回線に切り替わる「フェイルオーバー」設定を行います。この構成により、ISP障害時でも数秒〜数十秒程度でバックアップ回線に切り替わり、診療を継続できます。ただし、具体的な機器選定・設定はあらかじめIT部門・情報システム責任者・またはネットワーク事業者に相談のうえ実施してください。

なお、バックアップ回線のLTE/5Gは月額通信費が発生します。クラウドカルテのデータ転送量は通常それほど大きくないため、低容量プランでも業務継続に十分なケースが多いですが、プランの適正化はベンダーとの相談を推奨します。

4. パターン詳細2：ベンダーデータセンター障害／メンテナンス連絡漏れ

院内回線は正常なのにクラウドカルテにアクセスできない——この状況はベンダーのデータセンター側で障害が発生しているか、計画メンテナンス中に起きます。後者については「メンテナンス告知がメールで届いていたが確認できておらず、開院時刻に気づいた」という人的な情報漏れも頻繁に発生します。

4-1. データセンター障害の特性

クラウドカルテのベンダーは通常、複数のデータセンターを利用した冗長構成を採用しています。それでも、特定のアベイラビリティゾーン（AZ）での障害やネットワーク経路の問題で、一部のユーザーがアクセスできなくなることがあります。こうした障害は医療機関側ではコントロールできないため、SLAの確認と障害時の代替手段の整備が重要になります。

4-2. SLAの読み方と確認ポイント

SLA（Service Level Agreement：サービスレベル合意）は、ベンダーがユーザーに対してサービスの品質水準を約束した文書です。クラウドカルテの契約前にはあらかじめSLAを入手し、以下の項目を確認することが重要です。

稼働率の数値（99.9%・99.5%など）と計測方法：年間許容ダウンタイムは99.9%で約8.7時間、99.5%で約43.8時間
メンテナンス時間の扱い：計画メンテナンス中は稼働率の計算から除外されるケースが多い
障害時の通知方法・通知先：メールのみか、電話・ステータスページ・SMS等の複数手段があるか
損害補償の有無と上限：SLA違反時に月額料金の一部を返金するクレジット制度があるか、医療損害は補償対象外であることが多い
RTO（目標復旧時間）とRPO（目標復旧時点）：特に重大障害時に何時間以内にサービスを復旧させることを目標としているか

これらの確認はIT部門・情報システム責任者・またはベンダーの営業担当者に書面で確認することを推奨します。SLAの内容はベンダーによって大きく異なるため、複数のベンダーを比較する際の重要な評価軸となります。

4-3. メンテナンス連絡漏れの防止策

ベンダーからのメンテナンス告知メールが担当者に届かない、または確認されないまま当日を迎えるという事態は、運用体制を整備することで大幅に防げます。具体的には、告知メールの受信先を複数の担当者に設定すること（院長メール1本のみでは院長不在時に見逃す）、ベンダーのステータスページをブックマークしてトラブル時に確認できるようにしておくこと、またGoogle Workspace等のグループメール機能を活用することが効果的です。計画メンテナンスのスケジュールをスタッフ全員が確認できる院内の共有カレンダーに登録することも有効です。

5. パターン詳細3：オフライン運用機能の落とし穴（同期失敗・整合性破綻）

「オフライン対応」を謳うクラウドカルテも増えています。しかし、オフラインモードには運用上の制約と技術的なリスクが存在します。これを十分に理解せずに導入すると、ネットワーク復旧後の同期処理で深刻な問題が発生する可能性があります。

5-1. オフラインモードの仕組みと制約

クラウドカルテのオフラインモードは、通常「端末ローカルに患者データの一部をキャッシュし、ネットワーク断の間もカルテの参照・記録ができる」仕組みです。しかし、オフラインで記録できるデータの種類や範囲はベンダー・プランによって異なります。たとえば「SOAP記録は書けるが処方入力はできない」「当日受診の患者データのみキャッシュされる」といった制限がある場合があります。導入前にベンダーに詳細仕様を確認することが不可欠です。

5-2. 同期失敗のリスクと整合性破綻

オフラインで記録したデータは、ネットワーク復旧後にクラウド側と同期されます。このとき問題が起きるのは、「オフライン中に別の端末（または別の院）でも同じ患者のデータが更新されていた」ケースです。同期処理の競合（コンフリクト）が発生し、どちらのデータを正とするかの判定に誤りが生じると、最新の処方内容や病名コードが上書きされて消える可能性があります。

また、オフライン端末がキャッシュデータを保持したまま紛失・盗難に遭うと、患者の医療情報が端末内に残存することになります。厚生労働省ガイドラインでは、端末の暗号化・リモートワイプ機能の整備を求めており、オフライン利用時のセキュリティ管理は通常運用より高い水準が必要です。

5-3. ローカルキャッシュ設計の確認事項

オフライン機能を安全に活用するためには、導入前に以下の点をベンダーに書面で確認することを推奨します。IT部門・情報システム責任者を通じて確認することが理想的です。

オフライン時に参照・記録できるデータ種別と範囲
同期競合発生時のコンフリクト解消ルール（最新上書き・マージ・手動解決のいずれか）
同期失敗時のエラーログの確認方法と担当者への通知設定
キャッシュデータの暗号化方式とリモートワイプ対応の有無
オフライン継続可能な最大時間と、その超過時の挙動

6. 共通する根本原因（SLA・バックアップ・冗長化の事前設計不足）

セクション3〜5で解説した3つのパターンを横断すると、根本原因として共通しているのは「事前設計の不足」です。クラウドカルテを導入する際に「費用・機能・UI」は比較されますが、「障害時の業務継続設計」が契約前に十分検討されないケースが多く見受けられます。

6-1. SLA未確認による期待値のミスマッチ

「クラウドだから安定しているはず」という思い込みで導入し、SLAを確認していない医療機関では、障害発生後に「こんな条件だと思っていなかった」という事態が起きます。稼働率99.5%であれば年間43時間以上のダウンタイムが許容されているわけで、これが診療時間と重なれば深刻な影響が出ます。契約締結前にSLAを読み込み、IT部門・情報システム責任者とともに許容範囲かを判断することが不可欠です。

6-2. バックアップ設計の不足

クラウドカルテはベンダー側でデータをバックアップしているため、「バックアップは不要」と考える医療機関もいますが、これは誤解です。ベンダーのバックアップはデータセンター全体の障害や誤削除への対応であり、個別ユーザーのオペレーションミスや部分的なデータ破損には対応できないケースがあります。定期的なデータエクスポートの実施・保管についてもベンダーと運用方針を明確にしておくことが重要です。

6-3. 冗長化設計の「抜け漏れ」

回線を二重化しても、終端となるルーターが故障すれば冗長化は機能しません。また、電力供給が途絶えれば回線・端末・サーバー・ルーターすべてが止まります。冗長化設計では「回線」「電力（UPS）」「端末」「ネットワーク機器」を一体として考える必要があります。個別要素だけ対策しても、他の要素がボトルネックになって業務継続が失敗するケースがあります。これは経済産業省「サイバーセキュリティ経営ガイドライン」でも、BCP（事業継続計画）としてITシステム全体の回復力を設計するよう求めていることと一致します。

6-4. 障害時の意思決定者と手順が未策定

技術的な冗長化が整っていても、「障害発生時に誰が何を判断し、何を実行するか」が決まっていなければ現場は混乱します。特に院長が診察中の場合、事務長やリーダースタッフが即断できる権限と手順が必要です。IPA「中小企業の情報セキュリティ対策ガイドライン」では、インシデント発生時の連絡体制・エスカレーション先の文書化を強く推奨しています。

7. 障害対策チェックリスト（10項目以上：回線冗長・UPS・運用手順）

以下のチェックリストは、クラウドカルテ導入前・導入後の定期点検で活用できる項目を整理したものです。全項目について、IT部門・情報システム責任者・ベンダーと連携して対応状況を確認してください。

項目番号	チェック項目	対応レベル	担当
C-01	インターネット回線がメイン1本のみになっていないか	必須	IT担当・ベンダー
C-02	バックアップ回線（LTE/5G）のフェイルオーバー設定が完了しているか	必須	IT担当・ベンダー
C-03	UPS（無停電電源装置）がルーター・スイッチ・主要端末に設置されているか	必須	施設管理者・IT担当
C-04	UPSのバッテリー残量・定期交換サイクルが管理されているか	必須	施設管理者
C-05	ベンダーのSLA（稼働率・RTO・RPO）を書面で確認済みか	必須	院長・事務長・IT担当
C-06	ベンダーのメンテナンス告知を複数担当者が受信する設定か	必須	事務長・IT担当
C-07	障害発生時の連絡先（ベンダーサポート・IT担当）が全スタッフに周知されているか	必須	院長・事務長
C-08	オフラインモードの動作仕様（範囲・制限・同期ルール）をベンダーに書面確認済みか	推奨	IT担当・ベンダー
C-09	端末の暗号化・リモートワイプ機能が設定されているか	必須	IT担当
C-10	紙カルテ・印刷フォーマットが施設内に準備されているか	必須	事務長・看護師長
C-11	障害時の「紙運用」手順書が文書化・印刷保管されているか	必須	院長・事務長
C-12	年1回以上の障害訓練（障害発生を想定した紙運用シミュレーション）を実施しているか	推奨	院長・全スタッフ
C-13	ベンダーのバックアップデータの保持期間・エクスポート方法を確認済みか	推奨	IT担当・ベンダー

これらの項目はチェックの有無だけでなく、「担当者が誰か」「最後に確認した日付」を記録に残すことが重要です。医療機関の情報セキュリティは個人情報保護委員会「医療・介護関係事業者における個人情報の適切な取扱いのためのガイダンス」でも継続的な管理が求められており、一度設定して終わりではなく定期的な見直しが前提となります。

7-1. 冗長化レベルの比較

回線冗長化にはいくつかの構成レベルがあり、診療規模と予算に応じて選択肢が変わります。以下は構成の概念的な比較です。実際の構成はIT部門・ネットワーク事業者・ベンダーと相談のうえ決定してください。

構成レベル	概要	切替方式	想定コスト感	主な対策対象
Level 0（未対策）	光回線1本のみ	なし	最小	対策なし（リスク最大）
Level 1（手動切替）	光回線＋テザリング手動切替	手動	スマホ契約費のみ	ISP障害（短時間）
Level 2（自動フェイルオーバー）	光回線＋LTE/5G SIM内蔵ルーター	自動（数秒〜数十秒）	ルーター費用＋SIM月額	ISP障害・回線断
Level 3（デュアルISP）	光回線2系統（ISP異なる）＋LTE	自動	回線費用×2＋ルーター	ISP障害・局内障害
Level 4（SD-WAN）	複数回線の帯域を動的管理・品質制御	自動・高度	導入・月額費用高め	品質劣化含む広域対策

多くのクリニックにとって現実的な目標はLevel 2です。対応ルーターの導入とSIMカード1枚の追加で実現でき、ISP障害時の自動切替により診療継続性が大幅に向上します。ただし、機器の選定・設定はIT部門・情報システム責任者または専門業者に依頼することを強く推奨します。

8. もし起きてしまったら（紙運用・代替診療・後追入力の手順）

どれだけ事前対策を整えても、予期せぬ障害は発生し得ます。実際に通信障害が発生した際に、診療を安全に継続・縮小・停止するための行動フローを整理します。以下はあくまで概念的な手順であり、実際の対応はベンダーの指示・IT部門・情報システム責任者の指示に従ってください。

8-1. 発生直後（0〜5分）

障害発生直後は、まず「院内の問題か・ベンダー側の問題か・ISPの問題か」を切り分けることが重要です。他の端末でも同じ状態であれば院外側の問題です。ベンダーのステータスページ（URLは事前に院内に周知）とISPの障害情報ページを確認し、障害規模と想定復旧時間の情報を収集します。バックアップ回線（LTE）への切替を試みます。この段階で「復旧まで数時間かかる」と判断できれば、早期に紙運用への切替を決断します。

8-2. 紙運用への切替（5〜15分）

事前に準備しておいた紙のカルテ記録フォーマット・処方箋フォームを取り出します。受付では「電子システムが一時的に利用できない」旨を患者様に丁寧に説明し、診察待ち時間が通常より長くなる可能性を伝えます。診察室では医師が紙に記録しながら診療を継続します。この際、患者さんの氏名・生年月日・受診日時・主訴・処置内容・投薬内容を漏れなく記録することが重要です。後追入力の精度は記録の詳細さに依存します。

8-3. 障害長期化時の対応

数時間以上の長期障害が見込まれる場合は、当日以降の予約患者への対応も検討します。予約管理システムもクラウド型の場合は同時に利用不能になる可能性があります。患者様への連絡手段（電話・メール等）が確保されているか確認し、状況に応じて予約の変更・延期の案内を行います。診療の継続可否は院長が判断し、スタッフに周知します。

8-4. 復旧後の後追入力と確認

システムが復旧したら、紙に記録した内容を電子カルテに後追入力します。後追入力の際は以下の点に注意が必要です。

記録日時と診察日時を正確に分けて入力する（後追入力日が診察日として登録されないよう確認）
処方内容・投薬量の転記ミスがないよう、2人以上でダブルチェックする
オフラインモードで記録したデータがある場合、同期完了後に内容が正確か確認する
データの同期状態に疑義がある場合は、修正前にベンダーサポートへ連絡して指示を仰ぐ

後追入力の手順や同期後の確認方法は、ベンダーによって異なる場合があります。あらかじめベンダーの指示に従い、不明な点はIT部門・情報システム責任者・ベンダーサポートに確認してください。

8-5. 障害後の記録と再発防止

障害が解消したら、発生時刻・復旧時刻・対応内容・影響患者数・コスト影響を記録します。この記録は次の障害訓練や対策見直しの材料になります。ベンダーに対しては障害の原因説明・再発防止策の提示を書面で求めることも可能です。SLAにクレジット条項がある場合は、規定の申請手順に従ってクレジットを申請します。

9. FAQ 8問

Q1. クラウドカルテを使いながら完全にオフラインで運用できますか？

A. 基本的には難しいです。クラウドカルテの設計思想はネットワーク接続を前提としており、完全オフライン運用はほとんどのベンダーが想定していません。一部のベンダーがオフライン機能を提供していますが、利用できる機能に制限があります。「通信断時でも最低限の診療継続」を目標とし、オフライン機能とバックアップ回線を組み合わせて対応する設計が現実的です。詳細はご利用のベンダーに確認してください。

Q2. SLAの稼働率99.9%と99.5%では実際にどれくらい差がありますか？

A. 年間許容ダウンタイムで比較すると、99.9%は約8.7時間、99.5%は約43.8時間の差があります。年間43時間のダウンタイムは、週1回程度・1時間未満の障害が発生し得ることを意味します。計画メンテナンスがSLAの計算から除外される場合はさらに実質的な利用不能時間が増えます。稼働率だけでなくRTO（復旧目標時間）や障害通知の速さも合わせて評価することが重要です。

Q3. LTEバックアップ回線は具体的にどんな機器を使えばいいですか？

A. LTE/5G SIMスロットを内蔵した業務用ルーターが市場に多数存在します。主回線断時のフェイルオーバー機能を持つ機種を選ぶのが基本です。ただし、機器選定・設定・ネットワーク構成の変更はIT部門・情報システム責任者・または専門の業者に依頼することを強く推奨します。インターネット上のレビューだけで選定・設定を行うとセキュリティリスクが発生することがあります。

Q4. UPSはどこに設置すれば効果がありますか？

A. 最低限カバーすべきはインターネット接続の要となるルーター・スイッチ類と、電子カルテを入力する主要な端末です。電源が切れるとルーターが再起動して回線切替に時間がかかるため、ルーターへのUPS設置は特に効果があります。UPS選定・設置は電気設備の知識が必要なため、施設管理者またはIT担当者が専門業者と相談のうえ実施してください。

Q5. ベンダー側の障害でカルテが使えなかった場合、医療機関として責任を問われますか？

A. 現時点では、通信障害を理由とした医療機関への直接的な行政処分例は公開情報の範囲では確認できません。ただし、厚生労働省ガイドラインは「障害時の業務継続手順を整備していること」を医療機関の義務として明示しており、手順が未整備の状態で障害が発生し、患者様に何らかの不利益が生じた場合は施設側の管理責任が問われる可能性を否定できません。詳細は医療経営・法律の専門家にご相談ください。

Q6. 障害時に紙処方箋を発行することは問題ありませんか？

A. 医師が処方箋を手書きで発行することは法的に問題ありません。電子処方箋（2023年〜）が導入済みの施設でも、システム障害時は書面での発行が認められています。ただし、電子処方箋管理サービスへの登録が必要な場合は、障害解消後に規定の手順で後追処理が必要です。詳細は最寄りの地方厚生局またはベンダーにご確認ください。

Q7. オンプレミス型への回帰は障害対策として有効ですか？

A. オンプレミス型はインターネット回線に依存しないため、ISP障害には強いです。ただし、院内サーバーの故障・ランサムウェア感染・物理的な災害には脆弱になります。IPA「医療機関向けランサムウェア対策チェックリスト」でも、オンプレミス型サーバーへの直接攻撃が医療機関のシステム停止の主要因として挙げられています。どちらが「優れている」ではなく、自施設のリスク評価に基づいた選択が重要です。IT部門・情報システム責任者と総合的に判断してください。

Q8. 障害対策の整備に補助金は使えますか？

A. 医療機関のIT環境整備には、厚生労働省の医療DX推進支援補助金・ITベンダーを通じた各種補助金が存在します。また、経済産業省のIT導入補助金（中小企業向け）が活用できるケースもあります。補助金の対象範囲・申請要件は年度によって変わるため、最新情報は厚生労働省・経済産業省の公式サイトまたは最寄りの支援機関にご確認ください。IT補助金の詳細については別記事「電子カルテIT補助金2026年版」もご参照ください。

10. 次の1ステップ + 関連記事 + 出典

本記事で整理した通信障害対策は、すべてを一度に実施する必要はありません。まず「C-01〜C-07」の必須チェック項目から着手し、現状の対応状況を確認することが第一歩です。特に「回線一本化」「UPS未設置」「SLA未確認」のいずれかに該当する施設は、優先的にIT部門・情報システム責任者・ベンダーへの相談を実施することを推奨します。

クラウドカルテの選定・比較をこれから行う場合は、障害時対応の仕様をSLA確認の観点から評価することで、長期運用における安定性の差異が浮かび上がります。詳細な比較は以下の関連記事をご参照ください。