Folkbench は モデル整合性モニター（Integrity Monitor） にモデル劣化検知機能を正式に導入しました。従来のモデルランキングは公式環境における能力上限を評価し、一般的な API 中継ディレクトリは表示価格・HTTP 疎通・応答時間にとどまります。しかし実運用で本当に問われるのは、サードパーティの中継ルートを経由した場合でも、推論の深さ、制約遵守、モデル固有の振る舞いが公式直結 API と一致し続けているかどうかです。

この空白を埋めるため、Folkbench は時事とモデル指紋（Model Fingerprint）の 2 軸で構成される自動プローブ群を組み込み、同一の時間ウィンドウ内で独立した公式直結 API キーによるリアルタイム校正を実施します。中継ルートの実測値を公式の現在基準線に常時アンカーすることで、表面化しにくい劣化を早期に捉え、主観的な違和感を検証可能な公開シグナルへと変換します。

今回の機能の要点は以下の通りです。

  • 2 軸プローブ設計：時間とともに更新される時事プローブと、推論習慣・トークン配分・API 指紋を追跡するモデル指紋プローブを組み合わせ、静的キャッシュや表面的な模倣を防ぎます。
  • 独立した公式直結校正：外部中継を一切通さない独立した公式 API キーで同一プローブを並行実行し、モデル提供元のアップデートや揺らぎと中継側の逸脱を切り分けます。
  • モデル × サービスグループ単位の計測：サイト全体の曖昧な平均ではなく、モデルと具体的なサービスグループごとにプローブ一致率、入力トークン、思考トークン、モデル指紋、および利用可能なキャッシュ検知を記録します。
  • 選定から切替までの一貫導線：整合性モニターを 4 つの公開ランキング、横並び比較、オープンソースのデスクトップクライアント Folkbench Switch と接続します。

従来のランキングや疎通監視が「劣化」を捉えられない理由

中継構成では、呼び出し元とモデル開発元の間にゲートウェイが介在します。コスト圧力や混雑時のルーティング制御によって、ネットワーク指標だけでは見えにくい 3 種類の劣化が生じ得ます。

  • サイレントなモデル差し替え：上位モデルを指定していても、混雑時間帯や長いコンテキスト時に安価な小型モデルや旧スナップショットへ振り分けられる。
  • 推論予算の削減：モデル名は変わらないまま、推論強度（Reasoning Effort）が下げられたり内部思考ステップが短縮されたりして、十分な推論前に回答が打ち切られる。
  • コンテキストや出力上限の切り捨て：トークン消費を抑えるため会話履歴の序盤が削られたり最大出力長が制限されたりして、複数条件タスクで整合性が崩れる。
図 1 ワイヤーフレーム図：通常の監視が HTTP 200・速い TTFT・滑らかな短文を正常とみなす背後で、サイレント差し替え・推論予算削減・文脈切り捨ての 3 種の劣化が発生する構造。

図 1：通信表面がすべて正常（`HTTP 200`、低い初動遅延、自然な短文応答）であっても、モデル能力がそのまま届いているとは限りません。中継層での経路差し替え・推論削減・文脈圧縮は通常の死活監視に現れません。

これら 3 つはいずれも表面上の疎通を壊さないのが特徴です。HTTP 200 が返り、短い雑談は流暢に続き、思考が短いぶん見かけの応答時間すら速くなることがあります。一方でモデルには自然なサンプリングの揺らぎもあり、[モデルは本当に「賢さが落ちた」のか？](/ja/blog/did-the-model-get-dumber/)で整理した通り、1 回の失敗スクリーンショットだけでは通常の揺らぎと構造的な劣化を区別できません。

一般的な手動テストが現代のルーティングに通用しない理由

精度低下が疑われる際によく試される 2 通りの手動確認は、現代のプロキシ制御の前では容易にすり抜けます。

  1. 「あなたはどのモデルか」と直接尋ねる：言語モデルは前段のプロキシ構成を認識できません。システムプロンプトでの指定や学習済みの定型文により、差し替え後の軽量モデルでも堂々と上位モデル名を名乗ります。
  2. 固定の定番クイズを使い回す：有名な引っかけ問題は軽量モデルの学習データにも含まれており、同じ問題セットを繰り返すと静的キャッシュの返却や、検証プロンプトのみ高品質ルートへ流すホワイトリスト回避が可能になります。
図 2 ワイヤーフレーム図：モデル名を直接尋ねる質問や定番クイズの使い回しが、ゲートウェイ注入と静的キャッシュ・ホワイトリストによって無力化される仕組み。

図 2：よく使われる手動チェックが破られる理由。左はゲートウェイのシステム指示だけで実体と異なるモデル名を名乗れること、右は固定問題の反復パターンをゲートウェイが識別し、検証用だけを静的キャッシュや清浄プールへ逃がせることを示しています。

2 軸プローブ構成：最新の理解力とモデル指紋を同時に検証

表面化しにくい劣化を正確に捉えるため、Folkbench は同じ評価ウィンドウ内で 2 つの補完的なプローブ軸を並列実行します。

図 3 アーキテクチャ図：時事プローブとモデル指紋プローブを同一時間ウィンドウで独立公式直結 API キーと中継サイトの各グループへ並列送信し、同窓差分アライメントを行う構成。

図 3：同一ウィンドウ並列計測アーキテクチャ。時事プローブが静的キャッシュを遮断し、モデル指紋プローブが一致率・入力トークン・思考トークン・指紋・キャッシュ状態を収集したうえで、外部中継を通さない公式直結キーの現在基準線と突き合わせます。

1. 時事プローブ：静的キャッシュと旧版フォールバックを遮断

時事プローブは直近の出来事、最新の時系列関係、動的な条件を複数ステップの推論課題に組み込みます。問題が現実の時間に沿って更新され続けるため、中継側が事前回答をキャッシュしておくことは困難です。たとえば直近の出来事の時系列整理と新しい条件の組み合わせを要する問題では、知識カットオフの古い代替スナップショットが時間軸で破綻しやすく、過度な圧縮を受けた軽量モデルも条件統合で精度を落としやすくなります。

2. モデル指紋プローブ：正誤だけでなく「思考習慣とトークン消費」を検査

仮に一定の能力を持つ別モデルへ差し替えられたり、同一モデルでも思考予算が半分に削られたりした場合、単純な客観問題の正誤だけでは取りこぼします。モデル指紋プローブは、多段階制約や厳密なフォーマット境界におけるモデル固有の行動パターンと、エンドポイントが返すプロトコル上のバイタルを同時に記録します。

  • プローブ一致率：多段階推論および細かな制約検査における基準挙動との一致度。
  • 入力トークン・思考トークン（Reasoning Tokens）：回答生成前の内部推論に費やされたトークン量。
  • モデル指紋・キャッシュ検知：API 応答に含まれる指紋メタデータおよび計測可能な場合のキャッシュ状態。

たとえば推論モデルの裏側で思考強度が引き下げられた場合、出力文面自体は自然に見えても思考トークン量とプローブ一致率が同時に低下しやすくなります。

独立した公式直結 API キーによる校正：絶対値から相対基準線へ

プローブを備えても、中継側のスコア単独では原因を切り分けられません。ある時間帯に一致率が下がったとき、中継側の劣化なのか、公式側のモデル更新・一時的変動なのか、あるいは新設問題に対する公式自体の基礎通過率によるものなのかが判別できないためです。

この曖昧さをなくすため、Folkbench はすべての劣化検知プローブを独立した公式直結 API キーで同じ時間帯に並行実行し、公式のリアルタイム基準線を生成しています。

校正メカニズムのワイヤーフレーム図：原因を特定できない単独計測（左）と、公式直結レーンと中継レーンを同一ウィンドウ W_t の同期照合ゲートへ同時に通す 2 レーン校正（右）の比較。

校正メカニズム：同時刻の公式アンカーがない単独計測（左）では上流変動と中継劣化を切り分けられません。2 レーン同時校正（右）は独立公式直結キーと対象 `モデル × グループ` を同一評価窓 `W_t` に並走させ、相対差分を抽出します。

観測される状況公式校正なし（中継のみ計測）独立公式直結キーによるリアルタイム校正
公式モデル自体の微調整・変動提供元全体の変化を中継劣化と誤認しやすい公式基準線も同時に動くため、上流変動と単一中継の異常を分離できる
公式基準は安定し特定中継のみ低下同時刻の比較軸がなく逸脱幅を検証しづらい一致率と思考トークンの公式基準線からの乖離が明確に表れる
同一サイト内でグループ間に差がある高品質枠の印象で低価格枠の劣化を見落としやすい「モデル × サービスグループ」単位で基準線と独立照合できる
図 4 メカニズム模式図（実測値ではない）：上流モデル側の変動で両線が T3 から並行移動するケース A と、公式基準が横ばいのまま中継一致率と思考トークンだけが T3 以降落ち込むケース B の比較。

図 4（解説用の模式図であり実測データではありません）：独立した公式直結基準による切り分けイメージ。ケース A のように公式と中継が `T3` で揃って動く変化は提供元や問題セット由来の変動であり、ケース B のように公式が平坦なまま一致率と思考トークンが縮む現象が特定グループの逸脱を示します。

なお [モデル整合性モニター](/ja/arena) で明記している通り、1 回の応答や単独のパーセンテージだけでモデル差し替えを断定することはできません。サンプル数、連続した時間帯、トークン分布、検査条件とあわせて読み解くことで、客観的で再現確認可能な早期警戒シグナルとして機能します。

劣化検知から実利用までの閉ループ：他サイトとの明確な違い

従来の評価サイトは「固定データセットでのモデル理論値」か「価格と単純な HTTP 疎通」のどちらかに偏っていました。Folkbench は劣化検知を組み込むことで、実配信品質の継続検証へと踏み込んでいます。

図 5 Folkbench の全体フロー：4 つの公開ランキング、整合性モニター、中継サービス比較、Folkbench Switch を繋ぎ、静的な比較や疎通監視から継続的な実配信検証へ拡張する構成。

図 5：理論スコア比較や単純な疎通確認を超える 4 層の評価・切替導線。グループ別ランキング（`/rankings）、劣化監査（/arena）、同グループ比較（/stations/compare）、安全切替（Folkbench Switch`）を連携させ、整合性・キャッシュ監視は Web プラットフォーム側で継続実行します。*

  1. モデル × グループ単位の正確な計測：同一サイト内の特売枠と公式キー安定枠を混同せず、実際に契約するグループごとの実測値を公開します。
  2. 4 つの専門公開ランキング：[可用性](/ja/rankings)（偽 200 エラーやストリーム途中切断を除外）、[安定性](/ja/rankings/stability)（長時間・混雑時間帯の持続性）、[応答速度](/ja/rankings/latency)（TTFT と生成速度を分離）、[セッション費用](/ja/rankings/cost)（実作業 1 セッションの総コスト）。
  3. 無料公開の[整合性モニター](/ja/arena)と[中継サービス比較](/ja/stations/compare)：自前で複数の公式キーや動的テスト基盤を維持せずとも、校正済みデータと横並び比較を利用できます。
  4. 設定適用まで繋ぐオープンソースクライアント [Folkbench Switch](https://github.com/Folkbench/folkbench/releases)：Tauri + Rust 製（macOS .dmg / Windows .exe）で Claude Code・Codex・Gemini CLI・Aider・OpenCode・Kimi CLI などに対応し、書き込み前の差分プレビュー、Codex 公式 OAuth 認証情報の自動退避・復元、公開ルート閲覧とローカル使用量見積もりを提供します。（整合性モニターとキャッシュ計測は Web 側の継続監視機能です。）

実務での活用手順

  1. 用途に応じて[可用性](/ja/rankings)・[安定性](/ja/rankings/stability)・[応答速度](/ja/rankings/latency)・[セッション費用](/ja/rankings/cost)から対象モデルとグループを絞り込む。
  2. [整合性モニター](/ja/arena)で対象グループの連続時間帯におけるプローブ一致率・思考トークン・モデル指紋と公式基準線の整合を確認する。
  3. 課金前に[中継サービス比較](/ja/stations/compare)で契約予定グループそのものの数値を並べて検証する。
  4. Folkbench Switch に主回線と予備回線を登録しておき、指標の乖離が見られた際は差分を確認して数秒で切り替える。

これからの API 評価に求められるのは、カタログ上のモデル性能だけでなく「選択した経路が約束どおりの能力を届けているか」の継続的な検証です。時事プローブ、モデル指紋、独立した公式直結校正を公開基盤に据えることで、Folkbench は再現可能で透明な選定基準を提供します。