Claude Web Fetch ツールの使い方|最新情報取得エージェント
Claude に最新の Web 情報を取りに行かせたいが、検索ツールとの違いが曖昧ではないでしょうか。Web Fetch ツールの仕組みと最小実装、調査・監視エージェントへの組み込み方を本記事でまとめました。
Web Fetch ツールは、指定した URL や許可ドメインの本文を Claude が取得し、回答の根拠として組み込む「取得ツール」です。クエリで探す検索ツール、画面を操作するコンピュータ操作とは役割が分かれており、「読むべき場所が決まっている最新情報」を確実に回答へ反映させたいときに最も効きます。
2026 年 6 月 29 日に公開された anthropic-sdk-python v0.113.0 は、新しいツール版 20260318 に対応し、非同期の count_tokens で出力フォーマット指定が欠落していた不具合も修正しました。コスト見積もりが正しく出るようになったため、Web Fetch を組み込むなら この版以上に上げておくのが実務的な前提になります。
稼ぎに直結するのは、競合のリリース・価格ページ監視、業界ニュースの要約レポート、社内ナレッジの最新化といった「成果物が毎日出る」設計です。取得 → 要約 → 構造化出力の段構成にまとめ、許可ドメインの絞り込みと取得失敗時の代替手段まで決めておけば、受託・社内効率化のどちらにも転用できます。
Contents (16)
- Web Fetch ツールとは — 何ができて、検索・操作系と何が違うのか
- 「探す」のではなく「読む」ツールである
- 取得した本文は「根拠」として回答に組み込まれる
- v0.113.0 で何が変わったか
- 新しいツール版 20260318 への対応
- 非同期 count_tokens のバグ修正でコスト見積もりが正常化
- 最小構成で動かす — SDK で取得ツールを呼び出す基本形
- 許可ドメインと取得件数の上限を最初に決める
- 「稼げる」使い方 — 調査・監視・競合インテリジェンスのエージェント設計
- ユースケース 1: 競合のリリース・価格ページ監視
- ユースケース 2: 業界ニュースの要約レポート
- ユースケース 3: 社内ナレッジの最新化
- コストと安全の勘所 — token カウント・ドメイン制限・取得失敗時の設計
- 事前に count_tokens でコストを見積もる
- ドメイン制限と取得失敗時のフォールバック
- 出典
Web Fetch ツールとは — 何ができて、検索・操作系と何が違うのか
Web Fetch ツールは、Claude が指定された URL(または許可リストに載ったドメイン)にアクセスし、その本文を読み取って回答の根拠に使う「取得(fetch)」専用のツールです。検索エンジンのように候補を探すのではなく、「ここを読め」と場所が決まっているページの中身を確実に回答へ反映させるのが役割になります。レポートの引用元や監視対象の URL が事前に分かっているユースケースで真価を発揮します。
ここで混同しやすいのが、検索ツールやコンピュータ操作との違いです。三者は競合ではなく、目的が異なる別々の道具です。次の表で役割分担を整理します。
| ツール | 入力 | やること | 向いている場面 |
|---|---|---|---|
| Web Fetch | URL / 許可ドメイン | 指定ページの本文を取得して根拠に使う | 読む場所が決まっている最新情報 |
| 検索 | 検索クエリ | クエリで候補ページを探す | どこに情報があるか未知 |
| コンピュータ操作 | 画面・座標 | ブラウザや GUI を実際に操作する | ログインや入力など操作が必要 |
「探す」のではなく「読む」ツールである
検索ツールが「キーワードからページを発見する」のに対し、Web Fetch は「発見済みのページを読み込む」道具です。両者は組み合わせて使えます。まず検索で候補 URL を集め、確度の高い 1〜2 件だけを Web Fetch で精読させると、無駄な取得を減らしつつ根拠の質を上げられます。「最新情報を取れる手段はどれか」と一つに絞る必要はなく、目的ごとに使い分けるのが正解です。
取得した本文は「根拠」として回答に組み込まれる
Web Fetch の利点は、取得した本文がモデルの回答に引用元付きで反映される点にあります。どのページの記述に基づいた回答かを後から追跡できるため、調査レポートや社内向け要約のように「出典が問われる成果物」と相性が良いです。逆に、出典が曖昧でよい雑談的な用途では、わざわざ取得ツールを噛ませる必要はありません。
v0.113.0 で何が変わったか
Python SDK の最新版 anthropic-sdk-python v0.113.0 は 2026 年 6 月 29 日に公開されました。Web Fetch を実装に組み込むうえで押さえるべき変更点は 2 つあります。詳細はリリースノートに記載されています。1 点目は新しいツール版への対応、2 点目はコスト見積もりに関わる不具合修正です。順に見ていきます。
新しいツール版 20260318 への対応
v0.113.0 では、API 側の Web Fetch ツール新版 20260318 とその関連ツールが SDK から扱えるようになりました。ツール版は日付形式のバージョン文字列で管理されており、版を固定して指定することで、後方互換性を保ちながら挙動を安定させられます。実装時は、利用するツール版を明示し、対応する挙動を公式ドキュメントで確認しておくのが安全です。
非同期 count_tokens のバグ修正でコスト見積もりが正常化
もう一つの重要な修正が、非同期版の count_tokens 呼び出しで出力フォーマット指定が欠落していた不具合(Issue #162)の解消です。count_tokens はリクエストを送る前にトークン数を見積もるための機能で、ここが正しく動かないとコスト試算がずれます。この修正により、Web Fetch を組み込んだ非同期処理でも事前のコスト見積もりが正しく取れるようになりました。だからこそ、取得系の機能を本番投入するなら v0.113.0 以上へ上げておくべき、というのが実務的な結論です。
最小構成で動かす — SDK で取得ツールを呼び出す基本形
まずは最小構成で「取得結果が回答に反映される」流れを体感するのが近道です。基本の段取りは次の 3 ステップです。
- クライアントを初期化し、利用するツール版(
20260318)を指定して Web Fetch ツールを定義する - ユーザーの指示と一緒にツールをモデルへ渡し、メッセージを生成する
- モデルが対象 URL を取得し、その本文を根拠に組み込んだ回答を返す
Python での最小イメージは次のとおりです。パラメータの正確な指定方法は前述の公式ドキュメントで確認してください。
from anthropic import Anthropic
client = Anthropic()
resp = client.messages.create(
model="claude-opus-4-7",
max_tokens=1024,
tools=[{
"type": "web_fetch_20260318",
"name": "web_fetch",
"max_uses": 3,
"allowed_domains": ["docs.anthropic.com"],
}],
messages=[{
"role": "user",
"content": "このページの要点を3つに要約して",
}],
)
print(resp.content)
許可ドメインと取得件数の上限を最初に決める
最小構成でも、許可ドメイン(allowed_domains)と取得回数の上限(max_uses)は最初に決めておくべきです。許可ドメインを絞ると、想定外の URL を読みに行く事故を防げます。取得回数の上限を設けると、一回のやり取りで延々とページを取りに行ってコストが膨らむのを抑えられます。どちらも「動いてから付ける」のではなく、最初から付けておくのが安全側の設計です。
「稼げる」使い方 — 調査・監視・競合インテリジェンスのエージェント設計
Web Fetch が受託・社内効率化に効くのは、「読む場所が決まっている定常タスク」を任せられるからです。毎日同じ URL を読み、要約し、決まった形で出力する。この繰り返し作業こそ機械に向いています。代表的なユースケースを 3 つ挙げます。
ユースケース 1: 競合のリリース・価格ページ監視
競合製品のリリースノートや価格ページの URL を許可ドメインに登録し、毎日決まった時刻に取得 → 前回との差分を要約させる構成です。価格改定や新機能の発表を人手で巡回する手間が消え、「変わった点だけ」が手元に届きます。監視対象が増えても URL を足すだけで横展開できるのが強みです。
ユースケース 2: 業界ニュースの要約レポート
検索で候補を集めてから、確度の高い記事だけを Web Fetch で精読させ、日次のニュースダイジェストに仕立てる構成です。取得 → 要約 → 構造化出力の段構成にしておくと、Slack やメールにそのまま流せる成果物が毎朝出ます。出典 URL を本文に残す設計にすれば、レポートの信頼性も担保できます。
ユースケース 3: 社内ナレッジの最新化
社内ドキュメントや公式仕様の特定ページを取得対象にして、古くなった記述を検出・更新案を提示させる使い方です。「どのページのどの記述が変わったか」を機械が拾い、人は判断だけに集中できます。取得 → 比較 → 構造化出力の流れにまとめると、ナレッジ更新の抜け漏れを大きく減らせます。
コストと安全の勘所 — token カウント・ドメイン制限・取得失敗時の設計
最後に、本番投入で必ず詰まる「コスト」と「失敗時の振る舞い」を押さえます。Web Fetch は外部ページを読み込む以上、取得本文がそのままトークン消費とコストに跳ね返ります。誇張せずに言えば、取れないページ・古い情報も普通に存在します。前提として、取得できないケースまで含めて設計するのが実務です。
事前に count_tokens でコストを見積もる
v0.113.0 で非同期の不具合が直った count_tokens を使い、リクエスト前にトークン数を見積もる習慣をつけます。取得対象が大きなページだと本文だけで数千トークンに達することもあり、件数が増えれば無視できないコストになります。取得本文の上限を設定し、見積もり値が閾値を超えたら取得を止める、といった歯止めを入れておくと安全です。
ドメイン制限と取得失敗時のフォールバック
許可ドメインの絞り込みは、コストとセキュリティの両面で効きます。読みに行く先を限定すれば、想定外のページ取得による事故もコストの暴走も防げます。あわせて、取得が拒否されるページ・本文抽出に失敗するページへの備えも必要です。失敗時は「取得できなかった」と正直に出力へ残し、検索結果や前回キャッシュにフォールバックする段取りを決めておくと、エージェント全体が止まりません。鮮度にも限界がある以上、取れた情報がいつ時点のものかを明記する設計が、信頼される成果物の条件になります。
出典
- anthropic-sdk-python v0.113.0 リリースノート: https://github.com/anthropics/anthropic-sdk-python/releases/tag/v0.113.0
- Anthropic 公式ドキュメント(リリースノート / ツール): https://platform.claude.com/docs/en/release-notes/overview
Clauder Navi 編集部