Google MapsとBigQuery「エージェント対応」：MCP革命

「エージェントの未来」に対する最大の障壁は、モデルの知性ではありません。それはつながりの愚かさでした。

過去 2 年間、実際に何か (データベースのクエリや地図の確認など) を「実行」できる AI エージェントを構築するには、混乱した「接着コード」が必要でした。開発者は、関数定義を手動で作成し、認証を処理し、JSON スキーマを解析し、API が変更されるたびに「ツール」を常に更新する必要がありました。それは壊れやすく、オーダーメイドであり、拡張性がありませんでした。

さらに悪いことに、プラットフォームごとに異なる言語が使用されていました。 OpenAIには「アクション」があり、Anthropicには「ツール」があり、LangChainには「ツールキット」がありました。 GPT-4 用の統合を構築した場合、書き直さないと Claude では機能しませんでした。

そんな時代は終わったばかりです。

Anthropic (標準をオープンソース化) の足跡をたどり、標準化に向けた業界の動きとほぼ一致して、Google は マネージド モデル コンテキスト プロトコル (MCP) サーバーを展開し、Google Maps と BigQuery に対して完全に無料で開始します。

これは単なる機能アップデートではありません。それは根本的なアーキテクチャの変更です。 Google は自社のサービスを「エージェント対応設計」にし、事実上人工知能用の USB ポートを作成しています。

フック: なぜこれが今重要なのか

過去 10 年間、Web は次の 2 つの目的で最適化されてきました。

1. 人間 (ブラウザによって提供される HTML/CSS)
2. 特定のアプリケーション (厳格なフロントエンドによって使用される REST/GraphQL API)

これは、汎用 AI エージェント向けに設計されたものではありません。 ChatGPT に「近くのレストランを見つけて」と頼んだとき、ChatGPT は人間のように地図を「見る」ことはしません。トレーニング データに基づいて推測するか、ツールが装備されている場合は、人間のエンジニアが手動で設定した特定の API エンドポイントにアクセスします。

この「配線」がネックでした。 LLM を Google マップに接続するには、開発者は次のことを行う必要がありました。

• Google Cloud プロジェクトをプロビジョニングします。
• プレイス API を有効にします。
• API キーを生成します。
• API を呼び出すための Python 関数を作成します。
• LLM にその関数を説明するための JSON スキーマを作成します。
• LLM がパラメータを幻覚したときのエラー状態を処理します。

Google が マネージド MCP サーバー を提供するという動きは、開発者がその配線を構築する必要がなくなることを意味します。開発者は Maps MCP サーバーを「オン」にするだけで、エージェントは地理コード化、場所の検索、ルートの計算方法を即座に理解できます。コードもスキーマ定義もメンテナンスも必要ありません。

これは、ランプを壁に配線するのと、単にソケットに差し込むのとの違いです。 Google はソケットをインストールしたところです。

技術的な詳細: 「マネージド MCP サーバー」とは何ですか?

この規模の大きさを理解するには、MCP が実際には何なのか、そして Google の実装が開発の物理学をどのように変えるのかを見なければなりません。

1. プロトコル (「USB 標準」)

モデル コンテキスト プロトコル (MCP) は、AI モデルがデータやツールと対話する方法を標準化するオープン スタンダードです。 MCP が導入される前は、「統合の問題」は N x M でした。N 個のモデル (Claude、Gemini、GPT) と M 個のツール (Google Drive、Slack、Postgres) がある場合、N*M 個のカスタム統合が必要でした。

MCP はこれを N + M に還元します。

• モデルは「クライアント」（USB ポート）になります。
• ツールは「サーバー」(USB デバイス)になります。

このプロトコルは JSON-RPC 2.0 に基づいて構築されています。これにより、クライアント (AI エージェント) は、使用可能なツール、リソース、およびプロンプトのリストをサーバーに要求できます。サーバーは標準化された定義で応答します。エージェントがツールを使用したい場合、サーバーに JSON-RPC リクエストを送信し、サーバーがロジックを実行して結果を返します。

2. 「管理された」部分 (画期的な点)

今週まで、MCP サーバーの実行は「ローカル」の作業でした。エージェントがデータベースと通信できるようにするには、ローカルの Node.js または Python プロセス (npx -y @modelcontextprotocol/server-postgres など) をマシン上で実行する必要がありました。

このアーキテクチャは、ラップトップ上の開発者 (Claude Desktop を使用) では機能しますが、運用環境では失敗します。 Web エージェントがカレンダーを確認できるようにするためだけに、ユーザーに「ローカル ターミナル コマンドの実行」を依頼することはできません。

Google の マネージド MCP は、開発者の負担を軽減します。

• 管理する Docker コンテナはありません。
• 書き込み時の認証ハンドシェイクはありません (Google Cloud IAM を自動的に使用します)。
• スキーマ メンテナンスなし: Google が BigQuery API を更新すると、MCP サーバーは自動的に更新されます。
• プロトコル トランスポート: ローカル MCP に使用される stdio (標準入出力) の代わりに、Google の管理対象サーバーは安全なチャネル経由で Server-Sent Events (SSE) または HTTP POST を使用する可能性があり、リモート エージェントが安全に接続できるようにします。

3. BigQuery とマップの実装

BigQuery の実装は特に革新的です。

• スキーマ検出: クライアントは MCP サーバーに「どのテーブルが利用可能ですか?」と尋ねます。サーバーは、テーブル名だけでなく、列の型と説明も含めたスキーマを返します。
• クエリ生成: エージェントは列のタイプと関係をネイティブに理解します。 transaction_date は STRING ではなく TIMESTAMP であることがわかっています。
• 実行: エージェントは SQL を送信し、サーバーはモデルが期待する方法でフォーマットされた データ を返します。

これにより、BigQuery は「データベース クエリ ツール」から、人間がライブラリを参照するのと同じくらい簡単にエージェントが参照できる「ナレッジ ベース」に変わります。 MCP サーバーが グラウンド トゥルース スキーマをリアルタイムで提供するため、エージェントが存在しない列をでっち上げるリスク (幻覚) がなくなります。

コンテキストの歴史: 「Glue コード」の悪夢

これを理解するには、「ReAct」時代 (推論 + 演技) と呼ばれることが多い、2023 年から 2024 年の「最先端」に注目する必要があります。

独創的な「ReAct」論文の中で、研究者らは、LLM が「思考」を生成し、次に「行動」を生成し、次に「観察」を作成することによってツールを使用できることを示しました。しかし、「アクション」の部分は面倒でした。

BigQuery で在庫を確認し、Google マップで倉庫をマッピングできるエージェントを構築したい場合は、次のことを行う必要がありました。

1. ドキュメントを読む: BigQuery REST API ドキュメントを読みます。
2. コードの作成: Python 関数 check_inventory(sku) を作成します。
3. スキーマの定義: その関数を LLM に記述する JSON スキーマを手動で定義します (例: 「この関数は文字列 SKU を受け取ります…」)。
4. 認証の処理: API 認証 (OAuth2 フロー) を手動で処理します。
5. 繰り返し: Google マップに対して手順 1 ～ 4 を繰り返します。
6. 出力の解析: Maps からの奇妙な JSON 出力を、LLM が読み取れるものに解析します。

これは脆いでした。

• API が変更されると、エージェントが壊れます。
• LLM が間違ったパラメータを幻覚した場合 (たとえば、int の代わりに文字列を送信した場合)、コードはクラッシュしました。
• OpenAI から Gemini に切り替えたい場合は、ツール定義を書き直す必要がありました。

MCP は「N+1」問題を解決します。 すべてのエージェントがすべてのツールとの会話方法を学習する必要があるのではなく、すべてのエージェントが MCP を話し、すべてのツールが MCP を話します。

「Agentic Web」とグラウンディング

このアップデートの最も重要な側面の 1 つは グラウンディングです。

AI における「グラウンディング」とは、幻覚を防ぐためにモデルの応答を検証可能な現実世界のデータに固定することを指します。

• 地図なし MCP: 「SFO まで車でどのくらいかかりますか?」と尋ねます。このモデルは、2023 年の平均交通量データに基づいて推測します。
• マップ MCP を使用: モデルは maps.get_route を呼び出し、リアルタイムの交通データ、通行止め、正確な到着予定時刻を受け取ります。

Googleはこれをマップ向けの「Grounding Lite」と呼んでいる。これにより、エージェントは「空間認識」できるようになります。これは、物流、配送、旅行代理店にとって非常に重要です。

BigQuery についても同様に、「エンタープライズ グラウンディング」が可能になります。 「先月の売上はいくらでしたか?」と答えるエージェント推測ではありません。実際の台帳に対して SELECT sum(sales) ... クエリを実行しています。 MCP サーバーは、クエリが実行前に構文的に正しいことを確認し、安全策として機能します。

将来を見据えた分析: 「エンタープライズ OS」

Google による MCP の採用は、業界が標準に収束しつつあることを示す大きな兆候です。これはエージェントにとっての「HTTP モーメント」です。

1.「チャット」インターフェースの終焉?

現在、ほとんどのユーザーはチャット (ChatGPT、Gemini) 経由で AI を使用しています。管理された MCP サーバーにより、AI をシステムの「内部」に組み込むことができます。物流ダッシュボードには地図が表示されるだけではありません。 MCP サーバー経由でそのマップを監視するサイレント エージェントがあり、BigQuery インベントリ データに影響を与えるトラフィックの異常を監視し、必要な場合にのみ警告します。

2. 次に続くのは誰ですか?

Google (BigQuery/マップ) と Anthropic (Claude) が MCP を支援しているため、AWS と Microsoft にプレッシャーがかかっています。

• AWS は「マネージド MCP for DynamoDB」を開始しますか?
• Microsoft は「マネージド MCP for Excel/Graph」を提供しますか?

そうしないと、Google Cloud 上でエージェントを構築する方が、Azure や AWS よりも大幅に高速になります。 Google サービスに関する「統合税」がほぼゼロになりました。

3. セキュリティへの影響

もちろん、危険なのはエージェントにデータベースへの「ゴッドモード」アクセスを与えることです。ここで、「ローカル」と「マネージド」の区別が重要になります。

特定の「ローカル」MCP セットアップでは、多くの場合、エージェントはユーザーの完全な権限で実行されます。ただし、Google の実装は Cloud IAM (Identity and Access Management) に依存しています。 MCP サーバーは、サービス アカウントで表示が許可されているもののみを表示します。

• 特定のテーブルに対する BigQuery Data Viewer 権限のみを持つサービス アカウントを作成できます。
• MCP サーバーは その 制限を継承します。
• エージェントが DROP TABLE を試みても、MCP サーバー (IAM によって支援される) はそれを拒否します。

これにより、AI エージェントの荒野に「エンタープライズ グレード」のセキュリティがもたらされ、まさに CIO が待ち望んでいたものになります。

結論

業界は、AI が世界について単に「話す」時代から、AI が世界に「触れる」ことができる時代へ移行しつつあります。

Google が展開するマップと BigQuery 用のマネージド MCP サーバーは、これを可能にするインフラストラクチャです。これにより、厳格で人間中心のサービスが、流動的でエージェント対応のツールに変換されます。

開発者にとって、メッセージは明確です。グルー コードの作成をやめてください。 openapi.yaml ファイルの保守を停止します。新しいスタンダードがここにあります。ソケットが設置されています。いよいよエージェントを導入します。