ファイルサーバーからDirectCloudへ移行する実践手順｜事前準備・移行後の確認・定期メンテナンスのチェックリスト
ファイルサーバーからクラウドへの移行は、担当者の多くにとって初めての作業です。何から手を付ければよいのか、移行後に問題が起きないか、といった不安から、着手を先延ばしにしているケースも少なくありません。
本記事では、ファイルサーバーからDirectCloudへデータを移行する際に行う作業を、「セキュリティ設計」「移行前の準備」「移行直後の確認」「定期的な運用」の4つのフェーズ・14項目のチェックリストに整理しました。各項目について、なぜ必要なのか、DirectCloudではどの機能で対応するのかを順に説明します。
移行ツールの種類や選び方は、以下の関連記事をご覧ください。
目次- 1. 移行作業の全体像｜4つのフェーズと14のチェック項目
- 2. セキュリティ面で考慮すべきこと（設計・方針策定）
- 3. 移行前の準備・確認事項
- 4. 移行直後の対応・確認事項
- 5. 移行後に定期的に行う運用・維持保守（メンテナンス）
- 6. まとめ
移行作業の全体像｜4つのフェーズと14のチェック項目
ファイルサーバーからDirectCloudへの移行は、データを転送する作業そのものよりも、その前後の準備と確認に時間を使います。全体像を先に把握しておくと、各作業がどの段階で必要になるのかがわかり、見通しを立てやすくなります。
下表は、本記事で扱う4つのフェーズと14のチェック項目を一覧にしたものです。担当者間で分担を決める際や、進捗を確認する際のチェックリストとしても使えます。
| フェーズ | チェック項目 |
| 1. セキュリティ設計 | アクセス権限のマッピング／リンク共有・外部共有の制限／デバイス認証・IPアドレス制限 |
| 2. 移行前の準備 | データの整理／非対応ファイルのチェック／移行ツールの環境構築／帯域とスケジュールの設定 |
| 3. 移行直後の確認 | ログとレポートによる成否確認／データ整合性のスポットチェック／移行元の読み取り専用化 |
| 4. 定期的な運用 | アカウント・権限の棚卸し／容量管理／ログの監視／移行ツールのクリーンアップ |
以降の章は、この表の順に進みます。なお、移行ツールの操作手順そのものは本記事の対象外とし、各項目では設定画面を示しながら、どこで何を設定するのかを説明します。移行ツールの操作手順は、以下のWebマニュアルを参照してください。
セキュリティ面で考慮すべきこと（設計・方針策定）
データ移行を始める前に、自社のセキュリティポリシーをDirectCloud側の設定へ落とし込んでおく必要があります。移行後に設定を変えると、利用者のアクセスが突然遮断されるなど、業務への影響が大きくなるためです。この章では、移行前に決めておきたい3つの設計項目を取り上げます。
アクセス権限（ACL）のマッピング
アクセス権限（ACL：Access Control List）とは、誰がどのフォルダやファイルに対して、どのような操作をできるかを定めた一覧のことです。Windowsのファイルサーバーでは、ファイルシステムであるNTFSの機能を使ってフォルダ・ファイルごとにこの権限を設定しており、これをNTFSアクセス権と呼びます。NTFSアクセス権は、クラウドストレージへ自動では変換されません。移行前に、DirectCloudの共有フォルダ構造と、フォルダごとに誰にどのアクセスレベルを付与するかを設計しておく必要があります。
Windows ServerとDirectCloudでは、権限の考え方が同じではありません。Windows Serverでは「フルコントロール」「変更」「読み取りと実行」といったアクセス権を付与しますが、DirectCloudでは、ユーザーやグループがどのような操作をできるのかを「アクセスレベル」として設定します。主なアクセス権とアクセスレベルの対応は、下表のとおりです。
| Windows Server（移行元） | DirectCloud（移行先） | ||
| アクセス権 | 可能な操作 | アクセスレベル | 可能な操作 |
| フルコントロール | フォルダ・ファイルの作成・削除、ファイルの実行など | オーナー | フォルダの作成、ファイルのアップロード、フォルダ・ファイルの削除、ファイルのプレビューなど |
| 変更／読み取り、書き込みと実行 | フォルダ・ファイルの作成、ファイルの削除、ファイルの実行など | 編集者 | ファイルのアップロード、ファイルのプレビューなど（フォルダの作成は不可） |
| 読み取りと実行 | ファイルの実行など | 閲覧者 | ファイルのプレビューなど |
たとえば、営業部の共有フォルダに対して、部長には「フルコントロール」、部員には「変更」、他部署には「読み取りと実行」を付与していた場合、DirectCloudでは部長を「オーナー」、部員を「編集者」、他部署を「閲覧者」に置き換えるのが基本の考え方になります。
設計した内容は、アクセス権追加用のCSVファイルを作成してインポートすることで、一括で登録できます。移行先のフォルダには、副管理者の権限またはオーナーのアクセスレベルが設定されている必要がある点にも注意してください。権限の設計は、移行後の運用のしやすさを決める土台になります。
リンク共有・外部共有の制限
機密データを含むフォルダについては、共有リンクの扱いを移行前に決めておきます。移行直後は多くの利用者が一斉にクラウドへアクセスし始めるため、リンク共有のルールが未設定のままだと、意図しない外部共有が起きるおそれがあるからです。
DirectCloudの共有リンクには、有効期限、パスワード、アクセス回数制限を設定できます。パスワードは標準で8文字が自動生成され、送付方法もリンクとは別のメールで送る、送信者だけに送るといった形式から選べます。
さらに、「ワンタイム閲覧オプション」を使うと、アクセスレベルは閲覧のみ、有効期限は当日、パスワードは必須、アクセス回数は1回に固定されます。
このオプションは、管理ページの「セキュリティ」>「ファイル送信設定」メニューにある「リンクのオプション設定」で「使用する」になっている場合に、利用者のリンク作成画面に表示される仕組みです。標準では「使用する」に設定されていますが、移行前に設定を確認しておくと確実です。
たとえば、取引先へ契約書案を送る場合、ワンタイム閲覧オプションを使えば、相手が1回閲覧した時点でリンクが無効になり、転送による二次流出を防げます。機密度の高いフォルダを扱う部門には、こうした設定を標準の運用として案内しておくとよいでしょう。
どのフォルダでリンク作成を許可するか、パスワードや有効期限を必須にするかといった方針を移行前に固め、利用者へ周知しておくことが、移行直後の情報漏洩を防ぐ近道になります。
デバイス認証・IPアドレス制限の有効化
社外からのアクセスを許可するかどうか、許可する場合はどの端末やどのネットワークからに限定するかも、移行前に決めておく項目です。移行後に有効化すると、現場の端末が一斉にログインできなくなり、問い合わせが集中しかねません。
DirectCloudでは、管理者が承認したデバイスだけで利用できるようにする「デバイス認証」を設定できます。管理ページの「セキュリティ」>「アクセス制御」メニューにある「デバイス管理」タブで「新規デバイスの処理」を「管理者の承認が必要」にすると、未登録のデバイスからログインしようとしたときに管理者へ通知メールが届き、承認か遮断かを選べます。
通知を受けた管理者は、「承認待ちのデバイス」の一覧でデバイスの情報を確認し、「許可」または「遮断」をクリックします。なお、Webブラウザで利用するWebアプリケーションはデバイス認証の対象外です。
IPアドレスによる制限は、同じ「アクセス制御」メニューの「IPアドレス制限」タブで設定します。許可するグローバルIPアドレスの範囲を「IPアドレスグループ」として登録し、「登録されたIPアドレスグループのみアクセス許可」を有効にすると、指定したIPアドレスからのログインだけが許可されます。
たとえば、本社と支店の固定IPアドレスだけを登録しておけば、自宅や外出先からWebアプリケーションにログインすることはできなくなります。移行ツールもこの制限の対象になるため、移行作業を行う端末のIPアドレスを登録し忘れないようにしてください。
移行前の準備・確認事項
この章で扱うのは、移行中のエラーによる遅延や、データの欠落を防ぐための準備です。4つの項目のうち、作業量が最も多いのは非対応ファイルのチェックですが、移行ツールの事前スキャン機能を使えば、問題のあるファイルを機械的に洗い出せます。手作業で全ファイルを確認する必要はありません。
データの整理（クレンジング）
移行対象を決める段階で、不要なデータを除外しておくと、移行にかかる容量と時間を減らせます。移行後にクラウド側で整理するより、ファイルサーバー上で判断するほうが、関係部門への確認も進めやすいためです。
除外の候補になるのは、古いログファイル、同じ内容が複数の場所に保存されている重複ファイル、退職者が残した個人フォルダ、担当者が個人的に取っていたバックアップデータなどです。判断基準としては、最終更新日が一定期間（たとえば5年）より前のファイルや、所有者が在籍していないフォルダを一覧にし、部門の責任者に要否を確認する方法があります。
たとえば、経理部の共有フォルダに「旧システム出力」という名前で保存されている10年前の帳票データは、保存義務の期間を確認したうえで、移行対象から外すかアーカイブに回すかを判断します。
この作業はファイルサーバー側で完結するため、DirectCloud側の設定はありません。移行対象を絞り込むほど、後続のスキャンや転送が短時間で済みます。
非対応ファイル・エラー要素のチェック
移行前の準備で最も重要なのが、DirectCloud側の仕様に合わないファイルの洗い出しです。該当するファイルは移行時にエラーになるか、移行できても業務で使えない状態になるため、事前に見つけて対処しておく必要があります。確認する項目は、下表の5つです。
| 確認項目 | 内容 | 事前の対処 |
| パスの長さ | Windowsのパスが260文字を超えるファイルは移行できない | フォルダ階層を浅くする、フォルダ名・ファイル名を短くする |
| ファイル名の長さ | ファイル名が190文字を超えるファイルは移行できない | ファイル名を短くする |
| 禁則文字 | ファイル名に「\（バックスラッシュ）、¥（円記号）、/、:、*、?、”、<、>」を含むファイルは移行できない | 置換ルールを決めて一括で名前を変更する |
| 1フォルダ内の件数 | 1フォルダに保存するフォルダとファイルの数は2,000個以内が目安 | 年度・案件などの単位でフォルダを分割する |
| マクロ・リンク参照 | Excelのマクロや他システムと連携したファイルは、移行後の動作がサポート対象外 | 該当フォルダを洗い出し、運用方法を見直す |
このうち、パスが260文字を超えるファイルと禁則文字を含むファイルは、DirectCloud Migratorの事前スキャンで一覧化できます。スキャン結果では、ファイル名に禁則文字を含む、1ファイルがアップロード上限の60GBを超える、Windowsのパスが260文字を超える、といったファイルが「警告」として表示され、移行から自動的に除外されます。
一方で、ファイル名が190文字を超えるファイルは、移行前の棚卸しで確認し、リネームやフォルダ構成の変更で対応します。
たとえば、スキャンの結果、「2025/04_月次報告.xlsx」のようにファイル名に「/」を含むファイルが300件見つかったとしましょう。この場合、「/」は「_」に置き換えるという全社共通のルールを先に決め、一括リネームツールで300件をまとめて変更したあと、もう一度スキャンしてエラーが消えたことを確認するという流れになります。部署ごとに別々の文字へ置き換えてしまうと、移行後に同じ種類のファイルが異なる名前で散在し、探しにくくなるためです。
マクロやリンク参照については、ツールで検出することはできません。業務システムからファイルサーバーを参照している設定や、別ファイルを参照するExcelは、利用部門へのヒアリングで洗い出し、移行後の運用方法を決めておきましょう。
参照元
Microsoft Learn｜ファイル、パス、名前空間の名前付け – Win32 apps
DirectCloud Migratorの環境構築
移行ツールを動かす端末の準備も、移行前に済ませておく項目です。移行は数時間から数日にわたって動き続けるため、端末の条件を満たしていないと、途中で処理が止まる原因になります。
DirectCloud Migratorは、Windowsを対象としたデスクトップアプリケーションで、Mac用は提供されていません。インストールする端末には、移行元のファイルサーバーへ高速に接続でき、作業中に電源が落ちない環境を用意します。スリープや自動シャットダウンの設定も、移行期間中は無効にしておきます。
台数にも上限があります。DirectCloud Migratorは、会社全体で同時に4台まで使用でき、コマンドツールのDCMigratorを同時に使っている場合は、その台数も合算されます。上限に達している状態でスキャンを実行すると「致命的」の判定となり、次のステップへ進めません。
また、複数のPCで同時に実行する場合は、同じ移行元フォルダを指定しないようにしてください。ファイルの整合性に問題が生じる可能性があります。
たとえば、4つの拠点で同時に移行を進めたい場合は、拠点ごとに1台ずつ端末を割り当て、それぞれ別の移行元フォルダを指定します。5拠点目の端末を追加したい場合は、いずれかの拠点の移行が終わってから開始することになります。
このほか、DirectCloud Migratorを利用するには、利用権限を有効にするための申請が必要です。利用を開始する前に、データ移行作業申請フォームから申請してください。実行するユーザーには、契約担当管理者または一般管理者の権限と、第1階層フォルダの作成権限が必要です。
ネットワーク帯域の確保とスケジュール設定
移行中は大量のデータが回線を流れるため、日中の業務に使う通信を圧迫しないよう、転送速度の制御を設定しておきます。移行ツール側で帯域を制限すれば、ネットワーク機器の設定を変えずに業務への影響を抑えられます。
DirectCloud Migratorの「設定」ステップには「速度制限」の項目があり、転送速度の上限を設定できるほか、曜日と時間帯ごとに異なる速度を指定できます。JSONファイルを使って、スケジュールを一括で設定することも可能です。
設定例として、平日の8時から18時は10MB/sに制限し、平日の夜間と土日は制限なしで実行する、という組み方が考えられます。こうしておけば、業務時間中はWeb会議やメールの送受信に影響を与えず、夜間と週末に移行を一気に進められるでしょう。
移行期間の見積もりは、ファイル数と回線速度に左右されるものです。本番前にテスト移行を行い、実際の転送速度を測ったうえで、何日で完了するかを算出しておくと、切り替え日の設定や関係部門への説明がしやすくなります。
移行直後の対応・確認事項
データの転送が終わった時点では、移行はまだ完了していません。正しく移ったことを確認し、旧環境への誤った更新を防いでから利用者に開放するまでが、移行作業の範囲です。
この章では、転送直後に行う3つの確認を説明します。いずれも数時間で終わる作業ですが、省略すると移行後のトラブル対応に何倍もの時間がかかります。
ログとレポートによる成否確認
転送が完了したら、まず移行ツールのレポートで、すべてのファイルが移行されたかを確認します。失敗やスキップが発生していても転送自体は終了するため、レポートを見なければ移し漏れに気づけません。
DirectCloud Migratorでは、移行が完了すると自動的に「レポート」画面に切り替わり、「合計」「アップロード」「失敗」「スキップ」「削除」別にファイル数・フォルダ数・容量と、所要時間が表示されます。各項目のタイトルをクリックすると対象のファイル名をすべて確認でき、CSVファイルとしてダウンロードすることもできます。過去に実行した移行のレポートは、ホーム画面の「ログ」ボタンから一覧で呼び出せます。
たとえば、「失敗」に12件と表示されていた場合は、CSVをダウンロードして該当ファイルを特定し、原因（禁則文字、サイズ超過など）を取り除いてから、再度移行を実行します。「スキップ」の件数が想定より多い場合は、移行先にすでに同名ファイルがあった可能性があるため、どちらが最新かを確認してください。
「失敗」と「スキップ」がゼロになるまで、原因の除去と再実行を繰り返すことが、移し漏れを防ぐ確実な方法です。問い合わせが必要な場合は、「ログを出力（ZIP形式）」で出力したログファイルを添えると、サポート窓口での調査がスムーズに進みます。
データ整合性のスポットチェック
レポートの確認とあわせて、重要なフォルダについては、移行元と移行先の件数と容量を直接突き合わせておきます。レポートはツールが処理した結果を示すものであり、移行対象の指定漏れまでは教えてくれないためです。
確認方法は難しくありません。移行元のWindows側では、フォルダを右クリックして「プロパティ」を開くと、ファイル数とサイズが表示されます。移行先のDirectCloud側でも、同じフォルダの件数と容量を確認し、両者が一致しているかを見ます。あわせて、主要なファイルをいくつか開き、更新日時が移行前のまま保持されているかを目視で確かめます。
たとえば、経理部の「2025年度決算」フォルダが移行元で1,248件・3.2GBであれば、移行先でも同じ数値になっているかを確認します。件数が合わない場合は、対象フォルダの指定漏れか、スキャンで除外されたファイルがある可能性があります。
すべてのフォルダを確認する必要はなく、業務への影響が大きいフォルダを数か所選んで確認すれば十分です。
移行元ファイルサーバーの「読み取り専用」化
移行先への切り替えが済んだら、移行元のファイルサーバーを速やかに読み取り専用にするか、ネットワークから切り離します。利用者が旧サーバーのファイルを更新し続けると、移行先と内容が食い違う「先祖返り」が起きるためです。
Windows Serverの共有フォルダでは、共有アクセス権を「読み取り」に変更するか、共有自体を停止します。共有アクセス権は、フォルダのプロパティにある「共有」タブから設定する権限で、ネットワーク経由で接続する際に適用されます。NTFSアクセス権とは別に設定されるため、共有アクセス権を読み取りに変えるだけで、ネットワーク経由の更新を止められるのです。
たとえば、切り替え日の朝に共有アクセス権を「読み取り」に変更しておけば、旧サーバーへのショートカットを使い続けている利用者がいても、ファイルを参照できるだけで更新はできません。保存しようとした時点でエラーになるため、新しい保存先への移行を促すきっかけにもなります。
一定期間が過ぎて旧サーバーへのアクセスがなくなったことを確認してから、共有を停止し、サーバーの廃止に進むとよいでしょう。
参照元
Microsoft Learn｜共有フォルダーのプロパティの表示と変更
移行後に定期的に行う運用・維持保守（メンテナンス）
クラウドへ移行したあとも、健全な状態を保つためには管理者による定期的な点検が必要です。頻度の目安を決めて運用に組み込んでおくと、作業が属人化せず、担当者が交代しても続けられます。この章では、頻度の目安とあわせて4つの定期作業を取り上げます。
アカウント・権限の棚卸し（3か月〜半年に1回）
退職者や異動者のアカウント、不要になった共有リンクが残っていないかを、3か月から半年に1回の頻度で確認します。IPAの「組織における内部不正防止ガイドライン」でも、異動や退職で不要になった利用者IDとアクセス権はただちに削除することが求められています。
Active DirectoryやMicrosoft Entra IDと連携していれば、ユーザー情報は自動で同期されますが、連携対象外のゲストアカウントや、部門で共用しているIDは手作業での確認が必要です。デバイス認証を使っている場合は、「承認済みデバイス」の一覧に退職者の端末が残っていないかもあわせて確認し、不要なデバイスを削除します。
たとえば、半年に1回、人事部門から異動・退職者の一覧を受け取り、管理ページのユーザー一覧およびアクセス権のエクスポート結果と突き合わせる運用にしておくと、確認漏れを防げます。
アカウントと権限の棚卸しは、移行前に設計した権限を維持するための作業といえます。
容量管理とアラート確認
契約しているストレージ容量に対して、現在どれだけ使っているかを定期的に確認します。上限に近づいてから対処すると、不要ファイルの削除やプラン変更が間に合わず、利用者がファイルを保存できなくなるおそれがあります。
管理ページの「ストレージ」>「ストレージ容量」メニューでは、契約容量と使用容量、使用率が円グラフで表示され、マイボックス、共有フォルダなど機能ごとの内訳も確認できます。ストレージ使用量は毎日午前0時のバッチ処理で計算されるため、表示は前日時点の値です。
特に注意したいのが、バージョンファイルの蓄積です。ファイルを更新するたびに旧バージョンが保存されるため、気づかないうちに容量を圧迫します。
「ストレージ容量」メニューの「ユーティリティ」には、マイボックスや共有フォルダ内のバージョンファイル、ユーザーのゴミ箱、管理者のゴミ箱の容量が表示され、「削除」ボタンで容量を空にできます。削除したバージョンファイルと管理者のゴミ箱のデータは復元できないため、実行前に必要なデータが残っていないかを確認してください。
たとえば、月初に使用率を確認し、80%を超えていればバージョンファイルとゴミ箱の削除を実行し、それでも解消しない場合にプランの変更を検討する、という手順を決めておくと判断に迷いません。
ログの監視と監査（月1回）
月に1回、管理ページのログで、不審なアクセスや操作がないかを確認します。ログは問題が起きたあとの調査にも使いますが、定期的に目を通しておくことで、異常の兆候を早い段階でつかめます。
確認するログは2種類あります。「ログ」>「ログイン」メニューでは、ユーザーごとのログイン履歴を、期間、ユーザー、ログイン結果で絞り込んで表示できます。IPアドレスの欄には、許可されたIPアドレスからのアクセスであれば「指定の場所」、それ以外であれば「指定外」と表示されるため、社外からのログイン試行を見つけやすくなっています。ログイン結果には「ログイン失敗」「IPアドレス遮断」「デバイス遮断」などが記録されます。
「ログ」>「ファイルの操作」メニューでは、ダウンロードや削除といった操作履歴を、期間、ユーザー、ファイル名、アクションで絞り込めます。たとえば、アクションを「ダウンロード」に絞り、直近1か月で件数の多いユーザーを確認すれば、短期間に大量のファイルをダウンロードした利用者がいないかを把握できます。
どちらのログもCSVファイルへのエクスポートに対応しています。操作履歴は大量になる可能性があるため、絞り込んでからエクスポートするとよいでしょう。ログの保管期間は契約プランによって異なり、スタンダード・アドバンスドでは3年、ビジネス以上では7年です。
DirectCloud Migrator自体のクリーンアップ
移行作業が一段落したら、移行ツールと移行用端末の状態も整理しておきます。次回の差分移行や別フォルダの移行予定がなければ、端末に残ったログを整理し、ツールの状態を確認する作業です。
DirectCloud Migratorのログは、ホーム画面右上の「ログ」ボタンから一覧を表示でき、「フォルダを開く」ボタンでログフォルダを直接参照できます。過去の移行のレポートやログは、サポート窓口への問い合わせやあとからの確認に使うため、必要なものはZIP形式でエクスポートして保管してから整理します。
今後も差分移行や追加の移行を行う予定がある場合は、データ移行をする際に、その都度アプリダウンロードページを確認し、最新バージョンのDirectCloud Migratorで実施してください。
移行用に用意した端末を通常業務に戻す場合は、移行期間中に無効にしていたスリープや自動シャットダウンの設定も元に戻しておきましょう。
まとめ
ファイルサーバーからDirectCloudへの移行で行う作業を、セキュリティ設計、移行前の準備、移行直後の確認、定期的な運用の4つのフェーズ・14項目に分けて説明しました。項目数だけを見ると多く感じられますが、いずれも管理ページの設定か、移行ツールの機能で対応できるものです。
移行の成否を分けるのは、転送作業そのものではなく、アクセス権限の設計と、非対応ファイルの事前チェックです。この2つを丁寧に進めておけば、転送はツールに任せられ、移行後のトラブルも大幅に減らせます。
人手や時間が足りない場合は、調査から移行作業までを代行するデータ移行サービスを利用する方法もあります。本記事のチェックリストを手元に置き、自社でできる範囲と任せる範囲を切り分けながら、移行計画を立ててみてください。初めての移行でも、この順番で一つずつ進めていけば、確実に完了できます。
