Looker Studio（旧 Data Studio）は Google Workspace ユーザーが追加費用なしで利用できるダッシュボードツールで、GWS（Google Workspace）の監査データと接続することで月次の GWS 監査レポート自動化が実現できます。この記事では、データソース設計から共有設定まで、情シス担当者が判断を迫られるポイントを整理します。
この記事を読んだほうが良い人
- GWS の監査ログを管理コンソールで手作業で確認し、月次レポートを手動でまとめている情シス担当者
- 経営層や上司への利用状況・セキュリティ状況の定期報告を自動化したい人
- BigQuery を使うほどではないが、スプレッドシートだけでは可視化に限界を感じている人
- Looker Studio を GWS 監査に活用できるか判断したい人
Looker Studio が月次 GWS 管理レポートに向いている理由
Looker Studio は Google が提供するビジネスインテリジェンスツールです。Google Workspace のアカウントがあれば Enterprise ライセンス不要・追加費用ゼロで利用できます（Google の公式サービス一覧で確認できます）。GWS の監査データとの相性も高く、Google Sheets や BigQuery を経由してデータを引き込み、グラフ・表・フィルタを組み合わせたダッシュボードを構築できます。
月次報告に向いている最大の理由は、データを更新するだけでダッシュボードが自動的に最新状態になる点です。Excel でグラフを作り直す作業や PDF に書き出してメールで送る手順が不要になり、共有 URL を関係者に渡しておけば誰でも最新情報を参照できます。
月次レポートの作成では、担当者がスプレッドシートを手作業で更新・整形し、グラフを並べ替えて PDF にするだけで半日かかるケースがあります。Looker Studio と GAS（Google Apps Script）を組み合わせると、データ収集と書き出しを GAS が担い、Looker Studio が自動でグラフを描画します。毎月の報告作業を「GAS トリガで自動更新 → URL を送るだけ」に短縮できます。
一方で、Looker Studio は「データを整形して見せる」ツールであり、データ自体を GWS から引き出す仕組みは別途用意する必要があります。その設計判断が本記事の主題です。
データソース選択：Sheets 直接 vs BigQuery 経由
GWS の監査データを Looker Studio に取り込む方法は大きく 2 つあります。どちらを選ぶかによって、構築コストと運用の柔軟性が変わります。
パターン A：GWS Reports API → Google Sheets → Looker Studio
GAS で Reports API を叩き、結果をスプレッドシートに書き出す構成です。BigQuery を契約していなくても動き、GWS 管理者権限があれば今すぐ始められます。GAS のトリガで毎日・週次・月次など任意の頻度で自動更新できます。
適する場面は以下の通りです。
- BigQuery を使っていない、または使い始めていない組織
- 月単位で集計した値（件数・合計）をダッシュボードに出したい
- 100 名規模で月間ログ件数が数万〜数十万件程度
- 情シス担当者 1 名で管理・運用したい
Google Sheets は 1 スプレッドシートあたり最大 1,000 万セルという制約がありますが、月次集計データを書き出す用途なら制限に触れることはまずありません。なお、2026年4月発表のアップデートでさらに拡大が予定されています。100 名規模で 12 か月分の集計データを保持しても、数千行程度に収まります。
パターン B：BigQuery（Cloud Logging エクスポート）→ Looker Studio
GWS の管理コンソールから Cloud Logging へのエクスポートを設定し、BigQuery にストリーミング転送する構成です。リアルタイムに近い更新・複雑なクエリ・大容量ログへの対応が強みです。
適する場面は以下の通りです。
- すでに BigQuery を運用中で、ログ分析の延長としてダッシュボードを追加したい
- セキュリティチームがアドホック分析もできる環境を求めている
- 月間ログ件数が数百万件を超えるような規模
- 任意の期間を遡って詳細分析したい
BigQuery には無料ティア（月あたり 10 GB ストレージ・1 TB クエリが無償）がありますが、導入と運用の複雑さがパターン A より上がる点は考慮が必要です。GCP プロジェクトの管理権限・IAM 設計・エクスポート設定の手間がかかるため、「まず可視化してみたい」フェーズには向きません。
判断の目安
まず Sheets 直接（パターン A）から始めるのが現実的です。月次レポートの用途なら更新頻度は 1 日 1 回以下で十分で、100 名規模であれば Sheets の制限を超えることはほぼありません。分析要件が増えた、セキュリティチームが詳細ログを見たいとなったタイミングで BigQuery への移行を検討するパスを取れます。BigQuery 連携の詳しい構成は「GWS ログを BigQuery で活用する方法」で解説しています。
月次レポートに入れるべき KPI 指標一覧
月次管理レポートで経営層や上司が知りたいのは「組織で GWS が安全に使われているか」というサマリです。細かいログよりも、異常を早期発見できる指標と利用傾向が伝わる指標を中心に設計します。GWS Reports API（Admin SDK Reports API）の applicationName パラメータと対応させています。
利用状況系（GWS の稼働確認）
- アクティブユーザー数（月間ログインが 1 回以上あったアカウント）：
loginアプリケーション。総アカウント数との比率で「使われていないアカウント」の可視化にも使える - Gmail 送受信件数とドメイン内/外の比率：
gmailアプリケーション - Google Drive ファイル作成・共有件数：
driveアプリケーション。外部共有数の推移を折れ線グラフで出すと、情報漏えいリスクを経営層が直感的に把握しやすくなる - Meet 通話数・参加者数：
meetアプリケーション。テレワーク実施率の代理指標としても活用できる
セキュリティ系（異常の早期発見）
- ログイン失敗件数（合計・アカウント別上位 5）：
loginアプリケーション。前月比で急増していれば不正アクセス試行の兆候として調査が必要 - 外部アプリへの OAuth 認証件数（新規認証のみ）：
tokenアプリケーション。承認されていないサービスへのアクセス付与を把握する - 外部共有ファイル数の月次変化（増減傾向）：
driveアプリケーション - 管理者操作ログ件数（設定変更・アカウント作成/停止など）：
adminアプリケーション。想定外の管理操作がないか確認する
アラート系（翌月に対応が必要な事象）
- 新規追加・削除されたアカウント一覧
- パスワードリセット実施件数
- 2 段階認証未設定のアカウント数（スナップショット）
これらすべてを 1 画面に詰め込むより、タブを分けて「経営層向けサマリ」「管理者向け詳細」の 2 段構成にするのが実務で使いやすい形です。経営層には件数の推移と異常の有無だけ伝わればよいので、数値カードと折れ線グラフ中心の 1 ページに絞ります。詳細分析（ユーザー別の上位 10 件など）は管理者向けページに置き、必要なときだけ参照する構成にするとダッシュボードのメンテナンスも楽になります。
GWS Reports API を GAS でスプレッドシートに出力する
Looker Studio のデータソースとなるスプレッドシートを自動更新するための GAS スクリプトです。GAS の詳細設定画面（サービスの追加）から Admin SDK Reports API を有効にした上で利用します。
以下のスクリプトは、前月分のログインアクティビティを取得してログイン失敗件数をユーザー別に集計し、スプレッドシートの指定シートに書き出します。月次レポートの「ログイン失敗件数」列を自動更新する用途に使えます。
/**
* 前月のログイン失敗件数を集計してシートに書き出す
* 事前準備：[サービスを追加] から Admin SDK Reports API を有効化
* 実行アカウント：GWS 管理者権限が必要
*/
function writeLoginFailureSummary() {
const now = new Date();
const firstDayThisMonth = new Date(now.getFullYear(), now.getMonth(), 1);
const firstDayLastMonth = new Date(now.getFullYear(), now.getMonth() - 1, 1);
// RFC 3339 形式に変換
const startTime = firstDayLastMonth.toISOString();
const endTime = firstDayThisMonth.toISOString();
const failureCount = {};
let pageToken = null;
// ページネーションで全件取得
do {
const options = {
maxResults: 1000,
startTime: startTime,
endTime: endTime,
};
if (pageToken) options.pageToken = pageToken;
// userKey='all' で全ユーザー対象、applicationName='login'
const result = AdminReports.Activities.list('all', 'login', options);
const items = result.items || [];
items.forEach(item => {
const email = item.actor?.email || 'unknown';
(item.events || []).forEach(event => {
if (event.name === 'login_failure') {
failureCount[email] = (failureCount[email] || 0) + 1;
}
});
});
pageToken = result.nextPageToken;
} while (pageToken);
// スプレッドシートに書き出し
const ss = SpreadsheetApp.getActiveSpreadsheet();
const sheet = ss.getSheetByName('ログイン失敗集計') || ss.insertSheet('ログイン失敗集計');
sheet.clearContents();
sheet.appendRow(['メールアドレス', 'ログイン失敗件数', '集計月']);
const month = Utilities.formatDate(firstDayLastMonth, 'Asia/Tokyo', 'yyyy-MM');
Object.entries(failureCount)
.sort((a, b) => b[1] - a[1])
.forEach(([email, count]) => sheet.appendRow([email, count, month]));
}
このスクリプトで押さえておくべきポイントが 3 点あります。
ページネーション処理は必須
do...while ループでページネーションを処理しています。Reports API は 1 リクエストあたり最大 1,000 件を返し、件数が多いときは nextPageToken が返ります。トークンがなくなるまでループしないと、取得件数が途中で打ち切られたまま集計が完了してしまいます。
イベント名でフィルタする
login アプリケーションには成功ログインと失敗ログインが混在するため、イベント名 login_failure で絞り込みが必要です。イベント名の一覧は Admin SDK Reports API の公式リファレンスで確認できます。Drive や Token など他のアプリケーションも同様に、イベント名ベースのフィルタが集計精度の鍵になります。
トリガと実行権限の設定
GAS の時間主導型トリガを「月の最初の月曜日・午前 6 時」などに設定しておくと、毎月自動でシートが更新されます。GAS の 1 回あたり実行時間上限は 6 分なので、大規模なログを取得する場合は月次実行を複数回に分割するか、取得範囲を週単位に区切ってシートに追記する方式を検討します。
AdminReports.Activities.list の呼び出しには Reports API の有効化と、実行アカウントへの GWS 管理者権限が必要です。サービスアカウントで実行する場合は Domain-Wide Delegation（ドメイン全体の委任）の設定が別途必要になります。
Looker Studio ダッシュボードの共有とアクセス制限
Looker Studio のダッシュボードは URL 共有が基本で、閲覧者は Looker Studio アカウントがなくても参照できます。ただし、会社の監査データを含む以上、共有範囲のコントロールは必要です。
共有レベルの設計
経営層・上司への月次報告用ダッシュボードは、GWS の組織ドメイン（@yourdomain.com）にいる全員に閲覧権限を与える設定がシンプルです。ドメイン外への共有はオフにします。特定の管理職だけに見せたい場合は Google グループに共有する方法が管理しやすく、人事異動でグループメンバーを変えるだけでダッシュボードの共有設定を変える必要がなくなります。
データソース（スプレッドシート）のアクセス制限
ダッシュボードに閲覧権限があっても、接続先のスプレッドシートへの直接アクセスは別の設定で制御されます。生データを含むスプレッドシートを情シス担当者だけに閲覧制限したい場合は、データソースの「認証情報の種類」を「所有者の認証情報を使用」に設定します。この設定により、ダッシュボードは閲覧者の権限ではなくオーナー（情シス担当者）の権限でデータを取得するため、スプレッドシート自体を非公開のまま表示できます。
「所有者の認証情報を使用」設定を外した状態（閲覧者の認証情報）では、スプレッドシートの閲覧権限がないユーザーはダッシュボードを開いてもデータが表示されません。意図せず「見えるはずのユーザーが見えない」状態になることがあるため、設定後は経営層のアカウントでの動作確認が必要です。
編集権限の絞り込み
Looker Studio でダッシュボードの「編集者」権限を持つユーザーは、接続先データソースの詳細（フィールド名・クエリなど）にアクセスできます。編集権限は情シス担当者や承認されたメンバーだけに絞り、関係者には「閲覧者」権限のみを付与するのが適切です。ダッシュボードは情シス側で管理し、関係者はあくまで閲覧専用という役割分担を最初から設計しておくと、後から権限を絞る手間が省けます。
まとめ：何から始めるか
月次管理レポートを Looker Studio で自動化するときの取り組み順序を整理します。
最初の 1 週間は Reports API から何のデータを取るかを決め、GAS でスプレッドシートに書き出す仕組みを作ります。このフェーズで「API の有効化 → 実行アカウントの権限確認 → 取得データの内容確認」を済ませます。スプレッドシートが安定して更新できることを確認してから、Looker Studio でダッシュボードを組み始めます。
次の 1 週間でダッシュボードの初期版を作ります。経営層向けのサマリページ（アクティブユーザー数・ログイン失敗件数・外部共有ファイル数の推移グラフ）だけ先に完成させ、関係者にレビューを依頼します。フィードバックを受けて管理者向け詳細ページを追加する順序のほうが、最初から作り込むより現場ニーズに合った形に収まります。
BigQuery は最初から必要ありません。月次レポートの用途であればスプレッドシート経由で十分カバーできます。「もっと詳しく分析したい」「リアルタイム性を上げたい」となったタイミングで BigQuery に移行する判断をするのが、導入コストと保守コストのバランスが取れた進め方です。
自動化が完了すると、毎月の報告が「GAS トリガが動く → URL を送るだけ」で完了する状態になります。手作業でスプレッドシートを整形していた時間を、より本質的な分析や改善提案に充てられます。それが、この構成を選ぶ一番の理由です。
コーポレートITのご相談はお気軽に
この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。 「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。
御社の IT 部門、ここにあります。
「ITのことはあまりわからない」── そのような状態からで、まったく問題ございません。まずはお気軽にご相談ください。