AIツール追加申請のOAuthスコープ審査ポリシー設計

新しい AI ツールを Google Workspace に接続する際には、OAuth (Open Authorization) スコープという形でアクセス権をアプリに付与します。このスコープの範囲は情シスが申請段階で審査・設定するため、入口での判断基準が組織全体のデータガバナンスに直接影響します。この記事では、新規 AI ツールの申請を受け付けた時点から承認・却下を決定するまでの事前審査フレームと、承認フローの設計指針を整理します。

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

• Claude・Gemini・ChatGPT Enterprise など複数の AI ツールが社内に混在し始め、部門からの追加申請が増えてきた情シス担当者
• 新規ツール申請のたびに「このスコープは許可していいのか」を個別判断しており、判断根拠を文書化できていない方
• AI ツールの承認フローをこれから整備したい 100 名規模企業の IT 担当者

OAuthスコープとは何か、なぜ情シスが審査するのか

OAuth スコープとは、あるアプリがユーザーのデータに「どの範囲でアクセスできるか」を制御する設定です。ユーザーが AI ツールにサインインするとき、そのツールは要求するスコープの一覧を同意画面に提示し、ユーザーから許可を取得します。

問題は、多くのユーザーが同意画面の内容を確認せずに許可をクリックする点です。Google Workspace では、管理コンソールの API の制御から、サードパーティアプリへのスコープ付与をドメイン単位で管理できます。ここでの設定が甘いと、ユーザーが同意するだけで AI ツールが組織の Drive 全体や Gmail の送受信記録にアクセスできる状態になります。

既に接続済みのツールを事後確認する月次監査や、SSO（シングルサインオン）統合による一元管理とは別に、「申請を受け付けた瞬間の入口審査」が組織のデータリスクを根本から左右します。既存ツールの監査サイクルはあくまで過去の接続を点検するものであり、申請ゲートなしに運用していると、問題のあるスコープが静かに蓄積します。

OAuthスコープのリスクランクと最小権限の原則

OAuth スコープには「最小権限の原則」が適用されます。つまり、アプリが必要とする操作のみアクセスを許可し、それ以上のスコープは承認しない、という考え方です。

申請されたスコープを以下の 3 段階で分類することが、審査の起点になります。

ランク	スコープの種別	代表的なアクセス内容	基本の審査方針
低	Read Only	ファイルの閲覧・メールのメタデータ参照・カレンダーの読み取りのみ。データの作成・変更・削除は不可	閲覧対象の範囲（全ドライブか特定フォルダのみか）を確認のうえ、用途が明確なら承認可
中	Write	ファイルの作成・編集・削除、メール送信、カレンダー予定の作成・変更など書き込み操作が可能	業務上の必要性を申請書で確認。OU（組織部門）単位での利用範囲を条件に付けて承認
高	Admin	全ユーザー一覧の取得・ユーザーの作成削除・組織設定の変更・監査ログの閲覧など管理者レベルのアクセス	原則却下。承認する場合は情報セキュリティ責任者・上長の個別承認を必須とする

この表を参照する際の注意点が 1 つあります。Read Only と表示されていても、「組織全体の Drive ファイルを閲覧可能」なスコープと「アプリ自身が作成したファイルのみ閲覧可能」なスコープでは、実際のリスクが大きく異なります。スコープの名称だけでなく、アクセス対象の具体的な範囲を申請書に明記させることが重要です。

AIツール追加申請の審査フローと判断ステップ

承認フローは「申請書提出 → スコープのリスクランク判定 → 承認・却下判断 → 記録と棚卸し」の 4 段階が基本です。

ステップ1：申請受付と書類確認

申請書に必須項目が記載されているかを確認します。不足があれば差し戻し、追加情報を求めます。目安として 3 営業日以内に一次返答を行うことで、申請者側も見通しが立てやすくなります。

ステップ2：スコープのリスクランク判定

申請書に記載されたスコープ一覧を上記ランク表と照合します。スコープ一覧が記載されていない場合は、申請者がツールのドキュメントまたは同意画面を確認して明記するよう求めます。情シスが代わりに調べる運用は持続しません。

ステップ3：ランク別の承認判断

• Read Only のみの場合：情シス担当者が単独で承認可否を判定。原則 1 週間以内に回答する
• Write スコープを含む場合：情シスマネージャーの確認を経たうえで、OU 制限・利用期限を条件に付けて承認または却下する
• Admin スコープを含む場合：原則却下とし、申請者に代替手段を提示する。承認が必要な特別ケースは情報セキュリティ責任者の署名を必須とする

ステップ4：承認後の記録と定期棚卸し

承認したツール・スコープ・承認日・利用部門を台帳に記録します。申請ゲートはライフサイクルの入口であり、承認後も定期的な確認が必要です。接続済みツールの月次監査については、GWS 複数AIツール監査ポリシー補完設計で詳しく説明しています。

申請書に最低限含める項目

申請書は、審査の根拠を文書として残す役割と、申請者が「本当に必要か」を自ら考える契機にする役割の両方を担います。以下の項目を最低限含めることを推奨します。

• ツール情報：ツール名・提供ベンダー名・利用プラン（無料 / 有料の区別を明記）
• 利用計画：申請部門・申請者・利用予定人数・利用開始予定日
• 目的と必要性：どの業務プロセスで使うか。既存ツールでは対応できない理由
• 要求スコープ一覧：ツールのドキュメントまたは同意画面をもとに明記
• データ取り扱い方針：入力データがベンダー側で学習利用されるか否かを明記（利用規約の該当箇所を示す）
• 利用終了時の対応：契約終了・不要になったときにアクセス権限を剥奪する手順

「利用規約が長くて確認できなかった」という申請は差し戻しの対象です。情シスがベンダーの規約を代読する運用は拡張性がなく、申請者自身が確認・記載することを原則とします。

審査NGになりやすい事例3件

実際の申請で見られる NG パターンを 3 件取り上げます。同様の申請が来たとき、判断の参考にしてください。

事例1：Read Only だから安全と判断したが、対象が全社の Drive だった

「読み取りのみだから問題ない」と判断して承認したところ、そのツールは全ユーザーの Drive ファイル（人事情報・契約書・財務データを含む）を横断的に閲覧できる状態になっていた。

対応の考え方：Read Only でも「組織全体の Drive にアクセスできるスコープ」と「アプリが自ら作成したファイルのみに限定されるスコープ」では意味合いが根本的に違います。スコープ名を見るだけでなく、アクセス対象の範囲を申請書に書かせることで、この見落としを防げます。

事例2：Write スコープを承認した後、バグで意図しないメールが外部に送信された

メール作成・送信スコープを持つ AI ツールを承認した。後日、ツールのアップデートで設定が変更され、一部ユーザーから未確認のメールが外部宛てに送信された。

対応の考え方：Write スコープを承認する際は、「送信前に人間の確認が入る設計か」「自動送信が可能なツールか」をベンダーの仕様書で確認します。送信可能なスコープを持つツールについては、OU を限定して試験導入するのが現実的な対応策です。

事例3：Admin スコープを持つ効率化ツールを、部門の強い要望で条件なく承認した

全ユーザー一覧の取得・部署情報の参照が可能な Admin スコープを持つツールを「業務効率化に有用」と判断し、特段の条件を付けずに承認した。その後、「そのツールがユーザー情報をどこに送っているか」の把握が困難になった。

対応の考え方：Admin スコープを承認する場合は、ベンダーの SOC 2 Type II 報告書など外部セキュリティ認証の提出を条件とすることを検討してください。「業務効率化に有用だから」という理由だけでは、組織のユーザー情報を管理するシステムに接続する承認根拠として不十分です。

審査ポリシーを社内ルールとして定着させるには

審査基準は、文書化して関係者に周知して初めて機能します。整備すべきものを 3 点に絞ります。

1. 審査基準の文書化と公開

リスクランク表・審査フロー・申請書テンプレートをまとめた文書を作成し、情シス以外の全員が参照できる社内ポータルや共有ドライブに置きます。「どこに何を申請すればよいか」が明確になると、事前相談が増え、シャドー IT（未申請のツール利用）の抑止につながります。

2. 申請の窓口を一本化する

部門マネージャーへの口頭周知だけでは不十分です。専用の申請フォームや Jira・チケットシステムのテンプレートを用意し、情シスが申請を漏れなく把握できる経路を確立します。

3. 月次棚卸しと組み合わせて運用する

申請ゲートは「入口の審査」に過ぎず、承認後にスコープが適切に使われているかは別途確認が必要です。四半期ごとに接続済みツールの一覧を見直し、不要になったアクセス権限を剥奪する運用と組み合わせると、ライフサイクル全体をカバーできます。

最初の整備には数日かかりますが、テンプレートと承認フローが一度整えば、個別申請のたびにゼロから判断する状況から抜け出せます。AI ツールの申請件数が増えるほど、こうした仕組みの有無が情シスの業務負荷に直結します。

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

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