TANAKA Hiroki
Google Ads API、Merchant API、Google Ads Scripts。Google のプロダクトを扱っていると、公式ドキュメントを参照する機会はしょっちゅうあります。ただ、製品ごと・バージョンごとにドキュメントが分散していて、検索でたどり着いたページが実は旧バージョンだったとか、英語版と日本語版で内容が違うとか、そういうことがよくあります。AI に聞いても学習データの鮮度に依存するので、sunset された API のメソッドを自信満々に教えてくれたりもします。
Google が公式で提供している MCP サーバー「Developer Knowledge MCP」は、Google の開発者向けドキュメントを AI が直接検索・取得できる仕組みです。2026年2月のパブリックプレビュー公開から使い始めて、今はほぼ毎日の業務で使っています。
この記事では、数ヶ月使ってみてわかったことを実例つきでまとめます。
Developer Knowledge MCP とは
詳しい仕組みの説明は省きます。ざっくり言えば、Google Ads、Merchant API、Firebase、Google Cloud、Android、Maps などの開発者向けドキュメントを AI が検索・全文取得できるようにする、Google 公式の MCP サーバーです。対象は developers.google.com だけでなく、firebase.google.com、cloud.google.com、developer.android.com など複数のドメインにまたがっています。
提供されるツールは3つ。search_documents（ドキュメントの横断検索）、get_documents（特定ドキュメントの全文取得）、そして回答生成型の answer_query（Google 側の Gemini がコーパスをもとに引用元つきの回答を直接返す）。answer_query は後から追加されたものです。
僕が普段使っているのは前の2つで、Claude に MCP を接続した環境で search_documents でざっくり当たりをつけて、get_documents で詳細を確認する、というのが基本的な使い方になります。取得されるドキュメントはマークダウン形式なので、AI がそのまま構造を理解して処理しやすく、HTML をスクレイピングして読ませるよりも精度の高い回答が返ってきます。
検索クエリも結果も英語のみですが、実際に使っていてそれが不便だと感じることはありません。こちらは日本語で会話するだけで、生成 AI が文脈を踏まえて英語のクエリに変換して検索し、英語で返ってきた内容を日本語に訳して返してくれるからです。
自分で英語のクエリを考える必要も、英語の原文を読む必要もありません。むしろ精度の面ではプラスに働きます。Google の開発者ドキュメントの日本語版は機械翻訳されたものが多く、技術用語の訳が不自然だったり原文の更新に追従していなかったりするので、英語の原文を AI が文脈込みで訳す方が、機械翻訳された日本語ページを読むよりも正確なことが多いです。
対応する AI ツールは Claude（claude.ai での接続、Claude Code）、Gemini CLI、Cursor など。セットアップには Google Cloud プロジェクトの作成と API 有効化が必要です。手順は公式ドキュメントや先人の皆さまの記事に記載されているので、ここでは割愛します。
使ってみてわかったこと
導入ガイドや機能紹介は公式や先人の皆さまの記事にお任せするとして、ここでは実際にどんな場面で使い、何が返ってきて、どう役立ったかを書きます。
僕の業務が広告運用寄りなので以下の実例は Google Ads や Merchant API 中心になっていますが、対象はそれだけではありません。BigQuery や GA4、GTM のドキュメントも対象なので、Google のプロダクトを開発や分析で使っている方なら活用場面は多いはずです。
僕自身、個人開発で BigQuery のデータ基盤を構築した際にも、BigQuery API のドキュメントを MCP 経由で確認しながら進めました。
実例1：「できない」を確認する
ローカル在庫の実装に関わる中で、「ローカル在庫のデータを使って店舗ごとの需要分析や機会損失の可視化ができないか」という要望が挙がりました。
気持ちはよくわかります。実現できたら魅力的です。ただ、「できたらいいな」と「API で取れる」は別の話です。
そんなことが可能なのかどうか、事前に裏を取りたかったので、Merchant API の product_performance_view、Business Profile Performance API、Google Ads API のレポート仕様を MCP で横断的に調べてみました。
結果はこうでした。Google ビジネスプロフィールには商品レベルのレポートがない。Merchant API ではローカルクリックを個別店舗に分解できない。来店コンバージョンとの紐付けにはロイヤリティプログラムデータが必要で、一般的な小売事業者には現実的ではない。
想定していたインサイトの大半が、API 仕様上取得不可でした。
従来なら3つの API のリファレンスを個別に開いて英語で読み込む半日仕事です。それが会話の中で片がつきました。
MCP の便利さは「仕様を見つけてくれる」ことだけではありません。「その仕様は存在しない」を高速に確認できることの方が、実務では価値が大きいことがあります。できないことを早く知れれば、実現可能な範囲に方針を切り替えられるので。
実例2：機能が新しすぎてレポートツールが対応できていない仕様を調べる
動的検索広告（DSA）の機能が AI Max for Search に統合されるという話になったので、AI Max for Search キャンペーンで、DSA 同等なレベルでの検索語句やランディングページのレポートを API で取得できるか、知りたい場面がありました。
と言うのも、機能が新しすぎて、従来のサードパーティによるレポーティングツールではレポート取得に対応しておらず、Google 広告スクリプト（コード内から Ads API が呼び出せる）など活用してこれを補完できるレポートを取得できないかを検討する必要があったのです。
MCP で API ドキュメントを検索してみると、ai_max_search_term_ad_combination_view、search_term_view（search_term_match_source によるフィルタ対応）、expanded_landing_page_view の3つのレポーティングビューが見つかりました。いずれもヘルプの UI には出てこないビューです。GAQL のクエリサンプルまで返ってきたので、すぐに試せる状態になりました。
広告運用の現場では、新機能が出てもサードパーティのツールが対応するまで待たされることがよくあります。
ツールのアップデートは、API 提供から数ヶ月遅れることも珍しくありません。でも、API リファレンスにはその仕様がすでに載っている。MCP で一次情報に直接アクセスできれば、ツールの対応を待たずに、自前のスクリプトで先にレポートを組める。
この「ツールが対応する前に、一次情報から動ける」という点が、前述の「できない確認」とは別の軸での価値です。
実例3：仕様を見つけて、その場でコードで確かめる
Google 広告の管理画面で「広告のリンク先」レポートを見ていたら、「不明」に分類されるクリックが全体の6割を超えていました。しかも、あるアカウントでは起きるのに別のアカウントでは起きない。何が違うのか気になって調べ始めました。ヘルプ記事を確認しましたが、「不明」の定義が曖昧でよくわかりません。
MCP で Google Ads API のリファレンスを調べると、segments.ad_destination_type に対応する AdDestinationTypeEnum の全 enum 値が出てきました。UNKNOWN や UNMODELED_FOR_CONVERSIONS など、ヘルプの UI には表示されない値が複数あります。ヘルプ記事では8種類しか見えないセグメントが、API 上では13種類定義されていました。
ここから「不明の正体は UNMODELED_FOR_CONVERSIONS では？」という仮説が立ちました。確かめるために十数行の GAQL を書いて Google 広告スクリプトで実行。
結果は、UNKNOWN が 62.9%、WEBSITE が 37.1%。UNMODELED_FOR_CONVERSIONS はゼロ。仮説は棄却されました。ただ、「UNKNOWN 以外の値は来ていない」という事実を確認できたことで、これは Google 内部の分類アルゴリズムの問題であって、こちら側の計測設定の問題ではないと判断がつきました。
とはいえ、なぜアカウントによって UNKNOWN の出方がこれほど変わるのかは、これだけではまだ腑に落ちません。こちら側の設定の問題ではないにせよ、不気味な分類であることに変わりはないので、この件は今 Google Ads Developers の Discord サーバー（公式の API チャネル）で質問を投げているところです。MCP で仕様を確認できたことで、「自分の設定ミスではない」と切り分けたうえで、的を絞った質問ができるようになりました。
MCP で仕様を見つけて、仮説を立てて、その場でスクリプトを書いて検証する。この流れが会話の中で完結したのは便利でした。ヘルプ記事とウェブ検索だけでは、そもそも enum 値の全量を把握するところまで到達できなかったと思います。
この例では自分で GAQL を書きましたが、MCP で取得した仕様をもとに AI にコード生成を頼むこともできます。
AI が学習データではなく、取得したばかりの API リファレンスを参照しながらコードを書くので、メソッド名やパラメータの誤りが起きにくい。Google 広告スクリプトや Google Apps Script のコードを書く場面では、仕様確認とコード生成が同じ会話の中で完結するのは実用的です。
限界と注意点
良い話ばかり書いても仕方ないので、限界も書いておきます。
まず、プレビュー版（試験運用）であること。挙動が不安定なこともありますし、検索が空振りすることもあります。同じクエリで返ってくる結果が変わることもあるので、本番業務のクリティカルパスに乗せるにはまだ早いです。
カバー範囲にも明確な線があります。対象は developers.google.com、firebase.google.com、cloud.google.com など Google の開発者向けドキュメントに限られます。ヘルプセンター（support.google.com）、GitHub、YouTube、公式ブログは検索対象外です。「Google 広告の審査ポリシーを確認したい」「Google Merchant Center の承認要件を調べたい」といったヘルプ記事ベースの情報は、この MCP では検索できません。
そして AI が要約する以上、返ってきた内容の鵜呑みは禁物です。MCP の返答にはドキュメント URL が含まれるので、重要な判断に使う場合は原文を開いて確認する。ただし「どのドキュメントを読めばいいか」の当たりをつける用途としては十分です。
ドキュメント探索のやり方が少し変わった
数ヶ月使ってみて、仕事のやり方が劇的に変わったわけではありません。ただ、「この仕様、どこに書いてあるんだっけ」と思ったときに、まず MCP に聞いてみる癖がつきました。当たりがつけばそこから原文を読めばいいし、空振りなら従来通りウェブ検索に切り替えればいい。
ドキュメント探索の入口が一つ増えただけですが、それが日常の業務に定着したのは、使い方がシンプルだからだと思います。特別な準備も、複雑なプロンプトも要らない。聞けば返ってくる。その手軽さが継続につながっています。
Google のプロダクトに関わっていてドキュメント探索に時間を取られている方は、試してみる価値はあると思います。