公開2026.08.17更新2026.09.27 Google Cloud

BigQuery MCPサーバーの接続手順｜6ツールの権限分離とスキャン量の制御設計

BigQueryにAIエージェントからSQLを書かせる構成は、Google Cloudがホストするリモートのモデルコンテキストプロトコル（MCP）サーバーによって、自前でサーバーを立てる工程が消えました。残るのは権限と課金の設計です。この記事では、2026年8月17日に実測した6ツールの内訳、読み取り専用に寄せる二層の権限分離、スキャン量が跳ねないための割り当てとテーブル設計、本番データセットへ接続してよい条件までを順に整理します。

まとめ：接続前に決めるツール範囲・課金プロジェクト・本番接続の線引き

先に結論を置きます。着手前に決めるのは3つです。第一に、書き込み可能な execute_sql を残すか、SELECT限定の execute_sql_readonly だけに絞るか。第二に、ツール引数の projectId が課金先そのものになるため、どのプロジェクトを充てて割り当てを敷くか。第三に、本番データセットへ直接つなぐのか、コピーした検証用データセットに留めるのか。

この3点を後回しにすると、全ツールを開いたまま本番プロジェクトに接続した検証環境が、そのまま日常業務に居座ります。エージェントが投げたクエリは通常のクエリジョブとして課金され、走査バイト数は事後にしか見えません。接続作業自体は短時間で終わります。時間を割く価値があるのは、そのあとの権限とコストの締め方のほうでした。

BigQuery MCPサーバーの提供形態とリモート・ローカルの選択基準

BigQueryをMCP経由でつなぐ方法は、Google Cloudがホストするリモート型と、自分の環境で動かすローカル型に分かれます。選択で権限を締める場所が変わります。

リモートMCPサーバーのエンドポイントと有効化に必要なgcloudコマンド

リモートMCPサーバーのエンドポイントは bigquery.googleapis.com の mcp パスで、トランスポートはHTTPです。サーバーをデプロイする作業はありません。プロジェクト側での有効化は gcloud beta services mcp enable にサービス名 bigquery.googleapis.com とプロジェクトIDを渡す形で、無効化は同じ体系の disable コマンドで戻せます。

認証はIAMとOAuth 2.0で行われ、APIキーは受け付けません。必要なOAuthスコープは bigquery スコープ1本です。クライアント認証情報とデータでプロジェクトを分けている場合、両方で有効化が要ります。

提供区分には注意してください。2026年8月17日時点の公式ドキュメント日本語版は、この機能を「プレビュー版」と明示し、pre-GA サービス規約の対象だと記載しています。BigQuery本体の仕組みや課金モデルから確認したい場合は、サーバーレスDWHとしてのBigQueryの仕組みと採用判断を先に読むと前提が揃います。

tools/listで確認できる6ツールと読み取り専用フラグの内訳

公式ドキュメントは、ツール一覧の取得に認証が要らないと明記しています。2026年8月17日にエンドポイントへ tools/list を直接POSTしたところ、返ってきたツールは6件でした。各ツールにはMCPのアノテーションが付き、読み取り専用かどうかを機械的に判別できます。

ツール名	役割	readOnlyHint	destructiveHint
list_dataset_ids	データセットIDの一覧取得	true	false
get_dataset_info	データセットのメタデータ取得	true	false
list_table_ids	テーブルIDの一覧取得	true	false
get_table_info	テーブルのスキーマ取得	true	false
execute_sql_readonly	SELECT限定のクエリ実行	true	false
execute_sql	制限なしのクエリ実行	false	true

一覧系と情報取得系の4ツールはページネーションに対応し、pageSize と pageToken で件数を絞れます。クエリ実行系の2ツールは引数が projectId・query・dryRun の3つだけで、走査バイト数の上限を渡す口はありません。ここが後述するコスト制御の設計に効いてきます。

ローカルMCP（MCP Toolbox）を選ぶ条件と機能面の差

公式ドキュメントがローカル型を選ぶ理由として挙げるのは2つ。パラメータ化したSQLクエリでカスタムツールを組む場合と、リモート側を有効化・使用する権限が無い場合です。

権限設計の観点では、ローカル型のほうが締める手段が多く用意されています。オープンソースのMCP Toolbox for Databases のBigQueryソースには writeMode という設定があり、既定の allowed は全ステートメントを許し、blocked はSELECTのみ、protected はセッション内の一時データセットへの書き込みだけを許したうえで恒久データセットへの変更を止める挙動でした。加えて allowedDatasets でツールが触れるデータセットを列挙でき、リクエスト内の参照テーブルがリストの外にあれば拒否されます。

リモート型には、この allowedDatasets に相当する設定がありません。締めるならIAM側です。MCPという規格そのものの構造やクライアントとサーバーの役割分担が曖昧なら、AIと外部ツールをつなぐ標準規格としてのMCPの仕組みを先に押さえておくと、以降の権限設計の話が読みやすくなります。同じ二層の絞り込みをFirebase側で組むなら、Firebase MCPサーバーの機能グループとIAMによる権限設計が対応します。

接続手順とIAMロール設計：読み取り専用に寄せる二層の権限分離

手間がかかるのは、誰がどのツールでどのデータに届くかの設計です。

BigQuery MCPの有効化と接続に必要な4ロールの権限内訳

公式ドキュメントは、有効化から利用までに必要なロールを4つ挙げています。プロジェクトでAPIとMCPサーバーを有効にする Service Usage 管理者（roles/serviceusage.serviceUsageAdmin）、MCPツール呼び出しを行う MCP ツールユーザー（roles/mcp.toolUser）、BigQueryジョブを実行する BigQuery ジョブユーザー（roles/bigquery.jobUser）、データをクエリする BigQuery データ閲覧者（roles/bigquery.dataViewer）の4つです。実際に効いている個別権限は、有効化側が serviceusage.mcppolicy.get と serviceusage.mcppolicy.update、利用側が mcp.tools.call・bigquery.jobs.create・bigquery.tables.getData でした。

有効化は情シスや基盤担当が一度だけ実施し、常用アカウントには serviceusage 系を残さない
mcp.tools.call はMCP経由の呼び出しそのものを許すスイッチで、剥がせば接続だけを止められる
bigquery.tables.getData はデータセット単位で付与でき、ここが実質的なデータ境界になる

常用アカウントに渡すのは、下2つのジョブ実行とデータ閲覧に留めるのが扱いやすい形です。エージェント用のサービスアカウントも同じ考え方で切ります。

Gemini CLIとClaude Codeへのサーバー登録で入れる項目

クライアント側の登録は、ホストプログラムへリモートMCPサーバーの情報を渡すだけです。入力するのはサーバー名、サーバーURLまたはエンドポイント、トランスポート、認証の詳細の4項目にとどまります。

ホスト側でリモートMCPサーバーを追加する画面またはJSON設定を開く
サーバーURLに bigquery.googleapis.com の mcp を指定し、トランスポートはHTTPを選ぶ
Google Cloudの認証情報、OAuthクライアントIDとシークレット、エージェントのIDと認証情報のいずれかを設定し、スコープに bigquery を指定する
接続後、ツール一覧が6件返るかをクライアント上で確認する

Gemini CLIとClaude Codeは、それぞれのMCPサーバー設定手順が公式から案内されています。HTTPで直接叩く形との使い分けは、BigQuery APIの選び方と権限・リトライ設計にまとめてあります。

execute_sqlを外して読み取り専用ツールだけ残す判断

6ツールのうち、destructiveHint が true なのは execute_sql の1つだけでした。公式のツール説明も「可能であれば execute_sql より execute_sql_readonly を優先する」と明記しています。読み取り専用側はSELECTのみに制限され、INSERT・UPDATE・DELETEとストアドプロシージャは拒否されます。

読み取り専用のツールにはMCP属性 mcp.tool.isReadOnly が true で設定され、組織のポリシーで読み取り専用ツールだけを許せます。どのMCPサーバーを許すかは gcp.managed.allowedMCPService 制約で制御します。

判断としては、分析用途で接続するなら execute_sql は外してかまいません。テーブル作成やDML実行まで任せたいという要望は出ますが、その用途はCI経由のSQL実行やスケジュールクエリのほうが履歴も差分も残ります。書き込みを許すのは、対象が使い捨ての検証用データセットに限られる場合だけに絞ってください。

データセット単位の絞り込みをIAMと承認済みビューで賄う権限設計

リモートMCPサーバーには、ローカル型の allowedDatasets に相当する設定がありません。データの境界は、接続に使う主体へ bigquery.dataViewer をどの粒度で付けるかで決まります。プロジェクト全体に付ければ全データセットが見え、データセット単位で付ければそのデータセットだけが見えます。

個人情報を含む列を残したまま接続するなら、ポリシータグによる列レベルのアクセス制御を重ねてください。get_table_info はテーブルのスキーマを返し、フィールド定義には policyTags や dataPolicies が含まれるため、タグを付けた列は権限のない主体から読めません。集計結果だけを見せたい場合は、承認済みビューを別データセットに置く形が扱いやすい構成でした。

設計は二層です。上の層でツール（execute_sql を許すか）を絞り、下の層でデータ（どのデータセットとどの列に届くか）を絞る。片方だけでは、読み取り専用でも全社データが見える状態が残ります。

スキャン量の暴走を防ぐ制御：割り当て・パーティション・ジョブラベル監視

公式ドキュメントは、リモートMCPサーバー自体に独自の割り当てが無く、呼び出し回数にも制限が無いと記載しています。制御はBigQuery側で行う前提です。

dryRunで処理バイト数を先に返させるプロンプト側の制御設計

execute_sql_readonly の入力スキーマは projectId・query・dryRun の3フィールドだけです。dryRun を true にするとジョブは実行されず、クエリが有効なら処理されるバイト数などの統計が返り、無効ならエラーが返ります。既定値は false でした。

ジョブ設定で使う maximum_bytes_billed のように、上限を超えたら止めるパラメータはツール引数に存在しません。そのためエージェント側の指示で「大きなテーブルへのクエリはまず dryRun で処理バイト数を確認する」という手順を明文化しておきます。応答には totalBytesProcessed と totalBytesBilled が含まれるので、実行後の実績も同じ経路で拾えます。

ただしこれは規約ではなく指示です。止める仕組みは、次の割り当てとテーブル設計側に置いてください。

QueryUsagePerDayとユーザー単位割り当ての設定と限界

BigQueryのカスタム割り当ては2種類あります。プロジェクト内の全ユーザーの合計使用量を制限する QueryUsagePerDay と、各ユーザーおよびサービスアカウントへ個別に適用される QueryUsagePerUserPerDay です。超過すると usageQuotaExceeded エラーが返ります。

ここで期待値を合わせておきます。公式ドキュメントは、カスタム割り当てを「概算」であり、過剰な支出に対する追加の安全策ではあるが処理バイト数を厳密に制限する設計ではないと述べています。上限で完全に止まる仕組みではない、という理解で敷いてください。

MCP接続用のサービスアカウントを専用に切り、ユーザー単位の割り当てを設定すると被害範囲を分けやすくなります。オンデマンド課金とEditionsのどちらを敷いているかで前提が変わるため、オンデマンドとEditionsの分岐点とストレージ課金の内訳を確認して数値を決めてください。

パーティションフィルタ必須化とクラスタリングによる走査抑止設計

エージェントが書くSQLは、人が書くSQLよりWHERE句が緩くなりがちです。スキーマだけを見て日付条件を落としたクエリを投げれば、数TBのテーブルを丸ごと走査します。テーブル側で止める手段が require_partition_filter でした。

パーティション分割テーブルにこのオプションを付けると、パーティション列への条件が無いクエリはエラーになります。エージェントはエラー本文を読んで条件を足したクエリを投げ直すため、対話は止まりません。クラスタリングの併用で読み取りバイト数も減ります。

接続対象が未パーティションの巨大テーブルなら、日付パーティションを切り直すか、期間を限定したビューを用意してからつないでください。順序を逆にすると、初日の検証で月次予算を使い切ることがあります。

goog-mcp-serverラベルでMCP経由クエリを切り分ける監視

execute_sql_readonly で実行されたクエリには、ジョブラベル goog-mcp-server が true で自動的に設定されます。監視ではこの自動ラベルが効きました。INFORMATION_SCHEMA のジョブビューをラベル条件で絞れば、MCP経由のクエリだけを人手のクエリやスケジュール実行と切り分けて集計できます。

見るべき指標は3つです。日次の合計課金バイト数、1クエリあたりの最大課金バイト数、そして失敗ジョブの割合。3つ目は、権限不足やパーティションフィルタ違反による試行錯誤の量を示します。課金先はツール引数の projectId なので、エージェント用のプロジェクトを分ければ請求の段階でも切り分けられます。

本番データセットへAIエージェントを接続する条件と見送る体制の判断

技術的に接続できることと、業務で接続してよいことは別に扱います。

読み取り専用ツールと課金プロジェクト分離を条件にした本番接続の可否

本番データセットへ接続してよいのは、次の4条件がそろった場合だと考えています。execute_sql を組織のポリシーで排除し読み取り専用ツールに限定していること。接続主体が専用のサービスアカウントまたは個人アカウントで、bigquery.dataViewer がデータセット単位に付与されていること。課金プロジェクトが分離され、ユーザー単位のカスタム割り当てが設定されていること。対象テーブルにパーティションフィルタ必須が設定されているか、期間を限定したビュー越しに参照させていること。

この4条件は互いを補います。ツールを絞っても課金は止まらず、割り当てを敷いてもデータの見える範囲は狭まりません。4つそろえば、最悪ケースは「割り当てを使い切って当日のクエリが止まる」に収まります。なお、プレビュー版という提供区分も判断材料です。仕様変更を織り込めない基幹業務のワークフローに常設で組み込むのは、時期尚早だと見ています。

MCP接続を見送るべき体制：権限設計とレビューが未整備の組織

見送ったほうがよい体制を、条件付きで挙げます。BigQueryの権限がプロジェクト単位でしか付与されておらず、データセット単位の設計が無い組織。接続した瞬間に、全社データがエージェントの参照範囲に入ります。切り直す作業が先です。

個人情報や与信情報を含むテーブルが、列レベルの制御もビューによる遮蔽も無いまま同居している場合も同じです。エージェントの出力はチャット履歴やログに残り、クライアント側の保存範囲まで管理者が押さえられるとは限りません。

もう1つ、コストの責任者が決まっていない組織も見送りが無難です。走査バイト数は使う人の熟練度に依存せず、質問の形だけで数十倍に振れます。誰が日次の数字を見て止めるのかが決まらないまま常時接続に進むと、月末に判明します。

AIエージェントへ任せる範囲と人の承認を残す操作の実務的な線引き

任せてよいのは、スキーマ探索と単発の集計です。list_dataset_ids と list_table_ids で所在を当て、get_table_info で列と説明を読み、execute_sql_readonly で集計する。人が同じ作業をするより速く、間違えても読み取りしか起きません。

人の承認を残すのは、定義の確定と繰り返し実行です。「売上」「稼働率」といった指標の定義を推測に任せると、テーブルの選び方ひとつで数字が変わります。日次レポートに昇格させる段階では、SQLをレビューしてビューやスケジュールクエリに固定してください。この定義をエージェント側へ持たせる方式は、BigQuery Conversational Analyticsのコンテキスト整備で扱った検証済みクエリと用語集が担います。

この線引きを社内の業務フローに落とし込む段階では、権限設計とエージェント側の指示設計を同時に見る必要があります。自社の環境に合わせた構成や、既存の業務システムとの接続まで含めて設計を相談したい場合は、AIエージェント開発の支援内容をご確認ください。

BigQuery MCPサーバーの導入・権限・課金でよくある質問

接続と運用設計で判断が分かれやすい点を5つに絞って整理します。

BigQuery MCPサーバーの利用に追加料金はかかりますか？

MCPサーバー自体に固有の料金は設定されていません。発生するのは、ツールが呼び出すBigQuery APIの通常料金です。execute_sql_readonly と execute_sql は jobs.Query を呼ぶため、クエリジョブとして課金され、課金先はツール引数の projectId で指定したプロジェクトになります。リモートMCPサーバーには独自の割り当ても呼び出し回数の制限もないため、歯止めはカスタム割り当てやテーブル設計側で用意してください。

execute_sqlを無効にして読み取り専用だけにできますか？

読み取り専用のMCPツールにはMCP属性 mcp.tool.isReadOnly が true で設定されており、組織のポリシーによって特定の環境で読み取り専用ツールのみを許す運用ができます。tools/list が返す6ツールのうち、destructiveHint が true なのは execute_sql だけでした。接続主体から書き込み権限を外せば、ツール側とIAM側の二重で止められます。

特定のデータセットだけをエージェントに見せる方法はありますか？

リモートMCPサーバーには、参照先データセットを列挙して制限する設定が用意されていません。IAM側で実現します。接続に使うサービスアカウントへ BigQuery データ閲覧者をデータセット単位で付与し、プロジェクト全体への付与は避けてください。集計結果だけを見せるなら承認済みビューを専用データセットに置き、列単位で隠す情報にはポリシータグを重ねます。

プロンプトインジェクション対策は用意されていますか？

Google Cloud は Model Armor というサービスを提供しており、LLMのプロンプトとレスポンスを事前にスクリーニングします。プロジェクトで modelarmor のAPIを有効化し、フロア設定でMCPのサニタイズと悪意のあるURL・プロンプトインジェクションのフィルタを有効にしたうえで、MCPのコンテンツセキュリティプロバイダとして追加する流れです。ただし公式ドキュメントには、リクエスト失敗時にペイロード全体がログへ記録され、機密情報が露出しうるという注意書きがあります。ログの閲覧権限もあわせて設計してください。

ツールの一覧はどうすれば最新の状態を確認できますか？

tools/list メソッドは認証を必要としません。エンドポイントへJSON-RPC形式でメソッド名を投げるだけで、その時点で公開されているツール名・説明・入力スキーマ・アノテーションが返ります。MCPインスペクタから確認する方法も公式に案内されていました。本記事の6ツールは2026年8月17日の実測値で、プレビュー版という提供区分の性質上、構成や引数は変わりえます。設計前に自分の環境で一度取得してください。