EntraアカウントでGemini Enterpriseを使う環境構築の要件ヒアリング表：GWSなし構成の事前確認チェックリスト完全版
はじめに
「Entra IDアカウントでGemini Enterpriseを使いたい。ただし Google Workspace（GWS）は導入しない」——この要件は、Microsoft 365を全社IDaaSとして運用している企業がGoogleのエンタープライズAIを採用する際の典型的な出発点です。
しかし、いざ構築フェーズに入ると以下のような問題が頻発します。
- 「データソースはSharePointだけのつもりだったが、後からBoxやファイルサーバーも追加要望が出た」
- 「条件付きアクセスの適用範囲を決めずに進めたら、社外ユーザー混在で再設計が必要になった」
- 「ライセンス購入後にPOCと本番で別組織にすべきだったと判明した」
- 「コネクターのACL同期要件を確認しておらず、検索結果に他部署の機密が出てきた」
こうした手戻りを防ぐには、設計に入る前の要件ヒアリングで抑えるべき項目を体系化することが重要です。本記事では、Entra × Gemini Enterprise（GWSなし）構成に特化した要件ヒアリング表を6カテゴリ・100項目超で整理し、ヒアリング結果から構成パターンへ落とし込む流れを解説します。
本記事の対象読者
- SIer・コンサルタントでGemini Enterprise導入プロジェクトのPMやアーキテクトを担当する方
- 情シス部門で要件整理を主導する方
- POCから本番展開を検討中で、関係者との合意形成に使えるテンプレートを探している方
全体像：ヒアリングで決まる構成と6カテゴリ
ヒアリングで確認すべき項目は大きく6カテゴリに分類できます。各カテゴリは設計判断に直結するため、ヒアリングの順序・粒度・関係者を意識する必要があります。
graph LR
subgraph "要件ヒアリング 6カテゴリ"
A[① ビジネス・ユースケース]
B[② ID基盤・認証]
C[③ データソース・コネクター]
D[④ セキュリティ・コンプライアンス]
E[⑤ 課金・ライセンス]
F[⑥ 運用・ガバナンス]
end
subgraph "設計判断アウトプット"
G[GCP組織構成
本番/POC分離] H[WIF Pool/Provider
属性マッピング] I[コネクター種別
ACL同期方式] J[条件付きアクセス
DLP/監査ログ] K[サブスクリプション
契約期間] L[ロール設計
運用体制] end A --> G A --> K B --> H B --> J C --> I D --> J D --> I E --> K E --> G F --> L F --> J style A fill:#0078d4,color:#fff style B fill:#0078d4,color:#fff style C fill:#fbbc05,color:#000 style D fill:#cc0000,color:#fff style E fill:#34a853,color:#fff style F fill:#4285f4,color:#fff
本番/POC分離] H[WIF Pool/Provider
属性マッピング] I[コネクター種別
ACL同期方式] J[条件付きアクセス
DLP/監査ログ] K[サブスクリプション
契約期間] L[ロール設計
運用体制] end A --> G A --> K B --> H B --> J C --> I D --> J D --> I E --> K E --> G F --> L F --> J style A fill:#0078d4,color:#fff style B fill:#0078d4,color:#fff style C fill:#fbbc05,color:#000 style D fill:#cc0000,color:#fff style E fill:#34a853,color:#fff style F fill:#4285f4,color:#fff
ヒアリングの進め方
sequenceDiagram
participant PM as PM/アーキテクト
participant Biz as 事業部門
participant IT as 情シス（M365/Entra）
participant Sec as セキュリティ部門
participant Fin as 経理・調達
PM->>Biz: ① ユースケース・対象ユーザー確認
Biz-->>PM: 用途、対象部門、KPI
PM->>IT: ② Entra ID・条件付きアクセス確認
IT-->>PM: テナント情報、CAポリシー、MFA要件
PM->>IT: ③ データソース・コネクター範囲確認
IT-->>PM: SPO/OneDrive/Box等の権限構造
PM->>Sec: ④ DLP・MIP・監査要件確認
Sec-->>PM: 機密データ取扱い、ログ保管期間
PM->>Fin: ⑤ 課金・契約形態確認
Fin-->>PM: 予算、調達ルート、契約期間
PM->>IT: ⑥ 運用・ガバナンス確認
IT-->>PM: 運用体制、SLA、教育計画
Note over PM: 全カテゴリのヒアリング結果を
構成設計書に落とし込む
構成設計書に落とし込む
カテゴリ① ビジネス・ユースケース
最初に押さえるべきは「なぜGemini Enterpriseか・誰がどう使うか」です。ここが曖昧だと、後続の認証・データソース要件も発散します。
ヒアリング表
| No | 項目 | 確認ポイント | 設計への影響 |
|---|---|---|---|
| 1-1 | 導入目的 | 業務効率化／ナレッジ検索／ドラフト作成／専門エージェント | UI選択（Agentspace要否） |
| 1-2 | 主要ユースケース | 文書要約／RAG検索／会議録／コード生成／画像生成 | 必要モデル・API |
| 1-3 | 対象ユーザー数 | 初期人数、最大想定人数、部門別内訳 | ライセンス数・購入パターン |
| 1-4 | 対象部門 | 全社／特定部門／役職限定 | IAM条件式の粒度 |
| 1-5 | 社外ユーザーの有無 | 業務委託、外注、グループ会社 | ゲスト/B2B対応、CA設計 |
| 1-6 | フェーズ | POCのみ／POC→本番／本番一気導入 | GCP組織分離要否 |
| 1-7 | POC期間 | 1ヶ月／3ヶ月／6ヶ月 | 月契約 vs 年契約判断 |
| 1-8 | 本番展開時期 | 確定／未定／予算次第 | サブスク設計タイミング |
| 1-9 | KPI・成果指標 | 利用率／満足度／工数削減時間 | 監査ログ設計 |
| 1-10 | 経営層の関与 | 役員スポンサーの有無 | 予算・ガバナンス調整 |
| 1-11 | 競合検討状況 | M365 Copilot／ChatGPT Enterprise併用有無 | 重複機能の整理 |
| 1-12 | 言語要件 | 日本語のみ／多言語 | モデル選定・プロンプト設計 |
カテゴリ② ID基盤・認証
GWSなしでEntra IDをそのまま使うため、Workforce Identity Federation（WIF） の前提条件と属性設計を確認します。
ヒアリング表
| No | 項目 | 確認ポイント | 設計への影響 |
|---|---|---|---|
| 2-1 | Entra IDテナント数 | 単一／複数（合併・グループ会社） | WIF Provider数 |
| 2-2 | Entra IDライセンス | P1 / P2 / E5 | CA・PIM利用可否 |
| 2-3 | 既存SSO実績 | 他SaaSでのOIDC/SAML経験 | アプリ登録の標準化 |
| 2-4 | MFA運用状況 | 全員必須／条件付き／例外あり | CA設計の起点 |
| 2-5 | 条件付きアクセス | 既存ポリシーの内容 | 新規アプリへの適用範囲 |
| 2-6 | デバイス管理 | Intune／JAMF／管理外 | デバイス準拠要件 |
| 2-7 | ネットワーク制限 | IP制限／VPN必須／ZTNA | CA・GCP VPC SC連携 |
| 2-8 | ユーザー属性 | 部署・役職・ライセンス種別の格納場所 | クレーム設計 |
| 2-9 | 同期したい属性 | 部署のみ／役職／ライセンス／カスタム属性 | OIDCクレーム＋属性マッピング |
| 2-10 | グループ運用 | M365グループ／セキュリティグループ／動的グループ | グループクレーム要否 |
| 2-11 | グループ同期方針 | 同期する／属性ベースのみ／ハイブリッド | WIF属性条件式 |
| 2-12 | プロビジョニング | 自動／手動／不要 | SCIM要否（基本不要） |
| 2-13 | デプロビジョニング | Entra側で無効化→GCP側自動失効でOKか | トークン有効期限設計 |
| 2-14 | 監査ログ統合 | Entra SignIn ↔ GCP Audit Logの相関 | ログ集約基盤 |
| 2-15 | ブレイクグラスアカウント | 緊急時のGCP直接ログイン要否 | ローカルアカウント設計 |
重要：属性ベース vs グループ同期の選択
graph TD
Q1{ユーザー属性で
アクセス制御可能?} Q1 -->|Yes| Q2{属性は
Entraに格納済?} Q1 -->|No| Q3{グループは
少数で固定?} Q2 -->|Yes| A1[属性ベース
WIF属性マッピング
★推奨] Q2 -->|No| A2[Entra拡張属性で
付与してから属性ベース] Q3 -->|Yes| A3[グループクレーム
カスタムクレーム転送] Q3 -->|No| A4[Entra動的グループ＋
属性ベース併用] style A1 fill:#34a853,color:#fff style A2 fill:#fbbc05,color:#000 style A3 fill:#0078d4,color:#fff style A4 fill:#cc0000,color:#fff
アクセス制御可能?} Q1 -->|Yes| Q2{属性は
Entraに格納済?} Q1 -->|No| Q3{グループは
少数で固定?} Q2 -->|Yes| A1[属性ベース
WIF属性マッピング
★推奨] Q2 -->|No| A2[Entra拡張属性で
付与してから属性ベース] Q3 -->|Yes| A3[グループクレーム
カスタムクレーム転送] Q3 -->|No| A4[Entra動的グループ＋
属性ベース併用] style A1 fill:#34a853,color:#fff style A2 fill:#fbbc05,color:#000 style A3 fill:#0078d4,color:#fff style A4 fill:#cc0000,color:#fff
カテゴリ③ データソース・コネクター
Gemini Enterprise（Agentspace）の価値の大半は社内データへのRAG検索にあります。ここの抜け漏れがプロジェクト遅延の最大要因です。
ヒアリング表
| No | 項目 | 確認ポイント | 設計への影響 |
|---|---|---|---|
| 3-1 | 接続したいデータソース | SPO／OneDrive／Teams／Box／ファイルサーバー／Confluence／Jira／ServiceNow／Salesforce／Notion | 必要コネクター種別 |
| 3-2 | 各ソースのデータ量 | 件数／総容量／月間増分 | インデックス容量見積もり |
| 3-3 | クロール対象範囲 | 全社／特定サイト／特定ライブラリ | コネクター設定粒度 |
| 3-4 | クロール頻度 | リアルタイム／日次／週次 | コネクター稼働設計 |
| 3-5 | ACL（権限）の取り扱い | コンテンツに合わせて検索結果も制御要 | パーミッションアウェア検索 |
| 3-6 | ACL同期方式 | ソース権限ベース／GCP IAMで再設計 | コネクター仕様確認 |
| 3-7 | MIP感度ラベル | 暗号化ファイルの存在 | クロール除外 or 復号設計 |
| 3-8 | 多言語コンテンツ | 日本語・英語・中国語等の比率 | 埋め込みモデル選定 |
| 3-9 | バイナリ・画像 | PDF／画像／動画／音声の取扱い | マルチモーダル要否 |
| 3-10 | 履歴データ | 過去N年分のクロール要否 | 初回フルクロール工数 |
| 3-11 | 削除・更新の反映 | 即時／日次／週次でOK | デルタクロール設計 |
| 3-12 | 機密データの除外 | 人事・経理・法務文書 | 除外ルール設計 |
| 3-13 | データレジデンシー | 日本リージョン必須／不問 | リージョン選定 |
| 3-14 | 既存検索基盤 | M365 Search／自社検索／なし | 並行運用設計 |
| 3-15 | 非構造化以外 | DB／DWH／BigQuery／Salesforceレコード | 構造化データコネクター |
SharePoint接続時の追加ヒアリング
| No | 項目 | 確認ポイント | 設計への影響 |
|---|---|---|---|
| 3-16 | SPOテナント数 | 単一／複数 | コネクター数 |
| 3-17 | サイト数 | 数十／数百／数千 | クロール工数 |
| 3-18 | ハブサイト構造 | 利用有無 | クロール対象選定 |
| 3-19 | サイト権限の継承 | 統制／部門ごとに自由設定 | ACL同期の複雑度 |
| 3-20 | 外部共有設定 | 全社オフ／部分許可 | クロール対象外設定 |
カテゴリ④ セキュリティ・コンプライアンス
ヒアリングを怠ると後段の監査・法務レビューで差し戻しが起きやすい領域です。
ヒアリング表
| No | 項目 | 確認ポイント | 設計への影響 |
|---|---|---|---|
| 4-1 | 業界規制 | 金融／医療／公共／一般 | コンプライアンス要件 |
| 4-2 | 個人情報の取扱い | PII含むデータの入出力 | DLPルール |
| 4-3 | DLP要件 | 既存M365 DLPとの整合 | 二重DLPの整理 |
| 4-4 | プロンプト記録 | 全件保管／集計のみ／不要 | 監査ログ設計 |
| 4-5 | 応答記録 | 全件保管／不要 | ストレージ容量 |
| 4-6 | ログ保管期間 | 1年／3年／7年／無期限 | Cloud Loggingバケット設計 |
| 4-7 | データ学習禁止 | モデル学習に使わせない | エンタープライズ契約条項 |
| 4-8 | データ所在地 | 日本国内必須／可 | リージョン・データレジデンシー |
| 4-9 | 暗号化要件 | デフォルト／CMEK必須 | KMS設計 |
| 4-10 | 鍵管理 | Cloud KMS／HSM／外部KMS | CMEK構成 |
| 4-11 | VPC Service Controls | 利用有無 | 境界保護設計 |
| 4-12 | プライベート接続 | Private Service Connect要否 | ネットワーク設計 |
| 4-13 | セキュリティ承認 | 社内CISO・セキュリティ委員会レビュー | スケジュール |
| 4-14 | リスクアセスメント | 評価シート提出要否 | ドキュメント作成工数 |
| 4-15 | 監査対応 | 内部監査／外部監査（SOC2等） | エビデンス自動化 |
カテゴリ⑤ 課金・ライセンス
GWSなし構成では、Gemini EnterpriseのサブスクリプションをGCP上で直接管理します。請求タイミングのズレなど落とし穴も多いため、調達部門も巻き込んだヒアリングが必要です。
ヒアリング表
| No | 項目 | 確認ポイント | 設計への影響 |
|---|---|---|---|
| 5-1 | 予算 | 初年度／3年TCO | 契約期間判断 |
| 5-2 | エディション | Gemini Enterprise／Business／Standard | 機能差確認 |
| 5-3 | 契約期間 | 月単位／年単位／3年 | サブスク種別 |
| 5-4 | 初期ライセンス数 | POC人数／本番人数 | 段階購入設計 |
| 5-5 | ライセンス追加見込み | 半期／四半期／不定 | 請求ズレ対策 |
| 5-6 | 請求通貨 | 円／ドル | 為替リスク管理 |
| 5-7 | 調達ルート | 直接契約／パートナー経由／リセラー | 見積依頼先 |
| 5-8 | 支払方式 | 請求書／クレジットカード／PO | Cloud Billing設計 |
| 5-9 | コストセンター | 部門按分／単一部門 | 課金ラベル設計 |
| 5-10 | 既存GCP課金 | 既存アカウントへの統合／新規分離 | 請求アカウント設計 |
| 5-11 | POC・本番組織 | 同一組織／別組織 | GCP Organization設計 |
| 5-12 | 為替・予算オーバー時の対応 | アラート閾値 | 予算アラート設計 |
| 5-13 | 既存M365との比較 | M365 Copilot併用予算配分 | 経営説明資料 |
カテゴリ⑥ 運用・ガバナンス
導入後の「動かす人・直す人・改善する人」を決めずに本番展開すると、利用率低迷・障害対応遅延を招きます。
ヒアリング表
| No | 項目 | 確認ポイント | 設計への影響 |
|---|---|---|---|
| 6-1 | 運用主体 | 情シス／DX推進室／外部委託 | ロール設計 |
| 6-2 | GCP管理者数 | 1名／チーム／複数チーム | IAM・PAM設計 |
| 6-3 | 24/365監視 | 必要／業務時間のみ | 監視基盤・通知設計 |
| 6-4 | インシデント対応 | 自社SOC／Google Support／併用 | 契約サポート種別 |
| 6-5 | サポート契約 | Basic／Standard／Enhanced／Premium | コスト・SLA |
| 6-6 | エージェント管理 | 中央管理／部門ごと自由 | Agentspace権限設計 |
| 6-7 | プロンプト共有 | 全社／部門内／個人 | プロンプトギャラリー設計 |
| 6-8 | 利用ルール | AI利用ガイドライン有無 | ポリシー策定支援 |
| 6-9 | 教育・展開 | 全社研修／部門単位／オンデマンド | チェンジマネジメント |
| 6-10 | 利用状況可視化 | 経営報告ダッシュボード | BigQuery + Looker設計 |
| 6-11 | フィードバック収集 | アンケート／組込フィードバック | 改善サイクル |
| 6-12 | バージョン追従 | Google側機能更新の社内告知 | リリースノート運用 |
| 6-13 | 利用停止条件 | ライセンス未利用Nヶ月で剥奪 | 自動化スクリプト |
| 6-14 | データ削除・移行 | 解約時の取り扱い | 出口戦略 |
ヒアリング結果から決まる構成パターン
ヒアリング結果を組み合わせると、典型的に以下の構成パターンに収束します。
パターン判定マトリクス
| ヒアリング結果 | 推奨構成 |
|---|---|
| ユーザー数 < 50、POC期間 < 3ヶ月 | 単一組織・月契約・属性ベース最小構成 |
| ユーザー数 50〜500、本番計画あり | POC組織と本番組織を分離・年契約・属性ベース |
| ユーザー数 > 500、全社展開 | フォルダ階層で本番/POC/開発分離・3年契約・SCC/VPC SC併用 |
| 多テナントEntra・グループ会社展開 | Provider複数・テナントごと属性条件 |
| 機密データ多数・金融/医療 | CMEK + VPC SC + Private Service Connect + 全件監査ログ |
全体構成イメージ（標準的な本番＋POC分離）
graph TB
subgraph "Microsoft 365 / Entra ID"
ENTRA[Entra ID テナント]
CA[条件付きアクセス]
SPO[SharePoint Online]
OD[OneDrive]
end
subgraph "GCP Organization（本番）"
PRODFOLDER[フォルダ：本番]
PRODPROJ[Project：Gemini Enterprise本番]
PRODWIF[WIF Pool 本番]
PRODGE[Gemini Enterprise / Agentspace]
PRODVS[Vertex AI Search]
PRODLOG[Cloud Logging 7年保管]
PRODBILL[請求アカウント本番]
end
subgraph "GCP Organization（POC）"
POCFOLDER[フォルダ：POC]
POCPROJ[Project：Gemini Enterprise POC]
POCWIF[WIF Pool POC]
POCGE[Gemini Enterprise / Agentspace]
POCBILL[請求アカウントPOC]
end
ENTRA --> CA
CA --> PRODWIF
CA --> POCWIF
PRODWIF --> PRODGE
POCWIF --> POCGE
SPO --> PRODVS
OD --> PRODVS
PRODVS --> PRODGE
PRODGE --> PRODLOG
PRODPROJ --> PRODBILL
POCPROJ --> POCBILL
style ENTRA fill:#0078d4,color:#fff
style CA fill:#0078d4,color:#fff
style PRODGE fill:#34a853,color:#fff
style POCGE fill:#fbbc05,color:#000
style PRODLOG fill:#cc0000,color:#fff
ヒアリングチェックリスト（要約版）
プロジェクト初動時のキックオフで使える簡易チェックリストです。これだけ埋めれば最低限の構成方向性が決まります。
最優先で確認すべき10項目
- 対象ユーザー数：初期と最大
- フェーズ：POCのみ／POC→本番／本番一気
- GCP組織方針：単一／POCと本番で分離
- Entraテナント：単一／複数
- 属性 vs グループ：アクセス制御の基本方針
- 接続データソース：SPO/OneDrive/Box/その他
- ACL同期要否：パーミッションアウェア検索の要否
- データレジデンシー：日本国内必須か
- 契約期間：月契約／年契約／3年契約
- 運用主体：情シス／DX推進室／外部委託
まとめ
EntraアカウントでGemini Enterpriseを使う環境（GWSなし）を構築する際は、設計に入る前に6カテゴリ・100項目超のヒアリングで要件を可視化することが、後工程の手戻りを防ぐ最大のコツです。
| カテゴリ | 押さえるべき本質 |
|---|---|
| ① ビジネス・ユースケース | 誰が・何のために・どこまで使うか |
| ② ID基盤・認証 | 属性ベースかグループベースか・CA設計 |
| ③ データソース・コネクター | ACL同期方式・MIPの扱い |
| ④ セキュリティ・コンプライアンス | ログ保管・CMEK・VPC SC |
| ⑤ 課金・ライセンス | 組織分離・契約期間・請求ズレ対策 |
| ⑥ 運用・ガバナンス | 運用主体・サポート・教育 |
本記事のヒアリング表は、関係者との合意形成・要件定義書のベース・RFP回答テンプレートなど、プロジェクトの初動から要件確定までフル活用できるように設計しています。Gemini Enterprise導入プロジェクトのプロジェクトキックオフ資料としてそのまま流用してください。
関連記事
- Entra ID × Workforce Identity Federation で実現するGemini Enterprise / NotebookLM Enterprise SSO完全構築ガイド
- GCP Gemini Enterpriseライセンス購入パターン完全ガイド：本番・POC で GCP 組織が別々の場合のサブスクリプション設計と請求タイミング整理
- GCPで完結するエンタープライズAI環境構築ガイド：Gemini・Imagen・NotebookLMをEntra ID属性ベースSSOで従量課金利用する