APIsRouter を、LibreChat のカスタムエンドポイントとして追加する。

早わかり: librechat.yaml に1ブロック。

LibreChat のカスタムエンドポイントは librechat.yaml の endpoints.custom の下に設定します。ここは配列で、各エントリが1つのプロバイダーです。重要な3つのフィールドは name(エンドポイントセレクターに表示されるラベル)、apiKey(${VARIABLE} という形で環境変数を展開するため、キーは .env に置かれ YAML には決して現れません)、そして baseURL です。APIsRouter の場合、baseURL は /v1 を含めた https://api.apisrouter.com/v1 になります。LibreChat が与えられたベースに /chat/completions のようなルートパスを付け足すためです。 models ブロックがモデルドロップダウンに何を表示するかを決めます。models.fetch を true にすれば、LibreChat は起動時にそのエンドポイントの /v1/models 一覧を問い合わせるため、手書きのリストを維持しなくても、カタログの全 id が選択可能になります。models.default は配列として必須で、フェッチの前後あるいは代わりに表示されるフォールバックとして機能します。これはパッチではなく、上流のドキュメントに記載された正規の設定です。LibreChat のドキュメントにあるカスタムエンドポイントオブジェクトの構造が、ここで使われているすべてのキーを定義しています。

version: 1.2.1
endpoints:
  custom:
    - name: "APIsRouter"
      apiKey: "${APISROUTER_API_KEY}"
      baseURL: "https://api.apisrouter.com/v1"
      models:
        default: ["claude-sonnet-4-6"]
        fetch: true

LibreChat がカスタムエンドポイントをどうルーティングするか。

LibreChat(GitHub 上では danny-avila、スター数はおよそ41K)は、最も広く導入されているセルフホスト型の ChatGPT ライクなインターフェースです。マルチユーザー・マルチモデルで、会話検索、エージェント、ファイル処理、ユーザーごとのキーを備えています。プロバイダーの一覧をハードコードするクライアントとは異なり、その endpoints.custom 配列は任意の OpenAI 互換サービスを受け付け、ドキュメントに載っているよく知られたプロバイダーのいくつかも、まさにこの仕組みで設定されています。 ユーザーがカスタムエンドポイントからモデルを選ぶと、LibreChat はそのエンドポイントの baseURL に対して標準の /v1/chat/completions リクエストを、モデルフィールドをプレーンな文字列として送ります。クライアントはそのモデルをどのベンダーが訓練したかを気にしません。baseURL の背後にあるエンドポイントが複数のベンダーを提供している場合、librechat.yaml のエントリ1つで Claude・GPT・Gemini・DeepSeek・GLM の id が同じドロップダウンに並び、会話の途中でユーザーがベンダーを切り替えるのも、GPT の別バリアントに切り替えるのとまったく同じ操作になります。 これにより、通常のマルチプロバイダー LibreChat 設定がまとめられます。ベンダーごとにカスタムエントリ1つ、それぞれ .env に独自のキーを持ち、独自の請求面を持つ代わりに、エントリ1つ・キー1つでカタログをカバーでき、管理者はいくつものダッシュボードを突き合わせるのではなく、モデルごとの利用状況を1か所で確認できます。

フルセットアップ: YAML・.env・Docker のマウント。

librechat.yaml をプロジェクトルートに作成し、キーは .env に置いてください。YAML 内の ${APISROUTER_API_KEY} という参照は、起動時に環境から解決されるため、設定ファイル自体はコミット可能なままです。 初回セットアップで最も見落とされがちなのが、Docker 固有のステップです。コンテナは librechat.yaml をマウントするまで認識しません。ドキュメントでは docker-compose.override.yml を作成し、./librechat.yaml から /app/librechat.yaml へのバインドマウントを設定してから、コンテナを再作成する手順が案内されています。その後 YAML を編集する場合も再起動が必要です。このファイルは起動時に読み込まれるだけで、監視されているわけではないからです。 ゲートウェイのエントリに設定しておく価値のある、任意のフィールドがいくつかあります。titleConvo は会話タイトルの自動生成を有効にし、titleModel はそのタイトルを書くモデルを選びます。LibreChat のドキュメントに記載された titleModel の既定値は gpt-3.5-turbo で、これは OpenAI 以外のエンドポイントが提供していないかもしれない id なので、速いカタログの id か、特別な値 current_model を明示的に設定してください。modelDisplayLabel はアシスタントのメッセージに表示される名前を制御します。そして apiKey は、サーバーのキーを共有する代わりに各ユーザーが自分のキーを持ち込めるようにしたい場合、特別な値 user_provided を受け付けます。

version: 1.2.1
endpoints:
  custom:
    - name: "APIsRouter"
      apiKey: "${APISROUTER_API_KEY}"
      baseURL: "https://api.apisrouter.com/v1"
      models:
        default: ["claude-sonnet-4-6", "gpt-5.5", "deepseek-v4-pro"]
        fetch: true
      titleConvo: true
      titleModel: "claude-haiku-4-5-20251001"
      modelDisplayLabel: "APIsRouter"

共有チャットワークスペース向けのモデル選び。

すべてのモデルが同じキーを経由して課金されるため、管理者にとっての実務上のループは、1週間の利用状況をコンソールで観察し、ユーザーが実際に何を選んでいるかを見て、models.default をそれに合わせて絞り込みつつ、パワーユーザーがフルリストに届くよう fetch は有効にしておくことです。

• 日常使いのチャットには強力な汎用モデルが向いています。claude-sonnet-4-6 と gpt-5.5 は、モデルへの不安なしに長い会話、ファイルの議論、エージェントの実行を支えます。
• 頻度の高い短い質問はボリューム作業です。claude-haiku-4-5-20251001 と gemini-3.5-flash は速く回答し、多ユーザーの導入で使い捨てのターンに支出が集中するのを防ぎます。
• タイトル生成はすべての会話で発生します。titleModel は速い id に向けてください。使い捨ての6語のタイトルにフロンティア級の料金を払うことは、LibreChat 導入でもっともよくある静かな無駄です。
• 多言語のチームは、実際の言語構成で deepseek-v4-pro と glm-5.2 を試す価値があります。マルチベンダーのドロップダウンなら、それは再設定ではなくアプリ内比較になります。
• models.fetch のおかげで、新しいカタログモデルは YAML に触れなくても現れます。上流に追加されたモデルは、次にリストが更新されたときに選択可能になります。

従量課金 · 公式価格より安い

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

LibreChat に特有の失敗パターン。

設定が静かに読み込まれないのはよくある古典的な症状で、ほぼ常に Docker のマウントが原因です。docker-compose.override.yml のバインドマウントがないと、コンテナは librechat.yaml を一切持たないまま動き、カスタムエンドポイントはセレクターに現れず、何もエラーになりません。他をデバッグする前に、ファイルがコンテナの中に実在するか確認してください。 apiKey がリテラルに ${APISROUTER_API_KEY} のまま届く場合、その変数はサーバー起動時の環境に存在していなかったということです。この展開は .env から起動時に行われるため、後から追加したキーはコンテナの再起動が必要です。症状としては、意味のないベアラートークンによる 401 がゲートウェイから返ります。 baseURL に /v1 がないと、すべてのリクエストで 404 が発生します。LibreChat は与えられたベースに /chat/completions を付け足すからです。逆に完全な completions URL を baseURL に貼り付けてしまう誤りは、別の directEndpoint オプションに属するもので、通常のエントリと組み合わせるべきではありません。 fetch を無効にした状態でモデルドロップダウンが空なのは、models.default が欠落しているか空だからです。これは必須の配列です。fetch を有効にしていて空の場合は、たいてい fetch 自体が失敗しており、原因はキーか baseURL に戻ります。そして他は動いているのに会話タイトルの生成だけ失敗する場合は、titleModel のデフォルトがゲートウェイの提供していない id を指しているのが原因です。明示的に設定してください。

ゲートウェイ経由で LibreChat を使うのは誰か。

• 共有チャットワークスペースをセルフホストするチームで、endpoints.custom のエントリとベンダーアカウントをそれぞれ1つずつ維持するのではなく、Claude・GPT・Gemini・DeepSeek を1つのドロップダウンにまとめたい人。
• 1つの利用状況面を必要とするマルチユーザー導入の管理者。キーごとのログが、チームが実際にどのモデルを使っているかを、ベンダーダッシュボードを統合することなく価格付きで示します。
• 部門ごとに独自のキーを渡す運用者。同じ YAML、グループごとに1つのキー、そして利用ログがそのままチームごとのコストレポートになります。
• 複数のチャットサブスクリプションを、席数ではなく使ったトークン分だけ支払う1つの従量課金エンドポイントに置き換える世帯や小規模グループ。
• 特定ベンダーの請求手段にアクセスできない開発者。チャージ制でカード不要のアクセスなら、プロバイダーごとのサインアップという依存を取り除けます。

エンドポイントを検証し、最初のメッセージをデバッグする。

LibreChat に触れる前にゲートウェイ側を証明してください。あなたのキーでモデルを一覧し、models.default に入れた id が現れることを確認します。それが動けば、残る症状はすべて LibreChat 側の問題です。 次にスタックを起動してエンドポイントセレクターを開きます。APIsRouter のエントリがそもそも表示されることが YAML の読み込みを証明し、モデルリストが埋まることがフェッチとキーを証明し、最初の返信がチャットの経路を証明します。この3つを一度にではなく順番に確認してください。それぞれ異なる失敗要因(マウント、環境変数、baseURL)に対応しているからです。 メッセージが流れ始めたら、APIsRouter コンソールがリクエストごとのモデル、トークン数、支出を表示します。共有の LibreChat インスタンスは、利用が2つか3つのモデルに静かに集中していきがちな典型的な導入形態であり、利用ログはどれに集中しているかを、請求書が来る前に教えてくれます。

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $APISROUTER_API_KEY" | head -50

よくある質問