10月10日、Romin Iraniが「Grounding Google Docs Suggested Edits with Developer Knowledge MCP and Google Search」と題した記事を公開した。この記事では、Google Docsの編集提案機能にMCPサーバーとGoogle Search Groundingを組み合わせ、技術文書の事実誤りを自動検出・修正するAIエージェントの実装方法について詳しく紹介されている。

本記事はシリーズの第2弾にあたる。Part 1ではGoogle Docs APIとADK（Agent Development Kit：Googleが提供するエージェント構築フレームワーク）を使った基本的な編集提案エージェントの構築を扱っており、本稿はその発展として「修正の根拠となる出典URL」をセットで提示する仕組みを追加する。

スペルより「事実誤り」を直す——そのためのアーキテクチャ

AI文書レビューで本当に価値があるのは、スペルや文法の訂正ではなく事実誤りや古くなった技術的主張の検出だ。記事ではその例として以下が挙げられている。

• "Cloud Run services only support a maximum request timeout of 15 minutes and 8 GiB of RAM." → 実際は60分・32GiB（古いスペック）
• "gcloud run deploy my-api --source . --public-access" → **正しいフラグは --allow-unauthenticated**（存在しないフラグの幻覚）
• "Python 3.12, released in October 2021." → 実際のリリースは2023年10月（日付の誤り）

静的な学習データだけに頼るAIは、こうした誤りを見落とすか、逆に誤った「修正」を提案してしまう。さらに致命的な点として、出典のない修正提案は著者に受け入れてもらえないという問題がある。✓ Acceptボタンを押してもらうには、「どこからその数字が来たか」を示す必要がある。

そこで本記事では、修正の根拠となるURLを余白コメント（Anchored Margin Comment）として添付しつつ、修正内容をSuggested Editとして提案するエージェントを構築する。

2つの検索エンジンを役割で使い分ける

記事の核心は、Google Developer Knowledge MCPサーバーとGoogle Search Groundingを組み合わせたハイブリッド構成だ。

Google Cloud固有の情報を一般検索でカバーしようとすると、2021年の古いブログ記事やStackOverflowの回答が上位に来てしまう。一方、公式ドキュメントだけではPythonのリリース日のような第三者の情報をカバーできない。両者を組み合わせることで、それぞれの弱点を補完する。

実装の要点：ADKならではの2つの注意点

1. MCPサーバーへの認証——起動時とリクエスト時の二重対応

McpToolsetのheader_providerコールバックは、readonly_contextが非nullの場合（エージェントのターン実行中）にのみ呼ばれる。FastAPIの起動時にADKがAgent Cardを構築する段階ではreadonly_contextがnullのため、header_providerが機能しない。

この問題を回避するため、認証ヘッダーをStreamableHTTPConnectionParams(headers=...)とMcpToolset(header_provider=...)の両方に渡す必要がある：

developer_knowledge_mcp = McpToolset(
    connection_params=StreamableHTTPConnectionParams(
        url="https://developerknowledge.googleapis.com/mcp",
        headers=_developer_knowledge_headers(),  # 起動時用
        timeout=30.0,
        sse_read_timeout=30.0,
    ),
    header_provider=_developer_knowledge_headers,  # リクエスト時用
)

認証自体はgoogle.auth.default()（Application Default Credentials）で処理されるため、追加のAPIキーは不要だ。GOOGLE_CLOUD_PROJECT環境変数があれば自動的にX-Goog-User-Projectヘッダーに付与される。

2. google_searchはサブエージェント経由で渡す

GeminiのAPIには重要な制約がある。google_searchはモデル内部のGrounding専用ツールであり、カスタムのFunctionToolやMcpToolsetと同一のtools=[...]リストに混在させることができない。

これを解決するのがADKのAgentToolパターンだ。google_search専用のサブエージェントを作成し、それをAgentToolでラップしてルートエージェントに渡す：

web_search_verifier = Agent(
    name="web_search_verifier",
    model="gemini-2.0-flash",
    description="Verifies general public facts using Google Search Grounding.",
    instruction=(
        "You are a precise fact-checking researcher. Given a factual claim:\n"
        "1. Use `google_search` to verify the claim.\n"
        "2. Return the verdict, the corrected value if inaccurate, and the source URL."
    ),
    tools=[google_search],
)

ルートエージェントからは通常の関数ツールとして見えながら、内部では独立したモデル呼び出しでGoogle Search Groundingが実行される。

処理フローのポイント：コメントを先に挿入する

Google Docs APIへの書き込み順序にも実装上の工夫がある。記事では以下の順序を指定している：

1. insert_commentsを先に実行：検証済みURLと説明を余白に固定する
2. propose_suggested_editsを後に実行：古い記述を取り消し線で消し、修正案をインラインで提案（後ろから前の順でオフセットがずれないように処理）

この順序により、著者がSuggested Editを確認する際、隣の余白コメントに「なぜこの変更が必要か」と「出典URL」がセットで表示される状態になる。

まとめ

このシリーズで構築するdoc-reviewer-101は、技術文書の事実確認を自動化する実践的な構成だ。単なる文法チェックにとどまらず、「根拠を示しながら修正を提案する」という点が本アーキテクチャの本質的な価値といえる。静的な学習データの限界をリアルタイム検索で補い、さらに出典URLをコメントとして残すことで、著者が内容を判断・承認するプロセスを損なわずにAI支援を実現している。リポジトリにはPart 2対応のapp/agent.pyが公開されており、MCPサーバーへの接続からGoogle Docs APIへの書き込みまでの実装を確認できる。

※編集部の考察：Developer Knowledge MCPとGoogle Search Groundingを「役割で分離する」設計は、社内ドキュメントの自動レビューや、APIリファレンスの陳腐化チェックといった用途にも応用しやすい。ADKのAgentToolパターンはツール制約の回避策としても参考になる。

詳細はGrounding Google Docs Suggested Edits with Developer Knowledge MCP and Google Searchを参照していただきたい。