日次コスト推移
読み込み中…
日 × モデルの内訳
どの日に・どのモデルで・いくら使ったかのクロス集計 (成功リクエストの円コスト)。日合計・モデル合計も表示します。
読み込み中…
Cheapest モード削減レポート (Smart Routing ROI メータ)🚧 順次対応予定
Smart Routing の「Cheapest モード」を使った場合と、使わなかった場合 (ベースラインモデル = 顧客設定可、デフォルト Claude Sonnet) のコストを毎リクエストごとに比較し、累計削減額を実数値で表示します。「典型利用で 60-80% 削減」の抽象訴求を、お客様固有の利用パターンに対する実測ベースの削減実績として可視化します。 稟議・経営報告・社内 ROI 試算に直接使える数値レポート。
💡 たとえば:経理「Smart Routing を有効化した先月、ベースライン (元々使っていた Sonnet) と比べていくら浮いたか経営に報告したい」、 経営「Apimane の Smart Routing 有効化で、年換算でいくら削減できているか試算したい」、 CTO「開発チームごとに削減効果を比較し、ベストプラクティスを共有したい」、 ベンダー稟議「他社 (OpenRouter / Portkey) と並列検討中。実測ベースで「Apimane なら年 ¥XX 万削減」と提示して採用判定に活用したい」といった ROI 立証ニーズ。
今月の Cheapest 削減累計
¥—
vs ベースライン (Claude Sonnet)
削減率
¥—%
ベースライン総額 ÷ 実支払額
年換算削減額
¥—
直近 3 ヶ月平均 × 12 で試算
💡 ベースラインモデルは設定変更可: デフォルトは claude-sonnet-4-6 (一般的な選定モデル) ですが、お客様の元々の運用に合わせて GPT-5 / Gemini Pro / カスタム指定も可能。/v2/settings/cheapest-baseline から順次設定対応予定。
📡 API スタブ (技術者向け): GET /v2/usage/cheapest-savings(順次対応、routing_decision 列の追加が前提で 501)
Fastest モード CX 改善レポート (B2B2C UX メータ)🚧 順次対応予定
Smart Routing の「Fastest モード」を使った場合と、使わなかった場合 (同タスク種別 × 同入力長クラスの統計推定) の応答時間 (p50/p95/p99) を比較し、顧客の顧客 (エンドユーザー) の体験向上を実数値で可視化します。 「Cheapest 削減レポート」が経理/経営向けの ROI 指標であるのに対し、こちらはエンジニア / プロダクトマネージャー / CX 担当向けの UX 指標。 B2B2C SaaS のリテンション向上・SLA 達成・エンドユーザー満足度を可視化するメータです。
💡 たとえば:チャットボット運営「自社サービスの応答遅延が離脱率に直結している。Fastest モードで p95 がどれだけ改善するか、SLA 達成率がどう変わるかを実測で把握したい」、 リアルタイム翻訳「会議同時通訳の p95 を 1 秒以下に保ちたい (会話のテンポを維持)」、 コーディング支援 IDE「Cursor/Cline 連携で自動補完の遅延がエンジニアの集中を切る。Fastest 適用でどれだけ改善したか有償プラン更新の根拠にしたい」、 音声対話エージェント「スマートスピーカー / IVR の「沈黙」が顧客ストレスに直結。p95 改善でトランザクション完了率がどう変わるか確認したい」といった B2B2C UX 改善ニーズ。
p50 改善幅
— ms
Fastest 未適用との中央値差
Fastest 適用率
— %
全リクエストに占める比率
SLA 達成率
— %
p95 < 1.5s (顧客設定可)
累計待機時間削減
— h
年換算、エンドユーザー機会損失
💡 ベースライン手法 (Cheapest と異なる): レイテンシは変動が大きいため、同タスク種別 × 同入力長クラス × 同期間の Fastest 未適用リクエスト群を統計推定。サンプル不足 (N<20) は「参考値」表示。外れ値除去 (IQR×1.5)。SLA 目標は p95 / p99 のパーセンタイル + 閾値 ms で顧客設定可能。
📡 API スタブ (技術者向け): GET /v2/usage/fastest-improvement(順次対応、SLA 目標は /v2/settings/sla-target で設定可。現状 501)
レイテンシ詳細 (p50 / p95 / p99)🚧 順次対応予定
応答時間 (リクエスト → 応答までの所要時間) を統計的に分析します。p50 (中央値、半分のリクエストはこの時間内)、p95 (95% のリクエストはこの時間内)、p99 (最も遅い 1% を除く全リクエストはこの時間内)。 社内 SLA 監視や SRE の運用品質指標として活用できます。
💡 たとえば:開発チーム「ユーザー向けチャットボットを動かしているが、p95 が 3 秒を超えていないか毎日確認したい」 「Claude Sonnet vs Haiku で p99 がどれだけ違うか比較したい」といったプラットフォーム部門の運用ニーズ。
p50 (中央値)
— ms
半数のリクエストはこの時間内
p95
— ms
95% のリクエストはこの時間内
p99
— ms
最遅 1% を除く全リクエスト
最大値
— ms
期間中の最も遅いリクエスト
📡 API スタブ (技術者向け): GET /v2/usage/latency-stats
キー別利用ログ (0 件)
該当データなし。
※ 行をクリックすると、そのキーの個別ログ (リクエスト単位) を期間内で表示します。