「あるべき姿」は描けても、実務で最初に詰まるのは「今 24/365 で動いている検査を止めずに、どう移すか」。評価 → PoC → 並行稼働 → 切替 → 旧環境廃止の 5 フェーズ、AWS 7R の検査業務への当てはめ、データ移行とロールバック基準まで、移行のリスクを構造で押さえる。
シリーズ①〜④は「クラウドで LIS をどう作るべきか（あるべき姿）」を描いた。だが現場にはすでに動いているオンプレ LIS があり、検査は土日も夜間も止まらない。「あるべき姿」と「今あるもの」の間には移行という断層がある。ここを設計せずに提案すると、机上論で止まる。
検査システムの移行が一般的な業務システムより難しいのは、止められない（救急・時間外も稼働）・間違えられない（結果は診断の根拠）・戻れないと困る（切替失敗時のロールバック）の三重制約があるから。本編はこの制約下での段階移行を、フェーズ・戦略・データ移行・撤退基準の4点で構造化する。
本編はシリーズの「深掘り編」。②④が「移行先の作り方」、本編が「そこへの渡り方」。移行時のデータの真正性はデータインテグリティ編に、移行後の継続運用は別途「運用編（予定）」に接続する。
| 区分 | 内容 |
|---|---|
| 対象 | 稼働中のオンプレ臨床検査部門システム（LIS）を AWS クラウドへ移す段階移行の設計。フェーズ分解、AWS 7R の当てはめ、データ移行の手段と検証、並行稼働・カットオーバー・ロールバックの判定基準。 |
| 対象外 | ① クラウドのあるべき設計・実装（アーキ・認証・暗号）→ シリーズ②④。② 移行時に保つべき記録の真正性（ALCOA+）の詳細 → データインテグリティ編。③ 移行後の定常運用・監視・SLA → 運用編（予定）。④ 個別製品の移行手順書（ベンダー依存）。 |
移行の失敗は「手順の抜け」より「どの軸で見落としたか」で起きる。本編は 2 軸で機械的に押さえる。
この2軸で「いつ・どの要素を・どの戦略で動かすか」を漏れなく配置する。残リスクは「①追加技術／②運用／③契約・SLA／④受容」の4分類で引き取り先を明示する。
| 制約 | 意味 | 移行設計への要求 |
|---|---|---|
| 止められない | 救急・時間外・休日も検査は走る。長時間のダウンタイムは患者安全に直結 | ダウンタイムを分単位に抑える切替設計、または無停止の並行稼働。深夜帯の短時間カットオーバー窓を確保 |
| 間違えられない | 検査結果は診断の根拠。移行時のデータ欠落・変換誤り・取り違えは誤診に直結 | 移行リハーサルでの全件突合、変換ロジックの検証、移行中の記録の真正性維持（ALCOA+） |
| 戻れないと困る | 切替後に重大障害が出ても「昨日に戻す」が効かないと業務が止まる | 明確なロールバック基準と、旧環境を一定期間 Retain（即座に戻せる状態）で保持 |
| Phase | やること | 抜けやすい点 |
|---|---|---|
| 1 評価 | アプリ/データ/装置IFの棚卸し、依存関係マップ、データ量と保存期間、規制要件（3省2GL・検体検査精度）、各要素の 7R 仮決め | 分析装置との独自プロトコル/ファイル連携、外部システム（電子カルテ・会計）連携の洗い出し漏れ |
| 2 PoC | 代表ワークロードで性能・スループット・連携・データ変換を小範囲実証。コスト試算の前提取得 | 本番のピーク負荷（朝の検体集中）を模さず「動いた」で満足する |
| 3 並行稼働 | 新旧を同時に動かし、同一入力に対する結果を突合。差分ゼロを一定期間維持して新環境の信頼を確立 | 並行期間が短すぎる／突合を一部だけにする（全件・全項目で照合） |
| 4 切替 | 判定基準クリアを確認し、深夜等の短時間窓でカットオーバー。ロールバック手順を待機 | 切替判定基準を事前に数値で決めていない（後述） |
| 5 旧環境廃止 | 本番安定（例：N 週間無重大障害）を確認後、旧を Retire。法定保存データは新環境/アーカイブへ移管済みを確認 | 旧を早く消しすぎて戻れない／保存義務データの移管確認漏れ |
「全部 Refactor（作り直し）」は時間も金もかかり、検査停止リスクも最大。LIS を構成する要素ごとに、適切な R を選ぶ。
| 戦略 | 内容 | 検査システムでの当てはめ例 |
|---|---|---|
| Rehost （Lift & Shift） | 変更せずそのままクラウドへ。最速・低リスク | まず止血的に EC2 へ載せ替え、後で段階的に最適化。MGN で自動移送 |
| Replatform | 作り直さず一部を最適化（DB をマネージドに等） | オンプレ DB → Amazon RDS、ファイル共有 → S3。コスト・運用負荷を下げる現実解 |
| Refactor | クラウドネイティブに再設計（マルチテナント SaaS 化等） | 標準仕様 1.0版が求める SaaS/FHIR/ゼロトラストへの本格対応。効果大だが工数・リスク大、段階導入 |
| Repurchase | 自前運用を SaaS/第三者サービスに置換 | 周辺機能（帳票・通知・認証基盤）をマネージド/SaaS に寄せる |
| Retain | 当面は現環境に残す（まだ移さない） | 装置直結の制御部や移行リスクが高い部分は残置。切替後の旧環境も一定期間 Retain＝即ロールバック用 |
| Retire | 不要なものを廃止 | 使われていない旧機能・重複システムを移行を機に整理 |
| Relocate | 仮想基盤ごと大量移送（VMware 等） | 多数サーバを一括でクラウド版基盤へ。大規模検査センターの一斉移送 |
| 用途 | サービス | 勘どころ |
|---|---|---|
| サーバの載せ替え（Rehost） | AWS Application Migration Service（MGN） | 物理/仮想サーバを自動変換して AWS でネイティブ稼働。継続レプリケーションで切替直前まで同期 |
| DB の移行 | AWS Database Migration Service（DMS） | 移行中も現用 DB は稼働＝ダウンタイム最小。継続レプリケーションで並行稼働を支える。異種DB変換も可 |
| 大容量ファイル/検査画像の転送 | AWS DataSync | オンプレ → S3/EFS/FSx を高速・暗号化・転送時整合性チェック付き。病理画像など大容量に |
| 標準コード/形式の変換 | （アプリ層） | JLAC10→JLAC11、ローカルコード→標準コード、HL7 v2→FHIR の変換は移行の核心。詳細は実装側で（②参照） |
切替は「気合い」でなく事前に数値で決めた判定基準で実行・中止する。基準を決めずに当日判断すると、戻すべき場面で戻せない。
並行稼働は「念のため」でなく、新環境の信頼を数値で積み上げる工程。突合差分が説明できない間は切替しない——これが「間違えられない」制約への規律。
本シリーズは、医療情報システムの開発・クラウド化を手がける X Harumi が、公的な一次資料を根拠条項まで遡って再整理したものです。AI 活用支援・業務効率化・DX 推進・システム開発を提供しています。