はじめに
わたしたちのチームでは、プロジェクトの成長に伴い、複数のメールグループを一括で作成する必要がありました。Google Workspaceの管理コンソールで1件ずつ手動操作するのは時間がかかり、ヒューマンエラーのリスクも高まります。
そこで、Google Cloud Platform(GCP)とWorkspace APIを活用し、グループの作成からメンバー追加までを完全に自動化しました。本記事では、その実装手順と運用時のポイントを詳しく解説します。
実装の全体像
自動化実装は以下の4つのフェーズで進めます:
-
管理用Google Cloudプロジェクトの作成
- Workspace管理専用のGCPプロジェクトを準備
-
必要なWorkspace APIの有効化とサービスアカウント発行
- Cloud Identity APIやAdmin SDK Directory APIを有効化
- 認証用のサービスアカウントを作成
-
Workspaceでのドメインワイド委任の設定
- サービスアカウントに管理者権限を付与
-
自動化スクリプトの実装と実行
- gcloud CLIを使用したバッチ処理の実装
1. 管理用GCPプロジェクトの作成
まず、Workspace管理タスク専用のGCPプロジェクトを作成します。既存のプロジェクトと分離することで、権限管理やコスト管理が明確になります。
# プロジェクトIDは組織内で一意である必要があります
gcloud projects create admin-automation \
--name="Admin Automation"
# 作成したプロジェクトをデフォルトに設定
gcloud config set project admin-automation
2. APIの有効化とサービスアカウントの準備
2-1. 必要なAPIを有効化
Google Workspaceのグループ管理には、以下の3つのAPIが必要です:
gcloud services enable \
cloudidentity.googleapis.com \ # グループの作成・管理用
admin.googleapis.com \ # Admin SDK Directory API(メンバー管理用)
groupssettings.googleapis.com # グループ設定の管理用
各APIの役割:
- Cloud Identity API: グループの作成、削除、一覧取得
- Admin SDK Directory API: メンバーの追加、削除、ロール管理
- Groups Settings API: グループの詳細設定(外部メンバー許可、投稿権限など)
2-2. サービスアカウントの作成
APIを呼び出すためのサービスアカウントを作成します:
# サービスアカウントを作成
gcloud iam service-accounts create gw-admin-bot \
--display-name="GW Admin Bot"
# 認証用の鍵ファイルを生成
# 本番環境ではSecret Managerの使用を推奨
gcloud iam service-accounts keys create sa-key.json \
--iam-account gw-admin-bot@admin-automation.iam.gserviceaccount.com
⚠️ セキュリティ注意事項: 生成されたsa-key.json
は機密情報です。Gitにコミットせず、適切に管理してください。
2-3. 必要なIAMロールの付与
サービスアカウントに最小限必要なロールを付与します:
目的 | ロール | 説明 |
---|---|---|
API呼び出し許可 | roles/iam.serviceAccountTokenCreator | サービスアカウント自身へのトークン作成権限 |
プロジェクト閲覧 | roles/viewer | プロジェクトリソースの参照権限 |
3. Workspaceでのドメインワイド委任の設定
サービスアカウントがWorkspaceリソースにアクセスするには、管理者によるドメインワイド委任の承認が必要です。
3-1. 管理コンソールでの設定手順
- Google管理コンソール(admin.google.com)にログイン
- [セキュリティ] → [API制御] → [ドメインワイド委任] へ移動
- [新しい委任を追加] をクリック
- クライアントIDに、サービスアカウントのユニークID(数字のID)を入力
- 注意:メールアドレスではなく、サービスアカウントの詳細画面に表示される数字のIDです
3-2. 必要なOAuthスコープの設定
以下のスコープをカンマ区切りで入力します:
https://www.googleapis.com/auth/cloud-identity.groups,
https://www.googleapis.com/auth/cloud-identity.groups.readonly,
https://www.googleapis.com/auth/admin.directory.group,
https://www.googleapis.com/auth/admin.directory.group.member,
https://www.googleapis.com/auth/apps.groups.settings
各スコープの説明:
cloud-identity.groups
: グループの作成・更新・削除cloud-identity.groups.readonly
: グループ情報の読み取りadmin.directory.group
: Admin SDKでのグループ管理admin.directory.group.member
: メンバーシップの管理apps.groups.settings
: グループ設定の変更
3-3. 管理者ロールの付与(推奨)
さらに確実な権限管理のため、サービスアカウントに「グループ管理者」ロールを付与することを推奨します:
- 管理コンソールの [アカウント] → [管理者ロール] へ移動
- 「グループ管理者」ロールを選択
- サービスアカウントのメールアドレスを追加
💡 ポイント: この設定により、UIでも権限が明確になり、トラブルシューティングが容易になります。
4. 自動化スクリプトの実装
4-1. サービスアカウントでの認証
まず、作成したサービスアカウントでgcloud CLIを認証します:
# サービスアカウントキーを使って認証
gcloud auth activate-service-account \
--key-file sa-key.json \
--impersonate-service-account \
gw-admin-bot@admin-automation.iam.gserviceaccount.com
これにより、gcloud identity groups
コマンドがドメインワイド権限で実行可能になります。
4-2. グループ一括作成スクリプト
以下は、わたしたちが実際に使用したスクリプトの改良版です:
#!/usr/bin/env bash
set -euo pipefail # エラー時に停止、未定義変数の使用を防ぐ
# 設定
ORGANIZATION_DOMAIN="example.com"
LOG_FILE="group_creation_$(date +%Y%m%d_%H%M%S).log"
# 作成するグループのリスト
# 実際の運用では外部ファイル(CSV等)から読み込むことを推奨
GROUP_EMAILS=(
"CVAUG006@${ORGANIZATION_DOMAIN}"
"CZMPC007@${ORGANIZATION_DOMAIN}"
# 必要に応じて追加
)
# 初期メンバーリスト
INITIAL_MEMBERS=(
"alice@${ORGANIZATION_DOMAIN}"
"bob@${ORGANIZATION_DOMAIN}"
)
# ログ関数
log() {
echo "[$(date '+%Y-%m-%d %H:%M:%S')] $*" | tee -a "$LOG_FILE"
}
# グループ作成関数
create_group() {
local group_email=$1
local prefix=$(echo "$group_email" | cut -d '@' -f 1)
local display_name="Group: $prefix"
log "INFO: グループ作成開始 - $group_email ($display_name)"
if gcloud identity groups create "$group_email" \
--display-name="$display_name" \
--organization="$ORGANIZATION_DOMAIN" 2>&1 | tee -a "$LOG_FILE"; then
log "SUCCESS: グループ作成完了 - $group_email"
return 0
else
log "ERROR: グループ作成失敗 - $group_email"
return 1
fi
}
# メンバー追加関数
add_members() {
local group_email=$1
shift # 残りの引数はメンバーリスト
local members=("$@")
for member in "${members[@]}"; do
log "INFO: メンバー追加 - $member → $group_email"
if gcloud identity groups memberships add \
--group-email="$group_email" \
--member-email="$member" \
--roles=MEMBER 2>&1 | tee -a "$LOG_FILE"; then
log "SUCCESS: メンバー追加完了 - $member"
else
log "WARNING: メンバー追加失敗 - $member"
fi
done
}
# メイン処理
main() {
log "===== グループ一括作成開始 ====="
local success_count=0
local fail_count=0
for group_email in "${GROUP_EMAILS[@]}"; do
if create_group "$group_email"; then
add_members "$group_email" "${INITIAL_MEMBERS[@]}"
((success_count++))
else
((fail_count++))
fi
log "----------------------------------------"
done
log "===== 処理完了 ====="
log "成功: $success_count グループ"
log "失敗: $fail_count グループ"
log "詳細はログファイルを確認してください: $LOG_FILE"
}
# スクリプト実行
main
4-3. 高度な使用例:CSVからの一括処理
大量のグループを扱う場合は、CSVファイルから読み込む方法が効率的です:
#!/usr/bin/env bash
# groups.csv から読み込む例
# CSV形式: group_email,display_name,initial_members(|区切り)
while IFS=',' read -r group_email display_name members; do
# ヘッダー行をスキップ
[[ "$group_email" == "group_email" ]] && continue
# グループ作成
gcloud identity groups create "$group_email" \
--display-name="$display_name" \
--organization="$ORGANIZATION_DOMAIN"
# メンバーを配列に変換
IFS='|' read -ra member_array <<< "$members"
# 各メンバーを追加
for member in "${member_array[@]}"; do
gcloud identity groups memberships add \
--group-email="$group_email" \
--member-email="$member" \
--roles=MEMBER
done
done < groups.csv
まとめ
Google WorkspaceのグループをAPIで自動化することで、以下のメリットを得ることができました:
得られた効果
-
作業時間の大幅削減
- 手動作業:1グループあたり約3分 → 自動化後:1グループあたり数秒
- 100グループの作成で約5時間の削減
-
ヒューマンエラーの排除
- メールアドレスの入力ミスがゼロに
- メンバー追加漏れの防止
-
運用の標準化
- スクリプトによる処理の統一
- ログによる作業履歴の完全な記録
実装のポイントまとめ
ステップ | 主な作業 | 重要ポイント |
---|---|---|
1. GCPプロジェクト | 管理用プロジェクトの作成 | 既存プロジェクトとの分離で権限管理を明確化 |
2. API有効化 | 3つのAPIを有効化 + サービスアカウント作成 | Cloud Identity APIとAdmin SDK両方が必要 |
3. Workspace連携 | ドメインワイド委任の設定 | クライアントIDを正確に入力(メールではない) |
4. スクリプト実装 | gcloud CLIでバッチ処理 | エラーハンドリングとログ出力を必ず実装 |
今後の展開
この自動化の仕組みは、グループ作成以外にも応用可能です:
- ユーザーアカウントの一括作成
- 組織単位(OU)の管理
- グループポリシーの一括変更
わたしたちのチームでは、この基盤を活用してWorkspace管理の完全自動化を進めています。手作業から解放されることで、より価値の高い業務に集中できるようになりました。
参考リンク

