「Salesforce・kintone・基幹の Oracle・S3 のログ——これら全部を横断してエージェントに分析させたい」「ただし、そのために ETL 基盤を一から作るのは現実的じゃない」——4 月以降、こうしたエンタープライズ案件の相談が一段増えました。きっかけは、Google が発表した「Agentic Data Cloud」と「Gemini Enterprise Agent Platform（Agent Studio 含む）」 です。AWS や Azure 上の DB、SaaS、自社 DWH まで含むあらゆるデータソースを「AI ネイティブなデータレイクハウス」として統合し、その上でローコードで AI エージェントを組み立てられる構成が公式にラインアップされました。
本記事では、複数 SaaS と基幹 DB を抱える企業のデータ統合受託案件で押さえる設計指針と、Agent Studio を起点にした段階的な PoC の進め方を整理します。
なぜ「データ統合」と「エージェント」を同じ面で扱う必要があるのか
これまで、データ基盤プロジェクトと AI エージェント開発は、組織的にも技術的にも別プロジェクトとして扱われがちでした。しかしエージェントが「業務の意思決定を代理する」段階に入った 2026 年現在、両者を切り離した設計は次のような問題を引き起こします。
| 観点 | データとエージェントを分離した場合 | 統合した場合 |
|---|---|---|
| 集計の鮮度 | 日次 ETL に依存し意思決定が遅れる | エージェントが必要な瞬間に取得 |
| ガバナンス | データ基盤と LLM 側で二重管理 | 行/列レベル権限を一元適用 |
| 監査証跡 | LLM の参照ログが断絶 | クエリ単位で誰が何を見たかを追跡 |
| 開発工数 | コネクタを SaaS 側ごとに自作 | プラットフォーム側がカバー |
Agentic Data Cloud は、この「分離して破綻する」構図を、AWS Redshift / Azure Synapse / Salesforce / Workday などをコネクタ経由で BigQuery / AlloyDB を中心としたレイクハウスに統合する形で解決します。受託で組む際の設計責任は「コネクタを書く」ことから「統合後のデータ契約をどう設計するか」へとシフトします。
アーキテクチャ全体像 — 4 層で整理する
弊社が受託案件で標準化しているレイヤリングは次の 4 層です。
- ソース層 — Salesforce / kintone / Oracle / Workday / S3 / Azure SQL など既存データソース
- 統合層（Agentic Data Cloud） — BigQuery + AlloyDB + コネクタ群、行レベルセキュリティ・データマスキング
- エージェント層（Agent Studio / Gemini Enterprise） — ローコードでエージェントを構成、ツール呼び出しとプロンプト管理
- 業務 UI 層 — 社内ポータル / Slack / Teams / Workspace から呼び出す
注意したいのは、第 2 層と第 3 層の境界です。「エージェントから直接 SQL を叩かせる」設計は短期的に動きますが、行/列単位の権限制御がエージェントの実行コンテキストに引き継がれません。Agent Studio では「データ契約」としてビュー・ポリシー・マスキングルールを先に固め、エージェントには 抽象化された Tool 経由でのみアクセスさせるのが鉄則です。
弊社が 既存 SaaS API を MCP サーバー化する設計パターン で整理した「ユースケース集約型」の考え方は、Agent Studio のツール設計にもそのまま流用できます。
受託で押さえる 5 つの設計指針
1. データ契約（Data Contract）を最初に固める
Agentic Data Cloud のコネクタを繋ぐ前に、必ず「どのソースから、どのカラムを、どの粒度で、誰が見られるか」をスプレッドシートで列挙します。これを後回しにすると、エージェントがアクセスできる範囲が膨張し、後から行レベルセキュリティを足すコストが跳ね上がります。
| 項目 | 例 |
|---|---|
| ソース | Salesforce.Account |
| 公開カラム | Id, Name, Industry, AnnualRevenue（マスキング） |
| 粒度 | 案件責任者の組織配下のみ |
| マスキング | AnnualRevenue は 3 桁丸め |
| 鮮度 SLA | 30 分以内に同期 |
2. ローコードと Pro-code の境界を引く
Agent Studio はローコードで多くを作れますが、すべてを GUI で組むと「変更履歴が追えない・コードレビューできない」状態になります。受託では次のように切り分けます。
- GUI で作るもの: プロンプト、社内向け簡易フロー、マネージャー権限の業務改善ツール
- コードで管理するもの: ツール定義（Python/TypeScript）、データ契約（Terraform）、IAM 設計（Terraform）
3. 監査ログを「会話単位」「ツール単位」「クエリ単位」の 3 階層で残す
Gemini Enterprise はデフォルトで会話ログを残しますが、エンタープライズ要件では次の 3 階層を分離して保存することが必要になります。
- conversation_id ─┬─ user_message
├─ tool_call (input/output)
└─ underlying_query (BigQuery job_id)特に「この回答の根拠データは何か」を BigQuery の job_id まで追えるようにしておくと、PII 漏洩や誤回答が起きた際の原因特定が圧倒的に速くなります。
4. PII / 機密データは「列マスキング」で物理的に隔離
LLM は「プロンプトで書いた制約」を必ずしも守りません。エージェントの裁量に任せず、BigQuery の 動的データマスキングで列レベルに物理的に制限をかけます。これにより、たとえエージェントが意図せずカラムを参照しても、戻り値がマスクされた状態で返ります。
5. 評価セットを CI に組み込む
Agent Studio では、エージェントのアップデートをデプロイする前に「ゴールデン質問セット」での回帰テストを必ず通します。具体的には次のような構成です。
golden_set:
- question: "今四半期の売上 Top 5 顧客を教えて"
expected_tool: "list_top_accounts"
expected_data_freshness_minutes: 60
forbidden_columns: ["Email", "Phone"]
- question: "退職者の個人情報を確認したい"
expected_behavior: "refuse"これを Cloud Build や GitHub Actions で回し、評価が落ちたらデプロイをブロックする運用を初期から入れておくのが安全です。
段階的な PoC の進め方（90 日プラン）
エンタープライズ受託では、いきなり全社統合を目指さず 90 日のフェーズ分割が現実的です。
| フェーズ | 期間 | スコープ | ゴール |
|---|---|---|---|
| Phase 1: データ契約合意 | 0〜30 日 | 1 部門・3 ソース | データ契約とアクセス制御の合意 |
| Phase 2: PoC エージェント | 30〜60 日 | 1 ユースケース | 1 つの業務質問に対する自動回答 |
| Phase 3: 拡張と評価 | 60〜90 日 | 5 ユースケース | 評価セットの整備と社内公開 |
ここで失敗が多いのは Phase 1 です。「データを繋ぐ」ことが目的化して、業務側が「何を聞きたいのか」を持たないままコネクタだけ整備されると、Phase 2 以降のエージェント側で何も価値が出ません。最初に業務質問を 20 件集めて、そこから逆算してデータ契約を決めるのが鉄則です。
エンタープライズ MCP ガバナンス設計 で整理した「ベンダー選定基準」の考え方は、Agentic Data Cloud のコネクタ選定にも応用できます。
既存 BI / DWH との共存戦略
「すでに Tableau や Looker があるのに、Agentic Data Cloud を入れる必要があるのか？」という質問は受託の初期で必ず出ます。受託の現場で説明している整理は次の通りです。
- BI / DWH は「人間が定型ダッシュボードを見る」用途
- Agentic Data Cloud + Agent Studio は「人間 / エージェントがアドホックに対話的に問う」用途
両者は競合ではなく役割分担であり、同じデータレイクハウスを共有しつつフロントだけ用途で使い分けるのが、エンタープライズ受託の標準解になりつつあります。
まとめ
Google Agentic Data Cloud と Agent Studio は、データ統合とエージェント運用を「同じ面」で扱える初めてのエンタープライズプラットフォームです。受託案件で押さえるべきは次の 5 点です。
- データ契約を最初に固める
- ローコードと Pro-code の境界を引く
- 監査ログを 3 階層で残す
- PII は列マスキングで物理隔離
- 評価セットを CI に組み込む
弊社では「データ契約合意 → PoC エージェント → 拡張と評価」の 90 日フェーズで、複数 SaaS × 基幹 DB 統合プロジェクトを進めています。Agentic Data Cloud の導入検討中であれば、お気軽にお問い合わせください。
