病院CMSの選び方｜更新権限・アクセシビリティ・セキュリティの実務

病院CMSは、製品名ではなく「更新を安全に続けられる要件」で選ぶ

病院のWebサイトには、診療科、外来・入院案内、地域医療連携、採用、広報、災害時のお知らせなど、更新元も緊急度も異なる情報が集まります。CMS選定では、画面の使いやすさだけを比べるのではなく、どの情報を誰が作成し、誰が確認し、どの条件で公開するかを先に定義します。機能の多さより、病院の責任分担と更新頻度に合うことが判断の出発点です。

最初に対象コンテンツと責任部署を棚卸しする

現行サイトのURL、ページ名、更新元、確認者、更新頻度、公開期限、外部システムとの関係を一覧にします。診療時間のように正確さと即時性が重要な情報、医療内容の確認が必要な情報、採用や広報など主管部署が異なる情報を同じ承認経路に押し込むと、通常更新が滞る一方で緊急更新の統制も曖昧になります。棚卸しは移行対象を数えるためだけでなく、必要な権限・承認・履歴を具体化する作業です。

このガイドでは、特定製品のランキングや価格比較は扱いません。クリニック向けのWordPress・Wix・STUDIOの違いはクリニック向けCMS比較、病院サイト全体の検索・情報設計は病院のSEO対策ガイドに役割を分けます。本記事は、病院CMSを調達・移行・運用する際の要件と受入判断に集中します。

必須・望ましい・将来対応に分けて評価する

要件はすべてを同じ優先度にせず、公開事故や業務停止を避けるための必須条件、運用品質を高める望ましい条件、将来の拡張条件に分けます。候補CMSの説明資料だけで判定せず、デモ環境や検証環境で担当者が実際の更新を再現し、操作ログ、権限の境界、差し戻し、復元まで確認します。採点表には可否だけでなく、制約、代替手段、運用で補う事項、確認した証拠を残してください。

公開情報と患者情報を分け、CMSが扱う範囲を明確にする

一般公開ページを管理するCMSと、予約、問い合わせ、問診、医療情報システムは同じものとは限りません。サイト上にフォームがある場合でも、CMSが入力内容を保存するのか、別サービスへ引き渡すのか、通知メールに何が含まれるのかで責任範囲は変わります。見た目が一体でも、データの流れ、保存場所、管理者、保持期間、委託先を分けて図示します。

医療情報を扱う場合だけ追加の安全管理要件を適用する

厚生労働省「医療情報システムの安全管理に関するガイドライン 第7.0版」は、医療情報システムの取扱いに関する現行の確認先です。一般公開コンテンツだけを管理するCMSへ一律に同じ要件を当てはめるのではなく、フォーム、予約連携、認証領域、外部サービスなどで医療情報や患者情報を取り扱うかを確認し、該当する範囲に必要な管理を設計します。

入力項目は「あると便利」ではなく、利用目的に必要かで決めます。氏名や連絡先を含む情報がCMS、解析ツール、メール、外部連携先へ重複保存されないかを確認します。公開ページの編集者が問い合わせ内容まで閲覧できる権限設計も避ける必要があります。コンテンツ管理と個人情報処理の境界を明確にすることで、委託先の責任分担や障害時の連絡先も整理できます。

正本と同期方法を項目ごとに決める

診療時間、担当医、外来受付、面会、地域連携窓口などは、別の業務システムや院内規程が正本になっている場合があります。CMSへ手入力するのか、API等で同期するのか、変更通知を受けて担当者が反映するのかを項目ごとに決めます。自動同期は転記を減らせますが、誤データも自動反映し得ます。同期停止や不整合を検知し、必要なら安全な表示へ切り替えられることまで要件に含めます。

アクセシビリティを調達仕様と受入試験へ組み込む

アクセシビリティは、公開後に配色や文字サイズだけを調整する作業ではありません。テンプレート、見出し構造、キーボード操作、画像の代替テキスト、フォームのラベル、エラー表示、PDFへの導線など、CMSが生成するマークアップと編集画面の制約に関わります。デジタル庁のウェブアクセシビリティ導入ガイドブックを参考に、調達担当者と制作・運用担当者が共通の確認項目を持ちます。

編集者が崩しにくいテンプレートを選ぶ

自由な装飾機能が多くても、担当者ごとに見出しや色、表の作り方が変われば、読み上げ順や一貫性が崩れます。見出し階層、リンク文言、代替テキスト、表の見出し、動画の代替情報を編集画面で案内できるか、必要な入力を省略したとき警告できるかを確認します。再利用部品を用意し、担当者が正しい構造を選びやすいことが運用品質につながります。

自動検査と人による操作確認を分ける

自動検査は構文上の問題を効率よく見つけられますが、リンク文言の分かりやすさや読み上げ順、操作時の理解しやすさをすべて判断できるわけではありません。代表ページと主要部品を選び、PCとスマートフォン、キーボード操作、拡大、読み上げなどの確認方法を受入計画に書きます。公開後もテンプレート更新や新しい部品の追加時に同じ試験を繰り返せることが重要です。

適合レベルや試験対象を掲げる場合は、実際の試験範囲、実施日、例外、改善計画と整合させます。「対応済み」という短い表示だけで完成とせず、利用者が問題を知らせられる窓口と改善の責任者も決めておきます。

CMS本体だけでなく、運用・委託・周辺機能まで安全性を確認する

CMSの安全性は、製品名だけで決まりません。更新提供の方法、サポート期間、利用中の拡張機能、ホスティング、認証、権限管理、監視、バックアップ、委託先の作業方法を一つの運用として確認します。IPA「安全なウェブサイトの作り方」は、アクセス制御の欠落や入力処理など、Webアプリケーションで確認すべき脆弱性と対策の整理に利用できます。

更新停止を前提にしない保守契約を確認する

CMS、テーマ、拡張機能、サーバー環境の更新責任者と実施期限を決めます。更新前の検証環境、互換性確認、緊急修正の適用、失敗時の復元、サポート終了時の移行を契約と運用へ含めます。ベンダーが対応する範囲と病院側が行う範囲を曖昧にせず、脆弱性情報を誰が受け取り、どの基準で優先度を決めるかを確認します。

認証・セッション・監査ログを受入環境で試す

管理画面の多要素認証、パスワード方針、ログイン制限、セッション終了、権限別の操作制限、重要操作の記録を確認します。ログは保存するだけでなく、異常なログインや権限変更、公開・削除を誰が確認するかまで決めます。委託先の保守アクセスは必要な期間と範囲に限定し、終了時に無効化できることを確かめます。

IPAの安全なウェブサイト運用管理のチェックポイントも使い、担当者、アカウント、バックアップ、監視、脆弱性診断などを継続的に見直します。導入時の診断結果だけを恒久的な安全保証として扱わず、構成変更や更新後にも確認する計画を持ちます。

予約・フォーム・院内システムとの連携境界を評価する

CMSから外部サービスへつなぐ場合、リンク、埋め込み、API連携、データ同期のどの方式かでリスクと保守範囲が変わります。予約システムの障害がCMS全体へ波及しないか、外部スクリプトが表示性能や入力情報に影響しないか、サービス終了時に切り離せるかを確認します。連携先の名称だけでなく、送受信する項目、認証方式、エラー時の表示、責任分担を図にします。

フォームは送信後まで通して検証する

入力欄、同意表示、確認画面、送信先、保存、通知、削除までを一つの処理として確認します。エラー時に入力内容が意図せずURLや解析ログへ含まれないか、通知メールだけに情報が残らないかを点検します。迷惑送信対策を入れる場合も、利用者が操作できるか、代替手段があるかを確認してください。

連携先の変更をCMSの変更管理へ含める

外部サービスの仕様やドメイン、埋め込みコードが変わると、リンク切れや表示不具合が起こり得ます。連携一覧に契約担当、技術担当、更新通知の受け手、試験ページ、解除手順を記録します。個別連携を導入するたびに、アクセシビリティ、セキュリティ、プライバシー、表示性能、障害時案内を再評価できる運用が必要です。

URL・本文・ファイル・検索設定を一体で移行する

CMS移行では、画面上の文章だけでなく、URL、canonical、robots、リダイレクト、画像・PDF、構造化データ、内部リンク、更新履歴、フォーム、計測設定を対象に含めます。Google Search Centralのクロールとインデックス登録に関する資料も確認し、検索エンジンが到達できるURLと意図した正規URLを保ちます。移行用環境のnoindexを本番へ残さない一方、公開前の検証環境を検索可能にしない管理も必要です。

URL対応表とコンテンツ対応表を別々に作る

旧URLから新URLへの対応、統合・廃止の判断、内部リンクの更新、外部から参照されるPDFを整理します。同時に、本文、見出し、表、画像の代替テキスト、ファイル名、更新日、構造化データが移行前後で一致するかを確認します。URLが同じでも本文が欠けることがあり、本文が移っても正規化やリンクが変わることがあります。二つの対応表を照合して非退行を検査します。

段階移行とロールバック条件を事前に決める

一括切替か段階切替かを、依存関係と検証可能性で選びます。切替前にバックアップ、DNS・キャッシュ、フォーム、主要ページ、リダイレクト、管理画面の操作を確認します。重大な欠落、誤公開、認証不具合が見つかった場合に、誰が停止を判断し、どこまで戻すかを決めます。復元後に新旧データが分岐しないよう、切替中の更新受付も計画に含めます。

公開後はclean URLとキャッシュ回避URLの双方で主要ページを確認し、検索設定、リンク、画像、フォームを点検します。移行直後の変動をすべてCMSの成果と断定せず、技術的な欠落と検索需要の変化を分けて記録します。

RFP・デモ・PoC・受入試験を同じ評価軸でつなぐ

提案依頼書では、抽象的な「使いやすい」「セキュア」だけでなく、実際の業務シナリオを書きます。診療科のお知らせを作成して確認者へ回す、緊急情報を公開して解除する、退職者の権限を止める、画像の代替テキストを確認する、バックアップから戻す、といった操作を候補環境で試せるようにします。

費用は導入価格ではなく継続運用の範囲で比較する

初期構築だけでなく、保守、更新、追加機能、検証環境、監視、バックアップ、アクセシビリティ試験、脆弱性対応、データ出力、契約終了時の支援を確認します。本記事では具体的な料金や期間を示しません。候補ごとに条件が異なるため、見積書の項目とRFPの要件を対応させ、含まれない作業を明記します。

契約前に終了・移行可能性を確認する

本文、画像、PDF、メタデータ、URL対応、ユーザー、ログをどの形式で受け取れるか、取得に追加条件があるかを確認します。独自部品や外部連携が別環境でも再現できるかも重要です。契約終了時のデータ削除、アカウント停止、バックアップ取扱い、協力範囲を先に合意すると、将来の移行判断を行いやすくなります。

公開後は、成果だけでなく更新品質と安全性をKPIにする

CMS運用の評価では、アクセス数や問い合わせだけを見ず、情報を正しく更新できる状態を測ります。未処理の更新依頼、承認の滞留、期限切れ情報、リンク・画像・フォームのエラー、アクセシビリティの指摘、権限棚卸し、更新プログラムの適用、バックアップ復元試験などを確認します。値そのものではなく、定義、対象範囲、測定日、責任者を決めます。

業務KPI・品質KPI・検索KPIを分ける

業務KPIは更新依頼から公開までの状態や差し戻し、品質KPIは表示・リンク・アクセシビリティ・セキュリティ、検索KPIはquery別の表示・クリック・着地URLなどに分けます。検索表示が増えても古い案内へ着地していれば望ましい運用とはいえません。逆に、緊急情報を正確に短時間で更新できてもアクセス増加を目的にしない場合があります。ページの役割に合わせて解釈します。

Googleの構造化データ一般ガイドラインが示すように、構造化データは可視本文と一致させ、正確で関連する内容にします。CMSやプラグインの変更後は、本文だけでなくhead、canonical、robots、JSON-LD、サイトマップも点検します。正しい実装は検索結果の表示や順位を保証するものではありません。

定期レビューで要件と現状の差を閉じる

組織変更、診療体制、外部サービス、ガイドライン、CMSのサポート状況が変われば、導入時の要件も見直します。権限一覧、連携一覧、障害記録、更新履歴、試験結果を材料に、残す機能、改善する運用、終了する連携を判断します。病院CMSの選定は導入製品を決めて終わりではなく、正確な情報を安全に更新し続けられる仕組みを維持する活動です。