データベースを操作するたびに IDE の外に出る——そういう開発フローを当たり前だと思っていませんか? BigQuery のコンソールを開き、クエリを書き、結果を確認して、また IDE に戻る。この行き来、地味に時間を取られます。
2026年4月、Google が正式リリースした MCP Toolbox for Databases v1.0.0 は、そのワークフローを根本から変えてくれます。Antigravity のエージェントが BigQuery・AlloyDB・Spanner・Cloud SQL などの Google Cloud データベースに直接アクセスできるようになり、「スキーマを調べてほしい」「このカラムに NULL が何件あるか確認して」という問いかけをエディタ内で完結できるようになりました。
MCP Store を使ったセットアップから、実際のクエリ実行・スキーマ解析まで、私が試して有用だと感じたパターンを順番にご紹介します。
MCP Toolbox for Databases とは
MCP Toolbox for Databases は Google が開発・公開しているオープンソースの MCP サーバーです(GitHub: googleapis/mcp-toolbox)。Model Context Protocol(MCP)に準拠した設計により、Antigravity のエージェントがツールとしてデータベース操作を呼び出せます。
対応データベースは現時点で以下の通りです:
- AlloyDB for PostgreSQL
- BigQuery
- Bigtable
- Cloud SQL(MySQL / PostgreSQL / SQL Server)
- Spanner
- Looker
- その他(MySQL・PostgreSQL・Neo4j・Dgraph など)
v1.0.0 はプロダクション利用を想定した設計になっており、接続の認証は Google Cloud のサービスアカウントや Application Default Credentials(ADC)で管理されます。アクセストークンを手で管理する必要がなく、セキュリティ的に安心できる点が気に入っています。
Antigravity MCP Store からのセットアップ
最も手軽なのは Antigravity 内蔵の MCP Store を使う方法です。
- Antigravity を開き、左パネル上部の「...」アイコンをクリック
- 「MCP Servers」を選択
- 検索欄に「mcp-toolbox」と入力
- 「MCP Toolbox for Databases」を選択してインストール
インストール後、~/.antigravity/mcp.json(または .antigravity/mcp.json)に次のような設定が追加されます:
{
"mcpServers": {
"mcp-toolbox": {
"command": "toolbox",
"args": ["--config", "${workspaceFolder}/.toolbox/tools.yaml"],
"env": {
"GOOGLE_CLOUD_PROJECT": "${env:GOOGLE_CLOUD_PROJECT}"
}
}
}
}続いて、プロジェクトルートに .toolbox/tools.yaml を作成してデータベース接続を定義します。
BigQuery との接続実践
BigQuery への接続設定はシンプルです。.toolbox/tools.yaml に以下を記述します:
sources:
my-bigquery:
kind: bigquery
project: your-gcp-project-id
tools:
run-query:
kind: bigquery-sql
source: my-bigquery
description: "BigQueryでSQLクエリを実行する"
statement: |
${sql}
parameters:
- name: sql
type: string
description: "実行するSQLクエリ"
get-schema:
kind: bigquery-sql
source: my-bigquery
description: "指定テーブルのスキーマ情報を取得する"
statement: |
SELECT column_name, data_type, is_nullable
FROM `your-gcp-project-id`.INFORMATION_SCHEMA.COLUMNS
WHERE table_name = '${table_name}'
ORDER BY ordinal_position
parameters:
- name: table_name
type: string
description: "スキーマを取得するテーブル名"認証は事前に gcloud auth application-default login を実行しておけば ADC が自動で使われます。
設定後、Antigravity のチャットで次のように聞けます:
/agent: users テーブルのスキーマを確認して、NULL 値が多いカラムをレポートして
エージェントは get-schema ツールを呼び出してスキーマを取得し、続いて NULL カウントの SQL を生成して実行し、結果をまとめてくれます。手動で3ステップかけていた作業が、一度の指示で完結します。
AlloyDB for PostgreSQL との接続
AlloyDB の設定も同様のパターンですが、接続エンドポイントの指定が必要です:
sources:
my-alloydb:
kind: alloydb-postgres
project: your-gcp-project-id
region: asia-northeast1
cluster: your-cluster-name
instance: your-instance-name
database: your-database-name
user: your-db-user
password: ${env:DB_PASSWORD}
tools:
run-alloydb-query:
kind: postgres-sql
source: my-alloydb
description: "AlloyDBでSQLクエリを実行する"
statement: |
${sql}
parameters:
- name: sql
type: string
description: "実行するSQLクエリ"パスワードは環境変数から読み込む形にしておくと、.toolbox/tools.yaml をリポジトリにコミットしても認証情報が漏れません(.env は .gitignore に追加してください)。
エージェントに任せると便利な操作パターン
セットアップが完了すると、開発中に地味に便利なユースケースが出てきます。私が特に気に入っているのは次の3パターンです。
スキーマ解析とコード生成の連携: 「orders テーブルのスキーマを見て、TypeScript の型定義を生成して」という指示でエージェントが実際のカラム定義からコードを生成してくれます。スキーマとコードの不一致が起きにくくなります。
マイグレーション前の影響調査: 「user_id カラムを uuid 型に変更する場合、依存しているテーブルとクエリ数を調べて」という調査をエージェントが引き受けてくれます。これが地味に手間なので助かります。
データ品質チェック: 「先月登録された users の中で、email が空、または重複しているレコードを報告して」という監査的な確認も、自然言語で依頼できます。
MCP エコシステムの全体像を把握したい方はこちらを参照してください。
よくあるつまずき2点
① Application Default Credentials が見つからないエラー
Error: google.auth.exceptions.DefaultCredentialsError:
Could not automatically determine credentials.
このエラーは gcloud auth application-default login を実行していないか、GOOGLE_APPLICATION_CREDENTIALS 環境変数が設定されていない場合に発生します。ローカル開発なら ADC ログイン、CI/CD 環境ならサービスアカウントキーの設定を確認してください。
② BigQuery のクォータエラー
Error: 403 Quota exceeded for quota metric 'queries'
無料クォータを超えた場合に発生します。開発中は LIMIT 句を必ず付ける、またはテスト用データセットを用意しておくと安心です。MCP Toolbox の max_rows パラメータで返却行数を制限することもできます。
自分のプロジェクトに取り込む最初の一歩
まず試してほしいのは、手元のプロジェクトで最もよく使う BigQuery または Cloud SQL のテーブルを1つ選んで、get-schema ツールだけ設定してみることです。それだけでも「スキーマを調べるためにブラウザを開く」習慣がなくなります。
カスタム MCP サーバーの作り方はこちらでも詳しく解説しています。AlloyDB や Spanner など、複数データベースへの接続が安定してきたら、データパイプライン全体をエージェントで監視・修復するところまで発展させていくのも面白い方向性だと思います。