退職の申し出があった社員について、念のため直近の操作を確認したい。管理コンソールの監査ログを開き、ダウンロードの記録を絞り込む。300件ほどのファイルダウンロードが並ぶ。 ここまでは出ます。
問題はその先です。並んでいるのがどういう性質のファイルなのか、会社の資産なのか本人が作った下書きなのか、社給のPCからなのか私物のスマートフォンからなのか——ここが埋まらないと、「持ち出しがあった」とも「問題なかった」とも言えません。記録はあるのに判断ができない、というのが実際に起きる行き止まりです。
ログが「あるだけ」で終わっていた理由
監査ログは操作の記録です。誰が、いつ、どのファイルに、何をしたか。ここまでは以前から取れていました。足りていなかったのは、その操作に文脈を与える情報です。
たとえばファイルのダウンロード1件を見たとき、調査で本当に知りたいのは次のようなことです。
- そのファイルは共有ドライブのものか、本人のマイドライブのものか
- 所有者は退職予定者自身か、それとも別の部署の誰かか
- 操作した端末は会社が管理している端末か、それとも管理外か
- 同じ時間帯に、同じ端末から他の操作もあったか
これらが分からないまま件数だけを見ると、判断が「多いから怪しい」「少ないから大丈夫」という水準に落ちます。300件のダウンロードは、その人が自分で作った資料をまとめて整理しただけでも起きます。 逆に、他部署が所有する見積書を5件だけ落としているほうが重い場合もあります。
追加された2つの欄
Google Workspace の監査ログとセキュリティ調査ツールに、この文脈を埋める項目が追加されました。2026年3月に告知され、同年春から順次提供されています。
1つめが所有者情報（Owner details）です。 リソースの持ち主を示す情報で、2つの内容から成ります。ひとつは所有者の種別——個人ユーザーなのか、組織なのか、グループなのか、共有ドライブなのか。もうひとつは所有者の識別情報、つまり具体的なIDやメールアドレスです。
これが入ると、先ほどの300件は分解できます。所有者が本人になっているものと、他人・他部署になっているものを分けられるからです。「自分の資料を整理した」と「他部署の資料を集めた」は、ログの上で初めて区別が付くようになりました。
2つめがユーザー端末情報（User device info）です。 操作に使われた端末の情報で、端末ID・OSバージョン・端末の種別などが記録されます。
社給端末と管理外端末の区別が付くのは大きい変化です。エンドポイント管理を入れている組織であれば、記録された端末IDが自社の管理対象に載っているかを突き合わせられます。載っていない端末からの大量ダウンロードは、それだけで優先して見る理由になります。
これらの項目は管理コンソールの調査画面だけでなく、Admin SDK や BigQuery へ書き出されるイベントにも含まれます。 ログを外部の基盤に集約している組織では、既存の集計クエリに欄が増える形になります。
ログだけは、事故が起きてからでは作れない
機能が増えたことより実務上重いのは、この手の情報は遡って生やせないという点です。事故が起きてから「その日の端末情報が見たい」と思っても、記録されていなければ存在しません。
つまり管理者がいま確認すべきなのは、追加された欄の使い方ではなく、その手前の前提です。
| 確認すること | 見落としが起きやすい点 |
|---|---|
| 監査ログの保持期間 | エディションによって異なる。退職者の調査は数か月前まで遡ることがある |
| エンドポイント管理の登録状況 | 端末情報が取れても、自社の管理台帳と突き合わせられなければ判断に使えない |
| ログの書き出し先 | BigQuery 等へ出していない場合、期間を越えた分析はできない |
| 誰がログを見られるか | 調査権限が特定の1人に集中していると、その人が当事者のとき止まる |
いちばん多い見落としは1行目です。「必要になったときに見ればいい」と考えていると、必要になった時点で対象期間が過ぎているという形で効いてきます。退職者の調査は、申し出の数か月前から見たくなることが実際にあります。
4行目も実務では効きます。調査権限を情報システム担当1人が持っている状態は、その人自身の操作を調べる必要が出たときに機能しません。権限の分け方は管理者権限の委任と最小権限で扱っています。アラートを立てて能動的に気づく設計は監査ログとアラートで内部不正に気づくにまとめました。
端末情報が取れることの、別の意味
端末情報は調査のためだけのものではありません。日常的に見ると、想定していない経路が見つかります。
よくあるのが、私物のスマートフォンに会社のアカウントを追加したまま忘れている、というものです。本人に悪気はなく、数年前に一度設定しただけ。しかしそのアカウントは今も生きていて、メールもドライブも見られる状態です。端末の種別とOSバージョンが取れるようになると、この手の「棚卸しに載っていない端末」が浮かびます。
古いOSのまま放置された端末も同様です。OSバージョンが記録されるということは、サポートの切れたOSからアクセスしている端末を一覧にできるということでもあります。攻撃者が狙うのはたいてい、こういう管理の外側に落ちた端末です。ログイン後のセッションを端末に結び付ける仕組みについてはセッションCookieの窃取に効くDBSCを参照してください。
今月やること
調査の手順書を作るより先に、保持期間と書き出し先を1度だけ確認してください。
管理コンソールで自社のエディションと監査ログの保持期間を確認し、その期間が「退職者の調査で遡りたい期間」より短くないかを見ます。短ければ、ログの書き出し先を用意するかエディションを検討するかの判断が必要になります。これは事故が起きる前にしか決められません。
そのうえで、直近1か月のドライブのダウンロード記録を、所有者情報の欄で並べ替えてみてください。自分以外が所有するファイルを多くダウンロードしている人が上位に出ます。ほとんどの場合、それは業務上の正当な理由がある人です。その人たちの顔ぶれを把握しておくことが、いざというときに「いつもと違う」と気づける唯一の基準になります。
情報システムの専任がいない体制で、監査と調査の前提を最低限のところまで整えたい——そうしたご相談は、グリームハブのIT・Google Workspace 無料相談で承っています。要件によって最適な構成は変わるため、個別にお見積りします。お問い合わせからご相談ください。
