こんにちは！YOUTRUSTでデータエンジニアをしている小林（YOUTRUST）です。
YOUTRUSTでは、Claude Enterpriseの導入をきっかけにClaudeを活用したデータ分析が日常的に行われるようになりました。プロダクトマネージャー(PdM)やマーケティングのメンバーといった普段データに触れているメンバーだけでなく、WebやAppの開発をしているエンジニアメンバーもClaudeを活用してデータに触れる機会が増えています。
こうした流れを後押ししたのが、分析チームで開発・運用しているBigQuery MCPサーバーです。このMCPサーバーは、AIツールとBigQueryの橋渡し役として「データを見たい人が誰でも安全にデータにアクセスできる」環境を目指して改善を続けています。
この記事では、非エンジニアにとっての使いやすさと、それでも守るべき安全性をどう両立させているかを紹介します！
なぜ自前で開発しているのか
BigQuery用のMCPサーバーは、実はGoogle公式のものが公開されています。それでも自前で開発している理由は大きく2つあります。
1つ目は、ドメイン知識の埋め込みです。 公式サーバーは汎用ツールなので、BigQueryへの接続やクエリ実行は問題なくできます。しかし、「YOUTRUSTのDAUはどのテーブルから取るのか」「スカウトの定義は何か」といったビジネスコンテキストは当然持っていません。自前のサーバーでは、データカタログやクエリテンプレート、ドメイン知識といったYOUTRUST固有の情報をMCP Resourcesとして組み込んでいます。これにより、BigQueryにあるテーブルに詳しくなくても「先月のDAU教えて」と聞くだけで、正しいテーブルから正しいクエリが生成される体験を実現しています。
2つ目は、組織に合わせたガードレールです。 公式サーバーはフルアクセスを前提とした設計ですが、「誰でも使える」環境では安全策が欠かせません。クエリ実行前の自動見積もり、読み取り専用への限定、ジョブラベルによる追跡など、非エンジニアが安心して使える仕組みを組み込みました。
つまり、汎用ツールに「YOUTRUSTの知識」と「組織のルール」を載せたものがこのMCPサーバーです。以降のセクションで、それぞれの工夫を具体的に紹介します。
誰でも使える：始めやすく、使いやすく
もともと分析チームや一部のエンジニアのみが利用していたため、GitHubからインストールするローカルMCPサーバーとして実装されていました。利用するにはNode.jsのインストール、gcloud CLIの認証設定など複数の手順を踏む必要がありました。エンジニアにとっては手順があれば簡単にできる作業でしたが、非エンジニアにとってはハードルが高くインストールにはサポートが必要でした。
リモートMCPサーバーで1行セットアップ
この問題を解決するため、MCPサーバーをCloud Run上のHTTPサーバーとしてデプロイしました。それによって、リモートMCPサーバーのURLを指定すれば使える状態になりました。Google Cloudへの認証も初回接続時にブラウザからGoogleアカウントでログインするだけでできるようになりました！
ドメイン知識をMCPサーバーから提供
セットアップを簡単にしても、「どのテーブルを見ればいいかわからない」「YOUTRUSTのKPI定義がわからない」という壁は残ります。そこで、MCPのResources機能を活用し、データ分析に必要なドキュメント群をMCPサーバーが持っている状態にしました。
以下のようなドキュメントを提供しています。
- データカタログ: データセット・テーブル一覧、命名規則
- クエリテンプレート: DAU/MAU分析、KPI集計等のSQLテンプレート
- SQLスニペット集: よく使うSQLパターン
- ドメイン知識: ビジネス用語、セグメント定義など
- コーディング規約: SQLの書き方ルール
AIがこれらのドキュメントを自動的に参照するため、ユーザーは「先月のDAUの推移を教えて」と聞くだけで、適切なテーブルからクエリが生成されます。ドメイン知識を事前に把握していなくても分析を始められるのがポイントです。
安全に使える：コストと権限のガードレール
使いやすさだけを追求すると、意図しない巨大クエリによるコストの増加や、誤ったデータ操作といったリスクが出てきます。「誰でも使える」と「安全に使える」は両立させる必要があります。そのために、以下の4つのような工夫をしています。
クエリ実行の2段階チェック
BigQueryは従量課金のため、うっかり巨大なクエリを実行するとコスト増加に直結します。特に、AIが自律的にクエリを組み立てる場合、「とりあえずSELECT *」のようなクエリが生成されるリスクがあります。
これを防ぐために、クエリ実行を2つのステップに分けました。
- 見積もり（
estimate_query）— ドライランでスキャン量だけを算出する - 実行（
execute_query）— 実際にクエリを実行する
ドライランでスキャン量を見積もり、以下のようにスキャン量が1GB以上の場合はユーザーに確認して判断を仰ぐようにしています。
- 1GB以下: そのまま実行（ユーザーへの確認なし）
- 1GB超: スキャン量をユーザーに提示し、確認を得てから実行
ユーザーごとの権限でアクセス
認証にはGoogle OAuth 2.0を採用しており、各ユーザーのGoogleアカウントの権限でBigQueryにアクセスします。MCPサーバー側に強い権限を持たせるのではなく、ユーザー本人の権限がそのまま適用されるため、BigQuery側のIAM設定がそのまま効きます。
読み取り専用に限定
リモートサーバー化にあたり、データセットやテーブルの作成や削除をするツールは提供しないようにしました。もともと、BigQueryの利用ユーザーはIAMでデータセットやテーブルの作成・削除はできないようになっています。MCPサーバーでもツールを提供していないのでより安全にBigQueryをAIから使える状態になっています。
クエリの追跡
MCPサーバーから実行するすべてのBigQueryジョブにはラベルを付与しています。BigQueryコンソールやINFORMATION_SCHEMA.JOBSから「MCP経由のクエリ」だけをフィルタリングできるため、コスト分析や問題の切り分けができるようになっています。
リモートMCPサーバーを公開したことで…
分析チームに来ていたデータ抽出依頼が減りました。データを見たい人にとっては、自然言語でAIに聞いてすぐデータが出てくるので分析業務が捗っているように見えます。また、プロダクト開発をしているエンジニアもデータを見る機会が増え、施策や機能開発においてデータを見て会話することが盛んになっています。Slack上でデータを元に施策の会話をしているのを見て、「データを見て議論するのが自然になってきて、いいなぁ」と感じています。
おわりに
BigQuery MCPをリモートMCPサーバーにしたことで、以前の記事で掲げた「誰もが簡単にデータ分析できる環境」という目標に、大きく近づけた実感があります。Claude Enterpriseが導入されたこともあり、今まであまりデータ分析をできていなかったメンバーからも「BigQueryのデータを見れるようにするにはどうすればいい？」という相談が来るようになりました！
一方で、AIが抽出したデータの正確性をどう担保するのかが次の課題だと感じています。そのために、MCPに埋め込んでいるドメイン知識のアップデートやメタデータやセマンティックレイヤーの整備を進めていきたいです！
現在、データアナリストを募集中です。少しでも気になったらぜひカジュアル面談しましょう！
