Google Workspaceのドメイン全体の委任管理｜サービスアカウント・APIスコープ・廃止を見直す方法
Google Workspaceと外部のSaaSや社内システムをAPIでつなぐとき、ユーザーが画面で同意するOAuthだけでなく、管理者がサービスアカウントやOAuthクライアントにドメイン全体の権限委任を許可する構成があります。これは、アプリケーションがドメイン内のユーザーに代わってGoogle APIを呼び出すための仕組みです。便利な一方で、1つのクライアントIDに広いスコープを残すと、担当者の異動や連携終了後も不要なアクセス経路が残りやすくなります。
安全に運用する要点は、ドメイン全体の委任を「設定したかどうか」だけで管理せず、クライアントID、サービスアカウント、実際に偽装するユーザー、OAuthスコープ、所有者、利用目的、最終利用日、承認記録を1行の管理台帳へ対応付けることです。ここで記録するユーザーはアプリケーションの実行時に指定される対象であり、管理者がドメイン全体の委任に固定のユーザー一覧を登録するという意味ではありません。変更時はスコープを必要最小限にし、実際の利用を確認してから継続・縮小・削除を判断します。削除後に依存アプリが止まる可能性や、設定変更の反映に時間がかかることも記録しておきます。
人やグループがファイルへアクセスする権限設計は、Google Workspaceのグループを権限管理のハブにする方法と論点が重なります。ただし、ドメイン全体の委任は人の共有設定ではなく、管理者が承認したAPIクライアントがユーザーに代わって処理する経路です。ここでは、管理者が棚卸しと廃止判断を行うための記録方法に絞ります。
図はGoogleが定める一律の社内手順ではありません。公式ヘルプにあるクライアントID・スコープの管理、定期的なサービスアカウント確認、不要なクライアントの削除という要素を、社内で再現できる点検順に並べたものです。スコープと実際に偽装するユーザーは別々の管理項目として記録し、図の矢印だけから権限範囲を判断しないでください。
委任のスコープとアプリ側の対象ユーザー設定を分けて記録することが、権限の誤認を防ぐ出発点です。
本記事のポイント
- ドメイン全体の委任は、サービスアカウントなどのアプリケーションがユーザーに代わってWorkspace APIを呼ぶため、クライアント単位の管理が必要です。
- 棚卸しではクライアントID・偽装対象ユーザー・OAuthスコープ・所有者・用途・最終利用日を一つの台帳へ対応付けます。
- 変更や廃止は依存アプリと承認経路を確認し、スコープ縮小・削除後の動作と反映時間まで記録して完了とします。
1. ドメイン全体の委任は何を許可する設定か
Googleの公式説明では、サービスアカウントは個人ユーザーではなくアプリケーションに属するアカウントです。サーバー間の処理では、ユーザーが毎回同意画面を操作しなくても、アプリケーションがサービスアカウントの資格情報を使ってGoogle APIへ接続できます。Workspaceのドメイン管理者がドメイン全体の権限を委任すると、アプリケーションはドメイン内ユーザーのデータを、そのユーザーに代わって扱えるようになります。
ただし「ドメイン全体の委任を許可した」ことは、すべてのユーザーのすべてのデータを無条件に読めるという意味ではありません。ドメイン全体の委任を使うアプリケーションは、APIリクエストの中で処理対象のユーザーを指定します。Googleの管理者向けベストプラクティスは、OAuthスコープだけではサービスアカウントが偽装できるユーザーを制限できないと説明しています。ユーザーを固定したい場合は、アプリケーション側の制御とログで対象を確認し、委任そのものの許可範囲と混同しないことが必要です。利用可能なデータ範囲は、偽装したユーザーの権限と管理者が承認したOAuthスコープの組み合わせで決まります。
また、アプリケーションが自分自身のデータだけを扱えば足りる場合は、ドメイン全体の委任を使わず、サービスアカウントの直接アクセスやユーザー同意型OAuthで成立しないかを先に検討します。Googleのベストプラクティスでも、より広い委任を必要としない構成が選べる場合はその方法を優先する考え方が示されています。この3者を分けずに「サービスアカウントにDrive権限を付けた」とだけ記録すると、あとで影響範囲を説明できません。
| 経路 | 誰が許可するか | 台帳で分ける項目 | 見直しの焦点 |
|---|---|---|---|
| ユーザー同意型OAuth | ユーザーが同意し、管理者が制限する場合もある | ユーザー、OAuthクライアント、同意日時、要求スコープ | 利用者の異動、アプリの信頼性、同意の有効性 |
| ドメイン全体の委任 | Workspace管理者がクライアントIDとスコープを承認する | クライアントID、サービスアカウント、実際の偽装ユーザー、スコープ、所有者 | 最小スコープ、用途、実利用、依存アプリ、廃止 |
| グループ・共有ドライブ権限 | 管理者やリソース所有者がメンバーと共有範囲を設定する | グループ、共有ドライブ、メンバー、組織部門、外部共有 | 人の所属、共有先、ファイル単位の可視性 |
この違いは、障害や監査で「どのユーザーの、どのデータへ、どのアプリがアクセスできたか」を説明するときに効きます。ドメイン全体の委任はグループから自動的に決まる設定ではないため、共有ドライブのメンバー一覧だけを見ても、APIクライアントの許可状態は分かりません。
2. 棚卸しはクライアントIDと利用実態を同じ行で管理する
最初の棚卸しでは、管理コンソールの「ドメイン全体の委任」に表示されるクライアントを起点にします。Googleのヘルプでは、サービスアカウントを定期的に確認し、不要になったアカウントを削除することが推奨されています。名前だけで判断せず、開発プロジェクト、連携サービス、運用担当、偽装対象、最後に成功した処理まで別の資料と照合してください。
管理台帳は、次の項目を最低限そろえると、権限の広さと利用の必要性を同時に確認できます。クライアントIDは編集できない識別子なので、表示名やサービスアカウントのメールアドレスだけをキーにしないことが重要です。鍵を使う構成では、鍵の保管場所や有効状態も別欄に残しますが、秘密鍵そのものを台帳へ貼り付けてはいけません。
| 台帳項目 | 記録する内容 | 照合する資料 | 不明な場合の扱い |
|---|---|---|---|
| クライアント識別 | 数値のクライアントID、表示名、サービスアカウントメール、Cloudプロジェクト | 管理コンソール、Cloud IAM、アプリ設定 | 所有者が確認できるまで変更・拡張を止める |
| 実際の偽装ユーザー（アプリ側） | リクエストで指定するユーザー、アプリ側の対象制御、対象データの範囲 | アプリ設定、ジョブ定義、APIログ | 管理者の委任許可がユーザー一覧を制限すると誤解しない |
| OAuthスコープ | 承認済みスコープ、実際に呼ぶAPI、読み取り・書き込みの別 | 管理コンソール、コード設定、実行ログ | 未使用スコープを候補として分離する |
| 責任と目的 | 業務目的、データオーナー、技術担当、委託先、開始日 | 申請・承認記録、契約、運用手順 | 目的と責任者が空欄なら継続理由を再確認する |
| 利用実態 | 最終成功日、最終失敗日、利用頻度、呼び出し元、変更履歴 | アプリログ、管理レポート、監視通知 | 未利用とログ未取得を同じ「未使用」と扱わない |
| ライフサイクル | 承認者、次回レビュー、鍵の状態、廃止条件、削除証跡 | チケット、承認ワークフロー、削除記録 | レビュー期限を仮置きし、所有者を確定する |
ドメイン全体の委任一覧とは別の補助資料として、Google Workspaceのアプリ管理画面では、設定済みアプリ、アクセスされたアプリ、審査待ちアプリを確認でき、要求されたGoogleサービスやOAuthスコープを表示できます。管理者権限の範囲ではCSVに書き出せる情報もあるため、台帳には画面を見た日時と出力ファイルの保管場所を記録します。ただし、この画面やCSVだけでドメイン全体の委任が実際に使われたこと、または使われていないことを証明できるとは限りません。認可後の表示に24〜48時間かかる場合もあるため、アプリの実行ログ、ジョブ履歴、監視記録と突き合わせ、ログがない場合は「未使用」ではなく「利用を確認できない」と記録します。
このアプリ一覧やCSVだけで、ドメイン全体の委任の利用履歴が完全に分かるとは限りません。委任一覧、サービスアカウントの管理情報、実行元の設定、アプリケーションのログを照合してください。一覧に見えないことやログがないことを、未使用の証拠にしてはいけません。
パスワードや秘密鍵などの認証情報の棚卸しは、Google Workspaceのアプリパスワードを棚卸しして廃止する手順ともつながります。両者は同じ仕組みではありませんが、所有者不明の認証経路を放置しないという管理目的は共通します。委任台帳と認証情報台帳を統合する場合も、クライアントID・スコープ・偽装対象の対応関係を失わないようにします。
3. 設定・変更はスコープを決めてから承認する
まず、ドメイン全体の委任が本当に必要かを確認します。Googleは、サービスアカウントによる直接アクセスやユーザー同意型OAuthで目的を達成できるなら、そちらを使うよう推奨しています。委任が必要な重要業務に限定し、サービスアカウントを利用・変更できる人のIAM権限も点検します。サービスアカウント鍵の作成は必須ではなく、Googleは鍵を使わない方法も推奨しています。
新しい委任を追加するときは、先に「どのユーザーの、どのデータを、どの処理で、いつまで扱うか」を決めます。サービスアカウントを作ってから用途を探す順番にすると、最初から広いスコープを許可して後で狭める運用になりがちです。特にGmail、Drive、Calendarなど複数サービスを一つのクライアントへ束ねる場合は、処理ごとに分けられないかを検討します。
Google公式の管理手順では、特権管理者が管理コンソールの［セキュリティ］→［アクセスとデータの管理］→［APIの制御］→［ドメイン全体の委任を管理］へ進み、クライアントIDとOAuthスコープを登録します。スコープはアプリケーションが実際に必要とするものに絞ります。複数管理者による承認を有効にしている組織では、追加、スコープ編集、削除に別の特権管理者の承認が必要です。
実務では、次の順番で申請と変更を分けて記録します。
- 目的と責任者を固定する。連携する業務、処理対象、データオーナー、技術担当、終了条件を申請に書きます。
- 実行時に指定するユーザーを確認する。アプリケーションがどのユーザーとしてAPIを呼ぶのか、対象ユーザーの権限で処理が成立するのかを確かめます。これはアプリ側の利用設計を確認する手順であり、管理者のドメイン全体の委任に固定ユーザー一覧を登録する手順ではありません。
- 必要なAPIとスコープを列挙する。読み取りと書き込みを分け、未使用の広いスコープを申請へ含めません。
- 依存関係を調べる。定期ジョブ、Webhook、バッチ、連携先のエラー処理、サービスアカウント鍵の有無を確認します。
- 管理コンソールで変更し、差分を保存する。変更前後のクライアントID、スコープ、承認者、時刻、申請番号を台帳へ残します。
- 反映後に最小の動作確認をする。対象ユーザーのテストデータで読み取り・書き込みを確認し、失敗時のログとロールバック手順を記録します。
Googleは変更が反映されるまで最大24時間かかる場合があると案内しています。したがって、設定直後に「反映されないからスコープを追加する」と判断するのは危険です。変更時刻、対象ドメイン、実行したテスト、再確認時刻を分け、反映待ちと権限不足を切り分けます。AIエージェントやMCPのように複数サービスを横断する構成では、Google Workspace MCP Serverの接続設計も参照し、便利さだけで権限を広げず、データの所在と承認点を先に整理します。
| 変更前に確認すること | 変更後に確認すること |
|---|---|
| 目的、所有者、偽装対象、スコープ、依存ジョブ、停止時の影響 | 想定したAPIだけが成功すること、不要なAPIが拒否されること、ログに対象ユーザーとクライアントIDが残ること |
| 複数管理者承認の有無、変更時刻、反映待ちの窓 | 承認記録、テスト結果、エラー時の復旧手順、次回レビュー日 |
4. 定期レビューでは継続・縮小・削除を分ける
レビューの目的は、委任設定を残すことでも、数を減らすことでもありません。業務上必要なアクセスを維持しながら、使われていないスコープや所有者不明のクライアントを見つけることです。Googleの公式ヘルプはサービスアカウントとスコープを定期的に確認し、不要なクライアントを削除するよう案内しています。組織としてのレビュー周期は、データの機微性、連携頻度、委託先の変更量に応じて決めます。
| 判断 | 適用する状態 | 必要な作業 | 残す証跡 |
|---|---|---|---|
| 継続 | 目的・所有者・利用実態・スコープが一致している | 台帳のレビュー日を更新し、次回確認日を設定する | 確認者、確認日、ログの参照先、継続理由 |
| 縮小 | 処理は必要だが、未使用サービスや書き込み権限がある | スコープやアプリ側の対象制御を見直し、依存ジョブをテストする | 変更前後の差分、承認、テスト結果、反映確認 |
| 削除 | 移行・終了済みで、依存確認と削除承認が完了している | 利用停止の影響を確認してから委任を削除し、鍵やジョブも廃止する | 依存関係確認、削除承認、実施時刻、停止後の監視結果 |
「最終利用日が古い」または「所有者が分からない」という理由だけで、すぐにクライアントを削除するのは避けます。ログが取れていない、繁忙期だけ使う、障害時の復旧用に残している、といった別の状態もあるからです。まず所有者・依存アプリ・契約担当へ照会し、一定期間の停止テストや段階的なスコープ縮小ができるかを判断します。削除すると、その許可に依存するアプリケーションは直ちに動かなくなる可能性があります。
削除後は、委任の行を台帳から消すのではなく、削除済みとして残します。削除したクライアントID、承認者、実施者、時刻、影響、監視結果を保管しておけば、同じ連携を再導入する際に過去の判断を確認できます。サービスアカウント自体、Cloudプロジェクトの鍵、定期ジョブ、外部SaaS側の認証情報も停止対象かを分けて記録してください。
5. 監査と引き継ぎに耐える管理記録を作る
委任の台帳は、設定画面の写しだけでは不十分です。レビュー時に第三者が「なぜ必要か」「誰が責任を持つか」「どのユーザーに代わって何をするか」「いつ止められるか」を読めることが重要です。記録をチケットやスプレッドシートで管理する場合も、クライアントIDを主キーにし、表示名・メールアドレス・担当者名が変わっても履歴を追えるようにします。
定期運用では、月次または四半期などの周期を組織のリスクに合わせて決め、次のイベントが起きたら周期を待たずに臨時レビューします。
- 連携サービスの担当者、委託先、契約、Cloudプロジェクトが変わった。
- Gmail、Drive、Calendarなど扱うサービスやスコープが増えた。
- 偽装対象ユーザーの異動、停止、権限変更があった。
- サービスアカウントの鍵を作成、無効化、ローテーションした。
- ジョブの失敗、想定外のAPI呼び出し、データの取得範囲の変化があった。
AI連携を含む場合は、実行ログの保存先、プロンプトや処理結果に含まれるデータ、担当者が人手で承認する箇所も台帳から参照できるようにします。Google Workspaceの管理対象アプリを一覧化するCSVと、アプリケーション側のジョブログを同じ取得日で保管すると、管理コンソール上の許可と実際の利用がずれていないかを確認しやすくなります。
委任設定とAPI連携の棚卸し・縮小・廃止を管理台帳へ落とし込むときは、対象データと運用担当を一緒に整理します。
よくある質問
ドメイン全体の委任とユーザー同意型OAuthは同じですか？
同じではありません。ユーザー同意型OAuthはユーザーがアプリへ許可する流れが中心ですが、ドメイン全体の委任はWorkspace管理者がクライアントIDとOAuthスコープを承認し、アプリケーションが実行時に指定したユーザーに代わってAPIを呼び出す構成です。管理画面、承認者、アプリ側の利用対象、廃止手順を分けて記録してください。
ドメイン全体の委任を許可すると、サービスアカウントは全ユーザーの全データを読めますか？
承認したスコープの範囲で、ドメイン内の任意のユーザーに代わってアクセスできる強い権限です。スコープで対象ユーザーを限定することはできません。個々のアクセスは、リクエストで指定する偽装対象ユーザーの権限と、管理者が承認したOAuthスコープの両方に制約されます。どのユーザーとして、どのAPIを、どのスコープで呼ぶかを台帳とログで対応付けます。
OAuthスコープはどの単位で棚卸ししますか？
クライアントIDごとに、承認済みスコープと実際のAPI呼び出しを分けて棚卸しします。GmailやDriveなどサービス名だけでまとめず、読み取り・書き込みの違い、対象ユーザー、利用目的、最終利用日まで記録します。使っていないスコープがあれば、依存処理を確認したうえで縮小候補にします。
設定を変更したのに、すぐに権限が変わらないのはなぜですか？
Googleの公式ヘルプでは、変更が反映されるまで最大24時間かかる場合があると説明されています。変更時刻、承認状態、対象クライアント、テスト結果を記録し、反映待ちと設定ミスを分けて確認してください。待機中にスコープを追加して原因を隠さないことが重要です。
使わないサービスアカウントはすぐ削除してよいですか？
まず依存アプリ、定期ジョブ、復旧用処理、鍵、委託先を確認します。Googleは不要なクライアントの削除を推奨していますが、削除すると許可に依存するアプリが動かなくなる可能性があります。停止テストや承認を経て削除し、削除済みの記録と監視結果を残してください。
グループや共有ドライブの権限を見れば委任設定も分かりますか？
分かりません。グループや共有ドライブは人やリソースの共有設定であり、ドメイン全体の委任はAPIクライアントに対する管理者承認です。両方を同じアクセス台帳で参照しても、クライアントID、OAuthスコープ、アプリ側で実際に指定するユーザーの欄は別に持つ必要があります。
本稿は2026年9月26日時点で確認できたGoogle公式ヘルプとGoogle Identityの仕様説明に基づきます。管理コンソールの表示名、利用できる権限、組織の承認設定は契約プランや管理者ロールによって変わるため、実際の環境で表示される項目と自社の規程を照合してください。サービスアカウントの秘密鍵やアクセストークンは管理台帳へ記載せず、適切な認証情報管理の仕組みで保護してください。
参考情報
- Google Workspace「Domain-wide delegation best practices」（代替方式の検討、スコープでユーザーを制限できない点、サービスアカウントの保護）
- Google Workspace Admin Help「Control API access with domain-wide delegation」（クライアントID、OAuthスコープの追加・編集・削除、レビュー、反映時間、複数管理者承認）
- Google Identity「Using OAuth 2.0 for Server to Server Applications」（サービスアカウント、ドメイン全体の権限委任、ユーザー偽装、スコープとユーザー権限の関係）
- Google Workspace Admin Help「Control which apps access Google Workspace data」（設定済み・アクセス済みアプリ、アクセスレベル、利用サービス、OAuthスコープ、CSV出力）
API連携の権限範囲と管理責任を整理し、棚卸しから廃止まで一貫した運用にしたい場合は、ファネルAiへご相談ください。
