はじめに
「このページを要約して」と、URL を貼って AI に頼むことがあります。ですが、モデルは基本的に、渡された URL を自分で開けません。ではそのとき、AI は何を根拠に答えているのでしょうか。
Gemini には、プロンプト内の URL を実際に取得して読ませる URL Context というツールがあります。本記事では、このツールを付けた場合と付けない場合で、回答がどう変わるかを実際に叩いて比べました。結果は、ツールなしの挙動がかなり危ういものでした。
なお、本記事の検証は、Gemini API（google-genai SDK、APIキー認証）で行いました。ブラウザ版の Gemini ではなく、プログラムから API を呼び出したものです。Google Cloud（GEAP / Vertex AI）経由でも、クライアントの初期化を変えるだけで同じモデルと同じツールが使え、結果も基本的に同じになります。
また、仕様や料金は変わりうるため、最新の情報は公式ドキュメントで確認してください。
URL Context とは
URL Context は、プロンプトに含めた URL の中身を取得し、その内容に基づいて回答させるツールです。取得は2段階で、まず Google のインデックス（巨大なキャッシュ）から取りにいき、そこに無ければ実際にページへアクセスして取得します。
似た機能に Google 検索によるグラウンディングがありますが、役割が違います。グラウンディングは「検索して探す」、URL Context は「指定した URL をそのまま読む」。読ませたいページが決まっているなら URL Context が向きます。
取得の成否は、レスポンスの url_context_metadata で確認できます。どの URL を取得し、成功したか（URL_RETRIEVAL_STATUS_SUCCESS）失敗したか（ERROR）が返ります。
実装
google-genai SDK では、tools に URL Context を渡すだけです。URL はプロンプトの本文に書きます。
from google import genai
from google.genai import types
client = genai.Client()
url = "https://example.com/article"
resp = client.models.generate_content(
model="gemini-3.5-flash",
contents=f"次のURLの記事を読んで要約してください: {url}",
config=types.GenerateContentConfig(
tools=[types.Tool(url_context=types.UrlContext())], # これを外すと「ツールなし」
),
)
print(resp.text)
print(resp.candidates[0].url_context_metadata) # 取得したURLと成否
この tools=[...] を付けた場合（ツールあり）と、外した場合（ツールなし）で、同じ質問を投げて比べました。
検証の題材
読ませる URL には、私が Qiita に公開している自分の記事を使いました。理由は2つあります。中身を私が正確に把握しているので、答え合わせができること。そして個人記事なのでモデルが事前に丸暗記している可能性が低く、「本当にページを読んだのか」がはっきり出ることです。
題材にした記事は「Google Cloud 全冠を半年で達成した学習法」です。この記事には、次のような事実が書かれています。
- 学習法は3つのSTEPに分かれ、STEP2は「模擬問題を生成AI（Gemini）と一緒に復習する」
- 1資格あたりの学習時間の目安は約25時間
- 著者が特に難しかったと述べている資格は PCNE と PMLE
これらを、ツールあり/なしで質問しました。
検証① ツールあり と ツールなし
同じ URL と同じ質問を、ツールあり・なしの両方で投げた結果です。
| 質問 | URL Context あり | URL Context なし |
|---|---|---|
| STEP2は何をするか | 模擬問題を AI と復習する（正確） | 「Progate 等で学習」と、記事にない内容を回答 |
| 1資格の目安時間 | 約25時間（正確） | 別記事「AWS認定12冠を達成した…」の内容を作って回答 |
| 特に難しい資格 | PCNE と PMLE（正確） | 架空の「AWS12冠、ネスペ、支援士」記事を創作 |
ツールありは、3問とも正確に答えました。url_context_metadata はすべて SUCCESS で、実際にページを取得できています。
問題はツールなしです。URL を渡しても、モデルはそれを開けません。にもかかわらず「読めません」とは言わず、URL やタイトルから連想して、存在しない別の記事の内容を作って答えました。「Google Cloud 全冠」の記事なのに、なぜか「AWS認定12冠」という架空の記事の内容を、それらしく答えてきます。中身を読まないまま、もっともらしい要約を作ってしまう挙動です。
つまり、URL を貼って「要約して」と頼むとき、ツールを付けていなければ、返ってくる要約は中身を見ていない作り話かもしれない、ということです。
検証② 複数の URL を渡す
URL Context は、複数の URL をまとめて読ませることもできます。全冠学習法の記事と、別の「IAM 設計のアンチパターン」の記事を2つ同時に渡し、それぞれ何の記事かを要約させました。
結果は、2つとも正しく取得（SUCCESS が2件）し、次のように要約されました。
- 1つ目：Google Cloud 未経験から半年で全14資格を取得した著者が、1資格あたり約25時間で合格する3ステップの学習法を解説した記事
- 2つ目：Google Cloud の公式ドキュメントに基づき、IAM 設計の6つのアンチパターンと正しいアプローチを解説した記事
どちらも中身に即した要約で、取り違えもありませんでした。複数ページを読んで比較や統合をする用途に使えます。
検証③ 読めない URL はどうなるか
取得できない URL を渡すと何が起きるかも見ました。
-
存在しない URL（でたらめな記事ID）：
url_context_metadataはERRORを返し、回答も「アクセスできない、またはダミーのURLの可能性があり、内容を取得できませんでした」と正直に答えました。ツールありなら、取得に失敗したときは事実にない内容を作らず、失敗と伝える、という点が確認できました。 -
YouTube の URL：取得自体は
SUCCESSになり、動画のタイトルなどページの情報は答えられました。ただし、これはページの情報であって、動画そのものの中身を解析したわけではありません。公式にはペイウォールのページや一部のメディアは対象外とされているので、何でも読めるわけではない点は注意が要ります。
検証①のツールなしと対照的なのがポイントです。**ツールありは、読めなければ「読めない」と言う。ツールなしは、読めないのに読んだつもりで答える。**この差が、信頼性の分かれ目です。
使い分け
今回の実測をふまえた整理です。
-
読ませたい URL が決まっている：URL Context を使う。指定ページをそのまま読み、取得の成否も
metadataで確認できる。 - 何を読むべきか探す段階から任せたい：Google 検索によるグラウンディングを使う。検索で探し、必要なら URL Context と組み合わせる。
- URL を貼るだけでツールを付けない：やってはいけない。中身を見ていない作り話が返る危険がある。
RAG（自前の検索基盤）を組むほどでもなく、決まった Web ページを読ませたいだけなら、URL Context は手軽で確実な選択肢になります。
まとめ
| 観点 | 実測からの結論 |
|---|---|
| ツールなし | URL を開けないのに、別記事の内容を作って答える（要注意） |
| ツールあり | 実際にページを読み、事実を正確に抽出。metadata で取得を確認できる |
| 複数 URL | まとめて取得して要約できる。取り違えなし |
| 読めない URL |
ERROR を返し、事実にない内容を作らず「取得できない」と答える |
| 使い分け | 決め打ちの URL は URL Context、探索はグラウンディング |
「URL を貼って要約して」という何気ない使い方は、ツールを付けていなければ、AI が中身を読まずに要約してしまうリスクがあります。URL Context を付ければ、実際に読ませたうえで、取得できたかどうかまで確認できます。Web ページを AI に読ませるなら、まずこのツールを付けているかを確かめるのが安全です。