< ブログ一覧に戻る

Microsoft 365とGoogle Workspace併用の情報共有|構成・認証・権限の設計

最終更新日:2026.10.27 社内ポータル・デジタルワークプレイス
Microsoft 365とGoogle Workspace併用の情報共有設計

Microsoft 365とGoogle Workspaceを併用している企業では、「資料の置き場所が分からない」「共有リンクを開くと権限エラーになる」「同じ連絡を両方へ投稿している」という問題が起こり得ます。どちらか一方へ統一すれば解消するとは限らず、統一まで長い期間を要する組織もあります。

併用環境の情報共有は、文書の正本・本人確認・閲覧権限・全社への入口を分けて設計することが基本です。共同編集や文書管理は各基盤に残し、全社員向けの情報提供を共通化する方法も比較できます。ただし、入口の統一だけで、文書の権限や契約が自動的に統合されるわけではありません。

この記事は、両サービスの併用を続ける企業のIT・総務・社内広報向けに、構成の選び方、情報の所有ルール、検索と権限の検証、日常運用までを整理します。

最初に分けるのは「全社に届ける情報」と「一緒に作る情報」

すべての資料を同じ場所へ集めようとすると、共同編集や権限の移行まで必要になります。先に、情報の用途を分けましょう。

用途代表例設計の中心
全社の正式な情報規程、制度、経営メッセージ正本、責任者、対象者、更新の周知
部門・案件の共同作業提案書、議事録、作業中の表編集する場所、参加者、共有期限
業務への案内経費申請、ITサポート、人事手続き申請先、利用条件、説明の更新
日常の連絡進捗連絡、相談、短期の調整チャネル、参加者、正式情報への参照

例えば、休暇制度の正式な規程は所有部門の保管先で管理し、全社の入口には「対象者」「申請方法」「規程へのリンク」を載せます。制度の説明がTeamsとGoogle Chatの会話だけに残る状態を避け、会話からも正式な案内へ戻れるようにします。

同じ会社の社員でも、テナントやドメインが分かれていれば、各サービスでは外部共有として扱われる構成があります。会社名が同じだからアクセスできる、という前提を置かず、実際のアカウントと管理設定で確認してください。

Microsoft 365・Google Workspace併用で選べる3つの構成

構成適する条件注意点
基盤を分け、共有ルールを統一共同作業の境界が明確で、全社情報の量が限定的社員が複数の入口を使う負担が残る
既存の一方を全社の入口にする対象者がその入口を利用でき、認証・契約・運用の条件が合うもう一方の利用者のアクセスと、元文書への権限を確認する
両基盤の上に共通の入口を設ける複数基盤を維持しながら、全社発信と案内を共通化したい入口の費用と運用、連携、障害時の分担が加わる

共通入口を置く案は、すべての業務を移す案ではありません。社員が会社の正式な情報を知り、必要なツールへ向かう場所を整える考え方です。共同編集、メール、申請処理をどこまで入口で扱うかは、用途ごとに判断します。

Microsoft 365とGoogle Workspaceの既存文書を共通の入口へつなぐ構成
導入検討の整理図(概念図)

手順1:情報の正本と所有者を決める

最初に作るのは、サービスの機能一覧よりも「情報の管理台帳」です。次の例のように、情報単位で記入すると、二重投稿と更新漏れの原因が見えます。

情報正本所有者入口の役割更新のきっかけ
人事規程SharePointの指定文書人事制度担当概要・対象者・正本への案内規程改定、制度変更
部門の作業手順Google Driveの指定資料対象部門の責任者関連社員への案内業務変更、定期点検
全社ニュース合意した全社公開先社内広報本文の公開と対象者への配信発表、訂正、掲載終了
経費申請既存の申請システム経理業務担当必要書類と申請先の説明ルール・申請先の変更

これは記入例であり、特定の情報を必ずSharePointやGoogle Driveに置くという推奨ではありません。既存の承認・保管・業務要件に合う場所を選びます。

複製が必要な情報には、元の正本、複製の目的、更新担当、終了条件を記録します。「念のため両方に置く」を続けると、更新時にどちらを直すべきか分からなくなります。

手順2:認証とアカウントのライフサイクルを整理する

一つの入口と、一つのアカウントは別の話

SSOはログインの負担を減らす仕組みですが、それだけで両サービスのアカウントや閲覧権限がそろうわけではありません。「本人を確認できる」「入口に入れる」「文書を読める」「編集できる」を分けて設計します。

Googleは、組織で許可された場合にGoogleアカウントを持たない相手と文書を共有するビジター共有を案内しています。ただし、利用できる操作や本人確認の条件があります。特定文書の共有と、全社員向けポータルの認証設計は、同じものとして扱わないでください。

入社・異動・兼務・退職を一枚にする

組織情報の正本を人事システムなどに決め、社員番号、所属、拠点、役割をどこへ反映するかを整理します。メールアドレスは変更される場合があるため、同一人物を継続して識別できるかも確認しましょう。

  • 入社:誰がいつアカウントを作り、初日に何を読めるようにするか。
  • 異動:新しい情報を付与するだけでなく、不要になった権限を外せるか。
  • 兼務:複数部門の案内を受け取る期間と、解除の担当を決めているか。
  • 退職:入口と元サービスのID、残存セッション、共有設定をどう処理するか。

例外設定には、承認者と見直し日を付けます。組織改編のたびに手作業で修正するなら、その工数も構成比較へ含めてください。

手順3:検索・表示・編集を別々に検証する

「両サービスと連携する」という説明は、リンクを並べるだけの場合から、本文検索や画面内の表示まで、幅があります。必要な操作を次のように分けて質問します。

求める操作具体的に確かめること
リンクで案内正しい文書を開けるか。再ログインや申請で止まらないか
横断検索対象サービス・ファイル形式・本文・更新や削除の反映条件
文書の表示表示される範囲、元の権限、ダウンロードの扱い
共同編集誰がどのアカウントで編集し、履歴をどこに残すか
AI回答根拠、最新版、閲覧対象外の情報、答えられない場合の案内

検索結果に出ることと、開けることも区別します。検索対象が不足している問題と、元文書の権限が不足している問題は、改善の担当が違うからです。閲覧対象外の文書については、タイトルやプレビューに何が出るかまで検証しましょう。

手順4:全社の発信を一本化し、通知先を使い分ける

全社ニュースの正本を決めたら、TeamsやGoogle Chatなどへの通知は、正式な情報へ戻る導線として設計します。通知に本文全体を複製すると、訂正時に複数箇所の修正が必要になります。

通知には、何が変わったか、誰に対応が必要か、いつまでに何をするかを記載します。すべての社員へ毎回同じ通知を送るより、対象者と重要度を整理することが先です。配信先の設定と閲覧権限は別に確認してください。

既存基盤との役割分担を検討する材料として、「Google Workspace × LumApps 導入検討の手引き」と「Microsoft 365 × LumApps 導入検討の手引き」を比較して読む方法もあります。自社に必要な連携を、検索・表示・アクセスに分けて整理できます。

設計例:部門ごとの作業基盤を残して、制度案内を共通化する

以下は構成を考えるための仮想例です。本社はMicrosoft 365、別部門はGoogle Workspaceを使い、どちらも当面継続するとします。人事制度の案内は全社員が必要ですが、部門の作業文書まで統合する必要はありません。

  1. 人事が制度案内の正本と更新責任を持つ。
  2. 共通入口に、制度の概要、適用条件、申請先を掲載する。
  3. 各基盤の利用者が読める情報と、別の権限が必要な情報を区別する。
  4. TeamsとGoogle Chatなどの連絡経路は、正式な案内への通知に使う。
  5. 両方の利用者で閲覧・申請まで試し、止まった原因を直す。

この構成では、共同編集の慣習を一度に変えず、全社向けの案内から整えられます。ただし、正本の閲覧に契約やアカウントが必要なら、その条件の解決は残ります。誰でも開けるリンクへ変更して済ませず、共有すべき範囲と情報保護の要件を合わせて確認します。

失敗しやすいのは、入口だけを整えて裏側を変えないケース

見え方を変えたが、正本が二つ残っている

入口のリンクは正しくても、チャットや過去のメールから旧版へ到達できる状態では混乱が続きます。旧文書の廃止、更新通知、既存リンクの扱いまで計画してください。

表示対象を絞ったので、権限も守られたと思っている

自分向けの画面を出す設定は、元文書のアクセス権とは別です。直接URLを開いた場合や検索した場合も含めて、必要な制限が働くかを試します。

問い合わせをサービス別にたらい回しにする

社員には、入口、認証、保管先のどこでエラーになったか判断しにくいものです。受付で所属、対象情報、操作、エラーを集め、担当部門が切り分ける運用にします。認証情報など、調査に不要な秘密情報を求めない手順も必要です。

切り替え前に試す、併用環境の受入チェック

試験確認する条件
通常アクセス両基盤の社員が、同じ案内から必要な正本を開ける
権限なし対象外の社員が、検索・プレビュー・直接URLで何を参照できるか
異動・兼務表示対象と元文書の権限が、合意した手順で更新される
文書の改定入口・通知・検索が更新と整合し、旧版が混乱を招かない
連携停止問い合わせ窓口、調査担当、暫定の案内方法が機能する

確認結果には、使ったアカウントの区分、端末、保管先、設定条件を残します。管理者が開けたことをもって、一般社員も開けると判断しないようにしてください。

公開後に見るのは、入口のアクセス数だけではありません。二重投稿の回数、アクセス申請のやり直し、文書の所在に関する問い合わせを追います。基盤の違いを社員に意識させず業務を完了できたかが、運用改善の中心です。

段階展開では、最初の情報群で更新と問い合わせが回ることを確かめてから、対象部門と連携先を増やします。新しい保管先を加えるたびに、所有者、権限、検索への反映、障害時の担当を確認するルールを持つと、再び入口が複雑になることを防げます。

共通入口の追加費用に見合うかを判断する

共通入口を採用すると、新しい利用料と運用が加わります。削減できる二重投稿や案内の作業、権限エラーへの対応、社員の探す時間と比較してください。既存サービスを残す費用は、そのまま必要なものとして計上します。

導入前に代表的な業務で測り、公開後も同じ項目を追うと、改善を確認できます。入口を一つにすること自体を目的にせず、社員が業務を完了し、所有部門が正確に更新できる構成かを判断しましょう。

LumAppsを共通入口の候補にする場合の確認点

LumAppsは、Google Workspace連携とMicrosoft 365連携を公式に案内しています。既存の作業基盤を活かしながら全社情報の入口を整える候補として、自社の業務シナリオで適合性を確認できます。

比較時には、次の条件を共有すると話が具体的になります。

  • Microsoft 365とGoogle Workspaceを使う組織、テナント・ドメインの構成。
  • 利用者の種類と、会社メール・端末の有無。
  • 全社向けに共有する情報と、保管先に残す正本。
  • 検索、表示、編集のうち必要な操作。
  • 既存の認証方式と、異動・退職時の更新手順。

公開情報だけで、すべてのドメイン構成や連携範囲を確定することはできません。標準対応、追加設定、個別作業、契約条件を分けて回答してもらいましょう。

併用環境の情報共有に関するFAQ

どちらかのサービスに統一した方が安くなりますか?

ライセンスだけでなく、移行、業務変更、教育、連携保守を含めて比較します。統一後も必要な契約が残る場合や、併用中の追加管理が大きい場合があるため、自社の構成で試算します。

全社員に両方のアカウントを配る必要はありますか?

必要な業務と共有方式によります。入口を利用できることと、元サービスで閲覧・編集できることを分け、対象者ごとの契約・認証条件を確認してください。

すべてを横断検索できれば解決しますか?

正本の整理と権限管理は別途必要です。旧版が多数残っていたり、閲覧権限が付与されていなかったりすると、検索機能を増やしても業務は完了しません。

併用のまま、社員が迷わない入口をつくる

Microsoft 365とGoogle Workspaceの併用では、サービスを減らす判断と、社員が迷わず情報を使える設計を分けて考えられます。正本とID、権限、発信責任をそろえたうえで、共通入口の要否を判断しましょう。

Microsoft 365とGoogle Workspace併用の情報共有についてLumAppsに相談する

両基盤を維持した構成を具体化したい場合は、Microsoft 365・Google Workspace併用環境をLumAppsに相談することができます。上記の条件を共有すると、全社の入口で担う範囲と、既存基盤に残す役割を整理しやすくなります。

お問い合わせ

企業の社内コミュニケーション、従業員エンゲージメント、
ナレッジマネージメントの改善のお手伝いをします。

3分で分かるLumApps 資料の表紙