AIREITERコーディングエージェントでもGoogleの開発者向けページをスクレイピングすることはできます。ただしその場合、ページ構造への追従、情報の発見、重複排除、引用情報の管理まで、すべてエージェント側の責任です。Google Developer Knowledge APIなら、これらを文書化されたインターフェースの向こう側に任せられます。最新のGoogle公式ドキュメントを監査可能なコンテキストとして扱いたいなら、まずこちらを選ぶのがよいでしょう。もっとも、対象はGoogle開発者向けWeb全体ではなく、キュレーションされたコーパスに限られます。
このAPIが担うのは実行ではなく情報取得
Google Developer Knowledge APIは、Googleの公開開発者向けドキュメントを機械可読なコンテンツとして提供します。Googleは、ドキュメント検索、全文書の取得、バッチ取得、根拠付き回答をREST リファレンスで説明しています。
このサービスは、アプリケーションやエージェントに読み取り専用のコンテキストを渡すものです。非公開のCloudプロジェクトへアクセスしたり、IAM変更を承認したり、コードをデプロイしたり、生成されたコマンドの安全性を検証したりはしません。書き込み操作を行うエージェントには、別途認証情報とポリシーゲートが必要です。
コーパスの範囲も重要です。GoogleのAPIドキュメントが対象とするのは公開された開発者向けドキュメントであり、一般的なWeb検索ではありません。任意のGitHubリポジトリ、Stack Overflow、非公開の運用手順書、サードパーティ製ライブラリを検索する代替手段にはなりません。またGoogleは、返されるMarkdownが元のHTMLから生成されるものであり、表示ページのバイト単位の複製ではないことも明記しています。
利用可能状況と現在の挙動は、公式APIリファレンスおよびリリースノートで確認してください。
Google Developer Knowledge APIでできること
REST APIの操作は少なく、エージェントのポリシーにもそのまま落とし込みやすい構成です。
| 操作 | 返されるもの | 主な用途 |
|---|---|---|
SearchDocumentChunks | 一致したチャンクと親ドキュメントリソース | 根拠の発見と候補ページの特定 |
GetDocument | Markdown形式の完全な1ドキュメント | ページ前後の文脈をエージェントに与える |
BatchGetDocuments | 複数の完全なドキュメント | 関連ページの比較やローカルキャッシュのウォームアップ |
AnswerQuery | 裏付けとなる参照情報付きの回答 | 範囲を限定したドキュメント質問への回答 |
検索結果はチャンクであり、完全なページが返るとは限りません。結果のparentリソースを使って、GetDocumentまたはBatchGetDocumentsへ進みます。堅牢なクライアントでは、ページ取得前に親リソースごとに重複チャンクをまとめるべきです。そうしないと、ほとんど追加コンテキストを得られないまま、1ページが複数の取得枠を使ってしまいます。
一般的なリソース名は、ドキュメントリソース形式に従って次のようになります。
documents/docs.cloud.google.com/storage/docs/creating-bucketsこのリソース名のパターンは検索レスポンスの後に役立ちますが、エージェントは記憶から名前を組み立てるのではなく、サービスから返された正確なparentを優先すべきです。
検索モードごとに根拠の扱いが異なる
SearchDocumentChunksは、根拠を優先するモードです。正確なフラグ、パラメータ、権限、バージョンに関する注記、コード断片が必要な場合に使います。呼び出し元はチャンクを確認し、ドキュメントURIを保持したうえで、完全なページを取得するか判断できます。
GetDocumentとBatchGetDocumentsは、文脈を補うためのモードです。前提条件、警告、移行に関する注記、あるいは1つのチャンクでは抜け落ちる周辺セクションが答えに必要な場合、検索後に利用します。設計上の問いが複数の公式ページにまたがるなら、バッチ取得が便利です。
AnswerQueryは要約・統合のためのモードです。「この条件に合う現在のGoogle Cloudの選択肢はどれか」のように、コーパスに根拠を持たせたい範囲の明確な質問に向いています。ただし、流暢な回答だからといって参照情報を確認せず受け入れてはいけません。リスクの高いコード変更では、検索と全文書取得を組み合わせたほうが、エージェントの根拠の流れを検査しやすくなります。
認証方式は呼び出し元に合わせて選ぶ
実用上の認証パターンは3つありますが、同じ用途に適するわけではありません。
| 呼び出し元 | まず選ぶ方式 | 理由 |
|---|---|---|
| ローカルのcurlまたは簡単なプロトタイプ | 制限付きAPIキー | 最初のリクエストまで最短で進める |
| バックエンド、ワーカー、またはPythonクライアント | Application Default Credentials（ADC） | 認証情報をソースコードではなく実行環境に置ける |
| 対話型のMCPクライアント | ホストが対応するならOAuth、そうでなければ制限付きキー | 長期利用の単一キーをユーザーのツールに配布せずに済む |
クイックスタートでは、Google Cloudプロジェクトを作成または選択し、developerknowledge.googleapis.comを有効化して、Developer Knowledge APIに制限したAPIキーを作成します。制限のないキーをエージェントのプロンプト、リポジトリ、クライアント側バンドル、デバッグログへ入れてはいけません。
サービスを有効化する最小限のコマンドは次のとおりです。
gcloud services enable developerknowledge.googleapis.com \
--project="$PROJECT_ID"管理されたアプリケーションでは、通常ADCのほうが境界を明確に保てます。GoogleのPythonクライアントリファレンスでは、環境から検出される認証情報と、同期・非同期クライアントが説明されています。これにより、アプリケーションが設定テキストからキーを解析するのではなく、デプロイ環境がランタイム経由でIDを提供できます。
対話型エージェントにはOAuthも適しています。共有の静的シークレットではなく、ユーザー自身が接続を認可できるためです。具体的なOAuthフローはMCPホストに依存します。クライアントの認証対応は、API本体とは別に確認してください。MCP URLを受け取れるクライアントでも、ヘッダー、シークレット変数、トークン更新の扱いは異なる場合があります。
最小構成の取得ワークフロー
本番向けエージェントでは、情報取得の境界を明示しておくべきです。
- 質問文からシークレットや無関係なリポジトリ内容を取り除く。
SearchDocumentChunksで公式コーパスを検索する。- 親ドキュメントリソース単位で結果を重複排除する。
- 周辺コンテキストが必要なタスクでは、関連度の高い完全なドキュメントを取得する。
- 返されたURI、タイトル、タイムスタンプまたはメタデータ、選択した抜粋を保存する。
- 保持した根拠だけを基にモデルが回答するようにする。
- エージェントがコードやインフラを変更する前に、テストとポリシーチェックを実行する。
検索用RESTエンドポイントはGoogleのREST リファレンスに記載されています。
GET https://developerknowledge.googleapis.com/v1/documents:searchDocumentChunksAPIキーを使うシンプルなリクエストは次のようになります。
curl --get \
'https://developerknowledge.googleapis.com/v1/documents:searchDocumentChunks' \
--data-urlencode 'query=Cloud Storage bucket retention policy' \
--data-urlencode 'pageSize=5' \
--data-urlencode "key=$DEVELOPERKNOWLEDGE_API_KEY"パーサーを固定実装する前に、正確なレスポンススキーマとフィールド名を現在のREST リファレンスで確認してください。検索が返すのはチャンクと親ドキュメント名であり、ドキュメント取得ではその名前を使用します。
空の結果、欠落した親リソース、ページネーション、認証失敗、クォータ超過やレート制限のレスポンスについては、モックまたはスナップショットしたレスポンスでエージェントをテストします。リトライ処理はモデルのプロンプトの外に置き、上限付きバックオフと、根拠を取得できない場合の明確なフォールバックを用意してください。
REST API、MCP、Webページのどれを使うか
同じドキュメントソースでも、公開方法は3通りあります。
| 状況 | 最適な経路 | 理由 |
|---|---|---|
| サービスに再現性のある取得と引用が必要 | REST APIまたはクライアントライブラリ | アプリケーション側でパース、キャッシュ、根拠の保存を制御できる |
| コーディングアシスタントにオンデマンドのGoogleコンテキストが必要 | Developer Knowledge MCP server | 独自の接着コードなしで検索・取得ツールをエージェントから呼び出せる |
| ページがサポート対象コーパス外にある | ページへ直接アクセスするか別のソースコネクタ | Developer Knowledgeのコーパスでは不足するソースを補えない |
| 人間がレイアウト、ナビゲーション、対話的なサンプルを確認する | ブラウザまたはページへのアクセス | Markdownの取得は視覚的なページ検査ではない |
GoogleのMCPドキュメントでは、エンドポイントをhttps://developerknowledge.googleapis.com/mcpとして案内しています。MCPはエージェントのためのアダプターであり、別のナレッジベースではありません。リモートサーバー設定の代表例は次のとおりです。
{
"mcpServers": {
"google-developer-knowledge": {
"serverUrl": "https://developerknowledge.googleapis.com/mcp",
"headers": {"x-goog-api-key": "${DEVELOPERKNOWLEDGE_API_KEY}"}
}
}
}シークレット変数の構文はホストのドキュメントに従ってください。リテラルの${...}展開がどの環境でも動くとは限りません。また、コンテキストコストも考慮が必要です。すべてのタスクにすべてのツールを公開すると、ツール定義と判断のオーバーヘッドが増えることがあります。複数サーバーを利用するエージェント構成についての実際のユーザー議論でも、この懸念は端的に表現されています。
「MCPはskillsと比べて非常にコンテキストを多く消費します。skillsは呼び出されるまで数行のテキストしか使いません。」 — u/junlim, Reddit discussion
これはDeveloper Knowledge MCP serverをやめる理由ではなく、Googleに焦点を当てたタスクで条件付きで利用可能にすべき理由です。Firebase、Android、Google Cloud、Maps、Flutterを扱うエージェントには、このソースが役立ちます。一方で、無関係なスタックを編集しているエージェントがデフォルトで呼び出す必要はありません。
Google開発者向けドキュメントでAPIがスクレイピングを上回る場面
次の条件の大半に当てはまるなら、APIを使うのがよいでしょう。
- 対象がGoogle所有の開発者向けドキュメントである。
- エージェントに一度きりのページ取得ではなく、再現性のある検索が必要である。
- 回答に引用、または保存可能なソース履歴が必要である。
- 関連するチャンクと完全なドキュメントをエージェントが区別する必要がある。
- 構造化されたページネーション、バッチ処理、キャッシュがワークフローに必要である。
- ページデザインの変更でHTMLパーサーを作り直したくない。
それでもスクレイピングが適切なフォールバックになる場面はあります。必要なページがサポート対象コーパスにない場合、視覚的な操作がタスクに含まれる場合、正確なレンダリング後のHTMLやナビゲーション状態が重要な場合です。インシデント時にAPIへアクセスできないなら、一時的な調査手段としても合理的です。ただし、それを知らないうちに本番の情報取得契約へ変えてはいけません。
| 判断要素 | Developer Knowledge API | 開発者向けページのスクレイピング |
|---|---|---|
| 情報の発見 | インデックス済みコーパスに対するサービス検索 | 検索機能を構築するか、既知のURLから開始する |
| 出力 | チャンク、ドキュメントリソース、Markdown | HTMLまたはレンダリング済みページコンテンツ |
| 引用ワークフロー | 親リソースとドキュメントURIが明示される | アプリケーションがリンクを抽出して保存する必要がある |
| レイアウト保守 | API契約が境界となる | デザイン変更後にセレクタが壊れる可能性がある |
| カバレッジ | サポート対象の公開開発者向けコーパス | アクセス制限およびrobotsルールの対象となる、公開アクセス可能な任意のページ |
| 視覚的な忠実度 | 目的ではない | ブラウザ自動化を使えばレンダリングされたレイアウトを保持できる |
| エージェントの制御 | 検索、取得、統合の順に進める | 通常は取得、解析、整形、推論までを行う |
APIは、新しく公開されたすべてのページが即座に利用可能になることを保証しません。Googleのリリースノートではインデックス更新について説明されていますが、エージェントは鮮度を検証対象の性質として扱うべきであり、最新ページがすでにインデックスされている証拠と見なしてはいけません。リリース当日の移行では、返されたメタデータを現在の公式ページと比較し、根拠が不足する場合は安全側に倒して処理を停止してください。
実運用で採用したいエージェントポリシー
Google固有のコーディングエージェントでは、次のルーティングルールを採用します。
- 正確な実装詳細：まず
SearchDocumentChunksを使い、チャンクに前提条件がなければ親ドキュメントを取得する。 - 複数ページにまたがる設計の質問：検索後、関連する親リソースを少数に絞って
BatchGetDocumentsを使う。 - 単純な説明を求める質問：
AnswerQueryを使う。ただし、レスポンスには参照情報を必須とする。 - Google以外または非公開のドキュメント：承認済みの別コネクタへルーティングする。
- コードまたはインフラへの書き込み：情報取得は助言にとどめ、テスト、IAM、レビュー、デプロイの制御は引き続き必須とする。
ポリシーで許可される範囲では完全なドキュメントをキャッシュし、繰り返される検索はデバウンスし、未加工のシークレットや不要なリポジトリコンテキストではなくソースURIをログに残します。取得したMarkdownは信頼できない入力として扱ってください。権威ある出所であっても、埋め込まれたすべての指示が書き込み可能なツールを持つエージェントにとって安全になるわけではありません。
未解決のトレードオフはシンプルです。APIはHTMLスクレイピングよりもクリーンで監査しやすい契約をエージェントに提供しますが、ブラウザが持つカバレッジと即時のページ忠実性は手放すことになります。サポート対象のGoogleドキュメントではAPIをデフォルトにし、スクレイピングや別コネクタは、両方の経路を見えない形で混在させるのではなく、明示的なフォールバックとして残すべきです。
Google Developer Knowledge API FAQ
Developer Knowledge APIはGoogle検索と同じですか？
いいえ。これはサポート対象のGoogle開発者向けコーパスを対象とするドキュメント取得サービスであり、一般的なWeb検索APIではありません。非公開ドキュメント、任意のGitHubコンテンツ、Googleに関連するあらゆるページを自動的に検索するものではありません。
AnswerQueryとSearchDocumentChunksはどちらを使うべきですか？
範囲が限定された、根拠付きの説明にはAnswerQueryを使います。検査可能な根拠、正確な構文、ソース履歴が必要な場合はSearchDocumentChunksを使い、チャンクだけでは足りなければ親ドキュメントを取得してください。
APIキーは必須ですか？
制限付きAPIキーは、プロトタイプを最も素早く始める方法です。バックエンドクライアントはADCを利用でき、対話型MCP統合ではホストが対応していればOAuthを使えます。あるクライアントで利用できる認証方式が、別のクライアントでも自動的に利用できると考えてはいけません。
エージェントはこのAPIでGoogle Cloudリソースをデプロイできますか？
いいえ。このAPIが提供するのはドキュメントのコンテキストです。デプロイには、別のツール、認証情報、IAM権限、承認、検証が引き続き必要です。
どのようなときにスクレイピングすべきですか？
ページがAPIコーパスの対象外である場合、視覚的なレイアウトが重要な場合、またはインデックスにまだ現れていないページが必要な場合は、スクレイピングまたはブラウザコネクタを使います。エージェントがスクレイピングしたコンテンツをAPI由来の引用として扱わないよう、このフォールバックは明示的に記録してください。
検索で完全なページを取得できますか？
いいえ。検索が返すのはドキュメントチャンクです。完全なMarkdownページが必要な場合は、返された親ドキュメントリソースをGetDocumentまたはBatchGetDocumentsで使用します。