Amazon Web Services ブログ

第 1 回: 電子カルテベンダーのためのガバメントクラウド入門 — ガバクラ・公共 SaaS を理解する

みなさん、こんにちは。AWS ジャパン 執行役員 パブリックセクター技術統括本部長の瀧澤です。

電子カルテベンダーの皆様が、ガバメントクラウドと公共 SaaS を正しく理解し、クラウドネイティブな電子カルテへの第一歩を具体化するためのブログシリーズを紹介します。なお、この投稿は、同じチームで、ヘルスケアソリューションアーキテクトの松浦さんと一緒に書いています。よろしくお願いします。

電子カルテを取り巻く環境は、大きく変わろうとしています。厚生労働省とデジタル庁は 2026 年 3 月 31 日に、「中小病院向け電子カルテ及びレセプトコンピュータ標準仕様書（基本要件）1.0 版」と「医科診療所向け電子カルテ及びレセプトコンピュータ標準仕様書（基本要件）1.0 版」を公開しました。その背景・目的では、ガバメントクラウド対応が可能となるマルチテナント方式、いわゆる SaaS（Software as a Service）型のクラウドサービスに加え、標準 API、データ引き継ぎが可能な互換性などが示されています。また 2026 年 7 月 21 日に閣議決定された「日本成長戦略」では、「クラウドネイティブに最適化された医療ＤＸ基盤」の目標として、2030 年までに電子カルテ普及率約 100%、大病院向けクラウドネイティブ型製品の提供を目指すことが示されました。あわせて、電子カルテ未導入の 200 床以上の病院（療養病床等が中心の病院を除く）については、2028 年度までに普及率 100% を目指すことも示されています。主な施策としては、認証されたクラウドネイティブ型電子カルテ製品の普及を促進することが挙げられています。同日に日本成長戦略本部が決定した官民投資ロードマップでは、この分野の投資額を 2040 年度までで 5.2 兆円と想定しています。

これまで電子カルテのクラウド化についてお客様からお話を伺う中で、「ガバメントクラウドとは政府専用の特殊なクラウドなのか」「ガバメントクラウドや公共 SaaS の利用は必須なのか」「クラウドを選べばセキュリティやガイドライン対応は自動的に完了するのか」といったご質問をいただいてきました。

そこで本シリーズでは、電子カルテベンダーの開発責任者とアーキテクトの皆様に向けて、公開済みの政府資料と AWS のベストプラクティスを基に、クラウドネイティブ化を検討する際の考え方を解説します。第 1 回では、ガバメントクラウドと公共 SaaS の位置付け、2026 年 10 月に公開された標準仕様の認証制度の要点、医療分野にとっての意味、そして AWS の責任共有モデルを整理します。そのうえで、今から着手できるアクションを紹介します。

本記事の前提
本記事は 2026 年 11 月 10 日時点で公開されている情報を基にしています。制度、手続き、標準仕様は更新される可能性があるため、実際の検討では必ず各省庁およびデジタル庁の GCAS ガイド（ガバメントクラウドの利用者向けガイド）の最新版を確認してください。

ガバメントクラウドは「政府共通のクラウドサービスの利用環境」

デジタル庁は、ガバメントクラウドを「政府共通のクラウドサービスの利用環境」と説明しています。その目的は、クラウドサービスの利点を最大限に活用し、迅速、柔軟、セキュアかつコスト効率の高いシステムを構築可能とするとともに、利用者にとって利便性の高いサービスをいち早く提供し、改善していくことです。

ガバメントクラウドは、政府専用に新しく作られたクラウドではありません。デジタル庁が選定したパブリッククラウド（ガバメントクラウド対象クラウドサービス）を、統一されたガバナンスのもとで利用する環境です。

ここで重要なのは、ガバメントクラウドを単なるインフラストラクチャの設置場所として捉えないことです。デジタル庁の説明では、次のような価値が挙げられています。

  • アプリケーション開発者の要求に応じた、柔軟かつ迅速なインフラストラクチャの提供
  • クラウドサービスが提供するセキュリティ、可用性、スケーラビリティの活用
  • ガバナンス機能とテンプレートによる、ベストプラクティスに基づく品質の底上げと標準化
  • セキュリティ、ネットワーク、運用監視などの検討省力化と設定自動化
  • マネージドサービスの利用と構築・運用の自動化によるインフラストラクチャコストの削減、コストの可視化・透明化

したがって、既存システムを仮想マシンへそのまま移すことだけが目標ではありません。標準化、自動化、マネージドサービスを活用し、変更へ継続的に対応できる運用モデルを作ることが重要です。これはガバメントクラウドを利用するかどうかにかかわらず、電子カルテをクラウドネイティブ化する際に共通する考え方です。

電子カルテSaaS

よくある誤解を整理する

誤解 1: ガバメントクラウドを使えば、アプリケーションの要件適合が自動的に保証される

ガバメントクラウドの基盤が満たす要件と、その上で電子カルテベンダーが設計・実装・運用するアプリケーションの要件は同一ではありません。基盤の利用によって継承できる統制がある一方、データ管理、アクセス制御、テナント分離、アプリケーションの脆弱性対策とパッチ適用、ログの確認など、サービス提供者が担うべき責任は残ります。

誤解 2: 公共分野向けである以上、医療機関ごとにすべてのリソースを分離しなければならない

分離要件を満たす方法は 1 つではありません。専用環境を用意するサイロモデル、リソースを共有しながら論理的に分離するプールモデル、両者を組み合わせるブリッジモデルなどがあります。どの方式が適切かは、データ、性能、障害影響範囲、運用、コスト、適用される要件を踏まえて判断します。詳しくは第 2 回で解説します。

誤解 3: クラウドネイティブとは、コンテナやサーバーレスを採用することである

これらは有力な選択肢ですが、特定の技術を採用すること自体が目的ではありません。変更を小さく安全に届けられること、構築と運用を自動化できること、システムの状態を観測できること、障害から回復できることなど、提供・運用の能力まで含めて考える必要があります。公共 SaaS に求められるモダン化について、GCAS ガイドの公共 SaaS の共通要件にかかる技術方針は「システム運用管理の省力化や自動化を含むモダン化が求められる」とし、参照先としてガバメントクラウドにおけるモダン化の定義を挙げています。採用するサービスは、特定のサービス名からではなく、これらの記載と自社が担える運用責任の範囲から判断することが大切です。

誤解 4: ガバメントクラウドでも、AWS と直接契約して利用する

ガバメントクラウドでは、デジタル庁がクラウドサービス事業者と契約し、利用者はデジタル庁が用意した環境を利用します。AWS と直接契約して AWS アカウントを使う場合とは、契約や費用負担の構造が異なります。公共 SaaS として提供する場合は、SaaS 事業者がデジタル庁とガバメントクラウド利用権付与兼債務引受契約を締結し、ガバメントクラウドの利用料は SaaS 事業者が負担してデジタル庁へ納付する、とされています。詳細な手続きや利用料の扱いについては、GCAS ガイドの公共 SaaS の手続きで確認してください。

公共 SaaS と標準仕様書

GCAS ガイドでは、公共 SaaS を、ガバメントクラウドを利用環境として、制度官庁等が標準仕様等を定める公共・準公共分野の情報システムを SaaS の形態で提供するもの、と説明しています。利用者ごとに稼働環境を個別に構築せず、共通化された環境を活用することで、システム資源や運用管理の負担軽減が期待されるとし、アプリケーションのモダン化も強く推奨しています。提供に向けた手続きや共通要件にかかる技術方針も公開されています。

電子カルテについては、標準仕様書（基本要件）が必須要件を項目ごとに定めており、公共 SaaS を利用する場合の扱いも示しています。

  • 2.1.2 非機能要件（中小病院向け p.16–18／医科診療所向け p.14–16。ページ番号は標準仕様書に印字されたものです）: 第三者認証の取得やペネトレーションテスト・脆弱性診断などのセキュリティ対策
  • 2.1.3 アーキテクチャ（中小病院向け p.19–20／医科診療所向け p.17–18）: ガバメントクラウド対象クラウドサービス（ガバメントクラウドの対象として選定されたパブリッククラウド）上で原則として稼働するマルチテナント方式の SaaS（ソースコード共通、カスタマイズ不可）であること（院内機器との中継など一部の例外があります）、「ガバメントクラウドにおけるモダン化の定義」への合致

公共 SaaS を利用している場合は、アーキテクチャの要件と、セキュリティのうち第三者認証・ペネトレーションテスト・脆弱性診断に適合しているものとみなされます。ただし、テストや診断が不要になるわけではありません。GCAS ガイドの公共 SaaS の共通要件にかかる技術方針では、サービス開始前の確認として、SOC2 等の監査、脆弱性検査、ペネトレーションテスト等の実施計画と結果をデジタル庁と共有することを求めています。公共 SaaS を利用しない場合は、各項目の要件に個別に適合する必要があります。標準仕様への適合を確認する認証制度については、次の章で説明します。最新の要件は、必ず原本で確認してください。

標準仕様の認証制度

厚生労働省とデジタル庁は 2026 年 10 月 16 日、標準仕様への適合状況を評価して要件を満たす電子カルテ製品を認証する、認証制度要綱を公表しました。あわせて、厚生労働省が FAQ を公開しています。要綱は 2026 年 11 月 1 日に施行され、標準仕様のページによると、標準仕様 第 1.0 版に基づく認証の申請は同日から 2027 年 10 月 31 日まで受け付けられます。なお、FAQ は、認証を取得していない電子カルテの販売を妨げるものではないとしています。主な内容は、次の資料に書かれています。

  • 標準仕様のページ「認証制度」: 制度の目的と概要、主な評価項目、認証取得までの流れ、スケジュール、申請先
  • 認証制度要綱 第 1.0 版
    • 本文（PDF の 3–9 ページ）: 認証の対象と有効期間（第 4 条）、認証要件と、ガバメントクラウドを利用していない製品に求められるガバメントクラウド利用に関する事前相談（第 5 条・第 6 条。Q&A では、ガバメントクラウドを利用する製品は公共 SaaS として提供されるものとされています）、審査・公開・更新の手続（第 7 条〜第 9 条）、免責事項（第 14 条）
    • 別表 1「認証制度の評価項目および評価指標」（PDF の 12–13 ページ）: 評価項目ごとの評価指標（公共 SaaS の場合の扱いを含む）、標準仕様書の該当箇所、更新時に必ず確認する項目
  • 電子カルテ標準仕様および認証制度に関する Q&A: 医療機関向けと事業者向けの質問と回答

これらの資料に書かれた内容のうち、次の 3 点は製品の開発・運用計画に直接影響するため、早めに確認しておくことをおすすめします（いずれも第 1.0 版の時点の内容です）。セキュリティに関する 2 点は、公共 SaaS を利用して提供している場合、前の章で触れたとおり適合しているものとみなされます。稼働実績は、公共 SaaS かどうかで求められる内容が変わります。

  • ペネトレーションテストと脆弱性診断 — 原則として年 1 回以上の実施が求められ、CVSS スコアが中（Medium）以上の脆弱性は原則として対策します。
  • ISMAP または ISMS 認証 — 第 1.0 版に基づく初回の申請では、経過措置として未取得でも申請できます。ただし、標準仕様の認証を受けた事業者は 2027 年 6 月 30 日までに取得する必要があり、申請時に取得計画と取得見込み時期を提出します。
  • 稼働実績 — 中小病院向けは 30 施設以上、医科診療所向けは 200 施設以上で稼働し、その状態が直近 1 年間続いていることが求められます。第 1.0 版の初回審査に限り、直近 3 か月間に読み替えられます。公共 SaaS（要綱の表記では「ガバメントクラウドを利用してシステム構築を行っている場合」）を利用して提供している場合は、この要件は適用されず、代わりに性能、障害復旧、業務・運用に関する検証結果の資料を提出します。

詳細や最新の内容は、必ず要綱と FAQ の原本で確認してください。

医療分野で SaaS 化が意味すること

ここでは、公共 SaaS に限らず、電子カルテを SaaS として提供すること全般の意味を整理します。中小病院向け標準仕様書（基本要件）は、現在の電子カルテの課題として、医療機関ごとのカスタマイズやオンプレミス型・シングルテナントの構築による導入・保守・改修コストの増大、独自のデータ引き継ぎ規格によるベンダーロックインの傾向、セキュリティ確保に医療機関側の多大な労力が必要で端末にセキュリティパッチを適用できない場合があることなどを挙げています。標準仕様書はこうした課題に対し、マルチテナント方式のクラウド・ネイティブ型による「所有」から「共同利用」への転換、サーバ側での一括更新による迅速かつ継続的なセキュリティパッチの適用、データ引き継ぎ規格の標準化といった方向性を示しています。官民投資ロードマップでも、現行のオンプレミス型システムは現地の改修費用や人的リソースの面で高コストになりやすいことが課題とされています。

なお、パッチを適用しにくい背景には、医療機関ごとに異なる構成や個別カスタマイズ、診療への影響を避けるために更新を控えたいという事情など、ベンダーと医療機関の双方の要因があるというのが、お客様のお話を伺う中での私たちの理解です（標準仕様書の記述ではありません）。

標準仕様書が挙げる課題とこうした背景において、電子カルテベンダーの設計課題として捉えると、医療機関側のサーバー運用やパッチ適用の負担を減らしつつ、医療機関の担当者がサービスの稼働状況やセキュリティ対策を確認・監査できる透明性、更新とパッチを全テナントへ計画的に届ける仕組み、院内ネットワークや閉域網との接続方式、24 時間 365 日の診療を止めない更新と障害対応、機微性の高い医療情報の保護、ベンダー変更時にもデータを引き継げる設計が重要になります。

SaaS 化の意義は、単に複数の医療機関へ同じアプリケーションを提供できることだけではありません。製品と運用を一体として標準化することで、次のような改善につなげられます。

  • 変更を一貫して届ける — セキュリティ修正や機能改善を、医療機関ごとの個別作業に依存せず展開しやすくなります。
  • 運用品質を揃える — 監視、バックアップ、構成管理、監査ログなどを共通の仕組みとして設計できます。
  • 利用状況を把握する — テナント単位の性能、可用性、利用量、コストを観測し、サービス改善へつなげられます。
  • 導入を再現可能にする — Infrastructure as Code（IaC）と自動化により、新しい医療機関のオンボーディングを標準化できます。
  • 製品開発へ注力する — マネージドサービスを適切に選択することで、基盤運用の一部を AWS に委ね、電子カルテ固有の価値へ開発リソースを振り向けられます。

ただし、SaaS 化は「共有すればよい」という設計ではありません。医療情報を扱うシステムでは、テナント間の分離、認証・認可、暗号化、監査可能性、バックアップと復旧、データ移行性などを、製品のライフサイクル全体で設計する必要があります。

AWS で SaaS を実現する際に活用できるもの

Amazon Web Services（AWS）は、デジタル庁が公表しているガバメントクラウド対象クラウドサービスの一つです。AWS 上で SaaS を設計する際には、次のような公開リソースを活用できます。いずれも設計判断を代替するものではなく、自社製品の要件に照らして取捨選択することが前提です。

  • マネージドサービス — 責任共有モデルでは、Amazon Simple Storage Service（Amazon S3）や Amazon DynamoDB のような抽象化されたサービスについて、AWS がインフラストラクチャレイヤー、オペレーティングシステム、プラットフォームを運用すると説明しています。採用するサービスによって、ベンダーが担うパッチ適用の範囲を小さくできます。
  • 設計レビューの枠組み — AWS Well-Architected Framework と、マルチテナント設計の観点をまとめた SaaS レンズで、トレードオフを確認できます。
  • リファレンス実装 — AWS SaaS Factory が公開するサーバーレスや Amazon Elastic Kubernetes Service（Amazon EKS）のリファレンスアーキテクチャで、テナント管理やオンボーディングの実装例を参照できます。これらは参考実装であり、本番利用にあたっては自社でのセキュリティレビューが必要です。

責任共有モデルを三者の会話に落とし込む

AWS では、セキュリティとコンプライアンスを AWS とお客様の責任共有モデルとして整理しています。AWS は、クラウドサービスを実行するハードウェア、ソフトウェア、ネットワーキング、施設など、「クラウドのセキュリティ」に責任を持ちます。お客様は、選択したサービスに応じて、データ、ID と権限、設定、ゲスト OS やアプリケーションのパッチ適用など、「クラウドにおけるセキュリティ」に責任を持ちます。

電子カルテ SaaS では、さらにサービス提供者である電子カルテベンダーと、サービスを利用する医療機関等の間でも役割分担が生じます。そのため、実務では「AWS とお客様」という二者の整理を、次の三者の作業へ具体化することが重要です。

主体 主な責任の例
AWS クラウドを稼働させる物理インフラストラクチャ、ハードウェア、マネージドサービスの基盤部分の保護と運用
電子カルテベンダー アプリケーション設計、テナント分離、ID・権限設計、データ保護、構成、脆弱性管理とパッチ適用、端末側の OS・ブラウザ更新との互換性検証、ログと監視、バックアップ・復旧、変更管理
医療機関等 利用者管理、端末や院内ネットワークの管理、業務手順、サービス選定・契約、委託先との責任分担の確認

電子カルテにおける責任共有モデルとの関係性

この図表は一般的な整理であり、実際の責任は採用する AWS サービス、提供方式、契約、適用される法令やガイドラインによって異なります。重要なのは、責任を曖昧なままにしないことです。「誰が、何を、どの頻度で実施し、どの証跡を残すか」まで合意し、設計書、運用手順、契約とサービスレベルの定義へ反映します。なお、医療機関に対しては、AWS が担う範囲を含むインフラの管理・運用も、サービス提供者である電子カルテベンダーの責任範囲として位置付けられます。

マネージドサービスを選ぶほど AWS が運用する範囲は広がりますが、データの分類、アクセス権、アプリケーションロジック、アプリケーションのパッチ適用と脆弱性対策は、引き続き電子カルテベンダーの責任です。認証制度要綱の別表 1 でも、SaaS 型の評価指標として、医療機関とサービス提供者の責任範囲を明確に区分すること、利用者の責任範囲は「データ」の管理に限定し、アプリケーション、OS、インフラ（ハードウェア、ネットワーク、施設等）の管理・運用はサービス提供者の責任範囲とすることが挙げられています。どのサービスを選び、残る責任をどう日常の開発・運用に組み込むかは、シリーズ後半で取り上げます。

今から始めるための 6 つのアクション

制度や認証の詳細が更新されるのを待つのではなく、目指すサービスの姿を描いたうえで、公開済みの情報と一般的なクラウドのベストプラクティスに基づき、次の準備を進められます。

1. 経営層や事業部門と一緒に、目指すサービスの姿を描く

現行製品の構成や制約から出発すると、クラウド化は「今のシステムをどう移すか」の議論になりがちです。まず経営層や事業部門、営業、サポートのメンバーも交え、SaaS として医療機関にどのような価値を届けたいかを、料金体系、導入期間、サポートの形、機能改善の頻度などを含めて描きます。技術的な制約との折り合いはその後で検討し、目指す姿と現状の差分を以降のアクションの優先順位づけに使います。

2. 一次資料を継続的にキャッチアップする

厚生労働省・デジタル庁の電子カルテ及びレセプトコンピュータ標準仕様（基本要件）と認証制度要綱・FAQ、デジタル庁のガバメントクラウド資料、GCAS ガイドを参照元として登録し、更新確認の担当と頻度を決めます。認証は毎年更新され、更新時には改訂後の標準仕様への対応も確認されるため、改訂を追う体制は認証を維持するための前提にもなります。

主な一次資料は、電子カルテの機能要件・非機能要件を定める標準仕様書、ガバメントクラウドの利用と公共 SaaS の要件・手続きを示す GCAS ガイド、そして医療情報の安全管理について定める厚生労働省の「医療情報システムの安全管理に関するガイドライン」と総務省・経済産業省の「医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン」（いわゆる 3 省 2 ガイドライン）です。ガイドラインの詳細はシリーズ後半で取り上げます。

3. 現行製品の責任と手作業を棚卸しする

OS やミドルウェアの更新、証明書更新、バックアップ確認、監視、障害対応、医療機関追加、医療機関ごとのカスタマイズなど、現在の作業を一覧化します。そのうえで、AWS のマネージドサービスや自動化へ移せる作業と、ベンダーが保持すべき責任を分けます。

4. テナント境界を先に定義する

「1 テナントは 1 医療法人か、1 医療機関か」「利用者、患者、部門、外部連携先をどのテナントへひも付けるか」を定義します。この判断は、ID、データ、ネットワーク、監査、コストのすべてに影響します。

5. 小さな対象で自動化を実証する

本番全体を一度に作り直すのではなく、非本番環境や限定した機能を対象に、IaC、継続的デリバリー、監視、バックアップ・復旧、セキュリティテストを一連の流れとして実証します。成功条件には、構築時間だけでなく、変更の再現性、パッチを全テナントへ展開するまでの時間、復旧時間も含めます。こうした検証の記録は、認証審査で求められる資料（たとえば公共 SaaS の場合の性能、障害復旧、業務・運用に関する検証結果）の土台にもなります。

6. 早い段階でアーキテクチャをレビューする

テナント分離やデータモデルを実装した後に変更することは容易ではありません。方式を固定する前に、AWS Well-Architected Framework や SaaS レンズを使ってトレードオフを可視化してください。

まとめ

ガバメントクラウドは、政府共通のクラウドサービス利用環境として、セキュリティ、可用性、スケーラビリティ、標準化、自動化を活用し、公共サービスを継続的に改善するための基盤です。公共 SaaS は、その環境で、標準仕様等に基づく情報システムを、利用者ごとに個別構築せず共通化された環境から SaaS として提供する仕組みです。

電子カルテベンダーにとって重要なのは、特定の制度対応だけをゴールにするのではなく、安全に変更でき、観測でき、回復できる製品と運用を作ることです。それは医療機関ごとの個別構築・個別保守やパッチ適用の負担を減らすことにもつながります。毎年の更新審査がある標準仕様の認証制度も、一度の適合ではなく、こうした運用を続けられるかを確かめる仕組みと捉えることができます。その第一歩は、経営層や事業部門とともに目指すサービスの姿を描き、ガバメントクラウドを正しく理解したうえで、AWS、電子カルテベンダー、医療機関等の責任を具体的な作業へ落とし込むことです。

次回は「電子カルテ SaaS のはじめ方 — AWS で考えるマルチテナント設計の選択肢」と題し、最初に決めるべきテナント境界、サイロ・プール・ブリッジの各テナント分離モデル、そしてオンボーディング、監視、課金などを担うコントロールプレーンの設計を解説します。

ガバメントクラウドや電子カルテ SaaS の構想・設計については、AWS の担当営業またはソリューションアーキテクトへご相談ください。

執行役員 パブリックセクター技術統括本部長
瀧澤 与一

参考資料