Data Agent Kitが正式版、AIに渡す権限は利用者のまま

|著者: QUASA編集チーム|2 分で読めます| 1
Data Agent Kitが正式版、AIに渡す権限は利用者のまま

Google Cloudは2026年9月30日付の発表でData Agent Kitの一般提供を明らかにし、BigQuery Graph、Bigtable、Managed Service for Apache Sparkへの対応を追加した。コーディングエージェントがデータを操作するときは、利用者本人、または利用者が偽装するサービスアカウントの権限で接続する。既存のIAMと行・列レベルの制御が適用されるため、自然言語で作業を頼んでもアクセスできる範囲が自動的に広がるわけではない。

Data Agent Kitは、Google Cloudのデータサービスを使うためのMCPツールとエージェントスキルの集合だ。IDE拡張かコーディングエージェント用プラグインを導入し、Google Cloudにサインインして対象サービスを選ぶ。韓国の技術解説が整理するように、キット自体に追加料金はない一方、エージェントが実行するクエリやSparkの処理などには利用したクラウドサービスの標準料金がかかる。

BigQuery Graph、Bigtable、Sparkで増えた操作

今回の一般提供では、エージェントが扱えるデータの種類と作業が広がった。MCPツールはスキーマの参照、クエリの実行、ジョブログの取得、リソースの操作をサービスにつなぐ。スキルはBigQuery SQLの最適化やBigtableの行キー設計など、作業手順に関する指示を与える。スキルが適切な手順を示しても、実際の読み取りや変更には接続主体の権限が必要だ。

BigQuery Graphでは、既存の表をノードとエッジに対応づける案をエージェントが作り、関係をデータと照合したうえで、作成前に利用者へ計画を示す。別のスキルがGQLによる照会を支援し、IDEでは結果をたどれる。すでにBigQuery Graphの利用条件を検討している場合、グラフ自体の提供条件に加え、エージェントにグラフ作成まで許すか、照会だけに絞るかが判断点になる。

Bigtable向けのスキルは読み取り方に合わせた行キーを提案し、ホットスポットや全表スキャンにつながる設計を事前に指摘する。許可された操作ではテーブルを作成し、GoogleSQLで照会できる。Managed Service for Apache Sparkでは、Apache Icebergの表をSparkから扱えるようになり、セッション内で一時ビューを引き継げる。クエリの参照、表の作成、Sparkでの処理は影響範囲が異なるため、同じデータサービスへの接続でも必要な権限を一括りにはできない。

エージェントが使う権限は接続主体で決まる

権限設計の起点は、どのエージェントを使うかより、Google Cloudに誰として接続するかだ。本人の認証情報で接続すれば本人のIAM権限が適用される。サービスアカウントを偽装する構成では、そのアカウントに許された操作がエージェントの実行範囲になる。利用者が偽装できるアカウントと、偽装先に付与されたデータ権限を合わせて考える必要がある。

行・列レベルのポリシーが設定されたデータでは、接続主体に応じて取得できる内容も制限される。エージェントがKnowledge Catalogから表の説明や所在を見つけても、その表を読める権限まで得るわけではない。一方、接続主体に表の作成や変更を許していれば、その範囲の操作はエージェントにも及ぶ。参照だけを任せる構成と、データ資産の変更まで任せる構成の差は、指示文ではなくIAMとデータ側のポリシーに表れる。

Google Cloud側では、管理者がIAMでMCPへのアクセスを管理できる。発表ではModel ArmorによるMCP通信の検査、VPC Service ControlsやPrincipal Access Boundaryによる範囲の制御も挙げられている。これらは接続主体に与える権限を決める作業と併せて使う機能であり、キットをインストールしただけで個々のプロジェクトやデータセットの権限が決まるわけではない。

IDE拡張とプラグインでは導入経路が違う

画面上でデータ資産を探し、クエリとエージェントの作業結果を行き来するならIDE拡張が対応する。VS Codeや互換エディタの拡張機能として導入でき、エディタ内にデータ資産やワークロードを見る画面が加わる。Cloud ShellとCloud Workstationsには導入済みの環境が案内されており、利用時はGoogle Cloudへのサインインが必要になる。

普段のコーディングエージェントから自然言語で依頼する経路がプラグインだ。対応先にはClaude Code、Codex CLI、Gemini CLI、Antigravity CLIが含まれる。プラグインはエージェントにスキルとMCPツールを追加するが、IDE拡張の資産閲覧画面そのものを提供する経路ではない。利用者が必要とするのがエディタ内の探索画面なのか、既存エージェントからの操作なのかで選択が変わる。

導入後はサインインして利用するGoogle Cloudサービスを選ぶ。案内されたセットアップでは、必要なAPIの有効化、対応するスキルの導入、MCPサーバーの設定が進む。ただし、組織の設定により利用者がAPIを有効化できない場合は、その権限を持つ管理者の対応が要る。セットアップの自動化は接続設定の手間を減らすが、データの読み取りや変更に必要なIAM権限を新たに付与するものではない。

サービス一覧と認証・デプロイの制約

Google Cloudの製品概要は、分析・ガバナンス分野にBigQuery、Dataflow、Managed Service for Apache Spark、Managed Service for Apache Airflow、Knowledge Catalogを、データベース分野にAlloyDB、Bigtable、Cloud SQL、Spannerを挙げ、Cloud Storageも対応対象としている。導入先のサービス名が一覧にあっても、既存の認証方法や自動デプロイ方法をそのまま使えるとは限らない。

データベース認証では差が明確だ。Data Agent KitでAlloyDBに接続する場合、サポートされるのはIAMデータベース認証だけである。Cloud SQLはIAMデータベース認証と組み込みのデータベース認証の両方に対応する。AlloyDBで従来の接続方法を前提にしている環境では、エージェントを選ぶ前に認証方式を確認する必要がある。

パイプラインについては、オーケストレーションパイプラインの自動デプロイがGitHub Actionsに限られる。この条件はData Agent Kitによるすべてのデータ操作がGitHub Actionsを必要とするという意味ではない。別のCI/CD基盤で運用する組織に関係するのは、自動デプロイを導入計画に含める場合だ。エージェントがパイプラインのコードを作れることと、そのパイプラインを既存の配備経路へ自動的に載せられることは分けて判断したい。

導入可否を判断する際の確認項目は、次のように整理できる。

  • 利用する環境に必要なのは、資産閲覧画面を持つIDE拡張か、既存のコーディングエージェント用プラグインか。
  • Google Cloudへの接続主体は本人か、偽装するサービスアカウントか。その主体に参照、実行、変更のどこまで許すか。
  • 対象サービスのAPIとIAM権限、データに設定済みの行・列レベルの制御を満たしているか。
  • AlloyDBやCloud SQLの認証方式、パイプラインで使う自動デプロイ経路が対応条件に合うか。
  • キットの追加料金とは別に、クエリや処理で生じる各サービスの利用料金を見込んでいるか。

本番データへの接続で最も大きな差を生むのは、エージェントに作業を依頼する文面より、接続主体に許した操作の範囲だ。閲覧だけを許すか、表やパイプラインの変更まで許すかによって、同じData Agent Kitを導入しても実行できる作業は変わる。

関連記事：

共有:

関連記事

ニュースレターを購読

Web3、AI、暗号資産の最新ニュースを受信箱にお届けします。

0