GWS Marketplace アプリ承認管理と棚卸し設計

Google Workspace 管理コンソールでは、Marketplace からのアプリインストール可否を「全許可 / 許可リスト制 / 全拒否」の3択で OU（組織ユニット）・グループ単位に制御できます。OAuth によるデータアクセス管理とは独立した設定ラインであり、両者を組み合わせないとシャドーアドオンのリスクをカバーしきれません。

この記事を読んだほうが良い人

• Google Workspace を運用している情シス担当者で、ユーザーが任意にアドオンをインストールできる状態を放置している方
• OAuth アクセス制御（サードパーティ連携の承認管理）は設定済みだが、Marketplace インストール制御が未設定の方
• Google Docs / Sheets のアドオンが何が入っているか把握できておらず、棚卸しを検討している方
• 既存アドオンのシャドー利用リスクを整理してセキュリティポリシーに落とし込みたい方

OAuth 管理と Marketplace インストール制御は何が違うのか

「シャドー SaaS は OAuth で管理する」という認識が情シスの間で広まっています。しかし Google Workspace Marketplace から入れるアドオンは、インストール自体の制御が別の管理ラインにあります。

比較軸	OAuth アクセス管理	Marketplace インストール制御
何を管理するか	Google アカウントのデータへのアクセス権限	Marketplace からのインストール可否
設定の場所	セキュリティ配下の API の制御	アプリ配下の Marketplace 設定
対象の範囲	OAuth 2.0 でデータ要求するアプリ全般（Web アプリ含む）	Marketplace 経由でインストールされるアドオン
何を止められるか	スコープ単位でのデータアクセス	インストール行為そのもの

この2つは独立した設定ラインなので、片方だけでは必ずリスクが残ります。

OAuth のみを制御した場合の抜け穴: ユーザーが Marketplace からアドオンをインストールすること自体は防げません。インストール時の OAuth 承認でエラーになるとしても、「何かをインストールしようとした」という事象は発生します。ユーザーが原因を理解できず問い合わせが増え、情シスの対応コストが上がるパターンにつながります。

Marketplace のみを許可リスト制にした場合の抜け穴: Marketplace 外の Web アプリや外部配布スクリプト経由のデータアクセスは、OAuth 管理で別途対処する必要があります。Marketplace の許可リストは、Marketplace 以外から配布されるアプリのインストールを防ぐものではないことが公式ヘルプにも明記されています。

2つを一体で設計することが、GWS のアプリ管理における基本的な前提になります。

組織ポリシーの3択と設計判断

管理コンソールの Marketplace アプリ設定では、以下の3つのポリシーから選びます（Google Workspace 管理者ヘルプより）。

ポリシー	内容	向いている組織・状況
全許可	ユーザーが任意のアプリをインストールできる	IT リテラシーが高く自己管理できるチーム（定期棚卸しが必須）
許可リスト制	管理者が承認したアプリのみインストール可	100名規模で情シス専任が1〜2名いる組織（最も現実的な選択）
全拒否	Marketplace からのインストールを一律禁止	セキュリティ要件が厳しい業種（医療・金融・法律等）や特定部門

100名規模の組織であれば、「許可リスト制」が利便性とガバナンスのバランスとして最も選ばれやすい選択肢です。全許可は管理コストが低い反面でリスクが残り、全拒否は業務効率を大きく損なう可能性があります。

ポリシー設計で押さえておくべき3点:

• OU 単位でポリシーを分けられるため、「開発部門は全許可・それ以外は許可リスト制」という構成も取れます。なお、許可リストは OU・グループ単位で設定できますが、除外リスト（特定アプリのブロック）は OU 単位のみ対応で、グループへの適用はできません
• 管理者側から必要なアプリを一括展開できます。「ユーザーには全拒否、情シスが選定したアプリは全員に配布」という運用で、利便性を損なわずに制御できます
• ポリシー変更後の反映には最大 24 時間かかります（公式ヘルプより）。切り替えを急ぐ場合もユーザーへの事前告知を忘れずに行いましょう

全許可 → 許可リスト制への移行タイミング

現在「全許可」にしている場合、突然ポリシーを切り替えると業務中に使っているアドオンが動かなくなり、ヘルプデスクへの問い合わせが集中します。移行前に「既存の利用アドオンを全件洗い出し → ユーザーへ周知 → 期限後に切り替え」という手順を踏むことで、移行時の混乱を抑えられます。周知からポリシー切り替えまでは2〜3週間を目安にするのが現実的です。

Google Workspace 拡張機能の棚卸しフロー

ポリシーを変更する前に、既存の棚卸しが必要です。棚卸しには主に2つの確認ラインを使います。

OAuth ログイベントで認可済みアプリを確認する

管理コンソールの監査と調査から OAuth ログイベントを確認すると、Marketplace 経由で認可されたアプリとそのスコープを把握できます。Drive の読み書き・メール送信・カレンダー参照といったスコープ単位で、どのアプリがどんなアクセス権を持っているかを洗い出せます。

API の制御画面で接続済みアプリ一覧を確認する

セキュリティ配下の API の制御（OAuth アクセス管理画面）では、現在接続されているサードパーティアプリとそのスコープを一覧で確認できます。Marketplace アドオンも OAuth を使う場合はここに表示されるため、実際に使われているアプリの全体像を把握する出発点になります。

棚卸しを進める順番

1. 上記2つの画面から「実際に認可されているアプリ」を一覧化する
2. 各アプリについて業務用途を確認する（使っているユーザーや部門へのヒアリングが確実です）
3. 業務上必要と確認できたアプリを許可リスト候補として整理する
4. 各アプリの公開者（デベロッパー）が Marketplace の確認済みバッジを取得しているか、スコープが業務用途に対して過剰でないかを確認する
5. 確認が取れたアプリを許可リストに追加し、ポリシーを切り替える

棚卸しと許可リスト構築を並行して進めることで、切り替え後に「使えなくなった」という問い合わせを最小化できます。

GWS アドオン承認フローの設計

許可リスト制に移行した後は、新しいアドオンの申請・承認フローを整備します。フローがないと、ユーザーが必要なアプリを使えずに業務が止まるか、情シスへの問い合わせが集中するかのいずれかになります。

基本的な申請フローの例

1. ユーザーが希望アプリを情シスに申請する（フォームやチケット管理ツール等で受け付ける）
2. 情シスが以下の観点で確認する

• Marketplace の公開者が Google の確認済みバッジを取得しているか
• 要求しているスコープが業務用途に対して過剰でないか（PDF 変換が目的なのに Drive 全体の読み書きを要求するようなケースは精査が必要）
• 社内の情報セキュリティポリシーに抵触しないか

3. 承認の場合 → 許可リストに追加し、必要な OU やグループに絞って展開する
4. 却下の場合 → 理由とともに代替手段を案内する

承認基準を文書化しておく理由

「スコープが Drive 全体書き込みを要求するアプリは原則却下」「確認済みバッジがないアプリは業務必須性の証明が必要」といった基準を書き残しておくと、担当者が変わっても判断軸がぶれません。情シス1〜2名体制では属人化が起きやすいため、承認基準の文書化は長期的な運用安定に直結します。

申請から承認までの期間目安（例: 申請から5営業日以内）を決めておくと、ユーザーが「いつ使えるようになるのか」を判断しやすくなり、問い合わせの往復が減ります。

Marketplace アプリ情シス制御の運用チェックリスト

初期設定確認

• [ ] Marketplace ポリシーが「全許可」のまま放置されていないか
• [ ] OU 構成に沿ったポリシー設定になっているか
• [ ] 業務に必要な主要アプリを管理者側から一括展開できているか
• [ ] ユーザー向けの申請ルート（フォーム等）が整備されているか
• [ ] 承認基準（スコープの過剰性の判断基準等）が文書化されているか

定期棚卸し（3〜6ヶ月ごと）

• [ ] OAuth ログイベントで認可済みアプリの状況を確認したか
• [ ] 許可リストに不要になったアプリが残っていないか確認したか
• [ ] 退職者・部署異動者に紐づくアプリの承認状況を見直したか
• [ ] 許可リスト内のアプリの公開者ステータスに変化がないか確認したか

申請・承認フロー

• [ ] 却下時に代替手段を提案できる仕組みがあるか
• [ ] 申請対応の期間目安がユーザーに伝わっているか

「OAuth だけやっていれば大丈夫」から一歩踏み出す

OAuth アクセス管理に注力してきた組織では、Marketplace インストール自体が「誰が何を入れたか把握できない状態」になっているケースがあります。管理上の空白ですが、「設定画面が2か所に分かれている」という構造上の問題で、整備すれば解消できます。

まず「現状の棚卸し → OAuth ログで使われているアプリを把握 → 許可リスト制へ移行」という流れを一度やりきることで、シャドーアドオンのリスクは大きく下がります。

その後は定期的な棚卸しと承認フローの運用でほぼ完結します。初回に仕組みを作る手間はかかりますが、一度整備してしまえばルーティンワークになります。OAuth 管理と Marketplace インストール管理を両輪で整えている組織はまだ少ない。この2点に取り組むだけで、情シスの管理体制は一段成熟します。

コーポレートITのご相談はお気軽に

この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。 「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。