AIエージェントを業務データへ安全につなぐ設計 ― 参照、検索・集計、更新を分け、権限と監査を組み立てる

1. データアクセスを三つに分ける

本記事では、AIエージェントによる業務データへのアクセスを、次の三つに分けます。

これはGoogle Cloudの公式な製品分類ではなく、設計判断を整理するための本記事独自の分類です。

「参照」は、顧客の契約状態や在庫数など、回答に必要な値を読み取る処理です。対象のシステム、取得する項目、取得時刻、利用できる範囲を定めます。

「検索・集計」は、多数の文書やレコードから必要な情報を絞り込む処理です。検索対象、条件、期間、結果件数、同期時刻、クエリ量を管理します。

「更新」は、業務システムへの登録、変更、削除、外部送信など、業務の状態を変える処理です。参照とはツールと権限を分け、実行前の確認、重複防止、結果確認、失敗時の扱いを追加します。

会話の継続に使うセッション情報やメモリも、業務データとは分けます。過去の会話に「契約中」と記録されていても、それを現在の契約状態として扱ってはいけません。受注、契約、在庫、従業員情報などの業務判断には、正として定めたシステムの現在値を使います。

図1　AIエージェントのデータアクセスは、接続先ではなく目的から分類し、それぞれに必要な接続方式と制御を選びます。

2. 正とするデータと鮮度を決める

同じ項目が複数のシステムに存在する場合は、用途ごとにどのデータを正とするかを定めます。たとえば、契約状態は契約管理システム、現在庫は在庫管理システム、確定済みの月次数値は集計済みの分析テーブルを正とします。

検索インデックス、キャッシュ、分析用の複製データは、検索速度や集計効率を高めるために有効です。しかし、元システムの更新が反映されるまで時間差があるため、常に最新のデータとは限りません。

事前にデータを取り込む方式では、最終同期時刻、同期周期、同期エラーを記録します。実行時に元システムへ問い合わせる方式では、応答時間、可用性、同時実行数、クエリ量を管理します。最新性が必要な在庫や承認状態と、更新頻度が低いマニュアルでは、同じ方式を選ぶ必要はありません。

回答には、業務上必要な場合、取得元、対象期間、取得日時を付けます。参照した文書やレコードと、モデルが生成した説明も区別します。グラウンディングは、モデルの出力を確認可能な情報源へ結び付け、事実と異なる内容の生成を減らすための仕組みです。ただし、参照元の選択やモデルによる解釈まで正しさを保証するものではありません。

検索結果が見つからない場合は、モデルの一般知識で補って業務上の事実として回答しません。「対象データを確認できなかった」と返すか、確認先を案内します。データソース間で値が競合した場合は、定めた優先順位に従い、解決できなければ回答や更新を停止します。

3. IDと権限を層ごとに分ける

データアクセスでは、少なくとも次の四つを分けて設計します。

エージェントが共通情報を読む場合は、専用のサービスアカウントなどに必要最小限の権限を付与します。利用者ごとに閲覧可能な顧客や部門が異なる場合は、利用者の権限や属性を使ってアクセス範囲を判定します。

Agent Identityは、エージェントごとのIDを使い、エージェント自身として、または利用者の代理として、MCPサーバー、Google Cloudリソース、外部エンドポイントなどへ認証するための仕組みです。ただし、Agent Identityを採用しただけで最小権限になるわけではありません。対象リソースへ付与する権限と、利用者から委任できる範囲を設計します。

Agent Identity自体は一般提供されていますが、Agent Identity APIや、Auth Managerを使う一部のOAuth方式、APIキー方式にはPreviewの機能が含まれます。製品全体の提供段階ではなく、採用する認証方式とAPIごとに確認します。

BigQueryでは、プロジェクト、データセット、テーブルのIAMに加え、行レベルセキュリティ、列レベルアクセス制御、動的データマスキングを利用できます。これらは組み合わせて利用できます。エージェントへテーブル全体を公開する前に、必要な行や列だけをビューやポリシーで公開できないかを検討します。

データベースへ接続する場合も、認証情報をプロンプトやソースコードへ埋め込みません。Cloud SQLでは、対応するデータベースエンジンと構成でIAMデータベース認証を利用でき、Cloud SQL Language ConnectorsはIAMによる接続認可と暗号化を提供します。

ただし、コネクタはネットワーク経路を作成しないため、Private IPやPrivate Service Connectなどの接続経路は別に設計します。固定パスワードが必要な場合はSecret Managerなどで保管し、参照できる実行主体を限定します。

4. 更新を読み取りから分離する

更新処理は、参照ツールへ更新用の引数を追加するのではなく、登録、変更、削除などの目的ごとに操作を限定します。モデルへ任意のSQLや任意のAPIリクエストを作らせるのではなく、変更可能な項目、対象範囲、最大件数をツール側で制限します。

重要な更新では、エージェントが最初に変更案を作り、対象、変更前の値、変更後の値、影響件数を示します。その後、利用者の確認や承認を受けて、別の処理で確定します。削除、支払い、外部送信、権限変更など、元に戻せない、または影響が大きい処理ほど、明示的な承認を求めます。

更新要求には処理IDや冪等性キーを付けます。冪等性とは、同じ要求が複数回届いても、最終結果が一度だけ実行した場合と変わらない性質です。サーバー側で処理IDと結果を記録し、同じ要求を受けた場合は更新を繰り返さず、保存済みの結果を返します。

タイムアウトは、更新失敗を意味するとは限りません。サーバー側では処理が完了し、応答だけを受け取れなかった可能性があります。結果が不明な状態で登録、送信、課金を再実行せず、処理IDを使って実行結果を照会します。

複数の変更を一つのデータベーストランザクションへまとめられる場合は、途中状態を残さないようにします。複数システムや外部APIをまたぎ、一括で確定できない場合は、成功、失敗、未実行を対象ごとに記録します。部分的に成功した処理を最初から再実行すると、成功済みの操作が重複するためです。

アプリケーションの版を戻しても、送信済みのメール、外部サービスへ登録した情報、実行済みの支払いは消えません。更新機能を公開する前に、取り消し、補正、人による復旧のどれを使うかを決めます。

図2　読み取りと更新では、権限だけでなく、確認、再試行、重複防止、復旧方法も分けて設計します。

5. 接続方式を目的と鮮度から選ぶ

接続方式は、製品名からではなく、利用目的、必要な鮮度、更新の有無から選びます。

文書やFAQを検索する場合は、Agent SearchやRAG Engineなどへデータを取り込み、検索結果を回答生成へ渡す構成を選べます。Agent SearchはVertex AI Searchから変更された現行名称ですが、Google CloudコンソールにはVertex AI SearchやAI Applicationsという従来名称が残っています。

RAG Engineは、利用するリージョンによって提供段階が異なります。東京リージョンは2026年8月2日時点でPreviewです。また、VPC Service ControlsとCMEKはサポートされていますが、データ所在地はサポートされていません。採用時は、リージョン、検索バックエンド、モデル、暗号化、データ所在地、料金を機能単位で確認します。

最新の在庫、申請、承認状態を取得する場合は、元システムのAPIやデータベースへ実行時に問い合わせます。分析や大規模集計にはBigQuery、トランザクションを伴う業務データにはCloud SQLやAlloyDBなど、データソースの役割に合うサービスを選びます。

MCPは、AIアプリケーションからツール、API、データソースを呼び出すインターフェースを標準化するプロトコルです。MCPサーバーは接続先の機能を公開しますが、データベースそのものでも、単独で完結するセキュリティ境界でもありません。MCPサーバーが呼び出すAPIやデータベース側でも、認証、認可、入力検証、監査を行います。

Agent Gatewayは、エージェント間やエージェントとツール間の通信へ認可ポリシーやガバナンスを適用するために利用できます。ただし、すべてのデータ接続で必須となる経路ではなく、接続先のIAM、行や列のアクセス制御、データベース監査を置き換えるものでもありません。Agent Gatewayは2026年6月18日に一般提供となっています。

6. データを保護し、処理を追跡する

個人情報や機密情報は、モデルへ渡す直前だけでなく、取り込み、検索、プロンプト、回答、ログ、評価データの各段階で保護します。

最初の対策は、業務に不要な項目を取得しないことです。必要な場合は、用途に応じてマスキング、削除、仮名化などを適用します。Sensitive Data Protectionは、機密情報の検出、分類、非識別化を支援し、マスキング、削除、日付シフト、トークン化などの変換を利用できます。ただし、検出結果を完全とみなさず、対象データに合わせて検出ルールと確認方法を定めます。

ログには、利用者、エージェント、ツール、対象データ、操作、処理結果を関連付けるための識別子を残します。一方、取得したデータやプロンプト全文を無条件に保存すると、ログ自体が機密情報の保存先になります。記録する項目、マスキング方法、閲覧権限、保存期間を決めます。

Google Cloudの操作はCloud Audit LogsやCloud Loggingで確認します。Data Access監査ログは、BigQueryを除く多くのサービスで明示的な有効化が必要です。Google CloudのリモートMCPサーバーについても、Data Access監査ログは初期状態では無効です。

BigQueryでは監査ログに加え、INFORMATION_SCHEMA.JOBSなどから、ジョブの実行主体、クエリ、処理量、エラーを確認できます。INFORMATION_SCHEMA.JOBSのジョブ履歴は過去180日分です。より長期間保持する必要がある場合は、監査ログの保存先と保持期間を別途設計します。

エージェントの実行、ツール呼び出し、データソースの監査ログは、セッションID、トレースID、処理IDで関連付けます。Agent Observabilityは、エージェントやMCPサーバーの動作、トレース、エラーを把握するために使えますが、データソース固有の監査記録を置き換えるものではありません。Agent Observabilityは2026年6月18日に一般提供となっています。

データを取得できない場合の動作も、データソースごとに決めます。最新値を確認できない場合は回答を保留する、古いキャッシュを使う場合は取得時刻を示す、更新は停止するといった扱いです。

7. 本番運用前の確認項目

本番運用を始める前に、次の点を確認します。

8. まとめ

AIエージェントのデータ連携では、データへ接続できることを完成条件にしてはいけません。

参照、検索・集計、更新を分け、業務上の正とするデータ、鮮度、権限、根拠、失敗時の動作、監査方法を定めます。特に更新処理には、読み取りとは別のツール、専用の権限、実行前の確認、重複防止、結果確認を適用します。

Google Cloudのサービスは、その設計を実装するための選択肢です。製品を先に選ぶのではなく、エージェントに何を読み取らせ、何を変更させ、どこで停止させるかを先に決めることが、安全なデータ連携の出発点です。

参考情報

• Agent Identity overview
• Agent Gateway overview
• Agent Observability overview
• Generative AI App Builder release notes
• RAG Engine overview
• RAG Engine supported documents
• Google Cloud MCP servers overview
• Google Cloud MCP servers: supported products
• Introduction to BigQuery row-level security
• Introduction to BigQuery column-level security
• Use row-level security with other BigQuery features
• JOBS view
• IAM database authentication
• About Language Connectors
• Cloud Audit Logs overview
• Sensitive Data Protection overview
• De-identify sensitive data
• InfoType detector concepts