【院内SE必読】神戸大病院のシステム障害から学ぶ｜電子カルテ更新時に絶対やるべき5つの対策

2026年1月5日、神戸大学医学部附属病院で発生したシステム障害。電子カルテの更新作業直後、会計処理が大幅に遅延し、ロビーに数百人の患者が滞留する事態となりました。この事例は、全国の院内SEにとって「明日は我が身」の教訓です。

「事前にシミュレーションしていたのに、なぜ本番で大規模障害が起きたのか?」「自分の病院では同じミスを繰り返さないために、何をすべきか?」――現場の院内SEが今すぐ知っておくべき実務対策を、今回の事例から徹底解説します。

神戸大病院で何が起きたのか？

2026年1月5日午前10時30分ごろ、神戸大学医学部附属病院で電子カルテシステムの更新に伴う大規模なシステム障害が発生しました。

【事故の経緯】

 　2025年12月31日〜2026年1月1日：年末年始の期間を利用し、電子カルテシステムの切り替え作業を実施

 　同日午前10時30分頃：会計処理システムが極端に遅延、マイナ保険証のカードリーダー認証も機能不全に

 　午後：ロビーに数百人の患者が滞留、会計待ち時間が3時間超え

 　午後3時頃：約300人の患者について後日精算の緊急措置を決定

同病院にはこの日、約2,000人の外来患者が訪れていました。病院側は「事前に業務シミュレーションなどの準備を行っていた」と説明していますが、本番環境では想定外の負荷により処理が追いつかず、大混乱を招く結果となりました。

なお、サイバー攻撃や個人情報流出の事実は確認されておらず、あくまでシステム更新に伴う内部的な不具合が原因とされています。

【  引用元記事】

システム更新で絶対に押さえるべき5つの実務対策

今回の神戸大病院の事例は、「事前準備をしていても本番で大規模障害が起きる」という厳しい現実を突きつけました。院内SEとして、システム更新時に何を優先すべきか、現場目線で5つの実務対策を解説します。

「シミュレーション≠本番環境」を前提に、段階的移行計画を立てる

神戸大病院は「事前に業務シミュレーションを実施していた」と発表していますが、それでも本番で大規模障害が発生しました。この原因として考えられるのが、シミュレーション環境と本番環境の差異です。

よくある落とし穴:

●　テスト環境では10人同時接続、本番では2,000人が一斉アクセス

●　模擬データは軽量、実データは何年分もの履歴を含む重いレコード

●　ネットワーク帯域や周辺機器(カードリーダー等)の実機検証が不十分

院内SEがやるべきこと:

●　 段階的移行(フェーズドロールアウト)を提案する
　　 例: 初日は外来患者数を制限、2日目から通常運用など

●　 本番環境に限りなく近い負荷テストを実施
　　 可能なら連休前の通常診療日に、並行稼働でピーク時の動作を確認

●　 ベンダーに「最大同時接続数」「ピーク時のレスポンス保証」を契約書に明記させる

ロールバック計画を必ず用意し、判断基準を事前に決めておく

今回の事例で最も疑問なのが、「午前10時30分に障害が顕在化したのに、なぜ旧システムへ切り戻さなかったのか?」という点です。多くの現場では、ロールバック(切り戻し)の判断が遅れることで被害が拡大します。

院内SEがやるべきこと: 

●　ロールバック判断基準を数値で決める
　　 例: 「会計処理が平常時の2倍の時間がかかった時点で切り戻し」

●　 切り戻し手順書を事前に作成し、リハーサルを実施
　　 特に年末年始等の長期休暇明けは、ベンダー担当者が不在の可能性も考慮

●　 旧システムのバックアップデータを最低1週間は保持
　　 データ移行後もすぐに旧環境を撤去しない

「会計システム」と「資格確認」は優先度を上げて動作検証する

今回の障害では「会計処理の遅延」と「マイナ保険証カードリーダーの不具合」が同時発生しました。この2つは患者の帰宅を直接阻害する致命的な機能です。

院内SEがやるべきこと: 

●　会計・受付システムの優先順位を最上位に設定
　　電子カルテの一部機能が動かなくても診療は続けられるが、会計が止まると患者が帰れない

●　オンライン資格確認端末(マイナンバーカードリーダー)の実機テストを徹底
　　特に2026年現在、マイナ保険証への完全移行期であり、資格確認の不具合は致命的

●　手動運用(紙での会計処理)への切り替え手順を全スタッフに周知
　　システム障害時の代替フローを医事課と事前に合意しておく

「午前10時30分」の教訓―ピークタイム直前の最終チェックを怠るな

神戸大病院では、障害が「午前10時30分」に顕在化しました。これは外来患者が診察を終えて会計に殺到する時間帯です。つまり、システムは朝の受付時点では問題なく動いていたように見えたが、負荷が集中した瞬間に崩壊したのです。

院内SEがやるべきこと: 

●　 稼働初日の「診察開始前」に全機能のスモークテストを実施
　　 朝8時の時点で動いても、午前10時に動く保証はない

●　ピークタイム(10〜11時、14〜15時)の直前に再度動作確認

●　 初日は院内SEが会計窓口に常駐し、リアルタイムで異常を検知できる体制を作る

ベンダー丸投げ体質からの脱却―契約とSLAの見直し

多くの医療機関では、「電子カルテの更新はベンダー任せ」になりがちです。しかし、今回のような障害が起きた際、責任の所在が曖昧だと復旧が遅れ、患者への説明もできません。

院内SEがやるべきこと: 

●　SLA(サービスレベル契約)に「障害時の復旧時間」を明記
　　例: 「本番稼働後1時間以内に復旧できない場合、ベンダーは旧システムへの切り戻しを無償で実施」

●　更新作業の「立会い義務」をベンダー契約に盛り込む
　　年末年始等の長期休暇中でも、稼働初日はベンダーSEが必ず現地に常駐する条件を契約書に記載

● 「誰が何を判断するか」の責任分界点を明確化
　　例: システム切り戻しの最終判断は院内SE(病院長）、データ復旧作業はベンダーが実施、など

執筆者のコメント

「うちの病院は大丈夫」と思った瞬間が危ない

私自身、過去に中規模病院の院内SEとして電子カルテの更新を経験しましたが、今回の神戸大病院の事例は「他人事ではない」と強く感じました。

一番怖いのは、「事前準備をしっかりやったから大丈夫」と油断することです。神戸大病院も決して準備を怠っていたわけではありません。それでも本番で想定外の事態が起きたのです。

院内SEの仕事は、「システムを動かすこと」だけではなく、「システムが止まったときに患者を守ること」だと私は考えています。今回のケースでは、午後3時の時点で約300人を後日精算とする緊急措置が取られましたが、この判断がもっと早ければ、ロビーに数百人が滞留する事態は避けられたかもしれません。

「システムは必ず止まる」を前提に、止まったときの被害を最小化する準備こそが、院内SEの真価です。ベンダーとの契約書にロールバック条項を入れる、手動運用への切り替え手順を医事課と共有する、といった地味な作業が、いざというとき患者と病院を救います。

また、今回の事例で見落とされがちなのが、「システム障害=院内SEの責任」と見なされる組織風土です。たとえベンダーのミスが原因でも、現場では「なぜ院内SEは事前に防げなかったのか」と責められることがあります。だからこそ、契約段階でベンダーの責任範囲を明確にし、「何かあったときの証拠」を残しておくことが重要です。

まとめ

システム更新は「成功して当たり前」だからこそ、失敗への備えを

神戸大病院のシステム障害は、院内SEに多くの教訓を残しました。

今日から実践できる5つの対策:

●　段階的移行計画とピーク時の負荷テストを徹底する

●　ロールバック判断基準を数値で決め、切り戻し手順をリハーサルする

●　会計・資格確認システムの動作検証は優先度を高くする

●　稼働初日はピークタイム直前の最終チェックと現場常駐を実施する

●　ベンダー契約にSLAと責任分界点を明記し、丸投げ体質から脱却する

システム更新は「成功して当たり前」と思われるため、うまくいっても誰も褒めてくれません。しかし、失敗すれば患者に多大な迷惑をかけ、院内SEの評価も地に落ちます。だからこそ、「失敗したときの被害を最小化する準備」にこそ、時間とエネルギーを注ぐべきです。

あなたの病院では、もしも明日システム障害が起きたとき、「誰が」「何を」「いつまでに」判断しますか? その答えが明確でないなら、今すぐベンダーとの契約書を見直し、医事課と緊急時の対応フローを確認してください。

「うちの病院は大丈夫」「なんとかなるだろう」と思った瞬間が、一番危ないのです。