Googleが公開した Developer Knowledge MCPサーバーを、Claude Code に接続して1週間運用してみた。Google Cloud / Firebase / Android といった公式ドキュメントの整備状況に対し、生成AIに書かせると古いAPIが混じる「古い記憶問題」が長年の悩みだった筆者にとって、体感で7割ほど解消した感触がある。本稿では接続手順、Firebase Authentication v12を題材にした検証、8タスクの定量ログ、そして気になる欠点までを整理する。
なぜAIコードアシスタントの公式ドキュ参照は遅れがちなのか
LLMの学習データには、公開時点までのGoogle公式ドキュメントしか含まれていない。Firebase Auth v11→v12のような節目はもちろん、Android Studio側の細かいAPI deprecationまでは追いかけきれない。
筆者自身、Claude Code に Firestore のクエリを書かせて「あれ、これ古いSDKの書き方では?」と気づくケースが、ここ2ヶ月だけで13回あった。WebFetch でURLを差し込む手もあるが、毎回URLを貼るのは正直だるい。Vim時代に「補完辞書を手動で読み込む」儀式があったが、構造としてはあれに近い手間だ。
接続は1行、search_documents と answer_query の2つの顔
公式が出した接続コマンドはシンプルだ。
claude mcp add google-dev-knowledge \
--transport http https://developerknowledge.googleapis.com/mcp \
--header "X-Goog-Api-Key: YOUR_API_KEY"APIキーは Google AI Studio で発行する。OAuth経由でも認証可能とされている。
サーバーが提供するツールは2つ。search_documents は意味検索でドキュメントの断片を返す。answer_query はLLM側が回答を合成して返す。前者は素材、後者は調理済みの料理、と例えると分かりやすい。Cursor側の設定も似た形で、~/.cursor/mcp.json に同じ宛先とAPIキーを書くだけ。筆者の環境では1分で導入が終わった。
Firebase Authentication v12のリリース直後で検証
検証はシンプルな構成にした。Firebase Authentication v12のリリース直後、よくある「Email Link認証を実装して」というプロンプトを Claude Code に投げる。比較対象は、同じプロンプトをMCPなしで投げた場合だ。
MCPなしの結果は厳しかった。sendSignInLinkToEmail を旧形式で書き、actionCodeSettings の必須フィールドを2つ落とした。筆者が手動で直すまで気づかなかった内容だ。
一方、MCPありの結果は、新形式のオプション3つを正しく指定し、v12のmigration noteへのリンクも添えてきた。体感の差は、思っていたより大きい。1回の質問で完結する確率が、明らかに上がった感触だ。
8タスクの定量ログ：再質問は4回から1回へ
定量で評価するために、Google系SDKを触る8タスクを連続で実行してログを取った。内訳は Firebase 3件、Google Cloud Functions 2件、Maps Platform 2件、Android Compose 1件。
| 比較項目 | MCPなし | MCPあり |
|---|---|---|
| 再質問発生数 | 4回 | 1回 |
| 1タスク平均所要時間 | 11分20秒 | 6分40秒 |
| 出典URL付き回答 | 25% | 87.5% |
| ハルシネーション疑い | 3件 | 0件 |
特に出典URLが返ってくる確率が、3倍以上に伸びた点はレビュー側の心理コストを下げる。「根拠があるなら採用」という判断が早くなる感覚がある。
なお answer_query のレイテンシは平均2.8秒で、search_documents 単体より1.5倍ほど遅い。クリティカルではないが、対話のテンポは若干鈍る場面もあった。
個人的に気になった部分（レイテンシと粒度）
良い面ばかり書いても胡散臭いので、欠点も挙げておく。
第一に、answer_query の合成回答は時々「文章として正しいが、コード例の粒度が浅い」ケースがあった。8タスク中3件で、別途 search_documents を呼んで生の断片を取り直している。素材と料理を使い分ける感覚は、ある程度の慣れがいる。
第二に、現状のドキュメント対象は Firebase / Google Cloud / Android / Maps が中心で、Workspace API系のカバレッジはやや薄い印象だ。筆者の用途では Gmail API周りで「ヒットなし」が2回出た。ここは時間が解決する話だと考えているが、今すぐWorkspace連携を組む人は注意したほうがいい。
結論：常設して困らないMCPの枠に入った
導入コストはほぼゼロ。レイテンシのトレードオフはあるが、再質問が減るぶんトータルでは時間が浮く。出典URLが付くことの効用も、思った以上に大きい。
筆者個人としては、Anthropicの「Context7」「Read MCP」あたりと同じ枠に置いている。常設しておいて損がない、いつもの並びに加える系のMCPだ。次にやるなら、社内のFirebase運用Runbookと組み合わせて、回答にプロジェクト固有のpolicyを上乗せする構成だろう。
Cursor / Claude Code / Gemini CLI の3系統で同じMCPが共通言語として使えるのも、地味だが効く。設定ファイルさえコピーすれば、チームメンバーが何のクライアントを使っていても同じ品質の回答に近づける。MCPの恩恵がここで初めて実感できた、と言ってもいい。
※本記事は筆者個人の検証結果と所感を含みます。動作環境や利用プランによって結果は異なる場合があります。各製品の最新仕様は公式ドキュメントをご確認ください。
