AIエージェントのWeb読み取りは、速さとコストの両方がボトルネックになりやすい領域です。
2026年6月30日、Nous ResearchはHermes Agentのweb_extractを刷新し、最大60倍の高速化と49分の1のコスト削減を公表しました。スクレイピングバックエンドが返すクリーンなMarkdownをそのままエージェントへ渡し、長大ページはローカル保存とオンデマンド読み込みで扱う設計に切り替わっています。変更はv0.18.0（v2026.7.1、2026年7月1日リリース）に含まれ、独立メディアthehype.によるOpenClawとの比較検証も公開されています。
この記事では、公式発表とGitHub上の実装変更を軸に、何がどう変わったのかを整理します。
この記事でわかること
web_extractの旧仕様が遅く高コストだった理由- truncate-and-store方式への変更内容と数値根拠
- 長大ページのローカル保存と
read_fileによるページング - 利用者が設定できる
web.extract_char_limitの意味
課題は「すでにきれいなMarkdownをLLMで再要約していた」点
Hermes Agentは、オープンソースの自律型AIエージェントです。Web関連ではweb_search（検索）とweb_extract（URLから本文取得）の2ツールを備え、Firecrawl・Tavily・Exa・Parallelなど複数のバックエンドに対応します（参考）。
旧仕様では、バックエンドが返したMarkdownが5,000文字を超えると、補助モデル（auxiliary model）が要約処理を実行していました。5,000〜500,000文字は単一要約、500,000〜2,000,000文字は100,000文字単位のチャンク分割と並列要約、さらに最終合成という多段パイプラインです。Firecrawlなどのバックエンドは、すでにボイラープレートを除去したMarkdownを返すのに、ネットワーク取得のあとにLLMラウンドトリップが直列で乗っていました。
Nous Researchの公式投稿は、この冗長な処理を廃止した点を強調しています。「スクレイピングバックエンドがクリーンなコンテンツをエージェントへ直接渡す」「大きなページはローカル保存し、必要に応じてページングする」と説明されています（参考）。
変更の中身：truncate-and-store方式
中核の実装変更は、GitHubのPull Request #54843「truncate-and-store instead of LLM summarization」です。2026年6月29日にマージされ、v0.18.0へ取り込まれました（参考）。
新方式の動作は次のとおりです。
- 文字数が
web.extract_char_limit（デフォルト15,000文字）以内のページは全文をそのまま返す - それを超えるページは先頭と末尾のウィンドウ（おおよそ75%／25%、行境界でスナップ）を返し、省略された中間部分のフッターにフルテキストの保存パスと
read_fileの呼び出し例を記載する - フルテキストは
cache/web/配下にMarkdownとして保存される
LLMによる要約パス（process_content_with_llm、チャンク分割要約など）は削除され、画像のbase64埋め込みは[IMAGE: alt]プレースホルダへ変換してトークン爆発を防ぎます。web_search側はもともとLLM不要のため、変更対象はweb_extractに限定されています。
数値はどこまで信じられるか
Nous Researchの公式X投稿は「最大60倍高速、49倍安価（49x cheaper）」としています。PR #54843の開発者ベンチマークは、Firecrawlバックエンドで4 URLを計測し、合計176.6秒から15.1秒へ短縮（11.7倍）と報告しています。個別ではPEP 8ページで59.7倍、Wikipedia Transformer記事で10.6倍の高速化が記録されています。
コスト面では、同じ4ページのテストで旧方式（Opus 4.xを補助モデルに使用）が合計2.80ドル、新方式が0.12ドルとなり、約23倍の削減です。大きな1ページだけでも、旧方式は要約だけで約1.43ドルのモデルコストが発生し、新方式はスクレイプ料金のみとなります。補助モデルを安価なFlash系にしてもLLMコストは残りますが、truncate-and-storeはLLMコスト自体をゼロにします。
品質検証では、返却コンテンツ内に既知の答えが含まれるかを確認し、旧新とも3/4で一致。切り詰められたページは保存ファイルから4/4で回答を回収できたと報告されています。公式の「60倍」「49倍」は最大値・条件依存の主張であり、PRの実測は保守的な下限に近い数値と読み分けるのが妥当です。
thehype.は2026年7月1日、HermesとOpenClawのweb_extractを正面から比較する検証を公開しました。「スクレイピングバックエンドがクリーンなコンテンツを直接渡し、大きなページを冗長処理なしで扱う」という主張を検証対象に挙げています（参考）。第三者による実運用比較として、公式数値の補強材料になります。
コミュニティレビュアーのkshitijk4poor氏は、Exaバックエンドで4ページを再現し、truncate-store方式が1.82秒、旧LLM要約（Gemini Flash）が32.4秒、Opus級デフォルトが67.2秒と報告しています（参考）。
長大ページの扱い方が変わる
旧仕様では、500,000文字超のページはチャンク要約のあと約5,000文字に圧縮されていました。情報の取りこぼしを避けたい用途ではbrowser_navigateへの切り替えが推奨されていました。
新仕様では、切り詰めたレスポンスに保存パスとread_file path=… offset=… limit=…のヒントが付きます。エージェントは必要な区間だけ追加読み込みできます。全文はcache/web/に残るため、要約で失われがちなコードブロックや引用も、ファイル経由で追跡可能です。リモート実行環境（Docker／Modal／SSH）でもcache/webは読み取り専用マウント対象に追加され、クラウド上のエージェントから同じパスでアクセスできます。
一方、保存ファイルのサイズ上限やキャッシュの自動削除はPR時点では未実装で、コミュニティからは2MB上限の復活やTTL付きエビクションの提案が出ています。巨大ページを連続処理する運用では、ディスク使用量に注意が必要です。
設定とバックエンドの組み合わせ
web.extract_char_limitは~/.hermes/config.yamlで変更できます。デフォルト15,000文字を超えると切り詰めが始まります。検索と抽出は別バックエンドを指定できるため、SearXNG（無料・検索専用）とFirecrawl（抽出）の組み合わせのような構成も引き続き有効です。
Firecrawlはデフォルトバックエンドで、月500クレジットの無料枠があります。JavaScriptレンダリングが必要なページでも、APIキー設定後はブラウザレンダリング経由でMarkdown化されます（参考）。今回の変更はバックエンドの選択肢を増やすものではなく、取得後の処理パイプラインを軽量化するものです。
補助モデルのauxiliary.web_extract設定は、要約パス廃止により主目的が変わりました。旧ドキュメントが説明していた「長文要約を安価なFlashモデルへルーティング」は、新方式では不要です。代わりに、切り詰め閾値とread_fileによる追読の使い分けが実務上のポイントになります。
v0.18.0への取り込みと他機能との関係
この変更はHermes Agent v0.18.0「The Judgment Release」（2026年7月1日）の一部です。同リリースではMixture-of-Agentsのモデル選択統合、作業検証のcompletion contracts、/learnスキル蒸留など大規模な更新が含まれますが、web_extractのtruncate-and-storeはエージェントの情報収集コストに直結する変更です（参考）。
PR #55207では、@-参照展開の並列化とtruncate-storeの堅牢化が追加され、複数URLを同時に参照するワークフローでも恩恵が広がります。Firecrawlバックエンド側の複数URL並列取得（#47611）とは別レイヤーの最適化であり、両方が揃うと取得段階と後処理段階の双方で高速化が重なる、とコミュニティでは整理されています。
使い分けの指針
単純なドキュメントやAPI仕様の取得にはweb_extractが最適です。公式ツールリファレンスでも、ログインやフォーム操作が不要な情報取得ではbrowser_navigateよりweb_extractを優先するよう記載されています（参考）。
JavaScript操作が必須なサイト、Cookie同意クリック後にしか表示されないコンテンツ、スクリーンショットが必要な場面では、引き続きブラウザツールが必要です。切り詰められたレスポンスでは中間部分が省略されるため、構造化データの全フィールドが必要なスクレイピングでは、フッターが示すread_fileで追読するか、より細かいURLへ分割して抽出する運用が有効です。
Hermes AgentをWebリサーチのバックエンドに使っている開発者にとって、今回の更新は「毎回LLMに要約させていた無駄」を取り除く実務的な改善です。公式の60倍・49分の1という数字は条件次第の上限値ですが、LLM要約の廃止という設計転換自体は、エージェントのWeb利用コストを構造的に下げる変更と言えます。