OpenRouterとは｜多数のLLMを1つのAPIで使える基盤とビジネスモデル

OpenRouter は、さまざまな提供元の大規模言語モデル（LLM: Large Language Model）を、1 つの API からまとめて使えるようにするモデル基盤です。アプリ側は OpenRouter の API キーを 1 つ持つだけで、Anthropic・OpenAI・Google などのモデルや、多数のオープンモデルを切り替えながら呼び出せます（OpenRouter）。

01.結論：OpenRouterとは何か

モデルを使う側から見ると、提供元が増えるほど面倒が増えます。提供元ごとに API の作法・認証・課金が違い、あるモデルが落ちたり値上げされたりするたびに、アプリ側のコードを直す必要が出てきます。OpenRouter は、その「窓口」を 1 つにまとめる基盤です。OpenRouter のドキュメントは、自社を「OpenAI の差し替え（drop-in replacement）として使える統一 API」と位置づけています（OpenRouter Docs: FAQ）。

OpenRouter の概要ドキュメントによると、対応モデルは 300 以上、提供元は 60 以上にのぼります。新しいモデルが出ても、OpenRouter 側がつなぎ込めば、利用側はモデル名（スラッグ）を変えるだけで試せます（OpenRouter Docs: Models）。なお対応モデル数や提供元数は増減するため、最新はドキュメントで確認してください。

02.OpenRouterが解決する課題

複数のモデルを使い分けたいとき、提供元ごとに直接つなぐと、次のような負担が生まれます。OpenRouter は、これらをまとめて引き受けます。

• 契約・認証の分散：提供元ごとに API キーや課金を持つ必要があります。OpenRouter なら 1 つの API キーに集約できます。
• API の作法の違い：提供元ごとにリクエストの形が違います。OpenRouter は OpenAI 互換に統一するため、既存の OpenAI 向けコードを流用しやすくなります。
• 可用性のばらつき：ある提供元が落ちると止まります。OpenRouter は複数提供元の稼働をまとめ、フォールバックで別の提供元へ回せます。
• 利用管理の手間：チームでの予算や利用状況の把握がモデルごとに分かれます。OpenRouter は利用とコストを 1 か所で見られます。

03.主な機能

OpenAI互換API

OpenRouter の API は OpenAI 互換です。ドキュメントでは、OpenAI に対応した SDK はそのまま OpenRouter でも使えると説明されています。エンドポイントと API キーを OpenRouter のものに差し替え、model にモデルスラッグを入れるだけで、提供元をまたいで同じ書き方を保てます（OpenRouter Docs: FAQ）。

モデルルーティングとフォールバック

同じモデルでも、複数の提供元（エンドポイント）から提供されることがあります。OpenRouter は、価格や速度などの条件に応じて提供元を選び、ある提供元が使えないときには別の提供元へ回します。これにより、利用側は 1 つのモデル指定のまま、稼働率を底上げできます。

統一クレジットと利用管理

OpenRouter は、クレジット（前払いの残高）を 1 か所に置き、どのモデル・提供元を使っても、そこから利用分を差し引く仕組みです。提供元ごとに別々の請求を受ける代わりに、利用とコストをまとめて管理できます。チームで予算や利用状況を見たい場合に向きます。

04.OpenRouterのビジネスモデル

OpenRouter の収益は、提供元価格への「上乗せ」ではなく、利用への手数料から得る形が基本です。推論そのものの価格は各提供元のパススルー（上乗せなしの素通し）で、稼ぎは主に 2 つの手数料、つまり従量課金（pay-as-you-go）へのプラットフォーム手数料と、自分の API キーを持ち込む BYOK（Bring Your Own Key）利用への手数料です（OpenRouter: Pricing）。

利用側から見ると、直接契約と同じ単価に手数料を足して、統一 API とフォールバック、利用管理を買う形です。1 つの提供元に決め打ちで大量に使うなら直接契約が安く付く場面もあり、複数モデルを試す・切り替える・冗長化する用途では手数料が見合いやすい、という分かれ方になります。手数料率や無料枠は変わりうるため、最新は料金ページで確認してください。

05.データの扱い・プライバシー

コードや業務データを送る用途では、ログの扱いが気になります。OpenRouter は、リクエストの基本的なメタデータ（時刻・使ったモデル・トークン数など）は記録する一方、プロンプトと生成結果（completion）は既定ではログしないと説明しています。プロンプトや生成結果をログさせるには、利用側が明示的にオプトイン（opt in）する必要があります（OpenRouter Docs: Data Collection）。

提供元側のログについても、OpenRouter はプロンプトや生成結果が学習に使われないようにする方針を示しています。ログするか、方針が確認できない提供元へは、プライバシー設定の学習許可を明示的に有効にしない限り回さない、とされています。さらに、Zero Data Retention（ZDR: データを保持しない方針）のエンドポイントだけに限定するよう、全体・モデルグループ単位・リクエスト単位で強制する設定もあります（OpenRouter Docs: Zero Data Retention）。コーディングや社内データで使うなら、この設定を確認しておきたいところです。

06.使い方：APIキーとモデルスラッグ

最短の使い方は、OpenRouter で API キーを作り、OpenAI 互換のリクエストで model にモデルスラッグを指定するだけです。エンドポイントを OpenRouter のものに向け、認証に OpenRouter の API キーを使います。

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://openrouter.ai/api/v1",
  apiKey: process.env.OPENROUTER_API_KEY,
});

const completion = await client.chat.completions.create({
  model: "anthropic/claude-opus-latest",
  messages: [{ role: "user", content: "OpenRouter について教えて" }],
});

モデルを変えたいときは、model の値を別のスラッグに差し替えるだけです。提供元ごとに SDK や認証を組み直す必要はありません。GUI のチャットからモデルを試すこともでき、まず触ってから API に組み込む、という進め方も取りやすくなっています。

07.OpenRouter Fusionとの関係

OpenRouter には、複数モデルを 1 つの API から呼べる基盤の上に、複数モデルを協調させる OpenRouter Fusion という機能があります。Fusion は、1 つのプロンプトを複数モデルに並列で投げ、ジャッジ（judge）モデルが合意点・矛盾・盲点を整理してから最終回答にまとめる仕組みです。OpenRouter という土台があるからこそ成り立つ機能で、深いリサーチ系のベンチマークでは単体モデルを上回る結果も示されています。

08.よくある質問（FAQ）

09.まとめ

OpenRouter は、多数の提供元の LLM を OpenAI 互換の 1 つの API で使える中継基盤です。1 つの API キーでモデルを切り替えられ、フォールバックで稼働率を底上げし、クレジットで利用とコストをまとめて管理できます。ビジネスモデルは、推論価格を提供元のパススルーにしつつ、クレジット利用や BYOK に手数料を乗せる形です。プロンプトや生成結果は既定でログされず、ZDR など細かいプライバシー設定もあります。複数モデルを協調させたいときは、その先に Fusion があります。