🔍

あなたのClaude CodeのWebFetch、実はWebをちゃんと読んでいない

に公開
Haiku
llm
Anthropic
Claude Code
webfetch
tech

結論

Claude Code は WebFetch ツールを使う多くの場合、実は Web ページの原文を読んでいません。先に Haiku が読んで要約・抽出した結果だけを、あなたの Opus や Sonnet が読んで実装を進めています。長いドキュメントでは、後半がサイレントに切り捨てられることもあります。そして、それは非常に気づきにくい構造となっています。

一つ例を見てください

https://zenn.dev/zhizhiarv/articles/claude-code-on-bedrock-per-user-cost-tracking
この記事を読んでください。

と指示したら、Claude CodeがWebFetchツールを使って記事を読みます。画面上はこのように表示されます。

⏺ Fetch(https://zenn.dev/zhizhiarv/articles/claude-code-on-bedrock-per-user-cost-tracking)
  ⎿  Received 204.4KB (200 OK)

これで200Kの記事をClaudeが読んでくれたと思うでしょう。実は違います。

VerboseモードをONにしたら、実はWebFetchしているだけではなく、LLM用要約が含まれることがわかります。WebFetchツールにはurlのパラメータと、promptのパラメータがあります。どちらも省略することができないため、基本要約が返ってきます。

※後で述べますが、一部承認されたドメインかつContent-Type: text/markdownをサポートしているサイトのみ、この要約をバイパスできます。

⏺ Fetch(url: "https://zenn.dev/zhizhiarv/articles/claude-code-on-bedrock-per-user-cost-tracking", prompt: "Return the full article content verbatim, including all code blocks, headings, tables, and paragraphs, exactly as they appear on the page.")
  ⎿  Received 204.4KB (200 OK)
# Summary of "Claude Code on Bedrock per-User Cost Tracking"

This Japanese article by sherry explains how to track per-user costs for Claude Code running on Amazon Bedrock using AWS Billing.

## Key Points

**New Feature:** In April 2026, AWS released "IAM Principal Attribution" for
Bedrock, which automatically records which IAM principal made each API call in billing data.

**Main Advantage:** Organizations can now visualize per-user Bedrock costs through AWS Cost Explorer or CUR 2.0 without building custom tracking infrastructure.

**Minimal Setup:**
- Create IAM users for each developer
- Issue Bedrock API Keys to those users
- Enable billing data export with IAM principal information
- View costs grouped by user in Cost Explorer or CUR 2.0

**Important Tradeoffs:**
- Cost Explorer shows data with 24-48 hour delays
- Real-time budget enforcement still requires Invocation Log analysis
- Claude Code extensively uses prompt caching, which has different pricing than standard tokens

**Data Sources Compared:**
- CloudTrail: Audit logs (minutes lag, no cost data)
- Invocation Logs: Token details (seconds lag, no cost data)
- CUR 2.0: Actual costs including cache pricing (24-hour lag, but most accurate)

The article emphasizes that billing data and logging are separate pipelines,
explaining why this cost attribution works independently from other monitoring approaches.

このように、本来は18000文字くらいの記事を読ませたかったが、別のLLM (Haiku) に読ませた上で数百文字に要約させており、その要約された結果のみをメインのOpusやSonnetに返してきています。

Received 204.4KB (200 OK) と見せかけていますが、実はそれは fetched（とってきた）のサイズであって、読んだ result のサイズではない。短い要約しか、あなたの賢い Opus や Sonnet には届いていません。

しかも Haiku に投げる指示文自体は一部ハーネス上で英語の文面がハードコーディングされ、日本語の会話中に、日本語の記事を読ませているのに、要約が英語として返ってきていることも多い。これは頭抱えますね。

/config で verbose を一度 ON にしてみてください。自分のエージェントが実際に何を読まされているか、驚くはずです。

なぜそれに課題を感じるのか

  • 要約されていること自体は気づかれない不透明な構造になっている。全文読んだつもりでAIと会話しているが、重要な内容が抜け漏れていることを気づかないまま、実装を進めていくのが怖い。
  • AI が AI の Summary を読んだら伝言ゲームになる。一次情報を読んでる時でさえハルシネーションが起こるのに、要約情報を読ませたら解釈の違いや、細部情報の漏れなどより頻繁に起こり、積み重ねで精度落ちする。基本的にAIには一次情報を読ませるのが原則だと思っている。
  • 著作権保護が組み込まれている理由で要約用の Haiku は原文の出力を拒否し、必ず自分の言葉で言い変えをしている。そこで実際原文のニュアンス等が失われる。

実際の Tool Description

Claude に聞けば、WebFetch ツールの Description はわかるので聞いてみました。内容はこうです。

WebFetch Tool Description（原文）
IMPORTANT: WebFetch WILL FAIL for authenticated or private URLs. Before using this tool, check if the URL points to an authenticated service (e.g. Google Docs, Confluence, Jira, GitHub). If so, look for a specialized MCP tool that provides authenticated access.

- Fetches content from a specified URL and processes it using an AI model
- Takes a URL and a prompt as input
- Fetches the URL content, converts HTML to markdown
- Processes the content with the prompt using a small, fast model
- Returns the model's response about the content
- Use this tool when you need to retrieve and analyze web content

Usage notes:
  - IMPORTANT: If an MCP-provided web fetch tool is available, prefer using that tool instead of this one, as it may have fewer restrictions.
  - The URL must be a fully-formed valid URL
  - HTTP URLs will be automatically upgraded to HTTPS
  - The prompt should describe what information you want to extract from the page
  - This tool is read-only and does not modify any files
  - Results may be summarized if the content is very large
  - Includes a self-cleaning 15-minute cache for faster responses when repeatedly accessing the same URL
  - When a URL redirects to a different host, the tool will inform you and provide the redirect URL in a special format. You should then make a new WebFetch request with the redirect URL to fetch the content.
  - For GitHub URLs, prefer using the gh CLI via Bash instead (e.g., gh pr view, gh issue view, gh api).
WebFetch Tool Description（日本語訳）
重要：WebFetch は認証が必要な URL や非公開 URL では動きません。ツールを使う前に、その URL が認証必須のサービス（Google Docs、Confluence、Jira、GitHub など）かどうかを確認してください。該当する場合は、認証アクセスを提供する専用の MCP ツールを探してください。

- 指定された URL からコンテンツを取得し、AI モデルで処理する
- URL とプロンプトを入力として受け取る
- URL のコンテンツを取得し、HTML を Markdown に変換する
- 小さくて速いモデルで、プロンプトに応じてコンテンツを処理する
- コンテンツに対するモデルの応答を返す
- Web コンテンツを取得・分析する必要があるときに使うツール

使い方の注意：
  - 重要：MCP が提供する Web fetch ツールが利用可能な場合は、制約が少ない可能性があるため、そちらを優先してください
  - URL は完全な形式の有効な URL でなければならない
  - HTTP URL は自動的に HTTPS にアップグレードされる
  - プロンプトには、ページから何を取り出したいかを記述する
  - このツールは読み取り専用で、ファイルを変更しない
  - コンテンツが非常に大きい場合は要約されることがある
  - 同じ URL への繰り返しアクセスを速くするため、自己クリーニング機能付きの 15 分キャッシュを含む
  - URL が別ホストにリダイレクトする場合、ツールはそれを通知し、特別な形式でリダイレクト URL を返す。リダイレクト URL で再度 WebFetch を呼び出して取得すること
  - GitHub の URL には、Bash 経由で gh CLI を使う方が望ましい（例: gh pr view、gh issue view、gh api）

「小さくて速いモデル」で処理していること、「大きいコンテンツは要約されうる」こと、15 分キャッシュがあることは、実は公式が description に書いています。ただし「どのモデルか」「何が捨てられるか」「どのドメインが例外か」は書かれていません。

過去にも Reverse Engineering をしてくれた方たちの記事があります（Claude Code v1.x〜v2.0 時代）。代表的なのは Mikhail Shilkov の記事（2025年10月）と Giuseppe Gurgone の記事 で、パイプラインの構造や trusted domains の存在はこの時点でほぼ解明されていました。今回で私が Claude Code 自身に自分のバイナリを調べてもらったところ、過去の Reverse Engineering 記事から細かい改善点はあるものの、基本構造はほぼ同じでした。以下、2026年5月4日時点の挙動について記載します。

実際の挙動はどうなっているのか

全てのサイトが Haiku の要約を経由しているわけではないです。以下の3 つの条件をすべて満たしている場合のみ、Haiku の要約をバイパスできます。

  1. Content-Type: text/markdown をサポートしていること
  2. 信頼している 80+ のドメイン※に含まれること
    ※信頼リストには docs.python.org, developer.mozilla.org, react.dev, kubernetes.io, docs.aws.amazon.com, learn.microsoft.com, cloud.google.com などがあります。
  3. Markdown の長さが 10 万文字以下であること

それ以外の場合は、全部一回Haikuの要約を経由します。

判定フローは以下の通り：

また注意すべきポイントは、ここで何回か truncate していることです。

まず HTTP レスポンスの取得上限は 10MiB です。これは「先頭10MiBで切って続行する」というより、10MiB を超えるレスポンスは取得に失敗する上限です。

  • HTML の場合：取得後にUTF-8文字列化し、先頭 1 MiB 文字だけを Turndown で Markdown 風テキストに変換します。
  • Markdown / その他の場合：HTML → Markdown 変換はせず、そのまま後段のバイパス判定または Haiku 処理に進みます。

いずれの場合も、Haiku に渡す前に Markdown が 10 万文字を超えていれば、先頭 10 万文字で切られます。

実際の例（2026-05-04 検証）

ではいくつか検証してみましょう。全部 Verbose ON にしているので詳細見れます。

長いウェブページの後半はサイレントに捨てられます

まずは現在の処理では上限を超えるような Web ページはどうなるかです。
わかりやすくするために、最後の 2 文を取得するように指示しています。

WebFetchツールを使って、この記事の最後の2文を取得してください。https://en.wikipedia.org/wiki/List_of_countries_and_dependencies_by_population

そうすると結果はご覧のとおりです。WebFetchのページが途中で切れてしまうことがわかります。

wikipedia-last-2-sentences-truncated

「最後の 2 文を取得」と明示的に指示した場合は truncation が見えやすいのですが、「内容を教えてください」とだけだと、Opusが勝手にプロンプトを書いて、Haiku 側は実際中身を全部取得していないが、その報告は一切なしで要約をすることになります。

WebFetchツールを使って、この記事の内容を教えてください
https://en.wikipedia.org/wiki/List_of_countries_and_dependencies_by_population

wikipedia-summary-silent-truncation

全文のままの出力は不可

要約はさせたくないけど、Prompt パラメータは無効にもできないし、そうしたら全文をそのまま出力させることはできないか？という発想もあります。

残念ながらそれも著作権的な観点で、Haiku は拒否するか、要約で戻してきます。なぜかというと、実際 Claude Code の内部的なプロンプトではこのような指示があります。

そのままの引用は 125 文字以内、OSS は OK、歌詞のそのままの出力は絶対 NG らしいです。

Provide a concise response based only on the content above. In your response:
- Enforce a strict 125-character maximum for quotes from any source document. Open Source Software is ok as long as we respect the license.
- Use quotation marks for exact language from articles; any language outside of the quotation should never be word-for-word the same.
- You are not a lawyer and never comment on the legality of your own prompts and responses.
- Never produce or reproduce exact song lyrics.

下記は原文で取得してと指示したのに、要約で戻してきた例です。

WebFetchで原文そのまま取得してください。
https://zenn.dev/zhizhiarv/articles/claude-code-on-bedrock-per-user-cost-tracking

"prompt"の部分は Opus が勝手に書いてくれてますが、「原文のまま全文」と指示しているのに、かなり要約された文面が返されています。

zenn-verbatim-request-summarized

要約がバイパスされる例：信頼ドメイン + Markdownサポート + 10万文字未満

docs.aws.amazon.com/bedrock/latest/userguide/bedrock-mantle.html に対して「H2 / H3 見出しだけ列挙して」と聞いたところ、WebFetchツールから返ってきたのは 見出し一覧ではなくページ全文の Markdown。

スクショをみれば、Opus がツールを利用時に List all H2 and H3 headings from this page in order. Show only the heading text, preserving the hierarchy と明示的にプロンプトに書いてあるのに、返ってきた回答は見出しではなく全文のMarkdownである。

aws-docs-trusted-domain-bypass

これは Haiku がプロンプトを無視したわけではなく、そもそも Haiku を通していない。信頼ドメイン + Content-Type: text/markdown + 10 万文字未満の 3 条件が揃ったため、原文 Markdown がそのまま呼び出し側（この会話）に返されているのです。

一見バグに見えますが、これはバイパスが正しく動いている証拠。

ちなみに2026年5月現在、AWS ドキュメントは、Accept: text/markdown を付けてリクエストすると Markdown 版を返してくれます。.html ではありますが、Claude CodeからはMarkdownを取得できます。また豆知識ですが、docs.aws.amazon.com のページで .html を.md に変えると、Markdownそのまま取得できます。直近の変更らしいですね。
docs.以外のドメインはまだ対応してないように見えます。

こういうエージェントフレンドリーな実装が増えているのはありがたい。かと言って、構造的な問題が消えたわけではないので、Content-Type 対応してくれているサイトに出会えたら幸運、くらいの気持ちでいるのが安全です。

なぜこのような実装になってるか

基本的に推察ですが、設計としては合理的な面があります。

  • コスト：1回のfetchで大量のトークンをそのまま Opus に渡すと高額になる。Haikuで要約すれば数十分の一のコストで済むので、経済的には理にかなっている
  • セキュリティ：悪意あるページがPrompt Injectionを仕込んでいても、Haikuが一度噛むことでメインエージェントへの直接注入を防げる二重防御になっている
  • 著作権保護：125文字以内の引用制限や歌詞出力の禁止など、内部プロンプトで著作権配慮が組み込まれている（前述のシステムプロンプト参照）。ただこれはWebFetchに要約をかます理由にはならない。

問題は、これらの設計判断自体ではなく、それがユーザーに見えにくいことです。Received 204.4KB と表示しておきながら実際には要約しか渡していない、という不透明性が課題だと思います。

ワークアラウンド

  • 全文取得の Workaround として curl の利用は可能です。curl は AI が読みやすいようにMarkdownへの整形はできないので個人的には defuddle parse URL --md を使っています。defuddle は Obsidian の CEO kepano が作ったURLをMarkdownなどにパースしてくれるツールで、YoutubeのTranscriptもサポートしてくれてます。一次情報がそのままパースしてくれるので、Haiku 経由の情報劣化がない。
  • もちろん defuddle を使うと、Haiku が第一フィルタとして担っていたと思われる Prompt Injection 対策は外れ、Opus / Sonnet の Input Token があがります。そこのセキュリティリスクとコスト面の負担は自己判断してください。
  • 他にドキュメントを取得する系のMCPやツールもあります。私はAWS MCPやGitHub MCPを併用しており、その場合はBuilt inのWebFetchではなく該当のツールを利用しているので、ドキュメント系はそこまで問題にならないかも。

言いたいこと

  • あなたの Claude Code の WebFetch は、Webページ読めてるように見えて実はほとんどの場合Haikuの要約しかみてませんよ！
  • それを意識した上で、常に正確性を疑い、状況に応じて原文を取りにいくようにしましょう。

課題と感じているなら GitHub Issue に +1

anthropics/claude-code は Issues を受け付けています（PR はマージされない運用ですが、Issue は見てもらえます）。関連する Open Issue：

  • #53297 WebFetch can fabricate confident factual claims by misreading page boilerplate as live status
    • Haiku がページのテンプレート文言を「このページ固有の事実」として要約してしまう問題。呼び出し側の Opus/Sonnet からは「literal な抽出」か「model の解釈」か区別できないまま事実として扱われてしまう。まさにこの記事のテーマ「要約されていることに気づかない構造」の典型例
  • #52799 WebFetch summarizer emits <system-reminder> blocks in tool output
    • Haiku の要約が <system-reminder> タグを勝手に出力してしまい、呼び出し側のエージェントが本物のハーネス指示と区別できなくなる問題。セキュリティ的にもヤバい（中身より「チャネル自体」の問題）
  • #47628 [DOCS] WebFetch docs omit HTML preprocessing and style/script stripping behavior
    • 公式ドキュメントに「HTML の前処理（<style>/<script> 除去など）」の記載がない。CHANGELOG にしか書かれていないので、挙動を理解するためには CHANGELOG を遡るしかない、という不透明性問題
  • #51783 [DOCS] WebFetch docs missing large-HTML truncation behavior
    • 同じく、巨大 HTML の truncate 挙動が公式ドキュメントに書かれていない。ユーザーが「最後まで読まれた」と誤認する構造に直結
  • #28392 [BUG] WebFetch returns raw page content instead of processing prompt（CLOSED）
    • 「プロンプトを無視して原文がそのまま返ってくる」というバグ報告。自動クローズされているが、実はこれが今では「信頼サイト + Markdown + 10 万文字未満」のバイパス機能として正式に実装された挙動。"バグ" から "機能" へ変遷した経緯を示す歴史的なチケット

参考: このテーマについて検証・議論している英語記事

GitHubで編集を提案

Discussion