Dify のアプリを、OpenAI-API-compatible エンドポイントで動かす。

早わかり: プロバイダーをインストールし、id でモデルを追加する。

Dify で Settings を開き、Model Provider に進みます。Dify 1.0 以降、プロバイダーはプラグインです。リストから OpenAI-API-compatible(langgenius が公開)を探すか、Marketplace からインストールし、そのカードで Add Model をクリックします。 このダイアログはモデルごとです。Model Type を選び(チャットモデルなら LLM)、Model Name に正確なカタログの id を入力し、API Key にキーを貼り付け、API Base URL を https://api.apisrouter.com/v1 に設定します。Completion mode は Chat のままにし、Model context size と Upper bound for max tokens を、追加する id のドキュメント記載の上限に設定します。保存すると、モデルはプロバイダーのリストに現れ、すべてのアプリのモデルドロップダウンから選択できるようになります。欲しい id ごとにこのダイアログを繰り返します。1モデルあたり2分、一度きりの作業です。

Model Type:                LLM
Model Name:                claude-sonnet-4-6
API Key:                   sk-YOUR-APISROUTER-KEY
API Base URL:              https://api.apisrouter.com/v1
Completion mode:           Chat
Model context size:        200000
Upper bound for max tokens: 64000

Dify が互換プロバイダーとどう話すか。

Dify(GitHub 上では langgenius、スター数はおよそ149K)は、代表的なオープンソース LLM アプリプラットフォームです。ビジュアルなワークフロー、エージェントノード、ナレッジベース上の RAG パイプライン、そして独自の API エンドポイントを持つ公開アプリを備えています。そのスタック内のすべての LLM ノードは、いずれかのプロバイダーの下に登録されたモデルに解決されます。 OpenAI-API-compatible プロバイダーは、意図的に汎用的です。追加する各モデルは、id・エンドポイント・キー・上限を持つ自己完結型のレコードであり、Dify は設定されたベース URL に対して標準的なチャット補完リクエストを、あなたの Model Name を model 文字列として送ります。リクエストの中身は、どのベンダーがそのモデルを訓練したかを一切気にしないため、claude-sonnet-4-6 や deepseek-v4-pro は、どの GPT の id とも同じくらい有効であり、必要なら異なるモデルが異なるエンドポイントを指すことさえできます。 手間に感じられるモデルごとの登録は、同時に制御面でもあります。入力する context size と max-tokens の値は、Dify のオーケストレーターがプロンプトの予算を組み、会話履歴を切り詰め、ノード設定を検証するために使うものです。モデルのドキュメントに基づく正直な数値を入力してください。context を過大に申告すると、エンドポイントが拒否するリクエストが発生し、過小に申告すると、RAG ノードがせっかく検索した文脈が静かに切り詰められます。

実際に効いてくるフィールド。

Model Name はワイヤー上の値です。すべてのリクエストで運ばれるため、ゲートウェイの /v1/models の一覧と1文字違わず一致していなければなりません。任意の model display name は、UI 上のラベルを変えるだけです。 Completion mode は、現在のカタログのすべてのモデルについて Chat のままにしてください。Completion というオプションはレガシーなテキスト補完エンドポイント向けに存在し、チャットモデルに対しては不正な形式のリクエストを生成します。 Model context size と Upper bound for max tokens は、みんなが急いで済ませてしまうペアです。context size はモデルの総ウィンドウ、upper bound はノードが要求できる出力トークン数の上限です。Dify はデフォルトで両方を 4096 にしており、これは現行モデルが対応する値をはるかに下回ります。デフォルトのままにしておくと、長文ドキュメントの RAG や長文生成が静かに損なわれます。習慣ではなく、モデルのドキュメントに基づいて設定してください。 機能セレクターは、アプリがそれを使う場合に重要になります。Vision Support は画像入力を受け付ける id にだけ、そして function-call の設定はモデルのツール利用対応に一致させてください。エージェントノードはそれに依存しているからです。機能の申告が間違っていると、ワークフローの内部で実行時に失敗します。それはこのダイアログよりもデバッグに時間がかかる場所です。 ワークスペースがエンベディングモデルやリランクモデルも使う場合、同じプロバイダーが、同じベース URL に対して、それぞれ独自の Model Type エントリの下でそれらを登録します。ナレッジベースの設定をそこに配線する前に、そのエンドポイントが該当する id を実際に提供しているか確認してください。

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $APISROUTER_API_KEY" | head -50
# register these ids verbatim as Model Name entries

ワークフローとエージェント向けのモデル選び。

Dify 自体の概要ページはアプリごとのトークン数を示しますが、APIsRouter コンソールのキーごとの利用状況ビューは、同じ画面上ですべてのアプリ横断のモデルごとの内訳を加えます。それこそが、どの id がそのスロットを保持し続けるかを決める数字です。

• ワークフローの LLM ノードはボリューム作業です。実行のたびに走る分類・抽出・ルーティング・要約のステップです。claude-haiku-4-5-20251001、gpt-5.4-mini、gemini-3.5-flash が、実行あたりのコストを一定に保ちます。
• エージェントノードと複雑な推論ステップには claude-sonnet-4-6 が値し、エージェントにおいては生のベンチマークスコアより、その信頼できるツール利用の方が重要です。
• RAG の回答ノードは呼び出しのたびに検索済みの文脈を運ぶため、入力価格が支配的です。検索が重く回答が長い場面では deepseek-v4-pro を試す価値があります。
• 同じ役割に対して速い id と強力な id を登録し、ノードごとに A/B テストしましょう。Dify ではノードのモデル切り替えは移行ではなくドロップダウンです。
• 公開アプリは、そのノードのモデル選択をそのまま引き継ぐため、エディタでのドロップダウンの決定が、出荷するアプリのユニットエコノミクスそのものになります。

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

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

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

プロバイダーがリストにない場合、それはプラグインがインストールされていないということです。Dify 1.0 以降、OpenAI-API-compatible プロバイダーは Marketplace のプラグインとして提供され、新規のセルフホストインスタンスはそれなしで起動します。ワークスペースごとに一度インストールしてください。 保存はできても初回使用時にエラーになるモデルは、たいてい次の3つのいずれかです。カタログの綴りと一致しない Model Name、/v1 が欠けたベース URL(Dify は入力した値に /chat/completions のようなルートパスを付け足します)、あるいはモデルが受け付ける範囲を超えた context/max-token の値です。エラーはアプリやワークフローのログに現れ、修正は Add Model ダイアログに戻って行います。 普通のチャットノードは動くのにエージェントノードだけ失敗する場合は、function-calling の機能設定か、エージェント戦略が期待する水準にツール利用が届いていないモデルを疑ってください。まず claude-sonnet-4-6 でエージェントをテストし、設定の問題とモデル選択の問題を切り分けてください。 厳しい egress ルールの背後にあるセルフホストインスタンスでは、エンドポイントに到達しなければならないのはブラウザではなく Dify の api コンテナだということを忘れないでください。そのコンテナの中からの curl が、接続性に関する疑問を素早く解決します。

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

• LLM アプリを構築するチームで、プロバイダーごとのベンダーアカウントを維持することなく、ノードごとに Claude・GPT・Gemini・DeepSeek を選べるようにしたい人。
• 社内ツールとして Dify を運用するセルフホスター。1つのプロバイダーに1つのキーがあれば、ワークスペース全体のクラウド支出が1つの利用ログにまとまります。
• 実際のワークフローでモデルを比較するビルダー。各候補は新しい統合ではなく、Add Model ダイアログとドロップダウンの切り替えで済みます。
• 特定ベンダーの請求手段にアクセスできない開発者。チャージ制でカード不要のアクセスなら、プロバイダーごとのサインアップという依存を取り除けます。
• Dify でクライアント向けアプリを出荷する代理店で、プロジェクトごとのキーを必要とし、クライアントごとのモデル支出が自然に可視化されるようにしたい人。

エンドポイントを検証し、最初の実行をデバッグする。

まずモデル一覧を curl で確認し、その出力から id を登録してください。手入力の Model Name は、フィールドが自由記述であるがゆえに、not-found エラーの最大の原因です。次に、同じキーで登録した id に対して1回チャット補完を実行してください。 Dify の中では、本番ワークフローに組み込む前に使い捨てのアプリでテストしてください。LLM ノードを追加し、新しいモデルを選び、一度実行します。認証エラーは API Key フィールドを、not-found は Model Name を、接続エラーはベース URL かコンテナの egress を、長さのエラーは context と max-token の値を指しています。 実行が流れ始めたら、APIsRouter コンソールがリクエストごとのモデル、トークン数、支出を表示します。ワークフローは、エディタから目視するのが難しい形で LLM 呼び出しを増幅させます。利用ログこそが、5ノードのパイプラインの実際のトークンプロファイルを、モデルごと・日ごとに可視化する場所です。

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

よくある質問