AIエージェントにURLを渡して「このページを読んで」と頼む。
よくある使い方です。
ただ、その裏で何万トークンが流れているか。
そこまでは、あまり意識しませんよね。
Claude 関連のサブレディットで、only-cli（コマンド名は oc）というツールの紹介投稿を見かけました。
どんなサイトでもエージェント向けの小さなCLIに変える。
そういう触れ込みです。
数字のインパクトが強く、コメント欄には鋭い突っ込みも並んでいました。
この記事は、その投稿とコメントを読んで整理したものです。
数字はすべて投稿者の主張として読んでください。
投稿された数字
作者が挙げた測定結果は、こうです。
実在する15ページを対象にしています。
生のHTMLなら、合計1,552,491トークン。
ところが oc なら、10,936トークンで読めた。
比率にして、およそ142分の1です。
コスト比較もありました。
Wikipedia を対象にした5問の調べ物です。
Claude Code 標準の WebSearch が0.52ドル。
一方、oc は0.27ドルでした。
プログラミング言語のドキュメントを引く11問でも、結果を出しています。
WebFetch より23%、WebSearch より35%安い。
しかも正答率は同等以上だった、としています。
加えて、読み取りを弾いてくるサイトについても触れていました。
Reddit や LinkedIn、Yahoo Finance、DuckDuckGo。
これらでも中身を返せた、という主張です。
コメントの一つが、この数字をうまく言い表しています。
155万トークン分のHTMLを1万トークンで読む。
Webにようやく請求書が届いた。
そんな趣旨でした。
仕組みは意外なほど素朴
作者の説明によると、ヘッドレスブラウザは動かしません。
curl のようなGETリクエストを投げます。
そして、返ってきたHTMLからタグを削り、Markdownに変換する。
基本はそれだけです。
ブロックされやすいサイトには、別の手を用意しています。
サイトごとの設定ファイル（例：reddit.com.json）を置いて抜けています。
読ませ方にも工夫がありました。
ページ全体をどさっと渡すわけではありません。
およそ500トークンの番号付きビューとして見せます。
エージェントは do 12 や find、next で移動する。
つまり、読んだ分だけ払う形です。
だから、ページを取り直さずに済みます。
他のツールとどう違うのか
コメント欄では、比較の質問が続きました。
まず crawl4ai について。
作者は、役割が違うので補完関係になると答えています。
crawl4ai はヘッドレスブラウザとJS描画を備えたクロール基盤です。
ページ全体をMarkdownで返します。
RAG向けのデータ取り込みには向く。
ただし、1ページあたり数千トークンかかります。
対する oc は、エージェントが作業中に調べ物をする経路だけに絞った道具。
そういう整理でした。
r.jina.ai との違いも聞かれています。
作者は、jina が実際のブラウザを動かしているはずだと前置きしました。
そのうえで、oc はローカルで完結する小さなプロジェクトだと答えています。
Firecrawl との比較でも、軽量でサービスに依存しない点を挙げていました。
ここで一人が、厳しい指摘を入れます。
curlでMarkdownに変換するだけでは限界がある。
trafilatura のような本文抽出ライブラリのほうが仕事は上だ、と。
作者は反論しませんでした。
狙いはトークン削減と403回避にある、と答えています。
別のコメントが、実感を添えていました。
curlからMarkdownに変換しただけでは、ナビゲーションが残る。
すると、エージェントが同じページを何度も取り直した。
本文抽出を一段かませて、ようやく止まったそうです。
ブラウザ操作系の OpenCLI との比較も出ました。
OpenCLI は拡張機能から実際のChromeを動かします。
だからクリックも入力もできて、ログイン状態をそのまま引き継げる。
読むだけなら oc、操作させたいなら OpenCLI。
両方入れるのは重複で過剰だ、というのが作者の回答でした。
一番鋭かったのは「静かに欠ける」という指摘
議論で最も本質的だったのは、精度そのものではありません。
失敗の見え方でした。
1ページ平均729トークン。
ドキュメント1つ分のコード例より小さい数字です。
ここまで削るなら、何が落ちたのかも併記すべきだ。
そういう声が上がりました。
問題は、こうです。
エージェントには、次の二つを区別できません。
- ページにそもそも書かれていなかった
- 読み取りツールが返さなかった
ドキュメントでこれが効いてくるのは、タブや折りたたみ、バージョン切り替えの内側です。
パッケージマネージャごとのインストール手順が、タブに隠れているとします。
すると、残った側だけが自信満々の答えになる。
実際にコマンドを叩くまで、誰も間違いに気づけません。
作者の回答は誠実でした。
ベンチマークの採点は、1問につき1つの事実です。
間違えた場合も、見つけられなかった場合も、同じく不正解になります。
ただし11問の事実は、すべて平文の中にありました。
つまり、タブや折りたたみの裏は検証範囲に入っていません。
そのうえで、限界も認めています。
oc は hidden や aria-hidden の付いた要素を落とす。
しかも oc raw でも同じく落ちるので、逃げ道がありません。
ブロック回避は必ず古びる
もう一つ、運用面の指摘がありました。
Reddit のようなサイトは、UA文字列では判定しません。
クライアントの指紋（ブラウザーフィンガープリント）で弾いてきます。
ブラウザのUAを付けた素のcurlでも、403。
ヘッドレスブラウザには、チャレンジが飛びます。
つまり、今日動いている方法は特定の抜け道に依存しています。
そして抜け道が塞がれたとき、多くの場合エラーは返りません。
薄い内容や空の本文が返るだけです。
例外が飛ばないので、コードでは捕まえられない。
気づくのは、エージェントが半分のページから静かに推論した結果を眺めたときになります。
対策として挙がったのが、カナリア検査でした。
自分が管理しているページや、滅多に変わらないページを少数選ぶ。
それを定期的に取得して、既知の文字列が今も出てくるか確かめます。
壊れたことを外側から検知する仕組みを、別に持つという発想です。
似た趣旨の質問も出ていました。
きれいな取得失敗より、怖い状況がある。
もっともらしいのに、不完全な内容が返るケースです。
Reddit や LinkedIn、Yahoo Finance について回帰テストはあるのか、と聞かれました。
作者は、ベンチマーク用のリポジトリを公開していると答えています。
15のURLを Claude と Codex で走らせているそうです。
ただし、プロジェクトをまたいで何度も回すと費用がかさむ、とも書いていました。
失敗したときもトークンは減る
素朴な疑問も出ていました。
動かないページに当たったら、トークンは消費されるのか。
それとも、事前に教えてくれるのか。
答えは前者でした。
ブロックされているかどうかを確かめるため、まず取りに行きます。
ここは Claude の標準動作と変わりません。
回避策はコミュニティからの報告に頼っている。
それが現状のようです。
そもそもサイト側が出せばいい、という視点
エージェントから呼ばれるサーバ側を運用している人の意見も、混じっていました。
人間の目のために作られた文書を、機械に解析させる。
それより、最初から構造化されたビューを配ったほうがいい。
送る側も受け取る側も、安く済むからです。
今回の数字は、その主張を裏づける材料として読める。
HTMLをリバースエンジニアリングさせる状態を放置せず、サイト自身が機械向けの入口を用意すればいい。
そういう意見でした。
言われてみると、142分の1という数字の見え方が変わります。
ツールの性能というより、Webが抱えている無駄の大きさを映しているのかもしれません。
この投稿から持ち帰れること
コメントが30件を超えた時点で、自動生成のまとめがスレッドに投稿されていました。
要点は、次の三つです。
- 読むための道具であって、操作するための道具ではない
- 隠れたコンテンツは落ちる可能性があり、エージェントはそれに気づけない
- 重量級のフレームワークに対する、軽量な選択肢として見るべき
道具の選び方として、覚えておくと役に立つ点が二つあります。
一つは、読むのか操作するのかを最初に決めること。
フォーム入力やログインが絡むなら、ブラウザを動かす側を選びます。
テキストを拾うだけなら、軽い読み取りで足ります。
もう一つは、抽出結果を無条件に信じないこと。
取得が成功したかどうか。
必要な情報がそこにあるかどうか。
この二つは、別問題です。
重い判断をエージェントに任せるなら、元のページを自分の目で確認する手間は残しておきたいところ。
ちなみに、こんなコメントもありました。
全選択してテキストで保存し、そのファイルをエージェントに読ませている、と。
やっていることの本質は同じです。
ツールはそれを自動化してくれる、と作者は答えていました。
手作業でしのいでいる人が、現にいる。
そのあたりに、この問題の広がりが見えます。
まとめ
only-cli の投稿は、ツールの宣伝として読むより面白い読み方があります。
問題提起として受け取る読み方です。
エージェントにWebを読ませるコストは、想像より大きい。
そして削り方を間違えると、コストではなく正確さのほうが削れます。
142分の1という見出しの数字。
それより、何が落ちたのかを書けという指摘のほうが、実務では効いてくるはずです。
リポジトリは GitHub（github.com/only-cli/oc）で公開されています。
気になった方は、まず自分がよく読むページで試してみてください。
そして、期待した文章が本当に出てくるか確かめてほしいところです。
