Dify

必須フィールドは1つ — OpenAI-API-compatibleプラグインのAdd ModelフォームにあるAPI Base URL — これでDifyワークスペースのすべてのLLMノードをKunavoに接続します。

# Integrations → Model Provider → OpenAI-API-compatible → Add Model
Type                          LLM
Model Name                    claude-sonnet-5
Model display name            Kunavo · Claude Sonnet 5
API Key                       sk-kn-...
API Base URL                  https://api.kunavo.com/v1
model name for API endpoint   (leave blank — Model Name is already the id)
Completion mode               Chat
Model context size            1000000
Upper bound for max tokens    (your own ceiling for one reply)
Function Call Type            Tool Call     # defaults to no_call
Vision Support                Support       # only if you will send images
Structured Output             Support       # defaults to not supported

# Model context size is per model, not per endpoint: 1000000 is
# claude-sonnet-5's. The table below carries the rest.

手順

1. /app/keys でキーを作成してコピーします。キーは一度だけ表示されます。
2. DifyでIntegrations → Model Providerを開き、Install model providers（またはMarketplace）から、langgeniusが公開しているOpenAI-API-compatibleをインストールします。Difyのドキュメントによると、プロバイダーを管理できるのはワークスペースのオーナーと管理者のみです。
3. そのプロバイダーのカードでAdd Modelをクリックします。このプラグインには定義済みモデルがありません。customizable-modelプロバイダーなので、使いたいIDごとに個別の項目を追加します。
4. 前述のとおりフォームに入力します。Type = LLM、Model Name = KunavoのIDを正確に入力、API Key = sk-kn-キー、API Base URL = https://api.kunavo.com/v1、Completion mode = Chat、Model context size = 以下の表の値を指定します。次にFunction Call Typeを設定し、必要に応じてStructured OutputとVision Supportも設定します。保存します。
5. ワークフローを開き、モデルを使うノードでそのモデルを選択します。Difyではモデルをアプリ単位ではなくノード単位で割り当てるため、分類器と最終出力ノードで、異なるIDと料金のモデルを使えます。モデルを選択していないアプリやノードでは、Default Models → System Reasoning Modelが使われます。
6. 上限を設定したワークフローを1回実行し、DifyではなくKunavoアカウントで料金を確認します。料金表示については、以下の注記をご覧ください。

DifyのOpenAI-API-compatibleプラグインページで2026年9月21日に確認しました。サードパーティの設定は変更されます。ここに記載されたフィールド名が表示内容と一致しなくなった場合は、このページではなく、そのページを正しい情報源としてください。

クライアントをデバッグする前に確認すること

1回のリクエストで、失敗の原因がエンドポイント、キー、設定ファイルのどれかを特定できます。これがJSONを返すなら、同じベースURLとキーがDifyで機能します。

# Settles whether a failure is the endpoint, the key, or the client.
curl -sS https://api.kunavo.com/v1/models \
  -H "Authorization: Bearer sk-kn-..."

フィールドに入力するモデルID

すべてのテキストモデルにはモデルIDでアクセスできます。現在の一覧はGET /v1/models、価格付きのカタログはモデルページにあります。料金は100万トークンあたりのUSDで、入力 / 出力の順です。

「Dify API」と呼ばれるものは2種類あります

このページで扱うのはそのうちの1つですが、検索結果では両者が頻繁に混同されています。

1. Dify にモデルを追加する — これは上の設定手順で行うことです。Dify がクライアント、Kunavo がエンドポイントで、入力する認証情報は sk-kn- キーです。これにより、そのワークスペース内のすべてのアプリにあるすべての LLM ノードから、追加した ID を指定できるようになります。
2. 独自のコードから Dify アプリを呼び出す — 公開済みアプリ向けに Dify が提供する Service API で、Dify が発行する独自の app- キーを使います。そのキーは Dify のものであり、Kunavo のものではありません。また、これを別の場所に向けることはできません。この方向で Kunavo が関与することはありません。

両者は同じアプリ上で同時に動作でき、通常はそうなります。つまり、バックエンドは Dify キーで Dify アプリを呼び出し、アプリ内のノードは Kunavo キーで Kunavo を呼び出します。キーは2つ、請求も2つです。何かが 401 を返したときは、確認する場所も2か所あります。

追加したモデルのコストが Dify に表示されない理由

Dify のファーストパーティ製モデル定義ファイルには料金ブロックがあり、入力・出力の料金とトークン単位が定義されています。Dify はその値にトークン数を掛けて、ログに金額を表示します。一方、上記の日付時点で確認したところ、OpenAI API 互換プロバイダーのスキーマには、料金、単位、通貨のフィールドがどこにも定義されていませんでした。そのため、このプラグイン経由で追加したモデルについて、Dify には掛け合わせる料金がありません。金額欄に何も表示されないのは、割引を見つけたからでも、何かの不具合を起こしたからでもなく、そのためのフィールドが存在しないからです。実際の金額は Kunavo の利用状況で確認し、Dify の数値はトークン数として扱ってください。

関連する設定で、そのままにしておくべきものが1つあります。Include Usage in Stream はデフォルトで有効になっており、最終ストリームチャンクでプロンプトと完了のトークン数を返すようエンドポイントに要求します。これをオフにすると、トークン数も取得できなくなります。

Dify をセルフホストしている場合

Docker Compose スタックは、送信リクエストを ssrf_proxy サービス経由でルーティングするため、エンドポイントはノートパソコンのブラウザーから到達できるだけでなく、コンテナーネットワーク内からも到達できる必要があります。一方では動作し、もう一方ではタイムアウトする場合、通常はこれが原因です。認証情報ではなく、ネットワークの問題です。上記の curl をコンテナー内から実行すれば、直接確認できます。