NAS・ファイルサーバーの見直し：クラウド移行と買い替えの判断基準

NAS・ファイルサーバーを見直すきっかけには、容量が足りない、機器の保守期限が近い、社外や在宅から使いたい、誰がどのフォルダを見られるか分からない、業務ソフトが決まった場所のファイルを読み書きしている、といったものがあります。機器を選ぶ前に、これらを業務上の困りごととして整理します。

NASは、ネットワーク経由でファイルを保存・共有する機器で、社内のファイルサーバーとして使われることもあります。クラウドの保存・共有サービスとは仕組みも得意な使い方も異なるため、同じ種類の製品として容量と価格だけで比べることはできません。

容量が足りることと、必要な業務で使えることは別です。まず対象の業務と部署を決めて困っていることを整理し、保存しているファイルを次の3つに分けて考えます。

• 共同で編集する文書：複数の人が開き、コメントや修正を加える文書
• 業務ソフトが参照・更新するファイル：業務ソフトやスクリプト、複合機のスキャン保存などが、決まった場所を読み書きするファイル
• 保管が中心の資料：参照は少ないものの、一定の期間は残す必要がある資料

すべてをクラウドへ移すこと自体を目的にはしません。用途によって、更新・移行・併用の向き不向きが変わります。既存の機器を残す場合も、更新の時期、メーカーのサポート、バックアップ、管理の担当は確認します。

選択肢は、NASを更新する、クラウドへ移す、用途ごとに分けて併用する、の大きく3つです。クラウドは、使っている契約やサービスによって候補が分かれます。次の表で、選択肢ごとに先に確認する制約と、移した後も残る運用を比べます。表のSMBは、Windowsの共有フォルダなどで使われるファイル共有の仕組みです。

表は横にスクロールできます →

この表は候補を絞るための入口で、○×の採点で製品を決めるものではありません。選択肢は、NASか共同編集のサービスかの二択でもありません。業務ソフトがSMBを前提にしている場合は、Azure Filesのように、クラウド上でSMBのファイル共有を提供するサービスも候補になります（Microsoft：SMB Azure file shares）。

ただし、SMBで接続できることと、既存の業務ソフトがそのまま動くことは別です。Microsoftも、Azure FilesはSMBとファイルシステムの機能の一部に対応しており、対応していない機能に依存するアプリは正しく動かない場合があると説明しています（確認日：2026年10月現在）。ネットワーク、認証、応答の遅さ、アプリ側の対応を確認します。また、SMBのファイル共有は、SharePointのような共同編集の仕組みとは役割が異なります。

クラウドへ移す場合は、製品の名前よりも、組織の共有領域として何を使うかを先に決めます（確認日：2026年10月現在）。

• SharePoint：チームや組織で共有する文書を置き、サイトの単位で権限を管理する領域です。Microsoftは、プロジェクトに重要な文書は、自分以外の人も管理できるようにすることを勧めています（Microsoft：Teams、SharePoint、OneDriveを使用した共同作業）。
• OneDrive：利用者個人の作業や、特定の相手との共有に向いた領域です。共有もできますが、会社の共有ファイルを一人の領域に集める場合は、担当者の異動や退職の後の扱い、容量、契約を確認します。
• Google共有ドライブ：ファイルを個人ではなくチームや組織が所有する領域で、作成した人が所有するマイドライブとは扱いが異なります（Google：共有ドライブとは）。既定ではメンバー全員がすべてのファイルを見られますが、管理者の権限を持つメンバーは、アクセスを制限したフォルダで閲覧できる人を絞れます（Google：共有ドライブのファイルへのアクセスの仕組み）。使える機能は、組織の設定やエディションによっても変わります。

NASのユーザーやグループ、フォルダごとの継承や拒否の設定が、移行先でそのまま同じ意味の権限になるとは限りません。権限は、必要な人が参照・更新できることと、対象外の人が参照できないことの両方を確かめます。閲覧・編集・削除・外部共有を、それぞれ誰に任せるかも整理します。

画面上でフォルダに見えることと、NASの共有フォルダと同じように動くことも別です。決まった場所を指すパスやリンク、ファイルのロック、互いに参照し合う文書、業務ソフトの対応条件は、小規模な試行で確かめます。

日常の同期と、移行の作業も分けて考えます。OneDriveは、ネットワークドライブを同期の場所に指定できないことや、ファイル名・パス・同期する件数の条件を公開しています。件数の目安には、通常の推奨と、条件付きのプレビューがあります（Microsoft：Restrictions and limitations in OneDrive and SharePoint）。パソコン版Googleドライブも変更を同期する仕組みで、ストリーミングとミラーリングで端末の容量の使い方が変わります（Google：パソコン版ドライブを使用する）。同期の設定にNASの全データを登録しても、移行が終わったことにはなりません。条件は変わるため、現行の公式資料で確認します。

管理者の交代や退職者のファイル、所有と共有の引継ぎは、Google Workspace・Microsoft 365の運用引継ぎで扱っています。

移行先を決める前に、今の保存先について次の8項目を記録します。分かっていることと、まだ確かめていないことを分けて書くと、次に誰が何を確認するかが決まります。

表は横にスクロールできます →

この確認票は、自社で記入して保管するためのものです。パスワードなどの認証情報は記入しません。記入できない項目は「未確認」とし、次に確認する担当と方法を書きます。空欄を「問題なし」として扱いません。

棚卸しの結果は、移行先の制限と照らし合わせます。クラウドの保存先には、1つのファイルの大きさ、保存できるファイルの数、フォルダの階層の深さやパスの長さ、使えない文字や名前、共有ドライブに追加できるメンバーやグループの数などの上限があり、一定の時間にアップロードできる量に上限がある場合もあります（Microsoft：Restrictions and limitations in OneDrive and SharePoint、Google：共有ドライブの制限。確認日：2026年10月現在）。上限の値は製品や契約、時期によって変わるため、移行の時点の公式資料で確かめます。収まらないファイルやフォルダは、移行の設計の段階で、構成の見直し、分割、除外、今の環境に残すといった扱いを決めます。

移行は、次の6段階で進めます。段階ごとに、誰が判断し、何を記録するかを決めておきます。

1. 対象と候補を分ける
   業務やフォルダの単位で、移すもの、残すもの、保管の方法を別に確認するものに分けます。
2. 移行を設計する
   移行先の保存場所、ユーザーとグループの対応、対象と除外、権限・リンク・版の履歴・更新日時などの扱い、確認の方法、作業する人の権限を決めます。これまでの権限の設定は、移行先でそのまま再現できない場合があります。拒否の設定、個人への直接の付与、継承を止めたフォルダなどを、移行先のグループや共有の単位にどう置き換えるかを先に決め、対応表として残します。
3. 小規模に試す
   代表的なファイルと利用者に加え、許可されていない利用者でも確かめます。参照・編集・保存・リンク・業務ソフト・同期やオフラインの条件を確認します。移行後の応答の速さは環境によって変わるため、一律の時間を前提にしません。
4. 本移行と照合
   移行の単位、差分の取り込み方、変更を止める範囲、失敗や除外の記録を確認します。件数や容量の一致は確認の一部で、必要に応じて内容・属性・代表的なファイルの動作も照合します。ハッシュ値でファイルの中身が一致することを確かめても、Googleの形式へ変換したファイルの内容や、権限・属性が正しく移ったことまでは確かめられません。
5. 切替と受入
   切替の後にどの保存先を更新するかを周知し、業務の側で実際に使えることを確認します。元へ戻す場合に、新しい保存先で加えられた更新をどう扱うかも決めておきます。新旧の両方を自由に更新できる状態は残しません。
6. 旧環境の保持・廃止と運用の引継ぎ
   合意した確認が済むまで、旧環境のデータを急いで削除しません。保持する目的・期間・閲覧できる人・費用と、廃止を判断する人を決め、期限なく二重に管理する前提にはしません。

Microsoft 365へ移す場合、Migration Managerは、移行元のファイル共有と移行先の両方に接続するエージェントを使い、事前のスキャン、除外の設定、タスクごとの報告を提供しています。移行元のサーバーがSMB 2.0以上に対応していることや、移行元を読み取る権限、移行先の管理者の権限が前提です（Microsoft：Overview: Migrate your file shares to Microsoft 365。確認日：2026年10月現在）。どの機器でも同じ条件で移せるわけではなく、権限・リンク・版の履歴がどこまで移るかも試行で確かめます。コピーが終わったことは、受入の完了ではありません。Google Workspaceへ移す場合の方法と条件は、別に確認します。

システム全体の移行方式や、切替と切り戻しの一般的な考え方は、レガシーシステム移行の進め方で扱っています。

次の表は、試行の前に、対象ごとの候補と確かめることを整理した例です。状態は「移行候補を整理中・試行前」で、移行先はまだ決めていません。

表は横にスクロールできます →

小さな範囲で確認できても、すべてのフォルダや拠点にそのまま広げてよいとは限りません。対象を広げる前に、残っている未確認の点と、次に判断する人を確かめます。

費用は、対象の業務、利用者の人数、データの量と増え方、比べる期間、税込みか税別か、通貨をそろえて比べます。次の項目を洗い出します。

• NAS・サーバー：機器、ディスク、無停電電源装置（UPS）など、必要なソフトとライセンス、更新、電気代、設置場所、保守契約、管理する人の工数
• クラウド：契約と追加のライセンス、容量やプランの追加、利用量に応じた課金、接続や端末の条件、管理・保持・復元と、必要な保護の追加費用
• 移行時と併用中：棚卸し、権限と保存先の整理、試行・コピー・照合・切替の作業、利用者への説明、新旧を並行して使う期間の費用、旧環境の廃止と保管

既存の契約の容量や人数の枠が使えることと、今後も追加の費用や作業費がかからないことは別です。未確認の費用を0円として合計しません。確認できた範囲は小計として示し、必要な費用に未確認があるうちは、小計だけで割安・割高や順位を決めず、同じ条件で確認を続けます。

費用の台帳と見直しの進め方はITコスト適正化の実務で、ベンダーの提案や見積もりを同じ条件で比べる方法はシステム見積もり・ベンダー提案の比較方法で扱っています。

NASのRAIDは、ディスクの故障に備える仕組みで、誤って削除したファイルや暗号化されたファイルを戻すための仕組みではありません。同じ装置に保存するスナップショットは、誤った削除などからの復元に役立ちますが、装置そのものの故障や、管理者の権限が奪われて削除される場合には失われるおそれがあります。QNAPも自社のNASについて、RAIDはバックアップではないと説明し、スナップショットもバックアップの原則に沿って別に保存することを勧めています（QNAP：Product Security）。

クラウドへ移す場合も、版の履歴、ごみ箱、保持の設定で戻せる範囲と、バックアップから復元できる範囲・期間・操作できる人・単位を確認します。同期は変更を自動的に反映する仕組みで、誤った変更も反映されます。必要な過去の状態を別に残して戻せるかも確認します。クラウド事業者の設備の対策は、自社の誤削除からの復元を保証するものではなく、業務を再開する条件をすべて満たすわけでもありません。

移行の後は、次の担当を決めます。

• 共有の追加・変更と、その承認
• 利用者と端末の追加・削除
• 容量と契約の確認
• エラーの通知を受け取り、対応する人
• 保護と復元の設定、復元の操作
• 利用者からの問い合わせと、委託先との分担

復元できるかを実際に試す方法は、バックアップ復元テストの進め方で扱っています。資料を残す期間は所管部門が決め、古い資料だからといって削除してよいとはしません。

NAS・ファイルサーバーの見直しを判断する前に、次の項目を確認します。