Google OpenRouterワークフロー、新たなClassifiersでコスト帰属を実現
OpenRouterはベータ版としてClassifiersを公開し、元のAI応答を遅らせることなく最大8つのラベル付与ディメンションを追加した。Google OpenRouterワークフローを運用するチームにとって、この機能は長年の疑問により明確な答えをもたらす可能性がある。どの担当者やタスクがモデル予算を消費しているのか、という問いだ。
このリリースにより、リクエストログはコストマップになり得る。別のモデルが完了済みの各生成結果を読み取り、構造化ラベルを割り当て、そのラベルを記録へ書き戻す。企業は、部門、タスク、対象読者、複雑性、コンプライアンス分類、コストセンター、あるいは独自の分類体系で作業を分類できる。
これにより、OpenRouterの位置付けはLangSmithのようなオブザーバビリティプラットフォームに近づく。こうした製品はすでにトレース、メタデータ、モデル支出を追跡している。OpenRouterは現在、モデル選択と請求がすでに行われるルーティングプラットフォーム内で、有用なビジネスメタデータを自動推論しようとしている。
魅力は明快だ。開発者はどのモデルがリクエストを処理したかを把握していることが多いが、財務・コンプライアンスチームが必要とする答えは異なる。法務レビュー、コーディングエージェント、公開コンテンツ、社内調査のどれが支出を発生させたのかを知りたいのだ。
より難しい問いは、AIモデルが、予算やガバナンスの判断を導くのに十分な精度でそうした活動をラベル付けできるかどうかである。Classifiersにより帰属情報は生成しやすくなる。しかし、それだけで信頼性が担保されるわけではない。
Google OpenRouter Classifiersがプロンプトをコストラベルに変換
Classifiersは、選択された各生成結果を構造化されたビジネスメタデータへ変換する、2回目の非同期モデル呼び出しを追加する。
OpenRouterは2026年7月24日にベータ版を発表した。classifier announcementによると、管理者はテンプレートからclassifierを作成するか、独自の分類体系を定義できる。
各設定には4つの主要コンポーネントがある。分類体系、分類モデル向けの指示、選択したモデル、サンプリング率だ。分類体系は最大8つのディメンションをサポートし、各ディメンションには管理者定義の値を設定できる。
これらのディメンションは、誰がリクエストを行ったか、そしてそのリクエストが何を達成する目的だったかを記述できる。ある企業はdepartment、task_type、audience、compliance_categoryを使うかもしれない。別の企業はproject、cost_center、data_sensitivity、agent_complexityを選ぶかもしれない。
classifierは元の生成が完了した後に実行される。OpenRouterによると、分類ジョブがキューに入る前に初期応答が返されるため、追加分析によってユーザーの推論レイテンシが増えることはない。
キューに入ったモデルはシリアライズされたトランスクリプトを受け取る。これは、システムメッセージ、ユーザーターン、アシスタントターン、ツール名、ツール呼び出し、ツール結果をラベル付きで表現したものだ。OpenRouterのclassifier documentationによると、完全なツールスキーマは含まれない。
シリアライズされた各ターンは5,000文字に制限される。切り詰められたコンテンツには、元のテキストの続きがあったことを示すマーカーが付与される。この詳細は重要である。省略された部分に、リクエストの目的や機密性に関する最も強いシグナルが含まれている可能性があるためだ。
分類モデルは、そのトランスクリプトを設定済みの分類体系に照らして評価する。構造化出力、つまり宣言済みのフィールドと値に制約された応答により、結果をフィルターや分析で利用できる状態に保つ。
その後、OpenRouterはラベルを生成記録に付加する。ユーザーは生成詳細パネルでディメンションと値の内訳を確認できる。また、法務部門からのリクエストや複雑なエージェントタスクなどの組み合わせでログをフィルタリングできる。
ベータ版には6つのプリセットが含まれる。Departmentは発信元の事業機能を特定し、Audienceは社内向け、顧客向け、規制対応向け、公開向けの出力を分ける。Task Typeはコーディング、データ処理、コンテンツ作成、エージェントワークフローなどの活動を対象とする。
Engineering Workは機能開発、バグ修正、ドキュメント作成、リファクタリング、コードレビューを区別する。Agent Complexityは難易度の階層とタスクファミリーを組み合わせる。Capitalizable Software Expenseは、開発投資となり得る支出を、保守、運用、サポートと分けようとするものだ。
最後のプリセットは、この機能の魅力と限界の両方を示している。推論されたラベルは、レビュー対象の記録をチームが見つける助けになる。ただし、人による検証と企業独自の資産計上方針なしに、最終的な会計上の結論として扱うべきではない。
OpenRouterでは、管理者が履歴上の生成結果に対してclassifierをテストすることもできる。これにより、新しいトラフィック全体に適用する前に、分類体系を確認する基本的な手段が得られる。
その結果は、単なるログフィールドの追加ではない。プロンプトを、ビジネスチームが理解できる分類へ変換する仕組みを生み出す。その仕組みは同時に、新たな課金対象ワークロードと、測定誤差の新たな発生源も生み出す。
自動帰属が手動タグ付けと外部オブザーバビリティに圧力をかける
OpenRouterは、AIリクエストの実行前に、開発者が有用なコスト・ガバナンスラベルをすべて与えなければならないという前提に挑戦している。
従来のリクエスト帰属は、アプリケーションの計測に大きく依存している。開発者はリクエスト作成時に、ユーザー識別子、プロジェクトコード、環境、機能名、部門フィールドを付与する。オブザーバビリティシステムはこうした値を保持し、フィルタリングに使用する。
アプリケーションがすでに答えを把握している場合、このアプローチは精密になり得る。調達支援アシスタントには固定のコストセンターが設定されているかもしれない。カスタマーサポートワークフローには、安定した部門と対象読者があるかもしれない。こうしたケースでは、明示的なメタデータが依然として最も強いシグナルである。
一方でモデルゲートウェイは、より複雑な現実を目にする。1つのAPIキーが複数のエージェント、部門、社内実験に利用される可能性がある。単一のアプリケーションでも、1つのセッション中に調査、コーディング、要約、文書レビューを切り替えることがある。
手動タグは、個々のリクエストで実行された作業ではなく、アプリケーション自体を説明していることが多い。Classifiersはコンテンツを読み、リクエストの実際の目的を推論することで、そのギャップを埋めようとする。
これは2つのグループに圧力をかける。社内プラットフォームチームは、既存の計測で引き続き十分かを判断する必要がある。独立系オブザーバビリティベンダーは、より広範なトレーシングと評価機能が別レイヤーを正当化する理由を示す必要がある。
たとえばLangSmithは、任意のタグとキー・バリューメタデータをサポートしている。trace metadataでは、環境、ユーザー、内部識別子、その他のアプリケーションコンテキストを記録できる。これらのフィールドは、その後のクエリやグループ化に利用できる。
LangSmithはトークン使用量とモデル支出も追跡する。cost trackingは、トレース、プロジェクト、ダッシュボード全体で費用を集計する。開発者がカスタム使用量データを送信すれば、モデル以外のコンポーネントも含められる。
OpenRouter Classifiersは、そのレベルのトレーシングを置き換えるものではない。OpenRouter経由でルーティングされた生成に対して動作する一方、エージェントトレースには取得処理、データベース呼び出し、ツール、分岐ロジック、複数のモデルリクエストが含まれ得る。
競争上の違いはより限定的だ。OpenRouterは、モデルアクセス、リクエスト支出、推論されたタスクラベルを1つのワークスペース内で組み合わせる。すでにそこでモデルをルーティングしているチームは、新たなタグ付けパイプラインを構築せずに、ビジネスレベルのコストビューを取得できる。
これはGoogle OpenRouterの導入環境で特に意味を持つ。企業は日常的な処理にはGoogleモデルを、難度の高いコーディング作業には別プロバイダーを、選択されたレビューには最先端モデルを使うかもしれない。Classifierのディメンションは、そうした選択を実行中の作業と結び付けることができる。
Activity Explorerは集計レイヤーを提供する。OpenRouterによると、チームはclassifierのディメンションごとにトラフィックをグループ化し、タスクタイプ、部門、複雑性レベルをまたいでモデル使用量と支出を比較できる。
これにより、モデル選択のフィードバックループが生まれる。単純なドキュメント作成タスクが一貫して高価なモデルを使用している場合、管理者はルーティングやアプリケーションのデフォルト設定を調査できる。難しいエージェントタスクが小型モデルへの移行後に失敗する場合も、同じ内訳によってそのパターンを明らかにできる。
この機能は、OpenRouterログを解釈できる人の範囲も広げる。財務チームはすべてのAPIキーを認識する必要がない。コンプライアンスレビュー担当者は各エージェントの内部名を理解する必要がない。プロダクトリーダーは、生のプロンプトを読む代わりにタスク分類を比較できる。
ただし、自動分類は明示的なメタデータを補完すべきであり、それを消し去るべきではない。アプリケーションは誰がリクエストを開始したかを把握している。classifierは、そのリクエストが何であるように見えるかを推論する。成熟したガバナンスでは両方のシグナルを保持し、両者の不一致を調査する必要がある。
ここで圧力は建設的なものとなる。OpenRouterは単に特定のオブザーバビリティベンダーと競合しているのではない。推論された意味的ラベルが、モデルインフラストラクチャの標準的な一部になり得るかを試しているのだ。
この仕組みは推論遅延をバックグラウンド支出と引き換えにする
OpenRouterは分類を応答経路から外すが、コンピュートコストや精度とのトレードオフまで取り除くことはできない。
非同期処理は、この製品における中心的な判断である。ユーザーが元のモデル出力を受け取る前にclassifierが完了する必要はない。タイムアウト、モデルエラー、無効な構造化応答は、アプリケーションのメインリクエストを中断しない。
OpenRouterによると、分類に失敗した場合、その生成にはタグが付かないだけである。この障害分離はアプリケーションの信頼性を守るが、後続レポート内に欠損データも生み出す。
したがって、分類済みトラフィックから作られたダッシュボードは、失敗したジョブを除外していても完全に見える可能性がある。チームは、グループ化された結果を総活動量の信頼できる説明として扱う前に、可視化されたカバレッジ率を確認する必要がある。
モデル選択も別のトレードオフを生む。OpenRouterはGemini 3.5 Flash Liteを推奨し、ほとんどの分類体系において低コストと構造化出力精度のバランスが良いと説明している。管理者は別のモデルを選択でき、後からそのモデルを変更することもできる。
構造化出力は重要である。各分類結果が、宣言されたディメンションと許可された値に一致しなければならないためだ。Googleのstructured output guidanceは、スキーマによってモデルをJSONオブジェクト、必須フィールド、列挙文字列に制約する方法を説明している。
スキーマは出力を有効にできても、判断を正しくするわけではない。classifierは許可された部門を常に返すかもしれないが、法務業務とコンプライアンス業務を繰り返し混同する可能性がある。形式の信頼性と意味的な精度は別の測定対象である。
サンプリング率により、管理者は分類量を直接制御できる。コンプライアンス用classifierはすべてのリクエストを対象にできる一方、より広範なコスト帰属用classifierはサンプルだけを調べることができる。
OpenRouterは、コンプライアンスを全件対象で実行し、コスト帰属ではトラフィックの10パーセントをサンプリングする例を示している。その考え方は、支出を各分類判断の影響に見合うものにすることだ。
サンプリングが最も有効なのは、トラフィックが安定しており、十分に大きい場合である。まれなタスクの重要性が不釣り合いに高い場合、その信頼性は低下する。少量のサンプルでは、異例の規制関連プロンプト、高コストの調査リクエスト、短期間で発生したエージェント障害を見逃す可能性がある。
管理者は、バックグラウンド呼び出しの費用を誰が支払うのかも考慮する必要がある。OpenRouterによると、classifierのトークンは他の生成と同様に課金され、classifierを設定した管理ユーザーに請求される。基礎となるリクエストを開始したAPIキーには割り当てられない。
その請求設計では、監督にかかるコストが一元化されます。また、分類器自体の支出は、測定対象となる部門やタスクとは分離されます。財務チームは、分類されたリクエストのコストと分類処理のオーバーヘッドを同じ区分として扱わないようにすべきです。
コンテキストの扱いにも追加の制約があります。OpenRouterは会話を、ツール名や選択されたツールとのやり取りを含む、ラベル付きの1つのメッセージにシリアライズします。完全なツールスキーマは送信しないため、エージェントの挙動に関する基本的な記録を維持しつつ、入力サイズを削減します。
ただし、すべてのターンで切り詰めが発生し得ます。長いツール結果や文書では、重要な証拠が失われる可能性があります。OpenRouterのドキュメントによれば、分類器モデルのコンテキストウィンドウが元のプロンプトより大幅に短い場合も、気付かれないまま失敗することがあります。
プライバシーにも同等の注意が必要です。分類では、追加のモデルがプロンプトの表現を読み取る必要があります。機密性の高い分類体系を有効化する前に、組織は選択するプロバイダー、ワークスペースの制御、保持設定、データポリシーを確認すべきです。
OpenRouterは、入力および出力のログ記録を無効にしていてもClassifiersは機能すると述べています。これは、分類に通常のプロンプトログが必要だという前提を弱めます。ただし、処理中にどのデータが分類モデルに届くのかを理解する必要性まではなくなりません。
最も合理的な導入は、狭い分類体系から始めることです。部門やタスク種別には、なじみのある境界があります。チームはサンプルを手作業でレビューし、不一致を測定し、指示を修正してから、財務またはコンプライアンス上の影響を持つカテゴリーを追加できます。
これは優れたAIワークフローを踏襲するものです。まず収集を自動化し、判断が重要な箇所にはレビュー工程を残します。分類器は、不確実性を隠すことなく、仕分け作業を減らすべきです。
ラベルでは証明できないこと
分類器は、曖昧な業務、不完全なコンテキスト、変化する組織ルールを誤って表現しながらも、整った分類体系を作り出すことがあります。
ベータ版における最大のリスクは、誤った精密さです。Activity Explorerは分類結果を洗練された支出グラフに変換できます。その視覚的な明快さにより、モデル生成のラベルが、その根拠となる証拠以上に権威あるものに見える可能性があります。
たとえば、プロダクトマネージャーがエージェントに対し、ロードマップ用に顧客インタビューを要約するよう依頼するとします。このリクエストは、プロダクト、リサーチ、マーケティング、エンジニアリングのいずれにも属し得ます。ワークフローの後半では、対象読者が社内の読者からクライアント向けプレゼンテーションへ移ることもあります。
企業がカテゴリーを事前に定義しない限り、単一のラベルが客観的に正しいとは言えません。したがって、分類体系の設計は単なるプロンプト作成作業ではなく、ガバナンスの取り組みです。
同じ問題は複雑性評価にも影響します。長いプロンプトが必ずしも難しいとは限らず、短い指示が負荷の高いエージェント処理を引き起こすこともあります。分類器はシリアライズされたコンテンツを見ますが、すべての外部状態や下流への影響を観測できるとは限りません。
資本化可能なソフトウェア費用には、より大きなリスクが伴います。OpenRouterは、第三者に提出される財務または税務情報の正確性について、顧客が引き続き責任を負うと明示しています。このプリセットは発見とレポーティングを支援するものであり、会計ポリシーエンジンではありません。
コンプライアンスのカテゴリーにも同様の注意が必要です。分類器は、社内データの可能性や規制当局向けの対象読者をフラグできます。しかし、プロンプトに保護対象の情報が含まれていないこと、法的義務を満たしていること、必要な承認をすべて経たことを保証することはできません。
こうしたケースでは、偽陰性が最も重要です。コンプライアンスダッシュボードが低い発生率を示していても、それはモデルが機密性の高いリクエストを見逃した結果かもしれません。サンプリングによって、多くのリクエストが未検査のまま残り、問題がさらに深刻化する可能性があります。
偽陽性にもコストがあります。過剰分類はレビューキューをあふれさせ、従業員による承認済みツールの利用を妨げたり、支出を誤った部門に配分したりする可能性があります。チームには、分類器の値を不変の事実とみなすのではなく、訂正のためのプロセスが必要です。
OpenRouterの履歴テスト機能はプロンプト調整に役立ちますが、1回の生成だけでは分類体系を検証できません。管理者には、通常のトラフィック、エッジケース、曖昧なリクエスト、長いコンテキスト、まれで高リスクなシナリオを含む、代表性のあるテストセットが必要です。
人間のレビュアーは、そのセットに独立してラベルを付けるべきです。その後、各次元について、分類器の結果を参照ラベルと比較できます。許容可能な総合スコアでもまれなクラスでの低い性能を隠し得るため、精度はカテゴリー別に報告すべきです。
組織はドリフトも監視すべきです。新しいプロジェクト、モデルの能力、エージェントツール、社内ポリシーによって、カテゴリーの意味が変わることがあります。導入時に機能していた分類体系も、目に見えるシステムエラーなしに劣化する可能性があります。
モデル変更も、ドリフトの別の要因となります。管理者はいつでも分類モデルを置き換えられます。この柔軟性はコストと品質の面で役立ちますが、新しいモデルは同一の指示を異なる形で解釈する可能性があります。
このような変更をまたぐレポートでは、分類器とモデルのバージョン情報を保持すべきです。そうしなければ、部門別利用量の変化が従業員の行動変化ではなく、新しいラベリングモデルを反映している可能性があります。
欠損タグには明示的な扱いが必要です。分類に失敗しても、元の生成処理は通常どおり継続します。集計レポートでは、分類済み、サンプリング対象外、失敗したトラフィックを別々の母集団として示すべきです。
OpenRouterの公開資料は仕組みと失敗時の挙動を説明していますが、顧客定義の分類体系におけるGemini 3.5 Flash Liteの独立した精度ベンチマークは提供していません。チームが自社の記録に照らして検証するまでは、この推奨は企業自身の判断にとどまります。
この検証上のギャップが、Classifiersを使えないものにするわけではありません。それは適切な役割を定義するものです。ラベルは、探索、異常検知、予算に関する議論、レビューの優先順位付けを支援できます。
ラベルだけで支出を承認したり、規制遵守を確立したり、雇用上の意思決定を行ったりすべきではありません。影響が大きくなるほど、必要な証拠の水準も高める必要があります。
有効な運用ルールはシンプルです。推定されたラベルは調査のきっかけにはなりますが、調査を終えるのは検証済みの記録です。この境界を守るチームは、確率的な出力を組織上の事実に変換することなく、可視性を得られます。
Classifiersがインフラとなるかを決める3つのシグナル
次の試金石は、組織がClassifiersを有用な分析レイヤーとして扱うのか、それとも絶えず修正を必要とする別のダッシュボードとして扱うのかです。
第1のシグナルは、測定可能な分類カバレッジと訂正品質です。OpenRouterは、対象となる生成のうち、どれだけがサンプリングされ、正常にタグ付けされ、スキップされ、失敗したかを示すべきです。
カバレッジデータがあれば、管理者は実際の利用傾向とパイプラインの欠落を区別できます。従業員やレビュアーが誤ったラベルを特定した際に、訂正ツールは分類体系を改善する道筋も作ります。
OpenRouterがカバレッジ指標、レビューキュー、体系的な評価機能を追加すれば、そのガバナンス上の主張はより強固になります。ユーザーがエラーを測定せずに生成を手作業で確認しなければならない場合、Classifiersは方向性を把握するための分析に最も適したままとなるでしょう。
第2のシグナルは、Activity Explorerがバージョニングと帰属をどのように扱うかです。特に設定変更後は、管理者が各ラベルを生成した分類体系、プロンプト、モデルを把握できる必要があります。
バージョンを認識したレポーティングは、過去比較を保護します。また、定期的な財務またはコンプライアンスレポートを支える分類手法を置き換える前に、チームが2つのアプローチを試すことも可能にします。
こうした制御が実現すれば、OpenRouterはガバナンスされた測定システムに近づきます。異なる分類器バージョンの結果がレポートでひそかに統合されるなら、見かけ上の傾向は依然として信頼しにくいままです。
第3のシグナルは、オブザーバビリティおよびゲートウェイの競合企業の反応です。LangSmithはすでに、メタデータ、トレーシング、評価、支出分析を組み合わせています。他のプラットフォームも、既存のトレースに自動化されたセマンティックタグを追加したり、外部で生成された分類結果を受け入れたりできます。
競合各社は、多くの場合エージェント実行全体を確認できるため、重要な優位性を持ちます。OpenRouterには、モデルのルーティングおよび請求経路に直接位置するという別の優位性があります。
勝つアプローチは、両者を組み合わせるものかもしれません。OpenRouterは生成レベルでタスクと部門のラベルを推定できます。オブザーバビリティプラットフォームは、これらの生成をツール、検索ステップ、評価、ユーザーフィードバック、アプリケーションリリースに結び付けられます。
Google OpenRouterワークフローは、この役割分担の初期テストを提供します。Gemini 3.5 Flash Liteは分類を実行し、OpenRouterは結果をモデル支出と結び付け、より広範なトレースシステムは運用コンテキストを保持できます。
チームは、ユーザーがモデル横断で1つの分類体系を採用するか、それともアプリケーションごとに別々の分類器を作るかを注視すべきです。共有された分類体系は組織全体のコスト帰属を支えます。分断された分類体系では、比較が難しくなります。
また、完全カバレッジとサンプリングのバランスも注視すべきです。控えめなサンプリング率でも導入が進めば、方向性を把握するコスト分析が十分な価値を提供していることを示します。完全カバレッジは、コンプライアンスと運用レビューがより強いユースケースになっていることを示唆します。
このベータ版は最終的に、AIコスト管理の捉え方を変えます。トークン総数は企業がいくら支出したかを説明します。自動推定されたラベルは、なぜその金額を支出したのか、どの業務にリソースが割り当てられたのかを説明しようとします。
これはより有用な問いですが、より規律ある証拠を求めます。Classifiersを検討するすべての組織は、ラベルが支援する意思決定を1つ定義し、代表的なサンプルをテストし、グラフの横にカバレッジ率を掲載すべきです。
あなたのチームはGoogle OpenRouterの分類結果を航行のためのシグナルとして使うでしょうか。それとも、会計上の事実へと変えてしまうでしょうか。その答えは、最初の経営層向けダッシュボードが表示される前に、分類体系、サンプリング方針、検証セット、人間によるレビュー工程を決めるべきです。
