情報システム部が Google Workspace の監査ログを n8n で毎日取り込み、権限の付与・大量の書き出し・時間外のログインを申請と照らして判定し、担当に知らせる

処理の起点を決める

毎朝7時の定時実行です。 Google の管理ヘルプでは、管理者の操作・ドライブ・ログインのログはほぼリアルタイム（数分）で反映されるとされています。前日分を朝に取れば、取りこぼしはまず出ません。 ただし、ユーザーアカウントのイベントは数十分、トークンのイベントは数時間かかるとされるので、この2つを足すときは取る範囲を前々日まで広げます。

n8n の Schedule Trigger は、ワークフローのタイムゾーンが無ければインスタンスのタイムゾーンを使い、自分で立てた n8n の既定は America/New York です。 ワークフローの設定で Asia/Tokyo にしないと、「前日」の範囲が半日ずれます。Schedule Trigger はワークフローを公開（publish）して初めて動きます。

urgent を待てない操作（特権管理者の付与など）は、毎朝ではなく15分ごとの別のワークフローで拾います。判定の仕組みは同じで、取る範囲だけが違います。

入力データを集める

質を決めるのは、下の3つです。 平常値が無ければ「300件のダウンロード」が多いのか普段どおりかが分かりません。申請と予定が無ければ、AIは判定の根拠を持てず、すべてが confirm になります。

データの取得方法を決める

n8n の Google の資格情報は、サービスアカウントにして「Impersonate a User」で管理者になりすまします。 これにはドメイン全体の委任を特権管理者が有効にする必要があり、反映には5分から24時間かかるとされています。HTTP Request ノードで使うので「Set up for use in HTTP Request node」を有効にし、スコープに https://www.googleapis.com/auth/admin.reports.audit.readonly を入れます。

ページ送りを忘れると、多い日ほど候補が消えます。 1ページの既定は1000件で、残りは nextPageToken で取ります。ダウンロードがいちばん多い月末の日に、1000件で切れて肝心の大量のダウンロードが落ちます。

filters で絞るときは、パラメータの名前の誤りに気をつけます。 filters はイベントのパラメータを ==・<> などで比べる書き方ですが、公式ページによると、API は無効なパラメータを無視し、残りの有効なパラメータで結果を返します。 名前を1文字誤ると、エラーにならずに絞り込みだけが外れます。また、同じパラメータを2回書くと最後の値だけが使われます。この構成では filters を使わず全件を取り、Code ノードで絞ります。 取る件数は増えますが、何で絞ったかがワークフローの中に残ります。

ドメイン全体の委任には注意があります。 n8n の公式ページも、Google がドメイン全体の委任を避けるよう勧めていること、どのユーザーにもなりすませる危険があることを書いています。委任するスコープは監査ログの読み取りの1つだけにします。

AIへ渡す前に整形する

1. 人ごとにまとめる … 3つのログを actor.email（操作した人）でまとめ、同じ日の候補を1つの束にする
2. 規則で候補を拾う … 次の表の規則に当たったものだけを残す
3. 平常値を付ける … ダウンロード数に、その人の過去30日の中央値を並べる
4. 申請と予定を引く … 候補の人の、前後7日の申請と予定だけを取る
5. 文書の名前を伏せる … doc_title は判定に要らないので外し、件数と文書の種類だけを渡す
6. 重なりの印を付ける … 同じ人に2種類以上の候補があれば multi_signal: true

大量のダウンロードを「件数」と「本人の中央値の何倍か」の両方で拾うのは、人によって普段の量が違うからです。 経理や営業企画は月末に数百件を書き出すのが普段どおりで、件数だけで拾うと毎月同じ人が並びます。逆に倍率だけだと、普段1件の人が5件書き出しただけで候補になります。両方に当たったものだけを残すと、候補の数が落ち着きます。 閾値は最初の1か月の候補の数を見て直します。

5番目の「名前を伏せる」は、判定に要らないものを渡さないためです。 文書の名前には顧客名や人事の情報が入ります。件数と種類で判定でき、名前が要るのは担当者が調べる段です。

AIに処理させる

させるのは、候補の束1つずつについて、申請と予定に照らして3段階のどれかに判定し、理由と根拠を書くことです。

urgent の条件は、AIに考えさせず指示に書き切ります。 「重大そうなら urgent」と書くと、判定が日によって揺れます。AIの役目は、条件に当たるかどうかを、申請と予定の文面から読むことです。

指示内容を固定する

あなたは情報システム部で、Google Workspace の監査ログから拾った操作について、
確認が要るかを判定する立場です。下の【候補】【申請】【予定】だけを見て判定してください。

【判定の選び方】
- expected … 候補の操作が、申請の「対象の人」「権限・データの種類」「期間」のすべてに当てはまる。
              または、予定にある締め・障害の対応・移行作業の時間帯と重なる。
- urgent ..... 次のどちらかに当たる。
              1. multi_signal が true で、権限の付与と、大量のダウンロードまたは外部への公開が
                 同じ日にあり、どれにも当てはまる申請が無い。
              2. suspicious_login の後に、権限の付与・大量のダウンロード・外部への公開がある。
- confirm .... 上のどちらでもない。

【厳守事項】
- 申請や予定に書かれていないことを根拠にしないでください。
  「月末なので書き出しは自然」「管理者なのでありうる」などの推測で expected にしないでください。
- 申請があっても、対象の人・種類・期間のどれかが合わなければ expected にしないでください。
  合わなかった項目を mismatch に書いてください。
- 根拠にした申請番号と予定の名前を、そのまま写してください。
- 「不正」「漏えい」「違反」という言葉を使わないでください。判定するのは確認が要るかだけです。
- confirm のときは、本人に尋ねる文面を2文で書いてください。
  何の操作について、何を教えてほしいかだけを書き、疑っていると受け取られる言葉を使わないでください。
- 迷ったときは confirm を選んでください。

【候補】{signals}
【申請】{requests}
【予定】{schedules}

「推測で expected にしない」を具体例付きで書くのが要点です。 何も言わないと、AIは「月末の締めの時期のため、書き出しは業務上自然と考えられる」と書いて expected にします。それらしい理由ほど、担当者は読み飛ばします。

「迷ったら confirm」も同じ理由です。 expected に倒れると担当者の目から外れ、urgent に倒れると通知が増えて読まれなくなります。真ん中に寄せて、人が読む範囲に残します。

出力形式を固定する

{
  "date": "2026-10-28",
  "actor": "[email protected]",
  "signals": ["role_assigned", "bulk_download"],
  "multi_signal": true,
  "verdict": "expected | confirm | urgent",
  "matched_request": "REQ-1234",
  "matched_schedule": "",
  "mismatch": ["期間"],
  "reason": "",
  "confirm_message": ""
}

1つ目の理由は、signals と verdict を分けて持てることです。 何を拾ったかは規則の側が埋め、AIは verdict と理由だけを書きます。規則を変えても、判定の指示は直さずに済みます。

2つ目は、matched_request と mismatch で、担当者が申請を開かずに済むことです。 「REQ-1234 に当たるが期間が合わない」と分かれば、確認は申請者に1行尋ねるだけです。

3つ目は、reason の後ろで Slack の文面を組み立てられることです。 通知は「誰が・何を・判定・根拠」の4行に決めておき、長い理由は Data Table に残して、通知には載せません。

システムへ連携する

Google Workspace には書き込みません。 権限を外す、アカウントを止める、共有を解除する操作は、担当者が管理コンソールで行います。この構成のサービスアカウントに、その権限を持たせません。

人が確認する

1. urgent を朝いちばんに開く … ログの原文（管理コンソール）で、操作の時刻・IP アドレス・対象の文書を確かめる
2. confirm は、文面を直して本人に送る … 送る前に、自分の知っている事情で説明がつかないかを考える
3. expected は一覧で流し見る … 根拠の申請番号が付いているかだけを見る
4. 結論を残す … 「申請どおりだった」「申請の漏れだった」「調査に回した」のどれかと、判定を覆したか

urgent を開いて説明がつかなければ、その場で情報システム部の責任者に上げます。 権限を外すか、セッションを切るかは、責任者が原文を見て決めます。本人に先に尋ねるかどうかも、責任者が決めます。 urgent の束では、本人に尋ねることで証跡が消されるおそれがあるためです。

3番目で根拠の無い expected があれば、それは指示の不具合です。 申請番号も予定も空のまま expected が出ていたら、その日のうちに指示を直します。

目標は、200件をならして1件6分です。 expected は数十秒、confirm は数分、urgent は30分以上かかることもあります。

例外に対処する

1行目と4行目で、判定を「出さない」か「すべて confirm」にするのは、黙って expected を出さないためです。 材料が欠けた日の判定がいちばん危うく、欠けたことを通知に書けば、担当者が自分で見ます。

記録を残す

• 取った監査ログの範囲（startTime・endTime）と、アプリごとの件数・ページ数
• 拾った候補と、当たった規則
• AIに渡した申請・予定と、判定・理由・根拠
• 担当者の結論と、判定を覆した記録
• 本人に送った確認の文面と、返事
• 規則の閾値を変えた日と変えた内容

1行目の件数を残すのは、取りこぼしに気づくためです。 ある日のドライブの件数が平常の1割なら、操作が少なかったのではなく、取れていない可能性が高いと分かります。

Google の管理ヘルプでは、監査ログの多くは6か月保持とされています。 調べ直しに要る期間がそれより長いなら、取ったログの原文を自社の保管先にも残します。