Generic OpenAI 経由で、AnythingLLM を任意のモデルで動かす。

早わかり: LLM Preference の5つのフィールド。

AnythingLLM の設定を開き、AI Providers の下にある LLM セクション(かつては LLM Preference という画面名でした)に進み、プロバイダーリストから Generic OpenAI を探します。選択すると5つのフィールドが現れます。Base URL、API Key、Chat Model Name、Token Context Window、Max Tokens です。 次のように入力します。Base URL は https://api.apisrouter.com/v1(/v1 はこのフィールドに含めます)、あなたのキー、そして Chat Model Name には正確なカタログの id、たとえば claude-sonnet-4-6 です。続いて2つの数値です。Token Context Window はモデルの総ウィンドウ、Max Tokens は単一の応答の上限なので、推測せずどちらもモデルのドキュメントから取ってください。保存すれば、システムデフォルトに従うすべてのワークスペースが、これでゲートウェイ経由でチャットするようになります。ドキュメントがこのプロバイダーを developer-focused と位置づけているのは、まさに入力内容を信頼して動くからです。それは使用を控えるべきという警告ではなく、5つのフィールドが契約だという説明にすぎません。

Base URL:              https://api.apisrouter.com/v1
API Key:               sk-YOUR-APISROUTER-KEY
Chat Model Name:       claude-sonnet-4-6
Token Context Window:  200000
Max Tokens:            8192

Generic OpenAI プロバイダーが実際に動かしているもの。

AnythingLLM(GitHub 上では Mintplex Labs、スター数はおよそ63K)は、オールインワンのプライベートドキュメントアシスタントです。ファイルを埋め込むワークスペース、検索された文脈に基づくチャット、ツールを使うエージェントを備え、デスクトップアプリとしてもセルフホストサーバーとしても利用できます。上で設定した LLM preference は、そのすべてのデフォルトの頭脳です。 リクエストは、Chat Model Name を model 文字列として、あなたの Base URL に対する標準的なチャット補完として送信されるため、ベンダーは問題になりません。Claude の id は GPT の id と同じくらい有効で、切り替えはフィールド1つの編集で済みます。ワークスペースは独自のプロバイダーとモデル設定でシステムデフォルトを上書きすることもでき、これによって1つのデプロイが、法務ワークスペースでは claude-sonnet-4-6 を、エンジニアリングでは gpt-5.5 を、互いに知ることなく走らせられます。 この2つのトークンフィールドは軽んじるべきではありません。AnythingLLM がこれらを使って文脈の予算を組むからです。コンテキストウィンドウの値は、検索されたドキュメントのテキストと会話履歴が各リクエストにどれだけ詰め込まれるかを決めます。過小に申告すれば、せっかく埋め込んだドキュメントが自身の回答から削られてしまい、過大に申告すればリクエストがモデルの実際の上限に跳ね返されます。汎用エンドポイントで「RAG が馬鹿になった」という報告の背後には、たいていこの2つのフィールドがあります。

エンベディングは別の判断事項。

AnythingLLM は LLM preference と embedding preference を分けており、この分離は構造上重要です。チャットモデルは質問に答え、エンベダーはアップロード時にドキュメントをベクトルに変換し、そのベクトルは永続化されます。チャットモデルの変更はいつでも、ワークスペースごとに、何のコストもなく行えます。エンベダーの変更は、すでに埋め込まれたすべてのものの幾何構造を無効にし、ドキュメントの再エンベディングを意味します。 実践的なセットアップはこうです。AnythingLLM にはオフラインで動き、費用がかからない組み込みのローカルエンベダーがあり、多くのデプロイは単純にそれを使い続けます。代わりに embedding preference をリモートエンドポイントに向けるなら、ドキュメントベースをアップロードする前に、そのエンベディング id が実際に提供されているか確認し、その選択をベクトルストアと結婚したものとして扱ってください。 これによってチャット側に生まれる自由こそが、このアーキテクチャの狙いです。エンベディングさえ固まっていれば、Generic OpenAI のチャットモデルはリスクの低いダイヤルになります。重い要約作業の1か月は deepseek-v4-pro を走らせ、クライアント案件の四半期はフィールドを claude-sonnet-4-6 に切り替える。ドキュメントに関しては何も動かす必要がありません。

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $APISROUTER_API_KEY" | head -50
# Chat Model Name must match one of these ids exactly

ドキュメント作業向けのモデル選び。

どの id も同じキーで課金されるため、比較のループは設定の編集で済みます。同じワークスペース、同じドキュメント、候補ごとに2週間、そして APIsRouter コンソールのモデルごとの支出を、回答に対する自分自身の判断と並べて見てください。

• 検索されたチャンクに基づくグラウンデッド QA は入力量の多い作業です。claude-haiku-4-5-20251001 と gemini-3.5-flash は、引用に沿った質問にボリューム価格でよく答えます。
• 回答が編集されずに人へ届く場面では claude-sonnet-4-6 がデフォルトに値します。契約書レビュー、レポートの下書き、結果に責任が伴うあらゆる場面です。
• deepseek-v4-pro は、大きなドキュメントの上に構築されたワークスペース向けの長文脈ワークホースであり、ウィンドウと入力価格が体験を左右します。
• エージェントのワークスペースには信頼できるツール呼び出しが必要です。まず claude-sonnet-4-6 でエージェントを始め、実際のフローで軽量な id が通用するか検証してください。
• ワークスペースごとのオーバーライドをポリシーとして使いましょう。デフォルトは速いままにし、高価な id はその作業に値するワークスペースだけに置きます。

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

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

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

トークンフィールドが、微妙な失敗の原因になります。コンテキストウィンドウを低く設定しすぎると、検索された文脈が静かに切り詰められ、モデルがドキュメントを無視しているように見えます。Chat Model Name の id について、ドキュメント記載のウィンドウを設定してください。Max Tokens をモデルに対して高く設定しすぎると、長い回答でハードエラーが発生します。モデルが実際に出力を許す値に設定してください。 ハードエラーの方がまだ正直です。認証失敗は API Key フィールドの問題です。Model-not-found は Chat Model Name がカタログの綴りからずれているということです。このフィールドは自由記述であり、/v1/models の一覧が正しさの拠り所です。デスクトップアプリでの接続エラーは、たいていアプリとエンドポイントの間にあるプロキシやファイアウォールが原因です。Docker デプロイでは、Base URL に到達しなければならないのはブラウザではなくコンテナだということを忘れないでください。 チャット自体は動くのに、あるワークスペースだけ予想と違う挙動をする場合は、そのオーバーライド設定を確認してください。ワークスペースレベルのプロバイダー設定はシステムデフォルトに優先するため、忘れられたオーバーライドは「同じ質問なのに違うモデル」という典型的な謎の正体です。ドキュメントの developer-focused という位置づけは、これまで述べたことをすべて要約しています。このプロバイダーは、5つのフィールドが語ること以上でも以下でもなく、そのとおりに動くのです。

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

• プライベートなドキュメントアシスタントを運用し、モデルファミリーごとのベンダーアカウントなしにフロンティア級の回答品質を求めるチーム。
• 個人のドキュメントベースを、前払い残高の Claude や GPT の id に向けるデスクトップユーザー。開始にカードは不要です。
• 組み込みのローカルエンベダーを保ちつつ、リモートチャットだけを計測対象のレーンとして扱い、1つの利用ログでモデルごとに読み解くセルフホスター。
• ワークスペースごとに区分されたデプロイ。ワークスペースごとのオーバーライドとキーごとの計測により、各チームが自分のモデルと自分の請求を持てます。
• 固定のドキュメントベースに対して回答モデルを比較するビルダー。各候補は移行ではなく設定1つの編集で済みます。

エンドポイントを検証し、最初のワークスペースチャットをデバッグする。

まず、Chat Model Name に入れる予定の正確な id を使って、モデル一覧と1回のチャット補完を curl で確認してください。両方が通れば、ゲートウェイ側は証明済みであり、残る症状はすべて5つのフィールドの中にあります。 次にプロバイダー設定を保存し、よく知っているドキュメントのあるワークスペースで1つ質問してください。文脈に基づき引用する回答が返れば、パイプライン全体が動いています。ドキュメントを無視した回答は、コンテキストウィンドウの値か、ワークスペース自体の検索設定を指しています。ハードエラーはきれいに切り分けられます。キー、id の綴り、Base URL の形です。 チャットが流れ始めたら、APIsRouter コンソールがリクエストごとのモデル、トークン数、支出を表示します。ドキュメント QA は検索を通じて入力トークンを増幅させるため、利用ログこそが、あなたのドキュメントベースを問い合わせるのに実際いくらかかるかを、モデルごと・日ごと、キーを分けていればワークスペースキーごとに教えてくれる場所です。

curl -s https://api.apisrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $APISROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-sonnet-4-6",
       "messages":[{"role":"user","content":"ping"}]}'

よくある質問