ガイド一覧へ戻る
比較·2026年9月21日·最終更新 2026年10月1日·読了11分

Dify対n8n:提供するものを基準に選び、3つの課金単位を予算化する

Difyとn8nは実際には競合製品ではありません。提供するものが異なり、混乱しやすいのは料金です。AIレスポンス、ワークフロー実行、tokenは相互に換算できない3つの単位です。

最終確認日:。

Difyとn8nは本当の意味で競合しているわけではなく、提供するものが異なります。Difyは、チャットアプリ、エージェント、RAG対応アシスタントなど、LLMアプリケーションそのものを構築するためのプラットフォームです。n8nは汎用的なワークフロー自動化ツールで、モデル呼び出しは数百あるコネクタ、スケジュール、Webhookと並ぶ1つのノードにすぎません。成果物がAIプロダクトならDifyから始めます。成果物が、時折モデルに質問するビジネスプロセスならn8nから始めます。逆にn8n vs Difyで検索しても答えは同じです。選択の基準は、何を構築するかだからです。

実際に人々をつまずかせるのは料金です。DifyはAI応答ごと、n8nはワークフロー実行ごと、モデルプロバイダーはトークンごとに課金します。この3つの単位は相互に換算できないため、この2つを並べた料金表の多くは、最初の行を読む前からすでに誤解を招きます。

まず2つのバージョンに関する事実です。この組み合わせについてインデックス化された記述の多くは古くなっています。n8nは2.x系列で、最新リリースはn8n@2.39.9、2026年9月21日公開です。Difyには2.xのリリース系列はまったくありません。現在のメジャー系列は1.xで、最新リリースは2026年9月10日の1.17.1です。両方のリポジトリは現在も稼働しており、アーカイブされていません(Difyとn8nの最新リリースページを2026年9月21日に再確認。n8nは頻繁にリリースするため、パッチ番号はすでに変わっている可能性があります)。

どの製品を誰が選ぶべきか

あなたの状況選ぶモデル理由
提供するものは、チャットアプリ、エージェント、またはRAG対応アシスタントですDifyプロンプトワークベンチ、ナレッジベース、公開アプリがプロダクトであり、ノードを組み合わせて構築するものではありません
AIステップは、CRM、メール、スプレッドシート、Webhook、スケジュールなど、より長いプロセスの中にありますn8nモデルノードはコネクタと同じキャンバス上にあるため、モデルが中心ではありません
非管理者はアプリを構築できますが、プロバイダーキーには触れてはいけませんDifyプロバイダーを管理できるのはワークスペース所有者と管理者だけで、追加したキーはワークスペース全体で使われ、そのキーを追加したユーザー自身のプロバイダーアカウントに請求されます
分離された環境とgitによるバージョン管理が必要ですn8nのBusinessティアから「Different environments」と「Version control using Git」は、n8nの料金ページにあるBusinessプラン独自の機能一覧で初めて登場します。StarterとProには記載されていません
ベンダーアカウントなしで自分で運用したいどちらでもよいが、先にライセンスを確認してくださいDify Communityはマルチテナント条項のある変更版Apache 2.0、n8n Communityは内部業務または非商用利用に限られるfair-codeです
一方にはすでに料金を支払っており、もう一方に統合したいどちらでもない、安価にはできませんどちらのプロジェクトも相手の形式用のインポーターを文書化していないため、移行ではなく再構築を見込んで、適合性で選んでください

この表の背後にある2つの構造的な違いは、明確に述べておく価値があります。権限:Difyのプロバイダー設定は、管理者のみが行えるワークスペース全体の操作です。そのドキュメントには、プロバイダーを管理できるのは所有者と管理者だけで、追加したキーは「そのプロバイダーの自分のアカウントに請求される」と明記されています。これは望んでいたガバナンスそのものか、望んでいなかったボトルネックそのもののどちらかです。n8nは代わりにプロジェクトを中心に共有を整理し、料金ページではティアごとに、Starterは共有プロジェクト1つ、Proは3つ、Businessは6つ、Enterpriseは無制限としています。実行モデル:n8nでは、内部でモデル呼び出しが何回行われても、1回の実行は1つのワークフロー実行です。一方、Difyアプリはモデル呼び出しごとに1回課金されるため、同じロジックでも2つのメーターには大きく異なる形で計上されます。

公開されているプランと料金

Dify Cloudはワークスペース単位で料金が設定されています。以下の年間表示は料金ページに実際に表示される文言で、ページには「Bill Annually Save 17%」トグルもあります。

Difyプラン価格メッセージクレジットメンバー / アプリナレッジ
サンドボックス無料200(1回限り、月額ではありません)メンバー1人、アプリ5個ドキュメント50件、50MB、ログ30日間
Professionalワークスペースあたり月額$59、またはワークスペースあたり年額$590月間5,000メンバー3人、アプリ50個ドキュメント500件、5GB、ログ無制限
Teamワークスペースあたり月額$159、またはワークスペースあたり年額$1,590月間10,000メンバー50人、アプリ200個ドキュメント1,000件、20GB、ログ無制限
Community(セルフホスト)無料なし — モデル料金は自分で支払います単一ワークスペース自分のインフラストラクチャ
Enterpriseカスタム、営業に問い合わせ公開なし公開なし公開なし

2026年9月19日にdify.ai/pricingとdify.ai/pricing/dify-cloudを確認しました。比較表には、Sandboxに「5,000 API Rate Limit/month」があり、有料ティアにはそのような制限がないことも示されています。AWS MarketplaceのマシンイメージであるDify Premiumは別SKUです。この確認中にDify公式ページで価格を確認できなかったため、ここでは価格を記載していません。

n8n Cloudはプラン単位で料金が設定され、クォータはモデル呼び出しではなく実行回数です。通貨に関する注意:2026年9月19日の確認ではn8n.io/pricingがユーロで表示されましたが、他の地域の購入者に別の通貨が表示されるかは確認していません。チェックアウト時に確認してください。

n8nプラン価格、年払い実行回数 / 月同時実行AI(Gateway)クレジット
スターター€20/月2,5005月2,300回
Pro€50/月10,00020月最大13,700回
Business€667/月40,000プランカードには記載なしプランカードには記載なし
Enterpriseカスタム、営業に問い合わせカスタム200+プランカードには記載なし
Community(セルフホスト)無料クォータとして販売されていません — 上記の実行回数上限はCloudプランに付属します自分のハードウェアGatewayクレジットはセルフホストでは利用できません

記載されているすべての有料ティアでユーザー数とワークフロー数は無制限で、Business以上ではセルフホストの選択肢が表示されます。無料トライアルでは、Proレベルの機能に加えて、1,000回の実行と同時実行5回が提供されると宣伝されています。

クレジットと呼ばれるものが3種類あります

これはアグリゲーターページが省略するセクションで、予算を左右します。

単位1単位とは何か考慮されないもの
Difyメッセージクレジット / AIクレジット「1回のモデル呼び出し(入力1つと出力1つ)。使用するトークン数にかかわらず、1応答として1つカウントされます」トークン量は完全に無視されます — 200トークンの返信も200,000トークンの返信も、どちらも1応答です。ただし、大きいモデルほど多くのクレジットを消費します
n8n実行「ワークフロー全体の1回の実行。ワークフローに含まれるステップ数や処理するデータ量は関係ありません」ノード数、データ量、実行内で行われるモデル呼び出しの回数
プロバイダートークン100万トークンあたりの単価による入力および出力トークン何もありません — これはモデルが実際に行った作業量を追跡するメーターです

Difyは同じ単位に2つの名称を使います。料金ページでは「message credits」、現行ドキュメントでは「AI credits」と記載されています。Difyのドキュメント自体は、各モデルが1応答あたりに消費するクレジット数について料金ページを参照するよう案内していますが、このページではモデルごとの表を逐語的に抽出できませんでした。そのため、ここにはモデルごとのクレジット数を記載していません。

n8nのクォータは、利用者に有利な形で見た目より狭いものです。その実行ドキュメントには「このクォータに加算されるのは本番実行のみ」と記載され、エディターからの手動実行、Execute Sub-workflowによって呼び出されるサブワークフロー実行(親だけがカウントされます)、エラーワークフロー実行、データを返さないポーリング、不正または拒否されたWebhookリクエストは除外されます。一方で、逆方向の注意もあります。Schedule Triggerは結果に関係なく発火するたびに1回の実行をカウントし、Webhook Triggerは空のボディを含め、それを起動する受信リクエストごとに1回カウントします。

正直な比較で避けて通れない点がもう1つあります。n8nは現在、モデルアクセス自体を販売しています。Gatewayクレジットは「n8n 2.36.0から利用可能」で、n8n Cloud StarterとProに限られ、「n8n Cloud Enterpriseまたはセルフホストn8nでは利用できません」。料金は「サービス料金ページに記載されたレートでリクエストごと」に請求され、追加購入したクレジットは「購入後12か月で失効」します。これはゲートウェイが行うのと同じ役割を、プロダクト内で販売するものです。ドキュメントはn8n Cloudアプリ内のサービス料金ページを指していますが、2026年9月21日にログアウト状態で取得したところ、読める料金表は表示されませんでした。そのため、1ドルあたりのクレジット数や、それとのコスト比較はここでは公開していません。確認できるのは適用範囲です。GatewayクレジットはセルフホストやCloud Enterpriseには及びません。また同じドキュメントには、カタログ外のサービスも「自分のAPIキーで認証情報を作成すれば、通常どおりn8nで動作する」と記載されています。Difyの同等機能はより限定的で、そのことを自ら示しています。キーとAIクレジットは「併用でき」、Usage Priorityスイッチによってどちらから先に引き落とすかが決まります。

いずれか一方を自分のモデルエンドポイントに向ける

どちらもサードパーティのOpenAI互換エンドポイントを受け付け、どちらもAnthropic互換エンドポイントを受け付けます。いずれの場合も境界は「ベースURLを設定できるか」ではありません。そのフィールドは各プロジェクトのソースに含まれる認証情報およびプラグインのスキーマに存在し、どちらの料金ページにもプラン制限はありません。境界となるのは、エンドポイントが応答することを期待されるプロトコルと、既定でオフになっている機能フラグです。

質問n8nDify
エンドポイントの指定場所Credentials → OpenAI、Base URLフィールドの既定値はhttps://api.openai.com/v1。またはCredentials → Anthropic、既定値はオリジンhttps://api.anthropic.comで、/v1は付きません公式のOpenAI-API互換プラグインをインストールし、Model Provider → Add Modelに進みます。API Base URLフィールドは必須です
モデル検出ドロップダウンはGET {base}/modelsを呼び出します。ベースURLがapi.openai.comでない場合、チャット専用のIDフィルターは削除されるため、そのエンドポイントの/modelsが返すものはすべて、チャットモデルかどうかにかかわらず提示されますなし。プラグインはcustomizable-modelのみなので、すべてのモデルを1行ずつ手入力します
プロトコルOpenAI Chat ModelノードにあるUse Responses APIトグル — 未解決の既定値については以下を参照してくださいapi_typeスイッチ、default: chat_completions。代替値はresponsesです
ツール呼び出しチャットモデルを接続したAI Agentノードを通じて動作します既定ではオフです。function_calling_typeの既定値はno_callなので、チャットで動作するゲートウェイでも、設定するまでAgentノードでは暗黙に失敗します
変更できないエンドポイントOpenRouter認証情報はURLをtype: 'hidden'として固定します各カスタムモデルは固有のキーに紐付けられます。唯一のキーを削除すると、モデルも削除されます
BYOK自体に対するプラン制限見つかりませんでした — Base URLフィールドはn8nのソース内の認証情報スキーマで宣言されており、料金ページにはそれに関するティア条件が記載されていませんプロバイダー追加に関するものは見つかりませんでした。複数のキーにリクエストを分散するLoad Balancingは、CloudドキュメントではProfessionalおよびTeamの機能として表示されています

2026年9月19日に取得したソースファイル:OpenAiApi.credentials.ts、AnthropicApi.credentials.ts、OpenRouterApi.credentials.ts、およびDifyのopenai_api_compatible.yaml。知っておくべき点として、n8nの公式OpenAI認証情報ページは現在もAPIキーと組織IDのみを説明しており、Base URLフィールドには一切触れていません。また、それを追加するコミュニティのプルリクエスト(n8n-docs#5146)はマージされないままクローズされました。この経路で最も重要なフィールドが文書化されていないため、代わりにソースファイルを引用しています。

本当に未解決の既定値が1つあります

n8nの2つの公式ソースは、新しく追加したOpenAI Chat Modelノードがどのエンドポイントを呼び出すかについて一致していません。master上のノードソースは、responsesApiEnabledをdefault: trueとして宣言しており、ノードバージョン1.3以上で表示されます。また、1.3がそのノードのバージョン一覧にある最新エントリであるため、Responses APIがオンになっているように読めます。ノードのドキュメントは反対に、「それ以外の場合、OpenAI Chat ModelノードはデフォルトでChat Completions APIを使用します」と説明しています。両方とも2026年9月19日に取得したもので、今日追加されるノードについては両立しません。このページではどちらが正しいかを決めません。ノードを開いてトグルを確認し、その設定によってリクエストが/responsesまたは/chat/completionsのどちらに送られるかを把握してください。どちらか一方だけを提供するエンドポイントに対しては、動作するか、すべての呼び出しで404になるかを分ける設定です。Kunavoは両方の経路を実装しているため、ここではどちらの位置でも対応できますが、思い込まずに確認してください。

n8nでは、カスタムエンドポイントが越えられない境界が2つあります。組み込みのResponsesツールであるWeb Search、File Search、Code InterpreterはOpenAIがホストする機能で、ドキュメントには「AI Agentノードと組み合わせたOpenAI Chat Modelノードを使用する場合のみサポートされる」とも記載されています。また、ノードレベル(認証情報ではなく)で設定されたベースURLは、使用前に認証情報のドメイン制限と照合されます。ノードソースはそのURLに対してassertOpenAiCredentialAllowsUrlを呼び出し、URLがそれらのドメイン外にある場合は例外をスローします。

Dify側では、既定値が重要です。function_calling_type: no_call以外にも、手動で追加したモデルはstructured_output_support: not_supportedとvision_support: no_supportで始まり、それぞれエンドポイントの実際の動作に合わせて手動で設定するトグルです。stream_include_usageは、エンドポイントが最終ストリームチャンクでusageを返さない場合、Difyが最初のプロンプトメッセージだけを数えるローカル推定にフォールバックし、複数メッセージのプロンプトを過少計上するため、既定で有効になっています。同じファイルにはゲートウェイ用の明示的な回避策もあり、「一部のOpenAI互換ゲートウェイが拒否する」ためトップレベルのuserフィールドを省略するオプション、token_param_nameスイッチ、厳格互換モードと拡張互換モードがあります。これは、ゲートウェイ経路がハックではなく、保守されているケースであることを示す十分な証拠です。

Anthropic形式のアクセスについては、Difyの公式Anthropicプラグインがpredefined-modelおよびcustomizable-modelで、任意のanthropic_api_urlフィールドもあるため、組み込みのClaudeリストを別のエンドポイントに向けられます。その場合はIDに注意してください。Difyの組み込みフォルダーには、claude-opus-5、claude-sonnet-5、claude-opus-4-8、claude-opus-4-7、claude-opus-4-6、claude-sonnet-4-6のような日付のないIDと、claude-sonnet-4-5-20250929のような日付付きIDが混在しています。最初のグループの日付のないものはKunavoカタログのスラッグですが、日付付きの形式はそうではなく、Difyのフォルダー内のすべてのIDが現在販売されているものに対応するわけでもありません。キーを使ってGET /v1/modelsを呼び出し、返されたものから選んでください。そのリストには、提供されていないものがすでに除外されています。KunavoのベースURLは2つの規約に正確に従います。OpenAI形式のフィールドにはhttps://api.kunavo.com/v1、Anthropic形式には裸のオリジンhttps://api.kunavo.comです(そこに/v1を追加すると404になる理由は、ベースURLのドキュメントを参照してください)。

n8nのAnthropic認証情報について、テストからではなく両プロジェクトのコードを読んで分かった固有の詳細があります。この認証情報はx-api-keyで認証し、GET {base}/v1/modelsで自身をテストします。Kunavoの/v1/modelsは/v1/messagesと同様、そのヘッダーでキーを受け取るため、認証情報テストとモデルドロップダウンの両方が応答するはずです。ドロップダウンは各モデルをdisplay_nameで表示し、なければIDにフォールバックします。Kunavoのリストにはdisplay_nameがないためIDが表示されます。また、Messagesエンドポイントが提供するclaude-のIDだけでなく、カタログ内のすべてのモデルが含まれるため、その中から選んでください。このページでは、これらを実行時にテストしていません。通常のOpenAI互換経路については、クイックスタートで説明しています。

Difyでゲートウェイキーがカバーできないもの

Difyのワークスペースには5つの既定モデルスロットがあり、モデルプロバイダーのドキュメントに一覧されています。これらが、あらゆるモデルプロバイダーに対する実際の適用範囲のテストになります。Kunavoのキーは5つのうち1つを埋めますが、残り4つはKunavoが実行するものには解決されません。

Difyの既定スロット動作現在のKunavo
システム推論モデル一般的なLLMタスクの既定値対応 — これはチャットカタログ用です
埋め込みモデルナレッジベースのコンテンツをインデックス化し、取得します提供されていません。カタログに埋め込みモデルがないため、このステップはローカルで実行するか、外部プロバイダーに対して実行します
リランクモデル関連性に基づいて検索結果を並べ替えます提供されていません。Difyのリランクタイプは{base}/rerankにPOSTしますが、Kunavoにはそのような経路がありません
音声テキスト変換モデル音声をテキストに変換します提供されていません。カタログには音声テキスト変換モデルがありません
テキスト音声変換モデルテキストを音声に変換します提供されていません。現在、カタログで有効になっているテキスト音声変換モデルはないため、このスロットも別の場所を指します

移行を計画する前に、これを明確に認識してください。DifyのナレッジベースやRAGパイプラインには、依然としてどこかから埋め込みモデルが必要で、通常はリランクモデルも必要です。ゲートウェイキーがカバーするのは推論スロットであり、ワークスペース全体ではありません。RAG実装ガイドでは、この分割を通常どのように構成するかを説明しています。

コスト見積もりの例

これは測定したタスクコストでも請求上限でもない、説明用のトークン計算です。本番で月2,000回実行されるトリアージワークフローを想定し、各実行で2回のモデル呼び出し(分類用と下書き用)が行われ、それぞれ入力トークン4,000個を送り、出力トークン400個を返すものとします。これはモデル呼び出し4,000回、入力トークン1,600万個、出力トークン160万個に相当します。料金は100万トークンあたりのKunavoカタログの現行価格です。

モデル100万トークンあたりの入力/出力月間の推定トークンコスト
Claude Haiku 4.5$0.70 / $3.50$16.80
GPT-5.6 Terra$0.70 / $4.20$17.92
Claude Sonnet 4.6$2.10 / $10.50$50.40
Claude Opus 5$3.50 / $17.50$84.00

ここにプラットフォームのメーターを並べます。同じワークロードはn8nでは本番実行2,000回です。2回のモデル呼び出しが1回の実行内にあるため、Starterの2,500回以内に収まります。DifyではAI応答4,000回です。Difyはモデル呼び出しごとにカウントするため、Sandboxの1回限りのクレジット200を直ちに超え、Professionalの月間クレジット5,000以内に収まります。同じ4,000回の呼び出しでも、モデルの選択だけでトークン分が$16.80から$84.00へ変わります。通常、これはプランティアより大きなレバーです。掲載されている最安料金と、ジョブを完了するための最低コストは別の問題です。リトライが必要な安価なモデルは、リトライ不要な高価なモデルより高くつく可能性があります。

Kunavoのカタログ金額は上限ではなく請求の下限です。上流が料金を報告すると、請求額はカタログコストと、適用されるマークアップを掛けた上流コストのうち大きい方になります。キャッシュ料金と外部ツールはこの例の対象外です。最低チャージ額は前払いクレジットの$10であり、資金補充の最低額であって、タスク料金やサブスクリプションではありません。請求の詳細と、見積もりをそのまま信頼せず自分のワークロードを測定する方法についてのAIコスト最適化を参照してください。

両方を使う方法と、方針を変えるためのコスト

「Difyとn8nのどちらか」という問いに対する、実際に最も一般的な答えは、異なる層で両方を使うことです。DifyはAIアプリを構築してホストし、n8nはそれを起動して結果を業務の他の部分へ接続します。どちらの製品もこの組み合わせを禁じておらず、各ツールを設計どおりの役割に専念させられます。コストは2つのメーターと2組の認証情報になるため、安価な選択肢だと判断する前に両方を確認してください。

移行パスではありません。どちらのプロジェクトも相手の形式用インポーターを文書化していないため、移動ではなくロジックの再構築を前提にしてください。価格ではなく適合性で選ぶべき最大の理由はここにあります。プラン料金は翌月に変更できますが、再構築は元に戻せません。プラットフォームではなくモデルの経路を選ぶ場合は、OpenAI互換APIガイドで両ツールが想定するエンドポイントを、LLMゲートウェイガイドでゲートウェイが提供するものと提供しないものを説明しています。

どちらのクライアントもKunavoに対する実行時テストは行われていません。上記はすべて、現在のソースと現在の公式ドキュメントを読み取った内容であり、Kunavoはどちらのツールについてもセットアップガイドを公開していません。設定は標準的なOpenAI互換のものです。試す間は動作中の経路を利用可能にしておき、範囲を限定したタスクを1つ実行してから、アカウントに実際に記録された請求額を確認してください。キーに入金する準備ができたらKunavoアカウントを作成するか、セットアップが文書化されているクライアントについては統合一覧をご覧ください。

よくある質問

Difyはn8nより優れていますか?

一般論として優れている方はありません。提供するものが異なるためです。DifyはLLMアプリケーションプラットフォームです。リポジトリでは、モデルとツールのサポートを備えたエージェントワークフローやRAGパイプラインを、共同作業用の1つのワークスペースで構築する場所と説明しており、成果物はAIアプリです。n8nは汎用ワークフロー自動化で、モデル呼び出しはコネクター、Webhook、スケジュール、データベースと並ぶ1種類のノードにすぎず、成果物はプロセスです。AIプロダクト自体が中心ならDifyを選んでください。AIステップがより長い業務プロセスの一部ならn8nを選んでください。逆にn8nとDifyのどちらかと尋ねても答えは同じです。選択はどちらのツールが強いかではなく、何を提供するかに関するものです。

Difyとn8nは連携できますか?

はい。これは回避策ではなく、一般的な構成です。Difyでは、公開するすべてのアプリが、自分のバックエンドからAPIキーで呼び出すREST APIを兼ねると説明されています。また、n8nにはHTTP Requestノードがあります。そのため、n8nがトリガー、コネクター、リトライを処理し、Difyアプリをn8nワークフロー内の推論ステップにできます。この構成では両方のメーターを予算化してください。Difyはアプリが行うモデル呼び出しごとにAIレスポンスを1件カウントし、n8nはそれを呼び出したワークフロー全体の実行ごとに本番実行を1件カウントします。どちらのプロジェクトも相手の形式をインポートする機能を文書化していないため、Difyアプリとn8nワークフローは、別のツール間で移行された1つの成果物ではなく、2つの成果物のままです。

Difyとn8nではどちらが安いですか?

プラン価格だけでは答えられません。2つのプランは異なるものを計測し、通常もっともコストがかかるものをどちらも計測しないためです。Dify Cloudはワークスペース単位で料金が設定され、メッセージクレジットをカウントします。AIレスポンス1件は、使用するトークン数に関係なくモデル呼び出し1回です。n8n Cloudはプラン単位で料金が設定され、本番実行をカウントします。1回の実行は、内部に何ステップまたはモデル呼び出しがあるかに関係なく、ワークフロー全体の実行1回です。含まれるクレジット内に収めない限り、モデルのトークン料金は両方に加わる3つ目の請求です。どちらもセルフホスティングすればサブスクリプションはなくなり、各プロジェクトのライセンス制限に従って、インフラ費用とモデル料金が残ります。

RAGにはDifyとn8nのどちらが適していますか?

設計上はDifyです。Difyには、プランごとのドキュメント数とストレージ制限を備えた知識ベースが第一級オブジェクトとして組み込まれており、ワークスペースには推論モデルに加えて、埋め込みと再ランキング専用のデフォルトモデル枠があります。n8nでもベクトルストアノードと埋め込みノードから検索パイプラインを構築できますが、組み立てて保守する必要があります。どちらを選んでもモデル側の影響に注意してください。検索には埋め込みモデルと通常は再ランキングモデルが必要ですが、Kunavoは現在どちらも提供していません。そのため、Difyまたはn8nのRAGスタックのその部分は、選択したプラットフォームに関係なく、ローカルまたは外部プロバイダーに対して実行されます。

Difyとn8nで自分のAPIキーを使用できますか?

どちらもこのフィールドを公開しており、どちらの料金ページにもこの機能に対するプラン制限は示されていません。n8nでは、OpenAI認証情報に編集可能なBase URLがあり、既定値はhttps://api.openai.com/v1です。Anthropic認証情報にも同様のフィールドがありますが、既定値はオリジンであるhttps://api.anthropic.comで、/v1は付きません。OpenRouter認証情報はURLを非表示フィールドとして固定しており、変更できません。Difyでは、公式のOpenAI-API-compatibleプラグインをインストールして各モデルを手動で追加するか、公式のAnthropicプラグインをカスタムAPI URLに向けます。Difyでは、キーと独自のAIクレジットを併用することもでき、プロバイダーカードのUsage Priorityスイッチによって、どちらから先に引き落とすかが決まります。

Difyはオープンソースですか? n8nはオープンソースですか?

どちらの回答にも但し書きが必要で、GitHubのリポジトリAPIは両方のライセンスについてNOASSERTIONを返します。github.com/langgenius/difyとgithub.com/n8n-io/n8nにある2つのLICENSEファイルを引用すると、Difyは変更されたApache License 2.0を使用しています。商用利用は許可されていますが、ソースからマルチテナント環境を運用するには書面による許可が必要です。ここでいう1テナントは1ワークスペースを意味し、フロントエンドのロゴと著作権情報を削除または変更することはできません。n8nはOSIの意味でのオープンソースではなく、fair-codeです。Sustainable Use License v1.0では、自社の内部業務目的、または非商用・個人利用に限って使用または変更が許可されています。ファイル名に.ee.を含むファイル、またはディレクトリ名に.eeを含むファイルには、有料のn8n Enterprise Licenseが必要です。また、master以外のブランチは明示的にライセンスされていません。

2026年9月19日に確認し、9月21日に再確認しました。GitHub API経由で両方のGitHubリポジトリと最新リリース、両方のライセンスファイル、dify.ai/pricing、dify.ai/pricing/dify-cloud、n8n.io/pricing、Difyのモデルプロバイダードキュメント、n8nのexecutions、Gateway credits、OpenAI Chat Modelの各ドキュメント、さらにn8nのOpenAIおよびAnthropic認証情報、OpenAI Chat Modelノード、DifyのOpenAI互換およびAnthropicプラグインマニフェストの生ソースを確認しました。どちらの製品もインストールしておらず、Kunavoを接続もしていないため、ここに記載した内容はテスト結果ではありません。Kunavoのトークン単価はライブカタログに基づき、すべてのドル額は説明用の算術例です。