社内全体で生成 AI アシスタント（AI Agents / Assistants）を展開するにあたり、企業の IT 管理者やセキュリティ・コンプライアンス担当者は深刻なジレンマに直面しています。社内ナレッジベースと連携した自然言語 AI は生産性を飛躍的に高める一方、従来の検索拡張生成（RAG）アーキテクチャでは、部門を跨いだ致命的なデータ漏洩（Cross-Department Data Leakage）のリスクが常に潜んでいるためです。たとえば、マーケティング部門の一般社員が社内共通 AI に向かって「先月承認された役員報酬の改定内容を教えて」あるいは「ベンダーとの法廷闘争に関する機密訴訟戦略を要約して」と入力した場合、単一のベクトルストアからデータを取得する設計では、本来閲覧権限のない機密文書が容易に抽出・要約されてしまいます。
「給与に関する話題は答えないこと」といったプロンプトによる指示（Prompt Guardrails）は、巧妙なプロンプトインジェクションや婉曲的な質問、文脈の言い換えによって容易に突破されます。エンタープライズ環境におけるデータ分離は、大規模言語モデル（LLM）のコンテキストウィンドウに未承認データが絶対に投入されないよう、アーキテクチャレベルで確定的（Deterministic）に強制されなければなりません。
Dust は、Spaces（データ分離コンテナ）、ロールベースアクセス制御（RBAC）、SCIM を用いた IdP（Identity Provider）ディレクトリ同期、およびコネクタ単位のスコープ制御を組み合わせた独自の**2層権限モデル（Dual-Layer Permission Model）**によってこの課題を根本から解決します。本稿では、企業 IT 管理者が Dust Spaces と権限マトリクスを体系的に設計し、部門間の情報漏洩を完全に防ぐカスタム AI アシスタント環境を構築する手順を解説します。
1. 根幹となる仕組み：Dust の 2 層権限モデル
部門間のデータ漏洩を防ぐためには、まず「エージェントがデータにアクセスする権限」と「人間がエージェントを利用する権限」を明確に分離して理解する必要があります。従来の SaaS ツールは「ユーザー X が文書 Y を閲覧できるか」という単一レイヤーの権限モデルを採用していましたが、自律型 AI エージェントがユーザーに代わって複数文書を横断検索・要約する環境では、この前提が通用しません。
Dust は以下の 2 層権限モデルを採用しています。
[ 外部データソース (Google Drive, SharePoint, Slack, Notion) ]
│
▼ (管理者によるスコープ制限と専用サービスアカウント)
[ Dust Connections (接続) ]
│
▼ (管理者が割り当てた特定データサブセット)
┌──────────────┴──────────────┐
▼ ▼
[ Open Spaces (公開) ] [ Restricted Spaces (制限) ]
(例: Company Data) (例: 財務, 法務, 人事)
│ │
▼ ▼
[ 全社共通エージェント ] [ 部門専用制限エージェント ]
│ │
▼ ▼
(ワークスペース全メンバー) (当該制限 Space の所属メンバーのみ)
▲ ▲
└──────────────┬──────────────┘
│
[ ユーザーとグループ ]
(IdP / SCIM により自動同期)
レイヤー 1：エージェントからデータへのアクセス（データ境界の隔離）
Dust でエージェントを構築する際、そのナレッジ検索およびツール実行権限は、指定された Spaces に厳密に紐付けられます。たとえば「技術サポート Space」と「Company Data」のみを参照するように設定されたエージェントは、技術的・物理的に「財務 Space」や「法務 Space」のベクトルインデックスを検索する手段を持ちません。この境界線はデータベースおよび検索レイヤーで強制されるため、未承認の文書チャンクが LLM の推論パイプラインに渡ることはありません。
レイヤー 2：人間からエージェントへのアクセス（デフォルト安全の可視性制御）
Dust には確立された原則があります。それは「エージェントが使用する Space によって、そのエージェントを閲覧・利用できるユーザーが決定される」という点です。デフォルト設定では、ユーザーはエージェントが依存するすべての Space に対するアクセス権を保持していない限り、そのエージェントをワークスペース上で検索・表示・呼び出しすることができません。
財務部門専用の Restricted Space を参照するエージェントが存在する場合、財務部門に属していない一般社員の画面上には、そのエージェント自体が表示されません。これにより、権限のないユーザーが高権限エージェントを踏み台にして社内機密を引き出す「プロキシ型インジェクション攻撃」を根本から防止します。
2. Spaces 設計戦略：公開ドメインと制限ドメインの分離
Dust では、すべてのナレッジ、文書、統合ツールが Spaces というコンテナに格納されます。空間構造を正しく設計することが、データ漏洩防止の基礎となります。
Open Spaces と Restricted Spaces の比較
| 項目 | Open Spaces（例: Company Data） | Restricted Spaces（制限付き空間） |
|---|---|---|
| 参加メンバー | ワークスペースの全メンバーが自動参加 | 指定された個別ユーザーまたは IdP 連携グループ（SCIM） |
| 管理権限 | ワークスペース管理者（Admin）のみ | ワークスペース管理者（Admin）のみ |
| 外部接続データ | 管理者が選択した全社共通ファイル・チャンネル | 管理者が部署ごとに選別した高機密ファイル・サイト |
| ネイティブデータ（フォルダ・URL） | 管理者および Builder のみ追加可能 | 当該制限 Space の全メンバーが追加可能 |
| 関連エージェントの可視性 | ワークスペースの全社員に表示・利用可能 | 当該制限 Space の権限保持者のみに表示・利用可能 |
| 主な用途 | 全社就業規則、福利厚生案内、公開製品仕様 | 給与明細、取締役会議事録、訴訟戦略、M&A 関連資料 |
Company Data の役割と運用上の鉄則
すべての Dust ワークスペースには、デフォルトで Company Data という Open Space が備わっています。
- この Space は全社員に常時開放されており、削除、名前変更、アクセス制限の付与はできません。
- Company Data に格納された文書は、全社デフォルトエージェント（
@dustなど）から即座に検索可能になります。 - IT 管理者の鉄則： 財務諸表のドラフト、役員専用の Slack チャンネル、人事考課シートなど、機密性の高いデータを Company Data に紐付けてはなりません。ここは「社内掲示板に貼り出せる公開情報」専用の領域として運用してください。
プラン別 Space 作成上限
- Business プラン： 最大 5 つの Spaces を作成可能。組織階層が比較的フラットで、基礎的な分離（Company Data、経営陣、開発、営業、オペレーション等）を必要とする企業に適しています。
- Enterprise プラン： 最大 100 の Spaces を作成可能。法務レビュー、役員給与、内部監査、M&A 推進など、プロジェクトや部門単位での厳格な隔離を要するエンタープライズ企業向けです。
3. 実装の 6 ステップ：セキュアな AI アシスタント環境の構築手順
部門間データ漏洩ゼロを実現するため、IT 管理者は以下の手順に沿って Dust の初期構成とガバナンス設定を進めます。
ステップ 1：SCIM 2.0 による IdP ディレクトリ同期の確立
手動でのユーザー管理は、権限の陳腐化や退職者の権限残存リスクを招きます。Enterprise プランでは、主要 IdP（Okta、Microsoft Entra ID、Google Workspace 等）との SCIM 連携を最優先で実施します。
- Dust 管理画面から Admin > Organization > Members > Groups > User provisioning > Set up Directory sync を開きます。
- ご利用の IdP を選択し、SCIM 2.0 連携手順を完了させます。
- 部署単位のグループ（例:
dept-finance、dept-legal、dept-hr、exec-board）を Dust へプッシュ配信するよう設定します。 - これにより、異動や退職が発生した際、IdP 側の変更が即座に Dust へ反映されます。財務部から他部署へ異動した社員は、その瞬間に財務 Restricted Space および財務エージェントへのアクセス権を失います。
ステップ 2：専用サービスアカウントによるソースシステムのスコープ最小化
Dust のデータコネクタ（Google Drive、Microsoft SharePoint/OneDrive、Notion、Confluence、Slack など）は外部の業務システムと直結します。接続時のリスクを排除するため、以下を徹底してください。
- 個人の管理者アカウントを使用しない： 特定のシステム管理者の個人アカウントで認証すると、その社員の異動・退職で連携が遮断されるだけでなく、私的な下書き文書までインデックスされる危険があります。
- 専用のサービスアカウントを用意する：
- Google Drive：
dust-admin@yourdomain.comなどの専用アカウントを作成し、AI に読み込ませたい共有ドライブ（Shared Drives）のみに対して閲覧・ダウンロード権限を付与します。 - Microsoft SharePoint / OneDrive： Entra ID でアプリケーション登録を行い、
Sites.Selectedアプリケーション許可を付与するか、専用アカウント（dust-service@yourdomain.com）を作成して PowerShell（Grant-PnPAzureADAppSitePermission）等でアクセス可能な SharePoint サイトコレクションを厳格に限定します。 - Slack： Dust Bot を全チャンネルに追加せず、公開チャンネルや特定のリサーチ用アーカイブチャンネルのみに限定して招待します。
- Google Drive：
- フォルダツリー単位で選択する： Dust 側の同期設定モーダルでは、ルート階層を一括選択せず、必要なサブフォルダのみを個別にチェックして同期します。
ステップ 3：Restricted Space の作成とプロビジョニンググループの紐付け
コネクタ経由でデータが取り込まれても、管理者が Space に紐付けるまではエージェントから参照されません。
- Dust の Spaces タブで New をクリックします。
- 空間名を入力します（例:
Finance & Accounting）。 - 種類として Restricted を選択します。
- メンバー設定で Provisioned group access を選択し、SCIM 連携済みの IdP グループ（例:
dept-finance）を指定します。 - 作成した Space の詳細画面に入り、Connected Data から Add data from connections を選択します。
- 前段で同期したデータツリーの中から、財務部門専用のフォルダや SharePoint ライブラリのみを選択します。
- Save をクリックします。これで高機密データが特定の制限コンテナ内に隔離されます。
Dust 管理画面：Restricted Space の作成イメージ
┌─────────────────────────────────────────────────────────────┐
│ 新規 Space 作成 (Create New Space) │
│ 名前: [ Finance & Accounting ] │
│ 公開区分: ( ) Open (公開) (•) Restricted (制限) │
│ メンバー割り当て: │
│ [ Provisioned group access (IdP グループ連携) ▼]│
│ 対象グループ: [ dept-finance x ] [ exec-cfo x ] │
│ │
│ 割り当てデータ (Connected Data): │
│ [x] Google Drive: /Shared Drives/Finance/FY26_Budgets/ │
│ [x] SharePoint: /sites/FinanceOps/Financial_Statements/ │
│ [ ] Google Drive: /Shared Drives/Company_Wide/ (除外) │
│ │
│ [ キャンセル ] [ Space を作成 ]│
└─────────────────────────────────────────────────────────────┘
ステップ 4：ワークスペースロールとビルダー権限の統制
初期状態の Dust ワークスペースでは、全メンバーが自由にエージェントを作成・公開できるようになっています。社内ガバナンスを効かせるため、Admin > Governance で権限を絞り込みます。
- Create agents & Publish agents： Everyone から、承認済みの作成者グループ（例:
AI Builders）または Admin only に変更し、野良エージェントの乱立を防ぎます。 - Create skills & Manage skill availability： 外部ツール連携や API 実行を伴うスキルの作成は、セキュリティ確認が取れるまで Admin only に留めます。
- ロールマッピングの実施： Admin > Members > Roles にて、グループ単位で役割を付与します。システム基盤全体を管理する社員のみに Admin ロールを付与し、各部署のリーダーには Manager ロールまたは Group Managers（グループ管理者） を任命して、自部門の利用枠やメンバー管理のみを委譲します。
- セキュリティ権限の個別委譲： セキュリティ監査やネットワーク設定に関わる Access security features は、Manager にもデフォルトでは付与されません。セキュリティ専任チームに対してのみ個別に付与してください。
ステップ 5：部門専用 AI アシスタントの構築と可視性テスト
エージェント作成画面（Agent Builder）で部門専用エージェントを構築する際は、以下のルールを徹底します。
- Instructions にて、業務目的、回答ポリシー、取り扱う情報の範囲を明確に定義します。
- Knowledge / Tools 設定にて Search data sources を追加します。
- ナレッジソースとして、該当する部門の Restricted Space のみを選択します。
- 全社規定を参照させる必要がある場合を除き、不用意に
Company Dataを併用しないようにします。
- 複数 Space 指定時の積集合ルール（AND 条件）：
- エージェントが Space A（財務） と Space B（経営陣） の両方を参照している場合、ユーザーが Space A と Space B の両方に所属していなければ、そのエージェントを利用できません。
- 一方しか持たないユーザーにはエージェントが表示されなくなります。意図しない利用不可トラブルを避けるため、通常のエージェントは単一の Space に紐付ける設計を推奨します。
ステップ 6：ツール実行時の認証モード設定（Personal vs. Shared）
エージェントが外部ツール（GitHub、Salesforce、Jira、HubSpot、MCP サーバー等）を介してアクションを実行する場合、Knowledge > Tools で認証方式を選択します。
- 共有認証（Shared Credentials）： 管理者が設定した一律のサービスアカウントで全ユーザーが実行。全社員に共通公開されている参照専用データベース等に適しています。
- 個人別認証（Personal Level Credentials）： 管理者が全体の OAuth 接続を確立した後、ユーザーがエージェントからツールを初回呼び出しする際に、個人のアカウントでログインを求められます。
- 機密性の高い業務ツールの必須設定： Salesforce や Jira など、システム側で細かな閲覧・編集制限（レコード権限）が設定されているツールでは、必ず個人別認証を選択します。これにより、マーケティング社員がエージェント経由で営業データを照会しようとしても、Salesforce 本来のアクセス権限によって自動的にブロックされます（二重防御の確立）。
4. 監査ログ、モニタリング、およびアカウントライフサイクル
安全な設計が完了した後は、ポリシーが遵守されているかを検証・追跡する監査体制が必要です。
┌──────────────────────────────────────────────────────────────┐
│ エンタープライズ・リアルタイムイベント流 │
└──────────────────────────────┬───────────────────────────────┘
│
┌──────────────────┴──────────────────┐
▼ ▼
[ 人間による直接操作 ] [ AI エージェントの自律動作 ]
actor: "user" actor: "user"
action: "agent.executed" metadata.actor_type: "agent"
targets: ["agent-finance-01"] metadata.initiating_user: "..."
│ │
└──────────────────┬──────────────────┘
▼
[ Dust Enterprise 監査エンジン ]
│
┌──────────────────┴──────────────────┐
▼ ▼
[ 管理画面の改ざん耐性ログ ] [ 外部 SIEM へのストリーミング ]
(Admin > Security > Audit Logs) (Datadog, Splunk, S3, GCS)
監査ログによる責任追跡：人間と AI の実行主体分離
Enterprise プランの監査ログ（Admin > Organization > Security > Audit Logs）は、改ざん耐性を持つ時系列ログを提供します。
ログには以下の重要情報が含まれます。
- 主体（Actor）： 人間ユーザー（
user）、API キー（api_key）、システム処理（system）を識別。IP アドレスやユーザーエージェントを記録。 - 操作内容（Action）：
agent.executed、space.created、space.deleted、data_source.updated、tool.executedなどを網羅。 - AI 実行の正確な帰属： エージェントがデータ検索やツール実行を行った場合、ログ内の
metadata.actor_typeに"agent"と記録されると同時に、そのタスクを指示した人間の情報（initiating_user_idおよびinitiating_user_email）が紐付けられます。これにより、インシデント発生時の完全なトレーサビリティが担保されます。
SIEM へのリアルタイムログ送信
Datadog、Splunk、AWS S3、Google Cloud Storage（GCS）、または任意の HTTPS エンドポイントへのログストリーミングがサポートされています。インバウンド通信を制限している社内環境では、Dust ドキュメントに記載されている WorkOS の配信 IP アドレスをホワイトリストに登録してください。
退職・異動時のライフサイクル保護
社員が退職する際：
- 社内 IdP でアカウントが無効化されると、SCIM 経由で Dust アカウントも即座に停止されます。
- すべての Restricted Space へのアクセス権が瞬時に遮断されます。
- 当該ユーザーが作成していた個人用自動化タスク（Triggers）は自動的に完全削除されます。
- 管理者の引き継ぎ手順： 退職処理前に Programmatic Usage > Automations を確認し、残すべき定周期タスクのエディターを変更してください。未公開エージェントの作成者が退職する場合は、管理者が Agent Builder 上で Become an editor as an admin をクリックして編集権限を引き継ぐことができます。
5. アーキテクチャ設計マトリクスと IT チェックリスト
Space および権限マトリクス一覧
| 部門 / データ分類 | Space 種別 | アクセス権ソース | コネクタ側のスコープ戦略 | ツール認証モード | 推奨されるエージェント例 |
|---|---|---|---|---|---|
| 全社共通ナレッジ | Open (Company Data) | 全メンバー自動参加 | 社内規程、全社イントラ Notion、公開 Wiki | Shared (共有) | 全社 Q&A、新入社員オンボーディング (@dust) |
| 財務・会計 | Restricted (制限) | SCIM: dept-finance | 予算管理専用 Google ドライブ、決算フォルダ | Shared (集計用) | 月次決算支援、予実差異分析アシスタント |
| 法務・コンプライアンス | Restricted (制限) | SCIM: dept-legal | 契約書アーカイブ、規制対応文書、訴訟記録 | Personal / 厳格共有 | 契約条項レビュー支援、法務デューデリジェンス |
| 人事・労務 | Restricted (制限) | SCIM: dept-hr | 人事考課表、給与テーブル、役員評価シート | Personal (個人別) | 人事評価キャリブレーション、社内告知文起草 |
| 営業・CRM | Restricted (制限) | SCIM: dept-sales | 提案書ライブラリ、見積書、HubSpot / Salesforce | Personal (個別 OAuth) | 商談インテリジェンス、パイプライン要約エージェント |
| 開発・インフラ | Restricted / Open | SCIM: dept-eng | GitHub ディスカッション、アーキテクチャ RFC | Personal (GitHub) | コードベース解説アシスタント、リリースノート生成 |
本番展開前の IT 管理者セルフチェックリスト
- IdP 同期が確立されているか： SCIM 2.0 が正常稼働し、主要部門グループが Okta や Entra ID から正しく同期されている。
- Company Data の棚卸しが済んでいるか： 公開領域に給与、決算前数値、法務相談などの機密文書が紛れ込んでいない。
- 専用サービスアカウントを使用しているか： Drive や SharePoint の接続に個人アカウントを使用せず、権限を絞り込んだシステムアカウントを充てている。
- Restricted Space が適切に設定されているか： 秘密情報を扱う部門ごとに独立した制限空間を作成し、IdP プロビジョニンググループを紐付けている。
- コネクタデータが制限空間に正しく配置されているか： 外部システムから取得した特定フォルダが、意図した Restricted Space のみに格納されている。
- エージェント作成権限を管理しているか： Admin > Governance で一般社員による野良エージェントの乱立・公開を制限している。
- 業務ツールに個人別認証を適用しているか： Salesforce や GitHub 等の操作ツールで、個人別権限（Personal Credentials）が有効化されている。
- 監査ログの送信テストが完了しているか： SIEM（Splunk / Datadog）へのログ転送が正常に疎通し、テストクエリで確認できている。
構造化された Space 設計と統制された RBAC を組み合わせることで、社内の機密データを鉄壁の防御で保護しながら、全社規模で安全に AI アシスタントを展開することが可能になります。