Difyにモデルを接続するときは、プロバイダーを追加し、利用する資格情報またはAIクレジットを確認し、アプリ内でモデルを選び、実際の応答まで確かめます。
APIキーを保存できたことと、そのモデルで文章を生成できたことは別の確認です。
この記事は、Dify Cloudでアカウントと作業用workspaceを用意した初学者向けです。
目標は、選択したモデルと利用経路を記録し、短い応答を確認できる設定を作ること。
自分のAPIキーを使う例にはOpenAIを取り上げますが、利用契約や購入を必須にはしません。
資料確認日は2026年10月27日です。
以下は公式資料に基づく未検証の実習手順であり、今回、ログイン、プラグイン導入、キー入力、モデル実行は行っていません。
実際のCloud画面、Dify版、導入済みプラグイン版、モデルID、実行結果は未確認です。
画面の英語名は公式資料に合わせています。
接続の完成条件を先に決める
接続の完成は「一覧にモデルが出た」ではなく、対象モデルへ送った入力に対する実行結果と、どの費用経路で処理したかを確認した状態とします。
この記事では本番アプリを公開せず、仮の確認用Workflowで試します。
| 用語 | この実習での意味 | 確認すること |
|---|---|---|
| プロバイダー | モデルをDifyから利用するための接続先・連携単位 | 目的のModel Providerを選んだか |
| モデル | 文章生成などを担当する個別のモデル | 実際に選べる正確なモデルIDか |
| プロバイダーのAPIキー | 接続先のAPIを利用する資格情報 | 対象project、権限、費用負担が適切か |
| AIクレジット | Dify Cloudで対応モデルに使う利用枠 | 残量、対象モデル、優先する利用経路は何か |
| 応答確認 | 選んだモデルを実行して出力を調べる作業 | ノードの結果と利用経路の証拠があるか |
Dify Cloudでは、対応するプロバイダーを導入し、付属AIクレジットで利用できるモデルなら自分のAPIキーを用意せずに始められます。
一方、自分のキーを登録する経路では接続先のアカウント側に費用が発生します。
すべてのプロバイダーで付属クレジットを使えるわけではありません。
実行前にworkspace・権限・費用を記録する
まず対象workspaceを確認します。
Difyのプロバイダー設定を管理できるのはOwnerまたはAdminです。
プラグインをインストールできる人の範囲はworkspaceのポリシーにも依存するため、インストールボタンが見えない場合に別の個人workspaceへ移って作業を続けないでください。
| 記録欄 | 実習前に確かめる内容 | 分からない場合 |
|---|---|---|
| 環境と権限 | Dify Cloud、対象workspace、自分のrole、確認日 | 担当者へ確認して停止 |
| プロバイダーと版 | 導入する識別子と実際のplugin version | 公開最新版を実環境の版として記入しない |
| モデル | 正確なmodel ID、対応するAPI方式、利用資格 | 利用可能な組み合わせを確認 |
| 利用経路 | AIクレジットまたは自分のAPIキー、Usage Priority | 経路を決めるまで呼び出さない |
| 費用 | 負担者、残量、通貨、読者が決めた今回の金額上限 | 上限未設定なら実行しない |
| 実行と証拠 | 通常の手動実行は1回から開始、出力とノード記録の保存先 | 秘密情報を保存しない方法を決める |
金額上限または通貨が未記入なら、Setupによる資格情報の検査も、後のTest Runも行わず停止します。
「1回」は読者が開始する通常実行の編集上の上限です。
資格情報の検査、内部SDKの再試行、利用経路の切り替えなどで通信回数が増える可能性があり、APIリクエストが必ず1回、費用が必ず一定という意味ではありません。
空入力の確認も含め、予期しない処理が動いたら止めて記録します。
設定したプロバイダーはworkspace内の利用に関係します。
既存の共有設定を変えるときは、他のアプリや費用負担者への影響を確認してください。
教材には実顧客データ、メールアドレス、APIキーを入れず、後述の短い固定文だけを使います。
付属クレジットと自分のAPIキーを使い分ける
経路A：対応モデルをAIクレジットで試す
付属AIクレジットを使う場合は、対象プロバイダーを導入し、現在の残量と対応モデルを確認します。
新規Cloud環境のSandboxに付くクレジットは、公式Quick Startでは一度限りの枠として説明されています。
毎月自動で同じ量が補充される前提にしないでください。
モデルごとの消費や利用条件は変わります。
料金ページに名前が載っていても、今のworkspaceで導入したプラグインに同じ名前で表示されるとは限りません。
手元で選択できるモデルとその条件を確認し、この経路では「自分のキーを検証した」と記録しません。
経路B：OpenAIの自分のAPIキーを使う
OpenAIのAPIを使う場合、ChatGPTのサブスクリプションとAPIの課金は別です。
ChatGPTを有料で利用しているだけで、APIの残高や利用枠が使えるとは判断できません。
API側で対象organizationとproject、利用できるモデル、支払いと利用制限を確認します。
OpenAIのproject設定では、対象projectのAPI Keysから+ Create new secret keyを使ってキーを作成する手順が案内されています。
ただし、DifyでAdminであることはOpenAIでも同じ権限を持つことを意味しません。
標準のproject roleに加えて、organizationのAPI Key Governanceや権限制御によって作成できるキーが制限される場合があります。
既存の適切なprojectを使うか担当者に確認し、作成できないときに権限の広い個人キーで代用しないでください。
キーの権限は、対象モデルとAPI方式に必要な範囲で設定します。
Read Onlyを選べば文章生成にも十分だとは考えず、組織の方針に沿って必要な実行権限を確かめます。
完全な秘密値は作成時にのみ表示されるため、安全に扱い、本文・配布JSON・画面キャプチャへ貼り付けないでください。
OpenAIの現在のSpend limitsには、通知だけの設定とEnforce a hard limitによる停止を伴う設定があります。
organizationとprojectの両方に設定でき、通知だけでは処理は止まりません。
hard limitも反映が完全に瞬時とは限らず、少し超過する場合があります。
今回の予算と通貨を記録し、設定可能な停止制御を確認したうえで、少量の入力から始めます。
Difyの付属クレジットを使う経路にOpenAI projectの上限がそのまま効くとは判断しません。
プロバイダーを追加してモデルを選ぶ
1．目的のModel Providerを導入する
Dify CloudのIntegrations > Model Providerを開き、目的のプロバイダーを探します。
OpenAIの例では、Modelカテゴリーのlanggenius/openaiを確認します。
ツール用のOpenAIプラグインや、別事業者の互換API接続を、同じ名前の接続先として選ばないでください。
2026年10月27日の公開Marketplaceでは1.0.8の表示を確認しました。
これは資料確認時の公開版であり、読者のworkspaceに入っている版の証明ではありません。
導入後に実際の版を記録します。
既存プラグインをこの実習だけのために無条件で更新する必要はありません。
2．資格情報とUsage Priorityを確認する
自分のAPIキーを使う場合は、プロバイダーカードのSetupからキーと必要な項目を設定します。
Difyは資格情報を検査しますが、保存できても、目的のモデルへのアクセス、残高、アプリからの実行まで保証されたわけではありません。
既存設定を扱う場合は、対象のConfigureと資格情報を取り違えないようにします。
標準のOpenAI接続では、Organization IDやcustom API baseは必要な場合だけ指定します。
見知らぬ互換ゲートウェイのURLを追加しないでください。
現在の公式プラグインは、対応する公式モデルでResponses APIを利用する構成を説明しています。
実際のモデル、API方式、プラグイン版を照合し、すべてのモデルに同じtemperatureや出力上限パラメーターを押し付けないようにします。
付属クレジットと自分のキーの両方がある場合は、Usage Priorityを確認します。
優先経路とフォールバックにより、応答が返っても想定と違う経路で処理された可能性があります。
自分のキーを確かめる実習では、実行時刻と接続先側の利用記録などを照合してください。
どちらを使ったか分からない場合は「応答あり・利用経路未確認」と記録します。
任意の記録・保存関連設定は、今回の接続確認のために追加で有効にする必要はありません。
現在のOpenAIプラグインではrequest metadataの有効化がリクエスト等の保存動作にも関係します。
「外へ送られない」「保存されない」と設定を見ずに判断しないでください。
3．テキスト生成用のモデルを明示する
選ぶのは、今回の入力に応答でき、LLMノードでUserメッセージを設定できるテキスト生成モデルです。
provider側のprojectで使えることと、Difyの導入済みプラグインが対応していることの両方を確認します。
モデル名の例を見て、利用できないIDをそのまま入力しないでください。
workspaceのDefault Modelsには、一般的なLLM処理に使うSystem Reasoning Model、知識検索用のEmbedding、検索結果を並べ替えるRerank、音声関連のモデルなどがあります。
今回の短文テストではすべてを設定する必要はありません。
後で作るLLMノードで対象モデルを明示し、既存アプリが参照する共通のデフォルトを不用意に変更しないようにします。
小さなWorkflowで接続を確認する
4．確認専用の3ノードを作る
StudioからCreate from Blankを選び、Workflowとして確認用アプリを作ります。
ここでの名前CONNECT-012は教材上の任意の例です。
アプリ数などの制限に達している場合は、既存アプリを勝手に削除せず、作業場所を確認します。
作成からテストまでの基本操作は公式30-Minute Quick Startに沿います。
構成は次の3ノードです。
接続順に加え、変数の割り当ても行います。
線をつなぐだけでは入力や出力の値が自動的に目的どおり渡るとは限りません。
| ノード | 設定する内容 | 確認点 |
|---|---|---|
| User Input | Short Textの変数probe_textを追加し、必須入力にする | 入力欄の変数名と必須設定 |
| LLM | 対象の正確なモデルを選び、Userメッセージにprobe_textを変数選択で挿入 | 文字列として変数名を書いただけになっていないか |
| Output | 出力名replyに、LLMノードのtext出力を割り当てる | モデルの文章が最終出力へ渡るか |
User Inputは開始時に必要な情報を集めるノードです。
LLMの入力へ値を入れるときは、画面の変数選択を使います。
モデルの出力はLLMのtextからOutputへ渡します。
今回はツール、外部検索、知識ベース、ループ、例外用の成功メッセージを追加しません。
5．空入力を確かめてから短文を送る
先にTest Runを開き、必須のprobe_textが空のまま通常実行できないことを確認します。
これは入力の確認であり、意図的に間違ったAPIキーを送ったり、共有キーを無効化したりするテストではありません。
空欄なのに実行された場合は停止し、必須設定と記録を確認します。
次に、予算・利用経路・モデル選択を確認してから、次の短文をprobe_textへ入力します。
この英文は言語に依存しない接続確認用の固定入力です。
Return only CONNECT_OK. Do not add any other text.
Start Runで通常実行を1回開始します。
期待する出力は次の文字列です。
これは実測結果ではありません。
CONNECT_OK
余分な句読点や説明が付いた場合、固定文への追従は期待と違っていても、それだけで認証失敗とは言えません。
LLMノードの状態、実際の応答、選んだモデルと利用経路を別々に記録します。
逆に、エラー時の代替出力や手入力の固定文が表示されただけでは接続成功としません。
Test RunやLast Runでノードの入出力、エラー、実行時刻などを確認し、秘密情報を含めず記録します。
CloudのProduction LogsにはWorkflowのTest RunやChatflowのPreviewは含まれないため、「後からLogsにあるはず」と考えず、テスト時点の結果を保存してください。
8項目の記録で「確認済み」を判定する
次の表は記入用の確認項目です。
記事を読んだだけで合格にせず、自分の環境で観察できた結果を残してください。
分からない値は未確認にし、スクリーンショットにはキーや個人情報を写さないようにします。
| ID | 確認すること | 期待する状態 |
|---|---|---|
| CONN-01 | 環境と権限 | 対象workspaceで必要な設定権限を持つ |
| CONN-02 | 費用と利用経路 | 負担者、通貨、今回の上限、残量と優先経路を把握した |
| CONN-03 | プロバイダー | 目的のModel Providerと実際の版を記録した |
| CONN-04 | 資格情報 | 選んだ経路に必要な設定があり、秘密値を記録に含めていない |
| CONN-05 | モデルと変数 | 対象model IDを明示し、入力・出力を正しく割り当てた |
| CONN-06 | 空入力 | 必須の入力が空なら通常実行へ進まない |
| CONN-07 | 応答と経路 | LLMの実結果、期待との違い、利用経路の証拠を記録した |
| CONN-08 | 後片付け | 確認用資源を把握し、残すものと削除するものを判断した |
自分のキーで成功したと判断するには、モデルの実応答に加え、そのキーの経路が使われた根拠が必要です。
利用記録の反映に時間がかかる場合や、経路を特定できない場合は、断定せず確認を保留します。
CONNECT_OKとの完全一致は指示への追従、ノード成功は処理、課金記録は利用経路というように、証拠の意味を分けると原因を探しやすくなります。
接続できないときは、失敗した段階を分ける
同じ「動かない」でも、設定権限、資格情報、モデル選択、費用、変数の割り当てでは確認先が違います。
再実行を繰り返す前に、失敗したノードとエラーの詳細を読みます。
次の表は切り分けの目安で、番号だけから原因を断定するものではありません。
| 症状 | まず確認する内容 | 次の行動 |
|---|---|---|
| プロバイダーがない・導入できない | workspace、role、インストール方針、カテゴリー | 担当者と対象の設定画面を確認 |
| キーを保存できない・401 | キーの誤り、失効、対象organization/project、資格情報 | 秘密値を再掲せず、接続先の詳細メッセージを確認 |
| 403やアクセス拒否 | キー権限、projectのモデル許可、利用条件 | 必要な権限を担当者と照合 |
| モデルが見つからない・404 | 実際のmodel ID、plugin version、API endpoint | 対応する組み合わせへ修正してから再確認 |
| 429 | rate limitか、残高・project/organizationのspend limit・利用枠か | 詳細のerror.codeを読み、原因ごとに対応 |
| 空の出力 | LLMのtextに結果があるか、Outputの割り当て | モデル側と変数側の問題を分ける |
| 未対応パラメーター | モデルとAPI方式、指定した生成設定 | 不要な独自設定を外し対応仕様を確認 |
| timeout・5xx | 一時障害、待ち時間、サービス状態 | 記録を残して停止し、状況と費用を見てから再試行を判断 |
特に429は、待てば解消するrate limitだけではありません。
OpenAIではproject_spend_limit_exceededやorganization_spend_limit_exceeded、残高不足なども区別されます。
課金・上限に関するエラーで自動再試行を続けたり、別のキーへ切り替えて制限を回避したりしないでください。
キー漏えいの疑いがある場合は、そのキーを公開資料から消すだけでは不十分です。
接続先で失効させ、依存するアプリへの影響を確認して適切なキーへ切り替えます。
Difyから設定を消す操作と、接続先でキーを失効させる操作は別として扱います。
記録を残して、最初のチャットボットへ進む
実習後は、実際のmodel ID、provider ID、plugin version、確認日時、予算と利用経路、入力、応答、エラー、次の対応を保存します。
実行していない項目に成功や日時を書かず、費用が確認できなければゼロとしないでください。
キーの秘密値は記録に含めません。
確認用Workflowを残すなら用途が分かる名前にし、不要なら自分が作った確認用資源であることと依存関係を確認して削除を判断します。
一時キーを失効させる場合も、共有アプリが使っていないことを確認します。
既存のプロバイダー設定やキーを一括削除する必要はありません。
8項目の表をワークシートとして使うと、後日のモデル変更でも同じ観点で見直せます。
応答と利用経路まで確かめられたら、次は最初のチャットボットを作り、会話の入力と返答を試す段階です。
今回の確認だけで、公開アプリの品質、知識検索、音声機能まで検証したことにはなりません。
参照した公式資料と更新時の確認点
本文中の公式資料は2026年10月27日に確認しました。
画面の場所、プラグイン、モデルの対応、AIクレジットと料金、OpenAIの権限・spend limitは変更され得るため、実習時に再確認します。
公開MarketplaceやGitHubの情報と、実際に導入した環境の版を区別してください。
Cloudの環境準備が未完了なら、先にアカウントと作業workspaceの確認を済ませます。
Self-hosted環境は設定や認証の条件が異なるため、本稿の付属クレジット経路をそのまま適用せず、該当環境の公式手順を参照してください。
