Outlook→Google Calendar 移行：部門別チェックリスト

M365（Microsoft 365）から GWS（Google Workspace）への段階移行では、カレンダーの共存期間が運用上のボトルネックになりやすい。この記事では、部門ごとに移行タイミングが異なる混在期間を安全に乗り切るための設計観点と注意点を整理します。

この記事を読んだほうが良い人

• 全社一斉移行ではなく、部門ごとに GWS 移行スケジュールを組んでいる情シス担当者
• Outlook ↔ Google Calendar 間での会議招待・空き確認・会議室予約が共存期間中にどう機能するか把握したい方
• Outlook Google Calendar 移行の実務で、移行前に確認すべき設定や手順を一覧で押さえておきたい方

Outlook と Google Calendar の移行で詰まる 3 つのポイント

M365 と GWS は、互いに異なるカレンダープロトコルを採用しています。M365 は EWS（Exchange Web Services）と Microsoft Graph API、Google Workspace は Google Calendar API と CalDAV です。この違いが共存期間中の混乱の根本原因になります。

100 名規模の企業では「営業チームは今月中に GWS へ、経理は四半期末後」のように部門別スケジュールになることが多く、その間の 2〜3 ヶ月が最も管理コストの高い期間です。

主な詰まりポイントは次の 3 点です。

• 会議招待の互換性: Outlook ユーザーが GWS ユーザーを招待すると、ICS（iCalendar 形式）の添付ファイルまたはリンクとしてメールで届く。相手が Google カレンダーから参加を押せば予定として登録されるが、その後 Outlook 側で日時を変更した場合、更新通知が Google カレンダーに正確に反映されるかどうかは相手の操作次第になる
• 空き状況の確認: Calendar Interop（カレンダー相互運用）を設定しない限り、Outlook のスケジュールアシスタントから GWS ユーザーの空き情報は参照できない
• 会議室リソースの二重管理: Exchange に登録された会議室と Google カレンダーの会議室リソースは別々のシステムで管理されるため、混在期間中は二重予約が発生しやすい

特にトラブルが多いのは定期会議（繰り返し予定）の扱いです。単発の予定は「書き換えて終わり」で完結しますが、毎週の定例会議はすべての参加者が GWS へ移行し終わるまでシステムが混在します。「Outlook 側の変更が GWS 参加者に届いていなかった」というトラブルは、定期会議の日程変更が発生したタイミングで集中して起きます。

移行前チェックリスト

部門の移行を開始する前に、次の観点を確認します。

カレンダーデータの移行方針

• [ ] 過去の予定データをどこまで移行するか（例: 直近 1 年分のみ）を決める
• [ ] GWMME（Google Workspace Migration for Microsoft Exchange）を使った移行対象ユーザーのリストが揃っているか確認する
• [ ] 会議の詳細説明がリッチテキスト形式の場合、移行後にプレーンテキストに変換されることを関係者に周知する（GWMME の公式仕様）
• [ ] カレンダーに添付ファイル付きの予定が存在する場合、GWMME では添付ファイルは移行されない点を確認する
• [ ] 定期会議の扱いを決める: 移行日以降も繰り返しが続く定期会議については、移行後の日程分を GWS で新規作成するか、Outlook の招待を継続受信する運用にするかを、部門ごとに判断する

共有カレンダー・権限の整理

• [ ] Exchange 上のチームカレンダーや部門カレンダーを棚卸しする
• [ ] カレンダーの共有権限（閲覧のみ・編集可・代理操作可）を移行先 GWS で再設定する担当者を決める
• [ ] 外部パートナーとの定例会議の招待を書き換えるタイムラインと担当者を決める
• [ ] 代理操作（メールボックス委任）を使っているユーザーを洗い出す: Exchange で秘書・アシスタントが上司のカレンダーを代理操作している場合、GWS 側で同等の権限設定が必要になる。移行前に利用者リストを確認する

Calendar Interop の設定判断

• [ ] 混在期間中に Outlook ↔ Google カレンダー間で空き状況を相互参照する必要があるか判断する
• [ ] Calendar Interop を使う場合、Exchange 2016 以降または Exchange Online が接続要件であることを確認する
• [ ] Calendar Interop を有効にしても、Exchange で非公開に設定された予定の詳細は Google カレンダー側に表示されない点を把握する
• [ ] 設定完了から反映までのラグを把握する: Calendar Interop を有効化してから双方向で空き情報が安定参照できるようになるまで、環境によって数時間から 1 日程度かかる場合がある。移行直前の土日に設定を完了させ、月曜朝に動作確認するスケジュールが安全

会議室リソースの現状把握

• [ ] Exchange に登録されている会議室リソースの一覧を取得する
• [ ] 各会議室の移行先（GWS のリソースとして新規登録するか、暫定的に Exchange 管理を継続するか）を決める
• [ ] 複数部門をまたぐ定例会議で使われている会議室を洗い出す
• [ ] すでに予約済みの会議室データを確認する: GWMME でユーザーカレンダーを移行しても、Exchange の会議室リソース側に記録されている予約データは移行対象外。移行後の予定に会議室が「参加者として」記録されていても、GWS のリソースカレンダーとしては認識されないため、担当者による再設定が必要になる

共存期間の設計パターン（部門別スケジュール例）

100 名規模で 3 ヶ月かけて順次移行するパターン例は以下の通りです。組織の業務サイクルに合わせて調整します。

フェーズ	対象部門	カレンダー環境	会議室予約ルール
1 ヶ月目	情シス・先行チーム	GWS 開始 / Exchange 縮小	GWS で予約（Exchange 室は暫定二重管理）
2 ヶ月目	営業・マーケティング	GWS 開始 / Exchange 縮小	GWS で統一（Exchange は経理のみ）
3 ヶ月目	経理・総務・全社	Exchange 廃止・全員 GWS	GWS に一本化
共存期間全体	全員	Calendar Interop で空き参照	部門ごとのルールを文書化

設計パターンには主に 3 つの選択肢があります。

パターン A: Calendar Interop を設定して空き情報を共有しながら共存する

GWS 移行済み部門と Exchange 残留部門が互いの空き情報を参照できる状態にします。運用の摩擦が最も少なく、Exchange Online（M365）を使っている場合は現実的な選択肢です。設定には IT インフラ担当との調整が必要で、Exchange 側での EWS 有効化と GWS 管理コンソールでの接続設定が伴います。混在期間が 2 ヶ月以上になる場合、このパターンの設定投資は確実に回収できます。

パターン B: ICS 購読で片方向の参照にとどめる

Google Workspace 管理コンソールのカレンダー設定から取得できる ICS 購読 URL を Outlook に追加する方法です。更新が即時反映されない（最大 24 時間程度の遅延が発生することがある）ため、変更が少ない祝日カレンダーや外部公開予定の参照に限定するのが適切です。社内の定例会議への利用は遅延リスクがあるため推奨しません。

パターン C: 全社まとめて一斉移行する

共存期間を設けずに 1 日で切り替えます。組織規模が小さく外部パートナーとの定例が少ない場合は最もシンプルな方法です。ただし移行当日にサポートが集中するため、情シスの人員リソースを事前に確保します。ユーザー数が多い場合は移行ツールの処理完了に数時間かかることもあるため、業務開始前（例：金曜夜〜土曜朝）に実行するスケジュールが現実的です。

会議室リソース移行の注意点

会議室リソースの移行は、カレンダー移行の中で最も見落とされがちな領域です。

Exchange の会議室と Google カレンダーのリソースは独立したシステム

Exchange に登録された会議室メールボックスと、Google カレンダーのリソースカレンダーは別々のオブジェクトです。GWMME でユーザーのカレンダーデータを移行しても、会議室リソースのデータは自動では引き継がれません。移行後の予定に含まれていた Exchange の会議室情報は参加者リストとして残りますが、Google のリソースカレンダーとしては認識されないため、担当者による再設定が必要です。

混在期間中の二重予約リスクへの対処

一部の部門が GWS 移行済みで、別の部門がまだ Exchange を使っている状態では、同じ物理的な会議室に対して両システムから予約が入る可能性があります。対処方法は次の 3 つです。

• 会議室を Exchange 専用と GWS 専用に一時的に分割して運用する
• Calendar Interop を設定して空き状況を相互参照できるようにする（予約確定は各システムで行う）
• 混在期間中はチャットや物理的なホワイトボードを会議室予約の一時的な管理手段とする

会議室の数が多い場合は Calendar Interop の設定投資が回収しやすく、3 部屋以下の少人数オフィスなら分割運用かホワイトボード管理のほうがシンプルです。どのパターンを選んだとしても、ルールを 1 枚の文書に書いて全員に周知することが混乱を防ぐ最大の施策です。口頭説明だけでは混在期間が終わる頃には誰も覚えていません。

やってはいけないNG手順

NG 1: 外部パートナーに事前連絡なしで招待送信元を変える

外部との定例会議の招待主が Outlook から Google カレンダーに移行すると、次の更新送信時に送信元アドレスが変わります。相手の Outlook には新しい招待として届き、旧招待と二重になることがあります。移行の 1〜2 週間前に「カレンダー招待の送信元が変わります」と一報を入れるだけで、この混乱を防げます。

NG 2: ICS の一括インポートを「移行完了」とみなす

Outlook からエクスポートした .ics ファイルを Google カレンダーにインポートするのは、その時点のスナップショット取り込みです。その後 Outlook 側で予定が変更されても Google カレンダーには反映されません。インポートは過去予定の参照用と位置づけ、移行日以降の新規予定は Google カレンダーで一から作成します。特に 1 ヶ月以上先の定期会議がある場合は、インポートデータに頼らず GWS 側で新規作成することを徹底します。

NG 3: Calendar Interop なしで「空き確認は口頭で」と割り切る

Calendar Interop を使わないと、会議を設定するたびに Slack や電話で空き確認が必要になります。設定に数時間かかりますが、2〜3 ヶ月の共存期間を通じた効率化を考えると、導入コストは回収できます。初期設定の手間を惜しんで口頭確認フローを常態化させると、移行後も悪習が残るリスクがあります。

NG 4: 会議室の再設定を移行後に先送りにする

会議室リソースの再設定は、手順と担当者を決めずに移行すると必ず後回しになります。特に複数部門をまたぐ定例会議の会議室は誰が再設定するかが曖昧になりがちです。移行チェックリストに会議室担当者の名前を明記しておくことで、この先送りを防げます。「移行後にやる」は「永遠にやらない」と同義です。

段階移行を成功させるための共存期間設計

カレンダーの混在期間を安全に乗り越えるカギは、どの予定をいつ誰が書き換えるかが全員に周知されていることです。情シス側が手順を決めても、各部門がそれを知らなければ個別対応が増えてサポートコストが膨らみます。

移行前に各部門向けのカレンダー移行ガイドを 1 枚で作成し、次の内容を明記します。

• 切替日
• 既存の Outlook 会議招待を書き換えるタイムライン
• 定期会議の扱い（継続受信 or 新規作成）
• 会議室予約の一時ルール
• 問い合わせ窓口

この 1 枚が共存期間の混乱を大幅に減らします。M365 → GWS の移行プロジェクトでは、Exchange・Gmail の移行が完了した後もカレンダーの完全切り替えが最後まで残るケースが多くあります。カレンダーを移行計画の最初からスコープに入れ、共存期間の設計を早い段階で確定させることが、移行全体のリスクを下げます。

なお、チェックリストは部門数が多いほど「誰が確認済みか」の管理が煩雑になります。Google スプレッドシートで部門別の進捗を一元管理し、情シスがステータスをリアルタイムで把握できる状態にしておくと、混在期間中の問い合わせ対応が格段に楽になります。

コーポレートITのご相談はお気軽に

この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。 「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。