© KAKEHASHI Inc. All Rights Reserved. クラウド上のデータ復旧で見落としがちな制約 医療系 SaaS の BCP 設計から得た教訓 2026/07/10 SRE NEXT　TrackC 

© KAKEHASHI Inc. All Rights Reserved. 自己紹介 森藤 敏之 株式会社カケハシ Musubi Embedded SRE 広島 ／ フルリモート 趣味: 完全食で生きること 近況: Google Cloud → AWS 経歴 前職： 病院向け SaaS ● 画像解析・クラウド PACS ● 開発〜運用〜SRE チーム立ち上げ 現職： 薬局向け SaaS ● 電子薬歴システム「Musubi」 ● Embedded SRE 2 

© KAKEHASHI Inc. All Rights Reserved. 今日のトークについて 話すこと ● BCP(事業継続計画：Business Continuity Plan) とは ● そもそもBCPってなにをしないといけないんだっけ ○ BCP を “前に進める” ための、考え方そのもの ● 取り組んでみて、後追いでBCPを整備する落とし穴 話さないこと ● 具体的な構成・数値・カバレッジなど社外秘になる情報には触れない 医療というドメインでは、BCP は “やった方がいいこと” ではなく、 顧客からお預りしている医療情報を守り抜くための、重要な投資でありSREのミッション。 3 

© KAKEHASHI Inc. All Rights Reserved. 4 前提) サービス紹介 

© KAKEHASHI Inc. All Rights Reserved. 5 医療業界を取り巻く BCP 医療情報システムの安全管理に関するガイドライン 医療機関・薬局におけるサイバーセキュリティ対策チェックリスト 医療情報システムの安全管理に関するガイドライン　第7.0版（経営管理編） SaaSサービス提供者ではなく、医療機関等に対するガイドライン 

© KAKEHASHI Inc. All Rights Reserved. BCP、いざ取り組もうとすると… ● そもそもなにに備える？、どうやって備える？ ● 復旧にかけていい時間や地点の目標は誰が決める？ ○ また整備完了と復旧目標の達成のトレードオフはどちらが優先？ ● その投資はどこまで許容される？ ● 法令や業界ガイドライン、顧客要求は満たせる？ 論点は、技術・コスト・規制・社内合意 ── 複数方向に同時に広がる “何を考えるべきか” の全体像が掴みにくい 6 

© KAKEHASHI Inc. All Rights Reserved. BCP は “整理と合意” の設計である。 これが今日のトークの主張です。 7 

© KAKEHASHI Inc. All Rights Reserved. BCP 設計の 3 次元 

© KAKEHASHI Inc. All Rights Reserved. BCP（事業継続計画）とは 災害・障害・攻撃などの緊急事態が起きても、 事業を継続、または早期復旧させるための計画 止めない Continuity 業務・サービスを停止させない 戻す Recovery 停止しても、素早く元の状態に戻す BCP には 2 つの側面がある 9 

© KAKEHASHI Inc. All Rights Reserved. 3 つの次元で整理する ① 何に備えるか What to prepare ② どう備えるか How to prepare ③ どう戻すか How to recover この 3 次元は独立ではない ── 互いに制約し合っている 10 

© KAKEHASHI Inc. All Rights Reserved. 復旧モード × 実行・訓練 サービス可用性 データ保護手段 × 隔離レベル 脅威シナリオ × 影響範囲 BCP 設計の 3 次元 ① 何に備えるか What to prepare ② どう備えるか How to prepare ③ どう戻すか How to recover すべてを貫く合意指標 → RTO / RPO 11 

© KAKEHASHI Inc. All Rights Reserved. RTO / RPO：3 次元を貫く合意指標 RTO Recovery Time Objective 復旧までにかかっていい時間 RPO Recovery Point Objective 復旧しなければならないデータの時点 これは技術目標ではなく、事業判断の翻訳結果。 経営・プロダクト・SRE が合意して初めて意味を持つ。 AWS Whitepaper: Business Continuity Plan (BCP) Google Cloud Architecture center: Disaster recovery planning guide 12 

© KAKEHASHI Inc. All Rights Reserved. ① 何に備えるか 

© KAKEHASHI Inc. All Rights Reserved. 何が起きうるか：脅威は 4 種類 ① 広域災害 地震・水害・停電 大規模インフラ喪失 ② インフラ障害 クラウド障害 AZ 障害 ネットワーク障害 ③ サイバー攻撃 ランサムウェア攻撃 認証情報漏洩 DDoS ④ 人為的ミス オペミス 設定ミス 誤削除 SaaS サービス で想定される脅威を 4 分類に整理 14 

© KAKEHASHI Inc. All Rights Reserved. 脅威は “等しくない” 医療 SaaS を運営する我々にとっての優先度 規制の要請 医療情報ガイドライン “サイバー攻撃の想定を含む BCP” を名指しで求める 時代の傾き 生成 AI 台頭以降 ランサムは高度化・増加 戻しにくさ 論理破壊系の脅威 データそのものが壊れる ── 最も戻しにくい だから、“サイバー攻撃 × データ破壊” を最優先で見る 15 

© KAKEHASHI Inc. All Rights Reserved. “何に備えるか” は事業判断 経営・プロダクト・CS がそれぞれの役割で関わる 経営 事業継続の 優先順位を判断する 緊急事態時の体制確保 プロダクト 守るべき業務 （顧客の優先業務） を定義する 営業/CS 顧客への影響度を 評価する 迅速な コミュニケーション SRE 実態から 優先度づけを支える “何に備えるか” は事業判断であり、技術判断ではない 16 

© KAKEHASHI Inc. All Rights Reserved. ② どう備えるか 

© KAKEHASHI Inc. All Rights Reserved. 18 “備える” には 3 つの観点がある 観点 1 可用性 インフラそのものを 止めないための冗長化 → “どこまで止まらずに済む か” 観点 2 復元性 壊れた・消えたデータを 戻すためのバックアップ → “いつの状態に戻れるか” 観点 3 隔離 備え自体が一緒に 壊れないための分離・改変不可 → “備え自体が守られている か” 止まらないための備え、戻せるための備え、備え自体を守る 

© KAKEHASHI Inc. All Rights Reserved. Multi-AZ 冗長化 同一リージョン内の AZ 障害に耐える AZ 単位で物理的に分散 クロスリージョン レプリケーション リージョン障害・広域災害に耐える 地理的に分散 インフラそのものが止まらないように、 地理的・物理的に分散させる 観点1：可用性 ── "止まらない" ための備え 19 

© KAKEHASHI Inc. All Rights Reserved. 20 AWS が自動で担うもの 自前で設計・構成が必要なもの ・ DynamoDB 　・ リージョン内で自動冗長化 　・ グローバルテーブルでマルチリージョン化 ・ S3 　・ 特定ストレージクラス以外、リージョン内で自動冗長化 ・ Aurora ストレージ層 　・ データを3AZ x 6つに自動複製 ・ Lambda / API Gateway 　・ リージョン内で自動冗長化 ・ VPC / サブネット 　・ 複数AZに配置するようインフラ構成が必要 ・EC2 / Auto Scaling 　・ 複数AZで分散されるようインフラ構成が必要 ・RDS 　・ 複数AZにスタンバイインスタンスの分散配置が必要 ・ElastiCache / OpenSearch 　・ 複数AZにノードの分散配置が必要 観点1: インフラ可用性 — “止まらない” ための備え 冗長化は AWS が自動で提供するもの と 自前で構成が必要なもの が混在する 事前に "何が自動か・何が自前か" を把握し、説明できる状態にしておく。 

© KAKEHASHI Inc. All Rights Reserved. 21 観点1: インフラ可用性 — “止まらない” ための備え AWS Well-Architected Framework: Shared Responsibility Model for Resiliency Google Cloud Architecture Center: Shared responsibilities and shared fate on Google Cloud 

© KAKEHASHI Inc. All Rights Reserved. 観点2：復元性 ── "戻せる" ための備え 保護手段ごとに、守れる障害が違う スナップショット 定期的な点で戻せる 低頻度 / 過去のある時点 PITR 任意時点に戻せる RPO 最小 / 継続的なログ レプリカ 即時に戻せる RTO 最小 ※論理破壊には無力 “冗長化＝バックアップ” は誤解。レプリカは、壊れたデータをそのまま複製する。 22 

© KAKEHASHI Inc. All Rights Reserved. ・ スナップショットの取得 　・ 定期的なデータ断面を保管 ・ 継続バックアップ(PITR)の取得 　・ 任意時点に遡及するための増分バックアップを保管 ・ バージョニング管理 　・ S3のデータ消失/改ざんに備える 23 観点2：復元性 ── "戻せる" ための備え "常時同期" と "特定時点に戻す" は目的が違う。 何が守れて何が守れないかを把握する ・ DynamoDB 　・ グローバルテーブルの活用 ・ S3 　・ クロスリージョンレプリケーションの活用 ・ RDS / Aurora 　・ グローバルデータベース構成の活用 ・ OpenSearch 　・ クロスクラスタレプリケーション構成の活用 常時同期(リージョン切替時のRTO最小化) 特定時点に戻す手段（論理破壊に対応） 

© KAKEHASHI Inc. All Rights Reserved. 観点2の復元手段は、"どこに置くか" によって効き方がまったく変わる 同一リージョン内 Multi-AZ 複数リージョン 同一アカウント 更に分離 別アカウント / 改変不可 インフラ障害 AZ 障害 広域災害 リージョン喪失 ランサム / 論理破壊 人為的ミス 誤削除 ◎ 即復旧 - - ✕ 一緒に喪失 ◎ 別リージョンへの切り替え - ✕ 一緒に暗号化/破壊されるリスク ✕ 侵害が波及するリスク ◎ バックアップを保護 ○ - ◎ 権限が分離 ※ S3 Object Lock / AWS Backup Vault Lock は同一アカウント内でも改変不可を提供。 　 "更に分離" は "別アカウント" と "改変不可" の2つの実装ルートがあり、厳格性とコストで選ぶ。 隔離レベルを上げるごとに、"備え" は新しい脅威に届く。だが同時にコストも上がる。 観点3: 隔離 ── "備え" の置き場所によって、守れる脅威が変わる 24 

© KAKEHASHI Inc. All Rights Reserved. 25 ・ モード選択 　・ Governance / Compliance ・ ランニングコストの増加 　・ Vault Lock: 定期的なフルスナップショットの取得が必要 　・ S3 Object Lock: バージョンが肥大化リスク ・ 復旧手順の複雑化 　・ 復旧手順や訓練計画がより複雑化 観点3：隔離 ── 備え自体を”守る” バックアップのイミュータブル化と隔離 AWS が提供する機能 ・ DynamoDB 　・ AWS Backup Vault Lock ・ Aurora 　・ AWS Backup Vault Lock 　　※ 継続バックアップ は Vault Lock 適用不可 ・ S3 　・ S3 バージョニング管理 　・ S3 Object Lock 設計や投資判断が必要なポイント より堅牢性を高めたい場合、 Backup Vault やS3バケットのレプリケーション先を別アカウントに分離し、隔離が推奨される 

© KAKEHASHI Inc. All Rights Reserved. “どう備えるか” の隔離は投資判断 セキュリティ・財務・経営がそれぞれの役割で関わる セキュリティ 脅威モデルと 隔離戦略を策定する 財務 / 経営 投資判断を下す SRE 技術的実現性と 選択肢を提示する 安全管理対策は “コスト” ではなく “投資”（医療情報ガイドライン） 26 

© KAKEHASHI Inc. All Rights Reserved. ③ どう戻すか 

© KAKEHASHI Inc. All Rights Reserved. 復旧モードは 3 つ 既存環境復旧 既存を直す／巻き戻す 得意：素早く元に戻る 立ちはだかる “3 つの壁” ・同名リソースの壁 ・接続先の壁 ・最後の砦が消える壁 リージョン切り替え 別リージョンの待機環境に切り替える 得意：リージョン喪失に即応 前提となる “3 つの準備” ・複数リージョン同期 ・フェイルオーバー機構 ・スタンバイのコスト 新環境再構築 別アカウント・別環境を作り直す 得意：汚染を断ち切る やるべき “3 つのこと” ・環境の再現性を確保する ・クリーンなデータを移行する ・安全に切り替える これらの復旧モードには、それぞれ異なる制約や壁がある 28 

© KAKEHASHI Inc. All Rights Reserved. 既存環境復旧の壁 同名リソースの復旧はできない 要件 DynamoDB の PITRバックアップ は残したままテーブルのデータ復旧を行いたい 設計 マネージドサービスの多くは “同名リソースの作成” ができない 「別名でリストア」または「削除して再作成」のニ択（Side-by-Side 原則） 学び 「削除して再作成」を選択した瞬間、 任意の時点に戻れる機能（別リージョンへのレプリカ や PITRバックアップ）を失う → AWS Prescriptive Guidance にもSSMを活用した動的なテーブル名切り替えが推奨されている アプリケーション側の影響範囲を洗い出しきれない場合、インフラレイヤーのみで対応を検討する... 29 

© KAKEHASHI Inc. All Rights Reserved. 案1. 東京リージョン の PITR をなんとかして残す ● テーブルのレコードのみを全削除し、 PITRから復旧する → 100万レコードを削除するのに約20分（テーブルのパーティション等に依存） → 5億レコードの削除に約 9日 案2: 大阪リージョンの PITR のみを残し 、東京リージョンの復旧を優先する ● 東京リージョンのテーブル削除時点で大阪の PITRを失う 案3. AWS Backup を利用して、 DynamoDB テーブルと PITRバックアップ を分離する ● AWS Backup は DynamoDB の継続バックアップ非対応 案4. AWS Backup を利用して、 DynamoDB テーブルの 定期スナップショット を取得する ● コールドストレージ - $0.0342/GB x テーブル数 x 世代 => 月額 数十万〜数百万円 案5. Time to Live 機能を利用してデータ削除を行う ● 全然ダメだった 30 既存環境復旧の壁 同名リソースの復旧はできない 

© KAKEHASHI Inc. All Rights Reserved. リージョン切り替えの壁 ① スナップショット取得 ② 削除保護の無効化 ③ パラメータグループ設定の記録 ④ レプリケーションラグが0に近いことを確認してから Secondary Cluster をデタッチ 31 Step 1 事前準備 & デタッチ Step 2 プライマリUP セカンダリ再作成 Step 3 インスタンス追加 事後確認 通常時の運用コストの増加 - Aurora MySQL Global database バージョンアップ ⑤ Primary Cluster に アップデートを実行（--apply-immediately） (リードレプリカがあればフェイルオーバーするため、Datadog monitor など設定している場合は事前に Downtimeを設定のうえアラートが鳴らないようにする) ⑥ Secondary Cluster を 再作成（データ自動同期） ⑦ 全インスタンスのバージョン一致を確認。 ⑧ レプリケーションラグの収束を確認後、削除保護を再有効化 

© KAKEHASHI Inc. All Rights Reserved. 既存環境復旧 / リージョン切り替えの壁 パイプラインは "データ" と別レイヤー 要件 データ復旧やリージョン切り替えを経ても、 サービス間連携やデータパイプラインに影響を与えてはならない 通常時 Tokyo (アクティブ) アプリ S3 Lambda Osaka (パッシブ) S3 レプリカを保持 / 通知は無効 / Lambda は待機 CRR フェイルオーバー後の罠 Tokyo (生きている) S3 Lambda 二重発火 Osaka (アクティブ化) CRR (逆方向) S3 アプリ S3 Lambda 32 

© KAKEHASHI Inc. All Rights Reserved. コンソール上でプライマリリージョンを「無効化」 リージョン切り替えの壁 訓練は、不確実 要件 プライマリリージョンを擬似的に被災状態にして切り替え訓練を実施する 設計 学び とても安全にリージョンがシャットダウンされる レプリケーション や 変更データキャプチャ(CDC) 設定が安全に切断される etc. 33 

© KAKEHASHI Inc. All Rights Reserved. 壁の外にある制約 

© KAKEHASHI Inc. All Rights Reserved. 起因事象でRTOを語ると設計を誤る 起因事象だけでは、RTOは決まらない 要件 地震・ランサム・誤操作 ―― 起因事象ごとにRTOを設計しがち 設計 しかしデータストアごとに復旧特性は異なり、 起因事象だけでは値が定まらない 学び RTOを決めるのは“データ整合性が失われたか × その範囲”。 逆に、リージョン切り替えのような備えは顧客への重要な訴求ポイントとなる 35 

© KAKEHASHI Inc. All Rights Reserved. RTOの“時計の起点”問題 RTOは、いつから測るかも合意が必要 要件 外部要求「n日以内に復旧」 に対し、SREは実作業時間だけでRTOを設計しがち 設計 障害発生・検知・復旧着手 ―― どの時点が起点かの合意が抜けたまま数値が動く フォレンジック調査だけで数日かかることもある 学び RTOは“何を測るか”だけでなく“いつから測るか”も要る。 これは技術ではなく契約・SLAで握る領域 36 

© KAKEHASHI Inc. All Rights Reserved. まとめ 

© KAKEHASHI Inc. All Rights Reserved. 3 次元 × 全社ステークホルダーの役割 ① 何に備えるか 経営 事業継続の 優先順位を判断する プロダクト 守るべき業務を 特定する 営業/CS 顧客への影響度を 評価する ② どう備えるか セキュリティ 脅威モデルと 隔離戦略を策定する 財務/経営 投資判断を下す Platform/SRE 技術的実現性を 検証する ③ どう戻すか 開発チーム アプリ側の設計に 反映する CS/運用 顧客通知と運用手順を 整備する 法務/コンプラ 規制対応の 説明責任を果たす 各部署が自分の役割を全うすることが、緊急時の事業継続を支える 38 

© KAKEHASHI Inc. All Rights Reserved. 3 次元 × Embedded SRE の技術ミッション ① 何に備えるか ・プロダクト固有のデータ資産を特定する ・サービス間依存とデータ層をマッピングする ・優先度を RTO/RPO という技術目標に翻訳する ② どう備えるか ・マネージドサービス特性を見極める ・隔離アーキテクチャを設計する ・バックアップの健全性を継続検証する ③ どう戻すか ・復旧モードを選択し自動化する ・依存関係グラフに基づき復旧順序を設計する ・訓練シナリオを設計し定期実行する 事業判断を土台に、実態から 3 次元を 主体的に 設計し、必要な合意を主導する 39 

© KAKEHASHI Inc. All Rights Reserved. 訓練は “合意の再確認” 訓練は技術検証だけではない ミクロで得た知見をマクロの合意に戻す仕組み 訓練 巻き込み 学び 手順書の作成とウォークスルー ―― プロバイダの仕様変更・権限不足・パラメータ欠落の検知 役割分担と意思決定ポイントの確認 ―― 承認プロセス・統制 も訓練で検証する 訓練でいざという時に動くことを担保する 小規模データ・時間計測なしでも、この価値は成立する 40 

© KAKEHASHI Inc. All Rights Reserved. 教訓 ① BCP は “バックアップを取ること” ではない。 3 次元（備える対象・備える手段・戻し方）の設計である ② 3 次元それぞれに、異なるステークホルダーとの合意が要る ── SRE は事実に基づき主体的に設計し、合意を主導する ③ 技術選択は、事業要件と合意の “結果” であり、出発点ではない ④ BCP に “完成” はない。訓練と合意のサイクルこそが本体である ⑤ クラウドの復旧は、選んだ戦略によって制約の質が変わる 41 

© KAKEHASHI Inc. All Rights Reserved. BCP は、インフラの整備ではない。 全社の体制とワークフローの設計である。 SRE はその推進を担える SRE だけでは、BCP は完成しない。だからこそ Inclusive ── 立場を超えて関わる人が増えるほど、BCP は強くなる。 42