- Google Workspaceで外部アプリへの接続を制御する設計の考え方
- OUごとに異なる制御方針を適用する方法
- GASでOAuth申請をSlackに自動通知する仕組みの作り方
- ClaudeのAPIをGASから呼び出して承認判断を自動分析させる実装
ある会社でGWSのAPI制御——つまり、社員が外部アプリにGoogleアカウントを連携させることへの制御——を整備することになった。
目的はシンプルで、野良SaaSへの情報流出・意図しないデータ連携を防ぐことだ。ただ単に「全部禁止」にすれば業務が止まるし、「全部許可」では管理にならない。そこで制御方針を設計し、申請が来たら自動でSlackに通知+ClaudeのAPIで安全性を分析する仕組みまで実装した。この記事はその設計と実装の話だ。
▼背景:GWSのAPI接続が野良状態になっていた
Google AdminのAPI制御画面を開くと、社員が自由に外部サービスへのOAuth連携を行っていた状態が可視化された。ZoomがGmailとDriveにフルアクセスしていたり、用途不明のサードパーティGASがスプレッドシートを読み書きしていたりと、「誰が何を許可したか」が誰にも把握できていない状態だった。
・退職者が使っていた外部サービスがGmailやDriveに接続したままになる
・セキュリティ審査で「外部アプリへのアクセス管理状況を説明してください」と問われても答えられない
・野良GAS(個人Gmailで作成されたスクリプト)が社内のスプレッドシートを読み書きし続ける
▼制御方針の設計
① 最低要件を決める:ログイン情報のみOK
外部アプリがGoogleアカウントに要求するスコープは大きく2種類に分けられる。
| 種別 | スコープ例 | 方針 |
|---|---|---|
| 基本スコープ | openid / email / profile / userinfo.email / userinfo.profile | ✅ 原則許可(Googleログインのみ) |
| 追加スコープ | Gmail / Drive / Calendar / Contacts など | ⚠️ 申請制・個別審査 |
「Googleでログイン」するだけなら基本スコープで完結する。問題になるのは、アプリがGmailを読んだりDriveを書き換えたりできるスコープを要求してくるケースだ。これを申請制にして、1件ずつ審査するという方針にした。
② OUごとに制御を分ける
全社員に同じ制御をかけるのではなく、OUの性質に応じて適用ルールを変えた。
| 対象OU | 制御方針 |
|---|---|
| 正社員・マネージャー等 | 基本スコープは自由に許可。追加スコープは申請制 |
| 業務委託・インターン・サービスアカウント | 基本スコープを含む全アクセスを申請制(より厳格に管理) |
業務委託やサービスアカウントは特に管理が抜けやすいので、こちらは全スコープ申請制にした。
③ 申請が来たらSlackに通知+Claude分析
制御設定を入れるだけでは「申請が来ても誰も気づかない」問題が起きる。なので申請があった瞬間にSlackへ通知し、そのスレッドにClaudeが自動でアプリの概要・リスク・承認判断を投稿する仕組みを作った。
▼仕組みの全体像
Google Admin Reports APIはPush通知(Webhook)に対応していない。そのためGASのトリガーで5分おきに申請を取得するポーリング方式を採用している。最大5分のタイムラグが生じるが、実務上は問題ない。
▼実装:GASのコード解説
設定値
メイン処理:申請の検知と振り分け
ポイント①:スコープ判定
基本スコープだけのアプリ(Googleログインのみ)は通知不要なのでスキップする。追加スコープが1つでも含まれていたら通知対象になる。
ポイント②:重複防止
5分おきに実行するためポーリングするたびに同じ申請が取れてしまう。スプレッドシートに処理済みキーを記録しておき、重複は通知しない設計にした。
ポイント③:Slack通知(スレッドtsを返す)
ポイント④:ClaudeのAPIをGASから呼び出す
▼実際のSlack通知イメージ
申請が来るとこんな形でSlackに通知される。
そのスレッドにClaudeが自動で分析を返してくる。
▼実装でハマったこと
- ▶ Admin Reports APIはeventName=authorizeじゃない:「審査待ち」のイベントはeventName=
requestで取得する。authorizeは承認済みのログ全件が返ってくるので別物 - ▶ Admin SDKはAdmin Reportsと同じサービスに登録できない:GASのサービスにAdmin SDK APIを追加する際、directory_v1とreports_v1は別々に登録しようとするとエラーになる。Reports APIはURLFetchAppで直接叩く方法で解決した
- ▶ Slackのプライベートチャンネルへの投稿にはgroups:historyスコープが必要:パブリックチャンネルとは必要なスコープが異なる
- ▶ スレッドへの返信にはmessage_tsではなくmessage.ts:Slackのペイロード構造が古いattachments形式だとtsの取得パスが変わる
▼まとめ
- ▶ GWSのAPI制御は「全禁止」ではなく「基本スコープはOK・追加スコープは申請制」が現実的
- ▶ OU別に制御の厳しさを変えることで、業務委託・サービスアカウントを厚く管理できる
- ▶ GAS+Admin Reports API+Slack+Claude APIを組み合わせることで、申請通知〜安全性分析までが全自動になる
- ▶ Claudeに「アプリ概要・リスク・判断」を出力させることで、情シス担当者がスコープの意味を1から調べなくてよくなる
📅 30分無料相談、受け付けています
「GWSのAPI制御をどう設計すればいいかわからない」「こういう自動化を自社でも導入したい」——そういった段階からお気軽にどうぞ。
📅 30分無料相談を予約する →