業務システムのバックアップ体制2026｜守れるのはコピーではなく復旧

「バックアップは毎晩正常終了しています」。タイの工場でシステム担当者からこの答えが返ってきたとき、次に確かめるべきことは1つです。そのバックアップから、実際に業務を再開できたことがあるか。業務システムのバックアップ体制で守れるのは、保存されたコピーの本数ではなく、復旧そのものです。本記事では、復旧できる体制の条件を、RTO・RPOという2つのものさしと費用の分解を使って、タイ拠点の実情に合わせて具体化します。

「バックアップは取れている」と「復旧できる」はなぜ違うのか

バックアップの話をすると、最初に出てくるのはほぼ例外なく「取得状況」です。毎晩何時にジョブが走り、何世代保持していて、成功通知がどこに飛んでいるか。監査でもこの3点が確認され、緑のチェックが並べば問題なしとされます。

ところが実際に障害が起きたときに問われるのは、まったく別のことです。何時点のデータに戻せるのか。戻す作業に何時間かかるのか。その手順を実行できる人は今この国にいるのか。戻したあとに業務が回るのか。ジョブの成功通知は、これらの問いに1つも答えていません。

ここに本記事の中心的な主張があります。「バックアップが動いている」ことと「復旧できる」ことは別物です。 バックアップは手段であり、目的は復旧です。手段の健全性をいくら測っても、目的が達成できる保証にはなりません。にもかかわらず、多くの現場で測られているのは手段のほうだけです。

この差が具体的な数字として現れているのが、JIPDECの企業IT利活用動向調査2026です。調査期間は2026年1月16日から1月20日、対象は従業員50名以上の国内企業1,107社で、回答したのはIT戦略や情報セキュリティに従事する担当者です。この調査では、ランサムウェアの感染経験率が45.8%、そして身代金を支払わずにシステム・データを復旧できなかった割合が13.0%でした。後者は前回調査の10.5%から上昇しています。

この13.0%という数字の読み方が重要です。これらの企業がバックアップを取っていなかったと考えるのは、おそらく実態と違います。取ってはいたが、そこから戻せなかった。あるいは戻せる状態のものが残っていなかった。復旧できなかった割合が下がるどころか上がっているという事実は、バックアップの普及と復旧能力が同じ方向に進んでいないことを示しています。

だから、選定や体制構築で最初に決めるべきは製品名ではありません。業務ごとにRTO（復旧までの許容時間）とRPO（失われるデータの許容範囲）をいくつに置くかという設計判断です。この2つが決まっていない状態で製品を比較すると、比較の軸が「価格」と「機能の多さ」しか残らず、復旧できるかどうかは最後まで検証されないまま導入が終わります。

2026年もタイ拠点がランサムウェアの標的であり続ける理由

タイの拠点でこの話をすると、「日本本社ほど狙われないのではないか」という反応が返ってくることがあります。実際の分布はその感覚とずれています。

Check Point Software Technologiesの集計によれば、2024年7月から9月に公表されたランサムウェア攻撃事例1,230件超のうち、13%がアジア太平洋地域で発生しています。地域単位で見て無視できる規模ではありません。加えてタイ国家サイバーセキュリティ局（NCSA）によれば、タイ国内のランサムウェア被害は2023年が2022年比で1.5倍に増加しています。増加の傾向は、日系拠点が集中するこの国でも例外ではないということです。

日系製造拠点そのものの被害も報告されています。生産停止・データ暗号化・情報窃取を伴う被害が、タイでは2022年から2024年にかけて、マレーシアでは2022年から2023年にかけて、インドネシアでは2021年と2024年に、ベトナムでは2024年に発生しています。ASEAN全域にわたって、しかも複数年に分散して起きているという分布は、特定の国や特定の年の特殊事情では説明がつきません。

製造業であることが条件を悪くする

業種別に見ると、条件はさらに厳しくなります。JIPDECの調査では、製造業の感染経験率は57.1%で、全体の45.8%を大きく上回っています。さらに製造業では、身代金を支払った後も復旧に失敗した割合が18.2%でした。支払いは復旧の保証にならないという事実が、業種の数字としてはっきり出ています。

被害の中身も見ておく必要があります。同じ調査で、被害の影響として最も多かったのはデータの喪失・破損で51.3%、次いで機密情報の漏えいが35.1%でした。漏えいは前回調査の29.3%から約6ポイント上昇しています。ここが体制設計に効きます。データを暗号化されるだけなら、健全なバックアップがあれば戻せます。しかし窃取されたデータは、バックアップを何本持っていても取り消せません。バックアップは可用性の対策であって、機密性の対策ではないという線引きを、社内の説明資料の段階で引いておいてください。

そして復旧期間です。同調査では復旧までの期間として「1週間から1か月以内」が34.7%で最多でした。工場を1週間から1か月止めるという想定で、経営に説明できる計画になっているか。この問いに答えられないなら、体制の検討はまだ始まっていません。

タイ拠点で製造ラインまで含めて守る話は、情報システムだけの範囲を超えます。制御ネットワーク側の切り分けについてはオペレーションテクノロジー（OT）セキュリティ｜工場の実務ガイド2026で扱っています。本記事は、そのうちバックアップと復旧の設計に絞って掘り下げます。

バックアップが「動いていた」のに復旧できなかった典型パターン3つ

復旧できなかった事例を分解すると、原因はおおむね3つの型に収まります。どれもジョブの成功通知では検出できません。

パターン1 — 一度も検証していない

最も多い型です。バックアップジョブは成功しているが、そこから実際に戻す作業を一度もやっていない。この状態で見過ごされる不具合はいくつもあります。取得対象から重要なフォルダやデータベースが外れている。データベースのオンラインバックアップが整合性のない状態で取られている。暗号化されているが復号鍵の保管場所が誰も分からない。取得は成功しているがファイルが破損している。

これらは、戻してみるまで表面化しません。そして戻す機会は、たいてい本番の障害が最初になります。復旧作業の初回が本番、というのは工程管理の常識からすれば異常な状態ですが、バックアップの世界ではこれが標準になっています。

パターン2 — 本番と同じネットワークに置いている

2つ目は隔離の欠如です。バックアップサーバーが本番と同じネットワークセグメントにあり、同じ認証基盤で管理され、同じ管理者アカウントでログインできる。この構成では、本番が侵害された時点でバックアップも侵害の射程に入ります。

ランサムウェアの攻撃者が最初に探すのはバックアップです。復旧手段を潰してから暗号化するほうが、支払いに応じる確率が上がるからです。共有フォルダとしてマウントされたバックアップ領域、ドメイン参加したバックアップサーバー、本番と共通の特権アカウント。この3つが揃っていると、バックアップは「攻撃者にとって最初に消す対象」になります。

パターン3 — リストア手順が属人化している

3つ目は人です。手順書がない、あるいは手順書はあるが実際の作業とかけ離れている。復旧できるのは特定の1人だけで、その人は日本本社にいる、あるいはすでに退職している。タイ拠点では、ベンダー側の担当者交代や、現地スタッフの離職によってこの穴が開きやすくなります。

障害が起きるのは平日の日中とは限りません。深夜や連休中に起きたとき、誰が、どの手順で、どの権限を使って復旧に着手するのか。その連絡経路が1本しかない体制は、その1本が繋がらない瞬間に復旧時間が無限大になります。

この3つに共通しているのは、どれもバックアップの取得側からは見えないという点です。取得の健全性を測る仕組みをいくら強化しても、検証・隔離・手順の3つは改善しません。測る対象を復旧側に移す必要があります。

ニチレイの事例に見る「復旧できたバックアップ」の条件

では、復旧できたバックアップとはどういうものか。2026年に公表された事例が参考になります。

ニチレイグループは、2026年7月13日午前6時50分頃にサイバー攻撃の疑いのある事象を検知し、直ちに緊急対策本部を設置してグループ全体のシステムを緊急遮断しました。この対応の結果、発生から4日後の2026年7月17日より低温倉庫・食品工場の出荷業務を段階的に再開し、約1週間後には通常稼働の目処が立っています。

先に見たJIPDECの調査では、復旧期間は「1週間から1か月以内」が34.7%で最多でした。この分布と比べると、4日で出荷業務の段階再開に入り、約1週間で通常稼働の目処という速度がどれだけ違うかが分かります。

速度を生んだ2つの条件

公表されている内容から、この速度を生んだ条件は2つに整理できます。

1つ目は、本番ネットワークから論理的・物理的に分離されたバックアップシステムが生存していたことです。前節のパターン2の逆をやっていた、ということになります。論理的な分離だけでも、物理的な分離だけでもなく、両方が揃っていた点が重要です。論理的分離は認証と経路の分離、物理的分離は装置と設置場所の分離を指します。片方だけでは、攻撃者が管理権限を取った時点で崩れる可能性が残ります。

2つ目は、初動での即座の全社遮断です。検知から遮断までの判断が速いほど、暗号化される範囲は狭くなります。ここで効くのは技術ではなく意思決定の設計です。誰が、どの情報をもって、どの範囲まで止める判断を下せるのか。この権限が事前に降ろされていないと、確認と報告に数時間が消えます。

縮退運用が併走していたこと

もう1つ見落とせないのが、手書き伝票による縮退運用を並行させて物流停止を最小化していた点です。システムが完全に戻るまで業務を止めるのではなく、紙で回せる範囲を紙で回す。これはバックアップ製品の機能ではなく、業務側の設計です。

工場でも同じ考え方が必要です。生産指示、入出庫、出荷、検査記録のうち、どれを何日間なら紙で回せるか。回すための帳票は印刷して保管してあるか。システムが戻ったあと、紙で処理した分をどうやってシステムに取り込むか。この3点を決めておくと、RTOに対する要求が現実的な水準に下がります。縮退運用の設計は、実質的にRTOを買う手段です。

RTO・RPOという2つのものさし — 業務ごとに変えるべき理由

ここで、体制設計の中心にある2つの言葉を定義します。RTO RPO 設計は、バックアップ製品を選ぶより前に行う作業です。

RPO（Recovery Point Objective）は、どの時点まで戻れればよいかを示します。言い換えると、失われても業務が成立するデータの範囲です。RPOが1時間なら、障害直前の1時間分のデータは失われる前提で業務を組む、という意味になります。RPOを短くするには取得の頻度を上げる必要があり、頻度を上げるほど回線・ストレージ・処理負荷の費用が増えます。

RTO（Recovery Time Objective）は、どれだけの時間で業務を再開するかを示します。データが手元にあることと、業務が再開できることは違います。復旧先の機材の調達、OSとミドルウェアの再構築、データの転送時間、動作確認、利用者への周知。これらの合計がRTOです。バックアップからのリストア時間だけを見積もって「2時間で戻ります」と説明している計画は、ほぼ確実に外れます。

全社一律にすると必ず破綻する

この2つを全社一律で決めようとすると、2方向のどちらかに破綻します。

厳しいほうに揃えると、費用が跳ねます。全システムのRPOを1時間、RTOを4時間に揃えるということは、共有フォルダも試験環境も同じ水準で守るということです。守る価値と費用が釣り合いません。

緩いほうに揃えると、業務が止まります。基幹システムのRPOを24時間に置くと、障害の起きた日の受注・出荷・在庫移動がすべて消えます。工場では、その1日分を紙の記録から復元する作業が発生し、復元中は次の生産が進みません。

したがって、業務区分ごとにRTOとRPOを変えるのが唯一の現実解です。区分ごとに数字が違えば、投入する手段も費用も変わります。これが体制設計の骨格になります。

誰が決めるのかを先に決める

もう1つ実務的な注意があります。RTOとRPOは情報システム部門が決める数字ではありません。「何時間止まったら、いくら損失が出るか」を知っているのは業務部門です。情報システム部門が単独で置いた数字は、災害が起きた瞬間に「そんな条件は聞いていない」と覆されます。

進め方としては、業務部門に対して「この業務が止まったとき、何時間なら耐えられますか」「直近何時間分のデータが消えたとき、紙や記憶から復元できますか」の2問を投げ、返ってきた答えを情報システム部門が費用に翻訳する、という順序が機能します。費用を見せた段階で、業務部門の要求は現実的な水準に修正されます。この往復を1回やっておくことが、後の合意形成を圧倒的に速くします。

表A 業務別RTO・RPO設計対応表

ここまでの考え方を、実際の設計表に落とします。以下はTOMAS TECHが工場向けの体制設計で使っているフレームワークで、外部の統計調査ではなく、業務区分ごとの性質から導いた設計指針です。自社の事情に合わせて数字を動かす前提の、出発点として使ってください。

表の読み方

基幹システムのRPOを1時間以内、RTOを4時間以内に置いているのは、この区分が止まると入出荷そのものが止まるためです。受注も出庫も在庫移動も、この1本に集まっています。ここだけはクラウドとオンプレの二重化を前提にし、さらにイミュータブルスナップショット、つまり後から消したり書き換えたりできないコピーを組み合わせます。手段が二重になる分だけ費用は上がりますが、上げるならこの区分です。

生産ライン制御・SCADAのRPOを24時間以内としているのは、この領域の主なデータが設定値・レシピ・ラダーであり、日々変化する量が小さいためです。変更が起きるのは段取り替えや改造のときで、毎時間書き換わるわけではありません。ただしRTOを翌営業日としているのは復旧が簡単だからではなく、復旧作業がネットワーク経由で完結せず、現地での作業を伴うためです。装置ベンダーの立会いが要る場合、時間はさらに延びます。ここは方式より、誰が来られるかを先に確認してください。なお、方式を「ローカルNASと週次のクラウド同期」としているのは、24時間以内のRPOを日次で取得するローカルNAS側が担い、クラウド側は遠隔地に独立したコピーを残す役割に絞っているためです。週次の同期は、拠点ごと失われた場合の最後の砦として位置づけています。

共有ファイル・図面は、量が多く、変更頻度は中程度、そして失ったときの影響が「作業のやり直し」で済むことが多い区分です。3世代保持としているのは、破損や誤上書きが直近1世代では検出されず、数日遅れて気づくことがあるためです。

メール・グループウェアだけRTOとRPOの両方が数時間以内になっている理由は、この区分が業務そのものというより、全業務の連絡経路だからです。障害対応中に連絡手段が落ちていると、他のすべての復旧作業が遅れます。そして重要な点として、Microsoft 365のようなSaaSは、サービス提供者側の可用性は高くても、利用者の誤削除や内部からの破壊に対する長期の巻き戻しは標準では限定的です。SaaS向けバックアップサービスを別に用意する必要があるのは、この理由によります。

この表を自社版に直す手順

この表をそのまま使うのではなく、自社版に作り直してください。手順は3段階です。まず自社の業務システムを、この4区分のどれに当たるかで分類します。どこにも当たらないもの（例えば品質検査データや原価計算の集計基盤）は、5番目の行として追加します。次に、業務部門への2問の聞き取りでRTOとRPOの希望値を集めます。最後に、その希望値を満たすために必要な方式と費用を並べ、費用が過大な行だけ数字を緩める交渉をします。

この作業の成果物は表1枚です。表1枚のために会議が3回必要になることもありますが、この表がないまま製品を選ぶと、選定の根拠が後から説明できなくなります。

3-2-1ルールとイミュータブル設計 — 「消せないコピー」がなぜ要るのか

RTOとRPOが決まると、次は手段の話になります。ここで基準になるのが3-2-1ルールです。データのコピーを3つ持ち、2種類の異なる媒体に置き、そのうち1つを別の場所に保管する、という考え方です。

このルール自体は古くからありますが、ランサムウェアの時代に入って意味が変わりました。かつて3-2-1が守っていたのは、機器の故障と火災・水害でした。今守るべき相手は、管理権限を取ったうえで意図的にバックアップを探して消しに来る攻撃者です。相手が変われば、同じルールでも実装が変わります。

3つのコピーが同じ運命を共有していないか

まず確認すべきは、3つのコピーが本当に独立しているかです。ありがちな失敗は、本番サーバー、同じラック内のバックアップサーバー、同じ建物内のNASという構成です。コピーは3つありますが、火災でも侵害でも同時に失われます。数だけ満たしていて独立していない状態を、私たちは「見かけの3-2-1」と呼んでいます。

判定の方法は単純です。1つの管理者アカウントの権限で、3つとも消せるかどうかを確認してください。消せるなら、それは1つのコピーと同じです。攻撃者は権限を取ってから動くので、権限の届く範囲が実質的な被害範囲になります。

イミュータブル、つまり消せないコピー

この問題への直接の答えがイミュータブル設計です。保持期間を設定したコピーを、その期間中は管理者ですら削除・変更できない状態で保管します。クラウドストレージのオブジェクトロック機能や、専用アプライアンスの書き込み一回限りの領域がこれに当たります。

イミュータブルなコピーがあると、攻撃者に管理権限を取られても、その1本だけは残ります。逆に言えば、イミュータブルなコピーが1本もない構成では、管理権限の喪失がそのまま全コピーの喪失を意味します。表Aで基幹システムだけにイミュータブルスナップショットを明記しているのは、この区分が権限喪失時に最後に残るべき対象だからです。

オフラインという最後の手段

もう1つの選択肢がオフラインです。テープや取り外し可能なディスクに書き出し、装置から物理的に切り離して保管します。ネットワークに繋がっていないものは、ネットワーク経由では消せません。手間はかかりますが、確実性という点では今でも最上位です。

タイの拠点で採用する場合の注意は、保管場所の環境です。高温多湿の環境に長期保管すると媒体の劣化が早まります。事務所の施錠された保管庫か、空調のある別拠点を確保してください。そして、オフラインに落とした媒体からの読み出しを年に一度は実施してください。読めない媒体は、無いのと同じです。

隔離の3層を書き出す

実務としては、隔離を3つの層で書き出すことを勧めています。ネットワークの隔離（バックアップ領域に本番から直接到達できないこと）、認証の隔離（本番の管理者アカウントでバックアップ側にログインできないこと）、そして場所の隔離（同じ建物・同じ電源系統に依存していないこと）。この3つを表にして、それぞれ「できている・できていない」を埋めるだけで、自社の弱点は明確になります。

クラウド型とオンプレ型、タイ拠点ではどちらが現実的か

手段が決まると、置き場所の議論になります。クラウドバックアップ 費用の相場感を押さえたうえで、タイ拠点の条件に当てはめます。

料金の実際

公表されている料金例を整理すると、課金方式は大きく2つに分かれます。

一般的な相場感としては、PC1台あたり月1,000円前後から、サーバー1TBで月20,000円から50,000円台、ユーザー課金型は月300円から900円程度とされています。

この一覧から読み取るべきことが2つあります。1つは、ユーザー課金型のサービス間で価格に開きがあり、その要因の1つが保持期間だという点です。AvePoint Cloud Backupの3年保持と無制限保持の差が典型で、Veeam Data Cloud for Microsoft 365のように規模によって単価が動くものもあります。保持期間は、RPOではなく「いつ気づくか」で決まります。誤削除や内部不正は、数か月経ってから発覚することがあります。もう1つは、容量課金型でサーバー1TBの月額に20,000円から50,000円台という幅がある点です。同じ1TBでも、取得頻度・世代数・復旧時の転送料金の扱いで大きく動きます。見積を取るときは、容量だけでなく復旧時にかかる費用を必ず確認してください。平常時の保管料が安く、取り出しに高額な料金がかかる構成は、いざというときに復旧をためらう理由を作ります。

タイ拠点での判断軸

タイ拠点でクラウドかオンプレかを判断する軸は3つです。

1つ目は回線です。バックアップの取得はゆっくりでも構いませんが、復旧は速くなければ意味がありません。1TBのデータをクラウドから引き戻すのに何時間かかるか、実測してください。この時間がRTOを超えるなら、クラウドだけの構成は成立しません。表Aで基幹システムをクラウドとオンプレの二重化としているのは、この計算が理由です。手元のコピーから速く戻し、手元が失われた場合の最後の砦としてクラウドを使う、という役割分担になります。

2つ目は現地の運用要員です。オンプレの装置は誰かが物理的に面倒を見る必要があります。媒体の交換、装置の故障対応、ファームウェアの更新。現地に担当者が常駐していない拠点でオンプレ中心の構成を選ぶと、運用が止まったまま数か月経過することがあります。

3つ目は電源と設置環境です。停電と電圧変動は、装置の寿命と整合性の両方に影響します。オンプレを選ぶ場合、無停電電源装置と設置場所の空調は前提条件として費用に入れてください。

併用が基本形

結論としては、どちらかを選ぶ問題ではありません。復旧速度を稼ぐためのローカルと、独立性を確保するためのクラウドを併用するのが基本形です。この構成は3-2-1ルールの実装としても自然に成立します。判断すべきは「どちらか」ではなく、どの業務区分をどちらから戻すかです。

表B バックアップ体制の費用5層

費用を1本の見積で見ると、安い提案が「安い」のか「範囲が狭い」のかを判別できません。層に分けます。

モデル工場の前提

以下は、次の前提を置いたモデル工場の試算です。タイに拠点を持ち、ERP・生産管理システムのデータ量が1TB、Microsoft 365の利用ユーザーが40名、年2回のリストア訓練を実施する製造業を想定しています。

この金額はモデル工場の前提にもとづく試算であり、実勢価格を保証するものではありません。データ量、ユーザー数、拠点の構成、要求するRTOのいずれかが変われば、金額は大きく動きます。

各層の根拠と読み方

第1層は、前節で見た容量課金型の料金にもとづきます。サーバー1TBで月額20,000円という水準を12か月分計上して240,000円としています。ここはデータ量に比例するので、自社のデータ量を測れば置き換えられます。

第2層は、ユーザー課金型の料金にもとづきます。3年保持のサービスで1ユーザーあたり年3,840円という水準に、利用者40名を掛けて153,600円としています。保持期間を無制限に伸ばす選択をすれば、この層は上がります。

第3層は、リストア訓練と日常の運用工数です。ここを費用として明示していることが、この表の要点の1つです。訓練は「やろうと思えばできる作業」ではなく、担当者の時間を消費する業務です。金額として計上しないと、稟議上は安く見え、実行段階で「本業が忙しい」という理由で先送りされます。

第4層は、ディザスタリカバリ待機環境です。5層のうち最も金額が大きく、そして最も削られやすい層でもあります。削ると何が起きるかは、次の節で扱います。

第5層は、監査とPDPA対応の文書化です。年1回の外部レビューを想定しています。この層は技術ではなく説明責任のための費用で、後述するタイの法令要件に直結します。

削れる層と削れない層

限られた予算でどこから削るかという議論は必ず起きます。ここで注意すべきは、効果が乗っていない層は削られるということです。第4層のディザスタリカバリ待機環境は、平常時には何の効果も生みません。だから真っ先に候補に挙がります。

削るという判断自体は否定しません。ただし削るなら、削った結果としてRTOがどこまで延びるかを表Aに書き戻してください。待機環境を持たない構成では、障害時に機材の調達から始まります。タイでサーバー機材を調達して設置するまでの期間を考えると、基幹システムのRTO 4時間以内という設計は成立しなくなります。削るのは費用ではなく、RTOの約束です。 この対応関係を表に明記しないまま第4層だけを落とすと、体制図の上ではRTO 4時間のまま、実態は数週間という状態が残ります。

なお、この5層はバックアップ体制に限った切り出しです。システム全体の維持費の中でどの位置を占めるかは、業務システムの保守費用2026で扱っている保守費用の分解と合わせて見てください。バックアップだけを単独で稟議に載せると、金額の妥当性を判断する基準がなくなります。

タイの個人情報保護法（PDPA）とバックアップ体制の関係

バックアップとディザスタリカバリの議論は、技術の話として進みがちですが、タイでは法令要件と直接つながっています。

72時間という制約

タイの個人情報保護法（PDPA）は、データ管理者に対し、データ侵害を認知してから72時間以内に個人情報保護委員会（PDPC）へ報告することを義務付けています。さらに個人の権利に危険が及ぶ場合は、データ主体への通知もPDPCへの通知と同時に行う必要があり、対象が複数人にわたる場合はメディア等の公開チャネルを通じて行うことが求められます。

この72時間が、体制設計に具体的な要求を課します。報告するには、何が漏れたのかを特定しなければなりません。どのシステムのどのデータが、いつの時点で、どの範囲まで侵害されたのか。この特定作業は、侵害前の状態のデータが手元にあって初めて可能になります。つまりバックアップは、復旧の手段であると同時に、侵害範囲を特定するための証拠でもあります。

侵害を受けたサーバーをそのまま復旧作業で上書きしてしまうと、何が起きたのかを再構成する材料が消えます。復旧を急ぐあまり証拠が消え、72時間の報告に必要な情報が揃わない、という展開は現実に起こります。対策は単純で、復旧作業の前に、侵害された状態のディスクイメージを1本取るという手順を計画に入れておくことです。

ISO 27001の位置づけ

もう1つ押さえておくべきなのは、タイのデジタル経済社会省（MDES）がISO 27001の取得を、最低限のセキュリティ基準を満たす証拠として認めているという点です。認証を取ることが法令上の免罪符になるわけではありませんが、基準を満たしていることの説明手段として使えます。

実務的には、認証を取るかどうかより、ISO 27001が求める文書の型を借りるほうが役に立ちます。資産の一覧、リスク評価、対策の記録、そして事故発生時の手順。この4点が文書として存在していれば、72時間の報告に必要な情報の大半はそこから引けます。表Bの第5層で監査・PDPA対応文書化を層として立てているのは、この文書が「作れば終わり」ではなく、システム構成の変化に合わせて更新し続ける必要があるためです。

ディザスタリカバリとバックアップの線引き

ここで用語を整理しておきます。バックアップはデータのコピーを作ることであり、ディザスタリカバリは業務を別の場所で再開できるようにする体制です。前者はデータの話、後者は業務の話です。

タイの拠点で考えるべきディザスタリカバリの範囲は、システムだけではありません。洪水で工場そのものが操業できなくなった場合、どこで、誰が、どの業務を継続するのか。バックアップからデータを戻せても、動かす場所と人がいなければ業務は再開しません。第4層の待機環境を検討するときは、機材の話と同時に、その機材を誰がどこで操作するのかまで書いてください。

復旧訓練（リストアテスト）を「儀式」にしない仕組み

前節までの設計が正しくても、検証されていなければ最初のパターンに戻ります。訓練の話をします。

形骸化する典型的な経路

リストアテストは、放っておくと必ず形骸化します。経路は決まっていて、1年目は真剣にやり、2年目は前年の手順書をなぞり、3年目は「前回と同じ構成なので実施済みとする」という記録だけが残ります。担当者が代わると、手順書の内容と実際の構成が乖離していることにも気づかなくなります。

形骸化を防ぐ方法は、訓練を増やすことではありません。訓練の合否条件を数字で定義することです。

合否条件をRTO・RPOで書く

訓練の目的は「戻せた」ことの確認ではなく、「決めた時間内に戻せた」ことの確認です。したがって合否条件は表Aから直接引いてきます。基幹システムの訓練であれば、4時間以内に業務が再開できる状態まで到達したかどうかが合否です。到達できなければ不合格で、不合格なら手段か数字のどちらかを直します。

この形にすると、訓練の結果が設計にフィードバックされます。4時間で戻らなかったという結果は、二重化を追加するか、RTOを緩めるかの判断材料になります。合否のない訓練は、実施記録以外に何も生みません。

記録すべき4項目

訓練のたびに記録する項目を4つに固定してください。開始から業務再開までの実測時間、復旧できた時点のデータ（実測RPO）、途中で詰まった作業とその所要時間、そして手順書の記載と実際の作業が食い違った箇所です。

4つ目が最も価値があります。手順書との食い違いは、次の障害で必ず同じ場所で発生します。訓練直後に手順書を直すところまでを1セットにしてください。直さないまま次の訓練を迎えると、同じ食い違いを毎回発見することになります。

誰にやらせるか

もう1つの工夫として、手順書を書いた人以外に実施させるという方法があります。書いた人は行間を補って作業できてしまうため、手順書の不備が表面化しません。現地スタッフに手順書だけを渡して実施してもらうと、記載の曖昧さが一気に露出します。タイ拠点では、この方法が言語の問題も同時に洗い出してくれます。手順書が日本語だけで書かれていて、深夜に対応するのが現地スタッフだという構成は、それ自体が復旧時間のリスクです。

年2回という頻度は、表Bの第3層で前提にした水準です。全システムを毎回やる必要はありません。1回目は基幹システム、2回目は共有ファイルとメールというように、対象を分けて回すほうが現実的です。

生産管理システム・基幹システムに固有の論点 — 工場停止コストとの紐付け

一般的な情報システムのバックアップと、工場の基幹システムのバックアップには、決定的な違いが1つあります。止まると生産が止まるという点です。

停止コストを自社の数字で出す

RTOの妥当性を経営に説明するとき、最も強い根拠は停止コストです。ここは他社の平均値では意味がなく、自社の数字を出す必要があります。

計算に必要な材料は4つです。1つ目は、対象システムが止まったときに生産が停止する範囲。全ラインなのか、特定の工程だけなのか。2つ目は、その範囲の1時間あたりの生産高です。3つ目は、生産が止まっても発生し続ける費用、つまり人件費と設備の固定費です。4つ目は、納期遅延によって発生する追加費用で、特別便の輸送費や客先へのペナルティが該当します。

この4つを掛け合わせると、1時間あたりの停止コストが出ます。この数字と、表Bの第4層の年額を並べて初めて、待機環境を持つかどうかの判断ができます。停止コストが分からないまま「720,000円は高い」と判断するのは、比較対象のない判断です。

生産管理システム特有の復旧の難しさ

もう1つ、技術的な論点があります。生産管理システムは単体で動いていません。実績収集の端末、ハンディターミナル、ラベルプリンタ、計測器、上位の会計システム、客先とのEDI。これらが繋がって初めて業務が回ります。

したがって、データベースを戻しただけでは業務は再開しません。周辺の接続がすべて生きているか、接続先のシステムとデータの整合が取れているかを確認する必要があります。ここが一般的なファイルサーバーの復旧と大きく違う点です。訓練の合否条件を「データベースが戻ったこと」ではなく「業務が再開できたこと」に置くべき理由も、ここにあります。

復旧の順序を決めておく

複数のシステムが同時に落ちたとき、どれから戻すかを事前に決めておいてください。順序は表Aから導けます。RTOが短い区分から戻すのが原則ですが、依存関係も考慮します。認証基盤が戻らなければ他のシステムにログインできない、といった前後関係は先に洗い出しておく必要があります。

この順序表は、障害の最中に作れるものではありません。平常時に作り、訓練で妥当性を確認しておく対象です。

本社標準と現地拠点のズレ — 海外拠点で起きる3つの穴

日系のタイ拠点では、バックアップの方針が日本本社から降りてくることが多くあります。この構図で起きる穴が3つあります。

穴1 — 標準が現地の構成を想定していない

本社の標準は、本社のシステム構成を前提に書かれています。現地拠点にしか存在しないシステム、例えば現地の会計要件に対応した仕組みや、現地で導入した生産管理システムは、標準の対象範囲から外れていることがあります。外れていることが明示されていればまだよいのですが、多くの場合は言及がありません。言及がないものは、誰も守っていない状態になります。

対処は単純で、現地のシステム一覧を作り、本社標準のどの項目に該当するかを1つずつ突き合わせることです。該当しないものが見つかったら、それが現地で決めるべき範囲です。

穴2 — 報告が「実施している」で止まる

2つ目は報告の粒度です。本社への報告様式が「バックアップを実施しているか」の可否だけを問う形式になっていると、実施の質は伝わりません。前述のとおり、実施していることと復旧できることは別です。

報告様式に、直近の復旧訓練の実施日と実測RTO・実測RPOを追加してください。この3項目が入るだけで、報告は「やっているかどうか」から「戻せるかどうか」に変わります。本社側にとっても、拠点間の比較ができる形になります。

穴3 — 復旧の権限が現地にない

3つ目が最も深刻です。バックアップの管理権限や、復旧作業に必要な認証情報が本社側にしかなく、現地の判断で復旧に着手できない構成です。障害は時差を考慮して起きてはくれません。タイの深夜は日本の未明で、連絡がつくまでの数時間がそのままRTOに乗ります。

権限を全面的に現地に渡すことがセキュリティ上難しい場合もあります。その場合は、緊急時に限って使える手順を用意してください。封緘した認証情報を現地の金庫に保管し、使用したら事後報告する、といった運用でも構いません。平常時の統制と、緊急時の到達速度は、別々に設計するという考え方が必要です。

導入の順序 — 最初の90日

体制の見直しは、範囲を広げると着地しません。90日で区切った進め方を示します。

最初の30日 — 現状を数える

システムの入れ替えの話をせず、現状を数えます。数える対象は5つです。対象システムの一覧とそれぞれのデータ量。現在のバックアップの取得頻度と保持世代数。バックアップの保管場所と、そこへ到達できる管理者アカウントの数。直近1年間のリストア実施回数。そして、対象システムが止まったときに生産が停止する範囲です。

この5つは、既存の記録から拾える範囲で構いません。完璧な棚卸しを目指すと30日では終わりません。目的は精度ではなく、議論の土台を作ることです。

31日目から60日目 — 表を2枚作る

表Aの自社版と、隔離の3層の点検表を作ります。表Aは業務部門への聞き取りを伴うので、時間がかかるのはこちらです。営業・製造・購買・経理・品質から1名ずつ出して、同じ場で埋めてください。部門ごとに答えが違うことが分かるだけでも価値があります。

隔離の点検表は情報システム部門だけで作れます。ネットワーク・認証・場所の3層について、現状を「できている・できていない」で埋めます。埋まらない欄があれば、それは調べていない箇所です。

61日目から90日目 — 1系統で訓練する

作った表を持って、最もRTOが厳しい1系統だけで復旧訓練を実施します。全システムでやろうとしないでください。1系統でも、実際にやると想定外のことが5つや6つは出てきます。

訓練の合否は表Aの数字で判定します。不合格だった場合、その原因が手段の不足なのか、数字が非現実的なのかを切り分けます。切り分けた結果が、そのまま次の投資判断の材料になります。この段階まで来て初めて、製品やサービスの見積を取る意味が出てきます。

90日以降

90日で1系統の訓練まで到達したら、残りの区分に順次広げます。同時に、表Bの5層に自社の数字を入れて年額を算出し、停止コストと並べた資料を作ります。この資料が、翌年度の予算要求の根拠になります。

よくある失敗5つ

体制構築で繰り返し見られる失敗を整理します。

このうち影響が大きいのは1つ目と2つ目です。1つ目は、問題があること自体に気づけない状態を作ります。2つ目は、気づいたときにはもう手段が残っていない状態を作ります。どちらも、平常時の指標では検出できません。

4つ目については補足が必要です。予算の制約で待機環境を持てない拠点は現実に多くあります。問題は持たないこと自体ではなく、持たないまま体制図のRTOを書き換えないことです。書き換えていれば、障害時に経営が下す判断も変わります。

よくある質問（FAQ）

業務システムのバックアップ体制はなぜ重要ですか？

バックアップを取ることが重要なのではなく、そこから復旧できることが重要です。JIPDECの企業IT利活用動向調査2026では、ランサムウェアの感染経験率が45.8%、身代金を支払わずに復旧できなかった割合が13.0%で、前回調査の10.5%から上昇しています。製造業では感染経験率が57.1%とさらに高く、身代金を支払った後も復旧に失敗した割合が18.2%でした。支払いは復旧の保証になりません。復旧できる状態を自力で確保しておくことが、事業継続の前提になります。

RTOとRPOの違いは何ですか？

RPOはどの時点まで戻れればよいか、つまり失われても業務が成立するデータの範囲を示します。RTOはどれだけの時間で業務を再開するかを示します。RPOを短くするには取得頻度を上げる必要があり、RTOを短くするには復旧先の環境と手順をあらかじめ用意しておく必要があります。この2つは業務区分ごとに変えるのが原則で、本記事の設計表では基幹システムをRPO 1時間以内・RTO 4時間以内、共有ファイル・図面をRPO 24時間以内・RTO 翌営業日としています。

クラウドバックアップの費用はどれくらいですか？

公表されている料金例では、容量課金型で100GBが月額3,000円から（年36,200円）、1TBが月額20,000円からという水準です。ユーザー課金型のMicrosoft 365向けサービスでは、1ユーザーあたり年3,840円からのものから、年9,822円から10,913円のものまで幅があります。一般的な相場感としては、PC1台あたり月1,000円前後から、サーバー1TBで月20,000円から50,000円台、ユーザー課金型は月300円から900円程度とされています。本記事のモデル工場試算では、ストレージ利用料とMicrosoft 365バックアップに加えて訓練工数・待機環境・監査文書化まで含めた年額を1,669,600円としています。

バックアップとディザスタリカバリは何が違うのですか？

バックアップはデータのコピーを作ることで、ディザスタリカバリは業務を別の場所で再開できるようにする体制です。前者はデータの話、後者は業務の話になります。バックアップからデータを戻せても、動かす機材と場所と人がいなければ業務は再開しません。本記事の費用5層で第4層としてディザスタリカバリ待機環境を独立させているのは、この層が第1層・第2層のストレージ費用とは性質の違う投資だからです。タイの拠点では、洪水などで工場そのものが操業できなくなる場合まで含めて範囲を決めてください。

復旧訓練はどのくらいの頻度で行うべきですか？

本記事のモデル工場では年2回を前提にしています。ただし全システムを毎回やる必要はなく、1回目は基幹システム、2回目は共有ファイルとメールというように対象を分けて回すほうが現実的です。頻度より重要なのは合否条件です。訓練の目的は戻せたことの確認ではなく、決めた時間内に戻せたことの確認なので、合否は表Aで定めたRTO・RPOから直接引いてきます。加えて、手順書を書いた人以外に実施させると、記載の曖昧さと言語の問題が同時に洗い出せます。

まとめ

バックアップが動いていることと、復旧できることは別物です。ジョブの成功通知は、何時点に戻れるか、何時間で業務を再開できるか、誰が実行できるかという問いに1つも答えていません。JIPDECの企業IT利活用動向調査2026で、身代金を支払わずに復旧できなかった割合が前回調査の10.5%から13.0%へ上昇しているという事実は、バックアップの普及と復旧能力が同じ方向に進んでいないことを示しています。

タイ拠点が例外である理由もありません。2024年7月から9月に公表されたランサムウェア攻撃事例1,230件超のうち13%がアジア太平洋地域で発生し、タイ国内の被害は2023年に2022年比1.5倍へ増加しました。日系製造拠点の被害も、タイ・マレーシア・インドネシア・ベトナムで複数年にわたって報告されています。製造業の感染経験率は57.1%で、身代金を支払った後も復旧に失敗した割合は18.2%です。

復旧できなかった原因は、検証していない、隔離されていない、手順が属人化している、の3つに集約されます。逆にニチレイグループの事例では、本番ネットワークから論理的・物理的に分離されたバックアップシステムが生存していたことと、検知直後の全社遮断によって、2026年7月13日の検知から4日後の7月17日に出荷業務の段階再開へ入り、約1週間で通常稼働の目処が立ちました。手書き伝票による縮退運用の併走も、停止範囲の縮小に効いています。

設計の中心はRTOとRPOです。全社一律ではなく業務区分ごとに数字を変え、基幹システムはRPO 1時間以内・RTO 4時間以内でクラウドとオンプレの二重化とイミュータブルスナップショット、生産ライン制御・SCADAはRPO 24時間以内・RTO 翌営業日でローカルNASと週次のクラウド同期、共有ファイル・図面は同じ水準でクラウドバックアップの3世代保持、メール・グループウェアは数時間以内でSaaS向けバックアップサービス、という組み立てになります。

費用は5層に分かれます。モデル工場の試算では、ストレージ利用料240,000円、Microsoft 365バックアップ153,600円、リストア訓練・運用工数256,000円、ディザスタリカバリ待機環境720,000円、監査・PDPA対応文書化300,000円で、合計1,669,600円です。このうち削られやすいのは第4層ですが、削るのは費用ではなくRTOの約束であることを、表に書き戻してください。

タイではPDPAの要件も体制に直接効きます。侵害の認知から72時間以内のPDPCへの報告義務があり、報告には侵害範囲の特定が必要です。復旧を急ぐ前に侵害された状態のイメージを1本取る、という手順を計画に入れてください。MDESがISO 27001を最低限のセキュリティ基準を満たす証拠として認めていることも、文書化の型を選ぶうえで参考になります。

したがって、明日から着手すべきことは製品比較ではありません。対象システムとデータ量を数えること、業務区分ごとのRTO・RPOを業務部門と合意して1枚の表にすること、ネットワーク・認証・場所の3層で隔離の状態を点検すること、そして最もRTOが厳しい1系統で復旧訓練を実施し、合否を数字で判定すること。この4つが埋まってから見積を取れば、各社の提案が同じ土俵に乗ります。

自社のRTO・RPOをまだ決めていない段階でも、現在のバックアップ構成を一緒に点検して、隔離の3層のどこに穴があるかを確かめるところだけを見る、という関わり方で構いません。TOMAS TECHはタイの日系製造業向けに、現状の実測、体制の設計、製品選定の技術的助言、復旧訓練の設計と実施までを一貫してお手伝いしています。点検の結果、既存の仕組みの運用を直すだけで足りると判明することもありますので、新しい製品の導入を前提にしないご相談でもお問い合わせからお気軽にお声がけください。

参考情報

• 企業IT利活用動向調査2026 プレスリリース — JIPDEC 調査期間2026年1月16日から1月20日、従業員50名以上の国内企業1,107社、ランサムウェア感染経験率45.8%、製造業57.1%、身代金を支払わずに復旧できなかった割合13.0%で前回調査は10.5%、復旧期間は1週間から1か月以内が34.7%で最多、データ喪失・破損51.3%、機密情報漏えい35.1%で前回調査は29.3%、製造業で身代金支払い後も復旧失敗18.2%
• ASEANにおけるランサムウェア被害の動向 — リスクマネジメントNavi Check Point Software Technologiesの集計で2024年7月から9月の公表事例1,230件超のうち13%がアジア太平洋地域、タイ国家サイバーセキュリティ局によるタイ国内被害の2023年は2022年比1.5倍、日系製造拠点の被害はタイ2022年から2024年・マレーシア2022年から2023年・インドネシア2021年と2024年・ベトナム2024年
• ニチレイのサイバー攻撃対応とバックアップ — london3.jp 2026年7月13日午前6時50分頃の検知と緊急対策本部設置、グループ全体のシステム緊急遮断、本番ネットワークから論理的・物理的に分離されたバックアップシステムの生存、2026年7月17日からの出荷業務段階再開、約1週間後に通常稼働の目処、手書き伝票による縮退運用
• タイ個人情報保護法 PDPA の解説 — LOGON International データ侵害の認知から72時間以内のPDPCへの報告義務、個人の権利に危険が及ぶ場合のデータ主体への通知、複数人が対象の場合の公開チャネルによる通知、デジタル経済社会省がISO 27001を最低限のセキュリティ基準を満たす証拠として認めていること
• クラウドバックアップの費用相場 — セキュリティソフト比較コンペ 容量課金型は100GBで月額3,000円から・年36,200円、1TBで月額20,000円から、Veeam Data Cloud for Microsoft 365は年9,822円から10,913円／ユーザー、AvePoint Cloud Backupは3年保持年3,840円から・無制限保持年6,000円から、SysCloudは年5,890円／ユーザー、PC1台あたり月1,000円前後から、サーバー1TBで月20,000円から50,000円台、ユーザー課金型は月300円から900円程度