【2027年に何が変わるか】クラウドネイティブ電子カルテとは｜2.5億円の導入費とベンダーロックインは解消されるのか

2026年の夏、病院の電子カルテをめぐって性格の異なる2つの発表がありました。ひとつは費用負担の重さを数字で突きつけたもの、もうひとつはその構造を変えうる新しい製品の登場を告げるものです。

この2つは別々のニュースとして報じられましたが、並べて読むと、これから電子カルテの更新を迎える病院にとって避けて通れない論点が浮かび上がります。「2027年に登場する選択肢を待つべきか、それとも今動くべきか」という判断です。

本記事では、クラウドネイティブ電子カルテとは何かを整理した上で、それが費用構造とベンダーロックインを本当に変えるのか、そして病院が今から準備できることは何かを、調達の視点から検討します。

—

1: 2026年夏、電子カルテをめぐって起きた2つの出来事

1-1: 日医調査が示した費用の実態（7月15日公表）

2026年7月15日、日本医師会は200床以上の病院における電子カルテの普及状況と費用負担に関する実態調査の結果を公表しました。中国四国医師会連合が中国・四国9県の200床以上の病院265施設を対象に実施し、176施設から回答を得たものです（回答率66.4%）。

病床規模	導入費用の平均	年間保守費用の平均	リプレイス費用の平均
200〜299床	約2億5300万円	約2300万円	約2億8900万円
300〜399床	約4億900万円	約3400万円	約5億6000万円
400〜499床	約5億3300万円	約8600万円	約7億1400万円
500床以上	約12億7500万円	約1億7400万円	約13億6300万円

日本医師会公表資料（2026年7月15日）の数値をもとに作成

注目すべきは2点です。すべての規模帯でリプレイス費用が導入費用を上回っていること。
そして調査対象の医療機関から「ベンダー変更時の費用が法外である」という声が寄せられていることです。

調査を担当した山口県医師会会長の加藤智栄氏は、診療報酬上の支援では電子カルテ関連費用の1割にも満たない補填しかできないと指摘し、医療DXにかかる費用負担を医療機関だけに求める形は持続可能とはいえないと訴えました。

1-2: 標準仕様準拠クラウドネイティブ製品の開発発表（8月25日）

その約1か月後の2026年8月25日、医療DXを手がけるメドレーが、病院・有床診療所向けにクラウドネイティブの電子カルテを開発すると発表しました。

厚生労働省が示す標準仕様に準拠した「MALLクラウド」で、2027年1月以降の段階的な提供を目指すとしています。

この発表が持つ意味は、単に新製品が1つ増えたということではありません。厚労省が定義する「クラウドネイティブ電子カルテ」の要件を満たす製品が、病院向けに具体的に動き出したという点にあります。

1-3: この2つを並べると見えてくる論点

日医調査が明らかにしたのは、現在の電子カルテが抱える2つの構造的問題です。

問題① 費用が高すぎる：200床規模でも2.5億円の初期投資、年2300万円の保守費用。10年間では約4.8億円に達します。

問題② 乗り換えられない：データ移行費・カスタマイズ再現費・部門システム再接続費が積み上がり、ベンダー変更の実質的なハードルが極めて高い。競争が働かない構造です。

クラウドネイティブ化は、この2つの問題に対する処方箋として期待されています。院内サーバーが不要になれば初期費用は下がるはずですし、標準仕様に準拠すればデータ移行も容易になるはずです。

しかし「はず」で調達判断はできません。本当に安くなるのは何で、何は変わらないのか。 これを切り分けることが本記事の目的です。

—

2: クラウドネイティブ電子カルテとは何か

2-1: 厚労省が示す要件｜院内サーバー運用を前提としない

厚生労働省が示すクラウドネイティブ電子カルテは、医療機関内のサーバーでの運用を前提とせず、情報セキュリティ基準を満たしたパブリッククラウド環境で稼働することが要件とされています。

ポイントは「院内サーバーを前提としない」という部分です。従来の電子カルテは、クラウドを名乗るものであっても院内に何らかのサーバーを置く構成が一般的でした。クラウドネイティブでは、この院内サーバーそのものを不要にすることが設計の起点になっています。

2-2: 従来の「クラウド型」と何が違うのか

「クラウド型電子カルテ」という言葉自体は以前からありました。両者の違いを整理します。

既存のオンプレミス製品をベースに、データの保管場所や一部機能をクラウドに移した構成です。院内サーバーが残る、あるいは院内に一定の機器を置く前提の設計が多く見られます。アーキテクチャ自体は院内設置時代の考え方を引き継いでいます。

最初からクラウド環境で動くことを前提に設計されたシステムです。院内サーバーを持たず、拡張性・可用性・アップデートの仕組みがクラウドの特性を活かす形で構築されます。

この違いは、運用の実態に表れます。従来型では病院ごとにサーバーの保守・更新が必要ですが、クラウドネイティブではベンダー側の環境で一元的に管理・更新される設計です。

2-3: オンプレミスからクラウドへ移行が進む背景

医療分野でクラウド移行が進んでいる背景には、複数の要因があります。

サーバーの維持負担：院内サーバーは5〜7年ごとの更新が必要で、その都度ハードウェア費用が発生します。設置スペース・空調・電源の確保も継続的なコストです。

BCP・災害対策：院内サーバーは災害時に物理的な被害を受けるリスクがあります。データセンターでの運用は、この観点でメリットがあります。

IT人材の不足：院内でサーバーを管理できる人材の確保は、中小規模の病院ほど困難です。

セキュリティ要件の高度化：ランサムウェア被害の増加を受け、医療機関に求められるセキュリティ水準は上がり続けています。個別病院で対応し続けることの限界が意識されるようになりました。

2-4: なぜ政府がこの方向を推すのか

政府は2030年までに電子カルテ普及率100%の達成を掲げています。

この目標と、日医調査が示した費用の現実の間には大きな隔たりがあります。

普及率を上げるには、導入のハードルを下げる必要があります。クラウドネイティブ化と標準仕様の整備は、そのための手段という位置づけです。

厚生労働省は200床未満の中小規模の病院・診療所には2030年までに標準型電子カルテ（導入版）や標準仕様に即した低価格のクラウド型電子カルテの導入を進め、200床以上の大規模病院に対しても標準仕様に即した製品を段階的に拡大させる方針を示しています。

—

3: 病院向けクラウドネイティブ製品の具体例

ここでは、2026年8月に発表された具体例を通じて、病院向けクラウドネイティブ電子カルテがどのような姿を目指しているかを見ていきます。特定製品の推奨ではなく、この分野の方向性を理解するための材料として扱います。

3-1: メドレーが開発を発表した「MALLクラウド」の概要

メドレーは2026年8月25日、AIを活用し、病院・有床診療所向けにクラウドネイティブの電子カルテを開発すると発表しました。厚生労働省が示す標準仕様に準拠した「MALLクラウド」で、2027年1月以降の段階的な提供を目指すとしています。

同社はこれまでクリニック向けのクラウド型電子カルテ（CLINICS）を展開してきましたが、今回の発表は病院・有床診療所という、より複雑な要件を持つ領域への展開という位置づけになります。

3-2: オンプレの機能・導線を踏襲するという設計思想

発表内容で注目すべきは、機能や導線などの基本的な仕様をオンプレミス電子カルテから踏襲するとしている点です。

病院の電子カルテは、医師・看護師・薬剤師・検査技師など多職種が長年の運用で身につけた操作手順の上に成り立っています。クラウド化を理由に画面や導線が大きく変わると、移行時の混乱と教育コストが跳ね上がります。

「クラウドになるが、使い勝手は変えない」という方向性は、病院向け製品として現実的なアプローチといえます。

3-3: 部門システムを同一画面で扱う構成

薬剤・栄養・検査・透析などの自社部門システムを同一画面で扱えるようにするとされています。

病院の電子カルテが複雑化する最大の要因は、部門システムとの連携です。放射線・検査・薬剤・栄養・手術など、各部門が独自のシステムを持ち、それらを電子カルテと接続する構成が一般的です。この接続数が多いほど、導入費用も更新費用も膨らみます。

同一ベンダーの部門システムを同じ画面で扱える構成は、この連携コストを抑える方向性を示しています。ただし後述の通り、既に他社の部門システムを使っている病院にとっては、別の判断が必要になります。

3-4: 生成AIによる文書作成支援・外部連携

検査機器・医事会計・画像システム・周辺機器などの外部連携による多機能化と、生成AIによる医療文書作成支援などの機能も搭載する予定とされています。

医療文書の作成は、医師の負担として長年指摘されてきた領域です。診断書・紹介状・退院サマリー・各種計画書の作成に費やされる時間は無視できません。ここに生成AIを活用する方向性は、医師の働き方改革が求められる現在の状況と合致しています。

ただし生成AIの活用については、記載内容の正確性の担保、責任の所在、患者情報の取り扱いといった論点が残ります。実際の運用ルールは各医療機関で設計する必要があります。

3-5: 2027年1月以降の段階的提供とパイロット募集

提供開始に先立って、パイロット版のユーザーとなる病院や診療所を募集するとされています。

「2027年1月以降に段階的に提供」という表現は、全機能が一斉に使えるようになるわけではないことを意味します。更新時期が確定している病院にとっては、この段階性がスケジュールにどう影響するかが重要な確認事項になります。

—

4: 医療DXの全体像の中での位置づけ

4-1: 電子カルテ情報共有サービスとの連携

クラウドネイティブ化と標準仕様準拠が政策的に推進される最大の理由は、電子カルテ情報共有サービスの実現にあります。

これは全国の医療機関の間で診療情報（傷病名・アレルギー・感染症・薬剤禁忌・検査値等）を共有する仕組みです。患者が別の医療機関を受診した際に過去の情報を参照できれば、重複検査・重複投薬の削減、救急時の対応、災害時の診療継続といった効果が期待されます。

この共有を実現するには、各医療機関のデータが共通の規格（HL7 FHIR準拠）で保持されている必要があります。標準仕様への準拠は、この連携基盤に参加するための条件という位置づけです。

4-2: オンライン資格確認・電子処方箋との接続

医療DXの各施策は独立ではなく連動しています。オンライン資格確認は既に原則義務化され、電子処方箋は薬局への導入が進み、次の段階として電子カルテ情報共有サービスへの接続が広がっていきます。

電子カルテを更新する際は、これらの施策への対応状況をまとめて確認することが効率的です。個別に対応すると、その都度改修費用が発生します。

4-3: AI活用で効率化できる領域とできない領域

生成AIの活用が期待される領域は、主に文書作成の支援です。診療録の下書き生成、紹介状・診断書の作成支援、退院サマリーの要約などが挙げられます。

一方で、AIが代替できない領域も明確です。診断そのものの判断、患者への説明と合意形成、記載内容の最終的な確認と責任は医師が担います。AIは作業時間を削減する道具であり、判断を委ねる対象ではありません。

調達の観点では、「AI機能が搭載されている」ことよりも、「その機能が自院の業務のどこにどれだけ時間削減をもたらすか」を具体的に検証することが重要です。デモの場で、自院で実際に作成している文書を題材に試させてもらうことを推奨します。

—

5: 導入費2.5億円は何にかかるのか｜費用の分解

5-1: 製品・開発・機器・データ移行の初期費用

日医調査が示した200〜299床で2.53億円という金額は、以下の要素で構成されています。

ハードウェア費用：サーバー、クライアント端末（数十台〜数百台）、ネットワーク機器、プリンタ、UPS等

ソフトウェアライセンス費用：電子カルテ本体、部門システム、オプション機能

カスタマイズ費用：自院の運用に合わせた画面・帳票・ワークフローの開発

部門システム連携費用：放射線・検査・薬剤・手術等との接続開発

データ移行費用：既存システムからの診療データ・患者マスタの移行

導入支援・教育費用：設定作業、テスト、多職種向けの操作研修

この中でクラウドネイティブ化によって減る可能性があるのは、主にサーバー関連のハードウェア費用です。ただし端末・ネットワーク機器は引き続き必要であり、ハードウェア費用がゼロになるわけではありません。

5-2: 月額料金だけではない運用・保守・院内支援のコスト

クラウドネイティブでは、費用の構造が「初期一括＋年間保守」から「初期費用＋月額利用料」に変わります。

ここで注意すべきは、月額利用料が従来の保守費用より安いとは限らないことです。日医調査では200〜299床の年間保守費用が約2300万円でした。月額換算で約190万円です。クラウドの月額利用料がこれを下回るかどうかは、契約条件次第です。

また月額料金以外にも、以下の費用が発生します。

• ネットワーク回線費用（可用性を高める冗長構成の場合は増加）
• 端末の更新費用（数年ごと）
• 追加ユーザー・追加機能の従量費用
• 院内のIT運用体制の人件費
  

契約前に、5年・10年スパンでの総額を試算して比較することが不可欠です。

5-3: クラウドで消える費用と、残る費用の切り分け

ここが本記事の中核です。クラウドネイティブ化で何が変わり、何が変わらないかを整理します。

消える・減る可能性がある費用

項目	理由
院内サーバーのハードウェア費用	院内設置が不要になる
サーバー室の設備費用（空調・電源）	同上
サーバーの定期更新費用	ベンダー側で管理される
バージョンアップ作業費用	クラウド側で一元的に更新される
サーバー障害対応の院内負担	ベンダー側の運用に移る

変わらない・残る費用

項目	理由
クライアント端末の費用	院内で使う端末は引き続き必要
ネットワーク機器・回線費用	むしろ重要性が増し、増加の可能性
部門システム連携の開発費用	接続先が変わらなければ費用構造も変わらない
データ移行費用	現行システムからの移行作業は必要
導入支援・教育費用	多職種への研修は避けられない
カスタマイズ費用	標準機能で足りない部分は同じ

増える可能性がある費用

クラウドネイティブでは、インターネット接続が切れると診療業務が停止します。回線の冗長化（複数事業者との契約）、モバイル回線のバックアップ、障害時の代替運用体制の整備が必要になり、これらは新たなコストです。

つまり「クラウドにすれば安くなる」という単純な話ではありません。 サーバー関連費用は減りますが、ネットワーク投資は増え、連携・移行・教育の費用は残ります。

5-4: 有床病院と診療所で異なる投資回収の考え方

規模によって、クラウドネイティブ化のメリットの出方が変わります。

中小規模（200床未満・有床診療所）：院内サーバーの維持負担とIT人材の確保が困難な層です。クラウド化のメリットが相対的に大きく、政府が標準型電子カルテ（導入版）を用意しているのもこの層です。

中規模（200〜400床）：部門システムの数がある程度あり、連携費用の比重が高くなります。サーバー費用の削減効果と連携費用の残存を天秤にかけた試算が必要です。

大規模（500床以上）：部門システムが多数あり、カスタマイズも蓄積しています。クラウド化しても連携・移行の費用が大きく残るため、費用面のメリットは相対的に小さくなる可能性があります。一方で、BCP・セキュリティ・IT人材の観点でのメリットは大きくなります。

—

6: ベンダーロックインは解消されるのか

6-1: データの出力・移行・連携仕様を契約前に確認する

日医調査で「ベンダー変更時の費用が法外である」という声が寄せられた背景には、データが各社の独自形式で保持されているという構造があります。

標準仕様（HL7 FHIR準拠）への準拠は、この構造を変える方向に働きます。データ形式が共通化されれば、理論上は移行の難度が下がります。

ただし、契約時に確認すべき点があります。

• 標準形式でのデータ出力に対応しているか：「標準仕様に準拠」と「標準形式で全データを出力できる」は別問題です
• 出力の範囲：診療録本体だけでなく、添付文書・画像・部門データも出力できるか
• 出力の費用：解約時のデータ出力が有償か無償か、金額はいくらか
• 出力のタイミングと期限：契約終了後、いつまでデータを取り出せるか
  

これらを契約書に明記させることが、将来のロックイン回避の実務です。導入時に確認しなければ、更新時には交渉力を失っています。

6-2: プラットフォーム依存と拡張性の評価項目

クラウドネイティブには、従来型とは異なるロックインのリスクがあります。

部門システムの抱き合わせ：同一ベンダーの部門システムを同じ画面で使える構成は利便性が高い反面、部門システムごとそのベンダーに依存することを意味します。将来、電子カルテだけを他社に変えるという選択が難しくなる可能性があります。

独自機能への依存：便利な独自機能を使い込むほど、それが標準仕様の範囲外であれば、乗り換え時に失われます。

評価すべき項目

• 他社製の部門システムとの連携実績があるか
• APIが公開されており、外部システムとの接続に対応しているか
• 標準規格の範囲でどこまでの機能が実現されているか
• 独自拡張部分がどの程度あり、それに依存する運用になっていないか
  

6-3: 買収・事業方針変更時に医療機関が備えるべきこと

クラウドサービスを利用する上で、見落とされがちなリスクがあります。

医療ITの業界では、企業の買収・統合・事業撤退が現実に起きています。オンプレミス型であれば、ベンダーの状況が変わっても院内のサーバーでシステムは動き続けます。しかしクラウドネイティブでは、サービスが停止すればシステムそのものが使えなくなります。

契約時に確認すべき事項は以下の通りです。

• サービス終了時の通知期間：何か月前に通知されるか
• サービス終了時のデータ返却：形式・期限・費用
• 事業譲渡時の契約承継：条件がどうなるか
• エスクロー（第三者預託）：ソースコードやデータの預託の仕組みがあるか
• 提供事業者の財務状況：上場企業であれば決算情報を確認できます
  

診療録は法令上の保存義務があります。「サービスが終わったのでデータがなくなりました」では済みません。この点は、クラウド調達における最重要の確認事項です。

6-4: 標準仕様準拠がロックインに与える影響の限界

標準仕様への準拠は、ロックイン解消に向けた前進ですが、万能ではありません。

第一に、標準仕様がカバーするのは主にデータ形式です。カスタマイズの再現、部門システムの再接続、職員の再教育といったコストは標準化とは別に残ります。

第二に、標準準拠製品が普及し、実際に乗り換え事例が積み上がるまでには時間がかかります。「理論上は移行できる」と「実際に妥当な費用で移行できた事例がある」の間には隔たりがあります。

第三に、標準仕様は最低限の共通部分を定めるものであり、各社が独自機能で差別化を図る構造自体は変わりません。

したがって、標準仕様準拠は選定時の必須条件ではあるが、それだけで安心できるものではないという理解が実務的です。

—

7: 病院の判断軸｜待つべきか、今動くべきか

ここが多くの病院にとって最も切実な問いです。判断軸を整理します。

7-1: 待てないケース（保守期限・OS終了が迫っている）

以下に該当する場合、2027年以降の選択肢を待つリスクのほうが大きくなります。

• 現行システムの保守期限が1年以内に到来する
• サーバーOSのサポート終了が迫っている
• 既に障害が頻発し、診療業務に支障が出ている
• セキュリティ上の脆弱性が指摘されている
  

医療機関へのランサムウェア攻撃は現実に発生しており、保守が切れたシステムを使い続けることは経営リスクです。「新しい選択肢を待つ」という判断が、診療停止のリスクを高めることになりかねません。

この場合は、現時点で選べる製品の中から、標準仕様への対応方針が明確なベンダーを選ぶことが現実的な対応になります。

7-2: 待つ価値があるケース（更新まで2〜3年ある）

以下に該当する場合は、2027年以降の市場を見てから判断する価値があります。

• 現行システムの保守期限まで2年以上の余裕がある
• 現状で運用上の重大な支障が出ていない
• 部門システムの更新時期も同時期に調整できる
  

2027年以降、クラウドネイティブ製品が複数のベンダーから出揃えば、比較検討の選択肢が広がります。また先行導入した病院の運用実績が蓄積され、カタログではわからない実態を確認できるようになります。

ただし「待つ」ことと「何もしない」ことは別です。待つ期間にこそ、次章で述べる準備を進めるべきです。

7-3: パイロット参加という選択肢のメリットとリスク

メドレーはMALLクラウドの提供開始に先立ち、パイロット版のユーザーとなる病院や診療所を募集するとしています。同様の募集は他社からも出てくる可能性があります。

メリット

• 導入費用の優遇を受けられる場合がある
• 自院の要望を製品仕様に反映できる可能性がある
• 先進的な取り組みとして対外的にアピールできる
  

リスク

• 開発中の製品であり、不具合や仕様変更が発生する可能性がある
• 検証への協力に院内の人的リソースを割く必要がある
• 想定していた機能が提供されない、または遅れる可能性がある
• 診療への影響が出た場合の責任範囲を明確にする必要がある
  

パイロット参加を検討する場合は、検証範囲の限定（一部部門から段階的に）、現行システムの並行稼働、責任範囲と補償の契約への明記が最低限の防御になります。院内にIT担当の体制がある病院向けの選択肢といえます。

—

8: 今から準備できること

「待つ」を選んだ病院も、更新が迫っている病院も、今日から着手できる準備があります。しかもこれらは、次回の調達コストを直接下げる効果を持ちます。

8-1: カスタマイズの棚卸しは今すぐ着手できる

日医調査でリプレイス費用が導入費用を上回った要因の一つが、蓄積されたカスタマイズの再現費用です。

やるべきこと：現行システムに実装されているカスタマイズを一覧化し、それぞれが実際に使われているかを各部門に確認します。

導入時に「必要」と言われて作った機能が、実際にはほとんど使われていないケースは珍しくありません。使われていない機能を次回に持ち込まなければ、その分の再現費用がまるごと削減できます。

この作業に外部費用は不要です。院内の情報システム担当と各部門で進められます。そして次回更新の要求仕様書の骨格にもなります。

8-2: 現行ベンダーへの確認事項（標準仕様対応・データ出力）

現行ベンダーに対して、以下を書面で確認しておくことを推奨します。

• 現行製品の標準仕様への対応予定と時期
• クラウドネイティブ製品の開発計画の有無
• 現行システムからの標準形式でのデータ出力の可否
• データ出力を依頼した場合の費用と期間
• 現行製品の保守提供期限
  

更新交渉が始まってから聞くのと、平時に聞くのとでは、得られる回答の性質が変わります。交渉のテーブルに着く前に情報を持っておくことが、交渉力になります。

8-3: 2027年以降の比較に備えた要求仕様の整理

複数ベンダーを同じ土俵で比較するには、病院側から統一の要求仕様書（RFP）を提示する必要があります。各社が自由なフォーマットで提案してくると、価格の差が何の差なのかわかりません。

要求仕様書に含めるべき項目

• 必要機能の一覧（8-1の棚卸し結果を反映）
• 接続する部門システムの一覧とその接続要件
• 想定端末数・利用者数
• データ移行の範囲と条件
• 標準仕様への対応状況
• データ出力・解約時の条件
• SLA（稼働率・障害時対応）の要求水準
• 見積もりの記載粒度（項目別内訳の指定）
  

これを整えておけば、2027年以降に選択肢が増えたときに、すぐ比較検討に入れます。準備している病院とそうでない病院では、選定にかかる時間も、得られる条件も変わります。

—

9: クラウドネイティブ時代の調達の考え方

9-1: 「買う」から「使い続ける」へ｜評価軸の転換

オンプレミス型の調達は「買い物」でした。仕様を決め、価格を交渉し、納品されれば所有物になります。

クラウドネイティブの調達は「継続的な契約関係」です。所有するのではなく、サービスを使い続けます。この違いは、評価軸を根本的に変えます。

従来の評価軸：価格、機能、納期、保守体制

クラウド時代に加わる評価軸：事業者の継続性、SLAの水準、データの可搬性、契約解除の条件、値上げ時の取り決め

特に「値上げ時の取り決め」は見落とされがちです。月額課金モデルでは、契約更新のたびに料金が改定される可能性があります。値上げの上限や事前通知の条件を契約時に確認しておくことが、長期の予算管理につながります。

9-2: 契約時に確認すべき新しい項目

クラウドネイティブ電子カルテの契約で、従来にはなかった確認項目を整理します。

項目	確認内容
SLA（稼働率）	保証稼働率、未達時の補償内容
障害時対応	連絡体制、復旧目標時間、代替手段
データ保管場所	国内か国外か、データセンターの所在
データ持ち出し	形式・費用・期限・対象範囲
サービス終了時	通知期間、データ返却の条件
事業譲渡時	契約承継の条件
料金改定	改定の条件、上限、事前通知期間
セキュリティ	認証取得状況、監査報告の提供有無

これらは価格交渉ほど注目されませんが、10年使うシステムでは価格差以上の影響を持ちます。

9-3: デモ・資料請求で確認したい連携・管理・安全性

製品比較の実務では、カタログではわからない部分を確認することが重要です。

デモで確認すべきこと

• 医師・看護師・医事課それぞれの視点で実際に操作する
• 自院で実際に使っている帳票を題材に、出力を試す
• 部門システムとの連携画面を実機で見る
• AI機能は、自院の文書を題材に精度を確認する
• ネットワークが切断された場合の挙動を確認する
  

資料で確認すべきこと

• 自院と同規模・同機能の病院での導入実績
• 稼働実績のあるレセコン・部門システムの一覧
• セキュリティ認証の取得状況
• 過去の障害発生履歴と対応内容
  

特に「ネットワーク切断時の挙動」は、クラウドネイティブ特有の確認事項です。完全に使えなくなるのか、参照だけは可能なのか、復旧後のデータ同期はどうなるのか。診療継続計画（BCP）の設計に直結します。

—

10: まとめ｜2027年は選択肢が増える年、判断するのは病院

2026年夏の2つの発表は、病院の電子カルテが転換点にあることを示しています。

日医調査は、現在の費用構造が持続可能でないことを数字で示しました。200床規模で導入2.5億円、10年で約4.8億円、しかもリプレイスは導入費を上回る。「ベンダー変更時の費用が法外」という声は、競争が働いていない市場の実態を表しています。

クラウドネイティブ電子カルテと標準仕様の整備は、この構造への処方箋として期待されています。2027年以降、選択肢は確実に増えるでしょう。

ただし本記事で見てきた通り、クラウド化ですべての費用が下がるわけではありません。 サーバー関連費用は減りますが、ネットワーク投資は増え、部門システム連携・データ移行・職員教育の費用は残ります。標準仕様準拠もロックイン解消への前進ではあるものの、それだけで安心できるものではありません。

重要なのは、選択肢が増えたときに適切に比較・判断できる状態を作っておくことです。カスタマイズの棚卸し、現行ベンダーへの確認、要求仕様書の整理。これらは今日から着手でき、外部費用もかかりません。

そして、この準備をしている病院とそうでない病院では、2027年以降に得られる条件が変わります。市場が変わるのを待つのではなく、変わったときに動ける準備をしておく。それが、費用構造の転換期における最も現実的な調達戦略です。

—

よくある質問（FAQ）

Q1. クラウドネイティブ電子カルテとは何ですか？

A. 厚生労働省が示す要件では、医療機関内のサーバーでの運用を前提とせず、情報セキュリティ基準を満たしたパブリッククラウド環境で稼働する電子カルテを指します。従来の「クラウド型」が院内サーバーを残す構成が多かったのに対し、最初からクラウド前提で設計されている点が異なります。

Q2. クラウドにすれば電子カルテは安くなりますか？

A. 一概には言えません。院内サーバーのハードウェア費用・更新費用・設備費用は減りますが、クライアント端末費用、ネットワーク機器・回線費用、部門システム連携費用、データ移行費用、職員教育費用は残ります。またネットワークの可用性確保のための投資はむしろ増える可能性があります。5〜10年の総額で試算して比較してください。

Q3. 2027年まで待ったほうがいいですか？

A. 現行システムの保守期限次第です。保守期限が1年以内に迫っている、既に障害が頻発している、セキュリティ上の懸念があるといった場合は、待つリスクのほうが大きくなります。更新まで2年以上の余裕があれば、選択肢が増えてから比較する価値はあります。ただし待つ期間にカスタマイズの棚卸しや要求仕様の整理を進めておくことが前提です。

Q4. 標準仕様に準拠していればベンダーを変えやすくなりますか？

A. 前進ではありますが万能ではありません。標準仕様がカバーするのは主にデータ形式であり、カスタマイズの再現・部門システムの再接続・職員の再教育といった費用は残ります。契約時に「標準形式での全データ出力が可能か」「出力の費用と期限」を書面で確認しておくことが実務的な対策になります。

Q5. クラウドサービスの提供事業者が事業を撤退したらどうなりますか？

A. これはクラウド調達における最重要の確認事項です。オンプレミスと異なり、サービスが停止すればシステムが使えなくなります。契約時に、サービス終了時の通知期間、データ返却の形式・期限・費用、事業譲渡時の契約承継条件を必ず確認してください。診療録には法令上の保存義務があるため、データを確実に取り戻せる条件の明記が不可欠です。

—

本記事は、日本医師会が2026年7月15日に公表した実態調査、および2026年8月25日に発表されたメドレーのクラウドネイティブ電子カルテ開発に関する公表内容をもとに、調達実務の観点から構成したものです。制度・製品の詳細は各機関・各社の最新の公表資料をご確認ください。