どこまでわかる？Gemini Notebookの監査ログ入門

なぜ監査ログが必要なのか？

そもそも、なぜ監査ログが必要なのでしょうか。目的は大きく二つあります。一つは、情報漏洩などのトラブルが起きたとき、あるいはその疑いがあるときに、何が起きたのかを事実に基づいて調べることです。もう一つは、日頃から利用状況を把握し、社内ルールどおりに運用されているかを確かめることです。

現場の利便性重視の運用ではガイドラインだけでは不十分

Gemini Notebookで社外共有ができるようになった今、現場から社外共有を許可してほしいという要望が出ることは十分に考えられます。しかし、共有を許可する際に、ガイドラインを整備し、ルールの順守を現場に求めるだけでは、リスクへの対策として十分とはいえません。

人の確認や判断に頼る運用では、意図しない共有や想定外の使い方を完全に防ぐことは難しいためです。また、Google Workspace版のGemini NotebookではAPIが公開されていないため、APIを使って共有状況を確認したり、共有設定を制御したりする仕組みを構築できません。こうした制約も踏まえて、社外共有を認める範囲や確認の手順を検討する必要があります。

情報セキュリティにおける「責任追及性」の担保には監査ログが必要

万一の際に、誰が、いつ、どのような操作をしたのかを調査できなければ、影響範囲を特定することも、再発防止策を考えることもできません。例えば、社内資料を追加したノートブックが社外の相手に共有されたとします。

この場合、誰がいつその資料を追加したのか、誰がいつ共有設定を変更したのかを、それぞれ確認する必要があります。さらに、共有相手に付与されたのが閲覧権限なのか編集権限なのかによって、影響の大きさも変わってきます。

企業にとって必要な情報セキュリティには、機密性・完全性・可用性を中心に7つの要素が存在しますが、監査ログはその中の一つである「責任追及性」を担保するものになります。

監査ログはどこから確認できる？

Gemini Notebookの監査ログは、管理コンソールの［レポート］→［監査と調査］→［Gemini Notebookのログイベント］から確認可能です。

監査ログ閲覧のために必要な権限は？

本機能を利用するためには「監査と調査」の権限が必要です。具体的に、検索と閲覧を任せる場合は、特権管理者が次の設定を行います。

1. 管理コンソールの ［アカウント］→［管理者ロール］ を開く。
2. カスタムロールを作成するか、既存のロールを編集する。
3. 権限の ［サービス］→［セキュリティ センター］→［監査と調査］→［表示］ を有効にする。
4. そのロールを担当者に割り当てる。

検索・閲覧だけであれば［管理］権限は不要です。

監査ログで確認できるユーザー操作

監査ログで確認できるGemini Notebookに対するユーザー操作は以下の通りです。権限変更だけでなく、ノートブックやソース、Studio生成物の操作まで、管理者は追跡することができます。

• Studioアーティファクト(成果物)
  • エクスポート
  • 再生成
  • 削除
  • 生成
  • 表示
  • 名前変更
• ソース
  • 削除
  • 追加
  • 表示
  • 名前変更
  • ソース検出の発生(※3)
• チャットメッセージの交換(※4)
• ノートブック
  • 作成
  • 削除
  • 表示
  • 名前変更
• 共有権限の更新
• 公開設定の更新

※3 ノートブックに追加する資料を探す場合のソース探索機能を利用した場合に記録するイベントです。

※4「メッセージの送信」は、ノートブックのチャット欄でユーザーがGeminiに質問やメッセージを送ったことを記録するイベントです。

監査ログに記録される項目

前章では、監査ログでどのようなユーザー操作を追跡できるのかを整理しました。本章では、一つひとつのログにどのような情報が記録されているのかを整理します。具体的には以下表の項目がログとして記録されます。

これらの項目を組み合わせて見ることで、一つの操作を「誰が、いつ、何を、どうしたか」という形で確認できるようになります。例えば共有設定の変更であれば、実行者と日時に加えて、共有相手や変更前後の公開範囲までそろえて確認することで、社外への共有がいつ、どの範囲で行われたのかを把握できます。

なお、記録される項目はイベントによって異なり、すべての項目に必ず値が入るわけではありません。ソース情報と共有情報の詳しい見方は、この後で順に解説します。確認できる属性には、操作したユーザー、日時、IPアドレス、関連リソースなどがあります。ただし、すべての属性がすべてのイベントで表示されるわけではありません。

IPアドレスに関する注意点

また、IPアドレスにはVPNやプロキシのアドレスが記録される場合があります。このため、IPアドレスだけで利用者の物理的な所在地を断定するのは避けたほうが良いです。イベントの種類や対象リソースなど、複数の情報を照合するための項目として扱うとよいでしょう。

ログのフィルタリング方法

初期状態では過去7日間のイベントが表示されます。期間やイベントなどの条件を指定して検索します。

初めて確認する際は、対象期間や調べたい操作を絞ると、結果を読みやすくなります。権限付与に関する操作ログを確認したいのであれば共有に関するイベント、資料の追加であればソースに関するイベント、というように、確認したい事実から検索条件を考えます。

チャットの会話本文は記録されない

これは監査ログを理解するうえで大きなポイントです。チャットの送信が記録されていれば、送信という操作があったことを調査できます。しかし、その記録から、どの機密情報を入力したか、回答にどのような文章が含まれていたかまで判定することができません。

なお、Google Cloud側のGemini Notebook Enterpriseには、プロンプトやグラウンディング情報を含むリクエスト・レスポンスデータをCloud Loggingに保存する、利用監査の設定が別途あります。有効化や閲覧に必要な権限も定められており、機密データがログから除外されない点も明記されています。

同じGemini Notebookという名称が含まれていても、Workspace管理コンソールの監査と、Cloud側のEnterpriseの利用監査では、参照している仕組みが異なります。仕様を調べる際は、利用しているサービスと管理画面をそろえて確認してください。

監査ログの保管期間には注意が必要

Gemini Notebookの監査ログの保管期間は6か月です。ノートブックの作成や共有権限の変更などを確認できますが、過去の操作をいつまでもさかのぼれるわけではありません。また、管理者がこの保管期間を変更することもできません。社内規定で1年以上のログ保管が必要な場合は、管理コンソールで確認できる期間だけでは不足します。

長期保管が必要な場合は、期限を迎える前にログを外部へ保存する運用を検討しましょう。Gemini Notebookのログイベントは、検索結果をCSVやGoogle スプレッドシートにエクスポートできます。ただし、監査と調査のツールでは、一度にエクスポートできる検索結果は最大10万行です。操作件数が多い場合は、期間を分けて取得するなどの対応が必要です。

導入時には、ログの確認担当者だけでなく、保存する頻度や保存先、必要な保管年数まで決めておくことをおすすめします。問題が起きてから調べようとしても、必要な記録が保管期限を過ぎていれば、管理コンソールでは確認できません。

ログの永続化にはBigQueryを活用する

管理画面での確認に加えて、監査ログをBigQueryへエクスポートする方法もあります(※5)。ただし、監査ログの提供開始に関する案内では、管理コンソールでの利用はデフォルトで提供される一方、BigQueryへの出力は有効化するまで無効な状態になっています。

BigQueryへの出力を利用する場合は、対応エディションの確認に加えて、Google Cloudプロジェクトや権限、課金の設定が必要です。ログイベントの出力には費用が発生し、課金が有効になっていないサンドボックスのプロジェクトにはログデータが出力されません。

保存したログは、SQLを使って検索・集計できます。たとえば、ノートブックの所有者ごとにソースの追加件数や成果物の生成件数を集計し、利用状況を確認できます。保管先として用意するだけでなく、監査や利用実態の把握にも役立てましょう。

また、公開スキーマは更新される場合があります。追加されたフィールドを調べる際は、テンプレート更新後に生成された日次テーブルを参照する必要があるため、分析に使う期間と項目の対応も確認してください。

※5 BigQueryへのエクスポート方法についてはコチラの記事をご参考ください。

共有の変更は「変更前」と「変更後」を分けて見る

企業の情報セキュリティの観点では、共有に関する記録は特に確認したい部分です。Gemini Notebookの監査ログをBigQueryにエクスポートした上で、共有ログを確認する場合のポイントについて説明します。

BigQueryにエキスポートした場合のログテーブルのスキーマには、共有相手を示すrecipient、付与または削除されたアクセスの種類を示すrecipient_access_type、変更前の公開範囲を示すprior_visibility、変更後の公開範囲を示すvisibilityがあります。アクセスの種類は、閲覧、編集、アクセス削除に区分されています。

ここで、公開範囲の「名称」は正確に理解しておく必要があります。privateは所有者だけがアクセスできる状態、shared_internallyは所有者の組織内のユーザーに共有されている状態です。また、anyone_with_linkはリンクを知っている人がアクセスできる状態で、publicは誰でもノートブックを発見できる状態として定義されています。外部共有についても、通常の外部共有と信頼済みドメインへの共有が区別されています。

そのため、共有の調査では、変更後の状態だけを抜き出すよりも、どの状態から変わったかを併せて見ることをおすすめします。共有相手、権限の種類、変更前後の公開範囲をそろえることで、その操作について説明しやすくなります。

一方で、アクセスできる状態になったことと、相手が実際に閲覧したことは、別の確認事項です。共有設定の変更を確認した段階では、まずアクセス範囲が変わった事実として整理し、閲覧については対応する操作記録を調べる必要があります。

監査ログを説明できる運用にする

監査ログは、トラブル時の調査だけでなく、日々の安全な運用の土台にもなります。まずは、共有設定の変更、ソースの追加、生成物のエクスポートなど、目的ごとに確認手順を決めておきましょう。万一の際も「誰が、いつ、何をしたか」をすばやく確認することができます。

さらに、社外共有や公開範囲の変更を定期的に確認すれば、意図しない共有を早期に発見できます。監査ログの取得については管理コンソールのAPIが公開されているため、ログ収集の自動化も可能です。

ログを可視化することで見えてくる利用実態は、ルールの見直しにも役立ちます。一律に禁止するのではなく、必要な共有は認めたうえで、注意すべき使い方にだけ対策を打てるようになります。「何かあっても確認できる」状態があるからこそ、便利な機能を安心して現場に開放できるようになります。最初から完璧を目指す必要はありません。まずは管理コンソールで記録を確認し、調査目的、確認頻度、担当者、保存期間を決めるところから始めましょう。