1. Gemini Sparkで実際にできたアクセス権監査
今回の検証では、Gemini Sparkへ「Google Drive内の各ファイルについて、誰にどの権限が付いているかを取得して整理する」と依頼し、アクセス権の一覧を作成できました。人が共有ダイアログを順番に開く作業を、ファイル探索、権限情報の取得、表形式への整形という一つの流れにまとめた実例です。
Googleの公式ヘルプでは、SparkはDriveのファイル検索、内容の読み取り、メタデータ確認、最近使った文書の確認に加え、Sheetsの作成・編集ができると案内されています。今回のような棚卸しは、Google Workspaceのアプリ連携と、複数工程を進めるTaskを組み合わせる使い方です。
- Step 01対象Driveと範囲を指定
- Step 02ファイル一覧を取得
- Step 03共有相手・権限を展開
- Step 04監査用Sheetへ整理
- Step 05要注意設定を抽出
ファイル一覧と権限一覧を分けず、「1ファイル×1権限」の行へ展開すると確認しやすくなります。
2. 監査表に入れる項目
監査表は、一つのファイルに複数の共有相手がいる場合、相手ごとに行を分けます。ファイル名だけの一覧では「誰が編集できるのか」を絞り込めません。最低限、ファイル名、URL、保存場所、オーナー、権限対象、対象種別、権限レベル、直接付与か継承か、確認結果を用意します。
| 列 | 記録内容 | 監査で分かること |
|---|---|---|
| ファイル | 名前、URL、種類、保存場所 | 対象と親フォルダを特定 |
| 権限対象 | ユーザー、グループ、ドメイン、全員 | 誰に公開されているか |
| 権限 | オーナー、編集、コメント、閲覧 | 操作できる範囲 |
| 付与経路 | 直接付与、親・共有Driveから継承 | どこを直すべきか |
| 判定 | 社内、社外、公開、要確認 | 対応の優先順位 |
Drive APIでは権限対象をuser・group・domain・anyone、役割をowner・organizer・fileOrganizer・writer・commenter・readerなどで表します。また共有Driveでは、上位から継承した権限かどうかも確認できます。この情報を日本語の表示名へ置き換えると、非エンジニアでも判断しやすい台帳になります。
3. そのまま使える指示テンプレート
権限変更を伴わないよう、目的と禁止操作を最初に明示します。さらに「すべて確認して」だけで終わらせず、対象、列、完了条件、エラー時の扱いまで指定することが重要です。
Google Driveのアクセス権を読み取り専用で監査してください。
対象：現在のアカウントでアクセスできるマイドライブと指定した共有ドライブ
除外：ゴミ箱内のファイル
1. ファイルとフォルダを列挙する
2. 各項目の共有相手と権限を取得する
3. 1ファイル×1権限を1行としてGoogleスプレッドシートへ整理する
4. 列は、ファイル名、URL、種類、保存場所、オーナー、共有相手、
対象種別、権限、直接付与・継承、外部共有判定、確認メモとする
5. 「全員」「組織ドメイン」「社外ユーザー」「編集以上」を別シートへ抽出する
6. 最後に、取得ファイル数、権限行数、取得失敗数、未処理範囲を報告する
禁止：共有設定の変更、通知、ファイルの移動・改名・削除、既存データの上書き
取得できない項目は推測せず「取得不可」と記録してください。最初はテスト用フォルダで試し、期待した列と判定が出るか確認します。その後、対象をマイドライブ、共有Driveの順に広げます。作業手順を再利用するならTaskとSkillを分けて設計し、列定義や判定基準をSkillへ保存すると、次回も同じ形式で監査できます。
4. 監査結果から優先確認する共有設定
一覧を作るだけでは改善につながりません。最初に確認したいのは、リンクを知っている全員または一般公開、社外ドメイン、編集権限、不要になったユーザー・グループです。特に契約書、顧客情報、人事、請求に関するフォルダは、閲覧権限でも対象者が適切かを確認します。
| 優先度 | 検出条件 | 人が確認する内容 |
|---|---|---|
| 高 | anyone・一般公開 | 公開が業務上必要か |
| 高 | 社外ユーザーの編集権限 | 契約・案件が継続中か |
| 中 | 個人への直接付与 | グループ管理へ置き換えられるか |
| 中 | 親フォルダからの継承 | 上位フォルダの共有範囲が適切か |
| 確認 | 取得不可・所有者不明 | 権限不足か処理漏れか |
MIRAINAの視点では、AIに権限を一括変更させるのではなく、AIは検出と整理、人は業務上の必要性の判断を担当する形が安全です。まず要注意候補を抽出し、ファイルの責任者へ確認してから変更します。監査表には「対応要否」「確認者」「確認日」「対応期限」を追加すると、棚卸しが実務の改善タスクへ変わります。
5. 漏れと情報流出を防ぐ注意点
第一に、Sparkが確認できる範囲は接続アカウントのアクセス範囲に依存します。Googleは、Geminiが利用者と同じWorkspaceデータのアクセス条件に従い、管理者設定やファイル所有者の制限によってはDriveファイルを利用できない場合があると説明しています。個人の結果を、会社全体の完全な監査結果とみなさないでください。
第二に、全件性を件数で照合します。Drive APIのファイル一覧と共有Driveの権限一覧はページ分割される場合があるため、取得件数、次ページの処理、失敗件数、未処理範囲を完了報告に含めます。ファイル数が多い場合は共有Drive単位、部署フォルダ単位に分割します。
第三に、監査表自体を厳重に扱います。共有相手の氏名、メールアドレス、フォルダ名は機密情報になり得ます。出力先を限定し、外部共有しない、記事やチャットへ実データを貼らない、不要になった監査表を保管ルールに従って削除する、といった運用が必要です。Sparkは開発途上の機能であり、重要な処理では進行状況と結果を人が確認します。
6. まとめ
今回の実例では、Gemini SparkでGoogle Drive内のファイルと共有相手・権限を整理し、アクセス権監査を効率化できました。再現のポイントは、1ファイル×1権限で表を作ること、読み取り専用を明示すること、外部共有・公開・編集権限を別途抽出すること、最後に件数と未処理範囲を照合することです。
AIは「探す・展開する・分類する」を支援できますが、アクセスが本当に必要かという判断は業務責任者が行います。まず小さなテストフォルダで試し、正確性と安全性を確認してから対象範囲を広げてください。
MIRAINAのGemini Spark活用研修は、1回90〜120分・5万円です。自社のDrive構成を想定し、アクセス権監査を含むTask、Skills、確認ルールを安全に設計します。
