DifyのGWS API連携：OAuthスコープ最小化と監査設計

社内 AI ツールとして Dify（LLM アプリケーション開発プラットフォーム）を Google Workspace API（以下 GWS API）に接続する企業が増えています。ただし、Dify Google Workspace OAuth スコープ最小化の観点が後回しになりやすく、管理コンソールとの統合まで対応が追いついていないケースも少なくありません。この記事では、スコープ設計・管理コンソール統合・監査ログの可視化という 3 つのフェーズに沿ったガバナンス設計の考え方を整理します。

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

社内に Dify を導入済みまたは導入を検討していて、GWS API との連携を計画している情シス担当者
連携時の OAuth スコープが適切かどうか確認・見直したい方
管理コンソールの API アクセス制御を使って Dify を組織管理の対象に組み込みたい方
GWS の監査ログで社内 AI ツールの利用実態を継続的に把握したい方

Dify の GWS API 連携で起きやすい過剰権限の問題

Dify を GWS API に接続する際、設定を急ぐと OAuth スコープが必要以上に広がりやすい傾向があります。典型的なパターンは 3 つです。

Gmail の全権限スコープで連携してしまうケース。 「メールを読んで要約する」だけの用途であっても、送信・削除・フィルタ設定変更まで含む全権限スコープで接続されているケースがあります。Dify のワークフロー上では「読む」しか使っていなくても、付与された権限は有効なままです。OAuth トークンが漏洩した場合、送信元を偽装したフィッシングメールの送信や、受信トレイのフィルタ書き換えが第三者から可能な状態になります。

Drive の書き込み権限が不要な用途でも付与してしまうケース。 ファイル内容をコンテキストに使うだけなら読み取り専用で十分です。ところが、セットアップ時に Dify が提示するデフォルトのスコープをそのまま承認すると、Drive 全体への書き込み権限が付与された状態が標準として定着し、見直されないことが多いです。組織全体のファイルに書き込み権限があれば、ワークフローのバグや設定ミスで意図しないファイル更新・削除が発生するリスクもあります。

社員が個人で OAuth 認証して、管理者が把握できていないケース。 Dify のコネクター設定はユーザーが自分のアカウントで OAuth 認証すれば完了できます。管理コンソール側での制御が届いていない場合、情シスは「誰がどのスコープで接続しているか」を把握できません。社員数が増えるほど、非公式な接続が組織内に積み重なっていきます。

なぜ見直されないのか

これらの問題が放置されやすい最大の理由は、「動いている状態」が問題の表面化を遅らせることです。設定が不適切でも Dify は正常に動作するため、情シスが気づく機会がありません。棚卸しの契機は、セキュリティインシデントの発生か、内部監査の実施か、外部から「このアプリはどんな権限を持っているか」と問われたときです。この 3 パターンのいずれも後手に回らないよう、連携の設計段階から権限を絞る習慣が重要です。

OAuthスコープ最小化の判断基準：GWSサービスごとの最小権限

Dify に付与する GWS の OAuth スコープは、そのワークフローが何をする目的で使うか を起点に選びます。「書き込みが必要かどうか」だけでなく、「どこまでの範囲を書き込むか」という粒度まで絞るのが原則です。

GWS サービス	過剰スコープの例（NG）	推奨する最小スコープの範囲	過剰な場合のリスク
Gmail	送信・削除・フィルタ変更を含む全権限	読み取り専用（メール情報取得のみ）	なりすまし送信・受信トレイ改ざん
Google Calendar	イベント作成・削除・招待送信を含む全権限	読み取り専用（空き時間参照のみ）	会議の無断設定・予定情報の漏洩
Google Drive	全ファイルの読み書き・共有設定変更	アプリが作成したファイルに限定 or 読み取り専用	組織全体のファイル閲覧・外部共有設定の変更
Google Sheets	スプレッドシートの全読み書き	特定シートの読み取りのみ	財務・人事データの改ざんリスク
Google Chat	メッセージ送受信・スペース管理の全権限	メッセージ送信のみ（通知ボット用途など）	スペース設定変更・メッセージ閲覧の乱用

スコープを選ぶ前の 3 つの問い

スコープの選定で迷ったときは、以下の 3 問に順番に答えると判断しやすくなります。

このワークフローはデータを書き換える必要があるか？ → NO なら読み取り専用スコープ一択
書き換えが必要な場合、対象範囲はユーザー個人のデータか組織全体か？ → 個人データのみなら drive.file（アプリが作成したファイルのみ）で足りる場面が多い
将来的に機能を拡張する予定があるか？ → 「将来のために広めに取っておく」は禁止。拡張が確定した時点でスコープを追加する方針に統一する

GWS API の各サービスには段階的なスコープが用意されており、Google Workspace API の公式ドキュメントで各サービスのスコープ一覧を確認できます。最初から全権限スコープを選ばなくてよい設計になっているため、「必要なものだけ選ぶ」を徹底できます。

サービスアカウントを使う場合の追加注意点

ユーザー個人の OAuth 認証ではなく、サービスアカウントにドメイン全体への委任（Domain-Wide Delegation）を付与して使う構成もあります。この場合、付与したスコープが「組織全体のデータ」に対して有効になるため、スコープ設計のミスが影響する範囲は格段に広がります。サービスアカウントへの委任は、組織全体を対象にする処理（例: 全ユーザーのカレンダーを参照して会議室の空き状況を集計するなど）でなければ採用せず、ユーザー OAuth に留めることを検討してください。

管理コンソールの API アクセス制御で Dify を組織管理に組み込む

OAuth スコープを絞っても、そのアプリを「組織として認可している」状態に明示的にしなければ管理の空白は残ります。GWS の管理コンソールには、サードパーティアプリが GWS API にアクセスすることを許可・制限・ブロックするための API アクセス制御機能があります。

この機能を使って Dify の GCP プロジェクト（OAuth クライアント ID）を信頼できるアプリとして登録すると、管理者が「このアプリに、このスコープだけを許可する」という状態を一元管理できます。登録していない状態では、ユーザーが個別に OAuth 認証してしまい、情シスが把握できないまま接続が広がる可能性があります。

設定の方針として押さえておきたい点は 3 つです。

信頼するアプリを明示的に登録する。 Dify のクライアント ID を信頼できるアプリとして追加した上で、許可するスコープを絞ります。この状態にすると、それ以外のスコープはユーザーが要求しても GWS 側でブロックできます。クライアント ID は Dify の GCP プロジェクトの認証情報から確認できます。

ブロックと制限の使い分けを決める。 組織で使うことが確定しているアプリは「信頼」に設定し、把握できていないアプリは「制限あり」か「ブロック」にします。方針を決めておかないと、野良接続が増えても検知できません。「新規アプリは全てデフォルトでブロック、申請ベースで信頼登録する」というフローにすると、ガバナンスが安定します。

OU（組織部門）単位で適用範囲を設計する。 全社員に同一の制御を適用するのではなく、開発チームや IT 部門だけ許可する形でも設定できます。Dify の用途が特定部門に限られるなら、段階的に拡大する方針が安全です。たとえば初期は IT 部門のみで運用し、安全性が確認できた段階で営業部門・カスタマーサポート部門へと拡大する流れが現実的です。

API アクセス制御の詳細な操作方法は、Google Workspace 管理者ヘルプのセキュリティ関連セクションに掲載されています。

GWS の監査ログで Dify の利用実態を可視化する

スコープを絞り、アプリを信頼登録した後も「実際にどのデータにアクセスされているか」を継続的に確認する仕組みが必要です。GWS の Admin SDK Reports API を使うと、OAuth トークンの発行・利用履歴を参照できます。

以下は Google Apps Script（GAS）を使って、過去 7 日間の OAuth トークン認可イベントを取得し、スプレッドシートに記録するサンプルコードです。実行には管理者権限を持つアカウントと、GAS の「管理者サービス（Advanced Services）」での Admin SDK の有効化が必要です。

/**
 * 過去7日間のOAuthトークン認可イベントを取得してスプレッドシートに記録する
 * Admin SDK Reports API の token アプリケーションを参照
 */
function listRecentTokenEvents() {
  var startTime = new Date();
  startTime.setDate(startTime.getDate() - 7);

  var options = {
    startTime: startTime.toISOString(),
    eventName: 'authorize'
  };

  var response = AdminReports.Activities.list('all', 'token', options);
  var items = response.items || [];

  // 結果の書き込み先シートを取得（なければ作成）
  var ss = SpreadsheetApp.getActiveSpreadsheet();
  var sheet = ss.getSheetByName('OAuthログ') || ss.insertSheet('OAuthログ');
  sheet.clearContents();
  sheet.appendRow(['日時', 'ユーザー', 'クライアントID', 'スコープ']);

  items.forEach(function(item) {
    var events = item.events || [];
    events.forEach(function(event) {
      var params = {};
      (event.parameters || []).forEach(function(p) {
        params[p.name] = p.value;
      });
      sheet.appendRow([
        item.id.time,
        item.actor.email,
        params['client_id'] || '(不明)',
        params['scope']    || '(不明)'
      ]);
    });
  });

  Logger.log('記録完了: ' + items.length + '件のイベントを取得');
}

このスクリプトを実行すると、「いつ・誰が・どの OAuth クライアントに・どのスコープを付与したか」がスプレッドシートに記録されます。Dify のクライアント ID でフィルタリングすれば、新規接続ユーザーや想定外スコープの付与を早期に検知できます。GAS のトリガー機能で週次または月次の定期実行に設定しておくと、確認漏れを防げます。

監査ログで検知できるシグナル

トークンイベントのログを定期的に確認していると、以下のシグナルを検知できます。

想定していないユーザーが Dify に OAuth 認証している（野良接続の早期発見）
管理者が制限したはずのスコープが含まれているトークンが存在する（設定の抜け漏れ確認）
特定ユーザーやクライアントの認可頻度が急増している（乗っ取りやクレデンシャル漏洩の兆候）
深夜・休日など業務外の時間帯に認可イベントが発生している（不審な自動処理の兆候）

異常を発見した場合は、管理コンソールのセキュリティ設定からトークンを失効させてアクセスを遮断できます。

月次レビューのフロー設計

監査ログを「見るだけ」にしないために、月次レビューのフローをあらかじめ決めておきます。フローの最低限の要素は次の 3 点です。

スプレッドシートのダウンロードと前月比較: 新規クライアント ID や新規スコープが増えていないかをチェックする
想定外の行を確認してチケット起票: 情シスが把握していないアプリは申請フローを経由させるか、管理コンソールでブロックする
結果を記録して次回と比較: 「前月と変化なし」という記録自体が監査証跡になる

3フェーズで整えるガバナンス設計：着手すべき順序

ここまで解説した内容を、実際に整備していく順序としてまとめます。この 3 フェーズには依存関係があり、順番を前後させると設計の矛盾が生じます。

フェーズ 1：スコープ設計（連携設定前）

Dify と GWS API を接続する前に、ワークフローごとに「必要なスコープの最小範囲」を定義します。成果物として「Dify × GWS API スコープ設計書」を 1 枚用意しておくと、後から追加連携が発生したときの判断基準になります。設計書には、ワークフロー名・対象 GWS サービス・選択したスコープ・選定理由の 4 列を最低限記載します。

この段階を飛ばして接続だけ先行させると、フェーズ 2 で「どのスコープまで許可すべきか」の判断基準がなくなります。

フェーズ 2：管理コンソール統合（連携設定と同時）

Dify のクライアント ID を管理コンソールの API アクセス制御に登録し、許可するスコープをフェーズ 1 の設計書に合わせて明示的に設定します。この手順を後回しにすると、ユーザーが個別に接続を増やしても管理者側からの可視性がありません。

また、「この Dify ワークフローは IT 部門のみ使用可」のような制限を OU 単位で設定するのもこのフェーズです。設定完了後、テストアカウントで接続を試みて「想定外のスコープが承認できないこと」を確認しておくと安心です。

フェーズ 3：監査ルーティン（連携設定後・継続的に）

Reports API を使った定期チェックを運用に組み込みます。月 1 回は「想定外のスコープや接続ユーザーがいないか」を確認するフローを作り、スプレッドシートへの書き出しや通知と組み合わせます。このフェーズは一度設定すれば自動化できるため、継続コストを最小化できます。

よくある落とし穴

フェーズ 3 だけ実施しているパターン。 監査ログを確認する習慣はあるが、管理コンソールへのアプリ登録が未完成なため、発見した問題を管理コンソールで対処する手段が整っていないケースです。検知しても対処できない状態は「監査している安心感」だけがあって実効性がありません。

フェーズ 2 で全スコープを許可しているパターン。 管理コンソールに Dify を登録したものの、許可するスコープを絞らずに「全スコープ信頼」で登録してしまうケースです。登録すること自体は正しい判断ですが、スコープの絞り込みがなければフェーズ 1 の設計が反映されません。

Dify の GWS 連携は「動かす」より「管理できる状態にする」が本来の完成形です。3 フェーズを連携設定と並行して整えておけば、その後の運用コストは大幅に下がります。

まとめ：今すぐ取り組めること

設計全体を一度に整えるのが難しい場合、まず以下の 3 点から着手します。

現在 Dify に付与している GWS API のスコープを一覧化し、「読み取り専用で足りるもの」を特定する
管理コンソールのセキュリティ設定から、Dify のクライアント ID が登録済みかどうかを確認する
GAS で Reports API のトークンイベントを 1 回だけ取得し、想定外の接続がないかを確認する

この 3 点だけでも現状把握の精度は大きく変わります。Dify × GWS の連携ガバナンス設計については、DRASENASのコーポレートIT支援サービスでも相談を受け付けています。

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

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

CONTACT

御社の IT 部門、ここにあります。

「ITのことはあまりわからない」── そのような状態からで、まったく問題ございません。まずはお気軽にご相談ください。

無料相談を予約する → サービス詳細を見る

一社ずつ、一から。