情報システム担当のところに、こういう相談が来るようになりました。「営業部で使いたいAIツールがあるんですが、社内のドライブに繋いでいいですか」
判断材料が足りません。そのツールがドライブの何を読むのかは、同意画面の「Google ドライブのすべてのファイルの表示、編集、作成、削除」という一行にまとまってしまっています。営業部が見たいのは提案書のフォルダだけなのに、接続する利用者が人事フォルダや給与関係のスプレッドシートにもアクセスできるなら、それらも対象に入り得ます。OAuth スコープだけで、利用者が持たない社内全体の権限まで得られるわけではありません。一律に却下するだけでは、管理外のアカウントを使う動機も残ります。
この「アプリ単位でしか許可を出せない」という詰まり方が、いま構造として見直されつつあります。
アプリ単位の許可では、エージェントを止められない
Google は2026年7月27日、企業向けセキュリティの新しい枠組みとして Beyond Zero を公開しました。同社が2014年から進めてきた BeyondCorp（社内ネットワークを信用せず、端末と利用者の状態で毎回判断するゼロトラストの実装）の後継にあたる位置づけです。
考え方の中心は、アクセスの判断をアプリケーションの単位から、個々のリソースと操作の単位へ動かすことにあります。Google の一次資料は、画面・API・MCP を含め、特定のリソースに対する操作ごとに認可する考え方を示しています。以下では、この考え方を Workspace の運用に当てはめて考えます。
なぜ単位を細かくする必要が出てきたのか。人の操作にも過剰な権限のリスクはありますが、エージェントは連続した処理を短時間で実行できます。目的を取り違えたまま処理が進めば、利用者が気づく前に多数のファイルへ影響が及ぶ可能性があります。権限が広いほど、誤操作やプロンプトインジェクションが起きた場合の影響範囲も広がります。
Beyond Zero はここに、静的な認可設定と、状況に応じた動的な判断を組み合わせる方向を示しています。誰が何にアクセスできるかという固定のルールに加えて、いまの文脈でその操作を通してよいかを都度判断する層を重ねる形です。
枠組みの話を、来週の実務に落とす
とはいえ、これは大企業のセキュリティ部門に向けた設計思想です。従業員50人の会社の情シス担当が明日から実装できるものではありません。
それでも、対象データ・操作・利用条件を分けて棚卸しすることは、いまの Google Workspace 運用でも始められます。管理コンソールの設定だけで Beyond Zero の継続的な認可モデル全体を実装できる、という意味ではありません。
具体的には、次の3つを分けて決めます。
1. どのデータに届くのか（対象の限定）
AIツールを承認する前に、そのツールが読む範囲を組織側で絞れないかを見ます。共有ドライブを部門ごとに分けてあれば、接続用のアカウントをその共有ドライブだけのメンバーにするという形が取れます。全社員のマイドライブに散らばっている状態では、この絞り込み自体が成立しません。アクセス制御の細かさは、データの置き方の細かさを超えられないというのが実務上の制約です。
2. 何をしてよいのか（操作の限定）
読むだけなのか、書き換えもするのか。OAuth の同意画面で要求されるスコープには、読み取り専用のものと編集を含むものがあります。ここは要求される側ではなく、承認する側が確認する項目です。任意スコープと拒否されたときの振る舞いを整理した記事でも触れましたが、必要以上のスコープを要求してくるツールは、その時点で設計の粗さを疑う材料になります。
3. どの状況なら通すのか（条件の限定）
管理コンソールのコンテキストアウェア アクセスを使うと、端末の状態やIPアドレス、地域といった条件でアクセスの可否を分けられます。ただし、対応エディション、対象アプリ、端末条件の取得方法に制約があります。サードパーティの AI ツールやバックグラウンドの API 処理まで一律に制御できるとは限りません。接続経路ごとの適用範囲を確認し、データ側の権限と組み合わせます。
「繋いでいいか」に答えるための順番
冒頭の相談に戻ります。実際に判断するときは、この順で確認すると詰まりません。
- そのツールは、どの Google アカウントとして社内データに触るのか（個人の権限を借りるのか、専用アカウントか）
- 借りる権限の範囲は、その担当者が普段見ている範囲と同じか、それより広くないか
- 読み取りだけで足りる用途に、編集権限を要求していないか
- 使った記録が後から追えるか
4番が抜けている状態で承認すると、半年後に「あのツールで何を読んだのか」を聞かれたときに答えられません。Workspace 側の監査と調査ツールで何が見えるかを先に確認しておくと、承認するかどうかの判断そのものが変わることがあります。記録が残らない繋ぎ方しかできないツールは、それ自体が判断材料です。
なお、AIツールが社内システムのデータに直接アクセスする構成については、CRM側の権限設計として整理した記事も参考になります。考え方は同じで、「誰の権限を借りているのか」を最初にはっきりさせるところから始まります。
細かくする前に、置き場所を直す
Beyond Zero が示す方向は正しいと思いますが、中小企業でいきなりリソース単位の認可を組もうとすると、たいていその手前で止まります。そもそもデータが、権限を分けられる形で置かれていないからです。
共有ドライブが「全社」ひとつしかない、退職者のマイドライブに重要ファイルが残っている、部門横断のスプレッドシートが個人所有になっている。この状態でアクセス制御だけを精密にしても、実際には何も絞れません。
順番としては、置き場所を部門・機密度で分ける方が先です。そこが済んでいれば、AIツールを繋ぐときの判断は「この共有ドライブだけ」と言い切れる形になります。エージェントの利用が広がるほど、この地味な情報設計が効いてきます。
次にやること
いま社内で使われている、あるいは申請が上がっているAIツールを1つ選んで、上の4項目を書き出してみてください。書けない項目が出たら、そこが承認前に埋めるべき穴です。
全部をいきなり整えようとせず、まず1件を最後まで詰めて、その形を次からの申請の型にするのが現実的です。
社内でのAI利用の権限設計、共有ドライブの再編、Google Workspace の管理設定については、グリームハブの IT・Google Workspace 無料相談で承っています。現在の契約エディションとデータの置き方によって取れる構成が変わるため、お問い合わせから個別にご相談ください。
