Hakaru Lab ｜ 公開: 2026-09-03 ｜ 検証記事
対象読者：AIエージェントにWebページを読み込ませたい個人開発者・小規模チームの実務担当者、およびこの種のツールを比較検討している情報収集中の人。向く人は、タグや装飾スクリプトで肥大化した重いページの本文をAIへ渡す前処理を減らしたい人。向かない人は、表形式データを厳密に読み取りたい人や、作業時間の短縮・料金への影響そのものを知りたい人——本記事はAIへの入力分量（トークン数）の実測にとどまり、それらは確認していません。「無料で試せる」ことと「導入すれば成果が出る」ことは別であり、本記事は後者を保証するものではありません。
3行要点
・AIエージェント向けにWebページを圧縮して返す「Opera Browser CLI」について、生HTML・既定出力・`--full`出力の3系統でトークン数を実測したところ、軽いページでは削減率10.5%にとどまる一方、重いページでは`--full`使用時にトークン基準81.3〜94.9%の削減を確認した。あわせて、既定設定のまま使うと12,000文字の上限で本文が途中欠落する場合があることも確認した。
・AIエージェントにWebページを読み込ませる機会が多い個人開発者・小規模チームの実務担当者が、既定出力のまま使うか`--full`オプションを使うかを判断する材料になる。表形式データを厳密に読み取りたい用途や、既に軽量なページの圧縮が目的の用途には向かない。
・結果は当ラボが選んだ4ページ（自サイト記事1件・GitHub/note.com/Rewardfulの重量ページ3件）における各条件N=1の実測値であり、提供元公表値（66%・80%）とは比較対象が異なる。検証日は2026年8月30日、対象は`opera-browser-cli` 0.1.49。
検証の前提
・検証日：2026-08-30
・利害関係：広告リンクなし（Operaのアフィリエイトプログラムには不参加）
本記事は当ラボの実測レビューシリーズの第1弾です。現時点でOperaのアフィリエイトプログラムには参加しておらず、本文に広告リンクはありません。
AIエージェントにWeb調査をさせる場面が増えると、ページのHTMLをそのまま読み込ませるやり方は、AIに渡す分量（コンテキスト）が大きくなりがちです。渡す分量が膨らめば、大事な情報が埋もれて見落とされたりする可能性があります。Opera社が配布する「Opera Browser CLI」は、AIエージェントがブラウザ経由でページを取得する際に、内容を圧縮した形で返すツールです。うまく使えば、AIに渡すページの分量を大きく減らせる可能性がありますが、既定設定のまま使うと本文の一部が欠けたまま渡ってしまう注意点もあります。当ラボで実際にトークン数を測り、効果と注意点の両方を確かめました。なお、本記事で測定したのはAIに渡す入力分量の代理指標であり、実際の利用料金・作業全体のコスト・タスクの成功率については測定していません。
まず用語を整理します。
Opera Browser CLIは、npm（Node.jsのパッケージ配布サービス）で公式配布されているコマンドラインツールです。`open`（ページを開く）や`snapshot`（現在のページ状態を取得する）といったコマンド一つで、ヘッドレスブラウザ経由でページ情報をAIが読みやすい形に圧縮して返します。基本のブラウズ・抽出系コマンドはOpera Neon本体がなくても動く設計に見えましたが、`invoke-do`や`research`といった上位のAI機能はOpera Neon本体とサインインが前提で、今回は未検証です。
Opera Browser CLIだけを見て効果を語る前に、似た目的で使われる主なツールとの位置関係を整理しておきます。以下は各ツールの公式情報にもとづく構造比較で、実測ではありません。
| ツール | 主目的 | 実行場所とデータ経路 | 費用 | 向く用途 | 非選定理由 |
|---|---|---|---|---|---|
| Opera Browser CLI（GitHub） | ページ取得とAI向けの圧縮出力 | ローカルのヘッドレスブラウザ（既存Chromeを再利用）を直接操作。取得したページを外部サーバーに送信しない | 基本コマンドは無料。Opera Neon本体の上位AI機能のみ有料プラン＋サインインが必要 | 既にあるローカルブラウザを操作しながら、圧縮済みの本文をそのまま得たい場合 | （今回の選定対象） |
| Jina Reader（GitHub） | 単一URLのMarkdown化 | クラウドAPI（`r.jina.ai`へ対象URLを送信） | 無料枠＋従量課金、レート制限あり | curlなどからの単発取得・手軽なMarkdown化 | 外部クラウドへの送信が前提でローカル完結ではなく、継続的な操作は主眼外 |
| Firecrawl（公式ドキュメント） | scrape／crawl／構造化抽出 | クラウドAPI（セルフホストも選択可）、対象サイトを外部経由で取得 | 従量課金（無料枠あり） | サイト全体のクロールや構造化データの抽出 | 単一ページの圧縮検証には範囲が広すぎ、クラウド経路が前提になりやすい |
| Cloudflare Browser Run（公式ドキュメント） | リモートChromeを使ったブラウザ実行基盤 | Cloudflare Workers上のリモートブラウザ（エッジ側で実行） | Workersの従量課金 | 高並列・遠隔実行が必要な自社基盤への組み込み | Workerの実装が別途必要で、ローカル圧縮CLIとしての単純比較にならない |
| Playwright CLI／MCP（公式ドキュメント） | 状態を保った継続的なブラウザ操作・自動テスト | ローカル（またはCI）のヘッドレスブラウザを直接操作 | OSS・無料 | クリックやフォーム入力など、複数手順の操作をAIエージェントに繋ぐ場合 | 本文取得の圧縮出力そのものが主目的ではなく、今回は実測比較の対象外とした |
上表は公開情報にもとづく構造比較（2026年8月31日確認）です。実測比較は別記事で扱います。
Opera Browser CLIを選んだ理由は、既にあるローカルブラウザを操作しながら、出力を小さくできるという仮説を測るためです。他ツールに対する総合的な優位性を主張するものではありません。
Opera公式のリソースページには、次のような試験結果が示されています（出典）。
この66%と80%は、同じレンジに収まる幅のある数字ではありません。前者は「圧縮なしの生出力」との比較、後者は「MCP経由の標準的な取得方法」との比較であり、比較対象が異なる別々の基準への2つの値です。両者を並べて「66〜80%のレンジ」と表現するのは正確ではないため、本稿ではこの2値を区別して扱います。
試験条件は、AXI（Agent eXperience Interface、AI向けのCLI設計原則）にもとづく`bench-browser`スイートから採用した7つのブラウザ課題を、1条件につき7課題×各5回=35試行、これを`opera-compact`・`opera-raw`・`mcp-raw`などの4つの条件で実施し、合計140試行としたものです（技術資料）。提供元ページ自身も「1つのモデルと、かなり限定された7課題」による試験である点を明記しており、対象は主にGitHub・MDN・Wikipediaのような文書中心ページだったとしています。
基本機能は、2026年8月14日の発表でOpera Neon無料プランとCLI接続が購読なしで利用できるようになったと案内されています（発表）。自律ブラウジングなどNeon独自のAI機能のみ、引き続き有料プランとサインインが必要という構造です。
提供元の試験は文書中心ページに限られていたため、当ラボでは対象を広げ、実務でAIに読ませる機会が多そうな4ページで実測しました。
比較したのは次の3系統の出力です。
重要な注記（読者が抱きやすい疑問への補足）: 本記事の数値は固定コマンドの出力を機械計数したもので、実行エージェントのモデルやエフォートは数値そのものを左右する要因ではなく、誰が作業したかを示すだけの記録（来歴情報）です。再現に重要なのはコマンド・対象URL・計数方法です。
非公開事項（セキュリティ上の理由による伏せ字であり、問題が起きたわけではありません）: 内部の保存パスや認証情報などは本稿では伏せていますが、計測結果・再現性には影響しません。
まずバイト数（`wc -c`）を比較しましたが、AIが実際に処理する負荷はバイト数ではなくトークン数で決まるため、実トークン数でも測り直しました。トークンの換算にはtiktoken（OpenAI公式のPython製トークナイザーライブラリ）の`o200k_base`エンコーディング（GPT-4o系列が使用する語彙表。トークン計数の限界についての解説も参照）を使っています。Claudeでの実使用トークン数は直接計測していないため、本測定はo200k_base換算による代理指標であり、Claudeでの実際のトークン数と厳密には一致しない点にご留意ください。他に公開された同等の参照点が無いため、この換算器を採用しました。
4ページとも同一セッション内で「生HTML→既定出力→`--full`出力」の順に、各条件1回ずつ連続取得し、各ファイルを保存してから`tiktoken`でバイト数・トークン数を機械計測しました。実行環境には既にGoogle Chromeが入っており、今回はその既存バイナリを再利用したヘッドレス起動でした。Chromium系ブラウザが何も無い環境での新規ダウンロードの挙動は未確認です。取得した生HTML・既定出力・`--full`出力の各ファイルはすべて当ラボ内で保存しており、あとから照合できます。下表の「本文の読めぐあい」は、生HTMLの主要な見出し・本文セクションが各出力にも含まれているかを目視で確認して判定したものです。
なお本測定は、提供元が示す66%・80%というトークン削減率の独立追試ではありません。提供元の試験は同一課題・同一モデルでの比較実験ですが、当ラボの測定は実際の4つのWebページを対象にした出力量の実測であり、比較の条件そのものが異なります。
| 対象ページ | 生HTML（bytes / tokens） | 既定出力（bytes / tokens、バイト削減率／トークン削減率） | `--full`出力（bytes / tokens、バイト削減率／トークン削減率） | 本文の読めぐあい |
|---|---|---|---|---|
| 自サイト記事（軽量・静的ページ） | 17,352 / 4,922 | 15,817 / 4,406（8.8%減／10.5%減） | 15,817 / 4,406（既定と同一。打ち切りなし） | 問題なく読める |
| GitHub README（apify/mcpc） | 732,874 / 277,950 | 11,596 / 3,574（98.4%減／98.7%減） | 139,562 / 39,089（81.0%減／85.9%減） | 既定は本文欠落・`--full`で読める |
| note.com記事 | 356,655 / 116,638 | 17,122 / 5,350（95.2%減／95.4%減） | 19,149 / 5,955（94.6%減／94.9%減） | 既定のままで読める |
| Rewardfulレポート | 141,341 / 51,931 | 12,313 / 2,970（91.3%減／94.3%減） | 40,722 / 9,726（71.2%減／81.3%減） | 既定で読めるが表は直列化 |
測定日時: 2026年8月30日23:50〜23:58頃（JST）。トークン数は`tiktoken` o200k_baseエンコーディングによる換算値。
自サイトのような元々軽いページでは、トークン基準の削減率は10.5%（バイト基準では8.8%）にとどまりました。これは対象ページのインラインCSSが858文字・JSが255文字しかない、削るべき「贅肉」がほとんど無いページだったためです。一方、今回測定したGitHub・note.com・Rewardfulの3ページでは、`--full`ベースでトークン基準81.3〜94.9%（バイト基準では71.2〜94.6%）の削減となりました。今回測定した8パターン（4ページ×既定/`--full`）すべてで、トークン基準の削減率はバイト基準と同じかそれを上回りました。この傾向は、生HTMLがタグや属性を含むぶん1バイトあたりのトークン数が相対的に高く、Operaが返す読みやすいテキストはトークン密度が下がるためではないかと考えられますが、この因果関係自体は今回個別に検証したものではありません。少なくとも、バイト数だけを見た数字は実際の効果をむしろ控えめに示す方向だった、という今回の観測結果は確かです。
ここで確認できたのは、あくまで当ラボが選んだ4ページでの出力量の実測値です。提供元が示す66%・80%という別基準の数値と、そのまま並べて比較できるものではありません。
今回の測定でもっとも注意が必要だと感じたのは、削減率そのものより「既定出力の文字数上限」でした。
Opera Browser CLIの既定出力には12,000文字の上限があり、これを超えるページでは本文が途中で打ち切られます。GitHubのREADMEページを既定のまま取得すると、トークン数だけ見れば277,950から3,574への98.7%減という、際立って大きな数字が出ます。しかし実際の中身を確認すると、取得できていたのはナビゲーションとファイル一覧までで、README本文の核心にあたるMotivationやUsageのセクションが欠落していました。
ツール自体は、この打ち切りが起きたときに`(truncated, N chars total)`という注記を出力に添えます。危険なのはツールが何も知らせないことではなく、この注記をAIエージェント側が見落とし、あるいは無視したまま「ページは読めた」と判断して作業を進めてしまうことです。`--full`で取得し直すと、GitHubの例では39,089トークン・85.9%減となり、上限による打ち切りが解消して、確認対象としていたMotivation・Usageのセクションを読める内容になりました。note.comとRewardfulの例では既定出力のままでも本文の骨子は読めており、打ち切られていたのは埋め込み動画や関連リンクなど周辺部分にとどまっていました。
ここから得られる実務上の対処は明確です。削減率が極端に高い結果を見たときは、まず何が削られたのかを確認することが大切です。運用ルールとして、出力に`(truncated, N chars total)`の表示を見つけたら`--full`で再取得する手順を組み込んでおくと、この見落としを防げます。
今回の観測で興味深かったのは、打ち切りが起きた場所です。note.comとRewardfulの例では、既定出力のままでも本文の骨子は読めており、削られていたのは埋め込み動画や関連リンクといった周辺部分にとどまっていました。ここから浮かぶのは、AIエージェントがWebページを読み取る環境では、動画や装飾的な埋め込みだけに情報を頼る構成よりも、テキストを主体にし、要旨・数値・字幕などを本文中に文字として併記しておく構成の方が、打ち切りの影響を受けにくく拾われやすいのではないか、という仮説です。ただしこれはあくまで今回の4ページの観測から浮かんだ仮説であり、AI検索全般での効果は測定していません。
向いていると感じた用途
向いていないと感じた用途、あるいは注意が必要な用途
採用（当ラボの決定）
当ラボは2026年9月1日から、巡回・調査業務で重い公開文書の本文をAIへ渡す前処理として、Opera Browser CLI（0.1.x）を限定試験採用します。条件は、`(truncated, N chars total)`という打ち切りの注記を検知した場合に、`--full`で自動的に再取得することです。表の厳密な読み取りが必要な用途、既に軽量なページ、Opera Neonの有料機能には使いません。4週間後に、この間の実測ログをもとに再評価します。
読者への推奨（2026年8月31日時点）
対象は、GitHubのREADMEやnote.com記事のような重いWebページの本文を、AIエージェントに読ませる機会が多い個人開発者・小規模チームの実務担当者です。この読者層には、当ラボが確認した条件——`(truncated, N chars total)`の検知時に`--full`で再取得する運用ルールをセットで組み込むこと——を前提に、試す価値があると考えます。ただし、表形式データを厳密に読み取りたい用途や、既に軽量なページの圧縮が目的の用途には、まだ薦められません。この推奨は2026年8月31日時点の当ラボの実測にもとづくものであり、ツールの仕様変更やバージョンアップによって前提が変わる可能性があります。