Web Fetch
URL が既に分かっているページの全文をモデルに渡します。ツールエントリを 1 つ追加すれば、Synthorai がページを取得して整形し、読みやすい本文を会話に入れます——どのモデルでも、どのチャネル経由でも。
最小リクエスト
/v1/messages の tools に synthorai:web_fetch を追加します。他は何も変わりません:
curl https://synthorai.io/v1/messages \
-H "x-api-key: $YOUR_KEY" \
-H "content-type: application/json" \
-d '{
"model": "claude-sonnet-4-6",
"max_tokens": 1024,
"tools": [{"type": "synthorai:web_fetch"}],
"messages": [
{"role": "user", "content": "Summarise https://docs.anthropic.com/en/docs/build-with-claude/tool-use"}
]
}'ページが取得されるのは、モデルが必要と判断し、かつ synthorai:web_fetch を含めていた場合のみです。ツールなしのリクエストは通常のリクエストで、挙動にも費用にも影響ゼロです。
オプション
synthorai:web_fetch エントリのフィールドはすべて省略可能です:
| パラメータ | 説明 |
|---|---|
max_uses | 1 リクエストで取得する最大ページ数。デフォルト 3、上限 10。これは支出上限であるためリトライをまたいで強制されます——max_uses: 1 を宣言したリクエストは、チャネルをまたいでリトライされても最大 1 フェッチ分しか課金されません。 |
{
"type": "synthorai:web_fetch",
"max_uses": 2
}Web Search との併用
検索はページを見つけ、フェッチはページを読みます。両方を宣言すると、モデルは検索して有望な結果を選び、ページ全体を取り込めます——リサーチ型の質問ではたいていそれが望みの動作です:
"tools": [
{"type": "synthorai:web_search"},
{"type": "synthorai:web_fetch"}
]レスポンスの形
各フェッチは assistant ターンにブロックのペアとして現れ、その後にモデルの回答が続きます:
{
"type": "server_tool_use",
"id": "srvtoolu_synth_...",
"name": "web_fetch",
"input": { "url": "https://example.com/page" }
},
{
"type": "web_fetch_tool_result",
"tool_use_id": "srvtoolu_synth_...",
"content": {
"type": "web_fetch_result",
"url": "https://example.com/page",
"title": "Example page",
"content": { "type": "text", "text": "…page body…" }
}
}フェッチ回数は usage で報告されるため、料金をご自身で突合できます:
"usage": {
"input_tokens": 9241,
"output_tokens": 412,
"cache_read_input_tokens": 0,
"cache_creation_input_tokens": 0,
"server_tool_use": { "web_fetch_requests": 1 }
}課金
| 項目 | 料金 |
|---|---|
| 取得ページごと | $0.01 / フェッチ |
| トークン(プロンプト + 補完) | 使用モデルの標準 input 単価 |
フェッチごとの料金は費用の全体ではありません。取得したページは入力トークンとして会話に入り、長い記事は数千トークンになることもあります——ほとんどのモデルでそのトークン費用は $0.01 の料金を上回ります。両方を予算に入れてください。
予測可能に保つ 3 つの方法:
max_usesをタスクに必要な最小値に設定してください——リトライ込みで、リクエスト全体の料金上限になります。- モデルに探索させるのではなく、特定のページを取得させてください。ユーザーが貼った URL は 1 フェッチですが、「トピックの周辺を読む」は 3 フェッチになり得ます。
usage.server_tool_use.web_fetch_requestsとusage.input_tokensをセットで監視してください——お金が消えるのはたいてい後者です。
制限と安全性
- 取得されるのは
httpとhttpsの URL のみです。認証情報が埋め込まれた URL は却下されます。 - プライベート、ループバック、リンクローカル、クラウドメタデータのアドレスは拒否されます——web_fetch が到達するのは公開ページのみです。
- ページ本文は会話に入る前に設定された文字数上限で切り詰められるため、巨大なページ 1 枚が 1 リクエストを際限なく膨らませることはできません。
- 取得できなかったページはリクエスト全体を失敗させず、エラーブロックとして返ります。モデルはそれに反応することも、ページなしで回答することもできます。
synthorai:web_fetchの宣言中は、裸の名前web_fetchが予約されます——その名前で自前のツールを宣言すると、名前を明示した400が返ります。リネームするか、synthorai:パラメータを外してください。- 当社ネットワークを出る前に拒否したフェッチ——却下 URL、ブロック対象ドメイン、未設定バックエンド——は課金されません。プロバイダーに到達してそこで失敗したフェッチは、プロバイダーが当社に課金するため課金されます。どちらも
max_usesにはカウントされます。
取得するものへのお客様の責任
web_fetch はお客様の指示でページを取得します。どの URL を取得するかを決めるのはお客様であり、その取得と、返ってきたものの扱いはお客様の責任です。
- コンテンツへのアクセス権はお客様が持っていなければなりません。対象サイトの利用規約、
robots.txt、ペイウォールやログイン境界、適用される著作権およびデータベース権を含みます。当社経由のフェッチが、本来持っていないアクセス権を与えることはありません。 - 個人データはお客様の義務のままです。取得したページに個人情報が含まれる場合、GDPR、PIPL および同等の制度の下でお客様がその管理者であり続けます——法的根拠、保持、消去要求への対応を含めて。
- フェッチに起因する請求はお客様のものです。取得したコンテンツについて権利者やサイト運営者が申し立てを行った場合、その申し立てはお客様に向けられ、費用はお客様が負担します。これは当社が経由する上流取得プロバイダーの規約と同じ構造です。
- モデル出力は再利用が許可されたものではありません。取得素材に基づくモデルの回答は、その一部を再現することがあります。その出力を再公開できるかどうかはソースのライセンスの問題であり、当社は何の表明もしません。
当社が負うこと:取得インフラの運用、内部・プライベートネットワークアドレスのブロック、管理者が設定したドメインブロックリストの尊重、リクエスト処理を超えた取得ページ内容の非保持。個別 URL の適法性は審査しませんし、できません——URL 単体はライセンスを運びません。
信頼できる不正利用の報告を受けた、または取得プロバイダーがフラグを立てた API キーの web_fetch は停止します。プロバイダーアカウントが停止されると、全顧客の機能が道連れになるためです。
FAQ
言及していないページをモデルが取得することはありますか?
同じ会話の中で synthorai:web_search で見つけた URL をたどることはできます。それこそが 2 つを組み合わせる意味です。URL をでっち上げないよう指示されており、ページを探す必要があるならまず検索すべきです。
ページがログインの内側にある、あるいはクローラーをブロックしている場合はどうなりますか?
そのフェッチについてはエラーブロックが返り、モデルはページなしで続行します。リクエストは実際にお客様に代わって行われたため、フェッチは max_uses にカウントされます。
ページを取得しなかった場合、ツールの宣言は何かを変えますか?
いいえ。モデルが実際に何かを取得するまで、課金も挙動も通常のリクエストと同一です。