LLMの分類呼び出しは、毎回API料金が発生する。一方で、実運用のログにはすでに入力とラベルのペアが残っている。機械学習の博士号を持つAdam Rida氏が開発したTRACERは、このトレースを学習データに変え、予測しやすい呼び出しを軽量なMLモデルへ切り替えるルーティング層だ。2026年6月19日にv0.3.0が公開され、無料の可観測性機能が追加された。

この記事では、TRACERの仕組みとv0.3.0の新機能、導入手順を整理する。

この記事でわかること

  • TRACERが解決する課題とルーティングの仕組み
  • v0.3.0で追加された無料可観測性機能
  • トレースのアップロードからML置き換えまでの流れ
  • 既存のLLM可観測性ツールとの違い

LLM分類のコストが積み上がる理由

インテント分類、コンテンツモデレーション、サポート振り分け、エージェントのツール選択など、LLMを分類器として使うワークフローは増えている。各リクエストにLLMを呼ぶ設計だと、件数に比例してコストとレイテンシが膨らむ。

TRACERの公式ドキュメントによると、多くの分類トラフィックは入力パターンが繰り返される。ロジスティック回帰やランダムフォレストなどの古典的MLモデルで、LLMの出力と高い一致率を保てるケースが多い。問題は「どの入力をMLに任せ、どれをLLMに残すか」を安全に決めることだ。

TRACERが何をするか

TRACER（Trace-Based Adaptive Cost-Efficient Routing）は、LLMの本番トレースから軽量なMLサロゲート（代理モデル）を学習し、入出力のルーティングを行うオープンソースのPythonパッケージだ。GitHubリポジトリはadrida/tracer、PyPIパッケージ名はtracer-llm、ライセンスはMITだ。

処理の流れは次のとおりだ。

  1. テキストを埋め込みベクトルに変換する
  2. MLサロゲートがラベルを予測する
  3. アクセプタゲートが信頼度を評価し、閾値以上ならローカル処理、未満ならLLMへ委譲する

サロゲートはLLMではない。CPU上でサブミリ秒級の推論が走る。委譲されたLLM呼び出しは新しいラベル付きトレースを生み、tracer.update()で再学習に使える。

パリティゲートによる品質担保

TRACERはパリティゲートと呼ぶ仕組みで、サロゲートと教師LLMの一致率がユーザー指定の閾値（例: 0.95）を超えた場合にのみルーティングを有効化する。タスクが難しすぎる場合はルーティングを拒否し、すべてLLMに残す。

公式サイトのベンチマーク（Banking77、77クラスの意図分類）では、トラフィックの92.2%をローカル処理し、処理済みトラフィックでの教師一致率は96.1%だった。1日1万クエリの想定では、年間約30万ドルの削減見込みが示されている。

v0.3.0で追加された無料可観測性

v0.3.0は2026年6月19日にリリースされた。Adam Rida氏はXで「無料のLLM可観測性ツール」を公開したと告知し、トレースをアップロードしてトラフィックマップを確認し、LLMから移せる処理を特定できると説明している。

https://tracerml.ai/

主な追加機能は次の3点だ。

tracer.watch（Python） — 既存のLLM呼び出しをデコレータで包むだけで、OpenTelemetry GenAIスキーマ（gen_ai.*）に沿ったスパンを記録する。デフォルトでは.tracer/watch/配下のJSONLにローカル保存され、データはマシン外に出ない。入力・出力メッセージ、トークン数、レイテンシ、ツール呼び出しなどを捕捉する。

@tracer-llm/watch（JavaScript/TypeScript） — Python版と同等のウォッチャーをnpmパッケージとして提供。依存関係ゼロで、非同期コンテキストにも対応する。

tracer cloud CLI — Tracer Cloudのダッシュボード操作をコマンドラインから実行できる。トレーサーの作成、トレースの一括アップロード、再学習、ルーティング設定、APIキー管理などをカバーする。

Tracer Cloudの可観測性は無料だ。TRACER_CLOUD_KEY環境変数を設定すれば、バックグラウンドでバッチ送信され、本番のレイテンシに影響を与えない設計になっている。記録されたスパンはTraceRecordと1対1で対応し、そのままtracer.fit()の学習データに使える。

使い方

https://github.com/adrida/tracer

ステップ1: トレースを記録する

import tracer

watch = tracer.watch("support_classifier", system="my-provider", model="my-model")

@watch
def classify(ticket: str) -> str:
    return call_my_llm(ticket)

既存のJSONLログ（{"input": "...", "teacher": "label"}形式）をそのままアップロードしてもよい。公式には「Raw logs are fine」とある。

ステップ2: トラフィックを分析する

Tracer Cloudにトレースを送ると、クラスタごとのトラフィックマップが表示される。各クラスタがサロゲート処理、中間難易度、教師LLM委譲のどれに振り分けられるかを2次元投影で確認できる。クラスタカードには代表クエリとモデルごとの精度が並び、どの入力がMLに移せるかを読み取れる。

ステップ3: ルーティングポリシーを学習・配備する

pip install tracer-llm
tracer fit traces.jsonl --target 0.95
tracer serve .tracer --port 8000

Pythonから直接呼ぶ場合はtracer.fit()でポリシーを学習し、tracer.load_router()で推論する。委譲が必要な入力だけ既存のLLM呼び出しにフォールバックする。

既存ツールとの違い

LangfuseやOpenTraceなどのLLM可観測性ツールは、呼び出しの記録・コスト追跡・デバッグに強い。TRACERはその先の最適化まで担う。トレースを見るだけでなく、MLサロゲートへの置き換え候補を特定し、パリティゲート付きで本番ルーティングまで行う点が異なる。

アプローチ 内容 限界
キャッシュ 同一リクエストの再利用 完全一致のみ有効
小型LLM 安価なモデルへ切替 LLMコスト構造のまま
モデルルーター 最適なLLMを選択 LLMが必要かは問わない
TRACER 予測可能な入力をMLへ 分類系ワークロード向け

導入実績

Tracer AIの公式サイトによると、フランスのフィンテック企業Obsideとエージェント基盤のgetclawで本番稼働している。getclawではHermesエージェントのツール選択をTRACERで分類し、エンドツーエンドのコストを約50%削減したと報告されている。ルーティング手法はarXiv論文（2604.14531）として公開されている。

料金

OSSのtracer-llmはMITライセンスで永久無料だ。ホスト版のTracer Cloudは、フロンティアLLMの支出削減額の20%を課金するモデルで、LLM推論へのマークアップはない。

向いているワークロード

TRACERが想定するのは、同じ種類の分類判断が大量に繰り返されるワークロードだ。インテント分類、モデレーション、コンプライアンススクリーニング、サポート振り分け、エージェントのツール選択などが該当する。創造的な文章生成や複雑な推論が主目的のタスクには向かない。

LLM運用のコスト最適化を検討しているなら、まず既存ログをtracer.watchで記録し、トラフィックマップでML化の余地を測るのが現実的な第一歩だ。