エディタ内でライブ利用し、AI モデルを最適に選択する方法

AI モデルを選ぶ際は、まず行うべきタスクを明確にし、実際の利用状況やベンチマークデータから候補を絞り込みます。その後、各プロバイダー間の価格とレイテンシを比較し、最終候補を実際の自分のプロンプトでテストします。評価基準はトークンあたりのコストではなく、「完了したタスクあたりのコスト」に置くべきです。また、新しいモデルがリリースされるたびに最適な回答も変わることを想定しておく必要があります。

ここでは「唯一最高のモデル」として特定の名称を挙げるつもりはありません。もし名前を挙げたとしても、1 ヶ月後には古くなってしまいます。また、どのモデルが最適かは、あなたが何を作ろうとしているか、そして正確な結果を得るためにいくら支払う覚悟があるかによって異なります。

この記事では、その質問に答えるために私たちが採用しているフレームワークと、エディターから離れることなくそれを実行する方法を解説します。当社の MCP サーバー を介して、アシスタントは実際の利用状況ランキング、第三者によるベンチマーク、各プロバイダーごとの価格情報にアクセスでき、さらに候補モデルへのテストプロンプト送信も可能になります。

結論（要約）

• 「ベスト」の定義は、あなたのタスク内容、完了したタスクあたりのコスト、そして許容できるレイテンシです。リーダーボードでの順位はこれら 3 つには含まれません。
• 候補を絞り込むにはベンチマークを活用し、最終的な勝者を選ぶには自分自身でプロンプトを作成して比較してください。Ori Eval を使えば、この比較の作成と実行も自動化できます。
• エディターから MCP を経由してライブランキングや価格を照会し、get-generation コマンドを使って各テスト呼び出しのコストを実測してください。
• 明確な勝者がいない場合は、特定のモデルを選ぶのではなく、リクエストごとに openrouter/auto-beta でルーティングすることを検討してください。

なぜ「最高の AI モデル」とは存在しないのか

「世界で最も優れた AI モデル」などというものは存在しません。重要なのは、特定のタスク・予算・タイミングにおいて「最適なモデル」を選ぶことです。

タスクごとに求められる強みは異なります。要約とコーディングではモデルに異なる負荷がかかりますし、データ抽出においては流暢な文章よりも、すべての呼び出しで正確な JSON を返す能力が求められます。チャット機能では回答の質そのものよりも、最初のトークンが届くまでの速度が重要になります。

あるベンチマークでコーディング性能が一位だったモデルでも、長いドキュメントの処理では振る舞いが悪かったり、日常的な抽出タスクにはコストが高すぎたりする可能性があります。

より有益なのは、「何のために使うか」を具体的に問うことです。「どの AI モデルが最強ですか？」と聞くのではなく、「スキャンされた請求書から行項目を抽出するには？」「TypeScript のプルリクエストレビューには？」「90 分の通話記録の要約には？」といった具体的な問いを立て、最新のデータに基づいて回答を出すべきです。

当社のトラフィックデータを見ると、タスクによって最適な回答モデルは大きく異なることがわかります。私たちはリクエストのサンプルを 29 のタスクタイプに分類し、市場シェア を公開しています。コーディング関連だけで 9 つのタスクが含まれており、コード生成、デバッグ、コードレビュー、リポジトリのスキャン、SQL 作業、DevOps 設定などが該当します。しかし、これら 9 つのタスクに共通するリーダーは存在しません。2026 年 7 月 25 日までの 7 日間において、あるモデルが 8 つのタスクで首位を占めた一方で、コードレビューとセキュリティでは別のモデルがトップでした。「コーディングに最適なモデル」という問い自体が、コーディングという分野の中でも広すぎます。

ベンチマークは絞り込みのフィルターであり、答えそのものではない

ベンチマークは、数百ある選択肢から実際にテストできる数候補に絞り込むために有用です。私たちは、Artificial Analysis や Design Arena などの第三者によるスコアと、自社の利用データを併せて提示しています。

リーダーボードが最終的な選択を代行することはできません。スコアにはノイズが含まれており、人気のあるベンチマークではチューニングが行われる可能性があり、いずれもあなたの具体的なプロンプトで評価されたものではありません。リーダーボードは候補を絞り込むために使い、最終判断は自分自身で行うテストに基づいてください。

異なるタスクにはそれぞれ適した強みが求められます。コーディングには推論の質と、ツール呼び出しの信頼性が不可欠です。要約には長いコンテキストウィンドウと低い入力コストが必要です。構造化されたデータからの抽出では、流暢さよりもスキーマへの厳密な準拠が重要になります。チャットには低遅延が求められます。ビジョン（画像認識）においては、そもそも画像を受け付けられるモデルであることが最優先条件であり、これが品質を比較する前に候補を大幅に絞り込みます。

どのモデルがすべてのカテゴリで最上位を独占することはありません。万能なモデルを選んでも、デモでは良好に動作しても実際の業務ではコストが高くパフォーマンスも低いという「デフォルトの罠」にはまります。

OpenRouter MCP サーバーの設定

以下の手順はすべて MCP サーバーを経由して実行されるため、まず接続してください。

OpenRouter MCP サーバー は当方でホストしているため、ローカルへのインストールは一切不要です。あらゆる MCP クライアントが接続可能です。以下のセットアップ手順では Claude Code、Cursor、Codex CLI に対応していますが、ドキュメントには OpenCode や Claude Desktop の設定も記載されています。

一度接続すれば、エディタから離れることなく、アシスタントがライブモデルの取得、価格やクレジット残高、ランキング、ベンチマーク、ドキュメントの参照、テストプロンプトの実行をすべて行えます。モデル選定中はこれを利用し、本番リリース時には通常通り API を呼び出してください。

Claude Code:

claude mcp add --transport http openrouter https://mcp.openrouter.ai/mcp
claude mcp login openrouter

セッション内から認証することも可能です。/mcp コマンドを実行して openrouter を選択し、Authenticate ボタンをクリックします。

Cursor: ~/.cursor/mcp.json に以下の設定を追加し、cursor-agent mcp list で確認してください。

{
  "mcpServers": {
    "openrouter": { "url": "https://mcp.openrouter.ai/mcp" }
  }
}

Codex CLI:

codex mcp add openrouter --url https://mcp.openrouter.ai/mcp
codex mcp login openrouter

認証はブラウザでのワンステップで完了し、3 つのエディタすべてで同じ手順です。Cursor ではログインコマンドではなく、最初のリクエスト時に自動的に実行されます。未認証のリクエストには 401 エラーが返され、OAuth フローが開始されます。承認画面では、同意する前に何に同意するのかを明確に表示します。

この画面では、クライアントに限定された OpenRouter MCP: <アプリ名> というラベルのキーが発行されます。有効期限は 7 日で、クレジット制限はデフォルトが$10 ですが、この画面で変更可能です（MCP 発表）。このキーは短期間で失効し、デフォルトで上限が設定されているため、いつでも切断できます。また、キー管理ダッシュボード から即時取り消しも可能です。 （原文の技術表記: OpenRouter MCP: <app name>）

フローが localhost へリダイレクトされます。Claude Code や Cursor のようなデスクトップクライアントではこれが正常な動作ですが、その結果、どのローカルアプリがキーを受け取ったかを確認することができなくなります。直前に自分自身で接続を開始した場合のみ、承認してください。

使用するツール

多くの機能は、ライブデータに対する読み取り専用の照会です。ただし例外として、send-message（メッセージ送信）、generate-image（画像生成）、transcribe-audio（音声文字起こし）、generate-speech（音声合成）の 4 つは、

課金対象の推論呼び出しと、send-feedback という機能です。

自分の生成物に対してフィードバックを書く（MCP ドキュメント を参照）。

モデル選定のための 6 ステップ・フレームワーク

以下の手順を順番に実行してください。2～5 のステップは、アシスタントがリアルタイムデータに対して実行できる特定の呼び出しに対応しています。1 と 6 はあなたの判断に委ねる部分です。まず必要なものを定義し、最後に何をリリースするかを決めます。

ステップ 1. リリースするタスクを明確にする

モデル名から入るのではなく、まずは「何をするか」から始めましょう。入力と期待される出力、品質の基準、レイテンシの目標、そしてコストと品質が衝突した際にどちらを優先するかを明記します。

最後の項目は、その後のすべてのステップに影響を与えます。顧客に表示する要約であれば、高価格帯でも正当化できます。一方で、100 万件のレコードにわたる夜間の抽出ジョブであれば、多少の品質低下を許容してでも低コストで済ませるべきです。なぜなら、この場合はボリュームが請求額を支配するからです。あなたが構築しようとしているのがどちらなのかを明確にしてください。

ステップ 2. リアルタイムデータから候補を絞り込む

候補リストは、以下の 2 つの問いから導き出されます。「人々は現在このタスクのために何を使っているのか」「そのタスクで高いスコアを獲得しているのは何か」です。

まず、list-task-classifications を呼び出します。これにより、直近 7 日間のトラフィックに基づいて、29 のタスクタグそれぞれの利用シェアと、そのタスクを担当するモデルのランキングリストが取得できます。

次に、task_type に coding（コーディング）、intelligence（知能）、または agentic（自律型エージェント）を指定して list-benchmarks を呼び出します。これにより、Artificial Analysis と Design Arena のスコアと価格情報が取得できます。

この 3 つのカテゴリーは、29 のトラフィックタグよりも意図的に粗く設定されており、両方の呼び出しを組み合わせて使用することを想定しています。ベンチマークフィルターで広範なカテゴリ内で低スコアのモデルを除外し、その上で特定のタスク領域で実際に利用されているモデルを、トラフィックタグを通じて確認できる仕組みです。

list-daily-model-rankings はトレンド分析に役立ちます。デフォルトでは、このコマンドは上位 50 件のモデルの全体的なトークン総数を毎日返すほか、1 日ごとに集計された other 行も 1 つ含みます。

使用ケースのカテゴリ（例：programming や roleplay）、モダリティ、ツール呼び出しのアクティビティなどによって絞り込むことができますが、これらのカテゴリ区分は集約されたサンプリングデータセットに基づいています。

週次で更新されるため、これらの数値は概算値として捉えてください。これは「何が増加しているか」を示すものであり、「あなたの業務で実際にどのモデルが優秀か」を直接示すものではありません。

このランキングページは openrouter.ai/rankings でも確認できます。

ステップ 3：コスト、プロバイダー、レイテンシを比較する

各候補モデルに対して list-model-endpoints を呼び出します。これにより、そのモデルを提供しているすべてのプロバイダーから、過去 30 分間の価格、コンテキスト長、スループット、レイテンシ、稼働率、量子化レベル、およびサポートされているパラメータといった詳細情報を取得できます。

同じモデルでも、プロバイダーによって価格や速度、信頼性が異なる場合があります。こうした違いは本番環境で発見するのではなく、ここで事前に把握しておくべきです。

比較ページ では、ブラウザ上で同様のデータを確認でき、他者と共有したい際にも便利です。

ステップ 4：自社データで候補モデルを実際にテストする

ベンチマーク結果から候補リストを絞り込み、最終決定は自社のプロンプトで行います。

実際に手元にある作業に対して send-message を実行してください。実在するチケット、ドキュメント、スキーマ、そして通常は失敗を引き起こすようなケースを含めてください。評価セットが綺麗すぎるだけでは、どのモデルも有能に見えてしまい、結果としてモデル間の差を見分けることができません。

テスト時には3つのバリアントが役立ちます。`:floor` は、そのモデルを提供する最も安価なプロバイダへルーティングし、評価コストを抑えます。`:nitro` は最速のプロバイダへルーティングするため、レイテンシの予算チェックに利用できます。

:onlineは、タスクに最新の文脈が必要となる場合にウェブ検索機能を追加します。

:online のコストに注意してください。同じ簡単なプロンプトを 3 つの方法で実行した結果、:floor は 0.0000030 ドル、:nitro は 0.0000024 ドルでしたが、:online は 0.0052576 ドルとなりました。

これは単一のプロンプトに対する通常の呼び出しの約 2000 倍のコストがかかるため、不用意に有効にするのではなく、意図的に使用する必要があります。

Ori Eval を使って比較を再現可能にする

一時的なテスト呼び出しでは一度きりの質問にしか答えられませんが、Ori Eval を使えばこの手順を反復可能になります。例えば「サポートエージェントに最適なモデルはどれか」という素朴な問いを投げかけると、コーディングエージェントがプロジェクト内のテスト素材を見つけ、評価用ファイル *.eval.ts を作成し、候補となるモデルを実行して、スコア・所要時間・コストといった詳細を添えて推奨モデルを提示します。エディタから始めるには、コーディングエージェントに以下の指示を与えてください。

run curl -fsSL https://openrouter.ai/skills/spawn-ori-eval and follow the instructions in its output to get started

Ori は、1 つのランごとに 1 つのハネスと 1 つのモデルを解決し、そのラン内のすべてのテストでそれらを保持します。そのため、同じ評価ファイルを実行する 2 つのランは同一の設定を使用することになります。リクエストは OpenRouter を経由して送信されるため、1 つの比較には複数のプロバイダーからのモデルを含めることが可能です。

上記の手順は一時ディレクトリ上で動作しますが、マニュアル手順を実行する代わりに選択すれば、評価ファイルは通常のコードとしてプロジェクト内に残ります。これにより、新しいモデルがリリースされた際に再実行したり、--baseline オプションを使って以前のランと比較したり、スケジュールに基づいて CI で実行したりすることが可能になります。

ステップ 5. 完了したタスクあたりのコストを測定する

テスト呼び出しのたびに、生成 ID を get-generation に渡してください。これにより、正確なコスト、プロンプトと完了トークンのカウント、処理を担当したプロバイダー、そしてレイテンシが取得できます。

代表的なプロンプトセットで平均値を算出し、タスクの成功率に応じて調整した上で、その数値を意思決定ドキュメントに記録してください。

2 つ注意すべき点があります。生成レコードは呼び出しが返された瞬間には照会できないため、直後に検索を行うと 404 エラーとなり、数秒後に解決されます。最初の 404 を失敗として扱うのではなく、再試行してください。また、完了レスポンスにはすでに usage.cost が含まれているため、通話の価格のみが必要であれば、追加の往復通信は不要です。プロバイダー、レイテンシ、ネイティブトークン数も取得したい場合は get-generation を使用します。

ステップ 6. 決定するか、リクエストごとにルーティングする

実行する作業において、あるモデルが明確に優れているなら、それを使用してください。

結果が拮抗している場合、トラフィックに複数の種類のジョブが混在している場合、あるいはより優れたモデルがリリースされるたびに判断を見直したくない場合は、openrouter/auto-beta というモデル文字列を指定して Auto Router を利用してください。古くからある openrouter/auto も動作しますが、非推奨として文書化されているため、現在は新しい方を使用するのが適切です。

ルーターはランダムに選択するわけではありません。各リクエストを約 30 の細分化されたタスクタイプに分類し、直近 7 日間の実際の利用シェアに基づいて候補をランク付けします。さらに、ユーザーが設定したコストと品質の優先順位を適用し、フォールバック機能付きでルーティングを行います（Auto Router ドキュメント）。上記のフレームワークは、ステップ 2 で照会したタスク分類データと同じものを用いて、リクエストごとに実行されています。

トークン単価ではなく、タスク単価で考える

モデルの経済性を比較する際の正しい単位は「トークン単価」ではなく「タスク単価」です。

人々がトークン単価で比較するのは、計算が簡単だからであり、また過去にはフルコスト（完全な実行コスト）を測定するのが難しかったからです。しかし、get-generation が呼び出しごとに実際の数値を返すようになった今、その困難は解消されました。

単価が安くても、リトライが必要になったり、トークン予算を超えて長い補完結果を生成したり、失敗をカバーするために背後にさらに強力なモデルを必要としたりする場合は、安価ではなくなります。逆に、初回の実行でタスクを完了できる高価なモデルの方が、トータルのコストは安くなるケースも珍しくありません。

2026 年に実施された推論モデルの価格に関する調査で、この現象が実証されました。モデルペアを比較したケースの 32% で、表示価格が低いモデルの方が総コストが高くなるという逆転現象が発生しています。極端なケースではその差は最大 28 倍に達しました（Chen et al., "The Price Reversal Phenomenon"）。この原因は、各モデルが思考プロセスでトークンを消費する方式の差異にあります。同じクエリに対して、あるモデルは別のモデルより 900% も多くのトークンを使用することがありますし、同一クエリの繰り返し実行でもコスト変動幅が最大 9.7 倍になることもあります。表示価格にはこうした変動要素は一切反映されていません。

cost per task = ((input tokens × input price) + (output tokens × output price)) × expected attempts

多くの比較検討では「必要な試行回数」の期待値が考慮されず、この項目こそが結果を決定づける重要な要素となります。

2026 年 7 月 27 日に確認した実際の価格を用いた計算例を示します。GPT-5.4 mini は、入力トークン 100 万あたり$0.75、出力トークン 100 万あたり$4.50 です。一方、Claude Sonnet 5 はそれぞれ$2.00 と$10.00 で、約 2.4 倍の価格設定です。

入力トークン 2,000、出力トークン 800 のタスクを想定します。Sonnet 5 が初回試行で 95% の確率で成功する場合、1,000 タスクあたりのコストは約$12.63 になります。これと同等のコストを実現するには、mini モデルが初回試行で少なくとも 40% の成功率を達成する必要があります。もし成功率が 40% を下回る場合、トークン単価が 2.4 倍安いモデルの方が、実際には作業完了にかかるコストが高くなるのです。

他者に報告する際は「1,000 タスクあたりの完了コスト」で比較してください。トークン単価が最も安いモデルが、必ずしも作業完了に最も安価な選択肢とは限りません。

以下のチャートは、単一の点をプロットするのではなく、曲線全体を描いています。この曲線を維持する方が有用です。なぜなら、比較対象となる 2 つの候補間の価格差によって、損益分岐点は変動するためです。

価格差が広い場合、より安価なモデルは、競合他社に負ける前に許容できる成功率を大幅に下げることができます。

*同じ事例を、特定の一点ではなくあらゆる成功率の範囲でプロットしたものです。参照のために Sonnet 5 の成功率は 95% で固定し、mini モデルの成功率を変動させています。リスト価格は 2026 年 7 月 27 日時点のもので、タスクは入力トークン 2,000、出力トークン 800 です。ここでは測定値ではなく、成功率をスweep（掃引）する変数として扱っています。

タスクごとに何を最適化すべきか

これはランキングではなく、出発点です。各行には、最適化すべき対象と行うべき呼び出し先が示されており、実際のデータからモデル名を確認できます。勝者を列挙しないのは、どんなリストでも次のリリース時には古びてしまうからです。

コーディング: どの種類のコーディングを指すか明確にしましょう。タスクタグはコード生成、デバッグ、レビュー、フロントエンド、リポジトリスキャンを区別しており、各分野のリーダーモデルは異なります。候補モデルの評価には、お遊びの問題ではなく、実際のバックログから選ばれた課題でテストしてください。

要約: 入力価格とコンテキスト長はセットで確認する必要があります。どちらか一方だけを見ると誤った判断を下す恐れがあります。ウィンドウサイズが大きくても入力コストが安いモデルの方が、入力単価が高く強力なモデルよりも優れているケースが多々あります。

情報抽出: 毎日2回フィールドを破損する強力なモデルよりも、毎回必ず有効な JSON を返す小規模なモデルの方が実務では勝ります。欠落したフィールド、曖昧なレコード、書式が崩れたソーステキストなど、難しい入力ケースでのテストも必須です。

ビジョン: 多モーダル性能はドメインによって大きく異なります。画像入力を対象に絞り込み、自社のスクリーンショットで実際に評価を行ってください。一般的なデモセットでは、どの候補モデルも良く見えてしまいます。

いずれの場合も、クエリを実行して今週の実際の数値を確認し、そこから選定してください。

なぜ OpenRouter を通じてループを回すべきか

特定のモデルに一度きりでコミットする必要はありません。

1 つの統合で、すべてのプロバイダーにわたる カタログ にアクセスできます。来月より優れたモデルがリリースされた場合、別の SDK を追加して統合経路を再テストする必要はありません。モデル名を指定する文字列を変更するだけで済みます。

選択と実行は同じプラットフォーム上で完結します。また MCP（Model Context Protocol）を利用すれば、選択したモデルのデータも、すでに使用しているエディタ内で直接確認できます。さらに プロバイダーの冗長化と自動フォールバック も提供されるため、コスト計算が推定値ではなく、正確な数値に基づいたものになります。

「特定の 1 つのモデルを、特定の 1 つのプロバイダーからだけ使い続けたい」と確信がある場合のみ、直接プロバイダーに接続する選択は妥当です。ただし新しいモデルは絶えずリリースされているため、その確信が本当に正しいか再考する必要があります。

モデル選定でよくある間違い

多くの失敗したモデル選定は、「何を測るか」を間違えているか、「何を測るタイミング」が遅すぎることが原因です。特に多いのは以下の 5 つのケースです。

リーダーボードの順位を生産環境の判断基準にする: パブリックなリーダーボードで高い評価を得たからといって、それが即座に本番トラフィックへの採用を意味するわけではありません。まずは実際にプロンプトを実行して検証してください。

トークンあたりの価格だけで選ぶ: 単価が安くても、リトライの発生や完了までの処理時間、フォールバック時のコストなどが見え隠れしています。get-generation API を通じて「1 つのタスクを完了させるのに実際にいくらかかるか」を確認するまでは、そのモデルのコストは不明です。

コンテキストの形状を無視しない: コンテキスト長と、その長さでかかるコストの両方を確認してください。ロングコンテキストモデルは能力が高い反面、高価です。タスクを完遂できる最小限の信頼できるコンテキスト戦略を使い、より大きなウィンドウを検討する前に、まず検索（Retrieval）を検討しましょう。

一度選んで見直さない: 1 月の時点で最適なモデルでも、7 月には最適とは限りません。2026 年 7 月 27 日までの 30 日間で約 40 のモデルを追加しました。カテゴリ内で主要なリリースが行われた後は、以下の 6 つのステップを再実行してください。リポジトリに評価（Ori eval）を常駐させ、定期的に再実行するか、この問題を Auto Router に任せることをお勧めします。

レイテンシと信頼性を本番公開まで先送りしない: list-model-endpoints でレイテンシ、スループット、稼働率の数値を確認し、本番環境と同じようにエンドポイントをテストしてください。リリース後に信頼性の低いプロバイダーを発見するのは、回避可能なインシデントです。

タスクに合わせて選び、その選択を常に最新の状態に保つ

「どのモデルが最良か」ではなく、「あなたが今、予算の中で構築しようとしているものに対して、どのモデルが最適か」という問いを立ててください。

タスクの定義を明確にし、生データと実際のプロンプトセットを用意すれば、この答えは午後には出せます。何か変化があれば、数分で再評価できます。

• 「最良」はタスク固有かつ時間固有です。ランクではなく、完了したタスクあたりのコストとレイテンシで判断してください。
• ベンチマークは候補を絞り込むために使います。勝者を決めるのはあなた自身のデータです。send-message と get-generation で決着をつけます。

MCP サーバーが接続されれば、この一連のループはエディターから一度で実行できます。

今週リリースするタスクのために、OpenRouter MCP サーバー を追加し、アシスタントに候補の選定と価格比較を依頼しましょう。どのモデルを選ぶか迷っている場合や、複数のタスクを並行して行う場合は、openrouter/auto-beta を使用した Auto Router で、リクエストごとに最適なモデルを選ばせるのがおすすめです。

よくある質問

最高の AI モデルはどうやって選べばいいですか？

タスクを明確に定義し、実際の利用状況とベンチマークデータから候補を絞り込み、各モデルを提供するプロバイダー間で価格とレイテンシを比較した上で、最終候補を実際のプロンプトでテストします。勝者を決める際は、トークンあたりのコストではなく、完了したタスクあたりのコストで判断してください。OpenRouter を使えば、これらの手順はすべてエディター内の MCP サーバー経由で実行できます。

コーディングに最適な AI モデルとは？

正解は一つではなく、コーディングも単一のタスクではありません。コード生成、デバッグ、ファイル入出力、シェル実行、コードレビューとセキュリティ、フロントエンドと UI、リポジトリスキャン、SQL とデータベース作業、DevOps 設定の 9 つのカテゴリにトラフィックを分類すると、各分野で最も優れたモデルは異なります。

list-benchmarks コマンドで task_type=coding を指定して候補を絞り込み、list-task-classifications で実際のトラフィックと照合した上で、自社のバックログから実チケットを使って候補モデルを実際にテストしてください。

OpenRouter MCP サーバーとは？

これは、ローカルへのインストールが不要なリモート MCP サーバーです。接続すると、エディタから離れることなく、AI アシスタントが生モデルデータやプロバイダー別の価格、利用状況ランキング、サードパーティによるベンチマーク結果、ドキュメントを照会したり、候補となるモデルへテストメッセージを送信したりできます。MCP クライアントであれば誰でも接続可能です。

Claude Code、Codex CLI、OpenCode、Cursor CLI、Claude Desktop 向けのセットアップ手順は、それぞれ文書として用意されています。

Claude Code や Cursor で OpenRouter MCP サーバーをセットアップするには？

Claude Code で、まず claude mcp add --transport http openrouter https://mcp.openrouter.ai/mcp を実行し、続けて claude mcp login openrouter を実行してください。

Cursor では、サーバー URL を ~/.cursor/mcp.json に追加し、cursor-agent mcp list で確認してください。

認証はブラウザ上での単一のステップで完了し、その後、有効期限が 7 日間で利用上限が 10 ドルに設定された専用 API キーが発行されます。

トークンごとのコストとタスクごとのコストの違いは何ですか？

トークンあたりのコストは、入力と出力に対する広告上の単価です。一方、タスクあたりのコストは、1 つの成功した結果を得るために実際に必要な費用で、再試行や完了までの長さ、より強力なモデルへのフォールバックなどすべてを含みます。トークン単価が低いモデルでも、タスク完了時の総コストが高くなる可能性があります。

get-generation コマンドは、各呼び出しにおける実際の費用とトークン数を返すため、推測ではなく実測が可能になります。

AI モデルをどう比較するか？

モデル選定では、タスクごとの品質、完了あたりのコスト、レイテンシの 3 つの軸で比較しましょう。ベンチマークサイトを使って候補を絞り込み、list-model-endpoints で各プロバイダー間の価格やレイテンシ、スループットを確認し、最終的には自社のプロンプトで判断するのがおすすめです。並列比較用の Web ビューは openrouter.ai/compare にあります。

モデル選定をどのくらいの頻度で見直すべきか

タスクカテゴリにおける主要なリリースが行われた際や、コスト・レイテンシ・失敗率が変動した際は、必ず評価フレームワークを再実行してください。2026 年 7 月 27 日までの 30 日間に約 40 のモデルが追加されたように、モデル選定は一度きりの設定ではなく、継続的な運用判断として捉える必要があります。頻繁な追跡が面倒な場合は、リクエストごとに自動で振り分ける Auto Router を利用しましょう。

モデル評価を再現可能にするには

Ori Eval を活用してください。自然言語で質問すると、コーディングエージェントがプロジェクト内のテスト素材を検索し、*.eval.ts 形式の評価ファイルを自動生成します。その後、候補モデルを OpenRouter で実行し、スコア・所要時間・コストを付与した上で推奨モデルを提示します。評価ファイルは通常のコードなので、新モデルリリース時に再実行したり、--baseline オプションで比較したり、CI に組み込んで定期的に実行したりできます。

単一モデルを使うべきか、複数間で振り分けるべきか

タスクが限定的でプロンプトが安定しており、候補の一つが評価基準を明確にクリアできる場合は、単一のモデルを使用してください。一方、リクエストの複雑さがバラつきがある場合や、モデルの一貫性よりも信頼性が重要である場合、あるいは毎回のリリースサイクルで判断を見直す手間を避けたい場合は、ルーティングを活用しましょう。

Auto Router クラスは各リクエストを約 30 のタスクタイプに分類し、直近 7 日間のコミュニティの支出シェアに基づいて、リクエストごとに最適なモデルを選択します。

リファレンス

本ページ上のすべての主張は、これらのソース（生 API 呼び出しを含む）に対して検証済みです。

• OpenRouter MCP サーバードキュメント。ホストされたサーバー、エディターごとの設定方法、ツール一覧、および課金対象となるツールの詳細。

• OpenRouter MCP サーバーの発表について詳しくはこちら。OAuth フロー、7 日間のキー有効期限、10 ドルの支出上限、そしてモデルサフィックスのバリアントについても解説されています。

• モデルに関するドキュメントはこちらをご覧ください。価格、コンテキスト長、モダリティ、サポートされているパラメータなど、モデルのメタデータフィールドについて詳しく記載されています。

• モデルのバリアントドキュメント。:online、:nitro、:free というサフィックスがルーティングにどのような影響を与えるかについて解説しています。

:floor ショートカットの詳細は、プロバイダーの選択 のドキュメントに記載されています。

• Ori Eval ドキュメント。評価ファイルの形式、candidateModels、setupJudge、--baseline オプション、および CI 環境での評価実行方法について解説しています。

「Auto Router」のドキュメントはこちら：https://openrouter.ai/docs/guides/routing/routers/auto-router。この機能は、リクエストごとに約 30 のタスクタイプに分類し、直近 7 日間の支出シェアに基づいてランク付けを行います。また、モデル識別には openrouter/auto-beta という文字列が使用されます。

モデルのフォールバック設定については、Model fallbacks docs を参照してください。プロバイダーの冗長化と自動的なフォールバック動作について解説しています。

API リファレンスは API reference にあります。モデル選定が完了した後の本番環境用 API に関するドキュメントで、リクエスト実行後のコストや統計情報の確認方法も含まれています。

「Model catalog」(https://openrouter.ai/models) では、70 社以上のプロバイダーが提供する 400 種類以上のモデルをライブで確認できます。

「Rankings」(https://openrouter.ai/rankings) では、モデルごとの日次トークン使用量や、タスク分類別の市場シェアを閲覧可能です。

「Compare」(https://openrouter.ai/compare) を利用すれば、ベンチマーク結果、価格、コンテキストサイズ、レイテンシなどを横並びで比較できます。

「Artificial Analysis」(https://artificialanalysis.ai/) と「Design Arena」(https://designarena.ai/) は、list-benchmarks コマンドで表示される 2 つの第三者ベンチマークソースです。

「Task classification market share」(https://openrouter.ai/docs/api/api-reference/classifications/task-classification-market-share) は、list-task-classifications の背後にあるエンドポイントで、使用シェアと各タグごとの主要モデルを含む 29 のタスクタグを返します。

「List Benchmarks」のドキュメントを確認しましょう。このエンドポイントは list-benchmarks の背後にあり、task_type でフィルタリング可能です。

生成ごとのリクエストと使用状況のメタデータを取得する方法も解説されています。これにより、1 回の呼び出しにおける正確なコスト、トークン数、プロバイダー、レイテンシを確認できます。

また、Chen, Zhang, He, Stoica, Zaharia, Zou による論文「The Price Reversal Phenomenon: When Cheaper Reasoning Models Cost More」も参照してください。これは、モデルペア間での総コストに対するリスト価格の独立した測定結果です。arXiv にて 2026 年 3 月に発表され、同年 5 月に改訂されました。

https://openrouter.ai/docs/api/api-reference/benchmarks/list-benchmarks

https://openrouter.ai/docs/api/api-reference/generations/get-request-%26-usage-metadata-for-a-generation

https://arxiv.org/abs/2603.23971