LLM比較ページの要件定義とQAチェックリスト

本稿は、公開UIを参考にした要件・テスト設計のメモです。特定サイトの内部実装やデータパイプラインを説明するものではありません。

目的を「順位表示」から分解する

モデル比較ページの目的は、順位を見せることだけではありません。利用者が、どのタスクの、どの指標を、いつの条件で比較しているかを理解し、次の検証へ進めることが目的です。

公開ページの LLMBoard AI では、能力カテゴリ、価格、速度、プロバイダーの信頼性、ベンチマーク一覧、モデルディレクトリが別の入口になっています。この分離を要件に落とすと、総合スコアと運用条件の混同を減らせます。

要件表

要件	確認内容	失敗時の表示
指標の明示	スコア、単位、タスク、測定日が見える	指標情報を表示
比較条件	benchmark名とバージョンを保持する	比較不可の注意
価格	通貨と計算単位を表示する	料金未確認
更新状態	更新日と鮮度を区別する	古いデータ
出典	根拠ページへ遷移できる	出典不明
欠損値	0と未計測を分ける	データなし

「スコアがない」を「0点」として描画しないことは、ランキングUIの最低限の契約です。

「LLM Leaderboard」をテスト観点に変える

LLM Leaderboard という検索語を、次のテスト観点へ変換します。

• タスクカテゴリを変更したとき、タイトルと表の列が連動するか
• 価格表示を開いたとき、能力スコアと同じ単位に見えないか
• モデルを比較対象から外したとき、URLと画面状態が一致するか
• ベンチマークのバージョンが違う場合、同率順位として扱わないか
• 更新日を過ぎたデータに「最新」という表現を残していないか

Playwrightの例

以下は実装済みセレクタではなく、契約を表すための例です。

test('ranking context remains visible', async ({ page }) => {
  await page.goto('/leaderboard?task=coding');
  await expect(page.getByRole('heading', { name: /coding/i })).toBeVisible();
  await expect(page.getByText(/measured|updated/i)).toBeVisible();
  await expect(page.getByRole('table')).toBeVisible();
});

セレクタの名前より、テストが守る契約のほうが重要です。ランキングの数値だけをスナップショットにすると、出典や更新日が消えても検知できません。

QAで残すログ

テスト結果には、モデルID、ベンチマーク名、バージョン、測定日、表示単位、比較対象を残します。データが更新されたときに、見た目だけでなく意味の変化を追跡できるためです。

性能ランキングは、数字が大きいほど正しいとは限りません。比較条件を読めるUI、欠損を正しく扱う状態、再確認できる出典。この3点を要件に含めることで、ページは単なるリストではなく、検証可能な意思決定ツールになります。

更新時には、同じ条件で再表示できることも確認します。表示順位だけが変わったのか、ベンチマークの条件やデータ範囲まで変わったのかを区別できるログがあると、原因調査が短くなります。