ファイルサーバのクラウド移行、どこに置くか｜製品を選ぶ前に整理したいデータの使い方

「ファイルサーバが更改時期なので、そろそろクラウドに移したいのですが」—機器の保守期限や、社外から使いにくいといった事情をきっかけに、そうした相談をいただきます。

そして次に挙がりやすいのが、「OneDriveか、SharePointか、Azure Filesか」という製品の質問です。

ただ、その前に一度確認しておきたいことがあります。

今回の更改で実現したいのは、サーバーの撤去なのか、共同作業の改善なのか、運用負荷の軽減なのか。

目的によって、移す範囲も、置き場所の選び方も変わります。そしてもうひとつ。いまファイルサーバに置いてあるデータは、1種類ではありません。

この記事では、置き場所を決めるまでの考え方を整理します。

この記事でわかること

• 更改の目的によって、移す範囲がどう変わるか

• 置き場所の候補を絞るための、データの3分類

• 候補を確定する前に確認する4つのこと

※各サービスの仕様や上限は変更されることがあります。実際の検討時には、公式ドキュメントで最新の情報を確認してください。

「全部まとめて1か所へ」で起きること

ファイルサーバの中身は、フォルダとして並んでいると同じように見えます。しかし、管理のされ方も、使われ方も違います。

個人が作業中のファイル。部門で共有している資料。業務システムが読み書きするデータ。複合機のスキャン保存先。バックアップやログの出力先。

製品を先に決めて、これらを全部まとめて運ぼうとすると、要件に合わないデータが移行の段階で見つかることがあります。そして多くの場合、大半は移せたものの、動かなくなったものだけがオンプレミスに残る、という形になります。

ここで気をつけたいのは、オンプレミスが残ること自体は、失敗ではないということです。業務上の理由があり、費用と運用体制を織り込んだうえで残す判断は、十分に成立します。

問題になるのは、想定していなかったものが残り、その維持費と担当が計画から漏れることです。サーバーを撤去する前提で予算を組んでいたのに、機器も保守契約も残り、そこにクラウドの費用が上乗せされる。こうなると、何のための更改だったのかが分からなくなります。

だから最初にやるのは、製品選びではありません。目的の確認と、データの仕分けです。

そしてこの2つは、つながっています。目的が、移す範囲を決めます。 具体的にどう変わるかは、後半の「移す範囲を決める」で整理します。

データを3つに分けて、候補を絞る

置き場所を選ぶ前に、そのデータを誰が管理し、どのように利用しているかを整理します。

ここで挙げる3つの分類は、置き場所を決めるものではありません。候補を絞るための入口です。確定するのは、次の章の4つの確認を経てからになります。

1. 個人の作業を中心に管理するデータ

本人が作成し、本人が管理している、作業中のファイルや下書き、参照用の控え。候補はOneDriveです。

判断の軸は、個人の作業領域なのか、組織が継続して管理すべきマスターなのかです。

落とし穴は、「個人フォルダ」の中に部門のマスターが混ざっていることです。そのまま移すと、組織として管理すべきデータが個人の領域に置かれたままになります。これは分類の段階で拾い出して、次の②として扱います。

なお、退職や異動のときの扱いは、アカウントの削除手順や保持の設定に左右されます。「個人の領域に置けば、いずれ自動的に整理される」と考えるのではなく、組織として残す必要があるデータを、あらかじめ②へ移しておくことが要点です。

2. 組織で管理・共有するデータ

組織が管理し、複数人が更新し、版を重ねていくデータです。社外と共有することもあります。候補はSharePoint（Teamsのチャネルからも利用）です。

TeamsとSharePointは別々の保存先ではありません。Teamsのチャネルにアップロードしたファイルは、SharePointに保存されます。この関係を理解しておくと、どちらで設計するかという議論にならずに済みます。

落とし穴は、いまのフォルダ階層をそのまま持ち込むことです。サイトやライブラリは、共有する範囲に応じて設計します。フォルダやファイルごとの個別の権限を増やしすぎると、誰が何を見られるのかを把握しにくくなります。移行は、その構造を見直す機会になります。

もうひとつ、この分類で一緒に決めておきたいのが、社外とのファイルの受け渡し方法です。

すでにファイル共有のサービスを導入しているなら、それを前提に設計できます。導入していない場合は、この移行を機に方針を定めておくことをおすすめします。パスワード付きZIPと別送メール（いわゆるPPAP）からの切り替えも、ここに含まれます。移行が終わってから別途検討すると、元のやり方が残りやすくなります。

実際には、同じ会社でも部門ごとに社外共有の方法が違っている、というケースをよく見かけます。移行は、それを揃える機会にもなります。

3. アプリや機器がファイル共有として利用するデータ

業務アプリが共有パスを直接参照している。バッチ処理が出力している。複合機のスキャン保存先になっている。CADが参照している。他システムとの連携フォルダになっている。こうしたデータの候補は、Azure Files、AWSであればFSx for Windows File Server、あるいはオンプレミスの継続です。

このデータが①②と違うのは、アプリや機器の動作が、共有パスやファイルの読み書きの仕組みに依存しているという点です。人が開くこともありますが、それとは別に、決まった場所を決まったやり方で読み書きすることが前提になっています。

SharePointやOneDriveは、人の共同作業に最適化された作りです。既存のSMB共有を前提とした処理を、そのまま置き換えられるとは限りません。

そして厄介なのは、ファイルサーバを長年運用していると、情報システム部門も把握していない使われ方をしていることがよくある、という点です。

事業部門がファイルサーバをローカルPCにドライブとして割り当て、業務システムの一部として使っている。複合機のスキャン保存先に指定されていて、そこから会計システムへ連携している。こうした使われ方は、台帳にも構成図にも載っていません。

つまりこの分類は、フォルダの中身を見るだけでは終わりません。誰が、どの業務で、どう使っているかを、現場に確認する必要があります。

分類しきれないデータについて

実際には、1つのフォルダに複数の性質が混ざっていることがよくあります。部門で共有している資料を、バッチ処理が読み込んでいる、といったケースです。

この場合は、用途ごとに分けるか、同じ場所で両方の要件を満たすかを判断することになります。どちらが現実的かは、次の章の確認を経て決まります。分類だけで結論を出さないというのが、ここで一番お伝えしたいことです。

なお、BoxやDropboxをはじめとするクラウドストレージサービスも選択肢になります。位置づけとしては②に近く、社外との共有要件が強い場合に検討の対象になります。

候補を確定する前に確認する4つのこと

1. ファイルサイズ・パス長・ファイル名

SharePointやOneDriveには、1ファイルのサイズ、パスの長さ、使用できる文字に制約があります。長年運用してきたファイルサーバには、これに該当するファイルが含まれていることがあります。

移行ツールの事前スキャンで洗い出せる部分なので、候補を決める前に確認しておきます。具体的な値は変更されることがあるため、OneDrive と SharePoint の制限事項と制約事項で最新の情報を確認してください。

2. 権限

よく誤解されるところですが、移行ツールには権限を移す機能があります。すべてを手作業で作り直す、という話ではありません。

確認すべきなのは、そのまま移せる権限と、再設計が必要な権限を切り分けることです。特に、深い階層での個別の権限設定や、継承を切っている箇所は、移行先の権限モデルと構造が異なるため、同じ形では再現できない場合があります（移行時の権限の扱い）。

ここを移行前に把握しておくと、必要な作業量が見えます。

設計の考え方としては、業務上アクセスが必要な範囲を基準にするのが基本です。その範囲が同じ利用者はグループでまとめ、不要な細分化は避けます。機密情報など、最初から分離しておくべきデータは別に扱います。部門や役職は、範囲を考えるときの起点、という程度に捉えるのがよいと思います。

プロジェクト単位の権限を追加する場合は、プロジェクトが終わったあとの、フォルダと権限グループの扱いまで決めておきます。決めていないと、使われないグループが残り続けます。

必要な境界は守りつつ、管理を複雑にしすぎない。グループを細かく作り込みすぎると、誰が何を見られるのかを追いきれなくなります。移行は、そのバランスを整理する機会です。

3. IDと認証

誰がどのデータにアクセスできるかは、最終的にIDの設計に行き着きます。

Azure Filesを使う場合、利用できる認証方式は、既存のIDの持ち方、端末の状態、接続元によって変わります。まずはいまの環境で利用できる認証方式を確認するところから始めます。

ここが整理できていないと、置き場所の候補そのものを絞りきれません。ID基盤の整備が複数の施策の前提になる、という話は別の記事で書いています。

4. 接続と性能

最後に、見落とされやすい点です。

SMBに対応していることと、既存のアプリや複合機がそのまま使えることは、別の話です。

確認するのは、接続の経路、機器側の対応状況、認証方式、そして通信の遅延です。特に③に分類したデータでは、ここを飛ばすと、移行してから問題が判明します。

現在の機器やアプリから接続できるか。業務で許容できる速度で動くか。移行先を確定する前に、代表的な利用方法で検証しておきます。

移す範囲を決める

候補が絞れたら、次は移す範囲です。

ここで冒頭の目的に戻ります。「共同作業の改善」が目的なら、移す対象は②に絞れます。「サーバーの撤去」が目的なら、すべてのデータについて行き先を決めきる必要があります。目的が範囲を決めます。

そのうえで、移す前に棚卸しをします。

気をつけたいのは、更新日は手掛かりであって、判断そのものではないということです。更新されていないことと、参照されていないことは別です。規程や図面のように、何年も更新はないけれど、必要になったときには即座に取り出せなければ困る資料もあります。

判断の材料になるのは、利用の実態、保管しておく必要性、そして取り出すまでに待てる時間の3つです。

移行の対象を減らせば、負荷は下がります。ただし、所要時間は容量だけでは見積もれません。ファイルの数やサイズの分布にも左右され、小さなファイルが大量にあるほうが時間がかかる傾向があります。

アーカイブ向けの保管階層を使う場合にも、注意点があります。保管の費用は下がりますが、読み出す前に復元の処理が必要になる階層があります。通常の共有フォルダと同じようにすぐ開けるとは限りません。保管の費用だけでなく、取り出すまでの時間と、そのための費用も確認してください。

使っていないデータに高い性能帯の費用を払い続けない、という考え方そのものは、他のクラウド費用の見直しと同じです。

候補の整理例

ここまでを整理すると、次のような形になります。

3列目は候補であって、確定ではありません。ここから前章の4点を確認して、置き場所を決めていきます。

2列目に「管理と利用のしかた」を置いているのが、この表の要点です。製品を横に並べて比べる表ではなく、自社のフォルダを当てはめて考えるための表として使ってください。

そして、1つのフォルダに複数の性質が混ざっている場合は、用途ごとに分けるか、同じ場所で両方の要件を満たすかを判断することも、移行計画の一部になります。ここは追加の調査が必要になる部分です。

まとめ

置き場所は、製品から選ぶのではなく、そのデータを誰が管理し、どう使っているかから絞ります。3つの分類で候補を出し、サイズ・権限・ID・接続の4点で適合性を確認する。この順序で進めると、移行先に合わないデータを、早い段階で見つけやすくなります（費用やバックアップ、復旧の要件も、最終的な判断には関わってきます）。

そして、目的をはっきりさせておくこと。サーバーを撤去したいのか、共同作業を良くしたいのか、運用負荷を下げたいのか。目的が、移す範囲を決めます。

まずは、いまのファイルサーバの第1階層を開いて、フォルダを3つに仕分けしてみてください。仕分けられなかったフォルダが、最初に調べるべき部分です。