はじめに
生成AI、議事録作成サービス、ファイル変換ツール、営業支援ツールなどを利用するとき、「Googleでログイン」「Microsoftアカウントで接続」といったOAuth認証を使う場面が増えています。
OAuthは、外部サービスにパスワードそのものを渡さず、必要な権限だけを与えられる便利な仕組みです。しかし、従業員が承認したアプリに、メール、ファイル、カレンダー、連絡先などを読み取る権限が残り続ける可能性があります。
特に注意したいのが、外部生成AIとOAuthアプリを別々に管理してしまうことです。
生成AIサービスがGoogle DriveやOneDrive、メール、チャット、CRMなどと接続されれば、「生成AI利用のリスク」と「OAuthによるデータアクセスのリスク」が一体化します。
安全な運用に必要なのは、一度限りの導入審査ではありません。利用しているアプリ、付与した権限、入力データ、契約条件、実際の利用状況を定期的に確認する仕組みです。
本記事では、OAuthアプリと外部生成AIを統合して監査するための実務手順を解説します。
1．なぜ導入時の審査だけでは不十分なのか
企業では、新しいクラウドサービスを導入するときに、情報システム部門や管理者が安全性を確認することがあります。
しかし、導入時点で問題がなくても、その後に次のような変化が生じます。
- アプリが要求するOAuth権限が追加された
- 利用者が増え、機密情報を扱う部門でも使われ始めた
- 無料版から有料版へ移行し、利用機能が変わった
- 生成AIのモデル、保存期間、学習設定が変更された
- サービス提供事業者や再委託先が変更された
- 退職者や異動者が連携したアプリが残っている
- 業務上不要になったアプリのアクセストークンが有効なまま残っている
- ブラウザ拡張機能やAIエージェントが追加された
Microsoftは、ユーザーの同意設定を変更しても、その変更は今後の同意に適用されるものであり、すでに付与された同意は別途取り消す必要があると説明しています。
つまり、「今後の利用を制限したから安全」とは限りません。既存アプリの棚卸しと権限の取り消しが必要です。
Google Workspaceでは、管理コンソールからアクセス済みアプリ、利用者数、要求されたサービス、OAuthスコープなどを確認し、一覧をCSVで出力できます。アプリを「信頼できる」「限定」「特定のGoogleデータ」「ブロック中」に分類することも可能です。
参考：Google Workspaceのデータにアクセスできるアプリを制御する
2．監査対象を対話型生成AIだけに限定しない
外部生成AIの監査というと、ChatGPT、Gemini、Claudeなどの対話型サービスだけを想定しがちです。
実際には、次のサービスも監査対象に含める必要があります。
- 文章作成、翻訳、要約サービス
- AI議事録、文字起こしサービス
- 画像、動画、音声生成サービス
- ブラウザ拡張機能
- Google WorkspaceやMicrosoft 365のアドオン
- CRM、SFA、MAツールのAI機能
- チャットツールと連携するAIボット
- クラウドストレージを検索するAIサービス
- 独自GPT、AIエージェント、ワークフロー
- APIキーを使って接続された生成AI
- 個人アカウントで利用される無料AIサービス
- スマートフォンにインストールされたAIアプリ
サービス名ではなく、「組織のデータを外部へ送信、保存、解析できる仕組み」を監査対象とすることが重要です。
3．OAuthアプリと外部生成AIを同じ台帳で管理する
OAuthアプリと外部生成AIを別々の台帳で管理すると、生成AIから社内システムへ接続されている事実を見落とす可能性があります。
そのため、両者を一つの監査台帳で管理します。
最低限、次の項目を記録します。
| 分類 | 記録項目 |
|---|---|
| 基本情報 | サービス名、提供事業者、URL、利用開始日 |
| 管理情報 | 業務責任者、システム管理者、利用部門、利用者数 |
| 認証情報 | OAuth、SAML、ID・パスワード、APIキー |
| 権限情報 | 要求スコープ、委任権限、アプリケーション権限、管理者同意 |
| データ情報 | 入力可能な情報、接続先、機密区分、個人情報の有無 |
| 生成AI情報 | 利用モデル、学習利用の有無、保存期間、削除方法 |
| 契約情報 | 利用規約、DPA、再委託先、データ保存国、事故通知条件 |
| 技術情報 | MFA、SSO、SCIM、暗号化、監査ログ、APIキー管理 |
| 利用状況 | 最終利用日、利用頻度、主要利用者、業務上の必要性 |
| 監査情報 | 前回監査日、判定、是正期限、次回監査日 |
ここで大切なのは、「承認済みサービス一覧」だけを作らないことです。
次の状態まで一つの台帳で管理すると、監査漏れを防ぎやすくなります。
- 承認済み
- 条件付き承認
- 未承認
- 調査中
- 停止予定
- 停止済み
4．OAuthアプリで確認すべきリスク
OAuthアプリの監査では、アプリ名だけで安全性を判断してはいけません。同じサービスでも、接続方法や付与された権限によってリスクが変わります。
アプリの提供元と識別情報
次の項目を確認します。
- 提供事業者は実在するか
- OAuthクライアントIDは正しいか
- パブリッシャーは確認済みか
- プライバシーポリシーが公開されているか
- 問い合わせ先や事故時の連絡先があるか
- 類似名称の不正アプリではないか
有名なサービスと同じような名称やアイコンを使用した不正アプリも考えられるため、表示名だけで判断しないことが重要です。
要求されている権限
次に、アプリがどのデータへアクセスできるのかを確認します。
- メールの閲覧、送信、削除が可能か
- クラウド上の全ファイルへアクセスできるか
- ユーザーが選択したファイルだけに限定できるか
- カレンダーや連絡先を読み取れるか
- ファイルや設定を変更できるか
- 管理者権限が付与されていないか
- ドメイン全体の委任が行われていないか
- 本来の利用目的に対して権限が過剰ではないか
議事録を作成するだけのサービスが、すべてのメールやクラウドファイルへのアクセスを要求している場合は、利用目的と権限が釣り合っているとはいえません。
委任された権限とアプリケーション権限
OAuthの権限には、利用者本人の操作として実行する「委任された権限」と、利用者がログインしていなくてもアプリ単独で動作できる「アプリケーション権限」があります。
アプリケーション権限は、バックグラウンドで広い範囲のデータへアクセスできるため、より慎重な審査が必要です。
MicrosoftのApp Governanceでは、高権限、過剰権限、未使用、未確認パブリッシャー、アプリケーション権限などを確認できます。最終利用日、アクセスしたサービス、機密ラベル付きデータへのアクセスなども監査対象にできます。
参考：Microsoft App Governanceの可視化と分析
自社開発アプリで確認すべき技術要件
自社開発アプリや委託開発アプリでは、次の技術要件も確認します。
- PKCEが適切に使用されているか
- リダイレクトURIが厳格に照合されているか
- 認可コードが安全に保護されているか
- アクセストークンを安全に保存しているか
- リフレッシュトークンのローテーションや失効に対応しているか
- 不要になったクライアントシークレットが残っていないか
OAuthの技術要件については、2025年1月に公開されたRFC 9700で、OAuth 2.0における最新のセキュリティ対策が整理されています。
参考：RFC 9700：OAuth 2.0 Security Best Current Practice
5．外部生成AIで確認すべきリスク
外部生成AIについては、セキュリティ機能だけでなく、入力データ、保存方法、学習利用、外部接続、出力の利用方法まで確認します。
入力データ
- 個人情報や要配慮個人情報を入力していないか
- 顧客情報、契約書、未公開製品情報を入力していないか
- 入力禁止情報が具体的に定義されているか
- 匿名化やマスキングが適切に行われているか
- ファイルを丸ごとアップロードする必要があるか
- 利用者が情報区分を判断できる状態になっているか
「機密情報を入力しない」と書くだけでは不十分です。
顧客名、従業員情報、契約金額、設計図、ソースコードなど、入力してはいけない情報を具体的に示す必要があります。
保存と学習
- 入力データがモデル学習に使用されるか
- 管理者が学習利用を停止できるか
- 入力履歴と生成結果の保存期間は何日か
- 一時保存されたデータも削除対象になるか
- 利用者または管理者がデータを削除できるか
- 契約終了後の削除方法が定められているか
無料版と法人向けプランでは、データの取り扱いや管理機能が異なる場合があります。
サービス名だけで判断せず、実際に利用しているプランと設定を確認することが重要です。
外部サービスとの接続
- Google DriveやOneDriveの全体を検索できないか
- メール、チャット、CRMと自動連携していないか
- AIエージェントがファイルを作成、変更、削除できるか
- AIがメールやメッセージを自動送信できるか
- プラグインや外部ツールが追加されていないか
- 外部接続の追加を管理者が制限できるか
生成AIが情報を読むだけなのか、作成や送信まで実行できるのかによって、リスクの大きさは変わります。
出力結果の利用
- 重要な判断を生成AIだけで行っていないか
- 事実確認、承認、記録の手順があるか
- 著作権、個人情報、営業秘密を確認しているか
- 誤った出力が顧客や住民へ直接送信されないか
- AIが作成した内容であることを識別できるか
- 問題が発生したときに利用履歴を確認できるか
経済産業省・総務省の「AI事業者ガイドライン」は、2026年3月31日に第1.2版へ更新されています。
AI利用者にも、AIガバナンスの構築、リスクの分析、適切な利用、関係者への情報提供などが求められています。
NISTの生成AIプロファイルも、生成AIのリスクを単発の製品審査で終わらせず、AIライフサイクル全体で管理する考え方を示しています。
参考：NIST AI RMF Generative AI Profile
6．実務で使えるリスク評価方法
監査結果は、「問題あり・なし」だけで終わらせず、一定の基準で点数化します。
| 評価領域 | 0点 | 1点 | 2点 | 3点 |
|---|---|---|---|---|
| アクセス範囲 | 外部データなし | 限定データ | 複数サービス | メール・全ファイル・全社データ |
| 情報の機密性 | 公開情報 | 社内情報 | 個人・顧客情報 | 要配慮情報・営業秘密 |
| 権限方式 | 参照のみ | 限定的な更新 | 広範囲な更新 | アプリ単独・管理者権限 |
| 事業者管理 | 契約・監査資料あり | 一部確認済み | 不明項目あり | 提供元・規約が不透明 |
| 利用状況 | 管理下で利用 | 一部未把握 | 部門ごとに拡大 | 個人利用・実態不明 |
| ログと統制 | 詳細ログあり | 管理ログあり | 利用者のみ確認可能 | ログ取得不可 |
判定例は次のとおりです。
- 0～5点：継続利用
- 6～10点：条件付き継続、是正計画を設定
- 11～14点：新規利用を停止し、責任者が再審査
- 15点以上：原則停止し、権限とトークンを取り消す
ただし、次のような事象が確認された場合は、合計点にかかわらず利用停止候補とします。
- 要配慮個人情報の無許可送信
- 提供元を確認できないアプリ
- ドメイン全体への過剰な委任
- 管理者権限の不必要な付与
- 重大な脆弱性や情報漏えい
- 利用目的を説明できないサービス
7．推奨する監査周期
すべてのサービスを毎月詳細に監査すると、運用負担が大きくなります。
リスクと変更頻度に応じて、監査周期を分けることが現実的です。
随時監視
- 新規アプリの接続
- 管理者同意の申請
- 高リスク権限の追加
- 大量データへのアクセス
- 異常なログインやAPI利用
- 重大な規約変更
- 提供事業者のセキュリティ事故
月次監査
- 新しく接続されたOAuthアプリ
- 未承認の生成AIサービス
- 高権限アプリ
- 新規に発行されたAPIキー
- 退職者、休職者、異動者に関連する連携
- 前月からの設定変更
- 是正期限を超過したサービス
四半期監査
- 全OAuthアプリの棚卸し
- 外部生成AIの利用部門と利用者数
- 権限と実際の利用機能の整合性
- 未使用アプリと過剰権限
- 入力データと利用目的
- 学習設定、共有設定、ログ取得状況
- 業務責任者の在籍と承認状況
年次監査
- 利用契約、DPA、利用規約
- 再委託先とデータ保存地域
- 認証取得や第三者監査報告書
- インシデント通知条件
- サービス終了時のデータ移行
- 契約終了後のデータ削除
- 社内規程、教育内容、責任分担
高リスクのアプリは月次、中リスクは四半期、低リスクは年次を基本とします。
権限、接続先、利用部門、契約条件などが変わった場合は、通常の周期を待たず臨時監査を実施します。
8．定期監査の実施手順
手順1 管理画面から一覧を取得する
Google Workspace、Microsoft Entra ID、Microsoft Defenderなどから、OAuthアプリと権限の一覧を取得します。
外部生成AIについては、次の情報も組み合わせます。
- SSOログ
- 経費精算データ
- ブラウザ拡張機能の一覧
- DNSやプロキシのログ
- APIキーの発行記録
- 従業員アンケート
- 利用申請記録
管理画面に表示されるサービスだけでは、個人アカウントで使われている生成AIを把握できない場合があります。
手順2 前回監査との差分を抽出する
新規アプリ、利用者の増加、権限追加、最終利用日の変化を確認します。
毎回ゼロから一覧を読むのではなく、前回監査からの差分を優先的に確認することで、監査負担を減らせます。
手順3 業務責任者を確認する
責任者が不明なサービスは、それ自体がリスクです。
次の質問に答えられる担当者がいるか確認します。
- なぜこのサービスが必要なのか
- どの業務で利用しているのか
- どのデータを取り扱っているのか
- 停止した場合にどのような影響があるのか
- 問題が発生した場合に誰が対応するのか
手順4 権限と利用目的を照合する
サービスの利用目的と、実際に付与されている権限を照合します。
必要以上の権限がある場合は、次の対応を検討します。
- OAuthスコープを縮小する
- 接続するデータを限定する
- 利用者や部門を限定する
- 管理者同意を取り消す
- 接続方法を変更する
- より安全なサービスへ移行する
手順5 生成AI固有の設定を確認する
学習利用、履歴保存、共有設定、外部連携、APIキー、管理者ログなどを、実際の管理画面で確認します。
利用規約を読んだだけで監査を完了させてはいけません。
契約上の取り扱いと、実際の管理画面の設定が一致していることを確認します。
手順6 継続・是正・停止を決定する
監査結果を次のいずれかに分類します。
- 承認して継続
- 条件付きで継続
- 権限縮小後に継続
- 利用者を限定して継続
- 代替サービスへ移行
- 一時停止
- 利用禁止
条件付きで継続する場合は、是正内容、担当者、期限、再確認日を記録します。
手順7 証跡を保存する
次の情報を監査証跡として保存します。
- 監査日
- 確認者
- 管理画面の記録
- 権限一覧
- 利用規約の版
- 契約資料
- 判定結果
- 判定理由
- 是正内容
- 是正期限
- 次回監査日
監査の目的は一覧を作ることではありません。
「なぜこのサービスの継続利用を認めたのか」を、後から説明できる状態にすることが重要です。
9．利用停止時に必要な対応
アプリを監査台帳上で「停止済み」にするだけでは不十分です。
次の処理が完了したことを確認します。
- OAuth同意の取り消し
- 管理者同意の取り消し
- アクセストークンの失効
- リフレッシュトークンの失効
- APIキーの削除
- クライアントシークレットの削除
- SSO連携の解除
- SCIM連携の解除
- サービス側アカウントの停止または削除
- 保存データの削除依頼
- 共有リンクの無効化
- 外部サービスとの連携解除
- 代替業務への切り替え
- 停止後にアクセスが発生していないことの確認
Google Workspaceでサービスへのアクセスを制限した場合、信頼されていないアプリが停止し、トークンが取り消されることがあります。
業務への影響を事前に確認し、対象部門へ通知したうえで実施する必要があります。
10．監査を形骸化させないためのKPI
定期監査では、実施回数だけでなく、問題の発見と是正の状況を測定します。
代表的なKPIは次のとおりです。
- 把握している外部AI・OAuthアプリの総数
- 未承認アプリの件数
- 責任者不明アプリの割合
- 高権限アプリの件数
- 90日以上未使用のアプリ数
- 過剰権限を削減した件数
- 監査期限を超過したサービス数
- 是正完了までの平均日数
- 退職者アカウントに残る連携件数
- 管理者ログを取得できないサービスの割合
- 機密情報の誤入力件数
- 利用規約変更後に再審査した件数
「監査を何回実施したか」よりも、「不要な権限をどれだけ削減できたか」を重視することが大切です。
11．OAuthアプリと外部生成AIの監査チェックリスト
OAuthアプリ
- アプリ名とOAuthクライアントIDを確認した
- 提供事業者とパブリッシャーを確認した
- 利用者数と利用部門を把握した
- 管理者同意の有無を確認した
- 要求されるOAuthスコープを確認した
- アプリケーション権限の有無を確認した
- ドメイン全体の委任を確認した
- メールや全ファイルへのアクセスを確認した
- 最終利用日を確認した
- 未使用の権限を削除した
外部生成AI
- 入力できる情報を分類した
- 個人情報と機密情報の入力ルールがある
- 入力データの学習利用を確認した
- 保存期間と削除方法を確認した
- データ保存国と再委託先を確認した
- 管理者が利用状況を把握できる
- SSO、MFA、SCIMへの対応を確認した
- APIキーを個人管理していない
- 外部ストレージとの接続範囲を確認した
- 出力結果を人が確認する手順がある
運用体制
- 各サービスに業務責任者がいる
- 月次・四半期・年次監査を分けている
- 新規利用の申請窓口がある
- 緊急停止の判断者が決まっている
- 退職・異動時に連携を解除している
- 規約変更を再確認する仕組みがある
- 判定理由と証跡を保存している
- 是正期限と担当者を記録している
12．中小企業では全面禁止より申請経路を整える
外部生成AIやOAuthアプリを全面的に禁止しても、現場の業務上の必要性がなくなるわけではありません。
従業員が便利なサービスを個人判断で利用し、管理部門から見えないシャドーAIへ移行する可能性があります。
そのため、次のような簡易申請経路を用意することが有効です。
- 利用目的
- サービス名
- 接続する社内サービス
- 入力予定の情報
- 必要な権限
- 利用予定期間
- 業務責任者
低リスクの利用は短時間で判断し、高リスクの利用だけを詳しく審査する仕組みにすれば、安全性と現場の利便性を両立できます。
承認を受けるための手続きが複雑すぎると、未申請利用が増える可能性があります。
申請しやすく、判断基準が分かりやすい制度にすることも、生成AIガバナンスの重要な要素です。
まとめ
OAuthアプリと外部生成AIのリスクは、導入時点で固定されるものではありません。
利用者、権限、接続先、AIモデル、利用規約、保存方法が変化するため、継続的な確認が必要です。
実務上の重要点は、次の5つです。
- OAuthアプリと外部生成AIを同じ台帳で管理する
- 新規接続と権限変更を差分で確認する
- 高リスクは月次、全体は四半期、契約は年次で確認する
- 不要なアプリは権限とトークンまで確実に取り消す
- 監査結果と継続判断の根拠を証跡として残す
生成AIガバナンスは、利用を止めるための仕組みではありません。
どのサービスに、誰が、何の情報を、どの権限で接続しているかを把握し、安全に使い続けるための経営管理です。
一般社団法人日本AIイノベーションセンター（JAIC）では、中小企業・自治体を対象に、生成AI利用規程、OAuthアプリ監査台帳、外部AI審査票、Google Workspace・Microsoft 365の権限管理、定期監査体制の構築を支援しています。
コメント