ファイルサーバーを Amazon S3 に置き換えると何が困る？「普段使い」で引っかかる5つのポイントを検証

当ページのリンクには広告が含まれています。

2026年10月1日

INGSTE編集部

【PR】本記事で紹介している S3 DriveBridge は、INGSTE を運営する Gratias合同会社が開発・販売している製品です。

社内のファイルサーバーが手狭になってきた。容量を足すにも機器がもう古い。そろそろクラウドに移してもいいのでは——という話は、どこの会社でも一度は出ます。

移行先としてよく名前が挙がるのが Amazon S3 です。容量を気にしなくてよくなり、機器の更新からも解放される。そこまでは検討資料にもよく書かれています。

ただ、実際に使い始めてから「そうだったのか」と気づくことがいくつかあります。しかもその多くは、あとから運用でカバーするしかない種類のものです。

今回は、S3 を Windows のドライブとして「普段使い」したときに引っかかるポイントを、5つに絞って整理しました。

先にお断りしておくと、この記事は「クラウドに移すべきかどうか」を決めるものではありません。移す前に知っておくと後悔しにくいことをまとめたものです。

そもそも S3 をドライブとして使えるの？

使えます。専用ソフトを入れると、S3 のバケットに Z: のようなドライブレターが割り当てられ、エクスプローラーからそのまま開けるようになります。

Windows のエクスプローラーに S3 バケットがネットワークドライブとして表示されている画面 — 見た目はいつものエクスプローラー。中身がクラウドであることは意識しません

Excel から「名前を付けて保存」で直接書き込めますし、コマンドプロンプトから copy も通ります。アプリ側は、相手がローカルのディスクなのかクラウドなのかを知りません。

ここまでは期待どおりです。問題はこの先です。

① フォルダー名を変えるとどうなる？

ここがいちばん意外だったところです。

S3 には、実はフォルダーというものが存在しません。あるのは「名前」と「中身」の組み合わせだけで、2025_案件/設計/図面.dwg という名前の中にある / が、階層のように見えているだけなのです。

普段は意識せずに済みます。効いてくるのは、フォルダーの名前を変えたときです。

ファイルサーバーではフォルダー名の変更は一瞬で終わるが、S3 では中のファイルを1件ずつコピーして削除する必要があることを比較した図 — 同じ「名前を変えるだけ」でも、中身の数だけ仕事が発生するかどうかが違います

これまでのファイルサーバーなら、フォルダー名の変更は名前を書き換えるだけです。

中に何万ファイル入っていても一瞬で終わります。

S3 では、そのフォルダーに属するファイルを1件ずつコピーして、元を削除することになります。10,000 ファイル入っていれば、20,000 回のやりとりです。

しかも1件ずつ順番に処理されます。1回のやりとりに数十ミリ秒かかるとして単純計算すると、それだけで10分を超えます。ドラッグ＆ドロップでの移動も同じ仕組みなので、同様です。

対策はひとつだけです。大きなフォルダーの名前を、あとから変えなくて済むようにしておくこと。年度やプロジェクト名を階層の上の方に置くつもりなら、「あとで一括で付け替えたくなる場面が来ないか」を移行前に考えておくと安全です。

② 2人が同じファイルを開いたら？

実害という意味では、これがいちばん大きいと思います。

これまでのファイルサーバーにはファイルロックという仕組みがありました。誰かが Excel ファイルを開いていると、次の人には「使用中です。読み取り専用で開きますか？」と表示されるアレです。

S3 にはこの仕組みがありません。

ファイルサーバーでは2人目に使用中と表示されるが、S3 では両方が保存でき後から保存した方だけが残ることを比較した図 — 違うのは「気づけるかどうか」です

2人とも普通に開けて、2人とも普通に保存できます。そしてあとから保存した方だけが残ります。先に保存した人の変更は、誰にも知られないまま消えます。

「同時に開かないように運用でカバーする」という話になりがちですが、それは全員が守り続けることが前提です。事故が起きるのは、守れなかった1回です。

現実的な対処は、保存する直前に、開いてから変わっていないかを確かめる仕組みを入れることです。変わっていたら相手の変更を上書きせず、自分の編集を別名で残して知らせる。どちらも失われませんが、あとで人が見比べる作業は残ります。

なお、Access の .mdb / .accdb を共有フォルダーに置いて複数人で使っているような構成は、このファイルロックに依存しています。S3 に置くと壊れます。工夫して動かすものではなく、別の方式に移す対象として考えてください。

③ 動作は遅くならない？

結論から言うと、作業の種類によります。

社内のファイルサーバーへの往復は1ミリ秒もかかりません。インターネット越しの S3 はその数十倍です。1回あたりは小さな差ですが、細かい読み書きを何百回もするアプリだと体感が変わります。

おおまかには、こう分かれます。

影響	作業の例
ほぼ気にならない	資料を見る、写真や図面を参照する、まとまったファイルを受け渡す、過去案件を保管する
設定しだい	Office 文書の日常的な編集（手元にキャッシュを持たせれば実用的）
引っかかりやすい	何万件も入ったフォルダーを頻繁に開く、大きなファイルを開いたまま少しずつ書き換える、外部参照の多い CAD 図面
向かない	共有ファイル型のデータベース、リアルタイムの動画編集

ソフト選びの際は、手元にキャッシュを持てるかどうかを見ておくと差が出ます。フォルダーを開いた直後の細かい問い合わせをキャッシュから返せるかどうかで、体感がかなり変わります。

④ 結局、月いくらかかる？

ここも考え方が変わります。

ファイルサーバーの費用は、機器を買った時点でほぼ決まります。使い方を変えても金額は動きません。

S3 は「置いている容量」「やりとりの回数」「外に出た通信量」で決まります。つまり使い方によって金額が動きます。

容量は見積もりやすいので、比較資料はたいていそこだけを比べています。実際に見込みと外れるのはやりとりの回数の方です。①で書いたフォルダー名の変更のように、画面上は一瞬の操作が裏では何万回、ということが起きるからです。

同じ容量・同じ人数でも、資料を見るのが中心の部署と、日々ファイルを作り替える部署では桁が変わります。単価表とにらめっこするより、一部の部署で実際に使って測る方が確実です。

⑤ 前の状態に戻せる？

戻せますが、やり方が変わります。

これまでは「シャドウコピー」や、バックアップからの復元でした。S3 ではバージョニングという機能がその役目を担います。

性質が少し違います。シャドウコピーはある時点のサーバー全体ですが、バージョニングはファイルごとの世代です。「昨日の18時の状態にフォルダーごと戻す」はそのままの形ではできません。逆に、特定のファイルだけを何世代でも遡るのは得意です。

ひとつ注意点があります。バージョニングを有効にすると、上書きや削除のたびに古い世代が残り続け、容量は自動では減りません。「何日で古い世代を消すか」を移行時に決めておいてください。あとから有効にしても、それ以前の変更は遡れません。

で、結局うちは移していいの？

向き不向きがはっきり出ます。率直なところをまとめます。

	内容
向いている	過去案件・図面・写真・契約書などの保管／部署間での資料の受け渡し／容量が読めず増え続けるデータ／拠点が複数あり、どこからでも同じものを見たい／ファイルサーバーの更新時期が近く、次の5年ぶんを買い切りたくない
条件付き	Office 文書の日常的な共同編集（②の同時編集をどう扱うか決めてから）／CAD の参照（外部参照が多い図面はキャッシュ設定を確認）
向いていない	共有ファイル型のデータベース（Access など）／何万ファイルの階層を頻繁に組み替える運用／ミリ秒単位の反応が要る作業

おすすめは、全部を一度に移さないことです。まず過去案件や保管用の領域から始めて、日常的に使う領域は後から判断する。実際の使い勝手も費用も、動かしてみないと分かりません。