本記事では、Gmailの移行に関してよく寄せられる質問への回答と、移行プロジェクトの作成および実行に関する基本情報を掲載しています。本記事は、移行ガイドを補足するものです。移行プロセスを開始するには、次のリンクから該当する移行ガイドを選択し、その手順に従ってください。

無料のGmail/Googleアカウントの移行は、サポートされていません。

移行できるアイテム

Google Workspaceインスタンスには、メールメッセージからカレンダーまで、さまざまなデータアイテムが存在します。移行できるアイテムと移行されないアイテムのリストは、次の通りです。これらのアイテムの一部は、エンドポイントによって異なる場合があるため、使用するエンドポイントを確認した上で、本リストを参照してください。以下をクリックすると、移行できるアイテムのリストが表示されます。

最大ファイルサイズ

MigrationWizでは、移行可能な最大ファイルサイズは、移行タイプと環境によって異なります。ただし、60GBを超えるファイルは、移行することはできません。

移行速度

移行速度は、さまざまな不確定要素の影響を受けるため、正確に予測することはできません：

• 各メールボックスは、異なるコネクタ、異なるサーバーを経由します。Microsoft 365からGoogle Workspaceへのデータ移行で、同じソフトウェアとハードウェアから成る2つのコネクタで速度を比較した時に、移行速度が同じでないことが証明されています。
• 「フォルダー」を「ラベル」に変換する移行では、フォルダーとラベルの数が、移行元と移行先の速度に影響する場合があります。たとえば、Microsoft 365のフォルダー数が多いほど、応答にかかる時間は長くなり、Google Workspaceでも同様に、時間が長くかかることが証明されています。
• 移行先でのレプリケーション戦略。GoogleのSLA要件により、移行と同時進行で、Googleによるフェイルオーバーまたはレプリケーションサイクルが移行先で行われる場合(Googleでは、データは複数のデータセンターに複製されます)、移行先ではさまざまに異なる移行速度が報告されることがあります。

 移行速度の影響を軽減するには、「前段階移行(Pre-Stage Migration)」戦略に従うことをお勧めします。

フィールドマッピング 

デフォルトでは、すべてのラベル/フォルダーが移行されます。「受信トレイ」は、移行先の「受信トレイ」 システムフォルダーにマップされます。 ラベル付きアイテムは、対応する各フォルダーに移行されます(「ラベルをフォルダーに変換」が、有効のままになっている場合のみ)。 フォルダーは、純粋に名前でマッピングされます(フォルダー名に無効な文字が含まれている場合、MigrationWizでは、それらを有効な文字に置き換え、名前を変更します)。

Gmailラベルの変換：

• • ラベルをフォルダーに変換 － これは、デフォルトの動作です。
  • ラベルをカテゴリに変換 － これは、オプションとして(プロジェクトの「詳細オプション(Advanced Options)」で)設定することができます。

Gmail移行におけるラベルの扱い

GmailからGmailへの移行では、ラベルは自動的に移行されます。Gmailから別のプラットフォームへの移行では、移行中にラベルの変換が必要になる場合があります。 

Gmailラベルの変換と移行

Gmailでは、フォルダー階層ではなく、ラベルと呼ばれる仮想ビューを使用して、メールを分類します。ラベルは、他のメッセージングシステムにはない、Google独自の機能です。Google自体も、現在のラベル機能を以前から確立していたわけではありません。メッセージは、Gmailのデータストアに1つのインスタンスとして保存されますが、Webインターフェースの複数のラベル内にも表示されます。OutlookやモバイルデバイスなどのIMAPクライアントからGmailに接続している場合、ラベルはフォルダーとして表示され、複数回ダウンロードされるため、ストレージを余分に消費します。

Gmailを移行元とする移行では、新しいメッセージング環境に合わせてラベルを変換するための選択肢が、いくつか設けられています。各変換方法には長所と短所があるため、内容をよく理解して、最適な方法を選択することが重要です。オプション：1) ラベルをフォルダーに変換する、または、2) ラベルをExchangeカテゴリに変換する。

ラベルをフォルダーに変換する：

最も一般的な方法は、ラベルをフォルダーに変換する方法です。これは、移行後の構造やビューが、現在使用しているGmailとほぼ同じになるということです。この方法の短所は、メッセージが対応する各フォルダーに複製されて格納されるため、メールボックスのサイズが大きくなることです。アイテムを1つのインスタンスとして保存する概念はなく、フォルダーの数だけアイテムが複製されます。

長所：

• Gmailと同様の構造とビュー。
• Webアクセス、デスクトップクライアント(Outlook など)、モバイルデバイス全般における、一貫したエクスペリエンス。
• アーカイブされたアイテムのみが、「All Mail」フォルダーに移行されます。

短所：

• 複数のコピーが保存されるため、メールボックスのサイズが大きくなります。

MigrationWizでは、ラベル名に「/」が含まれている場合、サブフォルダーが作成されます。たとえば、移行元のラベル名が「aaa/bbb/ccc」の場合、MigrationWizでは、まずフォルダー「aaa」が作成され、次に「aaa」内にフォルダー「bbb」が作成され、さらに「bbb」内にフォルダー「ccc」が作成されます。移行中は、これらのフォルダー名を変更しないようにしてください。

ラベルをExchangeカテゴリに変換する：

この方法では、Gmailの「すべてのメール」ラベルのみが移行されます。「すべてのメール」ラベルには、「ゴミ箱/削除済みアイテム」を除くGmailのすべてのメッセージが含まれており、各メッセージのコピーが1つだけ移行されるため、移行先のメールボックスのサイズは、Gmailのサイズと同じになります。 

長所：

• すべてのメッセージについて、コピーが1つだけ移行されるため、メールボックスのサイズが大きくなることはありません。
• ラベルはExchangeカテゴリに変換され、各アイテムに紐づけられます。
• カテゴリに基づいた検索フォルダーが作成され、Exchange内に仮想ビューが作成されます。

短所：

• Exchangeで大きなフォルダーを開く際に、パフォーマンスの問題が発生する場合があります。
• OWAまたはモバイルデバイスでは、Outlookで作成された検索フォルダーは表示されません。
• メールクライアントが、Exchangeカテゴリフィルターまたは検索フォルダーをサポートしていない場合は、すべてのアイテムを含む1つのフォルダーのみが表示されます。
• 「ゴミ箱」と「削除済みアイテム」内のアイテムは、移行されません。

次のいずれかの方法を選択します：

最初のオプション(ラベルをフォルダーに変換する)は、デフォルトの設定です。これを選択する場合、追加の操作は不要です。2番目のオプション(ラベルをカテゴリに変換する)を選択する場合：

1. MigrationWizアカウントにサインインします。
2. 「プロジェクトの編集」をクリックします。
3. 「詳細オプション(Advanced Options)」をクリックします。
4. 「移行元/移行先(Source/Destination)」をクリックし、「すべてのメールフォルダーの処理(All Mail Folder Handling)」フィールドで、該当するオプションを選択します。

移行後のメッセージ数の増加

Gmailには、フォルダーの概念はなく、代わりに「ラベル」と呼ばれる機能を使用します。「ラベル」は、基本的にはメッセージを分類するタグのことです。1つのメッセージに、1つまたは複数のラベルを付けることができます。

Gmailを移行元とする移行では、すべてのラベルがフォルダーに変換されます。メッセージに付けられたラベルの数だけメッセージのコピーが作成され、対応する各フォルダーに1つずつ格納されます。たとえば、メッセージに「A」、「B」、「C」のラベルが付いている場合、デフォルトでは、「/A」、「/B」、「/C」の3つのフォルダーに、同じメッセージが1つずつ作成されます。

Gmailには、「すべてのメール」という名前のラベルがあり、メールボックス内のすべてのメッセージのコピーが含まれています。デフォルトでは、アーカイブされたメール(ラベルのないメール)のみが、移行先の「All Mail」フォルダーに移行されます。 

複数のラベルを1つのフォルダーにマッピングする

端的に言うと、これは不可能です。各ユーザーは、どのラベルを他のラベルよりも優先するかを指定しなければならず、面倒なプロセスが必要になります。優先するラベルを指定できたとしても、移行中にデータが欠落してしまう恐れがあります。

Gmailの「すべてのメール」ラベルを活用する 

最善の方法は、最終サイクルまで「すべてのメール」ラベルを除外して移行を実行するという方法です。Gmailでは、ほとんどのアイテムにラベルが付けられ、個々のラベル内にそのアイテムが表示されますが、「すべてのメール」ラベル内にも、すべてのアイテムのコピーが保持されているためです。

「すべてのメール」ラベルを除外せずに移行を実行する場合、MigrationWizでは、移行の実行前に、「すべてのメール」ラベル内の全アイテムのインデックス作成が必要になります。通常、「すべてのメール」はサイズが非常に大きいため、インデックスの作成には、非常に長い時間がかかります。

「前段階移行(Pre-Stage Migration)」および「完全(差分)移行(Full (Delta) Migration)」サイクルでは、「すべてのメール」ラベルを除外するフィルターを設定した後に、他のすべてのラベルを移行することをお勧めします。その後、「すべてのメール」ラベルのフィルターを削除して、最後の「完全(差分)移行(Full (Delta) Migration)」サイクルを実行します。この最終サイクルでは、「すべてのメール」ラベル内の、ラベルが付いていないアイテムに対してインデックスが作成され、それらがすべて移行されます。

MigrationWizプロジェクトの「詳細オプション(Advanced Options)」でフィルターを追加する手順は、次の通りです。このフィルターは、最終サイクル(本セクションの最後で説明しますが、フィルターを削除する必要があります)を除いて、すべてのサイクルで設定したままにしておく必要があります。

1. MSPCompleteダッシュボードにログインします。
2. 左のナビゲーションパネルの「最近の顧客(RECENT CUSTOMERS)」リストから、該当する顧客を選択します。
3. 上部のナビゲーションバーのオプションをクリックします。
4. 一覧から、該当するプロジェクト名をクリックします。これにより、MigrationWizポータルが起動し、選択したプロジェクトが表示されます。
5. 上部のナビゲーションバーで、「プロジェクトの編集」をクリックします。
6. ドロップダウンリストから、「詳細オプション(Advanced Options)」を選択します。
7. 「フィルタリング」で、次を追加します： (^All Mail$|^All Mail/)　これにより、「すべてのメール」ラベルとそのサブラベルが、フィルター処理されます。
8. 「保存(Save)」をクリックします。 

お客様のシナリオに合った移行ガイドの手順に従って、移行を実行してください。

すべてのサイクルを完了した後に、フィルターを削除し、もう一度追加で最終サイクルを実行します。 この最終サイクルは、ユーザーが移行先アカウントの使用を開始した後でも、実行することができます。

最終サイクルでこのフィルターを削除するには、次の手順に従います：

1. MigrationWizプロジェクトのダッシュボード上部のナビゲーションバーで、「プロジェクトの編集」をクリックします。
2. ドロップダウンリストから、「詳細オプション(Advanced Options)」を選択します。
3. 「フィルタリング」で、以前に追加したフィルターを削除します。
4. 「保存(Save)」をクリックします。 
5. 移行するアイテムを選択し、「移行を開始」をクリックします。ドロップダウンリストから、「完全移行(Full Migration)」を選択し、プロンプトに従って、移行サイクルを開始します。このサイクルで移行されるのは、「すべてのメール」ラベルにだけあって、他のラベルにはない、残りのすべてのアイテムです。これらは通常、わずかな削除済みアイテムと、(ラベルの付いていない)アーカイブされたアイテムだけになります。これらのアイテムは、ユーザーによって認識されていないことも多いですが、完全性を確保するために、移行するのが最善です。

「スター付き」、「重要」、「重要度－高」ラベル

「スター付き」のアイテム、「重要」マーク付きのアイテム、または、「重要度－高」設定をサポートするメールクライアントから送られた「重要度－高」マーク付きのアイテムを、GmailからExchangeへ移行する場合、独自の変換動作が行われます。

「スター付き」アイテム：  「スター付き」アイテムは、移行先のメールボックスでは、赤色のフラグ付きで表示され、フォローアップ対象としてマークされたことが分かります。

「重要度－高」アイテム：  メールクライアントから「重要度－高」で送信されたアイテムは、移行後もその状態が維持されます。

「重要」アイテム：「重要」マーク付きのアイテムは、移行先のメールボックスでは、識別可能なマークは付けられず、  通常のメールアイテムとして​表示されます。

Gmailを移行元とする移行で、アイテムに何らかのタグが付けられている場合、そのタグは、そのアイテムに付けられた他のどのラベルよりも優先されます。

「受信トレイ/フォルダー名」ラベルへのマッピング 

移行先がGmailの場合、デフォルトでは、「受信トレイ」フォルダーの配下にあるフォルダーは、「受信トレイ/フォルダー名」ラベルに移行されます。

この動作を変更するには、プロジェクトの「詳細オプション(Advanced Options)」の「サポート(Support) / サポートオプション(Support Options)」で、フォルダーマッピングのオプションを追加します。

一般的なオプションは： 

FolderMapping="^INBOX/->"　これを追加することにより、移行先のメールボックスで、フォルダーが「受信トレイ/ラベル名」のような階層ではなく、ルートにマップされるようになります。

オプションを追加する手順は、次の通りです：

• MigrationWizダッシュボードで、「プロジェクトの編集」をクリックします。
• ドロップダウンリストから、「詳細オプション(Advanced Options)」を選択します。
• 「サポート(Support)」をクリックします。
• 「サポートオプション(Support Options)」フィールドで、次のテキストを入力します： FolderMapping="^INBOX/->"
• 「+」ボタンをクリックします。
• 「保存(Save)」をクリックします。
• 「プロジェクトを保存(Save Project)」ボタンをクリックして、プロジェクトダッシュボードに戻ります。

このフォルダーマッピングが適用されると、移行元のユーザーメールボックスで、「test」という名前のフォルダーが、ルートと「受信トレイ」フォルダーの両方にある場合、移行先のGmailでは、それらは同じラベルにマージされ、ルートラベル内に表示されます。

Gmailでは、フォルダーの代わりにラベルを使用して、アイテムを分類します。ソーシャルネットワークや写真共有サイトでのタグ付けのように、1つのメッセージに複数のラベルを付けることができるため、ラベルを活用することで、アイテムの整理がより簡単になります。

Google Workspaceエンドポイント

MigrationWizでは、Google Workspaceの移行に、2つのエンドポイントを使用することができます。詳細については、メールボックス移行のためのGoogle APIの設定を参照してください。本セクションでは、Google APIエンドポイントの設定手順について説明します。Google APIエンドポイントを使用すると、IMAPエンドポイントよりも多くのアイテムを移行することができます。Google APIエンドポイントは、IMAPよりも安定しており、テナントがIMAP接続を許可しない場合でも機能します。 

カレンダーを移行する

Google Workspaceでは、カレンダーの共有がサポートされています。メールボックスごとに、ユーザーが所有するカレンダーのみが移行されます(つまり、他のユーザーが所有するカレンダーは、移行されません)。ほとんどの場合、会議室のカレンダーは、移行されません。移行元のGoogle Workspaceメールボックスのプライマリカレンダーを移行するには、MigrationWizに入力されたアドレスが、移行元のGoogle Workspaceカレンダーに割り当てられたアドレスと一致している必要があります。

セカンダリカレンダーのカレンダーイベントが、プライマリカレンダーに移行されることがあります。カレンダーイベントを移行する場合、移行先のユーザーは、移行するイベントの主催者である必要があります。主催者でないユーザーにイベントを移行する場合、Googleでは、そのユーザーのメインカレンダーにイベントが作成されます。

技術的な観点から、移行できるカレンダーは、移行されるユーザーが、そのカレンダーに対して次の権限を有する場合に限られます：

• 所有者の権限レベル、または
• ルートの権限レベル、および
  1. 主催者が指定されていない、または
  2. 主催者は移行されるユーザーで、別のユーザーではない。

カレンダー共有権限のテクニカルリファレンスについては、このリンクを参照してください。カレンダーフォルダーを含む特定のフォルダーのフィルター処理については、このリンクを参照してください。

ユーザーのすべてのカレンダーを移行するには、サポートオプションの「MigrateGmailAllCalendar=1」を追加します。デフォルトでは、このオプションは設定されておらず、ユーザーが所有するカレンダーのみが移行されます。

カレンダーのリマインダーと通知

Googleカレンダーのリマインダー：

• リマインダーは、タスクが完了するまでGoogleカレンダーに残ります。
• リマインダーの詳細については、Googleの公式ブログの投稿を参照してください。
• Googleカレンダーのリマインダーは、移行されません。

 Googleカレンダーの通知：

• イベントとその通知は、イベントに参加したかどうかに関係なく、削除されます。
• Googleカレンダーの通知は、移行されます。

リソースカレンダーを移行する

Google WorkspaceからオンプレミスのExchangeまたはMicrosoft 365(Exchange Online)にリソースカレンダーを移行する場合、Google Workspaceのリソースカレンダーのメールアドレスと、Exchangeのリソースメールボックスのメールアドレスとのマッピングが、自動的には行われないため、「詳細オプション(Advanced Options)」を設定する必要があります。Exchangeでは、プログラムによるリソースカレンダーへの自動ログインが許可されていますが、Google Workspaceでは、OAuthを使用する場合でも、許可されていません。

Google WorkspaceからオンプレミスのExchangeまたはExchange Onlineにリソースカレンダーを移行するには、以下の手順に従います。

これらの手順は、リソースカレンダーの移行のみを対象としています。ユーザーメールボックスを移行するための一連の手順については、Google WorkspaceからオンプレミスExchangeへの移行ガイドまたはGoogle WorkspaceからMicrosoft 365への移行ガイドを参照してください。

1. Google Workspaceで、次の手順を実行します：
   • リソースカレンダーのメールアドレスを取得します。Google管理コンソールにサインインし、「アプリ」 > 「Google Workspace」 > 「カレンダー」 > 「リソース」に移動します。リソースを選択し、そのリソースのメールアドレスを表示させます。リソースカレンダーのメールアドレスは、アカウントのドメイン名とGUIDの組み合わせとなっています (例：bitrepro.com_3213265465461321@resource.calendar.google.com)。メールアドレスのリストをファイル(Word、Excelなど)に保存します。このファイルは、後にMigrationWizでメールボックス移行プロジェクトを作成する際に使用します。
   • 新しいユーザーアカウントを作成します。Google管理コンソールにサインインし、「ユーザー」 > 「新しいユーザーの追加」に進みます。作成したユーザーのアカウント情報は、以下の手順6で必要となるため、書き留めておきます。
   • このユーザーアカウントに、リソースカレンダーを追加します。このユーザーアカウントでGoogle Workspaceにサインインし、「カレンダー」に移動します。「他のカレンダー」の右の「+」ボタンをクリックして、「リソースのブラウジング」を選択します。「もっと見る」タブをクリックし、「ドメインのリソース」をクリックします。表示される各リソースカレンダーの横にある「購読」をクリックします。
   • すべてのリソースカレンダーの名前を、ユーザーのカレンダーリストに表示されている通りに、正確に取得します。「他のカレンダー」の右の「3点リーダー」をクリックし、「設定」を選択します。 リソースカレンダー名のリストをファイル(Word、Excelなど)に保存します。このファイルは、後にMigrationWizでメールボックス移行プロジェクトを作成する際に使用します。
2. 移行先のオンプレミスExchangeまたはExchange Online環境のリソースメールボックスの名前とメールアドレスを取得します。メールアドレスのリストをファイル(Word、Excelなど)に保存します。このファイルは、後にMigrationWizでメールボックス移行プロジェクトを作成する際に使用します。
3. MigrationWizで、メールボックス移行プロジェクトを作成します。
4. プロジェクトに、以下に示すサポートオプションを追加します。 
   • MigrateGmailAllCalendar=1
     • このサポートオプションを追加すると、すべてのカレンダーが確実に移行されます。
   • RecipientMapping="リソースカレンダーのメールアドレス->リソースメールボックスのメールアドレス"
     
     例：
     RecipientMapping="com_123456789@resource.calendar.google.com->ConfRoom1@bitrepro.com"
     
     
     • このサポートオプションを追加すると、Google Workspaceのリソースカレンダーのメールアドレスが、オンプレミスExchangeまたはExchange Onlineのリソースメールボックスのメールアドレスにマップされます。
     • 上記の「リソースカレンダーのメールアドレス」の部分には、手順1で取得したGoogle Workspaceのリソースカレンダーのメールアドレスを入力します。
     • 「リソースメールボックスのメールアドレス」の部分には、オンプレミスExchangeまたはExchange Onlineのリソースメールボックスのメールアドレスを入力します。
     • 移行するすべてのリソースカレンダーに対し、このサポートオプションを設定します。サポートオプションのテキストボックスを追加表示するには、各テキストボックスの横にある「+」ボタンをクリックします。
     • 移行元の同じ1つのGoogle Workspaceアカウントに対して、複数のメールボックス移行プロジェクトを作成する場合は、そのすべてのプロジェクトに、リソースカレンダーの受信者アドレスマッピングのサポートオプションを追加する必要があります。

5. 「保存(Save)」をクリックします。
6. メールボックス移行プロジェクトに、リソースカレンダーアイテムを追加します。
   • 移行元として、上記の手順1で作成したGoogle Workspaceユーザーアカウントのメールアドレスを入力します。移行するすべてのリソースカレンダーに、同じ移行元メールアドレスを使用します。
   • 移行先として、移行先のオンプレミスExchangeまたはExchange Online環境のリソースメールボックスのメールアドレスを入力します。
7. 追加した各リソースカレンダーアイテムに対し、右側の鉛筆アイコンをクリックして、以下に示すフォルダーフィルターとサポートオプションを追加します。
   • ^(?!Calendar/リソースカレンダー名)
     
     例：
     
     ^(?!Calendar/会議室1)
     • このフォルダーフィルターを設定すると、指定されたリソースカレンダーのみが移行されます。
     • 「リソースカレンダー名」の部分には、リソースカレンダーの名前を、手順1のユーザーのカレンダーリストに表示されている通りに、正確に入力します。
   • FolderMapping="Calendar/リソースカレンダー名->Calendar"
     
     例：
     
     FolderMapping="Calendar/会議室1->Calendar"
     • このサポートオプションを追加すると、オンプレミスExchangeまたはExchange Onlineのリソースメールボックスのルートカレンダーに、リソースカレンダーが確実に移行されます。
     • 「リソースカレンダー名」の部分には、リソースカレンダーの名前を、手順1のユーザーのカレンダーリストに表示されている通りに、正確に入力します。
     • 移行先のカレンダー名のスペル言語は、移行先リソースメールボックスのシステム言語と同じである必要があります。たとえば、移行先リソースメールボックスの言語が日本語の場合、フォルダーマッピングは、「FolderMapping="Calendar/Conf Room 1->予定表"」とする必要があります。
       
       フォルダーフィルターまたはサポートオプションに、特殊文字を含むリソースカレンダー名を使用する場合は、注意が必要です。特殊文字の前に、「\」を付ける必要があります。たとえば、リソースカレンダーの名前が「Room (1234)」の場合、フォルダーフィルターは「^(?!Calendar/Room \(1234\))」、サポートオプションは「FolderMapping="Calendar/ Room \(1234\)->Calendar"」と入力する必要があります。詳細については、RegExに関するドキュメントの特殊文字セクションを参照してください。カレンダー名に「/」が含まれている場合、フォルダーマッピングで「(」や「)」などの特殊文字に通常付けられる「\」の代わりに、「{%escape%}」を使用する必要があります。これは、フォルダー名のすべての「/」の前に追加する必要があります：
     • 例： 

                   FolderMapping="Calendar/Bob (4) - Tom / Jane (4)->Calendar"

                   の場合

                 FolderMapping="Calendar/Bob \(4\) - Tom {%escape%}/ Jane \(4\)->Calendar"

「アイテムを保存(Save Item)」をクリックします。すべてのユーザーメールボックスアイテムを移行プロジェクトに追加し、シナリオに従ってプロジェクトを構成します。 

重複するカレンダーアイテム

Google Workspaceを移行元とする移行では、移行中にカレンダーアイテムのリソースまたは場所が変更された場合、カレンダーアイテムが重複して作成されることがあります。

これは、Googleでは、イベントの場所が更新されると、別のIDを持つ別のアイテムが作成されるためです。更新されたアイテムには、新しいIDが付与されます。たとえば、元のIDに「_R2014...... 」が付け加えられます。これは、重複として移行されるアイテムです。

カレンダー移行における色の管理

デフォルトでは、カレンダーアイテムは、「完全移行(Full Migration)」サイクルの一部として、Google アプリからMicrosoft 365に移行されます。

移行元のGoogle アプリのカレンダーで使用されている色が、移行先のMicrosoft 365ではサポートされていない場合、それらの色は、Microsoft 365カレンダーのデフォルトの色に変換されます。

 Google アプリのカレンダーで使用されているすべての色を、正しく変換してMicrosoft 365に移行するには、カレンダーを移行する際に、以下の手順を実行してください：

移行先のMicrosoft 365テナント：

• たとえば、次の5つの色を使用しているGoogleカレンダーをMicrosoft 365に移行する場合は、移行を実行する前に、各ユーザーが各自のMicrosoft 365カレンダーで、これらの5つの色にマッチする新しいカテゴリを正確なカテゴリ名で作成しておく必要があります： 
  • 「ターコイズの分類」
  • 「グレーの分類」
  • 「鮮やかな青の分類」
  • 「鮮やかな緑の分類」
  • 「鮮やかな赤の分類」 
• マッチする色を、各カテゴリに手動で割り当てます。

上記の手順を実行しない場合：

• (Googleカレンダーの)予定に特定の色が割り当てられていない場合、その予定は、デフォルトの色(薄い赤)で表示されます。 
• 色の指定がないカレンダーアイテムを移行する場合、MigrationWizでは、移行先(Microsoft 365)で色をマッチさせることができません。
• したがって、予定の色は、Microsoft 365カレンダーの予定のデフォルトの色になります。

Googleリソース

Googleでは、ユーザーがイベントの主催者でない場合、そのイベントは、ユーザーのプライマリカレンダーにのみ作成されます。Googleのリソースカレンダーは、誰のプライマリカレンダーでもないため、MigrationWizでは、他のユーザーのイベントをリソースカレンダーに移行することはできません。

連絡先を移行する

連絡先の移行は、移行元と移行先の環境によって、動作が異なる場合があります。各シナリオの移行ガイドに、より具体的な説明が記載されていますが、一般的なケースをいくつか紹介します。

Contacts APIの廃止とPeople APIの採用

Googleは、2021年6月15日をもってContacts APIを廃止しました。Googleの公式発表については、こちらを参照してください。MigrationWizでは、Googleのガイドラインに従って、People APIへの変更を完了しています。

• 2021年6月3日より、Googleを移行元または移行先とするすべての新規メールボックス移行プロジェクトに、People APIが使用されるようになりました。プロジェクトの設定に必要な詳細情報については、該当する移行ガイドを参照してください。

  • People APIへの変更が行われた6月1日より前に作成された既存のプロジェクトでは、デフォルトでContacts APIが継続使用されます。  既存のプロジェクトは、6月15日までに移行を完了しておくことをお勧めします。既存のプロジェクトを6月15日以降に実行すると、連絡先の移行中にエラーが発生する恐れがあります。

People APIをプロジェクトに設定する方法は、次の通りです：

• • お客様個人のGoogleサービスアカウントを使用する場合は、次の点に注意して設定してください：

    1. お客様のサービスアカウントを使用しているプロジェクトで、People APIを有効にします。

    2. 移行元テナントに、新しいOAuthスコープを追加します：https://www.googleapis.com/auth/contacts.other.readonly

    3. 移行先テナントの既存のスコープの一覧に、新しいOAuthスコープを追加します：
       https://www.googleapis.com/auth/contacts

  • BitTitanサービスアカウントを使用する場合は、次の点に注意して設定してください：

    1. 移行元テナントに、新しいOAuthスコープを追加します：https://www.googleapis.com/auth/contacts.other.readonly

    2. 移行先テナントの既存のスコープの一覧に、新しいOAuthスコープを追加します：
       https://www.googleapis.com/auth/contacts

People API を使用して連絡先を移行する際は、次のような制限や動作に注意してください：

1. 1. 移行先がGoogleの場合、「その他の連絡先」は移行されません。 

      1. 「詳細オプション(Advanced Options)」で、「その他の連絡先」を移行するオプションを追加した場合、移行元の「その他の連絡先」ラベル内の連絡先は、「Suggested contacts」ラベルが付けられて、移行先に移行されます。 

      2. 「その他の連絡先」の連絡先情報のうち、移行先でサポートされているのは、名前、メールアドレス、電話番号のみとなります。その他のフィールドは、サポートされていません。

   2. 移行元のGoogleで非表示にしている連絡先を移行する場合、移行先では、「非表示」プロパティは保持されません。これらの連絡先は、メインの連絡先リスト内と、連絡先に紐づけられたラベル内の両方に表示されます。

その他の連絡先

「その他の連絡先」は、メールを送受信したことのある相手のメールアドレスに基づいて、Gmailが自動的に作成する、連絡先のプレースホルダーです。この機能により、新規メールの作成時に、受信者のオートコンプリートが可能になります。デフォルトでは、「その他の連絡先」は移行されません。ただし、MigrationWizでは、必要に応じて「その他の連絡先」を移行することができます。

「その他の連絡先」を移行するには：

1. MigrationWizアカウントにサインインします。
2. 「プロジェクトの編集」をクリックします。
3. 「詳細オプション(Advanced Options)」をクリックします。
4. 「移行元/移行先(Source/Destination)」をクリックし、「連絡先の処理(Contact Handling)」フィールドで、「連絡先候補を移行する(Migrate Suggested Contacts)」を選択します。
5. 「保存(Save)」をクリックします。

ファイルの場所

Exchangeでは、「その他の連絡先」はシステムフォルダーと見なされず、コンテンツは常に「Suggested Contacts」という名前のルートフォルダーに移行されます。

移行されない連絡先のための「詳細オプション(Advanced Options)」

Googleから別のメールプラットフォームへの移行では、連絡先のフィールド形式が、プラットフォーム間で一部異なります。

ユーザーの連絡先に、デフォルトでは移行先に移行されない連絡先が多く存在する場合、次の「詳細オプション(Advanced Options)」をプロジェクトに追加します。このオプションは、「サポート(Support)」セクションの「サポートオプション(Support Options)」フィールドに追加します。

次の「詳細オプション(Advanced Options)」を追加します： StoreOverflowGooglePropertiesInNotes=1

この「詳細オプション(Advanced Options)」を追加すると、メールボックスの連絡先を移行する時に、(マップされない)連絡先プロパティが、連絡先情報の最後に追加されます。

次のプロパティが追加されます：

• マップされないメールアドレス
• マップされないチャットのアドレス
• マップされない電話番号
• マップされない住所
• マップされないデータベースのイベント(記念日など)
• マップされない関係(兄弟など)

さらに、追加の「詳細オプション(Advanced Options)」を設定すると、これらの追加されたプロパティの上に表示される「ヘッダー」を編集することができます：

次の「詳細オプション(Advanced Options)」を追加します：

StoreOverflowGooglePropertiesInNotesPrefix="---- 次のプロパティはマップされませんでした ---"

すでにユーザーの移行が完了している場合、これらの追加の連絡先プロパティをマップするには、次の手順に従います：

1. 移行先から連絡先を削除します。
2. 統計情報をリセットします。MigrationWizダッシュボードで、「アイテムをリセットする」アイコンをクリックします。選択したすべてのアイテムについて、移行の統計情報(速度、移行されたアイテムの数/サイズなど)と、エラーの詳細(失敗アイテムの数/サイズなど)が、すべて削除されます。「アイテムをリセットする」をクリックします。
3. 次の「詳細オプション(Advanced Options)」を追加します： StoreOverflowGooglePropertiesInNotes=1
4. MigrationWizダッシュボードで、「プロジェクトの編集」をクリックし、「詳細オプション(Advanced Options)」を選択します。
5. 「サポート(Support)」セクションの「サポートオプション(Support Options)」フィールドに、次のオプションを追加します：
   1. StoreOverflowGooglePropertiesInNotes=1
   2. [+] をクリックします。
   3. 「保存(Save)」をクリックします。
   4. 「プロジェクトを保存(Save Project)」をクリックします。
   5. 再移行する1つまたは複数のメールボックスを選択します。
   6. 「移行を開始」をクリックします。
   7. ドロップダウンリストから、「完全移行(Full Migration)」を選択します。
   8. 「連絡先(Contacts)」以外のすべてのアイテムを選択解除します。
   9. 「移行を開始」をクリックします。

Googleの連絡先グループを移行する

「Googleグループ」をクリックすると、同じ連絡先レコードが表示されます。一方のグループの連絡先に変更を加えた場合、もう一方のグループをクリックすると、変更内容が反映されて表示されます。

Exchangeの動作は、これとは異なります。Google Workspaceの連絡先グループは、Exchangeのフォルダーにマップされます。両方のフォルダーに同じ連絡先レコードを配置することはできません。2つのレコードは異なるため、一方のフォルダー内の連絡先に加えた変更は、もう一方のフォルダーには反映されません。

連絡先フィールドのマッピング

連絡先の処理 － デフォルトでは、「その他の連絡先」はスキップされます。

• 「その他の連絡先」を移行するには、「詳細オプション(Advanced Options)」を設定します。
• すべての連絡先が、移行先の連絡先システムフォルダーに移行されます。
• 移行元のフォルダーにマッチするフォルダーが、移行先に作成されます。

次の(Exchangeの制限による)例外を除き、すべてのプロパティが移行されます：

• 最大3つのメールアドレス
• 電話番号カテゴリごとに1つの電話番号
• 住所カテゴリごとに1つの住所
• 1つの記念日
• 1つの誕生日
• 最大3つのチャットカテゴリ。 Exchangeでは、技術的に、カテゴリなしのチャットのアドレスを最大3つ表示できるはずですが、最新のUIには、1つしか表示されません。
• 次のカテゴリごとに1人の人物 ： 配偶者、パートナー、マネージャー、同棲相手、子ども、アシスタント
• 移行元がExchange 2007の場合、写真は添付ファイルのように見えます。この写真は、技術的には添付ファイルですが、移行後は、連絡先の写真として表示されます。
• カスタムフィールドは、移行されません。
• グループは、移行されません。

Googleディレクトリサービスによって入力されたGoogle Workspaceの連絡先フィールドは、移行されません。

転送

Gmailで転送先アドレスを設定する方法については、GoogleのGmailのメールを他のアカウントに自動転送するの記事を参照してください。

トラブルシューティング

本セクションでは、エラー以外の問題について説明します。Google Workspaceの移行エラーの原因と解決策については、弊社の「エラーの参照」を参照してください。

Googleのスロットリング制限 

Googleには、厳しいスロットリング制限があります。制限に達すると、アカウントが24 時間ロックアウトされ、移行計画に悪影響を及ぼす可能性があります。

Google Workspaceから移行する場合は、お客様のシナリオに合った移行ガイドを参照してください。移行ガイドを表示するには、ヘルプセンターのメインページで、「移行の実行(Perform a Migration)」をクリックし、移行元環境を選択します。  次のページで、移行タイプを選択し、該当する移行ガイドを選択します。 各ガイドには、最終サイクルまで「すべてのメール」ラベルを除外して移行を実行する手順が記されています。ガイドの手順に従うと、以下の問題の影響を受けずに移行することができます。

移行元がGoogle Workspaceの場合に注意すべき主な制限は、メールボックス内のラベルに、過剰な量のアイテムが含まれている場合の制限です。

• 10万個を超えるアイテムを含むラベルを移行すると、問題が発生することがあります。「すべてのメール」ラベルは、このサイズに達する可能性があります。
• 「すべてのメール」ラベルを一度のサイクルで移行しようとすると、Googleのスロットリング制限に達する可能性があります。この問題を回避する最善の方法は、移行ガイドの指示に従って、段階的に移行することです。

Google Workspaceでは、データの取得とプッシュの両方の処理で、スロットリングが行われます。データの取得とプッシュでは、スロットリングの制限値が異なります。

Googleでは、一定時間内にサーバーから過剰な量のデータを取得したと判断されたアカウントを、24時間ロックすることがあります。

この場合、移行を一時中断し、(24時間後に)ロックが解除されてから、再開することをお勧めします。

さらに、移行先がGoogle Workspaceの場合、1秒あたり1アイテムという厳しいデータ制限が課せられます。MigrationWizでは、移行スループットの調整が適宜行われますが、これらの制限は、常に適用されます。

IMAP

本セクションの説明は、IMAPアクセスとその設定方法に関するものであり、Google Workspace移行のIMAPエンドポイントを説明するものではありません。 

デスクトップクライアントのIMAPアクセス

以下の簡単な手順で、ユーザーのPOPとIMAPを有効または無効にすることができます。POPアクセスは、自動でユーザーに適用されます。この設定は、ドメイン内のすべてのユーザーに適用されますので、注意が必要です。IMAPを無効にすると、ユーザーは、GmailインターフェースのPOP/IMAP設定にアクセスできなくなります。また、以前にIMAPを有効にしていた場合でも、自分のメールにPOP/IMAP経由(Googleデスクトップなど)でアクセスすることはできなくなります。

1. Google管理コンソールにサインインします。
2. ダッシュボードから、「アプリ」 > 「Google Workspace」 > 「Gmail」 > 「詳細設定」に移動します。
3. 「組織」セクションで、設定を構成する組織部門を選択します。
4. 「POPとIMAPアクセス」で、「ドメインのすべてのユーザーのPOPとIMAPアクセスを無効にする」のチェックボックスをオンまたはオフにします。

IMAPとPOPの設定変更が反映されるまでに、15～30分かかる場合があります。チェックボックスがオフになっている限り、ユーザーは、さまざまなクライアントに対して、POPとIMAPアクセスを設定することができます。

IMAPフォルダーのサイズ制限の削除

Google Workspaceには、IMAPフォルダー内のメッセージ数を制限できる機能があります。この機能が設定されている場合、MigrationWizが各フォルダーから取得できるメッセージ数が制限され、指定された上限数のメッセージしか移行されません。

この機能がユーザーによって設定されているかどうかを確認し、その制限を削除するには、次の手順に従います：

1. アカウントにログインします。
2. ウィンドウの右上にある歯車アイコンをクリックして、「設定」画面を開きます。
3. 「メール転送とPOP/IMAP」タブをクリックします。
4. 「IMAPアクセス」の見出しの下にある「フォルダーサイズの制限」を特定します。
5. 「IMAPフォルダーのメールの数を制限しない(デフォルト)」が選択されていることを確認します。

この設定についての補足説明：制限が設定されている場合(たとえば、デフォルトの1000に)、フォルダーに格納されるアイテムは1000に限られ、1000を超えるアイテムは切り捨てられます。つまり、MigrationWizが各フォルダーから移行できるメール数は、1000のみになります。