オンプレミスからクラウドへの移行 実践ガイド
オンプレミス環境からクラウドへの移行を成功させるための実践ガイド。TCO比較、メール移行、ファイルサーバー移行、認証基盤の移行、運用変更まで、段階的な移行手順を詳しく解説します。
目次
1. クラウド移行の判断基準
「クラウドに移行すべきか」は、中小企業のひとり情シスが最も悩む質問の一つです。流行りだからではなく、自社の状況に基づいて合理的に判断しましょう。
TCO（総所有コスト）比較
オンプレミスとクラウドのコストを5年間のTCOで比較します。表面的な月額費用だけでなく、隠れたコストも含めて比較することが重要です。
| コスト項目 | オンプレミス（5年間） | クラウド（M365 / 5年間） |
|---|---|---|
| サーバーハードウェア | 60～100万円 | 0円 |
| OS・CALライセンス | 30～50万円 | 月額に含む |
| 電気代 | 30～50万円 | 0円 |
| UPS・空調 | 10～30万円 | 0円 |
| 保守・サポート費 | 50～100万円 | 月額に含む |
| バックアップ機器・媒体 | 10～30万円 | 0円（クラウド内で冗長化） |
| 月額・年額利用料 | 0円 | 約94万円/年 × 5 = 470万円（50名 × Business Standard） |
| 障害対応の人件費 | 50～100万円（推定） | 大幅減（SLA 99.9%） |
| 合計（5年間） | 240～460万円 | 約470万円 |
ポイント：TCOだけを見ると、中小企業ではクラウドとオンプレミスの費用は大きく変わらないケースもあります。しかし、TCOには「ひとり情シスの時間コスト」が十分に反映されていません。サーバーの物理管理、深夜の障害対応、バックアップ確認、ハードウェア更新の計画と実施にかかる時間を時給換算すると、クラウドのメリットはさらに大きくなります。ひとり情シスの時間を「戦略的なIT活用」に振り向けることが、クラウド移行の真の価値です。
移行パターン
クラウド移行には段階的なアプローチがあります。一度にすべてを移行する必要はありません。
| パターン | 説明 | 期間目安 | リスク |
|---|---|---|---|
| 段階移行（推奨） | メール → ファイル → 認証の順に段階的に移行 | 6ヶ月～1年 | 低（問題を早期発見可能） |
| 一括移行 | すべてのシステムを一度に移行 | 1～3ヶ月 | 高（問題発生時の影響が大きい） |
| ハイブリッド | 一部をクラウドに残しつつ共存運用 | 継続的 | 中（管理対象が増える） |
⚠️ 注意
ひとり情シスの場合、一括移行は絶対に避けてください。万一問題が発生した場合、すべてのシステムが同時に影響を受け、一人では対処しきれません。段階的に移行し、各段階で安定稼働を確認してから次のステップに進むのが鉄則です。
移行を決定する前のチェックリスト
- インターネット回線の帯域は十分か（50名なら最低100Mbps推奨）
- インターネット回線の冗長化はされているか（メイン＋バックアップ）
- 社内で利用しているアプリケーションはクラウドに対応しているか
- 取引先からのセキュリティ要件でクラウド利用に制限はないか
- 業界規制（金融、医療等）でデータの国内保存要件はないか
- 経営層のクラウド移行への理解は得られているか
2. メール移行（Exchange → Exchange Online）
メールは業務の生命線であり、移行は最も慎重に行う必要があります。同時に、クラウド移行の最初のステップとしても最適です（影響範囲が明確で、切り戻しも比較的容易なため）。
移行方式の選定
| 移行方式 | 概要 | 対象 | ダウンタイム |
|---|---|---|---|
| カットオーバー移行 | 全メールボックスを一括で移行 | メールボックス150個以下 | 数時間～1日 |
| 段階的移行 | バッチに分けて段階的に移行 | Exchange 2003/2007 | バッチごとに数時間 |
| ハイブリッド移行 | オンプレExchangeと共存しながら順次移行 | Exchange 2010以降 | ほぼゼロ |
| IMAP移行 | IMAPプロトコルでメールをコピー | 非Exchange環境 | メール量による |
| サードパーティツール | BitTitan MigrationWiz等 | 全環境 | ツールによる |
ポイント：中小企業で最もシンプルなのは「カットオーバー移行」です。週末にDNSのMXレコードを切り替え、一気にExchange Onlineに移行します。ただし、メールボックスの総容量が大きい場合（合計50GB以上）は事前のデータ移行に時間がかかるため、余裕を持ったスケジュールを立てましょう。
移行前の準備
- 現環境の棚卸し：メールボックス数、容量、配布リスト、パブリックフォルダ、転送ルールの一覧を作成
- M365テナントの準備：カスタムドメイン追加、ユーザーアカウント作成、ライセンス割り当て
- 移行テスト：テスト用メールボックスで移行を実施し、手順と所要時間を確認
- ユーザーへの周知：移行日時、影響範囲、Outlookの再設定手順を事前に通知
- 切り戻し計画：移行がうまくいかない場合の手順を準備
移行後の確認事項
- 全ユーザーのメール送受信テスト
- 配布リスト（メーリングリスト）の動作確認
- 共有メールボックスの動作確認
- Outlookの自動設定（Autodiscover）の動作確認
- モバイルデバイスのメール設定
- SPF、DKIM、DMARCレコードの確認
- 旧メールサーバーの停止（DNS伝播完了後、1～2週間後に）
📋 具体例
メール移行スケジュール例（カットオーバー方式）：2週間前：M365テナント準備完了、ユーザーアカウント作成。1週間前：ユーザーへの移行通知メール送付、FAQ配布。金曜18時：メールボックスデータの移行開始（BitTitan MigrationWiz使用）。土曜朝：移行完了確認、テストメール送受信。土曜昼：DNS MXレコード切替。日曜：DNS伝播確認、全ユーザーの受信テスト。月曜朝：ユーザーのOutlook再設定サポート（ヘルプデスク体制）。1週間後：旧サーバーを監視モードに（念のためメール転送設定）。1ヶ月後：旧メールサーバー完全停止。
3. ファイルサーバー移行（SharePoint Online / OneDrive）
ファイルサーバーの移行は、メール移行よりも複雑で時間がかかるケースが多いです。ファイル構造の見直しやアクセス権の再設計が必要な場合もあります。
移行先の選定
| 移行先 | 適するデータ | 容量 | 特徴 |
|---|---|---|---|
| SharePoint Online（チームサイト） | 部門・プロジェクトの共有ファイル | サイトあたり25TB | チームでの共同編集、バージョン管理 |
| OneDrive for Business | 個人の業務ファイル | 1TB/ユーザー | 個人ファイルの同期、モバイルアクセス |
| Teams（SharePoint連携） | チーム単位の共有ファイル | チームサイトと共有 | Teamsのチャネルからアクセス |
移行前のファイル整理
移行の前に、ファイルの棚卸しと整理を行うことで、移行後の利便性が大幅に向上します。
- 不要ファイルの削除：3年以上アクセスされていないファイルの確認。部門に確認し、不要なら削除またはアーカイブ
- フォルダ構造の見直し：10階層以上の深い構造は、SharePointの制限（パス文字数400文字）に引っかかる可能性あり
- ファイル名の修正：SharePointで使用できない文字（* : " < > ? / \ |）を含むファイル名を修正
- 大容量ファイルの対処：SharePointのファイルサイズ上限は250GB。超大容量ファイルがある場合は別途対処
⚠️ 注意
ファイルサーバーの全データをそのままSharePointに移行するのはお勧めしません。「引っ越しは断捨離のチャンス」と同じで、移行を機にファイル構造とアクセス権を見直しましょう。不要なファイルまで移行すると、クラウドストレージの容量を圧迫するだけでなく、ユーザーの利便性も低下します。
移行ツール
| ツール | 費用 | 特徴 | 推奨場面 |
|---|---|---|---|
| SharePoint Migration Tool（SPMT） | 無料 | マイクロソフト公式ツール。ファイルサーバー/SharePointオンプレからの移行 | 標準的な移行 |
| Migration Manager | 無料 | クラウドベースの移行管理。複数のエージェントで並列移行 | 大規模な移行 |
| BitTitan MigrationWiz | 有料 | 多機能。スケジュール移行、差分移行対応 | 複雑な移行 |
| Mover (by Microsoft) | 無料 | クラウド間の移行（Google Drive → OneDrive等） | クラウド間移行 |
📋 具体例
ファイルサーバー移行計画例：総容量500GBの社内ファイルサーバーを移行する場合。フェーズ1（2週間）：ファイル棚卸しと整理。不要ファイル100GBを削除し400GBに削減。フェーズ2（1週間）：SharePointサイト構造設計。部門別サイトとアクセス権を設計。フェーズ3（2週間）：SPMTで初回移行（400GB）。業務時間外に実施。フェーズ4（1週間）：ユーザーにSharePointの使い方を教育。フェーズ5（週末）：差分移行で最新データを同期し、ファイルサーバーを読み取り専用に変更。フェーズ6（2週間）：並行運用期間。問題なければ旧ファイルサーバーを停止。
4. 認証基盤の移行（オンプレAD → Entra ID / ハイブリッド）
認証基盤の移行は、クラウド移行の最も複雑な部分です。ユーザーのログイン体験に直結するため、慎重に進める必要があります。
移行パターン
| パターン | 概要 | メリット | デメリット | 推奨場面 |
|---|---|---|---|---|
| クラウド専用 | Entra IDのみ使用。オンプレADは使わない | 管理がシンプル。サーバー不要 | オンプレAD依存のアプリが使えない | 新規導入、小規模企業 |
| ハイブリッド（Entra ID Connect） | オンプレADとEntra IDを同期 | SSO実現。段階的な移行が可能 | 同期サーバーの管理が必要 | 既存AD環境からの移行 |
| 完全クラウド移行 | ハイブリッドを経て最終的にクラウド専用に | オンプレサーバー全廃 | 移行に時間がかかる | 長期的な目標として |
ポイント：既にオンプレADを運用している中小企業は、まず「ハイブリッド構成」を目指すのが現実的です。Entra ID Connect（旧Azure AD Connect）でオンプレADとEntra IDを同期し、ユーザーは既存のADアカウントでM365にもログインできるようにします。将来的にオンプレADに依存するアプリケーションがなくなれば、完全クラウドへの移行を検討できます。
Entra ID Connect（ハイブリッド構成）
Entra ID Connectは、オンプレADのユーザー・グループ情報をEntra IDに同期するツールです。
同期の仕組み
- 同期方向：オンプレAD → Entra ID（一方向。クラウド側の変更はオンプレに戻らない）
- 同期間隔：デフォルト30分。変更があれば次回の同期でEntra IDに反映
- 同期対象：ユーザー、グループ、連絡先。OUフィルタリングで同期対象を限定可能
- パスワード同期：パスワードハッシュ同期（PHS）により、ADパスワードでM365にログイン可能
導入手順の概要
- Entra ID Connectサーバーの準備（ドメイン参加済みWindows Server）
- Entra ID Connect のインストールと構成ウィザードの実行
- 同期対象のOU選択
- 認証方式の選択（パスワードハッシュ同期を推奨）
- 初回同期の実行と確認
- ユーザーのUPNとメールアドレスの一致確認
⚠️ 注意
Entra ID Connectの導入前に、オンプレADのUPN（User Principal Name）がメールアドレスと一致していることを確認してください。UPNが「user@domain.local」のようなルーティング不可能なドメインの場合、M365へのログインに問題が発生します。事前にUPNを「user@example.co.jp」に変更する作業が必要です。この変更は影響が大きいため、十分にテストしてから実施してください。
認証方式の選択
| 認証方式 | 概要 | メリット | デメリット |
|---|---|---|---|
| パスワードハッシュ同期（PHS） | パスワードハッシュをEntra IDに同期 | シンプル。オンプレAD障害時もM365にログイン可能 | パスワードハッシュがクラウドに保存される |
| パススルー認証（PTA） | 認証要求をオンプレADに中継 | パスワードがクラウドに保存されない | オンプレAD障害時はM365にもログイン不可 |
| フェデレーション（AD FS） | AD FSサーバーで認証 | 最も柔軟なカスタマイズ | AD FSサーバーの管理が必要。複雑 |
📋 具体例
ハイブリッド構成の移行スケジュール例：1ヶ月目：ADのUPN確認・修正、M365テナント準備。2ヶ月目：Entra ID Connectサーバー構築、テスト同期。3ヶ月目：本番同期開始、パイロットユーザー（IT部門）でテスト。4ヶ月目：全ユーザーへの展開、MFAの有効化。5ヶ月目：メール移行（Exchange Online）。6ヶ月目：ファイルサーバー移行開始。以降、段階的にクラウドサービスの活用範囲を拡大していきます。
5. 移行後の運用変更点と注意事項
クラウド移行後は、オンプレミス時代とは異なる運用スタイルに適応する必要があります。
運用体制の変化
| 項目 | オンプレミス時代 | クラウド移行後 |
|---|---|---|
| 障害対応 | 自社で全て対応 | クラウド側障害はマイクロソフトが対応。自社は影響確認と連絡が中心 |
| バックアップ | 自社で設計・運用 | M365標準のデータ保護＋必要に応じてサードパーティバックアップ |
| セキュリティ | FW/UTMでの境界防御 | ゼロトラスト（ID中心のセキュリティ）へシフト |
| パッチ管理 | WSUS等で自社管理 | SaaSは自動更新。IntuneでPC管理 |
| キャパシティ管理 | ハードウェアの拡張計画 | ライセンス数とストレージ容量の管理 |
注意すべきポイント
- インターネット回線が単一障害点に：オンプレミス時代はLAN内で完結していた業務が、クラウド移行後はインターネットに依存します。回線の冗長化は必須です
- M365のバックアップ問題：M365はデータの冗長化はしていますが、ユーザーが誤って削除したデータの長期保持は保証しません。サードパーティのバックアップサービス（Veeam Backup for M365等）の導入を検討してください
- コスト管理：ライセンスの使い過ぎや未使用ライセンスの放置に注意。月次でライセンス利用状況を確認する習慣をつけましょう
- ユーザー教育：新しいツール（Teams、SharePoint）の使い方を丁寧に教育しないと、結局メール添付でファイルをやり取りする旧来の働き方に戻ってしまいます
ポイント：クラウド移行後のひとり情シスの役割は、「サーバーの管理者」から「ITサービスのマネージャー」に変わります。ハードウェアの世話をする時間が減る分、M365の新機能の活用検討、セキュリティ対策の強化、ユーザーのITリテラシー向上支援など、より戦略的な業務に時間を使えるようになります。この変化を前向きに捉え、自身のスキルアップにもつなげましょう。
⚠️ 注意
クラウド移行で最も見落とされがちなのが「ユーザーサポートの負荷増大」です。移行直後の1～3ヶ月は、新しいツールの使い方に関する問い合わせが大幅に増加します。事前にFAQドキュメントを準備し、部門ごとにITリーダー（スーパーユーザー）を育成しておくことで、ひとり情シスへの問い合わせ集中を緩和できます。
移行後の定期確認事項
| 頻度 | 確認項目 | ツール・方法 |
|---|---|---|
| 日次 | M365サービス正常性 | M365管理センター → サービス正常性 |
| 週次 | セキュリティアラートの確認 | Microsoft 365 Defender |
| 月次 | ライセンス利用状況 | M365管理センター → ライセンス |
| 月次 | SharePointストレージ使用量 | SharePoint管理センター |
| 四半期 | 外部共有の棚卸し | SharePoint管理センター → 共有 |
| 四半期 | ゲストアカウントの棚卸し | Entra ID → ゲストユーザー |
| 年次 | 条件付きアクセスポリシーの見直し | Entra ID → セキュリティ |
| 年次 | DLPポリシーの見直し | Microsoft Purview |
クラウド移行は一度で完了するプロジェクトではなく、継続的な改善のプロセスです。最初の移行を完了したら、ユーザーからのフィードバックを収集し、より効果的なクラウド活用に向けて改善を続けていきましょう。