社内ツールがMicrosoft 365、Google Workspace、Slack、Jira、Confluence、Salesforce、さらには独自の社内システムへと細分化されるにつれ、企業のIT管理部門は深刻なセキュリティと業務効率のジレンマに直面します。従業員は分散した業務コンテキストを迅速に発見するために横断的なワークプレイス検索や生成AIアシスタントを求めている一方で、企業はアクセス権限の不備によるデータ漏洩を絶対に回避しなければなりません。役員報酬スプレッドシート、未公開の製品ロードマップ、法務コンプライアンス文書、人事の機密チケットなどが、権限を持たない一般従業員に露出することは許されません。
Gleanはこの課題を、パーミッションミラーリング（Permission Mirroring）、アイデンティティスティッチング（Identity Stitching）、そして**クエリ時アクセス検証（Query-Time Access Enforcement）**という3つの設計思想によって解決します。IT管理者がGlean内部で独立したアクセス制御リストを再構築する必要はなく、接続された各ソースシステムのネイティブなアクセス権限（ACL）をそのまま取り込んで厳密に適用します。
本ガイドでは、企業のIT管理者がデータソースコネクタの導入、IdP（IDプロバイダ）連携、ユーザーエイリアス統合、そして権限境界の検証を実施し、セキュアな統合検索環境を構築するための実践的な手順を解説します。
アーキテクチャの基本：Gleanが安全な統合検索を保証する仕組み
コネクタを設定する前に、IT管理者はGleanのデータガバナンスを支える3大中核メカニズムを理解しておく必要があります。
1. パーミッションミラーリング（Permission Mirroring）
Gleanはソースシステムと切り離された独自の権限データベースを持ちません。ネイティブコネクタがデータを取得する際、元システムに設定された権限体系も同時に抽出します。SharePointのネストされたフォルダ権限、Confluenceスペースのグループ制限、Salesforceレコードの共有ルールなど、すべてのACLルールがGleanの企業ナレッジグラフ（Enterprise Knowledge Graph）にそのまま反映されます。
2. 異種アカウントを束ねるアイデンティティスティッチング（Identity Stitching）
社内の複数ツールにおいて、同一従業員が全く同じアカウント識別子を使用しているとは限りません。Oktaでは jane.doe@enterprise.com であっても、Jiraでは jdoe、GitHubでは個人のハンドルネーム、M&A後の環境では旧ドメインのメールアドレスが混在している場合があります。GleanはプライマリIdPのディレクトリ属性をクロールすることで、各コネクタに点在するアカウントを同一人物の単一レコード（Person Record）へと安全に「縫い合わせ（スティッチ）」ます。
3. クエリ時およびパッセージレベルの権限強制（Query-Time & Passage-Level Enforcement）
従業員が検索を実行したり、Glean Assistantに質問を投げかけたりした際、Gleanはクエリ実行時にリアルタイムでアクセス権を検証します。
- 検索結果の除外： ソースシステムで閲覧権限がないファイルは、検索結果、プレビュー、推奨リンクから完全に除外され、その存在自体が隠蔽されます。
- 生成AIの参照制限（RAG）： Glean Assistantが回答を生成する際、質問したユーザーが実際に閲覧できる文書のみを根拠（Grounding）として使用します。一般従業員が業績見通しについて質問した場合、機密指定された経営陣向け資料を参照して回答を合成することは一切ありません。
- パッセージレベルの細粒度制御： 部分的なアクセス制限に対応するデータ形式では、ドキュメント全体は閲覧可能であっても、機密データを含む特定の段落やセクションのみを非表示にする制御が適用されます。
フェーズ1：IDプロバイダ（IdP）連携と管理者ロールの委任
導入の第一歩は、認証基盤の確立です。Gleanの導入ではシングルサインオン（SSO）が必須となっており、スケジュールされたユーザー属性クロール（People Data Crawl）によって組織階層と同期します。
SSOとIdPの設定
Glean環境ではSSOの有効化が義務付けられています。管理者は Admin Console > Users & permissions > Authentication から設定を行います。
- プロトコル： OpenID Connect（OIDC）およびSAML 2.0をサポートしています。きめ細かな権限管理とディレクトリ属性の安定した同期が可能なOIDCの採用が強く推奨されています。
- 対応IdP： Microsoft Entra ID（旧Azure AD）、Okta、Google Workspaceとの標準連携が用意されています。
管理者ロール階層と最小権限の原則
Gleanは権限分離のために以下の3つの管理者ロールを提供しています。
| ロール | 主な権限範囲 | 想定される担当者 |
|---|---|---|
| Setup Admin（設定管理者） | コネクタの接続と管理、クロール実行、SSO設定、Indexing APIトークンの発行、拡張機能統合の設定。 | 各SaaSの担当管理者（SharePoint管理者、Jira管理者など）。全体設定には触れずに自担当ツールの接続のみを担当。 |
| Admin（一般管理者） | 管理コンソールのフルアクセス、ユーザーロールの割り当て、UI/ホームページのカスタマイズ、グローバルスコープを除くAPIトークンの発行。 | 社内の中央ITエンジニア、システム管理者。 |
| Super Admin（特権管理者） | Adminの全権限に加え、機密データ検索（Admin Search）、DLP監査レポート、機密検出ログの閲覧、AIセキュリティ設定の管理。 | 最高情報セキュリティ責任者（CISO）、IT部門統括者、コンプライアンス責任者。 |
これらのロールは、個々のユーザーに直接割り当てるだけでなく、グループベースの権限（Group-based permissions） を通じて、IdP側のセキュリティグループ（例: Entra-IT-Admins）に直接マッピングすることが可能です。
フェーズ2：ユーザーエイリアスとアイデンティティスティッチング
横断検索を成立させるには、異なるツール上の jdoe による作成・閲覧ドキュメントを、主IdP上の正しい従業員に紐付ける必要があります。
ディレクトリクロールとエイリアスの抽出仕様
Gleanはディレクトリクロール時にIdPから属性を取得し、主メールアドレスをキーとして人物レコードを作成した上で、別名属性を「エイリアス」として登録します。
Microsoft Entra ID の属性マッピング
userPrincipalName： デフォルトの主メールアドレスとしてクロール。（主メールをmailに変更したい場合は、Gleanサポートにazure.useMailAsPrimaryEmailField=trueの設定変更を依頼可能）。mail： デフォルトでエイリアスとして自動クロール。proxyAddresses： デフォルトでエイリアスとして自動クロール。推奨ソース： Entra IDにおいてIT管理者のみが編集可能であり、マルチドメインやセカンダリアドレスを登録する最も安全な属性。otherMails： デフォルトでは無効（azure.crawlOtherMailsForAlias=trueの設定が必要）。
Okta の属性マッピング
email： 主メールアドレスとしてクロール。login： デフォルトでエイリアスとして自動クロール。proxyAddresses： AD/Entra連携や管理者マッピング属性として存在する場合、デフォルトでエイリアスとしてクロール（推奨属性）。secondEmail： デフォルトでは無効。
重大なセキュリティ警告：ユーザー編集可能属性によるなりすましリスク
[!WARNING] Entra IDの
otherMailsやOktaのsecondEmailは、テナント設定によってはエンドユーザーが自身のプロフィール画面から自由に追記・変更できます。もしこれらを無条件にエイリアスとして扱うと、悪意のあるユーザーや権限昇格を狙うユーザーが同僚や役員のメールアドレスを自身の予備メールに登録することで、他人のドキュメント閲覧権限を不正に奪取・継承してしまう脆弱性につながります。テナント全体で一般ユーザーによる編集が確実にブロックされていない限り、これらの属性をエイリアスソースとして有効にしてはなりません。常に管理者管理の
proxyAddressesを利用してください。
M&Aや複数ドメイン組織におけるベストプラクティス
- プライマリIdPの
proxyAddresses属性に、旧ドメインや別テナントのメールアドレスを網羅的に登録する。 - 移行済みの既存ユーザーだけでなく、新規採用者にも同様の属性付与ルールを適用し、未スティッチのアカウントを作らない。
- アップストリームのIdPで属性変更が困難な場合は、Glean管理コンソールのCSV一括アップロード機能をフォールバックとして活用する。
フェーズ3：データソースコネクタの設定
Gleanは多様な統合パターンを提供しています。
- Native Connectors（ネイティブコネクタ）： Google Drive、SharePoint、Slack、Jira、Confluence、Salesforce、GitHub、ServiceNowなど100以上のSaaSに対応。コンテンツとACLを自動抽出。
- Push API Connectors（プッシュ型APIコネクタ）： 社内ネットワーク内やオンプレミス環境にある独自開発ツール向け。Glean Indexing APIを用いて社内側からデータと権限を送信。
- Partner Connectors（パートナーコネクタ）： 外部ベンダーがGleanプラットフォーム向けに開発・保守するコネクタ。
- Web History Connectors（ブラウザ履歴コネクタ）： API非公開のツールに対し、ブラウザ拡張機能を介して個人の閲覧履歴のみをパーソナル検索対象とする。
コネクタ設定の標準ワークフロー
[1. コネクタハブで対象アプリを選択]
│
▼
[2. 前提要件とAPIスコープの確認]
│
▼
[3. 認証情報の入力と保存]
│
▼
[4. 「データ管理」での包含・除外ルール設定]
│
▼
[5. 初回フルクロールとインデックス作成]
│
▼
[6. パイロットテストグループによる権限検証]
ステップ1：コネクタハブでアプリを選択
Admin Console > Connectors > Connectors hub にアクセスし、対象アプリケーション（例: Confluence CloudやSharePoint）を選択します。
ステップ2：前提条件とアクセス権の確認
各コネクタの前提ドキュメントを確認します。
- サービスアカウントと権限： ServiceNowを接続する場合は
security_adminへの昇格とテーブルACLの付与が必要であり、Microsoft 365ではテナント管理者による承認が求められます。 - 最小特権スコープ： 読み取り専用スコープ（Microsoft Graphの
Sites.Read.AllやFiles.Read.Allなど）を使用します。検索インデックスの構築に書き込み権限は不要です。
ステップ3：認証とコネクタ設定の保存
Add connector をクリックし、インスタンスURL、OAuthクライアントシークレット、またはサービストークンを入力して設定を保存します。
ステップ4：「Manage Data」でインデックス対象を制御
保存後、Manage data タブでクロール範囲を調整します。
- 除外ルール： 機密性の高いSharePointサイトコレクション、法務・役員専用Slackチャンネル、アーカイブされたJiraプロジェクトなどを除外リストに設定します。
- アクセスモード： 高速な検索を実現する Indexed（インデックス型） または、リアルタイム性を重視する Live / Hybrid（ライブ・ハイブリッド型） を要件に応じて選択します。
フェーズ4：初回同期・インデックス構築と権限検証
設定を保存すると、コネクタは初期同期フェーズへと移行します。
同期の2つのフェーズ
- Crawling（クロールフェーズ）： ソースツールのAPIを呼び出し、文書本文、メタデータ（作成者、更新日時）、および関連するACL（ユーザー権限、グループ割り当て、共有リンク設定）を収集します。
- Indexing（インデックスフェーズ）： テキストの解析と埋め込みベクトルの生成、エンティティの関連付け、ソースアカウントとPeople Graphの紐付けを行い、セキュアなナレッジグラフを構築します。
所要時間はデータ量とAPIのレートリミットに依存します。進捗や同期件数は Admin Console > Connectors > Manage connectors でリアルタイムに確認可能です。
パイロットグループでの権限検証（最重要工程）
全社公開を行う前に、以下の検証を必ず実施します。
- テストグループへの公開制限： コネクタ設定で、検索の利用範囲をITテストグループや一部の先行ユーザーに限定します。
- 正常系テスト： 権限を持つ一般従業員アカウントでログインし、担当業務のファイルやチケットが正しく検索できることを確認します。
- 異常系テスト（非公開権限の厳格な検証）： 権限を持たないテストアカウントで、役員報酬資料や人事考課シートなどの機密ドキュメントを意図的に検索します。結果が0件であること、またGlean Assistantとの会話において該当文書の情報が一切漏洩・引用されないことを確認します。
- ツール実行権限の確認： AIアシスタント経由でチケット更新などのアクション（MCP連携）を有効にしている場合、操作が実行ユーザー本人の権限でのみ処理され、管理者がブロックしたツールが起動しないことを検証します。
フェーズ5：運用ガバナンス、同期監視、AI Agentの統制
安定した運用とセキュリティ基準の維持には、継続的な監視体制が不可欠です。
増量クロールとWebhookによる即時反映
初回フルクロール完了後、GleanはWebhookや増分クロールを活用して変更を検知します。主要なSaaSコネクタでは、元システムでの権限変更が数分以内にGlean側へ同期され、権限の陳腐化を防止します。
アラート監視と監査ログ
管理者は Notifications dashboard や Admin Alerts を定期的に確認し、OAuthトークンの期限切れやAPIレート制限のエラーを検知します。コネクタ設定の変更やロールの付与履歴は、すべて改ざん不可能な Audit Logs に記録されます。
モデルコンテキストプロトコル（MCP）とAgentガバナンス
自律型AIエージェントやMCPサーバーを展開する際：
- Gleanは、エージェントが指示元のユーザー権限を超えてデータを取得することを禁止します。
- 管理者は Admin Console > Tools からツールの利用を統制し、書き込みを伴う操作にはユーザー確認（Needs approval）を義務付けることで、意図しない自動更新を防止します。
企業IT管理者のためのベストプラクティスチェックリスト
- エイリアス属性の厳格な統制： Entra IDやOktaにおいて、エイリアス取得元を管理者管理の
proxyAddressesに限定し、一般ユーザー編集可能フィールドを無効化しているか。 - グループベースRBACの徹底： 個別のアカウント指定を避け、IdPのセキュリティグループを活用してSetup AdminやAdminロールを動的に割り当てているか。
- クロール前の除外設計： 本番クロールを実行する前に、Manage data で社内機密サイトや不要スペースをあらかじめ除外しているか。
- 非権限ユーザーによる遮断テストの徹底： 「見つかること」の確認にとどまらず、権限外ドキュメントが「完全に不可視であること」を多角的に検証したか。
- 認証情報の定期棚卸し： コネクタの接続状態と同期ログを定期監視し、APIトークンの失効による検索障害を予防できているか。
適切なID属性の設計、管理者ロールの委任、そしてGleanのパーミッションミラーリングを組み合わせることで、企業IT部門はセキュリティコンプライアンスを完全に維持しながら、組織のツール分断を解消することができます。