クラウドかオンプレか、ではない——業務システムとNASを安全につなぐ設計

「新しい業務システムはクラウドで作りたい。でも、社内に何十TBもあるファイルまで全部クラウドへ移す必要があるのか」

基幹システムや業務システムを刷新すると、かなりの確率でこの問題にぶつかります。

顧客情報、案件情報、進捗、検索条件、権限、操作履歴はクラウドのデータベースに置いた方が扱いやすい。一方で、PDF、画像、動画、図面、スキャンデータなどの原本ファイルは容量が大きく、社内LANで開いた方が速い場合があります。

そこで「クラウドかオンプレミスか」の二択で考えると、話がこじれます。

私の結論は、検索・権限・監査はクラウド、重い原本は社内NAS、災害復旧用のコピーは別拠点、最後の一線はオフラインで守るです。

これは中途半端な折衷案ではありません。データの役割ごとに、最適な置き場所を分ける設計です。

この記事では、クラウド業務システムとローカルNASを安全につなぐ仕組み、RAIDとバックアップの違い、遠隔地からファイルを開く速度、必要容量の決め方、運用時に見落としやすい復旧テストまでを整理します。

特定メーカーの製品を推す話ではありません。QNAP、Synology、TrueNASなど、どの選択肢でも判断できる土台を作ります。

先に全体像——4つの役割を混ぜない

最初に、構成全体を一枚で整理します。

推奨構成は、次の4層です。

層	主な役割	保存するもの	日常利用
クラウド業務システム	検索、権限、案件管理、監査	ファイル名、保存先、案件ID、版、権限、操作履歴	全拠点・外出先から利用
メインNAS	原本ファイルの保管と高速アクセス	PDF、画像、動画、図面、スキャンデータ	社内LANを中心に利用
遠隔バックアップNAS	拠点災害と機器故障への備え	メインNASの世代付きコピー	原則、復旧時のみ利用
オフライン保管	ランサムウェア等への最後の防壁	重要データの定期コピー	通常時は切り離す

重要なのは、4層を「同じデータを4か所に置く話」と理解しないことです。

クラウド業務システムは、ファイルの中身そのものを抱えなくても構いません。ファイルを見つけ、開く権限を判断し、誰がいつ参照したかを記録する司令塔になればよい。

メインNASは、巨大なファイルを社内LANで素早く配ることに集中します。

遠隔バックアップNASは、名古屋で火災や水害が起きても東京側から復旧できるようにするものです。普段から全社員が同時編集するための装置ではありません。

オフライン保管は、攻撃者やランサムウェアからネットワーク越しに触れない状態を作るためのものです。

役割を分けると、構成を必要以上に複雑にせず、事故時の判断も明確になります。

業務システムにはファイル本体ではなく「所在と意味」を持たせる

クラウド側のデータベースには、ファイルを業務上の情報と結びつけるメタデータを保存します。

たとえば、次のような情報です。

• 顧客ID
• 案件ID
• 文書種別
• ファイル名
• NAS上の相対パス
• ファイルサイズ
• 更新日時
• 版番号
• 閲覧できる部署や役職
• 登録者
• ハッシュ値
• 保管期限

ここで大切なのは、クラウドDBにWindowsのドライブ文字だけを保存しないことです。

Z:\顧客\A社\契約書.pdf のような値は、端末ごとにドライブ割り当てが違えば開けません。代わりに、customers/123/contracts/2026-001.pdf のような相対パスを正本にし、端末側で利用可能なNASルートと組み合わせます。

業務システムで「契約書を開く」を押したときの流れは、次のようになります。

1. クラウド側でログイン利用者の権限を確認する
2. 案件IDに紐づくファイル情報を取得する
3. その端末が社内LANまたはVPN経由でNASへ到達できるか確認する
4. 相対パスから実際のファイルパスを組み立てる
5. OSの標準アプリでファイルを開く
6. 成功・失敗と利用者を監査ログに残す

この仕組みにすると、利用者は「クラウドDB」と「NAS」を意識しません。案件画面から必要なファイルを開くだけです。

ただし、一般的なWebブラウザにはセキュリティ制約があります。ブラウザ上のボタンから任意のローカルファイルやSMB共有を直接開く動作は、OS、ブラウザ、社内ポリシーによって制限されます。

実装方法は、専用の小さなデスクトップアプリ、カスタムURLスキーム、端末内の連携エージェント、または社内ポータル用の信頼済み設定などから選びます。

「パスをDBに保存すれば終わり」ではなく、安全に開くための端末側連携までが仕様です。

社内では速い。社外では回線速度が上限になる

ファイルを開く速さは、NASのCPUやディスクだけでは決まりません。

最も大きく効くのは、利用者とNASの間のネットワークです。

社内LANから開く場合

社内で1GbEの有線LANを使う場合、理論上限は約125MB/秒です。実効速度はプロトコル、端末、ディスク、同時利用数などで下がりますが、PDFやOffice文書を開くには十分なことが多いでしょう。

10GbEなら理論上限は約1.25GB/秒です。ただし、NASだけ10GbEにしても速くなりません。スイッチ、配線、端末側NIC、ディスク構成まで含めて経路全体が対応する必要があります。

小さなPDFやExcelが中心なら、1GbEでも体感差が出にくい場合があります。数GBの動画、巨大画像、設計データを複数人が扱うなら、10GbEの価値が上がります。

VPN経由で開く場合

支社や自宅から本社のNASへ接続する場合、速度の上限は主に次の4つで決まります。

1. NAS拠点側のインターネット上り速度
2. 利用者側の下り速度
3. VPN装置の暗号化処理性能
4. 拠点間の遅延

たとえば本社側の上りが100Mbpsなら、理論上は約12.5MB/秒です。1GBのファイルを転送するだけでも理論値で約80秒かかり、実際にはさらに時間が必要です。

このため、遠隔利用では「ファイルを直接編集する」「一度端末へダウンロードして編集する」「プレビューだけクラウドで見る」を文書種別ごとに分けるべきです。

小さなPDFやOffice文書はVPN越しでも実用的です。動画や巨大な設計データを日常的に扱うなら、各拠点へ作業用コピーを置く、VDIやリモートデスクトップでNAS近くのPCを操作する、対象データだけクラウド配信する、といった別案が必要です。

つまり、VPNを作ればどこでも社内LANと同じ速さになるわけではありません。

この限界は、導入前に利用ファイルの実測サイズと回線速度で確かめます。

VPNは「NASをインターネットに公開しない」ために使う

社外からNASへアクセスしたいとき、NASの管理画面やSMBポートをそのままインターネットへ公開する設計は避けます。

基本はVPNです。

拠点間を常時接続するなら、本社と支社のルーター同士をSite-to-Site VPNで結びます。利用者は特別な操作をせず、支社オフィスから本社のNASへ社内ネットワークのように到達できます。

在宅勤務や外出先では、端末からVPNへ接続します。WireGuard、IPsec、Tailscaleなど選択肢はありますが、製品名より次の条件が重要です。

• 多要素認証を使える
• 退職者や紛失端末をすぐ無効化できる
• 利用者ごとに接続権限を分けられる
• 接続ログを残せる
• NAS管理画面とファイル共有の到達範囲を分離できる
• OSとVPN装置を継続的に更新できる

VPNは暗号化された通路です。通路を作るだけで、接続後の権限が自動的に安全になるわけではありません。

「VPNへ入れた人はNASの全フォルダを見られる」という状態にせず、NAS側でも部署、案件、役職に応じた最小権限を設定します。

クラウド業務システムの権限とNASの権限も、可能な限り同じ台帳から管理します。片方だけ退職処理され、もう片方にアクセスが残る状態を防ぐためです。

RAIDはバックアップではない

ここは、NAS検討で最も誤解されやすいところです。

RAID1は、2台のディスクへ同じ内容を書き、片方が故障しても運用を続ける仕組みです。RAID5、RAID6、RAID10なども、性能、容量効率、許容故障数のバランスを変える技術です。

しかし、利用者が誤ってファイルを消せば、その削除はRAID内の全ディスクへ反映されます。ランサムウェアがファイルを暗号化すれば、暗号化された状態が正しく複製されます。NAS本体が盗難、火災、水害に遭えば、同じ筐体内のディスクがまとめて失われます。

RAIDが守るのは、主にディスク故障時の可用性です。

バックアップが守るのは、過去の状態へ戻す能力です。

仕組み	主に守る事故	同じ筐体の故障	誤削除	ランサムウェア	拠点災害
RAID	ディスク故障	△	×	×	×
スナップショット	誤削除、上書き	△	○	△	×
遠隔バックアップNAS	本体故障、拠点災害	○	○	△	○
オフライン・イミュータブル保管	ランサムウェア、管理者権限侵害	○	○	○	配置次第

スナップショットも万能ではありません。

同じNAS内だけにあるスナップショットは、NAS本体の物理故障や災害では失われます。管理者権限を奪われ、スナップショットまで削除される可能性もあります。

遠隔NASへの同期も、単なるリアルタイムミラーでは不十分です。誤削除や暗号化を即座に相手へ反映すると、事故まで複製します。

バックアップ先には世代を持たせ、削除反映を遅らせ、通常利用者から直接触れない権限にします。可能なら書き換え不能期間を設定します。

第2NASは「同期先」ではなく「復旧元」として設計する

本社と支社に同じクラスのNASを置き、双方で同じフォルダを編集する構成は技術的には可能です。

ただし、両拠点で同じファイルを同時編集すると競合が起きます。SMBのファイルロックが拠点をまたいで期待どおり動くとは限りません。回線断中の変更を再同期すると、どちらを正とするか判断が必要になります。

利用者に意識させない双方向同期は魅力的ですが、運用難度が一段上がります。

最初の構成としては、次の方が堅実です。

• メインNASを一つに決める
• 全拠点の利用者は、社内LANまたはVPN経由でメインNASを使う
• 第2NASは遠隔バックアップ専用にする
• 第2NASへ一般利用者の書き込み権限を与えない
• 障害時だけ、決めた手順で第2NASへ切り替える

この構成なら「今どちらが正本か」が明確です。

双方向のアクティブ・アクティブ構成が必要なのは、遠隔拠点でも大容量ファイルを日常的に高速編集し、回線断中も業務を止められない場合です。その場合は、単純なフォルダ同期ではなく、分散ファイルシステム、ファイルロック、競合解決、フェイルオーバー、切り戻しまで設計します。

技術的に可能かどうかではなく、その複雑さを5年間運用する人がいるかで判断します。

テープを残すか、第3NASへ置き換えるか

テープは古い技術に見えますが、ネットワークから物理的に切り離せることが大きな強みです。

CISAのランサムウェア対策ガイドは、重要データのオフラインかつ暗号化されたバックアップを維持し、災害復旧を想定して可用性と完全性を定期的にテストするよう勧めています。多くのランサムウェアが、接続可能なバックアップを探して削除・暗号化しようとするためです。

出典: CISA #StopRansomware Guide

NIST SP 800-209も、ストレージのデータ保護を、バックアップと復旧、アーカイブ、レプリケーション、イミュータビリティ、継続的データ保護、スナップショットなどに分けています。つまり「コピーがある」だけでなく、目的別に保護方式を組み合わせる考え方です。

出典: NIST SP 800-209: Security Guidelines for Storage Infrastructure

テープを残すべき条件は、次の通りです。

• 長期間保存する必要がある
• 過去データの参照頻度が低い
• 取り出しに時間がかかっても業務影響が小さい
• 定期的な搬送、保管、台帳管理を続けられる
• 実際に復元できるか定期テストできる

反対に、古いファイルを頻繁に参照するなら、テープだけへ移すと日常業務が遅くなります。テープからの復元は、NAS上のファイルをクリックして開く体験とは違います。

第3NASへ置き換える場合は、「もう1台オンラインで置けばテープと同じ」とは考えません。普段はネットワークから切り離す、バックアップ専用資格情報を使う、イミュータブル期間を設ける、管理者権限を分離するなど、オフラインに近い性質を作る必要があります。

運用担当者が少ない組織では、遠隔第2NASに加えて、月次などで暗号化したオフラインコピーを保管する構成が現実的です。テープを継続できる体制がすでにあるなら、急いで捨てる理由はありません。

容量は「今のディスク本数」から決めない

NASの見積もりで、最初から144TB、192TBといった製品容量を比較しても、必要量は決まりません。

先に確認すべきなのは、現状データの中身です。

1. 現在の実使用量
2. 年間増加量
3. ファイル種別ごとの増加率
4. 古いデータの参照頻度
5. 保存義務と保存年数
6. スナップショットの保持期間
7. バックアップ世代数
8. 障害時に必要な空き容量

単純化した計算式は、次のようになります。

必要実効容量
= 現在使用量
+ 5年間の増加見込み
+ スナップショット・版管理分
+ 運用余裕

たとえば現時点の実使用量が30TBではなく18TBで、年間3TBずつ増え、5年分で15TB、履歴と余裕を40%見るなら、必要実効容量は約46TBです。

一方、動画や高解像度スキャンの運用が始まり、年間増加量が10TBへ上がるなら、同じ5年でも必要容量は大きく変わります。

ここで「古いデータをテープだけに移す」という判断が効いてきます。

ほとんど参照しないデータをアーカイブへ移せば、メインNASを必要以上に大きくしなくて済みます。ただし、検索結果から古いファイルを選んだときに「現在はアーカイブ保管中。復元依頼が必要」と分かるUIと運用が必要です。

容量削減は、単なるファイル削除ではありません。オンライン、ニアライン、オフラインの3段階で、取り出し時間を設計することです。

RAID構成は容量効率だけで決めない

大容量HDDを使うNASでは、ディスク1台の再構築に長い時間がかかります。再構築中は他のディスクにも負荷がかかり、さらに故障するとデータを失う可能性があります。

そのため、2台だけのRAID1をそのまま大容量化するより、複数台構成で2台故障まで耐えるRAID6相当、またはメーカー独自の二重パリティ構成を候補にします。

ただし、正解は常にRAID6ではありません。

構成	長所	注意点	向く状況
RAID1	単純、2台で構成可能	容量効率50%、拡張性が低い	小容量、台数を増やせない
RAID5相当	容量効率がよい	大容量では再構築中の二重故障リスク	別バックアップが強く、停止許容度が高い
RAID6相当	2台故障に耐える	容量効率と書込性能が下がる	大容量、5年以上の運用
RAID10	性能と再構築の予測性	容量効率50%	高いI/O性能が必要

業務文書中心のファイルサーバーで、ディスク本数を確保できるなら、RAID6相当を基準に検討するのが分かりやすいでしょう。

ホットスペアを1台置くか、故障時に保守会社が何時間で交換するか、交換用ディスクを現地保管するかも同時に決めます。

RAIDレベルだけを選び、故障検知メールが届く相手や交換手順が決まっていなければ、実運用では弱いままです。

「NASを買う」ではなく、復旧時間を買う

NASの比較表では、CPU、メモリ、ベイ数、最大容量、10GbEポートが目立ちます。

しかし、経営上の本当の論点は別です。

• 故障を何分で検知できるか
• 何時間まで業務停止を許容できるか
• どの時点のデータまで戻れればよいか
• 復旧作業を誰が行うか
• 夜間・休日に誰へ連絡するか
• 交換部品がどこにあるか
• バックアップから本当に戻せるか

ここで使う指標がRTOとRPOです。

RTOは、どれくらいの時間で業務を戻す必要があるか。RPOは、どれくらい前までのデータ損失を許容するかです。

たとえば「半日止まってもよい、前日夜の状態へ戻ればよい」なら、日次バックアップでも成立するかもしれません。

「1時間止まると顧客対応が止まり、失ってよい更新は15分まで」なら、構成も回線も保守契約も変わります。

24時間オンサイト保守が必要かどうかも、安心感ではなくRTOで決めます。

夜間に止まっても翌営業日に復旧すればよい会社が、最高額の24時間保守を付けても使わない可能性があります。反対に、休日も止められない業務なら、保守だけでなく冗長電源、UPS、予備回線、交換部品、遠隔監視まで必要です。

私が3,000万円のシステム開発で学んだこと

私は以前、外部の開発会社へ約3,000万円を投じて業務システムを作りました。要件定義に3か月、開発に6か月かけましたが、完成したものは現場で使い続けられず、最終的にExcelへ戻りました。

失敗の原因は、コードが書けなかったことではありません。

「誰が正本を持つか」「例外業務をどう扱うか」「導入後に誰が改善するか」「問題が起きたとき誰が直すか」が、システムの外に残っていたことです。

NAS設計も同じです。

高性能な機器を買って、RAIDを組んで、VPNをつないだだけでは運用は完成しません。

• 新しい社員の権限は誰が登録するか
• 退職者のアクセスをいつ止めるか
• フォルダ構成を誰が変更できるか
• 容量増加を誰が毎月確認するか
• バックアップ失敗を誰が受け取るか
• 復旧テストをいつ行うか
• 障害時にクラウド業務システム側のパスをどう切り替えるか

これらを決めて初めて、会社の仕組みになります。

700万行のAI開発をしても、物理世界は消えない

私はAI支援を使い、累計700万行を超えるコードを生成してきました。

AIによって、業務画面、検索、権限、監査ログ、連携処理を作る速度は大きく上がりました。以前なら見積もりと会議に時間を使っていた部分を、実際に動く画面で確認しながら進められます。

しかし、コードが速く書けても、HDDの故障確率は下がりません。インターネット回線の上り速度も、停電も、火災も、ランサムウェアも消えません。

むしろ開発が速くなったからこそ、物理インフラと運用設計がボトルネックとして目立つようになりました。

AIでシステムを作れる時代に差がつくのは、画面を早く増やすことではありません。

クラウド、社内ネットワーク、ファイル保管、バックアップ、担当者の運用を一つの業務としてつなげられるかです。

導入は6段階で進める

いきなりNASを発注する前に、次の順で進めます。

1. 現物を確認する

現在のサーバー型番、ディスク型番、本数、RAID構成、実使用量、空き容量、ファイルシステム、UPS、ネットワーク速度、バックアップ装置、保守契約を確認します。

口頭で聞いた「30TB」が、物理容量なのか実効容量なのか、現在使用量なのかで見積もりは変わります。

2. データを分類する

ファイル種別、機密度、更新頻度、参照頻度、保存義務、1ファイルの最大サイズを集計します。

オンラインで必要なもの、アーカイブでよいもの、廃棄可能なものを分けます。

3. 復旧目標を決める

RTOとRPOを業務ごとに決めます。

全ファイルを同じ基準で守る必要はありません。契約書と一時書き出し動画では、止められない時間も保存年数も違います。

4. 小さく検証する

代表的なファイルを使い、社内LAN、東京拠点、在宅VPNで実測します。

業務システムのボタンからファイルを開く連携も、最初に数台で検証します。ブラウザ制約や端末設定は、机上設計だけでは見落としやすい部分です。

5. バックアップと復旧を作る

メインNAS、スナップショット、遠隔NAS、オフライン保管を設定し、バックアップ成功通知だけでなく復元テストを行います。

小さなファイル1件、フォルダ単位、NAS全体の3段階で復旧手順を確認します。

6. 切り替えと運用を定着させる

旧ファイルサーバーをすぐ廃棄せず、読み取り専用期間を設けます。新旧の保存先が混在しないよう、切り替え日と正本を明示します。

月次で容量、ディスク状態、バックアップ、VPNアカウントを確認し、半年または年1回は復旧訓練を行います。

NASだけでなく、クラウドDBも復旧対象にする

ハイブリッド構成では、NASのバックアップに意識が集中しがちです。

しかし、クラウド業務システム側のデータベースが失われると、ファイル本体が残っていても、どの顧客・案件・文書種別に紐づくのか分からなくなる可能性があります。

クラウドDBには、ファイルの所在、意味、権限、履歴が入っています。NASには原本があり、クラウドDBには原本を業務として使うための文脈があります。どちらか片方だけでは、元の業務へ戻せません。

そのため、復旧単位は次のセットで考えます。

• クラウドDBの時点復旧または定期バックアップ
• NAS上のファイルとスナップショット
• DBとファイルを対応させるID・相対パス
• 認証・権限設定
• VPN、端末連携、通知などの設定情報
• 暗号鍵、復旧用アカウント、緊急連絡先

クラウドサービスに自動バックアップ機能があっても、保持期間、復旧方法、復旧に必要な権限、別リージョンや別アカウントへのコピー可否を確認します。

「クラウドだから消えない」ではなく、クラウド側も自社のRTO・RPOに合わせて戻せるかが判断基準です。

復旧訓練は3つの事故で試す

復元テストは、ファイルを1件戻して終わりにしません。

少なくとも、次の3つのシナリオを試します。

誤削除

利用者が案件フォルダを削除した想定で、スナップショットから元の場所へ戻します。復元後に業務システムのリンクから開けるか、権限が保たれているかまで確認します。

ランサムウェア

メインNASと接続可能なバックアップが使えない前提で、遠隔またはオフラインの健全な世代を選びます。感染端末をネットワークへ戻さず、クリーンな環境で復元する手順を確認します。

拠点停止

メインNAS、ネットワーク、建物を使えない前提で、第2NASとクラウド業務システムから最小限の業務を再開します。DNS、VPN、ファイルパスの切り替え、利用者への案内、切り戻しまで時間を測ります。

訓練で見るのは、復元ボタンが動くかだけではありません。

誰が判断し、誰が権限を持ち、どの連絡先へ電話し、何分で顧客対応を再開できたかを記録します。目標時間を超えた工程が、次に改善すべき本当のボトルネックです。

この構成にも限界はある

クラウド業務システムとNASのハイブリッド構成は、万能ではありません。

まず、クラウドだけで完結する構成より、管理対象が増えます。クラウドDB、NAS、VPN、バックアップ、端末連携のそれぞれに更新と監視が必要です。

次に、遠隔利用の速度は回線に依存します。大容量ファイルを複数拠点で常時編集する業務では、メインNAS一極集中が合わない場合があります。

さらに、クラウド上の権限とNAS側の権限を別々に管理すると、設定のずれが起きます。ID連携や定期照合を含めないと、退職者権限や異動後のアクセスが残ります。

そして、バックアップがあっても復旧テストをしていなければ、戻せる保証はありません。暗号鍵、管理者パスワード、アプリの設定、ファイルパス情報が欠けると、ファイルだけ戻っても業務システムと再接続できません。

NISTがストレージ保護で「restoration assurance」を重視するのは、このためです。保存したかどうかではなく、必要な時に正しく復元できるかを確かめる必要があります。

経営者が最初に答えるべき10の質問

最後に、製品比較より先に決める質問を置きます。

1. 現在の実使用量は何TBか
2. 1年間で何TB増えているか
3. 5年以上前のファイルを月に何回参照するか
4. 最大ファイルサイズと主なファイル種別は何か
5. 遠隔拠点で大容量ファイルを直接編集するか
6. 何時間の停止まで許容できるか
7. 何時間分の更新まで失ってよいか
8. 火災・水害時にどの拠点から復旧するか
9. ランサムウェアから切り離されたコピーがあるか
10. 半年後も監視・権限・復旧テストを続ける担当者は誰か

この10問に答えれば、必要なベイ数、実効容量、RAID構成、回線、保守、テープ継続の判断がかなり具体的になります。

反対に、答えがないまま最大容量と価格だけを比べると、高すぎる機器を買うか、復旧できない安い構成を買うかのどちらかになりがちです。

クラウドかオンプレかを選ぶのではありません。

何を速く使い、何を安全に守り、事故時にどこから戻すかを選ぶ。

その結果として、クラウド業務システム、メインNAS、遠隔バックアップNAS、オフライン保管の役割が決まります。

IIWAYO.TECHでは、既存システム、ファイルサーバー、ネットワーク、現場運用を一緒に確認し、業務システムの画面から実際のファイルを安全に開けるところまで設計・実装しています。

AIセミナーやクラウド導入は入口です。入口から先の、データ移行、権限、バックアップ、復旧、現場定着までつながって初めて、会社の資産になります。

AI・業務システム開発について見る

BANSOU CTO™について見る

現在の構成と更新計画を相談する

---

伊藤翔太

株式会社IIWAYO.TECH 代表取締役 / 株式会社リサスティー 代表取締役