AIREITER2026年8月17日、OpenRouterは自社のプレビューモデルのひとつが、気づかないうちに月約6.2Kドルのコストを発生させていたと明らかにしました。組織全体の平均単価のおよそ25倍で、その98%は単一のバッチパイプライン用APIキーに集中していたといいます。同日公開されたActivityダッシュボードは、こうした異常を数カ月後ではなく、数分で見つけるためのものです。支出額、トークン数、キャッシュヒット率、リクエスト単位の詳細をまとめて確認できるUIはかなり実用的。一方、その下で動くベータ版Analytics APIには、まだいくつか扱いにくい点があります。この記事ではそこまで含めて整理します。
月6.2Kドルの教訓：OpenRouter Activityダッシュボードで分かること
ローンチ記事の社内事例は、このツールが想定している典型的な事故をそのまま示しています。あるプレビューモデルは、1カ月で2億5,000万トークンを処理し、6,185ドルを消費しました。100万トークンあたり約24.7ドル、キャッシュヒット率は7.6%です。APIキー別に掘り下げると、batch-pipelineというキーだけで1億2,700万トークン、3万7,000件のリクエストにまたがって6,067ドルを消費していました。大量かつ単純なバッチ処理に、実質48ドル/Mtokのモデルを使っていた計算です。解決策は、モデルを1行変更するだけでした（詳しい内訳はコスト管理のクックブックに掲載されています）。
ダッシュボードと同時に追加された機能は、カスタムクエリを作るExplore、変化を検知するTrends、プロンプトインジェクションや機密データのイベントを確認するGuardrails、リクエスト単位のログ、ベータ版のAnalytics APIです。さらに、コーディングエージェント向けに、GitHubからインストールできるopenrouter-analyticsスキルも用意されています。
Activityの各タブで分かること
OpenRouterのActivityダッシュボードは、メニューではなく「知りたいこと」を軸に構成されています。コストの確認で中心になるのは3つのタブで、それぞれ役割が異なります。
Overview：結局いくら使ったのか
Overviewでは、総支出、リクエスト数、トークン量、キャッシュヒット率、100万トークンあたりの平均コストという5つの主要指標を最初に確認できます。それぞれスパークラインと前期間との比較付きです。下には、ユーザーとアプリの利用上位、モデル別の支出、OpenRouterクレジットと推定BYOK支出の内訳、プロンプトと完了トークンの数が続きます。まず金額の全体像をつかみたいときに開くタブです。
Trends：前の期間から何が変わったのか
Trendsは、絶対額ではなく変化の大きさをモデル、ユーザー、APIキー、アプリごとにランキング表示します。急にコストが膨らんだエージェント、新たに利用が増えたモデル、実験段階から標準ツールになった社内アプリなどを見つけるのに向いています。Overviewが「何か高い」と教えるなら、Trendsは「最近、高くなったもの」を教えてくれる画面です。
Explore：自分で切り口を作る
Exploreはクエリビルダーです。支出、リクエスト数、複数のトークン区分、キャッシュヒット率、100万トークンあたりの平均コスト、BYOKとクレジットの支出内訳に加え、P50/P90/P99レイテンシーやスループットも指定できます。
グループ化できるディメンションは、モデル、プロバイダー、APIキー、アプリ、ユーザー、ワークスペース、国、地域、コンテキスト長、セッション、生成、カスタムID、分類器などから最大2つまでです。時間の集計単位は分から月まで選べ、グラフは棒、線、ドットで表示できます。作成したグラフは自分だけ、または組織全体に保存可能です。注意点は2つあります。3つ目のディメンションを指定すると明確に拒否されること、そしてログ内のプロンプトや出力内容は、リクエスト実行前にプライベート入出力ログを有効にしていた場合にしか表示されないことです。
APIを使わずCSVやPDFに書き出す
経理処理や表計算のためだけにAPIを使う必要はありません。Activityページでは、集計済みの数値をサマリーレポートまたは詳細レポートとして、コードなしで2種類の形式に書き出せます。公式のエクスポート手順は次の5ステップです。
- Activityページを開く。
- 期間とグループ化の単位（モデル、APIキー、または作成者）を選ぶ。
- 右上のオプションメニューを開く。
- Export to…を選択する。
- CSVまたはPDFを選ぶ。
デフォルトのエクスポートは、支出、トークン、リクエストをまとめたサマリーです。詳細レポートが必要なら、先に特定の指標カードを開いてからエクスポートします。すると、その指標を選択したグループ単位で分解したレポートになります。期間を選ぶと、サブ区間は自動的に決まります。
| 期間フィルター | サブ区間 |
|---|---|
| 1 Hour | 1分ごと |
| 1 Day | 1時間ごと |
| 1 Month | 1日ごと |
| 1 Year | 1カ月ごと |
ドキュメントにある細かな注意点も押さえておきましょう。レポート内のBYOK支出は、プロバイダーの市場価格を基にした推定値です。プロバイダーごとの割引は含まれないため、実際の外部請求額とはずれる可能性があります。また、推論トークンは完了トークンの中で課金されますが、レポートでは別項目として表示されます。そのため、「考える」処理にいくらかかったかを、二重計上なしで確認できます。
5分でAnalytics APIの最初のクエリを実行する
Analytics APIでは、Exploreが集計しているのと同じデータを、2つのエンドポイントから取得できます。ただし明確にベータ版です。いきなりクエリを書くのではなく、まず現在の仕様を確認するところから始めましょう。
管理キーが必要
Analyticsのエンドポイントには管理キーが必要です。通常の推論用キーではHTTP 403が返ります。逆も同様で、コスト管理のクックブックによれば、管理キーからモデルリクエストを実行することはできません。キーが漏えいした場合の影響範囲を抑えられる設計ですが、組織全体の支出内訳にはアクセスできます。クックブックの指摘はシンプルです。ほかの認証情報と同じように管理してください。
まずmeta、クエリはその後
GET /api/v1/analytics/metaを呼ぶと、現時点で対応している指標、ディメンション、フィルター演算子、集計粒度が返ります。ベータ版では対応範囲が変わるため、自動化を実行するたびに確認するのが安全です。実際のクエリ用エンドポイントはPOST /api/v1/analytics/queryです。公式ドキュメントのcURL例を示します。
curl -X POST https://openrouter.ai/api/v1/analytics/query \
-H "Authorization: Bearer <management-key>" \
-H "Content-Type: application/json" \
-d '{
"metrics": ["request_count"],
"dimensions": ["model"],
"granularity": "day",
"limit": 100,
"time_range": {
"start": "2026-08-01T00:00:00Z",
"end": "2026-08-08T00:00:00Z"
}
}'レスポンスでは行データがdata.dataの下に入り、metadataブロックにはquery_time_ms、row_count、truncatedが含まれます。クックブックの例では、1行のクエリが17msで完了しています。呼び出し自体は軽く、既存の利用コスト以外は無料の読み取り専用ワークフローと説明されています。ドキュメント上のエラーは400（不正なクエリ）、401（認証なし）、403（キー種別の誤り）、408、500です。
使いすぎを見つける4つのクエリ
公式クックブックには5つのレシピがあります。ここでは、それらをコスト調査の流れとして組み直します。
1. どのモデルが最もコストを消費しているかクックブックの最初のクエリでは、total_usage、request_count、tokens_total、cache_hit_rateをmodelごとに集計し、支出順に並べます。
{
"metrics": ["total_usage", "request_count", "tokens_total", "cache_hit_rate"],
"dimensions": ["model"],
"order_by": { "metric": "total_usage", "direction": "desc" },
"limit": 10,
"time_range": { "start": "2026-07-01T00:00:00Z", "end": "2026-08-01T00:00:00Z" }
}ここで見るべき派生値は、100万トークンあたりの実効コストです。計算式はtotal_usage / tokens_total × 1e6。ディメンションを指定せずに同じ計算をした組織の平均単価と比べます。平均単価の何倍もの価格になっているモデルほど、調査すべき強いサインです。先ほどの25倍のプレビューモデルも、この方法で見つかりました。
2. どのAPIキーが原因なのか対象モデルの正確なスラッグでフィルターし、api_key_idでグループ化します。結果ではキー名が人間に読めるラベルへ解決されるため、batch-pipelineが6,185ドル中6,067ドルを占めていたことも確認できました。フィルターには解決済みのキー名ではなくapi_key_idを使い、返却されるuser_emailで社内記録と突き合わせます。
3. その支出は何に使われたのか日ごとの支出を次の要素に分解します。
| 指標 | 意味 |
|---|---|
usage_upstream | 推論の生コスト |
usage_cache | キャッシュによる節約（またはキャッシュ書き込みコスト） |
usage_data | 割引。通常はマイナス |
usage_web | ウェブ検索の追加料金 |
usage_file | ファイル処理の追加料金 |
プロンプトと完了トークンの比率が20:1前後なら、コンテキストが大きすぎる可能性があります。推論トークンの割合が大きい場合は、不要な思考処理に料金を払っているかもしれません。キャッシュの優先候補は、プロンプト比率が高く、キャッシュヒット率が低いトラフィックです。すでにヒット率が高いなら、次はモデル構成を見直します。プロンプト主体の利用は例外ではありません。OpenRouterの公開プログラミングカテゴリーデータを分析した記事では、トークンの93.4%が入力だったと測定されています。
4. 対策は本当に効いたのかクエリ1を、api_key_idでグループ化した週次の時系列として再実行します。公式例では、batch-pipelineキーの支出が5月31日の週の1,402.50ドルから、6月7日の週には11.20ドルまで減少しました。モデルの切り替えが成功した場合、グラフは緩やかな下降線ではなく、崖のように落ちます。
クエリ1の結果を受けて安いモデルへ切り替えるなら、その判断を実際のルーティングに反映する場所がOpenRouterのルーティング層です。自動ルーティングと固定ルーティングの違いについては、こちらのOpenRouter auto router guideで解説しています。
リファレンスだけでは分かりにくいベータ版の注意点6つ
クエリさえ正しければAPIはドキュメントどおり動きます。ただし、以下の注意点もドキュメントには記載されているものの、クックブックの脚注などに分散しています。
- 3つのディメンションを指定すると400になる。上限は2つです。
model × key × dayのような集計には、複数回のクエリか時間粒度の調整が必要です。 group_limitが時間バケットを黙って切り捨てることがある。未指定ならOpenRouterが安全な値を自動計算します。低すぎる値を設定すると、時系列から数週間分が消えます。ディメンションを指定しない場合は完全に無視されます。- 件数系の指標が文字列で返ることがある。リファレンスでは数値になっていますが、APIは文字列を返す場合もあるため、両方を処理できるようにします。
- 時系列のカラム名が一定しない。同じバケットでも、クエリの形によって
date__dayまたはcreated_at__dayになります。 - 使われていないコスト項目は0ではなく
nullになる。集計スクリプトにはnullチェックを入れておきましょう。 metadata.truncated: trueは、合計が一部しか含まれていないという意味。limit（デフォルト1,000）を増やすか、期間を狭めて再実行します。
ダッシュボード、API、それとも自前のパイプライン？
アカウント単位の確認なら、標準機能で十分です。自前で構築する価値が出てくるのは、その範囲を超えたときです。
| 必要なこと | 使うもの |
|---|---|
| 支出、トークン、キャッシュ率をざっと確認 | Activity Overview |
| 何が変わったか、何が急増しているか | Trends |
| 単発の切り分けと共有 | Explore + CSV/PDFエクスポート |
| 定期レポート、アラート、社内ダッシュボード | Analytics API |
| 複数プロバイダーの集計、ユーザー別予算、独自の異常検知 | 利用ログとWebhookを使ったカスタムパイプライン |
自前で構築する道筋はすでにあります。r/FinOpsの投稿者は、次のように書いています。
「モデルの価格が一晩で数セントから3€に跳ね上がったので、Obsidianで自分用のAIコストトラッカーを作った」
この投稿と、r/openrouterの「Long context pricing should be more transparent」という議論には共通する原因があります。ルーティング、キャッシュ、推論トークン、長いコンテキスト向けの料金体系によって、手元の見積もりと実際の請求額がずれていくことです。Activityダッシュボードに記録された利用額が基準となる数字なので、自前の価格表ではなく、こちらと突き合わせてください。
6カ月間プラットフォームを使ったビルダーが紹介している、より手軽な帰属方法もあります。リクエストにX-Titleヘッダーを付ければ、アプリや実験ごとにActivity上で別名義として集計できます。また、支出が1つのルーターではなく複数のプロバイダーに分散しているなら、AIReiterなどの統合APIを使うことで、集計の問題を最初からまとめて解消できます。
FAQ
Activityダッシュボードを見るのに管理キーは必要ですか？
必要ありません。ダッシュボードは通常のアカウントログインで利用するUI機能です。管理キーが必要なのは、Analytics APIのエンドポイント（/api/v1/analytics/metaと/api/v1/analytics/query）だけです。
OpenRouter Analytics APIの呼び出しは無料ですか？
クックブックでは、Analyticsの処理は読み取り専用で無料と説明されています。自分の利用記録を参照するだけなので、呼び出しごとの料金はかかりません。ただし、記録に含まれる推論処理の料金は通常どおり発生します。
OpenRouterのActivityデータはどこまで遡れますか？
以前からある/api/v1/activityエンドポイントでは、完了済みのUTC日ベースで過去30日分を取得できます。新しいAnalytics APIのドキュメントには保持期間の上限が記載されていません（サンプルクエリは1カ月にまたがっています）。そのため、長期間の履歴については未確認の仕様として扱い、保存しておきたいデータはCSVにエクスポートしてください。
Activityログでプロンプトやレスポンスを見られないのはなぜですか？
プロンプトと完了内容の詳細が残るのは、リクエスト実行時点でプライベート入出力ログを有効にしていた場合だけです。発表でも明記されているとおり、過去のプロンプト内容を後から復元することはできません。利用量は記録されますが、内容の記録はオプトインです。
導入前に考えておきたいトレードオフ
ここまで紹介したことは、すべて今すぐ構築できます。特にクエリ1だけでも、5分かけて設定する価値は十分にあります。一方で、注意すべきなのは仕様の変化です。Analytics APIはベータ版と明記されており、対応する指標やディメンションが変わる可能性があります。OpenRouter自身も、スキーマを信頼する前に/metaを再取得するよう自動化側に求めています。固定のフィールド名だけに依存せず、cronジョブの前にmetaチェックを挟んでおけば、APIが発展途上でもダッシュボードの可視性を維持できます。
関連記事： OpenRouter auto router guide · Best free OpenRouter models for programming · OpenRouter pricing guide