Google WorkspaceのGeminiライセンスを調達したとき、全社展開の前に決める項目は6つあります。誰に配るか（配布範囲）、何を読ませるか（データ参照範囲）、誰が承認するか（管理主体）、何を記録するか（監査ログ）、どう削除するか（利用停止基準）、どう伝えるか（利用ルール）です。この6項目を決めずに配ると、ライセンスが届いた部署から順に使い始め、データ参照範囲の設計が後回しになります。結果として過共有のドライブをGeminiが読み、意図しない情報の横断検索が可能になります。本記事は、全社展開の意思決定に必要な検証材料と決定の順序を示します。

Gemini全社展開で最初に決める配布範囲

最初に決めるのは配布範囲です。全従業員に配るか、部署単位で段階配布するか、職種で絞るかの3択があります。

全従業員配布は、ライセンス数が全社分あり、機能制限を事前に設定できる場合に成立します。管理コンソールで機能のオン・オフが切り替えられるため、配布後に段階的に解放できます。ただしGeminiはドライブの権限をそのまま参照するため、ドライブの過共有が残っている組織では、配布範囲を広げると意図しない情報の横断検索が可能になります。

部署単位の段階配布は、特定部署で先に使わせ、問題が出たら止める方式です。配布前にその部署のドライブ権限を洗い出し、部署外への共有を削除します。配布後に監査ログで利用状況を確認し、次の部署へ広げる判断材料にします。段階配布は検証期間を確保できる一方、部署ごとに権限設計を繰り返すため展開速度が遅くなります。

職種での絞り込みは、情報の横断検索が業務上必要な職種に先行配布する方式です。経営企画・法務・IR・監査部門など、全社情報へのアクセス権がすでに付与されている職種が対象です。これらの職種は既存の権限範囲内でGeminiを使うため、新たな権限拡大が発生しません。ただし職種の定義が曖昧な組織では、配布対象の線引きが難しくなります。

配布範囲はドライブの権限設計が完了している範囲と一致させます。権限設計が未完了の部署へ配ると、Geminiが読める範囲と業務上読んでよい範囲がずれます。

データ参照範囲を決める2つの軸

Geminiが読めるデータの範囲は、ドライブの権限設定で決まります。ここで決めるのはどのフォルダをGeminiに読ませるかとどのフォルダを読ませないかの2軸です。

読ませるフォルダは、業務上の情報検索が必要な範囲を洗い出します。例えば営業部門であれば、営業資料フォルダ・提案書テンプレート・顧客情報の3つが対象です。この3フォルダへの閲覧権限が営業部員全員に付与されていれば、Geminiは営業部員が手作業で検索する範囲と同じ範囲を参照します。

読ませないフォルダは、機密情報・人事情報・契約書原本など、横断検索の対象から外すべきものを指定します。これらのフォルダは閲覧権限を狭く設定し、Geminiの参照範囲から除外します。ただしドライブの権限設定が「リンクを知っている全員が閲覧可」になっている場合、フォルダ単位の除外は効きません。まず権限設定を「特定ユーザーのみ」へ変更する作業が必要です。

データ参照範囲の設計は、ドライブ監査を先に実施してから行います。現状の権限設定を可視化せずに範囲を決めると、設計と実態が乖離します。監査の結果、過共有が大量に見つかった場合は、Geminiの配布前に権限の棚卸しを完了させます。

管理主体と承認フローを決める

Geminiの利用申請を誰が承認し、誰が設定を変更するかを決めます。管理主体はIT部門が一元管理する方式と、部門ごとに管理者を置く方式の2つがあります。

IT部門一元管理は、管理コンソールの操作権限をIT部門のみに付与し、利用申請を集約する方式です。承認基準を統一でき、設定の一貫性が保たれます。ただし申請が集中すると承認待ちが発生し、配布速度が遅くなります。

部門管理者方式は、各部門に管理者を配置し、部門内の利用申請を部門管理者が承認する方式です。承認待ちが分散され、配布速度が上がります。一方で部門ごとに承認基準がずれるリスクがあります。部門管理者には最低限の設定権限（ユーザー追加・削除のみ）を付与し、機能のオン・オフはIT部門が一元管理する分離設計が必要です。

承認フローは申請・承認・設定反映の3段階を明示します。申請はフォーム提出、承認は上長承認、設定反映はIT部門による管理コンソール操作です。この3段階を文書化し、承認者と設定作業者を分けることで、誰が何を決めたかの記録が残ります。

監査ログで記録する項目を決める

Geminiの利用状況を記録する監査ログは、管理コンソールの監査機能で取得できます。ここで決めるのはどのログを取るかと誰がログを見るかです。

取得するログは、ユーザーのログイン記録・プロンプト送信回数・参照したファイル名の3つが基本です。プロンプトの内容（ユーザーが入力した質問文）は、Google Workspaceの監査ログには記録されません。参照したファイル名は記録されますが、ファイルの中身は記録されません。

ログを見る権限は、監査部門・IT部門・情報セキュリティ部門のいずれかに限定します。ログには利用者の行動履歴が含まれるため、閲覧権限を広く設定すると監視が強くなりすぎます。閲覧権限の付与には社内承認が必要であり、承認されない場合は監査ログを取得しても見る人がいない状態になります。

監査設計は技術的に取得できるかではなくその権限が社内で承認されるかで決まります。Purviewなど高機能な監査ツールを導入しても、監査ロールの付与が承認されなければ、取得したログを誰も見られません。実際に、監査ロールの付与がメール等まで閲覧範囲が及ぶことを理由に承認されず、監査目的の大半を別の管理基盤へ載せ替えたケースがあります。

利用停止基準を決める

Geminiの利用を停止する基準を事前に決めます。停止基準は未使用期間と規約違反の2軸です。

未使用期間による停止は、一定期間ログイン記録がないユーザーのライセンスを回収する方式です。ただし未使用期間を一律に設定すると、低頻度で稼働する業務を停止してしまいます。例えば四半期決算資料の作成や半期レビューなど、3カ月に1回しか使わない業務では、90日間未使用による一律削除は成立しません。実際に、90日間未使用のエージェントを一律削除する基準を設けたが、半年に1回稼働するエージェントが存在するため撤回したケースがあります。

未使用期間の基準を設ける場合は、業務の稼働頻度を先に洗い出し、最も低頻度な業務の周期を基準にします。または未使用期間ではなく、利用者による明示的な利用終了申請を停止の条件にします。

規約違反による停止は、禁止行為を列挙し、違反が確認された時点でライセンスを停止する方式です。禁止行為には、個人情報のプロンプト入力・機密情報の外部共有・業務外利用の3つを含めます。違反の検出は監査ログで行い、違反者への通知と再発防止策の提出を義務付けます。

利用ルールの伝達方法を決める

Geminiの利用ルールをどう伝えるかを決めます。伝達方法は文書配布と研修実施の2つがあります。

文書配布は、利用ルールを1枚のガイドラインにまとめ、ライセンス配布時に添付する方式です。ガイドラインには、禁止行為・データ参照範囲・問い合わせ先の3項目を記載します。文書は読まれない前提で設計し、禁止行為は3項目以内に絞ります。項目が多いと読み飛ばされ、重要な禁止事項が伝わりません。

研修実施は、Gemini配布前に30分程度の説明会を開き、利用ルールと禁止行為を口頭で伝える方式です。研修では実際の画面を見せながら、どの機能がオンでどの機能がオフかを説明します。研修の実施記録を残し、未受講者へはライセンスを配布しない運用にすることで、ルールの周知率を上げられます。

伝達方法は配布範囲の広さで決めます。全社配布の場合は文書配布が現実的であり、部署単位の段階配布では研修実施が可能です。

6項目の決定順序

6項目を決める順序は、配布範囲→データ参照範囲→管理主体→監査ログ→利用停止基準→利用ルールです。この順序を守ることで、後工程の手戻りを防げます。

配布範囲を先に決める理由は、範囲によってデータ参照設計の粒度が変わるためです。全社配布ではドライブ全体の権限を洗い出す必要があり、部署配布では部署内のフォルダのみを対象にできます。データ参照範囲を先に決めると、配布範囲を後から狭めたときに設計のやり直しが発生します。

管理主体を監査ログより先に決める理由は、管理主体によって監査ログの閲覧権限が変わるためです。IT部門一元管理では監査ログもIT部門が見ますが、部門管理者方式では部門管理者にもログ閲覧権限を付与するかを追加で決める必要があります。

利用停止基準を利用ルールより先に決める理由は、停止基準が利用ルールに含まれるためです。利用ルールの文書には「90日間未使用の場合ライセンスを回収します」のように停止基準を記載するため、基準が確定していないとルールを書けません。

検証、決定、手順書の順序を崩すと手戻りが発生します。決定を急がせる前に、検証結果を材料として先に出すことが重要です。