Cloud SQL に触る道が増えた — Next '26 新発表の Data API（HTTP）と Remote MCP サーバ（AI経由）を両方試してみた

Last updated at 2026-07-01Posted at 2026-06-30

こんにちは！
KDDIアイレットの取り組みとして6月22日〜7月3日の期間で開催中の「Google Cloud Next '26 / Google I/O やってみた系ブログリレー」、本日は10日目の投稿です。
今回は「Cloud SQL の Data API（HTTP）と Remote MCP サーバ（AI経由）」を対象に、実際に検証してみた様子をお届けします！

前回の記事はこちらです。

Gemini APIのGoogleマップ・グラウンディングを検証！あり・なしで回答を比べてみた by @y-miyake

ざっくり言うと

Next '26 で Cloud SQL に触る新ルートが2つ GA ：HTTP で SQL を叩く Data API、AI から自然言語で DB を触る Remote MCP サーバ
どちらも「Google マネージドで動く + IAM 認証で完結 + DB パスワード不要」が共通点
本記事では両方を個人 Google Cloud プロジェクトで実機検証し、curl で作った articles テーブルを MCP からも読めることを確認

この記事の対象者

Cloud SQL を業務で使っているエンジニア（PostgreSQL / MySQL）
AI エージェントから DB を触らせたいと考えている人（Claude Code / Gemini CLI ユーザー）
管理系の小さな SQL を実行する手段に悩んでいる人（DB ユーザー作成、スキーマ更新など）
Next '26 で何が増えたのかを Cloud SQL 周りで把握したい人

Cloud SQL へのアクセス方法を整理しておく

先に率直に書いておくと、「HTTP で SQL を叩く」も「AI から自然言語で DB を触る」も、これまでまったく不可能だったわけではありません。
ただし、いずれも 自前で何かを動かす必要がありました。本記事の主題は「それらが Google マネージドで提供されるようになった」という変化点です。

従来の主なアクセスルート

どのルートも最終的にアクセスするのは Google Cloud 上の Cloud SQL で、そこは同じです。違うのは次の3点。

接続元：誰が・どこから叩くか
接続先：Cloud SQL のどの IP に届くか
経路：途中で何を経由するか

補足（前提知識）：Cloud SQL は1つのインスタンスに対して Public IP（インターネットから到達可能な IP）と Private IP（同じ VPC 内からのみ到達可能な内部 IP）の両方を割り当てられます。本番運用では Private IP のみ にしてインターネットから遮断するのが一般的です。

ルート	接続元（誰が叩く）	接続先（Cloud SQL のどこ）	経路	使うケース
psql / mysql クライアント	開発者のローカル PC（または踏み台 VM）	Cloud SQL の Public IP（例：`34.146.x.x:5432`）	クライアント → インターネット → Public IP	個人検証や Public IP の検証 DB を手元から叩きたいとき。本番は Private IP 運用が多いのでこの方法は使われにくい
アプリの ORM / SQL Client	アプリのプロセス（Cloud Run / GKE / Compute Engine 等のサーバ側）	Cloud SQL の Private IP（例：`10.x.x.x:5432`）または Public IP	アプリ → 同じ VPC 内 → Private IP	自分たちが作った Web API・バックエンドサーバが、本番運用で DB を読み書きするとき。ユーザーがブラウザやアプリで操作 → リクエストが Cloud Run 等にデプロイされた API に届く → API が Cloud SQL を読み書きして結果を返す、という一番ありふれた構成
Cloud SQL Auth Proxy / Connector	開発者のローカル PC またはアプリのコンテナ	localhost（Proxy が裏で HTTPS で Cloud SQL に到達）	クライアント → localhost → Auth Proxy → HTTPS → Cloud SQL	業務リポジトリの開発環境で、ローカルから本番/検証 DB を安全に触りたいとき。docker-compose で Proxy を上げて localhost に繋ぐパターン
Cloud SQL Studio	開発者のブラウザ	接続意識不要（Console が裏で繋いでくれる）	ブラウザ → Google Cloud Console → Cloud SQL	ローカルに psql 等を入れたくない / ちょっと中身を確認したいときの即席アクセス
`gcloud sql connect`	開発者のローカル PC（gcloud CLI）	Cloud SQL の Public IP（自 IP を一時許可してから）	CLI → 認可ネットワーク追加 → ローカルの psql → Public IP	Public IP の検証 DB に CLI から一発で繋ぎたいとき。ただし Private IP 運用の本番 DB には使えない
OSS の MCP サーバ（genai-toolbox など）	Claude / Cursor 等の AI	MCP サーバ内部から localhost（Auth Proxy）または Public IP	AI → 自前ホストの MCP サーバ → DB ドライバ → Cloud SQL	Claude Code や Cursor から自然言語で DB を触りたいとき。AI 連携は元々できていたが、MCP サーバを自前で動かす運用が必要

「HTTP で SQL を叩く場合」も「AI から DB を触る場合」も、やる気と運用負担さえあれば既に可能だったわけです。

Next '26 で増えた「2 つのマネージドルート」

機能	ステータス	触り方	既存比での新しさ
Cloud SQL Data API	正式リリース（GA）	`curl` / Cloud Run Functions / Workflows などから HTTP で SQL 実行	自前 API ラッパー不要。Cloud SQL Admin API として標準提供
Cloud SQL Remote MCP サーバ	正式リリース（GA）	Claude Code / Gemini CLI / Cursor から自然言語で操作	MCP サーバの自前ホスト不要。Google が用意した URL を繋ぐだけ

補足: GA = 正式公開・本番利用OK

両方とも共通するキーワードは以下です。

Google マネージド：自前で MCP サーバや API ゲートウェイを立てなくていい
IAM 認証で完結：DB パスワード管理が不要（autoIamAuthn=true）
TCP 接続不要：5432 / 3306 を開けなくていい

言い換えると「機能が初めて生まれた」のではなく、「Google が標準サービスとして組み込んだ」のが今回の発表のポイントです。

新ルートに切り替えると、実際の手順がどう変わるか

Data API と Remote MCP それぞれについて、従来やっていたこと → 新ルートでどう変わるかを並べてみます。

Cloud SQL Data API：「プログラムから DB に SQL を投げる」場面

例：CI/CD パイプラインや管理スクリプトから、Cloud SQL に管理用 SQL を投げるシチュエーション。

従来（Auth Proxy + psql ルート）

# 1) Auth Proxy バイナリをダウンロード・起動
./cloud-sql-proxy {プロジェクトID}:asia-northeast1:my-instance &

# 2) psql を別途インストール（apt install postgresql-client など）
# 3) Secret Manager 等から DB パスワードを取り出す
PGPASSWORD=$(gcloud secrets versions access latest --secret=db-password)

# 4) localhost 経由で SQL 実行
psql -h localhost -U postgres -d mydb -c "CREATE USER newuser ..."

→ Proxy バイナリの管理・psql のインストール・パスワードの取り出し、という 3 段階の段取りが必要。

Next '26 後（Cloud SQL Data API ルート）

事前にやっておくこと（初回セットアップ）

gcloud auth login で Google アカウントにログイン済み（実行するとブラウザが開いて Google アカウントを選択 → 認証完了。これで以降 gcloud auth print-access-token でアクセストークンを発行できるようになる）
Cloud SQL Admin API の有効化（gcloud services enable sqladmin.googleapis.com）
Data API を有効化した Cloud SQL インスタンスの作成（--data-api-access=ALLOW_DATA_API フラグつき）
IAM 認証ユーザーを Cloud SQL に追加 + Cloud SQL Instance User ロールを付与
DB の public スキーマに権限付与

上の5項目の具体的なコマンドはこの記事の後半「検証セットアップ手順」セクション（インスタンス作成 → DB 作成 → IAM ユーザー追加 → ロール付与 → スキーマ権限付与）にすべて掲載しています。最初の1回さえこの手順を通せば、以降 SQL を投げたくなったときは下記の curl コマンドを叩くだけで済みます（毎回 Auth Proxy を起動したり psql を立ち上げたりする必要なし）。

# ①トークン取得：gcloud から短命のアクセストークンを発行して TOKEN 変数に入れる
TOKEN=$(gcloud auth print-access-token)

# ②curl で SQL 投げる：上で取得した ${TOKEN} を Authorization ヘッダにセット
curl -sS -X POST \
 -H "Authorization: Bearer ${TOKEN}" \
 -H "Content-Type: application/json" \
 -d '{
 "database": "mydb",
 "sqlStatement": "CREATE USER newuser ...",
 "autoIamAuthn": true
 }' \
 "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT/instances/INSTANCE/executeSql"

→ Proxy バイナリも psql も不要、パスワード管理も不要。初回セットアップさえ済めば、繰り返し利用は curl + gcloud auth print-access-token だけで完結。

この手軽さは、GitHub Actions などの自動化ジョブから「軽い管理 SQL」を流したいときにも有効です。たとえば、

DB ユーザーや権限の追加（CREATE USER ... / GRANT ALL ON ...）
設定値の単発更新（UPDATE settings SET ...）
データ整合性チェック（SELECT count(*) FROM orders WHERE status IS NULL で異常データの件数確認）

こうした「SQL 1〜数本で完結する軽量タスク」が対象です。

従来は Auth Proxy 起動、psql インストール、Secret Manager からパスワード取り出し…と段取りが多めでした。新ルートなら上の 2 コマンドをジョブに貼るだけで済みます。

※ Data API は「軽い単発 SQL を投げる窓口」と理解するのが正確です。Alembic のような マイグレーションツール（複数の SQL を順番に実行し、途中で失敗したら全部ロールバックする、数分かかる処理など）は Data API の制約（30秒タイムアウト・トランザクション継続不可）に引っかかるため、引き続き従来構成（Cloud Run Jobs + Auth Proxy など）が向いています。

補足: たとえると、Data API は「バイク便」のような存在。書類1枚や小包1個を素早く運ぶのは得意ですが、引っ越し業者（=Alembic のような重量級ツール）の代わりにはならないということです。新ルートは「重い既存ジョブを置き換える」のではなく「軽量タスクのための新しい選択肢」として捉えると分かりやすいです。

Cloud SQL Remote MCP：「AI から DB を触る」場面

例：ローカル開発環境のデータベース（docker-compose で立てた PostgreSQL など）の中身を AI に見てもらうシチュエーション。AI は Claude Code、Gemini CLI、Cursor などが該当します。本記事の後半で動かす Gemini CLI も同じ構造です。

従来（OSS の postgres MCP を自前ホストするルート）

このときの .mcp.json はここんな感じです。

{
 "mcpServers": {
 "postgres": {
 "command": "npx",
 "args": [
 "@modelcontextprotocol/server-postgres",
 "postgresql://{DBユーザー名}:{パスワード}@localhost:5432/{DB名}"
 ]
 }
 }
}

→ 設定ファイルに DB 接続文字列（ユーザー名・パスワード込み）を書く必要があります。

さらに localhost:5432 で接続先の実体が稼働している必要があり、docker-compose up などで起動しておかないと動きません。具体的には、ローカル DB を触るなら PostgreSQL コンテナを、Google Cloud の Cloud SQL を触るなら Cloud SQL Auth Proxy コンテナを起動する形です。

注意：ローカルの docker-compose 上のダミー DB ならまだ許容できますが、本番 DB のパスワードを書くのは Git 流出リスク・退職者対応・監査の観点で本来あまりやりたくないことです

Next '26 後（Cloud SQL Remote MCP ルート）

事前にやっておくこと（初回セットアップ）

gcloud auth application-default login で ADC（Application Default Credentials）をセット
触りたい Cloud SQL インスタンスがある Google Cloud プロジェクトで、自分の Google アカウントに Cloud SQL Instance User などの IAM ロールが付与されていること
IAM 認証ユーザーが Cloud SQL に追加済み（Data API 側と同じ前提）

※ docker-compose も Auth Proxy も MCP サーバの自前ホストもいっさい不要。設定済みの環境なら、下記の .mcp.json を書くだけで Claude / Gemini CLI から触れる。

このときの設定ファイルはこんな感じです。Claude Code と Gemini CLI で書式が少し違うので両方並べておきます。やっていることはどちらも同じで、「Google ホストの MCP に URL で繋ぐ」だけ。

Claude Code 用（.mcp.json）

{
 "mcpServers": {
 "cloud-sql": {
 "type": "http",
 "url": "https://sqladmin.googleapis.com/mcp",
 "headers": {
 "x-goog-user-project": "{プロジェクトID}"
 },
 "headersHelper": "echo \"{\\\"Authorization\\\":\\\"Bearer $(gcloud auth print-access-token)\\\"}\""
 }
 }
}

注：headersHelper は Claude Code の公式機能で、接続のたびに指定したコマンドを実行して JSON 出力をヘッダにマージしてくれる仕組みです。これを使うと gcloud auth print-access-token が毎接続時に呼ばれて、トークンが1時間で失効しても自動的にフレッシュなものに差し替わるため、長期運用しても問題ありません（詳細は後述「Claude Code でつなぐ場合」セクション）。

Gemini CLI 用（gemini-extension.json）

{
 "mcpServers": {
 "Cloud SQL MCP Server": {
 "httpUrl": "https://sqladmin.googleapis.com/mcp",
 "authProviderType": "google_credentials",
 "headers": { "x-goog-user-project": "{プロジェクトID}" }
 }
 }
}

→ どちらも書くのは URL とプロジェクト ID だけ。DB ユーザー名もパスワードも書かなくていい。認証は IAM が担当するので「AI に DB のパスワードを渡さなくていい」状態が手に入る。

両方に共通する「変化点」

Data API も Remote MCP も、構造的な変化は同じです。これまで自分で動かしていた仲介役（Auth Proxy バイナリや OSS MCP サーバ）が Google 側に置き換わり、認証も IAM だけで済むようになりました。だから設定ファイルもこんなに違います。

	従来	新ルート
書く必要があるもの	接続情報 + パスワード + 中継ツール起動	URL とプロジェクト ID だけ
AI / クライアントに渡す認証情報	DB パスワード	なし（IAM が裏で担当）
稼働させる必要があるもの	Auth Proxy バイナリ or 自前 MCP サーバ	なし（Google が稼働）

検証環境

ここからは、実際に手を動かして Data API と Remote MCP サーバを動かしてみた検証ログをお届けします。まずは検証に使った環境の構成からご紹介します。

業務環境ではなく個人 Google Cloud プロジェクトで、最小構成の Cloud SQL を1インスタンスだけ立てて検証しました。誰でも同じ構成で再現できるはずです。

項目	値
Google Cloud プロジェクト	個人プロジェクト
Cloud SQL エンジン	PostgreSQL 17
インスタンス Tier	db-g1-small (Enterprise)
Region	asia-northeast1
IAM DB 認証	有効
Data API アクセス	有効
Python	3.9

かかるコストは Cloud SQL の起動代だけです。1〜2 時間サクッと触る程度なら数百円で済みました。検証が終わったらインスタンスを消し忘れないようにだけ注意してください。

検証セットアップ手順

1. Cloud SQL Admin API を有効化

gcloud services enable sqladmin.googleapis.com \
 --project={プロジェクトID}

2. Cloud SQL PostgreSQL インスタンスを作成

ポイントは以下のフラグです。

--database-flags=cloudsql.iam_authentication=on ：IAM DB 認証を ON（Data API / MCP 両方で必須）
--data-api-access=ALLOW_DATA_API ：Data API を有効化

# 注意：--data-api-access フラグは現時点で alpha track でのみ利用可能。
gcloud alpha sql instances create next26-data-api-poc \
 --database-version=POSTGRES_17 \
 --tier=db-g1-small \
 --edition=ENTERPRISE \
 --region=asia-northeast1 \
 --root-password='{任意のパスワード}' \
 --database-flags=cloudsql.iam_authentication=on \
 --data-api-access=ALLOW_DATA_API \
 --project={プロジェクトID}

インスタンス作成には 5〜10 分かかります。

ハマった箇所①：`--data-api-access` フラグが認識されない

何があったか：gcloud sql instances create で Cloud SQL インスタンスを作ろうとしたら、--data-api-access というフラグが「そんなオプション知りません」と怒られた
エラーメッセージ：unrecognized arguments: --data-api-access
理由：gcloud には 3つのリリースチャンネル（正式版 GA / ベータ版 beta / 実験版 alpha）があり、新機能はまず alpha → beta → GA の順で昇格していきます。--data-api-access フラグは検証時点では まだ alpha 段階 にしかないため、普通の gcloud sql ...（GA track）では認識されなかった
直し方（2通り）：
- A. コマンドに alpha を挟む：gcloud alpha sql instances create ... のように、コマンドの 2 番目に alpha を入れる
- B. Google Cloud Console から有効化：Cloud SQL の「インスタンス」ページ → 対象インスタンス → 右側「構成」枠の 「構成の編集」 → 編集ページを下にスクロールして 「接続」セクション を展開 → 最下部の 「Data API の承認」 → 「Data API を許可する」チェックボックス を ON → 保存（作成後でも切り替え可能なので、とりあえずインスタンス作ってからあとで有効化もOK）

3. データベース作成

gcloud sql databases create demo_db \
 --instance=next26-data-api-poc \
 --project={プロジェクトID}

4. IAM ユーザーを Cloud SQL に追加

gcloud sql users create {自分のメールアドレス}@gmail.com \
 --instance=next26-data-api-poc \
 --type=cloud_iam_user \
 --project={プロジェクトID}

5. IAM ユーザーに Cloud SQL Instance User ロールを付与

gcloud projects add-iam-policy-binding {プロジェクトID} \
 --member=user:{自分のメールアドレス}@gmail.com \
 --role=roles/cloudsql.instanceUser \
 --condition=None

6. `public` スキーマ権限を付与

PostgreSQL 15 以降では、デフォルトでは IAM ユーザーが public スキーマに CREATE できません。なので管理者ユーザー（postgres）で接続して、IAM ユーザーに GRANT（権限を与える SQL コマンド）を流す必要があります。

一般的には psql コマンドで実行する手順が紹介されることが多いですが、私の Mac には psql が入っていなかったので（brew install postgresql 等が別途必要）、手元にすでにある Python の psycopg2 で代用しました。やっていることは「postgres ユーザーで TCP 接続して GRANT 文を流す」だけなので、psql でも psycopg2 でも結果は同じです。

補足：このあと出てくる Data API 検証用のスクリプト（data_api_demo.sh や data_api_sample.py）は、psql では代用できません。Data API は「HTTP の Web API として SQL を実行する仕組み」で、TCP 接続で動く psql とは仕組みそのものが別物です。psql で代用できるのは、この手順6 の grant_public_schema.py だけです。

事前準備

スクリプト実行の前に、以下の2つを済ませておきます。

　1. 自分の PC のグローバル IP を Cloud SQL の「承認済みネットワーク」に追加

psycopg2 から Public IP に直接接続するには、Cloud SQL 側で接続元 IP をホワイトリスト（承認済みネットワーク）に登録しておく必要があります。登録しないと接続拒否されます。

gcloud sql instances patch next26-data-api-poc \
 --authorized-networks="$(curl -s https://ifconfig.me)/32" \
 --project={プロジェクトID}

curl -s https://ifconfig.me は「自分の今のグローバル IP を取得」する処理、/32 は「その IP 1個だけを許可」の意味です。

　2. psycopg2-binary をインストール

pip install psycopg2-binary

スクリプトを作成して実行

任意の場所にスクリプトを保存して実行します。私は検証用作業フォルダに scripts/ ディレクトリを作って、その中に置きました（ファイル名は何でも OK）。

mkdir -p scripts
vi scripts/grant_public_schema.py   # 中身は下記をコピペ
python scripts/grant_public_schema.py

スクリプトの中身は以下です。

# scripts/grant_public_schema.py
import psycopg2

# 接続文字列に channel_binding=disable を入れている理由：
# 環境によっては psycopg2 のバージョンと PostgreSQL サーバの設定の組み合わせで
# 「SCRAM channel binding check failed」という SSL エラーが出ることがある。
# このオプションを付けると回避できる。
conn = psycopg2.connect(
 "host={インスタンスのパブリックIP} port=5432 user=postgres password={設定したパスワード} "
 "dbname=demo_db sslmode=require channel_binding=disable"
)
conn.autocommit = True
cur = conn.cursor()
for sql in [
 'GRANT ALL ON SCHEMA public TO "{自分のメールアドレス}@gmail.com"',
 'ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT ALL ON TABLES TO "{自分のメールアドレス}@gmail.com"',
 'ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT ALL ON SEQUENCES TO "{自分のメールアドレス}@gmail.com"',
]:
 cur.execute(sql)
print("granted.")

granted. が出力されれば成功です。これで IAM ユーザーが public スキーマでテーブル作成・更新ができる状態になります。

Cloud SQL Data API を試す

Data API とは何か

ざっくり言うと、Next '26 で新しく登場した「HTTP（REST）経由で SQL を叩けるエンドポイント」です。

技術的な位置づけを整理すると、以下のようになります。

昔からある Cloud SQL Admin API（Cloud SQL のインスタンス作成・削除・設定変更などができる管理用 API 群）
そこに新しく executeSql というエンドポイントが追加された のが Next '26 の発表
それを「Cloud SQL Data API」という機能名でパッケージング・命名したもの

すなわち「Cloud SQL Admin API に SQL 実行用の新しい窓口がついた。それの呼び名が Data API」という関係です。

公式ドキュメントの説明（Cloud SQL Data API（PostgreSQL 日本語版））には以下のように書かれています。

Data API を使用すると、Cloud SQL Admin API と gcloud CLI を使って、Data API アクセスを有効にした任意のインスタンスで SQL ステートメントを実行できます。Data API は、データベースロールやユーザーの作成、小規模なスキーマ更新など、小さくて簡単な管理ステートメントの実行に適しています。

要点をまとめると以下のとおりです。

小さくて速い管理 SQL に最適
DML / DDL / DQL すべて対応（INSERT/UPDATE/DELETE、CREATE TABLE、SELECT）
レスポンスは最大 10MB、リクエストは 0.5MB、タイムアウトは 30 秒
同時実行数はインスタンスあたり 10 まで

ポジションを一言で言うと、アプリの本番ワークロード（高 RPS で連続クエリ）や Alembic のような重量級マイグレーションには向かない一方、ユーザー追加・件数確認・設定値更新など 1〜数本で完結する単発 SQL にはかなり便利、という立ち位置。詳しい向き不向きは後述の「向いている用途・向いていない用途」を参照してください。

curl で叩いてみる

Cloud SQL Data API のエンドポイントはこんな形です。

POST https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME/executeSql

このエンドポイントは「SQL を JSON に詰めて POST すると、結果が JSON で返ってくる」という Web API です。まずは疎通確認として、サーバのバージョンを返すだけの軽い SQL（SELECT version()）を投げてみます。{プロジェクトID} を自分のプロジェクト ID に置き換えれば、そのままコピペで動きます。

curl が裏でやっているのは「Google の API URL（...executeSql）に対して、demo_db（手順3.データベース作成で作った DB）で SELECT version() を実行してください、というリクエストを POST する」だけです。

# ①トークン取得：gcloud から短命のアクセストークンを発行して TOKEN 変数に入れる
TOKEN=$(gcloud auth print-access-token)

# ②Cloud SQL Data API（executeSql エンドポイント）に curl で POST
curl -X POST \
 -H "Authorization: Bearer ${TOKEN}" \
 -H "Content-Type: application/json" \
 -d '{
 "database": "demo_db",
 "sqlStatement": "SELECT version()",
 "partialResultMode": "ALLOW_PARTIAL_RESULT",
 "autoIamAuthn": true
 }' \
 "https://sqladmin.googleapis.com/sql/v1beta4/projects/{プロジェクトID}/instances/next26-data-api-poc/executeSql"

実機レスポンス

{
 "metadata": {
 "sqlStatementExecutionTime": "0.000882995s"
 },
 "results": [
 {
 "columns": [
 { "name": "version", "type": "TEXT" }
 ],
 "rows": [
 {
 "values": [
 { "value": "PostgreSQL 17.10 on x86_64-pc-linux-gnu, compiled by Debian clang version 12.0.1, 64-bit" }
 ]
 }
 ]
 }
 ],
 "messages": [
 { "message": "Execution complete. 1 result set(s) returned.", "severity": "INFO" }
 ]
}

PostgreSQL のバージョン情報が返ってきました。sqlStatementExecutionTime で実行時間（約0.0009秒）まで取れます。

なお上のコードは IAM 認証で叩く形（autoIamAuthn: true）にしてあります。これを試しに外したら次のエラーで弾かれました。

ハマった箇所②：Data API でパスワード認証が使えない

何があったか：上の curl で autoIamAuthn: true を外して false にしてみたら、パスワード認証が拒否された
エラーメッセージ：Password authentication is not supported for this client
理由（観察ベース）：Cloud SQL Data API は IAM 認証で使うのが基本で、autoIamAuthn: true を付ける必要がある。少なくとも検証時点では、postgres ユーザー + パスワードでの認証は受け付けてくれなかった
直し方：リクエストボディに "autoIamAuthn": true を付ける。事前に IAM 認証ユーザーを Cloud SQL に追加し、Cloud SQL Instance User ロールを付与しておく

CREATE → INSERT → SELECT → 集計を `curl` だけでやってみる

次に、実際にテーブルを作って → データを入れて → SELECT で読んで → 集計するまでを全部 curl だけで通してみます。

curl を毎回ベタ書きすると長いので、シェル関数 call で「SQL を渡したら API を叩く」のをラップしました。jq で JSON を組み立てているので、事前に brew install jq で jq を入れておいてください。

手順6.publicスキーマ権限を付与で作った scripts/ ディレクトリに data_api_demo.sh というファイル名で以下を保存し、bash scripts/data_api_demo.sh で実行します。

# scripts/data_api_demo.sh
# 事前準備：brew install jq（mac の場合）

# 自分の環境に合わせて書き換え
PROJECT_ID="{プロジェクトID}"
INSTANCE="next26-data-api-poc"
DATABASE="demo_db"   # 手順3「データベース作成」で作った DB

ENDPOINT="https://sqladmin.googleapis.com/sql/v1beta4/projects/${PROJECT_ID}/instances/${INSTANCE}/executeSql"
TOKEN=$(gcloud auth print-access-token)

# SQL を渡すと Data API を叩いて整形表示するシェル関数
call() {
 local sql="$1"
 curl -sS -X POST \
 -H "Authorization: Bearer ${TOKEN}" \
 -H "Content-Type: application/json" \
 -d "$(jq -n --arg sql "${sql}" --arg db "${DATABASE}" '{
 database: $db, sqlStatement: $sql,
 partialResultMode: "ALLOW_PARTIAL_RESULT", autoIamAuthn: true
 }')" \
 "${ENDPOINT}" | python3 -m json.tool
}

# ①テーブル作成
call "CREATE TABLE IF NOT EXISTS articles (
 id SERIAL PRIMARY KEY, title TEXT NOT NULL, author TEXT,
 published_at TIMESTAMPTZ DEFAULT now())"

# ②3件 INSERT
call "INSERT INTO articles (title, author) VALUES
 ('Next 26 やってみたブログ 1日目', '川島'),
 ('Cloud SQL Data API 入門', '川島'),
 ('Remote MCP Server で AI から DB を触る', '川島')"

# ③全件 SELECT
call "SELECT id, title, author, published_at FROM articles ORDER BY id"

# ④集計（著者ごとの件数）
call "SELECT author, COUNT(*) AS posts FROM articles GROUP BY author"

実行手順は以下です。

# 1) ファイル作成（手順6「public スキーマ権限を付与」で作った scripts/ ディレクトリに保存）
vi scripts/data_api_demo.sh   # 上の中身をコピペ、PROJECT_ID を自分の値に書き換え

# 2) 実行
bash scripts/data_api_demo.sh

call が4回呼ばれて、それぞれ Data API のレスポンス JSON が画面に流れていきます。

全部成功しました。SELECT の結果（一部抜粋）。

{
 "results": [{
 "columns": [
 {"name": "id", "type": "INT4"},
 {"name": "title", "type": "TEXT"},
 {"name": "author", "type": "TEXT"},
 {"name": "published_at", "type": "TIMESTAMPTZ"}
 ],
 "rows": [
 {"values": [
 {"value": "1"},
 {"value": "Next 26 やってみたブログ 1日目"},
 {"value": "川島"},
 {"value": "2026-06-23T13:45:27.697523Z"}
 ]},
 // ... 残り2行
 ]
 }]
}

Cloud SQL Auth Proxy も psql も使わずに、curl だけで DB が完結して触れました。

Python から叩いてみる

同じ Data API を Python からも叩いてみました。bash 版（前のセクション）は「運用スクリプトや CI/CD ジョブに組み込む用途」向け、こちらの Python 版は「Python アプリのコードに組み込む用途」向け、という棲み分けのイメージです。Data API は HTTP の Web API なので、HTTP を喋れる言語ならどこからでも叩けます。

手順6.publicスキーマ権限を付与で作った scripts/ ディレクトリに data_api_sample.py というファイル名で以下を保存します。

# scripts/data_api_sample.py
# 事前準備：pip install requests

import subprocess
import requests

# 自分の環境に合わせて書き換え
PROJECT_ID = "{プロジェクトID}"
INSTANCE = "next26-data-api-poc"
DATABASE = "demo_db"   # 手順3「データベース作成」で作った DB

# ①gcloud からアクセストークンを取得
token = subprocess.check_output(
 ["gcloud", "auth", "print-access-token"], text=True
).strip()

# ②executeSql エンドポイントの URL を組み立て
url = (
 f"https://sqladmin.googleapis.com/sql/v1beta4/projects/{PROJECT_ID}"
 f"/instances/{INSTANCE}/executeSql"
)

# ③requests で POST：SELECT version() を投げる
resp = requests.post(
 url,
 headers={"Authorization": f"Bearer {token}"},
 json={
 "database": DATABASE,
 "sqlStatement": "SELECT version()",
 "partialResultMode": "ALLOW_PARTIAL_RESULT",
 "autoIamAuthn": True,
 },
)

# ④結果を表示
print(resp.status_code)   # 200 が返ってくれば成功
print(resp.json())        # PostgreSQL のバージョン情報が JSON で表示される

実行手順は以下です。

# 1) requests を入れていなければ事前にインストール
pip install requests

# 2) 実行
python scripts/data_api_sample.py

ステータスコード 200 と PostgreSQL のバージョン情報を含む JSON が出力されれば成功です。requests 1個と subprocess で完結する素朴な作りで、特別な SDK は不要です。

Data API の特徴まとめ

触ってみての所感を一言で言うと、「軽い単発 SQL を投げるためのバイク便」。書類1枚や小包1個を素早く運ぶのは得意ですが、引っ越し業者（= Alembic のような重量級マイグレーションツール）の代わりにはなりません。

良かった点

HTTPS 経由なので、Cloud SQL Auth Proxy のバイナリやサイドカーが要らない
Cloud Run Functions から呼びやすい（プライベート IP や VPC コネクタの面倒さがゼロ）
CI/CD で軽い SQL を流し込みやすい。シェルスクリプトで完結する
gcloud sql instances execute-sql でも同じことができる

制約

レスポンス 10MB / リクエスト 0.5MB の上限
30 秒タイムアウト（長時間バッチ用ではない）
同時実行 10 まで（高頻度アクセスには向かない）
IAM 認証で使うのが基本（パスワード認証を試したら弾かれた。詳細は前述「ハマった箇所②」）
トランザクション継続不可（複数 SQL を1トランザクションでまとめる処理は不可）

向いている / 向いていない用途

向いている用途	向いていない用途
DB ユーザーや権限の追加（`CREATE USER ...` / `GRANT ALL ON ...`）	大規模なマイグレーション（Alembic / Flyway など）
設定値の単発更新（`UPDATE settings SET ...`）	アプリの本番ワークロード（高 RPS で連続クエリ）
データ件数の確認（CI で異常データチェック等）	30 秒を超える重い SQL（大量データ集計など）
Cloud Run Functions から軽く DB を読み書き
シェルスクリプトでサクッと管理タスク

Cloud SQL Remote MCP サーバを試す

Remote MCP サーバとは

ざっくり言うと、Next '26 で Google が新しくホストを始めた「AI 用の DB 操作 MCP サーバ」です。

技術的な位置づけは以下のとおりです。

MCP（Model Context Protocol） = Anthropic が提唱した、AI と外部ツールをつなぐためのプロトコル。これ自体は OSS の標準仕様
これまで Cloud SQL を MCP 経由で触りたければ自分で MCP サーバを立てる必要があった（OSS の genai-toolbox 等）
Next '26 で、その MCP サーバを Google 自身がホストして公開し始めたのが「Cloud SQL Remote MCP サーバ」
URL は固定の https://sqladmin.googleapis.com/mcp。中に 15 個のツール（SQL 実行、ユーザー管理、バックアップ等）が用意されている

つまり「OSS で自分で立てていた MCP サーバを、Google がマネージドで提供し始めた」というのが新しさのキモです。

公式ドキュメント（Cloud SQL リモート MCP サーバ（日本語版））には以下のように書かれています。

Cloud SQL のリモート MCP サーバを使用すると、AI エージェントが MCP プロトコル経由で Cloud SQL インスタンスを管理・クエリできるようになります。

ポイントは以下のとおりです。

自分で MCP サーバを立てる必要なし。URL は固定の https://sqladmin.googleapis.com/mcp
対応 DB：PostgreSQL / MySQL / SQL Server すべて
対応エージェント：Gemini CLI / Claude Code など（その他、公式ドキュメント記載のクライアントから接続可能）
認証：ADC（gcloud auth application-default login）+ IAM ロール

Google マネージドで何が省けるか

「マネージド」と言われてもピンとこないと思うので、そもそも MCP サーバってどこで動かす必要があるの？という話から整理します。

MCP サーバを動かす 3 つの場面

「AI から DB を触る」と言っても、誰が叩くか・どこから叩くかで構成が変わります。MCP サーバを置く場所が 3 パターンあります。

パターン A：自分 1 人がローカル PC で使う

→ 一番シンプル。多くの開発者の最初の使い方はこれ。本記事冒頭の業務リポジトリ例（.mcp.json に postgres MCP を登録）もこのパターン。

パターン C：チームメンバーで MCP サーバを共有する

→ 各メンバーが個別に MCP サーバを立てると設定や接続情報がバラバラ・バージョン差で動く動かないが起きる。1か所にまとめて URL を共有することで解決する構成。

パターン D：本番アプリに AI 機能を組み込む

→ 例：社内ツールに「データ分析 AI チャット」を組み込んで、ユーザーが「先月の売上集計して」と入力すると AI が DB に SQL 投げて答える、みたいなサービス。24時間 365日動いてくれる場所が必要なので、ローカル PC ではなくクラウドに置く。

パターン別：何が大変だったか

パターン	従来（OSS の MCP サーバを自前ホスト）
A：自分1人ローカル	Rancher Desktop / Docker Desktop で MCP サーバのコンテナを常に起動しておく必要あり（業務リポジトリの `docker-compose up` と同じ感覚）
C：チーム共有	Cloud Run / GKE などにデプロイして24時間稼働。新バージョンが出ればアップデートして再デプロイ、負荷が増えればスケーリング設定、落ちれば再起動・障害対応…が全部チームの誰かの仕事
D：本番アプリ組み込み	C と同じ運用負担に加えて、本番品質の監視・ログ収集・SLA 運用が必要

つまり、ローカルだけで使うパターン A でも MCP サーバを起動し続ける負担があり、チームや本番で使うパターン C / D になると一気にデプロイ・運用・障害対応の負担が乗ってくる、というのが従来の状態でした。

Remote MCP に切り替えるとどうなるか

パターン	Cloud SQL Remote MCP 後
A：自分1人ローカル	URL に繋ぐだけ。Rancher Desktop すら起動しなくていい
C：チーム共有	全員が同じ Google の URL を `.mcp.json` に書くだけ。Cloud Run へのデプロイ不要
D：本番アプリ組み込み	アプリから URL を直接叩くだけ。MCP サーバの運用ゼロ

つまり「MCP サーバの面倒見」という仕事が 3 パターンすべてでまるごと消えます。これが「Google マネージド」の中身です。

共通の URL：https://sqladmin.googleapis.com/mcp
更新・スケーリング・監視・再起動・障害対応、全部 Google がやってくれる

補足：もし読者の方が「業務リポジトリの docker-compose で postgres MCP を立てて、自分の Claude Code から使ってる」ような状況なら、パターン A に該当します。今の使い方で困っていなければ無理に切り替える必要はありませんが、チームに広げたい、あるいは本番に組み込みたいとなった瞬間に Remote MCP の恩恵が一気に大きくなります。

サーバが動いているか生で叩いて確認

MCP は JSON-RPC over HTTP なので、curl でも生で叩けます。MCP サーバが提供しているツール一覧を取得する tools/list メソッドを呼んでみます。

TOKEN=$(gcloud auth print-access-token)
curl -sS -X POST \
 -H "Authorization: Bearer ${TOKEN}" \
 -H "Content-Type: application/json" \
 -H "x-goog-user-project: {プロジェクトID}" \
 -H "Accept: application/json, text/event-stream" \
 -d '{
 "jsonrpc": "2.0", "id": 1, "method": "tools/list", "params": {}
 }' \
 "https://sqladmin.googleapis.com/mcp"

レスポンス（抜粋）はこんな感じで、各ツールの名前・説明・入力パラメータが JSON で返ってきます。

{
 "result": {
 "tools": [
 {
 "name": "list_instances",
 "description": "List all Cloud SQL instances in a project.",
 "inputSchema": { ... }
 },
 {
 "name": "execute_sql_readonly",
 "description": "Execute a read-only SQL statement against a Cloud SQL instance.",
 "inputSchema": { ... }
 },
 // ... 残り13ツール
 ]
 }
}

tools[].name だけを取り出すと、提供されているツールは全部で 15個 ありました。

カテゴリ	ツール名	できること
DB クエリ系	`execute_sql`	DDL / DCL / DQL / DML など、有効な SQL ステートメントを実行
	`execute_sql_readonly`	読み取り専用の SQL ステートメントを実行（SELECT 等）
インスタンス管理系	`list_instances`	プロジェクト内のすべての Cloud SQL インスタンスを一覧表示
	`get_instance`	Cloud SQL インスタンスの詳細を取得
	`create_instance`	Cloud SQL インスタンスの作成を開始
	`update_instance`	Cloud SQL インスタンスのサポートされている設定を更新
	`clone_instance`	ソースインスタンスのクローンとしてインスタンスを作成
ユーザー管理系	`list_users`	Cloud SQL インスタンスのすべてのデータベースユーザーを一覧表示
	`create_user`	Cloud SQL インスタンスのデータベースユーザーを作成
	`update_user`	Cloud SQL インスタンスのデータベースユーザーを更新
バックアップ系	`create_backup`	Cloud SQL インスタンスのバックアップを作成
	`restore_backup`	Cloud SQL インスタンスのバックアップを復元
データ移行系	`import_data`	Cloud Storage から Cloud SQL インスタンスにデータをインポート
運用系	`get_operation`	Cloud SQL で長時間実行オペレーションのステータスを取得
	`postgres_upgrade_precheck`	PostgreSQL インスタンスがメジャーバージョンアップグレードの準備ができているかを確認

DB クエリだけでなく、インスタンスの作成・複製・バックアップ・リストアまで、Cloud SQL の運用業務にひと通り必要なツールが揃っています。「DB の中身を SELECT する」だけでなく、「運用者の代わりに Cloud SQL を管理する」用途まで意識したラインナップです。

`execute_sql_readonly` を生で叩く

curl -sS -X POST \
 -H "Authorization: Bearer ${TOKEN}" \
 -H "Content-Type: application/json" \
 -H "x-goog-user-project: {プロジェクトID}" \
 -H "Accept: application/json, text/event-stream" \
 -d '{
 "jsonrpc": "2.0", "id": 2,
 "method": "tools/call",
 "params": {
 "name": "execute_sql_readonly",
 "arguments": {
 "project": "{プロジェクトID}",
 "instance": "next26-data-api-poc",
 "database": "demo_db",
 "sql_statement": "SELECT id, title, author FROM articles ORDER BY id"
 }
 }
 }' \
 "https://sqladmin.googleapis.com/mcp"

レスポンス（抜粋）は以下です。

{
 "result": {
 "structuredContent": {
 "results": [{
 "columns": [
 {"name": "id", "type": "INT4"},
 {"name": "title", "type": "TEXT"},
 {"name": "author", "type": "TEXT"}
 ],
 "rows": [
 { "values": [
 {"value": "1"},
 {"value": "Next 26 やってみたブログ 1日目"},
 {"value": "川島"}
 ]},
 // ...
 ]
 }]
 }
 }
}

先ほど Data API で作った同じ articles テーブルを MCP 経由で読めました。

ハマった箇所③：MCP の `execute_sql_readonly` でパラメータ名を間違える

何があったか：Remote MCP の execute_sql_readonly に SQL を渡そうとして、sql という名前で渡したらエラーになった
エラーメッセージ：Missing required parameter: sql_statement
理由：Cloud SQL MCP サーバが期待するパラメータ名は sql_statement であって sql ではない
直し方：パラメータ名を sql_statement に直す。自然言語で Claude / Gemini に頼む場合は AI が自動で正しい名前で呼んでくれるので、生 JSON-RPC で叩くときだけ気をつければ OK

Gemini CLI でつなぐ

今回は Gemini CLI で検証しました。設定ファイル1個作るだけで動くので、サクッと検証を進めるのに向いていました。Claude Code でも同じことができるので、好きな方を選んで OK です（Claude Code 版の設定例は後述）。

~ はホームディレクトリのことです。Mac だと /Users/あなたのユーザー名/.gemini/... という場所になります。ドット始まりの隠しフォルダなので、まずは作るところから。

# 1) フォルダを作成
mkdir -p ~/.gemini/extensions/cloud-sql/

# 2) 設定ファイルを書く（エディタで開いて以下を貼り付けて保存）
vi ~/.gemini/extensions/cloud-sql/gemini-extension.json

中身（gemini-extension.json）は以下です。

{
 "name": "cloud-sql",
 "version": "1.0.0",
 "mcpServers": {
 "Cloud SQL MCP Server": {
 "httpUrl": "https://sqladmin.googleapis.com/mcp",
 "authProviderType": "google_credentials",
 "oauth": {
 "scopes": ["https://www.googleapis.com/auth/cloud-platform"]
 },
 "timeout": 30000,
 "headers": {
 "x-goog-user-project": "{プロジェクトID}"
 }
 }
 }
}

これで gemini を起動して /mcp を打つと、Cloud SQL MCP サーバが一覧に表示されます。あとは自然言語でお願いするだけ。対応するツールが自動で呼ばれます。

「{プロジェクトID} プロジェクトの Cloud SQL インスタンス一覧を見せて」

→ list_instances ツールが呼ばれて結果が返る。

「next26-data-api-poc の articles テーブルの全件を SELECT して」

→ execute_sql_readonly で SELECT が走る。

Claude Code でつなぐ場合

Claude Code でも繋げます。今回 Gemini CLI と同じ Cloud SQL に対して、Claude Code 経由で articles テーブルが読めることを実機確認しました。

設定は claude mcp add-json コマンド で ~/.claude.json に MCP 設定を登録します。

このコマンドの引数 JSON 内に headersHelper フィールドを入れると、Claude Code が MCP サーバに接続するたびに、そこに書かれたコマンドを自動実行してくれます。実行結果（JSON 形式の追加ヘッダ）が Authorization ヘッダにマージされて MCP サーバに送信されます。

今回は gcloud auth print-access-token を headersHelper に仕込みました。これで Claude Code が接続するたびにその瞬間のフレッシュなトークンが取れて、Authorization ヘッダに自動でセットされます。

接続フロー

ポイントは「設定登録は最初の1回だけ、接続時の処理は毎回自動」という点。一度 claude mcp add-json を叩いて .claude.json に書き込んでしまえば、それ以降は Claude Code が接続するたびに headersHelper が自動で実行されてトークンを取り直してくれます。

claude mcp add-json cloud-sql '{
  "type": "http",
  "url": "https://sqladmin.googleapis.com/mcp",
  "headers": {
    "x-goog-user-project": "{プロジェクトID}"
  },
  "headersHelper": "echo \"{\\\"Authorization\\\":\\\"Bearer $(gcloud auth print-access-token)\\\"}\""
}'

登録後の確認をします。

$ claude mcp get cloud-sql
cloud-sql:
 Scope: Local config (private to you in this project)
 Status: ✔ Connected   ← ここが Connected なら成功
 Type: http
 URL: https://sqladmin.googleapis.com/mcp

Status: ✔ Connected になれば、Claude Code 起動時に Cloud SQL MCP のツール（list_instances / execute_sql_readonly 等）が読み込まれ、自然言語から使えるようになります。Gemini CLI 版と同じく articles テーブルの中身が取得できました。

`headersHelper` の挙動

公式ドキュメントによると、headersHelper は「接続のたびに実行され、stdout に出力した JSON を接続ヘッダにマージする」仕組みです。

The helper runs fresh on each connection, at session start and on reconnect. There is no caching, so your script is responsible for any token reuse.
（公式ドキュメントより引用）

つまり **.claude.json に保存されるのは「トークンそのもの」ではなく「トークンを取るためのコマンド文字列」**です。Claude Code が Cloud SQL MCP に繋ぎに行く瞬間、headersHelper の中身（gcloud auth print-access-token）が実行されて、その時点で有効な新鮮なトークンが取れます。

アクセストークンは1時間で失効しますが、次に繋ぐときにまた新しく取り直されるので、設定ファイルを書いたら基本そのまま放置で OK。長期運用しても問題ありません。

補足：はじめは claude mcp add --header "Authorization: Bearer $(gcloud auth print-access-token)" のように静的に Bearer Token を渡す方法も試しましたが、こちらは登録時に取得したトークンが .claude.json に焼き込まれるため、1時間後に失効します。長期運用するなら headersHelper 一択です。

Remote MCP の特徴まとめ

触ってみての所感としては、Remote MCP の本命価値は「AI に DB パスワードを渡さなくていい」ことに尽きます。

冒頭で触れたとおり、AI に DB を触らせる仕組み自体は OSS の MCP サーバ（postgres MCP など）で前から実現できていました。

ただし、その方式では .mcp.json の接続文字列にパスワードを直接書く必要があります（postgresql://ユーザー:パスワード@... の形）。ローカル開発の docker-compose ならともかく、本番 DB のパスワードをそこに書くのは Git 流出・退職者対応・監査ログの観点で避けたい構成です。

Remote MCP に切り替えると、AI に渡すのは URL だけになり、認証は IAM が裏で担当します。

良かった点

MCP サーバを自分でホスト不要。URL を指すだけでインフラ管理がゼロ
「バックアップ取って」「ユーザー追加して」みたいなマネジメント系の操作も自然言語で頼める
対応エディタが多い（Claude Code / Gemini CLI など）
IAM ロールベースの権限制御（付与した権限以上の操作はできない）
AI に DB パスワードを渡さなくていい（本命）

従来との対比

観点	従来のやり方（OSS MCP サーバを自前ホスト）	Cloud SQL Remote MCP
AI に渡す認証情報	パスワード必須	不要（URLのみ）
認証情報の管理場所	`.mcp.json` / env / Secret Manager	不要（IAM のみ）
権限の管理単位	DB ユーザー	Google Cloud IAM ロール
退職者対応	DB パスワード変更（影響範囲広）	IAM ロール剥奪のみ
監査ログ	DB 側で別途取得	Cloud Audit Logs に自動記録

制約

本番データに対して使うときは権限を厳格に（execute_sql_readonly のみ付与など）
オーバーキルな使い方（単純な日次バッチなど）には向かない
AI クライアントによって設定方法やセットアップ難易度が異なる（本記事では Gemini CLI と Claude Code の設定例を掲載）

「本番 DB を AI に安全に触らせたい」という要件に対して、Remote MCP が現実的な解になっています。

Data API と Remote MCP サーバを比較する

まず一番大事な「誰のための窓口か」を整理します。

	Data API	Remote MCP サーバ
誰が使う？	プログラム / スクリプト	AI エージェント越しの人間
何をする窓口？	プログラムが HTTP で SQL を叩くための窓口	Claude や Gemini が自然言語で DB 操作するための窓口
典型的な使い方	Cloud Run Functions / CI/CD / シェルスクリプトから `curl` で叩く	開発中に Claude Code に「DB のこのテーブル見て」と頼む、運用調査で Gemini CLI に「先週のエラー件数集計して」と頼む
提供ツール数	1個（`executeSql` = SQL 実行のみ）	15個（SQL実行 + ユーザー管理 + バックアップ + インスタンス管理…）

Data API は「コードが叩く窓口」：道具1個（精密ドライバー）
Remote MCP は「AI が叩く窓口」：道具15個（工具箱）

両方とも結果的に同じ Cloud SQL に SQL を投げられますが、入り口と道具の数が違うわけです。

細かい比較

観点	Data API	Remote MCP サーバ
触り方	HTTP リクエスト	AI エージェントから自然言語
主な用途	軽い管理 SQL の単発実行（ユーザー追加、設定更新、件数確認等）。CI/CD の軽量タスク、Cloud Run Functions からの軽い読み書き	運用調査、開発支援、AI 統合
設定	API 有効化のみ	エディタ設定ファイル + IAM
認証	Bearer Token + IAM	ADC + IAM
AI / クライアントに渡す認証情報	なし（OAuth トークンを SDK が自動取得）	なし（同上）
クライアント	curl / requests / gcloud	Gemini CLI / Claude Code など
制限	レスポンス 10MB / 30 秒	エージェント側の文字数等
学習コスト	低（普通の REST）	中（MCP 概念、エディタ設定）

使い分けの目安

「プログラムから軽い管理 SQL を叩きたい」→ Data API
「人間が AI 越しに DB 触りたい」→ Remote MCP

※ Data API はあくまで「軽い管理タスク用のバイク便」。Alembic のような大規模マイグレーションや、本番アプリの常時クエリは引き続き従来構成（ORM + Auth Proxy / Cloud Run Jobs + Auth Proxy など）が向いています。

ちなみに、本記事の検証では Data API（curl）で作ったテーブルを Remote MCP の execute_sql_readonly で読んで、ちゃんと同じデータが見える ことも確認しています。同じ Cloud SQL を別の窓口から触っているので当然の結果ですが、「Data API と Remote MCP はバラバラのものじゃなく、同じ DB に対する2つの入り口」というイメージを掴むのに役立ちます。

既存ルートとの使い分け

「ローカルから DB 見るなら gcloud sql connect や Auth Proxy で十分じゃない？」と思った方もいるかもしれません。その通りで、ローカル開発者目線だけだと新ルートの価値はそこまで強くないです。

新ルートの真価が出るのは、ローカル PC から離れた4つの文脈です。

目的	既存ルートで十分？	新ルートが嬉しい？
開発者がローカルから DB 見たい	○ Auth Proxy で十分	△ あえて使う理由は薄い
Cloud Run Functions から DB 叩きたい	× VPC コネクタ（サーバーレスから VPC に橋渡しする装置）が必要で面倒	○ HTTP API でラク
AI に DB 触らせたい	△ できるけど自前 MCP サーバを立てて運用が必要	○ URL 教えるだけ
CI/CD で SQL 流したい	△ Auth Proxy 起動 → psql インストール → Secrets 取り出しの段取りあり	○ curl 1 発

つまり「ローカル開発者だけ見ると既存で十分。でもサーバーレス / AI / CI/CD の文脈で見ると圧倒的に楽になる」というのが新ルートの位置づけです。

補足：gcloud sql connect について

gcloud CLI から Cloud SQL に対話接続する便利コマンドですが、業務環境では使えない罠があります。動きは「自分の今のグローバル IP を認可ネットワークに 5 分追加 → ローカルの psql で Public IP に直接接続 → パスワード入力」で、Public IP がない Private IP 運用の DB には繋がらない / postgres パスワードが要る / 会社 VPN 配下だと出口 IP が違って失敗 / ローカルに psql 必須といった問題があります。業務環境は基本 Private IP 運用なので、結局 Auth Proxy 経由が正解になります。Data API / Remote MCP は HTTPS + IAM 認証なので Public / Private IP に依存しません。

検証で立てた Cloud SQL インスタンスは課金リソースなので、終わったら削除。

gcloud sql instances delete next26-data-api-poc \
 --project={プロジェクトID}

やってみて思ったこと

「Cloud SQL に触る = ポートを開けて TCP」という前提が、Next '26 で崩れてきた感覚があります
Data API は地味だけど使い勝手がいい。今まで「proxy 立ててちょっと SQL 流す」のためだけに苦労していた軽い管理タスク（ユーザー追加・件数確認・設定値更新など）が curl 1 発で済む。Cloud Run Functions との相性も良い（※ 大規模マイグレーションのような重い処理は引き続き従来構成が向いている）
Remote MCP サーバは「運用調査の体験」が変わる。インシデント対応で「先週のエラーログから、影響を受けたユーザー数を出して」みたいな探索が、自然言語で完結する
どちらも 正式リリース（GA） で個人プロジェクトでも動かせるので、まず触ってみるのが正解
ハマりどころも色々ありましたが、いずれもエラーメッセージを読めば突破できるレベル（詳細は本文中の「ハマった箇所①〜③」を参照）

明日のブログリレーもお楽しみに！

参考

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

Cloud SQL に触る道が増えた — Next '26 新発表の Data API（HTTP）と Remote MCP サーバ（AI経由）を両方試してみた

ざっくり言うと

この記事の対象者

Cloud SQL へのアクセス方法を整理しておく

従来の主なアクセスルート

Next '26 で増えた「2 つのマネージド ルート」

新ルートに切り替えると、実際の手順がどう変わるか

Cloud SQL Data API：「プログラムから DB に SQL を投げる」場面

Cloud SQL Remote MCP：「AI から DB を触る」場面

両方に共通する「変化点」

検証環境

検証セットアップ手順

1. Cloud SQL Admin API を有効化

2. Cloud SQL PostgreSQL インスタンスを作成

ハマった箇所①：--data-api-access フラグが認識されない

3. データベース作成

4. IAM ユーザーを Cloud SQL に追加

5. IAM ユーザーに Cloud SQL Instance User ロールを付与

6. public スキーマ権限を付与

事前準備

スクリプトを作成して実行

Cloud SQL Data API を試す

Data API とは何か

curl で叩いてみる

ハマった箇所②：Data API でパスワード認証が使えない

CREATE → INSERT → SELECT → 集計を curl だけでやってみる

Python から叩いてみる

Data API の特徴まとめ

良かった点

制約

向いている / 向いていない用途

Cloud SQL Remote MCP サーバを試す

Remote MCP サーバとは

Google マネージドで何が省けるか

MCP サーバを動かす 3 つの場面

パターン別：何が大変だったか

Remote MCP に切り替えるとどうなるか

サーバが動いているか生で叩いて確認

execute_sql_readonly を生で叩く

ハマった箇所③：MCP の execute_sql_readonly でパラメータ名を間違える

Gemini CLI でつなぐ

Claude Code でつなぐ場合

接続フロー

headersHelper の挙動

Remote MCP の特徴まとめ

良かった点

従来との対比

制約

Data API と Remote MCP サーバを比較する

細かい比較

使い分けの目安

既存ルートとの使い分け

やってみて思ったこと

参考

Next '26 で増えた「2 つのマネージドルート」

ハマった箇所①：`--data-api-access` フラグが認識されない

6. `public` スキーマ権限を付与

CREATE → INSERT → SELECT → 集計を `curl` だけでやってみる

`execute_sql_readonly` を生で叩く

ハマった箇所③：MCP の `execute_sql_readonly` でパラメータ名を間違える

`headersHelper` の挙動