2024年4月3日 / 最終更新日時 : 2024年11月8日 officeの杜 Google

Google Workspaceを新規に導入する時に押さえたいポイント

組織で初めてGoogle Workspaceを導入しようとなると何から始めたらよいのか？何をしなければならないのか？といったことで迷う点がたくさんあります。さらにMicrosoft365から移行するとなると新規導入よりも考慮しなければならないポイントが増えることになります。

今回は新規にGoogle Workspaceを導入する場合に押さえておきたいポイントをまとめてみました。Microsoft365からの移行についてはまた改めてまとめのページを作成したいと思います。とりわけ、今回の事例ではドメインをホストしてるケースがさくらインターネットの場合を想定しています（既に企業として独自ドメインを取得してることが前提です）。

目次

利用するサービスやツール

今回のエントリーはデータ類の移行と言うよりは、Google Workspaceの導入に伴う情シス側で要求される設定周りや社内メンバーに対する対応策などが中心です。大きく仕事のスタイルや使うツールが変更になるのでここをガッチリ組んでおかないと社内で大きな障害につながり、情シスに対する負荷が急上昇することにもなります。

Google WorkspaceとMicrosoft365の比較については以下のエントリーにまとめてあります。

新規導入時のGoogleアカウントに関するまとめはこちらに目を通しておくと良いでしょう。

Google WorkspaceとMicrosoft365の機能比較

注意点

考慮しなければならない既存システム

はじめてGoogle Workspaceを導入するといっても、これまでの業務やシステムが存在しており、それらを停止して作業するというわけにはいきません。必ず並行稼働期間というものを設けて、尚且つエンドユーザに周知・トレーニングといった十分な時間を用意しなければ混乱をもたらし、場合によっては情報漏洩といったようなトラブルが生じるかもしれません。

主に配慮しなければならないシステムは以下の通りです。利用頻度の高い順に列挙してみました。

  • メールサーバ（個々のメールボックスや転送設定）
  • ファイルサーバ（ローカルに置いてあるNASなど）
  • グループアドレスやカレンダーデータ
  • VBAなどを使ったMicrosoft Officeファイルの有無
  • 組織の共有連絡先データ
  • 社内掲示板などのポータルサイト

とりわけ、メールとファイルサーバが大きな仕事になる点で、混乱が生じる可能性が高い要素になります。実際のメールデータ、NASのファイル、カレンダー等の移管作業については計画的に実施しましょう。

他のグループウェアからの引っ越し

今回のエントリーはあくまでも、Microsoft365やサイボウズなどを利用していないで、旧来のメールサーバやローカルのNASを利用してるところから、新規導入でGoogle Workspaceを利用する場合の内容になっています。

そのため、Microsoft365などからの「お引越し」となると、今回の作業の他にGWMMEやGoogle Workspace Migrateといった移行用ツールを使っての大規模な作業が必要になります（コストもかなり掛かるので要注意）。

一方で、Lotus Notesなどからのお引越しとなるとかなり大変な作業です。Googleのドキュメントにも一応HCL Notesからの移行とツール（GWMHN）に関する記載はありますが、2024年11月20日をもってコレも終了が明記されています。自分個人では過去にOutlookなどへの移行用として以下のようなツールを作ってきましたが、いい加減にNotesに関してはもう移行を済ませておかないと、時間が経過する毎に大変になっていくものと思われるので検討しましょう。

VBAでLotus NotesのDB内ビュー全データを引き抜く

Lotus NotesのメールをOutlookに変換して移行する

試用期間中の制限

Google Workspaceを新規導入後におかしな制限に遭遇するという報告があり調べてみると、導入後14日間部分は試用期間に該当し実際にこの期間中は色々と制限が掛かるようです。その制限内容は

  • 追加できるユーザは最大10名までとなっている
  • ストレージについてもBusiness Standardならば200GB/1ユーザの制限がついている（Enterprise Standardだと500GBまで）
  • Youtubeについても制限があり利用そのものが出来ません。導入後30日経過か？早期払い30ドル支払いで解除されます。（現時点ではこのアカウントでは YouTube を利用できませんとメッセージが出ます）。ただし、EducationとNonprofitは対象外のようです。
  • この制限は2024年3月28日以降に新規に契約したテナントから発生している（Googleのサポートも知らなかったらしい）
  • 制限解除するには試用期間中に、管理コンソール上から早期払いを行い、30ドル以上の支払い実績を出す必要がある
  • 1日あたりのメール送信数が100通に制限され、こちらは100ドル以上の支払い実績を出す必要がある（GASでMailApp.getRemainingDailyQuota()で現在の残りの送信可能Quotaを調べることが出来ます）

この早期払いの手順は公式にもありますが以下の手順で行う。尚この件に関しての明確なリリース情報はアップデートブログ等にも出ていない。

  1. 管理コンソールにログインする
  2. 左サイドバーからお支払い→お支払いアカウントを開く
  3. 表示されてるアカウントIDをクリックする
  4. 下の方に「早期払い」というのが表示されてるので、クリックする
  5. カード払いで30ドル以上の金額（1ドル160円換算ならば、5000円以上）を入力してお支払いをクリック
  6. これで残高が変更されて、制限も解除されるようだ。ただし制限解除には48時間〜72時間掛かる。

これで制限が解除されて、ユーザの追加やストレージをフルで利用できるようになるとのこと。早期払いせずに1人で使ってると、30ドル到達まで3ヶ月も掛かってしまうので、早期払いで解除しておくと良いでしょう。この解除に関するドキュメントの項目はこちらの「Google Workspace の保存容量とアップロードの上限はどのようになっていますか？」がそれに該当する

ネットワーク帯域

Google WorkspaceはWebブラウザを介して利用するウェブアプリケーションであるため、それまでローカルで動かしていたMicrosoft Officeとは異なり、ネットワーク上の問題が導入の大きな障害になる可能性があります。

主に考えられるネットワーク上の問題点は以下の通り。

  • 社内プロキシーを介して外の世界に通じてる場合、プロキシーサーバの負荷が耐えられない可能性。
  • 多数のタブを表示してGoogle Workspaceの各アプリを表示することになるので、セッション数が増加することになる。
  • セッション数増加に伴うネットワーク機器の負荷上昇（セッションテーブルの枯渇など）
  • VPN越しにGoogle Workspaceを使わせることの結果として、VPN回線がパンク（コロナ禍に実際にあったことです）
  • 各所のWiFiの帯域不足でそもそも通信速度が激遅（学校などでの導入で事実発生しています）

それまでは問題にもならなかったネットワーク絡みでインフラを強化していない状態で導入すると、まともに使えないであったり予期せぬ障害が発生したりする可能性があります。

導入に当たっては社内ネットワーク・インフラに関しても増強を要することがあるため、イニシャルコストの算定に加えておくべき要素となります。

※ローカルのNASからの移行やOutlookのPSTの移行などをユーザが一斉に行ってしまい、帯域パンクの可能性もあるため、計画的な移行が必要な場合があります。

※セッション数についてはMicrosoft365だと主にOutlookと言われてますが、1ユーザ30セッション以上消費する可能性がある。ただ、Google Workspaceについてはそこまでの消費とはならないと言われています。故に、M365が入っていて稼働できていた実績のあるネットワークであればGoogle Workspace導入で問題になることは無いと思います。

Google Workspace契約時

ドメインについて

プライマリドメイン

スタートアップや初期導入時にはあまり考えずに決めてるであろう「プライマリドメイン」。会社で1個しかドメインないし、そのまま契約すればいいやというのはその通りなのですが、これが追々苦しめるケースがあります。会社が成長してホールディングス化したので、新たにドメインを取り、ホールディングスドメインをプライマリにして、これまでのドメインをセカンダリにしたいといったケース。

これめちゃくちゃ大変です。特にSAML認証やら色々と連携してる場合は、それらを全て洗い出してゼロからやり直しと検証が必要です。また、既存のプライマリでアカウントを作ってるので、これを異動するということは共有ドライブのグループアドレス付け替えや個々人のメールボックス、そもそものグループアドレスの作り直しなどなど。

殆どテナント間異動と変わらない大プロジェクトになるため、手軽にプライマリドメインを変更出来るとは思ってはいけません。

※また以前は申込時にGoogle Domainsにてドメインの手配も同時に出来ましたが、現在は終了してしまい「Squarespace」から別途契約をどうぞ状態なので、お名前.comやレンタルサーバのドメインなどを利用することになります。

複数テナント

実際に運用してたことがありますが、検証用として別のドメインで別のテナントとして運用をするケースがあります。例えばメインのテナントは300名超えでEnterprise Standardを利用しており、検証用はBusiness Starterを利用していたケース。なぜそんなことをするかといったら、一番の理由はコスト。また同一テナント内でプランを同居できないのも理由の１つ。

また、社員にはEnterprise Standardを使わせて、業務委託の人はBusiness Starterで区別し、ホワイトリストを用いて共有ドライブにアクセスさせるといった運用もあるでしょう。

きちんと理解して割り切ってこの手法を取ってる場合には合理的と言えます。特に病院のような施設ではない場合、Frontlineプランは利用出来ませんので、フル機能のEnterprise Standardはコスト的にも機能的にもオーバースペックです。

問題は、あとあとこのテナントを統合したいとなった場合、前述のプライマリドメイン統合と同じくらい大変な作業になります。故にあとからフラフラと「実は統合したい」なんて考えを実行すればいいやという考えはかなり甘い考えなので、導入前からよくよく考えて実行したほうが良いです。情シスリソースが無い組織なのに、手軽に移動できると考えてはいけません。

申し込みについて

契約先を選ぶ

個人事業主や数名程度の組織であるならば、Googleのサイト上から直接契約でも良いでしょう。しかしパートナー企業経由で導入するという手段もあります。パートナー企業経由で導入するメリットとしては

  • クレジットカード払いだけじゃなく請求書払いを選択することが可能（口座振込や引き落としで処理が出来る）。但し1年単位の支払いになります。
  • 有償で導入の手助けをしてくれる
  • 様々な導入後のサポートや情報を受けることが可能になる
  • パートナー契約ではディスカウントを受けられる可能性がある
  • パートナーコンソールからテナントに入ってもらって管理コンソールの設定を行ってもらうことが可能です。

もちろんGoogle直契約でも領収書はインボイス対応しているのでバッチリです。10名以上の利用が予定されてる企業ならば断然パートナー企業経由で導入したほうが先々を考えればお得です。

国内の有名どころのGoogle Workspaceパートナー企業としては、電算システム・吉積情報・サテライトオフィスなどの会社があります。

契約プランを決める

ここが悩みどころの１つです。Google WorkspaceやMicrosoft365はプランによって利用できるユーザに上限が設けられています。その閾値が300名。また、利用するサービス内容によってもプランが枝分かれしてくことになります。ポピュラーなプラン選択ですと以下のようになります。本エントリーはこのポピュラーなプランの導入を前提に話を進めます。

  • 300名以下ならばBusiness Starter、Business Standard、Business Standard Plusが選択可能
  • 300名以上の場合は、Enterprise Standard、Enterprise Plusを選択することになる

直接契約の場合は、Business StarterとBusiness Standardについてはプロモコード(初年度10%割引)がありますので、こちらのフォームから送っていただければ発行することが可能です。支払時に適用することで割引となります。

また、特定のサービスを利用しないという形で使えるものとしてEssentialというプランがあります。但しこちらは、初めて導入する時にだけ選択可能で、跡から他のプランから変更は出来ません。またGmailの機能がありません。プラン比較や契約する上での制約・比較はこちらのページ。

さらに、デスクワークではないユーザ向けという特殊なプランがあり、それがFrontlineプラン。Google Workspaceは1つのテナント内で複数のプランを混在させることは出来ません。が、このFrontlineは別として混在が可能のようです。例えば病院のような組織で医療事務やバックオフィスについては通常のプランを選択し、現場の看護師さんや介護士さんなどの方々はFrontlineを適用することで、コストを大幅に低減させることが可能な上、Frontlineは人数制限がありません。

その分1ユーザ辺りのディスク容量が5GB程度と低く、またデスクワークユーザに適用できず、契約はパートナー企業経由のみとなっています。

※さらにGmailとChat無し、カレンダー無し、共有ドライブ制約有り、無償版と有償版の2つがあるCloud Identityという特殊なものもあります。

Google Workspace用プロモコード

直接契約で申し込む場合

ドメインの所有権の証明

パートナー経由の場合には、パートナーの手助けを得ながら進めることが出来ますが、Google直接契約の場合は担当者が色々と整備を進めていかなければなりません。その最初の一歩が直接契約で申し込む手順です。並行稼働が必須要件であるため、ここでは注意点があります。

  1. こちらのページからまずはプランを選択し、今すぐはじめるをクリックする（この段階では14日間の体験版）
  2. 会社名や人数、担当者の名前とメアド、そして、会社所有のドメインで利用するよう進める
  3. ドメイン名入力画面では実際にGoogle Workspaceで利用するドメインを入力する
  4. 無事に完了し、管理コンソールへログインする
  5. 初回ログイン時のみ「Gmailを有効化」といったような画面が出ますがスルーします。メールはまだ移行しない為です。
  6. 左上のサイドバーのメニューからアカウント⇒ドメイン⇒ドメインの管理を開く
  7. 登録した企業ドメイン横の「ドメインの所有権を証明」をクリックする
  8. 確認レコードを追加という画面が出るので、出てきた文字列をコピーします。
  9. さくらのドメイン管理から対象ドメインのゾーン編集画面に入る
  10. 編集をクリックする
  11. 以下の設定でレコードを追加する

    コピーした値は、"google-site-verification=xxxxxx"といった値で入力することになります。
  12. 再度、6.の画面に戻ります。
  13. ドメイン所有権証明が完了していれば、続いて「Gmailを有効にする」をここでクリックします。ただし、「MX レコードの設定をスキップ」をクリックして進める必要があります。

このドメインの所有権の証明はセカンダリドメイン追加などでも同様に行う作業なので、複数ドメインを使い分ける場合には同じ作業が必要です。

図：ドメイン所有権はDNSで行う

Google Workspaceにセカンダリドメインを追加する

支払い方法をセットする

体験版のままでは14日後に利用不可能になってしまいます。そこで、以下の手順で支払い手段を登録しておきましょう。

  1. 管理コンソールの左サイドバーから、お支払い⇒お支払いアカウントを表示する
  2. 目的のプランの横にあるお支払い方法を表示をクリック
  3. お支払い方法を追加をクリックする
  4. クレジットカード番号を登録して保存する

カード払いではなく請求書払いや銀行振込等にしたい場合は、パートナー経由で契約する必要があります。移行様々なサブスクの追加後の支払いはこのカードから支払いが行われます。

図：支払い方法はカードのみ

組織部門の作成

Google Workspaceの各種設定は１本ではなく、作成しておいた組織部門ごとに区別してオンオフが可能になっています。しかし、組織の人数が少ない場合は組織部門を作成せずに、ルートの組織（ドメイン直下）にすべてのメンバーを所属させてしまっても良いでしょう。

しかし、主に以下のような理由により組織部門はいずれ必要になってきます。人数が増える可能性や特定の利用目的が生まれるであろう場合には、予め作成しておいて、各組織部門にユーザを所属させるようにしましょう（ユーザは１つの組織部門にしか所属出来ません）。

  • 部やチームごとにドライブの外部共有のオンオフを制御したい
  • 特定組織部門にだけ特定のアプリの使用を許可したい
  • 他の組織部門メンバーを連絡先一覧に表示・非表示をコントロールしたい

また、組織部門単位ではなくグループアドレス単位で、上記のオンオフも設定することが可能です。組織全体ではオフでも特定のグループアドレスメンバーにだけ許可をしたい場合には、設定グループを用意してコントロールも良いでしょう（設定グループのほうが組織部門設定よりも優先されます）

図：色々テストするために自分は分けてます

ユーザアカウントの作成

ライセンス枠の確保

パートナー経由の場合にはこの段階ですでに必要人数分のライセンス契約が終わっていると思いますが、直接契約の場合１名分（管理者のみ）の状態だと思います。その場合は、サブスクリプションのページから必要分を事前に購入しておく必要があります。でなければ、Cloud Identity Freeでしかユーザにライセンス割り当てが出来ません。

  1. 左サイドバーからお支払い⇒サブスクリプションを開く
  2. 対象のGoogle Workspaceプランをクリックする
  3. プランの詳細にある「さらに購入」をクリックして必要な分だけライセンス枠を購入しておく
  4. プランのアップグレードもここから行えます。

ライセンスはユーザ作成時にデフォルトでは自動割り当てされます。また、ユーザを削除するとその分だけライセンス枠が余るので別のユーザを作成してすぐに割り当てが可能です。

図：枠がないとアカウントを作れない

メールアドレス命名規則

これも新規導入時よりも追々問題になる課題です。これまでのメールボックスを移行するにせよ新しく設定して配布するにせよ、メールアドレス命名規則はよく考えて設定しなければなりません。理由は

  • 同姓同名や同じ読み方をする人の存在
  • ビジネスネームの存在（結婚してるけれど氏名は旧姓にしたいなど）
  • グループアドレスでも同様のことが起きる

例えば、yamada.taro@hogehoge.comというのはよくあるケース。でも同じ山田太郎さんが入ってきたらどうすんの？であったり、ｔt_yamada@hogehoge.comでは全く解決にもなっていない。かといって、yamada.taro.01@hogehoge.comではなんだか間違えやすそうだ・・・といった具合にあとあと苦しむケースがあります。

この問題に答えは無いのですが、一番悪いのはあとあとこの問題が発生したからといってt_yamadaとyamada.taroと２つの命名規則に基づくアカウントが混在するケース。これは収集がつかなくなります。修正も大変です。これだけは辞めましょう。

ユーザの作成

ディレクトリのユーザから１人ずつ作成することが可能です。但しこの時点では、MXレコードを設定していないのでGmailでメールの送受信は出来ません。

手動で作成する手順は以下のとおりです。

  1. ユーザの画面の上にある新しいユーザの追加をクリックする
  2. 姓、名、メアドを取り敢えず入力する
  3. 下の「ユーザのパスワード...」という部分をクリックする
  4. 組織部門を用意してる場合は組織部門を指定する
  5. Passwordにて、自動でランダムパスワードを生成するか？指定のパスワードを入力する
  6. 新しいユーザの追加をクリックする
  7. 作成完了画面から印刷や、プレビューして送信から対象者のメアド宛にログイン手順やパスワードを通知することが可能です。
  8. 完了をクリックして閉じる

CSVで作成でも良いのですが、スクリプトで一括でスプシ上から作成することも可能です。以下のスクリプトはそのサンプルです。

Google Apps Scriptでユーザの一括作成・削除をする【GAS】

図：ユーザの新規作成画面

※以下のエントリーにあるようなGoogle Apps Script + Admin SDKでユーザ一括作成のスクリプトを作成したり、サテライトオフィスのシングルサインオン for Google Workspaceなどを導入すると一括作成などが出来るようになります。今後のことも考えて用意しておくと作成作業を大幅に軽量化することが可能です。

※ユーザの細かなプロフィールもガッツリGoogle Apps Scriptから送り込むことが可能です。

Google Apps ScriptのAdmin SDKでユーザ作成フォームを作る【GAS】

情シス宛申請フォーム

リリース前にメールの転送

他の環境から移行する場合、既存のメールボックスが存在しつつ、Google Workspaceの導入準備をする事になります。実際にGoogle Workspaceを社内展開するまでの間、既存のメールボックスに届くメールを展開前にGmail側に転送することが可能です。

リリース前にGmail側にも同じメールを転送したい場合には、

  • 各ユーザに対して「user01@hogehoge.com.test-google-a.com」がデフォルトでセットされています。。転送受付用の特殊なドメインです。
  • 既存のメールサーバに対して、各ユーザのメールを自動転送する設定を行い、アドレスは上記のアドレスを指定します。
  • 実際にリリース日になりましたら、MXレコードを変更しGoogle側に振り向けて、既存のメールサーバの停止のフェーズに入りましょう。

運用開始までの並行期間を設けずゼロから始める場合はこの作業は行う必要はありません。移行が完了したら、.test-google-a.comについてはドメイン管理上で「無効」とすれば良いでしょう。

図：テストドメインエイリアスがセットされてる

グループの作成

グループの概要

メールのメーリングリストだけでなく、Google Workspaceではグループを様々なシーンで利用します。

  • ドライブのアクセス権限一括付与
  • 組織部門で特定ユーザにだけまとめて機能のオンオフ
  • Google Chatのスペースにまとめて招待
  • Google Sitesへのアクセスや編集権限をまとめて管理

などなど。グループを作成しておけばいちいち個別のメンバー単位で管理する必要がなくなり、Googleグループのメンバーの追加と削除でごっそり入れ替えが可能になります。可能な限り個別ユーザで権限付与などをせず、グループ単位で管理することが定石です（他部署に異動したのに権限外し忘れてセンシティブな情報が見られる状態のままになったりする為）。

ドライブで使う場合の注意点

Googleドライブのマイドライブや共有ドライブに於いて、権限設定でユーザではなくグループアドレスを使っている場合、グループアドレスに後からメンバーを追加した場合には、本人に通知が飛ぶことはありません。ただ、本人は対象のドライブに即時にアクセスは可能です。

また、マイドライブなどで違う人のディレクトリに同様の設定がなされている場合アクセスは可能なのですが、 [共有アイテム] には自動的に表示されません。

あらためて、グループでの権限を外して再度追加するか？対象者だけ個別にフォルダに設定するなどしないと出てこない仕様になっています。よって、ファイルやフォルダを見失う可能性があります。

グループのパターン

当初は既存のメールサーバ等にあるMLと同じものを、Google Workspaceでも作成しメンバーを所属させると良いでしょう。主に作成するであろうグループのパターンは以下のとおりです。

  • 現在の企業の部署に基づく所属メンバーのグループ
  • 全社員所属のグループ
  • 正社員のみ、派遣・業務請負のメンバーのみのグループ
  • 特定のプロジェクト用のグループ
  • 役職者専用のグループ
  • 組織部門用の設定グループ

グループアドレスの中にグループアドレスを入れることも可能なので便利ではあるのですが、組織改変があった場合に修正するのがとても大変で細かく作りすぎて入れ子にしすぎると、後で修正が大変になります。可能な限りシンプルなグループ作成が必要です。

※またプロジェクト単位でグループを作り続けると、全く使われてないグループなどが大量に残り、後で棚卸しをして削除する時に悲惨なことになるので、プロジェクトが完了したら随時停止するなり削除するなりしましょう。

グループの命名規則と表示規制

Google Workspaceではグループといっても、単なるメーリングリストで使うだけのものではありません。冒頭のグループの概要にもある通りです。また、メーリングリストとしても前述のグループのパターンがあったりします。その為、内部用メーリングリストだと思ったら、外部のメンバーが含まれていたであったり、役職員向けだと思ったら一般社員も含まれいて、センシティブな情報がダダ漏れしていました・・・・なんてことが頻繁にあります。

またユーザと違ってグループアドレスをメール作成時のリストに特定アドレスだけ表示しないといったことは出来ないので、以下のような命名規則を設けて制御すると良いでしょう。以下の文字をグループアドレス冒頭につけてメアドで判定するといった方法です。

  • prj_ : 内部プロジェクト用のグループアドレス。外部メンバーは含まれない。
  • share_ : プロジェクト用のグループアドレス。外部メンバーも含まれる。
  • team_ : 部門専用のグループアドレス。基本その部門のメンバーのみ所属とする。
  • manage_ : 管理職専用のグループアドレス。上長や部長等の管理職のみで構成する。
  • notif_ : 通知専用のグループアドレス。基本返信はできないようにセッティングする必要あり。
  • security_ : 設定グループや特定ドライブ等に於ける権限管理の目的のみで利用するセキュリティグループ。メール送信はできないようにセッティングする。
  • inhouse_ : 社内の横断プロジェクトなどで利用するグループアドレス。
  • info_ : 主に外部からの窓口専用の受け取り用グループアドレス。

このグループアドレス分類を共有ドライブのメンバー設定でも共用することで、ルールを統一することが可能です（外部共有可のドライブならば、share_を利用するといった具合）。ドライブのメンバーグループやドライブ名でもこの文字列付与を活用するとベストです。

図：投稿はさせない設定にする場合

図：セキュリティグループとする場合

グループを作成する

グループもユーザ同様、管理コンソールから１つずつ作成する必要があります。標準ではユーザの一括作成の機能は用意されていません。

  1. 管理コンソール右サイドバーから、ディレクトリ⇒グループを開く
  2. 上部にある「グループを作成」をクリックする
  3. グループ名称、アドレスを入力する。オーナー設定をする場合はオーナーを入れますが、通常はオーナー無しで特権管理者のみがメンバー入れ替え等できるようにするのが定石です。
  4. セキュリティは通常はチェックは入れません。アクセス制御などを目的とした場合にはチェックを入れます。
  5. 次へをクリック
  6. アクセスタイプは通常は「公開」でオッケーです。選んだ項目によって下のアクセス設定が変わります。
  7. ただし、グループに外部メンバーがいる場合は、これに加えて「投稿できるユーザ」については「外部」にチェックを入れると良いです。
  8. くれぐれも会話を閲覧できるユーザを外部にしないこと。情報漏洩に繋がります。
  9. 組織外のメンバーの許可は特権管理者が管理コンソールから加える場合は適用されないので、ここはオフでオッケー
  10. グループを作成をクリック

グループメンバーの個別の権限などは、作成したグループをクリック⇒設定に入り、一番下の管理設定と詳細設定からGoogle Group上で個別で行います。共同トレイ機能の有効化などはそちらで行うことになるので、注意が必要です。

図：グループの作成画面

図：アクセス権限制御

※以下のエントリーにあるようなGoogle Apps Script + Admin SDKでグループ一括作成のスクリプトを作成したり、サテライトオフィスのシングルサインオン for Google Workspaceなどを導入すると一括作成などが出来るようになります。今後のことも考えて用意しておくと作成作業を大幅に軽量化することが可能です。

※また、Enterprise Standard以上ですと動的グループというものが作れるので、ユーザの属性情報を元に自動でグループを構成し、組織改変があってもユーザ情報の一部を一括で書き換えるだけでグループ自体をメンテナンスフリーにすることが可能です。

Google Apps Scriptでグループアドレスの作成・削除を行う【GAS】

Google Workspaceの動的グループで楽をしよう【GAS】

グループのロール

前述の作成時にもありましたが、グループには参加者にそれぞれロールが付与されます。しかし、通常一般企業ではグループの管理をユーザに任せるのは色々とマズイ為、権限自体付与しないで運用するのが望ましいです。それでも付与したいという場合、各権限で一体何ができるのか？というと

  • メンバー：通常のグループ参加者。特に何も権限を持ち合わせていない。
  • マネージャー：グループ設定変更、データエクスポートでグループデータを出力、メンバーの追加と削除
  • オーナー：グループ設定変更、グループ削除、オーナー指名、データエクスポートでグループデータを出力、メンバーの追加と削除、メールアドレス変更

他、マネージャやオーナーはスパムメールの承認・削除なども可能になっています。自分が過去に運用していた運用は以下の通り。

  • 外部メンバー追加可能なアドレスは極めて限定して作成する
  • ユーザにマネージャもオーナーも設定しない。メンバーのみ。
  • ユーザの管理はGoogle Workspaceの特権管理者のみに限定し、申請ベースとする

なぜこのような運用をするか？といったら、現場の人間に管理を任せると、統制が取れなくなるだけじゃなく情報漏洩する可能性が発生する為。よって一切現場に管理する権限は渡さないのが定石です。

共有ドライブの作成

ドライブの移行に関する概要

新規で移行する組織の場合、日常で使ってるファイルに関しては、ファイルサーバ（NAS）に格納されてるケースが殆どではないかと思います。中には個別でDropboxやBoxなどを使ってるケースもあるかもしれませんが、これらをGoogle Driveに統合することでGoogle Workspaceのライセンスの範囲内でコストを収めることが可能です。

現在はドライブの容量はユーザ数 x プランの1人当たりの容量を全員でシェアするストレージプールの方式なので、全容量とNASの全ファイル容量に於いて、Google Drive側の容量が足らないということがなければ移行が可能です（Enterpriseプランの場合、申請で増量することが出来ます）。Businessプランの場合は、Enterpriseにアップグレードを検討することで大幅にドライブ容量を増やすことが可能です。

また、NASからの移行の場合個人アカウントのマイドライブではなく、共有ドライブに保存することで、担当者が退職してもファイルのオーナー権は組織にあるので消えたりもしません。

※また、Google Workspaceアドオンとして、ストレージプールの容量を10TB増やすパックがサブスクで用意されています。ただ、33,750円/月で10TBという容量なのですが、Enterprise Standardの2ユーザライセンス分の金額ですが、こちらは2600円/月なのでBusiness Standard以下でこのパックがお得か？といったら疑問。

図：10TB増量パックが用意されてる

共有ドライブの作成

通常組織で共有ドライブを作成する場合は、特権管理者のみ許可とし、ユーザ権限の割り当ても特権管理者のみ、ユーザに割り当てる権限もコンテンツ管理者までとするのが定石です。でなければ、好き放題に作成されてコントロールができなくなります。

主に用意する共有ドライブは以下の通りです。

  • 部署専用の共有ドライブ
  • 部門間で受け渡しするための共有ドライブ
  • 外部共有用の共有ドライブ
  • 顧客別・プロジェクト別の共有ドライブ
  • 特定用途用に制限された共有ドライブ

ここで課題になるのが、顧客別・プロジェクト別のドライブ。あいうえお順でドライブを作成したり、1プロジェクト1ドライブにした場合、当初はそれでも良いのですが、時間経過とともにファイルがドライブの容量に収まらなくなったり、終了済みプロジェクトのドライブがたくさん表示されたままで日々のファイル操作の障害になったり、問題が出始めます。当初から運用ルールをしっかり用意して管理することが肝要です。

※また、共有ドライブの作成やコントロール、ユーザ割り当て等もGoogle Apps Scriptで制御が可能です。以下のエントリーを参考に実装してみてください。組織改編や異動、日々のドライブの作成などの業務が非常に軽量化する事が可能です。

Google Apps Scriptで共有ドライブをコントロールする【GAS】

外部共有について

Google Workspace導入前の組織の場合、外部の人とのファイルのやり取りはメールが中心であったと思います。しかしメールは添付出来るファイルが25MBまでと制限がある上に、昨今のPPAP問題であったり、誤送信の問題があったり、果にはシャドーITによる組織外サービスを使った受け渡し（例：ギガファイル便など）があります。

結果として情報漏洩などに繋がったケースも多数あり、企業としては頭を悩ます問題が非常に多いです。かといって、Google Driveで外部共有を完全に禁止となると、それが原因でシャドーITが広がるわけなので、外部共有手段として共有ドライブやビジター共有機能を適切に整備して、一定の要件の元に許可をすると良いでしょう。

但し、外部共有は期限を設けるとともに、一定期間が経過したら削除するなどの対策は別途必要です。いつまでも共有しておくと外部のメンバーが異動や退職で異動になっても、アクセス出来てる状況は避けなければなりません。以下のエントリーを参考に対策を講じましょう。

Google Workspaceで安全に外部とファイルを共有する方法

注意点

Google Driveの容量はメールボックスも併用しています。よって社内でやり取りをする場合は、添付ファイルにするのではなく、ドライブにあるファイルを指定するようにするべきです（でなければドライブの容量をその分だけ重複して消費することになる）。加えて、ドライブ容量が不足する原因となる「仮想環境の巨大なファイル」などは、Google Driveで管理するのではなく、それだけはローカルのNASで管理するなど併用も重要になります（アップもダウンロードも時間掛かりますし）。

また、共有ドライブは1つのドライブに最大50万ファイルまでという制限がついています。ファイルサイズではなく個数というのがポイントで、組織が大きくなるとリミットに達してしまう恐れがあります。ログ・ファイルや既に完了したプロジェクトなどの場合にはZIPで固めて保存しておくことで、容量制限に引っかかりにくくなります。

さらに、Google Driveには1アカウントが1日にアップロードできる容量は750GBまでの制限があります。

また、共有ドライブは導入初期より導入後しばらく経ってから色々と問題が出現するものの１つであったりします。初期のうちにしっかりと設計をして運用ルールを策定するのが吉です。それらをまとめたエントリーが以下のものになるのでご一読していただければと思います。

Google Workspaceの共有ドライブ管理を極める

その他のテナント設定

以下の作業は代表的なものになりますが、テナントに設定する各種の制限事項を設けるオプション項目になります。必ずしも行う必要性は無いものもありますが、設定しておくと良い項目になります（利用してるライセンスのエディションによっては出来ない項目もあります）。

二段階認証

2023年時点ですでにEnterprise Standard以上から先行して「Google Workspaceの特権管理者について二段階認証の強制化」が始まっています。今後全てのテナントに対して、2024年中には特権管理者に対しての強制化は完了するとのことなので、導入時からこの設定については意識しておく必要があります。

また一般ユーザに関しても原則二段階認証を要求するのが望ましいです。昨今はID/PWの使い回しによって、他のWebサービスから漏洩したリストを元に、Google Workspace等にログインを試みるケースが多々あり、情報漏洩に即繋がります。二段階認証の設定手順は以下の通りです。

  1. 管理コンソールにログインする
  2. 左サイドバーより、セキュリティ=>認証=>2段階認証プロセスを開く
  3. 適用する組織部門を指定する
  4. 二段階認証プロセスに於いて、以下のような設定を行う
  5. 保存をクリックして適用する

仮にも特権管理者がロックアウトされてしまった場合には、Googleカスタマーケアサポート・ポータルにアクセス権限のあるユーザによって、解除をしてもらうか？パートナー企業であれば、パートナーコンソールから対象テナントに対して入ることが可能であるため、そちらで解除をしてもらう必要が出てきます。

尚二段階認証の選択肢であるGoogle AuthenticatorはAndroid向けおよびiPhone向けにリリースされています。各ユーザで行う必要があり、こちらにその手順が記載されています。また、Chromeの拡張機能としてもAuthenticatorがサードパーティ製ですが存在します。

図：二段階認証は設定推奨です。

アカウントの復元

アカウントの復元とは、パスワードを忘れた場合に於いて忘れた場合から処理を行えるようにするかどうかの設定です。ですが、企業ユーザの場合には乗っ取りの可能性もありえるので、通常は特権管理者についてはオンにしても、一般ユーザに関してはオフにするのが推奨です。よって一般ユーザがパスワード忘れがおきた場合には、情シスへ依頼して管理者からパスワードリセットしてあげるようにします。

  1. 管理コンソールにログインする
  2. 左サイドバーより、セキュリティ=>認証=>アカウントの復元を開く
  3. 適用する組織部門を指定する
  4. 特権管理者のアカウントの復元はオンにする
  5. ユーザアカウントの復元についてはオフにする

尚、Googleアカウントは何回もパスワードを間違えるとロックされてしまいますが、このロックが何回で掛かるのか？（一般には8回程度と言われている）については、テナントで設定することは出来ませんし、また何回でロックされるのか？の情報は一般公開されていません。

図：この設定はしておいたほうが望ましい

コンテキストアウェアアクセス

社用PCやスマートフォンなどについては、社内のプロキシーサーバ経由でなければテナントに入らせないという厳しい制限を課したほうが望ましいです。ただし、在宅勤務などのケースも考慮する必要があるので、IPアドレスでの制限よりもデバイスのシリアル番号を登録しておいて、一致した場合に通過するようにすることが可能です。

この機能をコンテキストアウェアアクセスと呼び、Enterprise Standard以上もしくはCloud Identity Premium以上で利用することが可能です。詳細な設定は以下のエントリーを参考に設定してみてください。この設定はIP制限以外のケースではChrome Enterpriseが必須となっています。

個人端末からのログオンを制限することが可能になります。

Google Workspaceで高度なアクセス制限を実現する

Chrome Enterprise

Google Chromeもドメインで管理し、勝手に拡張機能のインストールをさせないであったり、ポリシーを適用することの出来る機能がChrome Enterpriseです。Chrome拡張機能も情報漏洩の可能性のある要素の１つです。

またそれだけではなく、Endpoint Verification拡張機能を利用してのコンテキストアウェアアクセスを導入する場合にもこの設定が必要になっています。

さらにChromebookのデバイス管理をしたい場合には別途Chrome Enterprise Upgradeが必要になるため、厳しいデバイス管理をすることにより安全で快適な環境を構築することが可能になるため、最低でもChrome Enterpriseは導入しておくべきでしょう。個人アカウントでログインをさせないということのためにも必須です。

Google Chromeを組織管理下に置く方法

ASUS Chromebook flip C436FAを業務で使ってみるテスト

プロビジョニングとSSO

通常ある程度の大きな組織になると、Windows端末の制御のためにActive DirectoryやAzure Entra IDが導入されていることが多いです。これらの組織に於いてGoogle Workspaceを導入するとなると、AD側とGoogle Workspace側の両方に対してユーザ管理が必要になったり、パスワード管理を別々に行わなければなりません。

よって、この手間を省くために、ADやEntra ID側からユーザのプロビジョニングを行ったり、Entra IDのパスワードで入れるようにシングルサインオンの設定をしておくことが業務負荷低減に繋がります。

ADで行う手法とEntra IDで行う手法とで大きくやり方が異なるため、注意が必要ですが個人的にはEntra IDに絞ってそちらからの連携がもっともスマートだと思います（ただし、Windows端末のポリシー制御などが必要になるため、Entra IDの場合は別途Intuneが必要になります）。

Entra IDとGoogle Workspaceのメンバーを同期させる方法 - Provisioning編

Entra IDアカウントでGoogle WorkspaceにSSO連携してみた

Entra IDとGoogle Workspaceのメンバーを同期させる方法 - GDS編

Google Cloud Directory Syncを使ってOpenLDAPから同期させる

サービスのオンオフ

Google Workspaceに於いて通常はあまり行いませんが、特定のアプリケーションの利用だけに制限したいという要望があります。企業に於いて許可するアプリケーションを選択し、それ以外についてはGoogleサービスの利用を停止することが可能です。

ただし、ドライブとドキュメントを停止すると、ドライブ自体が使えなくなる為メールボックスの受信も出来なくなってしまいます（容量をシェアしている為）。Analyticsも停止するサービスによっては横連携していたりするので（例えばTag ManagerやGoogle広告、Merchant Centerなど）、停止する場合は他にどこまで影響するのか？をよく把握する必要があります。

  1. 管理コンソールにログインする
  2. コアサービスの一覧を開く
  3. 停止したい項目をクリックする
  4. サービスのステータスをクリックする
  5. 組織部門を指定する
  6. オフにして保存をクリックする
  7. 次にノンコアサービスの一覧を開く
  8. 停止したい項目をクリックする
  9. サービスのステータスをクリックする
  10. 組織部門を指定する
  11. オフにして保存をクリックする

図：停止するサービスはよく吟味する必要があります。

ログオンを特定テナントのみに制限したい

Google Workspaceは前述のChrome Enterpriseに於いて一般アカウントのログオン制限などを行うことは出来ますが、組織全体に於いてプロキシーサーバを経由する場合、ログオンするURLなどは一緒であるため、例えばFirefoxなどからの一般アカウントの作成やログインなどを防ぐことが出来ません。

これらも含めて丸っと企業ネットワークから「特定テナントに対してだけログオンを許可する」という設定をしたい場合には、プロキシーサーバに対して高度な設定を追加する必要性があります。

  • プロキシーサーバに於いてログオンのみであれば以下の２つを通過許可とする（必要に応じて許可するURLを増やす）。ただ、実際には以下の2つだけだと全然足りないと思います。
  • 証明書等での通過が必要なケースでは以下の3つを通過許可とする
  • また、特定テナントのみを通過許可とする場合には、端末レベルで「X-GoogApps-Allowed-Domains」のHTTPヘッダを付けて、特定ドメインだけを通過するように例外設定を行う

この設定はGoogle Workspaceではなく、社内のプロキシーサーバに対して設定を行うものになるため、利用してるプロキシーサーバによっては設定ができないケースがあります。

SMTPリレーサービス

それまでレンタルサーバなどのSMTPサーバを使っていて送信していたようなものも場合によっては移行作業が必要になるかもしれません。その場合、GoogleのSMTPリレーサービスを利用して置き換えることが可能です。特にプログラムからの利用やプリンターからの利用などが想定されるので、以下のエントリー内で設定方法を記述していますので、あらかじめリリース前に準備をしておくと良いでしょう。

VBAからGmailを送りたくなったら

野良アカウント対策

Google Workspace導入前の時点で同じドメインにてメールボックスが存在する場合、ユーザは実はそのドメインでもってGoogleアカウントを個人で作れてしまいます。結果、Google Workspaceでは管理されていないドメインのメアドを持ったユーザが出現してしまいます。これらのユーザの出現を阻止するためには、Cloud Identityやグループアドレスを使った「野良アカウント対策」が必要になってきます。

導入スタート前に野良アカウントがいる可能性がある為、GWSテナントへの移行を促したり、ドメインを剥ぎ取ったりして個人所有にしないよう対策が必要になっています。

個人GoogleアカウントをGoogle Workspaceに移管する手法

Google Workspaceの管理対象に含まれないユーザ用の移行ツールを検証してみた

Google Cloud Identityはどこまで使えるのか実験

移行作業のタスク

ここまででGoogle Workspaceの下準備は完了しています。しかしいきなり全面移行でリリースというわけにはいかないのが世の常。実際にはこれまでのシステムも並行稼働しつつ、徐々に移行が必要になります。特に新規導入の場合は、ユーザの側でやっていただく作業もあるため、移行スケジュールとタスク一覧を整備しておくべきでしょう。

ユーザ側で行う必要のある作業

メール関係

PSTデータのエクスポート

GWMMOを利用する場合、Outlookが必要なのはもちろんの事、ローカルにメールデータが入ったPSTファイルがあることが前提条件になります。しかし、現在のMicrosoft365はPOP対応を廃止済みであるため、原則IMAP4での接続になってるハズです。よって、移行したいと思ってもローカルにメールデータが無いため、このままではGWMMOを使っての移行は出来ません。

そこで、ユーザ側、管理者側の２つの観点からPSTファイルをエクスポートする手段について調査しました。以下のエントリーを参考にPSTファイルを用意しましょう。

Microsoft365のOutlookからPSTをエクスポートする手法

メールボックスデータの移行

旧式のPOP3とSMTPで送受信を行っていたような組織の場合、メールサーバの容量も少ない上に、クライアントのメーラで受信したらサーバからは削除する設定であるケースが多いです。この場合、メールデータはユーザのクライアントにだけ残ってるため、管理者が一括でGoogle Workspaceに移行させるのは難しいです。

この場合、２つのパターンでユーザはデータを自分のGoogle Workspaceアカウントに移行させることが可能です。

  • Outlookの場合：Google提供のGWMMOというツールを使って、PSTファイルを変換してGmailのメールボックスに送ることが可能です。
  • Mozilla Thunderbirdの場合：MBOX形式でエクスポートし、ImportExportTools NGという拡張機能を使ってGmailアカウントへ移行可能です。MBOXで出力できるクライアントならばこの手法が使えます。

また、注意点として

  1. GWMMOは、Outlook 以外のメールクライアント以外は未対応
  2. IMAP, Exchange, ウェブ版の Outlook データの移行は対象外。Windows 版OutlookでPOPダウンロードされているもののみ対象。
  3. Windows11 ARM版では、GWMMOは動作しませんので要注意。

※但し、2021年10月より、Microsoft365のExchange OnlineではPOP接続が廃止されてるため、GWMMOが使えるシーンは限られてると思います。

MBOX形式のメールをThunderbirdを使ってOutlookにお引っ越し

メーラーの設定

本来はPCにデータを残さない上でも管理手間のあるソフトウェアを排除する上でも、クライアント側でこれまで使ってきたメーラーアプリに関しては廃止すべきでしょう。Chromeのブラウザで十分作業は出来ますし、メーラーの場合だとGoogle Driveのファイルへのリンクの挿入などが出来ないので逆に利便性を欠きます。Google Chatのデータも見ることが出来ません。

しかし、どうしてもメーラーを使いたいと言う人（主に役員の方々とか）の要望を無碍に出来ないというケースに於いてはメーラーに対して個別に設定が必要です。この作業はローカルのメールボックスの移管が完了後に行います。しかし、現在のGmailは古いタイプのID/PWでのログインは出来なくなっていますので、OAuth2.0認証で設定する必要があるため、未対応メーラーは使えません（Mozilla Thunderbirdは対応しています）。

IMAPでの接続となるのでローカルにデータは残りません。

カレンダー

現在の組織でどのようなカレンダーツールを使っているか？によりますが、概ねどのサービスであっても、ical形式やCSV形式で予定のデータを出力できるのではないかと思います。これを手動でGoogle Calendarにインポートすることで移行が可能です。

  • Outlookの場合：Google提供のGWMMOというツールを使って、カレンダーを変換してGoogle Calendarに送ることが可能です。
  • icalやCSV形式の場合：手動で自身のGoogle Calendarに対してインポートをすることで移行が可能です。

図：カレンダーのエクスポート/インポート

連絡先

個人の連絡先データ（取引先など）のデータも移行が可能です。利用してるサービスによりますが、vCard形式やCSV形式で連絡先データを出力できるならば、手動でGoogle Contactsにインポートすることで移行が可能です。

  • Outlookの場合：Google提供のGWMMOというツールを使って、連絡先を変換してGoogle Contactsに送ることが可能です。
  • vCardやCSV形式の場合：手動で自身のGoogle Contactsに対してインポートすることで移行が可能です。

図：インポートダイアログ

Google Apps ScriptでContactsをPeople APIで弄る【GAS】

個人のPC内のデータ

昔と違って現代の企業内における貸与PCに於いて、「ローカル保存禁止」は割と定着してきたルールです。データの漏洩や個人所有で企業が管理出来ない状態で抹消される可能性、退職時にデータの移管が非常に面倒、業務がブラックボックス化するなど良いことは殆どありません。またデスクトップに山のようにファイルを配置してるような人もいる状態です。

Google Workspace導入の目的の１つはこういった個人のPC内にデータを残さないというものでもあるので、個人のPC内にあるデータはマイドライブ、出来れば共有ドライブの所定の場所にアップロードしておき、ローカル環境からは抹消するよう通達を出すべきでしょう。

ですが、後述のPC版Google Driveアプリで大量のファイルをアップロードするとミスが起きたり同期しないといったものが出てきたりします。Chromeブラウザでのアップロードも同じで、何よりも非常に煩雑です。情シスの手助けが必要になりますが、以下のエントリーにあるrcloneツールが非常に強力ですので、退勤時にでも仕掛けてGoogle Driveにアップロードをし移行するようにしましょう。

rclone browserでGoogle Driveにガッツリ同期させる

VBAやPower Automate資産

新規導入であっても、Microsoft365からの引っ越しであっても割と管理者が軽視して導入の大きな障害になってるのが「ExceマクロやVBA、Power Automateで作ってしまった仕組み」の取り扱いです。この点を軽視して進めるとどうなるか？現場から猛反発と突き上げを食らうことになるでしょう。小さなプログラムですが、現場の業務改善や時間の削減にめちゃくちゃ貢献してるものなので、当然ながら強行するならばこれらの資産について担保しろと迫られることは必死です。

まずですが

  • VBAコードは簡単なマクロ程度であればEnterprise PlusプランのMacro Converterが使えると言えば使えますが、完璧な変換は全く期待出来ません。よって、これらはGoogleスプレッドシートのマクロ機能でスクラッチから作り直しが必要です。また、この為に、Enterprise Plusプランを導入するというのも馬鹿げた話です。
  • VBAでガッチリ組んであるプログラムの場合、これらは中身を解析してGoogle Apps Scriptで実装をし直しということになります。ローカルのアプリをCOM操作してるようなものは置き換えが出来ないものもあるでしょう。
  • Power Automateですが、これはタスクランターサービスでありGoogle Workspaceには同種のサービスはありません。GASなどで自動化処理を構築して置き換える必要があります。
  • Power Automate for DesktopというRPAについてですが、これもGoogle Workspaceには同種のサービスはありません。
  • Power Appsアプリですが、これもMicrosoft独自のサービスです。同様のものがGoogle Workspace側にはAppSheetがありますが、フルスクラッチで作り直しになります。

Google Apps Scriptはオープンな技術のJavaScriptをベースにしてるものなので可搬性がありますが、VBAやPower Automateは特定企業に依存したクローズドな技術をベースにしてるものです。基本移植は出来ません。これは、過去のNotes問題でも同様のことが起きています。つまり、ベンダーロックインされてしまってるということ。

故に、Microsoftと共に生き続けるならば悪い選択肢ではないですが、移行するとなるとこれは大きな痛みの伴う作業となります。当然並行稼働期間も必要となるので、移行スケジュールも長くなり移行コストもそれだけ増大することになります。甘く考えてはいけない領域なのです。

※この作業をユーザ側としてる理由は、情シス側はほぼほとんどのケースで現場サイドの業務を知らないだけじゃなく、その詳細な中身についても理解してる人は殆どいない為。つまり作り直すといっても彼らのほとんどは作り直すだけの技術を持ち合わせていないことが多い為です。

※マクロの記録で作成されたVBAについてはGeminiとGASを使って変換する仕組みを作ってみました。

Geminiを使ってVBAからGoogle Apps Scriptに変換する仕組みを作る【GAS】

Google Apps Scriptを始めよう。出来ること代表例【GAS】

Googleスプレッドシートのマクロの記録機能を使ってみた

Google WorkspaceでAppSheetを使いDXを加速化させる

管理者側で行う必要のある作業

複数の管理者アカウント

作成したばかりのGoogle Workspaceのテナントは特権管理者1名のみの状態です。最初のセッティング時はそれだけでも良いのですが、時間経過と共に企業の規模にもよりますが、管理者アカウント1つだけで運用は厳しくなります。主な理由は以下の通り。

  • 管理者は二段階認証が必須であるため、スマフォやAuthenticatorなどが必要となり複数名での使いまわしが難しい。
  • 普段使いのアカウントに対して管理者ロールを割り当てるのは、漏洩した際にテナントにまで危機が及ぶ為、セキュリティ面で推奨出来ない。
  • 役割分担を考えた場合、各種ロールをもたせた複数名である必要がある。
  • 一方は出先から、一方は社内からといった用途が発生した場合、１つだと担当者が戻るまで設定変更が出来ない。
  • 複数名承認機能がリリースされていますが、１名のみの組織の場合、悪意のある管理者によるテナントの設定変更を許してしまう。

しかしこの為にGoogle Workspaceのフルライセンスを割り当てるのもコスト面では無駄が大きいため、自分の場合は以下のような管理者を複数名用意して運用しています。

  • 普段遣いのアカウントとは別にCloud Identity Freeによる管理者専用アカウントを複数用意。
  • それぞれでスマフォのGoogle Authenticatorで二段階認証を設定する。
  • 複数名承認機能をオンにして、他のメンバーによる管理者設定のオンオフを牽制する。
  • 特権ではなくユーザ管理者などのロールを絞ったユーザを現場に配置する場合も同じ

こうしておくことで、よりセキュアにより利便性が高くGoogle Workspaceを運営することが可能です。

Google Cloud Identityはどこまで使えるのか実験

メール関係

転送設定

現存のメールサーバを活かしつつ、Google Workspace側のGmailに新規受信のメールについて転送をすることが可能です。まだ、MXレコードを切り替えていないので本番のドメインではGmailは受信が出来ないわけですが、新規導入時点で管理コンソールのドメインの管理を見てみると「hogehoge.com.test-google-a.com」というテストドメインエイリアスが設定されています。

但しこれは、現存のメールサーバ側に受信メールの自動転送の機能がある場合でないと利用できません。

全ユーザに対して転送の設定をしておき、転送先はGoogleアカウントのドメイン部分をテストドメインエイリアスにしておく。すると新規に受信したメールはGmailのメールボックスにも入るようになります。一部のユーザにだけ先行してGoogle Workspaceを使わせたいといった場合にも利用が可能です。概ね転送で十分な日数が経過したならば、いよいよ次項のDNS切り替えで完全にGmailに移行しましょう。

Gmailに移行後はテストドメインエイリアスは無効化してしまって問題有りません。

図：テストドメインエイリアスを利用する

DNS切り替え

全てのユーザをGmailに移行させて、現行のメールサーバの運用を停止するというステージになったら、ドメインを管理してるDNSに於いて、以下の作業をする必要があります。以下の作業を行います。

但し、MXレコードを登録するまえに、既存のDNS上のMXレコードはすべて削除しておく必要があります。削除してから追加しないとGoogle Workspace側で認識することができません。

  1. さくらのDNSの対象のドメインのゾーン編集画面を開く
  2. 既存のDNSには現在のメールサーバ向けのMXレコードがある筈なので削除する
  3. 新規にDNSに対して以下のようなMXレコードを追加します。

    ※データの最後に必ずピリオドを入れるのを忘れずに
  4. しばらく待ってみる
  5. こちらの内容に従って、Google Workspaceの管理コンソールに入り、アカウント→ドメイン→ドメインの管理にて、対象ドメインの「Gmailを有効化」をクリックする
  6. 指示にしがって進めて有効になればオッケー。Gmail を有効にしましたという表記になるはずです。
  7. これでGmail側でメールの送受信が出来るようになってるはずなので、確認テストを行う。

図：MXレコードを書き換える

SPF, DKIMやDMARCの設定

2024年2月、Googleは取り敢えずGmailに対して送信されるメールについては、送信元でSPF、DKIM、DMARCが適切に設定されていない場合受信を拒否するということを発表しました。実際にこの設定が出来ていないメールが拒絶されて届かない状況になっています。この設定はMicrosoftやYahooなども追従する方針が出ているため、Google Workspaceを導入したらもはや必須の作業となります。

前述のDNS切り替えと同時に以下のエントリーを参考に、GWSおよびDNSに対して設定を施すようにしましょう。

Google WorkspaceでSPF, DKIM, DMARCを設定する

ドッペルゲンガードメイン対策

割と古い手でもあり、そして防ぐのが難しいのがドッペルゲンガードメイン。メール誤送信で大規模な情報漏洩の原因となっていたりします。これはユーザが手打ちでメアドを入力した結果、似たような違うドメインで送信をしてしまい、全く違うドメイン宛にメールが送られてしまうもの。

例えば、gmail.comではなくgmai.comやgmail.coなどなど。これらは入力者のタイポであるため、なかなか防ぐのが難しいものになります（相手のメアドはあくまでも正規のドメインですので）。大学などでも今この取り組みが進んでいます。それだけ誤送信が多いのでしょう。

明確に攻撃者が似たようなドメインを用意して情報を横取りする為の古典的な攻撃手法なのですが、これを防ぐ為に、Google Workspaceに対してこれらドッペルゲンガーになりやすいドメインをブラックリストとして登録しておいて送信拒否するようにセットすると良いでしょう。公式リファレンスはこちら。

  1. 管理コンソールにログインする
  2. 左サイドバーよりアプリ⇒Google Workspace⇒Gmailを開く
  3. 一番下にある「ルーティング」を開く
  4. さらにその中にあるルーティングの設定もしくは別のルールを追加をクリックする
  5. 一番上はルーティングの名称なので「ドッペルゲンガー対策」とでも入れましょう。
  6. 影響を受けるメールでは「送信」にチェックを入れる
  7. 上記の種類のメッセージに対し、次の処理を行うでは、「メールを拒否」を選択する
  8. 下のオプションを表示をクリック
  9. 「アドレスリストを使用して、この設定を適用するアプリケーションを除外、制御する」のチェックを入れる
  10. この設定を特定のアドレスまたはドメインにのみ適用するにチェックを入れる
  11. リストを作成または編集をクリックする
  12. アドレスリストページに飛ぶので、アドレスリストを追加するか？既存のものを利用する。ここではとりあえず新規作成します。
  13. 名前は「ドッペルゲンガードメイン」とでも入力
  14. アドレスを追加をクリックする
  15. アドレスではなくドメインを入力してどんどんここに追加していく。
  16. 保存をクリックする
  17. ルーティングの設定画面に戻る
  18. 既存のリストを使用するをクリックする
  19. 今さっき作ったドッペルゲンガードメインにチェックを入れて、✕印をクリックして閉じる
  20. 影響を受けるアカウントの種類は、ユーザとグループにチェックを入れる
  21. ルーティング設定画面の保存をクリックして閉じる

実際に、例えばtest@gmai.comなどのリストに合致するようなドメイン宛に送ってみる。すると、Mailer Daemonから拒否された旨のメールが返ってくればオッケー。

このリストに入れるべきドメインですが、まぁ、多種多様なのでメンテは難しいとは思いますが、最低限度以下のリストは入れておくべきでしょう。自身のテナントが送る先にどんなものが多いのかから、間違えやすいパターンを想像してどんどん入れていきましょう。

図：ルーティングの設定

図：ドッペルゲンガーリスト

図：リストを選択してる様子

図：無事にメール送信が拒否されました

ファイルサーバのファイル

業務でローカルのNASだけがある場合、NASを廃止してGoogle Driveに寄せることは可能です。その場合、NASのアクセス権限はグループで制御することになります。アップロード先は共有ドライブとするわけなのですが、膨大なファイル数とファイルサイズであるため、安定的にアップロードして移行する手段が必要です。

個人のケースでも利用したrcloneでNAS内の各ディレクトリを対応する共有ドライブにアップロードするよう指示を作成し、アップロードを実行しましょう。但し、前述の注意点にもあるように1日1アカウント当たりアップロード出来る容量は750GBまで。また、共有ドライブは1ドライブ当たり50万ファイルまで(階層は100階層まで可能)。

NAS側の対象のディレクトリがどれくらいのファイル数があり、どれくらいの容量なのか？をよく考慮して共有ドライブに上手に収めてあげる必要があります。また、アップロード中、社内のネットワーク帯域が圧迫される恐れがあるので、可能であれば深夜にアップロード実行するように少しづつ移行しましょう。

rclone browserでGoogle Driveにガッツリ同期させる

共有連絡先

全社員で共有してる連絡先データというものを用意してるケースはあります。Active Directory、メールクライアントやグループウェアに入ってるわけですが、Google Workspaceにも共有連絡先というあまり知られていない機能があります。但しこの機能はユーザはGoogle Contactsで利用しメールでも宛先に出てくるようになるのですが、API経由でなければデータの入出力が出来ないという問題点があります。

Google Apps Scriptでこれを実現するものを用意しましたので、以下のエントリーを参考に移管をしてみると良いかもしれません。

Google Apps Scriptで共有の外部連絡先を管理する【GAS】

GoogleアカウントでWindowsにログオン

現在の組織の環境にローカルのActive Directoryがあり、今後も利用することが決定してるならば、このActive DirectoryとGoogle Workspaceを連携させてユーザアカウントの自動作成、組織部門へ自動配置、共有連絡先の同期、グループの自動同期が可能になります。ADとGWSで個別に作業をする必要がなくなるので、ADを基軸として業務フローを構築可能です。前述のその他のテナント設定にも記述してある通りです。

但し、ローカルADの場合はログオンパスワードに関しては対象のPCに対して別途Password Syncをインストールし設定しておく必要性があります。

殆どローカルADは活用しておらず、Google Workspaceに寄せるということであるならば、ADを廃止してGoogle 認証情報プロバイダ（GCPW）をローカルPCに対してインストールすることで、GoogleアカウントでPCにログインするといった事も実現可能です。

AD不要！？Google WorkspaceアカウントでWindowsにログインする方法

ポータルサイトの構築

現行の組織の環境でもおそらく旧来のイントラネットの顔であるポータルサイトがあったかと思います。これそのものの移行は手段が無いため出来ませんが、あらためて作成することが可能です。

簡単な作成手順は以下の通り

  1. 特権管理者のアカウントにてGoogle Sitesでサイトを作成しデプロイする
  2. Chrome Enterpriseにて、組織管理のChromeの初期ホームページを1.のサイトの公開URLを指定して全ユーザに配信。
  3. Google Apps Scriptにて業務用アプリを開発し、サイトに埋め込む（申請フォーム系など）
  4. 掲示板システムはGoogle Workspaceには存在しないので、どうしても欲しい場合はrakumoなどを追加導入する（自分の場合、GASで作成しました）
  5. ポータルのコンテンツを日々充実させ、利用者が離れないよう努力する
  6. Google Analyticsコードを追加して閲覧状況をモニターする

5.が一番大切ですが一番出来ていない人が多いかもしれません。ただ無闇に貼り付けておけば見に行くだろうという期待をしても実際には驚くほど見られていません。

新しいGoogle Sitesを使い倒してみた

情シス宛申請フォーム

汎用チャットスペースを作る

例えば人事からのお知らせや、総務からの企業全体のイベントの通知、現業部門からの商品情報の掲示発表など、主に通知を目的としたものは「メール」ではなく、「Google Chatのスペース」で行うようにしたほうがベターです。理由は明確で「メールだと他のメールに埋もれる」というよくある事例です。導入初期はそういった事例が薄くても、時間が経過する事に濃くなっていきます。

とりわけ旧来タイプの組織の場合、チャット文化がゼロなので何でもメールで片付ける傾向があります。

前述のグループアドレスに於いて、全員や特定社員のみのスペースを作成し、なるべく通知はGoogle Chatで行うように誘導しましょう。また、GASなどからも通知を送ることが可能ですが、最も簡単なWebhookを使って投稿する方法もありますので、簡単に対象のスペースに通知を行えるので、チャットを活用する習慣を定着させましょう。

Google Apps ScriptでGoogle Chatにメッセージを送る【GAS】

Classroomで社内研修の場を用意する

Google Workspaceを導入して意外と企業ユースで活用されていないのが、「Google Classroom」。各個人でもクラスルームを使えますが、できれば特権管理者にてルームを用意しておき、講師として各ユーザを追加、研修資料（スライドやフォームの問題集、課題、動画）などをアップしてもらうようにしましょう（Classroomのファイル類は設置した対象者のマイドライブに保存される為。特権管理者ならば削除される心配がない）。

もともとはGoogle Workspace Educationの機能でしたが、現在は全プランで利用可能で各資料を単体で用意してというよりは体系やコース別に作り上げていく上では非常に優れたツールです。社内研修のe-Learningの場所として活用しましょう。情シス部門からも「セキュリティ講座」や「社内システム活用講座」、人事部門からは「コンプライアンス講座」「新法制度の解説講座」などなど色々と使い所は満載です。

※ファイルで管理の出来るGoogle Sitesで作成しても良いかもしれません（簡単に丸ごと複製も出来ますし）

通常のG SuiteでもClassroomが使えるようになってた

GASのウェブアプリ専用アカウント

Google Workspaceを導入して現場の改善意識が高まり様々なGASを使ったツールが増えるのは良い傾向です。単純なGASであるならばそれを含めたスプレッドシートのファイル類は共有ドライブに配置しておけば問題ないでしょう。

しかし、GASで作成したウェブアプリとなるとちょっと事情が異なります。GASのウェブアプリはデプロイした人間のアカウントで動作する仕組みであるため、仮にも対象者が退職してしまい、アカウントを削除してしまうと動作停止してしまいます。ファイルのオーナー権は共有ドライブに移動させておけば消える心配はないのですが、突如としてウェブアプリが動かなくなるので、非常によく使われてるアプリの場合困ったことになります（結果、本人がもういないのにアカウントだけは延々生き続けてるケースがあったりします）。

故に、この自体を防ぐために内部で運用ルールを定めて、Webアプリケーションのデプロイに関しては特権管理者のアカウントで行うか？専用に用意したアカウントで実行するようにし、退職されたとしても動作を継続する体制を整えるのが肝要です。

Google Apps Scriptでウェブアプリケーション作成入門【GAS】

Youtubeチャンネル

企業でGoogle Workspaceを導入した場合、個人のアカウントでチャンネルを作って運用してしまうと、あとあと問題になります。これは前述のGASのアプリ同様、対象者が退職した場合、アカウントを削除するとチャンネルも削除されます。

かといってそのためにアカウントをずっと延命するというのはコストの無駄遣いです。よって企業チャンネルを作る場合には、個人アカウントに紐ついたチャンネルではなくブランドアカウントを作成し、そこに複数名の管理者を参加させて共有する形で運用する必要があります。あとからブランドアカウントに変えることは出来ませんので（チャンネルのURLが変わりますので）、最初が肝心です。

現場まかせでチャンネル作って運用などということは絶対に行わないようにしましょう。

Google WorkspaceでYoutubeチャンネルを運用するコツ - 前編

Youtubeのブランドアカウント作成と移管

移行後のタスク

社内研修を行う

Google Workspaceは個人でも利用できるGoogleアカウントとそのサービスと基本的には使い方が同じです。それ故に学習コストはMicrosoft365などと比較すると低いと言えます（普段からGmailとかは使ってるでしょうし、Googleスプレッドシートの要領も理解してる人は多いでしょう）。

しかし社内となると、そもそもITリテラシーに疎い人も多いだけじゃなく、企業運用ならではの問題なども多々あります。にも関わらず、その点を蔑ろにして社内周知を掲示板だけにとどめ、十分な社内研修を行わずに見切り発車して後々面倒なことになるケースを見てきています。時間と手間は掛かりますが、必ず社内研修を十分に行い、　フォロー体制を構築しましょう。

以下は古い資料でリライトが必要なものですが、過去に自分が社内研修で作成した動画資料です。他アップしていませんが、スライド資料や研修中のテスト用の資料なども用意して、全国の施設を回って研修を行っていました。パートナー企業に於いても同様のサービスを提供してるケースがあるので、ここは投資ということで利用すると良いでしょう。

G Suite 中級編

G Suite 入門編

アプリでカバーをする

Google Workspaceを導入したからといって、いきなりローカルのMicrosoft Officeを全部廃止・・・ということは恐らくできないと思います。最終目標はそれでも良いのですが、移行期間や一部のメンバーに関してはどうしても避けられないというケースもあります（Excel VBAで組まれたツールがガッツリ業務のフローに入り込んでるケースなど）。また、Google DriveではなくBoxを採用していて使ってきたという企業の場合も、Google Driveに移行するというのはなかなか難しいのではないかと思います。

前者の場合は、PC版Google Driveアプリを導入し、PCのGドライブとしてGoogle DriveをマウントしてMicrosoft Officeの運用を継続できるようにしてあげると良いでしょう。

後者の場合、Boxをそのまま継続利用する場合は、box for google workspaceを導入し、Box上でファイルを開くとGoogleスプレッドシートやドキュメントで開かれるといったヘルパーアプリを用意するとスムーズです（GASが使えないという制限はありますが）。

徐々に徐々に、Google Workspaceの文化に移行していき、とりわけMicrosoft Officeの利用は卒業する方向性に持っていかないと、GoogleとMSの両方でコストを払い続けるのは非常に勿体ないです。

図：Box上で直接作成や編集が可能に

PC版Google Driveを使う上での注意点

SAML認証の設定

Google Workspace以外のWebサービスが存在し、現在も利用し今後も継続利用する方向性であるならば、そのWebサービスに対するSAML認証設定をすることによって、Google Workspaceアカウントによるシングルサインオン環境を構築することが可能です（例：ZoomやBacklog）。

SAML認証をセットすることによって、個別のサービスで個別に管理（パスワードなども）するのではなく、１つのGoogle Workspaceアカウントにてアカウント認証をして入れるようになるため、ユーザにとっては利便性が向上し、組織的には個別アカウントの管理が容易になるだけじゃなくパスワード漏れに関して注力すべきはGoogle Workspaceに絞ることが可能になります。

SAMLの設定は殆どのWebサービスで対応している場合は同一の手順となるため、１つ手順を身につければ概ね設定はできるようになります（一部特殊な設定をする事例はありますが、設定方法は必ずドキュメントで用意されてる筈です）。

カスタムSAMLアプリを設定すると、Chromeトップページのアカウント横のつぶつぶをクリックすると、対象のアプリが出てくるようになるので、ブックマークなどをしておく必要もありません。

図：SAML認証の設定中の画面

関連リンク

カテゴリー
Google、入門編、業務テクニック
タグ

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。（スパム対策）

Google

前の記事

Google SpreadsheetでBigQueryを操る最初の一歩【GAS】
2024年4月2日
Google

次の記事

Google Apps Scriptで現在の割り当てライセンス数を調べる【GAS】
2024年4月4日