Token Optimization - Getting More from Less

トークン最適化 – 少ないリソースでより多くの成果を

昨日は外科的ツール選択によるカスタムエージェント構築法をご紹介しました。本日はさらに深く掘り下げます：トークン最適化。

適切なツールの選択は戦いの半分に過ぎません。真のゲームチェンジャーは、それらのツールが返す結果を最適化することです。出力トークンを40～80%削減しながら最高精度を実現するため、データパイプラインを再設計しました。

その手法を解説します。

問題点：データの肥大化

scrape_as_markdownやsearch_engine といったツールを呼び出すと、API は豊富なデータを返します。しかし問題点は、そのデータの大半が人間向けにフォーマットされており、LLM 向けではないことです。

従来のAPIには不要なオーバーヘッドが含まれています：

LLMが不要とする冗長な書式（太字、斜体、見出し）
広告やスポンサードコンテンツが自然検索結果に混在している
トークンを浪費する画像メタデータや視覚的要素
一貫性のないフィールド名と冗長なメタデータ

典型的なウェブスクレイピングや検索クエリでは、LLMが推論に実際に必要とするデータの3～5倍ものデータが取得されることが多い。

解決策：二層トークン最適化

異なるデータタイプを対象とした階層的最適化戦略を実装しました：

ウェブページコンテンツ向け：Remark + Strip-Markdown（scrape_as_markdown）
検索エンジン結果向け：パース軽量化＋ペイロードクリーニング（search_engine）

各層を分解して説明します。

でも待って―TOONはどうした？

TOON（Token-Oriented Object Notation）はどうなったのか？と疑問に思うかもしれません。当初、LinkedInプロフィールやAmazon商品のような構造化データセット向けの第三の最適化レイヤーとして検討していました。

TOONはインデントと表形式レイアウトでトークン数を削減する巧妙なフォーマットです。理論上、同一オブジェクトの均一な配列では30～60%の削減効果があります。しかしBright Dataの実際のAPIレスポンスでテストした際、重要な事実を発見しました：

ボトルネックは区切り文字ではなく、データそのものにある。

区切り文字の幻想

典型的なLinkedInプロフィールレスポンスを見ると、トークンの大半は以下から発生している：

長いテキストフィールド（about、recommendations、activity[].title）
長いURL（avatar、banner_image、activity[].link、credential_url）

区切り文字（n,|,t）はトークン総数のごく一部です。

改行 (n) は既に:

主要なLLMトークナイザーすべてで単一の非常に一般的なトークン
モデルのテキスト分割方法（行単位）と自然に整合
URLや大半のテキスト内に現れないため、エスケープ処理の問題を回避

|、^、x1Fなどの特殊な区切り文字は一部でクォーティングを減らせる可能性があるが、稀な複数トークン連続を引き起こし、その利点を相殺することが多い。

短答: 区切り文字のみを調整する場合、nはこの種のデータにおいて既に最適な選択肢です。

TOONの弱点

TOONは同一オブジェクトの均一な配列（例：同一スキーマの従業員レコード1,000件）で真価を発揮します。しかしweb_data_linkedin_person_profileやweb_data_amazon_productのような現実のWebデータは：

異種混合型— スキーマが異なるネストされたオブジェクト（経験、学歴、活動配列など）
非均一性— 配列タイプの混在（一部エントリにimgあり、他にはなし）
単一オブジェクト応答— API呼び出しの大半は1,000件ではなく1件のプロファイルや製品を返す

深くネストされた構造や非均一な構造の場合、ミニファイされたJSONはTOONよりも少ないトークンで表現できることが多い。TOON仕様自体もこれを認めており、深いネストを持つ単一オブジェクトでは、コンパクトなJSONよりも多くのトークンを使用する可能性がある。

真の解決策：フォーマットではなく送信内容を変える

重要な洞察はこれだ：フォーマットレベルの最適化（JSON vs TOON vs YAML）は、送信するデータそのものを変えることに比べれば取るに足らない。

当社ツールはBright Data APIの全データを返すため、この手法は適用していません。ただし、ウェブスクレイピング応答で頻繁に発生し、情報増分なしにトークンを浪費するNULL値は除去しています。

要点は：区切り文字の微調整で節約できるのはせいぜい5～10%。コンテンツフィルタリングで20～80%節約可能。TOONは現実のウェブデータにおいて最適化すべき変数を間違えている。

ツールの未成熟性

TOONはまた非常に新しく、仕様への最初のコミットは2024年11月2日です。文字通り1ヶ月しか経っていません。JSONにはあらゆる言語のバリデータ、エディター、ライブラリが存在します。TOONはカスタムパースを必要とし、エコシステムサポートが不足しています。

あるエンジニアの表現が的を射ている：「TOONを初めて見た時、誰かが中途半端に書き残したメモ帳のように見えた。バックエンドエンジニアに見せれば、新たな問題を持ち込まれたかのように眉をひそめるかもしれない」

私たちの決断

実際のBright Dataペイロード（LinkedInプロフィール、Amazon商品、Google SERP）でTOONをベンチマークした結果、以下の結論に至りました：

検索結果の場合：BrightDataのParsed Lightフォーマット（下記レイヤー2参照）はAPIレベルでのフィルタリングによりトークンを80%削減—カスタムエンコーディング不要。
ウェブスクレイピングの場合：Strip-markdownはトークンを40%削減しつつ、レスポンスを人間が読める状態に維持します。新たなフォーマットは不要です。
構造化データセットの場合：真の利点はJSONをTOONに置き換えることではなく、フィールド削除とテキスト切り詰めによるものです。

TOONは適切なユースケース（大規模で均一なデータセット）には優れたアイデアです。しかし異種混合のWeb APIレスポンスでは、標準的な最適化が特殊なフォーマットを常に上回ります。

レイヤー1: ウェブスクレイピング向けRemark + Strip-Markdown

課題：マークダウンの肥大化

当社のscrape_as_markdownツールは、あらゆるウェブページをクリーンでLLM対応のマークダウンに変換します。しかし生のマークダウン変換ツールには以下が含まれることが多く：

推論に不要な冗長な書式（太字、斜体、見出し）
画像の代替テキストとメタデータ
空白行や改行位置の不統一

典型的なブログ記事や製品ページでは、生のマークダウンは中核コンテンツの3～5倍の長さになることがあります。

解決策：Strip-Markdown

構造を保持しつつマークダウンをインテリジェントにプレーンテキストへ変換するため、remark+strip-markdownを採用：

優れたマークダウン処理ライブラリを提供してくださったremarkプロジェクトに感謝します。彼らの活動を支援することをご検討ください！

import {remark} from 'remark';
import strip from 'strip-markdown';

// scrape_as_markdown ツール内部
const minified_data = await remark()
    .use(strip)
    .process(response.data);
return minified_data.value;

何が削除されるのか？

strip-markdownプラグインは以下の要素を除去します：

太字/斜体—**Important**→Important
画像構文—![alt text](image.png)→alt text(必要に応じて) または空
見出し—### Section Title→Section Title(テキストは保持、マークアップは削除)
コードブロック— バッククォートと書式を簡略化しつつ内容を保持

結果？意味は保持しつつ、すべての書式設定のオーバーヘッドを削除したプレーンテキスト。

例：変換前と変換後

生のマークダウン（Web Unlocker より）：

# 製品レビュー

## お客様の声

- **John D.** - ⭐⭐⭐⭐⭐
  *"素晴らしい製品！強くお勧めします。"*
  [続きを読む](https://example.com/review/123)

- **Sarah M.** - ⭐⭐⭐⭐
  *"コストパフォーマンスが良いです。"*
  [続きを読む](https://example.com/review/456)

![製品画像](https://cdn.example.com/product.jpg)

[今すぐ購入](https://example.com/buy)

remark().use(strip).process() 実行後:

製品レビュー

お客様の声

John D. - ⭐⭐⭐⭐⭐
「素晴らしい製品！強くお勧めします。」
続きを読む

Sarah M. - ⭐⭐⭐⭐
「コストパフォーマンスが良い。」
続きを読む

製品画像

今すぐ購入

トークン削減率:1ページ全体で約40%。

LLMはリンクURL、画像パス、マークダウン書式構文を除き、レビュー全文・評価・行動喚起文を保持します。

ストリップドマークダウンの使用タイミング

この最適化は以下に最適です：

要約タスク— 「このブログ記事を要約してください」
感情分析— 「顧客はこの製品をどう評価しているか？」
エンティティ抽出— 「このページから会社名と連絡先情報を抽出せよ」

エージェントがリンクをクリックしたりページをナビゲートする必要がある場合は、代わりに当社のスクレイピングブラウザツール（scraping_browser_navigate、scraping_browser_snapshot）をご利用ください。

レイヤー2: Parsed Light – AIエージェント向けに設計

課題：従来のSERP APIはLLM向けに設計されていない

従来の検索エンジン結果ページ（SERP）APIは、ウェブインターフェースを閲覧する人間向けに設計されていました。それらはあらゆる情報を返します：

エージェントが不要な広告やスポンサードコンテンツ
回答を肥大化させるナレッジパネルやフィーチャードスニペット
複数の命名規則にまたがる冗長なメタデータフィールド
トークンを浪費するビジュアル要素（サムネイル、ファビコン）
関連検索、オートコンプリート候補、「こんな質問もされています」セクション

結果？10件の結果を単一検索すると、2,000～3,000トークンのJSONが返される一方、LLMエージェントが必要なのはリンク＋タイトル＋説明文のみ。

複数ステップの調査ワークフローを実行するAIエージェントにとって、これは致命的な問題です。余分なトークンはコンテキストウィンドウ全体で累積し、制限に達する前に実行できるクエリ数を制限します。

解決策：Bright DataのパースされたLightフォーマット

速度と効率を必要とするAIエージェント向けに設計された「Parsed LightAPI」レスポンス形式を導入しました。

主な特徴は以下の通りです：

–オーガニック検索結果トップ10のみ（広告・ナレッジパネル・サイドバーの不要な情報なし）
一貫したフィールド構造— 全結果にリンク、タイトル、説明、オプションのglobal_rankを付与
設計段階での最適化— APIレベルで事前最適化済み、複雑な後処理不要
高速な応答時間— ペイロードの軽量化によりネットワーク転送とパースが高速化

不統一なフィールド名や肥大化したレスポンスに悩まされる代わりに、Parsed LightはAIエージェントが必要とするものを正確に提供します：最小限のトークンで実用的な検索結果を。

パースされたLightの実践例

検索エンジンとしてGoogleを指定してsearch_engineツールを呼び出すと、自動的にBrightDataのparsed_lightフォーマットをリクエストします：

// search_engineツール内部（Google用）
const response = await axios({
    url: 'https://api.brightdata.com/request',
    method: 'POST',
    data: {
        url: search_url('google', query, cursor),
        ゾーン: ctx.unlocker_ゾーン,
        format: 'raw',
        data_format: 'parsed_light',  // ← 魔法のパラメータ
    },
    headers: api_headers(ctx.api_token, ctx.client_name, 'search_engine'),
    responseType: 'text',
});

得られるもの: クリーンで予測可能なJSON

実際の検索クエリに対するParsed Lightのレスポンス例:

{
  "organic": [
    {
      "link": "https://example.com/pizza",
      "title": "Best Pizza in NYC - Joe's Pizza",
      "description": "Family-owned pizzeria serving authentic New York slices since 1975...",
      "global_rank": 1
    },
    {
      "link": "https://example.com/pizza-guide",
      "title": "Top 10 Pizza Places in NYC",
      "description": "Discover the highest-rated pizza restaurants across all five boroughs...",
      "global_rank": 2,
      "extensions": [
        {
          "type": "site_link",
          "link": "https://example.com/pizza-guide/brooklyn",
          "text": "ブルックリン"
        }
      ]
    }
    // ... さらに8件の結果
  ]
}

ここにないものに注目してください：

広告やスポンサー掲載は一切ありません
ナレッジグラフパネルなし
「よくある質問」セクションなし
冗長なメタデータフィールドなし
Unicode制御文字やフォーマットノイズなし

LLMが処理できる、クリーンで順位付けされた検索結果10件のみ。

追加クリーンアップ：最終仕上げ

Parsed Lightが主要な処理を担う場合でも、完全な一貫性を確保するため軽量な後処理を適用します：

function clean_google_search_payload(raw_data){
    const data = raw_data && typeof raw_data=='object' ? raw_data : {};
    const organic = Array.isArray(data.organic) ? data.organic : [];
    const pagination = data.pagination && typeof data.pagination=='object'
        ? data.pagination : {};

    // リンク、タイトル、説明のみに正規化
    const organic_clean = organic
        .map(entry=>{
            if (!entry || typeof entry!='object')
                return null;
            const link = typeof entry.link=='string' ? entry.link.trim() : '';
            const title = typeof entry.title=='string'
                ? entry.title.trim() : '';
            const description = typeof entry.description=='string'
                ? entry.description.trim() : '';
            if (!link || !title)
                return null;  // 無効なエントリをスキップ
            return {link, title, description};
        })
        .filter(Boolean);

    const parsed_page = Number(pagination.current_page);
    const current_page = Number.isFinite(parsed_page) && parsed_page>0
        ? parsed_page : 1;

    return {organic: organic_clean, current_page};
}

この最終的なクリーンアップ処理:

データ型の検証—リンク、タイトル、説明が文字列であることを保証
空白をトリム— 先頭/末尾のスペースを削除
無効なエントリのフィルタリング— 必須フィールドが欠落している結果をスキップ
ページネーションを正規化—current_pageを一貫した数値形式に変換
オプションフィールドの削除—global_rankとextensionsを除去し、応答を極限まで最小化

結果として、LLMが例外ケースなしでパース可能な堅牢なJSONが生成されます。

例: 従来型 vs. パースされた Light

従来のSERP API（パース軽量化前）：

{
  "ads": [...],
  "organic": [
    {
      "link": "https://example.com/product",
      "url": "https://example.com/product",
      "cache": {"url": "https://webcache.google.com/..."},
      "title": "Amazingu2003Productu2003u2003Review",
      "heading": "Amazing Product Review",
      "name": "Product Review",
      "description": "This   is   a   great   product...",
      "snippet": "これは素晴らしい製品です...",
      "snippet_long": "これは多くの機能を備えた素晴らしい製品です...",
      "subtitle": "製品の特長",
      "rating": 4.5,
      "price": "$49.99",
      "image": "https://cdn.example.com/image.jpg",
      "favicon": "https://example.com/favicon.ico"
    }
    // ... 広告、ナレッジパネルなどを含む30以上の追加結果
  ],
  "knowledge_graph": {...},
  "people_also_ask": [...],
  "related_searches": [...],
  "pagination": {...}
}

典型的なレスポンスで約2,500トークン。

パース済みライト版（AIエージェント向けに最適化）：

{
  "organic": [
    {
      "link": "https://example.com/product",
      "title": "素晴らしい製品レビュー",
      "description": "これは素晴らしい製品です...",
      "global_rank": 1
    }
    // ... 9件の追加結果（上位10件のみ）
  ]
}

同じクエリで約600トークン。

clean_google_search_payload() 適用後:

{
  "organic": [
    {
      "link": "https://example.com/product",
      "title": "素晴らしい製品レビュー",
      "description": "これは素晴らしい製品です..."
    }
  ],
  "current_page": 1
}

~500トークン— 従来のSERP APIと比較して80%の削減。

Parsed Lightが従来のパーサーを凌駕する理由

多くのSERP APIはページ全体をパースし、後処理をユーザーに委ねます。Parsed Lightは異なります：

ソースで事前フィルタリング— オーガニック検索結果のみを抽出、広告やサイドバーは含まれません
標準化されたスキーマ— 全クエリで一貫したフィールド名（snippetvs.descriptionvs.snippet_long といった混乱なし）
LLM優先設計— 後付けではなく、最初からトークン効率を重視して構築
1秒未満の応答時間— 重要度の高いAIアプリケーション向けに設計されたBright Dataのプレミアムルーティングインフラ経由で提供

これは単なるトークン節約ではなく、AIエージェントにおけるSERPデータの在り方を再考する取り組みです。

リアルタイムAIエージェント向けに構築

Bright Dataのパースされた光は最適化されているだけでなく、スピードのために設計されています。1秒未満の応答時間で、以下に最適です：

リアルタイムデータ強化— ユーザー会話中にライブ検索を実行するエージェント
マルチステップ調査ワークフロー— 遅延ボトルネックなしに複数のクエリを連鎖
事実検証— 主張や発言の即時検証
ユーザー向けアプリケーション— 瞬時に感じられる検索機能

従来のSERP APIはクエリごとに3～5秒かかる場合があります。大規模運用ではこの遅延が累積します。Parsed Lightは1秒未満で結果を返すため、エージェントの応答性を維持し、ユーザーの関与を継続させます。

複合効果：実世界のワークフロー

現実的なエージェントワークフローでトークン使用を追跡してみましょう：

タスク：「AI規制に関する記事を検索し、各ソースの要点を要約せよ」

ステップ1: 記事を検索

エージェント呼び出し:search_engine({query: "AI regulations 2024"})

最適化なし（従来のSERP API）：約2,500トークン（検索結果10件＋広告＋ナレッジパネル）
Parsed Light + クリーンアップ適用時：約500トークン
削減率：80%（2,000トークン削減）

ステップ2: 記事ページのスクレイピング

エージェント呼び出し:scrape_as_markdown({url: "https://example.com/article"})× 5 記事

最適化なし: 約15,000トークン (5ページ × 3,000トークン/ページ)
remark().use(strip) 適用時: 約9,000トークン
節約量: 40%(6,000 トークン節約)

ステップ3: 追加調査

エージェント呼び出し:search_engine({query: "EU AI Act details"})による追跡調査

最適化なし: 約2,500トークン
Parsed Light + クリーンアップ適用時: 約500トークン
節約量： 80%（2,000トークン節約）

ワークフロー全体の削減量

最適化なし: 20,000トークン
最適化あり: 10,000 トークン
全体削減率: 50%(10,000トークン削減)

入力トークン100万件あたり3ドル（Claude Sonnetの価格設定）の場合、ワークフロー1件あたり0.030ドルの節約となります。これを1日1,000回実行すると、1日あたり30ドル、年間10,950ドルの節約になります。

しかし真の価値はコスト削減だけではありません—それは処理能力です。これらの最適化により、エージェントは同じコンテキストウィンドウ内でより複雑なワークフローを実行でき、タスクをより迅速に完了し、より高度なクエリを処理できるようになります。

エージェントワークフローにとって重要な理由

トークン最適化は単なるコスト削減ではありません。コンテキストウィンドウ内でより複雑なワークフローを可能にするものです。

20万トークンのコンテキストウィンドウの場合：

最適化なし：制限に達する前に処理可能なマルチステップワークフローは約10件
最適化後：同じウィンドウで約20のワークフローを処理可能

同一インフラで100%のスループット向上を実現

これをDay 1のツールグループ（システムプロンプトトークンを60-95%削減）とDay2のカスタムツール（精密なツール選択）と組み合わせると、エージェントライフサイクル全体（システムプロンプト＋ツール呼び出し＋ツール応答）で大幅な総トークン削減が実現します。

技術詳細：パッケージ依存関係

両最適化レイヤーは実戦で検証済みのオープンソースライブラリで実装：

remark— Markdownプロセッサー（MDX、Gatsby、Next.jsで使用）
strip-markdown— フォーマット除去用Remarkプラグイン

これらは、1日あたり数百万のリクエストを処理する本番サイトで使用されているのと同じツールです。

違いを確認

効果を測定したいですか？トークン数を比較してみましょう：

検索エンジンツールを呼び出し、レスポンス内のトークン数をカウント
同じクエリに対する従来のSERP APIレスポンスと比較
LLMプロバイダーのトークナイザーを使用（例：OpenAI/Claude用tiktoken）

Google検索では80%、スクレイピングページでは40%、構造化データセットでは50% の削減が確認できます。

これは単なる最適化ではなく、ウェブデータをAIエージェントに提供する方法の根本的な見直しです。

パフォーマンス統計の概要

最適化	影響を受けるツール	トークン削減	ユースケース
Strip-Markdown	`scrape_as_markdown`	~40%	ウェブページの要約、コンテンツ抽出
解析済みライト	`search_engine`(Googleのみ)	~80%	検索結果のパース、リード生成、調査ワークフロー

次は何？

明日（4日目）、チームが既に利用しているプラットフォームへMCPサーバーを統合するエンタープライズ連携機能をリリースします。

ご期待ください。