GWS 二段階認証 未設定ユーザーをDifyで自動検出する

Google Workspace (GWS) の Admin Directory API Users リソースには、二段階認証（2SV: 2-Step Verification）の登録・強制状況を返す専用フィールドが用意されています。この記事では、そのフィールドを起点に「未設定ユーザーの自動検出→通知」パイプラインを Dify（LLMワークフロープラットフォーム）で設計するアプローチと、GAS・n8n との使い分けの判断軸を整理します。

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

• GWS で二段階認証を推奨または強制設定にしているが、未設定ユーザーの月次チェックが手作業になっている情シス担当者
• GAS（Google Apps Script）以外の自動化ツールを探しており、Dify や n8n との使い分けを整理したい方
• Admin Directory API を活用したコンプライアンス監査の自動化に関心がある方

月次チェックが手作業になりやすい理由

GWS の管理コンソールで「二段階認証を推奨または強制」に設定しても、実際に全ユーザーが設定を完了しているかどうかは別の話です。管理コンソールのレポート画面から手動で CSV をエクスポートし、スプレッドシートでフィルタリングして未設定者に個別メールを送る——この作業を月1回こなしている情シスは少なくありません。

手順を分解すると「エクスポート→ファイル開く→フィルタ設定→リスト抽出→メール作成→送信確認」と、ざっと6〜8ステップになります。慣れていても30分以上かかる場合があり、継続的に未設定者が発生する組織では無視できません。

作業自体は難しくありませんが、属人化しやすい性質があります。担当者の休暇・異動で継続が途切れるリスクに加え、GAS でスクリプト化したとしても、OAuth 認証トークンはパスワード変更や管理者による取り消し時に失効するため、スクリプトの動作維持に定期的な確認が必要です。「動いていたスクリプトが失敗した」「エラーメールに気づかず2ヶ月放置していた」という状況は、規模を問わず情シス現場で繰り返されるパターンです。

さらに重要なのは、未設定ユーザーが放置されるセキュリティリスクです。二段階認証が未設定のアカウントは、パスワード漏洩時の不正ログインに対して無防備な状態になります。月次チェックが機能しない期間があるたびに、その窓口が広がります。

Admin Directory API で二段階認証の登録状況を確認する

Admin SDK（Admin Directory API）の Users リソースには、2SV に関連するフィールドが 2 つ含まれています。

フィールド名	型	意味
isEnrolledIn2Sv	boolean（出力のみ）	ユーザーが 2 段階認証を登録済みかどうか
isEnforcedIn2Sv	boolean（出力のみ）	ユーザーに 2 段階認証の強制が適用されているかどうか

どちらも読み取り専用フィールドです。API を通じて書き換えることはできません。

この 2 つのフィールドを組み合わせて読むと、ユーザーの状態をより正確に把握できます。

isEnrolledIn2Sv	isEnforcedIn2Sv	実際の状態
true	true	強制対象かつ設定済み（理想状態）
true	false	任意で設定済み（問題なし）
false	true	強制対象だが未設定（最優先で連絡すべき）
false	false	強制対象外かつ未設定（推奨設定組織では要注意）

監査の中心になるのは isEnrolledIn2Sv: false のユーザーです。特に isEnforcedIn2Sv: true との組み合わせは、組織ポリシー上の強制が有効であるにもかかわらず未設定という矛盾した状態なので、優先的に対処する必要があります。

Users リソースの取得には Admin SDK Directory API を利用します。任意の HTTP クライアントや SDK からアクセスでき、組織全体または特定の OU（組織部門）を対象にユーザー一覧を取得して isEnrolledIn2Sv の値で絞り込む設計が基本的な流れです。なお、外部サービスからこの API を呼ぶには、GWS ドメインでサービスアカウントの認証設定（ドメイン全体の委任: Domain-Wide Delegation を含む設定）が必要です。また、ユーザー数が多い組織ではレスポンスがページネーションされるため、全件を取得するロジックを設計段階で考慮する必要があります。

GAS・Dify・n8n の使い分け：どのツールが適切か

「GAS で書けばよいのでは」という選択肢は当然あります。一方、ツールごとに向き・不向きがあり、ユースケースに合わせた選択が運用コストを左右します。

MFA コンプライアンスチェックという用途で比較すると、以下の表が参考になります。

比較軸	GAS	Dify	n8n
導入コスト	GWS に内包・追加費用ゼロ	セルフホストまたはクラウドプランが必要	セルフホストまたはクラウドプランが必要
コーディング量	JavaScript で全体を記述	ノード組み合わせで最小限	ノード組み合わせで最小限
AI 処理の組み込み	別途 LLM API 呼び出しを実装	LLM 処理がネイティブ統合	プラグインで対応可能
認証トークン管理	OAuth 設定を自分で定期的に維持	クレデンシャルをノードで集中管理	クレデンシャルを一元管理
向いているケース	既存 GAS 資産がある / LLM 不要の軽量タスク	AI 要約・判定・文面生成を加えたい場合	複数システム連携が主な場合

各ツールのデメリットも整理しておきます。

GAS のデメリット: OAuth トークンの有効期限切れで定期実行が静かに失敗するリスクがあります。スクリプトエディタ上での管理になるため、チームでのバージョン管理・引き継ぎが難しくなりやすい点も注意点です。

Dify のデメリット: セルフホスト版はサーバー管理が必要で、小規模情シスにとってはインフラ維持コストが課題になります。クラウドプラン（Dify Cloud）を使うとコストが発生しますが、管理の手間は大幅に軽減されます。

n8n のデメリット: LLM を活用した柔軟なテキスト生成は Dify よりも設定が煩雑になりやすく、「通知文を AI で動的に生成したい」用途では Dify のほうがシンプルです。

判断の基準を一言でまとめると、「AI 処理を組み込む必要があるかどうか」で Dify か否かを判断し、LLM が不要なら GAS（既存資産がある場合）か n8n（多システム連携が多い場合）を選ぶのが合理的です。

Dify ワークフローの設計パイプライン

Dify のワークフローノードで構成するパイプラインの概念設計は以下の通りです。

ステップ 1：トリガー

月次スケジュール（または手動実行）でワークフローを起動します。Dify のスケジューラー機能を使うか、外部 cron ジョブから Dify の API エンドポイントを叩く構成のどちらでも実現できます。

ステップ 2：Admin Directory API へのリクエスト

認証済みの認証情報（サービスアカウントの秘密鍵や OAuth トークン）を Dify の変数として安全に保管し、HTTP リクエストノードから Admin SDK を呼び出します。対象ドメインのユーザー一覧を取得し、isEnrolledIn2Sv: false のユーザーを抽出したリストを変数に格納します。ページネーション対応が必要な場合は、繰り返しノードを使って全件取得するループ設計にします。

ステップ 3：条件分岐

抽出された未設定ユーザー数が 0 件であれば「今月は全員設定済み」という正常終了メッセージのみを情シス向け Chat スペースに送って完了します。1 件以上であれば次のステップへ進みます。この条件分岐を入れることで、毎月のノイズを排除し、実際に対応が必要なときだけ詳細通知が届く設計になります。

ステップ 4：LLM 処理（任意）

未設定ユーザーのリスト・所属 OU・前回チェックからの経過日数などを変数として LLM ノードに渡し、通知文を自動生成させます。具体的には「ユーザーの所属部門や在籍日数に応じて連絡のトーンを変える」「複数ユーザーをまとめた管理者向けサマリーを生成する」といった判断を LLM に委ねられます。このステップは省略可能で、固定テンプレートの通知文で十分な場合は LLM ノードをスキップする設計にしても問題ありません。

ステップ 5：通知送信

Google Chat の Incoming Webhook URL または Gmail API 経由で通知を送ります。詳細は次のセクションで解説します。

各ノード間のデータは変数として引き渡せます。API レスポンスの JSON をそのまま LLM ノードに渡すことも、整形してから渡すことも設計の選択肢です。n8n で同じパイプラインを構成する場合、ステップ 4 の LLM 処理を省いたシンプルな構成であれば n8n のほうが設定が直感的です。まず動かすことを優先するなら n8n から始め、AI 処理が必要になったタイミングで Dify に移行する判断も合理的です。

通知先の設計：Google Chat か Gmail か

通知先の設計では「情シス担当者への報告」と「未設定ユーザー本人への連絡」を分けて考えます。

情シスへの報告には Google Chat Webhook が最適です。Chat スペースの管理設定から Incoming Webhook URL を発行し、Dify の HTTP ノードで JSON ペイロードを POST するだけで完結します。メッセージには未設定ユーザーの件数・氏名・所属 OU・前回からの経過日数などを含めると、情シスが次のアクション（本人連絡・管理コンソールでの状態確認）をすぐに取れます。

メッセージフォーマットの設計で気をつける点は「情報の優先度」です。未設定者が 10 名いる場合、全員の名前を羅列するより「強制対象かつ未設定が 3 名、推奨対象かつ未設定が 7 名」のようにカテゴリ別に集計した情報のほうが、情シスの判断コストが下がります。LLM ノードを使う場合は、このような集計サマリーの生成も合わせて委ねられます。

ユーザー本人への通知には Gmail API 経由のメール送信が一般的です。月次頻度で 100 名未満の組織であれば API のレート制限に引っかかる可能性は低いものの、送信ロジックが複雑になりやすいため注意が必要です。特に「一度送ったユーザーには X 日間は再送しない」という制御をワークフローに組み込む場合、送信済みユーザーのリストを外部（スプレッドシートや Dify 変数）に保持する仕組みが別途必要になります。

実務的な進め方として、まず「情シスへの Chat 通知」から始め、運用が定着してから「本人通知」に拡張する段階的なアプローチが現実的です。一度にすべての機能を実装しようとすると、設計が複雑になり途中で止まるリスクがあります。

導入前に確認すべき前提と注意点

設計を始める前に、以下の点を確認します。

Admin Directory API の認証設定の確認

外部サービスから Users リソースを参照するには、GWS ドメインでサービスアカウントへのドメイン全体の委任を有効にする設定が必要です。管理コンソールのセキュリティ設定から確認できます。この設定変更は GWS 管理者権限が必要なため、権限の有無を事前に確認してください。また、委任を付与するサービスアカウントには最小権限の原則を適用し、Users リソースの読み取りに必要なスコープのみを付与します。

Dify の認証情報管理の方針決定

API 認証情報はセルフホスト環境の場合、環境変数や Dify の組み込みシークレット管理機能を使います。クレデンシャルをワークフローのノードに直接ハードコードするのは避けます。クラウドプランであれば Dify 側のシークレット管理機能を活用できます。

段階的なテスト実行の計画

初回の実行は本番環境で全ユーザーを対象にせず、テスト用のサブドメインや少数の OU を対象に絞った動作確認から始めます。API の認証が通るか・レスポンスの JSON を正しくパースできるか・条件分岐が期待通り動くかを順番に確認していきます。

GAS や n8n への切り替え余地の確保

Dify を採用してみたものの「LLM が不要だった」「インフラ管理が想定以上に重かった」と判断した場合に、n8n や GAS へ切り替えやすい設計を維持することが重要です。処理の論理（ユーザー取得→絞り込み→通知）をシンプルに保ち、Dify 固有の複雑な機能に依存しすぎない構成にしておくと、切り替えコストを抑えられます。

手作業の脱却から継続的なコンプライアンス監視へ

月次の手作業を自動化した先にあるのは、単なる工数削減ではありません。「未設定が発生した瞬間に検知・通知する」仕組み、つまり月次から週次・日次へのサイクル短縮が視野に入ります。

自動化の成熟度を段階的に整理すると、次のようなフェーズで考えられます。

フェーズ 1（最小構成）: 月次スケジュールで未設定ユーザー一覧を情シス Chat スペースに通知する。所要工数はゼロになります。

フェーズ 2（本人通知の追加）: 情シスへの通知に加えて、未設定ユーザー本人へのリマインドメールを自動送信します。LLM で文面をパーソナライズすることで、定型メールより高い対応率が期待できます。

フェーズ 3（週次サイクル化＋履歴管理）: スケジュールを週次に短縮し、対応済みユーザーをスプレッドシートに記録して追跡できるようにします。未設定日数が一定期間を超えたユーザーは上長も含めて通知するエスカレーション設計を加えます。

フェーズ 4（継続的監視）: 新規ユーザーが作成されたタイミングでも監視をトリガーし、オンボーディング段階から二段階認証を確認する仕組みを構築します。

GWS のセキュリティ自動化を定着させる鍵は、一気にフェーズ 4 を目指すのではなく、フェーズ 1 で動かして現場の受け入れを確認してから次に進む進め方です。MFA 未設定ユーザーの自動通知は、その出発点として取り組みやすいユースケースです。

自動化が定着すると「いつでも現状を把握できる」という副次的な効果があります。監査対応時に「現時点で二段階認証が未設定のユーザー数は？」という問いに即答できる体制は、内部統制の観点からも価値があります。

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

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