こんにちは、 ネクストモード株式会社 のSaaSおじさん久住です。
ネクストモードではID統合管理（IDaaS）のOktaを利用して各SaaSへのシングル・サインオンやプロビジョニングの一元管理をしています。
本記事では、Okta Identity Governance (OIG) の「アクセスリクエスト機能」を活用し、ユーザーからのGemini利用申請を承認フローに乗せ、一時的な利用を許可する仕組みを構築する方法をご紹介します。
OIGの様々な機能については下記ブログで紹介しておりますので、是非御覧ください！
昨今急速に普及する生成AIは、業務効率化の大きな可能性を秘めています。その一方で、Gemini (Google Workspace) やChatGPTなどの導入においては、情報漏洩、コンプライアンス違反、シャドーITといったセキュリティリスクが常に伴います。
多くの企業が「全面禁止」か「全面許可」など利用に関連する会社方針で悩んでいるかと思いますが、ビジネスの成長を止めないためには、リスクを管理しながら安全に活用する「ゼロトラストに基づいたガバナンス」が不可欠です。
今回のゴールは、「デフォルトではGemini利用を禁止し、申請・承認を得たユーザーのみ、指定された期間だけ特定の機能（今回はアプリ利用とDrive連携）を使えるようにする」ことです。
ユーザー: Oktaダッシュボードから「Gemini一時利用」を申請します。
承認者: 申請内容（利用目的など）を確認し、承認します。
Okta (OIG): 承認後、ユーザーを「Gemini利用許可グループ」に30日間だけ自動で追加します。
Okta (Provisioning): Oktaグループへの追加をトリガーに、Google Workspace側の特定グループにユーザーが追加されます (Group Push)。
Google Workspace: このグループに対し、Geminiの「アプリ利用」と「Drive利用」が有効化されています。
(30日後): ユーザーは「Gemini利用許可グループ」から自動で削除され、Geminiが利用できなくなります。
この仕組みにより、IT部門が手動で権限を付与・剥奪する手間をなくし、権限の削除漏れ（＝シャドーアクセス）を防ぎます。
Okta Identity Governance (OIG) のライセンスが有効であること。
OktaとGoogle WorkspaceがSAMLで連携され、プロビジョニング（Lifecycle Management）が設定済みであること。
Google Workspace側でGeminiが契約されており、組織単位 (OU) やグループ単位で機能のオン/オフが制御可能であること。
まずはじめに組織全体のGeminiの利用については、全てオフにしておきます。
次にGeminiの機能を制御する受け皿となるグループ（例: gemini-partial-users@example.com）を作成します。
このグループに対して、Geminiのサービス設定画面で以下のように制御をかけます。
Gemini (gemini.google.com) の利用: ON
Google Drive内のGemini機能 (要約など): ON
Gmail内のGemini機能: OFF
その他 (Meet, Chatなど): OFF
次に、Okta側でOIGのアクセスリクエストの対象となるグループ（例: OIG_Allow_Gemini_Temporary）を作成します。
そして、OktaのGroup Push機能を使い、Oktaの OIG_Allow_Gemini_Temporary グループのメンバーが、Google Workspaceの gemini-partial-users グループと同期するように設定します。
すでにGoogleグループは作成しているので「グループをリンク」で設定します。
Group Pushについての詳細を知りたい方は下記ブログをご参照ください。
ここがOIGの核となる部分です。
Okta管理画面の [Identity Governance] > [Access Requests] に移動し、Create request typeをクリックします。
「Gemini一時利用申請」というリクエストタイプを作成します
質問フォーム: 申請時に「利用目的」などをユーザーに入力させるフォームを定義します。
承認フロー: 「ユーザーのマネージャー」または「特定のIT管理者」が承認するステップを定義します。
リソースの定義: ユーザーが申請する対象として、Step 2で作成したOktaグループ OIG_Allow_Gemini_Temporary を指定します。
アクセス期間: 最も重要な設定です。承認されたアクセスが有効な期間（例: 30日間）を指定します。
詳細な設定内容は省略しますが、下記のようなフローを作成しました。
実際の動作について、今回は自分自身で体験してみます。
初期段階ではGoogle Workspace上でどのグループにも所属していません。
Geminiを利用できる権限も付与されていないため、Geminiアプリの画面にいっても、使えないことが確認できます。
Oktaダッシュボードの「アクセスを要求する」から「Gemini一時利用申請」を選択し、理由を書いて送信します。
マネージャーはOktaのダッシュボードやメール/Slack/Teams等で通知を受け取り、申請内容を確認して「Approve」します。
今回はSlack上で承認してみます。
Approveを押すとOktaグループ「OIG_Allow_Gemini_Temporary」に追加されたことが確認できました。
承認後、ユーザーはOktaグループに追加され、通常数分以内にGoogle Workspace側のグループへ同期され、Google Workspaceにログインし直すと、許可されたGeminiの機能（アプリとDrive）が使えるようになっています。
30日後、ユーザーは自動的にグループから除外され、Geminiの機能にアクセスできなくなります。
今回のような構成をOIGで組むことには、明確なメリットがあります。
ガバナンスの強化（最小権限の原則）
「必要な人」が「必要な理由」で「必要な期間」だけアクセスすることを強制できます。
ライフサイクル管理の完全自動化
IT部門が手動で行っていた権限付与・剥奪作業がゼロになります。特に「権限の削除漏れ」を完全に防ぐことができます。
監査対応（トレーサビリティ）
「誰が」「いつ」「なぜ」Geminiの利用を申請し、「誰が」承認したかのログ（証跡）がOIGに一元的に記録され、監査レポートも容易に作成できます。
セルフサービスによるUX向上
ユーザーはIT部門にチケットを発行する代わりに、Oktaからセルフサービスで申請でき、承認されればすぐに利用を開始できるため、利便性が向上します。
生成AIは「禁止」するのではなく、「管理」して活用する時代です。
Okta Identity Governance (OIG) は、Geminiのような強力な生成AIツールに対して、セキュリティと利便性を両立させるための「ガバナンスの効いた入り口」を提供します。
特に、権限の棚卸しや期限切れアクセス権の管理は、従来のIT運用において非常に工数がかかる部分でした。
OIGのアクセスリクエストと自動化されたライフサイクル管理は、生成AI時代のセキュリティ対策において非常に強力なソリューションとなります。