LLM Liveの仕組み
当サイトのすべての判定結果は、ここに記載された明確なルールに基づいています。掲載料を支払った事業者は存在せず、以下に記載する数値はすべてコード内で実際に使用されているものです。
ステータス
4つのシグナルから1つの判定。最も深刻な状態を採用します。
- 独自チェック
- APIキーを保持しているサービスに対し、ワーカーからベンダー自身のAPIへ60〜120秒ごとに小規模なストリーミングリクエスト(1から20までのカウント、最大80トークン)を送信し、TTFT(最初のトークンまでの時間)と秒間トークン数を記録します。失敗したチェックは20秒間隔で2回再試行されます。レートリミットや弊社インフラ側のエラーは除外されます。各サービスページに、独自チェックが稼働中かどうかが表示されます。
- 判定ルール
- 直近3回のチェックが連続で失敗 → 大規模障害。10分間のチェックのうち半数以上が失敗 → 部分的障害。20%以上が失敗、またはTTFTの中央値が3秒を超え、かつ過去24時間の中央値の3倍以上遅延 → パフォーマンス低下。
- 公式ステータスページ
- 1分ごとにポーリング。更新から15分以上経過したステータスは無視されるため、ページの停止・不具合によってステータスが緑や赤のまま固定されることはありません。
- OpenRouter経由
- OpenRouterは全モデルのプロバイダーごとのリクエスト成功率を公開しています。ベンダー自体のエンドポイントにあるモデルのうち、2つ以上かつ半数以上で過去30分間の成功率が80%未満、かつ過去24時間の水準を10ポイント下回る場合 → パフォーマンス低下。平均して50%未満の場合 → 部分的障害。3社以上のベンダーが同時に失敗した場合はOpenRouter側の問題と判断し、シグナルを無視します。
- ユーザー報告
- 15分間に10件以上の報告があり、かつ通常の4倍以上の件数 → パフォーマンス低下。ユーザー報告のみでサービス全体を停止と判定することはありません。
- 復旧とアラート
- ステータスは30秒ごとに再評価されます。問題が発生しない状態が3分間続いて初めて「正常稼働」に戻るため、APIの不安定な変動によるアラートの連発を防ぎます。アラートは問題の発生時、悪化時、および復旧時に送信されます。
- ステータスバー
- 各バーは30分間を表し、その枠内で最も深刻だった状態の色で表示されます。グレーはデータなしを意味します。稼働率は問題のないバーの割合です。
モデルと料金
すべての価格はパブリックAPIから取得し、5分ごとに確認しています。
- 情報源
- モデル一覧、料金、コンテキストウィンドウはOpenRouterのパブリックAPIから取得しています。料金はOpenRouterの掲載どおり1Mトークンあたりで表示されており、通常はベンダー自体の価格と一致しますが、例外もあります。
- 価格履歴
- 5分ごとにスナップショットを保持し、すべての変更を記録しているため、値下げや新モデルの追加、廃止は数分以内にニュースフィードに反映されます。
- 利用可能なプロバイダー
- OpenRouter上でそのモデルを提供しているプロバイダーの数です。Flex、バッチ、優先、スポットなどの利用枠は、仕様上利用不可になることが多いためカウントから除外しています。
チェスアリーナ
モデル同士の対局。チェスエンジンが厳密に判定します。
- 指し手
- モデルに盤面(FEN)とこれまでの棋譜が渡され、指し手と短いコメントを返します。合法手判定はchess.jsで行います。非合法手を指した場合、合法手リストを渡して再試行させます。非合法手を3回指すと反則負けになります。また、指し手のない返答が3回連続した場合は時間切れ負けとなります。
- 思考トークン枠
- 対局コストを抑えるため、推論トークンは1手あたり最大1024トークンに制限しています。これにより推論特化モデルの本来の実力は抑えられますが、アリーナでは全力を出させるのではなく、等しく厳しい制限下での性能を比較しています。
- レーティング
- 評価の不確実性を考慮できるGlicko-2を採用しています。リーダーボードはレーティングから偏差の2倍を引いた保守的な推定値で並べ替えられます。10局プレイするまでは暫定値として扱われます。マッチングは対局数が少なくレーティングが近いモデルが優先されます。
- 精度(Accuracy)
- Stockfishが深さ14で各局面を評価します。勝率が5、10、15ポイント低下すると、それぞれ不正確、ミス、大悪手(ブランダー)と判定されます。精度はLichessの計算式を使用しています。
- ノーコンテスト
- プロバイダーのAPIエラーで中断した対局はレーティングに反映されません。また、理由を明記した上で手動で無効化される場合もあります。
人間による投票
匿名化された2つの回答から優れた方を選択。Bradley–Terryモデルが投票をレーティングに変換します。
- バトル
- プロンプトは、主要ラボの現行モデル約20種類から選ばれた異なる2つのモデルに送られます。配置はランダムで、投票するまで名前は伏せられます。投票数が少ないモデルやペアが優先して選ばれ、高価なフラッグシップは頻度が抑えられます。日常的な手軽な回答を比較するため、各回答は推論なしで最大1024トークン(推論をオフにできない場合は最大512トークン)に制限されています。
- 投票
- 両方の回答が完了した後にのみ、1回のバトルにつき1度だけ投票できます。AまたはBへの投票はそのモデルの勝利となり、引き分けおよび「両方とも悪い」はLMArenaと同様に各モデルに0.5勝としてカウントされます。モデルの回答が失敗したバトルは集計から除外されます。
- レーティング
- 全投票に対してBradley–Terryモデルを一度にフィッティングするため、Eloとは異なり投票の順序は影響しません。レーティングはEloスケールで表示され、400ポイントの差は10:1の勝率差を意味し、中央値のモデルは1000に固定されます。未敗のモデルでも値が発散しないよう、弱い事前分布(モデルごとに1回の仮想的な引き分け)を設けています。
- 信頼区間
- 95%信頼区間は投票の100回ブートストラップ再サンプリングから算出されます。順位は「信頼区間全体が自モデルを上回っているモデル数+1」となるため、信頼区間が重なるモデルは同順位を共有します。投票数が20未満のモデルは末尾に表示されます。すべて10分ごとに再計算されます。
- カテゴリ
- 小型言語モデルが投票されたプロンプトを「コーディング」「数学」「クリエイティブライティング」「アドバイス・ハウツー」「知識・事実」「その他」に分類し、言語も検出します。ロシア語プロンプト専用ボードにはロシア語のプロンプトのみが使用されます。モデルは該当カテゴリで20票以上獲得するとカテゴリ一覧に表示されます。
- 注意事項
- どなたでも匿名で投票できます。訪問者ごとの制限(IPアドレスのソルト付きハッシュにより1時間あたり8回、1日あたり40回)と1日の予算枠により組織票を難しくしていますが、完全に排除できるわけではありません。人は内容だけでなく文体も評価するため、長文で見栄えの良い回答が勝ちやすい傾向があります。プロンプトはカテゴリ分類のために保持され、統計として公開される場合があります。生のIPアドレスは一切保存されません。
ディベート
2つのモデルが3ラウンドにわたり論戦。AI審査員が2回判定し、その後ユーザーが投票します。
- 論題
- 厳選された約40の論題を「技術・AI」「社会」「科学」「倫理」「日常の話題」の5グループに分け、英語とロシア語で用意しています。選挙や候補者、宗教間の対立、特定集団を標的とするテーマは除外しています。論題は直近10回で使われておらず、最も使用頻度の低いものが選ばれます。3回に1回のディベートはロシア語で行われます。
- ディベーター
- 約20種類の現行モデルの中から異なる2つのモデルが選ばれます。ディベート数が少ないモデルや対戦頻度の低い組み合わせが優先され、高価なフラッグシップは頻度が抑えられます。肯定・否定の立場はランダムに割り振られるため、モデルが自身のスタンスを選ぶことはできません。エラーが続くモデルは2時間、アカウントまたはモデルエラー発生後は24時間出場停止となります。新しいディベートは前回の終了から30〜60分後、1日の予算が続く限り開始されます。
- ペルソナ
- 2026年10月29日以降、モデルはキャラクターになりきって討論します。実在の人物、政治家、宗教関係者を除く10人の架空キャラクターから2人が選ばれ、それぞれ固有の話し方を持ちます。ペルソナはモデルとは別に選ばれ、出演回数の少ないキャラが優先されます。各ペルソナは戦績、今日の対戦相手に対する戦績、直近3回のディベートの要約、定番の決め台詞という記憶を持ち、これらがプロンプトに入力されます。要約はディベート終了ごとに小型モデル(Qwen Flash)が作成し、発言と同じモデレーションを受けます。引用句は本人の発言に一字一句違わず含まれている場合のみ保持されます。ペルソナのリーダーボードも審査員の判定をもとに同じ方式で算出され、審査員にはキャラではなく論拠を評価するよう指示しています。
- ラウンド構成
- 立論、反論、結論の計6ターンが厳格に交互に行われます。各ラウンドで肯定側が先に話し、否定側が応答するため、最終発言権は否定側にあります。各ディベーターには論題、自身の立場、それまでの全議事録が提供されます。発言は推論オフで最大250語(600トークン、ロシア語は800トークン、推論をオフにできない場合は最大512トークン)に制限されています。統計や引用の捏造、自身のモデル名を名乗ることは禁じられています。
- モデレーション
- すべての発言は表示前にチェックされます。軽量安全性分類モデルのLlama Guard 4を使用し、フォールバックとして小型汎用モデルを使用します。問題が検出された場合、発言内容は「モデレーションにより削除されました」に置き換わり、ディベートは即時終了してレーティング対象外となります。
- 審査員
- 対戦中の両モデルとは異なるラボの小型モデル(Claude Haiku、DeepSeek Flash、Qwen Flash)が、モデル名を伏せた状態で立場ごとにまとめられた発言を読み、論拠、反論、明瞭さを各1〜10点で採点し、短い解説とともに勝者を決定します。LLM審査員は先に読んだ立場を優遇する傾向があるため、肯定側を先に読ませる回と否定側を先に読ませる回の計2回判定を行います。両方の判定が一致した場合にのみ勝利となり、不一致の場合は引き分けとなります。
- 閲覧者投票
- ディベート終了後、どなたでも7日間「肯定」「否定」「引き分け」に投票できます。投票は1ディベートにつき訪問者ごとに1回(IPアドレスは生の形式ではなくソルト付きハッシュで管理)、1時間あたり最大30回までです。投票後に結果が表示され、審査員の判定も開示されます(希望すれば投票前に判定を見ることも可能です)。5票以上集まったディベートが閲覧者ボードに反映されます。最多得票の選択肢が勝者となり、肯定と否定が同数の場合は引き分けとなります。
- レーティング
- バトル投票と同じ手法による2つのBradley–Terryボードを用意しています。1つは審査員の判定に基づくもの、もう1つは閲覧者の多数決に基づくもので、引き分けは双方に0.5勝として扱われます。すべての結果を一度にフィッティングするため、ディベートの順序は関係なく、無効となった対局は単純に除外されます。中央値のモデルを1000とするEloスケールで、100回のブートストラップ再サンプリングによる95%信頼区間を算出し、レーティング対象ディベートが10回未満のモデルは末尾に表示されます。15分ごとに再計算されます。
- 注意事項
- これは厳しい制限下でのディベート力を測定するものであり、知識の正しさや真実性を測るものではありません。不利な立場を巧みに主張することで勝利することも可能です。審査員は小型モデルであるため、自信に満ちた語り口を好むなどの独自のバイアスを持っています。順序の入れ替えは提示順によるバイアスを排除しますが、すべてのバイアスを除去できるわけではありません。特定の立場に有利な論題もありますが、立場の割り当てはランダムであるため、対戦を重ねることで偏りは相殺されます。
コードアリーナ
複数のモデルがPythonまたはJavaScriptで同じ課題を解決。勝敗は隠しテストで決まり、実行速度は同点時のみ考慮されます。
- 課題
- 厳選された71の課題(初級12、中級21、上級38)。初級・中級は古典的なアルゴリズムや文字列・データ処理(CSV、バージョン、ログ、JSONパス)を扱い、上級は遅延セグメント木、最大流・マッチング、接尾辞オートマトン、ビット演算・木DP、厳密な整数幾何、小型インタプリタ、板情報(オーダーブック)、スケジューラなど、高度なアルゴリズムや厳密な実装が求められます。各課題には問題文、関数シグネチャ、公開テストケース、エッジケースを含む6〜19件の隠しテストがあり、うち66問には時間制限付きの大規模入力テストが含まれます。正解出力は、数千件のランダムな小規模入力で総当たり解法と突き合わせて検証された模範解答に基づきます。制限時間は、サンドボックス上で模範解答と標準的な教科書的解法を3回実行したうちの最遅時間の2倍に100msを加えた値です。適切なアルゴリズムなら余裕を持って通過できますが、二乗オーダーの解法は通過できません。出題割合は上級が6割、中級が3割、初級が1割で、同難易度内では直近10回で出題されておらず最も出題回数の少ない課題が選ばれます。
- ラウンドの流れ
- コーディング向けモデル約20種類の中から、可能な限り1ラボにつき1モデルとなるよう選ばれた4モデルに、同時に課題が与えられます。推論はオフ(オフにできない場合は最大1024トークンに制限)で、回答トークンは最大2048トークン(上級課題は4096トークン)です。言語は約3分の2がPython 3.12、3分の1がJavaScript(Node.js 24)で、JavaScriptが出力・入力を変更なしで扱える(2^53を超える整数がない)65課題から出題されます。JavaScriptでも同じテストと制限時間が適用され、シグネチャと例題はJavaScript向けに書き直されます。モデルは1つのコードブロックで返答し、必要な関数を定義しているブロックが抽出されます。回答時間はリクエスト送信から完了までを計測し、参考情報として表示されます。新しいラウンドは前回の終了から20〜30分後、1日の予算が続く限り開始されます。
- サンドボックス
- 各回答はgVisor環境下のクリーンなコンテナで1回実行されます。ネットワーク遮断、読み取り専用ファイルシステム、メモリ制限512MB(Pythonは約380MB、JavaScriptはヒープ192MB+バッファ)、CPU 1コア、64プロセス、16MBの一時フォルダ、出力サイズ制限が課されます。コードは専用プロセスで実行され、独立したテスト実行ハーネスプロセスから1問ずつテストケースが渡されます。入力送信から全結果受信までの各呼び出し時間を外部から計測するため、コード側からクロックを改ざんすることはできません。時間切れやクラッシュが発生したテストは停止され、残りのテストは新しいプロセスで実行されます。期待される結果がコンテナ内に渡されることはなく、ハーネスが結果のハッシュを返し、外部で照合します。公開された例題についてはコードが返した値が表示されますが、隠し入力と結果が表示されることはありません。
- 採点基準
- すべてのテスト(制限時間内の大規模入力含む)に合格した場合に「正解」となります。1ラウンド内の全モデルのペアについて、テスト通過率で勝敗を判定します。完全な同点の場合にのみ速度が考慮され、サンドボックス内での合計実行時間が25%以上かつ20ms以上高速だったコードが勝利し、それ以外は引き分けとなります。モデルが回答を生成するまでにかかった時間は勝敗に一切影響しません。2026年10月28日までは正解同士の判定に回答生成時間を使用していましたが、現在は保存された対局データから現行ルールで全レーティングを再計算しています。
- レーティング
- 全デュエルに対して一括でBradley–Terryモデルを適用します(バトル投票と同様の手法)。中央値のモデルを1000とするEloスケールで、100回のブートストラップ再サンプリングによる95%信頼区間を算出し、レーティング対象ラウンドが10回未満のモデルは末尾に掲載されます。プロバイダーエラーで回答できなかったモデルはそのラウンドから除外され、2時間(アカウントまたはモデルエラー時は24時間)出場停止となります。
- 注意事項
- このレーティングは事前の動作確認なしでの1回の試行を評価するものであり、限られたトークン制限下でのpass@1を測定しています(モデルが全力を尽くした状態とは異なります)。実行時間は共有サーバー上で測定されるため、わずかな差はノイズとなり得ます。そのため明確な差がある場合のみ速度差として判定しています。制限時間はPythonを基準に調整されているため、通常より高速に動作するJavaScriptにとっては緩めの設定になっています。課題は英語のみで、71問がローテーションするため、モデルが学習時に類似の問題を見ている可能性があります。
- 再挑戦
- いずれかのテストで失敗したコードを持つモデルには、自身のコードと結果(合格したテスト数、失敗した例題の期待値と実際の返り値またはエラー内容。隠しテストおよび大規模入力テストについては入力値は伏せられ、失敗数と原因のみ)を与えてもう1度だけ試行の機会が与えられます。修正されたコードは同じテストで実行されます。これは最初の回答の下およびリーダーボード上に「修正・再試行」として表示されますが、順位やレーティングには一切影響しません。
チャート
市場チャートには収集済みのデータのみを使用しています。データが不足している箇所はその旨を明記しています。
- 価格 vs 性能
- 価格は、当サイト全体で採用している入力3トークン・出力1トークンの比率で算出した1Mトークンあたりの加重平均価格(対数スケール)です。無料モデルは除外しています。性能は、5つ以上のモデルが20票以上を獲得している場合は人間による投票のレーティング(Bradley–Terry)、それ以外はチェスのレーティング(Glicko-2)を採用しており、切り替えも可能です。それより安価でスコアの高いモデルが存在しない場合、そのモデルはパレート境界上に位置します。確定したレーティングが3つ未満の場合、境界線は暫定値を通る形となり、チャート上にその旨が表示されます。他のリーダーボードからのスコア借用は行っていません。
- リリース時期
- モデルの四半期は、OpenRouterのカタログに追加された日付に基づきます(通常はリリース後数日以内)。日付付きのスナップショット版(「0902」など)は個別にカウントされません。カタログには当サイトが追跡を開始した2026年10月時点で提供されていたモデルのみが掲載されているため、それ以前の四半期については、その時点で廃止されていたモデルが含まれていません。
- 国・地域
- OpenRouterの各開発元は、当サイトの内部テーブルに基づいて各ラボの本社所在地にマッピングされています。コミュニティによるファインチューニング版、非公開モデル、拠点を特定できないラボは「その他 / 不明」に分類されます。ロシアのラボ(Yandex、Sber GigaChat、T-Bankなど)はOpenRouterに未登録のため、チャートにはロシアは表示されません。
- オープンウェイト
- OpenRouterにHugging Faceリポジトリ(hugging_face_id)が登録されているモデルを「オープンウェイト」、それ以外を「商用・独自(プロプライエタリ)」として扱います。これはモデルの重みが公開されていることを示すものであり、ライセンスがオープンであることを意味するわけではありません(多くのオープンウェイトモデルで商用利用が制限されています)。
- トークンシェア
- OpenRouterがCC BY 4.0ライセンスのもとで公開している、モデルごとの日次トークン数およびラボごと(上位9社とその他)の週次トークン数を取得しています。6時間ごとに取得し、モデルごとに1日1回の7日間スナップショットを保持し、進行中の週は完了するまで除外されます。これはOpenRouter上のトークンシェアであり、市場全体のシェアではありません。直接のAPI利用、チャットアプリ、エンタープライズ契約のトラフィックは含まれず、安価なモデルや無料モデル、自律エージェントで多用されるモデルの比重が高くなります。データソースはOpenRouterのランキングページの内部データであり、公開APIではないため、仕様変更があった場合は直近の保持データをそのまま表示します。
- オープンデータ
- チャートページのすべてのデータは、/api/v1/charts でJSON形式として取得可能です。
ニュース
客観的なデータを最優先し、次いでベンダー自身の発表を掲載します。
- 独自イベント
- 新モデルの登場、価格改定、提供終了、障害情報、アリーナの首位交代などは、上記データから人手を介さず自動生成されます。
- 外部ソース
- 各ベンダーの公式ブログ(RSS経由)、主要ツールのGitHubリリースページ、およびHacker Newsで150ポイント以上を獲得したAI関連の話題を15分ごとにチェックしています。
- 編集・要約
- 小型言語モデルが見出しと1行の要約を作成し、重要度を1〜5で評価して重複記事を特定します。モデルが参照するのはタイトルとRSSの概要のみで、記事本文全体を読むことはありません。すべての記事に出典へのリンクが記載されています。
制限事項
本サイトが現在把握できない領域について。
- 単一拠点からの監視
- 監視チェックはフィンランドにある1台のサーバーから実行されています。他地域特有の障害は検出されない可能性があり、また弊社側のネットワーク障害がベンダー側の問題のように見えるリスクがあります。そのため、他の指標と矛盾する場合に単一のシグナルだけで判定を下すことはありません。
- 一部のAPIへの非対応
- 機械可読なステータスページを持たないベンダーが存在し、また独自チェックにはベンダーごとのAPIキーが必要です。いずれも存在しない場合、ステータス判定はOpenRouterのデータとユーザーからの障害報告のみに基づいて行われます。
- オープンデータ
- すべてのサービスの現在の稼働状況は、APIキー不要・無料で /api/v1/status からJSON形式で取得できます。