LLMルーター: リクエストを振り分け、コスト60%削減 [2026]

LLMルーター: リクエストを振り分け、コスト60%削減 [2026]

LLMルーターとは、アプリと複数の言語モデルの間に置く薄い層で、各リクエストをどのモデルが処理するかを選びます。リクエストの中身（タスクの種類、複雑さ、トークン予算）を調べ、最適なモデルへ転送し、そのモデルでエラーが起きればバックアップへフェイルオーバーします。狙いは、トークンコストを最小に抑えながら、タスクに見合った回答を得ることです。

「返金ポリシーは？」という質問にフロンティアモデルで答えるのは、請求額を膨らませる典型パターンです。AWSは2025年4月に代替策を計測しました。分類器ルーターはレイテンシを0.53秒、セマンティックルーターは0.10秒追加し、同一モデルファミリー内のルーティングで請求額を最大30%削減します。この計算を2026年7月のリスト価格でベンダー横断に再計算すると（後述）、削減率は70%に達します。節約分の大部分は、トークンが1つも生成される前に下される、たった1つの判断から生まれます。

重要なポイント

• LLMルーターは、タスクの種類、コスト、または計測した品質に基づいて、各リクエストを処理するモデルを決めます。
• 戦略は5つあります。ルールベース、コスト考慮、レイテンシ考慮、セマンティック（埋め込み）、LLM分類器ルーティングです。
• ルールベースルーティングは約0msと0ドルを追加します。分類器ルーティングは1リクエストあたり300〜800msと分類器のトークンコストを追加します。
• シンプルなトラフィックの大部分を10〜20倍安いモデルへ振り向けると、ルーティングでトークン支出を最大60%削減できます。
• プロバイダーが1社だけで、1日1万リクエスト未満、コスト圧力もなし？ルーターは不要です。素のフォールバックで十分です。

LLMルーターは実際何をするのか？

LLMルーターは、モデル呼び出しの前に小さな判断ステップを実行します。リクエストを読み、ルーティングルールに照らしてスコアリングし、モデルを選び、呼び出しを送り、最初のモデルでエラーが起きればフォールバックでリトライします。アプリ側のそれ以外は何も変わりません。これまで通り1回リクエストして1回レスポンスを受け取ります。

リクエストのライフサイクルは順に次の通りです。

1. リクエスト到着。 ルーターのエンドポイントに、モデルAPIに届くのと同じ形で届きます。
2. 分析。 ルーターがプロンプトを調べます。キーワード、トークン数、埋め込み、または分類器スコアを確認します。
3. 選択。 ルーティング戦略がそのシグナルをモデル階層（低価格、中位、フロンティア、またはローカル）へ対応付けます。
4. 転送。 呼び出しはOpenAI互換APIを通じて選ばれたモデルへ送られます。
5. フォールバック。 タイムアウト、レート制限、エラーが起きた場合、リクエストはチェーン内の次の階層でリトライされます。

「llm gateway vs router」と検索される人が多いのは、ベンダーのドキュメントが用語を曖昧に使っているからです。一文で整理できます。ゲートウェイは配管、ルーターは判断です。両者は層であって競合ではなく、たいていのゲートウェイは内部にルーターを備えています。

LiteLLMのドキュメントによれば、仮想キーを保持するのと同じプロキシがルーターも実行します。配管レベルのツールだけを比較したい場合は、LLMゲートウェイツールのまとめ記事で10本をランキングしています。

そもそもLLMルーターは必要か？

小規模アプリの大半には不要です。ルーターが元を取るのは、トラフィックが明確に異なるタスク種類に分かれるとき、トークン請求額がインフラコストの筆頭であるとき、または複数のプロバイダーを運用していてフェイルオーバーが必要なときです。これらの閾値を下回るなら、素のリトライと1つのフォールバックモデルで、可動部品を増やさずに信頼性は手に入ります。

あえて率直に言います。この領域でそう言う人はほとんどいませんが、1日1万リクエスト未満でプロバイダーが1社だけなら、ルーターは不要なオーバーヘッドです。素のフォールバックが勝ちます。

なぜここまで率直に言うのか？すべてのルートは1つの主張（「このタスククラスは安いモデルで安全」）であり、モデル・価格・プロダクトが変わるにつれて劣化するからです。節約分がメンテナンスコストを明確に上回るときだけ、そのコストを引き受けてください。

5つのLLMルーティング戦略（それぞれの使いどき）

すべてのLLMルーティング戦略は、1つの問いに答えます。「モデルを選ぶのに十分なほど、どのシグナルを信頼するか？」です。ルールはキーワードを信頼します。コストルーティングはトークン予算を信頼します。レイテンシルーティングはタイマーを信頼します。セマンティックルーティングは埋め込みを信頼します。分類器ルーティングは別のLLMを信頼します。トレードオフは常に同じ形です。シグナルの質が上がるほど、1リクエストあたりの追加レイテンシとコストが増えます。

オートコンプリートはこれらを「llm routing strategies」「llm task routing」「llm intent routing」「llm dynamic routing」として表示します。これらは5つのパターンに対応します。

5つすべてを貫くパターンが1つあります。カスケード（モデル階層化とも呼ばれます）です。安いモデルから始め、失敗または低信頼のときだけエスカレートします。サポートボットは100万トークンあたり0.25ドルのモデルで答え、信頼度が0.7を下回れば、同じリクエストをフロンティアモデルでリトライします。安い階層が「行き詰まった」と認めたときだけ、知性に対価を払います。

学術的な深さとしては、ulab-uiucのLLMRouterライブラリが16種類以上の研究済みルーティングアルゴリズム（KNN、SVM、MLP、行列分解、Elo、グラフ、BERT系）をカタログ化しています。セマンティックルーティングを選ぶなら、例示の埋め込みがほぼすべてを決めます。埋め込みモデルのガイドでは、実コーパスで耐えるモデルを解説しています。

LLMルーターをPythonでどう構築するか？

OpenAI互換エンドポイントに対して、素のPython約80行で構築できます。フレームワークは不要です。以下の4つのルーターは、洗練度を段階的に上げていきます。キーワードルール、コスト閾値、埋め込み類似度、そしてフェイルオーバー付きの分類器モデルです。それぞれ選んだモデルを表示するので、判断が起きる様子を確認できます。

「how to build an llm router」と検索してAWS CDKスタックと学術リポジトリしか見つからなかったなら、このセクションがその素直な答えです。AWSのリファレンス実装は堅牢ですが、Bedrock、Lambda、CDKに溶接されています。私たちのものはOpenAIクライアントが指すどこででも動きます。OpenAI、プロキシ経由のAnthropic、ノートPC上のOllama、GPUボックス上のvLLMです。まずクライアントにスケッチするルーターはこれです。

ステップ1：ルールベースルーター（キーワードからモデルへ）

レイテンシゼロの基準線です。正規形マップが判断し、一致しないものはすべてフロンティア階層へ送ります。

import re
from openai import OpenAI

client = OpenAI()  # works with OpenAI, Ollama, vLLM, or a LiteLLM proxy

def ask(model: str, prompt: str) -> str:
    r = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
    )
    return r.choices[0].message.content

ROUTES = [
    (re.compile(r"\b(refund|cancel|invoice|password|hours)\b", re.I), "gpt-5-mini"),
    (re.compile(r"\b(summarize|translate|rewrite)\b", re.I), "gpt-5-mini"),
]
FRONTIER = "gpt-5"

def rule_router(prompt: str) -> str:
    for pattern, model in ROUTES:
        if pattern.search(prompt):
            return model
    return FRONTIER

prompt = "How do I cancel my subscription?"
model = rule_router(prompt)
print(model)  # gpt-5-mini: regex hit on "cancel"
print(ask(model, prompt))

入力：サポートの質問。判断：「cancel」への正規形一致。選ばれたモデル：gpt-5-mini。ルーティングにAPIコールは不要で、だからこそこれがデフォルトのままです。

ステップ2：コスト考慮ルーター（トークン予算閾値）

同じ考え方ですが、シグナルはキーワードではなくリクエストサイズです。出力予算が小さい短いプロンプトは安いモデルへ、それ以外はフロンティアへ送ります。

def cost_router(prompt: str, max_output_tokens: int = 500) -> str:
    word_count = len(prompt.split())
    if word_count < 60 and max_output_tokens <= 300:
        return "gpt-5-mini"  # $0.25 in / $2 out per M tokens
    return "gpt-5"           # $1.25 in / $10 out per M tokens

prompt = "Write a two-line product description for a ceramic mug."
model = cost_router(prompt, max_output_tokens=120)
print(model)  # gpt-5-mini: short prompt, small output budget

雑ですか？はい。効果的ですか？これもはい。トークン量は、多くの人が思うよりタスクサイズとよく相関するからです。これは有料の「cheap llm router」製品いくつかの全戦略そのものです。

ステップ3：セマンティックルーター（埋め込みから例示へ）

キーワードをすり抜ける曖昧なユーザー入力には、プロンプトを埋め込み、埋め込み済みの例示プロンプトと比較します。最も近いクラスタがそのリクエストを引き取ります。

import numpy as np

EXEMPLARS = {
    "gpt-5-mini": [
        "classify this support ticket into a category",
        "extract the shipping address from this email",
    ],
    "gpt-5": [
        "debug this race condition in our worker pool",
        "design a multi-tenant billing schema",
    ],
}

def embed(texts: list[str]) -> np.ndarray:
    r = client.embeddings.create(model="text-embedding-3-small", input=texts)
    return np.array([d.embedding for d in r.data])

CENTROIDS = {m: embed(xs).mean(axis=0) for m, xs in EXEMPLARS.items()}

def semantic_router(prompt: str) -> str:
    v = embed([prompt])[0]
    scores = {
        m: float(np.dot(v, c) / (np.linalg.norm(v) * np.linalg.norm(c)))
        for m, c in CENTROIDS.items()
    }
    return max(scores, key=scores.get)

print(semantic_router("pull the tracking number out of this message"))
# gpt-5-mini: closest to the extraction exemplars

ルーティング呼び出しのコストは埋め込み1回（数百トークン）と50〜150msです。セントロイドは起動時に事前計算し、リクエストごとには計算しません。

ステップ4：フォールバック付きLLM分類器ルーター

最強のシグナルです。安いモデルがプロンプトを読み、難易度をスコアリングします。これはAWSが追加レイテンシ0.53秒と計測した戦略なので、フォールバックチェーンで包みます。

def classify_router(prompt: str) -> str:
    verdict = client.chat.completions.create(
        model="gpt-5-mini",
        messages=[{"role": "user", "content":
            "Reply HARD or EASY only. Task: " + prompt}],
        max_tokens=5,
    ).choices[0].message.content.strip().upper()
    return "gpt-5" if verdict.startswith("HARD") else "gpt-5-mini"

def route_and_call(prompt: str) -> str:
    model = classify_router(prompt)
    try:
        return ask(model, prompt)
    except Exception:
        backup = "gpt-5-mini" if model == "gpt-5" else "gpt-5"
        return ask(backup, prompt)  # fallback tier catches the failure

print(route_and_call("Prove this greedy algorithm is optimal."))
# classifier says HARD, so gpt-5 answers

これがLLMルーター例の全体です。関数4つ、クライアント1つ、すでに運用しているもの以外のインフラは不要です。本番向けの堅牢化は次のセクションです。

LLMルーティングは実際いくら節約するのか？

AWSはルーターのオーバーヘッドを、1日10万質問あたり月107.90〜188.90ドルと計測しました。分類器ルーティングは1リクエストあたり0.53秒、セマンティックルーティングは0.10秒を追加します。節約側はこのオーバーヘッドを圧倒します。以下の実例計算は2026年7月のリスト価格に基づき、支出の70.7%削減に着地します。落とし穴はトラフィック構成です。リクエストの大部分が安い階層に適合する必要があります。

テーブルを2つ。まず、ルーター自体が1,000リクエストあたりいくらかかるかです。

AWSの2025年4月の投稿は、この領域で唯一独立して公開された計測セットなので、これを基準にし、拡張部分は実行した数値ではなく推定として明示します。AWSによれば、Bedrock Intelligent Prompt Routingはファミリー内コストを最大30%削減しました。

次に、見出しの根拠となる節約の実例計算です。

前提条件（明示）：月10万リクエスト、1リクエスト平均で入力800トークン＋出力200トークン、シンプル80%/複雑20%の比率、2026年7月時点のAnthropicの料金ページとOpenAIの料金ページのリスト価格。全レート表はLLM API料金比較にあります。1リクエストあたりの計算：Sonnet 4は800 x 3ドル/M + 200 x 15ドル/M = 0.0054ドル、GPT-5 miniは800 x 0.25ドル/M + 200 x 2ドル/M = 0.0006ドル。

結果は70.7%の削減で、タイトルにある60%はここから来ており、余裕があります。正直な注意点：これは実例計算であり、私たちが実行したベンチマークではありません。安い階層が10〜20倍安く、トラフィックの80%が本当に適合することを前提としています。AWSのシナリオであるファミリー内ルーティングは30%付近にとどまります。そしてルーティングは多くのレバーの1つに過ぎません。プロンプトキャッシュとトリミングの方が早く回収できることが多く、LLM APIコスト削減のガイドでは12の方法すべてをランキングしています。

本番のルーティングパターン

おもちゃのルーターはモデルを選びます。本番のルーターはさらに、リトライし、負荷を分散し、繰り返しをキャッシュし、チームごとにAPIキーを分離します。1日数千リクエストを超えたら、それらを手作りするのはやめ、ルーターを内蔵したゲートウェイを運用してください。

重要なパターンは4つです。

• フォールバックチェーン。 最初に安い階層、エラーまたはタイムアウト時にフロンティア。単独で最も価値の高いパターンです。信頼性の大部分はこれだけで得られます。
• ロードバランシング。 重複デプロイやAPIキーをまたいで呼び出しを分散し、キーごとのレート制限を回避します。
• レスポンスキャッシュ。 同一プロンプトはキャッシュされた回答を返します。サポートトラフィックは想像以上に繰り返します。命中率10〜30%は一般的です。
• 仮想キーと予算。 月間上限付きのチームごとのキーを発行し、1つの暴走ループが請求全体を焼き払えないようにします。

これは、私たちのステーシング用エージェントスタックで運用している設定に近いものです（ファイル：litellm-router.yaml、LiteLLMプロキシコンテナにマウント）。

model_list:
  - model_name: cheap
    litellm_params:
      model: openai/gpt-5-mini
  - model_name: frontier
    litellm_params:
      model: anthropic/claude-opus-5

router_settings:
  routing_strategy: simple-shuffle
  fallbacks: [{"cheap": ["frontier"]}]
  num_retries: 2
  timeout: 30

各ツールの位置づけと、私たちの意見です。

• LiteLLM。 セルフホストでオープンソース、すでにDockerを運用しているなら選びます。LiteLLMプロキシセットアップガイドで、キーと予算を含む完全なデプロイを解説しています。
• OpenRouter。 数百のモデルを1つのキーで、運用ゼロで使いたいなら選びます。ランキングページはスループットデータも兼ねています。
• Portkey。 エンタープライズ要件（SSO、監査ログ、コンプライアンスレポート）が判断を左右するなら選びます。
• この記事のカスタムコード。 1日約5万リクエスト未満で、新しいインフラをゼロにしたいなら選びます。

どれを選んでも、LLMゲートウェイツールのまとめ記事が10本を直接比較しています。

ローカルモデルとホステッドAPIの間でルーティングできるか？

できます。そしてトークンの計算は魅力的です。ローカルモデルはトークンあたり0ドルで課金するので、OllamaやvLLMが答えるすべてのリクエストが純粋な節約です。トレードオフは、ワットあたりのレイテンシと品質です。すでに所有するハードウェアでの大量シンプルタスクにはローカルが勝ち、フロンティアの頭脳が必要なものはすべてホステッドAPIが受け止めます。

仕組みは拍子抜けするほど単純で、それが要点です。Ollamaはlocalhost:11434/v1でOpenAI互換エンドポイントを公開し、vLLMも同じ形を提供します。したがって上記のすべてのルーターが無変更で動きます。base_urlをローカルサーバーに向け、安いスロットにqwen3:8bを入れ、gpt-5をフォールバック階層として保持します。セルフホストのルーターボックスには、LiteLLMがDockerイメージとして提供されており、これが人々の検索する「llm router docker」セットアップです。

正直な注意を2つ。1台のA100上の70Bモデルは、おおむね秒30〜40トークンを提供します。ホステッドAPIはバーストスループットでこれを上回るので、ローカルルーティングはスパイクのあるユーザー向けチャットより、安定したバックグラウンドトラフィックに向きます。またローカルの8Bモデルはマルチステップのツール呼び出しをしくじるので、難しいルートはクラウドに向けたままにしてください。サービングエンジン自体を選ぶなら、vLLM vs SGLangが両者をベンチマークしています。

ルーティングはマルチモデルのコーディングエージェント構成にも力を発揮します。LiteLLMスタイルのプロキシは、Claude Codeがローカルとホステッドのモデルに1つのエンドポイントで話せるようにします。正確な配線はClaude Codeで異なるモデルを使うを参照してください。

ルーティングが機能しているか、どう分かるか？

計測するか、さもなくば推測です。すべてのリクエストでどのモデルが答えたかをログに残し、出力のサンプルをルーブリックで採点し、そのスコアをルーティングルールへフィードバックします。このステップを省いたチームは、モデルと価格が足元で変わる中で静かに腐っていく静的設定を抱えることになります。

卒業のアークは、ルール、次にコスト、そして計測した品質の順に進みます。

1. ルートをログする。 選んだモデル、レイテンシ、トークン数を、リクエストごとに既存のトレースの1カラムとして保存します。
2. 出力を週次で採点する。 LLM審査または人間のサンプルで、リクエストクラスごとに合格/不合格。クラスごとに50件の採点済み出力があれば、判断の指針として十分です。
3. 再チューニングする。 あるクラスで安い階層が95%以上合格するなら、そのトラフィックをより多く取り込むようルールを広げます。90%を下回れば絞ります。

クライアントに繰り返し伝えている一文があります。再チューニングしないルーターは、追加レイテンシを載せた静的設定に過ぎません。選んだモデルをログし、出力を採点し、スコアをフィードバックしてください。

このループは、evalとオブザーバビリティをルーティングに適用したものです。LLM evalガイドが採点ルーブリックを、AIオブザーバビリティガイドがトレースの置き場所を解説しています。

LLMルーティング研究はどこへ向かうか？

学術の流れは、ルーティングを設定ファイルではなく学習問題として扱います。このキーワードで1位にランキングするulab-uiucのLLMRouterは、16種類以上のアルゴリズム（KNN、SVM、MLP、行列分解、Elo、グラフ、BERT、RLルーター）を、11データセットにわたるベンチマークパイプライン付きで実装しています。最近で最も引用される論文RouteLLM（Ong et al., arXiv:2406.18665）は、人間の嗜好データでルーターを訓練し、MMLUとMT-Benchで品質を落とさず2倍以上のコスト削減を報告しています。最新の動き：prefill-activationルーター、いわゆる「prefill is all you need」系は、生成が始まる前にモデルの内部活性をprefill中に読み取り、難易度を予測します。進む方向は、あなたのevalデータから自ら訓練するルーターであり、まさに前のセクションのフィードバックループそのものです。

Techsyのアプローチ： B2Bクライアントに提供するエージェントスタックは、まさにこのパターンで動いています。ゲートウェイに組み込んだフォールバックチェーン付きコスト階層ルーターと、eval駆動の再チューニングです。ルーティングがスタックに合うか検討中なら、無料相談をご用命ください。トラフィック構成を一緒にマッピングします。

著者について

Mert BaturはTechsy.ioの共同創業者で、チームはB2Bクライアント向けにAIエージェント、自動化システム、音声/SDRパイプラインを提供しています。Techsyチームが実際に本番で使っているLLMツーリングスタックについて執筆しています。LinkedInでつながる。

よくある質問

LLMルーターとは何ですか？

LLMルーターは、アプリケーションと複数の言語モデルの間にあり、各リクエストをどのモデルが処理するかを決める層です。リクエストのタスク種類、サイズ、難易度を確認し、最適なモデルへ転送し、そのモデルが失敗した場合のフォールバックを備えます。モデルAPI呼び出しの交通管制官だと考えてください。

LLMルーティングはどう機能しますか？

LLMルーティングは5ステップで動きます。リクエストが到着し、ルーターがそれを調べ（キーワード、トークン数、または埋め込み）、戦略がモデル階層を選び、呼び出しが転送され、フォールバックモデルが失敗を受け止めます。判断全体は生成開始前に起きるので、分類器モデルがスコアリングしない限り、追加は秒ではなくミリ秒です。

LLMルーターはLLMゲートウェイと同じですか？

いいえ。ゲートウェイは配管です。APIキー、レート制限、予算、ログです。ルーターは判断です。どのモデルが答えるかです。両者は層であって競合ではなく、たいていのゲートウェイ（LiteLLM、Portkey、OpenRouter）は内部にルーターを備えています。ゲートウェイなしでルーターを動かせますが、本番では通常、両方を一緒に使います。

モデルルーティングは実際にお金を節約しますか？

はい。トラフィックの大部分が、はるかに安い階層に適合する場合です。私たちの実例計算は、リクエストの80%を100万トークンあたり3ドル/15ドルのモデルから0.25ドル/2ドルのモデルへ移し、請求額を70.7%削減します。AWSは同一モデルファミリー内のルーティングで最大30%を報告しています。トラフィックが一様に複雑なら、節約はゼロに近づきます。

最高のオープンソースLLMルーターは何ですか？

本番向けにはLiteLLMです。セルフホスト、活発にメンテナンスされ、ゲートウェイとルーターを兼ねます。研究グレードのアルゴリズムには、ulab-uiucのLLMRouterが学術文献から16種類以上のルーティング戦略を実装しています。RouteLLMは、嗜好データで訓練された、ドルあたり品質で最強のルーターです。大半のチームはLiteLLMから始め、カスタムスコアリングが必要なときだけ研究ライブラリに手を伸ばすべきです。

LLMルーターをPythonでどう構築しますか？

OpenAIクライアントと約80行のコードから始めます。キーワードからモデルへのルールマップ、トークン数のコスト閾値、例示プロンプトとの埋め込み類似度、または難易度をスコアリングする安い分類器モデルです。4つのパターンすべてが上記の構築セクションにあり、OpenAI、Ollama、vLLMに対して無変更で実行できます。

ローカルモデルとクラウドAPIの間でルーティングできますか？

はい。Ollama（localhost:11434/v1）とvLLMはどちらもOpenAI互換エンドポイントを公開するので、同じルーターコードが、安いトラフィックにはローカルモデルを、難しいトラフィックにはホステッドAPIを指します。ローカルトークンは0ドルですが、ハードウェアとレイテンシは自分で抱えます。これはマルチモデルのClaude Code構成の大半の背後にあるパターンです。

セマンティックルーティングとは何ですか？

セマンティックルーティングは、到着した各プロンプトを埋め込み、埋め込み済みの例示プロンプトと比較して、最も近い例示クラスタを持つモデルへリクエストを送ります。キーワードルールが逃す、曖昧で言い換えられたユーザー入力を処理します。コストは1リクエストあたり50〜150msと埋め込みトークンです。AWSは追加レイテンシ0.10秒と計測しました。

LLM分類器ルーターはどれくらいレイテンシを追加しますか？

AWSは、LLM支援分類の追加レイテンシを0.53秒と計測しました。セマンティックルーティングの0.10秒に対してです。ルールベースとコスト考慮ルーティングは、純粋なコードパスなので、おおむねゼロを追加します。製品に厳しい応答時間SLAがあるなら、ルール、コスト閾値、または埋め込みを優先し、分類器はオフラインまたはキューイングされたワークロードにとっておいてください。

出典

• Seifi, N. and Chugh, M. (2025-04-09). "Multi-LLM routing strategies for generative AI applications on AWS." AWS Machine Learning Blog. https://aws.amazon.com/blogs/machine-learning/multi-llm-routing-strategies-for-generative-ai-applications-on-aws/ （2026年7月30日アクセス）
• AWSサンプルコード：sample-multi-llm-dynamic-prompt-routing. https://github.com/aws-samples/sample-multi-llm-dynamic-prompt-routing （2026年7月30日アクセス）
• LiteLLMドキュメント. https://docs.litellm.ai （2026年7月30日アクセス）
• Anthropic料金. https://www.anthropic.com/pricing （2026年7月30日アクセス）
• OpenAI API料金. https://openai.com/api/pricing （2026年7月30日アクセス）
• ulab-uiuc LLMRouter. https://github.com/ulab-uiuc/LLMRouter （2026年7月30日アクセス）
• Ong, I. et al. (2024). "RouteLLM: Learning to Route LLMs with Preference Data." arXiv:2406.18665. https://arxiv.org/abs/2406.18665 （2026年7月30日アクセス）
• OpenRouterランキング. https://openrouter.ai/rankings （2026年7月30日アクセス）