Google公式MCPリポジトリは“ツール接続の標準実装”をどう変えるか

Google が公開している google/mcp は、「Google製のMCPがたくさんある」という話で終わらせると少しもったいないリポジトリです。README をそのまま読むと、このリポジトリがやっているのは大きく3つです。ひとつは Google が管理する remote MCP server の一覧化。もうひとつは Google Cloud で MCP server を動かすための導線整備。最後に、ADK を使って BigQuery と Google Maps を組み合わせる実例の提示です。つまり本質は、ツール接続を“個別の裏技”ではなく“標準化された運用”に寄せることにあります。

MCP はエージェントに外部ツールを渡すための共通プロトコルですが、現場では「どのサーバーが本番向きか」「認証はどう張るか」「クラウドでどう公開するか」「サンプルはあるか」で止まりがちです。google/mcp はその詰まりどころをかなり正面から埋めています。しかも README では、Google 管理の remote MCP servers と、ローカル実行または Google Cloud 配備できる open-source MCP servers を分けて提示している。この整理がかなり重要です。

重要なのは“公式MCPが多い”ことではなく、接続様式が整理されたこと

README には remote MCP servers として、BigQuery、Bigtable、Firestore、Spanner、Cloud SQL、Compute Engine、Cloud Resource Manager、Google Security Operations、GKE、Google Maps (Grounding Lite) などが並びます。一方で open-source MCP servers としては、Google Workspace、Firebase、Cloud Run、Google Analytics、Google Cloud Storage、gcloud CLI、Google Cloud Observability、Chrome DevTools などが挙がっています。

ここで見るべきは“網羅性”より“整理方法”です。どれが Google 管理の endpoint として使えるのか、どれが OSS として自分で動かす前提なのかが明示されているので、エージェント実装側は接続責任の置き場所を決めやすい。要するに、MCP の議論が「つながるらしい」から「この方式で運用する」に進みます。

認証・権限・デプロイを例付きで示しているのが効く

google/mcp の価値はリスト化だけではありません。README からは Cloud Run へのデプロイ手順、secure MCP server の codelab、Apigee での MCP support、MCP Toolbox for Databases の配備方法など、実運用に寄せた導線がかなり張られています。MCP を本番で使うときに一番面倒なのは、プロトコルそのものより認証と公開面です。そこに Google Cloud 側のホスティング導線が用意されているのは大きいです。

実例として examples/launchmybakery を見ると、ADK のサンプルエージェントが BigQuery 用 remote MCP と Google Maps 用 remote MCP を組み合わせています。tools.py では BigQuery 側に OAuth bearer token と x-goog-user-project を使い、Maps 側では API key をヘッダで渡していました。つまり「MCP でつなぐ」と言っても、裏側の認証パターンはサービスごとに違う。その違いを“サンプルとして読める形”で出しているのが実務的です。

公式リポジトリがあると、エージェント統合は“コピペ接続”から抜けやすい

Launch My Bakery の例は、単なるデモとしても分かりやすいですが、本質はもっと地味で重要です。ADK のエージェントが、BigQuery で商圏や価格・売上データを引き、Google Maps で競合店や移動時間を見て、ひとつの意思決定フローにまとめている。これは「MCP があると便利」ではなく、「複数ツールを agent runtime の中で標準的に束ねやすい」という証明です。

従来のツール統合は、SDK ごとの個別実装、API キーの貼り分け、エラーハンドリングの独自実装が増えやすく、エージェントを増やすほど接続面が散らかります。公式リポジトリが一覧・配備導線・実例を持つと、少なくとも出発点を標準化しやすい。企業にとって重要なのはここで、MCP の数よりも、監査しやすい接続面を作れるかのほうです。

どのMCPを見るべきか

今の README だけでも、見るべき代表例はかなりはっきりしています。

• BigQuery: 企業データ分析をエージェントに渡す中心線。構造化データ活用の起点になりやすい。
• Google Maps (Grounding Lite): 現実世界の位置・店舗・移動文脈を扱う入口。データ分析だけでは終わらないのが強い。
• Google Workspace: Docs、Sheets、Slides、Calendar、Gmail を含む Gemini CLI extension。ナレッジ作成や業務連携の面で広い。
• Google Analytics: マーケや事業分析で使いやすい。集客やコンバージョン文脈のエージェントに直結しやすい。
• Cloud Run / GKE / Apigee 系導線: “MCPをどう安全にホストするか”という運用論点を担う。

つまり google/mcp が示しているのは、Google の各APIをただMCP化したという話ではありません。エージェント時代のツール接続を、一覧・責任分界・認証・配備・実例まで含めて整理し始めたことに意味があります。MCP の次の争点は「どれだけ多くのツールがあるか」ではなく、「どれだけ標準的に、運用可能な形で接続できるか」です。google/mcp はその問いに対して、かなり実務寄りの答えを出し始めているリポジトリだと言えます。

一次ソースを直接確認したい場合は、google/mcp の README と、Launch My Bakery サンプル を見るのがおすすめです。特に後者は、BigQuery と Google Maps の remote MCP を ADK のツールセットとして扱う実装例まで読めるので、MCP の“紹介”より一段深い理解につながります。